Model transformations play a cornerstone role with the emergence of Model Driven Engineering (MDE), where models are transformed from higher to lower levels of abstraction. Unfortunately, a quick and easy way to check the correctness of model transformations is still missing, which compromises their quality (and in turn, the quality of the target models generated from them).

As a solution, in the paper presented in MtATL 2011 workshop we propose a lightweight method that performs a static analysis of ATL rules with respect to two correctness properties: weak executability and coverage. In order to improve its efficiency, our method works at design time without any need to simulate/execute the rules. A relevant feature of our method is the feedback it provides: if the checked property is not satisfied, the method returns feedback suggesting possible corrections to repair the detected errors.

First property we propose, weak executability of an ATL rule r, analyzes whether a rule r may be safely applied without breaking the target metamodel integrity constraints. That is, if there is at least a given set of elements that match the input pattern of r and for which the execution of  r generates a target model consistent with the target metamodel and its integrity constraints. Otherwise, r is useless, as every time it is executed, an error arises because the target model violates some integrity constraints.

As an example, consider the ATL rule “Person2Student” (which transforms people into students) according to the source and target metamodels showed below:

module Person2Student;

create OUT: StudentMM from IN: PersonMM;

rule Person2Student {
	from p: PersonMM!Person
	to s: StudentMM!Student (
		fullName <- p.name,
		college <- c
	),
	c: StudentMM!College (
	name <- p.collegeName
	)
}

 

Rule “Person2Student” is not weakly executable since, every time we create a new student and we do not associate it to any subject, we reach an erroneous target model where the minimum 1 cardinality of the IsEnrolledIn association is violated given that the new student is not related with any subject. Our method can report that, in order to create a new student, we need to assign at least one subject within the same execution.

The second property we propose, covering of an ATL rule set, analyzes whether a set of rules allow addressing all elements of the source and target metamodels. This property may be viewed regarding two perspectives:

• Source-coverage: We consider that a set of ATL rules is source-covering when all elements of the source metamodel may be navigated through the execution of these rules. For instance, the set composed by the single rule “Person2Student” is not source-covering since, for instance, rules to navigate age attribute and Knows association are not specified.
• Target-coverage: We consider that a set of ATL rules is target-covering when all elements of the target metamodel may be created and initialized through the execution of these rules. For instance, the set composed by the single rule “Person2Student” is neither target-covering since, for instance, rules to create objects of type Subject are not specified, forbidding users to create new subjects on the target model.

Even though not coverage does not indicate explicitly an error but only a warning, we feel this property is important to guarantee that no behavioral elements are missing in the rules.

For more information about how our method computes weak executability and coverage properties in a static way, please, read the complete paper.