Software Engineering & UML

Module-3
Software
Design
 Module-3 Contents

 Software Design:
 Overview of the Design Process
 Cohesion and Coupling
 Layered Arrangement of Modules
 Approaches to Software Design

 FOD:
 SA/SD Methodology
 DFD
 Structured Design
 Detailed Design
Introduction

 Design phase transforms SRS doc to Design docs:

 Design documents are easily implementable

using any programming language

SRS Design
Document Design Activities Documents
 Items Designed in Design Phase

Items designed during design phases are :

1. Design of all the Modules

HLD 2. Relationship (or dependencies) among

modules

3. Interface between modules

i.e. Data exchanged between modules

DD 4. Data structures of individual modules

5. Algorithms for individual modules

 Design activities
Design activities are usually classified into two
stages:
1. High-level design (HLD)
2. Detailed design (DD)

1. High-level design Identifies: d1 d2

 Modules
d3 d1 d4
 Relationships among modules
 interfaces among modules
 1. High-level design

 The output of high-level design:

 Software architecture document

d1 d2
 Also called
d3 d1 d4
 structure chart
2. Detailed design

Output of detailed design :

Module specification

D1 ..
For each module, design : D2 .. Data
D3 ..
Data structure & F1 .. Functions
F2 ..
Algorithms (or functions) F3 ..
F4 ..
F5 ..
 Characteristics of a good design

1. Correctness
2. Understandability
3. Maintainability
4. Efficiency
5. Modularity
6. Clean decomposition
7. Neat Arrangement
8. High cohesion & Low coupling
9. High Fan-In & Low Fan-Out
 Characteristics of a good design

1. Correctness & 4. Efficiency

Design should accurately translate the

requirements :
For correct & efficient Implementation of the
system

2. Understandability & 3.Maintainability

 The design should be easy to understand

 Use consistent & meaningful names for design
components
 Characteristics of a good design

5. Modularity & 6. Clean

Decomposition
 Decomposition of a problem cleanly into modules using
divide & conquer principle

 Modules must be almost independent of each other

 If modules are independent: they can be solved

separately
This reduces the complexity
Design

M1 M1

M2 M3
M2 M3

M4 M5 M6
M4 M5 M6

Modular Design
Design exhibiting poor
Characteristics of a good design

7. Neat arrangement

Neat arrangement of modules in a hierarchy

means:
Layered solution &
abstraction
 Characteristics of a good design

9. High Fan-In & Low Fan-Out

Characteristics of Structure Chart

 Depth: no. of levels of control

 Width: overall span of control

 Fan-out: no. of modules directly called by a module

=> Fan-out => dependency (Low is good / high is
bad)
 Fan-in: how many modules call/invoke a given module
=> Fan-in => re-usability (High is good / low is
bad)
 Module Structure
Fan
out=2

Fan in=1 Fan

out=1
Fan in=2 Fan
out=0

Fan-out: no. of modules directly called by a module

=> dependency (Low is good / high is bad)
Fan-in: how many modules call a given module
=> re-usability (High is good / low is bad)
 Having high Fan-In & low Fan-out is a good design

Bad Design
8. Cohesion & Coupling

 Cohesion is a measure of:

 functional strength of a module
 How cohesive/closely knit the functions of the module
are

 Coupling between two modules:

 a measure of the degree of interdependence or
interaction between modules

 A module having high cohesion & low coupling is

 functionally independent of other modules
Structure Chart

D1 ..
D2 ..
D3 ..
Data
F1 .. Functions
F2 ..
F3 ..
F4 ..
F5 ..
 Adv.s of Functional Independence

 Complexity of design is reduced

 Modules are easily understood

 Reduces error propagation

 An error in one module does not affect other
modules

 Reuse of modules is better

 if it is functionally independent
 Classification of Cohesiveness

 Classification gives us idea about cohesiveness of a

module
i.e. whether it displays high or low
cohesion
 7 types of cohesion
functional
are there
sequential
Degree of
communicational cohesion
procedural
temporal
logical
coincidental
1. Coincidental cohesion

 The module performs a set of tasks

 But these are not related

 Tasks are random collection of functions

 The functions are put in the module

 without any thought or design
2. Logical cohesion

 All the functions of the module

 Perform similar operations

Ex. Error handling

data input
data output etc.
 3. Temporal cohesion

 The tasks are related by time

 All the tasks are to be executed in the same time

span

 Ex

 Initialization of a process
 Start-up process
 Shut-down process etc.
 4. Procedural cohesion

 All the functions of the module:

 Are part of a procedure (algorithm)

 Contains sequence of steps to be carried out

in certain order for achieving an objective

Ex: Payroll run to generate salary of employees

5. Communicational cohesion

 All functions of the module:

 Reference or update the same data structure

 Ex: The set of functions defined for a stack or

queue
6. Sequential cohesion

 All tasks of the module form different parts of a

sequence

 Output from one task of the sequence is input to

the next
sort

search
display
7. Functional cohesion

 All the functions of the module cooperate to

achieve a
single goal

 Ex: Renew book in LIS, Ticket booking in RRS

 Coupling
 Coupling indicates:

 Interdependent between the modules of a

system
 Classifications of coupling will help us
estimate the degree of coupling between two
modules
 Five typesdata
of coupling are there
stamp
Degree of
control coupling

common
content
 1. Data Coupling & 2. Stamp coupling

1. Two modules are data coupled,

 If they communicate via an elementary data item
 Ex: an integer, a float, a character etc.

2. Two modules are stamp coupled,

 If they communicate via a composite data item
such as a record in PASCAL or a structure in C
 4. Common & 5. Content Coupling

4. Two modules are common coupled,

 If they share some global data

 Ex: Room-Number[100] in a Hotel Management

system

5. Two modules are content coupled,

 if they share code
 Ex: Branching from one module into another
module
The degree of coupling increases from data coupling
 3. Control Coupling

3. Two modules are control coupled,

 If data from one module is used to direct order of

instruction execution in another

 Ex:
A flag set in Module-1 and tested in Module-2
If (Book Availability_Status = True)
Then Renew_Book
Else Display Regret message
 Design Approaches

 Two fundamentally different software design

approaches:

1.Function-oriented design

2.Object-oriented design
 1. Function-Oriented Design

 In FOD, A system is seen as a set or collection of

functions
 Starting at this high-level view of the system:
 Each function is successively refined into more detailed
functions
• f1 are mapped to a module structure
 Functions
• f2 d1 d2
• f3
•
• d3 d1 d4
•
• fn
 EX:

 The function create-new-library- member:

Creates the record for a new member

Assigns a unique membership number

Prints a bill towards the membership

2. 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 information
 Library Information System:
 Each library 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
 Object-Oriented Design

 Objects have their own internal data

 Similar objects constitute a class
 Each object is a member of some class
 Classes may inherit features from a super class
 Objects communicate by message passing

 Unlike FOD,
 in OOD, the basic component is not functions such
as “sort”, “display”, “track”, etc.
 but real-world entities such as “employee”,
“machine”, “Account”, etc.
 OOD VS FOD

1. As per Grady Booch : Identify verbs if you are doing FOD &
Identify nouns if you are doing OOD”

2. In FOD: We design functions, but in OOD, we design Objects

3. In FOD: the system state is centralized, In OOD, it is

decentralized

4. Objects communicate by message passing, Functions

communicate by data passing

5. In FOD, we follow Top-down approach & in OOD, we follow

Bottom-Up approach
Function-Oriented
Software Design
 Topics

 Introduction to function-oriented
design
 High level Design
 SA/SD Methodology
 Data flow diagrams (DFDs)
 Introduction
 Symbols
 Level-0 DFD (Context Diagram)
 Level-1 DFD (Example)
 Level-2 DFD (Example)
 Rules of DFD
 Examples
 Detailed Design
 FOD -
Introduction
 Function-oriented design techniques are very
popular
 Heavily used in many s/w dev. organizations

 During the FOD process:

 Structured Analysis is performed – produces DFDs

 Structured Design is performed

 High Level Design – produces “Structure Chart”
 Detail Design – produces “Module Specification”
 Structured Analysis

 Each functionality specified in the SRS is Analyzed

 Then Decomposed into more detailed functions

 High-level data is decomposed into more detailed data

 SA transforms a textual problem description in the

SRS to a graphic model called DFD

 DFDs graphically represent the results of structured

analysis
 Structured Design - HLD
 All the functions represented in the DFD are mapped
to the module structure
 The module structure also called as the : Software
architecture (Structure chart) – the result
of HLD
• f1
• f2 d1 d2
• f3
•
• d3 d1 d4
•
• fn
 Structured Design -Detail
Design

S/W architecture produced in HLD

is Refined during detailed design

Output of detailed design :

Module specification D1 ..
D2 ..
D3 ..
Data

For each module, design :

F1 .. Functions
F2 ..
F3 ..
Data structure & Algorithms F4 ..
F5 ..
 Structured Design -Detail
Design

 Detailed design can be directly implemented:

Using any programming language

Data Flow Diagrams

(DFDs)
 Data flow diagrams

 DFD is a popular modelling technique:

 Used to represent the results of structured

analysis

 DFD technique is very popular because:

 It is simple to understand and use

 Data flow diagram

 DFD is a graphical model:

 Shows different processes of the system

&
 Data interchange among the processes
 DFD Concepts

 Function or Process:

 Each function accepts some input data

&
 Produces some output data

 A DFD model uses:

 Limited types of symbols

&
 Simple set of rules
Data Flow Diagrams
(DFDs)
 Primitive Symbols Used for Constructing
DFDs:

External Entity

Process
Data Flow

Output

Data Store
 (1) External Entity

 Is a real physical entity

Librarian
 These entities input data to the system
 Receive output data produced by the system
Student

 These are also called terminator, source, or sink

Customer
 Represented by a rectangle
 (2) Process Symbol

 A process or function such as “search-book” /

“Renew-book” is represented using a circle

 This symbol is called a search-

process or bubble or transform book
 Generally processes transform data values
 Process represent some activity
Process names should be verbs Renew-
book
 (3) Data Flow Symbol

 A Directed arc Author-

name

Matching Book-Details

 Represents data flow in the direction of the arrow

 Data flow symbols are labelled with names of data

they carry
 (4) Data Store Symbol

 Represents a logical file: book-details

 A logical file can be: Data Read Data

 a data structure Write
 a physical file
 Table(s)

 Each data store is connected to a process by

means of a data flow symbol
 Data Store Symbol

 Direction of data flow arrow:

 shows whether data is being read find-book

from or written to
Books
 An arrow into or out of a DS
 implicitly represents the entire data of the data
store
 arrows connecting to a data store need not be
labelled
(5) Output Symbol

 Output produced by the system

Ex: Reports, Physical docs (Ticket, Admit card..),

Files..
Synchronous operation

 If two bubbles are directly connected by a

data flow arrow:
 They are synchronous

number

Read- Validate-
numbers numbers Valid
Data- 0.1 0.2 number
items
Asynchronous operation

 If two bubbles are connected via a data

store:
 they are not synchronous

Read- Validate-
numbers numbers
0.1 0.2
numbers Valid
Data- number
items
 How is Structured Analysis Performed /
Developing DFD model of a system

 Initially represent the System at the most abstract

level called the Context diagram

 The entire system is represented as a single

Bubble(Or Process)

 This bubble is labelled according to the main

function of the system (or Title of the system :
Indian Railway Reservation System)
 Context Diagram

 A context diagram shows:

1. Data input to the system
2. Output data generated by the system
3. External entities
 Context diagram captures:
 Various entities external to the system and
interacting with it (Student, Admin, Bank Accountant etc.)
 Data flow occurring between the system and the
external entities (User credentials, Authentication status,
Start & End Stations, Train details)
 The context diagram is also called as the level 0
DFD
Example 1: Tic-Tac-Toe Computer Game
DFD- Level 0 (Context diagram) & level
1 DFD
 Data Dictionary

 A DFD is always accompanied by a data dictionary

 A data dictionary defines all simple & composite

data items (with component items) appearing in a
DFD, along with
 Their Name & definition
 Their Purpose

 DD provides all project members with a standard

terminology for all data to avoid confusion

 EX: See next page

 Data Definition in DD

 Composite data are defined in terms of primitive

data items using following operators:
 +: Denotes composition of data items
 Ex: ‘a+b’ represents data a and b

=: Represents equivalence,

Ex: ‘a=b+c’ means that a represents b and c

[,,,]: Represents selection

Any one of the data items listed inside the square
bracket can occur
Ex: [a,b,c] represents either a or b or c occurs
 Data Definition
 ( ): Contents inside the bracket represent optional data
( data may or may not appear)
 Ex: ‘a+(b)’ represents either ‘a’ or ‘a+b’ occurs

 {}: Represents, iterative data definition

 Ex: ‘{name}5’ represents ‘five instances of name
data’
 {name}*: represents , zero or more instances of
name

* *:
 Anything appearing within * * is considered as
comment
Data Dictionary – Tic-Tac-Toe Game DFD

Display=game + result
move = integer /* number between 1-9 */
board = {Integer}9
game = board /* number 1 to 9 */
result=string [“computer won”, “human won”,
“draw”]
Ex1: Transport Service Automation System

User credentials
Authentication Status
Car Inquiry Details
Available Car Details
Selected Car for Transport
Booking Service
Car Booking Auto.
Customer Confirmation System
Amend/Cancel Booking info
Booking Amendment/ 0
Cancel Confirmation

Payment detail info

Payment Status
 Level 1 DFD

 Examine the SRS document:

 Represent each high-level function as a bubble

 Ex: Train Information Enquiry, Ticket Booking, Ticket
Cancellation

 Identify data inputs & outputs to every high-level

function
 Ex:Travel dates, start & end stations, Passenger info(name,
age ..)

 Represent data store for I/P & O/P of data to the

system
 Ex: Train Info database, Train Availability File ..
 Higher level DFDs

 Each high-level function is then decomposed into

sub-functions:
 Identify the sub-functions
 Identify the data input & output to each sub-
function

 These are represented as DFDs

 Decomposition

 Decomposition of a bubble:
 Also called factoring or exploding

 Each bubble is decomposed to between 2 to 7

bubbles

 Too few bubbles: make decomposition

meaningless

 Too many bubbles: more than 7 bubbles make

the DFD hard to understand
Decompose how long?

 Decomposition of a bubble should be carried

on until:

 The function of the bubble can be described using

A simple algorithm
Ex1: Transport Service Automation System

User credentials
Authentication Status
Car Inquiry Details
Available Car Details
Selected Car for Transport
Booking Service
Car Booking Auto.
Customer Confirmation System
Amend/Cancel Booking info
Booking Amendment/ 0
Cancel Confirmation

Payment detail info

Payment Status
DFD-1: Transport Service Auto. System
DFD-2: Transport Service Auto. System
 Decomposition is stopped after reaching “simple set
instruction” level:

 A bubble is not decomposed any further:

If it can be represented by a simple set of
instructions
Rule-1: Balancing a DFD

 Data flowing into or out of a bubble:

 Must match the data flows at the next level of DFD
 This is known as Balancing a DFD
 Ex: In the level 1 of the DFD of RMS
 Data item c flows into the bubble P3 and the data
items
d & e flow out
 In the next level, bubble P3 is decomposed
The decomposition is balanced as data item c flows
into the level 2 diagram and d and e flow out
 Balancing a DFD

c
b c

c1
d1

a d
e
Level 1 d e1
e
Level 2
 Rule-2: Numbering of
Bubbles

 Number the bubbles in a DFD:

 Numbers help in uniquely identifying any bubble

 Bubble at context level, assigned number 0

 Bubbles at level 1: assigned numbers 0.1, 0.2,

0.3...

 When a Bubble numbered x is decomposed,

 its children bubble are numbered x.1, x.2, x.3...
 Ex2 : RMS Calculating Software

A software system called RMS calculating software would

-

Read three integer numbers from the user in the range

of -1000 and +1000 and then determine the root
mean square (rms) of the three input numbers and
display it.

The system accepts three integers from the user and

returns the result to him.
Context Diagram
Level 1
Structure chart
Data dictionary for RMS S/W

 numbers=valid-numbers=a+b+c * Composite i/p

data *
 a:integer * input number *
 b:integer * input number *
 c:integer * input number *
 asq:integer
 bsq:integer
 csq:integer
 squared-sum: integer
 Result=[RMS,error]
 RMS: integer * root mean square value*
 error:string * error message*
 Ex3 – Supermarket prize scheme

A supermarket needs to develop the following software to encourage regular

customers.

For this, the customer needs to supply his/her residence address, telephone
number, and the driving license number.

Each customer who registers for this scheme is assigned a unique customer number
(CN) by the computer.

A customer can present his CN to the check out staff when he makes any purchase.

In this case, the value of his purchase is credited against his CN.

At the end of each year, the supermarket intends to award surprise gifts to 10
customers who make the highest total purchase over the year.

Also, it intends to award a 22 caret gold coin to every customer whose purchase
exceeded Rs.10,000. The entries against the CN are the reset on the day of every
year after the prize winners’ lists are generated
Context diagram
Level 1
Level 2
Structure chart
Data Dictionary - Supermarket prize
scheme
 Commonly made errors

• Unbalanced DFDs
• Forgetting to mention the names of the data flows
• Unrepresented functions or data
• External entities appearing at higher level DFDs
• Trying to represent control aspects
• Context diagram having more than one bubble
• A bubble decomposed into too many bubbles in the
next level (should be 3 to 7)
• Terminating decomposition too early
• Nouns used in naming bubbles
Shortcomings of the DFD Model

 DFD models suffer from several shortcomings:

 DFDs leave ample scope to be imprecise.

 In a DFD model, we infer about the function

performed by a bubble from its label

 A label may not capture all the functionality of a

bubble
Shortcomings of the DFD Model

 Control information is not represented:

 For instance, order in which inputs are consumed
and outputs are produced is not specified.

Customer-history Item-file

Accept- inventory
Customer-file order

order Process-
Accepted-
orders order
Shortcomings of the DFD Model

 A DFD does not specify synchronization aspects:

 For instance, the DFD in TAS example does not

specify:

 whether process-order may wait until the

accept-order produces data

 whether accept-order and handle-order may

proceed simultaneously with some buffering
mechanism between them.
Transaction analysis

Transaction-
center
trans 3
trans 1
trans 2

type 1 type 2 type 3

Transform Analysis
Level 1 DFD for TAS

Customer-history Item-file
query

Accept- inventory statistics

Customer-file order
Handle-
query
order Accepted-orders Process-
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-order Process-

order
THE END