Cours complet sur ATL (ATLAS Transformation Language) : les règles appelées (Called Rules)

Dans l'article précédent :

https://www.urbanisation-si.com/cours-complet-sur-atl-atlas-transformation-language-les-regles-paresseuses-lazy-rules

nous avion abordé les règles paresseuses (Lazy Rules). Voyons à présent les règles appelées (Called Rules).

Les règles appelées (Called Rules)

Elles permettent de générer explicitement des éléments de modèle cible à partir de code impératif. Excepté pour un “entrypoint”, une règle appelée doit explicitement être invoquée à partir d’un bloc impératif ATL.

Syntaxe :

[entrypoint]? rule rule_name''(''parameters''){
[using {
var1 : var_type1 = init_exp1;
...
varn : var_typen = init_expn;
}]?
[to
out_var1 : out_type1 (
bindings1
),
out_var2 : distinct out_type2 foreach(e in collection)(
bindings2
),
...
out_varn : out_typen (
bindingsn
)]?
[do {
statements
}]?
}

Description, une règle appelée :

est identifiée par un nom unique (inclus les nom des helpers), different de “main”
peut optionnellement être déclarée dans l’entrypoint ATL.

Une transformation ATL peut inclure une seule règle appelée avec un entrypoint.

A la différence des autres règle appelées, celles avec entrypoint n’ont pas besoin d’être invoquées explicitement : elles le sont implicitement au début de l’exécution de la transformation une fois que la phase d’initialisation des modules est terminée.

Une règle appellee peut avoir des paramètres de la même manière que les helpers.

Elle est constituée de 3 sections optionnelles :

using,
to,
do.

Par rapport à une règle de correspondance, une règle appellée n’a pas de section from et la section to est optionnelle.

La sémantique des sections disponibles est la même que pour les règles de correspondances :

using permet de déclarer et d’initialiser des variables locales visibles du reste de la section using aussi bien que de la to et do;
to section correspond au pattern cible. Elle contient plusieurs éléments de pattern cible. Contrairement aux règles de correspondances, il n’y a pas d’élément de modèle source qui doivent correspondre pour que les éléments de modèle cible soient initialisés;
do permet de spécifier un bloc impératif d’instructions. Si une section to est spécifiée, le bloc imperative est execute une fois que le pattern cible est terminé d’être traité.

Exemple :

helper def: metamodel : KM3!Metamodel = OclUndefined;
...
entrypoint rule Metamodel() {
to
t : KM3!Metamodel
do {
thisModule.metamodel <- t;
}
}

Cette règle appellée est définie dans le point d’entré de la transformation. Cela signifie qu’elle est exécutée entre l’initialisation et la phase de correspondance. Il génère un élément de métamodèle. Le code est spécifié à l’intérieur d’un bloc impératif avec une variable (metamodel) définie dans le contexte du module ATL, pointant sur cet élément de modèle. Cela signifie que le métamodèle généré reste accessible pour des futures traitements pendant la transformation.

"Tous les trésors de la terre ne valent pas le bonheur d'être aimé."
Pedro Calderón de la Barca

Voir aussi :

http://urbanisation-si.wix.com/blog

http://urbanisme-si.wix.com/blog

http://urbanisation-si.wix.com/urbanisation-si

http://urbanisation-si.over-blog.com/

http://rhonamaxwel.over-blog.com/

http://urbanisation-des-si.blogspot.fr/

http://bonnes-pratiques-si.eklablog.com/

http://urbanisation-si.eklablog.com/

13/10/2015