Overview of the ITERA Meta Model

The purpose of the ITERA meta-model is to enhance the activity diagram with test-relevant aspects and to provide a interpretation of the actions modelled within the activity diagram. This enables the automated execution of test cases derived from the test model and makes it easier to determine the domain specific test data for a test case.

ITERA supports the modelling of context parameters and test relevant data, including inputs and expected outputs, within the framework of model based testing. The integration of these parameters into the test model is part of an iterative refinement of the previously created activity diagram. This is achieved by using a UML Profile (extending the OMG Meta Object Facility [47]). For the design of the meta-model, the modelling language UML was chosen, because it ensures that the test models based on this meta-model can be easily integrated into the development process of a software system. In addition to test modelling, the meta-model also bridges the gap between the semi-formal UML activities and the semantic model from Section 4.2.

The ITERA UML profile provides stereotypes that enable a direct modelling of the test relevant aspects into activity diagrams. This eliminates inconsistencies caused by separate documentation of additional test data. It is also suited for automated test execution, as all data is available through the models. The generation process of executable test cases is divided into two stages. At first the additional information contained in the activity diagram is transferred to abstract test cases. In the second step input data is provided which manifests itself in the concrete test cases, which can be used by the test environment.

Currently, UML activity diagrams do not directly provide a suitable way of including addi- tional test data. This is partly due to insufficient semantics of the activities and their informal descriptions (e.g. “place book”). The UML specifies the semantics of an action as:

“An Action is a fundamental unit of executable functionality contained, directly or indirectly, within a Behavior. The execution of an Action represents some transfor- mation or processing in the modeled system, be it a computer system or otherwise.” [47, p. 443]

The semantics of the individual activities in regard to testing is not apparent, especially con- sidering the high abstraction level of the activity diagram created from the use case. Therefore, it is necessary to clarify these with regard to the derivation of test cases. This is in accordance with the UML specification, stating that one reason for extending UML with profiles is: “Add additional semantics to UML or specific metaclasses” [47, p. 252].

By looking at an application from a black-box perspective, the behaviour is determined by inputs and outputs. Their type is defined by the interfaces of the SUT and informally described by the text contained in the activities of an activity diagram. Consequently, an activity diagram created from the application specification already contains descriptions of inputs and outputs, but usually in an informal and not computable format.

Common to all RFID systems is that RFID tags are detected when they pass through the interrogation zone of a RFID reader. However, depending on the implementation, interactions with other interfaces may also be possible. For example, interaction-based RFID applications (see Section 3.6) usually also offer a graphical user interface that can be used for interactions with the system.

As there are numerous different application areas for RFID technology, the number of available interfaces is difficult to delimit. For example, light barriers, weigh scales or other sensors can be employed also. However, a comprehensive description of all interfaces is too extensive and would go far beyond the scope of this work. For this reason a restriction to the aforementioned graphical user interface was made, in addition to the RFID components. In principle, other interfaces can be described similarly. An extension of the presented methodology by any input or output type is allowed, provided that appropriate changes are also made in the subsequent steps of the methodology and the test automation technology supports it.

An activity diagram also contains decisions that manifest themselves in alternative control flows and usually result in different execution paths of the SUT. For the transformation of UML activity diagrams to test cases, the distinction between alternative control flows initiated by the user or by system-internal functions is decisive. System decisions are often significantly influenced by user input and reflect the functional requirements of the application to be tested. However, internal system functions can also completely elude external influence, because they use parameters that cannot be determined by the user. Automated test case generation for such systems is expected to generate valid test cases for all alternatives in the control flow of such decision nodes. From the black-box perspective, the expected behaviour of the SUT can only be expressed through business rules (including preconditions). In order to influence the control flow in one direction or another, well selected test inputs must be chosen which either fulfil the precondition or not. In contrast to the system-internal decision nodes in the control flow graph, the decision criteria of user inputs are not determined by preconditions, but by alternative ways of interacting with the system interfaces. User decisions can be non-deterministic but constitute a fundamental part of the test, as all possible ways the user can interact with the SUT need to be tested. Likewise, a UML profile must be able to model the dependency of certain control flow alternatives on arbitrary decisions of the user.

However, the exclusive consideration of the system’s in- and output sequences is not sufficient to determine RFID specific test cases from activity diagrams. In contrast to other works that generate test cases from UML activity diagrams, RFID application tests must also consider activities that only have an indirect correlation to input. These are characterised in particular

by the temporal sequence of activities. Depending on the technology used and the configuration of the RFID system, an RFID tag can be read several times and thus results in multiple inputs to the SUT. Therefore, the test cases created from an activity diagram must provide detailed information about the temporal aspects (e.g. sequence, duration) and these need to be reflected by corresponding elements in the activity diagram.

Summarising the deduced requirements for an activity diagram, which can be used as a suitable test model:

• Requirement 1: The description of business processes modelled with UML activity dia- grams usually include user-specific and system-specific process steps. User-specific process steps are all types of decisions or actions and interactions with the system the user can carry out. From a classical black-box viewpoint, the user can only submit input to the system or observe the corresponding outputs of the system. Therefore, the meta-model as basis for the test model must be able to distinguish between actions initiated by users and actions initiated by the system.

• Requirement 2: Activities within the UML activity diagrams usually have no explicit semantic. In order to use it as a solid basis for test case determination, the meta-model for testable activity diagrams needs to be extended with a profile that also provides modelling elements for the semantics of these activities. These are interactions and decisions for each user and system.

• Requirement 3: Usually the duration of a sequence of activities is not considered when using activity diagrams. Therefore, the meta-model must be able to cover timing aspects as well, especially since it is an important aspect of RFID system testing.