Slide 14.
Object-Oriented and
Classical Software
Engineering
Eighth Edition, WCB/McGraw-Hill, 2011
Stephen R. Schach
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
CHAPTER 14 Slide 14.2
DESIGN
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
Overview Slide 14.3
Design and abstraction
Operation-oriented design
Data flow analysis
Transaction analysis
Data-oriented design
Object-oriented design
Object-oriented design: The elevator problem case
study
Object-oriented design: The MSG Foundation
case study
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
Overview (contd) Slide 14.4
The design workflow
The test workflow: Design
Formal techniques for detailed design
Real-time design techniques
CASE tools for design
Metrics for design
Challenges of the design workflow
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
Data and Actions Slide 14.5
Two aspects of a product
– Actions that operate on data
– Data on which actions operate
The two basic ways of designing a product
– Operation-oriented design
– Data-oriented design
Third way
– Hybrid methods
– For example, object-oriented design
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
14.1 Design and Abstraction Slide 14.6
Classical design activities
– Architectural design
– Detailed design
– Design testing
Architectural design
– Input: Specifications
– Output: Modular decomposition
Detailed design
– Each module is designed
» Specific algorithms, data structures
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
14.2 Operation-Oriented Design Slide 14.7
Data flow analysis
– Use it with most specification methods (Structured
Systems Analysis here)
Key point: We have detailed action information
from the DFD
Figure 14.1
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
Data Flow Analysis Slide 14.8
Every product transforms input into output
Determine
– “Point of highest abstraction of input”
– “Point of highest abstract of output”
Figure 14.2
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
Data Flow Analysis (contd) Slide 14.9
Decompose the product into three modules
Repeat stepwise until each module has high
cohesion
– Minor modifications may be needed to lower the
coupling
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
14.3.1 Mini Case Study: Word Counting
Slide 14.10
Example:
Design a product which takes as input a file name, and
returns the number of words in that file (like UNIX wc )
Figure 14.3
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
Mini Case Study: Word Counting (contd)
Slide 14.11
First refinement
Figure 14.4
Now refine the two modules of communicational
cohesion
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
Mini Case Study: Word Counting (contd)
Slide 14.12
Second refinement
Figure 14.5
All eight modules now have functional cohesion
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
Word Counting: Detailed Design Slide 14.13
The architectural design is complete
– So proceed to the detailed design
Two formats for representing the detailed design:
– Tabular
– Pseudocode (PDL — program design language)
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
Detailed Design: Tabular Format Slide 14.14
Figure 14.6(a)
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
Detailed Design: Tabular Format (contd)
Slide 14.15
Figure 14.6(b)
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
Detailed Design: Tabular Format (contd)
Slide 14.16
Figure 14.6(c)
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
Detailed Design: Tabular Format (contd)
Slide 14.17
Figure 14.6(d)
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
Detailed Design: PDL Format Slide 14.18
Figure 14.7
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
14.3.2 Data Flow Analysis Extensions
Slide 14.19
In real-world products, there is
– More than one input stream, and
– More than one output stream
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
Data Flow Analysis Extensions (contd) Slide 14.20
Find the point of highest abstraction for each stream
Figure 14.8
Continue until each module has high cohesion
– Adjust the coupling if needed
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
14.4 Transaction Analysis Slide 14.21
DFA is poor for transaction processing products
– Example: ATM (automated teller machine)
Figure 14.9
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
Transaction Analysis (contd) Slide 14.22
This is a poor design
– There is logical cohesion and control coupling
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
Corrected Design Using Transaction Analysis
Slide 14.23
Software
reuse
Have one
generic edit
module, one
generic update
module
Instantiate
them 5 times
Figure 14.10
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
14.5 Data-Oriented Design Slide 14.24
Basic principle
– The structure of a product must conform to the structure
of its data
Three very similar methods
– Michael Jackson [1975], Warnier [1976], Orr [1981]
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
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
14.6 Object-Oriented Design (OOD) Slide 14.25
Aim
– Design the product in terms of the classes extracted
during OOA
If we are using a language without inheritance
(e.g., C, Ada 83)
– Use abstract data type design
If we are using a language without a type
statement (e.g., FORTRAN, COBOL)
– Use data encapsulation
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
Object-Oriented Design Steps Slide 14.26
OOD consists of two steps:
Step 1. Complete the class diagram
– Determine the formats of the attributes
– Assign each method, either to a class or to a client that
sends a message to an object of that class
Step 2. Perform the detailed design
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
Object-Oriented Design Steps (contd) Slide 14.27
Step 1. Complete the class diagram
– The formats of the attributes can be directly deduced
from the analysis artifacts
Example: Dates
– U.S. format (mm/mm/yyyy)
– European format (dd/mm/yyyy)
– In both instances, 10 characters are needed
The formats could be added during analysis
– To minimize rework, never add an item to a UML
diagram until strictly necessary
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
Object-Oriented Design Steps (contd) Slide 14.28
Step 1. Complete the class diagram
– Assign each method, either to a class or to a client that
sends a message to an object of that class
Principle A: Information hiding
Principle B: If an operation is invoked by many
clients of an object, assign the method to the
object, not the clients
Principle C: Responsibility-driven design
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
14.7 Object-Oriented Design: The Elevator Problem Case Study
Slide 14.29
Step 1. Complete the class diagram
Consider the second iteration of the CRC card for
the elevator controller
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
OOD: Elevator Problem Case Study (contd)
Slide 14.30
CRC card
Figure 13.9 (again)
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
OOD: Elevator Problem Case Study (contd)
Slide 14.31
Responsibilities
– 8. Start timer
– 10. Check requests, and
– 11. Update requests
are assigned to the elevator controller
Because they are carried out by the elevator
controller
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
OOD: Elevator Problem Case Study (contd)
Slide 14.32
The remaining eight responsibilities have the form
– “Send a message to another class to tell it do something”
These should be assigned to that other class
– Responsibility-driven design
– Safety considerations
Methods open doors, close doors are assigned to class
Elevator Doors Class
Methods turn off button, turn on button are assigned to
classes Floor Button Class and Elevator Problem
Class
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
Detailed Class Diagram: Elevator Problem
Slide 14.33
Figure 14.11
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
Detailed Design: Elevator Problem Slide 14.34
Detailed design
of elevatorEventLoop
is constructed
from the
statechart
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Figure 14.12
14.8 Object-Oriented Design: The MSG Foundation Case Study
Slide 14.35
Step 1. Complete the class diagram
The final class diagram is shown in the next slide
– Date Class is needed for C++
– Java has built-it functions for handling dates
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
Final Class Diagram: MSG Foundation Slide 14.36
Figure 14.13
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
Class Diagram with Attributes: MSG Foundation
Slide 14.37
Figure 14.14
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
Assigning Methods to Classes: MSG Foundation
Slide 14.38
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 14.15
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
Assigning Methods to Classes: MSG Foundation (contd)
Slide 14.39
Assigning the other methods is equally
straightforward
– See Appendix G
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
Detailed Design: MSG Foundation Slide 14.40
Determine what each method does
Represent the detailed design in an appropriate
format
– PDL (pseudocode) here
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
Method EstimateFundsForWeek::computeEstimatedFunds
Slide 14.41
Figure 14.16
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
Method Mortgage::totalWeeklyNetPayments Slide 14.42
Figure 14.17
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
14.9 The Design Workflow Slide 14.43
Summary of the design workflow:
– The analysis workflow artifacts are iterated and
integrated until the programmers can utilize them
Decisions to be made include:
– Implementation language
– Reuse
– Portability
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
The Design Workflow (contd) Slide 14.44
The idea of decomposing a large workflow into
independent smaller workflows (packages) is
carried forward to the design workflow
The objective is to break up the upcoming
implementation workflow into manageable pieces
– Subsystems
It does not make sense to break up the MSG
Foundation case study into subsystems — it is too
small
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
The Design Workflow (contd) Slide 14.45
Why the product is broken into subsystems:
– It is easier to implement a number of smaller
subsystems than one large system
– If the subsystems are independent, they can be
implemented by programming teams working in parallel
» The software product as a whole can then be delivered sooner
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
The Design Workflow (contd) Slide 14.46
The architecture of a software product includes
– The various components
– How they fit together
– The allocation of components to subsystems
The task of designing the architecture is
specialized
– It is performed by a software architect
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
The Design Workflow (contd) Slide 14.47
The architect needs to make trade-offs
– Every software product must satisfy its functional
requirements (the use cases)
– It also must satisfy its nonfunctional requirements,
including
» Portability, reliability, robustness, maintainability, and security
– It must do all these things within budget and time
constraints
The architect must assist the client by laying out
the trade-offs
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
The Design Workflow (contd) Slide 14.48
It is usually impossible to satisfy all the
requirements, functional and nonfunctional, within
the cost and time constraints
– Some sort of compromises have to be made
The client has to
– Relax some of the requirements;
– Increase the budget; and/or
– Move the delivery deadline
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
The Design Workflow (contd) Slide 14.49
The architecture of a software product is critical
– The requirements workflow can be fixed during the
analysis workflow
– The analysis workflow can be fixed during the design
workflow
– The design workflow can be fixed during the
implementation workflow
But there is no way to recover from a suboptimal
architecture
– The architecture must immediately be redesigned
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
14.10 The Test Workflow: Design Slide 14.50
Design reviews must be performed
– The design must correctly reflect the specifications
– The design itself must be correct
Transaction-driven inspections
– Essential for transaction-oriented products
– However, they are insufficient — specification-driven
inspections are also needed
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
14.11 The Test Workflow: The MSG Foundation Case Study
Slide 14.51
A design inspection must be performed
– All aspects of the design must be checked
Even if no faults are found, the design may be
changed during the implementation workflow
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
14.12 Formal Techniques for Detailed Design
Slide 14.52
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
» This should lead to fewer faults
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
14.13 Real-Time Design Techniques Slide 14.53
Difficulties associated with real-time systems
– Inputs come from the real world
» Software has no control over the timing of the inputs
– Frequently implemented on distributed software
» Communications implications
» Timing issues
– Problems of synchronization
» Race conditions
» Deadlock (deadly embrace)
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
Real-Time Design Techniques (contd) Slide 14.54
The major difficulty in the design of real-time
systems
– Determining whether the timing constraints are met by
the design
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
Real-Time Design Techniques (contd) Slide 14.55
Most real-time design methods are extensions of
non-real-time methods to real-time
We have limited experience in the use of any real-
time methods
The state-of-the-art is not where we would like it to
be
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
14.14 CASE Tools for Design Slide 14.56
It is critical to check that the design artifacts
incorporate all aspects of the analysis
– To handle analysis and design artifacts we therefore
need upperCASE tools
UpperCASE tools
– Are built around a data dictionary
– They incorporate a consistency checker, and
– Screen and report generators
– Management tools are sometimes included, for
» Estimating
» Planning
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
CASE Tools for Design (contd) Slide 14.57
Examples of tools for object-oriented design
– Commercial tools
» Software through Pictures
» IBM Rational Rose
» Together
– Open-source tool
» ArgoUML
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
14.15 Metrics for Design Slide 14.58
Measures of design quality
– Cohesion
– Coupling
– Fault statistics
Cyclomatic complexity is problematic
– Data complexity is ignored
– It is not used much with the object-oriented paradigm
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
Metrics for Design (contd) Slide 14.59
Metrics have been put forward for the object-
oriented paradigm
– They have been challenged on both theoretical and
experimental grounds
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
14.16 Challenges of the Design Phase
Slide 14.60
The design team should not do too much
– The detailed design should not become code
The design team should not do too little
– It is essential for the design team to produce a
complete detailed design
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
Challenges of the Design Phase (contd)
Slide 14.61
We need to “grow” great designers
Potential great designers must be
– Identified,
– Provided with a formal education,
– Apprenticed to great designers, and
– Allowed to interact with other designers
There must be a specific career path for these
designers, with appropriate rewards
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
Overview of the MSG Foundation Case Study
Slide 14.62
Figure 14.18
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
Overview of the Elevator Problem Case Study
Slide 14.63
Figure 14.19
Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved.
