urbanisation-si.com

Ou comment Red Hat donna vie au langage DMN (Decision Model and Notation) en le rendant exécutable et en fit une pièce maîtresse du concept des transformations des aspects dans l'architecture d’entreprise.

Les règles métiers font partie de la connaissance stratégique de l’entreprise et doivent être modélisées avec la norme DMN les rendant indépendantes de leur implémentation informatique.

Les dernières innovations des outils de modélisation DMN permettent avec un simple clic de générer le code en langage Drools (DRL Drools Rules Language), le standard open source de l’industrie des moteurs de règles métiers (BRMS Business Rules Management System) et bien sûr de pouvoir l’exécuter.

Si vous n’êtes pas familier avec BPMN (Business Process Model and Notation)

La plupart des experts métiers ne sont pas concernés par le code, sauf dans les domaines des règles métiers où la logique très détaillée, y compris les quantités, les dates et les formules de calcul, est essentielle.

BPMN a été étendu pour inclure la modélisation des règles métier avec la notation de modélisation de décision (DMN).

Bien que séparé de BPMN, DMN a été conçu pour fonctionner avec BPMN.

Avec la modélisation de décisions, les experts métier peuvent contrôler un processus en déterminant :

• Que doit-on faire ensuite ?
• Qui doit le faire ?
• Quand et où cela est-il fait ?
• Et surtout, des règles importantes ont-elles été enfreintes ? 

Cela fait déjà un certain temps que les processus métiers exécutables au sens de la norme de modélisation BPMN, peuvent l’être réellement dans un moteur BPM (Business Process Management) comme par exemple jBPM.

Les 2 open source jBPM  et Drools de l’éditeur Red Hat (qui édite aussi des versions payantes) sont aujourd'hui intimement associés et supportent entièrement les 2 normes soeurs BPMN et DMN.

Les concepts de base :

1. BPMN 2 : les concepts de base des processus métiers
   
2. BPMN l’exemple type pour tout comprendre sans prendre d’aspirine

Démonstration de la modélisation d’un processus métier avec BPMN et son exécution complète.

Ce tutorial sur jBPM est destiné aux experts métiers et garantit 100% sans code de programmation :

1. Tutoriel jBPM : étude de cas avec human task (partie 2/10)
2. Tutoriel jBPM : connexion à l'IDE KIE Workbench et création des unités organisationnelles (partie 5/10)
3. Tutoriel jBPM : conception du processus en BPMN 2 (partie 6/10) 
4. Tutoriel jBPM : vérifiez la conformité à la norme BPMN 2 (partie 7/10)
5. Tutoriel jBPM : génération de formulaires et mapping des variables (partie 8/10)
6. Tutoriel jBPM : construction et déploiement du processus de notre étude de cas (partie 9/10)
7. Tutoriel jBPM : démarrage et test final de l'exécution complète de l'étude de cas (partie 10/10)

Si vous n’êtes pas familier avec DMN (Decision Model and Notation)

DMN permet aux utilisateurs métier de modéliser des décisions exécutables en utilisant un langage graphique de haut niveau, normalisé OMG (Object Management Group), qui favorise l'interopérabilité et préserve leur investissement en évitant d’être liés à des fournisseurs.

Voici une sélection d’articles que nous avions consacré à DMN :

Les concepts de base :

• Quels sont les objectifs et les concepts de la notation de modélisation des règles métier, DMN Decision Model and Notation ?
  
• Et voici les concepts de bases pour bien comprendre la modélisation des règles métiers avec DMN ( Decision Model Notation )
  
• Apprenez le niveau logique de décision de la norme de modélisation de règles métiers DMN ( Decision Model Notation )
  
• Introduction au graphique DRG et au diagramme DRD d'exigences de décisions de la norme de modélisation de règles métiers DMN
  
• DMN - L'antisèche de la notation complète des composants d'un DRD ( Decision Requirement Diagram ) : notation de la décision

• DMN - L'antisèche de la notation complète des composants d'un DRD ( Decision Requirement Diagram ) : notation des règles de connexions

• La norme DMN ( Decision Model and Notation ) pour les tables de décision

Pour tout comprendre, voici un exemple complet montrant un processus métier modélisé avec BPMN et incluant des règles métiers modélisées avec DMN. 

Cet exemple va des modèles jusqu’à leur exécution :

1. Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : le processus métier BPMN
   
2. Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : La vue des exigences des décisions
   
3. Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : Le niveau logique de décision
   
4. Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : Exemple d'exécution du modèle de décisions
   
5. DMN ( Decision Model Notation ) : Ne serait-ce pas un langage de plus, une contrainte de plus imposée à la MOA par la MOE ?

Pour aller plus loin avec DMN, nous avions même consacré un tutorial archi complet sur comment concevoir un outil de modélisation DMN :

1. DMN ( Decision Model and Notation ) : comment concevoir son propre outil de modélisation DMN ? [1/4]
   
2. Le métamodèle Eclipse Ecore DMN ( Decision Model and Notation ) : comment concevoir son propre outil de modélisation DMN ? [2/4]
   
3. Tutorial Obeo Designer Community : comment concevoir son propre outil de modélisation DMN ? [3/4]
   
4. 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]

Et Drools donna vie à la norme DMN

L'équipe de Drools, le moteur BRMS open source de RedHat, standard de l’industrie, a activement suivi les spécifications DMN.

L’éditeur Red Hat estime que, conformément à son engagement de longue date envers les normes ouvertes, il est maintenant temps de soutenir la spécification DMN (V 1.1) et de fournir une implémentation conforme aux intérêts des utilisateurs.

Drools a un niveau le niveau conformité maximal (= 3) à la norme, il met en œuvre le langage FEEL (Friendly Enough Expression Language) pour par exemple les formules mathématiques, prend en charge complètement le format d'échange XML permettant de traduire les graphiques DMN en langage interprétable par une machine ainsi qu’une implémentation du métamodèle.

La mise en œuvre DMN exploite toute la plate-forme Drools (y compris, entre autres, le modèle de déploiement, l'infrastructure et l'outillage).

Les modèles DMN sont des citoyens de première classe dans la plate-forme et un atout supplémentaire pour Drools.

Drools DMN est intégré à jBPM BPMN dans la dernière version 7.

Partenariat entre l’éditeur Signavio et Red Hat : transformez vos diagramme DMN en code exécutable RedHat Drools

Modéliser les processus et les règles métiers avec les standards BPMN et DMN en utilisant les outils Signavio, puis en déployant ces modèles dans les moteurs jBPM et Drools pour l'exécution !

C'est un BPM de bout en bout : de la modélisation de processus avec Signavio à l'exécution avec Red Hat !

Pendant près d'une décennie, la conception de processus dans BPMN (Business Process Model Notation) a été une bonne pratique pour aligner les objectifs métiers et techniques.

Avec BPMN, l'analyste métier ou l'expert peut définir avec précision les interactions des clients, des systèmes et des partenaires métiers avec les activités et les événements qui les animent.

Avec le gestionnaire de processus Signavio, toutes les parties prenantes peuvent collaborer sur les modèles de processus.

L’outil peut exporter le diagramme dans un format XML que d'autres systèmes peuvent interpréter.

Signavio et Red Hat ont mis à profit cette capacité pour que les processus puissent être échangés.

La logique de décision peut être exportée depuis Signavio Process Manager et intégrée dans l'atelier KIE de RedHat.

Le travail d'équipe de Signavio et Red Hat est un exemple de la séparation parfaite des préoccupations entre l'entreprise et l'informatique.

Parce qu'il est conçu pour être facile à utiliser et collaboratif, le gestionnaire de processus Signavio est l'environnement idéal pour développer la vision d'un processus ou d'une décision.

De même, parce qu'il peut tirer parti de la puissance et de l'évolutivité de l'ensemble de la pile middleware Red Hat, la suite BPM est l'environnement idéal pour transformer ces décisions en une forme exécutable et les héberger.

Signavio vous permet de modéliser la logique de décision avec l'éditeur Signavio facile à utiliser et d'exporter ensuite les diagrammes DMN en fichiers DRL pour les transférer dans la solution de gestion des règles métier open source Drools.

Ainsi, vous pouvez facilement transférer des diagrammes DMN dans une logique métier automatisée.

Vous pouvez exporter plusieurs diagrammes, un diagramme ou une seule table de décision et ses sous-décisions.

L'exportation Signavio Drools prend en charge trois types d'exportation différents: Production, Développement et Test.

Contrairement à la production, le développement ajoute des commentaires et un comportement de journalisation supplémentaires.

De plus, vous pouvez sélectionner la dernière révision ou la révision publiée qui sera utilisée pour l'exportation.

Les autorisations pour l'exportation Drools peuvent être limitées aux utilisateurs de groupes d'utilisateurs spécifiques.

Pour exporter la logique de décision vers Drools, ouvrez le Signavio Explorer. sélectionnez un ou plusieurs diagrammes et allez dans Import / Export - Export Drools:

Exemple d'un modèle DMN avec son code généré :

Vous pouvez également exporter une table de décision et ses sous-décisions directement à partir de l'éditeur DMN Signavio.

Dans l'éditeur, ouvrez une table de décision et cliquez sur Importer / Exporter dans le coin supérieur droit de la boîte de dialogue.

Vous pouvez choisir entre générer l'exportation Drools ou les cas de test.

Et inversement ...

Pour être conforme à la norme MDA (Model DrivenArchitecture), les transformations doivent être bidirectionnelles.

L'outil Signavio permet à partir du code exécutable RedHat Drools conçu par les développeurs, de générer automatiquement les modèles DMN.

Pour être complet, voici d'autres outils

L’outil DecisionsFirst Modeler Enterprise Edition

Avec DecisionsFirst Modeler Enterprise Edition et l'intégration pour RedHat JBoss BRMS (Drools pour la version opensource), les modèles de décision basés sur la norme DMN peuvent être plus facilement intégrés aux règles métier gérées et déployées à l'aide de RedHat BRMS, améliorant ainsi la traçabilité.

DecisionsFirst Modeler est une solution de modélisation décisionnelle collaborative utilisant la norme DMN.

DecisionsFirst Modeler fournit une interface utilisateur conviviale et supporte les diagrammes DMN.

L'intégration de RedHat BRMS lie les modèles de décision graphique aux règles métier implémentées et gérées dans Drools, facilitant ainsi la définition partagée de l'implémentation par l'architecte et l’expert métier propriétaire de la règle.

Trisotech, la solution d’intégration de bout en bout

Drools / Red Hat - Trisotech DMN Modeler - Method & Style DT Analysis

Les règles métier sont modélisées par l'outil Trisotech DMN Modeler, puis analysées à l'aide du module Method & Style DT Analysis et exécutées dans le cloud à l'aide de BRMS de Drools / Red Hat.

Les processus métier modélisés en BPMN et les règles métiers en DMN sont nativement exécutées dans RedHat BPM !

Une belle illustration de l’Ingénierie Dirigées par les Modèles

Voici un brillant exemple de l’Ingénierie Dirigées par les Modèles (IDM ou MDE Model Driven Engineering ou bien encore MDA Model Driven Architecture la norme de l'OMG Object Management Group), qui repose sur la volonté de décrire précisément les besoins des clients par des CIM (Computational Independent Models) et la connaissance métier d’une organisation dans des modèles abstraits indépendants des plates-formes (PIM - Platform Independent Models).

Ayant isolé le savoir-faire métier dans des PIM, on a besoin soit de transformer ces modèles en d’autres PIM (besoin d’interopérabilité, migration vers un nouveau système, fusion de SI en cas d’acquisition d’une autre organisation, …), soit de produire ou de créer des modèles PSM (Platform Specific Models) ciblant une plate-forme d’exécution spécifique (pour améliorer la portabilité et augmenter la productivité) et ceci de manière bidirectionnelle.

Vous l’avez compris les modèles BPMN et DMN sont des PIM et jBPM et Drools sont des PSM.

• Transformation de modèles et Ingénierie Dirigées par les Modèles (IDM ou MDE Model Driven Engineering ou bien encore MDA Model Driven Architecture)

Dans l'article ci-après on posait la question : « Et pourquoi pas dériver le couple (BPMN, DMN) en modèle de code (PSM Platform Specific Model) d’un moteur de processus métier ou de règles métiers, par exemple le couple open source bien intégré (jBPM, Drools) ? »

• Pour trouver les services logiques, les modèles sémantiques et pragmatiques tu dériveras. (« Praxeme 4ème commandement extrait de la bible de l’aspect logique »).

Conclusion

Le jour est arrivé où les experts métier peuvent exprimer leurs processus et règles métiers sous forme de diagrammes normalisés en BPMN et DMN et directement les simuler, vérifier, exécuter et gérer leurs cycles de vie dans un référentiel.

Avec cette conversion de modèles métier (PIM) BPMN + DMN en code exécutable (PSM) jBPM + Drools, pour une fois une des principales préconisations des cadres d’architecture d’entreprise comme Praxeme ou TOGAF, concernant l’outillage pour les transformations des niveaux selon MDA est bien satisfaite.

Drools donne ainsi vie à la norme DMN, puisse d’autres outils de dérivation donner vie à l’automatisation des dérivations des autres aspects de l’architecture d’entreprise.

Rhona Maxwel

@rhona_helena

"La variété est la véritable épice de la vie, qui lui donne toute sa saveur."

William Cowper

Articles conseillés :

Comment concevoir une règle ? 

Les étapes d’un projet avec un moteur de règles

A quoi sert un moteur de règles ?

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.

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

Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : La vue des exigences des décisions

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]

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]

Avec la plate forme Obeo Designer Community ( open source ), nous avions intégré le métamodèle Ecore de DMN ( Domain Model and Notation ), puis à partir de celui-ci, nous avions instancié un modèle DMN ( Demande de prêt ). Nous avions le son mais pas encore l'image. Voici qui est chose faite, avec cet article qui montre comment construire un outil pouvant représenter visuellement un modèle DMN et tant qu'à faire en respectant la norme.

Le premier article rappelait les notions de métamétamodèle Ecore :

• DMN ( Decision Model and Notation ) : comment concevoir son propre outil de modélisation DMN ? [1/4]

Le précédent article décrivait l'intégration du métamodèle DMN avec Ecore en utilisant Obeo Designer Community et l'utilisation de l'outil pour créer un modèle Ecore DMN non visuel. Vous y trouverez à la fin en annexe le fichier source DMN Ecore de référence. 

• Le métamodèle Eclipse Ecore DMN ( Decision Model and Notation ) : comment concevoir son propre outil de modélisation DMN ? [2/4]

Le fichier source du modèle DMN de la demande de prêt se trouve en annexe à la fin de cet article.

Le plus compliqué dans cette histoire, ce n'est pas de comprendre ces histoires de métamétamodèle, ni d'assimiler la sémantique des concepts de DMN, non, le plus difficile c'est d'avoir les images des éléments de la notation au bon endroit et de gérer correctement leur affichage et d'éviter l'affichage d'autres icônes parasites qui seraient contraire à la norme.

Comme son nom l'indique, DMN est une notation, pour construire un outil de modélisation il faut se fabriquer les artefacts de modélisation.

Pour faire simple, répérer les 2 images ci-dessous, puis avec Paint, découper les éléments de notation en effaçant les libéllés à l'intérieur et sauvegarder chaque élément dans un fichier ( de type jpeg par ex. ) dans un répertoire icons.

Voici l'aspect du contenu des fichiers images représentant les principaux éléments de modélisation DMN :

Pour lier ces fichiers aux différents éléments de modélisation DMN dans Obeo Designer, il faut les inclure dans un jar ( une blibliothèque Java archive ) accesible de l'Ouil. 

Par exemple dans le répertoire d'installation :

• ObeoDesigner-Community\plugins

Ouvrir avec WinZip ou WinRAR ou ... le fichier :

• org.eclipse.sirius.samples.family_4.1.1.201610251427.jar

Une fois l'archive ouverte, aller dans le répertoire :

• samples\org.eclipse.sirius.sample.basicfamily.edit\icons\full\obj16

Ajouter à cet endroit le contenu du répertoire icons avec vos fichiers représentant les éléments DMN.

Reprendre l'article précédent, exécuter Obeo Designer, ouvrit le projet Ecore Modeling, nommé com.urbanisationSI.dmn.dmnEcore.

Dans model - double clic sur dmnEcore.genmodel - dans la vue Properties, mettre Creation Icons à false

Double cliquer sur le diagramme dmnEcore situé sous le package DMN du fichier dmnEcore.ecore

Clic droit - Generate All

Mauvaise nouvelle, le plugin com.urbanisationSI.dmn.dmnEcore.edit généré et qui est l'éditeur pour générer des objets DMN ( des décisions, ... ), contient des icônes par défaut représentant les classes DMN et qui vont s'afficher en plus de nos images personnalisées.

La bonne nouvelle, c'est qu'on peut les neutraliser en reprenant les fichiers gif avec Paint ( qui se révèle ici être l'outil primordial ) et en remplaçant le contenu par un petit rectangle blanc ( sinon mettre une texture transparente mais on s'égare du sujet ).

Dans le répertoire ...\com.urbanisationSI.dmn.dmnEcore.edit\icons\full\obj16, modifier les icônes, voici le résultat :

Exécuter le plugin : sélectionner com.urbanisationSI.dmn.dmnEcore.edit - clic droit - Run As - Run Configuration - Eclipse Application - clic droit - New - nommer la configuration par ex. DMN Ecore edit et à condition d'être en Java 8, laisser toutes les options par défaut - Apply - Run

Nous avions traité le mode opératoire d'Obeo Designer dans les 3 articles suivants ( repris du reste sur le site d'Obeo ) :

1. Ingénierie Dirigée par les Modèles : fini Eclipse GMF, vive Eclipse Sirius ( didacticiel / tutoriel Sirius)
     
2. Didacticiel ( tutoriel ) Eclipse Sirius ( Obeo Designer Community ) : le digne successeur de GMF le framework le plus complexe du monde !
    
3. Didacticiel ( tutoriel ) Eclipse Sirius ( Obeo Designer Community ) : on peaufine l'éditeur de diagramme
    

Un nouveau runtime d'Obeo Designer se lance.

Nous allons créer un nouveau modeling project et utiliser le wizard pour créer des objets DMN. 

• Dans la nouvelle fenêtre "runtime-DMNEcoreedit - Modeling - Obeo Designer Community", fermer l'onglet "Welcome"
• File - New - Modeling Project - Name =  com.urbanisationSI.dmn.dmnEcore.demandeDePret - Finish
• Cliquer sur le projet créé - clic droit - New - Other - dans la fenêtre Wizard, ouvrir "Example EMF Model Creation Wizards" - cliquer "DmnEcore Model" - Next - File Name = demandeDePret.dmnecore - Next - Model Object = sélectionner dans la liste "Definitions" qui correspond à un conteneur de haut niveau dans le métamodèle DMN et qui permet de créer à l'intérieur des "Decision", "BusinessKnowledgeModel", "InputDate", "KnowledgeSource", ... - Finish

Et c'est où les athéniens atteignirent, sous le fichier demandeDePret.dmnecore, la racine Definitions ne doit pas avoir d'icône :

Après ces longues et fastidieuses tâches pas très passionnantes, nous arrivons enfin au véritable objectif de cet article, nous allons utiliser le plugin Sirius pour créer des outils graphiques. 

Pour cela il faut passer en perspective Sirius ( le plugin opensource intégré dans Obeo Designer ).

• File - New - Viewpoint Specification Project - name = DMN.project.design - Next - Viewpoint Specification Model name = DMN.odesign - Finish
• Dans le projet DMN.project.design - description - double clic DMN.odesign - onglet DMN.odesign - MyViewpoint - Properties - Id = DMNViewpoint

Créer un diagramme : clic droit sur DMNViewpoint - New Represantation - Diagram Description - Properties :

• Onglet General - Id = DMNDiagram
• Onglet Metamodels - Add from filesystem - sélectionner le répertoire ou vous avez mis bien au chaud le fichier contenant le métamodèle Ecore ( par ex. DMN.ecore ) 
• Onglet General - Domain Class = saisir le package du métamodèle DMN c'est à dire DMN, taper le point, puis CTRL espace pour avoir l'auto completion, sélectionner dans la liste Definitions
• Penser à sauvegarder de temps en temps.

Aouter le premier élément de modélisation dans le diagramme :

• Clic droit sur Default - New Diagram Element - Node
• Properties - Onglet General - Id = DecisionNode - Domain Class = DMN.Decision

Affecter l'icône fruit de votre harassant labeur précédent :

• Clic droit sur DecisionNode - New Styme - Workspace Image
• Properties - Image Path - clic sur  ... - Dans Plugins ( souvenez-vous, on a mis les fichiers images des éléments DMN dans l'archive du plugin org.eclipse.sirius.sample.family ), sélectionner :

Pour utiliser ce début de diagramme dans notre projet com.urbanisationSI.dmn.dmnEcore.demandeDePret :

• Clic droit sur le projet - Viewpoints Selection - sélectionner DMNViewpoint
• Dans demandeDePret.dmnecore - Sélectionner Definitions - clic droit - New Representation - New DMNDiagram - demandeDePretDMNDiagram
• Pour ouvrir le diagramme - double clic sur demandeDePretDMNDiagram sous Definitions
• Un nouvel onglet s'ouvre vide. Eh oui, dans notre monde proche il n'y pas de génération spontanée d'objets.
• Mais on se décarcasse, on a mis en annexe à la fin de cette article le fichier XMI correspondant au modéle Ecore de notre demande de prêt et en copiant son contenu dans demandeDePret.dmnecore on aura nos objets et leurs relations.
• Sélectionner demandeDePret.dmnecore - clic droit - Open With - Test Editor - remplacer le contenu par celui de l'annexe.
• Miracle revenez dans l'onglet du diagramme demandeDePretDMNDiagram, les objets de type  Decision sont bien la, ils sont juste tous superposés, vous pouvez les réarranger en les déplaçant à la souris.

Et voilà le boulot, c'est propre et de bon goût :

De la même manière, créer les autres node :

• BusinessKnowledgeModelNode de type DMN.BusinessKnowledgeModel, n'oubliez pas d'affecter l'image. Vous devez voir apparaître les objets : BureauCallType et EligibilityRules
• InputDataNode de type DMN.InputData, n'oubliez pas d'affecter l'image. Attention, quelque fois les images apparraissent petites, il faut les chercher dans le coin supérieur gauche et les agrandir ( cela peut se régler dans les propriétés ). Vous devez voir apparaître les objets : ApplicantData et RequestedProduct 
• KnowledgeSourceNode de type DMN.KnowledgeSource, n'oubliez pas d'affecter l'image. Vous devez voir apparaître les objets : RiskManager et ProductSpecification

Voici le résultat :

Juste pour terminer, ajoutons les InformationRequirement, relations entre des décisions ou entre des InputDate et des décisions :

Comme précédemment :

• InformationRequirementNode de type DMN.InformationRequirement, n'oubliez pas d'affecter l'image.
• Cliquer sur la flèche, vérifier dans Properties les objets liés et déplacer la flèche de manière à relier les objets correspondant. Bon je sais ce n'est pas très optimisé, mais cela ira pour un début.

Par exemple : 

Voici donc une première partie de notre modèle DMN de demande de prêt :

Evidemment, le résultat est assez rudimentaire, il souffre de pas mal de lacunes, mais il nous a permis de comprendre le fonctionnement du plugin Sirius embarqué dans Obeo Designer Community.

La documentation est très bien faite, il vous reste encore à faire un petit effort pour la parcourir et étudier notamment le plugin Acceleo avec son langage AQL ( Acceleo Query Language ). 

Dans cet article, on a, pour simplifier et à des fins pédagogiques, implémenté les relations par des objets avec leurs images associées représentant des flèches.

C'est un bon début mais pas viable, la bonne solution se trouve dans l'article complet suivant :

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]

Rhona Maxwel

@rhona_helena

"La meilleure manière d'atteindre le bonheur est de le donner aux autres."

Robert Baden-Powell

Articles conseillés :

Didacticiel ( tutoriel ) Eclipse Sirius ( Obeo Designer Community ) : le digne successeur de GMF le framework le plus complexe du monde ! 

Didacticiel ( tutoriel ) Eclipse Sirius ( Obeo Designer Community ) : on peaufine l'éditeur de diagramme 

<?xml version="1.0" encoding="UTF-8"?>
<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>
<drgElement xsi:type="DMN:Decision" name="Eligibility" requiresInformation="//@drgElement.0/@informationRequirement.1">
<informationRequirement requiredDecision="//@drgElement.9"/>
<knowledgeRequirement requiredKnowledge="//@drgElement.4"/>
</drgElement>
<drgElement xsi:type="DMN:BusinessKnowledgeModel" name="BureauCallTypeTable" requiresKnowledge="//@drgElement.1/@knowledgeRequirement.0">
<authorityRequirement requiredAuthority="//@drgElement.5"/>
</drgElement>
<drgElement xsi:type="DMN:BusinessKnowledgeModel" name="EligibilityRules" requiresKnowledge="//@drgElement.2/@knowledgeRequirement.0">
<authorityRequirement requiredAuthority="//@drgElement.6"/>
</drgElement>
<drgElement xsi:type="DMN:KnowledgeSource" name="RiskManager" requiresAuthority="//@drgElement.3/@authorityRequirement.0"/>
<drgElement xsi:type="DMN:KnowledgeSource" name="ProductSpecification" requiresAuthority="//@drgElement.4/@authorityRequirement.0"/>
<drgElement xsi:type="DMN:InputData" name="ApplicantData" requiresInformation="//@drgElement.9/@informationRequirement.0"/>
<drgElement xsi:type="DMN:InputData" name="RequestedProduct" requiresInformation="//@drgElement.10/@informationRequirement.0"/>
<drgElement xsi:type="DMN:Decision" name="PreBureauAffordability" requiresInformation="//@drgElement.2/@informationRequirement.0">
<informationRequirement requiredInput="//@drgElement.7"/>
<informationRequirement requiredDecision="//@drgElement.10"/>
</drgElement>
<drgElement xsi:type="DMN:Decision" name="RequiredMonthlyInstallment" requiresInformation="//@drgElement.9/@informationRequirement.1">
<informationRequirement requiredInput="//@drgElement.8"/>
</drgElement>
</DMN:Definitions>

Pour créer un outil de modélisation pour un langage de modélisation, il faut son métamodèle qui n'est plus ni moins qu'un diagramme de classe UML décrivant les éléments de la notation.

Si vous avez manqué le début :

DMN ( Decision Model and Notation ) : comment concevoir son propre outil de modélisation DMN ? [1/4]

L'outil ( méta outil ? ) servant à créer l'outil de modélisation DMN est Obeo Designer Community. Il s'agit d'une plateforme Eclipse intégrant toute une flopée de plugins parmi lesquels Sirius, Eclipse Modeling Project, Acceleo, …

Le métamodèle est un diagramme de classe UML qui doit lui aussi ( heureusement il s'auto décrit ) être spécifié par un métamétamodéle représentant les concepts de base comme une classe, un attribut, une relation, …

Nous allons utiliser EMF Ecore ( Eclipse Modeling Framework ) qui est le standard de l'industrie par opposition à celui de la norme de l'OMG ( MOF Meta Object Facility ) encore pauvre en terme d'implémentations.

Si des choses vous ont échappées dans ce qui précède, pas de panique, nous avons consacré une série d'articles pédagogiques à ces sujets.

Articles sur IDM ( Ingénierie Dirigée par les Modèles ) :

1. Les recherches en urbanisation du Système d'Information : le Model-Driven Engineering (MDE) encore un acronyme à la mode ?
    
2. Model-Driven Engineering (MDE) : modèles, métamodèles, métamétamodèles, méta... ?
    
3. Ingénierie Dirigée par les Modèles (IDM) : un exemple vaut mieux qu'un long discours
    

Articles sur Eclipse Ecore :
 

1. Ingénierie Dirigée par les Modèles (IDM) : tutoriel ATL (ATLAS Transformation Language), concevez les métamodèles avant de passer aux choses sérieuses
    
2. Eclipse Modeling Framework (EMF) : revoyons les fondamentaux
    
3. Ingénierie Dirigée par les Modèles (IDM) : tutoriel Eclipse Ecore, le corps à corps avec les méta modèles
    

Articles sur l'installation de Obeo Designer Community ( Sirius ) :
 

• Ingénierie Dirigée par les Modèles : fini Eclipse GMF, vive Eclipse Sirius ( didacticiel / tutoriel Sirius)
   

1)

Une fois Obeo Designer Community installé, sélectionner la perspective "Modeling", puis créer un  "Ecore Modeling Project" 

File - New - Ecore Modeling Project - nommer le projet, par ex. : com.urbanisationSI.dmn.dmnEcore - Finish

2)

Copier le contenu du fichier Ecore en annexe à la fin de cet article dans le fichier "dmnEcore.ecore"

Dérouler le projet - model - clic droit sur dmnEcore.ecore - Open with - Text Editor - remplacer la totalité du contenu par celui de l'annexe - Sauvegarder CTRL S

Un nouveau package DMN apparaît sous le fichier ecore avec tous les éléments du métamodèle DMN.

3)

Pour avoir le diagramme, sous le package DMN, double cliquer le diagramme dmnEcore, l'onglet indique "Double click to initialize" - double cliquer - le diagramme complet apparaît.

4)

Un certain effort est à fournir pour réarranger et organiser le diagramme.

La bonne nouvelle : Obeo Designer Community offre dans le coin supérieur gauche du diagramme des stratégies d'arrangement : "Arrange All, ..."

Vous pouvez aussi tout sélectionner : "Select All" puis "Arrange Selection" et/ou "Align Left, Right, ..." et/ou "Distribute Gaps Horizontally, Center, ..."

La mauvaise nouvelle : malgré tout cela, vous devrez manuellement réorganiser le diagramme si vous désirez qu'il soit lisible.

Rassurez-vous ce travail fastidieux de réarrangement du diagramme n'est pas nécessaire pour la conception de notre outil de modélisation DMN.

5)

Pour tester la création d'instances de "Decision" et autres éléments du métamodèle DMN, nous devons créer le plugin de l'éditeur Ecore :

Clic droit dans le diagramme dmnEcore - Generate - All

3 plugins sont générés, cliquer sur com.urbanisationSI.dmn.dmnEcore.edit - clic droit - Run As - Run Configuration - cliquer Eclipse Application - clic droit - New - Name = DMN Ecore - Apply - Run - éventuellement sauvegarder ce qui doit l'être - puis une nouvelle instance d'Obeo Designer se lance.

6)

Dans la nouvelle fenêtre "runtime-DMNEcore - Modeling - Obeo Designer Community", fermer l'onglet "Welcome"

File - New - Modeling Project - Name =  com.urbanisationSI.dmn.dmnEcore.demandeDePret - Finish

Cliquer sur le projet créé - clic droit - New - Other - dans la fenêtre Wizard, ouvrir "Example EMF Model Creation Wizards" - cliquer "DmnEcore Model" - Next - File Name = demandeDePret.dmnecore - Next - Model Object = sélectionner dans la liste "Definitions" qui correspond à un conteneur de haut niveau dans le métamodèle DMN et qui permet de créer à l'intérieur des "Decision", "BusinessKnowledgeModel", "InputDate", "KnowledgeSource", ...

7)

Sous le projet, clic droit sur "demandeDePret.dmnecore" - Open with - DmnEcore Model Editor -  Dans le nouvel onglet ouvert, déployer et sélectionner la racine "Definitions"

Clic droit - Nex Child - Decision

Nous allons suivre l'exemple complet de DMN de l'article :

• Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : La vue des exigences des décisions
   

Dans la vue Properties, Name = Strategy 

De la même manière, créer par exemple,  d'autres objet de type Decision : BureauCallType, Eligibility, PreBureauAffordability, RequiredMonthlyInstallment

Créer des objets de type BusinessKnowledgeModel : BureauCallTypeTable, EligibilityRules, ...

Créer des objets de type KnowledgeSource : RiskManager, ProductSpecification

Créer des objets de type InputData : ApplicantData, RequestedProduct

8) 

Pour créer les relations, par exemple de type "InformationRequirement" entre Decision -> Decision ou InputData -> Decision, sélectionner Decision Strategy - clic droit - New Child - sélectionner InformationRequirement

Cliquer sur InformationRequirement créé - dans la vue Properties - Required Decision = sélectionner dans la liste Decision BureauCallType

Répéter pour créer un autre InformationRequirement lié à Decision Eligibility

De la même manière créer les relations de type KnowledgeRequirement entre BusinessKnowledgeModel -> Decision

Clic droit sur Decision BureauCallType - KnowledgeRequirement - dans Properties, Required Knowledge = Business Knowledge Model BureauCallTypeTable

Idem pour Decision Eligibility, Required Knowledge = Business Knowledge Model EligibilityRules

Idem pour les relations de type AuthorityRequirement, entre :

Knowledge Source RiskManager -> Business Knowledge Model BureauCallTypeTable

Knowledge Source ProductSpecification -> Business Knowledge Model EligibilityRules

Idem pour les relations de type "InformationRequirement" entre :

Input Data ApplicantData  -> Decision PreBureauAffordability

Input Data RequestedProduct-> Decision RequiredMonthlyInstallment

Voici le résultat en guise de conclusion de cette étape :

Le prochain article s'intéresse ce à quoi Obeo Designer Community est fait c'est à dire à la création des artefacts visuels et aux règles de modélisation avec DMN et on aura ainsi notre outil DMN. 

Pour voir la suite :

Tutorial Obeo Designer Community : comment concevoir son propre outil de modélisation DMN ? [3/4]

Rhona Maxwel

@rhona_helena

"La patience est un arbre dont la racine est amère et les fruits très doux."

Proverbe persan

Articles conseillés :

Didacticiel ( tutoriel ) Eclipse Sirius ( Obeo Designer Community ) : le digne successeur de GMF le framework le plus complexe du monde !

Didacticiel ( tutoriel ) Eclipse Sirius ( Obeo Designer Community ) : on peaufine l'éditeur de diagramme

<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="DMN" nsURI="http://www.omg.org/spec/DMN/20130901" nsPrefix="DMN">
<eAnnotations source="http://www.eclipse.org/emf/2002/GenModel">
<details key="documentation" value="Author:csma.&#xA;Created:8/4/13 9:11 PM.&#xA;Title:.&#xA;Comment:.&#xA;"/>
</eAnnotations>
<eClassifiers xsi:type="ecore:EClass" name="AuthorityRequirement">
<eStructuralFeatures xsi:type="ecore:EReference" name="requiredAuthority" ordered="false"
eType="#//KnowledgeSource" eOpposite="#//KnowledgeSource/requiresAuthority"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="requiredInput" ordered="false"
eType="#//InputData" eOpposite="#//InputData/requiresAuthority"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="decision" ordered="false"
eType="#//Decision" eOpposite="#//Decision/authorityRequirement"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="bkm" ordered="false" eType="#//BusinessKnowledgeModel"
eOpposite="#//BusinessKnowledgeModel/authorityRequirement"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="requiredDecision" ordered="false"
eType="#//Decision" eOpposite="#//Decision/requiresAuthority"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="knowledgeSource" ordered="false"
eType="#//KnowledgeSource" eOpposite="#//KnowledgeSource/authorityRequirement"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="KnowledgeSource" eSuperTypes="#//DRGElement">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="type" ordered="false" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="owner" ordered="false"
eType="#//OrganisationalUnit"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="authorityRequirement" ordered="false"
upperBound="-1" eType="#//AuthorityRequirement" containment="true" eOpposite="#//AuthorityRequirement/knowledgeSource"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="locationURI" ordered="false"
eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="requiresAuthority" ordered="false"
upperBound="-1" eType="#//AuthorityRequirement" eOpposite="#//AuthorityRequirement/requiredAuthority"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="DRGElement" abstract="true" eSuperTypes="#//DMNElement">
<eStructuralFeatures xsi:type="ecore:EReference" name="definitions" ordered="false"
lowerBound="1" eType="#//Definitions" eOpposite="#//Definitions/drgElement"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="elementCollection" ordered="false"
upperBound="-1" eType="#//ElementCollection" eOpposite="#//ElementCollection/drgElement"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="DMNElement" abstract="true">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="id" ordered="false" lowerBound="1"
eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="name" ordered="false" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="description" ordered="false"
eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Definitions" eSuperTypes="#//DMNElement">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="namespace" ordered="false"
lowerBound="1" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="expressionLanguage" ordered="false"
eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="typeLanguage" ordered="false"
eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="import" ordered="false"
upperBound="-1" eType="#//Import" containment="true" eOpposite="#//Import/_"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="itemDefinition" ordered="false"
upperBound="-1" eType="#//ItemDefinition" containment="true" eOpposite="#//ItemDefinition/definitions"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="businessContextElement"
ordered="false" upperBound="-1" eType="#//BusinessContextElement" containment="true"
eOpposite="#//BusinessContextElement/definitions"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="collection" ordered="false"
upperBound="-1" eType="#//ElementCollection" containment="true" eOpposite="#//ElementCollection/definitions"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="drgElement" ordered="false"
upperBound="-1" eType="#//DRGElement" containment="true" eOpposite="#//DRGElement/definitions"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Import">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="importType" ordered="false"
lowerBound="1" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="locationURI" ordered="false"
eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="namespace" ordered="false"
lowerBound="1" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="literalExpression" ordered="false"
eType="#//LiteralExpression" eOpposite="#//LiteralExpression/import"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="_" ordered="false" eType="#//Definitions"
eOpposite="#//Definitions/import"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="LiteralExpression" eSuperTypes="#//Expression">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="expressionLanguage" ordered="false"
eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="text" ordered="false" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="import" ordered="false"
eType="#//Import" containment="true" eOpposite="#//Import/literalExpression"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Expression" abstract="true" eSuperTypes="#//DMNElement">
<eStructuralFeatures xsi:type="ecore:EReference" name="inputVariable" ordered="false"
upperBound="-1" eType="#//InformationItem" eOpposite="#//InformationItem/expression"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="informationItem" ordered="false"
upperBound="-1" eType="#//InformationItem" volatile="true" transient="true"
derived="true" eOpposite="#//InformationItem/valueExpression"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="allowedInItemDefinition"
ordered="false" eType="#//ItemDefinition" eOpposite="#//ItemDefinition/allowedValue"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="inputExpressionClause"
ordered="false" eType="#//Clause" eOpposite="#//Clause/inputExpression"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="inputClause" ordered="false"
eType="#//Clause" eOpposite="#//Clause/inputEntry"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="outputClause" ordered="false"
eType="#//Clause" eOpposite="#//Clause/outputEntry"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="concludedRule" ordered="false"
upperBound="-1" eType="#//DecisionRule" eOpposite="#//DecisionRule/conclusion"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="conditionedRule" ordered="false"
upperBound="-1" eType="#//DecisionRule" eOpposite="#//DecisionRule/condition"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="itemDefinition" ordered="false"
eType="#//ItemDefinition" eOpposite="#//ItemDefinition/expression"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="decision" ordered="false"
eType="#//Decision" eOpposite="#//Decision/decisionLogic"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="bkm" ordered="false" eType="#//BusinessKnowledgeModel"
eOpposite="#//BusinessKnowledgeModel/body"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="formulaBinding" ordered="false"
eType="#//Binding" eOpposite="#//Binding/bindingFormula"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="invocation" ordered="false"
upperBound="-1" eType="#//Invocation" volatile="true" transient="true" derived="true"
eOpposite="#//Invocation/calledFunction"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="contextEntry" ordered="false"
eType="#//ContextEntry" eOpposite="#//ContextEntry/value"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="functionDefinition" ordered="false"
eType="#//FunctionDefinition" eOpposite="#//FunctionDefinition/body"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="list" ordered="false" eType="#//List"
eOpposite="#//List/element"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="InformationItem" eSuperTypes="#//DMNElement">
<eStructuralFeatures xsi:type="ecore:EReference" name="valueExpression" ordered="false"
eType="#//Expression" volatile="true" transient="true" derived="true" eOpposite="#//Expression/informationItem"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="informationRequirement"
ordered="false" eType="#//InformationRequirement" eOpposite="#//InformationRequirement/variable"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="itemDefinition" ordered="false"
eType="#//ItemDefinition" eOpposite="#//ItemDefinition/informationItem"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="bkm" ordered="false" eType="#//BusinessKnowledgeModel"
eOpposite="#//BusinessKnowledgeModel/parameter"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="binding" ordered="false"
upperBound="-1" eType="#//Binding" eOpposite="#//Binding/parameter"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="contextEntry" ordered="false"
eType="#//ContextEntry" eOpposite="#//ContextEntry/variable"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="functionDefinition" ordered="false"
eType="#//FunctionDefinition" eOpposite="#//FunctionDefinition/formalParameter"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="relation" ordered="false"
eType="#//Relation" eOpposite="#//Relation/column"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="expression" ordered="false"
eType="#//Expression" eOpposite="#//Expression/inputVariable"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="InformationRequirement">
<eStructuralFeatures xsi:type="ecore:EReference" name="requiredInput" ordered="false"
eType="#//InputData" eOpposite="#//InputData/requiresInformation"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="requiredDecision" ordered="false"
eType="#//Decision" eOpposite="#//Decision/requiresInformation"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="decision" ordered="false"
lowerBound="1" eType="#//Decision" eOpposite="#//Decision/informationRequirement"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="variable" ordered="false"
lowerBound="1" eType="#//InformationItem" containment="true" eOpposite="#//InformationItem/informationRequirement"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="InputData" eSuperTypes="#//DRGElement">
<eStructuralFeatures xsi:type="ecore:EReference" name="itemDefinition" ordered="false"
eType="#//ItemDefinition" eOpposite="#//ItemDefinition/inputData"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="requiresAuthority" ordered="false"
upperBound="-1" eType="#//AuthorityRequirement" eOpposite="#//AuthorityRequirement/requiredInput"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="requiresInformation" ordered="false"
upperBound="-1" eType="#//InformationRequirement" eOpposite="#//InformationRequirement/requiredInput"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="ItemDefinition" eSuperTypes="#//DMNElement">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="typeDefinition" ordered="false"
eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="typeLanguage" ordered="false"
eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="isCollection" ordered="false"
lowerBound="1" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EBoolean" defaultValueLiteral="false"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="allowedValue" ordered="false"
upperBound="-1" eType="#//Expression" containment="true" eOpposite="#//Expression/allowedInItemDefinition"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="typeRef" ordered="false"
eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="itemComponentRef" ordered="false"
upperBound="-1" eType="#//ItemDefinition" eOpposite="#//ItemDefinition/itemDefinition"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="itemDefinition" ordered="false"
upperBound="-1" eType="#//ItemDefinition" eOpposite="#//ItemDefinition/itemComponentRef"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="clause" ordered="false"
upperBound="-1" eType="#//Clause" eOpposite="#//Clause/outputDefinition"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="definitions" ordered="false"
lowerBound="1" eType="#//Definitions" eOpposite="#//Definitions/itemDefinition"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="expression" ordered="false"
upperBound="-1" eType="#//Expression" eOpposite="#//Expression/itemDefinition"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="informationItem" ordered="false"
upperBound="-1" eType="#//InformationItem" eOpposite="#//InformationItem/itemDefinition"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="inputData" ordered="false"
upperBound="-1" eType="#//InputData" eOpposite="#//InputData/itemDefinition"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Clause">
<eStructuralFeatures xsi:type="ecore:EReference" name="inputExpression" ordered="false"
eType="#//Expression" containment="true" eOpposite="#//Expression/inputExpressionClause"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="inputEntry" ordered="false"
lowerBound="1" upperBound="-1" eType="#//Expression" containment="true" eOpposite="#//Expression/inputClause"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="outputEntry" lowerBound="1"
upperBound="-1" eType="#//Expression" containment="true" eOpposite="#//Expression/outputClause"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="name" ordered="false" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="decisionTable" ordered="false"
lowerBound="1" eType="#//DecisionTable" eOpposite="#//DecisionTable/clause"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="outputDefinition" ordered="false"
eType="#//ItemDefinition" eOpposite="#//ItemDefinition/clause"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="DecisionTable" eSuperTypes="#//Expression">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="hitPolicy" ordered="false"
lowerBound="1" eType="#//HitPolicy" defaultValueLiteral="UNIQUE"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="rule" upperBound="-1" eType="#//DecisionRule"
containment="true" eOpposite="#//DecisionRule/decisionTable"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="aggregation" ordered="false"
lowerBound="1" eType="#//BuiltinAggregator"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="preferedOrientation" ordered="false"
eType="#//DecisionTableOrientation"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="isComplete" ordered="false"
eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EBoolean" defaultValueLiteral="false"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="isConsistent" ordered="false"
eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EBoolean" defaultValueLiteral="false"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="clause" ordered="false"
upperBound="-1" eType="#//Clause" containment="true" eOpposite="#//Clause/decisionTable"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EEnum" name="HitPolicy">
<eLiterals name="UNIQUE"/>
<eLiterals name="FIRST" value="1"/>
<eLiterals name="PRIORITY" value="2"/>
<eLiterals name="ANY" value="3"/>
<eLiterals name="UNORDERED" value="4"/>
<eLiterals name="RULEORDER" value="5"/>
<eLiterals name="OUTPUTORDER" value="6"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="DecisionRule">
<eStructuralFeatures xsi:type="ecore:EReference" name="conclusion" ordered="false"
lowerBound="1" upperBound="-1" eType="#//Expression" eOpposite="#//Expression/concludedRule"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="condition" ordered="false"
upperBound="-1" eType="#//Expression" eOpposite="#//Expression/conditionedRule"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="decisionTable" ordered="false"
lowerBound="1" eType="#//DecisionTable" eOpposite="#//DecisionTable/rule"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EEnum" name="DecisionTableOrientation">
<eLiterals name="RuleasRow"/>
<eLiterals name="RuleasColumn" value="1"/>
<eLiterals name="CrossTable" value="2"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Decision" eSuperTypes="#//DRGElement">
<eStructuralFeatures xsi:type="ecore:EReference" name="decisionLogic" ordered="false"
eType="#//Expression" containment="true" eOpposite="#//Expression/decision"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="decisionMaker" ordered="false"
upperBound="-1" eType="#//OrganisationalUnit" eOpposite="#//OrganisationalUnit/decisionMade"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="decisionOwner" ordered="false"
upperBound="-1" eType="#//OrganisationalUnit" eOpposite="#//OrganisationalUnit/decisionOwned"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="impactedPerformanceIndicator"
ordered="false" upperBound="-1" eType="#//PerformanceIndicator" eOpposite="#//PerformanceIndicator/impactingDecision"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="question" ordered="false"
eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="allowedAnswers" ordered="false"
eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="authorityRequirement" ordered="false"
upperBound="-1" eType="#//AuthorityRequirement" containment="true" eOpposite="#//AuthorityRequirement/decision"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="informationRequirement"
ordered="false" upperBound="-1" eType="#//InformationRequirement" containment="true"
eOpposite="#//InformationRequirement/decision"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="knowledgeRequirement" ordered="false"
upperBound="-1" eType="#//KnowledgeRequirement" containment="true" eOpposite="#//KnowledgeRequirement/decision"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="requiresAuthority" ordered="false"
upperBound="-1" eType="#//AuthorityRequirement" eOpposite="#//AuthorityRequirement/requiredDecision"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="supportedObjective" ordered="false"
upperBound="-1" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="requiresInformation" ordered="false"
upperBound="-1" eType="#//InformationRequirement" eOpposite="#//InformationRequirement/requiredDecision"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="OrganisationalUnit" eSuperTypes="#//BusinessContextElement">
<eStructuralFeatures xsi:type="ecore:EReference" name="decisionOwned" ordered="false"
upperBound="-1" eType="#//Decision" eOpposite="#//Decision/decisionOwner"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="decisionMade" ordered="false"
upperBound="-1" eType="#//Decision" eOpposite="#//Decision/decisionMaker"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="BusinessContextElement" abstract="true"
eSuperTypes="#//DMNElement">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="URI" ordered="false" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="definitions" ordered="false"
lowerBound="1" eType="#//Definitions" eOpposite="#//Definitions/businessContextElement"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="PerformanceIndicator" eSuperTypes="#//BusinessContextElement">
<eStructuralFeatures xsi:type="ecore:EReference" name="impactingDecision" ordered="false"
upperBound="-1" eType="#//Decision" eOpposite="#//Decision/impactedPerformanceIndicator"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="KnowledgeRequirement">
<eStructuralFeatures xsi:type="ecore:EReference" name="requiredKnowledge" ordered="false"
lowerBound="1" eType="#//BusinessKnowledgeModel" eOpposite="#//BusinessKnowledgeModel/requiresKnowledge"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="bkm" ordered="false" eType="#//BusinessKnowledgeModel"
eOpposite="#//BusinessKnowledgeModel/knowledgeRequirement"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="decision" ordered="false"
eType="#//Decision" eOpposite="#//Decision/knowledgeRequirement"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="BusinessKnowledgeModel" eSuperTypes="#//DRGElement">
<eStructuralFeatures xsi:type="ecore:EReference" name="authorityRequirement" ordered="false"
upperBound="-1" eType="#//AuthorityRequirement" containment="true" eOpposite="#//AuthorityRequirement/bkm"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="body" ordered="false" eType="#//Expression"
containment="true" eOpposite="#//Expression/bkm"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="knowledgeRequirement" ordered="false"
upperBound="-1" eType="#//KnowledgeRequirement" containment="true" eOpposite="#//KnowledgeRequirement/bkm"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="parameter" ordered="false"
upperBound="-1" eType="#//InformationItem" containment="true" eOpposite="#//InformationItem/bkm"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="requiresKnowledge" ordered="false"
upperBound="-1" eType="#//KnowledgeRequirement" eOpposite="#//KnowledgeRequirement/requiredKnowledge"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Binding">
<eStructuralFeatures xsi:type="ecore:EReference" name="bindingFormula" ordered="false"
eType="#//Expression" containment="true" eOpposite="#//Expression/formulaBinding"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="invocation" ordered="false"
lowerBound="1" eType="#//Invocation" eOpposite="#//Invocation/binding"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="parameter" ordered="false"
lowerBound="1" eType="#//InformationItem" eOpposite="#//InformationItem/binding"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Invocation" eSuperTypes="#//Expression">
<eStructuralFeatures xsi:type="ecore:EReference" name="calledFunction" ordered="false"
lowerBound="1" eType="#//Expression" volatile="true" transient="true" derived="true"
eOpposite="#//Expression/invocation"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="binding" ordered="false"
upperBound="-1" eType="#//Binding" containment="true" eOpposite="#//Binding/invocation"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="ContextEntry">
<eStructuralFeatures xsi:type="ecore:EReference" name="value" ordered="false"
lowerBound="1" eType="#//Expression" containment="true" eOpposite="#//Expression/contextEntry"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="context" ordered="false"
eType="#//Context" eOpposite="#//Context/contextEnrty"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="variable" ordered="false"
eType="#//InformationItem" containment="true" eOpposite="#//InformationItem/contextEntry"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Context" eSuperTypes="#//Expression">
<eStructuralFeatures xsi:type="ecore:EReference" name="contextEnrty" ordered="false"
upperBound="-1" eType="#//ContextEntry" containment="true" eOpposite="#//ContextEntry/context"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="FunctionDefinition" eSuperTypes="#//Expression">
<eStructuralFeatures xsi:type="ecore:EReference" name="body" ordered="false" eType="#//Expression"
containment="true" eOpposite="#//Expression/functionDefinition"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="formalParameter" ordered="false"
upperBound="-1" eType="#//InformationItem" containment="true" eOpposite="#//InformationItem/functionDefinition"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Relation" eSuperTypes="#//Expression">
<eStructuralFeatures xsi:type="ecore:EReference" name="row" ordered="false" upperBound="-1"
eType="#//List" containment="true" eOpposite="#//List/relation"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="column" ordered="false"
upperBound="-1" eType="#//InformationItem" containment="true" eOpposite="#//InformationItem/relation"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="List" eSuperTypes="#//Expression">
<eStructuralFeatures xsi:type="ecore:EReference" name="element" ordered="false"
upperBound="-1" eType="#//Expression" containment="true" eOpposite="#//Expression/list"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="relation" ordered="false"
eType="#//Relation" eOpposite="#//Relation/row"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="ElementCollection" eSuperTypes="#//DMNElement">
<eStructuralFeatures xsi:type="ecore:EReference" name="drgElement" ordered="false"
upperBound="-1" eType="#//DRGElement" eOpposite="#//DRGElement/elementCollection"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="definitions" ordered="false"
lowerBound="1" eType="#//Definitions" eOpposite="#//Definitions/collection"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EEnum" name="BuiltinAggregator">
<eLiterals name="COLLECT"/>
<eLiterals name="SUM" value="1"/>
<eLiterals name="COUNT" value="2"/>
<eLiterals name="MIN" value="3"/>
<eLiterals name="MAX" value="4"/>
<eLiterals name="AVERAGE" value="5"/>
</eClassifiers>
</ecore:EPackage>

Commençons par une vue synoptique des principaux concepts du métamodèle DMN.

Une simple recherche dans Google ( qui est mon ami ! ) ou dans Wikipedia, nous démontre la rareté des outils de modélisation DMN.

Comme on n'est jamais aussi bien servi que par soi même, nous allons dans cette série d'articles montrer comment créer son propre outil DMN, open source bien évidement.

L'objectif n'est pas d'être exhaustif, mais de montrer les différentes étapes et d'implémenter les principaux concepts du métamodèle DMN, il suffit ensuite de reproduire ces étapes pour les autres éléments sachant que de toute manière il y en a toujours qui ne sont jamais utilisés.

Même dans des outils commerciaux onéreux, il est rare d'en trouver 100 % compatibles avec la norme.

Si vous ne pratiquez pas tous les jours la modélisation de règles métiers avec DMN, voici les principaux articles dans l'ordre pédagogique que nous avions consacrés à DMN :

1. Quels sont les objectifs et les concepts de la notation de modélisation des règles métier, DMN Decision Model and Notation ?
    
2. DMN - L'antisèche de la notation complète des composants d'un DRD ( Decision Requirement Diagram ) : notation de la décision
    
3. DMN - L'antisèche de la notation complète des composants d'un DRD ( Decision Requirement Diagram ) : notation des règles de connexions
    
4. La norme DMN ( Decision Model and Notation ) pour les tables de décision
    
5. Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : le processus métier BPMN
    
6. Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : La vue des exigences des décisions
    
7. Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : Le niveau logique de décision
    
8. Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : Exemple d'exécution du modèle de décisions
    

 Zoomons sur le concept de "Decision" :

Cette partie du métamodèle représente les principaux éléments de modélisation que nous allons implémenter dans notre outil à savoir : Decision, BusinessKnowledgeModel, KnowledgeSource et InputData.

Après ces rappels ô combien nécessaire, le prochain article sera consacré à la réalisation de la totalité du métamodèle DMN en technologie Eclipse Ecore ( rassurez-vous on ne fera que récupérer un fichier déjà prêt sur étagère) que l'on utilisera ensuite avec l'excellent outil français ( cocorico la french tech ) Obeo Designer Community 9.1( = Eclipse prêt à l'emploi intégrant une floppée de plugins dont Sirius ).

Pour voir la suite :

Le métamodèle Eclipse Ecore DMN ( Decision Model and Notation ) : comment concevoir son propre outil de modélisation DMN ? [2/4]

Rhona Maxwel

@rhona_helena

"La joie est en tout ; il faut savoir l'extraire."

Confucius

Articles conseillés :

Les recherches en urbanisation du Système d'Information : le Model-Driven Engineering (MDE) encore un acronyme à la mode ?

Model-Driven Engineering (MDE) : modèles, métamodèles, métamétamodèles, méta... ?

Ingénierie Dirigée par les Modèles (IDM) : un exemple vaut mieux qu'un long discours

Ingénierie Dirigée par les Modèles (IDM) : tutoriel ATL (ATLAS Transformation Language), concevez les métamodèles avant de passer aux choses sérieuses

Eclipse Modeling Framework (EMF) : revoyons les fondamentaux

Ingénierie Dirigée par les Modèles (IDM) : tutoriel Eclipse Ecore, le corps à corps avec les méta modèles

Ingénierie Dirigée par les Modèles : fini Eclipse GMF, vive Eclipse Sirius ( didacticiel / tutoriel Sirius)

La bonne pratique est de séparer les préoccupations et donc, en urbanisation du Système d'Information, les règles métiers doivent avoir leur langage de modélisation, c'est ce qu'a fait l'OMG ( Object Management Group ) avec DMN ( Decision Model Notation ), mais sera t'il utilisé par les experts métiers ou deviendra t'il une spécification "poussiéreuse" rangée dans les placards de l'OMG et oublié des utilisateurs ?

Après la série d’articles ( voir : Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : Exemple d'exécution du modèle de décisions ) consacrés au langage de modélisations des règles métiers DMN , normalisé par l’OMG, il est légitime de se demander si c’est vraiment utilisé dans la « vraie vie » ?

Comme on le sait, un gouffre sépare maîtrise d'ouvrage et maîtrise d'œuvre.

Un des objectifs de l’urbanisation du Système d’Information, est justement d’estomper ce fossé.

L'urbanisme cible la réappropriation du SI par la maîtrise d'ouvrage.

Pour y arriver, une compétence plus grande en matière de SI leur est nécessaire.

Une meilleure communication maîtrise d'ouvrage - maîtrise d'œuvre pourra s'instaurer.

Dans le cadre de la refonte du SI d’un assureur, j’ai proposé l’intégration d’un moteur de règles ( voir nos articles dans la catégorie :  MOTEUR DE RÈGLES ). Mon équipe d’urbanistes à gérer les préoccupations techniques et métiers.

Au lancement du projet, pour moi le risque était avant tout technique à cause du contexte extrêmement contraignant et complexe.

Le domaine métier me paraissait plus maîtrisé. Les règles métiers étaient certes nombreuses, certaines très compliquées et mal formulées. Mais avec l’outil Enterprise Architect, en appliquant ses profils UML et sa méthode, j’étais plutôt confiante.

Les solutions de moteur de règles métier, proposaient tous des outils pour les experts métiers, comme la possibilité d'intégrer leur propre terminologie en concevant un DSL ( Domain Specific Language ), des assistants pour la conception et les tests des règles ainsi que des tables de décision de production avec Excel.

Et puis au fil du temps, après consultation des éditeurs et experts techniques en BRMS ( Business Rules Management System ) et BPM ( Business Process Managment ), les exigences techniques ont toutes été satisfaites, un « Proof Of Concept ( POC )» a été réalisé avec succès sur un vrai cas métier simplifié.

Restait à convaincre les experts métiers d’utiliser la méthode et les outils orientés utilisateur ( DSL Domain Specific Language = langage utilisant les concepts et la terminologie métier de l’assureur, fichiers Excel pour les tables de décision, tests utilisateur, …).

Et la patatras !

Malgré des présentations, puis des formations spécialement conçues pour eux avec un prototype qui s’exécutait et qui leur permettait de voir réellement les apports, d’une gestion des règles métiers bien à part, l’intégration dans un processus métier et l’automatisation dans un moteur de processus exécutables couplé à un moteur de règles métiers, les utilisateurs ont refusé d’avoir à faire l’effort d’intégrer cette nouvelle méthodes et ces nouveaux outils.

En ce qui concerne DMN, pour ne rien arranger, il existe très peu d’outils conviviaux destinés aux utilisateurs et aucun ne s'interface avec par exemple Drools.

L’outil Sirius ( l’open source Obeo Designer Community basé sur la plateforme standard Eclipse ) de la société Obeo, permet de créer son propre langage de modélisation et donc DMN. En plus, le métamodèle ( la grammaire du langage ) en UML ( Unified Modeling Language ) est bien spécifié par l’OMG et donc peut être injecté dans l’outil.

Cela sera peut-être possible dans certaines organisations comme dans le domaine de l'aéronautique par exemple, mais pour d’autres ( mutuelles, ... ) cela ne fera pas partie de leurs préoccupations et restera l’affaire d’experts en ingénierie dirigée par les modèles et de passionnés de méthodes et autres théories, certes très intéressantes intellectuellement parlant, mais qui n’a rien à voir avec la liquidation de garantie d’un capital décès.

Le point critique d’un projet BRMS concerne le développement de tout ce qui va être exposé aux utilisateurs « métier », c’est à dire :

• Le langage « métier » utilisé,
• L’élaboration de modèles et d’autres fonctions connexes comme des tests de non-régression ou des aides au débogage.

La criticité vient principalement du niveau technique des utilisateurs « métier » concernés.

Si trop de liberté est laissée et que les utilisateurs ne sont pas assez formés, le système peut devenir instable, incompréhensible et donc ne pas remplir du tous ses objectifs d’amélioration de l’évolutivité du système, les utilisateurs ayant systématiquement besoin de l’assistance de l’équipe informatique.

À l’inverse, si le système est trop contraint, les utilisateurs ne pourront pas forcement exprimer toutes les règles qu’ils souhaiteraient.

Dans ce cas, soit les utilisateurs cessent d’utiliser le système, soit les demandes à l’équipe informatique se multiplient.

Un bon conseil, n'hésitez pas à réaliser un POC avec comme objectifs de concevoir la méthode, les modèles et la granularité des règles, de former quelques développeurs et experts métiers, de communiquer avec pédagogie a l'ensemble des acteurs projet y compris la direction générale et la DSI.

Et puis très important, faites une première itération ou seul les développeurs vont écrire les règles. Les processus d'intégration, d'exploitation, de tests et de cycle de vie des règles doivent être validés.

Profitez-en pour mesurer les temps de développement et autres charges pour affiner votre retour sur investissement.

Le moteur de règles métier open source Drools ( voir nos articles dans la catégorie : DROOLS ), est le standard choisi par l'industrie. 

Son langage a été repris par la plupart des autres éditeurs.

La spécification des tables de décision a même été repris par l'OMG ! 

Drools s'intègre parfaitement avec le moteur de processus métiers exécutables open source jBPM ( voir nos articles dans la catégorie :  JBPM ) de la même société.

Tous les acteurs du domaine d'urbanisation du SI des règles métiers ont leurs outils, cela va du développeur avec des plugins Eclipse, en passant par l'administrateur pour la gestion et le cycle de vie des règles métiers jusqu'à l'expert métier avec des applications web permettant la conception avec leurs propres DSL reprenant leur jargon métier.

On peut donc avec une telle plate-forme, se passer aisément de DMN.

En conclusion, DMN n'est t'il pas un DSL ( Domain Specific Language ) pour "savants fous", méthodologues et autres théoriciens de l'IDM ( Ingénierie Dirigée par les Modèles voir nos articles : INGÉNIERIE DIRIGÉE PAR LES MODÈLES (IDM) ), épris uniquement de concepts abstraits et éloignés des préoccupations pratiques de la vraie vie des experts métiers qui ont d'autres choses à faire que d'apprendre un langage et des outils techniques ? 

"Le danger, ce n'est pas ce qu'on ignore, c'est ce que l'on tient pour certain et qui ne l'est pas."

Mark Twain

 Rhona Maxwel

@rhona_helena

Articles conseillés :

Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : le processus métier BPMN

Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : La vue des exigences des décisions

Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : Le niveau logique de décision

DMN

Un scénario pour tester notre modèle DMN de règles métiers

Un premier article :

Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : le processus métier BPMN

vous a présenté le processus métier BPMN utilisé pour ce tutoriel sur DMN et qui comporte des tâches de type décisions ou règles métiers.

Le deuxième article :

Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : La vue des exigences des décisions

propose le DRG ( Decision Requirement Graph )

Le troisième article :

Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : Le niveau logique de décision

détaille le modèle précédent en montrant les tables de décision et les règles métiers. 

L'objectif de cet article est d'illustrer par un exemple de données en entrée, le fonctionnement du modèle de décisions.

Ce scénario de test, termine notre série d'articles sur la norme de modélisation des règles métiers DMN.

Rhona Maxwel

@rhona_helena

"Je veux être tout ce que je peux devenir."

Katherine Mansfield

Articles conseillés :

Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : Le niveau logique de décision

Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : La vue des exigences des décisions

Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : le processus métier BPMN

Exemple de tables de décision liées à un DRG ( Decision Requirement Graph )

Le DRG de notre article précédent : Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : La vue des exigences des décisions est complété en détail par les expressions associées aux décisions et modèles de connaissances :

Rhona Maxwel

@rhona_helena

"Nul ne peut atteindre l'aube sans passer par le chemin de la nuit."

Khalil Gibran

Articles conseillés :

Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : La vue des exigences des décisions

Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : le processus métier BPMN

La norme DMN ( Decision Model and Notation ) pour les tables de décision

DRD ( Decision Requirement Diagram ) des prises de décisions

Le schéma ci-dessus montre un DRD ( Decision Requirement Diagram ) des prises de décisions dans le processus métier vu dans l'article précédent : Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : le processus métier BPMN

Il y a quatre sources de données en entrée pour la prise de décisions (Requested product, Applicant data, Bureau data and Supporting documents) et quatre décisions dont les résultats sont utilisés dans le processus métier (Strategy, Bureau call type, Routing and Adjudication). Entre les deux sont des décisions intermédiaires : « evaluations of risk », « affordability » et « eligibility ».

Les caractéristiques de ce DRD incluent :

• Il couvre les prises de décisions automatisées et humaine.
• Des décisions (par exemple, « Pre-bureau risk category ») et des données en entrée (par exemple, « Applicant data) » sont exigées par de multiples décisions, cela signifie que le réseau d'exigences de l'information n'est pas un arbre.
• Des modèles de connaissance métiers (voir «  Affordability calculation ») peut être invoqué par de multiples décisions.
• Les modèles de connaissance métiers (voir «  Credit contingency factor ») peut être invoqué par d'autres modèles de connaissance métiers.
• Quelques décisions n'ont pas de modèles de connaissance associés.
• Les sources de connaissance peuvent fournir les aspects légaux (autorité) pour de multiples décisions et-ou des modèles de connaissance métiers.

Il est conseillé de séparer les DRDs pour les 3 décisions :

Les 2 services de décisions nécessaires par le processus métier doit être modélisé :

Rhona Maxwel

@rhona_helena

 "Accomplis chaque acte de ta vie comme s'il devait être le dernier."

Marc Aurèle

Articles conseillés :

Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : le processus métier BPMN

La norme DMN ( Decision Model and Notation ) pour les tables de décision

DMN - L'antisèche de la notation complète des composants d'un DRD ( Decision Requirement Diagram ) : vues partielles et informations masquées

Pour notre tutoriel sur la norme DMN ( Decision Model Notation ) de modélisation des règles métiers, voici un exemple complet basé sur le processus de création de prêt, modélisé avec BPMN 2 ( Business Process Model Notation ) .

Le processus métier est implémenté par une application qui a pour but de gérer une demande de prêt, obtenant des données d'un bureau de crédit seulement si c'est nécessaire et décide automatiquement si la demande doit être acceptée, ou renvoyée pour étude par un gestionnaire. Si elle est renvoyée, les documents du demandeur sont rassemblés et un gestionnaire du domaine crédit juge le cas. Cela consiste dans les composants suivants :

• La tâche « Collect application data »  rassemble des données décrivant le produit demandé et le demandeur) (par exemple, par un formulaire de demande en ligne).
• La tâche de type décision « bureau Strategy » appelle un service de décision en lui transmettant en entrée passant le produit demandé et les données du demandeur. Le service produit deux décisions : « Strategy » et « Bureau call type ».
• Une passerelle utilise la valeur de « Strategy » pour aiguiller vers les tâches « Decline application », « Collect bureau data » ou « Decide routing ».
• La tâche « Collect bureau data » rassemble les données d'un bureau de crédit selon la décision de la tâche « Bureau call type », alors le cas est passé à la tâche « Decide routing ».
• La tâche « Decide routing » appelle un service de décision, en lui transmettant le produit demandé, les données du demandeur et les données du bureau (si la tâche « Collect bureau data » n'a pas été exécutée, les données de bureau sont mises à nulle). Le service rend une décision seule: «  Routing ».
• Une passerelle utilise la valeur «  Routing » pour aiguiller pour « Accept application », « Review application » ou « Decline application ».
• La tâche « Collect documents » récupère et télcharge les documents du demandeur.
• La tâche « Review application » permet au gestionnaire du domaine crédit d'étudier le cas et décider s'il doit être accepté ou refusé.
• Une passerelle utilise la décision du gestionnaire du domaine crédit pour aiguiller le cas vers « Accept application » or « Decline application ».
• La tâche « Accept application » informe le demandeur que sa demande est acceptée et initialise le prêt avec le produit de crédit.
• La tâche « Decline application » informe le demandeur que l'on refuse sa demande.

Notez que dans cet exemple deux décisions (automatisées avec des appels aux services de décision) qui ont représentés en BPMN 2 comme des tâches de règle métiers ; la troisième décision (qui est la prise de décisions humaine) est représenté comme une tâche d'utilisateur.

Rhona Maxwel

@rhona_helena

"Mille victoires sur mille ennemis ne valent pas une seule victoire sur soi-même"

Bouddha

Articles conseillés :

La norme DMN ( Decision Model and Notation ) pour les tables de décision

DMN - L'antisèche de la notation complète des composants d'un DRD ( Decision Requirement Diagram ) : le service de décision

DMN - L'antisèche de la notation complète des composants d'un DRD ( Decision Requirement Diagram ) : vues partielles et informations masquées