The Unified Modeling Language (UML1) defines an Actor (from
UseCases) as:
An actor specifies a role played
by a user or any other system that interacts with the subject.
In Alistair Cockburn’s book “Writing Effective Use Cases” (2) Actors
are further defined as follows:
Primary Actor: The primary actor of a use case is the stakeholder that
calls on the system to deliver one of its services. It has a goal with respect
to the system – one that can be satisfied by its operation. The primary actor
is often, but not always, the actor who triggers the use case.
Supporting Actors: A supporting actor in a use case in an external
actor that provides a service to the system under design. It might be a
high-speed printer, a web service, or humans that have to do some research and get
back to us.
In a 2006 article (3) Cockburn refined the definitions
slightly to read:
Primary Actors: The Actor(s) using the system to achieve a goal. The
Use Case documents the interactions between the system and the actors to
achieve the goal of the primary actor.
Secondary Actors: Actors that the system needs assistance from to achieve
the primary actor’s goal.
Finally, the Oracle Unified Method (OUM) concurs with the
UML definition of Actors, along with Cockburn’s refinement, but OUM also includes
the following:
Secondary actors may or may not
have goals that they expect to be satisfied by the use case, the primary actor
always has a goal, and the use case exists to satisfy the primary actor.
Now that we are on the same “page”, let’s consider two
examples:
A bank loan officer wants
to review a loan application from a customer, and part of the process involves a real-time credit rating check.
Use Case Name: Review Loan Application
Primary Actor: Loan Officer
Secondary Actors: Credit Rating System
A Human Resources manager wants to change the job code of
an employee, and as part of the process, automatically notify several
other departments within the company of the change.
Use Case Name: Maintain Job Code
Primary Actor: Human Resources Manager
Secondary Actors: None
The first example is quite straight forward; we need to
define the Secondary Actor because without the “Credit Rating System” we cannot
successfully complete the Use Case. In other words, the goal of the Primary
Actor is to successfully complete the Loan Application, but they need the explicit
“help” of the Secondary Actor (Credit Rating System) to achieve this goal.
The second example is where people sometimes get confused.
Within OUM we would not include the “other departments” as Secondary Actors and therefore not include them on the Use Case diagram
for the following reasons:
The other departments are
not required for the successful completion of the Use Case
We are not expecting any
response from the other departments (at least within the bounds of the Use
Case under discussion)
Having said that, within the detail of the Use Case
Specification Main Success Scenario, we would include something like:
“The system sends a notification to the related department
heads (ref. Business Rule BR101)”
Now let’s consider one final example.
A Procurement Manager wants to place a “bid” for some goods
using an On-Line Trading Community (B2B version of eBay)
Use Case Name: Create Bid
Primary Actor: Procurement Manager
Secondary Actors: On-Line Trading Community
You might
wonder why the Trading Community is listed as a Secondary Actor, i.e. if all we
are going to do is place a bid for a specific quantity of goods at a given
price and send that off to the Trading Community, then why would the Trading
Community need to “assist” in that Use Case?
Well, once
again, it comes back to the “User Experience” and how we want to optimize that
when we think about our Use Case, and ultimately, when the developer comes to
assembling some code.
In this
final example, the Procurement Manager cannot successfully complete the “Create
Bid” Use Case until they receive an affirmative confirmation back from the
Trading Community that the Bid has been accepted. Therefore, the Trading
Community must become a Secondary Actor and be referenced both on the Use Case
diagram and Use Case Specification.
Any astute
readers who are wondering about the “single sitting” rule will have to wait for
a follow-up Blog entry to find out how that consideration can be factored in!!!
Happy Use Case writing!
(1)
OMG Unified Modeling LanguageTM (OMG UML), Superstructure Version
2.4.1
(2) Cockburn, A, 2000, Writing Effective Use
Case, Addison-Wesley Professional; Edition 1
(3) Cockburn, A, 2006 “Use Case fundamentals”
viewed 20th March 2012, http://alistair.cockburn.us/Use+case+fundamentals
