Object-Oriented Software Engineering Use Case Fundamentals Paul J Krause

Outline Brief description of Use Cases and Actors Use Case terminology and methodology Detailed description of Use Case template Validating Use Cases

What are Actors and Use Cases? Actors - users of the system external entities (people or other systems) who interact with the system to achieve a desired goal. Use Cases - what happens when Actors interact with the system by recording all the ways the system is used (“cases of use”) we accumulate all the goals or requirements of the system.

Therefore: The Use Case is a collection of sequences of actions or events relating to a particular goal. The Collection of Use Cases (the Requirements Specification) should define all system behaviour relevant to the actors to assure them that all their goals are carried out properly. Any system behaviour that is irrelevant to the actors should not be included in the Use Case.

Actors: Primary and Secondary Primary Actor: a role name for the Actor that initiates the Use Case. Secondary Actor: other systems needed to accomplish Use Case.

Identifying Actors Who uses the system? Who installs the system? Who starts up the system? Who maintains the system? Who shuts down the system? What other systems use the system? Who gets information from this system? Who provides information to the system? Does anything automatically happen at preset times?

Examples of Actors Clerk Supplier Customer Shipping Company

Use Case Diagram Customer Supplier Place Order Supply Product Get Order Status Clerk Shipping Company Deliver Package Calculate Postage

Use Cases: Hold Functional Requirements in a easy to read, easy to track text format. Represents the goal of an interaction between an actor and the system. The goal represents a meaningful and measurable objective for the actor. Records a set of paths (scenarios) that traverse an actor from a trigger event (start of the use case) to the goal (success scenarios). Records a set of scenarios that traverse an actor from a trigger event toward a goal but fall short of the goal (failure scenarios or exceptional events). Are multi-level, one use case can use/extend the functionality of another.

Use Cases Do Not ... Specify User Interface Design They specify the intent, not the action detail. Specify implementation detail unless it is of critical importance for the Actor in order to be assured their goal has been met.

Use Cases Do ... Capture the Requirements for the system; Act as a springboard for software design; Act as a reference to validate the design against; Act as a foundation for Software Test and Quality Assurance; Act as an initial framework for the User Manual (if necessary).

Outline Brief description of Use Cases and Actors Use Case terminology and methodology Detailed description of Use Case template Validating Use Cases

Use Case Definitions Primary Actors: Secondary Actors: The Actor(s) using the system to achieve a goal. Secondary Actors: Actors that the system needs assistance from to achieve the Primary Actor’s goal.

A Use Case ... Is a collection of possible scenarios between the system under discussion and external Actors; Is characterised by the goal the Actor has; Shows how the Primary Actor’s goal might be delivered or might fail.

What’s a Use Case made of? Use Cases are goals made up of scenarios. Scenarios consist of a sequence of steps to achieve the goal: each step in a scenario is a “mini” goal of the use case which may be: another Use Case; an autonomous action or event. This last point means that Use Cases can have a hierarchical relationship.

Levels: Summary Level Use Case: User Level Use Case: Represent collections of User Level Goals. User Level Use Case: Represents a User Task - the level of greatest interest. Sub-function level Use Case: A sub-goal or step below the main level of interest to the User.

Outline Brief description of Use Cases and Actors Use Case terminology and methodology Detailed description of Use Case template Validating Use Cases

Reference: The following template is based on that used in: Alistair Cockburn, Writing Effective Use Cases, Addison Wesley. Other templates are available

Use Case Template Use Case: <the name should be the goal as a short active verb phrase> Exercise: Let’s have some names please!

CHARACTERISTIC INFORMATION Description: <a longer statement of the goal> Level: <Summary, Primary task, or Subfunction> Preconditions: <what we expect of the world> Postconditions: <the state of the world upon successful completion > Primary Actor: <a role name for the actor that initiates the Use Case> Secondary Actors: <Other actors needed to accomplish Use Case>

FLOW OF EVENTS Trigger: <the action upon the system that starts the use case; may be a time event> <put here the actions that take place from trigger to goal delivery, and any cleanup after> <step #> <action description> ….

EXCEPTIONAL EVENTS <put here the sub-variations that will cause eventual bifurcation in the flow of events> <step or variation # > <list of sub-variations> ….

RELATED INFORMATION (optional, applies to indicate the <<uses>>, <<extends>> relations) Superordinate Use Case: <optional, name of use case that includes this one> Subordinate Use Cases: <optional, depending on tools, links to sub.use cases>

Use Case: Place Order Customer Place Order

Use Case: Place Order Description: This Use Case describes how a customer selects an item to purchase and then places an order for that item. Level: Primary task Preconditions: The Customer is logged into the system Postconditions: A product has been ordered Primary Actor: Customer Secondary Actors: Credit Company

Place Order: Flow of Events Trigger: The Customer selects a Product category The Customer browses the chosen Product category page The Customer selects a specific Product to purchase The Customer adds the Product to their Shopping Cart The Customer may repeat events 1, 2 and 3 to add additional items to their Shopping Cart When ready, the Customer requests that the Order be commited to The Credit Company is notified to authorise the Customer’s credit rating If the credit rating is positive, the Order will be placed

Nouns as Candidate Classes Trigger: The Customer selects a Product category The Customer browses the chosen Product category page The Customer selects a specific Product to purchase The Customer adds the Product to their Shopping Cart The Customer may repeat events 1, 2 and 3 to add additional items to their Shopping Cart When ready, the Customer requests that the Order be commited to The Credit Company is notified to authorise the Customer’s credit rating If the credit rating is positive, the Order will be placed

Place Order: Exceptional Events The Customer may terminate the transaction at any point before Step 7 and the Order will not be placed 2a If the Product is out of stock, the customer will be notified and asked to confirm of they wish to continue with the selection 6a If the Customer’s credit rating is not satisfactory, the transaction will be politely terminated at this point

Outline Brief description of Use Cases and Actors Use Case terminology and methodology Detailed description of Use Case template Validating Use Cases

Remember, Use Cases …. Capture the Requirements for the system; Act as a springboard for software design; Act as a reference to validate the design against; Act as a foundation for Software Test and Quality Assurance; Act as an initial framework for the User Manual (if necessary).

Validating Use Cases? Ask the following questions: Is the Use Case complete? Are there any details that need to be added? Do I feel confident that the Actor’s goal is going to be properly met? Can I simplify the process depicted in the Use Case? Are there any additional Goals of the Actors that are not addressed? Are there any additional Actors that are not represented (directly of indirectly)?

Summary We have: Introduced Use Cases as Sequences of Actions, aimed at achieving a Goal of an Actor. Covered some basic definitions and methodology. Introduced the Use Case template. Emphasised the importance of Validating Use Cases.