MODULE:V

SOFTWARE DESIGN

01/13/24 MODULE-V SOFTWARE DESIGN 1

Software Design

 Design phase transforms SRS document into

the design document.

 The design document produced at the end of

the design phase should be implementable
using a programming language in the coding
phase.
01/13/24 MODULE-V SOFTWARE DESIGN 2
Software Design

01/13/24 MODULE-V SOFTWARE DESIGN 3

Items Designed During Design Phase
 Different modules
 Control relationship (call/invocation
relationship) among modules
 Interface among modules(data items
exchanged among different modules)
 Data structure of individual modules
 Algorithm required to implement individual
module.
01/13/24 MODULE-V SOFTWARE DESIGN 4
Software Design

01/13/24 MODULE-V SOFTWARE DESIGN 5

Software Design
 A module consists of:
--several functions
--associated data structures.
A High Level Design identify…
 Modules

 control relationships among modules

 interfaces among modules.

01/13/24 MODULE-V SOFTWARE DESIGN 6

Software Design

 Several notations are available to represent

high-level design:
 Usually a tree-like diagram called structure
chart is used.

01/13/24 MODULE-V SOFTWARE DESIGN 7

Software Design
 Detailed design

For each module, design:

--data structure
--algorithms

01/13/24 MODULE-V SOFTWARE DESIGN 8

Attributes of a good software design
 Correctness
 Should correctly implement all the functionalities of

the system.
 Understandability
 Easily understandable
 Efficiency

-- A good design solution should adequately address

resource ,time and cost optimization issues.
 Maintainability
 Easily amenable to change

01/13/24 MODULE-V SOFTWARE DESIGN 9

Goals of a good design
 Three characteristics that serves as a guide for the
evaluation of a good design:
 Design must
o Implement all the explicit requirements
o Accommodate all the implicit requirements
 Design must be
o Readable
o Understandable guide for those who generate the code, who
test and who support the software
 Design should provide a complete picture of the software,
addressing data, functions, and behavioral domain from
an implementation perspective.

01/13/24 MODULE-V SOFTWARE DESIGN 10

Understandability
 Unless a design is easy to understand,
tremendous effort needed to maintain it.
 We already know that about 60% effort

is spent in maintenance.
 If the software is not easy to understand:

maintenance effort would increase many

times.

01/13/24 MODULE-V SOFTWARE DESIGN 11

Understandability
 Use consistent and meaningful names
for various design components.
 Design solution should consist of: a cleanly
decomposed set of modules (modularity).
 Different modules should be neatly arranged
in a hierarchy: in a neat tree-like diagram.

01/13/24 MODULE-V SOFTWARE DESIGN 12

Modularity
 Modularity is a fundamental attribute of any
good design.
 Decomposition of a problem cleanly into
modules facilitates the design by taking
advantage of the divide and conquer principle.
-Modules are almost independent of each
other.

01/13/24 MODULE-V SOFTWARE DESIGN 13

Example of Cleanly and Non cleanly
Decomposed Modules

01/13/24 MODULE-V SOFTWARE DESIGN 14

Modularity…
Neat arrangement of modules in a hierarchy
means:
 low fan-out
 abstraction

01/13/24 MODULE-V SOFTWARE DESIGN 15

Modularity…
 If modules are independent:
- modules can be understood separately,
 To understand why this is so,
 remember that it is very difficult to break a
bunch of sticks but very easy to break the
sticks individually.

01/13/24 MODULE-V SOFTWARE DESIGN 16

Modularity…
 Reduces complexity
 Facilitate changes

 Results in easier implementations by

encouraging parallel development

of different parts of a system.

01/13/24 MODULE-V SOFTWARE DESIGN 17

Modularity…

01/13/24 MODULE-V SOFTWARE DESIGN 18

Functional Independence
Benifits:
 Better understandability and good design:

 Complexity of design is reduced,

 Different modules easily understood in

isolation:
 Since different modules are independent

01/13/24 MODULE-V SOFTWARE DESIGN 19

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.

01/13/24 MODULE-V SOFTWARE DESIGN 20

Modularity…
 In technical terms, modules should display:

--high cohesion
--low coupling.

01/13/24 MODULE-V SOFTWARE DESIGN 21

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 .

01/13/24 MODULE-V SOFTWARE DESIGN 22

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

01/13/24 MODULE-V SOFTWARE DESIGN 23

Classification of Cohesiveness

01/13/24 MODULE-V SOFTWARE DESIGN 24

Coincidental Cohesion
 The module performs a set of tasks which
relate to each other very loosely .
 Data elements or instructions within module

have no relation to each other.

 the module contains a random collection of
functions.
 functions have been put in the module out of pure
coincidence without any thought or design.

01/13/24 MODULE-V SOFTWARE DESIGN 25

 Example:(Coincidental Cohesion)

FILE PROCESSING
OPEN EMPLOYEE UPDATE FILE
READ EMPLOYEE REC
PRINT_PAGE_HEADING
OPEN MASTER FILE(EMPLOYEE)
SET PAGE_COUNT TO 1
SET ERR_FLAG TO FALSE
END

01/13/24 MODULE-V SOFTWARE DESIGN 26

Logical cohesion
 All elements of the module perform similar
operations:
 e.g. error handling, data input, data output,

etc.

 Components are logically related to each

other.
 Modules which contains routines to support

different types of input.

01/13/24 MODULE-V SOFTWARE DESIGN 27
 Example(Logical Cohesion)
READ_ALL_FILES
CASE OF FILE_CODE
1:READ CUST_TRAN REC
IF NOT EOF
INCREMENT_TRAN_COUNT
ENDIF
2:READ CUST_MASTER REC
IF NOT EOF
INCREMENT CUST_MASTER_COUNT
ENDIF
3:READ PRODUCT_MASTER REC
IF NOT EOF
INCREMENT PRODUCT_MASTER_COUNT
ENDIF
ENDCASE
END

01/13/24 MODULE-V SOFTWARE DESIGN 28

Temporal cohesion
 The module contains tasks that are related by the
fact that all the tasks must be executed in the same
time span.
 Example:
 Cancel all tasks

 Cancel all windows

 Cancel all data files

 Shuts down the machines

 These tasks which are not logically or functionally related

to each other, but takes place when a failure occurs.

01/13/24 MODULE-V SOFTWARE DESIGN 29
 Example(Temporal cohesion)

INITIALIZATION
OPEN TRAN_FILE
ISSUE PROMPT ‘ENTER DATE’
READ TODAYS_DATE
SET TRAN_COUNT TO ZERO
SET REPORT_TOTAL TO ZERO
OPEN REPORT_FILE
END

01/13/24 MODULE-V SOFTWARE DESIGN 30

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.

01/13/24 MODULE-V SOFTWARE DESIGN 31

 Example(Procedural cohesion)
READ STUD_REC AND TOTAL_STUD_AGES
NO_OF_REC=0
TOTAL_AGE=0
READ STUD_REC
DO WHILE MORE_REC_EXIST
ADD AGE TO TOTAL_AGE
ADD 1 TO NO_OF_REC
READ STUD_REC
ENDDO
END

01/13/24 MODULE-V SOFTWARE DESIGN 32

Communicational cohesion
All functions of the module reference or update
the same data structure.
 Different outputs are generated on same input
 i.e. Communicational cohesion occurs when two
operations share common data, but are otherwise
unrelated.

01/13/24 MODULE-V SOFTWARE DESIGN 33

 Example(Communicational cohesion)
PROCEDURE ERR_REPORT
VALIDATE PRODUCT_REC
IF TRAN_TYPE NOT=0 THEN
WRITE_ERR_REPORT
ENDIF
IF CUST_NO NOT NUMERIC THEN
WRITE ERR REPORT
ENDIF
IF PRODUCT_NO=BLANKS
WRITE ERR REPORT
ENDIF
END

01/13/24 MODULE-V SOFTWARE DESIGN 34

Sequential cohesion
 Elements of a module form different parts of a
sequence, i.e., the output from one element of the
sequence is input to the next.
 Example-1

Example-2

01/13/24 MODULE-V SOFTWARE DESIGN 35

 Example(Sequential cohesion)

PROCESS PURCHASES
TOTAL_PURCHASE=0
READ NO_OF_PURCHASES
DO LOOP_INDEX=1 TO NO_OF_PURCHASES
GET PURCHASES
ADD PURCHASES TO TOTAL_PURCHASES
ENDDO
SALES_TAX=TOTAL_PURCHASES*SALE_TAX_PERCENT
AMT_DUE=TOTAL_PURCHASES+ SALES_TAX
END

01/13/24 MODULE-V SOFTWARE DESIGN 36

Functional cohesion

 Different elements of a module cooperate to

achieve a single function,

 A simple example of functional cohesion is a math function.

Pick any of them, sin(), cos (), or atan ()

01/13/24 MODULE-V SOFTWARE DESIGN 37

 Example(Functional cohesion)

CALCULATE_SALES_TAX
IF PRODUCT IS SALES_TAX EXEMPT THEN
SALES_TAX=0
ELSE
IF PRODUCT_PRICE<$50 THEN
SALES_TAX=PRODUCT_PRICE*0.25
ENDIF
ENDIF

01/13/24 MODULE-V SOFTWARE DESIGN 38

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.

01/13/24 MODULE-V SOFTWARE DESIGN 39

Classes of coupling

01/13/24 MODULE-V SOFTWARE DESIGN 40

Data coupling

 Two modules are data coupled, if they

communicate via an elementary data item,
---e.g. an integer, a float, a character, etc.

 The data item should be problem related,

but not used for control purpose.

01/13/24 MODULE-V SOFTWARE DESIGN 41

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.

01/13/24 MODULE-V SOFTWARE DESIGN 42

 Control coupling
 Data from one module is used to direct the 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

share code,
 e. g, branching from one module into another

module.
 When customer not found, component calls the
AddCustomer( ) method that is responsible for
maintaining customer data.

01/13/24 MODULE-V SOFTWARE DESIGN 43

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.
 Fan-in: indicates how many modules directly
invoke a given module.
 High fan-in represents code reuse and is in
general encouraged.
01/13/24 MODULE-V SOFTWARE DESIGN 44
Fan-in & Fan-out

01/13/24 MODULE-V SOFTWARE DESIGN 45

 A design having modules:
with high fan-out numbers is not a good
design:
 a module having high fan-out lacks cohesion.

01/13/24 MODULE-V SOFTWARE DESIGN 46

Visibility and Layering

 A module A is said to be visible by 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.

01/13/24 MODULE-V SOFTWARE DESIGN 47

Abstraction
 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.
01/13/24 MODULE-V SOFTWARE DESIGN 48
Design Concepts & Principles

01/13/24 MODULE-V SOFTWARE DESIGN 49

 DFD serves two purposes:
 Provides an indication of how data are transformed
as they move through the system
 To depict the functions (& sub-functions) that
transform the data flow.
 A description of each function presented in the
DFD is contained in a processes specification
(PSPEC).

01/13/24 MODULE-V SOFTWARE DESIGN 50

 STD indicates how system behaves as a
consequence of external events. It represents
various modes of behavior (state) of the
system & the manner in which transitions are
made from state to state.
 Additional information about the control
aspects of the software is contained in the
control specifications (CSPEC)

01/13/24 MODULE-V SOFTWARE DESIGN 51

 The attributes of each data objects noted in the ER
diagram can be described using data object
description.
 Data Design
 Transforms the information domain model created
during analysis into the data structure that will be
required to implement the software.
 The data objects and the relationships defined in the
ER diagram and the detailed data contents depicted in
data dictionary provides the basis for the data design
activity.
 Part of the design occurs in conjunction with the design
of s/w architecture and more detailed data design
occurs as each s/w component is designed.

01/13/24 MODULE-V SOFTWARE DESIGN 52

 Architectural Design
 Defines the relationships between major
structural elements.
 Can be derived from the system specification, the
analysis model and the interactions of
subsystems.
 Interface Design
 Describes how the software communicates
within itself, with the system that interoperate
with it and with humans who use it.
01/13/24 MODULE-V SOFTWARE DESIGN 53
 Component Level Design
 Transforms structural elements of the software
architecture into procedural description of software
component.
 Information obtained from PSPEC, CSPEC, &
STD serves as basis for component design.
 Software design serves as the foundation for
all the software engineering and software
support steps that follow.

01/13/24 MODULE-V SOFTWARE DESIGN 54

Design Concepts…
 A set of fundamental software design concepts has evolved
over past four decades. Each provides the software designer
with a foundation from which more sophisticated design
methods can be applied.
1. ABSTRACTION
2. REFINEMENT
3. MODULARITY
4. SOFTWARE ARCHITECTURE
5. CONTROL HIERARCHY
6. STRUCTURAL PARTITIONING
7. DATA STRUCTURE
8. SOFTWARE PROCEDURE
9. INFORMATION HIDING

01/13/24 MODULE-V SOFTWARE DESIGN 55

Abstraction

01/13/24 MODULE-V SOFTWARE DESIGN 56

 Procedural Abstraction
 It is a named sequence of instructions that has a
specific and limited function.
 E.g. OPEN A DOOR is a long sequence of
procedural steps
1. walk to the door
2. Reach out and grasp the knob
3. Turn knob & pull door
4. Step away from moving door etc.

01/13/24 MODULE-V SOFTWARE DESIGN 57

 Data Abstraction
 Is a named collection of data describes a data
object
 E.g. DOOR; The attributes are
1. Door type
2. Swing direction
3. Opening mechanism
4. Weight
5. Dimension etc.

01/13/24 MODULE-V SOFTWARE DESIGN 58

 Control Abstraction
It implies a program control mechanism without
specifying internal details
 e.g.Thread management in a multithreading

environment

01/13/24 MODULE-V SOFTWARE DESIGN 59

Refinement

-It is the top down design strategy.

-In each step(of refinement), one or several
instructions of the given program are
decomposed into more detail instructions.
-Refinement is actually a process of elaboration.

01/13/24 MODULE-V SOFTWARE DESIGN 60

Architecture

 Architecture is the hierarchical structure of a

program components (modules), the manner in
which these components interact and the
structure of data that are used by the
component.
-- Client Server Architecture
-- Main program/Subprogram Architecture
-- Layered Architecture(core layer, utility layer,
application layer, user interface layer)

01/13/24 MODULE-V SOFTWARE DESIGN 61

01/13/24 MODULE-V SOFTWARE DESIGN 62
01/13/24 MODULE-V SOFTWARE DESIGN 63
01/13/24 MODULE-V SOFTWARE DESIGN 64
Control Hierarchy
(program structure)

 It represents the organization of the program

components (modules) and implies a hierarchy
of control.
 It does not represents the procedural aspect of
software.

01/13/24 MODULE-V SOFTWARE DESIGN 65

Control Hierarchy CONT…

01/13/24 MODULE-V SOFTWARE DESIGN 66

Structural partitioning
 For a hierarchical style of architecture the program module
can be partitioned into:
 Horizontal
 Vertical
 Horizontal partitioning defines separate branches of the modular
hierarchy for each major program function.

Simplest way is to partition a system into: input, data transformation

(processing), and output.

Advantages of horizontal partition:

- easy to test, maintain, and extend
- fewer side effects in change propagation or error propagation
Disadvantage: more data to be passed across module interfaces -
complicate the overall control of program flow

01/13/24 MODULE-V SOFTWARE DESIGN 67

 Vertical partitioning suggests the control and
work should be distributed top-down in
program structure.
Advantages:
- good at dealing with changes:
- easy to maintain the changes
- reduce the change impact and and
propagation

01/13/24 MODULE-V SOFTWARE DESIGN 68

Data Structure
 Represents the logical relationship among individual
elements of data.
 It indicates the
 Organization of data

 Method of access

 Degree of associativeness

 Process alternatives for information

01/13/24 MODULE-V SOFTWARE DESIGN 69

Software Procedure
 Program structure define control hierarchy without
regard to the sequence of processing and decision.
 Software focuses on the processing details of each
module individually.
 Procedure must provide a precise specification of
processing including
 Sequence of events
 Exact decision points
 Repetitive operations, data organization and structure

01/13/24 MODULE-V SOFTWARE DESIGN 70

Information Hiding
 Modules be characterized by design decision
that each module hides from all others .
 i.e. information (data & procedure) contained
within a module is inaccessible to other
modules that have no need for such
information.

01/13/24 MODULE-V SOFTWARE DESIGN 71

Structured Analysis
 Transforms a textual problem description into
a graphic model.
– Done using Data Flow Diagrams (DFDs).
 – DFDs graphically represent the results of
structured analysis.

01/13/24 MODULE-V SOFTWARE DESIGN 72

 DFD is an elegant modeling technique:
 – Useful not only to represent the results of
structured analysis.
 – Applicable to other areas also:
e.g. for showing the flow of documents or
items in an organization,
 DFD technique is very popular:
– It is powerful and yet simple to understand
and use.
01/13/24 MODULE-V SOFTWARE DESIGN 73
 DFD is a hierarchical graphical model:
 – Shows the different functions (or processes)
of the system and
 – Data interchange among the processes.

01/13/24 MODULE-V SOFTWARE DESIGN 74

It is useful to consider each function as a
processing station:
 –Each function consumes some input data.
 –Produces some output data.

01/13/24 MODULE-V SOFTWARE DESIGN 75

 Data Flow Model of a Car Assembly Unit

01/13/24 MODULE-V SOFTWARE DESIGN 76

 A DFD model:
– Uses limited types of symbols.
– Simple set of rules
– Easy to understand:
It is a hierarchical model.

01/13/24 MODULE-V SOFTWARE DESIGN 77

 Primitive Symbols Used for Constructing
DFDs:

01/13/24 MODULE-V SOFTWARE DESIGN 78

External Entity Symbol

 Represented by a rectangle
 External entities are real physical entities:
– input data to the system or
– consume data produced by the system.
– Sometimes external entities are called
terminator, source, or sink.

01/13/24 MODULE-V SOFTWARE DESIGN 79

Function Symbol
 A function such as “search-book” is
represented using a circle:
 – This symbol is called a process or bubble or
transform.
 – Bubbles are annotated with corresponding
function names.
 – Functions represent some activity:
 Function names should be verbs.

01/13/24 MODULE-V SOFTWARE DESIGN 80

Data Flow Symbol

 A directed arc or line.

 – Represents data flow in the direction of the
arrow.
 – Data flow symbols are annotated with names
of data they carry.

01/13/24 MODULE-V SOFTWARE DESIGN 81

Data Store Symbol

 Represents a logical file:

 – A logical file can be:
- a data structure
- a physical file on disk.
 – Each data store is connected to a process:
by means of a data flow symbol.

01/13/24 MODULE-V SOFTWARE DESIGN 82

 Direction of data flow arrow:
– Shows whether data is being read from or
written into it.
 An arrow into or out of a data store
– Implicitly represents the entire data of the
data store
 – Arrows connecting to a data store need not
be annotated with any data name.

01/13/24 MODULE-V SOFTWARE DESIGN 83

01/13/24 MODULE-V SOFTWARE DESIGN 84
Output Symbol

 Output produced by the system

01/13/24 MODULE-V SOFTWARE DESIGN 85

Synchronous Operation

 If two bubbles are directly connected by a data

flow arrow: they are synchronous.

01/13/24 MODULE-V SOFTWARE DESIGN 86

Asynchronous Operation

 If two bubbles are connected via a data store:

they are not synchronous.

01/13/24 MODULE-V SOFTWARE DESIGN 87

 Initially represent the software at the most
abstract level:
– Called the context diagram.
 – The entire system is represented as
a single bubble,
 – This bubble is labeled according to the main
function of the system.

01/13/24 MODULE-V SOFTWARE DESIGN 88

Tic-tac-toe: Context Diagram

01/13/24 MODULE-V SOFTWARE DESIGN 89

 A context diagram shows:

–Data input to the system,

–Output data generated by the system,
–External entities

01/13/24 MODULE-V SOFTWARE DESIGN 90

 Context diagram captures:
– Various entities external to the system
and interacting with it.
– Data flow occurring between the system and
the external entities.
 The context diagram is also called as the level
0 DFD.

01/13/24 MODULE-V SOFTWARE DESIGN 91

 Context Diagram Establishes the context of the
system, i.e.
–Represents:
Data sources
Data sinks.

01/13/24 MODULE-V SOFTWARE DESIGN 92

Level 1 DFD
Examine the SRS document:
 – Represent each high-level function as a

bubble.
 – Represent data input to every high level

function.
 – Represent data output from every

high-level function.

01/13/24 MODULE-V SOFTWARE DESIGN 93

Higher Level DFDs
 Each high-level function is separately
decomposed into sub functions:
– Identify the sub-functions of the function
– Identify the data input to each sub-function
– Identify the data output from each sub-
function
 These are represented as DFDs.

01/13/24 MODULE-V SOFTWARE DESIGN 94

Decomposition of a bubble:
– Also called factoring or exploding.
 Each bubble is decomposed to

– Between 3 to 7 bubbles.

01/13/24 MODULE-V SOFTWARE DESIGN 95

Example 1: RMS Calculating
Software
 Consider a software called RMS calculating
software:
 – Reads three integers in the range of - 1000
and +1000
 – Finds out the root mean square (rms) of
the three input numbers
 – Displays the result.

01/13/24 MODULE-V SOFTWARE DESIGN 96

01/13/24 MODULE-V SOFTWARE DESIGN 97
 Accept input numbers from the user:
– Validate the numbers,
– Calculate the root mean square of the input
numbers
– Display the result.

01/13/24 MODULE-V SOFTWARE DESIGN 98

Level 1 DFD for RMS Software

01/13/24 MODULE-V SOFTWARE DESIGN 99

Level 2 DFD for RMS Software

01/13/24 MODULE-V SOFTWARE DESIGN 100

Level 3 DFD for RMS Software

01/13/24 MODULE-V SOFTWARE DESIGN 101

 Decomposition is never carried on up to basic
instruction level:
– A bubble is not decomposed any further:
 If it can be represented by a simple set of
instructions

01/13/24 MODULE-V SOFTWARE DESIGN 102

Balancing a DFD
 Data flowing into or out of a bubble:
 – Must match the data flows at the next level
of DFD. In the level 1 of the DFD,
 – Data item c flows into the bubble P3 and the
data item d and 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.
01/13/24 MODULE-V SOFTWARE DESIGN 103
01/13/24 MODULE-V SOFTWARE DESIGN 104
 Number the bubbles in a DFD:
 – Numbers help in uniquely identifying any
bubble from its bubble number.
 The bubble at context level: Assigned number 0.
 Bubbles at level 1: – Numbered 0.1, 0.2, etc.
 When a bubble numbered x is decomposed,
 – Its children bubble are numbered x.1, x.2, x.3,
etc.

01/13/24 MODULE-V SOFTWARE DESIGN 105

Data Dictionary
 A DFD is always accompanied by a data dictionary.
 A data dictionary lists all data items appearing in a
DFD:
 Definition of all composite data items in terms of
their component data items.
 All data names along with the purpose of the data
items.
 For example, a data dictionary entry may be:
 grossPay = regularPay+overtimePay

01/13/24 MODULE-V SOFTWARE DESIGN 106

Importance of Data Dictionary
 Provides all engineers in a project with
standard terminology for all data:
 – A consistent vocabulary for data is very
important
 – Different engineers tend to use different
terms to refer to the same data, Causes
unnecessary confusion.

01/13/24 MODULE-V SOFTWARE DESIGN 107

Importance of Data Dictionary
 Data dictionary provides the definition of
different data: In terms of their component
elements.
 For large systems, The data dictionary grows
rapidly in size and complexity.
 – Typical projects can have thousands of data
dictionary entries.
– It is extremely difficult to maintain such a
dictionary manually.
01/13/24 MODULE-V SOFTWARE DESIGN 108
 CASE (Computer Aided Software
Engineering) tools come handy:
– CASE tools capture the data items appearing
in a DFD automatically to generate the data
dictionary

01/13/24 MODULE-V SOFTWARE DESIGN 109

 Composite data are defined in terms of
primitive data items using following operators:
 +: denotes composition of data items ,

e.g. – a+b represents data a and b.

 [,,,]: represents selection,

 – i.e. any one of the data items listed inside the

square bracket can occur.

 – For example, [a,b] represents either a occurs

or b occurs.

01/13/24 MODULE-V SOFTWARE DESIGN 110

 ( ): contents inside the bracket represent
optional data
– which may or may not appear.
e.g. – a+(b) represents either a or a+b occurs.
 {}: represents iterative data definition,

– e.g. {name}5 represents five name data.

01/13/24 MODULE-V SOFTWARE DESIGN 111

 {name}* represents
– zero or more instances of name data.
 = represents equivalence,

– e.g. a=b+c means that a represents b and c.

 * *: Anything appearing within * * is

considered as comment.

01/13/24 MODULE-V SOFTWARE DESIGN 112

Data Dictionary for RMS Software
numbers=valid-numbers=a+b+c
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*

01/13/24 MODULE-V SOFTWARE DESIGN 113

 During structured design,
 – The DFD representation is transformed to a
structure chart representation.
 ● DFDs are very popular:
 – Because it is a very simple technique.

01/13/24 MODULE-V SOFTWARE DESIGN 114

 A DFD model:
– Difficult to implement using a programming
language:
 Structure chart representation can be easily

implemented using a programming language.

01/13/24 MODULE-V SOFTWARE DESIGN 115

Trading-House Automation
System (TAS)
 A large trading house wants us to develop a
software:
 – To automate book keeping activities

associated with its business.

 It has many regular customers:

– Who place orders for various kinds of

commodities.

01/13/24 MODULE-V SOFTWARE DESIGN 116

 The trading house maintains names and
addresses of its regular customers.
 Each customer is assigned a unique

customer identification number (CIN).

 As per current practice when a customer

places order:
 – The accounts department first checks the

credit-worthiness of the customer

01/13/24 MODULE-V SOFTWARE DESIGN 117

 The credit worthiness of a customer is
determined:
 – By analyzing the history of his payments

to the bills sent to him in the past.

 If a customer is not credit-worthy:

 – His orders are not processed any further

– An appropriate order rejection message is

generated for the customer.

01/13/24 MODULE-V SOFTWARE DESIGN 118

 If a customer is credit-worthy:
 – Items he/she has ordered are checked

against the list of items the trading house

deals with.
 The items that the trading house does not

deal with:
– Are not processed any further
– An appropriate message for the customer for
these items is generated.

01/13/24 MODULE-V SOFTWARE DESIGN 119

 The items in a customer's order that the
trading house deals with:
 – Are checked for availability in inventory.
 If the items are available in the inventory in
desired quantities:
 – A bill with the forwarding address of the
customer is printed.
 – A material issue slip is printed.

01/13/24 MODULE-V SOFTWARE DESIGN 120

 The customer can produce the material issue
slip at the storehouse:
 – Take delivery of the items.
 – Inventory data adjusted to reflect the sale to
the customer.

01/13/24 MODULE-V SOFTWARE DESIGN 121

 If an ordered item is not available in the
inventory in sufficient quantity:
 – To be able to fulfill pending orders store
details in a "pending-order" file :
 out-of-stock items along with quantity
ordered. customer identification number

01/13/24 MODULE-V SOFTWARE DESIGN 122

 The purchase department: would periodically
issue commands to generate indents.
 When generate indents command is issued:

 – The system should examine the

"pendingorder“ file
– Determine the orders that are pending
– Total quantity required for each of the items.

01/13/24 MODULE-V SOFTWARE DESIGN 123

 TAS should find out the addresses of the
vendors who supply the required items:
– Examine the file containing vendor
details (their address, items they supply etc.)
– Print out indents to those vendors

01/13/24 MODULE-V SOFTWARE DESIGN 124

 TAS should also answers managerial queries:
 – Statistics of different items sold over any
given period of time
 – Corresponding quantity sold and the price
realized.

01/13/24 MODULE-V SOFTWARE DESIGN 125

Context Diagram for TAS

01/13/24 MODULE-V SOFTWARE DESIGN 126

Level 1 DFD for TAS

01/13/24 MODULE-V SOFTWARE DESIGN 127

Data Dictionary for TAS
 response: [bill + material-issue-slip, reject-
message]
 query: period /* query from manager
regarding sales statistics*/
 period: [date+date,month,year,day]
 date: year + month + day
 year: integer
 month: integer
 day: integer
01/13/24 MODULE-V SOFTWARE DESIGN 128
 order: customer-id + {items + quantity}*
 accepted-order: order /* ordered items
available in inventory */
 reject-message: order + message /* rejection
message */
 pending-orders: customer-id +
{items+quantity}*
 customer-address: name+house#+street#+city+pin

01/13/24 MODULE-V SOFTWARE DESIGN 129

 item-name: string
 house#: string
 street#: string
 city: string
 pin: integer
 customer-id: integer
 bill: {item + quantity + price}* + total-amount +
customer-address
 material-issue-slip: message + item + quantity + customer-
address
 message: string
 statistics: {item + quantity + price }*
 sales-statistics: {statistics}*
 quantity: integer
01/13/24 MODULE-V SOFTWARE DESIGN 130
 Guidelines For Constructing DFDs
 Context diagram should represent

the system as a single bubble:

 – Many beginners commit the mistake of

drawing more than one bubble in the context

diagram.

01/13/24 MODULE-V SOFTWARE DESIGN 131

 All external entities should be represented in
the context diagram:
 – External entities should not appear at any

other level of DFD.

 Only 3 to 7 bubbles per diagram should be

allowed: Each bubble should be decomposed to

between 3 and 7 bubbles.

01/13/24 MODULE-V SOFTWARE DESIGN 132

 A common mistake committed by many
beginners:
 – Attempting to represent control
information in a DFD.
 – e.g. trying to represent the order in which
different functions are executed.

01/13/24 MODULE-V SOFTWARE DESIGN 133

 A DFD does not represent control
information:
 – The conditions under which different
functions are invoked are not represented.
 – For example, a function might invoke one
function or another depending on some
condition.
 – Many beginners try to represent this aspect
by drawing an arrow between the
corresponding bubbles.

01/13/24 MODULE-V SOFTWARE DESIGN 134

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

01/13/24 MODULE-V SOFTWARE DESIGN 135

For example, a bubble named find-bookposition
has only intuitive meaning:
– Does not specify several things:
● What happens when some input information
is missing or is incorrect.
● Does not convey anything regarding what
happens when book is not found
● or what happens if there are books by different
authors with the same book title.

01/13/24 MODULE-V SOFTWARE DESIGN 136

01/13/24 MODULE-V SOFTWARE DESIGN 137
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

01/13/24 MODULE-V SOFTWARE DESIGN 138

The way decomposition is carried out to arrive at
the successive levels of a DFD is subjective.
● The ultimate level to which decomposition is
carried out is subjective:
– Depends on the choice and judgement of the
analyst.
● Even for the same problem,
– Several alternative DFD representations are
possible:
– Many times it is not possible to say which
DFD representation is superior or preferable.
01/13/24 MODULE-V SOFTWARE DESIGN 139
DFD technique does not provide:
– Any clear guidance as to how exactly one
should go about decomposing a function:
– One has to use subjective judgement to carry
out decomposition.
● Structured analysis techniques do not specify
when to stop a decomposition process:
– To what length decomposition needs to be
carried out.

01/13/24 MODULE-V SOFTWARE DESIGN 140

Structured Design
 Aim is to transform the result of structured
analysis ( i.e. DFD )into structured chart.

 A structured chart represents the software

architecture, i.e. the various modules making
up the system, the module dependency and the
parameters that are passed among the different
modules
01/13/24 MODULE-V SOFTWARE DESIGN 141
The building blocks of structured chart:

01/13/24 MODULE-V SOFTWARE DESIGN 142

 One and only one module at the top
• At most one control relationship between any two
modules. (modules arranged in Layers / levels)
 The principle of abstraction doses not allow
the lower level modules to be aware of the
existence of the higher level modules

01/13/24 MODULE-V SOFTWARE DESIGN 143

Transformation of a DFD into a
Structured Chart:
1) Transform Analysis
2) Transaction Analysis
 Start with 1 Level DFD and then proceed to
lower level DFDs
 At each level of transformation, determine
whether it is transform or transaction
analysis applicable??

01/13/24 MODULE-V SOFTWARE DESIGN 144

Transform Analysis
 If all data input to the diagram are processed
in a similar ways (i.e. if all input data are
incident on the same bubble in the DFD), then
transform analysis is applicable.
 It is applicable to very small problems or at
the lower level DFD.

01/13/24 MODULE-V SOFTWARE DESIGN 145

Transaction Analysis
 Each different way in which data is processed
corresponds to a separate transaction.
 Each transaction corresponds to a
functionality.
 Useful for transaction processing system
 For each transaction, we trace the input data to
the output data.

01/13/24 MODULE-V SOFTWARE DESIGN 146

 The transaction is identified by studying the
discrete event types that drive the system
 The three transaction types here are: Check
Availability (an enquiry), Reserve Ticket
(booking) and Cancel Ticket (cancellation).

01/13/24 MODULE-V SOFTWARE DESIGN 147

01/13/24 MODULE-V SOFTWARE DESIGN 148
Transform Analysis

 Transform analysis is strategy of converting

each piece of DFD (may be from level 2 or
level 3, etc.) for all the identified transaction
centers.
 In case, the given system has only one
transaction (like a payroll system), then we can
start transformation from level 1 DFD itself.

01/13/24 MODULE-V SOFTWARE DESIGN 149

 Transform analysis is composed of the
following five steps:
1. Draw a DFD of a transaction type (usually done
during analysis phase)
2. Find the central functions of the DFD
3. Convert the DFD into a first-cut structure chart
4. Refine the structure chart
5. Verify that the final structure chart meets the
requirements of the original DFD
01/13/24 MODULE-V SOFTWARE DESIGN 150
01/13/24 MODULE-V SOFTWARE DESIGN 151
01/13/24 MODULE-V SOFTWARE DESIGN 152
Partitioning DFD
 Transformation-Centered Application:
 Data flow in a sequence, i.e. in a straight line
manner.

 Focus is on file handling and manipulation of data.

 Example: Sequential processing of a purchase

order

01/13/24 MODULE-V SOFTWARE DESIGN 153

Transformation Analysis…

01/13/24 MODULE-V SOFTWARE DESIGN 154

01/13/24 MODULE-V SOFTWARE DESIGN 155
Transaction Analysis…

01/13/24 MODULE-V SOFTWARE DESIGN 156

01/13/24 MODULE-V SOFTWARE DESIGN 157
01/13/24 MODULE-V SOFTWARE DESIGN 158
01/13/24 MODULE-V SOFTWARE DESIGN 159
01/13/24 MODULE-V SOFTWARE DESIGN 160
01/13/24 MODULE-V SOFTWARE DESIGN 161