Use Cases Considered Harmful

This article traces the unstable semantics of use cases from Jacobson to UML 1.3. The UML 1.1 metamodel formally defined the «uses» and «extends» use case relationships as stereotypes of generalisation, yet both received interpretations that varied between inheritance and composition, reflecting a large degree of confusion among developers. The recently revised UML 1.3 has quietly dropped these in favour of new «include» and «extend» relationships, which are styled instead as kinds of dependency. Despite this change, the deployment of use case diagrams encourages analysts to conceptualise and develop models which conceal arbitrary jumps in the flow of control, corresponding to goto and comefrom statements, and in which unpleasant non-local dependencies exist across modules. A discussion of examples reveals how a conscientious designer must disassemble use case models completely to produce properly-structured code. A radical solution is proposed. 1. Jacobson's original use cases The recording of use cases was hailed as a significant advance in object-oriented analysis, since it allowed the process of requirements capture to begin further upstream than with naïve object modelling [4]. Different scripting techniques in object-oriented analysis appeared at around the same time: as use cases in OOSE [17], as scenarios in OBA [23] and as task scripts in SOMA [13]; although formalised scripts first appeared in Schank's work on conceptual dependency [24]. 1.1. The size and representation of a use case A use case is defined as: "a sequence of transactions performed by a system, which yields an observable result of value for a particular actor" [19, p66]. The emphasis on a single observable result is a deliberate constraint which seeks to ensure a minimum and maximum granularity for a use case, which cannot be an incomplete sequence (offering no benefit), nor multiple sequences (achieving several benefits). A use case is drawn as a labelled ellipse in a use case diagram, connected by lines to stick-figure actors, denoting the typed rôles of the participants in a use case, accompanied by an informal paragraph describing either: the interaction of an idealised user with a computer system [17], or: the performance by an idealised business stakeholder of an everyday work task [18]. Various authors have attempted to improve on this informality, for example: [9, 14, 15, 5, 6]. 1.2. The type-level semantics of a use case Whereas the scenarios of OBA were collected as instances of user-interaction, each like a single execution of a process [12, 23], in Jacobson's approach [17, p127-8] a use case was considered a type-level concept, more like a procedural definition. This is evident in statements such as: "Each use case is a specific way of using the system and every execution of the use case may be viewed as an instance of the use case" (p127) ... "When a use case is performed, we therefore view this as: we instantiate the use case's class" (p127-8). "The use case instance exists as long as the use case is operating." (p127). Furthermore, Jacobson considered a use case to be a kind of class, which defined state variables, whose instances could record how far a particular thread of execution had reached [17, p128]. Curiously, this account resembles exactly a class having a procedural body, a construct present in the languages Simula [7] and Beta [20]. Defining a use case as a class was in keeping with Jacobson's meta-theoretic goals to have a single framework for describing both systems and the Objectory method itself. He was keen to see Objectory as a "use-case driven approach", that is, a method that could reflexively be described in terms of use cases. Use cases therefore had to follow the class and object model used elsewhere to describe software systems. 1.3. Unequal uses and extends dependencies Jacobson described all optional, alternative and exceptional branching behaviour as extensions to a putative main use case [17, p163-5]. The style in which extensions were developed was motivated chiefly by the observation that it was inconvenient to have to return to the textual description of the "main flow of events" and edit this, just to incorporate new branch points; instead the extension named the point in the main case at which its behaviour was to be inserted. Visually, this dependency was indicated by making the extends arrow run from the extension to the main case. Curiously, this directionality is the exact opposite of the selection decomposition in traditional Yourdon or JSP structure charts. The meaning of an extension was: a guarded block of optional functionality that could be inserted into a main use case (p165). The principle of minimising the impact of changes was abandoned when analysts were encouraged later to restructure their use cases. A common underlying set of interactions in several main cases could be pulled out as an abstract use case (so-called because it was not to be instantiated independently, since it did not refer to a complete sequence), which was then used by several concrete use cases [17, p170-3). Visually, this dependency was indicated by making the uses arrow run from the concrete to the abstract case. The meaning of a concrete using case was that it was equivalent to the original use case prior to refactoring, the only change being the internal way in which the information was described. In this respect, the uses relationship was considered to be a "kind of inheritance" (p170). The rationale for developing uses relationships (restructuring) therefore seems to contradict that for developing extends relationships (convenience). Why was it not equally appropriate to restructure use cases to include branch points? This asymmetric treatment lies at the cause of a major inconsistency in the way in which the notion of dependency is interpreted in UML 1.3 (see section 3.4). 1.4. The procedural meaning of uses and extends The procedural interpretation of extends is over-simplistic (and challenged in section 3.2). Jacobson's main idea, which persists into UML 1.3, seems to have been that you can insert optional behaviour into existing procedural descriptions, and that this model should then be sufficient to cover: optional subroutines, alternative courses and exceptional cases [17, p165]. Jacobson's examples of extensions (p164-5) can all be interpreted as guarded blocks, that is, single-branch if statements that execute if the appropriate condition, or guard, is satisfied. Login/Logout Login/Logout Compile Word Process Mail extends extends extends