On the true nature of use case actors

The use case actor remains either undefined or ill-defined.

As is well known, Jacobson’s use cases went mainstream in ‘92 without benefit of a rigorous definition.  While that choice was arguably key to their successful initial adoption, as their use has matured a consensus formalism (well, formal enough – call it a ’soft’ formalism) has emerged, driven first by Alistair Cockburn’s ‘Structuring Use Cases with Goals’ and later by the adoption of use cases in UML.

But that consensus has a significant gap that is still in my experience the source of endless debate and the cause of practical problems: the actor.

Closing that gap – getting at the true nature of use case actors – is the goal of today’s rumination.

There is simply not a common working understanding of what an actor is.  I have had very senior systems analysts tell me they really only did use cases for human actors – anything else was an integration problem.  As a partial result, that shop’s requirements docs confusingly include both SSA-style context diagrams as well as use case diagrams.  (Of course SSA’s ‘is it an internal or external system’ is simply the same issue in a different guise.)

It’s so bad that in a recent (2006) book on UML 2.0 (‘Learning UML 2.0′ by Russ Miles and Kim Hamilton) the authors start to throw in the towel and say you’ll know an actor when you see one:

“Deciding what is and what isn’t an actor is tricky and is something best learned by experience.”

Then in some sort of pole shift they throw the reader a bone in the form of an actor-identification algorithm:

“Identify a Thing from your requirements.  Is it an actual person?  If yes, it is _probably_ an actor – but be careful, some people are a actually part of the system.  If the thing is not an actual person, then it is something you can change in the system’s design?  If yes, then it is probably _not_ an actor.  If no, then is probably is an actor.”

Sorta maybe kinda.

And a little further on…in a section called ‘Tricky Actors’ (you can’t make this stuff up):

“Not all actors are obvious external systems or people that interact with your system.  An example of a common tricky actor is the system clock.  The name alone implies the clock is part of the system.  But is it really?  The system clock comes into play when it invokes some behavior within your system.  It is hard to determine if the system clock is an actor because the clock is not clearly outside of your system. As it turns out, the system clock _is_ often best described as as actor because it is something you can’t influence.”

Come again? (It’s a red flag for me when what I’m reading starts to sound like an Abbott and Costello routine.)

And from Doug Rosenberg and Matt Stephens’s 2007 ‘Use Case Driven Object Modeling with UML‘:

“An actor is represented on the diagram by a stick figure and is analagous to a ‘role’ that users can play.”

“Actors can represent nonhuman external systems as well as people. Sometimes people are confused by this notion; we’ve found that drawing a ‘robot stick figure icon’ seems to clear this up.”

Evil Robots!  Cool.

In fairness to the authors – who I don’t mean to impugn, I’m just having a little fun at their expense – the Schadenfreude is yours, gentle reader – earlier, more authoritative, less florid works did not much improve on Jacobson.

From the OMG’s UML standard we take the following:

“An actor in the Unified Modeling Language (UML) “specifies a role played by a user or any other system that interacts with the subject.”

“An Actor models a type of role played by an entity that interacts with the subject (e.g., by exchanging signals and data), but which is external to the subject.”

“Actors may represent roles played by human users, external hardware, or other subjects. Note that an actor does not necessarily represent a specific physical entity but merely a particular facet (i.e., “role”) of some entity that is relevant to the specification of its associated use cases. Thus, a single physical instance may play the role of several different actors and, conversely, a given actor may be played by multiple different instances.”

That last one was pretty circular, wasn’t it.  Craig Larman, hedging his bet carefully, gives us an ‘informal definition’ in his Applying UML and Patterns from 2002:

“First for some informal definitions.  An actor is something with behavior, such as a person (identified by role), computer system, or organization ; for example, a cashier.”

And in a work citing Jacobson himself as an author,  ‘Use Case Modeling,’ the 2003 book by Kurt Bittner and Ian Spence and Ivar Jacobson , we find the prosaic ‘[a]ctors represent the people or things that interact with the system; by definition, they are outside the system. We focus on the actors to ensure the system does something useful.”

Cockburn – if Jacobson is the father of use cases Cockburn is the oldest son – says in his seminal ‘Structuring Use Cases with Goals‘ that

“[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 its goal. One of the actors is designated as the system under discussion.

Each actor has a set of ‘’responsibilities’’. To carry out that responsibility, it sets some goals. To reach a goal, it performs some actions. An ‘’action’’ is the triggering of an interaction with another actor, calling upon one of the responsibilities of the other actor (see also Figure 3)[not shown here - Ed.]. If the other actor delivers, then the primary actor is closer to reaching its goal. The entity-relationship diagram corresponding to this is shown in Figure 2.

Figure 2 says that there are internal and external actors. An external actor can be a person, a group of people or a system of any kind. The internal actor may be the system in design, a subsystem or an object. The system in design consists of subsystems, which consist of objects. Actors have behavior(s). The top-level behavior is a responsibility. It contains goals, which contain actions. An action triggers an interaction. The interaction is one actor’s goal calling upon another actors (or its own) responsibility.”

This is much better…although a goal calling on a responsibility doesn’t really work, does it?  The previous authors have attempted to identify an actor by listing its attributes – a dog is furry, has four legs, and barks.  But we need to understand something like an actor by placing it in a context, such as Cockburn has done.  But is has to be a logical context, one that makes sense.   And as we’ll see, Cockburn’s is both incomplete and inaccurate.   And we are completely missing an understanding of an actor’s essense.  For better or worse, our Folk IT understanding (the subject of the next rumination!) is based on essences.

So what do we have so far?   A collective definition synthesized from the aforementioned sources would be something like this:

“An actor is an person, system, or clock external to the in-scope system with goals which require them to engage in behaviors interacting with the in-scope sytem to achieve.”

Let’s analyze this.

First, can a system really have a goal?  Of course not.  Systems are tools…no matter how sophisticated (and leaving the Strong AI debate for a different day), they have purposes, not goals.  A cup is designed and built to achieve the user’s goal of having a drink.

So if a system can’t have a goal, how can a system be an actor?  It can’t, at least as described by Cockburn’s framework.  So the framework fails.

Who or what has goals, and what is their relationship to the system in question?

Simply put, humans, both singly and in groups, have goals.   The pursuit of a goal is an act of will.   The ability to achieve goals in the face of obstacles is intelligence.  The pursuit is a moral act – the agent is responsible for the outcome.

This is so fundamental it is reflected in language itself.  In Pinker’s ‘The Stuff of Thought’ we find this:

“Linguists sort verbs into classes, each called an ‘Aktionsart’, German for “action type,” based on their temporal conture….Each of the four major action classes, state, activity, culmination, and accomplishment, smuggles in a concept of will….Activities and accomplishments are voluntary,  state and culmination involuntary….Indeed, with an accomplishment it is the actor’s goal that determines the exact event that consummates it.  Once again, this is not just a fine point of grammar but a key to our moral sense.”

So the fundamental actors are those humans and groups of humans who can exercise will.  We shall call them ‘volitional entities.’  And the fundamental relationship of volitional entities to our systems is a moral one – they are responsible for the actions they take with the system to achieve their ends.

The practical relationship of an actor to an in-scope system is one of communication.  There must be some direct chain of events from a physical action – clicking a mouse, pushing a button, inserting a card, speaking a word – that triggers a state change in the in scope system.

When a volitional entity is a person, they may interact directly with the in scope system.  But when a volitional entity is a group, they have no direct ability to interact…a company doesn’t have a voice, or fingers.  So they have to communicate indirectly.

So what are system actors?   When a system is an actor, it is only so because it in turn has been driven by a volitional entity who has triggered its actions – or by another system which in turn was put in motion by a volitional entity, etc.    So the volitional entity is interacting indirectly with the in scope system – so in a sense the in-scope system is simply acting as a component of a larger system – and the volitional entity, the primum movens, is still responsible for the actions of the in-scope system.

A clock actor simply refers to a system actor whose purpose is narrowly to express the deferred will of the volitional entity as to when something occurs.  For actions whose period is arbitary, such as daily batch jobs, the will may not be just the timing, but that is happens at all, that is, the clock is a way to express the will of the group.

A rule actor would be the more general case, where the volitional entity has codified their will to have particular things happen in particular circumstances.  Unlike the clock actor, whose triggering domain is just the clock, the rule actor’s domain includes a larger set of states, usually including some business subdomain.

Ok.  We seem to have made some progress.  Let’s recap.

A volitional entity is human or group of humans – Fowler’s ‘Party’ – which can attempt to achieve goals by interacting with systems.  They are morally responsible for the outcomes.

A volitional entity’s will can be exercised in pursuit of a goal with respect to a given system either directly or indirectly.

When it is expressed directly, the volitional entity is a human engaged in physical communication with the system.

When it is expressed indirectly, some other system is engaged in physical communication with the in scope system.  That system in turn has either been directly or indirectly engaged by a volitional entity.  The primum movens, the ‘first mover,’ will always be either a human or an event-triggering system that has been programmed by a human or group to initiation an action according to a set of environmental rules – at a given time, or at a give barometric pressure, etc.

So a use case actor is an object which represents a direct or indirect volitional entity’s communication with an in-scope system.  A complete use case picture would have at its periphery only volitional entities, which are both the primum movens and moral owners of any system behaviors.