Specifying Use Case Interaction: Clarifying Extension Points and Rejoin Points

Pierre Metz and John O´Brien, Dept. of Mathematics & Computing, Cork Institute of Technology, Ireland
Wolfgang Weber, Dept. of Computer Science, Darmstadt University of Applied Sciences, Germany

REFEREED
ARTICLE

PDF Version

Abstract

This article is the second work in a series of papers on advancing specification and modelling techniques for goal-based use cases. In this article we highlight major and remaining problems associated with the true semantics of extension points and rejoin points, which are used as branching and return locations for a use case’s alternative interaction courses, and also for the application of UML’s Extend-relationship. Based on a previous work that identified and defined three reconciling types of alternative courses of use case interaction, this article proposes clear and simple semantics for extension points and rejoin points that significantly reduce use case interaction ambiguity. These semantics allow the uniform treatment of any type of alternative course, so that a practitioner can concentrate on the coherence of the use case’s goal, precondition and business results. Our proposal is independent of the way the use case interaction is documented, i.e. textually or graphically. Finally, our suggested semantics will dramatically contribute to an understanding of practical use case interaction specification.

PAPER ROADMAP

We will highlight the ambiguity that surrounds the current semantics of extension points and rejoin points for specifying alternative courses of use case interaction. In order to address this issue, we propose that the interaction steps, within the branched interaction course that are referenced by the extension point, are always excluded from a use case scenario, while the interaction steps within the rejoined interaction course that are referenced by a rejoin point are always included into a use case scenario. Relevant use case fundamentals and terms are reviewed, briefly. A definition of the inconsistently-used term “use case scenario” is also presented. Existing problems involving the use of extension points and rejoin points are highlighted. Finally, we present a solution to the raised issues, and outline the implications for UML’s use case foundation.

1 BRIEF REVIEW OF USE CASE BASICS

Actors, Stakeholders, Goals, Use Cases and Use Case Interaction

A use case, as considered here, is the black-box requirements description of a single software-supported business goal of an actor or stakeholder. It must provide a corresponding business result of value to at least one actor or stakeholder. The actor instances need to participate in a use case execution. This they achieve by interacting with the system in order to make the system accomplish the use case goal and, thus, deliver the use case business result instances.

Example 1:

Use case goal: Withdraw Cash (ATM)

Figure 1. Use Case Diagram for Example 1

Use case business result:

Now consider the following alternative course:

The description of all possible use case interactions encompasses, generally, two parts: a text block describing the "main" sequence of interaction which always shows the use case goal succeeding; this is called the Basic Course and is also known as the "happy path". Zero or more text blocks describe alternative courses of interaction to the basic course, e.g. optional interactions and interactions handling business error recovery which may end in the use case goal succeeding or failing, are cal led Alternative Courses (see Example 1). These text blocks, being optional, must be guarded by a business condition [1], [5], [7], [9], [10], [15].

The reference to the label of an interaction step of a branched interaction course, where an alternative course branches off, is called an Extension Point. Correspondingly, a Rejoin point is a reference to the label of an interaction step in the base interaction course that represents the return location (see Example 1). It should be noted that, originally, UML introduced the term extension point to indicate branching locations for the Extend-relationship only [13]; an Extend-relationship is used to attach optional behaviour, that resides in an extension use case, to its base use case. However, we consider the term extension point to be also applicable to branching points of alternative courses that are text blocks residing within the same base use case document.

Use Case Scenarios

In order to fully comprehend the issues raised and the examples presented in this paper, the term “use case scenario” needs to be clearly understood.

A use case scenario is a single path through the use case´s interaction courses. Figure 1 illustrates three interaction courses, i.e. one basic and two alternative courses. In fact, there are four scenarios: the basic course only, the basic course plus alternative course 1, the first part of the basic course and alternative course 2, and basic course with both alternative courses 1 and 2. Cockburn [5] refers to the basic course as the “main success scenario” because, if never branched by an alternative course, the basic course directly shows the use case goal succeeding.

Figure 2. Illustration of the term “scenario”

2 PROBLEMS IDENTIFIED WITH THE SEMANTICS OF EXTENSION POINTS AND REJOIN POINTS

The remaining and confusing problem with extension points and rejoin points in both literature and practice is that it remains unclear if the interaction steps referenced by extension points and rejoin points are actually included in or excluded from the scenario.

Consider our “Withdraw Cash” use case in Example 1. Clearly, as we know from our daily banking knowledge, the alternative course in Example 1 rejoins the basic course at label 3 because the next logical scenario step is to offer the possibility to re-enter the PIN. However, the scenario which steps through the alternative course must exclude the basic course step at the extension point, i.e. label 4. The step at label 4 is clearly excluded from this scenario because if the failure condition of the alternative course holds then there actually is no system action which validates the PIN.

Now consider the following altered basic course of Example 1. This trivial basic course may also be correctly written with the validation statements omitted, i.e. the validation success is implicit:

Example 2: Alteration of Example 1

Use case goal: Withdraw Cash (ATM)

Now consider the altered alternative course:

It is clear that the basic course in Example 2 is rejoined at label 2. However, in this example the validation success is implicit, i.e. it is not explicitly documented. Hence, the extension point references the basic course label 2 because this seems to be the suitable context for checking the failure condition. However, in such a situation, the interaction step of the extension point, i.e. entering the PIN at label 2, clearly cannot be excluded from the scenario, as was the case in Example 1, because entering the PIN is the prerequisite for the system to be able to check if the entered PIN is incorrect. As we see, in contrast to Example 1, in Example 2 the interaction step referenced by the extension point must be included into the scenario.

These examples highlight the following problem: in the use case world there is no common agreement on whether or not the interaction step at an extension point is included into the current scenario; the outcome may depend on the use case specification approach chosen, i.e. explicitly or implicitly specified validation action, both of which are commonly considered good practice. Moreover, it may even depend on the interpretation of the text. This presents further difficulties because individual interpretation varies and is highly dependent on the reader´s experience and knowledge of the underlying business semantics. Consequently, without clear use case semantics a given use case specification may be interpreted differently. Business analysts and software developers find this situation unsatisfactory because the absence of clear semantics glaringly fosters misunderstandings and misinterpretations of the functional requirements expressed by use cases.

With respect to a solution, we can say that there can be found four possible combinations of extension point and rejoin points semantics, namely:

Option (1) -
extension point inclusive, and rejoin point inclusive;

Option (2) -
extension point inclusive, and rejoin point exclusive;

Option (3) -
extension point exclusive, and rejoin point inclusive;

Option (4) -
extension point exclusive, and rejoin point exclusive.

However, leading technical text book authors and development process methods do not commit on the issue; in fact, the literature remains totally vague and imprecise, thus leaving the decision and interpretation to the reader [1], [2], [3], [5], [6], [7], [8], [9], [10], [15], [16]. In particular, use case examples in literature do not consistently use one of these options; the options are mixed in [1], [2], [3], [5], [10]. This is mostly the case when two distinct and subsequent actions, i.e. sub-goals, are labelled as a single interaction step but only one of these is to be excluded from the active scenario. Furthermore, the four above-mentioned possibilities are not even highlighted in literature. As a result, there is no methodological guidance for use case practitioners.
Before proposing a solution, however, we wish to highlight further weaknesses arising from the absence of commitment on the true semantics of extension points and rejoin points. One such weakness is the way conditional insertion is documented.

Conditional insertion refers to an optional interaction part that is subject to pure guarded insertion into another interaction course. Conditional insertion is not replacement; rather, it is a conditional addition of use case interaction [1], [2], [5], [10], [15], [17], [18]. But what exactly does this mean? Does this mean that the extension point and the rejoin point are strictly consecutive? Does this mean that the extension point and the rejoin point must be identical? Careful examination of current literature reveals examples of both approaches. Consider the following example:

Example 3:

Consider a use case with the goal “Establish New Customer Bank Account“. Further consider the following fragment of the basic course:

Now consider the following alternative course:

As we know from our knowledge about banking, the alternative course in Example 3 is obviously meant as conditional insertion. However, this is not made explicit because no rejoin point is specified; this could also mean the ending of the use case. Moreover, from our banking knowledge we know that an account number must be assigned first before an overdraft facility can be determined, i.e. the basic course action label 3 must not be excluded from the scenario flowing through the conditional insertion. However, this is not made explicit either. Nevertheless, we realise, because of available banking knowledge, that the active scenario must follow 1,2,3,3a1,4,... When taking a look at industrial requirements specifications and at the current literature, there are use case examples that, indeed, suffer from the problem of not explicitly stating rejoin points thus increasing the reading and understanding effort [1], [2], [5], [10], [16].

With respect to these problems, it is obvious that assumptions can be made based on our individual knowledge and experience of the underlying business domain. However, what happens when little, inconsistent or even no knowledge of the domain is available? This situation can be encountered by everyone who engages in software consulting in industrial projects where personnel changes are frequent. Even when equal knowledge of the true business domain is present, anyone experienced in industrial requirements engineering knows that there are always differing working philosophies among stakeholders competing with varying operating procedures among the prospective end users. Consequently, it is highly desirable to have general methodological guidance for use case analysis, specification and modelling clearly indicating how a baselined use case specification should be interpreted.

As noted previously, it is unclear whether the interaction steps referenced by an extension point or a rejoin point are inclusive or exclusive to a scenario. It is also unclear if the type of alternative course is relevant to answering this question since it must be clearly known where a rejoin point is required. Hence, all possible types and kinds of alternative courses must be considered, before a reasonable and uniform solution can be developed. The following section repeats all possible types of alternative courses as defined in [11], with each one indicating whether or not it needs a rejoin point. Our final solution proposal on extension and rejoin point semantics is presented subsequently.

3 TYPES OF ALTERNATIVE COURSES

In literature the term “alternative course“ is explained and treated inconsistently. Based on a rigorous examination and discussion of current literature, and practical observations, we have clarified the “terms jungle“ that impacts on the term alternative course by suggesting the sub-types use case exception, alternative history, and alternative part [11]. Moreover, we have consequently related these definitions to the notion of use case goals and use case business results in the context of goal-driven requirements engineering. In particular, we have interconnected these types of alternative courses with Cockburn’s use case guarantees [5], which is a refinement of the term use case business results.
Note that the following examples all apply Option (3), as defined in Section 2, when needing to handle extension points and rejoin points.

1. Use Case Exception

A use case exception branches the base interaction course and never rejoins; furthermore, it never establishes the use case’s business results. However, minimum guarantees are met and therefore the stakeholders interests are protected. This is indicated by the “earthing” in Figure 3. The following example illustrates a use case exception for the use case in Example 1:

Example 4: Use Case Exception

Consider the following additional alternative course, representing a use case exception, for the use case in Example 1:

Figure 3. Illustration of a use case exception

2. Alternative History

An alternative history branches the base interaction sequence never to rejoin, i.e. an alternative history also represents a fully parallel interaction flow. An alternative history differs from a use case exception in that at the end of an alternative history the use case goal is achieved and its business results are delivered. This is indicated by the line going to the finishing line in Figure 4. The following example illustrates an alternative history:

Example 5: Alternative History

Consider a use case with the goal “Register New Employee“. Further consider the following basic course:

Figure 4. Illustration of an alternative history

Now consider the following alternative history:

3. Alternative Part

An alternative part is an alternative course that always rejoins the branched base sequence; this encompasses conditional insertion (see Figure 5 a), interaction cycles (see Figure 5 b) and alternative interaction fragments (see Figure 5 c). The following examples illustrate alternative parts:

Example 6: Conditional Insertion

Consider a use case with the goal “Register New Student". Further consider the following basic course:

Now consider the following alternative course:

Example 7: Alternative interaction fragment

Consider the following basic course of a use case with the goal “Change Customer’s Contract Agreements”: a customer can be identified either by entering the contract number or his name and birthday.

Now consider the following alternative course:

An example of an interaction cycle can be found in Example 1.

Now that there are three types of alternative courses defined that reveal when a rejoin point is actually needed, the following provides a solution for handling extension points and rejoin points uniformly for any type of alternative course.

4 SOLUTION PROPOSAL ON THE SEMANTICS OF EXTENSION POINTS AND REJOIN POINTS

Promoting Option (3)

Our solution promotes Option (3) in Section 2 thereby suggesting the following uniform approach when dealing with alternative courses, extension points and rejoin points:

Extension Point
The interaction steps within the branched interaction course that are referenced by the extension point are always excluded from the scenario; the first interaction step of the alternative course substitutes the one referenced by the extension point.

Rejoin Point
The interaction steps within the rejoined interaction course that are referenced by the rejoin point are always included into the scenario.

Consequently, this solution implies that for conditional insertions the extension point and the rejoin point always reference the same label within the base interaction course. The reason is obvious: an insertion is not an alternative but an addition and, thus, nothing can be excluded from the scenario. The approach presented here guarantees that the excluded interaction step referenced by the extension point is re-included into the scenario after all. Note, however, that in our scenario semantics for conditional insertion the active scenario rejoining at the rejoin point only performs its function, i.e. it never checks for the same conditional behaviour again of other alternative courses branching off from this location; this implies that all guards at the same extension point must be formally disjoint.

For simplification in practice, we suggest the following default: for conditional insertion no textual rejoin point is specified in the use case narratives. If no rejoin point is given, this indicates conditional insertion, i.e. the rejoin point is implicitly identical with the extension point. Use case exceptions always state “Use case aborts”. Alternative histories always state “Use case completes”. In order to follow our approach in practice the extension points and rejoin points are correspondingly set as appropriate so that the intended scenario logic is maintained. This solution is consistent with any use case development approach that can be found in literature.

Correspondingly, the alternative courses in Example 2 and Example 3 are rewritten as shown below:

Adjustment of Example 2:

Possible scenario: 1, 2, 3a1, 3a2, 2, 3, 4, ...

Adjustment of Example 3:

Possible scenario: 1, 2, 3, 4a1, 4, ...

The alternative courses in Example 5, Example 6 and

Example 7 are already compliant with our solution. Possible scenarios for them are:

for Example 5: 1, 2, 3, 4, 5, 6a1, 6a2.
for Example 6: 1, 2, 3a1, 3a2, 3, 4, 5, ...
Example 7: 1, 2, 3, 4a1, 4a2, 6, 7.

The careful reader will have noticed that in all examples the rejoin point statements, the unsuccessful termination statements and the successful completion statements of the use case are not labelled as an interaction step. This seems perfectly reasonable since “direction statements” are not ranking full use case business interaction steps. However, in some situations we may want to have an alternative course branch off from another interaction course directly after the last interaction step but before the use case termination or the rejoining, respectively. We can do so by also labelling the termination and rejoin statements just like true use case interaction steps. Such labels can then be used for branching as presented. In this context, in symmetry with the way an alternative history (see Section 3) is specified, we may also append to the basic course the explicit system responsibility “Use case completes”.

Why are Option (2), Option (4), and Option (1) inappropriate?

Option (2) and Option (4) suggest exclusive semantics for rejoin points. In our opinion exclusion does not intuitively accompany the intention of “rejoin at...” a certain interaction step. Hence, these options would hardly be accepted in practice.

Option (1) suggests inclusion semantics for both extension points and rejoin point. This approach is intuitive, and it is also independent of implicit or explicit validation statements (see Example 1 and Example 2). Moreover, Option (1) also supports the above mentioned device of branching off from any interaction course before the rejoining or use case termination, respectively. However, Option (1) is not consistent with the way alternative courses are specified: consider a situation in which we want to add an alternative course to the basic course branching off before the first basic course interaction step but after the use case has started1.

In particular, having alternative histories branching off from the first step is common in practice. Such an alternative history is not an individual use case if the business results of this alternative history and the basic course are equivalent [5]; the alternative history then is an integral part of the use case´s behaviour because they deliver the same goal with respect to the goal´s business results (see the ScenarioPlusFragments and ExhaustiveAlternatives use case patterns in [1]).

Also consider the addition of an alternative course to an existing alternative course before the first alternative course interaction step but after the alternative course has been entered.
In order to illustrate this, consider Example 8 that reflects a simplified version of a real industrial use case description of the German Telekom general billing services software specification. When a customer enters a local Telekom service centre in order to request an upgrade from ISDN to DSL, for instance, the service clerk must find the customer´s profile. This is usually done by entering the billing number if the customer brings his paper contract or any billing invoice with him. If not, the customer´s profile can also be identified by his telephone number.

Example 8: Use case goal “Change customer´s Telekom service contract”

Basic course:

Alternative course attempt: the extension point remains unclear using
Option (1):

Example 9: Solution for Example 8

Basic course:

Alternative course solution with a determined extension point:

Using Option (1), we would have to solve the problem in Example 8 by adding the auxiliary statement “The use case starts” as shown in Example 9, because Option (1) demands inclusion semantics for the interaction steps referenced by the extension point. This looks very clumsy and, further, differs significantly from the way alternative courses are specified: an alternative course must always either give a rejoin statement or a use case termination statement which, in any case, is located at the very end of the alternative course’s text block (see Section 3). Now, since a basic course also is an interaction course, just like an alternative course, it is difficult to see why a basic course should carry a “starting” statement at the beginning while an alternative course carries a rejoin or termination statement at the end. Apart from this asymmetry, the textual complexity is unnecessarily increased for an alternative course having both starting and rejoin or termination statements, if we consider the branching from the first step of an alternative course. Introducing additional complexity truly appears counter-intuitive with respect to simplicity and methodological guidance.

5 CONCLUSION

The true meaning of combining use case interaction descriptions with extension points and rejoin points in industrial functional requirements specifications dealing with complex domains has been shown to be currently unclear. The first clarifying step was to build on the alternative courses types as have been consolidated in the textual use case world in [11]. We have then developed an approach to extension points and rejoin points in order to finalise the definition of alternative courses. We call our solution approach the “Exclusive-Inclusive Scenario Branching” rule: the interaction steps within the branched interaction course that are referenced by the extension points are always excluded from a use case scenario, while the interaction steps within the rejoined interaction course that are referenced by rejoin points are always included into a use case scenario.

Following this rule the branching and rejoining of any type of alternative course can be treated and understood uniformly; no extra convention, UML stereotype or tagged value is needed. This facilitates a practitioner because he or she no longer needs to reflect on what type of alternative course he or she is documenting when dealing with extension points and rejoin points; the practitioner needs to focus on the goal and the business results only when documenting use case interaction. Furthermore, the understanding of extension points and rejoin points is now fully independent of the comprehension of the underlying business domain; it is also independent of business knowledge available in the team. Moreover, with our solution basic courses and alternative course specifications are treated symmetrically while having minimum textual complexity and still supporting all situations mentioned in this paper.

While most of the recently published use case patterns focus on the quality of the use case content and the writing style, the presented approach to extension points and rejoin points makes more precise the given semantics of the use case syntax. Hence, our solution is not in conflict with, but even adds to, the goals of the use case patterns MultipleForms and PreciseAndReadable in [1]. Our solution helps to reduce misunderstandings among stakeholders, requirements analysts, and software developers thus contributing to the correctness of use cases as functional requirements vehicles and to the stakeholder’s needs for requirements precision and content [1]. In particular, our approach contributes to use case rigor and precision which is essentially important when the implementation activity is outsourced and the stakeholder’s business “core competency” is no longer available [1].

UML neither defines use case documentation items, nor does it offer a tailorable use case template [4], [13], [14]. UML considers only the graphical part of what makes up a use case model, i.e. the use case diagram. However, in practice a use case model consists of written specifications that are supported by a use case diagram, not vice versa (“A bubble does not tell us the story!”). In fact, the “graphical world” and the “textual world” currently exist in isolation from each other. In this respect, UML´s Extend-relationship is insufficiently explained as evidenced by numerous debates in the last decade; it is not even related to the textual world. However, in [12] it is suggested how to merge these two worlds by thoroughly refining and explicitly connecting UML´s Extend-relationship with the notion of alternative courses following the original spirit of Jacobson et al. in OOSE [9], i.e. Extend can be applied in order to extract all types of alternative courses into an extension use case and to attach this extension use case to the base use case. Consequently, our definitions of the alternative course types [11] together with our suggested semantics of extension points and rejoin points presented here should also be applicable to the Extend-relationship which would assist practitioners in aligning both worlds and practical use case model refactoring.

ACKNOWLEDGEMENTS

We wish to express our gratitude to Matthias Schork and Shane Sendall who have helped to improve this work. Thanks to Steve Adolph and Alistair Cockburn for the discussions on our alternative course types and our “Exclusive-Inclusive Scenario Branching” rule. Special thanks to Roderick Coleman.

REFERENCES

[1] Adolph S., Bramble P., Cockburn A., Pols A., Patterns for Effective Use Cases, Addison-Wesley, 2003

[2] Armour F., Miller G., Advanced Use Case Modeling, Addison-Wesley, 2001

[3] Bittner K., Spence I., Use Case Modelling, Addison-Wesley, 2003

[4] Booch G., Jacobson I., Rumbaugh J., The Unified Modeling Language User Guide, Addison-Wesley, 1999

[5] Cockburn A., Writing Effective Use Cases, Addison-Wesley, 2001

[6] IBM Global Services, IBM Global Services Method Release 3.1, IBM Corporation, 1998, 1999, 2000, 2001, 2002

[7] Jacobson I., “The Road to the Unified Software Development Process”, Cambridge University Press, SIGS Reference Series, 2000 (compilation of formerly published articles of I. Jacobson, revised and updated by S. Bylund)

[8] Jacobson I., Booch G., Rumbaugh J., The Unified Software Development Process, Addison-Wesley, 2000

[9] Jacobson I. Christerson M., Jonsson P., Övergaard, G., Object Oriented Software Engineering – A Use Case Driven Approach, Addison-Wesley, 1992

[10] Kulak D., Guiney E., Use Cases – Requirements In Context, Addison-Wesley, ACM Press, 2000

[11] Metz P., O’Brien J., Weber W. “Specifying Use Case Interaction: Types of Alternative Courses“, in Journal of Object Technology (JOT), vol. 2, no. 2, March-April 2003, pp. 111-131. http://www.jot.fm/issues/issue_2003_03/article1

[12] Metz P. “Merging the Use Case Textual and Graphical Use Case Worlds”, Ph.D. thesis, Dept. of Mathematics & Computing, Cork Institute of Technology, 2003

[13] OMG Unified Modeling Language Specification, Version 1.4, September, 2001

[14] Rumbaugh J., Jacobson I., Booch G., The Unified Modeling Language Reference Manual, Addison-Wesley, 1999

[15] Rosenberg D., Scott K., Use Case Driven Object Modeling With UML: A Practical Approach, Addison-Wesley, 1999

[16] Schneider G., Winters J.P., Applying Use Cases: A Practical Guide, Addison-Wesley, 1999

[17] Simons A. "Use Cases Considered Harmful", Proceedings of TOOLS-29 Europe, eds. R Mitchell, A C Wills, J Bosch and B Meyer (Los Alamitos, CA: IEEE Computer Society, 1999), p. 194-203, available on http://www.dcs.shef.ac.uk/~ajhs/abstracts.html#harmful

[18] Simons A., Graham I. “30 Things That Go Wrong In Object Modelling With UML 1.3”, Behavioral Specifications of Businesses and Systems, eds. H. Kilov, B. Rumpe, I. Simmonds, Kluwer Academic Publishers, 1999, p. 237-257, available on http://www.dcs.shef.ac.uk/~ajhs/abstracts.html#uml30thg

About the authors

		Pierre Metz is a postgraduate PhD student at the Dept. of Mathematics and Computing, Cork Institute of Technology, Ireland. He is interested in the area of software process assessment and improvement following CMMI and ISO 15504/SPICE, requirements engineering, quality assurance, use case analysis and modelling, object-oriented foundations, and UML. Pierre can be reached at pmetz@cit.ie
		John O´Brien joined the lecturing staff of the Maths and Computing Department, Cork Institute of Techbnology, CIT in 1987. Here he has lectured on, and developed courses in, software engineering at undergraduate and post-graduate levels. His current research areas include quality software engineering and project management. John is a current member of the academic council at CIT. John can be contacted at jobrien@cit.ie
		Wolfgang Weber is a full professor at the Dept. of Computer Science at Darmstadt University of Applied Sciences, Germany. He works and teaches in the field of project management, software engineering, UML, object-oriented methods and programming. Wolfgang can be reached at w.weber@fbi.fh-darmstadt.de.

Cite this article as follows: Pierre Metz, John O’Brien, Wolfgang Weber: “Specifying Use Case Interaction: Clarifying Extension Points and Rejoin Points”, in Journal of Object Technology, vol. 3, no. 5, May-June 2004, pp. 87-102. http://www.jot.fm/issues/issue_2004_05/article1

Previous column