Upload
triston-keigher
View
213
Download
0
Tags:
Embed Size (px)
Citation preview
Structured Design
2
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
3
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)
4
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
Structured Application Development
• Top-down approach • Partitioning• Modular design• Must proceed carefully, with constant
input from programmers and IT management to achieve a sound, well-integrated structure
• Must ensure that integration capability is built into each design and thoroughly tested
9-6
Process DecompositionDecomposition – the act of breaking a system into sub-components. Each level of abstraction reveals more or less detail.
9-7
Decomposition Diagrams
Decomposition diagram – a tool used to depict the decomposition of a system. Also called hierarchy chart.
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
12
Documenting Module Specifications
13
Criteria to Evaluate a Design• Coupling• Cohesion• Factoring• Decision-Splitting
Why do we bother?
The issue is always maintenance!
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
15
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 CoupleFlagA module uses a flag to signal a specific condition or action to another module
16
Coupling• Coupling refers to the degree of interdependence
between/among modules• The objective is to minimize coupling and make modules as
independent as possible
17
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
18
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)
19
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
get customername
acct_numcust_name
. . .
coupled through
parameters
20
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
calculate basiccharge
customer rentalrecord
basic rental
charge
compute mileagecharge
customer rentalrecordmileage
charge
stamp coupledvia a record
21
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
calculate basicCharge and Discount
customer rentalrecord
basic rental
charge
compute discount
prescriptive flagfor 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.
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
23
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)
24
Levels of Cohesion
• Functional cohesion• Sequential cohesion• Communicational cohesion• Temporal cohesion• Logical cohesion• Coincidental
Best (pure black box)
Increasing harder to maintain
25
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
26
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
27
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
28
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)
29
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)