DESIGN PHASE

1
DESIGN PHASE

• Chapter 12

2
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

3
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

4
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

5
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

6
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

7
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

8
STEP1 Construct Interaction Diagrams For Each
Scenario

• Sequence diagrams
• Collaboration diagrams
• both show objects and messages passed between
  them.

9
Sequence Diagram
10
Collaboration Diagram
11
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.

12
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

13
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.

14
STEP2 Detailed Class Diagram CNTD
15
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

16
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

17
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.

18
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

19
Detailed Design of Method elevator control loop
20
Testing During the Design

• Correctness of design
• accurate reflection of specifications
• detecting faults (before the coding)
• using inspections or walkthrough

21
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