Granularity

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 independent.

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 flow
	The system responsibilities (the what) are more refined as only a specific part of the system (the component) is being described.

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.

Extension/Inclusion Points

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 actors
	The proper use of extension is a ‘special case’, where the extension describes additional set of steps to achieve the special case.

example of explicit extension in triggers

4.4.1.1. Trigger

· Extends “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 – User authorised

13. 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 reuse.

[1] Although in the case of security these goals can often be the mitigation of key, named risks.

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: info@codel-services.com