Rule 12: Avoid variations on a theme
A common affliction amongst novice use case modellers (particularly those from a development background) is the desire to fettle the use case model – to organise it, revise it, balance it; and generally make it look more like a design model. Unfortunately, beyond a certain point this effort actually starts to degrade the utility and effectiveness of the model. More and more effort is put into a model that becomes less and less useful to the customer and the analyst.
This all-too-common situation is known as ‘Analysis Paralysis’.
I always advise, unless you can provide a really compelling reason to do otherwise avoid associations between use cases. Yes, you might have a less optimal model, but at least your stakeholders will find it easy (or easier) to follow. This is price you always pay with use case associations: Elegant but complicated to understand, versus sub-optimal but explicit. In my view explicit always wins; after all, we’re trying to understand the problem, not design a solution.
Case in point: Use case specialisation.
In UML a use case (and indeed an actor) is a special form of classifier. One of the properties of classifiers is that they can be specialised – that is, a new classifier may be defined that has the properties and behaviours of the parent, but may extend or modify these attributes. The definition of the specialised classifier is that it is also a the type of its parent – that is, all instances of the specialised classifier form a subset of the set of parent classifiers.
Use case and actor specialisation
In use case terms it means we can define actors or use cases that represent specialisations of some base behaviour. As part of our analysis we may choose to define actors whose goals form a superset of another actor’s. For example, we could define an Administrator actor as a specialisation of a User actor. The Administrator performs all the functions of the User but has additional behaviours (admin tasks)
Actor specialisation is avoidable if you consider actors as roles. A role is just a set of competencies and behaviours that can be adopted by a person (when interacting with the system). So, when I perform everyday tasks I adopt the role of a User actor; when I need to do an administrative task I adopt the role of an Administrator (if I’m able) This model also means I can be an Administrator without being a User – something the specialisation model doesn’t allow.
For use cases the problem becomes more complex. Given any particular use case, what does it mean to specialise it? A specialised use case is like a base use case, but may have different behaviour. This complication is adding nothing to our comprehension of the system (in fact, possibly the opposite!). Not to mention the pain you will go through trying to explain all this to your customers!
The Liskow Substitutabiliy Principle (LSP) can help with this situation. In simple terms the LSP says that a derived class can be substituted for a base class object if, and only if, the derived class has no stronger pre-conditions (demands no more of the client) and has no weaker post-conditions (delivers no less).
For use cases, this means the specialised use case must have the same pre-conditions as the super use case (or possibly weaker). The specialised use case may override super use case functionality (whatever that actually implies!). Finally, none of the scenarios in the specialised use case must result in weaker post-conditions than the super use case.
This could be achieved by having a super use case with limited (or no) behaviour, strong pre-conditions and very weak post-conditions.
However, one could reasonably argue this super use case becomes little more than a generic place-holder and doesn’t really add much to our understanding of the system’s (transactional) behaviour.
Use case specialisation can be avoided very simply by forking the use case with an optional flow. For one variation take one path through the use case; for another variation take the other. Unfortunately, this causes the use case to become more complicated; but at the benefit of explicitness.
There are some rare cases where use case specialisation can be more explicit but these are more the exception than the rule.
He specialises in C++, UML, software modelling, Systems Engineering and process development.
- Practice makes perfect, part 3 – Idiomatic kata - February 27, 2020
- Practice makes perfect, part 2– foundation kata - February 13, 2020
- Practice makes perfect, part 1 – Code kata - January 30, 2020
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.
Dear Glennan C:
Very good points. It is unnecessary to organize the Actors (more appropritately Roles) and Use Cases into a Class Hierarchy for each projec for the reasons you have given.
However if a repository of UML Artifacts is created, it would be useful to organize Roles and Use Cases in to Class Hierarchy and also Compositions. This need not be taken to the clients but the Business Analysts, Requirements Engineers and Developers need to work for it for REUSE of efforts and proven artifacts.
I have a Use Case Matrix which may be used to see that all actors and use cases are identified in a balanced manner. You may review and consider adding it.
putchavn@yahoo.com