CSE3001 SOFTWARE ENGINEERING

L T P J C
2 0 2 4 4

Dr. S M SATAPATHY
Associate Professor,
School of Computer Science and Engineering,
VIT Vellore, TN, India – 632 014.
SOFTWARE
DESIGN
 Module – 4

Software Design

1. Cohesion, Coupling

2. Architectural Design

3. Detailed Design

4. Object Oriented Design

5. User Interface Design

3
INTRODUCTION

• Design phase transforms SRS document:

– into a form easily implementable in some programming language.

SRS Document Design Documents

Design Activities
INTRODUCTION

• Items designed:
– module structure,
– control relationship among the modules
• call relationship or invocation relationship
– interface among different modules,
• data items to be exchanged among different modules,
– data structures of individual modules,
– algorithms for individual modules.
INTRODUCTION
• Good software designs:
– seldom arrived through a single step procedure:
– but through a series of steps and iterations.

• Design activities are usually classified into two stages:

– preliminary (or high-level) design
– detailed design.
• Meaning and scope of the two stages:
– vary considerably from one methodology to another.
HIGH LEVEL DESIGN
• The outcome of high-level design:
– program structure (or software architecture).
• Several notations are available to represent high-level design:
– Usually a tree-like diagram called structure chart is used.
– Other notations:
• Jackson diagram or Warnier-Orr diagram can also be used.
DETAILED DESIGN
• For each module, design:
– data structure
– algorithms
• Outcome of detailed design:
– module specification.
A FUNDAMENTAL QUESTION:
• How to distinguish between good and bad designs?
– Unless we know what a good software design is:
• we can not possibly design one.

• There is no unique way to design a system.

• Even using the same design methodology:
– different engineers can arrive at very different design solutions.
• We need to distinguish between good and bad designs.
WHAT IS GOOD SOFTWARE DESIGN?
• Correctness: Should implement all functionalities of the system correctly.
• Understandability: Should be easily understandable.
• Efficiency: Should be efficient.
• Maintainability: Should be easily amenable to change,
– i.e. easily maintainable.
WHAT IS GOOD SOFTWARE DESIGN?
• Understandability of a design is a major issue:
– determines goodness of design:
– a design that is easy to understand:
• also easy to maintain and change.
• 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.
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.
MODULARITY
• Modularity is a fundamental attributes of any good design.
– Decomposition of a problem cleanly into modules:
– Modules are almost independent of each other
– divide and conquer principle.
• If modules are independent of each other:
– modules can be understood separately,
• reduces the complexity greatly.
– 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.
EXAMPLE OF CLEANLY AND NON-
CLEANLY DECOMPOSED MODULES
MODULARITY
• In technical terms, modules should display:
– high cohesion
– low coupling.
• Neat arrangement of modules in a hierarchy means:
– low fan-out
– abstraction
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.
• A module having high cohesion and low coupling:
– functionally independent of other modules:
• A functionally independent module has minimal interaction with
other modules.
ADVANTAGES OF FUNCTIONAL
INDEPENDENCE
• Functional independence is key to:
– understandability and good design:
– Complexity of design is reduced,
– different modules can be understood in isolation:
• modules are more or less independent of each other.
• 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.
ADVANTAGES OF FUNCTIONAL INDEPENDENCE

• A functionally independent module:

– can be easily taken out and reused in a different program.
• each module does some well-defined and precise function
• the interfaces of a module with other modules is simple and
minimal.
• Unfortunately, there are no ways:
– to quantitatively measure the degree of cohesion and coupling:
– classification of different kinds of cohesion and coupling:
• will give us some idea regarding the degree of cohesiveness of a
module.
COHESION
• Cohesion is a measure of the degree to which the elements of a module
are functionally related.
TYPES OF COHESION

Degree of
cohesion
COINCIDENTAL COHESION
• The module performs a set of tasks:
– which relate to each other very loosely, if at all.
• the module contains a random collection of functions.
• functions have been put in the module out of pure coincidence
without any thought or design.
• Coincidental cohesion exists in modules that contain instructions that
have little or no relationship to one another.
LOGICAL COHESION
• All elements of the module perform similar operations:
– e.g. error handling, data input, data output, etc.
• An example of logical cohesion:
– a set of print functions to generate an output report arranged into a
single module.
• Logical cohesion occurs in modules that contain instructions that appear
to be related because they fall into the same logical class of functions.
TEMPORAL COHESION
• The module contains tasks that are related by the fact:
– all the tasks must be executed in the same time span.
• Example:
– The set of functions responsible for
• initialization,
• start-up, shut-down of some process, etc.
• Module exhibits temporal cohesion when it contains tasks that
are related by the fact that all tasks must be executed in the
same time-span.
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,
• e.g. the algorithm for decoding a message.
• Procedural Cohesion occurs in modules whose instructions although
accomplish different tasks yet have been combined because there is a
specific order in which the tasks are to be completed.
COMMUNICATIONAL COHESION
• All functions of the module:
– reference or update the same data structure,
• Example:
– the set of functions defined on an array or a stack.
• X and Y both operate on the same input data or contribute towards the
same output data. But we might consider making them separate
procedures.
SEQUENTIAL COHESION
• Elements of a module form different parts of a sequence,
– output from one element of the sequence is input to the next.
– Example:
•

sort
search
display
FUNCTIONAL COHESION
• Different elements of a module cooperate:
– to achieve a single function,
– e.g. managing an employee's pay-roll.
• When a module displays functional cohesion,
– we can describe the function using a single sentence.

• The mathematical subroutine such as “calculate current GPA” or

“cumulative GPA” are typical example of functional cohesion.
DETERMINING COHESIVENESS
• Write down a sentence to describe the function of the module
– If the sentence is compound,
• it has a sequential or communicational cohesion.
– If it has words like “first”, “next”, “after”, “then”, etc.
• it has sequential or temporal cohesion.
– If it has words like initialize,
• it probably has temporal cohesion.
COUPLING
• Coupling is the measure of the degree of interdependence between
modules.
• There are no ways to precisely determine coupling between two modules:
– classification of different types of coupling will help us to
approximately estimate the degree of coupling between two modules.
•
EXAMPLE
• Consider the example of editing a student record in a “Student
Information System”.
TYPES OF COUPLING

Degree of
coupling
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.
• The dependency between module A and B is said to be data coupled if
their dependency is based on the fact they communicate by only passing of
data. Other than communicating through data, the two modules are
independent.
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.
• Stamp coupling occurs between module A and B when complete data
structure is passed from one module to another.
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.

• Module A and B are said to be control coupled if they communicate by

passing of control information. This is usually accomplished by means of
flags that are set by one module and reacted upon by the dependent
module.
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.

• Module A and B are said to be control coupled if they communicate by

passing of control information. This is usually accomplished by means of
flags that are set by one module and reacted upon by the dependent
module.
COMMON COUPLING
• Two modules are common coupled,
– if they share some global data.

• With common coupling, module A and module B have shared data. Global
data areas are commonly found in programming languages. Making a
change to the common data means tracing back to all the modules which
access that data to evaluate the effect of changes.
COMMON COUPLING
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.

• Content coupling occurs when module A changes data of module B or

when control is passed from one module to the middle of another. In Fig.
9, module B branches into D, even though D is supposed to be under the
control of C.
CONTENT COUPLING
LAYERED ARRANGEMENT OF MODULES
• Control hierarchy represents:
– organization of modules.
– control hierarchy is also called program structure.
• Most common notation:
– a tree-like diagram called structure chart.
• Neat arrangement of modules essentially means low fan-out and
abstraction.
CONCEPTS AND TERMINOLOGIES
• Superordinate and Subordinate Modules:
– A module that controls another module:
• said to be superordinate to it.
– Conversely, a module controlled by another module:
• said to be subordinate to it.
• Visibility:
– A module A is said to be visible by another module B,
• if A directly or indirectly calls B.
CONCEPTS AND TERMINOLOGIES
• Control Abstraction:
– The principle of abstraction requires:
• lower-level modules do not invoke functions of higher level
modules.
• Also known as layered design.
• Depth and Width:
– Depth:
• number of levels of control
– Width:
• overall span of control.
CONCEPTS AND TERMINOLOGIES
• Fan-out:
– a measure of the number of modules directly controlled by given
module.
– with high fan-out numbers is not a good design:
– a module having high fan-out lacks cohesion.
• Fan-in:
– indicates how many modules directly invoke a given module.
– High fan-in represents code reuse and is in general encouraged.
DESIGN APPROACHES
• Two fundamentally different software design approaches:
– Function-oriented design
– Object-oriented design
• 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.
• Top-down Decomposition:
– Starting at this high-level view of the system:
• each function is successively refined into more detailed functions.
• Functions are mapped to a module structure.
FUNCTION-ORIENTED DESIGN
• The function create-new-library- member:
– creates the record for a new member,
– assigns a unique membership number
– prints a bill towards the membership
• Create-library-member function consists of the following sub-functions:
– assign-membership-number
– create-member-record
– print-bill
• Each subfunction:
– split into more detailed subfunctions and so on.
FUNCTION-ORIENTED DESIGN
• Centralised System State:
– 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
• Centralised System State:
– 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
• A few well-established function-oriented design approaches are:
– Step-wise refinement by Wirth [1971]
– Jackson’s Structured Design by Jackson [1975]
– Warnier-orr Methodology [1977, 1981]
– Structured Design by Constantine and Yourdan [1979]
– Hatley and Pirbhai’s Methodology [1987]
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.

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

OOD VS. FOD
• 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.
• 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.
OOD VS. FOD
• 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.”

• In OOD:
– state information is not shared in a centralized data.
– but is distributed among the objects of the system.
OOD VS. FOD
• In an employee pay-roll system, the following can be global data:
– names of the employees,
– their code numbers,
– basic salaries, etc.
• Whereas, in object oriented systems:
– data is distributed among different employee objects of the system.
• Objects communicate by message passing.
– one object may discover the state information of another object by
interrogating it.
• 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.
OOD VS. FOD
• 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.

• 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.
AUTOMATED FIRE-ALARM SYSTEM

• We need to develop a computerized fire alarm system for a large multi-

storied building:
– There are 80 floors and 1000 rooms in the building.
• Different rooms of the building:
– fitted with smoke detectors and fire alarms.
• The fire alarm system would monitor:
– status of the smoke detectors.
AUTOMATED 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 neighboring locations.
• The fire alarm system should:
– flash an alarm message on the computer console:
• fire fighting personnel man the console round the clock.
• After a fire condition has been successfully handled,
– the fire alarm system should let fire fighting personnel reset the alarms
FUNCTION-ORIENTED APPROACH:
• /* Global data (system state) accessible by various functions */
BOOL detector_status[1000];
int detector_locs[1000];
BOOL alarm-status[1000]; /* alarm activated when status set */
int alarm_locs[1000]; /* room number where alarm is located */
int neighbor-alarms[1000][10]; /* each detector has at most */
/* 10 neighboring alarm locations */
The functions which operate on the system state:
interrogate_detectors();
get_detector_location();
determine_neighbor();
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
• In the object oriented program,
– appropriate number of instances of the class detector and alarm should
be created.
OOD VS. FOD
• In the 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.
• Use OOD to design the classes:
– then applies top-down function oriented techniques
• to design the internal methods of classes.
• 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.