Use Case Diagram PDF

USE CASE DIAGRAM/ DOCUMENTATION OBJECTIVES  Explain how events can be used to identify use cases that define requirements  Identify and analyze events and resulting use cases  Explain how the concept of problem domain classes also defines requirements  Identify and analyze domain c...

USE CASE DIAGRAM/ DOCUMENTATION OBJECTIVES  Explain how events can be used to identify use cases that define requirements  Identify and analyze events and resulting use cases  Explain how the concept of problem domain classes also defines requirements  Identify and analyze domain classes needed in the system OBJECT-ORIENTED ANALYSIS AND DESIGN WITH THE UNIFIED PROCESS  1 USE CASE DIAGRAMS Use Cases: Technique for capturing functional requirements of a system Describe typical interactions between users of a system and the system itself. A scenario is a sequence of steps describing an interaction between a user and a system. Scenarios model the goal of the user (an actor). An actor is a role that a user plays with respect to the system. A use case is a set of scenarios tied together by a common user goal. EVENTS AND USE CASES 2 Several techniques can be used to identify use cases.  Event : an occurrence at a specific time and place that can be described. (what user wants / expect from the system ) Event decomposition: help identify use cases  A technique analysts used to identify use cases by first focusing on the events a system must respond to and then looking at how a system respond Elementary business processes (EBPs)  Task performed by one person in one place, in response to a business event that adds business value and leave the system and its data in a consistent state.  Each EBP (use case) occurs in response to business event. Use case : Activity the SYSTEM carries out OBJECT-ORIENTED ANALYSIS AND DESIGN WITH THE UNIFIED PROCESS 1 TYPES OF EVENTS 3 External Events  An event that occurs outside the system, usually initiated or triggered by an external agent or actor. (eg: students want to register subject) Temporal Events  Occurs when system reaches a point (deadline) in time. (eg: produce result slip every end of semester)  System should automatically process the event and produce the output when the time is reached without being instructed by user to do so. State Events  Occurs when something happens inside the system that triggers the need for processing. (Eg: autobackup procedure to occur when system fails)  Similar to temporal event except that the point in time cannot be defined. OBJECT-ORIENTED ANALYSIS AND DESIGN WITH THE UNIFIED PROCESS 5  4 External Event Checklist OBJECT-ORIENTED ANALYSIS AND DESIGN WITH THE UNIFIED PROCESS 6  5 Temporal Event Checklist OBJECT-ORIENTED ANALYSIS AND DESIGN WITH THE UNIFIED PROCESS 7 USE-CASE NOTATIONS : ACTORS 6 An actor models an external entity which communicates with the system:  User  External system  Physical environment Passenger An actor has a unique name and an optional description. Examples: Passenger: A person in the train GPS satellite: Provides the system with GPS coordinates USE-CASE NOTATIONS : USE CASE 7 A use case represents a class of functionality PurchaseTicket provided by the system as an event flow.  8 Identifying Use Cases by Focusing on Users and their Goals OBJECT-ORIENTED ANALYSIS AND DESIGN WITH THE UNIFIED PROCESS 10 USE CASE DIAGRAMS 9 Types: business use cases system use cases (our focus) Use cases tell a story of actors using a system. They illustrate functional requirements, by the stories they tell. Complementary with a functional requirements list. 10 IDENTIFYING USE CASES 11  Major distinct, complete, end-to-end processes of using a system.  Identification of use cases begins with the requirements definition. The process-oriented functional requirements — things the system must do — suggest a direct action resulting from an external or temporal event. The information-oriented functional requirements — content the system must have — suggest things that happen involving information or time triggers to collect or produce information.  WRITTEN USE CASES 12 Document containing detailed specifications for a use case Contents can be written as simple text or in a specified format USE CASE DESCRIPTIONS 13 Can be a step-by-step breakdown of interaction between actor and system Assign staff to work on a campaign Actor Action System Response 1. The actor enters the client name. 2. Lists all campaigns for that client. 3. Selects the relevant campaign. 4. Displays a list of all staff members not already allocated to this campaign. 5. Highlights the staff members 6.Presents a message confirming to be assigned to this campaign. that staff have been allocated. Alternative Courses Steps 1–3. The actor knows the campaign name and enters it directly. USE CASE DIAGRAMS: 14 ‘BUY A PRODUCT’ SCENARIO The customer browses the catalog and adds desired items to the shopping basket. When the customer wishes to pay, the customer describes the ship-ping and credit card information and confirms the sale. The system checks the authorization on the credit card and confirms the sale both immediately and with a follow-up call. Who is the actor? What is the actor’s goal? What if the customer is a regular customer and you already know shipping and credit card information? What happens if credit card authorization fails? EXAMPLE USE CASE TEXT/DESCRIPTIONS 15 USE CASE DIAGRAM 16 "robo-actor" Video Store system agent Information System Query For Items A way to conceive Credit Authoriz ation and illustrate the Service Pay Fines use cases. Usually created Rent Items during the initial use case Manage Memberships analysis. Clerk Customer Log In Manage Inventory Admin- Manager istrator Manage Users Use Case: Rent Items Typical Course of Events 17 Actor Intentions System Responsibility A SAMPLE 1. Customer arrives at a checkout with videos (and/or less often, video games) to rent. 2. The Customer presents their membership identification to the Clerk, who enters it into the system. 3. Presents membership information, and status of loans (usually nothing on loan, and no outstanding fines). DETAILED USE 4. For each video or game, the Clerk records the item identification into the 5. Presents accumulating list of rental item titles, due dates, total rental fee, CASE DESCRIPTIONS system. and any late charges. 6. Clerk informs Customer of total charge, and asks for payment. 7. Customer pays Clerk by cash or credit. 8. Clerk records payment into system. 9. If a credit payment, authorizes it. 10. Generates receipt and loan report. 11. Clerk gives receipt and loan report to Customer, who then leaves with the rental items. Alternative Courses  Step 7. Customer has insufficient cash. Request a credit payment, cancel the transaction, or deduct rental items until transaction can be paid for.  Step 7: Customer has unpaid late charges and will not pay them. Customer must pay them before renting more items, so either collect full payment, or cancel the transaction.  Step 9. Failure to authorize credit payment, either because of insufficient credit or inactive authorization service. Request cash payment instead.  SUMMARY USE CASE : EXAMPLE 18  Same principles a detailed use case, but simplifies steps and details, as a low-fidelity incomplete first draft.  Useful during early requirements and scope analysis. Actor Intentions System Responsibilities 1. Customer presents items to rent. 2. Clerk records items. 3. Remember rented items. 4. Calculate and present price. 5. Customer pays. 6. Authorize and record payment. USE CASE DIAGRAM 19  USE-CASE DIAGRAM 20 POST Buy Item Log In Cashier Customer Refund a Purchased Item MH  DIAGRAMMING USE CASES 21 STEREOTYPED DEPENDENCIES « include »  The included use case is a mandatory part of the including one (functionality-wise, not actor-wise) / factor out shared sub-processes « include » Included Including « extend »  The extending use case is an optional part of the extended one (functionality-wise, not actor-wise) / show precedence order (with exceptions) « extend » Extending Extended THE RELATIONSHIP 22 An represents behavior that is factored out Passenger for reuse, not because it is an PurchaseMultiCard exception. PurchaseSingleTicket The direction of a relationship is to the using use case CollectMoney NoChange Cancel THE RELATIONSHIP 23 relationships represent exceptional or Passenger seldom invoked cases. The exceptional event flows are factored out of the PurchaseTicket main event flow for clarity. Use cases representing exceptional flows can extend more than one use NoChange case. OutOfOrder The direction of a relationship is to the extended use case Cancel  24 ANOTHER EXAMPLE NOTATION OF USE CASE DIAGRAMS 25 Generalization shows that one use case provides all the functionality of the more general use case and some additional functionality shows that one actor can participate in all the associations with use cases that the more general actor can plus some additional use cases  26 Actors can be grouped in generalization categories.  GUIDELINES: USE CASE MODELING 27 Keep use case names simple: Verb object  Deposit money.  Not: Deposit money into checking. Why not? Accomplish a user’s goal  Invalid PIN is not a use case. Why not? Include Secondary Actors (e.g., Bank) Avoid ambiguity  E.g., in the ATM problem, System could be the machine or the Bank’s back-end server Start Up and Shut Down are use cases  Why do we usually not include them at first? GUIDELINES: USE CASE MODELING 28  A use case diagram is not a flow chart.  Keep each step and alternative simple; e.g., don’t validate PIN and balance in same step (and same alternative scenario)  29 LETS TRY TEST YOUR UNDERSTANDING.  Identify a set of use cases’ for the following high level processes in a housing system run by the campus housing service. Draw the possible use-case diagram. The campus housing service helps students find apartments. Apartment owners fill in information forms about the rental units they have available (eg: location, number of bedrooms, monthly rent), which are then entered into a database. Students can search through this database via the web to find apartments that meet their needs (eg: a two-bedroom apartment for RM400 or less per month within ½ km of campus). They then contact the apartment owners directly to see the apartment and possibly rent it. Apartment owners call the service to delete their listing when they have rented their apartment(s).