uml2.0-test-profile.rar_OMG

17 UML 2.0 Testing Profile

Zhen Ru Dai

Fraunhofer Fokus - Institute for Open Communication Systems

Kaiserin-Augusta-Allee 31, 10589 Berlin

dai@fokus.fraunhofer.de

17.1 Introduction

The Unified Modeling Language (UML) is a visual language to support the de-

sign and development of complex object-oriented systems [RJB99]. While UML

models focus primarily on the definition of system structure and behavior, they

[SDGR03, DGNP04].

by the OMG. Since March 2004, the profile has become an official standard at

the OMG [U2T04].

In the U2TP specification, the consortium does not only introduce new con-

thoughts have been made on the test execution of the test model. For that, the

of a compiler, a TTCN-3 abstract test suite (ATS) is translated into executable

test suite (ETS). By means of the standardized TTCN-3 execution environment,

the ETS is able to communicate with the system under test.

Besides the test concepts and the mapping rules, the U2TP specification

defines two meta-models. One meta-model is based on UML 2.0 [UML03b,

UML03a] meta-classes and the second meta-model is a MOF-based (Meta-Object

M. Broy et al. (Eds.): Model-Based Testing of Reactive Systems, LNCS 3472, pp. 497-521, 2005.

 Springer-Verlag Berlin Heidelberg 2005

and time. Figure 17.1 shows the main concepts of U2TP [U2T04]. Together, these

concepts define a modeling language to visualize, specify, analyze, construct and

Test control Validation action Coding rules

Architecture Concepts The test architecture group contains the concepts needed

to describe elements involved in the test and their relationships.

The system or object to be tested is called the System Under Test (SUT).

As the profile only addresses black-box conformance testing, the SUT provides

only a set of operations via publicly available interfaces. No information on the

test cases defined in the test context.

A test configuration as an internal structure of a test context is used to

initial setup of the test components and the connection to the SUT and between

A test control is a specification for the invocation of test cases within a test

given test context. Often, decisions about further test case executions are made

within the test control specification in order to prevent spare time and resource,

e.g. if test case #1 fails, the whole test should be stopped, even if there are more

setVerdict.ThesetVerdict operation is used to provide updated information to

the arbiter by a test component regarding the current status of the test case in

which it is participating. Every validation action invokes the setVerdict opera-

tion on the arbiter. Every test context should have an implementation of the

arbiter interface. If there is no specific arbiter interface implemented, a default

arbiter will take into account.

A scheduler controls the execution of the different test components. The

scheduler will keep information about which test components exist at any point

in time, and it will collaborate with the arbiter to inform it when it is time to

SUT. The public test case operations of a test context are the test cases. In

addition, there may be other private or protected test cases that are used as

tation of test cases is specified by a test behavior. A test case always returns a

test verdict.

possible trace of execution. In a testing context, there is a need to have complete

state machines, states or regions, and in Activity Diagrams to actions and ac-

defaults are attached on interaction fragments to the intersection between the

nermost default fail to recognize the observed behavior the default of the next

Methodology and Framework [ISO94]: Pass indicates that the SUT behaves cor-

Inconclusive is used where the test neither passes nor fails. An error verdict

indicates exceptions within the test system itself.

A validation action can be performed by a test component to denote that

the arbiter is informed of a test result which was determined by that test com-

ponent. The coordination between arbiter and test components is controlled by

are behaviors in general and are generated during the execution of a test case.

(* or ?) are needed to specify test data, especially for data reception.

Test cases are often executed repeatedly with different data values to stim-

classes are used to define sets of allowed values. Typically, these values are taken

from a partition of test data, or lists of explicit values. For this purpose, a data

pool provides a means for associating data sets with test contexts and test cases.

explicit values.

Time Concepts When specifying tests, time concepts are essential to provide

to the existing UML 2.0 simple time concepts: Timer and time zone.

active. The expiration time of an active timer can be read and its live status