Transcript Use Cases
Use Cases Ivar Jacobson - guru at Rational Corp., defined UML Forms of Use Case Use cases can be presented graphically in a diagram or in prose form, somewhat structured and highly structured. Terms Use cases define the context of a system. 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 A primary actor is one having a goal requiring the assistance of the system. A secondary actor is one from which the system needs assistance to satisfy a goal. Use cases are useful in the SDLC 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. In the execution stage: provide developers key parts of the specification Use Case Diagrams Use case diagrams are external view of a system's interactions with the outside world. System is illustrated as a single entity. Each line represents a channel of dialog between the actor and the system. The oval icon encapsulates how the system achieves its goal structuring mechanism for interaction diagrams. The actual software is often structured in a completely different way. Example Notes: A line between an actor and the system represent a relationship of communication, acquaintance, or inheritance. A box defines the boundaries of related use cases. Relationship lines labeled <<uses>> illustrate how two use cases are combined. Relationship lines labeled <<extends>> illustrate an exception behavior or special case (much like a programming patch). These extensions are used to avoid bloating the amount of use cases in the model. 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 How it all fits together 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 website 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 Primary Actor: me, the claimant Goal: I get paid for my car accident Conditions: Everything is in order Outcome: Insurance company pays claim Use Case Prose cont. 1. 2. 3. 4. 5. Scenario: Claimant submits claim with substantiating data. Insurance company verifies claimant owns a valid policy (failure here probably means goal failure) Insurance company assigns agent to examine case. Agent verifies all details are within policy guidelines. (an interaction between the agent and secondary actors) Insurance company pays claimant (implies all preceding goals managed to pass) More Structured Use Case Prose Alistair Cockburn suggests a general form of prose using a event/response pair : <time or sequence factor> <actor> <action> <constraints> Convert to active voice the verbs listed in Sample Action Verbs Thus, typical sentences might look like: At any time after the clerk gets the quote, he may cancel the sale. Structured Use Case Prose Various authors have proposed methods to better structure use case writeups. Alistair Cockburn's template provides space for information that is filled out over several passes during the life of the project. An example is descriptions for failed Extensions to the use case. Attribute Goal in Context Description a longer statement of the goal in context if needed> Example Buyer issues request directly to our company, expects goods shipped and to be billed. USE CASE # a unique identifier assigned sequentially. 5 USE CASE NAME the goal as a short active verb phrase> Buy Goods Scope & Level what system is being considered black box under design> <one of : Summary, Primary Task, Subfunction> Company / Summary Preconditions what we expect is already the state of the world> We know Buyer, their address, etc. Success End Condition the state of the world upon successful completion> Buyer has goods, we have money for the goods. Failed End Condition the state of the world if goal abandoned> We have not sent the goods, Buyer has not spent the money. Primary Actors a role name or description for the primary actor> Buyer, any agent (or computer) acting for the customer Secondary Actors other systems relied upon to accomplish use case> credit card company, bank, shipping service Trigger the action upon the system that starts the use case> purchase request comes in. User Stories and Extreme Programming A recent innovation to use cases are User Stories as defined by practitioners of “Extreme Programming” abbreviated XP (before Microsoft stole it with massive advertising). 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.