Software Design - II

1
 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.
 Coupling
• There are no ways to precisely measure coupling between
two modules:
– classification of different types of coupling will help us to
approximately estimate the degree of coupling between two
modules.
• Five types of coupling can exist between any two modules.
 Classes of coupling

data
stamp
control Degree of
coupling
common
content
 Data coupling
• Two modules are data coupled,
– if they communicate via a parameter:
• an elementary data item,
• e.g an integer, a float, a character, etc.
– The data item should be problem related:
• not used for control purpose.
 Stamp coupling
• Two modules are stamp coupled,
– if they communicate via a composite data item
• or an array or structure in C.
 Control coupling
• Data from one module is used to direct
– 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:
– if they share code,
– e.g, branching from one module into another module.
• The degree of coupling increases
– from data coupling to content coupling.
 Hierarchical Design
• Control hierarchy represents:
– organization of modules.
– control hierarchy is also called program structure.
• Most common notation:
– a tree-like diagram called structure chart.
 Good Hierachical Arrangement of modules

• Essentially means:
– low fan-out
– abstraction
 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.
 Characteristics of Module Structure
• Fan-in:
– indicates how many modules directly
invoke a given module.
– High fan-in represents code reuse and is
in general encouraged.
Module Structure
Fan
out=2

Fan
out=1
Fan in=1

Fan in=2
Fan
out=0
 Goodness of Design
• A design having modules:
– with high fan-out numbers
is not a good design.
– a module having high fan-out lacks cohesion.
 Large Fan Out
• A module that invokes a large
number of other modules:
– likely to implement several different functions:
– not likely to perform a single cohesive function.
 Control Relationships
• A module that controls another module:

– said to be superordinate to the later module.

• Conversely, a module controlled by another module:

– said to be subordinate to the later module.

 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.
Bad Design
 Abstraction
• Lower-level modules:
– Perform input/output and other low-level
functions.
• Upper-level modules:
– Perform more managerial functions.
 Abstraction
• The principle of abstraction requires:
– lower-level modules do not invoke functions of
higher level modules.
– Also known as layered design.
High-level Design f1
f2 d1 d2
f3

• d3 d4
d1
•
•
fn
 Design Approaches
• Two fundamentally different software design
approaches:
– Function-oriented design
– Object-oriented design
 Design Approaches
• These two design approaches are radically different.
– However, are complementary
• rather than competing techniques.
– Each technique is applicable at
• different stages of the design process.
 Function-Oriented Design
• A system is looked upon as something
– that performs a set of functions.

• Starting at this high-level view of the system:

– each function is successively refined into more detailed functions
(top-down decomposition).
– Functions are mapped to a module structure.
 Example
• The function create-new-library- member:

– creates the record for a new member,

– assigns a unique membership number

– prints a bill towards the membership

 Function-Oriented Design
• The system state is centralized:
– accessible to different functions,
– member-records:
• available for reference and updation to several functions:
– create-new-member
– delete-member
– update-member-record
 Function-Oriented Design
• Several function-oriented design approaches have been
developed:
– Structured design (Constantine and Yourdon, 1979)
– Jackson's structured design (Jackson, 1975)
– Warnier-Orr methodology
– Wirth's step-wise refinement
– Hatley and Pirbhai's Methodology
 Example
• Create-library-member function consists of the following
sub-functions:
– assign-membership-number
– create-member-record
– print-bill
• Split these into further subfunctions, etc.
 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 state information.
 Object-Oriented Design Example
• Library Automation Software:
– 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:
– defines their state.
• Similar objects constitute a class.
– each object is a member of some class.
• Classes may inherit features
– from a super class.
• Conceptually, objects communicate by message passing.
Object-Oriented versus Function-Oriented Design
• Unlike function-oriented design,
– in OOD the basic abstraction is not functions such
as “sort”, “display”, “track”, etc.,
– but real-world entities such as “employee”,
“picture”, “machine”, “radar system”, etc.
 Object-Oriented versus Function-Oriented Design
• In OOD:
– software is not developed by designing functions such as:
• update-employee-record,
• get-employee-address, etc.
– but by designing objects such as:
• employees,
• departments, etc.
Object-Oriented versus Function-Oriented Design

• Grady Booch sums up this fundamental

difference saying:
– “Identify verbs if you are after procedural design
and nouns if you are after object-oriented design.”
Object-Oriented versus Function-Oriented Design

• In OOD:
– state information is not shared in a centralized data.
– but is distributed among the objects of the system.
 Example
• In an employee pay-roll system, the following can be global
data:
– names of the employees,
– their code numbers,
– basic salaries, etc.
• In contrast, in object oriented systems:
– data is distributed among different employee objects of the
system.
 Object-Oriented versus Function-Oriented Design

• Objects communicate by message passing.

– one object may discover the state information of another
object by interrogating it.
 Object-Oriented versus Function-Oriented Design

• Of course, somewhere or other the functions must be

implemented:
– the functions are usually associated with specific real-
world entities (objects)
– directly access only part of the system state information.
 Object-Oriented versus Function-Oriented Design
• Function-oriented techniques group functions together if:
– as a group, they constitute a higher level function.
• On the other hand, object-oriented techniques group
functions together:
– on the basis of the data they operate on.
 Object-Oriented versus Function-Oriented Design

• To illustrate the differences between object-oriented

and function-oriented design approaches,
– let us consider an example ---
– An automated fire-alarm system for a large building.
 Fire-Alarm System
• We need to develop a computerized fire alarm
system for a large multi-storied building:
– There are 80 floors and 2000 rooms in
the building.
 Fire-Alarm System
• Different rooms of the building:
– fitted with smoke detectors and fire alarms.
• The fire alarm system would monitor:
– status of the smoke detectors.
 Fire-Alarm System
• Whenever a fire condition is reported by any smoke
detector:
– the fire alarm system should:
• determine the location from which the fire condition was
reported
• sound the alarms in the neighbouring locations.
 Fire-Alarm System
• The fire alarm system should:
– flash an alarm message on the computer console:
• fire fighting personnel man the console round the
clock.
 Fire-Alarm System
• After a fire condition has been successfully
handled,
– the fire alarm system should let fire fighting
personnel reset the alarms.
/* Global data (system state) accessible by various functions
*/
BOOL detector_status[2000];
int detector_locs[2000];
BOOL alarm-status[2000]; /* alarm activated when set */
int alarm_locs[2000]; /* room number where alarm is located */
int neighbor-alarms[2000][10];/*each detector has at most*/
/* 10 neighboring alarm locations */

interrogate_detectors();
get_detector_location(); Function-Oriented
determine_neighbor();
Approach
ring_alarm();
reset_alarm();
report_fire_location();
 Object-Oriented Approach:
class detector
attributes: status, location, neighbors
operations: create, sense-status, get-location, find-neighbors

class alarm
attributes: location, status
operations: create, ring-alarm, get_location, reset-alarm

– Appropriate number of instances of the class detector and alarm are created.
 Object-Oriented versus Function-Oriented Design

• In a function-oriented program :
– the system state is centralized
– several functions accessing these data are defined.
• In the object oriented program,
– the state information is distributed among various sensor
and alarm objects.
 Object-Oriented versus Function-Oriented Design

• Use OOD to design the classes:

– then applies top-down function oriented techniques
• to design the internal methods of classes.
 Object-Oriented versus Function-Oriented Design

• Though outwardly a system may appear to have been

developed in an object oriented fashion,
– but inside each class there is a small hierarchy of
functions designed in a top-down manner.
 Summary
• We started with an overview of:
– activities undertaken during the software design phase.
• We identified:
– the information need to be produced at the end of
design:
• so that the design can be easily implemented using a
programming language.
 Summary
• We characterized the features of a good software
design by introducing the concepts of:
– fan-in, fan-out,
– cohesion, coupling,
– abstraction, etc.
 Summary
• We classified different types of cohesion and
coupling:
– enables us to approximately determine the cohesion
and coupling existing in a design.
 Summary
• Two fundamentally different approaches to
software design:
– function-oriented approach
– object-oriented approach
 Summary
• We examined the essential philosophy behind these
two approaches
– these two approaches are not really competing but
complementary approaches.
Thank You!!

Faculty Name
Department Name 57