1. Lawrence ChungCS6359.OT1: Module 141 Module 14: Use Cases & Use Case Diagrams

2. CS6359.OT1: Module 142 Lawrence Chung 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

3. CS6359.OT1: Module 143 Lawrence Chung 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

4. CS6359.OT1: Module 144 Lawrence Chung 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?) LoanOfficer Process loan actor use case name

5. CS6359.OT1: Module 145 Lawrence Chung Use Cases – Basics2 Actor1  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 >

6. CS6359.OT1: Module 146 Lawrence Chung 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. Set Limits Analyze Risk Price Deal Capture Deal Actor Trading Manager Trader Salesperson Use Cases – Basics2 Actor2  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

7. CS6359.OT1: Module 147 Lawrence Chung Use Cases and Flow of Events Typical 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.

8. CS6359.OT1: Module 148 Lawrence Chung 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

9. CS6359.OT1: Module 149 Lawrence Chung 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. Place order Order management use case collaborationrealization

10. CS6359.OT1: Module 1410 Lawrence Chung Organizing Use Cases  Use packages.  Factor common behavior through relationships. Generalization Extend Include Use

11. CS6359.OT1: Module 1411 Lawrence Chung Organizing Use Cases Generalized Use Case  Child inherits behavior and meaning from parent.  Child may be substituted any place for a parent.  Rendered same as class generalization.

12. CS6359.OT1: Module 1412 Lawrence Chung Organizing Use Cases Use 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.

13. CS6359.OT1: Module 1413 Lawrence Chung Organizing Use Cases Extending 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 Capture Deal Actor Trader Salesperson Limits Exceeded Deal >

14. CS6359.OT1: Module 1414 Lawrence Chung Organizing Use Cases Uses  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 Price Deal Capture Deal > Analyze Risk >  UML 1.3: Replaces > relationship with Generalization and > dependency (http://www.jeckle.de/files/viewfront.pdf).

15. CS6359.OT1: Module 1415 Lawrence Chung Organizing Use Cases Example Track order generalization Validate user Retinal scan Check password Place rush order Place order Extension points: set priority extension inclusion extension point > (set priority) >  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.

16. CS6359.OT1: Module 1416 Lawrence Chung 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

17. CS6359.OT1: Module 1417 Lawrence Chung A Use Case Template : Example Use Case2. Reparing_Cellular_Network History created 1/5/98 Derek Coleman, modified 5/5/98 DescriptionOperator rectifies a report by changing parameters of a cell ActorsOperator (primary Cellular network Field maintenance engineer AssumptionsChanges to network are always successful when applied to a network Steps 1. Operator notified of network problem 2. Operator starts repair session 3. REPEAT 3.1 Operator runs network diagnosis application 3.2 Operator identifies cells to be changes and their new parameter values 3.3 IN PARALLEL 3.3.1 Maintenance engineer tests network cells || 3.3.2 Maintenance engineer sends fault reports UNTIL no more reports of problem 4. Operator closes repair session Variations (optional)#1. System may detec fault and notify operator or Field maintenance engineer may report fault to Operator Non-Functional (optional)Performance Mean: time to repair network fault must be less than 3 hours Issues What are the modes of communication betw field maintenance engineer and operator

18. CS6359.OT1: Module 1418 Lawrence Chung A Use Case Template : Example Use Case ExtensionRepair_may_fail extends 2. Reparing_Cellular_Network DescriptionDeals with assumption that network changes can never fail Steps#3.3. if the changes to network fail then the network is rolled back to its previous state Issues How are failures detected? Are roll backs automatic or is Operator intervention required?

19. CS6359.OT1: Module 1419 Lawrence Chung A Use Case Template : Example 2 Use Case : e.g., “Withdraw money” Actors Brief descriptionA couple of sentences: E.g., “This use case lets a bank account owner withdraw money from an ATM machine” PreconditionsWhat should be true before the use case can start. PostconditionsWhat should hold after the use case successfully completes. Basic flow of eventsThe happy day flow, or the sunny day flow. The most common successful case. Alternate flow of events/subflowsDifference for the specific subflow Exception flowsSubflows may be divided into 1) normal, 2) successful alternate actions, and 3) exception/error flows.

20. CS6359.OT1: Module 1420 Lawrence Chung 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. Perform card transaction Customer Credit Card Validation System Process customer bill Reconcile transactions Manage Customer account Corporate Customer Retail Institution

21. CS6359.OT1: Module 1421 Lawrence Chung 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. system boundary Place phone call extension actor «extend» Use scheduler Receive phone call Receive additional call Place conference call «extend» Cellular Network use case association Cellular Telephone

22. CS6359.OT1: Module 1422 Lawrence Chung 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.

23. CS6359.OT1: Module 1423 Lawrence Chung Use Case Diagrams: Common Uses Use Cases and Requirements Requirements Use Cases Classes iterate Associations  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]

24. CS6359.OT1: Module 1424 Lawrence Chung Use Case Diagrams: Uses also for Modeling 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.

25. CS6359.OT1: Module 1425 Lawrence Chung When to Use Use Cases Two Philosophies of Use Cases 1. 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 2. 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...

26. CS6359.OT1: Module 1426 Lawrence Chung Modeling Behavior of 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 the Behavior of an Element 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.

27. CS6359.OT1: Module 1427 Lawrence Chung 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.

28. CS6359.OT1: Module 1428 Lawrence Chung 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!

29. CS6359.OT1: Module 1429 Lawrence Chung 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!

30. CS6359.OT1: Module 1430 Lawrence Chung 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

31. CS6359.OT1: Module 1431 Lawrence Chung 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 > the same as >? 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?