Use Case Model Refactoring : Changes to UML ́ s Use Case Relationships

Use cases are a powerful and widely recognised tool for functional requirements elicitation. However, there still are major problems and gaps in UML ́s use case foundation. One such issue is the way extend and include relationships are used in refactoring textual and graphical use case models. Experience shows that practitioners do not only use extend-relationships as defined by UML, but also to express both partial and fully parallel interaction courses and exceptional use case behaviour. However, UML ́s current definition of the extend-relationship fails in this demand. Hence, this work presents significant and detailed UML changes to fully support these practical needs, based on a previous work that identified and defined types of alternative courses in use case interaction within the context of goaldriven requirement engineering. We include previous research findings on the notion of use case interleaving in use case relationships. As a result, this paper will close major and prevailing gaps between the UML use case metamodel and practical necessities leading to an improved understanding of how to apply use case relationships in practice. An initial review of use case basics is presented to help orientate the reader. Based on this, simple examples are presented that highlight the extend-relationship ́s weaknesses. Finally, we will finish with UML change proposals to fill in these gaps; these proposals are illustrated by applying them to the examples presented. 1 Brief Review of Use Case Basics A use case is the description of a software-supported part of an enterprise ́s business processes. It is derived from the stakeholder ́s and actor ́s needs. Stakeholders and actors may be human, hardware, or component elements of the future system’s IT environment. A use case must provide value to these business processes. Therefore, it is associated with a set of atomic measurable business results that is delivered to an actor or stakeholder [6]. The actor instances need to participate in a use case execution in order to deliver the use case business results. Consequently, a use case goal leads to an interaction between the system and actors. The description of use case interaction encompasses two parts [9]. A Basic Course describes the main sequence of interaction in which everything goes right (“happy path”). Any non-frequent alternative of the basic course of interaction, such as optional interaction parts and business error recovery, is called an Alternative Course. In this sense, the term alternative course specifies a guarded variation of a part of another interaction course and, thus, is subject to a business guard [1], [6], [9], [10], [11], [17]. The following examples illustrate basic courses and alternative courses following the specification technique in [6]. These examples will further serve as a basis for understanding the reasoning presented in the subsequent sections. Example 1: use case goal with the goal “Withdraw Cash” of an ATM Basic course: 1. The customer inserts the card. 2. The system validates the card. 3. The Customer enters the PIN. 4. The system validates the PIN. 5. Now consider the following alternative courses: 4a. PIN has been entered incorrectly for the first or the second time: 4a1. The system notifies the customer. 4a2. The system logs the attempt. 4a3. Rejoin at 3. 4b. PIN has been entered incorrectly the third time: 4b1. The system notifies the customer. 4b2. The system logs the attempt. 4b3. The system withholds the card. 4b4. Use case is aborted. Example 2: use case with the goal “Register New Student" Basic course: University Administration Clerk of the central student affairs dept. Register New Student Fig. 2: Use Case Diagram for Example 2 ATM Customer Withdraw Cash Fig. 1: Use Case Diagram for Example 1 1. Clerk enters new student ́s name, address, . 2. The system assigns a student ID. 3. Clerk assigns the university department. 4. System prints out a confirmation of registration. 5. Now consider the following alternative course: 3a. Student is a foreign student with scholarship: 3a1. The system shows the capacity of free campus apartments. 3a2. The clerk assigns an apartment to the student ID. 3a3. Rejoin at 3. Example 3: use case with the goal “Register New Employee“ Basic Course: 1. The personnel manager enters new employee ́s name, address, and telephone number. 2. The system displays the vacancies and job category. 3. The personnel manager chooses the considered vacancy. 4. The system shows the scale of wages. 5. The personnel manager determines the hourly rate. 6. The system assigns an employee number. 7. The system assigns the company department based on the selected vacancy. Now consider the following alternative course: 4a. The applicant will be paid outside the pay scale and will have flexible working hours: 4a1. The personnel manager determines the new employee ́s monthly salary. 4a2. The personnel manager determines fringe benefits. 4a3. Rejoin at 6. The following section relates the above-highlighted use case fundamentals to the semantics of UML’s use case relationships. Personnel Administration Personnel Manager Register New Employee Fig. 3: Use Case Diagram for Example 3 2 UML ́s Use Case Relationships An extend-relationship is used for extracting alternative courses from a base use case into a new use case and attaching it to the base use case [1], [5], [9], [10], [13], [15], [16], [17]. Therefore, when extracting an alternative course, an extend-relationship specifies a condition as well as an extension point which references the label of a single branching location within the base use case [13]. Fig. 4, Fig. 5 and Fig. 6 show examples of the application of extend-relationships based on the introductory examples in Section 1.