Issue 16905: Constraints on superclasses needs to be overwritable for test data specifications (uml-testing-profile-rtf) Source: Fraunhofer FOKUS (Mr. Marc-Florian Wendland, marc-florian.wendland(at)fokus.fraunhofer.de) Nature: Revision Severity: Minor Summary: 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. Resolution: Deferred due to time restrictions. Disposition: Deferred Revised Text: Actions taken: December 14, 2011: received issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 14 Dec 2011 14:36:41 -0500 To: Subject: Issue/Bug Report ******************************************************************************* Name: Marc-Florian Wendland Employer: Fraunhofer FOKUS mailFrom: marc-florian.wendland@fokus.fraunhofer.de Terms_Agreement: I agree Specification: UML Testing Profile Section: 7.3 FormalNumber: ptc/2011-07-19 Version: 1.1 - beta 2 Doc_Year: 2011 Doc_Month: July Doc_Day: 19 Page: 26 Title: Constraints on superclasses needs to be overwritable for test data specifications Nature: Revision Severity: Minor CODE: 3TMw8 B1: Report Issue Description: 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 <> 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 <> or <> 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.