• Save
Upcoming SlideShare
Loading in...5

Like this? Share it with your network








Total Views
Views on SlideShare
Embed Views



1 Embed 2

http://localhost:8080 2



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Umldistilled Document Transcript

  • 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 needsReorder := needToReorder ( ) [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