Martin Fowler: What We Will Cover

© Martin Fowler, 1998
Martin Fowler
fowler@acm.org
http://ourworld.compuserve.com/homepages/Martin_Fowler
Page 1 © Martin Fowler 8/13/98
What We Will Cover (1)

q Background to UML
q Outline process
q Grand Tour of Techniques
â Use Cases
â Class Diagrams
â CRC Cards
â Both kinds of Interaction Diagrams
â Package Diagrams
â State Diagrams
â Activity Diagrams
â Design by Contract
http://ourworld.compuserve.com/homepages/Martin_Fowler
1
OO Methods
Coad
Coad
Wirfs-Brock
Wirfs-Brock/ /
Late 80’s RDD
RDD
early 90’s Shlaer
Odell
Odell/ /OOIE
OOIE Shlaer/ /
Mellor
Mellor
Rumbaugh Jacobson
Jacobson/ /
Booch Rumbaugh/ /
Booch OMT Objectory
Objectory
OMT
Evolution of the UML
1988-92 Many analysis and design books

1993 Standardization not a priority
1994 Jim Rumbaugh joins Rational (Grady
Booch)
1995 Booch/Rumbaugh unified method
released, Rational buys Objectory (Ivar
Jacobson), OMG task force launched
(chairs Mary Loomis and Jim Odell)
Jan 97 UML 1.0 submitted to OMG as proposal
Mid 97 OMG proposals unified behind UML 1.1
Late 97 OMG adopts UML 1.1 as OMG UML 1.0
Spr 98 OMG to issue UML 1.2 (minor changes)
2
Unified Modeling Language
(UML)
q Developed by the three amigos: Booch,
Jacobson and Rumbaugh at Rational
â Many contributions through OMG process
q Notation and semantics, not process
q Organizations preparing processes
â Rational: Objectory (Unified Process)
â HP: Fusion
Fowler M with Scott K, UML Distilled:

Applying the Standard Object Modeling
Language, Addison-Wesley, 1997
www.rational.com/uml
UML Books
q Three amigos books

â User Guide, Reference, and Unified Process
â End 98
q Fowler: UML Distilled, Addison-Wesley
â Concise guide, assumes you know OO design
q Larman: Applying UML and Patterns, Prentice
Hall
â Intro to Objects using UML
q Martin and Odell, OO Methods a Foundation,
Prentice Hall
â Conceptual Modeling
q Douglass, Real-Time UML, Addison-Wesley
â Real Time
3
Use-cases
q A use case is a typical interaction with the

system
â Recognizable value to the user - meets a goal
â Testable
What would be some use cases for a Word

Processor?
http://members.aol.com/acockburn
Incremental Development
Development
Exploration
1 2 ...
Finishing Finishing
Goal: Reduce Risk
Cockburn A. Surviving Your Object-

Oriented Project, Addison-Wesley, 1998
McConnell S. Rapid Development,
Microsoft Press 1996
4
Development
q Break into increments

â Build a few use-cases
â Analysis, design, implementation, testing, and
integration
â Demo to user and verify functional tests for those
use-cases
â Step length 2 weeks to 2 months
q Do high risk and high priority use-cases first
q Time box the steps
â Cannot slip dates, may put off use-cases
Goal: Have clear milestones to measure progress

Goal: Tackle high risks early
Exploration
q Gather use-cases
â One or two paragraphs
q Outline conceptual model
â Find key abstractions in conceptual problem
q Baseline technical architecture
â Try out key pieces of technology and how they fit
together
â Determine key packages and interfaces
q About 1/5 of project length
Goal: Gain understanding to reduce risks in later

development
5
Dividing Use Cases
q Capture basic order information
â Customer, date received
â Line items: quantity and product
q Price order
â Rules vary with products, different price thresholds
and options.
â May be combination rules
q Discount plans
â Customers may be members of various discount
plans.
â Plans apply various discounts to orders
â A particularly involved discount plan is the “bonnie
prince” plan
How many use cases here?
Granularity of Use Cases
Take Order
Price Order
Take Order
Customer Discounts
Bonnie Prince
Discount Plan
Combination Pricing
Rules
6
The «extends» Notion
Take Order
«extends» «extends»
Price Order Customer Discounts
«extends»
«extends»
Combination Pricing Bonnie Prince

Rules Discount Plan
q Simple case and variations
Use-case Diagram
Use Case
Actor
Set Limits
«uses»
Trading Manager
Analyze Risk
«uses» Valuation
Trader Price Deal
«extends» Capture Deal

Salesman
Limits Exceeded
q Shows use cases and links between them

â Actors
â Uses and extends
q Can be useful but not essential
7
Cockburn’s Style
q Base on the goal of a user

q Consider main course scenario
â Everything goes well and goal succeeds
â Capture as sequence of steps
q Take each step in the use case
â Ask what can go wrong
â Can we recover, if so how
â Each step may be another use case with its own
goal
q Capture variations in main course
q Note priority, time to be done in, and frequency
http://members.aol.com/acockburn
Abuse Cases
q Decomposition
â Temptation to drive design
â Takes time (for little value)
q Abstraction
â Loses users
â Less value in testing
q GUI prototypes
â False sign of progress
â Encourages scope growth
q Denying choice
â System v user use cases
Have you seen these traps?
8
Class Diagrams
Order Association Customer

Date received
] 1 Name
isPrepaid Address
Number Credit Rating
Price Constraint
Generalization
Dispatch
Close
{Orders for a customer with poor
1 credit rating must be prepaid}
Corporate Personal
Customer Customer
] Contact Name Credit card #
Attributes Credit Rating
Order Line
Credit Limit
product Remind
quantity
price Class
Operations
Modeling Perspectives
q Conceptual
â Describes people’s perception of the world
â Independent of software
q Specification
â Interfaces of classes (types)
q Implementation
â Internal features of a class
Cook, S. and Daniels, J. Designing Object Systems: object-

oriented modeling with Syntropy, Prentice Hall
International, Hemel Hempstead, UK, 1994.
9
Association
An employee must have a single department
1 [ [
Department Employee Skill
[
notation
for cardinalities
q Defines connections between instances

â Conceptual: employees must have a single
department
â Specification: you can ask an employee object for
its department (and change it)
â Implementation: employee has a pointer to a
department
q Uni-directional and bi-directional
Generalization
A nurse is a kind of a person
Person
Doctor Nurse
q Conceptual: all nurses are people

q Specification: (subtyping) nurse satisfies the
interface of person (substitutable)
q Implementation: nurse is a subclass of person
(inherits data and behavior)
At what stages would you use which

perspective?
10
Dangers of Class Diagrams
q Emphasis on structure of classes

â May lead to data models
â De-emphasis on behavior
â Lost in details
â Over-powerful abstractions
How can you tell when you have the right

model?
Class, Responsibility,
Collaboration: CRC
Order
Check Items are in Stock Order Line
Determine the price Order Line
Check for valid payment Customer
Dispatch to delivery
address
q Developed by Ward Cunningham and

Kent Beck
q Informal technique
q Concentrates on behavior, not data
11
Interaction (Sequence)
an Order Entry
Diagrams
an Order an Order Line a Stock Item
window
prepare()
* prepare()
hasStock :=
Message check() Condition
Object
Iteration [hasStock]
remove()
needsReorder :=
needsToReorder()
self
delegation
return
[needsReorder] new
a Reorder
Item
[hasStock] new
a Delivery
Item
deletion
creation
q Many objects in one use-case

Interaction (Collaboration)
Diagrams
:Order Entry Window Object
1:prepare()
message
:Order self sequence
1.1*[for all order 1.1.1: hasStock := check ()
delegation number
lines]: prepare () 1.1.2:[hasStock] remove ()
talisker line : Order Line talisker stock : Stock Item 1.1.2.1: needsReorder :=
needToReorder ( )
1.1.2.2: [needsReorder] new

1.1.3:[hasStock] new
: Delivery Item : reorder item
q Numbering shows sequence

q Control symbols
â * For iteration Which form would you
â [ ] For condition use?
12
Key Books for Base
Techniques
q Implementation focus: Booch, G. Object-
oriented Analysis and Design With
Applications, (Second Edition), Benjamin /
Cummings, Redwood City, CA, 1993.
q Conceptual Focus: Martin, J. And Odell, J.
Object Oriented Methods: a Foundation, (UML
Edition) Prentice Hall, Englewood Cliffs, NJ,
1998).
q For Responsibilities: Wirfs-brock R, Wilkerson
B and Wiener L (1990) Designing Object-
oriented Software, Prentice Hall, Englewood
Cliffs NJ.
Patterns
…projects fail despite the latest
technology for lack of ordinary
solutions.
Ralph Johnson and Ward Cunningham
q Patterns are the key to going beyond the

basics
q “Gang of Four” book
q Pattern Languages of Programming (PLoP)
conference
http://www.hillside.net/patterns
13
Design Pattern: Proxy
Subject
request()
realSubject.request()
Real Subject Proxy
request() 1 request()
q Provide a surrogate or placeholder for another

object to control access to it
Gamma, E., Helm, R., Johnson, R. and Vlissides, J. Design

Patterns: elements of reusable object-oriented software, Addison-
Wesley, Reading, MA, 1995.
Analysis Patterns
Scenario Timepoint
[ 1
1
[
1 Scenario [
Instrument Money
[ Element 1
q Prices of instruments change over time

q Hypothetical combinations of prices
q Prices of one instrument can affect others
Create a scenario to capture the real or
hypothetical state of the market.
14
Packages
Stocks
Pricer UI Portfolio UI Martin, R.C. Designing
Object-Oriented C++
Applications Using the
GUI Library Booch Method, Prentice
Stocks
Hall, Englewood Cliffs,
Portfolio
Pricer Application
NJ, 1995.
Dependency
Package
Stocks Scenario
Positions
Database Manager
q Classes grouped into packages (categories)

q Dependency (visibility) relationships
between packages
q Classes within package marked public or
private
Harel Statechart
H Wait Open
close safe
candle removed [door closed] door opened key turned [candle in]
Active
Lock
catch released / reveal lock
Catch exit / hide lock
key turned [candle out]
Final
H entry / release killer rabbit
q Single object in many use-cases

15
Simple Activity Diagram
H
q Similar to a flow chart

Receive Order
Assign Goods to
Order
Authorize [failed]
Cancel Order
Payment
[suceeded]
Dispatch Order
Decision Notation
H
q More similar to flow

Receive Order chart notation
Assign Goods to
Order
[payment rejected]
Cancel Order
[payment authorized]
Dispatch Order
16
Introducing Parallel Behavior
Receive Order
Assign Goods to Authorize [failed]

Cancel Order
Order Payment
[suceeded]
Dispatch Order
q Sequence is independent
Adding Iteration
H
Receive Order
*[for each line item]
Assign Goods to
Item
Authorize [failed]
Cancel Order
[need to reorder] Payment
[suceeded]
Reorder Goods
[stock assigned to all items and payment authorized]
Dispatch Order
q Iteration also occurs in parallel
17
Multiple Diagrams (1)
H
Receive Order
Check Line Item
[in stock]
Assign Goods to
Item
Authorize [failed]
Cancel Order
[need to reorder] Payment
[suceeded]
Reorder Goods
Dispatch Order
q Order could be held up for stock
Multiple Diagrams (2)

H
Receive
Incoming Goods
Choose
outstanding
order items
*[for each chosen item]
Assign Goods to
Item
[stock assigned to all

items and payment [all chosen items assigned]
authorized]
Add Remainder
Dispatch Order
to Stock
q May also lead to dispatch order

18
Combining Diagrams
H
H
Receive
Incoming Goods Receive Order

Choose
outstanding
order items Authorize
Check Line Item
Payment
*[for each
chosen item]
[in stock] [suceeded] [failed]
Assign Goods to
Item Assign Goods to
Item
Cancel Order
[all chosen [need to reorder]

items
assigned]
Reorder Goods
Add Remainder
to Stock
Dispatch Order
Design by Contract
Square Root
q Inputs
â x : Real Number
q Output
â result : Real Number
q Pre-condition
â x 0 o Also uses class
q Post-condition invariants
â result * result == x
q Exceptions
â none
Meyer, B. Object-Oriented Software Construction,
Prentice-Hall, New York, 1996
Meyer, B. “Applying “Design by Contract”,” IEEE
Computer, 25,10, (1992), pp. 40–51.
www.eiffel.com
19
CASE Tools
Evaluate what you are getting
q Design Document
â Drawing facilities
â Repository reports
â Uses right set of UML for you?
â Selectivity
q Code Generation
â Can you work with the code?
â Updated code fed back into model?
What is your favorite CASE tool?
Translation
Capture
specifics of Domain Analysis
domain
Model Compiler Final System
Rules for your Archetypes
platform
q Advocated by Shlaer/Mellor
â Basic idea also used by ObjectTime
4 Easy regeneration of system to different
platforms
4 Can reuse the archetypes
8 Does it work in practice?
20
Why use these techniques?
q Start small, add notation as needed

q Experiment with different things
â throw away what does not work
â different teams have different needs
q UML can communicate with programmers and
domain experts
A method is not enough
q Using a method will not make or break your

project
q The choice of training and mentoring will make

or break your project
21

Martin Fowler: What We Will Cover

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Martin Fowler: What We Will Cover

Uploaded by

Copyright:

Available Formats

© Martin Fowler, 1998

Page 1 © Martin Fowler 8/13/98

What We Will Cover (1)

Page 3 © Martin Fowler 8/13/98

Evolution of the UML

1988-92 Many analysis and design books

Page 4 © Martin Fowler 8/13/98

Fowler M with Scott K, UML Distilled:

Page 5 © Martin Fowler 8/13/98

q Three amigos books

Page 6 © Martin Fowler 8/13/98

q A use case is a typical interaction with the

What would be some use cases for a Word

Page 7 © Martin Fowler 8/13/98

Goal: Reduce Risk

Cockburn A. Surviving Your Object-

Page 8 © Martin Fowler 8/13/98

q Break into increments

Goal: Have clear milestones to measure progress

Goal: Gain understanding to reduce risks in later

Page 10 © Martin Fowler 8/13/98

How many use cases here?

Page 11 © Martin Fowler 8/13/98

Granularity of Use Cases

Page 12 © Martin Fowler 8/13/98

Price Order Customer Discounts

Combination Pricing Bonnie Prince

q Simple case and variations

Page 13 © Martin Fowler 8/13/98

Trader Price Deal

«extends» Capture Deal

q Shows use cases and links between them

q Base on the goal of a user

Page 15 © Martin Fowler 8/13/98

Have you seen these traps?

Page 16 © Martin Fowler 8/13/98

Order Association Customer

Page 17 © Martin Fowler 8/13/98

Cook, S. and Daniels, J. Designing Object Systems: object-

Page 18 © Martin Fowler 8/13/98

q Defines connections between instances

q Conceptual: all nurses are people

At what stages would you use which

q Emphasis on structure of classes

How can you tell when you have the right

Page 21 © Martin Fowler 8/13/98

q Developed by Ward Cunningham and

Page 22 © Martin Fowler 8/13/98

q Many objects in one use-case

1.1.2.2: [needsReorder] new

: Delivery Item : reorder item

q Numbering shows sequence

Page 24 © Martin Fowler 8/13/98

Page 25 © Martin Fowler 8/13/98

Ralph Johnson and Ward Cunningham

q Patterns are the key to going beyond the

Page 26 © Martin Fowler 8/13/98

q Provide a surrogate or placeholder for another

Gamma, E., Helm, R., Johnson, R. and Vlissides, J. Design

q Prices of instruments change over time

q Classes grouped into packages (categories)

key turned [candle out]

H entry / release killer rabbit