Martin Fowler's 1998 Guide to UML Modeling Techniques

© 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 Odell / /OOIE Shlaer / /
Odell 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

H

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's 1998 Guide to UML Modeling Techniques

Recomendados

Recomendados

Mais conteúdo relacionado

Último

Último (20)

Destaque

Destaque (20)

Martin Fowler's 1998 Guide to UML Modeling Techniques