Unit IV

Function Oriented
Software Design

1
Introduction
Function-oriented design techniques are very popular:
currently in use in many software development organizations.
Function-oriented design techniques:
start with the functional requirements specified in the SRS
document.
During the design process:
high-level functions are successively decomposed into more
detailed functions.
finally the detailed functions are mapped to a module
structure.
Successive decomposition of high-level functions:
into more detailed functions.
Technically known as top-down decomposition.
2
Introduction
SA/SD methodology:
Has essential features of several important function-
oriented design methodologies ---
if you need to use any specific design methodology later
on,
you can do so easily with small additional effort.

3
SA/SD (Structured
Analysis/Structured Design)
SA/SD technique draws heavily from the following
methodologies:
Constantine and Yourdon's methodology
Hatley and Pirbhai's methodology
Gane and Sarson's methodology
DeMarco and Yourdon's methodology
SA/SD technique can be used to perform
high-level design.

4
Overview of SA/SD
Methodology
SA/SD methodology consists of two distinct
activities:
Structured Analysis (SA)
Structured Design (SD)

During structured analysis:

functional decomposition takes place.

During structured design:

module structure is formalized.

5
Functional
decomposition
Each function is analysed:
hierarchically decomposed into more detailed functions.
simultaneous decomposition of high-level data
into more detailed data.

6
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.
Other tools used in SA:
Data Dictionary
Structured English
Decision trees
Decision table

7
Structured design
All the functions represented in the DFD are mapped to a
module structure.
The module structure also called as the software
architecture:
Software architecture:
refined through detailed design.
Detailed design can be directly implemented:
using a conventional programming language.

8
Structured Analysis vs.
Structured Design
Purpose of structured analysis:
capture the detailed structure of the system as the user views
it.

Purpose of structured design:

arrive at a form that is suitable for implementation in some
programming language.

9
Structured Analysis vs.
Structured Design
The results of structured analysis can be easily
understood even by ordinary customers:
does not require computer knowledge
directly represents customer’s perception of the problem
uses customer’s terminology for naming different functions
and data.

The results of structured analysis can be reviewed by

customers:
to check whether it captures all their requirements.

10
Structured Analysis

Based on principles of:

Top-down decomposition approach.

Divide and conquer principle:

each function is considered individually (i.e. isolated from
other functions)
decompose functions totally disregarding what happens in
other functions.

Graphical representation of results using

data flow diagrams (or bubble charts).

11
Data flow diagrams
DFD is an elegant modelling 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 because
it is simple to understand and use.

DFD is a hierarchical graphical model:

shows the different functions (or processes) of the system
and
data interchange among the processes.

12
DFD Concepts
It is useful to consider each function as a processing
station:
each function consumes some input data and
produces some output data.

Engine Store Door Store

Chassis with Partly

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

Chassis Store Wheel Store

Data Flow Model of a Car Assembly Unit

13
Data Flow Diagrams (DFDs)
A DFD model:
uses limited types of symbols.
simple set of rules
easy to understand:
it is a hierarchical model.

In a hierarchical model:
we start with a very simple and abstract model of a
system,
details are slowly introduced through the hierarchies.

14
Hierarchical Model

15
Data Flow Diagrams (DFDs)

Primitive Symbols Used for Constructing DFDs:

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

17
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.

search-
book

18
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. book-name
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.

book-details
19
Data Store Symbol
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.

find-book

Books

20
Output Symbol

Output produced by the system

21
Synchronous operation
If two bubbles are directly connected by a data flow
arrow:
they are synchronous

Read- number Validate-

numbers numbers
0.1 0.2 Valid
Data- number
items

22
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
number
Data-
items

23
Yourdon's vs. Gane Sarson
Notations
The notations that we would be following are closer to the Yourdon's
notations
You may sometimes find notations in books that are slightly different
For example, the data store may look like a box with one end
closed

24
How is Structured Analysis
Performed?
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 labelled according to the main function of the
system.

25
Tic-tac-toe: Context
Diagram

Tic-tac-toe
display software

move
Human Player

26
Context Diagram
A context diagram shows:
data input to the system,
output data generated by the system,
external entities.

27
Context Diagram
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.

28
Context Diagram
Context diagram
establishes the context of the system, i.e. represents:
Data sources
Data sinks.

29
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.

30
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.

31
Decomposition
Decomposition of a bubble:
also called factoring or exploding.
Each bubble is decomposed to
between 3 to 7 bubbles.
Too few bubbles make decomposition superfluous:
if a bubble is decomposed to just one or two bubbles:
then this decomposition is redundant.
Too many bubbles:
more than 7 bubbles at any level of a DFD
make the DFD model hard to understand.

32
Decompose how long?
Decomposition of a bubble should be carried on until:
a level at which the function of the bubble can be described
using a simple algorithm.

33
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.
The context diagram is simple to develop:
The system accepts 3 integers from the user
returns the result to him.

34
Example 1: RMS Calculating
Software

Data- Compute-
items RMS
0

User result

Context Diagram

35
Example 1: RMS Calculating
Software
From a cursory analysis of the problem description:
we can see that the system needs to perform several things.
Accept input numbers from the user:
validate the numbers,
calculate the root mean square of the input numbers
display the result.

36
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

37
Example 1: RMS Calculating
Software
Squared-
sum Calculate-
Calculate- mean
squared-sum 0.3.2
0.3.1

Valid -
numbers Mean-
Calculate- square
root
0.3.3

RMS

38
Example: RMS Calculating
Software
b
a c
Square Square Square
0.3.1.1 0.3.1.2 0.3.1.3

bsq
asq
csq
Sum
0.3.1.4

Squared-sum

39
Example: RMS Calculating
Software
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.

40
Data Dictionary
A data dictionary is a structured repository of data elements in the
system.
It stores the descriptions of all DFD data elements that is,
details and definitions of data flows
data stores, data stored in data stores
the processes.
all data names along with the purpose of data items.

A data dictionary improves the communication between the analyst

and the user.
It plays an important role in building a database.
Most DBMSs have a data dictionary as a standard feature.

41
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.
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.
42
Example of a Data
Dictionary
Sl No Data Name Description Size Type

1 ISBN ISBN Number 10 Varchar

2 TITLE Book title 60 Varchar

3 SUB Book Subjects 80 Varchar

4 ANAME Author Name 15 Varchar

43
Data Dictionary
CASE (Computer Aided Software Engineering) tools come handy:
CASE tools capture the data items appearing in a DFD
automatically to generate the data dictionary.
CASE tools support queries:
about definition and usage of data items.
For example, queries may be made to find:
which data item affects which processes,
a process affects which data items,
the definition and usage of specific data items, etc.
Query handling is facilitated:
if data dictionary is stored in a relational database
management system (RDBMS).

44
Data Definition
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.
( ): contents inside the bracket represent optional data
which may or may not appear.
a+(b) represents either a or a+b occurs.
{}: represents iterative data definition,
e.g. {name}5 represents five name data.
45
Data Definition
{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.

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

47
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
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.

48
Balancing a DFD
c
b c

c1
d1

a d
e
Level 1 d e1
e
Level 2

49
Numbering of Bubbles:
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, 0.3, etc
When a bubble numbered x is decomposed,
its children bubble are numbered x.1, x.2, x.3, etc.

50
Example 2: Tic-Tac-Toe
Computer Game
A human player and the computer make alternate moves on a 3
3 square.
A move consists of marking a previously unmarked square.
The user inputs a number between 1 and 9 to mark a square
Whoever is first to place three consecutive marks along a
straight line (i.e., along a row, column, or diagonal) on the
square wins.

51
Example: Tic-Tac-Toe
Computer Game
As soon as either of the human player or the computer wins,
a message announcing 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.

52
Context Diagram for
Example
Tic-tac-toe
software
display 0

move
Human Player

53
Level 1 DFD
Display- game
move board
0.1
result

Validate- Check-
move board winner
0.2 0.4

Play-
move
0.3

54
Data dictionary
Display=game + result
move = integer
board = {integer}9
game = {integer}9
result=string

55
Decision trees
Decision trees are a method for defining complex relationships by
describing decisions and avoiding the problems in communication.

A decision tree is a diagram that shows alternative actions and

conditions within horizontal tree framework. Thus, it depicts which
conditions to consider first, second, and so on.

Decision trees depict the relationship of each condition and their

permissible actions.

A square node indicates an action and a circle indicates a

condition.

It forces analysts to consider the sequence of decisions and

identifies the actual decision that must be made. 56
Decision trees

57
Decision Tables

Decision tables are a method of describing the complex logical

relationship in a precise manner which is easily understandable.

It is useful in situations where the resulting actions depend on the

occurrence of one or several combinations of independent
conditions.

It is a matrix containing row or columns for defining a problem and

the actions.

58
Components of a Decision
Table
Condition Stub − It is in the upper left quadrant which lists all the
condition to be checked.

Action Stub − It is in the lower left quadrant which outlines all the
action to be carried out to meet such condition.

Condition Entry − It is in upper right quadrant which provides

answers to questions asked in condition stub quadrant.

Action Entry − It is in lower right quadrant which indicates the

appropriate action resulting from the answers to the conditions in
the condition entry quadrant.

59
Entries into a Decision
Table
The entries in decision table are given by Decision Rules which
define the relationships between combinations of conditions and
courses of action.
The entries are:
Y shows the existence of a condition.
N represents the condition, which is not satisfied.
A blank - against action states it is to be ignored.
X (or a check mark will do) against action states it is to be carried out.

60
Example of a decision
table

61
Structured English
Structure English is derived from structured programming language
which gives more understandable and precise description of
process.
It is based on procedural logic that uses construction and
imperative sentences designed to perform operation for action.
It is best used when sequences and loops in a program must be
considered and the problem needs sequences of actions with
decisions.
It does not have strict syntax rule. It expresses all logic in terms of
sequential decision structures and iterations.

62
Structured English
Example
if customer pays advance then
Give 5% Discount
else if purchase amount >=10,000 then
if the customer is a regular customer then
Give 5% Discount
else
No Discount
end if
else
No Discount
end if

63
Structured Design
Structured design is a data-flow based methodology that helps in
identifying the input and output of the developing system.
The main objective of structured design is to minimize the
complexity and increase the modularity of a program.
Structured design also helps in describing the functional aspects of
the system.
In structured designing, the system specifications act as a basis for
graphically representing the flow of data and sequence of processes
involved in a software development with the help of DFDs.
After developing the DFDs for the software system, the next step is
to develop the structure chart.

64
Structured Design
Structured design partitions the program into small and
independent modules.
These are organized in top down manner with the details shown in
bottom.
Thus, structured design uses an approach called Modularization or
decomposition to minimize the complexity and to manage the
problem by subdividing it into smaller segments.

65
Advantages of SD
Advantages:
Critical interfaces are tested first.
It provide abstraction.
It allows multiple programmers to work simultaneously.
It allows code reuse.
It provides control and improves morale.
It makes identifying structure easier.

66
Flowcharts
The pictorial representation of the programs or the algorithm is
known as flowcharts
It is nothing but a diagrammatic representation of the various steps
involved in designing a system.
Program flowcharts graphically represent the logic and interaction
between program modules

67
Symol used in flowchart

68
Flowchart for Payment
method
Start

Advance No
Payment

Amount>
Yes No
=10,000

Yes

Yes Regular No
Customer

Bill 0%
Bill 5%
Discount
Discount

Stop
69
Structured Charts
A tool for designing a modular, top down systems which define the
various modules of system development and the relationship
between each module.
It shows the system module and their relationship between them.
It consists of diagram consisting of rectangular boxes that
represent the modules, connecting arrows, or lines.
Control Module − It is a higher-level module that directs lower-level modules,
called subordinate modules.
Library Module − It is a reusable module and can be invoked from more than
one point in the chart.
Approaches to design a structured chart −
Transform flow-Centered Structured Charts − They are used when all the
transactions follow same path.
Transaction flow–Centered Structured Charts − They are used when all
the transactions do not follow the same path.

70
Transform Flow
Information enters the system along paths that transform external
data into an internal form.
These paths are identified as incoming flow.
At the kernel of the software, a transition occurs. Incoming data are
passed through a transform center and begin to move along paths
that now lead "out“ of the software.
Data moving along these paths are called outgoing flow.
The overall flow of data occurs in a sequential manner and follows
one, or only a few, "straight line" paths.
When a segment of a data flow diagram exhibits these
characteristics, transform flow is present.

71
Transaction Flow
The fundamental system model implies transform flow.
However, information flow is often characterized by a single data
item, called a transaction that triggers other data flow along one of
many paths.
When a DFD takes the form shown in transaction flow is present.
It should be noted that, within a DFD for a large system, both
transform and transaction flow may be present.
For example, in a transaction-oriented flow, information flow along
an action path may have transform flow characteristics.

72
Transform & Transaction
Flow

73
Structured Charts

74
Structured Charts for TTT

TIC TAC TOE

Validate Display Play

Move board Move

Check
Winner

75
Objectives of Using
Structure charts
Functional Decomposition (Top down approach)
Information Hiding
Modularity
Low Coupling
High internal cohesion

76
Coupling
Coupling is the measure of the independence of components.

It defines the degree of dependency of each module of system

development on the other.

In practice, this means the stronger the coupling between the

modules in a system, the more difficult it is to implement and
maintain the system.

Each module should have simple, clean interface with other

modules, and that the minimum number of data elements should
be shared between modules.

77
Types of Coupling
High Coupling
These type of systems have inter-
connections with program units dependent
on each other.
Changes to one subsystem leads to
high impact on the other subsystem.

Low Coupling
These type of systems are made up of
components which are independent or
almost independent.
A change in one subsystem does
not affect any other subsystem.

78
Coupling Measures
Content Coupling − When one component actually modifies
another,then the modified component is completely dependent on
modifying one.
Common Coupling − When amount of coupling is reduced
somewhat by organizing system design so that data are accessible
from a common data store.
Control Coupling − When one component passes parameters to
control the activity of another component.
Stamp Coupling − When data structures is used to pass
information from one component to another.
Data Coupling − When only data is passed then components are
connected by this coupling.

79
Cohesion
Cohesion is the measure of closeness of the relationship between
its components. It defines the amount of dependency of the
components of a module on one another. In practice, systems
designer must ensure that −
They do not split essential processes into fragmented modules.
They do not gather together unrelated processes represented as processes on
the DFD into meaningless modules.

The best modules are those that are functionally cohesive. The
worst modules are those that are coincidentally cohesive

80
Degree of cohesion
Logical Cohesion − It is where several logically related functions
or data elements are placed in same component.

Temporal Cohesion − It is when a component that is used to

initialize a system or set variables performs several functions in
sequence, but the functions are related by timing involved.

Procedurally Cohesion − It is when functions are grouped

together in a component just to ensure this order.

Sequential Cohesion − It is when the output from one part of a

component is the input to the next part of it.

81
82