SOFTWARE DESIGN

• During the software design phase, the design document is produced, based
on the customer requirements as documented in the SRS document.

• The activities carried out during the design phase (called as design process
) transform the SRS document into the design document.

• This view of a design process has been shown schematically in Figure 5.1.
• The design process starts using the SRS document and completes with the
production of the design document.

• The design document produced at the end of the design phase should be
implementable using a programming language in the subsequent (coding)
phase.
OVERVIEW OF THE DESIGN PROCESS
Outcome of the Design Process

🞆 The following items are designed and documented during the design phase.

1. Different modules required:

🞆 The different modules in the solution should be clearly identified.

🞆 Each module is a collection of functions and the data shared by the functions of the
module.

🞆 Each module should accomplish some well-defined task out of the overall responsibility
of the software.

🞆 Each module should be named according to the task it performs.

🞆 For example, in an academic automation software, the module consisting of the

functions and data necessary to accomplish the task of registration of the students
should be named handle student registration
2. Control relationships among modules:
⚫ A control relationship between two modules essentially arises due to
function calls across the two modules.
⚫ The control relationships existing among various modules should be
identified in the design document.

3. Interfaces among different modules:

⚫ The interfaces between two modules identifies the exact data items that
are exchanged between the two modules when one module invokes a
function of the other module.

4. Data structures of the individual modules:

⚫ Each module normally stores some data that the functions of the module
need to share to accomplish the overall responsibility of the module.
⚫ Suitable data structures for storing and managing the data of a module
need to be properly designed and documented.
5. Algorithms required to implement the individual modules:
⚫Each function in a module usually performs some processing

activity.
⚫ The algorithms required to accomplish the processing activities of

various modules need to be carefully designed and documented

with due considerations given to the accuracy of the results, space
and time complexities.
CLASSIFICATION OF DESIGN ACTIVITIES
• A good software design is seldom realized by using a single step
procedure called the design activities.
• Let us first classify the design activities.
• Depending on the order in which various design activities are
performed, we can broadly classify them into two important
stages.
⚫ Preliminary (or high-level) design, and
⚫ Detailed design.

• The meaning and scope of these two stages can vary considerably
from one design methodology to another.
⮚Preliminary (or high-level) design
• The outcome of high-level design is called the program structure or
the software architecture.

• High-level design is a crucial step in the overall design of a software.

• When the high-level design is complete, the problem should have
been decomposed into many small functionally independent modules

that are cohesive, have low coupling among themselves, and are

arranged in a hierarchy.

• Many different types of notations have been used to represent a

high-level design.
• A notation that is widely being used for procedural
development is a tree-like diagram called the structure chart.
• Another popular design representation techniques called
UML that is being used to document object-oriented design,
involves developing several types of diagrams to document
the object-oriented design of a systems.

• Though other notations such as Jackson diagram or Warnier-

Orr diagram are available to document a software design

• Once the high-level design is complete, detailed design is

undertaken.
➢ Detailed design.
• The outcome of the detailed design stage is usually documented
in the form of a Module Specification (MSPEC) document.

• After the high-level design is complete, the problem would

have been decomposed into small modules, and the data

structures and algorithms to be used described using MSPEC

and can be easily grasped by programmers for initiating coding.

HOW TO CHARACTERISE A GOOD SOFTWARE
DESIGN?
• Correctness: A good design should first of all be correct. That is, it
should correctly implement all the functionalities of the system.

• Understandability: A good design should be easily

understandable. Unless a design solution is easily understandable,
it would be difficult to implement and maintain it.

• Efficiency: A good design solution should adequately address

resource, time, and cost optimization issues.

• Maintainability: A good design should be easy to change. This is

an important requirement, since change requests usually keep
coming from the customer even after product release.
 UNDERSTANDABILITY OF A DESIGN: A MAJOR
CONCERN
• While performing the design of a certain problem, assume that we
have arrived at a large number of design solutions and need to
choose the best one.

• Obviously all incorrect designs have to be discarded first.

• Out of the correct design solutions, how can we identify the best
one?

• Given that we are choosing from only correct design solutions,

understandability of a design solution is possibly the most important
issue to be considered while judging the goodness of a design.

• A good design solution should be simple and easily understandable.

• A design that is easy to understand is also easy to develop
and maintain.

• A complex design would lead to severely increased life cycle

costs.

• Unless a design is easily understandable, it would require

tremendous effort to implement, test, debug, and maintain
it

• Besides, a design solution that is difficult to understand

would lead to a program that is full of bugs and is unreliable.
AN UNDERSTANDABLE DESIGN IS MODULAR AND
LAYERED

• How can the understandability of two different designs be

compared, so that we can pick the better one?
• To be able to compare the understandability of two design
solutions, we should at least have an understanding of the general
features that an easily understandable design should possess.
• A design solution should have the following characteristics to be
easily understandable:
• It should assign consistent and meaningful names to various design
components.
• It should make use of the principles of decomposition and
abstraction in good measures to simplify the design.
• We can now define the characteristics of an easily
understandable design as follows: A design solution is
understandable, if it is modular and the modules are arranged
in distinct layers.

• A design solution should be modular and layered to be

understandable.
MODULARITY
➢ A modular design is an effective decomposition of a problem.
➢ It is a basic characteristic of any good design solution.
➢ A modular design, in simple words, implies that the problem has
been decomposed into a set of modules that have only limited
interactions with each other.
➢ Decomposition of a problem into modules facilitates taking
advantage of the divide and conquer principle.
➢ If different modules have either no interactions or little interactions
with each other, then each module can be understood separately.
➢ This reduces the perceived complexity of the design solution
greatly.
➢ For example, consider two alternate design solutions to a problem that are
represented in Figure 5.2, in which the modules M1 , M2 etc. have been
drawn as rectangles.

➢ The invocation of a module by another module has been shown as an

arrow.

➢ It can easily be seen that the design solution of Figure 5.2(a) would be
easier to understand since the interactions among the different modules is
low.

➢ But, can we quantitatively measure the modularity of a design solution?

➢ Unfortunately, there are no quantitative metrics available yet to directly
measure the modularity of a design.

➢ However, we can quantitatively characterize the modularity of a design

solution based on the cohesion and coupling existing in the design.
➢ A design solution is said to be highly modular, if the
different modules in the solution have high cohesion and
their inter-module couplings are low.

➢ A software design with high cohesion and low coupling

among modules is the effective problem decomposition.

➢ Such a design would lead to increased productivity during

program development by bringing down the perceived
problem complexity.
LAYERED DESIGN
➢ A layered design is one in which when the call relations among
different modules are represented graphically, it would result
in a tree-like diagram with clear layering.
➢ In a layered design solution, the modules are arranged in a
hierarchy of layers.
➢ A module can only invoke functions of the modules in the layer
immediately below it.
➢ The higher layer modules can be considered to be similar to
managers that invoke (order) the lower layer modules to get
certain tasks done.
➢ A layered design can be considered to be implementing control
abstraction, since a module at a lower layer is unaware of (about
how to call) the higher layer modules.
➢ A layered design can make the design solution easily
understandable, since to understand the working of a module, one
would at best have to understand how the immediately lower
layer modules work without having to worry about the functioning
of the upper layer modules.
➢ When a failure is detected while executing a module, it is obvious
that the modules below it can possibly be the source of the error.
➢ This greatly simplifies debugging since one would need to
concentrate only on a few modules to detect the error.
COHESION AND COUPLING

➢ Good module decomposition is indicated through high cohesion of the

individual modules and low coupling of the modules with each other.

➢ Cohesion is a measure of the functional strength of a module, whereas

the coupling between two modules is a measure of the degree of

interaction (or interdependence) between the two module.

➢ Coupling: Intuitively, we can think of coupling as follows. Two modules are

said to be highly coupled, if either of the following two situations arise:

➢ If the function calls between two modules involve passing
large chunks of shared data, the modules are tightly
coupled.

➢ If the interactions occur through some shared data, then

also we say that they are highly coupled.

➢ If two modules either do not interact with each other at all

or at best interact by passing no data or only a few
primitive data items, they are said to have low coupling.
➢ Cohesion:
• When the functions of the module co-operate with each
other for performing a single objective, then the module
has good cohesion.

• If the functions of the module do very different things and

do not co-operate with each other to perform a single
piece of work, then the module has very poor cohesion.
CLASSIFICATION OF COHESIVENESS
1. 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, we can say that the module contains a random
collection of functions.
2. Logical cohesion: A module is said to be logically cohesive, if all
elements of the module perform similar operations.
3. Temporal cohesion: When a module contains functions that are related
by the fact that these functions are executed in the same time span,
then the module is said to possess temporal cohesion.
4. Procedural cohesion: A module is said to possess procedural cohesion,
if the set of functions of the module are executed one after the other,
though these functions may work towards entirely different purposes
and operate on very different data.
5. Communicational cohesion: A module is said to have
communicational cohesion, if all functions of the module
refer to or update the same data structure.
6. Sequential cohesion: A module is said to possess sequential
cohesion, if the different functions of the module execute
in a sequence, and the output from one function is input to
the next in the sequence.
7. Functional cohesion: A module is said to possess functional
cohesion, if different functions of the module co-operate to
complete a single task.
CLASSIFICATION OF COUPLING
1. Data coupling: Two modules are data coupled, if they communicate
using an elementary data item that is passed as a parameter between
the two, e.g. an integer, a float, a character, etc. This data item should
be problem related and not used for control purposes.

2. Stamp coupling: Two modules are stamp coupled, if they communicate

using a composite data item such as a record in PASCAL or a structure in
C.

3. Control coupling: Control coupling exists between two modules, if data

from one module is used to direct the order of instruction execution in
another. An example of control coupling is a flag set in one module and
tested in another module.
4. Common coupling: Two modules are common coupled, if
they share some global data items.

5. Content coupling: Content coupling exists between two

modules, if they share code. That is, a jump from one
module into the code of another module can occur.
Modern high-level programming languages such as C do

not support such jumps across modules.