Revision as of 07:53, 21 April 2015

Surrogate queries for derived features

While query-based features have supported the definition of well-behaving derived features in Ecore models, users of Ecore models that could not be modified had no way for using derived features in queries. EMF-IncQuery 1.0.0 introduces surrogate queries for derived features, where a derived feature in a query is replaced by a subpattern call during runtime.

Usage

@Surrogate
pattern superClass(self : Classifier, super : Classifer) {
  Classifier.generalization(self, generalization);
  Generalization.general(generalization, classifier);
}

In order to create a surrogate query, simply add the @Surrogate annotation for a pattern and the generator fragment will take care of generating the correct extension points. When the query plug-in is included in the host, the EMF-IncQuery runtime will automatically replace path expressions including the feature with a suppattern call. In addition, if the plug-in is available in the host or target platform, the warning for a derived feature usage will be different (instead of warning about not representable feature, it will include the fully qualified name of the surrogate query).

Example

The UML metamodel used in EMF-UML contains a large number of derived features (see EMFIncQuery/UMLSupport#Status_of_derived_features for details), most of which are not well-behaving. This meant that defining patterns over UML models was often cumbersome.

Consider the following pattern:

pattern superClassWithQualifiedName(self : Classifier) {
  Classifier.superClass(self, superClass);
  Classifier.qualifiedName(superClass, "my::favorite::package::SuperSuperClass");
}

Both Classifer.superClass and NamedElement.qualifiedName are derived features, therefore

• the pattern editor will display a warning about these features not being representable for incremental evaluation
• the runtime will index the value of these features and no matches will be returned.

Since the value of these feature can be computed from the rest of the model, users often manually defined helper patterns, for example:

pattern superClass(self : Classifier, super : Classifer) {
  Classifier.generalization(self, generalization);
  Generalization.general(generalization, classifier);
}
 
pattern superClassWithQualifiedName(self : Classifier) {
  find superClass(self, superClass);
  Classifier.qualifiedName(superClass, "my::favorite::package::SuperSuperClass");
}

However, this approach has several drawbacks:

• Everyone reinvents the wheel by specifying derived features again and again.
• The definition is error-prone, you can easily overlook some detail in the computation and get unexpected results.
• You cannot use the derived feature itself in the pattern, only the explicit find to your helper pattern.

Surrogate queries were introduced to help overcoming these issues.

Technical details

Surrogate query support is provided by the @Surrogate annotation in the pattern editor, the corresponding code generator fragment, the runtime loading and usage of surrogate query registry, the runtime replacement of derived feature usage in queries. Additionally, when running outside of Eclipse, some additional setup is required.

Definition of surrogate queries

Runtime behavior

Usage outside of Eclipse