Static Footprinting

Static footprinting is achieved in two steps: First, the definition of the operation is analyzed to establish its static metamodel footprint, that is, the set of all metamodel elements involved in its definition. Then, model footprints are obtained by filtering models, selecting only elements that are instances of elements in the static metamodel footprint.

To establish the static metamodel footprint of an operation, we collect all metamodel elements (types and features) along its control flow graph - the set of all its possible execution paths.

The image below displays an excerpt of Kermeta's abstract syntax. CallFeature is especially interesting, as it represents the access to an object's state or the invocation of an operation on an object.

CallFeature objects can be found in 3 contexts:

• the body of a constraint (invariant of a class, contract of an operation)
• the body of an operation
• the body of a getter/setter of a derived property

For every CallFeature object, we add the following elements to the static metamodel footprint:

• the (static) type of the target object
• the feature being invoked
• the type of the property or the paramaters and return types of the operation

For every type being added to the static metamodel footprint, we add all its subtypes as well, to make subsequent model filtering easier.

The analysis has been implemented in Kermeta, as a visitor on Kermeta abstract syntax trees (a .km file). Two aspects are first woven to the Kermeta metamodel:

• EnhancedKermeta.kmt: augments Kermeta AST with usage annotations and some "shortcuts" to make the analysis easier
• VisitableKermeta.kmt: makes Kermeta AST visitable

The creation of a static metamodel footprint (and a static footprint metamodel) is achieved in 5 steps:

1. PrepareTransformation.kmt: prepares a Kermeta transformation for analysis
2. AnalyzeTransformation.kmt: the analysis of the transformation (construction of the control flow graph + collection of metamodel elements)
3. CompleteStaticMetamodelFootprint.kmt: completes a static metamodel footprint to a static footprint metamodel
4. DisplayStaticMetamodelFootprint.kmt: displays the static metamodel footprint and stores usage annotations in tags (so that they are available in Ecore models for the filtering phase)
5. CreateStaticFootprintMetamodel.kmt: creates a static footprint metamodel by removing irrelevant constructs

Main.kmt loads a Kermeta AST and apply these 5 steps to the given AST, creating a static footprint metamodel for it.

The filtering of a model through a static metamodel footprint is straight foward. First, we remove model objects whose metaclass is not part of the static metamodel footprint. Then, for every remaining object, we unset its features that are not part of the static metamodel footprint. The result of this filtering is a model conforming to the static footprint metamodel.

We have implemented this filtering in Java:

• ModelFilter.java
• MetamodelMatcher.java