1. Use Cases Ivar Jacobson - guru at Rational Corp., defined UML

2. Forms of Use Case n Use cases can be presented graphically in a diagram or in prose form, somewhat structured and highly structured.prose form, somewhat structuredhighly structured

3. Terms n Use cases define the context of a system. n Use cases identify the intent satisfying the role assumed by external “actors" interacting with the “system under discussion/test”.  A role is an instance of an encapsulated set of properties and behavior n A primary actor is one having a goal requiring the assistance of the system. n A secondary actor is one from which the system needs assistance to satisfy a goal.

4. Use cases are useful in the SDLC n In the planning stage:  defining important use cases clarifies the most important goals of the system.  help to narrow the scope of the project.  surface unspoken assumptions  add a level of abstraction to object-based constructs. n In the execution stage:  provide developers key parts of the specification

5. Use Case Diagrams n Use case diagrams are external view of a system's interactions with the outside world. n System is illustrated as a single entity. n Each line represents a channel of dialog between the actor and the system. n The oval icon encapsulates how the system achieves its goal  structuring mechanism for interaction diagrams.interaction diagrams  The actual software is often structured in a completely different way.

6. Example

7. Notes: n A line between an actor and the system represent a relationship of communication, acquaintance, or inheritance. n A box defines the boundaries of related use cases. n Relationship lines labeled > illustrate how two use cases are combined. n Relationship lines labeled > illustrate an exception behavior or special case (much like a programming patch). n These extensions are used to avoid bloating the amount of use cases in the model.

8. Jacobson Use Case Model Widely accepted documentation protocol for OOD and OOP. Lines from a box point to lower-level entities -- subdivision -- subgoals. Ivar Jacobson Guru at Rational Corp. Defined UML

9. How it all fits together n Use cases are one aspect of a complete design, described in this graphic from a pdf file named “Structure and Style in Use Cases for User Interface Design” at Larry Constantine's websiteLarry Constantine's website

10. Use Case Prose There is no industry standard to describe use cases using sentences, but here is a typical example: System under discussion: the insurance company n Primary Actor: me, the claimant n Goal: I get paid for my car accident n Conditions: Everything is in order n Outcome: Insurance company pays claim

11. Use Case Prose cont. n Scenario: 1. Claimant submits claim with substantiating data. 2. Insurance company verifies claimant owns a valid policy (failure here probably means goal failure) 3. Insurance company assigns agent to examine case. 4. Agent verifies all details are within policy guidelines. (an interaction between the agent and secondary actors) 5. Insurance company pays claimant (implies all preceding goals managed to pass)

12. More Structured Use Case Prose Alistair CockburnAlistair Cockburn suggests a general form of prose using a event/response pair : Convert to active voice the verbs listed in Sample Action Verbs Sample Action Verbs Thus, typical sentences might look like: At any time after the clerk gets the quote, he may cancel the sale.

13. Structured Use Case Prose n Various authors have proposed methods to better structure use case writeups. n Alistair Cockburn's template provides space for information that is filled out over several passes during the life of the project. Alistair Cockburn's template n An example is descriptions for failed Extensions to the use case.

14. AttributeDescriptionExample Goal in Contexta longer statement of the goal in context if needed> Buyer issues request directly to our company, expects goods shipped and to be billed. USE CASE #a unique identifier assigned sequentially.5 USE CASE NAMEthe goal as a short active verb phrase>Buy Goods Scope & Levelwhat system is being considered black box under design> Company / Summary Preconditionswhat we expect is already the state of the world>We know Buyer, their address, etc. Success End Conditionthe state of the world upon successful completion> Buyer has goods, we have money for the goods. Failed End Conditionthe state of the world if goal abandoned>We have not sent the goods, Buyer has not spent the money. Primary Actorsa role name or description for the primary actor>Buyer, any agent (or computer) acting for the customer Secondary Actorsother systems relied upon to accomplish use case> credit card company, bank, shipping service Triggerthe action upon the system that starts the use case> purchase request comes in.

15. User Stories and Extreme Programming n A recent innovation to use cases are User Stories  as defined by practitioners of “Extreme Programming”“Extreme Programming”  abbreviated XP (before Microsoft stole it with massive advertising). n User stories are unstructured sentences  written by the customer  without technical term  define what a proposed system needs to do for them  focus on user needs and benefits, not GUI layouts.