UNIT-3

Software Design

Software design
More creative than analysis
Problem solving activity

Software design
Software design involves identifying the
component of software design, their inner
workings, and their interface from the SRS. The
principle work of this activity is the software
design document (SDD) which is also referred
as software design description
Software design deals with transforming the
customer requirements, as described in the SRS
document, into a form (a set of documents)
called software design document that is suitable
for implementation in a programming language.

Design Framework

Conceptual v/s Technical design

The conceptual design answers

Where will the data come from

What will happen to the data in the system
What is the timing of vents
How will the reports will be generated

conceptual design describe the system in language

understandable to the customer. it does not contain any
technical jargons and is independent of implementation.
By contrast, the technical design describe the hardware
configuration, software needs ,the communication
interface, input and out put of the system anything else
that translate the requirement in to a solution to
customers problem

Characteristics of a good software

design
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.

Features of a design document

It should use consistent and meaningful
names for various design components.
The design should be modular. The term
modularity means that it should use a
cleanly decomposed set of modules.
It should neatly arrange the modules in a
hierarchy, e.g. in a tree-like diagram.

Software Design process

Architectural Design (Top Level design):Describe how software is decomposed
and organized into components
Detailed Design (Low level design):describe the specific behavior of these
components. the output of this process is
a set of models that records the major
decision that have been taken.

Modularity or Modular design

software is decomposed of software modules
such that a change in one module has minimal
effect on other modules
A software module is a program unit consisting
of procedures, functions, and data structures
that
- can be separately compiled, and
- independently callable unit of code

Modularity or Modular design

The development of a modular design structure
is guided by the need for satisfying design
criteria regarding the coupling of pairs of
modules, and the cohesion, complexity, and
reusability of individual components in each
module
coupling is a measure of level of the interactions
between two modules

Software Design principle for

Modularity

Decomposition and modularization

Coupling and cohesion
Top-Down and Bottom-Up strategies
Design Complexity
Abstraction
Encapsulation/Information hiding

Decomposition and modularization

Decomposition and modularization large
software in to small independent once,
usually with the goal of placing different
functionality or responsibility in different
component

Coupling
Coupling is the measure of the degree of
interdependence between modules.
Coupling is highly between components if they
depend heavily on one another, (e.g., there is a
lot of communication between them).
Coupling is loose if there are few dependencies
between components.
Loose coupling promotes maintainability and
adaptability since changes in one component are less
likely to affect others.

High and low coupling

Coupling
Modules interact by passing parameters
through a call statement, or by sharing
common data and file structures. The goal
of modular design is to reduce the level of
coupling between modules

Module A
Module B

 The goal of modular design is to reduce

the level of coupling between modules and
increase the cohesion of each module
The following forms of module coupling
are listed from the lowest to the highest
levels of coupling

Coupling

Coupling
1. Data coupling: communication between modules is
accomplished through well-defined parameter lists consisting
of data information items
2.Stamp coupling: Stamp coupling occurs between module A
and B when complete data structure is passed from one
module to another.
Two normally coupled components are stamp coupled if one
passes to the other a complete piece of data - one with
meaningful internal structure
E.g customer record
3. Control coupling: Two components are control coupled if
one passes to the other a piece of information intended to
control the internal logic of another

Coupling
4. External Coupling
Common coupling: modules share common or
global data or file structures. This is the strongest
form of coupling both modules depend on the
details of the common structure
5. Content coupling: A module is allowed to access
or modify the contents of another, e.g. modify its
local or private data items. This the strongest form
of coupling

Example of common coupling

Example of content coupling

Cohesion
Cohesion is a measure of the internal relatedness of
the components of a module.
or

Cohesion
Cohesion is a measure of the degree to which the elements of a
module are functionally related.
Cohesion is weak if elements are bundled simply because they
perform similar or related functions (e.g., java.lang.Math).
Cohesion is strong if all parts are needed for the functioning of
other parts (e.g. java.lang.String).
Important design objective is to maximize module cohesion
and minimize module coupling

Cohesion
Functional cohesion: Every essential element to a single
computation is contained in the component. A and B are
part of a single functional task. This is very good reason
for them to be contained in the same procedure or
achieved when the components of a module cooperate
in performing exactly one function,
Sequential Cohesion :The output of one component is the
input to another. Module A outputs some data which
forms the input to B. This is the reason for them to be
contained in the same procedure.

 Communicational cohesion: Module

performs a series of actions related by a
sequence of steps to be followed by the
product and all actions are performed on
the same data. it is achieved when
software units or components of a module
sharing a common information or data
structure are grouped in one module

Example of Communicational
cohesion
Update record in data
base and send it to
the printer.

database.Update
(record).
record.Print().

Cohesion

Procedural cohesion: is the form of cohesion

obtained when software components are
grouped in a module to perform a series of
functions following a certain procedure
specified by the application requirements

Example of Procedural cohesion

...
Read part number from
data base
update repair record on
maintenance file.
...

May be useful to
abstract the intent of
this sequence. Make
the data base and
repair record
components handle
reading and updating.
Make component that
handles more
abstract operation.

 Temporal cohesion: Module exhibits

temporal cohesion when it contains tasks
that are related by the fact that all tasks
must be executed in the same time-span.
Examples are functions required to be
activated for a particular input event, or
during the same state of operation

Cohesion
Logical cohesion: Elements of component are
related logically and not functionally, such as
input/output functions, communication type
functions (such as send and receive),
Example
A component reads inputs from tape, disk, and
network. All the code for these functions are in
the same component. Operations are related,
but the functions are significantly different.

 Coincidental cohesion: Coincidental cohesion

exists in modules that contain instructions that have
little or no relationship to one another
Example
Print next line
Reverse string of characters in second argument
Add 7 to 5th argument
Convert 4th argument to float

Examples of Cohesion
Function A
Function Function
B
C
Function Function
D
E

Coincidental
Parts unrelated

logic

Function A

Time t0

Function A

Time t0 + X

Function A

Logical
Similar functions
Function A
Function B
Function C

Procedural
Related by order of functions

Time t0 + 2X

Temporal
Related by time

Examples of Cohesion
Function A

Function A

Function B

Function B

Function C

Function C

Communicational
Access same data

Sequential
Output of one is input to another
Function A part 1
Function A part 2
Function A part 3

Functional
Sequential with complete, related functions

Top-Down and Bottom-Up strategies

Top-down Design:
Start from the highest level of component of the hierarchy
and proceed throw low levels
A top-down design approach starts by identifying the
major components of the system, decomposing them into
their lower-level components and iterating until the
desired level of detail is achieved.
Top-down design methods often result in some form of
stepwise refinement Starting from an abstract design, in
each step the design is refined to a more concrete level,
until we reach a level where no more refinement is
needed and the design can be implemented directly.
Most design methodologies are based on the top-down
approach.

Top-Down and Bottom-Up strategies

Bottom-Up Design:
Start from the lowest level of component of the hierarchy
and proceed throw higher levels component
Modules are collected together in the form of library and
combine these modules to provide larger once
The operations of this layer are then used to implement
more powerful operations and a still higher layer of
abstraction.
until the stage is reached where the operations
supported by the layer are those desired by the system.

Top-Down and Bottom-Up strategies

Design Complexity
Complexity is another design criteria used in
the process of decomposition and refinement. A
module should be simple enough to be regarded
as a single unit for purposes of verification and
modification
a measure of complexity for a given module is
proportional to the number of other modules
calling this module (termed as fan-in), and the
number of modules called by the given module
..
(termed as fan-out)
Fan-in
No. of calls
Complex
Module

No. of calls

Fan-out

Abstraction
It is a tool that permit a designer to consider a
component at abstract level; without worrying
about the detail of the implementation of the
component.
Major kind of abstraction
Functional abstraction- is a normal sequence of
action that limits to specific function
Data abstraction- normal collection of data
objects and attributes
Control abstraction- program control mechanism

Encapsulation/ Information Hiding

the concept of information hiding is to hide the
implementation details of shared information and
processing items by specifying modules called
information hiding modules
Design decisions that are likely to change in the future
should be identified and modules should be designed in
such a way that those design decisions are hidden from
other modules
Module Interfaces are created to allow other modules
accessibility to shared items without having visibility to its
internal implementations