Répare ça, Sirius !

Mélanie BATS

Traducteur

Alain BERNARD

Cet article présente comment intégrer des règles de validation au sein des éditeurs créés avec Eclipse Sirius. Il est recommandé d'avoir les bases de la création de diagrammes avec Sirius, vous pouvez pour cela lire ce tutoriel.
Pour toute remarque ou question sur ce tutoriel, profitez de cette discussion : Commentez

- Titre : Répare ça, Sirius !

- Auteur : Mélanie BATS

- Traducteur : Alain BERNARD

- Parution : 24 novembre 2015

- Licence :

Sommaire

- I. Introduction

- II. La validation sémantique

- III. Validation de la vue

- IV. Quick Fix

- V. Remerciements

- VI. Annexes

I - Introduction

EMF propose un système de validation puissant qui vous aide à détecter des erreurs dans votre modèle EMF. Mais de temps à autre, vous pouvez être amené à ajouter des règles supplémentaires qui ne seraient pas encore implémentées dans votre métamodèle. Encore une fois, Sirius va vous y aider ! Imaginons que nous souhaitons représenter le jeu d'arcade bien connu basé sur le film « Les mondes de Ralph ».

Nous définissons un métamodèle représentant le bâtiment (« Building ») présent dans le jeu :

Nous définissons aussi un attribut « isFixed » qui indique si le bâtiment est cassé ou pas et donc s'il a besoin d'être réparé.

II - La validation sémantique

Nous créons alors un nouveau projet de spécification Sirius et définissons un nouveau « viewpoint » avec un nouveau diagramme nommé « SemanticValidation ». Un mapping vers l'objet « Building » est ajouté et est composé de deux styles, suivant que le bâtiment est cassé ou pas.

Nous créons un nouveau modèle d'exemple qui définit un élément « Game » ainsi qu'un élément « Building ». Nous activons notre nouveau « viewpoint » et créons un nouveau diagramme « SemanticValidation ».

Nous créons aussi un outil dans la palette nommé « Wreck it! » qui peut être appliqué sur un objet « Building » et met la valeur de l'attribut « isFixed » à « false ». Après application de cet outil sur notre bâtiment, le diagramme a cette allure :

Une règle est ensuite définie pour détecter lorsque l'attribut « isFixed » est mis à « false ». Nous améliorons la spécification de notre diagramme en ajoutant une nouvelle règle de validation. Pour ce faire, sur l'élément de spécification de diagramme, sélectionnez « New Validation > Validation » et créez une « Semantic Validation Rule ».

Puis nous définissons :

- l'attribut « Level » : la criticité des problèmes reportés lorsque la règle de validation n'est pas vérifiée. Les valeurs sont « Information », « Warning » ou « Erreur » ;

- l'attribut « Target Class » : le type d'élément sémantique vérifié par la règle ;

- l'attribut « Message » : le message montré à l'utilisateur dans la vue « Problems » lorsque la validation échoue.

Un élément de type « Audit » doit aussi être défini afin de fournir l'expression qui doit être vérifiée pour valider la règle. Lorsque l'expression est évaluée à « true », aucun problème de validation n'est reporté. Sinon, les problèmes seront listés dans la vue « Problems ». Il est possible de définir plusieurs « Audit » pour une règle, dans ce cas la règle est considérée comme non validée dès qu'un « Audit » n'est pas vérifié.

L'utilisateur peut déclencher la validation grâce à un clic droit sur l'arrière-plan du diagramme et en sélectionnant le menu « Validate diagram » :

Si nous activons la validation sur notre bâtiment détruit, nous obtenons une erreur :

Sur le diagramme, le problème de validation est aussi visible grâce à un décorateur affiché sur l'image :

III - Validation de la vue

Une autre possibilité est de définir des règles de validation basées sur les éléments graphiques au lieu des éléments du modèle. Pour cela, nous créons une autre représentation nommée « ViewValidation » qui définit une règle de validation sur la vue :

Dans ce cas, la règle de validation sera appliquée sur un mapping et une erreur sera affichée lorsque la composante rouge de la couleur RGB de la bordure du bâtiment sera différente de 239. On peut aussi définir un « quick fix » qui modifie le modèle afin de réparer le bâtiment.

IV - Quick Fix

Les utilisateurs d'Eclipse aiment leur EDI, car il est souvent capable de leur proposer un « Quick fix » afin de résoudre les problèmes les plus courants. Sirius permet d'implémenter facilement un tel « Quick Fix », appelons-le « Répare ça Félix » :

Sur la règle de validation, nous définissons l'élément « Fix » :

Nous définissons le message et définissons la manière dont la réparation met à jour le modèle. Pour finir, nous exécutons le « Quick Fix » sur notre exemple, cela met simplement à jour la valeur de l'attribut « isFixed » à « true ».

Grâce à Sirius et Félix, notre bâtiment est réparé !

Vous pouvez aussi le détruire de nouveau… grâce à Ralph…

V - Remerciements

Nous tenons à remercier Mélanie BATS pour nous avoir autorisé à traduire et gabariser cet article issu de son blog. Nous remercions aussi Alain BERNARD pour la traduction et gabarisation, ainsi que Claude Leloup pour sa relecture orthographique attentive.

VI - Annexes

Le code source de cet article est disponible sur GitHub : https://github.com/mbats/sirius-blog/tree/master/validation.