Difference between analysis and design
The aim of analysis is to understand the problem with a view to eliminate any
deficiencies in the requirement specification such as in completeness ,I nconsistencies, etc. The
model which we are trying to build may be or may not be ready .The aim of design is to produce
a model that will provide a seamless transition to the coding phase, i.e. once the requirements are
analyzed and found to be satisfactory, a design model is created which can be easily
implemented.
Items developed during the software design phase
For a design to be easily implemented in a conventional programming language,
The following items must be designed during the design phase.
Different modules required to implement the design solution.
Control relationship among the identified modules. The relationship is also known
as the call relationship or invocation relationship among modules.
Interface among different modules.
Identifies the exact data items exchanged among the modules.
Data structures of the individual modules.
Algorithms required implementing each individual module.
2.2.1 GOOD SOFTWARE DESIGN
The definition of “a good software design” can vary depending on the application being
designed.
For example, the memory size used by a program may be an important issue to
characterize a good solution for embedded software development – since embedded applications
are often required to be implemented using memory of limited size due to cost, space, or power
consumption considerations. For embedded applications, one may sacrifice design
comprehensibility to achieve code compactness. For embedded applications, factors like design
comprehensibility may take a back seat while judging the goodness of design.
Therefore, the criteria used to judge how good a given design solution is can vary widely
depending upon the application.
Not only is the goodness of design dependent on the targeted application, but also the
notion of goodness of a design itself varies widely across software engineers and academicians.
However, most researchers and software engineers agree on a few desirable
characteristics that every good software design for general application must possess.
The characteristics are listed below:
Correctness: A good design should correctly implement all the functionalities
identified in the SRS document.
Understandability: A good design is easily understandable.
Efficiency: It should be efficient.
Maintainability: It should be easily amenable to change.
Possibly the most important goodness criterion is design correctness. A design has to be
correct to be acceptable. Given that a design solution is correct, understand ability of a design is
possibly the most important issue to be considered while judging the goodness of a design.
A design that is easy to understand is also easy to develop, maintain and change. Thus,
unless a design is easily understandable, it would require tremendous effort to implement and
maintain it.
2.2.2 COHESION AND COUPLING
Cohesion
Most researchers and engineers agree that a good software design implies clean
decomposition of the problem into modules, and the neat arrangement of these modules in
a hierarchy.
The primary characteristics of neat module decomposition are high cohesion and low
coupling. Cohesion is a measure of functional strength of a module.
A module having high cohesion and low coupling is said to be functionally independent of
other modules. By the term functional independence, we mean that a cohesive module
performs a single task or function.
A functionally independent module has minimal interaction with other modules.
Classification of cohesion
The different classes of cohesion that a module may possess are depicted in the
following
Coincidental cohesion:
A module is said to have coincidental cohesion, if it performs a set of tasks that relate to
each other very loosely, if at all. In this case, the module contains a random collection of
functions.
It is likely that the functions have been put in the module out of pure coincidence
without any thought or design
. For example, in a transaction processing system (TPS), the get-input, print-error, and
summarize-members functions are grouped into one module. The grouping does not have any
relevance to the structure of the problem.
Logical cohesion:
A module is said to be logically cohesive, if all elements of the module perform similar
operations, e.g. error handling, data input, data output, etc. An example of logical cohesion is the
case where a set of print functions generating different output reports are arranged into a single
module.
Temporal cohesion:
When a module contains functions that are related by the fact that all the functions must
be executed in the same time span, the module is said to exhibit temporal cohesion. The set of
functions responsible for initialization, start-up, shutdown of some process, etc. exhibit temporal
cohesion.
Procedural cohesion:
A module is said to possess procedural cohesion, if the set of functions of the module are
all part of a procedure (algorithm)in which certain sequence of steps have to be carried out for
achieving an objective, e.g. the algorithm for decoding a message.
Communicational cohesion:
A module is said to have communicational cohesion, if all functions of the module refer
to or update the same data structure, e.g. the set of functions defined on an array or a stack.
Sequential cohesion:
A module is said to possess sequential cohesion, if the elements of a module form the
parts of sequence, where the output from one element of the sequence is input to the next. For
example, in a TPS, the get-input, validate-input, sort-input functions are grouped intoone
module.
