Slide 12.

1
CHAPTER 12 Slide 12.2

Object-Oriented
Software Engineering THE DESIGN
WORKFLOW
WCB/McGraw-Hill, 2008

Stephen R. Schach
[email protected]

Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved.

Overview Slide 12.3

Overview (contd) Slide 12.4

z Object-oriented design z CASE tools for design

z Object-oriented design: The elevator problem case z Metrics for design
study z Challenges of the design workflow
z Object-oriented design: The MSG Foundation
case study
z The design workflow
z The test workflow: Design
z Formal techniques for detailed design
z Real-time design techniques

Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved.

Design Techniques Slide 12.5

12.1 Object-Oriented Design Slide 12.6

z Operation-oriented design z Aim

– The emphasis is on the operations – Design the product in terms of the classes extracted
– Weakness: The data are of secondary importance during the analysis workflow

z Data-oriented design z If we are using a language without inheritance

– The emphasis is on the data (e.g., C, Ada 83)
– Weakness: The operations are of secondary importance – Use abstract data type design

z Object-oriented design z If we are using a language without a type

– Gives equal weight to data and operations statement (e.g., FORTRAN, COBOL)
– Use data encapsulation

Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved.

1
 Object-Oriented Design Steps Slide 12.7
Object-Oriented Design Steps (contd) Slide 12.8

z OOD consists of two steps: z Step 1. Complete the class diagram

– The formats of the attributes can be directly deduced
from the analysis artifacts
z Step 1. Complete the class diagram
– Determine the formats of the attributes
– Assign each method, either to a class or to a client that
z Example: Dates
sends a message to an object of that class – U.S. format mm/dd/yyyy
– European format dd/mm/yyyy
z Step 2. Perform the detailed design – In both instances, 10 characters are needed

z The formats could be added during analysis

– To minimize rework, never add an item to a UML
diagram until strictly necessary
Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved.

Object-Oriented Design Steps (contd) Slide 12.9

Object-Oriented Design Steps (contd) Slide 12.10

z Assign each method, either to a class or to a client z Step 2. Perform the detailed design
that sends a message to an object of that class – Design each class in detail

z Principle A: Information hiding z Select specific algorithms

z Principle B: If an operation is invoked by many z Choose data structures

clients of an object, assign the method to the
object, not the clients

z Principle C: Responsibility-driven design

Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved.

Detailed Design of Method find of Class Mortgage Slide 12.11

Detailed Design in PDL Slide 12.12

z We can also write a detailed design in a program

description language (PDL)
– Formerly called pseudocode

z Next two slides:

z Java-like PDL description of detailed design of

– Method computeEstimatedFunds of class

EstimatedFundsForWeek
Figure 12.1

– Method totalWeeklyNetPayments of class Mortgage

Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved.

2
Method EstimatedFundsForWeek.computeEstimatedFunds
Slide 12.13
Method Mortgage.totalWeeklyNetPayments Slide 12.14

Figure 12.2 Figure 12.3

Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved.

12.2 Object-Oriented Design: Elevator Problem Slide 12.15

OOD: Elevator Problem Case Study (contd) Slide 12.16

z Step 1. Complete the class diagram z CRC card

z Assign the operations to the class diagram

Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Figure 11.9 (again)

OOD: Elevator Problem Case Study (contd) Slide 12.17

OOD: Elevator Problem Case Study (contd) Slide 12.18

z Responsibilities z The remaining eight responsibilities have the form

– 8. Start timer
– “Send a message to another class to tell it do something”
– 10. Check requests, and
– 11. Update requests
are assigned to the Elevator Controller Class z These should be assigned to that other class
– Responsibility-driven design
z Because they are carried out by the elevator – Safety considerations
controller
z Methods openDoors, closeDoors are assigned to Elevator
Doors Class

z Methods turnOffButton, turnOnButton are assigned to

Floor Button Class and Elevator Problem Class
Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved.

3
 Detailed Class Diagram: Elevator Problem Slide 12.19
Detailed Design: Elevator Problem Slide 12.20

z Detailed design
of elevatorEventLoop
is constructed
from the
statechart

Figure 12.4

Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Figure 12.5

12.3 Object-Oriented Design: MSG Foundation Slide 12.21

Final Class Diagram: MSG Foundation Slide 12.22

z Step 1. Complete the class diagram

z The final class diagram is shown in the next slide

– Date Class is needed for C++
– Java has built-it functions for handling dates

Figure 12.6

Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved.

Class Diagram with Attribute Formats: MSG Foundation

Slide 12.23
Assigning Methods to Classes: MSG Foundation Slide 12.24

z Example: setAssetNumber, getAssetNumber

– From the inheritance tree, these accessor/mutator
methods should be assigned to Asset Class
– So that they can be inherited by both subclasses of
Asset Class (Investment Class and Mortgage Class)

Figure 12.8
Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Figure 12.7 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved.

4
Assigning Methods to Classes: MSG Foundation (contd)
Slide 12.25
Detailed Design: MSG Foundation Slide 12.26

z Assigning the other methods is equally z Step 2. Perform the detailed design
straightforward
– See Appendix F z Determine what each method does

z Represent the detailed design in an appropriate

format
– Tabular format for method find of class Mortgage
» (see Slide 12.11)
– PDL (pseudocode) for method computeEstimatedFunds of
class EstimatedFundsForWeek and for method
totalWeeklyNetPayments of class Mortgage
» (see Slides 12.13, 12.14)
Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved.

12.4 The Design Workflow Slide 12.27

The Design Workflow (contd) Slide 12.28

z Summary of the design workflow: z The idea of decomposing a large workflow into
– The analysis workflow artifacts are iterated and independent smaller workflows (packages) is
incremented until the programmers can utilize them carried forward to the design workflow

z Decisions to be made include: z The objective is to break up the upcoming

– Implementation language implementation workflow into manageable pieces
– Reuse – Subsystems
– Portability

z It does not make sense to break up the MSG

Foundation case study into subsystems — it is too
small
Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved.

The Design Workflow (contd) Slide 12.29

The Design Workflow (contd) Slide 12.30

z Why the product is broken into subsystems: z The architecture of a software product includes
– The various components
– It is easier to implement a number of smaller – How they fit together
subsystems than one large system – The allocation of components to subsystems

– If the subsystems are independent, they can be z The task of designing the architecture is
implemented by programming teams working in parallel
specialized
» The software product as a whole can then be delivered sooner
– It is performed by a software architect

Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved.

5
 The Design Workflow (contd) Slide 12.31
The Design Workflow (contd) Slide 12.32

z The architect needs to make trade-offs z It is usually impossible to satisfy all the
– Every software product must satisfy its functional requirements, functional and nonfunctional, within
requirements (the use cases) the cost and time constraints
– It also must satisfy its nonfunctional requirements, – Some sort of compromises have to be made
including
» Portability, reliability, robustness, maintainability, and security
– It must do all these things within budget and time z The client has to
constraints – Relax some of the requirements;
– Increase the budget; and/or
– Move the delivery deadline
z The architect must assist the client by laying out
the trade-offs

Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved.

The Design Workflow (contd) Slide 12.33

12.5 The Test Workflow: Design Slide 12.34

z The architecture of a software product is critical z Design reviews must be performed

– The requirements workflow can be fixed during the – The design must correctly reflect the specifications
analysis workflow – The design itself must be correct
– The analysis workflow can be fixed during the design
workflow
– The design workflow can be fixed during the
z Transaction-driven inspections
implementation workflow – Essential for transaction-oriented products
– However, they are insufficient — specification-driven
inspections are also needed
z But there is no way to recover from a suboptimal
architecture
– The architecture must immediately be redesigned

Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved.

12.6 The Test Workflow: MSG Foundation Slide 12.35

12.7 Formal Techniques for Detailed Design Slide 12.36

z A design inspection must be performed z Implementing a complete product and then

– All aspects of the design must be checked proving it correct is hard
z However, use of formal techniques during detailed
z Even if no faults are found, the design may be design can help
changed during the implementation workflow – 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
» This should lead to fewer faults
Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved.

6
 12.8 Real-Time Design Techniques Slide 12.37
Real-Time Design Techniques (contd) Slide 12.38

z Difficulties associated with real-time systems z The major difficulty in the design of real-time
systems
– Inputs come from the real world – Determining whether the timing constraints are met by
» Software has no control over the timing of the inputs the design

– Frequently implemented on distributed software

» Communications implications
» Timing issues

– Problems of synchronization
» Race conditions
» Deadlock (deadly embrace)

Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved.

Real-Time Design Techniques (contd) Slide 12.39

12.9 CASE Tools for Design Slide 12.40

z Most real-time design methods are extensions of z It is critical to check that the design artifacts
non-real-time methods to real-time incorporate all aspects of the analysis
– To handle analysis and design artifacts we therefore
need upperCASE tools
z We have limited experience in the use of any real-
time methods
z UpperCASE tools
– Are built around a data dictionary
z The state-of-the-art is not where we would like it to
– They incorporate a consistency checker, and
be
– Screen and report generators
– Management tools are sometimes included, for
» Estimating
» Planning

Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved.

CASE Tools for Design (contd) Slide 12.41

CASE Tools for Design (contd) Slide 12.42

z Data z Examples of tools for the design workflow

dictionary – Commercial tools
entries for » Software through Pictures
class Asset » IBM Rational Rose
» Together
– Open-source tool
» ArgoUML

Figure 12.9

Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved.

7
 12.10 Metrics for Design Slide 12.43
Metrics for Design (contd) Slide 12.44

z Measures of design quality z Metrics have been put forward for the object-
– Cohesion oriented paradigm
– Coupling – They have been challenged on both theoretical and
– Fault statistics experimental grounds

z Cyclomatic complexity is problematic

– Data complexity is ignored
– It is not used much with the object-oriented paradigm

Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved.

12.11 Challenges of the Design Workflow Slide 12.45

Challenges of the Design Phase (contd) Slide 12.46

z The design team should not do too much z We need to “grow” great designers
– The detailed design should not become code
z Potential great designers must be
z The design team should not do too little – Identified,
– It is essential for the design team to produce a – Provided with a formal education,
complete detailed design – Apprenticed to great designers, and
– Allowed to interact with other designers

z There must be a specific career path for these

designers, with appropriate rewards

Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved.