Function-Oriented Design

Module 3
Design

A process to design (verb)

Result of the design process (noun)

 Different levels…

System design or top-level design (modular level)

Detailed design (Internal design of the module)

 Design methodology

….is a systematic approach to create a design by

applying of a set of techniques and guidelines

Input – specifications of the system to be designed

Output – system design
 Object Oriented Design
vs
Function Oriented Design
 Object - oriented : modules in the design represent data
abstraction

 Function - oriented : consists of module definitions, with each

module supporting a functional abstraction

 Function-oriented design views a system as a set of modules

with clearly defined behavior that interact with each other in a
clearly defined manner to meet the system's requirements.
 In Function-oriented design, the system is viewed as a
Transformation function
 Design Objectives

The goal of software design is to find the best

possible design that meets your needs

You may have to explore different designs

Unfortunately, evaluation criteria for a design

are often subjective and non-quantifiable
 Major criteria to evaluate a design

 Correctness
• A software design is correct if a system built precisely according to
the requirements of the system
• A design should be verifiable (does an implementation match the
design), complete (does the design address its specified
requirements) and traceable (all design elements can be traced
back to specific requirements)
 Efficiency
• Does the design efficiently make use of scarce resources: such as
memory on a wireless sensor
 Maintainability and Simplicity
• How easy is it for the design of a system to be understood?
• Simpler designs make it easy for a developer to understand and
then maintain the system
 Cost
• Does the design help to reduce costs in later phases of software
development?
• Can one design achieve the same quality as another design while
reducing costs?
 Problem analysis Vs Design Principles

 Constructing a model of  Constructing a model of

problem domain solution domain

 Model depends on the  System depends on the

system model

 Model is used to  Model is used for

understand the problem optimization
Design Principles

Problem Partitioning and Hierarchy

Abstraction

Modularity

Top-Down and Bottom-Up Strategies

 Problem Partitioning and Hierarchy

 Divide and Conquer

 Decompose system into smaller and smaller pieces

 Ideally, each piece can be solved separately
 Ideally, each piece can be modified independent of other pieces

 Reality: each piece must communicate with other pieces

 This communication implies a certain cost
 At some point the cost is more than the benefit provided by the
individual pieces
 At this point, the decomposition process can stop
…contd

 Maintenance task can be minimized if each

peace can be modified separately (independent
peaces)
 Proper partitioning will make the system easier
to maintain by making the system easier to
understand
 Problem partitioning also aids design
verification
 The design produced by problem partitioning
can be represented as a hierarchy of
components (“whole-part of”)
 Abstraction

 Abstraction is a powerful concept used in all

engineering disciplines

 It is a tool that permits a developer to consider a

component in terms of the services (behaviors) it
provides without worrying about the details of its
implementation
 Contd…
 Abstraction is an excellent tool for creating a hierarchical
understanding of a system's functionality

 In design contexts, you might see references to two “types” of

abstraction
 functional abstraction: a module is specified by the functions it
performs
 data abstraction: a data structure is manipulated in terms of pre-
defined operations; the implementation of the data structure is
hidden from its users (only operations are visible)
 The former is primarily used in functional design, the latter is used
primarily in object-oriented design
 Modularity

 A system is considered modular if it consists of discreet

components so that each component can be
implemented separately, and a change to one
component has minimal impact on other components

 Helps in system repair and in system building

 Each component needs to support a well-defined

abstraction and have a specific interface that other
modules use to interact with it

 As Jalote says “Modularity is where abstraction and

partitioning come together”.
 Top-Down vs Bottom-Up Design
 A system consists of a set of components, which have
subcomponents of their own
 The highest level component is the system itself, a concept we
have seen when discussing context diagrams

 We can design such a hierarchy using either a top-down

approach or a bottom-up approach
 In reality, we use both approaches and meet in the middle

 A top-down approach starts with the system as a whole, and

using stepwise refinement, decomposes it into sub-
components that exist at lower levels of abstraction
 Contd…

 A bottom-up approach starts with primitive components that

provide foundational services and using layers of abstraction
builds the functionality the system needs until the entire system
has been realized

 A top-down approach is typically more useful in situations only if

the specifications of the system are clearly known and
application is being built from scratch (water fall model)

 A bottom-up approach is thus more useful in situations in which

a new application is being created from an existing (legacy)
system (Iterative enhancement model)
 Module Level Concepts

 Module is a logically separable part of a program

 It is a program unit that is discreet and identifiable with

respect to compiling and loading
 A module can be a macro, a function, a procedure, a
process or a package.
Module-Level Concepts

Two modularization criteria

Coupling

Cohesion
 Coupling
 “how strongly” different modules are interconnected

 By definition,
“Coupling between modules is the strength of interconnections between
modules or a measure of interdependence among modules”

 An abstract concept and is not easily quantifiable

 The more connections between modules the more dependent they are. ie. The
more knowledge about one module is required to understand or solve the other
module

 Highly coupled – strong interconnections

loosely coupled – weak interconnections
 Contd…
 Factors influencing coupling are :
type of connection between modules (interfaces)
the complexity of the interface
the type of information flow between modules
 To keep coupling low, Minimize the number of interfaces per
module and the complexity of each interface
Coupling is reduced only if the defined entry interface of a
module is used by other modules. (exclusive parameters)
Coupling would increase if shared variables used as interfaces
 …contd

 Complexity of interface is another factor.

 The more complex each interface, the higher
will be the degree of coupling
Complexity of the entry interface of a
procedure depends on the number of items
being passed as parameters
 Third factor is Type of information flow along
the interface
Two kinds of flow – data and control
Complexity is minimal- if only data flows
Complexity is maximum- if both flows
Factors affecting coupling
 Cohesion
 Cohesion is the concept that tries to capture intra-module bonds

 Shows how closely the elements of a module are related to each

other.

 Shows how tightly bound the internal elements of the module are to
one another

 Usually, greater the cohesion of each module in the system, the

lower the coupling between module is.

 cohesion: how focused is an object (or module, or function, or

package, etc.) on a particular task or concern
 a highly cohesive object has attributes and behavior that relate
only to one task or concern
Levels of cohesion
 Coincidental Low

 Logical

 Temporal

 Procedural

 Communicational

 Sequential

 Functional High
 Details…
 Coincidental Cohesion occurs when there is no meaningful
relationship among the elements of a module.

 Logical Cohesion: if there is some logical relationship between

the elements of a module (input and output modules)

 Temporal cohesion: same as logical cohesion, except that the

elements are also related in time and are executed together
(initialization, clean-up, termination)

 Procedurally cohesive module contains elements that belong

to a common procedural unit (loop or a sequence of decision
statements)
 Contd…
 Communicational cohesion has elements that are related
by a reference to the same input or output data (may
perform more than one function)

 Sequential cohesion occurs when output of one forms the

input to another.

 In functional cohesion all the elements of the module are

related to performing a single function (single function or
single goal – “compute square root” or “sort the array”)
 How does one determine the cohesion
level of a module?

 Compound sentence : sequential or communicational

cohesion

 “first”, “next”, “when”, “after” : sequential or temporal

 Predicate of the sentence does not contain a specific

object. Eg.“edit all data” : logical cohesion

 “initialize” or “cleanup” : temporal cohesion

We aim to create systems out of highly cohesive,
loosely coupled components…
Design Notations

A designer needs to record his

thoughts and decisions and to
represent the design so that he can
view it and play it.
Notations are graphical
Structure charts
UML
 Structure Charts
 A structure chart is a graphical representation of a system's structure;
in particular, its modules and their interconnections

 Each module is represented by a box

 If A uses B, then an arrow is drawn from A to B

 B is called the subordinate of A
 A is called the superordinate of B

 An arrow is labeled with the parameters received by B as input and

the parameters returned by B as output
 Arrows indicate the direction in which parameters flow
 Parameters can be data (shown as unfilled circles at the tail of a
label) or control information (filled circles at the tail)
The structure chart of the sort program
Supports Iteration and Branching
 Types of Modules
 Input: A module that only produces information that is
passed to its superordinate
 Output: A module that only receives information from
its superordinate for output to a device
 Transform: A module that converts data from one
format into another format, possibly generating entirely
new information.
 Coordinator: A module that manages the flow of data
to and from different subordinates
 Composite: Modules that combine one or more of the
above styles are composite modules
Different types…
Features…
 A structure chart is as nice representation
mechanism for a design that uses functional
abstraction
 It shows the modules, and their call hierarchy,
the interfaces between the modules, and what
information passes between modules
 It is convenient and compact notations
 But, it is not very useful for representing the final
design.
 It is generally not used to convey design to the
implementer
 Design specification
 A designer must also create a textual specification for
each module that appears in the system's structure

 Design specification contains

1. Problem Specification
2. Major Data Structures
3. Modules and their Specifications
4. Design Decisions
…contd

 Problem specification: the SRS specifies

the problem in the terminology of the
problem domain. It is restated for design
purpose
 Major Data structures: major data
structures for the solution domain are
identified
 Module specification : all the modules in
the system should be identified. To
specify a module, the design document
must specify:
…contd
The interface of the module (all data
items, their types, and whether they are
input and/or output)
The Abstract behavior of the module
(what the module does)
All other modules used by the module
being specified
 Design decisions : all major decisions taken
during the design process. The choices that
were available and the reason for making a
particular choices should be explained
 Structured Design Methodology

The structured design methodology (SDM)

views a system as a transformation function that
transforms specified inputs into specified outputs.
 Factoring
 A key concept of SDM is factoring

 Factoring is the process of decomposing a module

so that the bulk of its work is done by its
subordinates
 A system is said to be completely factored if all the
actual processing is done by bottom-level atomic
modules

 SDM attempts to achieve a structure that is close to

being completely factored
 SDM Strategy
 The overall strategy of SDM is to identify the input and output streams of
the system and the primary transformations that have to be performed to
produce the output

 High-level modules are then created to perform these major activities,

which are later refined (factored)

 There are four major steps in applying this strategy

 Restate the problem as a data flow diagram
 Identify the input and output data elements
 Perform first-level factoring
 Perform additional factoring on input, output and transform branches
created in the previous step
 Step 1: Restate the problem as a
data flow diagram
 DFD represents how the data will flow in the system
when it is built.

 Data flow diagrams during design are focused on the

solution domain
What are the inputs and outputs of our system (as
opposed to the inputs and outputs of the problem
domain)?
What are the central transformations?
Example 1: DFD for an ATM

Back
Example 2: DFD for a word-counting
program

Back
 Step 2: Identify the input and
output data elements
 What we are looking for is the most abstract input elements (MAI)
and the most abstract output elements (MAO)

 The MAI elements are found by going as far as possible from

physical inputs without losing the incoming nature of the data
element

 The MAO elements are found by identifying the data elements

most removed from the physical outputs without losing the
outgoing nature of the data element

Figure1 Figure2
 Step 3: First-Level Factoring
 First-level factoring is the first step towards converting the DFD into
a structure chart

 You start by creating a module that represents the software system

(the main module)
 The main module acts as a coordinator module

 For each MAI data element, specify a subordinate input module that
delivers these items to the main module

 For each MAO data element, specify an output module

 For each central transform, specify a subordinate transform module

 The inputs and outputs of these transform modules are specified in
the DFD
Example 1: First-Level Factoring of
word-counting example
Example 2: First-Level Factoring of ATM
example
 Step 4: Perform Additional Factoring

 Now stepwise refinement is used to specify the sub-

modules required to realize the functionality of the
modules created in the previous step

 For each input module:

assume that it is in the main module
add input modules that takes its MAI data element
closer to the raw input
add transform modules in order to transform the raw
input into the desired MAI data element
Example: additional factoring of the word
count program
 Contd…

Output modules are treated in a similar fashion,

this time working from MAO data elements to
the raw output of the system

Central transforms are also factored in a

stepwise manner until you have specified
atomic modules that can be implemented
directly
Example: additional factoring of the
word count program
 SDM Wrap-Up

Each new module produced in step 4 can then

be examined to see if additional factoring is
necessary
 Design Heuristics
 The strategy requires the designer to exercise sound judgment
and common sense
 The basic objective is to make the program structure reflect the
problem as closely as possible
 Module Size is often considered an indication of module
complexity
 Cohesion and coupling should be the primary guiding factors
 A module should not be split or combined with another module
if it is subordinate to many different modules
 As a rule of thumb, the designer should check the modules that
will be larger than about 100 lines of source code or will be less
than a couple of lines
 ...contd

 Another parameter that can be considered–Fan- in and Fan-out

 Fan-in of a module is the number of arrows coming in the
module, indicating the number of superiordinates of a module
 Fan-out of a module is the number of arrows going out of that
module, indicating the number of subordinates of the module
 A very high fan-out (above 5 or 6)is not very desirable (control
and coordinate more modules)
 Fan-in should be maximized, but not at the cost of increasing
coupling or decreasing cohesion
 …contd
 Another important factor is the correlation of the scope of
effect and scope of control
 The scope of effect of a decision is the collection of all
the modules that contain any processing that is
conditional on that decision or whose invocation is
dependent on the outcome of the decision
 The scope of control of a module is the module itself and
all its subordinates
 Scope of effect of a decision should be subset of the
scope of control.
 Verification

 Designs should be checked for internal consistency and

for completeness with respect to the SRS

 If a formal design notation is used, then tools may be

able to perform some of these checks (Automated
Cross Checking)

 Otherwise, design reviews (as part of your inspection

process) are required to ensure that the finished design is
of high quality
 Design Reviews
 To ensure “quality” of the design

 Aim of design reviews – detecting errors in design

 Review team – a member of both the system design team and

the detailed design team, the author of the requirements
document, the author responsible for maintaining the design
document, and an independent software quality engineer.
 Metrics

 To provide quantitative data to the management process

 Cost and schedule metrics are needed for tracking the

progress of the project

 Size is always a product metric of interest

 Size: Number of Modules x Average LOC expected per

module
Or you can generate LOC estimates for each individual
module
 Metrics

 Quality metrics
Simplicity – most important design quality attribute

 Complexity metrics
Network Metrics
Stability Metrics
Information Flow Metrics
 Network Metrics
 Network metrics focus on the structure chart of a system

 They attempt to define how “good” the structure or network is in

an effort to quantify the complexity of the call graph

 The simplest structure occurs if the call graph is a tree.

As a result, the graph impurity (deviation of the tree) is
defined as nodes - edges - 1
In the case of a tree, this metric produces the result zero
since there is always one more node in a tree than edges
This metric is designed to make you examine nodes that
have high coupling and see if there are ways to reduce this
coupling
 Stability Metrics

 Stability of a design is a metric that tries to quantify the

resistance of a design to the potential ripple effects that
are caused by changes in modules

 The creators of this metric argue that the higher the stability
of a design, the easier it is to maintain the resulting system

 This provides a stability value for each particular module

 In essence, the lower the amount of coupling between

modules, the higher the stability of the overall system
 …Contd

 The module that can be affected by change in

a module are the modules that invoke the
module or share global data with the module
 At design time only the interfaces of modules
are known, and hence, for calculating design
stability only the assumptions made about the
interfaces need to be considered
 The potential ripple effect is defined as total
number of assumptions made by other
modules regarding the module being changed
 …contd
 For minimal entity at least two categories of assumptions can be made-

 About the type of the entity

 About the value of the entity
 The steps for determining the stability of a module X and the stability of
the program are as follows:
 Step 1: Analyze the module x and all the modules that call x or share
some file or data structure with x , obtain the following sets
• Jx = { modules that invoke x}
• J`x = { modules invoked by another module y}
• Rxy = { passed parameters returned from x to y, y ϵ Jx}
• R`xy = {parameters passed from x to y, y ϵ J`x}
• G Rx = {Global data referenced in x}
• G Dx= {Global data defined in x}
• Gi= { x | i ϵ G Rx U G Dx}
 …contd
 Step 2 : For each module x, determine the number of
assumptions made by a caller module y about elements in
Rxy through these steps.
1. Initialize assumption count to 0.
2. If i is a structured data element, decompose it into
base types, and increment the assumption count by 1;
else consider I minimal
3. Decompose base types, and if they are structured,
increment the count by 1.
4. For each minimal entity I, if module y makes some
assumption about the values of I, increment the count
by 2; else increment by 1.
 Let T Pxy represent the total number of assumptions
made by module y about parameters in Rxy
 ..contd
 Step 3 : Determine T P`xy, the total number of
assumptions made by a module y called by the module x
about elements in R`xy. The method for computation is
same as previous
 Step 4: For each data element i ϵ G Dx, determine the
total number assumptions made by other modules.
 Let T Gx be the total number of assumptions made by
other modules about the elements in G Dx
 Step 5 : For module x, the design logical ripple effect
(DLRE) is defined as :
DLREx= T Gx+ Σ y ϵ Jx T Pxy + Σ y ϵ J`x T P`xy
 …contd
 DLREx is the total number of assumptions
made by other modules that interact with x
through either parameters or global data.
 The design stability (DS) of a module x is
defined as
DSx= 1 / (1+DLREx)
 Step 6 : The program design stability (PDS) is
computed as
PDS = 1 / (1 + Σx DLREx)
 Information Flow Metrics

Information flow metrics attempt to define the

complexity of a system in terms of the total
amount of information flowing through its
modules

Jalote discusses two information flow metrics

and how they can be used to classify modules
 Approach 1
 A module's complexity depends on its intramodule complexity and its
intermodule complexity

 intramodule complexity is approximated by the (estimated) size of the

module in lines of code

 intermodule complexity is determined by the total amount of information

(abstract data elements) flowing into a module (inflow) and the total
amount of information flowing out of a module (outflow)

 The module design complexity Dc is defined as

Dc = size * (inflow*outflow)2

 The term (inflow*outflow)2 refers to the total number of input and output
combinations, and this number is squared since the interconnections
between modules are considered more important to determining the
complexity of a module than its code size
 Approach 2
 Approach 1 depends largely on the amount of information flowing in and
out of the module

 Approach 2 is a variant that also considers the number of modules

connected to a particular module; in addition, the code size of a module
is considered insignificant with respect to a module's complexity

 The module design complexity Dc is defined as

Dc = (fan_in * fan_out) + (inflow*outflow)

 fan_in above refers to the number of modules that call this module,
fan_out is the number of modules called by this module
 Classification
 Neither of these metrics is any good, unless they can tell us when to
consider a module “too complex”
 To this end, an approach was developed to compare a module's
complexity against the complexity of the other modules in its system
 avg_complexity is defined as the average complexity of the modules
in the current design
 std_deviation is defined as the standard deviation in the design
complexity of the modules in the current design
 A module can be classified as error prone, complex, or normal using
the following conditions
Dc is the complexity of a particular module
A module is error prone if Dc > avg_complexity +
std_deviation
A module is complex if avg_complexity < Dc <
avg_complexity + std_deviation