You are on page 1of 42

Slide 8A.

An Introduction to
Object-Oriented
Systems Analysis and Design
with UML and
the Unified Process
McGraw-Hill, 2004

Stephen R. Schach
srs@vuse.vanderbilt.edu
Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

CHAPTER 8 Unit A

Slide 8A.2

THE OBJECT-ORIENTED DESIGN WORKFLOW

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

Chapter Overview

Slide 8A.3

The Design Workflow


Traditional versus Object-Oriented Design
Formats of the Attributes
Allocation of Operations to Classes
Allocation of Operations: Osbert Oglesby Case Study
CRC Cards

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

The Design Workflow

Slide 8A.4

The input to the design workflow is the set of


analysis workflow artifacts
These artifacts are iterated and incremented until they can
be used by the programmers

A major aspect of this iteration and incrementation is


The identification of operations, and
Their allocation to the appropriate classes

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

The Design Workflow (contd)

Slide 8A.5

Many other decisions have to be made as part of the


design workflow, including
Choice of programming language
Deciding how much of existing information systems to
reuse in the new information system
Level of portability
The allocation of each software component to its hardware
component

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

The Design Workflow (contd)

Slide 8A.6

The case studies in this book are small-scale


information systems
Under 5,000 lines of Java or C++ code in length

The Unified Process was designed for developing


large-scale information systems
500,000 lines of code or more
These information systems are at least 100 times larger
than the case studies presented in this book

Therefore, many aspects of the Unified Process are


inapplicable to the two case studies in this book
Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

The Design Workflow (contd)

Slide 8A.7

During the analysis workflow, a large information


system is partitioned into analysis packages
Each analysis package consists of a set of related classes
that can be implemented as a single unit
Example:
Accounts payable, accounts receivable, and general ledger are
typical analysis packages

The concept underlying analysis packages is:


It is easier to develop smaller information systems than
larger information systems
A large information system will be easier to develop if it
can be decomposed into independent packages
Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

The Design Workflow (contd)

Slide 8A.8

The idea of decomposing a large workflow into


independent smaller workflows 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 two case


studies into subsystemsthey are just too small
Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

The Design Workflow (contd)

Slide 8A.9

Reasons why subsystems are utilized


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 information system as a whole can then be delivered sooner

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

The Design Workflow (contd)

Slide 8A.10

The architecture of an information system includes


The various component modules
How they fit together
The allocation of components to subsystems

The task of designing the architecture is specialized


It is performed by an information system architect

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

The Design Workflow (contd)

Slide 8A.11

The architect needs to make trade-offs


Every information system 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 within the


time constraint

The architect must assist the client by laying out the


trade-offs
Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

The Design Workflow (contd)

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

Slide 8A.12

The client has to


Relax some of the requirements;
Increase the budget; and/or
Move the delivery deadline

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

The Design Workflow (contd)

Slide 8A.13

The architecture of an information system 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 suboptimal


architecture
The architecture must immediately be redesigned
Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Traditional versus Object-Oriented Design

Slide 8A.14

In the traditional paradigm, the design phase


consists of
Architectural design
The information system is decomposed into modules

followed by
Detailed design
Algorithms and data structures are designed for each module

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

Traditional versus Object-Oriented Design (contd)


Slide 8A.15

Classes are modules


Much of traditional architectural design is performed as part
of class extraction in the object-oriented analysis workflow

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

The Design Workflow (contd)

Slide 8A.16

Much of object-oriented design requires knowledge


of programming
Programming knowledge is not a prerequisite for this book

In this chapter a description is therefore given of just


one design artifact, the complete class diagram

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

Formats of the Attributes

Slide 8A.17

As part of the design workflow, the exact format of


each attribute of the class diagram must be
specified
Example: A date is usually represented by 10 characters
For instance, December 3, 1947 is represented as
12/03/1947 in the United States (MM/DD/YYYY format), and
03/12/1947 in Europe (DD/MM/YYYY format)

For both date conventions, 10 characters are needed

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

Formats of the Attributes (contd)

Slide 8A.18

The formats could be determined during the analysis


workflow

However, the object-oriented paradigm is iterative


Information is added to models as late as possible

Adding an item too early will make the next iteration


unnecessarily burdensome
Formats are therefore added during the design workflow

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

Formats of Attributes of Osbert Oglesby

Slide 8A.19

Class diagram with the formats of attributes added

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

Formats of Attributes of Osbert Oglesby (contd)


Slide 8A.20

Examples:
First name of an artist is up to 20 characters in length,
optionally followed by ? if there is uncertainty
firstNameOfArtist : 21 chars

Title is up to 40 characters in length, optionally with ?


title : 41 chars

Height and width are measured in centimeters


height, width : 4 digits (up to 9999 centimeters, or 99.99 meters)

Prices
targetSellingPrice, actualSellingPrice, maxPurchasePrice : 8 digits
(up to $99,999,999)

Dates
dateOfPurchase, dateOfSale, auctionDate : 10 chars
Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Formats of Attributes of Osbert Oglesby (contd)


Slide 8A.21

Fashionability coefficient
This could be a large number or a small number

The range can be determined only by computing


coefficients from a sample of Osberts sales
High: 985 (Rembrandt van Rijn)
Low: 0.064 (Joey T. Dog)

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

Formats of Attributes of Osbert Oglesby (contd)


Slide 8A.22

For safety, coefficient is of type 4 + 4 digits

Range is
High: 9999.9999
Low: 0.0001

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

Formats of Attributes of MSG Case Study

Slide 8A.23

Class diagram with the formats of attributes added

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

Formats of Attributes of MSG Case Study (contd)


Slide 8A.24

Example:
An asset number consists of 12 characters
assetNumber : 12 digits

Annual operating expenses are up to $999,999,999.99


estimatedAnnualOperatingExpenses : 9 + 2 digits

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

Allocation of Operations to Classes

Third iteration of the initial MSG class diagram

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

Slide 8A.25

Allocation of Operations to Classes (contd)

Slide 8A.26

There are empty rectangles at the bottoms of the


boxes
The operations of the classes are missing from this class
diagram

It is unwise to add an item to a UML diagram before


it is strictly necessary to do so
The Unified Process is iterative

The operations are deduced from the interaction


diagrams of the realizations of the use cases
These are produced after the class diagram
Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Allocation of Operations to Classes (contd)

Slide 8A.27

First the initial class diagram is determined


Then the interaction diagrams of the realizations of the
use cases

These interaction diagrams are used to deduce the


operations
Only then can the operations be allocated to the classes

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

Allocation of Operations to Classes (contd)

Slide 8A.28

Identifying the operations to be allocated to the


various classes is easy

Determining to which class each operation should


be allocated is hard

Three criteria are used


Responsibility-driven design
Inheritance
Polymorphism and dynamic binding (Chapter 20)

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

Responsibility-Driven Design

Slide 8A.29

The principle of responsibility-driven design


If Class A sends a message to Class B telling it to do
something, it is the responsibility of Class B to perform
the requested operation

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

Responsibility-Driven Design

Example:
MSG Foundation
case study

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

Slide 8A.30

Responsibility-Driven Design (contd)

Slide 8A.31

The weekly return on investments is computed by


summing the estimated annual return of each
investment and dividing by 52
The sequence diagram includes the message
3:Request estimated return on investments for week

The MSG Foundation case study must therefore


include the operation getAnnualReturnOnInvestment
Thus, for each object of class Investment Class, the
estimated annual return on that investment can be
determined

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

Responsibility-Driven Design (contd)

Slide 8A.32

It is not important which class sends that message

What is important is that Investment Class has the


responsibility of determining the annual return on an
investment
Accordingly, operation getAnnualReturnOnInvestment must be
allocated to Investment Class

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

Responsibility-Driven Design (contd)

Allocation of getAnnualReturnOnInvestment

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

Slide 8A.33

Inheritance

Suppose an operation is applicable to


An instance of a superclass; and to
Instances of subclasses of that superclass

Allocate that operation to the superclass

Then there is just one version of that operation

It can be used by
Instances of the superclass and by
Instances of all its subclasses
Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Slide 8A.34

Inheritance (contd)

Slide 8A.35

Convention in an object-oriented information system


Associated with each attribute of a class are operations
setAttribute, used to assign a particular value to that attribute; and
getAttribute, which returns the current value of that attribute

Example: In the MSG case study every asset has an


asset number
Asset Class has an attribute assetNumber
Operation setAssetNumber is used to assign the number of the
asset to the object that represents that asset
Operation getAssetNumber is used to obtain the asset number of
the asset represented by that object

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

Inheritance (contd)

Slide 8A.36

To which class should operation


allocated?

In the traditional paradigm, there would be two


different versions of setAssetNumber, one for each of the
two types of asset

setAssetNumber

be

That is, there would have to be


setInvestmentNumber
setMortgageNumber

Two separate functions are needed because the


traditional paradigm does not support inheritance
Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Inheritance (contd)

In the object-oriented paradigm


Consider the MSG inheritance hierarchy

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

Slide 8A.37

Inheritance (contd)

Slide 8A.38

Asset Class has attribute assetNumber


Inherited by Investment Class and Mortgage Class
Thus
Every instance of class Investment Class, and
Every instance of class Mortgage Class

has attribute assetNumber that consists of 12 characters

Any operation of class Asset Class that could be


applied to attribute assetNumber
Can also be applied to attribute assetNumber of
Every instance of class Investment Class, and
Every instance of class Mortgage Class
Copyright 2004 by The McGraw-Hill Companies, Inc. All rights reserved.

Inheritance (contd)

Allocation of setAssetNumber, getAssetNumber

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

Slide 8A.39

Inheritance (contd)

Operation setAssetNumber can then be applied to


instances of
Class Investment Class or
Class Mortgage Class

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

Slide 8A.40

Allocation of Operations: Osbert Oglesby

Slide 8A.41

Fifth iteration of the initial class diagram

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

Slide 8A.42

Continued in Unit 8B

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