Level of Granularity
In terms of semantics the sole difference between UCs
and Component Use Cases is the scope of the system boundary. Component Use
Cases should not be interpreted as a more detailed version of the other,
also UCs should not be considered analysis and Component Use Cases design.
Therefore it is important that the Component Use Case is not written using
a detailed design vocabulary. Whilst end-users are not the main customer
of these, they should be written in a way that they could review them
without being disenfranchised.
Use cases written as detailed design will require
greater maintenance, since typically designs often change between
iterations, and should the choice of solution change between cycles, then
the use case will need to be re-written.
In both cases “what” the system is responsible for
doing either in response to the actor stimulus or pre-empting it can be
described. Since no “how” is being described both use cases are solution
Of course the Component Use Case is not architecture
independent, it can be considered the intersection of the requirements and
the architecture (the two parallel drivers of any RUP initiative)
The only differences between the two artefacts are:
The Component Use Case will show different (and
typically more) interactions between the actor and the system in the
The system responsibilities (the what) are more
refined as only a specific part of the system (the component) is being
Irrespective of the scope of the system there should
be no other difference as to how the use cases are described! To
reiterate, there should not be confusion as to some correlation to the
level of system scope to the level of detail. Just because the scope is
“GCS” or “component”, one isn’t more detailed or design focus or
implementation than the other. All that has changed is that new
interactions occur – therefore new steps. Therefore the same level of
abstraction is appropriate and both are analysis – except one can be
thought of analysis of the business analysis domain, the other of the
system analysis domain.
Use cases work best where they are end-to-end.
Clearly this is easy to achieve where the scope of the system boundary is
wide. But even when the scope is small the temptation for functional
decomposition – i.e. the prolific use of extends and includes should be
avoided. Often careful use of Business Rules (see later) to outline a
specific range of conditions can be used as a substitute
Given the existing Component Use Case baseline is to
be built on the analysis team may have to accept cases where extension
points have not be used appropriately, so an approach to reduce the
confusion around these is to be used:
Extension/Includes should be shown explicitly in
the use case description – if the use case is triggered by another use
case, then the “calling” use case is described in the triggers, with its
Component Use Case number, but see also the following section regarding
The proper use of extension is a ‘special case’,
where the extension describes additional set of steps to achieve the
explicit extension in triggers
“Component Use Case329: Administer User Access”
If the use case is extending/including another use
case, extension/inclusion should be described as part of discrete step,
together with the Component Use Case extended and a textual description
of what the Component Use Case is achieving with regards to the flow.
3: Example of
explicit extension in flow
Main flow –
System includes “Component Use Case325: Authorise GCS
Services”, to establish what services the user is authorised to do.
Some extension/inclusion can be assumed, and need
not be shown in the flow as it will simply add clutter. An example of
this, is any interaction with the common infrastructure (e.g. for
authentication and authorisation purposes). Such interaction are best
described in the pre-conditions or post-conditions sections.
Extension/inclusion is never to another or a
discrete flow. If this is encountered the use case must be rewritten.
As a general principle extension/inclusion should
be avoided wherever possible to avoid Component Use Cases being over
fragmented. This lack of cohesion reduces the likelihood of use case
Although in the case of security these goals can often be the mitigation
of key, named risks.
2002-2005 Codel Services Ltd
This paper has been prepared
by Codel Services Ltd to illustrate how structured business
modelling can help your organisation. Codel Services Ltd is an IT
Consultancy specialising in business modelling. If you would like further
information, please contact us at: Deryck Brailsford, Codel Services Ltd,
Dale Hill Cottage, Kirby-Le-Soken, Essex CO13 0EN,United Kingdom.
Telephone: +44 (0)1255 862354/Mobile: + 44 (0)7710 435227/e-mail: email@example.com