Graphical Modeling Framework Tooling - Eclipse Modeling Project: A Domain-Specific Language Toolkit - page 526

with a corresponding reference. The diagram must be updated as well, to reflect
the change.
Node Constraints
A Constraint child element can be added to a Node Mapping , usually to dis-
tinguish between types in case a containment reference holds several (sub)types.
Constraint s can be defined in Object Constraint Language (OCL), Java, reg-
exp, and nregexp. The context of the constraint is the domain element selected
in the node mapping.
Primarily, constraints provide hints to the generator so that code is written
to obtain the proper visual ID for a node. A visual ID is an integer that the gen-
erator assigns to a node. At runtime, type checks are augmented by constraint
evaluation to return the proper visual ID where there would otherwise be ambi-
guity. Note that this feature becomes important when initializing a diagram from
an existing instance of a domain model. Normally, there is a user to eliminate
ambiguity when diagramming by selecting the proper node tool from the palette.
This also is useful when performing diagram updates with semantic refresh
because these constraints are checked when comparing view and domain ele-
ments, as discussed in Section 4.3.5, “Subtopic Figure.”
An example should make this point clear. Consider the Ecore metamodel and
the following relationship between EDataType and EEnum . Both are
EClassifiers and are held in the eClassifiers containment reference of
EPackage , as shown in Figure 11-11. When creating node mappings for each of
these, the eClassifiers reference is used as the Containment Feature .
With mappings to distinct creation tools in the palette, and with each node map-
ping's Element property set to distinct EClasses , the diagram supports the cre-
ation of both EDataType and EEnum elements. However, when trying to
determine the correct visual ID when pulling objects out of the eClassifiers
reference, instances of EEnum are ambiguous because they also appear as
EDataType . So which edit part visual ID to return?
Using a constraint on the node mapping for the EDataType that verifies (in
OCL) that it is not oclIsKindOf(ecore::EEnum) removes the ambiguity in
a straightforward manner. Alternative solutions exist, but this one falls into a
general pattern of using OCL to more precisely define mappings in GMF, as you
will see later.
Another use of constraints on a node is to distinguish between nodes that
represent the same domain element but might have an attribute set when initial-
ized. This is commonly the case with classes that have an enumerated type set to
a value. These go hand in hand with feature sequence initializers, which are
covered next.