CSE3308/DMS/2005/14
Monash University - School of Computer
Science and Software Engineering
Software Engineering: Analysis and
Design - CSE3308
Structured Design
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 5A.1
Lecture Outline
 The
Structure Chart
 Qualities of Good Design





Coupling
Cohesion
Factoring
Fan-out
Fan-in
 Transform
Analysis
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 5A.2
The Structure Chart - 1
 Principal
tool of Structured Design
 Based on dividing a system into modules à la
Structured Programming and then mapping the
connections between the modules
 Structured Design is only concerned with the
outside view of the module
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 5A.3
The Structure Chart - 2
A
module is defined as a collection of program
statements with four attributes:




input and output - what the module gets from its invoker and
what the invoker receives from the module
function - what it does to its input to produce its output
mechanics - the code or logic by which it carries out its
function
internal data - its own private workspace, data to which it alone
refers
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 5A.4
Connections between modules
A
connection indicates that one module calls
another module
A
B
Calling Module
Get
Customer
Details
Called Module
Find
Customer
Name
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 5A.5
Showing Data and Information
 Need
to show the movement of data and the
movement of information about data (flags)
Get
Customer
Details
Flag going from caller to called
Customer
Name
Customer
Account
Number
Data going from caller to called
Flag going from called to caller
Account
Number is OK
Find
Customer
Name
CSE3308 - Software Engineering: Analysis and Design, 2005
Data going from called to caller
Lecture 5A.6
Difference between Data and Flags
 Data
A
is processed, flags are not
flag is typically set and tested
 Data
relates to the problem
 Flags
communicate information about the
data
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 5A.7
Iteration and Decision on a
Structure Chart
Symbol for showing
decisions
Issue pay
cheques
for all
employees
Get Employee
Pay Record
Calculate Pay
for Casual
Worker
CSE3308 - Software Engineering: Analysis and Design, 2005
Symbol for showing
iteration
Calculate Pay
for Salaried
Worker
Print Pay
Cheque
Lecture 5A.8
Example Structure Chart
Total for One
Customer
Total for All
Customers
Total for One
Customer
EOTP
GET TOTAL
PAYMENT FOR
ONE
CUSTOMER
Valid Customer Record
SUMMARIZE
PAYMENTS FOR
ALL
CUSTOMERS
PUT
CUSTOMER
TOTAL
PUT FINAL
TOTAL
EOVCR
Final Total
Line
Customer
Total Line
GET VALID
CUSTOMER
RECORD
Field Valid
Customer Record
PRINT
Field
READ
EDIT FIELD
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 5A.9
Coupling
 Coupling
indicates the degree of
interdependence between two modules
 Aim for low coupling by



eliminating unnecessary relationships
reducing the number of necessary relationships
easing the “tightness” of necessary relationships
 Example

of low coupling:
Stereo System
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 5A.10
Advantages of Loose Coupling
 The
fewer connections between modules, the
less chance of a defect in one causing a
defect in another
 The risk of having to change other modules
as a result of changing one module is
reduced
 The need to know about the internals of other
modules is reduced when maintaining the
details of other modules.
 But of course we have to have some
coupling!
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 5A.11
Principles of Coupling
 Narrow
is better than Broad
 Direct
is better than Indirect
 Local
is better than Remote
 Obvious
 Flexible
is better than Obscure
is better than Rigid
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 5A.12
Types of Coupling
 Data
Coupling
 Stamp Coupling
 Control Coupling
Coupling
 Content Coupling
 Hybrid Coupling
Good Coupling
 Common
Bad Coupling
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 5A.13
Data Coupling
 Two
modules are data
coupled if they communicate
via parameters, each
parameter being an
elementary piece of data
 Data coupling is necessary
in a program and is harmless
if kept to a minimum
 Avoid tramp data that moves
around the structure chart
aimlessly – it creates
unnecessary and
unpredictable dependencies,
making maintenance harder.
CSE3308 - Software Engineering: Analysis and Design, 2005
Assess
House
Affordability
Term
Interest rate
Repayment
rate
Sum borrowed
Calculate
Mortgage
Repayment
Lecture 5A.14
Update
Customer
Master File
Put Customer
Master
M
R e a st e
co r
rd
M
R e a st e
co r
rd T
ra
n
sa
ct
n
io
ct
sa lid
an Va
Tr Is
io
n
Update Master
Tr
an
sa
ct
io
n
 Where is it read?
 Where is it
actually needed?
 How would you
change the
structure chart to
fix this problem?
Get Valid Input
da
t
R e ed M
co a
r d st e
r
r
Look at the
datacouple
“Master Record”
Master
Rec ord

Up
d Maste
Update rd
R ec o
n
lid tio
Va s a c
an
Tr
Valid
Transaction
Tramp Data
Example
Get Input
Tr
Ma
s
R ec ter
or d
Validate
Customer
Transaction
an
sa
c ti
on
Ac
Nu coun
mb t
er
Get Customer
Transaction
CSE3308 - Software Engineering: Analysis and Design, 2005
Get Customer
Master
Lecture 5A.15
Stamp Coupling
 Stamp
coupling is where one module passes
to another a composite piece of data, i.e. a
piece of data with meaningful internal
structure
 Stamp coupling results in some indirectness,
therefore not as desirable, but okay if the
composite is natural to the application
 Never pass composite data when only part of
the data is required
 Never bundle data into an artificial composite
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 5A.16
Stamp Coupling Examples
Bad
Good
Generate
Customer
Rental Bill
Play
Chess
Move
New
Chess
Board
Chess
Board
Customer
Rental
Record
Make
Move
CSE3308 - Software Engineering: Analysis and Design, 2005
Customer
Basic Rental
Rental Record
Charge
Calculate
Basic
Rental
Charge
Gasoline
Charge
Calculate
Gasoline
Charge
Lecture 5A.17
Bundling
Number of items
Price per item
Sales tax
Total cost
Purchase data
Total cost
Discount type
Calculate
Total
Purchase
Cost
CSE3308 - Software Engineering: Analysis and Design, 2005
Calculate
Total
Purchase
Cost
Lecture 5A.18
Control Coupling
 Control
coupling is when one
module passes to another a
piece of information intended
to control the internal logic of
the other
 Generally not a good thing!


Poor partitioning
Inversion of authority
 However
flags which are
descriptive can be fine


Match
Customer
Records
Master
Record
What
to do
flag
Transaction
Record
System
I/O
Control
Account Number is invalid
End of file has been reached
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 5A.19
Summary of Acceptable Coupling
Type
of
Information
Data
Descriptive
Control
Depicted
By
Type
of
Name
Noun
Examples
Price of eggs
Age
Postcode
Adjective Egg is rotten
Postcode is numeric
End of file reached
Read next record
Verb
Reject this customer
Rewind master file
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 5A.20
Coupling Evils - Common
Coupling
 Two
modules are common coupled if they
both refer to the same global data area






defect in a common coupled module may show up
anywhere
common coupling is usually by a specific name, therefore
reduces flexibility
remoteness in time between the coupling
easy to abuse by using the same data item for different
meanings in different modules
very hard to maintain and understand due to difficulty in
working out the actual coupling
difficult to work out what modules must be changed if
data is changed and vice versa
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 5A.21
Coupling Evils - Content Coupling
and Hybrid Coupling
 Content
coupling is where one module refers
to the inside of another in any way


one module changes the data inside another
one module alters a statement in another
 Defies
the principle of modularity
 Hybrid coupling is where different meanings
are assigned to different parts of a range of
data, it is both a data flag and a control flag
simultaneously
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 5A.22
Hybrid Coupling Example
Account numbers for a mail order business
Special 90XXX Range
means mail literature
to whole region represented
by last three digits
91000
00001
99999
91999
Account
Number
90000
90999
Normal Range
Special 91XXX Range
means Extra Credit Period
What happens when the business acquires customer 90000, and
the system tries to send a bill to him or her?
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 5A.23
Impact of coupling
Coupling Type Susceptibility to
ripple effect
Variable*
Data
Good
Understandability Module’s
reusability
Good
Good
Modifiability
Tramp
Poor
Medium
Medium
Poor
Stamp
Variable*
Medium
Medium
Medium
Bundling
Variable*
Medium
Poor
Poor
Control
Medium
Poor***
Poor***
Poor***
Hybrid
Medium**
Bad
Bad
Bad
Common
Bad
Medium
Bad
Poor
Content
Bad
Bad
Bad
Bad
* Depends on the breadth (the number of individual items) of the interface
** If the convention used in the hybrid data has to be changed, ripple effect can be devastating
*** poor mainly because of problems in interface and cohesion of one of the modules
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 5A.24
Cohesion
 Is
the measure of the strength of functional
relatedness of elements within a module
 “Element” means
 an instruction
 a group of instructions
 a data definition
 a call to another module
 i.e.
any piece of code that accomplishes some
work or defines some data
 We want strong cohesion: modules whose
elements are functionally related
 Measure of how well we have partitioned the
system
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 5A.25
Types of Cohesion
Maintainability

Functional

Black Box

Sequential

Not quite as Black Box

Communicational

Not quite as Black Box

Procedural

Grey Box

Temporal

Grey Box

Logical

White Box

Coincidental

White Box
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 5A.26
Functional Cohesion
 Where
a module contains elements that all
contribute to the execution of one and only
one problem related task
 Examples
 Compute Cosine of Angle
 Read Transaction Record
 Calculate Net Salary
 Assign Seat to Airline Customer
 Best
type of cohesion, but not all modules
can be defined as performing one function
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 5A.27
Sequential Cohesion
 Where
a module has elements which are
involved in activities such that output data
from one activity serves as input data to the
next
Formatted
 Example
Raw Record
Cross-Validated
Record
 Usually has good coupling
 Easily maintained
Format and CrossValidate Record
 Not as reusable
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 5A.28
Communicational Cohesion
 Where
a module has elements that contribute
to activities that use the same input or output
data
module determine customer details
 Example
use customer account number
find customer name
find customer loan balance
return customer name, customer loan balance
endmodule
 Are
quite maintainable but problems include
 Unnecessary data when reusing
 Temptation to share code among the activities in the
modules making it difficult to change one and not the
other
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 5A.29
Employee
Salary
Table
Problem with Communicational
Cohesion
Average Salary
Produce Employee
Salary Report
and Calculate
Average Salary
Employee
Salary
Report
Details
Customer
Account
Number
Customer
Name
Customer
Account
Number
Find
Customer
Name
Customer
Loan
Balance
AND
Determine
Customer
Details
should
become
Write
CSE3308 - Software Engineering: Analysis and Design, 2005
Customer
Name
Customer
Account
Number
Customer
Loan
Balance
Calculate
Customer
Loan Balance
Lecture 5A.30
Procedural Cohesion
 Where
a module has elements that are involved
in different and possible unrelated activities in
which control flows from one activity to the next
Table A
 Example:
Average
 Procedure
is the same for the
different data
 Data is unrelated
 Maintenance can become very
complex - i.e. what happens if
size of one table changes?
CSE3308 - Software Engineering: Analysis and Design, 2005
Table A
Table B
Average
Table B
Compute Table A
Average and Table B
Average
Lecture 5A.31
Temporal Cohesion
 Where
a module has elements which are
involved in activities that are related in time
 Example - Get Ready for Bed Module
 Put out garbage can
 Put out cat
 Turn off TV
 Brush teeth
 Activities
are unrelated except for being
carried out at a particular time.
 Classic example is an Initialisation module
 Does not lead to good maintainability
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 5A.32
Logical Cohesion
 Where
a module has elements which
contribute to activities of the same general
category in which the activity or activities to
be executed are selected from outside the
module
Destination
 Example
module travel to new destination
uses destination, travel type flag
if travel type flag = BUS
go destination by BUS
if travel type flag = TRAIN
go destination by TRAIN
if travel type flag = CAR
go destination by CAR
return arrival flag
endmodule
CSE3308 - Software Engineering: Analysis and Design, 2005
Travel Type
Flag
Arrival Flag
Travel to New
Destination
Lecture 5A.33
Problems with Logical Cohesion
 Code
of different activities is knotted together
 Example
All the records have different character lengths
when INPUT-FLAG = 1
RECORD-A is written to NEW MASTER FILE
RECORD-B is set to next TRAN FILE1 record
RECORD-C is undefined
when INPUT-FLAG = 2
RECORD-A is used as an auxiliary input flag
RECORD-B is set to next TRAN FILE1 record (only if RECORD-A set to SPACES;
otherwise undefined
RECORD-C is set to the next TRAN FILE2 record
when INPUT-FLAG = 3
RECORD-A is set to the next MASTER FILE2 record
RECORD-B is set to next TRAN FILE1 record
RECORD-C is set to the next MASTER FILE2 record
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 5A.34
Coincidental Cohesion
 Where
the elements of a module have no
meaningful relationship to each other
 Elements are not related by flow of data or
flow of control
Account
Transaction Record
Matnum
Account
Operator Message
Error Flag
Func flag
Miscellaneous
Functions
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 5A.35
Impact of
cohesion
types
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 5A.36
Consequences of Cohesion types
Cohesion
Level
Coupling
Cleaness of
Implementation
Modifiability
Understanda
bility
Effect on
maintenance
Functional
Good
Good
Good
Good
Good
Sequential
Good
Good
Good
Good
Fairly God
Communcational
Medium
Medium
Medium
Medium
Medium
Procedural
Variable
Poor
Variable
Variable
Bad
Temporal
Poor
Medium
Medium
Medium
Bad
Logical
Bad
Bad
Bad
Poor
Bad
Coincidental
Bad
Poor
Bad
Bad
Bad
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 5A.37
Factoring
 The
separation of a function contained as
code into a new module of its own
 Reasons
 to reduce module size
 to aid in the understanding of the system and to make
modifications more localised
 to avoid duplication of a function in more than one
module
 to separate work (calculating and editing) from
management (calling and deciding)
 to provide more reusable modules
 to simplify implementation
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 5A.38
Fan-Out and Fan-In
 Fan-out:
the number of immediate
subordinates to a module
 limit fan-out to no more than seven
 Fan-in:
the number of immediate bosses that
a module has
 Is a good thing - indicates reuse
 Modules with fan-in must have good cohesion, preferably
functional
 each interface to the module must have the same number
and types of parameters
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 5A.39
Transform Analysis
A
method for converting DFDs into Structure
chart
 Analyse the DFDs in terms of transactions
 For each transaction, identify the central DFD process
(called the central transform)
» The central transform is the portion of the DFD that
contains the essential functions of the system and is
independent of the implementation of the input and
output
 Make the central transform the top level module in
structure chart
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 5A.40
References
 Page-Jones,
Meilir, The Practical Guide to
Structured Systems Design (2nd Ed.),
Prentice-Hall, Englewood Cliffs, N.J., 1988.
(Chapters 3, 5, 6)
 Note that Ch. 6 is available online at
http://www.waysys.com/ws_content_bl_pgssd_ch06.html
(see link on unit resources page)
CSE3308 - Software Engineering: Analysis and Design, 2005
Lecture 5A.41