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

July 3th, 2000

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

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.

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

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

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

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

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

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

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

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

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

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 methodslog request, update requests, and request is pendingto the Elevator class

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

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

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 = length x (fan-in x fan-out)2