Summary: U2TP has to be aligned with the finalized UML 2.0

Since this is an old issue, alignment with the most recent version of UML (2.3) at the beginning of the UTP 1.1 RTF is targeted. Due to the changes of previously applied resolutions, UTP is now compatible with UML 2.3. Additionally, the resolution of this issue includes the alignment of the introductory sections with UML 2.3.

In the editing process for U2TP several editorial comments to be solved by the FTF have been made. These have to be addressed

see ptc/2004-04-10

Summary:
Hybrid defaults (i.e. defaults in state machines for test cases defined in interactions) cause the problem of defining the semantics for a hybrid behavior definition. In particular, the interworking of diagrams of different types is in general is not well defined in UML 2.0.
Hence, hybrid defaults should be removed from the U2TP specification

see ptc/2004-04-10

There are certain concepts in the standalone model which are of no use to the user: the default application, validation action and log action belong to behavior, which is not described in the standalone model. Hence, a tool vendor cannot really handle these concepts, e.g. a user could not really define a validation action outside of a context of a concrete behavioral specification.
Another view on this: we need for a tool vendor a compliance level which is an intermediate step from their existing tools to the standalone model. This compliance level should exclude the behavior definition, i.e. it should be open to any kind of test behaviors.

see ptc/2004-04-10

In testing, typically test cases are executed with different test data. For that, testdata is selected along different selection strategies. However, currently test data selection is not a separate concept in the UML testing profile.
The central point is the separation of test data specification and test selection for test execution. An additional interface to plug in different test selection strategies could be a solution.

see ptc/2004-04-10

The notions of data pool and data partition are used throughout the document but explained only in the terminology section. In the profile, it is argued that data pools and data partitions are modeled by use of standard UML 2.0 concepts, but it is not explained how. In the standalone model, both are missing completely.
Hence, data pool and data partition should be added to the standalone model. In addition, a standard way of representing data pools and data partitions should be defined for the profile (by defining stereotypes for data pools and data partitions).

closed issue

Technical references to TTCN-3 should not be part of the U2TP specification

see ptc/2004-04-10

the special comment declares a default - its behavior is given in a
behavioral diagram.

Hence the right rectangular box in Fig. 28 is superfluous. Also, the
definition of the statemachine for the default (in Fig. 28 and Fig. 29)
should simply contain the default identifier - i.e. hweDefault - and not
<<default>> statemachine hweDefault - both <<default>> and statemachine
are superfluous?!

Furthermore: the use of statemachine within the header of a
statemachine's behavioral diagram is repeated - i.e. in Fig. 30 - I
could not find in the superstructure document that this would be allowed

see ptc/2004-04-10

In some contexts where a Test Case (B) is reused (i.e. invoked) from another Test Case (A), there is an ambiguity to the actual intent of the tester
“A” needs to assess that “B” passes to set its own verdict
“A” is reusing the behavior of “B”. The verdict set for “B” by the arbiter is not relevant for either “A” or “B”
Proposal: A Test Case has a mandatory argument, which decides if its verdict should be logged in the Test Log. If the boolean is true, the verdict is logged, otherwise it is not

see ptc/2004-04-10

In the standalone model, default inherits from behavior, which would allow to define a test case or a test suite as a default.

see ptc/2004-04-10

The definition of load tests is cumbersome. There are no high-level operators to enable the parallel and quasi-simultaneous execution of test components - following a certain distribution function and realizing different test behaviors. Currently, one has to define e.g. a separate interaction to spawn the test components like in the example given in the U2TP specification.

see ptc/2004-04-10

The definition for a test suite in the profile has a condition: "A test suite must contain exactly one property realizing the Arbiter interface." This gives a constraint on the metamodel. The property is not named.

see ptc/2004-04-10

The arbitration interaction referenced in Fig. 36 is not shown.
The diagram in Fig. 39 defines a state machines and not an interaction. Hence, the sd in the header should be deleted.

see ptc/2004-04-10

The current specification of the UML Testing Profile does not address the specification of test behaviors with activity diagrams, although users see a need to have also activity diagrams been supported by the testing profile.

see ptc/2004-04-10

The notion trace could be confusing as it is used e.g. in UML 2.0 interactions to define the interaction semantics. Hence, a renaming is proposed.

see ptc/2004-04-10

Summary:
It should be possible to have traces for test suites and test cases. These traces should be defined comparable to the standalone metamodel traces.

see ptc/2004-04-10

The current standalone model does not allow to define a behavior for an arbiter

see ptc/2004-04-10

The current specification does not offer high-level concepts for functional synchronization and coordination between test components like rendezvous, joint start and joint termination

see ptc/2004-04-10

The current specification says nothing about the semantics of an arbiter for example how the arbiter gets to know that a test case finished and that the arbiter has to calculate the final verdict.

see ptc/2004-04-10

There is an "hanging" e top left of Fig. 4. - simply delete it.

see ptc/2004-04-10

Introduction of an ordered alt operator (“if-then-else”) operator. Mapping to more complex expression

see ptc/2004-04-10

Verdicts are part of a test case specification; however, a test case specification may contain several different verdicts - as different test sequences (all part of that test case) may lead to different verdicts. Hence, there is not a single test verdict and the attribute verdict of a test case should be deleted.

see ptc/2004-04-10

Users of the testing profile are confused with the containment relation of test cases to test suites. Test cases are considered to be independent of test suites (they are designed in the test planning phase), while test suites just denote one possible execution of test cases.

see ptc/2004-04-10

The UML Testing Profile lacks currently a definition of XMI schema for the profile and the standalone model. These are needed to allow tool interchange of test specifications. Here, the reference to an XML DTD in the compliance point definition should be changed to a reference to the schema definition

see ptc/2004-04-10

The standalone metamodel is not detailed enough to enable the implementation of testing profile compliant tools. In particular, many of the classes are having no attributes. Hence, a behavioural and further semantic foundation should be added to the standalone metamodel

see ptc/2004-04-10

Traces are currently related to test cases only, but a trace should be possible for a test suite as well.

see ptc/2004-04-10

Summary:
Test suites and test cases share certain characteristics, i.e. a behavior, test objective, and trace. Hence, a common superclass should be introduced

see ptc/2004-04-10