1 / 45

CHAPTER 13

CHAPTER 13. DESIGN PHASE. Overview. Design and abstraction Action-oriented design Data flow analysis Transaction analysis Data-oriented design Object-oriented design Elevator problem: object-oriented design. Overview (contd). Formal techniques for detailed design

mackenzie
Télécharger la présentation

CHAPTER 13

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CHAPTER 13 DESIGN PHASE

  2. Overview • Design and abstraction • Action-oriented design • Data flow analysis • Transaction analysis • Data-oriented design • Object-oriented design • Elevator problem: object-oriented design

  3. Overview (contd) • Formal techniques for detailed design • Real-time design techniques • Testing during the design phase • CASE tools for the design phase • Metrics for the design phase • Air Gourmet Case Study: object-oriented design • Challenges of the design phase

  4. Data and Actions • Two aspects of a product • Actions which operate on data • Data on which actions operate • The two basic ways of designing a product • Action-oriented design • Data-oriented design • Third way • Hybrid methods: action & data oriented design which is basically the object-oriented design

  5. Design Activities • Architectural design • Detailed design • Design testing

  6. Architectural Design • Also known as general design, logical design or high-level design • Input: Specifications • Output: Modular decomposition • The specifications are analyzed carefully • A module structure that has the desired functionality is produced • Output is a list of modules and a description of how they are to be interconnected • Goal: produce modules with high cohesion and low coupling (Read Sections 7.2 & 7.3)

  7. Detailed Design • Also known as modular design, physical design or low-level design • Each module is designed in detail • Specific algorithms are selected • Data structures are chosen

  8. Action-Oriented Design Methods • Data Flow Analysis (DFA) • A design technique for achieving modules with high cohesion • When to use it • With most specification methods (Structured Systems Analysis here) • Key point: Have detailed action information from DFD

  9. Data Flow Analysis • Product transforms input into output • Determine • “Point of highest abstraction of input” • “Point of highest abstractionof output”

  10. Data Flow Analysis (contd) • Decompose into three modules • Repeat stepwise refinement until each module has high cohesion • Minor modifications may be needed to lower coupling

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

  12. Data Flow Analysis Example (contd) • Structure Chart: First refinement • Need to refine modules of communicational cohesion

  13. Data Flow Analysis Example (contd) • Structure Chart: Second refinement • All eight modules have functional cohesion

  14. Multiple Input and Output Streams • Point of highest abstraction for each stream • Continue until each module has high cohesion • Adjust coupling if needed

  15. Transaction Analysis • DFA is poor for transaction processing products • Example: ATM (Automatic Teller Machine) • Poor design • Logical cohesion, control coupling

  16. Corrected Design Using Transaction Analysis • Software reuse • A basic edit module is designed, coded, documented, tested, then instantiated five times • Similarly for the update module

  17. Data-Oriented Design • Basic principle • The structure of a product must conform to the structure of its data • Three very similar methods • Warnier • Orr • Jackson • 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

  18. Object-Oriented Design (OOD) • Aim • Design product in terms of objects extracted during OOA • If we are using a language without inheritance (C, Ada 83) • Use abstract data type design • If we are using a language without a type statement (FORTRAN, COBOL) • Use data encapsulation

  19. Object-Oriented Design Steps • 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

  20. Elevator Problem: OOD • Step 1. Construct interaction diagrams for each scenario • Interaction Diagrams • Sequence diagrams • Collaboration diagrams • Both show the same thing • Objects and messages passed between them but in a different way

  21. Elevator Problem: OOD (contd) Normal scenario

  22. Elevator Problem: OOD (contd) • Sequence diagram

  23. Elevator Problem: OOD (contd) • Collaboration diagram

  24. Elevator Problem: OOD (contd) • Step 2. Construct Detailed Class Diagram • Do we assign an action to a class or to a client of that class? • Criteria • Information hiding • Reducing number of copies of action • Responsibility-driven design • Examples • close doors is assigned to Elevator Doors • move one floor down is assigned to Elevator

  25. Elevator Problem: OOD (contd) • Detailed class diagram

  26. Elevator Problem: OOD (contd) • Step 3. Design product in terms of clients of objects • Draw an arrow from an object to a client of that object • Objects that are not clients of any object have to be initiated, probably by the main method • Additional methods may be needed

  27. Elevator Problem: OOD (contd) • C++ Client-object relations

  28. Elevator Problem: OOD (contd) • Java Client-object relations

  29. Elevator Problem: OOD (contd) • elevator controller needs method elevator control loop so that main (or elevator application) can call it

  30. Elevator Problem: OOD (contd) • Step 4. Perform detailed design • Algorithms • Pseudo codes • Data structures • Detailed design of methodelevator controller loop

  31. Popular Techniques for Detailed Design • Applying stepwise refinement technique is assumed for most, if not all, methods • Flowcharts (section 5.1) • Table representation of module descriptions (Figure 13.6) • PDL (program description language, pseudocode, Figure 13.7)

  32. Formal Techniques for Detailed Design • Implementing a complete product and then proving it correct is hard • However, use of formal techniques during detailed design can help • Correctness proving (section 6.5) 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 • Should lead to fewer faults

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

  34. Real-Time Design Methods • Usually, extensions of nonreal-time methods are applied to real-time • We have limited experience in use of real-time methods • The state-of-the-art is not where we would like it to be • This is one of the active research areas in SE

  35. Testing during the Design Phase • Design reviews • Design must correctly reflect specifications • Design itself must be correct • Should not have logic faults • All interfaces must be correctly defined

  36. CASE Tools for the Design Phase • UpperCASE tools • Built around data dictionary • Consistency checker • Screen, report generators • Modern tools represent OOD using UML • Examples: Analyst/Designer, Software through Pictures, System Architect, Rose

  37. Metrics for the Design Phase • Number of modules – indicates size of product • Module cohesion and coupling – measure of design quality • Fault statistics – number and type • Cyclometric complexity M • A measure of control complexity: the number of binary decisions (predicates) plus 1 (i.e., the number of branches in the module) • Measure of design quality – the lower the value of M, the better • Data complexity is ignored • Little use with object-oriented paradigm

  38. Air Gourmet Case Study: Object-Oriented Design • 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. Step 1. Interaction Diagrams • Extended scenario for making a reservation

  40. Step 1. Interaction Diagrams (contd) • Sequence diagram for making a reservation

  41. Step 1. Interaction Diagrams (contd) Collaboration diagram for sending and returning a postcard

  42. Step 2. Detailed Class Diagram C++ version Java version

  43. Step 3. Client–Object Relations C++ version Java version

  44. Step 4. Detailed Design • The detailed design can be found in • Appendix H (for implementation in C++) • Appendix I (for implementation in Java)

  45. Challenges of the Design Phase • Design team should not do too much • Detailed design should not become code • Design team should not do too little • It is essential for the design team to produce a complete detailed design

More Related