Structured Design

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

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

6. Process Decomposition Decomposition – the act of breaking a system into sub-components. Each level of abstraction reveals more or less detail.

7. Decomposition Diagrams Decomposition diagram – a tool used to depict the decomposition of a system. Also called hierarchy chart.

8. Structured Application Development • Structure Charts • Structure charts show the program modules and the relationships among them • Control module • Subordinate modules

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

10. Structured Application Development • Structure Chart Examples

11. 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!

14. 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 Couple • Flag • A module uses a flag to signal a specific condition or action to another module

16. Coupling • Coupling refers to the degree ofinterdependence 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 coupled through parameters acct_num cust_name . . . get customer name

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 customer rental record customer rental record basic rental charge mileage charge calculate basic charge compute mileage charge stamp coupled via 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 compute discount basic rental charge 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. customer rental record calculate basic Charge and Discount prescriptive flagfor this module Flags should be descriptive – not prescriptive.

22. 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)