17-10-2016, 12:08 PM
1459397864-UseCasesIncludesAndExtends.pdf (Size: 312.26 KB / Downloads: 39)
Introduction
UML defines three stereotypes of association between Use Cases, «include», «extend»
and generalisation. For the most part, the popular text books on UML introduce the
«include» relationship but give little useful guidance on the «extend» and the
generalisation relationships. Confusion arises with project teams as to the correct usage
and this document seeks to clarify the situation and make some practical
recommendations based on actual project experience.
The first part of the document establishes the basic principles of Use Case modelling as a
foundation for exploring the Use Case relationships.
Background
UML is an industry standard for software specification that may be applied to a wide
variety of computing systems. The examples in this document are taken from operational
business systems and it is left to the reader to decide how to what extent the principles
described are more or less applicable to other types of problem.
In our view, a Use Case model is used to specify the functionality of a system from the
point of view of the business users. Each Use Cases describes a logical task that may be
performed by the system. The Use Case description describes the interaction between
the system and the outside world. That interaction may be an online transaction where the
Actor is a human user. Alternatively a Use Cases may describe the interaction between
two systems where no human is involved and in this case the Actor is the external system.
Finally the Use Case may describe a piece of background or batch processing, when the
Actor is often depicted as a time event; in this case, the dialogue with the outside world
tends to be minimal, perhaps just one or two steps. Our examples will focus on online Use
Cases with a human Actor, since they are usually more common and contain more
complex conditional flows.
The Principles of our Approach
We use UML as an effective tool to create a specification for a system. A development
process that is aimed at new build can be adapted quite straightforwardly for enhancing
existing systems or evaluating and implementing packages.
For project teams to adopt UML effectively, it is important to be able to derive benefit
quickly from UML modelling activities and minimise the burden of learning new techniques.
Therefore, in considering the best use of the different types of Use Case associations we
apply the Pareto principle (the 80/20 rule) and focus on the basic elements of the notation
and defer anything non-essential. This allows us to get as much value as possible from
modelling and stay within the orthodox rules of UML.
When modelling operational systems our Use Cases will be defined at a consistent level of
granularity. Each primary1 Use Case corresponds to a logical unit of work, so that as a
rule of thumb it is typically,
performed by one person, in one place, at one time,
leaves the business data in a consistent state and
generates some business value.
This standard approach to the granularity of Use Cases gives us more consistency across
projects and makes Use Cases a useful metric for estimating project cost. We do not
create high-level “summary” Use Cases; instead we start by modelling the business
processes and from there we identify our system Use Cases.
The Structure of a Use Case
A Use Case describes the behaviour of a business system from the business user’s point
of view2
. It should describe in plain business terms how the user interacts with the system
(assuming it is an online Use Case) and what the system does in response. It does not
determine how the system works internally, that is it does not define the implementation.
The description of a Use Case is usually presented in text. There is a good deal of
variation in how this is done, especially in the names assigned to the elements that can be
included. We will focus here on the description of the Use Case steps, so we will
disregard elements such as pre- and post-conditions.
The Use Case steps are usually arranged into a Basic Flow and Alternative Flows.
The Basic Flow has other names, such as the Main Success Scenario or Happy Day
scenario. It describes the steps that are required for a straightforward (but not always the
simplest) execution of the Use Case. It sets aside the panoply of possibilities within the
Use Case so that we can see the essence of the thing. This is helpful to the reader
because it allows them to understand quickly what the Use Case is aiming to do.
The Alternative Flows are also known by other names, such as exceptions or extensions.
Each one describes some variation from the steps in the Basic Flow. Alternative Flows
can also be overlaid on top of other Alternative Flows. Within a single execution of the
Use Case – a single Scenario – any number of Alternative Flows may be invoked.
The Use Case steps, both in the Basic and Alternative Flows, are usually numbered. This
is not a requirement but it helps the readability of the flows and in particular helps us to
define where an Alternative Flow takes effect. Numbering schemes should be kept simple
otherwise renumbering becomes increasingly time-consuming as we refine the Use Case.
The UML does not require (or preclude) numbering of Use Case steps. However it
specifies that labels may be attached to particular steps so that we can refer to identifiable
points in the flow from elsewhere. More on this later.
The nature of the «extend» relationship
The «extend» relationship allows us to modify the behaviour of the base Use Case.
Suppose we want to sell products that are made to order and require a degree of customer
specification. For these products we will need to record the customer’s additional
requirements, such as size and colour. In this case we are adding something extra to the
flow of the base Use Case.
We could do this as an Alternative Flow, thus:
When to use the «extend» relationship
As with the «include» relationship, the time to use the «extend» relationship is after you
have completed the first cut description of all your main Use Cases. Do not attempt to do
it before this as validity of the extending Use Cases will be questionable.
In fact you should be able to produce a pretty complete first cut Use Case Model without
any «extend» relationships and we would advise you to do this. The extending Use Cases
represent additional functionality, without which the model is consistent in itself.
The «extend» relationship should be applied to a well-formed first cut Use Case model in
the following circumstances:
1. A Use Case is too big. If a use Case description, with all its alternative flows is
becoming unmanageable, use this as a strategy to break it up. Take a substantial
alternative path, that is reasonably self-contained and make it an extending Use
Case.
For example, the Use Case “Sell Basket of Goods” in a Point Of Sale system is
notoriously complex. To simplify the main Use Case we can pull out “Give
Cashback” as an extending Use Case. Note also in this example, that “Register
Item” and “Take Payment” will have probably dropped out as included Use Cases.
2. The base Use Case is something that for one reason or another we don’t want to
change. It may be that the base Use Case is part of an existing system
implementation and perhaps there is no existing Use Case model for that system
but we want to create a Use Case description for the new functionality. Using an
«extend» relationship helps us to separate out our specification of the new
functionality from the old.
If it doesn’t already exist, create a simple Use Case description for the basic flow of
the existing Use Case so that we can see where the new Use Case occurs and
leave it at that. Now document the new Use Case fully.
An example of this was the “Sell Customer Specific Goods” in example 4. The
Customer Specific Goods in question were made-to-order window blinds. This was
new functionality being added to an existing system which required substantial new
business logic. The existing flow of the main Use Case was extended in one place
for capturing and validating the customer’s requirements and another for saving the
additional order data.
3. Where we want to delay delivery of some flows within the Use Case. We normally
use Use Cases to define the scope of our increments and occasionally this causes
us a problem if we want to partially implement a function and withhold some
features until a later increment. What we do is pull out the delayed alternative
flows into extending Use Cases so that we can track their delivery independently of
the main Use Case.
This is more likely to occur in the first increment where we are trying to create a
small increment of realistic business functionality but the core Use Cases have a lot
of alternative flows.
Bear in mind that the «extend» relationship is more likely to cause confusion and
disagreement than almost any other area of your UML analysis model. These debates
can be time-consuming, so approach it with caution and use it sparingly.
When to use the generalisation relationship
Never. We haven’t found a case yet which justifies the existence of this notation. We will
be happy to receive an example if anyone has one to offer.
When «include» and «extend» meet
There are some cases where a strong argument can be made either way for using an
«include» or an «extend» relationship. Characteristically these occur where the additional
steps are optional.
The following touchstone questions are offered for guidance but should be applied
judiciously:
1. Do the additional steps constitute a single contiguous set of steps?
Yes, you are adding steps at one place in the flow – use «include».
No, you need to modify the base Use Case in more than one place – use «extend».
2. Do the additional steps make sense on their own?
Yes – use «include».
No – use «extend».
In an included Use Case the additional steps may or may not be performable in isolation
but they are likely to have a degree of coherence on their own. The steps of the extending
Use Case are more likely to be an incomplete fragment or sequence of fragments.
3. Do the additional steps occur in more than one base Use Case?
Yes – use «include».
No – use «extend».
Although UML clearly allows that an extending Use Case may extend more than one base
Use Case, it is rarely likely to be used. To achieve it, each base Use Case would have to
support the same extension point or points referred to by the extending Use Case. All the
base Use Cases must have a logically similar step (or steps) which needs to be extended.
Taken with a “yes” answer to Question 1 (the extension applies to only one extension
point) you could achieve the same result with an «include» relationship and this might be
easier to manage without breaking the rules about the direction of the reference.
Summary
1. Do not try to identify «include» and «extend» relationships in your first cut model.
2. Use «include» to abstract sequences of steps out of the base Use Cases that are
useful to the analyst to avoid repetitious descriptions.
3. Use «extend», sparingly, to overlay additional functionality on top of a well-formed
Use Case to divide up the complexity of a large and complex Use Case.