Améliorations et notions avancées Eclipse Sirius, suite et fin de notre saga : comment concevoir son propre outil de modélisation DMN ? [4/4]
Voici les solutions aux défauts et aux limites de notre outil de modélisation DMN ( Domain Model and Notation ) commencé dans l'article précédent.
Les relations de type InformationRequirement sont remplacées par des « Element Based Edge » qui permettent l'ajout dans la palette des outils la possibilité de créer/modifier/supprimer des relations, des objets à la souris, la belle vie quoi.
On veut réaliser un outil graphique capable de créer un modèle DMN à la souris, respectant la norme de l'OMG.
Ci-dessous le résultat obtenu :
Pour ceux qui aurait manquer le début :
- DMN ( Decision Model and Notation ) : comment concevoir son propre outil de modélisation DMN ? [1/4]
- Le métamodèle Eclipse Ecore DMN ( Decision Model and Notation ) : comment concevoir son propre outil de modélisation DMN ? [2/4]
- Tutorial Obeo Designer Community : comment concevoir son propre outil de modélisation DMN ? [3/4]
Les relations étaient implémentées par des objets avec leurs images associées représentant des flèches.
C'était un bon début mais pas viable, la bonne solution c'est d'utiliser les Element Based Edge.
On commence donc par supprimer nos objets InformationRequirementNode :
- Dans le projet DMN.project.design – description – double clic sur DMN.odesign -
- Dérouler l'arborescence : le package DMN – DMNViewpoint – DMNDiagram - Default
- Clic droit sur InformationRequirementNode – Delete
La partie du modèle qui nous intéresse concerne la classe InformationRequirement représentant la relation entre 2 décisions.
Une relation InformationRequirement possède les attributs :
- requiredDecision : initialisé avec la Decision source qui elle même contient une liste nommée requiresDecision ( voir le source de Decision.java dans le projet Ecore Modeling Project com.urbanisationSI.dmn.dmnecore et aussi dans le fichier du projet Modeling Project du modèle DMN de la demande de prêt demandeDePret.dmnecore ).
- decision : initialisé avec la decision cible ( target ) ( qui possède une liste d'InformationRequirement qui ne sera pas utilisée ici ).
Un objet de type InformationRequirement est lié coté source de la relation à un requiredDecision de type Decision et coté cible à un objet de type Decision, nommé par défaut decision.
- Clic droit sur Default - New Diagram Element - Element Based Edge
- Dans Properties, voici comment mapper la source et la cible :
- Utiliser l'auto completion CTRL espace, par exemple en saisissant le package racine DMN, taper le . puis CTRL espace, la liste des classes du métamodèle DMN apparaît.
- Pour les expressions, Obeo Designer utilise le langage AQL ( Acceleo Query Language ), le terme feature: permet d'accéder aux rôles des classes UML ( nom d'une extrémité d'une association UML ). AQL possède aussi les termes var: et service:.
- Pour la propriété Source Finder Expression, saisir feature: puis CTRL espace une liste d'attributs de la classe InformationRequirement est proposé, il suffit de sélectionner requiredDecision.
Obeo Designer propose toute une série de style de relation ( trait continu, tiret, pointillé, flèche baton, flèche pleine, ... ) couvrant quasiment toutes les formes utilisées dans les langages de modélisation.
La norme DMN de l'OMG impose un trait continu et une flèche baton. Vérifier que la flèche est orientée dans le bon sens c'est à dire allant de la decision source requiredDecision vers la decision cible :
Affecter la couleur noire aux flèches :
- Sélectionner Center Label Style 8 - Onglet Color - dans la liste Label Color*, sélectionner black
Une nouvelle relation à implémenter par Element Based Edge, est la relation entre InputData et Decision représentée par la même classe InformationRequirement que précédemment :
La procédure est identique :
Procéder de la même manière pour la relation KnowledgeRequirement, relation entre BusinessKnowledgeModel et Decision
Attention, le style de trait est dash ( tiret ) : Edge Style - Properties - onglet General - Line Style = dash.
On termine par la relation AuthorityRequirement qui permet de lier KnowledgeSource à BusinessKnowledgeModel :
Le style adopté par l'OMG est un trait pointillé se terminant coté cible par un point noir. Pour simplifier, nous prendrons ce qui ressemble le plus :
En résumé, nous venons de créer un outil graphique capable de représenter visuellement un modèle DMN implémenté en Eclipse Ecore ( la demande de prêt ) en respectant la norme de l'OMG.
Mais ce ne serait pas un outil digne de ce nom, si l'utilisateur ne peut pas ajouter/modifier/supprimer des objets et des relations à la souris.
Nous allons donc voir comment créer et alimenter la palette graphique.
Pour créer la palette et pouvoir ajouter des objets Decision :
- Dans Default - clic droit - New Tool - Section - nommer la Outils
- Clic droit sur Section Outils - New Element Creation - Node Creation
- Properties - Onglet General - Id* = creationDecision - Node Mappings* = DecisionNode - Onglet Advanced - Icon Path sélectionner l'image que vous avez créée pour représenter un objet Decision ( voir article précédent ) =
- /org.eclipse.sirius.samples.family/samples/org.eclipse.sirius.sample.basicfamily.edit/icons/full/obj16/Decision.jpg
Définir les actions à exécuter lors d'une création de Decision :
- Clic droit sur Begin - New Operation - Change Context - Properties - Browse Expression = var:container
- Clic droit sur Change Context var:container - New Operation - Create Instance - Properties -
Remarque : Reference Name correspond au conteneur de base. Dans le fichier DMN Ecore de notre exemple demande de prêt ( demandeDePret.dmnecore ) :
...
<DMN:Definitions xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:DMN="http://www.omg.org/spec/DMN/20130901">
<drgElement xsi:type="DMN:Decision" name="Strategy">
<informationRequirement requiredDecision="//@drgElement.1"/>
<informationRequirement requiredDecision="//@drgElement.2"/>
</drgElement>
<drgElement xsi:type="DMN:Decision" name="BureauCallType" requiresInformation="//@drgElement.0/@informationRequirement.0">
<knowledgeRequirement requiredKnowledge="//@drgElement.3"/>
</drgElement>
On voit que les objets Decision sont bien contenus dans l'attribut drgElement qui est une liste d'objets Decision ou InputData ou BusinessKnowledgeModel ou KnowledgeSource ( la classe DRGElement est abstraite), de l'objet racine Definitions de notre modèle demande de prêt.
Voici un zoom, sur la classe Definitions du métamodèle DMN de l'OMG :
Pour nommer par défaut les objets Decision :
Clic droit Create Instance DMN.Decision - New Operation - Set - Properties -
Pour tester, il suffit dans l'onglet demandeDePretDMNDiagram, à gauche se trouve la palette Outils que l'on vient de créer avec l'icône Decision, cliquer dessus puis drag and drop dans le diagramme, un nouvel objet Decision est créé avec par défaut comme nom, uneDecision. Pour le renommer, cliquer sur l'objet, Propoerties et modifier la propriété Name, par ex. PreBureauRiskCategory.
Ajouter dans la palette des 3 autres objets de la même manière :
- BusinessKnowledgeModel
- InputData
- KnowledgeSource
On commence par InformationRequirement :
- Clic droit sur Section Tools - New Element Creation - Edge Creation
N'oubliez pas d'affecter l'image de la relation :
- Properties - Adavanced - Icon Path - ... - sélectionner le fichier images
Les action à réaliser lors de la création de la relation sont sur l'objet Decision source, créer une instance de type InformationRequirement.
- Pour avoir le détail complet des noms d'attribut des classes du métamodèle Ecore de DMN, il reprendre le Ecore Modeling Projetc : com.urbanisationSI.dmn.dmnecore, créé en premier et qui se trouve dans la 1ère instance d'Obeo Designer, celle à partir de laquelle, vous avez lancé le runtime.
- Dans src - DMN - Decision.java - (Interface) Decision - visualiser la liste des méthodes getter et setter permettant d'accéder et de modifier les attributs :
- setRequiresInformation : requiresInformation est l'attribut de la Decision source contenant la liste des InformationRequirement
- Interface InformationRequirement.java : la méthode setRequiredDecision modifie l'attribut requiredDecision permet d'établir la relation entre InformationRequirement et la Decision source et la méthode setDecision modifie l'attribut decision qui permet d'établir la relation avec la Decision cible ( target ).
- Il faut donc stocker la nouvelle instance InformationRequirement dans la liste requiresInformation de la Decision source puis initialiser son attribut requiredDecision avec la Decision source et son attribut decision avec la Decision target :
- Clic droit sur Begin - New Operation - Change Context - Properties - Browse Expression = source
- Clic droit sur Change Context source - New Operation - Create Instance
- Remarque : Reference Name = requiresInformation désigne la collection d'objet InformationRequirement de l'objet Decision source ( voir le source du fichier du métamodèle Ecore de la demande de prêt : demandeDePret.dmnecore )
- Clic droit sur Create instance DMN.InformationREquirement - New Operation - Set
- Clic droit sur Create instance DMN.InformationREquirement - New Operation - Set
Ajouter dans palette Outils de la même manière que précédemment, les Edge Creation :
- setInputData ( pas de difficultés )
- setBusinessKnowledge
- procéder de la même manière que précédemment, voici les propriétés pour create instance :
- setKnowledgeSource
- Pour le nom de l'attribut bkm, il faut regarder dans le Ecore Modeling Project "com.urbanisationSI.dmn.Ecore", dans le source de l'interface AuthorityRequirement.java, la méthode setBkm permettant de mettre le BusinessKnowledgeModel cible.
L'élément est supprimé de la vue et physiquement du modèle DMN.
- Clic droit sur Section Outils - New Element Edition - Delete Element
- Clic droit sur Begin - New Operation - Change Conrext - Browse Expression = var:element ( correspond à l'élément source )
- Clic droit Change Context var:element - New Operation - Remove
On peut vérifier par exemple que dans une relation entre 2 decisions, la suppression de la source ou de la cible entraine bien la suppression de l'objet et la relation InformationRequirement dans le modèle Ecore DMN de la demande de prêt ( demandeDePret.dmnecore ).
L'exemple vu dans l'article :
illustrait les concepts de DMN.
Voici le même modèle réalisé avec notre outil :
Conclusion
Cette série de 4 articles nous a permis de mieux comprendre DMN, son métamodèle, d'apprendre à créer un modèle DMN avec Eclipse Ecore et enfin d'apprendre ce merveilleux plugin Sirius, intégré dans l'open source Obeo Designer Community avec lequel on a créé notre outil de modélisation DMN qui possède les fonctionnaliés de base d'un outil visuel digne de ce nom.
Fini l'auto congratulation, il reste en effet pas mal de travail, voici quelques pistes pour compléter l'outil :
- Les pré-conditions an AQL ( Acceleo Query Language ), similaire à OCL ( Object Constraint Language de l'OMG )
- Reconnecter une relation
- Editer des propriétés directement dans le diagramme
- Personnaliser le style ( couleur, taille, ... )
- Layers permettant des affichages spécifiques du diagramme
- Les filtres
- Les règles de validations
- L'aide à la résolution des problèmes pour l'utilisateur
- Diagramme centré sur un objet
- Les conteneurs permettant d'avoir d'autres éléments de diagramme
- ...
Dans les projets d'urbanisation de Système d'Information auxquels j'ai participés, l'open source de moteur de règles métier Drools avait été choisi.
Son intégration concernait tous les acteurs de l'expert métier aux développeurs en passant par l'architecte technique et l'urbaniste.
Il conviendrait d'étudier l'interfaçage des modèles DMN avec Drools afin de générer des squelettes en langage natif DRL ( Drools Rules Language ).
En plus d'être non seulement le standrd de l'industrie, Drool s'intègre par défaut avec jBPM le moteur de processus métiers open source conforme à BPMN, mais on ne va quand même pas tout révéler aujourd'hui.
Rhona Maxwel
@rhona_helena
"N'allez pas là où le chemin peut mener. Allez là où il n'y a pas de chemin et laissez une trace."
Ralph Waldo Emerson
Articles conseillés :
DMN ( Decision Model and Notation ) : comment concevoir son propre outil de modélisation DMN ? [1/4]
Tutorial Obeo Designer Community : comment concevoir son propre outil de modélisation DMN ? [3/4]
A découvrir aussi
- DMN - L'antisèche de la notation complète des composants d'un DRD ( Decision Requirement Diagram ) : notation des exigences d'information
- DMN - L'antisèche de la notation complète des composants d'un DRD ( Decision Requirement Diagram ) : notation des exigences de connaissances
- DMN - L'antisèche de la notation complète des composants d'un DRD Decision Requirement Diagram : notation des exigences qui font autorité
Inscrivez-vous au site
Soyez prévenu par email des prochaines mises à jour
Rejoignez les 782 autres membres