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
• example data-flow analysis objective is to
  design modules with high cohesion
• Data-oriented design
• Jacksons technique the structure of the data is
  determined first, then the procedures are
  designed to conform to the structure of the data

5
Data and Actions

• The third way, grasshopper
• Hybrid methods
• For example, object-oriented design
• equal weight on data and actions

6
Design Activities

• Three activities in the design phase
• Architectural design (general design, logical
  design, high-level design)
• input specifications
• a modular decomposition of the product is
  developed.
• output a list of the modules and a description
  of how they are interconnected
• when using OO, part of the architectural design
  is done during OOA

7
Design Activities

• Three activities in the design phase
• Detailed design (modular design, physical design,
  low-level design)
• each module is designed in detail
• Example select algorithms and data structures
• ignore the fact that the modules are to be
  interconnected.
• Design testing
• testing is an integral part of design

8
Action-Oriented Design Methods

• Data flow analysis creating modules with high
  cohesion
• When to use it
• With most specification methods (Structured
  Systems Analysis here)
• Key point when finished have detailed action
  information from DFD

9
Data Flow Analysis

• Product transforms input into output
• Determine
• Point of highest abstraction of input (where
  input becomes internal data)
• Point of highest abstract of output (where
  internal data becomes identifiable output)

10
Data Flow Analysis (contd)

• Decompose into three modules
• input module
• transform module
• output module
• Repeat stepwise until each module has high
  cohesion
• each module should perform a single action
• Minor modifications may be needed to lower
  coupling
• example control coupling may arise
  inadvertently in a design constructed from a DFD.
• must then modify so that data, not control, is
  passed.

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)

• First refinement
• Refine modules of communicational cohesion

13
Data Flow Analysis Example(contd)

• problem with first refinement
• The DFD does not show what happens if the file
  name is not valid
• There must be a module read and validate file
  name
• will return a status flag to perform word count
• if name is invalid, it is ignored by perform word
  count and error printed.
• In general, where ever there is a conditional
  data flow, a corresponding control flow is
  needed.

14
Data Flow Analysis Example(contd)

• Another problem with first refinement
• read and validate file name and format and
  display word count have communicational cohesion.
• must decompose further
• A module has communicational cohesion if it
  performs a series of actions related by the
  procedure to be followed by the product, but in
  addition all the actions operate on the same data
• Final result next slide.

15
Data Flow Analysis Example(contd)

• Second refinement
• All eight modules have functional cohesion

16
Data Flow Analysis Example(contd)

• Next step detailed design.
• Must choose data structures and algorithms.
• Then hand each module to a programmer for
  implementation.
• Example module design see next slide.
• could also write module in pseudo-code.

17
Data Flow Analysis Example(contd)
18
Multiple Input and Output Streams

• Find the point of highest abstraction of input
  for each input stream and the point of highest
  abstraction for each output stream.
• Use these points to decompose the given data flow
  diagram into modules with fewer input-output
  streams.
• Continue until each module has high cohesion.
• Then determine the coupling between each pair of
  modules and make adjustments.

19
Multiple Input and Output Streams

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

20
Overview

• Iterate the following steps
• Find the point of highest abstraction of input of
  each input stream
• Find the point of highest abstraction of output
  of each output stream
• Decompose the data flow diagram using these
  points of highest abstraction
• until the resulting modules have high cohesion
• if a resulting coupling is too high, adjust the
  design.

21
Transaction Analysis

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

22
Corrected Design Using Transaction Analysis

• Software reuse

23
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

24
Object-Oriented Design (OOD)

• Goal
• 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

25
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

26
Elevator Problem OOD

• Step 1. Construct interaction diagrams for each
  scenario
• UML supports two types of interaction diagrams
• Sequence diagrams
• Collaboration diagrams
• Both show the same thing
• Objects and messages passed between them
• But in a different way

27
Elevator Problem OOD

• Sequence diagrams
• emphasize the explicit chronological sequence of
  messages
• useful in situations where the order in which
  events occur is important
• Collaboration diagrams
• emphasize the relationship between objects
• useful for understanding the structure of a
  product

28
Elevator Problem OOD (contd)

• Normal scenario

29
Elevator Problem OOD (contd)

• Sequence diagram
• users and objects are vertical lines
• an instance of a class is represented by the
  underlined name of the class
• time goes top to bottom

30
Elevator Problem OOD (contd)

• first event
• User A presses Up floor button
• next floor button informs elevator controller
  that is has been pushed
• elevator controller then sends message to
  relevant floor button to turn itself on

31
Elevator Problem OOD (contd)

• first event
• 4th event elevator arrives at floor 3 as a
  consequence of a series of messages sent by the
  elevator controller to the elevator.
• the iteration denoted by the asterisk in 4

32
Elevator Problem OOD (contd)

• constructing the sequence diagram
• first list the actors in the scenario, ie, users
  and objects active in the events of the scenario
• e.g., User A (events 1 and 8), floor button
  (events 1, 2, 3, 5), etc.
• boxes representing these actors are drawn at the
  top of the page and vertical double lines are
  drawn down.
• each event of the scenario in turn is inserted
  into the sequence diagram.

33
Elevator Problem OOD (contd)

• constructing the sequence diagram
• loops.
• two in this scenario
• both represent the actions of the timer within
  the elevator controller

34
Elevator Problem OOD (contd)

• first loop 7, start timer.
• the timer is started after the doors have been
  sent a message to open themselves
• while door is open, User A presses the elevator
  button for floor 7 (event 8)
• the elevator button informs the elevator
  controller about this (event 9)

35
Elevator Problem OOD (contd)

• first loop 7, start timer.
• and the elevator controller sends amessage to the
  elevator button to switch itself on (event 10)
• the timeout occurs and (event 11) the elevator
  controller sends a message to the doors to close
  themselves.
• this is why the end of the first timer loop meets
  the double vertical line representing the
  elevator controller between events 10 and 11.

36
Elevator Problem OOD (contd)

• Collaboration diagram
• shows the central role played by the elevator
  controller
• all but two messages are sent to or from the
  elevator controller

37
Elevator Problem OOD (contd)

• Collaboration diagram
• however, the timing information of sequence
  diagram is lost.

38
Elevator Problem OOD (contd)

• Constructing a collaboration diagram
• construct the same way as the sequence diagram
• actors extracted and drawn on diagram
• each event in turn examined and entered in
  diagram
• example
• in event 3, elevator controller instructs the
  floor button to turn itself on
• draw line from elevator controller to floor
  button
• place small arrow parallel to that line
• annotate arrow 3. turn button on

39
Elevator Problem OOD (contd)

• Constructing a collaboration diagram
• difference with sequence diagram
• in sequence, events represented by horizontal
  lines connecting the double vertical lines headed
  by a box containing the name of the relevant
  actor
• in collaboration, events represented by annotated
  arrows placed alongside lines connecting boxes
  containing the names of actors.

40
Elevator Problem OOD (contd)

• Step 2. Construct Detailed Class Diagram
• insert methods into the class diagrams of the OOA
  phase
• Do we assign an action to a class or to a client
  of that class?
• a client of an object is the unit that sends a
  message to that object.

41
Elevator Problem OOD (contd)

• Step 2. Construct Detailed Class Diagram
• Criteria
• Information hiding
• actions performed on state variables must be
  local to that class
• Reducing number of copies of action
• better to have one object do the action
• than many clients do the action
• Responsibility-driven design
• objects are responsible for carrying out the
  request of the client

42
Elevator Problem OOD (contd)

• Examples
• close doors is assigned to Elevator Doors
• move one floor down is assigned to Elevator

43
Elevator Problem OOD (contd)

• Detailed class diagram
• two groups of responsibilities
• responsibilities 8. Start timer, 10. check
  requests, and 11. Update requests were assigned
  to the elevator controller on the basis of
  responsibility-driven design.

44
Elevator Problem OOD (contd)

• the 8 remaining responsibilities (1-7, and 9 )
  have the form send a message to another class to
  tell it to do something
• responsibility-driven design assign methods to
  objects that receive messages

45
Elevator Problem OOD (contd)

• example methods close doors and open doors were
  assigned to the class Elevator Doors.
• because a client of Elevator Doors (Elevator
  Controller) sends a message to an object of the
  class Elevator Doors.

46
Elevator Problem OOD (contd)

• example methods move down one floor and move up
  one floor were assigned to the class Elevator.
• if neither method is invoked, elevator cannot
  move.

47
Elevator Problem OOD (contd)

• example methods turn button off and turn button
  on were assigned to both class Elevator Button
  and Floor Button.
• Principles responsibility driven design button
  control themselves.
• encapsulation internal state of a button is
  hidden.

48
Elevator Problem OOD (contd)

• Polymorphism
• methods turn button on and turn button off are
  declared abstract (virtual) in base class Button.

49
Elevator Problem OOD (contd)

• Step 3. Design product in terms of clients of
  objects
• use the interaction diagrams to draw a diagram
  showing the clients of each object.
• Draw an arrow from an object to a client of that
  object
• an object C that sends a message to object O is a
  client of O

50
Elevator Problem OOD (contd)

• Objects that are not clients of any object have
  to be initiated, probably by the main method
• Additional methods may be needed
• C function main must invoke object elevator
  controller.
• often a simple main program starts things off
  then objects take over.

51
Elevator Problem OOD (contd)

• C Client-object relations. Constructed
  directly from the collaboration diagrams.

52
Elevator Problem OOD (contd)

• Java Client-object relations

53
Elevator Problem OOD (contd)

• Must verify that all required methods have been
  assigned to each object
• I.e., object can respond to each of the possible
  messages sent to it.
• see that elevator controller needs method
  elevator control loop so that main (or elevator
  application) can call it

54
Elevator Problem OOD (contd)

• Step 4. Perform detailed design for all classes
• Detailed design of method elevator controller
  loop
• used pseudo-code here
• created from the state diagram of OOA.

55
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 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

56
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 software
• Communications implications
• Timing issues
• Problems of synchronization
• Race conditions
• Deadlock (deadly embrace)
• Major difficulty in design of real-time systems
• Determining whether the timing constraints are
  met by the design

57
Real-Time Design Methods

• Usually, extensions of nonreal-time methods to
  real-time
• We have limited experience in use of any
  real-time methods
• The state-of-the-art is not where we would like
  it to be

58
Testing during the Design Phase

• Design reviews
• Design must correctly reflect specifications
• Design itself must be correct
• no logic faults
• all interfaces correctly defined
• important that any faults in the design be
  detected before coding. Otherwise cost of fixing
  goes way up.
• use design inspections and design walkthroughs
• Transaction-driven inspections

59
CASE Tools for the Design Phase

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

60
Metrics for the Design Phase

• The five basic metrics
• Cyclomatic complexity is problematic
• cyclomatic complexity M of a detailed design is
  the number of binary decisions plus 1
• or equivalently the number of brancehs in the
  module.
• has been suggested that cyclomatic complexity is
  a metric of design quality the lower the value
  of M the better.
• Data complexity is ignored only measures control
  complexity
• Little use with object-oriented paradigm

61
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

62
Step 1. Interaction Diagrams

• Extended scenario for making a reservation

63
Step 1. Interaction Diagrams (contd)

• Sequence diagram for making a reservation
• first determine the actors of the scenario.
• then take each event in the scenario and draw an
  arrow between the instances of the relevant
  classes.

64
Step 1. Interaction Diagrams (contd)

• Creating the collaboration diagram
• examine the extended scenario and determine the
  actors
• Air Gourmet Staff Member
• passenger
• Air Gourmet database
• Draw actors
• Examine each event in scenario and enter into
  diagram
• labeled arrow is inserted to denote messages

65
Step 1. Interaction Diagrams (contd)

• Collaboration diagram for sending and returning a
  postcard

66
Step 2. Detailed Class Diagram

• The methods for the product appear in the various
  interaction diagrams designed earlier.
• Designer must decide to which class each method
  should be assigned.

67
Step 2. Detailed Class Diagram

• C version Java version

68
Step 3. ClientObject Relations

• Show the product in terms of objects and their
  clients.
• These are not UML diagrams.
• Diagrams of this kind can assist in gaining an
  understanding of how the various pieces of the
  product fit together.
• Also make the detailed design easier.

69
Step 3. ClientObject Relations

• C version Java version

70
Step 4. Detailed Design

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

71
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
• dont let the programmer do the detailed design.
• We need to grow great designers