UHD::3320::CH121 DESIGN PHASE Chapter 12

UHD::3320::CH122 Design Phase Two Aspects –Actions which operate on data –Data on which actions operate Two basic ways of designing a product –Action-oriented design –Data-oriented design –Data Flow Analysis (DFS) Third way: Object-oriented design –combination of both

UHD::3320::CH123 Design Activities Three activities: –Architectural design Input: Specifications Output: modular decomposition –Detailed design each module is designed in detail –specific algorithms –data Structures –design testing integral part of design

UHD::3320::CH124 Action-Oriented Design Decomposition with high cohesion and low coupling flow of data is secondary Practical techniques –data flow analysis –transaction analysis examples where other techniques are used: –rule based systems –databases

UHD::3320::CH125 Data Flow Analysis The product is decomposed to three modules –input module –transform module –output module How? –Start with any action DFD. Example: apply payment to invoice compute speed of incoming missile –Represent action by data flow graph

UHD::3320::CH126 Transaction Analysis Related actions with similar outlines but different details software reuse e.g., automated teller machine (ATM) –analyzer and dispatcher –edit and update modules

UHD::3320::CH127 Object-Oriented Design Aim: Design product in terms of objects extracted during OOA OOD is both action and data oriented OOD consists of the four steps: 1. Construct interaction diagram for each scenario 2. Construct the detailed class (object) diagram 3. Design the product in terms of clients of objects 4. Proceed to detailed design

UHD::3320::CH128 STEP1: Construct Interaction Diagrams For Each Scenario Sequence diagrams Collaboration diagrams both show objects and messages passed between them.

UHD::3320::CH129 Sequence Diagram

UHD::3320::CH1210 Collaboration Diagram

UHD::3320::CH1211 STEP2: Construct Detailed Object Model Assign operations (“methods”) to classes Dynamic Model: each state diagram describes the behavior of an object. Convert actions and activities in the dynamic model into operations attached to classes in the object model. We can associate an operation with each event received by an object.

UHD::3320::CH1212 STEP2: Detailed Object Model CNTD A client of an object is a program unit that sends a message to an object of that class (i.e. requests a service from an object of that class) –should an action be assigned to the class or to the client of that class? Criteria –Information hiding: state variables of a class must be private/protected Actions on private members of a class must be carried out by local methods –Reducing number of copies of action –Responsibility-driven design

UHD::3320::CH1213 STEP2: Detailed Object Model CNTD When an operation involves more than one object, who should own the operation? Is one object modified by the operation while other objects are only queried for info? The object that is modified is the target of the operation. Associate the operation with the target object. Look at the classes and associations involved in the operation. The class that is central should own the operation. Think in the real world: which object is being pushed, moved, closed, acted on, or manipulated? That object should own the operation.

UHD::3320::CH1214 STEP2: Detailed Class Diagram CNTD

UHD::3320::CH1215 STEP3: 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

UHD::3320::CH1216 STEP3 CNTD Additional methods may be needed –verify that each object has all required methods to be able to carry out all actions and activities under all conditions and events. Example: consider Elevator Controller –Must log and update requests –Needs state variable requests –Need methods log request, update requests This ends the architectural design part

UHD::3320::CH1217 STEP 4: Perform Detailed Design Data structures to represent state variables of each class. –Usually instances of container classes: lists, queues, stacks, sets, dictionaries, trees etc. –OO languages have predefined libraries Algorithms to implement the operations assigned to each class and function main. Basic techniques: –Stepwise refinement: divide a big task into smaller sub-tasks. Repeat until sub-tasks are simple enough to be implemented directly –Simple “sub-tasks” usually have simple mathematical or procedural definition. Algorithm is an implementation of the definition.

UHD::3320::CH1218 STEP 4: Perform Detailed Design Sometimes simple implementation is not efficient. Consider the following factors in selecting an algorithm: –computational complexity –ease of implementation and maintainability Stepwise refinement may necessitate additional internal methods. Detailed design can be specified using –flow charts –pseudocode

UHD::3320::CH1219 Detailed Design of Method elevator control loop

UHD::3320::CH1220 Testing During the Design Correctness of design accurate reflection of specifications detecting faults (before the coding) using inspections or walkthrough

UHD::3320::CH1221 CASE Tools back-end (lower CASE Tool) –implementation front-end (upper CASE Tool) –design Analyst/Designer, Excelerator, and Teamwork –consistency checking –screen and report generators –management tools for estimation and planning –Object-Oriented Design Tools OMTool, Rose, Software through Pictures