1 / 18

Chapter 12: Design Phase

July 3th, 2000. Chapter 12: Design Phase. 12.1 Design and Abstraction 12.2 Action-Oriented Design 12.3 Data Flow Analysis 12.3.1 Data Flow Analysis Example 12.3.2 Extensions 12.4 Transaction Analysis 12.6 Object-Oriented Design 12.7 Elevator problem: OO Design

raven-good
Download Presentation

Chapter 12: Design Phase

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. July 3th, 2000 Chapter 12: Design Phase • 12.1 Design and Abstraction • 12.2 Action-Oriented Design • 12.3 Data Flow Analysis • 12.3.1 Data Flow Analysis Example • 12.3.2 Extensions • 12.4 Transaction Analysis • 12.6 Object-Oriented Design • 12.7 Elevator problem: OO Design • 12.12 Metrics for the Design Phase

  2. Design and Abstraction • Major activities of the software design phase • Architectural design (also known as general, logical or high-level design) • Detailed design (also known as modular, physical, low-level design, or procedural design) • Design testing • Architectural design - Develop a modular program structure and represent the control relationships between modules • Detailed design - Specify each module by designing the algorithmic details and associated data structures

  3. Design and Abstraction (2) • Input to the design phase • The specification document, a description of what the product is to do. • Output to the design phase • The design document, a description of how the product is to achieve this. • Design techniques • Action-oriented techniques • Data-oriented techniques • Object-oriented techniques.

  4. Action-oriented Design • Actions is emphasized • Two practical techniques for action-oriented design • Data flow analysis • Transaction analysis • Weakness • Concentrate on the actions; the data are only of secondary importance

  5. Data Flow Analysis (DFA) • DFA is a design technique for achieving modules with high cohesion • The point of highest abstraction of input (HAI) • The point at which the input loses the quality of being input and becomes internal data operated on by the product • The point of highest abstraction of output (HAO) • The first point in the flow of data which the output can be identified • The product is decomposed into modules by using the point of highest abstraction of input and output • This procedure is continued stepwise until each module performs a single action

  6. Data Flow Analysis Example • Map a Data Flow Diagram into a Structure Chart • Figures 12.3, 12.4, and 12.5 • Detailed design of each module • Figure 12.6

  7. Extensions • In multiple input and output stream • Find the point of HAI and HAO for each input and output stream • Use these points to decompose the DFD into modules with fewer input and output streams, then continue until resulting module has high cohesion • Determine the coupling between each pair of modules and make necessary adjustments • Figure 12.8

  8. Transaction Analysis • A transaction is an operation from the viewpoint of the user of the product • Print a list of today’s orders • Data flow analysis is not appropriate for the transaction-processing type of product • Typical transaction-processing system - Figure 12.9 • Transaction analysis is a good way of decomposing transaction processing products into modules. • Analyzer - determines the transaction type and passes this information to the dispatcher • Dispatcher - performs the transaction • Figure 12.10

  9. Object-Oriented Design • OOD consists of four major steps: • Step 1: Construct interaction diagrams for each scenario • Step 2: Construct the detailed class diagram • Step 3: Design the product in terms of clients of objects • Step 4: Proceed to the detailed design

  10. Object-Oriented Design • Step 1: Construct interaction diagrams for each scenario • Two types of interaction diagrams in UML • Sequence diagram • Emphasize the explicit chronological sequence of messages • Useful in situations where the order in which events occur is important • Collaboration diagram • Emphasize the relationship between objects • Scenarios -> Sequence Diagram -> Collaboration diagram • Figures 12.11, 12.12, and 12.13

  11. Object-Oriented Design (2) • Step 2: Construct the detailed class diagram • Determine all the actions performed by the product • Examine all interaction diagrams • Decide on which actions go to which class • Message sender (client) or message receiver (object) • Insert methods (perform actions) into the class diagram developed in the OOA phase

  12. Object-Oriented Design (3) • Assigning actions to be performed (methods) to classes • Information hiding • Actions performed on state variables (attributes) must be local to that class. • Multiple requests • If a particular action is invoked by a number of different clients of an object, then it makes sense to have a single copy of that action implemented as a method of the object, rather than have a copy in each of the clients of that object. • Responsibility-driven design • If a client sends a message to an object, then that object is responsible for carrying out the request of the client. • Examine how messages in Figure 12.12 are mapped to methods in Figure 12.14

  13. Object-Oriented Design (4) • Step 3: Design the product in terms of clients of objects • Summarize all client-object relations (system architecture) • Figure 12.15 • An object that is not a client of some other object needs to be initiated, usually by the main program • Add an elevator controller loop method into the Elevator Controller class to allow main can invoke it • Examine all classes to identify missing methods • Use scenarios to traverse the detailed class diagram • When a button is pressed, the elevator must log the request and then cancel it when the elevator arrives • Add a state variable requests and three methods-log request, update requests, and request is pending-to the Elevator class

  14. Object-Oriented Design (5) • Step 4: Proceed to the detailed design • Perform the detailed design on the main program and the methods in all classes • A PDL specification of the elevator control loop method • Figure 12.16 • Automatic code generation performed by a CASE tool is usually followed by detailed design

  15. Metrics for the Design Phase • Cyclomatic complexity • Number of binary decisions (predicates) plus 1 • Number of branches in the module • The lower the value of Cyclomatic Complexity, the better • Advantage - easy to compute • Problem - Only measure the control complexity; the data complexity is ignored • Supplementary information on McCabe’s cyclomatic complexity will be distributed in class

  16. Metrics for the Design Phase (2) • Fan-in (of a module) • The number of flows into the module (i.e., number of other modules that call the module) + number of global data structures accessed by the module • Fan-out (of a module) • The number of flows out of the module (i.e., number of other modules that the module calls) + number of global data structures updated by the module • Module complexity = lengthx (fan-inxfan-out)2

More Related