When Ecore metamodels use many OCL invariants and the models constrained by these invariants grow large, re-evaluating the invariants becomes a performance challenge. As OCL expressions can navigate freely across resource boundaries, changes to a model element in one resource can easily affect invariants for model elements in other resources. To reliably catch all invalidated constraints after a change it would be necessary to re-evaluate all invariants on all their context objects regardless their resource. This does not scale sufficiently well.
The
ImpactAnalyzerFactory
interface allows tool builders to efficiently determine a much smaller set of model elements on which re-evaluation of expressions is necessary after a change.
Given an OCL expression, the factory can be used to create an impact analyzer for a single expression as follows:
final OCLExpression e = ...;
final ImpactAnalyzer impactAnalyzer =
ImpactAnalyzerFactory.INSTANCE.createImpactAnalyzer(
e, // the expression to re-evaluate incrementally
false, // whether to re-evaluate when new context objects appear
OCLFactory.INSTANCE);
The impact analyzer obtained this way can create a change notification filter which can then be used to register for notifications that indicate a change which may affect the value of the expression. Consider the following example:
ResourceSet myResourceSet = ...;
EventFilter filter = impactAnalyzer.createFilterForExpression();
EventManager eventManager =
EventManagerFactory.eINSTANCE.getEventManagerFor(myResourceSet);
eventManager.subscribe(filter, new AdapterImpl() {
public void notifyChanged(Notification notification) {
Collection<EObject> valueMayHaveChangedOn =
impactAnalyzer.getContextObjects(notification);
for (EObject eo : valueMayHaveChangedOn) {
// ... perform some re-evaluation action of e for context eo here
}
}
});
The event manager can be used to register the event filters of several OCL expressions with their respective adapters. The adapters for different expressions do not have to be distinct but may optionally be shared. The following figure shows how the classes relate, as a UML class diagram:
For each OCL expression a new impact analyzer is used. The event filters produced by them can be registered with the same event manager. The following figure shows a typical instance collaboration diagram in UML notation.
The event manager factory and the event managers it produces lay the scalable foundation for the re-evaluation process. Even if it has to manage many subscriptions, its performance does not degrade as it would if the change notification filters were evaluated one after the other. With this it becomes possible to register many OCL expressions for change impact analysis as shown above. The figure below shows a typical default configuration of an event manager, as a UML instance collaboration diagram.
The event manager in the figure is configured to listen to the change events coming from anything inside the resource set. In this example it is shown with three different event filters, each coming with its own adapter handling those change notifications matches by the respective filter.
As described in more detail in the Javadoc, event managers may be re-used, temporarily deactivated and new ones may be created specifically upon request. This way it is possible to have several event managers, e.g., listening for changes during different phases of a model’s life cycle without having to create and initialize the event managers again and again. Also, an event manager is not restricted to listen to the changes of exactly one resource set. The following figure shows a not so typical configuration, again as a UML instance collaboration diagram.
The
org.eclipse.ocl.examples.impactanalyzer.ui package provides experimental support
for embedding the impact analyzer in EMF editors. Adding the lines
@SuppressWarnings("unused") // not read; just used to avoid GC
private Revalidator revalidator; // from collecting re-validator
to the field declarations of an editor class, and adding the lines
revalidator = new Revalidator(editingDomain, OCLFactory.INSTANCE,
DefaultOppositeEndFinder.getInstance(),
MyMetamodelEcorePackage.eINSTANCE);
at the end of the editor class’s
createModel() method turns on this experimental
support for the respective editors. Consequently, changes in the editor’s
ResourceSet
will trigger the re-evaluation of the affected invariants on the set of context objects
determined by the impact analyzer. Error markers of successfully validated constraints will
be removed, markers for invalid constraints are produced. As is obvious also from the
examples part of the package name, this is not yet production-ready code. It
may change or disappear without notice.
The basic idea on which the impact analyzer’s algorithm is based is this: take the EMF
change notification and see which elementary subexpressions, such as property call expressions,
are immediately affected by the change. From these pairs of
(subexpression, model element)
it is possible to walk the expression tree and navigate “backwards” from the model element
to the candidates for the
self variable for which the subexpression
may evaluate to the model element indicated by the notification.
Recursive operation calls and general
->iterate(...) expressions complicate
matters and lead to a recursive algorithm for the impact analysis.
It is permissible to use calls to OCL-specified operations. The impact analyzer will trace changes considering the called operation’s body expression.
The use of
allInstances inside an expression may be nasty for analyzing the
impact of a change because then it may no longer be possible to trace the change back to
the possible values for
self. In those cases the impact analyzer will simply
“give up” and return a collection of all instances of the expression’s context type and
its subtypes.
The impact analyzer can be created in several different configurations as explained in
detail in the
Javadocs . Particularly noteworthy is the relationship between the
OppositeEndFinder
and the way an
allInstance expression is evaluated. Both depend on a notion of lookup
scope. EMF does not provide any particular rules or conventions in this regard other than assuming that what has been loaded into a
ResourceSet is what tools can see. While this is a working procedure for forward navigation, it doesn’t help in defining a scope for
allInstances and reverse navigation when there is no explicit opposite property.
For this purpose, Eclipse OCL has introduced the
OppositeEndFinder
interface through which reverse navigations
of references and
allInstances lookups can be performed. Its default implementation
is based on the EMF default which is to consider the contents of a
ResourceSet the
universe. Other implementations are possible, however, such as one that uses
EMF Query2 to perform the necessary lookups.
A default OCL evaluator will always use the current
ResourceSet to determine
the set of all instances of a type. If a client has used an opposite end finder that implements
a certain lookup strategy then the default
allInstances evaluation is most likely
inconsistent with the scope definitions of that opposite end finder. To avoid such problems,
a
specific OCL factory can create OCL instances that ensure consistency between opposite navigation and
allInstances evaluation.
Other configuration options (see
ActivationOption
concern the specific algorithm used for tracing back from a change notification to the set of context objects for which the expression
may have changed its value. The default selection has proven to be the fastest for a set
of benchmarks. However, mileage may vary, and we’d like to encourage users to experiment
also with the non-default configurations.