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.
