This simple (looking) scenario tests to see if an attribute value, the multiplicity of an element (say with value 5 and multiplicity 3) in one bag, can be kept consistent with the actual number of such elements (3 elements all with value 5) in the other bag.
In the diagram below (taken from ), simple class diagrams are used to show one possible representation of this scenario.
A version 1 bag is consistent with a version 2 bag if very element in the version 1 bag corresponds to an element with the same value in the version 2 bag, and if every element in the version 2 bag with multiplicity m corresponds to m elements in the version 1 bag with the same value.
Conceptually simple: adding/deleting/editing elements of a certain value in the version 1 bag should result in the initial creation/increment/decrement of the multiplicity value of a corresponding element in the version 2 bag. Changing values and multiplicities of elements in the version 2 bag should lead to the creation and deletion of the appropriate number of elements with the right values in the version 1 bag.
Properties [optional section]
Variants [optional section]
Surprisingly difficult to express with TGGs (at least with eMoflon). This is because attribute conditions are currently confined to relations between attribute values and not a mixture of structural parts and attribute values.
This (practical) limitation is imposed mainly to guarantee correctness (and that plugged in implementations for attribute conditions cannot mess around with the graph structure).
References [optional section]
This example is taken from the following paper:
 Westfechtel, Bernhard. "Case-based exploration of bidirectional transformations in QVT Relations." Software & Systems Modeling (2016): 1-41.
Bernhard Westfechtel, Anthony Anjorin
Artefacts [optional section]
An implementation with QVT-R can be taken from .