ATL Use Case - Model Adaptation

Metamodel Evolution, Model Adaptation, Model Transformation, Petrinet.

This use case presents a solution to the model adaptation problem. This solution has been presented in [1]. Figure 1 illustrates the problem: a metamodel MM1 evolves into a metamodel MM2 (see the dotted arrow). Our concern is to adapt any terminal model M1 conforming to MM1 to the new metamodel version MM2 (see the dashed arrow).

Figure 1. Metamodel evolution and model adaptation

The use case proposes a three-step adaptation (see Figure 2). Firstly, an matching strategy computes the equivalences and changes between MM1 and MM2. Secondly, a HOT derives an ATL transformation from the discovered equivalences and changes. Finally, this transformation brings M1 into agreement with MM2, and persists the result in M2. We implement the prototype on the AMMA platform. More specifically, we use the AtlanMod Matching Language (AML) to specify the matching strategy, AMW to work with models of equivalences and changes, and ATL to implement the HOT. The HOT generates the adaptation transformation in ATL code too.

Figure 2. Approach Overview

The bulk of this use case is devoted to the first step that discovers equivalences, as well as simple and complex changes. We explicitly distinguish two kinds of changes because complex changes need a more insightful adaptation that simple changes. Whereas a simple change describes the addition, deletion, or update of one metamodel concept, a complex change integrates a set of actions affecting multiple concepts. The reader interested on examples of simple and complex changes may consult [2].

The running example is based on the two versions of the Petri Net metamodel provided by [3]. Figure 3 illustrates versions 0 (MM1) and 2 (MM2). MM1 represents simple Petri Nets. These nets may consist of any number of places and transitions. A transition has at least one input and one output place. MM2 represents more complex Petri Nets. The extraction of the reference dst illustrates a complex change named Extract class. This implies to add and remove a reference, add a class, and associate classes. In considering these actions as isolated simple changes, we may skip changes without migrating involved data from M1 to M2. In contrast, when we distinguish the complex change, we infer (for instance) that the added property (e.g., dst), contained in the new class PTArc, actually corresponds to the property dst removed from the class Place. Since we know the relationship between the properties we can migrate the data. We thus need to explicitly distinguish complex changes in order to properly derive adaptation transformations.

Figure 3. Petrinet metamodels

First step - Matching equivalences and changes

Model of equivalences and changes

Figure 4. Excerpt of the matching metamodel

Matching step

modelsFlow {

	tp = TypeClass[map2]	
	typeRef = TypeReference[map2]
	typeAtt = TypeAttribute[map2]

	merged = Merge[1.0:tp, 1.0:typeRef, 1.0:typeAtt]
	
	nam = Name[merged]
	
	filtered = ThresholdMaxDelta[nam]
	prop = Propagation[filtered]
	sf = SF[filtered](prop)
	norm = Normalization[sf]

	tmpresult = WeightedAverage[0.5 : norm, 0.5:nam]
 
 	result = BothMaxSim[tmpresult]

	diff = Differentiation[result]
	td = TypeDifferentiation[diff]   
	cl = ConceptualLink[td] 
	rw = Rewriting[cl]      
	flatt = FlattenFeatures[rw]	
}

The transformations above are generic enough to be applied to many use cases. It is ConceptualLink the one that figures out complex changes, and therefore leverages the solution to the model adaptation problem. For example, Figure 6 shows a rule that verifies if change Extract Class has happened. The helper 'isExtractClass' evaluates if: 1) there is a relation between the owner classes of the structural features referenced by EqualStructuralFeature 2) the right class is a new class. If the conditions are satisfied, the rule decorates a simple equivalence with the type ExtractClass.

Figure 6. A conceptual link rule

Note that our approach may need the user to refine the results. The refinement can happen at high-abstraction level, i.e., over final matching models, or at low-abstraction level, i.e., over generated adaptation transformations.

Second step - Translation to adaptation transformations

Figure 7. Petrinet transformation excerpt

Third step - Adaptation transformation execution