Use Case 2.0 – Slices and Relationships: Inclusion

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 of include, extend and generalization.

In this blog we will look at the impact of the include relationship on use-case slicing.

What’s the Problem?

An include relationship is used when two or more use cases share common behaviour. This is then factored out into a separate use case.

Consider the case where we have two separate use cases Register Birth and Register Change of Address. Even though both use cases are concerned with registration these are separate use cases because  the flow of events and the business rules are quite different. They share however common behaviour. Both include a description of all the ways a case worker can find a citizen when registering births and address changes. As shown in Figure 1, the common behaviour can be re-factored  into a single Find Citizen Use Case that is included in both of the original use cases.

Use Case 2.0   Slices and Relationships: Inclusion

Figure 1 – The re-factored use-cases

Before the re-factoring it was very easy to slice up the original two use cases. The question now is what will happen to the use-case slices when we make use of inclusion:

  • Does an inclusion use case have its own use-case slices?
  • Does inclusion change the number of use-case slices?
  • Does inclusion have an impact on any existing use-case slices?

Does an inclusion use case have its own use-case slices?
Inclusion means that we move behaviour from one use case to another; we literally cut and paste text between the two use-case narratives. However, this does not mean that we move compete stories or use-case slices. This is because an inclusion use case is never performed on its own. In the above example the Register Birth or the Register Change of Address use cases are in control of when the Find Citizen use case is performed. Because an included use case is never performed independently of its including use case it does not have its own slices. This means that all the slices remain in the original use-cases, and that the included use-case does not have use-case slices of its own.

Does inclusion change the number of use-case slices?
Before refactoring we had two use cases and each use case has its own set of use-case slices. So what will happen when we factor out the common behaviour using the inclusion mechanism? Because an included use-case does not have use-case slices of its own, the total number of use-case slices remains the same. Each of the original use-cases keeps its original number of use-case slices.

Does inclusion have an impact on the use-case slices?
The use-case slices of the original use-cases are indeed impacted. Before refactoring the original use-case slices referred to flows contained within one use case. After refactoring the use-case slices of the base use-case refer to flows in two use cases: 1) the original use-case and 2) the included use-case.

Note: if new flows are added to the included use cases then new slices will be needed in all of the original use cases.

Some Examples

Use Case 2.0   Slices and Relationships: Inclusion

Figure 2 – Example Basic Flow use-case slices

Before inclusion all required behaviour for slice #1 of the use case Register Birth and slice #1 of the use case Register Moving House was contained in their respective basic flows.  After inclusion these slices reference the basic flow of their original use case and the basic flow of the Find Citizen use case. This is indicated in the slice by stating the name of the use case in front of the flow, in this case Find Citizen.BF.

Use Case 2.0   Slices and Relationships: Inclusion

Figure 3 – Example Alternative Flow use-case slices

Before inclusion all required behaviour for slice #2 of use case Register Birth and slice 2# of use case Register Change of Address was contained in their respective basic and alternative flows. The goal of the alternative flows is to handle finding citizens that are residents of different municipalities. After inclusion these slices required require the basic flow of their original use case, the basic flow of the Find Citizen use case and alternative flow 1 of the Find Citizen use case.

If it doesn’t affect the number of slices why both with includes?
The benefits of re-factoring a use-case model to use includes are not changed by the use of use-case slices. They can still make the model easier to understand and maintain, and provide clues to the developers that the included behaviour will be re-used in different circumstances.

Final words
So as you can see use-case slices are as effective for use cases and use-case models that use the inclusion mechanism as those that don’t.  In the next blog in this series we will examine the effect of the extends relationship on the slicing of the use cases.

This post was co-authored with Ian Spence.


3 Comments
  1. John | May 5, 2014 at 9:00 am Reply

    avatar

    I believe you’ve mixed figure 2 and 3.

  2. Eric Lopes Cardozo | July 2, 2013 at 4:06 am Reply

    avatar

    Hi Piermarco,

    Thanks for your feedback and question.

    Personally I do not like use case that are both base use case and inclusion at the same time. This backed up by Ian Spence and Kurt Bittner in [Use Case Modeling, ISBN 0-201-70913-9]p253. They classify having inclusion with just one base use case as a common mistake.

    You shared a bit of context and I have not seen the use-case model and the use-case narratives, so recommending anything is a bit of tricky.

    If I had to guess in this case I would recommend not to use inclusion at all or to construct it differently

    You already have good names : Find Document and Prepare Dossier. I would recommend create one use case: “Find Document and Prepare Dossier” and create slices that allow for only finding documents without having to prepare a dossier at all.

    If you want to explicitely have two separate you might consider having two use case: 1) Find Documents and 2) Prepare Dossier. In that case I would simply duplicate the flows that are needed for finding/searching, at least the basic steps that you need for searching. Having some duplication is not so bad and in my experience the steps required for finding/searching are often not that complicated. The complexity is mostly in the search/find criteria and maybe authorization. You could factor these out with Supporting Information and if you have a lot of interaction regarding error handling nd stuff you might factor these out with inclusion.

    I hope this answers you question, Piermarco

    Best,
    Eric

  3. Piermarco Burrafato | October 17, 2012 at 1:33 pm Reply

    avatar

    Hi Eric,

    Nice to interact with you again (albeit only virtually). Thanks for clarifying this point. I believe this approach makes a lot of sense in particular when an inclusion use case really contains factored out functionality from two or more use cases.

    However, I have an example at hand in which an inclusion use case could be a base use case on its own. Consider an online research application allowing attorneys to access legal documents (case law, treatises, expert commentaries, etc) and use them to prepare dossiers to defend legal cases before a court. Two typical use cases are: Find Documents and Prepare Dossier. Now Prepare Dossier always includes Find Documents since a dossier is essentially made by a collection of document parts. The activity of preparing a dossier is heavily based on finding relevant documents and selecting parts of them to be included in a dossier. On the other hand, an attorney may use Find Documents outside of the context of Prepare Dossier, for all sorts of reasons (e.g. curiosity, get the latest expert opinion on a given subject, etc). So Find Document is an example of a use case that is at the same time a base and an inclusion.

    How would you recommend going about that when it comes to slicing?

    Thanks and best regards,
    Piermarco