Against Use Case Interleaving

Use cases are a powerful and widely recognised tool for functional requirements elicitation and specification of prospective software applications. However, there still are major problems and misunderstandings about the use case approach. One of these is the troublesome notion of use case interleaving which is discussed in this work. Interleaving is still present in the current UML specification. A. Simons correctly realised that interleaving compares with goto/comefrom semantics that were already judged harmful by Dijkstra at the emergence of the Structured Programming era. Simons, thus, has requested the explicit dropping of interleaving semantics. The authors give further support for Simons ́ request by showing that interleaving causes severe inconsistencies within UML and contradicts other proven and practically relevant use case concepts such as Goal-Based Use Cases of A. Cockburn, and contractual specifications of use cases expressed by preand postcondition approaches. Significant fixes to UML are proposed, in addition to those suggested by Simons. These will dramatically clarify prevailing problems and confusion with use cases and use case relationships among both practitioners and researchers. 1 Use Case Interleaving Semantics From Jacobson to UML v1.2 In [15], Jacobson et al. introduced the notion of use case interleaving. On the one hand, abstract use cases that are attached by a use case relationship may represent continuous interaction courses which are plugged into another use case as a whole [7], [8], [15], [22]. On the other hand, instead of embedding an abstract use case as a unit, it is also proposed to interleave the interaction elements of an abstract use case into the base use case [7], [8], [15]. Interleaving can be understood as cutting a given use case interaction into pieces and weaving them into the interaction description of another use case (see Fig. 1). Any interleaving is possible as long as the relative order of all use case elements is preserved [15], [21]. Originally, interleaving was introduced for the Uses relationship only [15] (predecessor of UML v1.3 ́s «include» relationship), but not for Jacobson et al. ́s Extends relationship (predecessor of UML v1.3 ́s «extend» relationship). 1 An abstract use case does not represent a complete external system functionality. Abstract use cases are a mechanism for structuring and refactoring descriptions of complete system behaviour [15]. They represent extracted parts of other use cases and are meaningful only in the context of the surrounding base use case definition. Hence, abstract use cases cannot be processed in isolation; thus, in the use case model, they do not have an actor attached directly.