System

Design
 Design Phase
SRS SDD

Analysis DESIGN Design

Repository Repository
 Design Model

Component STD &

PSPEC
Level Design CSPEC
Interface
DFD Design
Architectural
Design
Data
ERD Dictionary
Data Design
 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.
 Definition
The practice of taking a specification of
externally observable behavior and adding
details needed for actual computer system
implementation, including human
interaction, task management, and data
management details.

Coad and Yourdon (1991)

 Definition
... a process of inventing and selecting
programs that meet the objectives for a
software system. Input includes an
understanding of the following:
1. Requirements.
2. Environmental constraints.
3. Design criteria.
Stevens (1991)
 The output of the design effort is
composed of the following:

1. An architecture design which shows how

pieces are interrelated.
2. Data design is translated from information
flow model.
3. Interface design: SW communicating within
itself, with incorporated systems and with
users.
4. Component design: Structural elements of
SW architecture into procedural description
of software components.
 Broad Characteristics
 A mechanism for translating the physical
problem to its design representation.
 A notation for representing functional
components and their interfaces.
 Heuristics for refinement and partitioning.
 Guidelines for quality assessment.
 Broad Characteristics (contd.)

 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
 Identify:
– modules
– control relationships among modules
– interfaces among modules.

d1 d2

d3 d1 d4
 High-level design

 The outcome of high-level design:

– program structure (or software
architecture).
 Detailed design
 For each module, design:
– data structure
– algorithms
 Outcome of detailed design:
– module specification.
 System architecture
Business Functions System Processes

F P

SF SF SF SP SP

EF EF EP EP EP
 Business Functions
M a te r ia l M a n a g e m e n t

In d e n t P u rc h a s e S to re s P a y m e n ts ....

E n q u ir y

Q u o ta tio n

O rd e r

F o llo w u p

...
 System Processes

MMS

D a ta E n try Q u e ry R e p o rt Task M is c e lla n e o u s

In d e n t In d e n t

O rd e r O rd e r

R e c e ip t

Is s u e

...
 Fundamental Concepts
 Stepwise Refinement
 Abstraction
 Software Architecture
 Program Structure
 Data Structure
 Modularity
 Software Procedure
 Information Hiding
 Stepwise Refinement
Stepwise refinement is a top-down approach
where a program is refined as a hierarchy of
increasing levels of detail. This process may
be begun during requirements analysis and
conclude when the detail of the design is
sufficient for conversion into code.
Processing procedures and data structures are
likely to be refined in parallel
 Abstraction
 Abstraction is a means of describing a
program function, at an appropriate level of
detail.
 Highest level of abstraction - requirements
analysis.
 Lowest level of abstraction - programming.
 Abstraction

Procedural Abstraction
Data Abstraction
Control Abstraction
 Software Architecture
While refinement is about the level of detail,
architecture is about structure. The architecture of
the procedural and data elements of a design
represents a software solution for the real-world
problem defined by the requirements analysis. It is
unlikely that there will be one obvious candidate
architecture.
 Software Architecture
Properties: Structural
Extra-functional
Families of related systems
Models:
1. Structural
2. Framework
3. Dynamic
4. Process
5. Functional
 Program Structure
The program structure represents the hierarchy of
control. Program structure is usually expressed as a
simple hierarchy showing super-ordinate and
subordinate relationships of modules.
It represents two different characteristics of SA:
Visibility & Connectivity
 Control Hierarchy
Width
M

a b c
Depth
d e f g h

i j k
 Data Structure
Data structure dictates the organization,
access methods, degree of associativity, and
processing alternatives for problem-related
information. Classic data structures include
scalar, sequential, linked-list, n-dimensional,
and hierarchical. Data structure, along with
program structure, makes up the software
architecture.
 Modularity
 Modularity derives from the architecture.
 Modularity is a logical partitioning of the
software design that allows complex software to be
manageable for purposes of implementation and
maintenance.
 The logic of partitioning is based on related
functions, implementation considerations, data
links, or other criteria.
 Modularity does imply interface overhead related
to information exchange between modules and
execution of modules.
 Modularity
C(p1) > C(p2)  E(p1) > E(p2)
C(p1+p2) > C(p1)+C(p2)  E(p1+p2) >
E(p1)+E(p2)

• Modular Decomposability
• Modular Composability
• Modular understandability
• Modular continuity
• Modular protection
Example of Cleanly and Non-cleanly
Decomposed Modules
 Modularity
 In technical terms, modules should
display:
– high cohesion
– low coupling.
 We will shortly discuss:
– cohesion and coupling.
 Modularity
Neat arrangement of
modules in a hierarchy
means:
– low fan-out
– abstraction
 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
interdependence or interaction between
the two modules.
 Cohesion and Coupling

 A module having high cohesion

and low coupling:
– functionally independent of other
modules:
• A functionally independent module
has minimal interaction with other
modules.
 Advantages of Functional
Independence
 Better understandability and good
design:
 Complexity of design is reduced,
 Different modules easily understood
in isolation:
– modules are independent
 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.
 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.
 Functional Independence

 Unfortunately, there are no ways:

– to quantitatively measure the degree
of cohesion and coupling:
– classification of different kinds of
cohesion and coupling:
• will give us some idea regarding the degree
of cohesiveness of a module.
 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.
Classification of Cohesiveness

functional
sequential
communicational Degree of 
cohesion
procedural
temporal
logical
coincidental
 Coincidental cohesion

 The module performs a set of tasks:

– which relate to each other very
loosely, if at all.
• the module contains a random collection
of functions.
• functions have been put in the module
out of pure coincidence without any
thought or design.
 Logical cohesion
 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 to generate an
output report arranged 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
 The set of functions of the module:
– all part of a procedure (algorithm)
– certain sequence of steps have to be
carried out in a certain order for
achieving an objective,
• e.g. the algorithm for decoding a
message.
 Communicational cohesion

 All functions of the module:

– reference or update the same data
structure,
 Example:
– the set of functions defined on an
array or a stack.
 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
 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.
 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.
– If it has words like initialize,
• it probably has temporal cohesion.
 Coupling
 Coupling indicates:
– how closely two modules interact
or how interdependent they are.
– The degree of coupling between
two modules depends on their
interface complexity.
 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.
Classes of coupling

data
stamp Degree of 
coupling
control
common
content
 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.
 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.
 Control coupling
 Data from one module is used
to direct
– order of instruction execution in
another.
 Example of control coupling:
– a flag set in one module and
tested in another module.
 Common Coupling

Two modules are common

coupled,
– if they share some global data.
 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.
 Neat Hierarchy
 Control hierarchy represents:
– organization of modules.
– control hierarchy is also called program
structure.
 Most common notation:
– a tree-like diagram called structure
chart.
Neat Arrangement of modules

Essentially means:
– low fan-out
– abstraction
 Characteristics of Module
Structure
 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.
 Characteristics of Module
Structure
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 out=2

Fan out=1
Fan in=1

Fan in=2
Fan out=0
 Software Procedure
Software procedure provides a precise specification
of the software processing, including sequence of
events, exact decision points, repetitive operations,
and data organization. Processing defined for each
module must include references to all subordinate
modules identified by the program structure.
 Information Hiding
Information hiding is an adjunct of
modularity. It permits modules to be
designed and coded without concern for the
internals of other modules. Only the access
protocols of a module need to be shared with
the implementers of other modules.
Information hiding simplifies testing and
modification by localizing these activities to
individual modules.
 Structural Partitioning

Horizontal partitioning:
Separate branches of modular hierarchy of
each major
program function

Vertical partitioning:
Factoring, suggests control or decision making
and work should be distributed top-down
 Structured Design
DFD  Software Architecture
 is the development of a blueprint of a
computer system solution to a business
application.
 seeks to conquer the complexity of large
systems through partitioning and
hierarchical structuring.
 uses graphical tools to render systems
more understandable.
 Structured Design
 offers a set of strategies for developing a
design solution from a well-defined
statement of a problem.
 offers a set of objective and empirically
justified criteria for evaluating the quality
of a given design solution with respect to
the problem on hand.
 Structured Design
 Type of information flow established
 Flow boundaries are indicated
 DFD mapped to program structure
 Control hierarchy defined
 Resultant structure refined
 Architectural description is refined
 Information Flow

Transform Flow
 External data internal form : Incoming
flow
 Data led out : Outgoing flow
 Transform center
Transaction Flow
 Transaction triggers other data flow along
one of many paths
 Hub of information flow from which many
action paths emanate – Transaction Centre
 Structure Chart
The structure chart has three components:
 Modules
 connections between modules
 communication between modules.
 Structure Chart
 Structure chart representation
– easily implementable using programming
languages.
 Main focus of a structure chart:
– define the module structure of a software,
– interaction among different modules,
– procedural aspects (e.g, how a particular
functionality is achieved) are not
represented.
 Basic building blocks of
structure chart
 Rectangular box:
– A rectangular box represents a
module.
– annotated with the name of the
module it represents.
Process­order
 Arrows
 An arrow between two modules implies:
– during execution control is passed from one
module to the other in the direction of the
arrow.

root

Process­order Handle­indent Handle­query

 Data flow Arrows
 Data flow arrows represent:
– data passing from one module to another in the
direction of the arrow.

root

order

Process­order
 Library modules
 Library modules represent
frequently called modules:
– a rectangle with double side edges.
– Simplifies drawing when a module is
called by several modules.

Quick­sort
 Selection
 The diamond symbol represents:
– one module of several modules connected to the
diamond symbol is invoked depending on some
condition.

root

Process­order Handle­indent Handle­query

 Repetition
 A loop around control flow arrows denotes
that the concerned modules are invoked
repeatedly.

root

Process­order Handle­indent Handle­query

 Structure Chart
 There is only one module at the top:
– the root module.
 There is at most one control relationship
between any two modules:
– if module A invokes module B,
– module B cannot invoke module A.
 The main reason behind this restriction:
– consider modules in a structure chart to be
arranged in layers or levels.
 Structure Chart
 The principle of abstraction:
– does not allow lower-level
modules to invoke higher-level
modules:
– But, two higher-level modules
can invoke the same lower-level
module.
 Example
root
Valid­numbers rms
rms
Valid­numbers

Get­good­data Compute­solution Display­solution

Validate­
Get­data data
Bad Design
 Shortcomings of Structure
Chart
 By looking at a structure chart:
– we can not say whether a module
calls another module just once or
many times.
 Also, by looking at a structure
chart:
– we can not tell the order in which the
different modules are invoked.
 Flow Chart
 We are all familiar with the flow chart
representations:
– Flow chart is a convenient technique to represent the flow
of control in a system.
 A=B A=B
 if(c == 100)
 P=20 yes no
 else p= 80
P=20 P=80
 while(p>20)
 print(student mark) dummy
yes no

Print
 Flow Chart versus Structure
Chart
 A structure chart differs from a flow
chart in three principal ways:
– It is difficult to identify modules of a
software from its flow chart
representation.
– Data interchange among the modules is
not represented in a flow chart.
– Sequential ordering of tasks inherent in a
flow chart is suppressed in a structure
chart.
Transformation of a DFD Model into
Structure Chart

Two strategies exist to

guide transformation of a
DFD into a structure chart:
– Transform Analysis
– Transaction Analysis
 Transform Analysis

 The first step in transform

analysis:
– divide the DFD into 3 types of
parts:
• input,
• logical processing,
• output.
 Transform Analysis
 Input portion in the DFD:
– processes which convert input data from
physical to logical form.
– e.g. read characters from the terminal and
store in internal tables or lists.
 Each input portion:
– called an afferent branch.
– Possible to have more than one afferent
branch in a DFD.
 Transform Analysis
 Output portion of a DFD:
– transforms output data from logical form
to physical form.
• e.g., from list or array into output
characters.
– Each output portion:
• called an efferent branch.
 The remaining portions of a DFD
– called central transform
 Transform Analysis
 Derive structure chart by
drawing one functional
component for:
– the central transform,
– each afferent branch,
– each efferent branch.
 Transform Analysis
 Identifying the highest level input and
output transforms:
– requires experience and skill.
 Some guidelines:
– trace the inputs until a bubble is found whose
output cannot be deduced from the inputs
alone.
– Processes which validate input are not central
transforms.
– Processes which sort input or filter data from it
are.
 Transform Analysis
 First level of structure chart:
– draw a box for each input and output
units
– a box for the central transform.
 Next, refine the structure chart:
– add subfunctions required by each high-
level module.
– Many levels of modules may required to
be added.
 Factoring
 The process of breaking functional
components into subcomponents.
 Factoring includes adding:
– read and write modules,
– error-handling modules,
– initialization and termination modules,
etc.
 Finally check:
– whether all bubbles have been mapped to
modules.
 Why Factor?

 to reduce module size

 to get the modular advantages of top-
down design
 to minimize duplication of code
 to separate work from management
 to provide more generally useful modules
 to simplify implementation
 Factoring

 factor the modules intelligently

 aim at a high fan-in factor
 aim at a low fan-out factor
 use an informational cluster to avoid
undesirable coupling
 keep the system balanced
Example 1: RMS Calculating
Software

Data­ Compute­ 
items RMS
0

User result

Context Diagram
 Example 1: RMS
Calculating Software
 From a cursory analysis of the
problem description,
– easy to see that the system needs to
perform:
• accept the input numbers from the user,
• validate the numbers,
• calculate the root mean square of the input
numbers,
• display the result.
Example 1: RMS Calculating
Software
numbers
Read­ Validate­
numbers numbers
0.1 0.2
Valid 
Data­ ­numbers
items error

Compute­
Display rms
0.4 0.3

result RMS
 Example 1: RMS
Calculating Software

 By observing the level 1 DFD:

– identify read-number and
validate-number bubbles as the
afferent branch
– display as the efferent branch.
 Example 1: RMS
Calculating Software
root
Valid­numbers rms
rms
Valid­numbers

Get­good­data Compute­solution Display­solution

Validate­
Get­data data
 Example 2: Tic-Tac-Toe
Computer Game
 As soon as either of the human player or the
computer wins,
– a message congratulating the winner should be
displayed.
 If neither player manages to get three
consecutive marks along a straight line,
– and all the squares on the board are filled up,
– then the game is drawn.
 The computer always tries to win a game.
Context Diagram for
Example 2

Tic­tac­toe 
display software
0

move
Human Player
 Level 1 DFD

game
Display­
move board result

Validate­ Check­
move board winner

Play­
move
 Structure Chart
root

Get­good­move Compute­game Display

Get­move Validate­ play­move Check­

move winner
 Transaction Analysis
 Useful for designing transaction
processing programs.
– Transform-centered systems:
• characterized by similar processing steps for
every data item processed by input, process,
and output bubbles.
– Transaction-driven systems,
• one of several possible paths through the DFD
is traversed depending upon the input data
value.
 Transaction Analysis
 Transaction:
– any input data value that triggers an
action:
– For example, selected menu options might
trigger different functions.
– Represented by a tag identifying its type.
 Transaction analysis uses this tag to
divide the system into:
– several transaction modules
– one transaction-center module.
 Transaction analysis

Transaction­ 
center
trans 3
trans 1
trans 2

type 1 type 2 type 3

 Level 1 DFD for TAS
Customer­history Item­file
query

Accept­ inventory statistics

Customer­file order
Handle­
query
order Process­
Accepted­orders
order
Vendor­list

Handle­
indent­ Sales­statistics
Indent­request request
Indents
pending­order
 Structure Chart
root
order query
indent

Handle­order Handle­indent Handle­query

Get­order Accept­ Process­

order order
 Design Heuristics
 Evaluate first iteration to reduce coupling &
improve cohesion.
 Minimize structures with high fan-out, strive
for fan-in as depth increases
 Keep the scope of effect of a module within
the scope of control for the module
 Evaluate module I/fs
 Define predictable modules but avoid
restrictive modules
 Strive for “controlled” entry modules
 How good is a design? -
Guidelines
 initialize as late as possible,
terminate as soon as possible
 avoid making the modules too restrictive
or too general
 avoid redundancy
 avoid state memory wherever possible
 make the module that locates an error to
report it
 Editing
 edit known before unknown (wait till user
has decided to give you the data)
 edit syntactic before semantic
 edit single before cross (field level checks
first)
 edit internal before external (edit intra-
record checks first before going for inter-
record checks)
 prefer table-driven validations