Structured Use Case Models

The research work of (Ryndina and Kritzinger, 2004) and (Ryndina and Kritzinger, 2005) provide an enhanced requirements specification methodology especially for complex systems and communication services by improving standard use case modelling (Jacobson et al., 1992). The authors point out that “use case models lack structure and exact semantics, which makes rigorous analysis of such models impossible” (Ryndina and Kritzinger, 2005). Consequently, they suggest supplementing traditional use case models with a formal structure and semantics such that the use cases are suitable for automated formal analysis. This procedure allows one to discover logical errors and missing requirements early in the development cycle and provides developers with a better understanding of the defined models (Ryndina and Kritzinger, 2004). The authors declare their enhanced use case approach as “structured use case models”.

In general, use case models specify functional requirements for a system or rather service by defining scenarios of interaction between the service and its environment. The main elements used in the models are actors and use cases. The actors represent entities that actually interact with the service whereas use cases define the functionality the service has to provide. Similar to the standard use case modelling, the approach described in (Ryndina and Kritzinger, 2005) focusses on treating the system (or service) under consideration as a “black box”.

The following Figure 5.1 illustrates the perspective on actor-system interaction, which is fundamental to the technique. Permission to reproduce Figure 5.1 has been granted by the authors of the referenced publication.

5.1 Existing Specification and Description Languages for Services in the Telecommunication Domain

Figure 5.1: Interaction between actor and system (Ryndina and Kritzinger, 2005)

Initially, the actor can call upon the system by activating the defined use cases. The system itself is described by the system state. This system state holds a set of conditions and can change throughout the model execution. Each defined use case within the specification is associated with a main flow and an unspecified number of alternative flows. Every type of flow has pre- and post-conditions. As soon as a use case is activated by an actor (1), the pre-conditions of the use case’s main flow are queried against the current system state (2). If the pre-conditions do not hold (3), the alternative flow of the use case is considered. Analogous to step 2, the pre-conditions of the alternative flow are queried (4) and in the example shown in Figure 5.1, they are satisfied in the system state (5). This leads to the post-conditions of the alternative flow changing the system state (6). The activation of a use case is said to be successful when the pre-conditions for one of the defined flows hold.

In order to define the structured use case models for systems or rather communication services, a metamodel was defined by the authors (see Figure 5.2). Permission to reproduce Figure 5.2 has been granted by the authors of the referenced publication.

Actor Use Case User System User System Main Flow Alternative Flow Pre-conditions Post-conditions Pre-conditions Post-conditions System State (2) Do these hold? (3) No (4) Do these hold? (5) Yes (6) Change state (1) Activate

Figure 5.2: Structured use case metamodel (Ryndina and Kritzinger, 2005)

The displayed metamodel shows that a structured use case model contains four different types of elements: actors, use cases, conditions and variable types. Each element comprises a number of properties that capture information related to that element. With reference to the definition of the metamodel elements, actors and use cases as well as their associations are depicted in a graphical representation (see Figure 5.1). For each actor and use case in the diagram, the textual properties can be defined in addition. The other elements, conditions and variable types, are completely textual and do not have graphical representations.

The actor element in the metamodel has two properties, a name and a list of attributes. The attributes include important information about an actor. In order to deliver services to the actor represented by use cases, a system has to be able to access these particulars. For example, an actor willing to setup a call to a system has an attribute called Username that he needs to provide to the system in order to consume the service. Due to the metamodel in Figure 5.2, each attribute is regarded as a variable, and each variable has

ModelElement name: String VariableType values: List Variable value : String InitialCondition type Actor UseCase actors 1..* use_cases 1..* Condition isTrue: Boolean condition 0..* attributes parameters 0..*

5.1 Existing Specification and Description Languages for Services in the Telecommunication Domain an associated variable type. A variable type is associated with a number of symbolic values, which are mainly string literals that can only be compared for equivalence (Ryndina and Kritzinger, 2004). Two defined variables are declared as equal if their values are set to identical string literals.

A further important element of the metamodel, the condition, is used to either describe the global state of the system or to declare use case pre- and post-conditions. The condition element has three properties: a name, a list of parameters and a truth-value (“isTrue”). A condition becomes a condition instance, as soon as values are assigned to all its parameters. The condition instance is either “true” or “false”. A special type of condition is the InitialCondition which is used to describe the state of the system before any interaction between actors and the system occurs (Ryndina and Kritzinger, 2005).

The final element in the metamodel, the use case, has five properties: a name, the list of actors playing a role in the use case, a parameter list, a list of pre-conditions and a list of post-conditions. The use case parameters describe information that is required to provide the corresponding service. As soon as a use case is activated, a value for each of its parameters needs to be passed to the system. The list of pre-conditions specifies that certain aspects about the system state must hold so that a use case activation can be successful. On the contrary, the post-conditions describe the change of the system state after a successful activation of the use case.

Based on the introduced metamodel for structured use case models, a simple chat service, will be described and specified as an example by means of the methodology. Initially, the general functions the simple chat service provides will be documented in a standard use

case diagram which also includes the participating actors. Figure 5.3 illustrates the sample use case diagram.

Figure 5.3: Use case model of sample chat service

The service chat usage includes two involved actors, an Administrator and a Service User. The Administrator can register new Service Users (“Add User”) and deregister existing ones (“Remove User”). He is also able to create new chat rooms for the Service Users (“Create Room”) or to erase old rooms that might not be used anymore (“Delete Room”). The other actor, the Service User, initially has to log in (“Login”) to use the provided functions, such as entering a new chat room (“Enter Room”), leaving the chat room after having entered (“Leave Room”) and sending messages to users in the same room (“Send Message”). Finally, the Service User can log out (“Logout”).

Each use case illustrated in Figure 5.3 can be defined by means of a special language presented in (Ryndina and Kritzinger, 2005). Exemplarily, the use case “Add User” of the actor Administrator is shown in the following Figure 5.4.

Service User Administrator

Login Logout Enter Room Leave Room Send Message Add User Remove User Create Room Delete Room

5.1 Existing Specification and Description Languages for Services in the Telecommunication Domain

Figure 5.4: Structured use case model definition of “Add User”

The definition of the “Add User” use case is quite straightforward and indicates that the Administrator is the only actor that can activate this use case. Furthermore, the Username of the Service User to be added needs to be provided to the system as a use case parameter. Each use case parameter has an associated variable type which defines a finite set of symbolic values. Here, the variable type UserLogin holds the value “chatUser1”. The pre- condition for the “Add User” use case states that the activation is successful if the user with the provided Username does not exist. In addition, the post-condition indicates that after successful activation of the use case, a Service User with the given Username exists. It is required that the pre- and post-condition defined within a use case correspond to a condition declaration within the model, where the name and the type of condition parameters are determined. In this example, the UserExists condition is declared. It indicates that the condition has one parameter of variable type UserLogin. The #uc prefix in the pre- and post-conditions states that at the time of activation, the value of the use case parameter Username should be used for the evaluation of this condition.

Most of the other use cases in Figure 5.3 can be defined similarly to the “Add User” use case. There is usually one action performed by an actor that causes a change of the system state, such as logging in and out or creating a new chat room. Through the pre- and post-

USE CASE 1 name: Add User actors: Administrator

parameters: Username of type UserLogin

pre-conditions: UserExists (#uc Username) is false post-conditions: UserExists (#uc Username) is true VARIABLE TYPE 1

name: UserLogin values: chatUser1 CONDITION 1 name: UserExists

conditions it can be easily verified if the action had the desired effect. The sending of a chat message is more complex because more parameters and conditions have to be checked. The following Figure 5.5 shows the definition of the “Send Message” use case.

Figure 5.5: Structured use case model definition of “Send Message”

In the use case model definition of “Send Message”, the actor role of the Service User is explicitly specified and enhanced by an attribute Username of the type UserLogin. Two parameters are required to activate the use case, the Username of the user who is about to receive the message and the Message itself. There are two pre-conditions that have to hold in order to activate the use case. On the one hand, all participating users have to be logged in; on the other hand, all users also have to have entered the chat room #room1. In order to verify both cases, the conditions LoggedIn and RoomEntered have been defined in the use case model definition. Besides, the #forall option allows checking that the conditions hold for all values of a particular variable type. Finally, the post-condition

USE CASE 2

name: Send Message actors: Service User

parameters: Username of type UserLogin, Message of type MessageContent pre-conditions: LoggedIn (#forall UserLogin) is true,

RoomEntered (#forall UserLogin, #room1) is true

post-conditions: MessageReceived (#uc Username, #uc Message) is true ACTOR 1

name: Service User

attributes: Username of type UserLogin VARIABLE TYPE 2

name: MessageContent values: Hello, how are you? VARIABLE TYPE 3

name: RoomDeclaration values: room1

CONDITION 2 name: LoggedIn

parameters: Username of type UserLogin CONDITION 3

name: RoomEntered

parameters: Username of type UserLogin, Room of type RoomDeclaration CONDITION 4

name: MessageReceived

5.1 Existing Specification and Description Languages for Services in the Telecommunication Domain of the “Send Message” use case states that the user with the Username of the use case receives the Message. Therefore, an additional condition MessageReceived is defined.

To sum up, the solution to structure standard use case models by applying the well- defined metamodel enables models that are far more consistent and correct. Nevertheless, important properties are missing, for instance the actions that actually take place within the use cases are not precisely specified. Tests cannot be generated from use cases if it is not defined how to trigger the system or rather service. Only the states of the system before the action and after the action are determined. It is also very hard to imagine how the conditions can be applied to the testing process. This can only be done if the conditions are predefined as reusable test components that have to be parameterised by the inputs defined within the use case models. This aspect would limit the possibilities to specify diverse types of services. It is possible that for each condition occurring in structured use case models for specified services, a proper test component first has to be developed by a test developer.