Weitere ähnliche Inhalte
Kürzlich hochgeladen (20)
Umldistilled
- 1. © 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
Page 2 © Martin Fowler 8/13/98
1
- 2. 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
Page 3 © Martin Fowler 8/13/98
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)
Page 4 © Martin Fowler 8/13/98
2
- 3. 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
Page 5 © Martin Fowler 8/13/98
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
Page 6 © Martin Fowler 8/13/98
3
- 4. 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
Page 7 © Martin Fowler 8/13/98
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
Page 8 © Martin Fowler 8/13/98
4
- 5. 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
Page 9 © Martin Fowler 8/13/98
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
Page 10 © Martin Fowler 8/13/98
5
- 6. 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?
Page 11 © Martin Fowler 8/13/98
Granularity of Use Cases
Take Order
Price Order
Take Order
Customer Discounts
Bonnie Prince
Discount Plan
Combination Pricing
Rules
Page 12 © Martin Fowler 8/13/98
6
- 7. 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
Page 13 © Martin Fowler 8/13/98
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
Page 14 © Martin Fowler 8/13/98
7
- 8. 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
Page 15 © Martin Fowler 8/13/98
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?
Page 16 © Martin Fowler 8/13/98
8
- 9. 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
Page 17 © Martin Fowler 8/13/98
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.
Page 18 © Martin Fowler 8/13/98
9
- 10. 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
Page 19 © Martin Fowler 8/13/98
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?
Page 20 © Martin Fowler 8/13/98
10
- 11. 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?
Page 21 © Martin Fowler 8/13/98
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
Page 22 © Martin Fowler 8/13/98
11
- 12. 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
Page 23 © Martin Fowler 8/13/98
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?
Page 24 © Martin Fowler 8/13/98
12
- 13. 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.
Page 25 © Martin Fowler 8/13/98
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
Page 26 © Martin Fowler 8/13/98
13
- 14. 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.
Page 27 © Martin Fowler 8/13/98
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.
Page 28 © Martin Fowler 8/13/98
14
- 15. 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
Page 29 © Martin Fowler 8/13/98
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
Page 30 © Martin Fowler 8/13/98
15
- 16. Simple Activity Diagram
H
q Similar to a flow chart
Receive Order
Assign Goods to
Order
Authorize [failed]
Cancel Order
Payment
[suceeded]
Dispatch Order
Page 31 © Martin Fowler 8/13/98
Decision Notation
H
q More similar to flow
Receive Order chart notation
Assign Goods to
Order
[payment rejected]
Cancel Order
[payment authorized]
Dispatch Order
Page 32 © Martin Fowler 8/13/98
16
- 17. Introducing Parallel Behavior
H
Receive Order
Assign Goods to Authorize [failed]
Cancel Order
Order Payment
[suceeded]
Dispatch Order
q Sequence is independent
Page 33 © Martin Fowler 8/13/98
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
Page 34 © Martin Fowler 8/13/98
17
- 18. Multiple Diagrams (1)
H
Receive Order
*[for each line item]
Check Line Item
[in stock]
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 Order could be held up for stock
Page 35 © Martin Fowler 8/13/98
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
Page 36 © Martin Fowler 8/13/98
18
- 19. Combining Diagrams
H
H
Receive
Incoming Goods Receive Order
*[for each line item]
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
[stock assigned to all items and payment authorized]
Dispatch Order
Page 37 © Martin Fowler 8/13/98
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
Page 38 © Martin Fowler 8/13/98
19
- 20. 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?
Page 39 © Martin Fowler 8/13/98
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?
Page 40 © Martin Fowler 8/13/98
20
- 21. 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
Page 41 © Martin Fowler 8/13/98
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
Page 42 © Martin Fowler 8/13/98
21