1 / 44

An Introduction to Use Case Modeling

An Introduction to Use Case Modeling. Agenda. Requirements Use Cases Use Case Diagrams Use Case Scenarios Use Case Modeling with UML. Requirements. Look at how the traditional approach to requirements has severely limited our ability to satisfy our customer and stabilize our work effort.

Antony
Download Presentation

An Introduction to Use Case Modeling

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. An Introduction to Use Case Modeling

  2. Agenda • Requirements • Use Cases • Use Case Diagrams • Use Case Scenarios • Use Case Modeling with UML

  3. Requirements • Look at how the traditional approach to requirements has severely limited our ability to satisfy our customer and stabilize our work effort. • Establish a requirement structure that will help ask the right questions and capture the information the Architects, Developers, Testers, and others will need. • Recognize that requirements strategies for categorizing, relating and agreeing requirements can greatly minimize the risk for building the wrong product. • Embrace the critical nature of a user-centric approach and employ techniques which keep user satisfaction at the center of our effort.

  4. Owners To make sure they are getting the value they paid for Developers To make sure they know what to develop Testers To make sure they know what to test Managers To know where the system will be deployed Technical Writers To know how to document the system IT Operations/Support To know how to install and maintain the system Users To know how to use the system Who needs to understand the system?

  5. Exercise: Requirements Review • Situation • You have been handed these requirements, a deadline, and a budget. • Exercise • Break into groups of 3-4 people. • Review the sample requirements document to become familiar with what the business wants to achieve. • As you review, think about the requirements in the context of communication between the owners, developers, managers, testers, technical writers, IT operations, and users. • As a group, mark problems in the requirements.

  6. Use Cases Defined • In general, use cases are high-level, user-centric requirements. [Fowler] • A use case specifies a sequence of actions, including variants, which the system can perform and that yields an observable result of value to a particular actor. [Jacobson] • Use Cases are: • One of many techniques to elicit and elaborate user requirements. • A common presentation of requirements for different roles. • A handy unit of planning and estimation.

  7. Advantages of Use Cases • Avoid analysis paralysis • Use cases help break up the problem so it can be solved incrementally. Do just enough analysis to get started but we don’t have to worry that it’s hard to come back later and add more. • Avoid gold plating • Using use cases to derive functional requirements avoids stating a functional requirement that is not directly tied to a user task needed to accomplish a business goal.

  8. Use Case Diagrams • A cashier uses the POS system to scan an item. • A cashier uses the POS system to total items.

  9. System Boundary • Marks off the system as separate from its environment • Actors are outside • When no system boundary is shown, the system is assumed

  10. Actor • Someone or something outside the system that interacts with it • Actors represent “roles” not individuals

  11. Use Case • A use case achieves a goal of value to an actor • System does these things for actors • What system is for not how it does it • Starts with an active verb from the point of view of the system

  12. Communications • Lines between Actor and Use Case summarize interactions graphically • Actors and use cases exchange information to achieve the goal but the details of interaction are not shown

  13. Considerations for Use Case Diagrams • Do not represent the flow of information or sequence of events. • Do not represent communication between actors. Keep the focus on putting the system in context, not the actors. Actors may collaborate through a use case. • Actors are not always roles played by a person. Actors may represent the role played by anything that acts on the system such as another system.

  14. Use Case Diagram Summary • Show the system in its environment • Show what a system is used for • From a behavioral perspective: • For capturing functional requirements • For enabling incremental specification • To understand who the system is for • Details of interactions are not shown

  15. Levels of Use Cases • Use Case Diagrams can be at different levels of granularity: • One diagram can show a system-wide view with every actor • This diagram can be later refined into design-level use cases

  16. Use Case Analysis • When do we start use case analysis? • During requirements elicitation • Obtain agreement on major concepts • Actors, system boundaries, business use cases • Maybe as a sketch, transfer to tool later • During requirements analysis • Insure the right questions have been asked and answered • Supplement complex text with pictures • Disambiguate text with precise models • When do we stop doing use case analysis? • When the use cases meet the communication needs • Stakeholders reach consensus • Less is more

  17. Exercise: Use Case Diagrams • Situation • You want to put requirements into context with use cases. • Exercise • Break into groups of 3-4 people. • Using the sample requirements document sketch an initial use case diagram. • As you create the diagram, think about the interactions between the system and actors. • As a group, consider how this level of use case analysis adds value to the existing requirements.

  18. Scenarios • Scenario is another name for a particular flow of events. • A use case covers a range of situations – a scenario is just one. • Each use case typically has: • a main flow describing the “happy path” • alternate flows describing major exceptions • Several alternatives exist for specifying the use case scenarios.

  19. Write text to describe the interaction of the actor(s) and the system. Simple and easy approach May be limiting: Numerous alternate flows make it hard to understand where normal flow can branch. Long alternate flows need to be broken out as steps too. Use Case: Checks out item Customer sets item on counter. Sales clerk swipes UPC reader across UPC code on item. System looks up UPC code in database procuring item description and price. System emits audible beep. System announces item description and price over voice output. System adds price and item type to current invoice. System adds price to correct tax subtotal. Error case 1: UPC code unreadable If after step 2, the UPC code was invalid or was not properly read, emit an audible ‘bonk’ sound. Error case 2: No item in database If after step 3 no database entry is found for the UPC flash the ‘manual entry’ button on the terminal. Accept key entry of price and tax code from Sales Clerk. Set Item description to “Unknown item”. Go to step 4. Describing Scenarios Textually

  20. Describing Scenarios Graphically • Create an Activity Diagram to graphically show the interaction of the actor(s) and the system. • Requires a little UML savvy • Easy to slip into too much detail • Create a Sequence Diagram to graphically show the interaction of the actor(s) and the system. • Requires more UML savvy • Great start for design activities

  21. Exercise: Use Case Scenarios • Situation • You want to elaborate an initial use case sketch with a scenario for one of the use cases. • Exercise • Break into groups of 3-4 people. • Using the initial use case diagram, create a use case scenario. • As a group, try both approaches. One person can try to capture the flow textually and another graphically.

  22. Use Case Modeling with UML • In combination with plain text • Large volume of requirements difficult to consume as a whole • Modeling provides constructs to help organize ideas • Visualization helps clarify complex ideas • Standards bring focus to key abstractions • In contrast to ad-hoc diagrams • Standards facilitate precise communication • Common language for all members of the team • Reap the benefits of Model-Driven Development (MDD) • Get ready for Model-Driven Architecture (MDA)

  23. Use Case Diagrams as the Hub of Architectural Viewpoints Adapted from [Kruchten]

  24. Formal UML Use Case Diagrams

  25. The line between an actor and a use case is an association. The association means the actor is participating and/or communicating with the system via that use case. The meaning of the association can be refined with: Multiplicity Direction Labels Association

  26. Multiplicity • Typically, • An actor will have up to one interaction with a given use case. • A use case instantiation interacts with one and only one of a given actor. • Previous to UML 2.0 this was the default association. • There are cases where we have multiple interactions simultaneously.

  27. Direction • Indicates who initiates the communication • Warning: does not necessarily indicate flow of information!

  28. Labels • UML allows: • Labels for the association • Labels for roles on each end • Usage is uncommon and is not recommended

  29. Specialization/Generalization of Actors • One actor can be a specialization of another. • Arrow points to the more general (base) actor.

  30. Using Generalization

  31. How Use Cases are Related to Each Other • Generalization • One use case is a special case of another • Includes • Included use case embodies common behavior • Extends • Extending use case adds behavior

  32. Generalization • Shows inheritance and specialization • One use case is simply a special kind of another

  33. Includes • “Factor out” of a use case commonly used behavior • Allows reuse of functionality by multiple use cases

  34. Extends • Indicates that one use case adds or replaces behavior of another • Must have a an associated extension point • May have a condition

  35. Exercise: Use Cases in UML • Situation • You want to formalize the initial use case sketch as UML. • Exercise • Break into groups of 3-4 people. • Using the initial use case diagram, create a formal UML use case diagram. • As a group, try determine if there are opportunities for reuse with generalization, extends, or includes.

  36. GAP Model Code Level 0 Level 1 Level 2 Level 3 Level 4 Level 5 Getting More from Modeling • Modeling maturity levels: • Level 0: No specification • Level 1: Textual • Level 2: Text with Diagrams • Level 3: Models with Text • Level 4: Precise Models • Level 5: Models only • But getting more means putting more in

  37. Use Case Behavior • Adapted from the Final Adopted Specification for the UML 2.0 Superstructure

  38. Activity • Activity diagrams are an easy way to represent the high-level flow of activity. • Show how activities connect to one another in a process. • Sequential or concurrent activities • Often used to: • model the flow of events in a use case • model business processes • model internal system processes • Not easy to tell who is responsible for the behavior.

  39. Interaction • Interaction diagrams help capture “who does what when” • Most popular way to show dynamic aspects of models. • Reveal the details of message passing – how objects respond to messages by delegating to others.

  40. State Machine • Use case analysis often reveals state-based behavior. • When you hear “status”, think of a state machine. • Exception flows may occur based on state. • The user may operate directly on the state of something in the system.

  41. Quotable Quotes on Using UML • The UML is a large and growing beast, but you don’t need all of it.– Martin Fowler • “…when learning the UML, you need to be aware that certain constructs and notations are only helpful in detailed design while others are useful in requirements analysis …UML needs to be used together with an effective process…”– Brian Henderson-Sellers

  42. A Parting Thought • The term “use-case driven” is a wonderful marketing term but the reality is that use cases aren’t sufficient to drive much of anything. Use cases are a good technique to document behavioral requirements but that’s only a small part of the functional requirements picture and an even smaller part of the total requirements picture – they aren’t very good at documenting business rules, user interface requirements, constraints, or non-functional requirements. [Ambler]

  43. References • [Fowler] Fowler, Scott, UML Distilled 2nd Edition, Addison-Wesley • [Jacobson] Jacobson, Booch, Raumbaugh, The Unified Software Development Process, Addison-Wesley • [Ambler] Scott Ambler, www.agile-modeling.com • [Kruchten] Philippe Kruchten, Architectural Blueprints—The “4+1” View Model of Software Architecture, IEEE Software 1995

  44. Recommended Reading • Armour, Frank, and Granville Miller, Advanced Use Case Modeling: Software Systems, Addison-Wesley • Charbonneau, Serge, Modeling Use Cases with the Borland Suite of Tools, BDN • Cockburn, Alistair, Writing Effective Use Cases, Addison-Wesley • Miller, Granville, Gathering Requirements: Use Cases, BDN • Miller, Randy, Practical UML™: A Hands-On Introduction for Developers, BDN • Miller, Randy, What's New in UML 2? The Use Case Diagram, BDN • Overgaard, Gunnar, and Karin Palmkvist, Use Cases: Patterns and Blueprints, Addison-Wesley • BDN content can be found at http://bdn.borland.com/

More Related