Jan Ron McFadyen1 Use Cases in the UML Functionality under consideration is represented by use cases (named ellipses) enclosed in a box Actors are shown outside the box Actors are connected to use cases they use by associations January 13, 2003

Jan Ron McFadyen2 Actor Use Case Associations –Between Actors and Use Cases –Between Use Cases –Between Actors Use Cases in the UML

Jan Ron McFadyen3 Actors Actors represent the people or other systems that interact with the system. Each actor is drawn as a stick person with the name written underneath An actor represents a set of roles that users of a system may assume In a university registration system, we might have: StudentRegistration Manager Registration Clerk Department Chair

Jan Ron McFadyen4 Use Case Behaviour A Use Case describes a sequence of actions that a system performs to achieve an observable result of value to an actor (something meaningful to a user) A use case is drawn as an ellipse, with its name within or below the ellipse A Use Case Model comprises the individual use cases that describe the system A use case describe what a system does, not how it does it A use case must be written as a behaviour specification separately from the diagram (the written use case) We will see that other UML diagrams (e.g.statechart, sequence) can illustrate behavioural information about a use case A use case will be implemented as a computer program and the actors initiate execution (or instantiation) of a use case

Jan Ron McFadyen5 Use Case Example We might begin describing a registration system as: Register Manage courses Student Department Chair Generate report Registration Clerk Registration Between actors and use cases we draw associations (the lines) to indicate the use cases each actor can instantiate

Jan Ron McFadyen6 Figure 6.2 – a portion of Use case context diagram – serves as a useful communication tool Handle Returns Cashier Payment Authorization Service Process Rental NextGen … Process Sale Page gives a written description of the Process Sale use case

Jan Ron McFadyen7 Process Sale Use Case P. 50+ Use Case UC1: Process Sale Primary Actor: Cashier … Preconditions: Cashier is identified and authenticated Postconditions: Sale is saved…Commissions recorded…Payment authorization approvals recorded Main Success Scenario: 1.Customer arrives at POS checkout with goods and/or services to purchase 2.Cashier starts a new sale 3.Cashier enters item identifier 4.System records sale line item and presents item description, price, and running total. Price calculated from a set of price rules. Cashier repeats steps 3-4 until indicates done. 5.System presents total with taxes calculated … At this point in time (Inception), processing a sale is handled in one use case that contains a main success scenario and all possible alternative scenarios.

Jan Ron McFadyen8 Process Sale Use Case P. 50+ Cashier repeats steps 3-4 until indicates done. 5.System presents total with taxes calculated 6.Cashier tells customer the total, and asks for payment. 7.Customer pays and System handles payment 8.System logs completed sale and sends sale and payment information to the external Accounting System and Inventory System. 9.System presents receipt 10.Customer leaves with receipt and goods Extensions or Alternate Flows *a. At any time, the System fails: 1.Cashier restarts System, logs in, and requests recovery of prior sale 2.System reconstructs prior state. … …

Jan Ron McFadyen9 Process Sale Use Case P. 50+ Extensions or Alternate Flows *a. At any time, the System fails: 1.Cashier restarts System, logs in, and requests recovery of prior sale 2.System reconstructs prior state. … 3a. Invalid identifier: 1.System signals error and rejects entry 3b. There are multiple of same item category and tracking unique item identity not important (e.g. 5 packages of veggie burgers) 1. Cashier can enter item category identifier and the quantity … 4a. The system generated item price is not wanted … 1. Cashier enters override price. 2. System presents new price. … Identifies the step where this condition may arise. “*” means any step; “4” means at step 4; a letter following identifies a different exception

Jan Ron McFadyen10 Use Cases in the text Some places where use cases are specifically addressed: Chapter 9 introduces sequence diagrams, system events and system operations Chapter 13 adds contracts Chapter 25 discusses Include, Extend, and Generalization …

Jan Ron McFadyen11 Chapter 25 Relating Use Cases Include relationship If one use case (the base use case) is designed to use the functionality of another use case (the addition use case), there is an “include” dependency Consider that the base use case is executing. When it reaches the inclusion point, the addition use case is executed and when it finishes the base use case continues. Include is a way to factor commonality out of use cases to make the design more modular Suppose the Process Sale use case is designed to use the functionality of Handle Credit Payment and the Handle Check Payment use cases. The written Process Sale use case has in its Extensions section two inclusions:

Jan Ron McFadyen12 Include Relationship UC1:Process Sale … Main Success Scenario … 7. Customer pays and System handles payment. … Extensions or alternate flows: 7a. Paying by cash … 7b. Paying by credit: include Handle Credit Payment 7c. Paying by check: include Handle Check Payment

Jan Ron McFadyen13 Include Relationship In the UML diagram Process Sale Handle Check Payment Handle Credit Payment > Process Sale has a dependency on Handle Check Payment, and another dependency on Handle Credit Payment The dashed lines and the stick arrowhead are the correct way to depict dependencies

Jan Ron McFadyen14 Include Relationship Suppose a Purchase order system has two use cases Place Order and Track Order and both contain customer validation. Customer validation could be factored out, resulting in: Validate Customer > Track Order Place Order Customer

Jan Ron McFadyen15 More terminology Place Order and Track Order are called concrete use cases because they are initiated directly by an actor. Validate Customer is an abstract use case because it is never instantiated by itself; Validate Customer is only instantiated as part of another use case.

Jan Ron McFadyen16 Include Relationship Suppose ATM has a base use case contains: 1.Show advertisement of the day 2.Include identify customer 3.Include validate account 4.… Validate Account > Identify customer Customer ATM session

Jan Ron McFadyen17 Extend Relationship The extend relationship is typically used for optional behaviour Extend is used to separate optional from mandatory behaviour; extend is used to distinguish variants in behaviour With include, the base use case explicitly incorporates the addition use case. With extend, the base use case implicitly incorporates the addition use case. Under a specified condition the base use case is extended with the behaviour specified in the addition use case. We say the addition use case is dependent on the base use case (note the directed line in the drawing)

Jan Ron McFadyen18 Extend Relationship Process Sale collects the payment from the customer. Suppose payment via a gift certificate is considered an exceptional case. See Figure 25.3 > Handle Gift Certificate Payment Cashier Payment, if the Customer presents a gift certificate Process Sale Extension Points: Payment

Jan Ron McFadyen19 Extend Relationship Process Sale declares/states “Payment” is an extension point, but Process Sale does not know anything else: the condition, the name of the other addition use case. (see page 389) > Handle Gift Certificate Payment Cashier Payment, if the Customer presents a gift certificate Process Sale Extension Points: Payment

Jan Ron McFadyen20 Generalization/Specialization Relationship Suppose there is more than one version of a use case, and that the different versions have some things in common and other things that differentiate them The general notation is Specialized use case name Generalized use case name

Jan Ron McFadyen21 Generalization/Specialization Relationship Example. Suppose we have a university registration system where people must be admitted to become students. Some potential students, who attended high school in the city, are already known to the university because they went through some prior screening processes. Admit new student Admit Student Admit HS student Admissions Clerk

Jan Ron McFadyen22 Generalization/Specialization Relationship Example. Suppose we have two ways to check someone’s identity: via a password or via a retinal scan Check Password Verify Identity Retinal Scan

Jan Ron McFadyen23 Generalization/Specialization Relationship Note that we could have used Include or Extend to document the same requirements in our system. Note page 390, that unproductive time may be spent trying to use Include, Extend and Generalization for requirements gathering.

Jan Ron McFadyen24 Generalization/Specialization of Actors Generalization can be applied to Actors. Example. Suppose for the department chair, who is a member of the faculty, there are some special duties FacultyChair Assign Grades Manage Sections Note that the Chair can do everything a faculty member can do, but also the Chair manages the sections of courses the department offers.

Jan Ron McFadyen25 Use Case Associations Between use case and actor –uses (unlabeled) Between use cases –include (dependency) –extend (dependency, condition) –generalization Between actors –generalization

Jan Ron McFadyen26 Use Case Exercises (part of Assignment #1) 1.Consider a library where members have library cards that identify themselves. Members may search the catalog, borrow books, return books, place holds on books, release holds, pay fines, and terminate their membership. Any person can enter the library in order to search the catalog or to become a member. To become a member a person must have some photo identification and fill out a form.