The enumeration Verdict should be renamed to VerdictKind, to be consistent with UML and all other UML profiles.
UML supports the substitution principle of the object-oriented paradigm among other by not allowing the violation of constraints on superclasses in specialized subclasses. This is fine for the definition of system specifications. Testing, however, has to deal with invalid situations and data types. The most common test design/test data design technique relies on that fundamental principle of identifying "invalid" partitions of data types - the equivalence classes. Invalid means that the data partition does not comply with the constraints that is either applied to an interface operation or the data type itself.
In UTP, data partitions are defined as stereotypes on classifier, hence it is possible to reuse existing type definition (from an existing system model) and to create data partitions for that type (let's called it base type) that divides the base type into several different data partitions.
As an example, consider the following:
class A{
+ i : Integer
}
Applying the equivalence class method, this base data type would result in three equivalence classes/data partitions:
1. DP_1 = i >= 0 and <= 100 //valid
2. DP_2 = i < 0 //invalid
3. DP_3 = i > 100 //invalid
If we want to reuse the base data type for the design of test specifications, we would have to generalize the already existing class A by three different data partitions like:
DP_1 extends A{ //valid
+ a : Integer
} //constraint inherited by class A
DP_2 extends A{ //invalid
+ a : Integer
}
DP_3 extends A{ //invalid
+ a : Integer
}
Creating DP_2 and DP_3 would result in a contradiction, since UML disallows constraints to be deactivated or overwritten. DP_2 would look like this:
DP_2 extends A{ //invalid
+ a : Integer
}
This requires a mechanism to explicitly target constraints in superclasses which are overwritten (not redefined) in subclasses with <<DataParition>> applied.
To summarize: Test specifications address a larger set of data types than sytem specification, since they have to stimulate the system with data which are invalid by the system specification.
A possible and minimal inversive solution could the following be:
Introduce a new stereotype <<OverwritingConstraint>> or <<TestConstraint>> that has at least one tag definition, namely:
+ overwrittenConstraints : Constraint [1..*]
whereas each Constraint being referenced by the tag definition must be a constraint initially introduced by the base type of the data partition or one of its subclasses.
In situations where components already exist which shall be reused for the test architecture, it is contra-productive that test component only extends StructuredClassifier. This requires always the creation of a completely new test component (maybe using generalization) for the test architecture.
Treating TestComponent, in addition to its current representation, similar to <<SUT>> (which extends Property) would result in more flexibility since existing classifier can be reused for being both the SUT and a TestComponent in different tets context.
This is in particular helpful for reusing existing classifier.
This way would ot restrict the situation where completely new tets component classifiers must be created (maybe though generalization from already existing classifier in the system model). Current approaches would not become invalid, in contrast, this would result in a more precise and clear test configuration.
The specification states that coding rules should be defined outside of the utp model and just being referred from the utp model.
In some situations, it can might be required to include a precise coding and decoding of values already in the model.
Therefore, the coding attribute should be typed by ValueSpecification, which would allow both merely naming the coding rule that should be used by an external test execution environment (LiteralString) and a formal representation of the coding/decoding mechanism itself (Expression/InstanceValue/OpaqueExpression)
In the normative XMI representation of the UML Testing Profile version 1.2 (http://www.omg.org/spec/UTP/20120801/utp_1.2.xmi) there is the following ownedComment element:
<packagedElement xmi:type="uml:Stereotype" xmi:id="_PsR94OVOEeG84fBOY39c0g" name="TestCase">
<ownedComment xmi:type="uml:Comment" xmi:id="_ZvGtsOVOEeG84fBOY39c0g">
<body>[09.08.2012 09:16:54] ... my choice would be: Scandic Palace Tallinn, 3 VABADUSE VALJAK SQUARE, TALLINN, EE10141</body>
</ownedComment>
It seems to me that comment is by mistake, and not necessary in the profile definition.
Figure B.28 depicts an interaction between a tect component lifeline and several SUT lifeline. The first two and the last two messages invoke an operation called checkBalance with a actual parameter p.euAccount/p.usAccount, where p is of type TrxnData.
The type TrxnData is specified in Figure B.23, and in this Figure (which is the only Figure for the definition of TrxnData) there are no attributes for TrxnData called euAccount or usAccount, but account.
Given by constraint 6 of UML::Message (Section 14.3.18 in UML 2.4 Superstructure), messages are not allowed to cross boundaries of a CombinedFragment. Gates manage the connection of messages outside of a CombinedFragment to messages inside the CombinedFragment. So, in general, a cfragmentGate should be used in this Figure.
However, in picture B.14 a Default is depicted. Defaults express behavior for exceptional situation within a test case specfication, so actually, the behavior of a Default is added to the receiving test component lifeline for a particular message (shown in Figure B.13), or for a set of messages (not mentioned in the spec at all). Thus, the two boundary-crossing messages shown in B.14 do not have a real counterpart in Figure B.13 (they are just additional messages).
For resolution, I suggest to use found messages (UML::Message with MessageKind::Found) within the InteractionOperands of the determAlt CombinedFragment, to indicate they are additional message for which no real counterparts exists in the interaction applying a Default.