- Количество слайдов: 58
1 Chapter 5: Use Cases Chapter 6 & 25 in Applying UML and Patterns Book.
2 Overview 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.
3 By the end of this chapter, you will. . 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.
4 Capturing functional requirements with use case diagram 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.
5 Example: Use Case Diagram ATM Banking System
6 Use Case Diagram Any use case diagram should contain: Actor(s). Use cases. Associations/Relationships among actors and use cases.
7 Use Case Diagram 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
8 Use Case Diagram Use Case 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
9 Use Case Diagram 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 Use Case Diagram Association/Relationship 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.
11 Example 1: Use Case Diagram Banking System
12 Example 2: Use Case Diagram Registration System
13 Example 3: Use Case Diagram Library System
14 Activity: Use Case Diagram Possible use cases for an online ticket reservation website: A. Sign in, sign out, register, add post, delete post. B. Sign in, sign out, Book flight, cancel flight, buy ticket. C. Sign in, sign out, rate service, buy item.
15 Use Case(s) 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: High Level Use Case Expanded Use Case Describes a process very briefly, usually in 2 or 3 sentences. Describes a process in details. It has an additional section not present in HL. It consists of : • Use Case: Use case name. • Actors: List of actors (external agents) indicating who initiates the use case. • Description (Success scenario): Narrative description of the process. • Purpose: Intention of the use case. • Type: 1 - Primary, Secondary or Optional. 2 - Essential or Real. • Cross References: Related use cases and system functions. • Typical course of actions: describes in detail the conservation of interaction between the actors and the system.
16 High Level Use Case Format: HL Example 1: Buy Items 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.
17 High Level Use Case Format: HL Example 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 Types Primary - Secondary - Optional Primary Secondary Describes a major, common Describes a rare, unusual, process. or exceptional processes. Ex: Buy items. Ex: Request for stocking new product. Optional Represents processes that may not be tackled.
Expanded Use Case Types Primary - Secondary - Optional Book ticket use cases is a: A. Primary B. Secondary C. Optional 19
20 Expanded Use Case Types Essential - Real Abstract level use cases: Essential Real • The essence of the process. • Concretely describes the process in terms of its real current design, committed to • Analysis-oriented. specific input and output Technology. • Expanded use cases that are expressed in • Design-oriented. an ideal form free of technology and implementation details. • Expressed in terms of the solution. Ex: screen shots of windows, entry into input • HL are always essential. fields, and so forth. • Expresses process relatively independent of HW/SW solutions.
21 Expanded Use Case Types Essential - Real Examples of essential vs. real types: Essential Real Ex 1 The Librarian records the call number. The Librarian uses the laser wand to scan the bar code for the call number, which is transmitted to the computer. Ex 2 The Account Holder identifies himself to the ATM. The Account Holder inserts the card into the ATM card reader. He is prompted to enter his PIN (see screen shot 4), which he inputs with a numeric keypad.
22 Expanded Use Case Format Example: Buy Items with Cash 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 R 1. 2, …
23 Expanded Use Case Format Example: Buy Items with Cash (cont. ) Actor Action System Response 1. This use case begins when a Customer arrives at the POST checkout with items to purchase. 2. The Cashier records the identifier from each item. If there is more than one of the same item, the Cashier can enter the quantity as well. 3. Determines the item price and adds the item information to the running sales transaction. The description and price of the current item are presented. 4. On completion of item entry, the Cashier indicates to the POST that item entry is complete. 5. Calculate and presents the sale total. 6. The Cashier tells the Customer the total.
24 Expanded Use Case Format Example: Buy Items with Cash (cont. ) Actor Action System Response 7. The Customer gives a cash payment possibly greater than the sale total. 8. The Cashier records the cash received amount. 9. Shows the balance due back to the Customer & generate a receipt. 10. The Cashier deposits the cash received & extracts the balance owing. The Cashier gives the balance owing, & the printed receipt to the Customer. 11. Logs the completed sale. 12. The Customer leaves with the items purchased. 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 Actor Action This Cashier records the identifier for each item. System Response Determines the item price & adds the item information to the running sales transaction. The description and the price of the items are presented. Real use case Actor Action For each item, the Cashier types in the UPC field of Window 1. They then press “Enter Item” button with the mouse or Enter key. System Response Display the item price & adds the item information to the running sales transaction. The description & price of the current item are displayed in Textbox 2 of Window 1.
26 Expanded Use Case - Essential vs. Real Types Example 2: ATM Withdraw Cash Essential use case Actor Action This Customer identifies themselves. System Response Presents options. Real use case Actor Action System Response 1. The Customer inserts his card. 2. Prompts for PIN. 3. Enter PIN on keypad. 4. Display options menu.
27 Identifying Use Cases Either by: Type 1: Actor based • Identify the actors related to an organization. • For each actor, identify the processes they initiate or participate in. Type 2: Event based • Identify the external events that a system must respond to. • Relate the events to actors and use cases. Example: Cashier Log in, Cash out. Customer Buy items, Refund items.
28 Use Cases = Processes 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.
29 Decision Point & Branching 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.
30 Decision Point & Branching Example: Buy items Section: Main Actor Action System Response 1. This use case begins when a Customer arrives at POST checkout with items to purchase. 2. …. . 3. Customer chooses payment type: a. If cash payment, see section pay by Cash. b. If credit payment, see section pay by Credit. c. If check payment, see section pay by Check. 4. Logs the completed sale. 5. Print the receipt. 6. The cashier gives the receipt to the customer. 7. The customer leaves with the items.
31 Decision Point & Branching Example: Buy items (cont. ) Section: Pay by cash Actor Action System Response 1. The customer gives a cash payment- possible greater than the sale total. 2. The Cashier records the cash tendered. 3. Shows the balance due back to the Customer. 4. The Cashier deposits the cash received and extracts the balance owing. The Cashier gives the balance owing to the Customer. 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 Plan and Elaborate Phase Steps 1. Define system function. 2. Define system boundary, actors & use cases. 3. HL use cases. 4. Draw use case diagram. 5. Expand critical use cases (Essential / Analysis). 6. Real use case (Design). 7. Rank use case (not discussed).
33 Example 1 2 - Define actors and use cases: Cashier Log in, Cash out. Customer Buy items, Refund items. Manager Start up, Shut down. System Administrators Add new users.
34 Example 1 (cont. ) 3 - Use cases in HL format: 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.
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 Example 2 Use Case: Make a book Entry Use Case: UC 1 - 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.
40 Example 2 (cont. ) Use Case Diagram
41 The <
42 The <
43 The <
44 The <
45 The <
46 The <
47 The <
48 The <
49 The <
50 The <
51 The <
52 The <
53 The <
55 Generalization/Specialization Relationship Called inheritance relationship. Occurs when there is a general sequence of events, but when considering the details, there are many specialised variations of the use case. Graphically, this is shown by a generalisation line pointing from the specialised use case to the more general use case.
56 Actor Generalization
57 Actor Generalization
58 Actor Generalization