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

Design and Abstraction n 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 n Architectural design - Develop a modular program structure and represent the control relationships between modules n Detailed design - Specify each module by designing the algorithmic details and associated data structures

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

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

Data Flow Analysis (DFA) n DFA is a design technique for achieving modules with high cohesion n 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 n The point of highest abstraction of output (HAO)  The first point in the flow of data which the output can be identified n The product is decomposed into modules by using the point of highest abstraction of input and output n This procedure is continued stepwise until each module performs a single action

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

Extensions n 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 n Figure 12.8

Transaction Analysis n A transaction is an operation from the viewpoint of the user of the product  Print a list of today’s orders n Data flow analysis is not appropriate for the transaction- processing type of product  Typical transaction-processing system - Figure 12.9 n 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

Object-Oriented Design n 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

Object-Oriented Design n Step 1: Construct interaction diagrams for each scenario n 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

Object-Oriented Design (2) n 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

Object-Oriented Design (3) n 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. n Examine how messages in Figure are mapped to methods in Figure 12.14

Object-Oriented Design (4) n Step 3: Design the product in terms of clients of objects  Summarize all client-object relations (system architecture)  Figure  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

Object-Oriented Design (5) n 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  Automatic code generation performed by a CASE tool is usually followed by detailed design

Metrics for the Design Phase n 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 n Supplementary information on McCabe’s cyclomatic complexity will be distributed in class

Metrics for the Design Phase (2) n 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 n 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 = length x (fan-in x fan-out) 2