Software Design

Prof. S. K. Swain
SCE, KIIT, Bhubanewar

1
Organization of This
Lecture
●
Introduction to software design
●
Information Modelling
●
Goodness of a design
●
Cohesion and Coupling
●
Function-oriented design vs.
Object-oriented design
●
Summary

2
 Introduction
●
Design phase transforms SRS
document:
– To a form easily implementable in
some programming language.

SRS Design
Document Design Documents
Activities

– Information modeling is crucial in design

phase for designing robust, scalable, and
maintainable software systems. 3
 Information modeling
●
Information modeling involves creating
abstract representations of the data structures
and relationships within a system.

●
help in understanding, designing, and
communicating the system's data
requirements and how they are
interconnected.

●
It helps ensure that data requirements are well
understood and accurately implemented,
reducing the risk of errors and inconsistencies
in the system. 4
 Key Aspects of Information
Modeling
●
Abstraction: Simplifying complex real-world
data into manageable and understandable
representations.

●
Representation: Using visual and textual
representations to depict data structures,
relationships, and constraints.

●
Communication: Facilitating communication
between stakeholders, including developers,
designers, and business analysts, using
standardized models. 5
 Techniques of
Information Modeling
●
ERD- Entity Relationships
Diagram

●
DFD- Data Flow Diagram

●
UML- Unified Modeling
Language

6
 Steps in Information
Modeling
●
Requirement Analysis:
– Identify key entities, relationships, and data
attributes.
●
Conceptual Modeling:
– Create high-level models that represent the
overall data structure and relationships
without focusing on implementation details.
●
Logical Modeling:
– Refine the conceptual models into more
detailed representations that define the data
structures and constraints in a technology-
agnostic manner.

7
 Steps in Information
Modeling
●
Physical Modeling:
– Translate logical models into physical models that
consider specific database management systems
(DBMS) and other technologies.
– Define tables, columns, indexes, and other database-
specific details.
●
Validation and Refinement:
– Validate the models with stakeholders to ensure
accuracy and completeness.
– Refine the models based on feedback and changing
requirements.
●
Documentation and Communication:
– Document the models clearly and comprehensively.
– Use the models to communicate data requirements and
design decisions to all stakeholders. 8
 Tools for Information
Modeling
●
ER Modeling Tools:
– ER/Studio, ERwin Data Modeler,
Oracle SQL Developer Data Modeler
●
UML Modeling Tools:
– Visual Paradigm, Enterprise Architect,
Lucidchart
●
General Diagramming Tools:
– Microsoft Visio, Draw.io, Gliffy

9
 Design activities
●
are usually classified into two
stages:
– High-level design.

●
The outcome of high-level design:
– software architecture
– Usually a tree-like diagram
called structure chart is used.
– Detailed design.
– Data structure
– Algorithms 10
 High-Level Design
●
Identify:
– Modules
– Control relationships among modules
– Interfaces among modules.

d1 d2

d3 d1 d4

11
 Module
●
A module consists of:
– Several functions
– Associated data structures.

D1 ..
D2 ..
D3 ..
Data
F1 .. Functions
F2 ..
F3 ..
F4 ..
F5 ..

12
Items Designed During
Design Phase
●
Module structure,
●
Control relationship among the
modules
– call relationship or invocation relationship
●
Interface among different modules,
– Data items exchanged among different
modules,
●
Data structures of individual modules,
●
Algorithms for individual modules.

13
 Does a Design Technique
Lead to a Unique Solution?
●
No:
– Several subjective decisions
need to be made to trade off
among different parameters.
– Even the same designer can
come up with several
alternate design solutions.

14
 Analysis versus
Design
●
An analysis technique helps elaborate
the customer requirements through
careful thinking:
– And at the same time consciously avoids
making any decisions regarding
implementation.
●
The design model is obtained from the
analysis model through transformations
over a series of steps:
– Decisions regarding implementation are
consciously made.
15
 A Fundamental
●
There is no Question
unique way to design a
system.
●
Different designers can arrive at very
different design solutions.

●
How to distinguish between the
superior of two alternate design
solutions?
– We need to distinguish between good
and bad designs.

16
 Which of Two is a
Better Design?
●
Should implement all
functionalities of the system
correctly.
●
Should be easily understandable.
●
Should be efficient.
●
Should be easily amenable to
change,
– i.e. easily maintainable.

17
 Which of Two is a
Better Design?
●
Understandability of a design is a
major issue:
– Determines goodness of design:
–A design that is easy to understand:
●
Also easy to maintain and change.
– Tremendous effort needed to maintain it
– We already know that about 60% effort is spent in
maintenance.

18
Understandability
●
Use consistent and
meaningful names:
– For
various design
components.
●
Should make use of
abstraction and
decomposition principles in
ample measure.
19
software design
●
Good software designs:
– Seldom arrived through a
single step procedure:
– Butthrough a series of steps
and iterations.

20
 How are Abstraction and
Decomposition Principles Used in
Design?
●
Two principal ways:
– Modular Design
– Layered Design

21
 Modularity
●
Modularity is a fundamental
attributes of any good design.
– Decomposition of a problem
cleanly into modules:
– Modules are almost independent
of each other
– Reduces the complexity greatly
– Divide and conquer principle.

22
 Modularity
●
In technical terms,
modules should display:
– High cohesion
– Low coupling.

23
Cohesion and Coupling
●
Cohesion is a measure of:
– functional strength of a module.
– A cohesive module performs a
single task or function.
●
Coupling between two
modules:
–A measure of the degree of the
interdependence or interaction
between the two modules.

24
 Cohesion and
Coupling
●
A good software design
should have high cohesion
and low coupling:
– functionally
independent of
other modules:
●
A functionally independent
module has minimal interaction
with other modules.

25
Advantages of Functional
Independence
●
Better understandability
and good design:
●
Complexity of design is
reduced,
●
Different modules easily
understood in isolation:
– Modules are independent

26
Advantages of Functional
Independence
●
Functional independence
reduces error propagation.
– Degree of interaction between
modules is low.
– An error existing in one module
does not directly affect other
modules.
●
Reuse of modules is possible.

27
 Advantages of Functional
Independence
●
A functionally independent
module:
– Can be easily taken out and reused
in a different program.
●
Each module does some well-defined
and precise function
●
The interfaces of a module with other
modules is simple and minimal.

28
 Functional
Independence
●
Unfortunately, there are no ways:
– To quantitatively measure the

degree of cohesion and coupling.

– Classification
of different kinds of
cohesion and coupling:
●
Can give us some idea regarding
the degree of cohesiveness of a
module.

29
 cohesion
●
cohesion measures the
strength of relationships
between pieces of functionality
within a given module.

●
For example, in highly cohesive
systems, functionality is
strongly related.
30
 Classification of
Cohesiveness
●
Classification is often subjective:
– Yet
gives us some idea about
cohesiveness of a module.
●
By examining the type of
cohesion exhibited by a module:
– We can roughly tell whether it
displays high cohesion or low
cohesion.

31
Classification of
Cohesiveness
functional
sequential
communication Degree of
al cohesion
procedural
temporal
logical
coincidental

32
 Coincidental
●
Cohesion
The module performs a set of
tasks:
– Which relate to each other very
loosely, if at all (having no
meaningful relationships.
●
The module contains a random
collection of functions.
●
Functions have been put in the
module out of pure coincidence
without any thought or design.
33
 Logical Cohesion
●
Exists when logically related
elements of a module are
placed together.
●
A logically cohesive module
integrates various related sub-
modules and its sub-parts.
– e.g.data input,error handling,
data output, etc.
●
An example of logical cohesion:
– A set of print functions to generate an
output report arranged into a single 34

module.
 Temporal Cohesion
●
The module contains tasks that are
related by the fact:
– All the tasks must be executed in the
same time span.
– It may be performed in a sequence
but their execution is related to a
certain time.
●
Example:
– The set of functions responsible for
●
initialization,
●
start-up, shut-down of some process, etc.
35
 Procedural Cohesion
●
A module is said to be procedural
cohesion if the set of purpose of
the module are all parts of a
procedure in which particular
sequence of steps has to be
carried out for achieving a goal,
e.g., the algorithm for decoding a
message.

36
 Procedural Cohesion
●
The set of functions of the
module:
– All
part of a procedure
(algorithm)
– Certainsequence of steps have
to be carried out in a certain
order for achieving an objective,
●
e.g. entering, reading, verifying ATM
password are bound in an order
manner for the procedural cohesive37
module “enter password”
 Communicational
Cohesion
●
All functions of the module:
– Reference or update the same
data structure,
●
Example:
– Theset of functions defined on
an array or a stack.

38
 Sequential Cohesion
●
Elements of a module form
different parts of a sequence,
– Output from one element of the
sequence is input to the next.
– Example:
sort

search

display
A module is said to possess sequential cohesion if the element
of a module form the components of the sequence, where the
39
output from one component of the sequence is input to the
 Functional Cohesion
●
Different elements of a module
cooperate:
– To achieve a single function,
– e.g. managing an employee's pay-
roll.
●
When a module displays
functional cohesion,
– We can describe the function
using a single sentence. 40
 Determining
Cohesiveness
●
Write down a sentence to
describe the function of the
module
– If the sentence is compound,
●
It has a sequential or
communicational cohesion.
– If
it has words like “first”,
“next”, “after”, “then”, etc.
●
It has sequential or temporal
cohesion. 41
– If it has words like initialize,
 Coupling
●
Coupling indicates:
– How closely two modules
interact or how
interdependent they are.
– Thedegree of coupling
between two modules
depends on their interface
complexity.
42
 Coupling
●
There are no ways to precisely
determine coupling between two
modules:
– Classification of different types of
coupling will help us to
approximately estimate the degree
of coupling between two modules.
●
Five types of coupling can exist
between any two modules.
43
Classes of coupling
data
stamp
control Degree of
coupling
common
content

44
 Data coupling
●
Two modules are data coupled,
– If they communicate via a
parameter:
●
an elementary data item,
●
e.g an integer, a float, a
character, etc.
– The data item should be problem
related:
●
Not used for control purpose.
45
 Stamp Coupling
●
Two modules are stamp
coupled,
– If
they communicate via a
composite data item
●
such as a record in
PASCAL
●
or a structure in C.
46
 Control Coupling
●
Data from one module is
used to direct:
– Orderof instruction execution
in another.
●
Example of control coupling:
–A flag set in one module and
tested in another module.

47
Common Coupling
●
Two modules are
common coupled,
– If
they share some global
data.

48
 Content Coupling
●
Content coupling exists between
two modules:
– If they share code,
– e.g, branching from one module
into another module.
●
The degree of coupling
increases
– from data coupling to content
coupling.
49
 Differentiate between
Coupling and Cohesion
Coupling Cohesion
also called Inter-Module Binding. also called Intra-Module Binding.

shows the relationships between shows the relationship within the

modules. module.

shows the relative independence shows the module's relative

between the modules. functional strength.

While creating, we should aim for While creating you should aim for
low coupling, i.e., dependency high cohesion, i.e., a cohesive
among modules should be less. component/ module focuses on a
single function with little
interaction with other modules of
the system.
In this, modules are linked to the In this, the module focuses on a
other modules. single thing.

50
 Neat Hierarchy
●
Control hierarchy represents:
– Organization of modules.
●
Most common notation:
–A tree-like diagram called
structure chart.

51
 Characteristics of
Module Hierarchy
●
Depth:
– Number of levels of control
●
Width:
– Overall span of control.
●
Fan-out:
–A measure of the number of
modules directly controlled by
given module.

52
 Characteristics of
Module Structure
●
Fan-in:
– Indicates
how many
modules directly invoke a
given module.
– Highfan-in represents
code reuse and is in
general encouraged.
53
Module Structure
Fan Fan
out=2 in=0
Fan Fan
out=1 in=1

Fan
in=2

54
 Layered Design
●
Essentially means:
– Low fan-out
– Control abstraction

55
Layered Design

56
 Layered Design
●
A design having
modules:
– Withhigh fan-out
numbers is not a good
design:
–A module having high fan-
out lacks cohesion.
57
Goodness of Design
●
A module that invokes a
large number of other
modules:
– Likelyto implement several
different functions:
– Notlikely to perform a
single cohesive function.

58
 Control
Relationships
●
A module that controls
another module:
– Said to be superordinate to it.
●
Conversely, a module
controlled by another module:
– Said to be subordinate to it.

59
 Visibility and Layering
●
A module A is said to be
visible by another module B,
– If A directly or indirectly calls
B.
●
The layering principle requires
– Modules at a layer can call only
the modules immediately
below it.
60
Bad Design

61
 Abstraction
●
A module is unaware (how to
invoke etc.) of the higher level
modules.
●
Lower-level modules:
– Doinput/output and other low-
level functions.
●
Upper-level modules:
– Do more managerial functions.
62
 Abstraction
●
The principle of
abstraction requires:
– Lower-levelmodules do not
invoke functions of higher
level modules.
– Alsoknown as layered
design.

63
 High-level Design
●
High-level design maps
functions into modules {fi}
{mj} such that:
– Eachmodule has high
cohesion
– Couplingamong modules is
as low as possible
– Modules are organized in a
neat hierarchy 64
High-level Design
• f1
• f2 d2
• f3 d1

•
• d3 d1 d4
•
• fn

65
A Classification of Design
Methodologies
●
Procedural (aka
Function-oriented)
●
Object-oriented
●
More recent:
– Aspect-oriented
– Component-based (Client-
Server)
66
 Design
Approaches
●
Two fundamentally different
software design
approaches:
– Function-oriented design
– Object-oriented design

67
Design Approaches
●
These two design approaches
are radically different.
– However, are complementary
●
Rather than competing
techniques.
– Each technique is applicable at
●
Different stages of the design
process.

68
 Function-Oriented
Design
●
A system is looked upon as
something
– That performs a set of functions.
●
Starting at this high-level view of
the system:
– Each function is successively refined
into more detailed functions.
– Functions are mapped to a module
structure.
69
 Example
●
The function create-new-
library- member:
– Creates
the record for a new
member,
– Assigns a unique membership
number
– Prints
a bill towards the
membership
70
 Example
●
Create-library-member
function consists of the
following sub-functions:
– Assign-membership-number

– Create-member-record

– Print-bill

71
 Function-Oriented
Design
●
Each subfunction:
– Split
into more detailed
subfunctions and so on.

72
 Function-Oriented
Design
●
The system state is
centralized:
– Accessible
to different functions,
– Member-records:
●
Available for reference and updation
to several functions:
– Create-new-member
– Delete-member
– Update-member-record

73
 Object-Oriented
Design
●
System is viewed as a
collection of objects (i.e.
entities).
●
System state is decentralized
among the objects:
– Eachobject manages its own
state information.

74
 Object-Oriented Design
Example
●
Library Automation Software:
– Eachlibrary member is a
separate object
●
With its own data and functions.
– Functions defined for one
object:
●
Cannot directly refer to or
change data of other objects.
75
 Object-Oriented Design
●
Objects have their own internal
data:
– Defines their state.
●
Similar objects constitute a class.
– Each object is a member of some class.
●
Classes may inherit features
– From a super class.
●
Conceptually, objects communicate
by message passing.
76
 Object-Oriented versus
Function-Oriented Design
●
Unlike function-oriented design,
– InOOD the basic abstraction is
not functions such as “sort”,
“display”, “track”, etc.,
– But real-world entities such as

“employee”, “picture”,
“machine”, “radar system”, etc.

77
 Object-Oriented versus
Function-Oriented Design
●
In OOD:
– Softwareis not developed by
designing functions such as:
●
update-employee-record,
●
get-employee-address, etc.
– But by designing objects such as:
●
employees,
●
departments, etc.

78
 Object-Oriented versus
Function-Oriented Design
●
Grady Booch sums up
this fundamental
difference saying:
– “Identifyverbs if you are
after procedural design
and nouns if you are after
object-oriented design.”

79
 Object-Oriented versus
Function-Oriented Design
●
In OOD:
– Stateinformation is not
shared in a centralized
data.
– Butis distributed among
the objects of the system.

80
 Example:
●
In an employee pay-roll
system, the following can be
global data:
– employee names,
– code numbers,
– basic salaries, etc.
●
Whereas, in object oriented
design:
– Data is distributed among
different employee objects of the
81
 Object-Oriented versus
Function-Oriented Design
●
Objects communicate by
message passing.
– One object may discover
the state information of
another object by
interrogating it.

82
 Object-Oriented versus
Function-Oriented Design
●
Of course, somewhere or other
the functions must be
implemented:
– Thefunctions are usually
associated with specific real-
world entities (objects)
– Directly
access only part of the
system state information.

83
 Object-Oriented versus
Function-Oriented Design
●
Function-oriented techniques
group functions together if:
– As a group, they constitute a higher
level function.
●
On the other hand, object-
oriented techniques group
functions together:
– On the basis of the data they
operate on.

84
 Object-Oriented versus
Function-Oriented Design
●
To illustrate the differences
between object-oriented and
function-oriented design
approaches,
– let us consider an example ---
– Anautomated fire-alarm
system for a large building.

85
 Object-Oriented versus
Function-Oriented Design
●
In the function-oriented
program :
– The system state is centralized
– Several functions accessing these
data are defined.
●
In the object oriented program,
– The state information is distributed
among various sensor and alarm
objects.

86
 Object-Oriented versus
Function-Oriented Design
●
Use OOD to design the
classes:
– Then applies top-down
function oriented
techniques
●
To design the internal
methods of classes.

87
 Object-Oriented versus
Function-Oriented Design
●
Though outwardly a system
may appear to have been
developed in an object
oriented fashion,
– Butinside each class there is a
small hierarchy of functions
designed in a top-down manner.

88
 Summary
●
We looked at the essential
philosophy behind these
two approaches
– These
two approaches are not
competing but
complementary approaches.

89