One of the most difficult concepts in the modelling use cases is the exact level of detail (often called
level of abstraction) to model to. Some modellers may model at a very high level of abstraction
which implies that the use case can still be broken down into several more detailed use cases.
Other modellers prefer to model at a very detailed level of abstraction which means that they
prefer to work at a very detailed use case level that often cannot be broken down any further.
As long as one modeller develops and maintains a model this does not have too many drawbacks.
Unfortunately in real life, more than one person will be modelling at the same time in the same
model. This often leads to misinterpretation between different parts of the model because of
modelling style differences.
To solve this problem we are going to need some help from the discipline of business analysis and
the associated technique of process decomposition.
From process decomposition we have the definition of an elementary business process: A process
where the activities performed under the control of only one person. Activities will start and
complete under the control of that person and there shall be no intervening time delays.
If we apply this to the concept of a use case the definition may be altered in such a way that it
states: An elementary use case is a use case which is executed under the control of one primary
actor, that starts and ends without any intervening time delays.
This definition implies that other actors may be involved, but that the achievement of the purpose,
or goal, of the use case is under the control of the primary actor.
The primary actor may be defined as: The stakeholder that initiates the interaction with the use
case in order to achieve the successful execution of the function.
Other actors or stakeholders can then be seen as anyone/anything that is involved (but does not
control) the behaviour of the function. If another actor, or stakeholder controls part of the use
case, it is an indication that the use case is not an elementary use case and should be split until a
primary actor in total control of the use case can be defined.
Modelling the use cases at an elementary level should eliminate confusion about the levels of
abstraction, although it is still possible for different levels of detail. It also brings with it the
following benefits:
- Clear role separation on use case level
- Use cases with clear boundaries in terms of scope
- Easy business rule definition
- Simple scenario definition
Modelling elementary use cases - A process
1. Functional decomposition. Although a contentious technique to use in the object oriented world, it
serves well as a technique to get to elementary use cases. By functional decomposition we mean
breaking down high level functions into it constituent lower level functions until the elementary use
case level is reached.
The higher level functions may be shown as high level use cases, but it makes more sense to use
package diagrams to show the decomposition. At the elementary level we can use case diagrams
to show the elementary use cases and the associated actors.
2. Identify primary actors. Each elementary use case should have only one primary actor. This will
be the actor that initiates the use case and controls the use case through the execution until it
achieves the goal of the use case.
3. Identify other actors/stakeholders. Other actors, or stakeholders, are normally recipients of
outputs of the use case interaction.
4. Documenting use cases. Simple documentation for the use cases may include:
- Use case – A contract for the behaviour of the function
- Scope – The function under discussion
- Business rules – The rules that govern behaviour of the function
- Scenarios – The possible behaviour paths of the function
- Extensions – Descriptions of additional behaviour that enhances the defined function
In order to ensure that modellers model at the same level of abstraction and what should be
modelled and documented, it should be clearly defined in the UML standards of the enterprise.
