Software Engineering (3rd ed.), By K.

K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 1
 Software Design
❖ More creative than analysis

❖ Problem solving activity

WHAT IS DESIGN

‘HOW’

Software design document (SDD)

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 2
 Software design
Software design is the process by which an agent creates a
specification of a software artifact, intended to accomplish goals,
using a set of primitive components and subject to constraints.
Software design may refer to either "all the activity involved in
conceptualizing, framing, implementing, commissioning, and
ultimately modifying complex systems" or "the activity following
requirements specification and before programming

Software design usually involves problem solving and planning a

software solution. This includes both a low-level component and
algorithm design and a high-level, architecture design.
 Software Design
Initial requirements

Gather data on user requirements

Analyze requirements data

Validate the design Obtain answers to

against the requirement
requirements questions

Conceive of a high level design

Refine & document the design

Completed design
Fig. 1 : Design framework
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 4
 Software Design

design

Satisfy

Customer Developers
(Implementers)

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 5
 Set of principles for software
design
The design process should not suffer from "tunnel vision." A good designer should
consider alternative approaches, judging each based on the requirements of the problem,
the resources available to do the job.
The design should be traceable to the analysis model. Because a single element of the
design model can often be traced back to multiple requirements, it is necessary to have a
means for tracking how requirements have been satisfied by the design model.
The design should not reinvent the wheel. Systems are constructed using a set of
design patterns, many of which have likely been encountered before. These patterns should
always be chosen as an alternative to reinvention. Time is short and resources are limited;
design time should be invested in representing (truly new) ideas by integrating patterns that
already exist (when applicable).
The design should "minimize the intellectual distance" between the software and the
problem as it exists in the real world. That is, the structure of the software design should,
whenever possible, mimic the structure of the problem domain.
The design should exhibit uniformity and integration. A design is uniform if it appears
fully coherent. In order to achieve this outcome, rules of style and format should be defined
for a design team before design work begins. A design is integrated if care is taken in
defining interfaces between design components.
The design should be structured to accommodate change. The design concepts
discussed in the next section enable a design to achieve this principle.
The design should be structured to degrade gently, even when aberrant data, events, or
operating conditions are encountered. Well-designed software should never "bomb"; it
should be designed to accommodate unusual circumstances, and if it must terminate
processing, it should do so in a graceful manner.
Design is not coding, coding is not design. Even when detailed procedural designs are
created for program components, the level of abstraction of the design model is higher
than the source code. The only design decisions made at the coding level should address
the small implementation details that enable the procedural design to be coded.
The design should be assessed for quality as it is being created, not after the fact. A
variety of design concepts and design measures are available to assist the designer in
assessing quality throughout the development process.
The design should be reviewed to minimize conceptual (semantic) errors. There is
sometimes a tendency to focus on minutiae when the design is reviewed, missing the
forest for the trees. A design team should ensure that major conceptual elements of the
design (omissions, ambiguity, inconsistency) have been addressed before worrying about
the syntax of the design model.
Software Design Levels
Software design have three levels:
Architectural Design - The architectural design is the highest
abstract version of the system. It identifies the software as a system
with many components interacting with each other. At this level, the
designers get the idea of proposed solution domain.
High-level Design- The high-level design breaks the ‘single entity-
multiple component’ concept of architectural design into less-
abstracted view of sub-systems and modules and depicts their
interaction with each other. High-level design focuses on how the
system along with all of its components can be implemented in forms
of modules. It recognizes modular structure of each sub-system and
their relation and interaction among each other.
Detailed Design- Detailed design deals with the implementation part
of what is seen as a system and its sub-systems in the previous two
designs. It is more detailed towards modules and their
implementations. It defines logical structure of each module and their
interfaces to communicate with other modules.
 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
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 9
s
 Software Design

Conceptual design answers :

✓ Where will the data come from ?
✓ What will happen to data in the system?
✓ How will the system look to users?
✓ What choices will be offered to users?
✓ What is the timings of events?
✓ How will the reports & screens look like?

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 10
 Software Design
Technical design describes :
❖ Hardware configuration
❖ Software needs
❖ Communication interfaces
❖ I/O of the system
❖ Software architecture
❖ Network architecture
❖ Any other thing that translates the requirements in to a
solution to the customer’s problem.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 11
 Software Design

The design needs to be

➢ Correct & complete
➢ Understandable
➢ At the right level
➢ Maintainable

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 12
 Software Design

Informal More
design Informal formal Finished
outline design design
design

Fig. 3 : The transformation of an informal design to a detailed

design.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 13
 Software
Design
MODULARITY
There are many definitions of the term module. Range is from :

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 Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 14
 Software Design

All these definitions are correct. A modular

system consist of well defined manageable
units with well defined interfaces among
the units.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 15
 Software Design
Properties :
i. Well defined subsystem
ii. Well defined purpose
iii. Can be separately compiled and stored in a
library.
iv. Module can use other modules
v. Module should be easier to use than to
build
vi. Simpler from outside than from the inside.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 16
 Software Design

Modularity is the single attribute of software that

allows a program to be intellectually manageable.
It enhances design clarity, which in turn
implementation,
eases debugging, testing,
documenting, and maintenance of software
product.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 17
 Software Design

Fig. 4 : Modularity and software cost

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 18
 Software Design
Module Coupling
Coupling is the measure of the degree
interdependence between of
modules.

(Uncoupled : no dependencies)
(a)
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 19
 Software Design

Loosely coupled: Highly coupled:

some dependencies many dependencies
(B) (C)
Fig. 5 : Module coupling

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 20
 Coupling
Coupling is a measure that defines
the level of inter-dependability among
modules of a program. It tells at what
level the modules interfere and
interact with each other. The lower
the coupling, the better the program.
There are five levels of coupling,
namely -
Content coupling - When a module can directly access or modify or
refer to the content of another module, it is called content level
coupling.
Common coupling- When multiple modules have read and write
access to some global data, it is called common or global coupling.
Control coupling- Two modules are called control-coupled if one of
them decides the function of the other module or changes its flow of
execution.
Stamp coupling- When multiple modules share common data
structure and work on different part of it, it is called stamp coupling.
Data coupling- Data coupling is when two modules interact with
each other by means of passing data (as parameter). If a module
passes data structure as parameter, then the receiving module
should use all its components.
 Cohesion
Cohesion is a measure that defines
the degree of intra-dependability
within elements of a module. The
greater the cohesion, the better is the
program design.
There are seven types of cohesion,
namely –
Co-incidental cohesion - It is unplanned and random cohesion, which
might be the result of breaking the program into smaller modules for the
sake of modularization. Because it is unplanned, it may serve confusion
to the programmers and is generally not-accepted.

Logical cohesion - When logically categorized elements are put

together into a module, it is called logical cohesion.

Temporal Cohesion - When elements of module are organized such

that they are processed at a similar point in time, it is called temporal
cohesion.

Procedural cohesion - When elements of module are grouped together,

which are executed sequentially in order to perform a task, it is called
procedural cohesion.
 Types………
Communicational cohesion - When elements of module are
grouped together, which are executed sequentially and work on
same data (information), it is called communicational cohesion.

Sequential cohesion - When elements of module are grouped

because the output of one element serves as input to another and so
on, it is called sequential cohesion.

Functional cohesion - It is considered to be the highest degree of

cohesion, and it is highly expected. Elements of module in functional
cohesion are grouped because they all contribute to a single well-
defined function. It can also be reused.
 Software
Design
This can be achieved as:
❑ Controlling the number of parameters passed
amongst modules.
❑ Avoid passing undesired data to
calling module.
❑ Maintain parent / child relationship
between calling & called modules.
❑ Pass data, not the control information.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 26
 Software Design
Consider the example of editing a student record in a
‘student information system’.
Edit student Edit student
record record
Student name,
Student Student Student
student ID,
record record
address, ID
EOF EOF
course
Retrieve Retrieve
student record student record
Poor design: Tight Coupling Good design: Loose Coupling

Fig. 6 : Example of coupling

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 27
 Software Design
Data coupling Best
Stamp coupling
Control coupling
External coupling
Common coupling
Content coupling Worst
Fig. 7 : The types of module coupling

Given two procedures A & B, we can identify number of

ways in which they can be coupled.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 28
 Software Design
Data coupling
The dependency between module A and B is said to be data
coupled if their dependency is based on the fact they
communicate by passing of than are
Other
communicating only
through data, modules
independent. data. the
two
Stamp coupling
Stamp coupling occurs between module A and B
when complete data structure is passed from one module to
another.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 29
 Software Design
Control coupling
Module A and B are said to be control coupled if they
communicate by passing of control information. This is usually
accomplished by means of flags that are set by one module
and reacted upon by the dependent module.

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 Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 30
 Software Design

Fig. 8 : Example of common coupling

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 31
 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 Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 32
 Software Design

Fig. 9 : Example of content coupling

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 33
 Software Design
Module Cohesion
Cohesion is a measure of the degree which the
to elements of a module are functionally
related.

Module
strength

Fig. 10 : Cohesion=Strength of relations within modules

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 34
 Software Design

Types of cohesion
➢ Functional cohesion
➢ Sequential cohesion

➢ Procedural cohesion
➢ Temporal cohesion
➢ Logical cohesion

➢ Coincident cohesion

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 35
 Software Design

Functional Cohesion Best (high)

Sequential Cohesion

Communicational Cohesion

Procedural Cohesion

Temporal Cohesion

Logical Cohesion

Coincidental Cohesion Worst (low)

Fig. 11 : Types of module cohesion

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 36
 Software Design

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 Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 37
 Software Design

Procedural Cohesion
➢Procedural Cohesion occurs in modules
although whose instructions different tasks yet
accomplish
because there is a specifichave
order been combined
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 Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 38
 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 Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 39
 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.

Fig. 12 : View of cohesion and coupling

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 40
 Software Design
STRATEGY OF DESIGN
A good system design strategy is to organize the program modules
in such a way that are easy to develop and latter to, change.
Structured design techniques help developers to deal with the size
and complexity of programs. Analysts create instructions for the
developers about how code should be written and how pieces of
code should fit together to form a program. It is important for two
reasons:
➢ First, even pre-existing code, if any, needs to be understood,
organized and pieced together.
➢ Second, it is still common for the project team to have to write
some code and produce original programs that support the
application logic of the system.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 41
 Software Design
Bottom-Up Design
These modules are collected together in the form of a “library”.

Fig. 13 : Bottom-up tree structure

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 42
 Software Design

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 Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 43
 Software Design

Hybrid Design
For top-down approach to be effective, some bottom-up approach is
essential for the following reasons:

➢ To permit common sub modules.

➢ Near the bottom of the hierarchy, where the intuition is simpler,

and the need for bottom-up testing is greater, because there are
more number of modules at low levels than high levels.
➢ In the use of pre-written library modules, in particular, reuse of
modules.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 44
 Software Design

FUNCTION ORIENTED DESIGN

Function Oriented design is an approach to software design where

the design is decomposed into a set of interacting units where each
unit has a clearly defined function. Thus, system is designed from
a functional viewpoint.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 45
 Software Design

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 46
 Software Design

We continue the refinement of each module until we reach the statement

level of our programming language. At that point, we can describe the
structure of our program as a tree of refinement as in design top-down
structure as shown in fig. 14.

Fig. 14 : Top-down structure

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 47
 Software Design
If a program is created top-down, the modules become very specialized.
As one can easily see in top down design structure, each module is used
by at most one other module, its parent. For a module, however, we
must require that several other modules as in design reusable structure
as shown in fig. 15.

Fig. 15 : Design reusable structure

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 48
 Software Design

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 flow diagrams

➢ Data Dictionaries
➢ Structure Charts
➢ Pseudocode

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 49
 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.

Fig. 16 : Hierarchical format of a structure chart

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 50
 Software Design

Fig. 17 : Structure chart notations

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 51
 Software Design
A transaction centered structure describes a system that processes a
number of different types of transactions. It is illustrated in Fig.19.

Fig. 19 : Transaction-centered structure

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 52
 Software Design
In the above figure the MAIN module controls the system operation
its functions is to:

➢ invoke the INPUT module to read a transaction;

➢ determine the kind of transaction and select one of a number

of transaction modules to process that transaction, and
➢ output the results of the processing by calling
OUTPUT module.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 53
 Software 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 Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 54
 Software Design
Functional Procedure Layers
➢ Function are built in layers, Additional notation is used to
specify details.
➢ Level 0
▪ Function or procedure name

▪ Relationship to other system components (e.g.,

partof which system, called by which routines, etc.)
▪ Brief description of the function purpose.

▪ Author, date

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 55
 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 Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 56
 Software Design
➢ Level 2
▪ Local data structures (variable etc.)

▪ Timing constraints

▪ Exception handling (conditions, responses, events)

▪ Any other limitations

➢ Level 3
▪ Body (structured chart, English pseudo code,
decision tables, flow charts, etc.)

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 57
 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

i. IEEE std 830-1998, IEEE recommended

practice for software requirements specifications.

ii. IEEE std 610.12-1990, IEEE glossary of

software engineering terminology.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 58
 Software Design
➢ Definitions
i. Design entity. An element (Component) of a design that is
structurally and functionally distinct from other elements and
that is separately named and referenced.

ii. Design View. A subset of design entity attribute information

that is specifically suited to the needs of a software project
activity.
iii. Entity attributes. A named property or characteristics of a
design entity. It provides a statement of fact about the entity.

iv. Software design description (SDD). A representation of a

software system created to facilitate analysis, planning,
implementation and decision making.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 59
 Software Design
➢ Purpose of an SDD
The SDD shows how the software system will be structured to
satisfy the requirements identified in the SRS. It is basically the
translation of requirements into a description of the software
structure, software components, interfaces, and data necessary for
the implementation phase. Hence, SDD becomes the blue print for
the implementation activity.

➢ Design Description Information Content

▪ Introduction

▪ Design entities

▪ Design entity attributes

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 60
 Software Design
The attributes and associated information items are defined in the
following subsections:

a) Identification f) Dependencies

b) Type g) Interface

c) Purpose h) Resources

d) Function i) Processing

e) Subordinates j) Data
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 61
 Software Design

➢ Design Description Organization

Each design description writer may have a different view of what

are considered the essential aspects of a software design. The
organization of SDD is given in table 1. This is one of the possible
ways to organize and format the SDD.

A recommended organization of the SDD into separate design

views to facilitate information access and assimilation is given in
table 2.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 62
 Software Design

Cont…
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 63
 Software Design

Table 1:
Organization of
SDD

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 64
 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

Dependency Description of relationships Identification, type, Structure chart, data

description among entities of system purpose, dependencies, flow diagrams,
resources resources transaction diagrams

Interface List of everything a Identification, Interface files,

description designer, developer, tester function, interfaces parameter tables
needs to know to use design
entities that make up the
system
Detail Description of the internal Identification, Flow charts, PDL etc.
description design details of an entity processing, data

Table 2: Design views

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 65
 Software Design
Object Oriented Design
Object oriented design is the result of focusing attention not on the
function performed by the program, but instead on the data that are
to do manipulated by the program. Thus, it is orthogonal to function
oriented design.
Object Oriented Design begins with an examination of the real
world “things” that are part of the problem to be solved. These
things (which we will call objects) are characterized individually in
terms of their attributes and behavior.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 66
 Software Design
➢ Basic Concepts
Object Oriented Design is not dependent on any specific
implementation language. Problems are modeled
Objects have: using objects.

▪ Behavior (they do things)

▪ State (which changes when they do things)

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 67
 Software Design
The various terms related to object design are:

i. Objects

The word “Object” is used very frequently and conveys different

meaning in different circumstances. Here, meaning is an entity able to
save a state (information) and which offers a number of operations
(behavior) to either examine or affect this state. An object is
characterized by number of operations and a state which remembers
the effect of these operations.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 68
 Software Design
ii. Messages
Objects communicate by message passing. Messages consist of the
identity of the target object, the name of the requested operation and
any other operation needed to perform the function. Message are often
implemented as procedure or function calls.

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 Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 69
 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.

Classes are useful because they act as a blueprint for objects. If we

want a new square we may use the square class and simply fill in the
particular details (i.e. colour and position) fig. 21 shows how can we
represent the square class.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 70
 Software Design

Fig.20: Indica, Santro, Maruti, Indigo are all instances of the class “car”

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 71
 Software Design

Fig. 21: The square class

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 72
 Software Design
v. Attributes
An attributes is a data value held by the objects in a class. The square
class has two attributes: a colour and array of points. Each attributes
has a value for each object instance. The attributes are shown as
second part of the class as shown in fig. 21.

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 Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 73
 Software Design
vii. Inheritance
Imagine that, as well as squares, we have triangle class. Fig. 22 shows
the class for a triangle.

Fig. 22: The triangle class

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 74
 Software Design
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 Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 75
 Software Design

Fig. 23: Abstracting common features in a new class

This sort of abstraction is called inheritance. The low level classes
(known as subclasses or derived classes) inherit state and behavior
from this high level class (known as a super class or base class).
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 76
 Software Design
viii. Polymorphism
When we abstract just the interface of an operation and leave the
implementation to subclasses it is called a polymorphic operation and
process is called polymorphism.

ix. Encapsulation (Information Hiding)

Encapsulation is also commonly referred to as “Information Hiding”. It
consists of the separation of the external aspects of an object from the
internal implementation details of the object.
x. Hierarchy
Hierarchy involves organizing something according to some particular
order or rank. It is another mechanism for reducing the complexity of
software by being able to treat and express sub-types in a generic way.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 77
 Software Design

Fig. 24: Hierarchy

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 78
 Software Design

➢ Steps to Analyze and Design Object Oriented System

There are various steps in the analysis and design of object

an oriented system and are given in fig. 25

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 79
 Software Design

Fig. 25: Steps for analysis & design of object

oriented system

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 80
 Software Design
i. Create use case model
First step is to identify the actors interacting with the system. We
should then write the use case and draw the use case diagram.

ii. Draw activity diagram (If required)

Activity Diagram illustrate the dynamic nature of a system by modeling

the flow of control form activity to activity. An activity represents an
operation on some class in the system that results in a change in the
state of the system. Fig. 26 shows the activity diagram processing an
order to deliver some goods.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 81
 Software Design

Fig. 26: Activity diagram

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 82
 Software Design
iii. Draw the interaction diagram
An interaction diagram shows an interaction, consisting of a set of
objects and their relationship, including the messages that may be
dispatched among them. Interaction diagrams address the dynamic
view of a system.
Steps to draws interaction diagrams are as under:
a) Firstly, we should identify that the objects with respects to every
use case.
b) We draw the sequence diagrams for every use case.

d) We draw the collaboration diagrams for every use case.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 83
 Software Design

The object types used in this analysis model are entity

objects, interface objects and control objects as given in fig. 27.

Fig. 27: Object types

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 84
 Software Design
iv. Draw the class diagram

The class diagram shows the relationship amongst classes. There are
four types of relationships in class diagrams.

a) Association are semantic connection between classes. When

an association connects two classes, each class can send
messages to the other in a sequence or a collaboration
diagram. Associations can be bi-directional or unidirectional.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 85
 Software Design
b) Dependencies connect two classes. Dependencies are
always unidirectional and show that one class, depends on the
definitions in another class.

c) Aggregations are stronger form of association. An

aggregation is a relationship between a whole and its parts.

d) Generalizations are used to show an inheritance relationship

between two classes.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 86
 Software Design
v. Design of state chart diagrams
A state chart diagram is used to show the state space of a given class,
the event that cause a transition from one state to another, and the
action that result from a state change. A state transition diagram for a
“book” in the library system is given in fig. 28.

Fig. 28: Transition chart for “book” in a library system.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 87
 Software Design
vi. Draw component and development diagram

Component diagrams address the static implementation view of a

system they are related to class diagrams in that a component typically
maps to one or more classes, interfaces or collaboration.

Deployment Diagram Captures relationship between physical

components and the hardware.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 88
 Software Design
A software has to be developed for automating the manual library of a
University. The system should be stand alone in nature. It should be
designed to provide functionality’s as explained below:
Issue of Books:
❖ A student of any course should be able to get books issued.
❖ Books from General Section are issued to all but Book bank
books are issued only for their respective courses.
❖ A limitation is imposed on the number of books a student can
issue.
❖ A maximum of 4 books from Book bank and 3 books from
General section is issued for 15 days [Link] software takes
the current system date as the date of issue and calculates date
of return.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 89
 Software Design
❖ A bar code detector is used to save the student as well as book
information.
❖ The due date for return of the book is stamped on the book.
Return of Books:
❖ Any person can return the issued books.
❖ The student information is displayed using the bar
detector.
code
❖ The system displays the student details on whose name the
books were issued as well as the date of issue and return of the
book.
❖ The system operator verifies the duration for the issue.
❖ The information is saved and the corresponding updating take
place in the database.
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 90
 Software Design
Query Processing:
❖ The system should be able to provide information like:
❖ Availability of a particular book.
❖ Availability of book of any particular author.
❖ Number of copies available of the desired book.

The system should also be able to generate reports regarding the

details of the books available in the library at any given time. The
corresponding printouts for each entry (issue/return) made in the
system should be generated. Security provisions like the ‘login
authenticity should be provided. Each user should have a user id and
a password. Record of the users of the system should be kept in the
log file. Provision should be made for full backup of the system.

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 91
 Software Design

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 92
 Software Design

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 93
 Software Design

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 94
 Software Design

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 95
 Software Design

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 96
 Software Design

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 97
 Software Design

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 98
 Software Design

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 99
 Software
Design

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 10
0
 Software Design

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 10
1
 Multiple Choice Questions
Note: Choose most appropriate answer of the following questions:
5.1 The most desirable form of coupling is
(a) Control Coupling (b) Data Coupling
(c) Common Coupling (d) Content Coupling
2. The worst type of coupling is
(a) Content coupling (b) Common coupling
(c) External coupling (d) Data coupling
3. The most desirable form of cohesion is
(a) Logical cohesion (b) Procedural cohesion
(c) Functional cohesion (d) Temporal cohesion
4. The worst type of cohesion is
(a) Temporal cohesion (b) Coincidental cohesion
(c) Logical cohesion (d) Sequential cohesion
5. Which one is not a strategy for design?
(a) Bottom up design (b) Top down design
(c) Embedded design (d) Hybrid design
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 10
2
 Multiple Choice Questions
6. Temporal cohesion means
(a) Cohesion between temporary variables
(b) Cohesion between local variable
(c) Cohesion with respect to time
(d) Coincidental cohesion
7. Functional cohesion means
(a) Operations are part of single functional task and are placed in same procedures
(b) Operations are part of single functional task and are placed in multiple procedures
(c) Operations are part of multiple tasks
(d) None of the above
8. When two modules refer to the same global data area, they are related as
(a) External coupled (b) Data coupled
(c) Content coupled (d) Common coupled

5.9 The module in which instructions are related through flow of control is
(a) Temporal cohesion (b) Logical cohesion
(c) Procedural cohesion (d) Functional cohesion

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 10
3
 Multiple Choice
Questions
5.10 The relationship of data elements in a module is called
(a) Coupling (b) Cohesion
(c) Modularity (d) None of the above

5.11 A system that does not interact with external environment is called
(a) Closed system (b) Logical system
(c) Open system (d) Hierarchal system

5.12 The extent to which different modules are dependent upon each other is called
(a) Coupling (b) Cohesion
(c) Modularity (d) Stability

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 10
4
 Exercises
1. What is design? Describe the difference between conceptual design and
technical design.
2. Discuss the objectives of software design. How do we
transform an informal design to a detailed design?
3. Do we design software when we “write” a program? What
makes software design different from coding?
4. What is modularity? List the important properties of a modular system.
5. Define module coupling and explain different types of coupling.
6. Define module cohesion and explain different types of cohesion.
7. Discuss the objectives of modular software design. What are the effects
of module coupling and cohesion?
8. If a module has logical cohesion, what kind of coupling is this module
likely to have with others?
9. What problems are likely to arise if two modules have high coupling?
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 10
5
 Exercises
10. What problems are likely to arise if a module has low cohesion?

11. Describe the various strategies of design. Which design strategy is most
popular and practical?
12. If some existing modules are to be re-used in building a new system,
which design strategy is used and why?
13. What is the difference between a flow chart and a structure chart?
14. Explain why it is important to use different notations to
describe software designs.
15. List a few well-established function oriented software
design techniques.
16. Define the following terms: Objects, Message, Abstraction,
Class, Inheritance and Polymorphism.
17. What is the relationship between abstract data types and classes?

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 10
6
 Exerci
18. sespolymorphism? Explain.
Can we have inheritance without
19. Discuss the reasons for improvement using object-oriented design.
20. Explain the design guidelines that can be used to produce “good quality”
classes or reusable classes.
21. List the points of a simplified design process.
22. Discuss the differences between object oriented and function oriented
design.
23. What documents should be produced on completion of the design phase?
24. Can a system ever be completely “decoupled”? That is, can the degree of
coupling be reduced so much that there is no coupling between modules?

Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007 10
7