Structured Design
Design Quality – Simplicity
“There are two ways of constructing a software design: One
is to make it so simple that there are obviously no
deficiencies, and the other is to make it so complex that
there are no obvious deficiencies. The first method is far
more difficult.”
-- C. A. R. Hoare
2
Good Designs . . .
• Are modular, reflecting a clear logical problem
decomposition
• Are flexible, making them easier to maintain
• Employ modules with coherence and sharp focus
• Employ loose coupling between modules
• Employ simple module interfaces
• Allow for reusability (leveraging)
• Employ encapsulation (logical data
independence)
3
Aspects of Structured Design
• Combined with Structured Analysis, it allows the form of the
problem to guide the form of the solution
• Manages complexity by partitioning the system design and
employing hierarchies
• Uses graphical tools (structure charts)
• Includes strategies for developing a design from analysis
• Offers a set of criteria for evaluating the quality of a design
4
Structured Application Development
•
•
•
•
Top-down approach
Partitioning
Modular design
Must proceed carefully, with constant
input from programmers and IT
management to achieve a sound, wellintegrated structure
• Must ensure that integration capability is
built into each design and thoroughly
tested
Process Decomposition
Decomposition – the act of breaking a system into
sub-components. Each level of abstraction reveals
more or less detail.
9-6
Decomposition Diagrams
Decomposition
diagram – a tool
used to depict the
decomposition of a
system. Also called
hierarchy chart.
9-7
Structured Application Development
• Structure Charts
– Structure charts show the program modules and
the relationships among them
– Control module
– Subordinate modules
Structured Application Development
• Structure Charts
– Condition
• A condition line indicates that a control module
determines which subordinate modules will be invoked,
depending on a specific condition
– Loop
• A loop indicates that one or more modules are
repeated
Structured Application Development
• Structure Chart Examples
Structured Application Development
• Drawing a Structure Chart
– Step 1: Review the DFDs
– Step 2: Identify Modules and Relationships
– Step 3: Add Couples, Loops, and Conditions
– Step 4: Analyze the Structure Chart and the
Data Dictionary
Documenting Module Specifications
12
Criteria to Evaluate a Design
•
•
•
•
Coupling
Cohesion
Factoring
Decision-Splitting
Why do we bother?
The issue is always maintenance!
13
Structured Application Development
• Cohesion and Coupling
– If you need to make a module more
cohesive, you can split it into separate units,
each of which performs a single function
– Loosely coupled
– Tightly coupled
– Status flag
Flags and Data in Structure Charts
• Sometimes we need to communicate information
beyond data
• Flags can be used to communicate control issues
• To distinguish the two different kinds of parameters, the
symbol is used for data and the symbol
is used for
flags in structure charts
Control Couple
Flag
A module uses a flag to signal a specific condition
or action to another module
15
Coupling
• Coupling refers to the degree of interdependence
between/among modules
• The objective is to minimize coupling and make modules as
independent as possible
16
Advantages of Low (Loose) Coupling
• Fewer connections between modules means less chance for
a ripple error effect
• We want to be able to change one module with minimum
effect on another
• Maintenance will be made easier if we can focus on only
one module at a time – the black box philosophy
17
Types of Coupling
•
•
•
•
Data coupling
Stamp coupling
Control coupling
Common( Module
refers to the same
global data area)
• Content (module refers
to inside of another
module (really bad))
Good, or Loose
Less Desirable, or Tight
(harder to maintain)
18
Example of Data Coupling
• Two modules are data coupled if they communicate explicitly
via parameters
• This is normal and desirable, provided the parameters have
been well thought through
format customer
record
coupled
through
parameters
acct_num
cust_name
get customer
name
...
19
Example of Stamp Coupling
• Two modules are stamp coupled if they refer to the same
data structure.
• This is done often for convenience, but it does present some
potential dangers:
– It exposes a module to more data than it needs
– Can create dependencies between otherwise unrelated modules
generate car rental bill
customer
rental
record
basic
rental
charge
calculate basic
charge
mileage
charge
customer
rental
record
compute mileage
charge
stamp coupled
via a record
20
Example of Control Coupling
• Two modules are control coupled if one passes information
(often a flag) to the other that is intended to control the
internal logic of the other
• Can indicate poor delegation of tasks/authority
generate car rental bill
compute discount
customer rental
record
basic
rental
charge
calculate basic
Charge and Discount
prescriptive flag
for this module
Rules for discount
eligibility and algorithm for
discount calculation seem
to be divided between the
two modules. Could be a
maintenance headache
when eligibility rules
and/or calculation
algorithm change.
Flags should be descriptive – not prescriptive.
21
Cohesion
• Cohesion refers to the degree to which a module has a
clear function and focus
• The objective is to maximize the cohesion of modules
Advantages of Strong Cohesion
• The more focused a module, the less likely that it will be
interdependent with other modules
• Maintenance is easier if the purpose of modules is clear
cut and singular (black box design)
23
Levels of Cohesion
•
•
•
•
•
•
Functional cohesion
Sequential cohesion
Communicational cohesion
Temporal cohesion
Logical cohesion
Coincidental
Best (pure black box)
Increasing harder to maintain
24
Functional Cohesion
• A functionally cohesive module focuses on one clearly
defined problem or task
• Note that details of this task may require calls to other
modules, so we are not talking about just the size of a task,
but rather its focus
Three examples of functionally cohesive modules:
Read customer record
Calculate basic rental charge
Compute federal tax deduction
25
Sequential Cohesion
• A sequentially cohesive module has functions that operate in
sequence, with results from one function acting as input for
the next
• Can sometimes be factored into several functionally cohesive
modules – example later
Example:
Validate account number and use it to find customer name
26
Communicational Cohesion
• A communicationally cohesive module operates on
common input data
• Individual tasks may not be tightly related – only by the fact
that they operate on the same data
• Could be factored (separated) if this is deemed desirable
Example:
Compute maximum and average regional sales
Both calculations would operate on the same data set
27
Temporal Cohesion
• A temporally cohesive module has activities related by time
• These occur because it is tempting to group activities that
occur at initialization or end-of-task, etc.
• Could be a problem for maintenance. May be wise to
separate.
Two examples:
Initialize all records and tables
Perform all end of job activities (write logs, close files, rewind tapes)
28
Logical Cohesion
• A logically cohesive module has activities that are of the
same general category (i/o for example)
• At a given call, the activity appropriate to the task at hand
might be chosen (perhaps by a flag)
• Again, can be an issue for maintenance. Such modules can be
very useful, but they must be designed carefully.
Two examples:
Collect any required input (probably need a flag to operate)
Compute selected statistics for data (again, need a flag)
29