The Software Process

1
CHAPTER 13
DESIGN PHASE
2
Overview

• Design and abstraction
• Action-oriented design
• Data flow analysis
• Transaction analysis
• Data-oriented design
• Object-oriented design
• Elevator problem object-oriented design

3
Overview (contd)

• Formal techniques for detailed design
• Real-time design techniques
• Testing during the design phase
• CASE tools for the design phase
• Metrics for the design phase
• Air Gourmet Case Study object-oriented design
• Challenges of the design phase

4
Data and Actions

• Two aspects of a product
• Actions which operate on data
• Data on which actions operate
• The two basic ways of designing a product
• Action-oriented design
• Data-oriented design
• Third way
• Hybrid methods action data oriented design
  which is basically the object-oriented design

5
Design Activities

• Architectural design
• Detailed design
• Design testing

6
Architectural Design

• Also known as general design, logical design or
  high-level design
• Input Specifications
• Output Modular decomposition
• The specifications are analyzed carefully
• A module structure that has the desired
  functionality is produced
• Output is a list of modules and a description of
  how they are to be interconnected
• Goal produce modules with high cohesion and low
  coupling (Read Sections 7.2 7.3)

7
Detailed Design

• Also known as modular design, physical design or
  low-level design
• Each module is designed in detail
• Specific algorithms are selected
• Data structures are chosen

8
Action-Oriented Design Methods

• Data Flow Analysis (DFA)
• A design technique for achieving modules with
  high cohesion
• When to use it
• With most specification methods (Structured
  Systems Analysis here)
• Key point Have detailed action information from
  DFD

9
Data Flow Analysis

• Product transforms input into output
• Determine
• Point of highest abstraction of input
• Point of highest abstraction of output

10
Data Flow Analysis (contd)

• Decompose into three modules
• Repeat stepwise refinement until each module has
  high cohesion
• Minor modifications may be needed to lower
  coupling

11
Data Flow Analysis (contd)

• Example
• Design a product which takes as input a file
  name, and returns the number of words in that
  file (like UNIX wc )

12
Data Flow Analysis Example (contd)

• Structure Chart First refinement
• Need to refine modules of communicational cohesion

13
Data Flow Analysis Example (contd)

• Structure Chart Second refinement
• All eight modules have functional cohesion

14
Multiple Input and Output Streams

• Point of highest abstraction for each stream
• Continue until each module has high cohesion
• Adjust coupling if needed

15
Transaction Analysis

• DFA is poor for transaction processing products
• Example ATM (Automatic Teller Machine)
• Poor design
• Logical cohesion, control coupling

16
Corrected Design Using Transaction Analysis

• Software reuse
• A basic edit module is designed, coded,
  documented, tested, then instantiated five times
• Similarly for the update module

17
Data-Oriented Design

• Basic principle
• The structure of a product must conform to the
  structure of its data
• Three very similar methods
• Warnier
• Orr
• Jackson
• Data-oriented design
• Has never been as popular as action-oriented
  design
• With the rise of OOD, data-oriented design has
  largely fallen out of fashion

18
Object-Oriented Design (OOD)

• Aim
• Design product in terms of objects extracted
  during OOA
• If we are using a language without inheritance
  (C, Ada 83)
• Use abstract data type design
• If we are using a language without a type
  statement (FORTRAN, COBOL)
• Use data encapsulation

19
Object-Oriented Design Steps

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

20
Elevator Problem OOD

• Step 1. Construct interaction diagrams for each
  scenario
• Interaction Diagrams
• Sequence diagrams
• Collaboration diagrams
• Both show the same thing
• Objects and messages passed between them but in a
  different way

21
Elevator Problem OOD (contd)

• Normal scenario

22
Elevator Problem OOD (contd)

• Sequence
• diagram

23
Elevator Problem OOD (contd)

• Collaboration diagram

24
Elevator Problem OOD (contd)

• Step 2. Construct Detailed Class Diagram
• Do we assign an action to a class or to a client
  of that class?
• Criteria
• Information hiding
• Reducing number of copies of action
• Responsibility-driven design
• Examples
• close doors is assigned to Elevator Doors
• move one floor down is assigned to Elevator

25
Elevator Problem OOD (contd)

• Detailed class diagram

26
Elevator Problem OOD (contd)

• Step 3. 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
• Additional methods may be needed

27
Elevator Problem OOD (contd)

• C Client-object relations

28
Elevator Problem OOD (contd)

• Java Client-object relations

29
Elevator Problem OOD (contd)

• elevator controller needs method elevator control
  loop so that main (or elevator application) can
  call it

30
Elevator Problem OOD (contd)

• Step 4. Perform detailed design
• Algorithms
• Pseudo codes
• Data structures
• Detailed design of method elevator controller loop

31
Popular Techniques for Detailed Design

• Applying stepwise refinement technique is assumed
  for most, if not all, methods
• Flowcharts (section 5.1)
• Table representation of module descriptions
  (Figure 13.6)
• PDL (program description language, pseudocode,
  Figure 13.7)

32
Formal Techniques for Detailed Design

• Implementing a complete product and then proving
  it correct is hard
• However, use of formal techniques during detailed
  design can help
• Correctness proving (section 6.5) can be applied
  to module-sized pieces
• The design should have fewer faults if it is
  developed in parallel with a correctness proof
• If the same programmer does the detailed design
  and implementation
• The programmer will have a positive attitude to
  the detailed design
• Should lead to fewer faults

33
Design of Real-Time Systems

• Difficulties associated with real-time systems
• Inputs come from real world
• Software has no control over timing of inputs
• Frequently implemented on distributed hardware
• Communications implications
• Timing issues
• Problems of synchronization
• Race conditions
• Deadlock
• Major difficulty in design of real-time systems
• Determining whether the timing constraints are
  met by the design

34
Real-Time Design Methods

• Usually, extensions of nonreal-time methods are
  applied to real-time
• We have limited experience in use of real-time
  methods
• The state-of-the-art is not where we would like
  it to be
• This is one of the active research areas in SE

35
Testing during the Design Phase

• Design reviews
• Design must correctly reflect specifications
• Design itself must be correct
• Should not have logic faults
• All interfaces must be correctly defined

36
CASE Tools for the Design Phase

• UpperCASE tools
• Built around data dictionary
• Consistency checker
• Screen, report generators
• Modern tools represent OOD using UML
• Examples Analyst/Designer, Software through
  Pictures, System Architect, Rose

37
Metrics for the Design Phase

• Number of modules indicates size of product
• Module cohesion and coupling measure of design
  quality
• Fault statistics number and type
• Cyclometric complexity M
• A measure of control complexity the number of
  binary decisions (predicates) plus 1 (i.e., the
  number of branches in the module)
• Measure of design quality the lower the value
  of M, the better
• Data complexity is ignored
• Little use with object-oriented paradigm

38
Air Gourmet Case Study Object-Oriented Design

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

39
Step 1. Interaction Diagrams

• Extended scenario for making a reservation

40
Step 1. Interaction Diagrams (contd)

• Sequence diagram for making a reservation

41
Step 1. Interaction Diagrams (contd)

• Collaboration diagram for sending and returning a
  postcard

42
Step 2. Detailed Class Diagram

• C version Java version

43
Step 3. ClientObject Relations

• C version Java version

44
Step 4. Detailed Design

• The detailed design can be found in
• Appendix H (for implementation in C)
• Appendix I (for implementation in Java)

45
Challenges of the Design Phase

• Design team should not do too much
• Detailed design should not become code
• Design team should not do too little
• It is essential for the design team to produce a
  complete detailed design