Répare ça, Sirius !

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 Donner une note à l'article (5)

Article lu   fois.

Les deux auteur et traducteur

Profil ProSite personnel

Traducteur : Profil ProSite personnel

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

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 ».

Image non disponible

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

Image non disponible

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.

Image non disponible

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 ».

Image non disponible

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 :

Image non disponible

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 ».

Image non disponible

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é.

Image non disponible

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 » :

Image non disponible

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

Image non disponible

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

Image non disponible

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 :

Image non disponible

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 » :

Image non disponible

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

Image non disponible

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 ».

Image non disponible
Image non disponible

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

Image non disponible

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.

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+