Sept Ron McFadyen1 Use Cases Introduced by Ivar Jacobson in 1986 literal translation from Swedish ”usage case” Used to capture and describe the functionality encompassed in some system or subsystem – a tool for analysis A use case will illustrate one or more scenarios – one typical path and many alternative scenarios A use case captures a goal of using the system Use cases can be used to guide development of testing plans

Sept Ron McFadyen2 Use Cases Illustrated with diagrams and/or a behaviour specification (written in text form) A project may begin with the definition of many “brief” or “casual” use case definitions – a few sentences each. Later on, these can be become very formal or “fully dressed” (for example see alistair.cockburn.us/usecases/uctempla.htm) The UML defines the nature of the diagrams, but not the behaviour specifications – companies standardize their own approaches

Sept Ron McFadyen3 Use Cases in the UML Functionality under consideration is represented by use cases (named ellipses) Actors are connected to use cases they use through associations Use Cases

Sept Ron McFadyen4 Actor (typically a stick person) Use Case (a named ellipse) Associations (lines) –Between Actors and Use Cases –Between Use Cases –Between Actors Use Cases

Sept Ron McFadyen5 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 Advisor Chair

Sept Ron McFadyen6 Use Case Behaviour A use case is drawn as an ellipse, with its name within or below the ellipse A use case should be written as a behaviour specification separately from the diagram (the written use case) other UML diagrams (statechart, sequence, activity) can be used to illustrate behavioural information in a use case A use case will be implemented as a computer program and the actors initiate execution (or instantiation) of a use case A use case describe what a system does, not how it does it – a design activity is to determine how a use case is carried out.

Sept Ron McFadyen7 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

Sept Ron McFadyen8 Example: Processing a Sale at a Cash Register 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 …

Sept Ron McFadyen9 Process Sale Use Case 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

Sept Ron McFadyen10 Process Sale Use Case 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 is 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

Sept Ron McFadyen11 Use Case Associations Between use case and actor –uses Between use cases –include –extend –generalization Between actors –generalization

Sept Ron McFadyen12 Relating Use Cases Include relationship If one use case is designed to utilize the functionality of another use case there is an “include” dependency Consider that a base use case is executing. When it reaches the inclusion point, the included use case is instantiated and 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.

Sept Ron McFadyen13 Process Sale Use Case Extensions or Alternate Flows …… 7a. Customer pays with a credit card: include HandleCreditPayment 7b. Customer pays by cheque: include HandleChequePayment 7a and 7b show alternative ways for step 7 to complete The Process Sale use case has explicit statements referring to other use cases ….. These are include dependencies …. Like calling a function or subroutine Instead of the word include, we could use something else such as execute

Sept Ron McFadyen14 Include Relationship In the UML diagram Process Sale Handle Cheque 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 these dependencies

Sept Ron McFadyen15 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

Sept Ron McFadyen16 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

Sept Ron McFadyen17 Generalization/Specialization Relationship Example. Figure 3.14: specializations of RegisterCarSharer Manually add car sharer Register car sharer Transfer car sharer from web-server Car match administrator Add car sharer web service Third party

Sept Ron McFadyen18 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.

Sept Ron McFadyen19 Generalization/Specialization of Actors What use cases can a Faculty execute? What use cases can a Chair execute? FacultyChair Assign Grades Manage Sections

Sept Ron McFadyen20 Extend Relationship The extend relationship is typically used for optional behaviour Extend is used to separate optional from mandatory behaviour Under a specified condition the base use case is extended with the behaviour specified in the extending use case. We say the extending use case is dependent on the base use case (note the directed line in the drawing)

Sept Ron McFadyen21 Extend Relationship Process Sale collects the payment from the customer. Suppose payment via a gift certificate is considered an exceptional case, or for some reason we don’t want to alter the Process Sale use case > Handle Gift Certificate Payment Cashier Payment, if the Customer presents a gift certificate Process Sale Extension Points: Payment

Sept Ron McFadyen22 Extend Relationship Process Sale declares/states “Payment” is an extension point, but Process Sale does not know anything more about this - the condition, the name of the other use case, … > Handle Gift Certificate Payment Cashier Payment, if the Customer presents a gift certificate Process Sale Extension Points: Payment

Sept Ron McFadyen23 Example: Handle Gift Certificate Use Case Use Case UC7: Handle Gift Certificate Trigger: customer intends to pay with a gift certificate Extension Points: Payment in Process Sale Level: subfunction Main Success Scenario: 1.Customer gives gift certificate to cashier 2.Cashier enters id for gift certificate 3.System verifies certificate

Sept Ron McFadyen24 Example: Processing a Sale at a Cash Register Use Case UC1: Process Sale Primary Actor: Cashier … Preconditions: Cashier is identified and authenticated Postconditions: Sale is saved…Commissions recorded…Payment authorization approvals recorded Extension Points: Payment, step 7. 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 … There are no substantive changes to the Process Sale use case Why would we use extend instead of include?