Chapter 5 Software Design
Chapter 5 Software Design
Software Design
❖ More creative than analysis
WHAT IS DESIGN
‘HOW’
Completed design
Fig. 1 : Design framework
Software Design
design
Satisfy
Customer Developers
(Implementers)
Software Design
Conceptual Design and Technical Design
D
e
What How
s
Conceptual Technical
design i design
g
A two part
e design System
Customer
process
r Builders
Fig. 2 : A two part design process
s
Software Design
Informal More
design Informal formal Finished
outline design design
design
i. Fortran subroutine
ii. Ada package
iii. Procedures & functions of PASCAL & C
iv. C++ / Java classes
v. Java packages
vi. Work assignment for an individual programmer
Software Design
(Uncoupled : no dependencies)
(a)
Software Design
Common coupling
With common coupling, module A and module B have shared
data. Global data areas are commonly found in programming
languages. Making a change to the common data means tracing
back to all the modules which access that data to evaluate the
effect of changes.
Software Design
Content coupling
Content coupling occurs when module A changes data of
module B or when control is passed from one module to the
middle of another. In Fig. 9, module B branches into D, even
though D is supposed to be under the control of C.
Software Design
Module
strength
Types of cohesion
➢ Functional cohesion
➢ Sequential cohesion
➢ Procedural cohesion
➢ Temporal cohesion
➢ Logical cohesion
➢ Coincident cohesion
Software Design
Sequential Cohesion
Communicational Cohesion
Procedural Cohesion
Temporal Cohesion
Logical Cohesion
Functional Cohesion
➢ A and B are part of a single functional task. This is very good
reason for them to be contained in the same procedure.
Sequential Cohesion
➢ Module A outputs some data which forms the input to B. This is
the reason for them to be contained in the same procedure.
Software Design
Procedural Cohesion
➢Procedural Cohesion occurs in modules whose
although instructions different tasks yet have
accomplish
because there is a been
specificcombined
order in which the tasks are to
be completed.
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.
Software Design
Logical Cohesion
➢ Logical cohesion occurs in modules that contain instructions
that appear to be related because they fall into the same logical
class of functions.
Coincidental Cohesion
➢ Coincidental cohesion exists in modules that contain
instructions that have little or no relationship to one another.
Software Design
Relationship between Cohesion & Coupling
If the software is not properly modularized, a host of seemingly
trivial enhancement or changes will result into death of the project.
Therefore, a software engineer must design the modules with goal of
high cohesion and low coupling.
Top-Down Design
A top down design approach starts by identifying the major modules
of the system, decomposing them into their lower level modules and
iterating until the desired level of detail is achieved. This is 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.
Software Design
Hybrid Design
For top-down approach to be effective, some bottom-up approach is
essential for the following reasons:
Design Notations
Design notations are largely meant to be used during the process
of design and are used to represent design or design decisions.
For a function oriented design, the design can be represented
graphically or mathematically by the following:
➢ Data Dictionaries
➢ Structure Charts
➢ Pseudocode
Software Design
Structure Chart
It partition a system into block boxes. A black box means that
functionality is known to the user without the knowledge of internal
design.
Pseudocode
Pseudocode notation can be used in both the preliminary and detailed
design phases.
Using pseudocode, the designer describes system characteristics
using short, concise, English language phrases that are structured by
key words such as It-Then-Else, While-Do, and End.
Software Design
Functional Procedure Layers
➢ Function are built in layers, Additional notation is used to
specify details.
➢ Level 0
▪ Function or procedure name
▪ Author, date
Software Design
➢ Level 1
▪ Function Parameters (problem variables, types, purpose,
etc.)
▪ Global variables (problem variable, type,
purpose, sharing information)
▪ Routines called by the function
▪ Side effects
▪ Input/Output Assertions
Software Design
➢ Level 2
▪ Local data structures (variable etc.)
▪ Timing constraints
➢ Level 3
▪ Body (structured chart, English pseudo code,
decision tables, flow charts, etc.)
Software Design
IEEE Recommended practice for software design
descriptions (IEEE STD 1016-1998)
➢ Scope
An SDD is a representation of a software system that is used as a medium
for communicating software design information.
➢ References
▪ Design entities
a) Identification f) Dependencies
b) Type g) Interface
c) Purpose h) Resources
d) Function i) Processing
e) Subordinates j) Data
Software Design
Cont…
Software Design
Table 1:
Organization of
SDD
Software Design
Design View Scope Entity attribute Example
representation
Decomposition Partition of the system into Identification, type Hierarchical
description design entities purpose, function, decomposition diagram,
subordinate natural language
i. Objects
iii. Abstraction
In object oriented design, complexity is managed using abstraction.
Abstraction is the elimination of the irrelevant and the amplification of
the essentials.
Software Design
iv. Class
In any system, there shall be number of objects. Some of the objects
may have common characteristics and we can group the objects
according to these characteristics. This type of grouping is known as a
class. Hence, a class is a set of objects that share a common structure
and a common behavior.
We may define a class “car” and each object that represent a car
becomes an instance of this class. In this class “car”, Indica, Santro,
Maruti, Indigo are instances of this class as shown in fig. 20.
Fig.20: Indica, Santro, Maruti, Indigo are all instances of the class “car”
Software Design
vi. Operations
An operation is a function or transformation that may be applied to or
by objects in a class. In the square class, we have two operations: set
colour() and draw(). All objects in a class share the same operations.
An object “knows” its class, and hence the right implementation of the
operation. Operation are shown in the third part of the class as
indicated in fig. 21.
Software Design
vii. Inheritance
Imagine that, as well as squares, we have triangle class. Fig. 22 shows
the class for a triangle.
Now, comparing fig. 21 and 22, we can see that there is some
difference between triangle and squares classes.
For example, at a high level of abstraction, we might want to think of a
picture as made up of shapes and to draw the picture, we draw each
shape in turn. We want to eliminate the irrelevant details: we do not
care that one shape is a square and the other is a triangle as long as
both can draw themselves.
To do this, we consider the important parts out of these classes in to a
new class called Shape. Fig. 23 shows the results.
Software Design
The class diagram shows the relationship amongst classes. There are
four types of relationships in class diagrams.