In the current UTP specification, the different test actions (StartTimerAction, ValidationAction, etc.) are indirectly bound to a lifeline by being referenced from an ActionExecutionSpecification that covers a lifeline, representing a structured classifier with <<TestComponent>> stereotype applied. This was necessary because there was no adequate meta model element in Interactions for placing a single action onto a lifeline. With UML 2.4, the meta model of Interactions have been reworked significantly in the way that the meta model element OccurrenceSpecification became a concrete class, specializing InteractionFragment. An OccurrenceSpecification has a reference to exactly one lifeline it covers. This the precise redefinition of test actions for Interactions, using the new UML 2.4 semantics.

Therefore, each test action (StartTimerAction, StopTimerAction, ValidationAction, etc.) shall extend UML::OccurrenceSpecification directly. Since OccurrenceSpecifications do not have a notation a priori, each test action has to define a dedicated notation (for some actions, there is already a notation defined, e.g. TimeOutMessage). This makes the actions easily and freely positionable on the lifelines. By doing so, the applicability of UTP would be significantly simplified. Besides, the memory footprint in the background would be extremly decreased, due to the fact that the event would be bound directly to the OccurrenceSpecification instead of creating a lot of elements (ActionExecutionSpecification, Action, Event, Input/OutputPins...)

The UTP predefines three interfaces, that are Scheduler, Arbiter and Timer. Mixing interfaces and stereotypes, which are supposed to work with those interfaces, is confusing and complicates the implementation of the profile. The idea of those interfaces is straight forward, however, the technical realization is hard to achieve due to mixed meta layers. UML::Interfaces instances are located at meta layer M1 (model layer), whereas Stereotype instances are located at meta layer M2 (meta-model layer).

Since the profile mechanism allows the definition of constraints for the base class of a stereotype, it is possible to express the semantics of the predefined interfaces with stereotypes and constraints, being applied on them. Even if a UML profile tool does not include OCL evaluation, the profile would be still easily implementable. The key point is here: Including OCL constraints into the semantics of a stereotype does not restrict the technical feasibility of the profile. Rather, the modeler would be responsible to respect the constraints of the stereotype. If a tool makes use of OCL expressions, the validity of the model would be checked automatically.

Some test cases might required additional hardware that is only available in specific timeframes. This means the test cases must be scheduled in detail and in certain sequences. Also, test cases may depend on each other.

Corresponding model element assignments can be established in principle with the current UTP specification, but a corresponding rule-set or a basic standard is missing.

Such kind of rule-set standard is necessary for potential tooling support of scheduling aspects coming out of an UTP test model.

Rational
#####################
OCL is the OMG’s formal, MOF-based language to express fine-grained constraints in MOF-based models. OCL expressions are unambiguous, precise and computable.

Issue
#####################
All constraints in UTP specification are defined with natural language. In order to help readers (tool vendors, tester, modeler) to implement, understand and apply the stereotypes of UTP properly, it would be helpful to use formal OCL expressions for these constraints. The natural language description may remain in the specification, meaning the OCL supplements the already existing description. The benefits would be two-folded: Both readers with and without OCL knowledge would be able to understand the specification.
UML 2.3 Superstructure, section 18.3.2 Extension, subsection Semantics explains how OCL constraints can be exploited to define restriction on the extended metaclass.

Source: Lockheed Martin, Jon Hagar
Specification: UML Testing Profile
Section: term data value
Nature: Issue
Severity: med
Summary:

The term data value is used many places and seems to be a root for data definitions, e.g. pools, but is not semantically defined.

Resolution:

Create a semantic definition for data values

Source: Lockheed Martin, Jon Hagar

Specification: UML Testing Profile
Section: fig 6.2

Nature: Issue
Severity: med
Summary:

Test Cases as an Operation
There isn’t a formal diagram notation for an operation in the UTP; therefore you can’t show it on a diagram using a standard notation. Tool vendors have provided solutions but they are not part of the standard. Figure 6.2 shows test case and operation (metaclass)

Resolution:

Provide notation definition of operation to be used throughout the standard.

Revised Text:

A common early step in specifying test cases is identifying a set of test cases. Today, «TestCase» is a stereotype of an "Operation" or a "Behavior" which is a specialization of a "Class". To support test case identification a test case should be a first-class model element that may exist standalone and that may visually be recognized as a test case.

A single test case must be stateful as it controls the sequence of the individual test steps and may need to store temporary data while being executed. These requirements make it difficult to have test cases based on operations. On the other hand, test cases need to be parameterized to achieve some level of genericity, which is less common to behaviors.

A single test case is a type that needs to be instantiable (i.e. executed) many times. Instances of a single test case may either be executed in a sequence or in parallel (in which case multiple instances of the same test case exist at the same time). When a single instance of a test case has been executed it should mainly be frozen but may be retained for historical reasons.

Today, «TestContext» is a stereotype of a "StructuredClassifier". However, test contexts must be able to contain anything that is useful to model test specifications, including other test contexts, test cases, test components, and even different kinds of diagrams.

When identifying test cases one of the most important goals is to minimize the number of test cases while maximizing the test coverage. The core approach to achieve this is to employ various mechanism that facilitate reusability. Therefore, it is very helpful to visualize families of related test cases and their associations on dedicated diagrams.

Test cases must support various associations among them so that they may be organized into families of related test cases.

The role of operation "getDistributionInterval" on class "DataPool" (in figures 6.39 and 6.41) is not clear.

The wildcard * to indicate any kind of default is particularly on state machines uncommon and inflexible.

Monitoring of interfaces between components within the SUT.

For each operand the guard has to be on each leading event within an alternative