proprietary and confidential an examination of use cases mark smith director operations support...

Proprietary and Confidential

An Examination of Use Cases

Mark Smith Director Operations Support Services Adaptis, Inc. ([email protected])

Proprietary and Confidential 2

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 & descriptionof domain or project

Use case map

Actor list Roles Descriptions

Use Case Specification Title Description Pre & Post Conditions Basic course of action . . .




Model


The Use Case MapActor Use Case Title

Receptionist Check patient for appointment

Receptionist Schedule patient for appointment

Billing Clerk Research Claim

Referral Coord. Refer patient

Admit Patient

<<extends>>

Notify Health Plan

Request Authorization

<<extends>>

Check Eligibility/Benfit

<<includes>>

Confirm Authorization

<<extends>>

Use Case Diagram

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

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

SystemEnvironment

Use Case Model --Actor List --Use Case Map

Use Case Specification

Context Diagram


Use Case Topics

The Use Case Model






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 ofvalue 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 . . .



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


Use Case Topics

The Use Case Model






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


Use Case Topics

The Use Case Model






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-conditionsStart

Post-conditionsEnd

Action 1

Action 2

Action 3

Action 4


Alternative Paths

Each use case may haveextensions that result in achieving the goal

These may be referred to as alternate paths» Alternatate

• Departs after action 1of the basic path

• Rejoins before action 4

» Alternatate• Departs after 1st action

of the alternative path• Rejoins before action 4

Pre-conditionsStart

Post-conditionsEnd

Action 1

Action 2

Action 3

Action 4


Exception Paths

Each use case may haveextensions 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-conditionsStart

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


- Business vs. System Use Cases Elaboration (unfolding)




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 viewutilizing 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


Use Case Topics

The Use Case Model






Some use cases may be sufficiently specified at level II

Stop when sufficient detail is achieved

Alternate & Exception Paths

Basic Path

Pre- & Post-conditions

Name & Description

Includes/Extends Relationships

Unfolding

L 1

Level 2

Level 3

Level 4

Level 5

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


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 levelDetailed 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



Graphical representation» Additional views & supporting UML diagrams



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>>


Another Use Case Diagram

Admit Patient

AdmissionsClerk

<<extends>>

Notify Health Plan

Request Authorization

<<extends>>

Check Eligibility/Benfit

<<includes>>

Confirm Authorization

<<extends>>


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 PatientCheck Eligibility

/BenefitNotify

Health PlanRequest

authorizationConfirm

authorization

[Authorization required]


User

System

Find a Claim – Sequence Diagram

initiate search

return results

select list item

return claim summary

select claim detail

return claim detail of services

option

select encounter detail

return encounter detail of services

select claim detail

return claim detail of services

detail = full (all services for claim)

detail = encounter (all services for specific encounter)

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 DetailLeaves Basic Path after 4.Returns to Basic Path at 71. 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 DetailLeaves Basic Path after 4Returns to Basic Path at 61. 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 – SortLeaves Basic Path after 2Returns to Basic Path at 31. 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 CriteriaLeaves Basic Path after 11. 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?)

Use Case and High Level Sequence Diagram


Diagramming interaction - Make a phone call

Caller Called Party

:PhoneSystem

Lift ReceiverLift Receiver

Dial ToneDial Tone

DialFirstDigetDialFirstDiget

No Dia lToneNo Dia lTone

AdditionalDigitsAdditionalDigits

Ringing ToneRinging Tone RingRing

Lift RecieverLift Reciever

No Ringing ToneNo Ringing Tone Stop RingStop Ring

Establish ConnectionEstablish Connection Establish ConnectionEstablish Connection

Hang UpHang Up

DisconnectDisconnect DisconnectDisconnect

Hang UpHang Up

Interaction diagram illustrates basic course


Composite – representing multiple scenarios

Idle

Dial tone

Dialing

Connecting

Ringing

Connected

Disconnected

Busy

Playingrecordedmessage

[Line is busy][Line is busy]

[Trunk is busy][Trunk is busy]

HangUpHangUp

[invalid number][invalid number]

[Time out][Time out]

HangUpHangUp

Additional DigitsAdditional Digits

LiftReceiverLiftReceiver

Dial First DigetDial First Diget

[valid number][valid number]

[connected][connected]

LiftRecieverLiftReciever

HangUpHangUp

HangUpHangUp



State diagram summarizes

Basic course & 7 alternative paths


CRUD Matrix Combining Use Case & Class Views

Entityclasses

Use Cases& Scenarios

Use Case

Class

UC

UC

UC

Class Class Class

C

U U

C D

C

Use Cases

Class Model


Use Case

Entity

UC

UC

UC

Entity Entity Entity

C

U U

C D

C

Modeling Entity State Behavior

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




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 applicableCustomize the templateto 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 Places 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 Places 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 1st 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

Action 1

Action 2

Action 3

Action 4

Condition

Rejoin

3a13a Condition

proprietary and confidential an examination of use cases mark smith director operations support...

Documents

use case topics

use case maps

use case model elements

use case model definition

use case map summary

list of use cases

collection of use cases

use cases actor descriptions