1. CS540 Software Design Lecture 8 1 Lecture 8: Structured Design Anita S. Malik anitamalik@umt.edu.pk Adapted from Schach (2004) Chapter 13 and Appendix E

2. CS540 Software Design 2Lecture 8 Data and Actions Two aspects of a product Two aspects of a product Actions which operate on data Actions which operate on data Data on which actions operate Data on which actions operate The two basic ways of designing a product The two basic ways of designing a product Action-oriented design Action-oriented design Data-oriented design Data-oriented design Third way Third way Hybrid methods Hybrid methods For example, object-oriented design For example, object-oriented design

3. CS540 Software Design 3Lecture 8 Design Activities Architectural design Architectural design Detailed design Detailed design Design testing Design testing

4. CS540 Software Design 4Lecture 8 Architectural Design Input: Specifications Input: Specifications Output: Modular decomposition Output: Modular decomposition Abstraction Abstraction

5. CS540 Software Design 5Lecture 8 Detailed Design Each module is designed Each module is designed Specific algorithms Specific algorithms Data structures Data structures

6. CS540 Software Design 6Lecture 8 Action-Oriented Design Methods Data flow analysis Data flow analysis When to use it When to use it With most specification methods (Structured Systems Analysis here) With most specification methods (Structured Systems Analysis here) Key point: Have detailed action information from DFD Key point: Have detailed action information from DFD

7. CS540 Software Design 7Lecture 8 How to Perform Data Flow Analysis? Data Flow Analysis (DFA) is a design technique for achieving modules with high cohesion Data Flow Analysis (DFA) is a design technique for achieving modules with high cohesion Using the points of highest abstraction of input and output, the product is decomposed into three modules: input module, transform module and output module Using the points of highest abstraction of input and output, the product is decomposed into three modules: input module, transform module and output module This procedure is continued stepwise until each module performs a single action i.e., the design consists of modules with high cohesion This procedure is continued stepwise until each module performs a single action i.e., the design consists of modules with high cohesion

8. CS540 Software Design 8Lecture 8 Data Flow Analysis Product transforms input into output Product transforms input into output Determine Determine “Point of highest abstraction of input” “Point of highest abstraction of input” “Point of highest abstract of output” “Point of highest abstract of output”

9. CS540 Software Design 9Lecture 8 Data Flow Analysis (contd) Decompose into three modules Decompose into three modules Repeat stepwise until each module has high cohesion Repeat stepwise until each module has high cohesion Minor modifications may be needed to lower coupling Minor modifications may be needed to lower coupling

10. CS540 Software Design 10Lecture 8 Data Flow Analysis (contd) Example Example Design a product which takes as input a file name, and returns the number of words in that file (like UNIX wc )

11. CS540 Software Design 11Lecture 8 Data Flow Analysis Example(contd) First refinement First refinement Refine modules of communicational cohesion Refine modules of communicational cohesion

12. CS540 Software Design 12Lecture 8 Data Flow Analysis Example(contd) Second refinement Second refinement All eight modules have functional cohesion All eight modules have functional cohesion

13. CS540 Software Design 13Lecture 8 Multiple Input and Output Streams Point of highest abstraction for each stream Point of highest abstraction for each stream Continue until each module has high cohesion Continue until each module has high cohesion Adjust coupling if needed Adjust coupling if needed

14. CS540 Software Design 14Lecture 8 Transaction Analysis DFA poor for transaction processing products DFA poor for transaction processing products Example: ATM (Automatic Teller Machine) Example: ATM (Automatic Teller Machine)

15. CS540 Software Design 15Lecture 8 Transaction Analysis (contd) Poor design Poor design Logical cohesion, control coupling Logical cohesion, control coupling On the other hand it seems a waste of time and effort to have five very similar edit modules and five very similar update modules On the other hand it seems a waste of time and effort to have five very similar edit modules and five very similar update modules

16. CS540 Software Design 16Lecture 8 Corrected Design Using Transaction Analysis Software reuse (Section 8.1) Software reuse (Section 8.1) A basic edit module should be designed, coded, documented and tested, then instantiated five times. Each version will be slightly different but the differences will be small enough to make this worthwhile. A basic edit module should be designed, coded, documented and tested, then instantiated five times. Each version will be slightly different but the differences will be small enough to make this worthwhile. Similarly a basic update module can be instantiated five times and slightly modified to cater to the five different update types. Similarly a basic update module can be instantiated five times and slightly modified to cater to the five different update types. The resulting design has high cohesion and low coupling The resulting design has high cohesion and low coupling

17. CS540 Software Design 17Lecture 8 Data-Oriented Design Basic principle Basic principle The structure of a product must conform to the structure of its data The structure of a product must conform to the structure of its data Three very similar methods Three very similar methods Warnier Warnier Orr Orr Jackson Jackson Data-oriented design Data-oriented design Has never been as popular as action-oriented design Has never been as popular as action-oriented design With the rise of OOD, data-oriented design has largely fallen out of fashion With the rise of OOD, data-oriented design has largely fallen out of fashion

18. CS540 Software Design 18Lecture 8 Design of Real-Time Systems Difficulties associated with real-time systems Difficulties associated with real-time systems Inputs come from real world Inputs come from real world Software has no control over timing of inputs Software has no control over timing of inputs Frequently implemented on distributed software Frequently implemented on distributed software Communications implications Communications implications Timing issues Timing issues Problems of synchronization Problems of synchronization Race conditions Race conditions Deadlock (deadly embrace) Deadlock (deadly embrace) Major difficulty in design of real-time systems Major difficulty in design of real-time systems Determining whether the timing constraints are met by the design Determining whether the timing constraints are met by the design

19. CS540 Software Design 19Lecture 8 Real-Time Design Methods Usually, extensions of nonreal-time methods to real-time Usually, extensions of nonreal-time methods to real-time We have limited experience in use of any real-time methods We have limited experience in use of any real-time methods The state-of-the-art is not where we would like it to be The state-of-the-art is not where we would like it to be

20. CS540 Software Design 20Lecture 8 Testing during the Design Phase Design reviews Design reviews Design must correctly reflect specifications Design must correctly reflect specifications Design itself must be correct Design itself must be correct Transaction-driven inspections Transaction-driven inspections

21. CS540 Software Design 21Lecture 8 Metrics for the Design Phase The five basic metrics The five basic metrics Cyclomatic complexity is problematic Cyclomatic complexity is problematic Data complexity is ignored Data complexity is ignored Little use with object-oriented paradigm Little use with object-oriented paradigm

22. CS540 Software Design 22Lecture 8 Challenges of the Design Phase Design team should not do too much Design team should not do too much Detailed design should not become code Detailed design should not become code Design team should not do too little Design team should not do too little It is essential for the design team to produce a complete detailed design It is essential for the design team to produce a complete detailed design Difficult to find ‘great designers’ Difficult to find ‘great designers’