1. Slide 13.1 © The McGraw-Hill Companies, 2002 Object-Oriented and Classical Software Engineering Fifth Edition, WCB/McGraw-Hill, 2002 Stephen R. Schach srs@vuse.vanderbilt.edu

2. Slide 13.2 © The McGraw-Hill Companies, 2002 CHAPTER 13 DESIGN PHASE

3. Slide 13.3 © The McGraw-Hill Companies, 2002 Overview l Design and abstraction l Action-oriented design l Data flow analysis l Transaction analysis l Data-oriented design l Object-oriented design l Elevator problem: object-oriented design

4. Slide 13.4 © The McGraw-Hill Companies, 2002 Overview (contd) l Formal techniques for detailed design l Real-time design techniques l Testing during the design phase l CASE tools for the design phase l Metrics for the design phase l Air Gourmet Case Study: object-oriented design l Challenges of the design phase

5. Slide 13.5 © The McGraw-Hill Companies, 2002 Data and Actions l Two aspects of a product –Actions that operate on data –Data on which actions operate l The two basic ways of designing a product –Action-oriented design –Data-oriented design l Third way –Hybrid methods –For example, object-oriented design

6. Slide 13.6 © The McGraw-Hill Companies, 2002 Design Activities l Architectural design l Detailed design l Design testing

7. Slide 13.7 © The McGraw-Hill Companies, 2002 Architectural Design l Input: Specifications l Output: Modular decomposition l Abstraction

8. Slide 13.8 © The McGraw-Hill Companies, 2002 Detailed Design l Each module is designed –Specific algorithms –Data structures

9. Slide 13.9 © The McGraw-Hill Companies, 2002 Action-Oriented Design Methods l Data flow analysis l When to use it –With most specification methods (Structured Systems Analysis here) l Key point: We have detailed action information from the DFD

10. Slide 13.10 © The McGraw-Hill Companies, 2002 Data Flow Analysis l Product transforms input into output l Determine –“Point of highest abstraction of input” –“Point of highest abstract of output”

11. Slide 13.11 © The McGraw-Hill Companies, 2002 Data Flow Analysis (contd) l Decompose into three modules l Repeat stepwise until each module has high cohesion –Minor modifications may be needed to lower the coupling

12. Slide 13.12 © The McGraw-Hill Companies, 2002 Data Flow Analysis (contd) l Example Design a product which takes as input a file name, and returns the number of words in that file (like UNIX wc )

13. Slide 13.13 © The McGraw-Hill Companies, 2002 Data Flow Analysis Example (contd) l First refinement l Now refine the two modules of communicational cohesion

14. Slide 13.14 © The McGraw-Hill Companies, 2002 Data Flow Analysis Example (contd) l Second refinement l All eight modules now have functional cohesion

15. Slide 13.15 © The McGraw-Hill Companies, 2002 Multiple Input and Output Streams l Point of highest abstraction for each stream l Continue until each module has high cohesion –Adjust the coupling if needed

16. Slide 13.16 © The McGraw-Hill Companies, 2002 Transaction Analysis l DFA poor for transaction processing products –Example: ATM (automated teller machine) l Poor design –Logical cohesion, control coupling

17. Slide 13.17 © The McGraw-Hill Companies, 2002 Corrected Design Using Transaction Analysis l Software reuse l Have one generic edit module, one generic update module l Instantiate them 5 times

18. Slide 13.18 © The McGraw-Hill Companies, 2002 Data-Oriented Design l Basic principle –The structure of a product must conform to the structure of its data l Three very similar methods –Warnier –Orr –Jackson l Data-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

19. Slide 13.19 © The McGraw-Hill Companies, 2002 Object-Oriented Design (OOD) l Aim –Design the product in terms of the classes extracted during OOA l If we are using a language without inheritance (C, Ada 83) –Use abstract data type design l If we are using a language without a type statement (FORTRAN, COBOL) –Use data encapsulation

20. Slide 13.20 © The McGraw-Hill Companies, 2002 Object-Oriented Design Steps l OOD consists of four steps: –1.Construct interaction diagrams for each scenario –2.Construct the detailed class diagram –3.Design the product in terms of clients of objects –4.Proceed to the detailed design

21. Slide 13.21 © The McGraw-Hill Companies, 2002 Elevator Problem: OOD l Step 1. Construct interaction diagrams for each scenario l Sequence diagrams l Collaboration diagrams –Both show the same thing –Objects and messages passed between them –But in a different way

22. Slide 13.22 © The McGraw-Hill Companies, 2002 Elevator Problem: OOD (contd) l Normal scenario

23. Slide 13.23 © The McGraw-Hill Companies, 2002 Elevator Problem: OOD (contd) l Sequence diagram

24. Slide 13.24 © The McGraw-Hill Companies, 2002 Elevator Problem: OOD (contd) l Collaboration diagram

25. Slide 13.25 © The McGraw-Hill Companies, 2002 Elevator Problem: OOD (contd) l Step 2. Construct the detailed class diagram l Do we assign an action to a class or to a client of that class? l Criteria –Information hiding –Reducing number of copies of each action –Responsibility-driven design l Examples close doors is assigned to Elevator Doors move one floor down is assigned to Elevator

26. Slide 13.26 © The McGraw-Hill Companies, 2002 Elevator Problem: OOD (contd) l Detailed class diagram

27. Slide 13.27 © The McGraw-Hill Companies, 2002 Elevator Problem: OOD (contd) l Step 3. Design the product in terms of clients of objects l Draw an arrow from an object to a client of that object l Objects that are not clients of any object have to be initiated, probably by the main method –Additional methods may be needed

28. Slide 13.28 © The McGraw-Hill Companies, 2002 Elevator Problem: OOD (contd) l C++ client-object relations

29. Slide 13.29 © The McGraw-Hill Companies, 2002 Elevator Problem: OOD (contd) l Java client-object relations

30. Slide 13.30 © The McGraw-Hill Companies, 2002 Elevator Problem: OOD (contd) l elevator controller needs method elevator control loop so that main (or elevator application ) can call it

31. Slide 13.31 © The McGraw-Hill Companies, 2002 Elevator Problem: OOD (contd) l Step 4. Perform the detailed design Detailed design of method elevator controller loop

32. Slide 13.32 © The McGraw-Hill Companies, 2002 Formal Techniques for Detailed Design l Implementing a complete product and then proving it correct is hard l However, use of formal techniques during detailed design can help –Correctness proving can be applied to module-sized pieces –The design should have fewer faults if it is developed in parallel with a correctness proof –If the same programmer does the detailed design and implementation »The programmer will have a positive attitude to the detailed design »This should lead to fewer faults

33. Slide 13.33 © The McGraw-Hill Companies, 2002 Design of Real-Time Systems l Difficulties associated with real-time systems –Inputs come from the real world »Software has no control over the timing of the inputs –Frequently implemented on distributed software »Communications implications »Timing issues –Problems of synchronization »Race conditions »Deadlock (deadly embrace) l Major difficulty in the design of real-time systems –Determining whether the timing constraints are met by the design

34. Slide 13.34 © The McGraw-Hill Companies, 2002 Real-Time Design Methods l Usually, extensions of nonreal-time methods to real-time l We have limited experience in use of any real-time methods l The state-of-the-art is not where we would like it to be

35. Slide 13.35 © The McGraw-Hill Companies, 2002 Testing during the Design Phase l Design reviews –The design must correctly reflect the specifications –The design itself must be correct –Transaction-driven inspections

36. Slide 13.36 © The McGraw-Hill Companies, 2002 CASE Tools for the Design Phase l UpperCASE tools –Built around a data dictionary –Consistency checker –Screen, report generators –Modern tools represent OOD using UML –Examples: »Software through Pictures »Rose

37. Slide 13.37 © The McGraw-Hill Companies, 2002 Metrics for the Design Phase l The five basic metrics l Cyclomatic complexity is problematic –Data complexity is ignored –Not used much with the object-oriented paradigm

38. Slide 13.38 © The McGraw-Hill Companies, 2002 Air Gourmet Case Study: Object-Oriented Design l OOD consists of four steps: –1. Construct interaction diagrams for each scenario –2. Construct the detailed class diagram –3. Design the product in terms of clients of objects –4. Proceed to the detailed design

39. Slide 13.39 © The McGraw-Hill Companies, 2002 Step 1. Interaction Diagrams l Extended scenario for making a reservation

40. Slide 13.40 © The McGraw-Hill Companies, 2002 Step 1. Interaction Diagrams (contd) l Sequence diagram for making a reservation

41. Slide 13.41 © The McGraw-Hill Companies, 2002 Step 1. Interaction Diagrams (contd) l Collaboration diagram for sending and returning a postcard

42. Slide 13.42 © The McGraw-Hill Companies, 2002 Step 2. Detailed Class Diagram C++ version Java version

43. Slide 13.43 © The McGraw-Hill Companies, 2002 Step 3. Client–Object Relations C++ version Java version

44. Slide 13.44 © The McGraw-Hill Companies, 2002 Step 4. Detailed Design l The detailed design can be found in –Appendix H (for implementation in C++) –Appendix I (for implementation in Java)

45. Slide 13.45 © The McGraw-Hill Companies, 2002 Challenges of the Design Phase l The design team should not do too much –The detailed design should not become code l The design team should not do too little –It is essential for the design team to produce a complete detailed design l We need to grow great designers