RULE 3: Never mix your Actors
The UML definition of an Actor is an external entity that interacts with the system under development. In other words: it’s a stakeholder.
Having analysed all your stakeholders (see Part 3 ) it’s tempting to stick them (no pun intended) as actors on a use case diagram and start defining use cases for each.
Each set of stakeholders (Users, Beneficiaries or Constrainers) has its own set of concerns, language and concepts:
Each stakeholder group has a different set of issues, problems, wants and desires. For example, Users are interested in functionality; Constrainers in compliance.
The way a system is perceived by the stakeholders depends on their viewpoint, their needs, their technical background, etc. Each group’s paradigm – their way of perceiving the system – will be different and involve often subtly different concepts. For example, Users may have no concept of return-on-investment (RoI) for the system; whereas this may be a key concept to a Beneficiary.
Just as concepts are different; so is the language used to describe them. In many cases, the same word is used in different contexts to mean different things. For example: how many different concepts of ‘power’ can you think of? Mechanical, physical, electrical, political…
It is vital never to mix actors from different stakeholder groups on the same use case diagram. Trying to mix actors leads to ambiguity and confusion; both for the writer and reader! The differences in concept, viewpoint and language will make the use case almost impossible to decipher and understand.
By all means draw a separate use case diagram for each set of stakeholders. (Note: non-User stakeholder use case descriptions is beyond the scope of this article)
Glennan is an embedded systems and software engineer with over 20 years experience, mostly in high-integrity systems for the defence and aerospace industry.
He specialises in C++, UML, software modelling, Systems Engineering and process development.