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
