Software Design

Introduction
• Design phase transforms SRS document

– To a form easily implementable in some programming language

SRS Document Design Documents

Design Activities

– Software design is a process to transform user requirements into

some suitable form which helps the programmer in software coding
and implementation
 Introduction
• For a design to be easily implementable in a programming language

• Following items must be designed during Design Phase

• Different modules required to implement the design solution

• Control relationship among the identified modules (also known

as call relationship or invocation relationship)

• Interface among different modules

– Identifies the exact data items exchanged among the modules

• Data structure of the individual modules

• Algorithms required to implement individual modules

 Introduction
• The goal of design phase
– To take the SRS document as the input
– To produce the items mentioned at the completion of the design phase

SRS Document Design Documents

Design Activities
 Introduction
• Design activities are usually classified into two stages
– Preliminary (or high-level) design
– Detailed design

• Meaning and scope of the two stages

– Vary considerably from one methodology to another
 High Level Design
• Identification of
– Different modules
– Control relationships among different modules
– Definition of interfaces among different modules

• The outcome of high-level design

– Program structure (or software architecture)
 High Level Design
– Many different notations are used to represent high level design
• A popular way is to use a tree like diagram called structure chart
to represent the control hierarchy in a high level design

d1 d2

d3 d1 d4

• Other notations can also be used

– Such as Jackson diagram or Warnier-Orr diagram
 Detailed Design
• During detailed design
– For each module, design
• Data structure
• Algorithms

• Outcome of detailed design is usually known as

– Module specification document
 Good Software Design
• A good software design is
– Can be achieved through a series of steps and iterations
• Characteristics
– Correctness
• Design should be correct as per requirement
– Understandability
• Design should be easily understandable with features
– Should be modular and neatly arrange the modules in a
hierarchy
– Should use meaningful and consistent names for various
design components
– Maintainability
• Design should be so simple so that it can be easily
maintainable by other designers
– Efficiency
• Resources should be used efficiently by the program
 Ways of using
Abstraction and Decomposition Principles
in Design

• Two ways
– Modular Design

– Layered Design
 Modularity
• A fundamental attribute of any good design

– Decomposition of a problem cleanly into modules

– Modules should be almost independent of each other

• So that they can be understood separately
– Reduces the complexity greatly

– Unintentionally follows the rules of divide and conquer

problem-solving strategy
 Modular Design
• Reduces the design complexity and
• Results in easier and faster implementation by allowing parallel
development of various parts of a system
• Exhibits properties such as

– Functional Independence
– Information hiding
 Functional Independence
• When a software program is modularized, its tasks are divided into
several modules based on some characteristics
• Modules are set of instructions put together in order to perform
some tasks
• The quality of the design of modules and their interaction can be
measured by
– Cohesion
– Coupling
• Technically, modules should display
– High cohesion
– Low coupling
 Cohesion
• Cohesion is a measure that defines the degree of intra-
dependability among the elements of a module
• The greater the cohesion, the better is the design
• Classification of cohesion

functional
sequential
communicational Degree of cohesion
procedural
temporal
logical
coincidental
 Coincidental Cohesion
• Result of breaking the program into smaller modules for the sake
of modularization
– It is unplanned
• It may serve confusion to the programmers
 Logical Cohesion
• When logically categorized elements are put together into a module
• All elements of the module perform similar operations

– e.g. error handling, data input, data output, etc.

• An example of logical cohesion

– A set of print functions put together to generate an output report

into a single module
 Temporal Cohesion
• The module contains tasks that are related by the fact
– All the tasks must be executed in the same time span

• Example:
– The set of functions responsible for

• initialization

• start-up, shut-down of some process, etc.

 Procedural Cohesion
• When elements of module are grouped together which are executed
sequentially in order to perform a task
• e.g. the algorithm for sorting and searching
 Communicational Cohesion
– When elements of module are grouped together which are executed
sequentially and work on same data (information)

– Example:

• The set of functions defined on an array or a stack

 Sequential Cohesion
• When elements of module are grouped because the output of one
element serves as input to another and so on
– Example:

sort

search

display
 Functional Cohesion
– Elements of module in functional cohesion are grouped because they
all contribute to a single well-defined function
• e.g. managing an employee's pay-roll
– It is considered to be the highest degree of cohesion, and it is highly
expected
– It can also be reused
 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

• Ideally, no coupling is considered to be the best
 Coupling
• Content Coupling
– When a module can directly access or modify or refer to the
content of another module
• Common or Global Coupling

– When multiple modules have read and write access to some

global data
• 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
 Coupling
• Stamp coupling
– When multiple modules share common data structure and work
on different part of it
• 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
 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
• Fan-in:
– Indicates how many modules directly invoke a given module
– High fan-in represents code reuse and is in general encouraged
Module Structure

Fan Fan in=0

out=2
Fan Fan in=1
out=1

Fan in=2
 Layered Design
• A design having modules

– With high fan-out numbers

• Not a good design

• Lacks cohesion

• Essentially means

– Low fan-out

– Control abstraction
 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
 Visibility and Layering
• A module A is said to be visible to 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
Bad Design
 Abstraction
• A module is unaware (how to invoke etc.) of the higher level modules

• Lower-level modules

– Do input/output and other low-level functions

• Upper-level modules

– Do more managerial functions

• The principle of abstraction requires

– Lower-level modules do not invoke functions of higher level

modules

– Also known as layered design

 High-level Design
• High-level design maps functions into different modules such that

– Each module has high cohesion

– Coupling among modules is as low as possible

– Modules are organized in a neat hierarchy

• f1
• f2 d2
• f3 d1

•
• d3 d1 d4
•
• fn
 Different Design Approaches
• Procedural (or Function-oriented)
• Object-oriented
• More recent

– Aspect-oriented
– Component-based (Client-Server)
 Different Design Approaches
• These two design approaches are radically different

– However, they are complementary

• Rather than competing techniques

– Each technique is applicable at

• Different stages of the design process

 Function-oriented Approaches
• A system is viewed 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

 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

• Create-library-member consists of the following sub-functions

– Assign-membership-number

– Create-member-record

– Print-bill

• Similarly, Each sub-function, if required

– Split into more detailed sub-functions and so on

 Function-Oriented Design
• The system state is centralized
– Shared among different functions
– Member-records
• Available for reference and updation to several functions
– Create-new-member
– Delete-member
– Update-member-record
 Function-Oriented Design
• Several function-oriented design approaches have been developed:
– Structured design (Constantine and Yourdon, 1979)
– Jackson's structured design (Jackson, 1975)
– Warnier-Orr methodology
– Wirth's step-wise refinement
– Hatley and Pirbhai's Methodology
 Object-Oriented Design
• System is viewed as

– A collection of objects (i.e. entities)

• System state is decentralized among the objects

– Each object manages its own state information

 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

 Object-Oriented
versus
Function-Oriented Design
• Unlike function-oriented design
– In OOD the basic abstraction is not functions such as
“Sort”, “Display”, “Track”, etc.
– But by designing real-world entities, objects, such as
“Employee”, “Picture”, “Machine”, “Department”, etc.
– The functions are usually associated with specific real-world entities
(objects) which directly access only part of the system state
information
 Object-Oriented
versus
Function-Oriented Design
• let us consider an example

• An automated fire-alarm system for a large building

 Fire-Alarm System
• Here, we need to develop a computerized fire alarm system for a
large multi-storied building with

– 80 floors and

– 1000 rooms

• Each rooms of the building

– Fitted with smoke detectors and fire alarms

• The fire alarm system would monitor

– Status of the smoke detectors

 Fire-Alarm System
• Whenever a fire condition is reported by any smoke detector

– the fire alarm system should

• Determine the location from which the fire condition was

reported
• Sound the alarms in the neighboring locations

• Flash an alarm message on the computer screen

– Monitored by Fire fighting personnel round the clock

• After the fire condition has been successfully handled

– The fire alarm system should let fire fighting personnel reset the
alarms
 Function-Oriented Approach
• /* Global data (system state) accessible by various functions */
BOOL detector_status[1000];
int detector_locs[1000];
BOOL alarm-status[1000]; /* alarm activated when status set */
int alarm_locs[1000]; /* room number where alarm is located */
int neighbor-alarms[1000][10];/*each detector has at most*/
/* 10 neighboring alarm locations */
The functions which operate on the system state:
interrogate_detectors();
get_detector_location();
determine_neighbor();
ring_alarm();
reset_alarm();
report_fire_location();
 Object-Oriented Approach
• class detector

Attributes: status, location, neighbors

Operations: create, sense-status, get-location, find-neighbors
• class alarm
• Attributes: location, status
• Operations: create, ring-alarm, get_location, reset-alarm

• In the object oriented program

– Appropriate number of instances of the class detector and alarm
should be created
 Object-Oriented
versus
Function-Oriented Design
• In the function-oriented design
– The system state is centralized
– Several functions on these central data are defined
• In the object oriented design
– The state information is distributed among various sensor and
alarm objects