UTP11 — utp::InteractionOperator::determAlt not applicable in CombinedFragment

Rational: Section 6.3.2 Test Behavior, Subsection InteractionOperator says the following:
—
The deterministic alternative is a shorthand for an Alternative where the operands are evaluated in sequence such that it is deterministic which operand is chosen given the value of the guards, regardless of the fact that the guard for more than one operand may be true
—

Issue: utp::InteractionOperator::determAlt is embedded in an UTP enumeration and therefore not applicable to UML models. UML::CombinedFragment refers to UML::InteractionOperator instead, so that it seems as utp::InteractionOperator is an extension to UM::InteractionOperator. Extending metaclasses is restricted by the UML Profile design requirements (UML::Superstructure, Section 18.1.2, Item 1):
—
8. […] UML Profiles should form a metamodel extension mechanism that imposes certain restrictions on how the UML metamodel can be modified. The reference metamodel is considered as a “read only” model, that is extended without changes by profiles. It is therefore forbidden to insert new metaclasses in the UML metaclass hierarchy (i.e., new super-classes for standard UML metaclasses) or to modify the standard UML metaclass definitions (e.g., by adding meta-associations). Such restrictions do not apply in a MOF context where in principle any metamodel can be reworked in any direction.
—

UTP::InteractionOperator::determAlt must be completely redesigned in order to be applicable to UML models.

Change the determAlt enumeration into a «DetermAlt» stereotype, enhancing CombinedFragment instead. The idea is to declare the whole combined fragment as a deterministic alternative. This would address another shortcoming of the current description of determAlt. In contrast to the normal operand selection semantics of UML for alternative combined fragments, the determAlt combined fragment is intended to work slightly different: The decision whether an operand should be entered is resolved by the first occurrence specification of a test component lifeline first. If the actual occurrence specification matches the expected one during execution, than the guard condition is going to be evaluated. The guard condition expresses restrictions on data instances, potentially accompanying a receive message. If the guard is left empty, this is a shortcut for “true”. Only if both conditions are met, the operand will be entered.