Module 14: Use Cases & Use Case Diagrams

1. Module 14: Use Cases & Use Case Diagrams CS6359.OT1: Module 14

2. Overview • Use cases • Use Cases - Basics • Use Cases & Flow of Events • Organizing Use Cases • Modeling Behavior of Element • Use Case Diagrams • Modeling System Context • Modeling System Requirements • Modeling System Test Cases CS6359.OT1: Module 14

3. Use Cases – Basics1 • UML User Guide • Description of a set of sequences of actions that a system performs to yield an observable result of value to an actor. • Object-oriented Software Engineering; Jacobson, ‘92 • Narrative document that describes the sequences of events of an actor using a system to complete a process. • Use cases are about externally required functionality -- Martin Fowler • OO modelers had been working informally with scenarios - loose descriptions of what the software was expected to do • Ivar Jacobson gave the idea more formal treatment - called it use case • Since 1994 the object community has embraced the Use Case idea • Use cases have become the “requirements” of the OO world CS6359.OT1: Module 14

4. Use Cases – Basics2 • Defines “what” without specifying “how”! (how about why?) • Specify desired behavior. • Promotes communication among: End users, Domain experts, Architects, Developers, Information Modelers • Represents a set of functional requirements on a system. • Achieve a tangible amount of work. • Provide a starting point for test cases (-> use-case driven testing). • An interaction between a user and a computer system. • A use case captures some user-visible function. • A use case may be small or large. • A use case achieves some goal for the user. (What goal?) use case actor Process loan name LoanOfficer CS6359.OT1: Module 14

5. Use Cases – Basics2Actor1 • Coherent set of roles that users assume when interacting with a system. • Human or automated systems. • Represents an individual interacting with the system in a specific way. • Live outside the system. • Connected to use cases through associations. automated system <<stereotype>> CS6359.OT1: Module 14

6. Use Cases – Basics2 Actor2 • Actor: • A role that a user plays in a system context. • A user may play more than one role. • It is often easier to come up with actors first - then use case. • Actors don’t need to be human. • Actors are a useful concept in helping determine the use case • Tracking actors over time can help: • in assessing competing needs and in specifying security policy Set Limits Trading Manager Analyze Risk Actor Price Deal Trader Salesperson Capture Deal CS6359.OT1: Module 14

7. Use Cases and Flow of EventsTypical Course of Events • Usually described in informal text or formal structured text (what’s this?). • Visualized in interaction diagrams; commonly system sequence diagram. • Exceptional flows or variations depicted separately. • Identifies when the use case begins and ends. CS6359.OT1: Module 14

8. Use Cases and Flow of Events Use Cases and Scenarios • Scenario and use case are often used interchangeably. • Both terms are often ambiguously used. • Scenarios describe a single path, or a particular sequence, through a use case. • Real or prototypical values are used. • Each sequence defines a set of system operations. • System operation: • System level function. • A single interaction between an actor and the system. • E.g., Use Case: Order Goods • Scenario 1: all goes well • Scenario 2: insufficient funds • Scenario 3: out of stock CS6359.OT1: Module 14

9. Use Cases and Flow of Events Use Cases and Collaborations • Collaboration — a society of classes and other elements that work together to implement the behavior of a use case. • Realization of a use case. realization collaboration Place order Order management use case CS6359.OT1: Module 14

10. Organizing Use Cases • Use packages. • Factor common behavior through relationships. • Generalization • Extend • Include • Use CS6359.OT1: Module 14

11. Organizing Use CasesGeneralized Use Case • Child inherits behavior and meaning from parent. • Child may be substituted any place for a parent. • Rendered same as class generalization. CS6359.OT1: Module 14

12. Organizing Use CasesUse Case Inclusion • Base use case explicitly incorporates the behavior of another use case. • The included use case cannot stand alone. • Example of delegation. • Rendered as a stereotyped dependency. CS6359.OT1: Module 14

13. Organizing Use CasesExtending Use Case • when a use case does the same as another but just a bit more or deals with a special situation • Base use case incorporates the behavior of another use case. • The extending use case indicates where the extended behavior occurs in the base use case. • Base use case only extended through extension points. • Used to model optional behavior. • Rendered as a stereotyped dependency. Price Deal Actor Capture Deal Trader Salesperson <<extends>> Limits Exceeded Deal CS6359.OT1: Module 14

14. <<uses>> Analyze Risk <<uses>> Price Deal Price Deal Capture Deal Organizing Use CasesUses • The uses relation occurs when you have a chunk of behavior that is similar across more than one use case • It saves having to copy or rewrite the logical flow • Often no actor may be associated with a ‘used’ use case • UML 1.3: Replaces <<uses>> relationship with Generalization and <<include>> dependency (http://www.jeckle.de/files/viewfront.pdf). CS6359.OT1: Module 14

15. Organizing Use Cases Example extensionpoint extension • Track Order- Main flow of control : Obtain and verify the order number. Include (Validate user). For each part in the order, query its status, then report back to the user. • Place Order- Main flow of control: Include (Validate user). Collect the user’s order items. (set priority). Submit the order for processing. <<extend>> (set priority) Place order Extension points: set priority Place rush order <<include>> Check password inclusion Validate user Track order generalization <<include>> Retinal scan CS6359.OT1: Module 14

16. A Use Case Template(http://www.bredemeyer.com/pdf_files/use_case.pdf) • Use Case: Use case identifier, reference number, and modification history • Description: Goal to be achieved by use case and sources for requirement • Actors: List of actors involved in use case • Assumptions: Conditions that must be true for use case to terminate successfully • Steps: Interactions between actors and system that are necessary to achieve goal • Variations (optional): Any variations in the steps of a use case • Non-Functional (optional): List of NFRs that the use case must meet • Issues: List of issues that remain to be resolved CS6359.OT1: Module 14

17. A Use Case Template: Example CS6359.OT1: Module 14

18. A Use Case Template: Example CS6359.OT1: Module 14

19. A Use Case Template: Example 2 CS6359.OT1: Module 14

20. Customer Credit Card Validation System Perform card transaction Process customer bill Retail Institution Reconcile transactions Manage Customer account Corporate Customer Use Case Diagrams: Common Uses Modeling System Context • Identify the actors that surround the system. • Which groups need help from the system. • Which groups are needed to execute system functions. • Which groups interact with external hardware & perform secondary functions. • Organize actors using generalization if appropriate. • Use stereotypes for actors to aid understanding. • Populate a use case diagram with actors and associate with system use cases. CS6359.OT1: Module 14

21. Use Case Diagrams: Another Example • Use case diagram — diagram that shows a set of use cases and actors and their relationships (Dependencies, Generalizations, Associations). • Used to visualize the behavior of a system. • Allows users to comprehend the interactions with the system. • Notes and constraints can be associated. Place conference call Place phone call «extend» extension actor Receive phone call «extend» Receive additional call Cellular Network system boundary use case Use scheduler Cellular Telephone association CS6359.OT1: Module 14

22. Use Case Diagrams: Common Uses Modeling System Requirements • Establish the system context. • Consider the behavior that each actor expects from the system. • Name common behaviors as use cases. • Factor common behavior; extensions, inclusions, and generalizations. • Model the actors, use cases, and relationships into a use case diagram. • Adorn with notes for non-functional requirements. CS6359.OT1: Module 14

23. Use Case Diagrams: Common Uses Use Cases and Requirements • The conventional wisdom in OO: use cases = requirements • For small projects this works • For large projects, however, classic requirements still remain the starting point for software projects [Use Cases Combined with Booch, OMT, UML. Process and Products. P. Texel & C. Williams, Prentice Hall, 1997] Requirements Use Cases Classes iterate Associations CS6359.OT1: Module 14

24. Use Case Diagrams: Uses also forModeling System Test Cases • For each use case, identify its flow of events. • Generate a test script for each flow. • Obtain initial state from preconditions. • Test success against post conditions. • Build necessary test drivers to simulate scenarios using test scripts. • Use tools to regression test using the tests. CS6359.OT1: Module 14

25. When to Use Use Cases Two Philosophies of Use Cases • A use case should describe only sequential flow of interaction - no if..then • UC1: customer withdraws money from the bank • UC2: customer tries to withdraw more than the balance will allow • It’s OK to include some if..then situations Fowler’s View • Capture the simple, normal use-case first • For every step ask “What could go wrong?” and how it might work out differently • Plot all variations as extensions of the given use case • Fowler: do use cases first • Another view: do object modeling first, then use cases • Another: iterate model - use case - model - use case ... CS6359.OT1: Module 14

26. Modeling Behavior of Element Modeling the Behavior of an Element • Element could represent: The system as a whole; A subsystem.; An individual class. • Important reasons: • Allows domain experts to specify external view to sufficient details for developers to continue. • Provides a means for developers to approach and understand an element. • Provides a basis for testing. Modeling Behavior as Use Cases • Identify actors that interact with the element. • Organize actors by generalized and more specialized roles. • Consider the primary ways actors interact with the element. • Consider the exceptional ways actors interact with an element. • Organize the behaviors as use cases. CS6359.OT1: Module 14

27. Hints & Tips on Use Cases • Well structured use case: • Names a single, identifiable and atomic behavior. • Factors common behavior through inclusion. • Factors variants by pushing behavior through extension. • Describes the flow of events such that a non-technical person can follow. • Clarified by a minimal set of scenarios that specify the normal and variant semantics. • Depicting a use case: • Show only the use cases that are important to understand the behavior in a particular context. • Show only the actors related to those use cases. CS6359.OT1: Module 14

28. Use Case Diagrams Common Uses • Model the context of a system. • Identifying the system border. • Defining what is inside the system. • Defining what is outside the system. • Model the requirements of a system. • What the system should do. • Independent of how the system will do it! CS6359.OT1: Module 14

29. Hints & Tips on Use Case Diagrams • Well-structured use case diagrams: • Focused on communicating a single aspect of a system’s static use case view. • Contains only actors and use cases essential to that aspect. • Should contain sufficient detail to inform a reader of important system semantics. • Depicting a use case diagram: • Choose a name that communicates purpose. • Minimize crossing of lines. • Physically co-locate semantically related elements. • Use notes and colors for necessary emphasis. • Only show what is more or less useful! CS6359.OT1: Module 14

30. Summary • Use cases • Use Cases - Basics • Use Cases & Flow of Events Typical Course of Action, Scenarios, Collaborations • Organizing Use Cases Include, Generalize, Extend, Uses • Modeling Behavior of Element • Use Case Diagrams • Modeling System Context • Modeling System Requirements • Modeling System Test Cases • When to Use Use Cases CS6359.OT1: Module 14

31. Points to Ponder • What are use cases for ultimately? • To some people, a “scenario” can be a “use case,” an “episode,” or a “script.” Find out how this view differs from the notions of “use case” and “scenario” in this module. • Can you represent, in UML, an instance of a use case? If so, how? • How many different flows of events can there be in general, given a use case? • Is <<uses>> the same as <<include>>? If not, give an example showing how they differ. • Use cases are considered as a significant aid to ensuring that the software functional requirement specification is complete. But then how do we ensure the completeness of use cases we’ve come up with? CS6359.OT1: Module 14