From use case to activity diagram

The first phase (see Section 4.1.1) of the ITERA methodology is the systematic creation of an activity diagram derived from the specification. First of all, use cases are determined on the basis of use case diagrams. The aim is to identify RFID relevant use cases and convert them step-by-step into activity diagrams. In the following steps, this process is illustrated by example of a RFID equipped library.

It is assumed that requirement specifications are available, which informally reflect the require- ments of the system to be tested or the system to be developed. These documents should identify a number of individual functional aspects, which at least partially describe the desired target behaviour of the system.

In the approach presented in this thesis, functional tests are carried out from a purely black-box perspective. Hence, the model is merely intended to describe the system’s black-box behaviour as perceived by the system environment. Therefore, a specification that describes the functional and process-related requirements of the system, i.e. the behaviour perceptible by the users or the system environment is required. The resulting model should not describe details of the technical implementation, which are insignificant from the viewpoint of system tests.

Example Use Case

In a first step, it is necessary to identify the components that are functionally related to each other in the requirement documents. A use case diagram can be created to obtain an overview of the various functions that the system is going to implement. The content of the use case diagram is the desired, externally visible system behaviour. Thus it is a part of the requirements that the system is supposed to meet. In use case diagrams, however, the activities within the individual uses are not considered. The aim is to identify the core functionality of the RFID application and the relationships between the application and its actors.

Figure 4.8 shows the use case diagram created during requirements analysis. In this example, it contains eight use cases and two actors. Every actor in the diagram has an association to a use case when he takes over tasks in the particular use case.

Use cases where first described by Ivar Jacobson [123] in 1987 as “a special sequence of transac- tions, performed by a user and a system in a dialogue”. Use cases often serve not only as a tool for designing the software, but can also serve as a basis for selecting test cases. In general, a use case contains steps and interactions of external actors with the system to perform a particular task. It is possible that an application may also contain alternative execution paths that are bound to certain conditions, as well as some exceptions where it is no longer possible to complete the task.

Use cases are often written in natural language and must therefore be refined in order to achieve detailed instrumentation for tests. For this reason, the initially informal descriptions of the

Figure 4.8: Example Use Case Diagram of a library

individual use cases are broken down by their functions in order to divide them into individual steps. Use cases can and should be continually adapted during discussions with stakeholders and by analysing other sources of demand. For simplification, the creation can be carried out in two steps: Initially, only the essential steps for a successful completion are covered. In a second step, these are then refined by adding exceptional cases.

Obviously, the most complete, detailed and consistent specifications of requirements at the beginning of a development project are desirable. In early phases of software development, however, it is not always possible to produce such precise documents - be it for lack of time or because of uncertainties about the exact design of the system to be developed. Therefore, the prerequisite that the original requirements documents must be complete or free of contradictions is waived. However, the activity diagram created in the following steps should be complete and consistent.

The table 4.2 shows the use case “check out books” of a sample library. According to Cockburn [124], use cases always contain a target that is contained in the description. The basic steps (also called main success scenario) describe the easiest way to achieve this goal. One step is an elementary action, which means that it cannot be broken down any further.

The pre-condition specifies the minimum requirements with which the described task can be started. The post-condition specifies possible effects or the result of the execution. Different conditions of can be linked with OR or AND to display possible results or exception handling during task processing.

Name check out books

Description The use case describes which checks are neces- sary in which order, so that a customer can bor- row a book from the library. The outcome is that the user successfully rented a book. actors user, self-checkout terminal

pre-condition the user has chosen some books to rent AND the self-checkout terminal is ready

post-condition the book was marked as borrowed basic steps

1. identify user

2. check user authorisation 3. identify rental object 4. check borrow-ability

5. save loan and mark book as rented 6. finish rental process

alternative

steps 2.a identification failed (Exception / Condi- tion)

3.a book could not be borrowed (Exception / Condition)

6.a user wants to borrow more than one book (Real alternative / Condition)

Table 4.2: Use Case: “check out books”

Since in practice individual requirements often do not completely satisfy the above pattern, an illustrative breakdown of the use case is shown. To illustrate this, the textual description of the “check out book” use case is used. In order to allow for a better understanding of the use case and to supplement the textual description, the self checkout terminal is shown in Figure 4.9. Use Case “check out book”: “The user selects some books from the library stock and moves to the self checkout terminal. After the start of the rental process, the terminal requires the user’s identification with the library card (ID card). For this purpose, the user places the ID card in the designated compartment. The system then checks the user’s authorisation. If the authorisation was successful, the user is asked to place the books to be borrowed on the designated shelf space. A RFID reader embedded in the shelf then records the books. If the borrow-ability has been successfully evaluated, the book is marked as ”rented“ in the library system and the terminal display is updated accordingly. When the user presses the finish button a summary is displayed and the process is complete.”

Figure 4.9: Self checkout terminal of the example library

Example Activity Diagram

For each use-case with relevance to the RFID system test, an activity diagram is created. Since it is often not possible to automatically transfer the use cases into activity diagrams, this step must be carried out manually. Figure 4.10 shows the derived activity diagram of the use case “check out books”.

It should be noted that when modelling process flows using activity diagrams, several test cases are modelled together for a given test problem. An activity diagram thus defines an entire test suite. For this reason, the individual test cases are initially not displayed in isolation, but in combination of different possible execution paths of the modelled application. Since the activity diagram is to be used as a basis for determining the test cases, it is necessary that the individual requirements are so fine-grained that a typical concrete execution scenario (sequence of context steps and interaction steps) is visible. If not, it may be necessary to further refine the requirements.

The activity diagram created this way should be lightweight and retain the natural language to be used as a communication medium between the requirements engineer and the customer. In order for the model to be suitable for the test purpose, the semantics of the individual activities must be clearly defined. Inputs and outputs should be clearly visible. User and system activities must be clearly separable. Alternative paths or their conditions must be explicitly listed and evaluable for the test.

The concept of model-based test automation for RFID application examined in this thesis is designed to generate added value through the systematic generation of specific test cases in

Figure 4.10: Example Activity Diagram derived from the use case refinement of “rental process”

software processes that do not force system modelling. Therefore, the test execution examined in Chapter 5 explicitly allows the manual creation of test cases.