Since the introduction of Use-Case 2.0 we have received a number of questions about use-case slices and in particular how they relate to the concepts on include, extend and generalization. In this blog we will look at the impact of the extend relationship on use-case slicing.
What’s the Problem?
An extend relationship can be used to factor out optional behaviour from a use-case narrative. It is particularly useful in the following situations:
- Where the optional behaviour will be part of a separately purchased extension
- Where different customers require different variations of the same behaviour
- Where already implemented use cases need to be extended
- Where additions need to be made to previously frozen or signed off use cases
Consider a hotel management system with which customers can make online room reservations. As shown in figure 1, the primary use cases would be “Reserve Room”, “Check In Customer” and “Check Out Customer”.
Now let’s consider what happens if the hotel management system being built is to be a modular commercial product with an optional waiting list feature. This feature allows a customer to be put on a waiting list in the case where the room they like is already booked. The customer will then be informed when the room becomes available or can have the room reserved automatically within a given timeframe. This feature could easily be captured within use case “Reserve Room” but since it is an optional feature, it is factored out into an extension use case.
Now, to provide a little more context, let’s first have a look at the use-case narrative of the original Reserve Room use-case.
Without the extending use case we would have had only one use case to slice up - Reserve Room. Consider the following example Reserve Room use-case slices.
The question now is what will happen to these slices when we make use of extension:
- Does an extending use case have its own use-case slices?
- Does using extend change the number of use-case slices?
- Does using extend have an impact on any existing use-case slices?
Does an extending use case have its own use-case slices?
The answer is yes. Using extend means that we move behaviour from one use case to another; we start by literally cutting and pasting text between the two use-case narratives. More specifically we take out one or more alternative flows and place them in a use case of their own. In this case the Alternative Flows AF16, 17, 18 and 19, which are all about the waiting list, would be moved to the new Handle Waiting List use case.
We could have left all the behaviour related to handling a waiting list in the Reserve Room use case. By using extend we have made optional behaviour explicit. In the case of extension the extending use case is performed in the context of the original use case but without the original use case’s knowledge. This means that any use-case slice that requires behaviour of the extension use case must belong to the extension use case. So, extension use cases do have their own use-case slices
Does extension change the number of use-case slices?
Before refactoring we had one use case with its set of use-case slices. The question is what will happen to this set when we factor out the optional behaviour using the extension. Most likely the total number of use-case slices will remain the same because any alternative flow significant enough to get moved to an extension use-case would probably have got its own slice or slices.
Does extension have an impact on the use-case slices?
Yes and no. Yes, because in the use-case slices we must refer to the right flows of the right use cases; the original use case or the extension use case. No, because the stories and test conditions remain the same independent of the use case they belong to.
Let’s first have a look at the refined narrative of the Reserve Room use case and the narrative of the Handle Waiting List use case
And below you will find use-case slices from the extending Handle Waiting List use case
Notice that in the example use-case slice above:
- The basic flow of the Reserve Room is always required because the Handle Waiting List (extension) use case cannot be performed without it.
- Alternative Flow 16 of the original Reserve Room use case has become the basic flow of the Handle Waiting List (extension) use case.
- Alternative Flow 17, 18 and 19 of the original Reserve Room use case have become Alternative Flow 1, 2 and 3 respectively of the Handle Waiting List (extension) use case.
So, as you can see use-case slices are as effective for use cases and use-case models that use the extension mechanism as those that don’t. In the next blog in this series we will examine the effect of the generalize relationship on the slicing of the use cases.
This post was co-authored with Ian Spence.