Use Cases A Comprehensive Look

An Examination of Use Cases Mark Smith Director Operations Support Services Adaptis, Inc. ( [email_address] )

Use Case Topics The Use Case Model The Basics A Use Case is … Level of detail Paths Purpose of specification Elaboration (unfolding) Graphical representation Use case specification

The Use Case Model Definition A model of a domain or subject area A collection of use cases Defines “who” does “what” Who – the list of actors What – the list of use cases May have a business and/or system focus Contains An overview of the domain or project A use case “map” (summary of the use cases) Actor descriptions The detailed use case specifications

Use Case Model Elements Name & description of domain or project Use case map Actor list Roles Descriptions Model Use Case Specification Title Description Pre & Post Conditions Basic course of action . . . Use Case Specification Title Description Pre & Post Conditions Basic course of action . . . Use Case Specification Title Description Pre & Post Conditions Basic course of action . . . Use Case Specification Title Description Pre & Post Conditions Basic course of action . . .

The Use Case Map Tabular form Groups together all the use cases for an individual actor Tabular, use case or package diagram format Together - the use case maps define the scope being modeled Use Case Title Actor Schedule patient for appointment Receptionist Research Claim Billing Clerk Refer patient Referral Coord. Check patient for appointment Receptionist Use Case Diagram Package Diagram

The Missing Link Use Case Model Links the high-level context diagram and the individual system use cases Roadmap of the ground --scope-- the project will cover Connects initial project goals and development activities Excellent tool for keeping resources focused on value-added activities

A use case is … A structured textual specification Tells who (the actor) does what (the task) Actor Name Role of person performing task or interacting with system Desired result of value to actor Customer Pays bill Use case diagram Use Case Specification Title: Customer pays bill Description Pre-condition Post-condition Basic path Alternative paths Exception paths . . . Use case specification

In general - a Use Case Describes a task Performed by an actor Yielding a result of business value Business or system focus Task may be Interactive A system use case describes an actor’s interaction with a system in pursuit of the defined business goal Manual A sequence of actions performed by an actor Automated A sequence of steps performed by a program or script Customer pays bill

Level of detail Illustration taken from Writing Effective Use Cases – Alistair Cockburn Atomic, user level use cases are the goal for system requirements specification Summary User Sub-function Atomic Composite Business process Activity Activity Activity UC UC UC UC UC UC UC UC

Atomic vs. Composite use cases Atomic Singular with respect to: Who One primary actor What One primary goal When Once started, must be completed How Is interactive, manual, or automated, but not a combination May be a candidate for decomposition if It involves more that one actor that initiates an action Has two or more independent, well defined goals May be accomplished in independent steps (at different times) Is partially supported by a system (interactive or automated) and a partially manual task

A Use Case may have many paths A use case Has only one goal, with a single Starting point Ending point May describe multiple paths for getting from start to finish I.E. specify behavior for a variety of possible conditions Each conditions may require specific action(s) Example “ Customer pays bill” Multiple paths to achieve the goal Telephone payment By mail In person by check cash, etc. A path that does not lead to the goal Credit card is declined

Success and Failure Each path may lead to Success A scenario where the goal is achieved The basic success scenario Typical or normal success path Often referred to as the “ happy path .” Other success scenarios are called alternate paths Failure A scenario where the goal is not achieved but still protects the interests of the stakeholders .

The Basic Path Each use case has A start state Pre-conditions define what must be true at the starting point An end state Post-conditions define will be true upon successful conclusion A basic or “happy” path The simplest, “normal”, or most frequent set of steps for achieving the goal Pre-conditions Start Post-conditions End Action 1 Action 2 Action 3 Action 4

Alternative Paths Each use case may have extensions that result in achieving the goal These may be referred to as alternate paths Alternatate Departs after action 1 of the basic path Rejoins before action 4 Alternatate Departs after 1 st action of the alternative path Rejoins before action 4 Pre-conditions Start Post-conditions End Action 1 Action 2 Action 3 Action 4

Exception Paths Each use case may have extensions where the desired result is not achieved These may be referred to as exception paths Exception 1 Departs after action 3 of the basic path Does not rejoin the basic path The use case terminates Pre-conditions Start Post-conditions End Action 1 Action 2 Action 3 Action 4

The Use Case Specification A system use case will specify a collection of paths (scenarios) Use Case Specification Title Description Pre & Post Conditions Basic Path Alternative Path Alternative Path Alternative Path Alternative Path Exception Path

Complete specification of all paths A fully specified use case will define all of the ways in which the goal can be achieved All the paths from start to finish All the way in which the activity can fail to complete Specification Guideline : The 80/20 rule for alternate and exception paths Identify the condition Determine the frequency of occurrence Assigned a priority or rank And, only if necessary, specify the actions of the path Intent : Not to spend a significant amount of effort designing a process/system for a possibility that will rarely occur! Agile concepts!

Use Case Topics The Use Case Model The Basics A Use Case is … Level of detail Paths Purpose of specification - Business vs. System Use Cases Elaboration (unfolding) Graphical representation Use case specification

Level of abstraction: Business vs System A use case can stated in general terms, or specific to the technology required to accomplish the task Business focus (Technology/tool independent) Perspective: business role of the primary actor Portrays essence of business function Uses terminology of business domain Independent of specific tools required to perform the task System focus (UI independent) Perspective: business/end user role of the primary actor Portrays essence of system interaction Uses terminology of the business & system domain Independent of specific user interface System focus (UI specific) Perspective: business/end user role of the primary actor Portrays specifics of system interaction Uses terminology of the application domain Specific to the application use to perform the task

Business use case spec - example Title Banking customer withdraws cash Triggering event Customer identifies self Description Customer withdraws cash from a bank account Pre-conditions Account referenced (e.g., checking) is in good standing Account balance > withdrawal amount Post-conditions Account has been debited Basic course of action … Business use case – business task view

System use case spec - example Title ATM customer withdraws cash Triggering event Card inserted into ATM machine Description Customer withdraws cash from a bank account using an ATM Pre-conditions Account referenced (e.g., checking) is in good standing Account balance > withdrawal amount Post-conditions Account has been debited Basic course of action … System use case –business task view utilizing a system to complete the task

Business & system example – basic path Basic course of action Customer identifies self Customer makes “withdrawal” request Transaction account Transaction amount Bank representative Dispenses cash Provides transaction receipt Inquires if another transaction is desired Customer indicates “no” Basic course of action Customer inserts card System prompts for PIN Customer enters PIN System asks for transaction type Customer indicates “withdrawal” System asks for account type Customer indicates account type System asks for amount Customer enters amount System displays advertisement System dispenses cash System prints receipt Systems asks “another transaction?” Customer indicates “no” System ejects card Systems displays start screen

Some use cases may be sufficiently specified at level II Stop when sufficient detail is achieved Unfolding The use case model and its individual use cases evolve level by level over time Not all use cases of a model will necessarily need to be specified to the same level of detail Alternate & Exception Paths Basic Path Pre- & Post-conditions Name & Description Includes/ Extends Relationships L 1 Level 2 Level 3 Level 4 Level 5

Establish the foundation Focus on the big picture - steps I & II pertain to the use case model I. Define the scope by completing the use case map List actors Enumerate use cases for each actor II. Refine the model & understand dependencies Identify beginning & end points for each Define pre- and post-conditions Determine “how often” each case occurs Sketch the work flow showing the dependencies As the model evolves cases may be added, dropped or their priority changed

Unfold each use case – level by level Detailed analysis may be planned for an appropriate iteration - steps III & IV pertain to individual use cases III – Individual use cases - define basic path Actions that comprise “happy path” IV – Define extensions Alternative paths Identify conditions, frequency, & steps for each (as needed) Exception paths Identify conditions, frequency, & steps for each (as needed) V - Refine structure May be illustrated with a use case diagram Identify common actions (<<includes>> relationships) Diagram key special cases (<<extends>> relationships)

Use Case Topics The Use Case Model The Basics A Use Case is … Level of detail Paths Purpose of specification Elaboration (unfolding) Graphical representation Additional views & supporting UML diagrams Use case specification

Supporting Views Summary or Scope - Use case diagram Use case dependency – Activity diagram Scenario interaction – Interaction diagram Scenario – composite view – State diagram Entity state (from use cases) - State diagram

Example of use case diagram <<extends>> Limits exceeded Trader Analyze risk Price deal Capture deal Salesperson Valuation <<includes>> <<includes>>

Diagramming Use Case Dependencies UML activity diagrams may be used to Show use case sequence Provide a view of a the business activity [No covered] [Authorization not required] [Covered] Admit Patient Check Eligibility /Benefit Notify Health Plan Request authorization Confirm authorization [Authorization required]

Use Case and High Level Sequence Diagram Find a Claim – Use Case (Design considerations in parenthesis) Basic Path 1. User initiates a claim search per submitted criteria. 2. System returns subset of search results (display of 10 @ a time) 3. User selects claim (click item in upper list pane; item highlighted) 4. System returns claim summary (lower preview pane) 5. User requests full claim detail (link/button from preview pane) 6. System returns full claim detail (pop up -claim header with vertical list of services and encounter details) 7. Repeats process if applicable beginning at step 3 or back to step 1. Alternate Path – Encounter Detail Leaves Basic Path after 4. Returns to Basic Path at 7 1. User requests Encounter detail (encounter hyperlink in claim summary) 2. System returns Encounter detail (pop up -claim header & encounter header with vertical list of service level details) Alternate Path – Claim Detail via Encounter Detail Leaves Basic Path after 4 Returns to Basic Path at 6 1. User requests Encounter detail (encounter hyperlink in claim summary) 2. System returns Encounter detail (claim header & encounter header with vertical list of service level details) 3. User requests full claim detail (link/button from encounter detail screen) Alternate Path – Sort Leaves Basic Path after 2 Returns to Basic Path at 3 1. User sorts list by column heading (i.e. Dates of Service in ascending order) 2. System returns subset of search results in new sort order. (Different set of 10 from full search results) Exception Path - Invalid Search Criteria Leaves Basic Path after 1 1. System returns no records that match criteria 2. System returns error message 3. System directs user back to search page (Can we maintain state from previous search?)

Diagramming interaction - Make a phone call Interaction diagram illustrates basic course

Composite – representing multiple scenarios State diagram summarizes Basic course & 7 alternative paths

CRUD Matrix Combining Use Case & Class Views Entity classes Use Cases & Scenarios Use Case Class UC UC UC Class Class Class C U U C D C Use Cases Class Model

Modeling Entity State Behavior Use Case Entity UC UC UC Entity Entity Entity C U U C D C Use Cases Entity State Model S 1 S 2 S 3 Class S 1 S 2 S 3

Use Case Topics The Use Case Model The Basics A Use Case is … Level of detail Paths Purpose of specification Elaboration (unfolding) Graphical representation Use case specification Use case template & guidelines for each element

Components of a Use Case A use case template may contain the following elements. Title Actor(s) Description Trigger Pre-conditions Post-conditions Basic Path Alternate conditions & paths* Exception conditions & paths* *If applicable Customize the template to meet the needs of the project

Title Title Should state the goal of the use case End result that is of business value to the primary actor Use “verb noun” phrasing E.G. “Place order” The primary actor is the implied subject “ Customer Place s order” Use the vocabulary of the business Rather than the technical terms or jargon Use strong verbs Rather than mushy verbs like “maintain”

Title (continued) Title Try the “reverse it” test Flip the verb noun phrase “ noun verb’ed” It should state the result of value An example that passes the test Place order >reversed> Order has been placed An example that fails the test Maintain employee list >reversed> Employee list is maintained This is an ambiguous goal & indicates that the use case should be renamed to be more specific

Actors Actors The Primary Actor is the person (role) or external system initiating the use case The primary actor is the implied subject “ Customer Place s order” There can be multiple actors in a use case. Supporting actors are external actors (including systems) that participate or provide input in the use case but do not initiate it.

Description Description A brief summary Elaborates on the title Clarifies the essence of the use case Focus is on what is to be accomplished in the use case, not the method or reasoning behind it

Description (continued) Description The description may Start as a narrative (level 1) End as a short, concise summary of a task (level 3 and higher) As a use case unfolds, information in the description may end up in other elements of the specification When initially written, the description Will further describe business value provided Amply on end result May include mention of the inputs provided May mention the “start” and “end” states In terms of preceding & following use cases And/or in terms of business objects produced or modified May mention of actors other than the primary actor

Initiation of a use case How the trigger event and pre-conditions work together … When the trigger event occurs … The pre-conditions are “checked” before the 1 st step of the UC is taken Pre-conditions are also referred to as “guard” conditions In words When the _<event>_ occurs AND all of the pre-conditions have been found to be true THEN proceed with the use case

Trigger Trigger An event that initiates an occurrence of the use case Source of event Person Clock or calendar Another system Triggers may be the first step in the use case, but are not always Example: Use Case Title: ATM customer withdraws cash Trigger: Card inserted into ATM

Pre-conditions Pre-conditions Assertions stating what conditions must be true in order for an occurrence of the use case to begin A pre-condition may be stated in terms of the “state” of Business object (or, related information) “ ___ must exist” “ ___ must exist and be in state ___” Business process “ Action XYZ must have … “ Successfully completed Failed Produced result x The system “ The ___ workspace is open” “ A new ___ has been opened”

Initiation –Special case There may not be a single triggering event The special case in general terms: Two or more prerequisites must become true AND Order is not important Trigger The final prerequisite to become true triggers the occurrence of the use case If all the other prerequisite conditions are still true In words When all of the pre-conditions have been found to be true THEN proceed with the use case

Post-conditions Post-condition An assertion stating what conditions are true upon the successful completion of the use case A post-condition may be stated in terms of the “state” of Business object (or, related information) The results produced by the use case just completed “ ___ created” “ ___ created and in ___ state” “ ___ updated to reflect ___” “ ___ updated to be in state ___” “ ___ deleted” Business process The state of the containing process relating to what can happen next “ Action QRS … “ Can now be initiated Must be initiated “ This use case may now be initiated for the next ___” The system The result is apparent to the user “ The revised ___ is displayed”

Basic Path Basic path Typical, most frequent, shortest, simplest … Enumerates actions performed to accomplish goal Actions performed by A participating actor The system Coburn defines three types of actions: An interaction or information flow “ Member submits claim” A validation step System confirms eligibility An internal change “ System suspends claim” Action 1 Action 2 Action 3 Action 4

Alternative Path Alternative path Describes an extension to the basic path Starts with a condition Departs after a specific step Enumerates actions performed as a result of the condition May rejoin the basic path Accomplishes goal Action 1 Action 2 Action 3 Action 4 1a1 1a2 1a Condition … Rejoin

Exception Path Exception path Describes an extension to the basic path Starts with a condition Departs after a specific step Enumerates actions performed as a result of the condition Does not rejoin the basic path Does not accomplished the goal 3a Condition Action 1 Action 2 Action 3 Action 4 Condition Rejoin 3a1

Use Cases A Comprehensive Look

More Related Content

What's hot

Similar to Use Cases A Comprehensive Look

More from telab

Recently uploaded

Use Cases A Comprehensive Look

Editor's Notes