Bx Examples Repository

Title: ModelTests

Version: 0.1

Type: Sketch


This is an informal example designed to illustrate that:

  1. it's reasonable to expect each model to contain information not contained in the other
  1. a naive notion of least change may not do the right thing


Let $M$ be UML models (not limited to class diagrams only)

Let $N$ be test suites (say, collections of JUnit test classes)


$R(m,n)$ iff both:

  1. for every class in model m, say with name Foo, there is at least one test class in n, with the naming convention that each such test class is called TestFooX for some natural number X;
  1. for every string Name such that there is at least one test class in n with a name of the form TestNameX for an integer X (there could be several different values of X for the same Name), there is a class called Name in m.

Consistency Restoration


$\overrightarrow{R}(m,n)$ deletes any test classes from n whose names are of the form TestNameX but for which there is no class Name in m. For any class (say called Name) in m not having any corresponding test class in n, it adds one “skeleton” test class TestName0.


$\overleftarrow{R}(m,n)$ deletes from m any class for which n contains no test class (along with any other model elements that must be deleted, such as associations to deleted classes). For any test class in n whose name is of the form TestNameX but for which there is no class Name in m, it adds a new class Name to m (in a suitable “default” state, e.g., not related to any other class, and having no attributes or operations).


Implemented naturally this will be correct and hippocratic, but not undoable (etc.: see Example 3, 4 of reference). It is simply matching (p13 of reference).


Ways to change the consistency condition include:

  1. We may specify that only certain classes in m, say, those with a given stereotype, need to be tested; any unstereotyped classes are ignored.
  2. We may drop the second consistency condition, allowing the test suite to have test classes TestFooX that don't correspond to a class in the model.
  3. We may impose a complex requirement relating the content of test class TestFooX to the model class Foo, e.g., relating the operations of the model class to the test methods of the test class.


If we make all of the changes to consistency listed above, and consider what consistency restoration can do, we get an instructive demonstration of the inadequacies of a natural naive notion of least change. Suppose that we start with a model having a «mustTest» class Foo, and a consistent test suite with a test class TestFoo0. Now a change is made to several test methods in TestFoo0, perhaps reflecting a decision by the coders that an argument of type float should actually be double, or similar. This violates the consistency requirement between Foo and TestFoo0. Now if we restore consistency by changing the model, one way to do so is simply to remove the «mustTest» stereotype from model class Foo. The restoration the user probably wants, however, involves making changes to several operations of Foo so as to restore the complex consistency requirement. In most naive measures of change size, the desired change to the model is not the least change that will restore consistency. Possible resolutions include a custom notion of change size that makes adding or removing the «mustTest» stereotype a very large change, or restricting the class of changes that consistency restoration is "allowed" to effect.


This is Example 1 from

author = {Perdita Stevens},
title = {Observations relating to the equivalences induced on model sets by bidirectional transformations},
journal = {ECEASST},
volume = {49},
year = {2012},
ee = {},
bibsource = {DBLP,}


Perdita Stevens



Unless otherwise stated, the content of this page is licensed under GNU Free Documentation License.