Software Engineering & UML

Module-3

Faculty :
Dr. Pulak Sahoo
Associate Professor
Silicon Institute Of Technology 1
 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

2
Software
Design
Introduction

 Design phase transforms SRS doc to Design docs:

 Design documents are easily implementable using any

programming language

SRS Document Design Documents

Design Activities
 S/W Design Process
S/W
Design

FOD OOD

Structured Structured Identify Objects

Analysis Design & Relationships

DFD HLD DD

UML
Structure Module Models
Chart Spec.
 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

4. Data structures of individual modules

DD
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
 Relationships among modules d3 d1 d4

 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 ..
D3 ..
Data
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
 This will make the system easy to maintain & change
 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
modularity
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 are there
functional
sequential
communicational Degree of
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 types of coupling are there
data
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
 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
 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 to
content coupling
 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
 Functions are mapped to a module structure
• f1
• f2 d2
• f3 d1

•
• 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

39
 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
40
 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”

41
 S/W Design Process
S/W
Design

FOD OOD

Structured Structured Identify Objects

Analysis Design & Relationships

DFD HLD DD

UML
Structure Module Models
Chart Spec.
 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 d2
• f3 d1

•
• d3 d1 d4
•
• fn
44
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
F1 .. Functions
For each module, design : F2 ..
F3 ..
Data structure & Algorithms F4 ..
F5 ..
Structured Design -Detail Design

 Detailed design can be directly implemented:

Using any programming language

46
Data Flow Diagrams

(DFDs)
47
 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

48
DFD of a Car Assembly Unit

Engine Store Door Store

Chassis with Partly

Engine Assembled
Car
Fit Fit Fit Paint and
Engine Doors Wheels Test
Assembled
Car Car

Chassis Store Wheel Store

49
 Data flow diagram

 DFD is a graphical model:

 Shows different processes of the system

&
 Data interchange among the processes

50
 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

51
Data Flow Diagrams (DFDs)

 Primitive Symbols Used for Constructing DFDs:

External Entity

Process
Data Flow

Output

Data Store
52
 (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

53
 (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

54
 (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

55
 (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

56
 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

57
(5) Output Symbol

Output produced by the system

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

58
Continue from here
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

60
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

61
 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)

62
 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
63
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

66
 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
67
 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

68
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
70
 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 ..

71
 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

72
 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

73
Decompose how long?

 Decomposition of a bubble should be carried on until:

 The function of the bubble can be described using

A simple algorithm

74
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

75
DFD-1: Transport Service Auto. System

76
DFD-2: Transport Service Auto. System

77
 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

78
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

79
 Balancing a DFD

c
b c

c1
d1

a d
e
Level 1 d e1
e
Level 2
80
 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...

81
 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*

86
 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
query
order
indent

Handle-order Handle-indent Handle-query

Get-order Accept-order Process-

order
THE END

101