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)