Coupling and Extension

Tightly Coupled Use Cases

Extension can lead to interesting circumstances where two use cases are tightly coupled to one another (but in different components). Effectively they are doing the same thing but from different perspectives – the actor in one is the system in the other, and vice versa.

Figure showing tightly coupled use cases

This cannot be avoided, since each component is separately managed and separately built (and possibly outsourced) initiative. It must be clear in the flow which is the actor and which is the system since there is a danger that (using the example above) :

	The use case for component B describes what component A is doing (A should be black box).
	Both use cases (using the example above) are contradictory
	Tight coupling between use cases in different components should signal a rethink about component responsibilities.

Also common in this situation is that there are often only one or two steps since the end-to-end nature of the Component Use Case has been completely lost. Whilst this looks strange it should be lived with – but the temptation to expand the steps simply to make it “look better” is to be resisted. What will typically happen is that this is done by describing things using design language.

System Actors vs. Extension Points

As described in the above, an inevitable use of shrinking the system scope to that of the component level, is that the majority of actors are not peoples roles, but other systems. This in itself is not a problem since the purpose of the Component Use Case still describes the contract between the actor (a component) and the system (another component). However it is easy to lose track of this important difference and show this cross component interaction by using extends (this is the purpose of the enterprise scenarios).

xample of missing actor

Main flow [from trade management component perspective]

7. The system extends “Component Use Case1151 Store order” and PM stores the resulting message in the generic structure by providing information (including a contingency file indicator_.

Why is this dangerous? It is worth remembering that Component Use Cases will typically be built in an autonomous and separately managed manner. By using the includes or extends approach:

	could (wrongly) suggest that the component has control of activity
	implicit actor responsibilities and system responsibilities could be confused.
	loss of visible actor results in loss who the Component Use Case is accountable to (i.e. who the “contract” is with)
	harder to maintain if responsibility changes to another component (as it is embedded in use case, with less visibility)
	since Component Use Cases are semantically identical to UCs, it would not be acceptable have an actor in a UC described using extends/includes (i.e. to have an UC without an actor)

To this end, where there is cross component interaction, actors should be used rather than included and extends. Also if another component is triggering this, this should be shown both as the first step and trigger. Who the system and actors are is dictated by the context of the use case (i.e. which component), so it is worth being explicit here. The following rules are to be observed:

	In the assumptions section of the use case it is clear which component is being described as the system – so if the responsibility moves to another component, it only needs to be updated once
	Where the actor is another component it is parenthesised with the component name, with the appropriate Component Use Case described in the step of the flow
	Where the Component Use Case is being invoked during the execution of another component’s Component Use Case, then the first step of the use case should describe this from that actors perspective.

The following flow gives a clearer picture of what the system and actors are.

Main flow [from trade management component perspective]

7. The System requests the trade to be stored.

8. The Actor (PM)stores the resulting message in the generic structure by providing information (including a contingency file indicator

(Defined in: “Component Use Case1151 Store order”)

The maintenance of this is reduced since we are not modelling responsibility. The first step states that trade management wants to do something, but cannot do it itself. The second states that (currently), the actor is responsible for carrying it out. If this responsibility is later given to another component, it is easy to spot this dependency, and only the component reference in parenthesis needs to be changed.

[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