Chapter 5: Use Cases Chapter 6 & 25 in Applying UML and Patterns Book.

1. Chapter 5: Use Cases Chapter 6 & 25 in Applying UML and Patterns Book.

2. What use cases are and how to write them. • Different format of use cases. • How to draw a use case diagram. • Extend and include use cases. Overview

3. Understands the use case diagram and the different relationship types inside the use case diagram. • Understands the meaning of “Use Case”. • Understands the different methods in writing the use cases. By the end of this chapter, you will..

4. It describes the main system functions from the standpoint of an external observer. • Used during requirements elicitation to represent external behavior. • It emphasize on what the system does rather than how it. • It is created during the early stages of a project – during the analysis phase rather than during the design phase. • It provides a high-level view of what the system does and who uses it. • It provides the basis for determining the user interfaces (UIs) to the system. Capturing functional requirementswith use case diagram

5. Example: Use Case DiagramATM Banking System

6. Any use case diagram should contain: • Actor(s). • Use cases. • Associations/Relationships among actors and use cases. Use Case Diagram

7. Actors are drawn as stick persons with the role of the actor written below. • Actor names are unique typically represent the role that an actor plays with respect to the system. • Is someone (e.g. human beings) or something (e.g. other objects or systems) that interact with the system. • Is entity external to the system who participates in the story of the use case (receive or input), such as a person, computer system or organization. • Example: a library clerk, cashier, customer, Passenger, GPS satellite, bank, customer department. Actor role name Use Case DiagramActor

8. Use cases are drawn as ellipses with the name of the use case written inside the ellipse. • Use case name typically consists of an active verb and one or more nouns that concisely describe the system function modeled. Use case Use Case DiagramUse Case

9. Use Case DiagramUse Case • Use Cases: is a collection of related scenarios that describe actors using a system to support a goal. • Scenario (Use Case instance): • Is a possible example of what happens when an actor interacts with the system. • Represents a unit of functionality that the system provides. • Contains a specific sequence of actions and interactions between actors and the system under discussion. • Example: the scenario of entering book information into the catalog, or buying items at a store, or using an ATM.

10. Actors are connected to the use case(s) with which they interact by a line, which represents the relationship between the actor(s) and the use case(s). • One actor may be associated with one or more use cases. • One use case may be associated with one or more actors. Use Case DiagramAssociation/Relationship

11. Example 1: Use Case DiagramBanking System

12. Example 2: Use Case DiagramRegistration System

13. Example 3: Use Case DiagramLibrary System

14. Activity: Use Case Diagram Possible use cases for an online ticket reservation website: Sign in, sign out, register, add post, delete post. Sign in, sign out, Book flight, cancel flight, buy ticket. Sign in, sign out, rate service, buy item.

15. Each use case have an associated behavior specification which describes the sequence of actions making up a use case scenario. • Use case behavioral description has two formats: Use Case(s)

16. Use Case: Buy Items Actor: Customer(initiator) , Cashier Description (Success Scenario):A customer arrives at a checkout with items to purchase. The Cashier records the purchase items and collects payment. On completion, the Customer leaves with the items. High Level Use Case Format: HLExample 1: Buy Items

17. High Level Use Case Format: HLExample 2: Library - Add Resources Use Case: Add Resources Actor: Librarian Description (Success Scenario):The use case begins when the Librarian receives new resources (books and videos) to add to the catalog. The title, call number, and other information are recorded. Then the resources are placed on a shelf organized by resource type and call numbers.

18. Expanded Use Case TypesPrimary - Secondary - Optional

19. Expanded Use Case TypesPrimary - Secondary - Optional Book ticket use cases is a: Primary Secondary Optional

20. Abstract level use cases: Expanded Use Case TypesEssential - Real

21. Expanded Use Case TypesEssential - Real Examples of essential vs. real types:

22. Use Case: Buy Items with Cash. Actor: Customer (initiator), cashier. Purpose: Capture a sale & its cash payment. Overview (Success Scenario):A customer arrives at a checkout with items to purchase. The Cashier records the purchase items and collects a cash payment. On completion, the Customer leaves with the items. Type:Primary. Cross References: Functions R1.2,… Expanded Use Case Format Example: Buy Items with Cash

23. Expanded Use Case Format Example: Buy Items with Cash (cont.)

24. Expanded Use Case Format Example: Buy Items with Cash (cont.) Alternatives: Line 2. Invalid identifier entered. Indicate errors. Line 7. Customer didn’t have enough cash. Cancel sales transaction.

25. Expanded Use Case - Essential vs. Real Types Example 1: Buy Items with Cash Essential use case Real use case

26. Expanded Use Case - Essential vs. Real Types Example 2: ATM Withdraw Cash Essential use case Real use case

27. Either by: Example: Identifying Use Cases

28. A use case describes a process, such as business process. • A process describes, from start to finish, a sequence of events, actions and transactions required to produce or complete something of value. • Example: • Withdraw cash from an ATM. • Order a product. • Register for courses at a school. • Check the spelling. • Handle a call. Use Cases = Processes

29. A Use case may contain decision points such as in Buy Items, the customer may choose to pay via cash, credit or check. • If one of them is the typical case (usual), then the typical case is the one written in Typical course of events, and the other alternatives should be written in the Alternatives section. • If all the alternatives are equal in their likelihood, (like the payment types), write in the main section of Typical course of events a branch event, that indicates that the possible branches are written in subsections. • Then write a subsection for each branch, again using Typical course of events. • If subsections have alternatives,write them in an Alternatives section. Decision Point & Branching

30. Section: Main Decision Point & BranchingExample: Buy items

31. Decision Point & BranchingExample: Buy items (cont.) Section: Pay by cash Alternatives: Line 4. Insufficient cash in drawer to pay balance. Ask for cash from supervisor or ask Customer for a payment closer to sale total.

32. Define system function. Define system boundary, actors & use cases. HL use cases. Draw use case diagram. Expand critical use cases (Essential / Analysis). Real use case (Design). Rank use case (not discussed). Plan and Elaborate Phase Steps

33. Example 12- Define actors and use cases:

34. Use Case: Buy Items Actors: Customer (initiator), Cashier Type: Primary Description: A Customer arrives at a checkout with items to purchase. The Cashier records the purchase items and collects a payment. On completion, the Customer leaves the store with the items. Use Case: Start Up Actors: Manager Type: Primary Description: A Manager powers on a POST in order to prepare it for use by Cashiers. The Manager makes sure the date and time are correct, after which the system is ready for Cashiers’ use. Example 1 (cont.)3- Use cases in HL format:

35. Example 1 (cont.)4- Use cases diagram:

36. Example 1 (cont.) 5- Expand critical use cases:

37. Example 1 (cont.) 5- Expand critical use cases:

38. Example 1 (cont.) 5- Expand critical use cases:

39. Use Case: Make a book Entry Use Case: UC1 - Make Book Entry Actor: Library clerk Success Scenario: A library clerk accesses a terminal in order to enter one or possibly many book entries in a database. At the end of every entry, the system displays a confirmation message. At the end of the session the system would display an informative message. Example 2

40. Use Case Diagram Example 2 (cont.)

41. <<extends>> relationships represent exceptional or seldom invoked cases. • A reusable use case (component) that conditionally interrupts (is invoked optionally - like a menu selection in an application) the execution of another use case to augment its functionality. • The functionality in the original problem statement needs to be extended. • The exceptional event flows are factored out of the main event flow for clarity. • The base use case can be executed without the use case extension in extend associations. • The responsibility for deciding when the extending use case should be used lies with the extending use case. • Arrow points to use case being extended. The <<extends>> Relationship

42. Use cases representing exceptional flows can extend more than one use case. • The direction of an <<extends>> relationship is to the extended use case. • For example: the use case “ReportEmergency” is complete by itself, but can be extended by the use case “Help” for a specific scenario in which the user requires help. The <<extends>> Relationship

43. Major variation: If you have a major alternative path in the use case, and it’s complex enough to have its own alternative paths, then placing it on your diagram will honestly expose the complexity - which is helpful in costing, assignment and scheduling. • Optional subgoal: If you have parts of the use case that would be optional to implement (or even optional to execute) to meet the actor’s goals, put those parts into their own use case. Doing so clarifies the relationships between actors and their goals. It also emphasizes that you may deliver these optional goals in later releases. The <<extends>> Relationship

44. The <<extends>> Relationship

45. The <<extends>> Relationship

46. The <<extends>> Relationship

47. The <<extends>> Relationship

48. The <<extends>> Relationship

49. <<includes>> relationship represents behavior that is factored out of the use case. • A use case uses another use case (“functional decomposition”). • Used to indicate that one use case includes the functionality of another use case. • A function in the original problem statement is too complex to be solvable immediately. • Describe the function as the aggregation of a set of simpler functions. The associated use case is decomposed into smaller use cases. • A reusable use case (component) that is unconditionally called into the execution of another use case (always included in the process – like running BIOS in a system boot). The <<include>> Relationship

50. Responsibility for the decision about when to use it lies with the calling use case. • Arrow points to the included use case. The direction of a <<includes>> relationship is to the using use case (unlike <<extends>> relationships). The <<include>> Relationship