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
{i >= 0 and i <= 100}
}
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
{i >= 0 and i <=100}
} //constraint inherited by class A
DP_2 extends A{ //invalid
+ a : Integer
{i < 0}
}
DP_3 extends A{ //invalid
+ a : Integer
{i > 0}
}
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
{i < 0 and i >= 0 and i <=100}
}
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.