DMN

BPMN, CMMN et DMN : évolution des spécifications et émergence du langage FEEL

En tant que lecteur assidu de notre blog www.urbanisation-si.com, vous avez bien compris que nous préférons les notations normalisées et nous ne prenons pas beaucoup de risques quand nous vous recommandons de les utiliser. Selon les notations, leurs spécifications sont mises à jour plus ou moins régulièrement, mais la fréquence de ces mises à jour n’est pas forcément le signe de leur usage intensif. Nous allons démontrer ici que c’est même le contraire, ce qui semble paradoxal. C’est à travers ce prisme que nous allons faire le point dans cet article sur les évolutions des spécifications BPMN, CMMN et DMN, surtout DMN en fait, avec son langage FEEL et un exemple d’application.

BPMN (Business Process Model and Notation)

La dernière version 2.0.2 de BPMN fut publiée en janvier 2014, soit il y a plus de 11 ans déjà. Et encore, il ne s’agissait que d’un simple changement mineur concernant les formats d’échanges. La version 2.0.1 mineure précédente, publiée en septembre 2013, était plus importante, car elle permit à BPMN de devenir un véritable standard international : ISO/IEC 19510. En fait, la dernière version majeure 2.0 fut publiée en décembre 2010. Aucune mise à jour majeure depuis une quinzaine d’années donc, mais BPMN est pourtant une notation qui remporte un énorme succès. Peut-être que les spécifications de BPMN (une belle somme de 532 pages pour la version 2.0.2) ont approché, voire atteint, l’exhaustivité ?

Exemple d’un diagramme d’orchestration BPMN
représentant un processus d’approvisionnement (OMG)

CMMN (Case Management Model and Notation)

Seulement deux versions pour CMMN : la version initiale 1.0 en mai 2014, puis la version 1.1 en décembre 2016. Nous n’avons jamais été de fervents supporters de CMMN. En gros, CMMN permet de lister des tâches qui pourront être exécutées par les opérateurs dans n’importe quel ordre, en fait dans un ordre adéquat qui ne peut pas être prédéterminé et qui répond à un besoin de flexibilité. On reconnait un diagramme CMMN à sa représentation octogonale des étapes (stages) :

Exemple d’un modèle plan de cas CMMN représentant la gestion des réclamations (OMG)

Afin d’une notation normalisée soit utilisée, il faut qu’elle soit supportée par l’outillage. L’éditeur allemand Camunda a décidé d’arrêter de supporter CMNN en 2019, tandis que d’autres, comme l’éditeur australien Sparx Systems et l’éditeur canadien Trisotech, continuent de la supporter. Trisotech promeut le concept de Triple Crown - triple couronne, sorte de tiercé gagnant pour améliorer les processus métier - constituée de BPMN + CMMN + DMN. Finalement, CMMN ne semble pas avoir rencontré le succès escompté. Ce qui est absolument certain, c’est que CMMN est bien moins utilisé que BPMN.

Rappelons que BPMN propose le sous-processus Ad-Hoc, reconnaissable à son tilde « ~ », qui permet en partie de modéliser de tels cas, sans doute bien difficiles à automatiser. Voici l’exemple officiel de sous-processus Ad-Hoc, extrait de la spécification BPMN 2.0.2 :

Exemple d’un sous-processus BPMN Ad-Hoc représentant l’écriture d’un chapitre de livre (OMG)

Ce sous-processus Ad-Hoc représente l’écriture d’un chapitre de livre (mais aussi l’écriture de cet article !) : on effectue des recherches, on écrit du texte, on crée des illustrations, etc., dans un ordre quelconque (SANS flux de séquence entre les tâches) et souvent plusieurs fois, pourvu que le livrable final (un chapitre ou cet article donc) constitue un ensemble logique et cohérent (c’est ce que l’on espère !).

DMN (Decision Model and Notation)

Si la notation DMN peut s’utiliser seule, rappelons qu’elle est aussi destinée à compléter BPMN. Ou plutôt, selon le principe de séparation des préoccupations, à dissocier les prises de décisions des processus métier. Comme nous le démontrerons plus loin, cela permet de faire évoluer une prise de décision, sans modifier le processus métier qui invoque cette prise de décision. Rappelons que DMN ne sert pas qu’à représenter les prises de décisions, mais peut également servir à représenter des calculs plus ou moins complexes (exemple : calculer le pourcentage d’une remise commerciale, selon l’ancienneté du client, le montant de sa commande, etc.).

Tandis que la notation DMN semble encore peu utilisée, notamment en France, le groupe de travail de l’organisme normalisateur OMG est très actif, avec en moyenne une nouvelle version des spécifications DMN tous les 2 ans depuis 10 ans ! Voici l’historique des différentes versions de DMN :

Historique des différentes versions de DMN

N.B. Une version 1.6 Beta de la spécification DMN est déjà publiée.

Langage FEEL (Friendly Enough Expression Language)

Si le nombre de pages des spécifications DMN est un indicateur, la tendance étant généralement à la hausse d’une ancienne vers une nouvelle version (dans un volume toutefois contenu de 250 pages en moyenne depuis plusieurs années), un autre indicateur a retenu notre attention : le nombre de fonctions du langage FEEL (Friendly Enough Expression Language). Il s’agit donc d’un langage destiné théoriquement à une large audience : les développeurs, mais aussi les experts métier.

Si, au début, il était réservé pour les expressions littérales et les tables de décision de DMN, il est désormais possible de l’utiliser dans BPMN (bien que la dernière version 2.0.2 des spécifications n’en fasse aucune mention, mais vous avez bien noté que BPMN est antérieure à DMN) : dans les passerelles (gateways) conditionnelles et dans les tâches de type Script. L’éditeur Camunda offre également la possibilité d’utiliser le langage FEEL dans ses formulaires.

En 10 ans, le nombre de fonctions de FEEL a plus que doublé, atteignant la centaine ! Dans le tableau récapitulatif ci-dessous, nous nous sommes alignés sur les différents types de fonctions de la version 1.5 de spécifications DMN, alors que des regroupements fonctionnels pourraient être effectués (Date and time, Temporal et Miscellaneous, par exemple) :

Nombre de fonctions FEEL intégrées, par type et par version de DMN

Certains éditeurs comme Camunda ajoutent déjà certaines fonctions FEEL étendues (la dernière ligne du tableau ci-dessous), sans attendre qu’elles soient normalisées dans la dernière version 1.5 de la spécification DMN : nous vous recommandons d’utiliser ces fonctions avec parcimonie, en espérant qu’elles soient normalisées dans la prochaine version… Bon, l’éditeur Camunda est un membre très actif du groupe de travail DMN de l’OMG. Ces fonctions supplémentaires sont clairement reconnaissables dans la documentation en ligne grâce à la mention « Camunda Extension ».

Exemple d’application simple, mais opérationnel

Voici un exemple très simple pour illustrer l’utilisation du langage FEEL dans la notation DMN. Soit le processus métier d’un transporteur qui consiste à indiquer au destinataire d’un colis une date de livraison en fonction d’une date d’expédition. Dans la représentation BPMN du processus, une tâche de type Règle Métier (symbolisé par la petite table de décision au haut à gauche du rectangle) calculera cette date de livraison. Nous verrons que la méthode de calcul de cette date de livraison pourra évoluer au fil du temps et devenir plus élaborée, SANS modifier la représentation BPMN du processus : c’est là l’illustration du principe de séparation des préoccupations.

Diagramme d’orchestration BPMN simple, mais immuable, représentant le calcul d’une date de livraison

Il convient ensuite de créer un modèle DMN, en l’occurrence un diagramme DRD (Decision Requirements Diagram) avec au moins une décision - ou un calcul - complétée par une expression littérale ou une table de décision. Voyons en détail ces deux possibilités.

Selon le plan de transport, la livraison de colis est théoriquement effectuée le lendemain de l’expédition, délai que l’on nomme souvent « J+1 ». Le langage FEEL propose la fonction « duration » pour calculer cette date de livraison. En fait, il suffit d’ajouter une Période de 1 jour « P1D » (ce format de durée est défini dans XPath Data Model) à la date d’expédition. Voilà comment cela se traduit en langage FEEL, dans une expression littérale :

Diagramme DRD et expression littérale associée simple, en langage FEEL (DMN)

Mais les livraisons ne sont pas effectuées par ce transporteur durant le weekend, aussi : si la date d’expédition est un vendredi (5e jour de la semaine), on ajoutera deux jours de plus, et si la date d’expédition est un samedi (6e jour de la semaine), on ajoutera un jour de plus, afin de livrer le lundi qui suit. Voilà comment cela se traduit en langage FEEL, toujours dans une expression littérale :

Diagramme DRD et expression littérale associée plus élaborée, en langage FEEL (DMN),
afin de prendre en compte les weekends

Résultat de l’exécution de cette expression (variable d’entrée, puis variable de sortie).

Mais plutôt que d’imbriquer plusieurs tests « if-then-else » (disponible dans le langage FEEL donc) comme avec n’importe quel autre langage de programmation (cela reste toutefois lisible grâce à un effort sur l’indentation), il est préférable ici d’utiliser l’une des fonctionnalités de DMN, en l’occurrence une table de décision, plus lisible et donc plus facilement modifiable qu’une expression littérale (en cas de changement du plan de transport, dans cet exemple) :

Diagramme DRD et table de décision associée, en langage FEEL (DMN),
prenant en compte les weekends

Une démarche « Low Code » ? Vous remarquerez que dans la formalisation des règles métier dans une table de décision, le « when » remplace le « if ». Pas de changement pour le « then ». Quant au « else », il devient implicite : chaque règle, c.-à-d. chaque ligne (numérotée de 1 à 4 dans la table de décision ci-dessus) correspond plus ou moins à un « else » (pour être précis, cela dépend de la Hit policy, mais ce point important mériterait un prochain article pour lui tout seul).

Des éditeurs interactifs en ligne permettent de tester partiellement vos expressions en langage FEEL. Cette méthode de calcul de la date de livraison est encore assez sommaire. La prochaine étape consisterait à prendre en compte dans le calcul, en plus des weekends, les jours fériés. Toujours SANS modifier (et SANS redéployer) la représentation BPMN du processus, qui se contente de la simple tâche « Calculer Date Livraison ».

Conclusion

BPMN est une norme (et même un standard ISO) peu mise à jour, mais très utilisée, tandis que DMN est une norme bien vivante et régulièrement mise à jour, mais encore peu utilisée : pas forcément très logique, tout cela !

Continuez à utiliser BPMN, dont si nécessaire ses sous-processus Ad-Hoc pour remplacer CMMN. Mais surtout, n’hésitez pas à séparer les prises de décisions et les calculs complexes dans des modèles DMN, puis à évaluer puis utiliser les nombreuses fonctions du langage FEEL, dans vos expressions littérales et tables de décision notamment.

Thierry BIARD

urbanisation-si.com

« Le secret pour réussir, c’est de toujours prendre de bonnes décisions.
Et comment prend-on de bonnes décisions ? Grâce à l’expérience.
Et comment acquiert-on de l’expérience ? En prenant de mauvaises décisions. »
Citation attribuée à Mark Twain

Annexe

Cet exemple opérationnel d'application du langage FEEL de DMN a été réalisé avec :

Camunda Modeler version 5.33.1,
Camunda 8 Run version 8.6.12.

L'installation de Camunda Modeler n'a rien de particulièrement difficile.

L'installation de Camunda 8 Run nécessite l'installation préalable d'un JDK (Java Development Kit) version 21 ou supérieure, qui n'est pas une version très courante (bien que la dernière version du JDK en cours de développement soit la version 25, Oracle recommande toujours la version 8 de Java aux utilisateurs finals !). Comme avec d'autres composants, choisissez de préférence une version LTS (Long Term Support). Enfin, n'oubliez pas d'initialiser les variables d'environnement JAVA_HOME et JAVA_VERSION :

Une fois la version adéquate de JDK installée et le paquet ZIP de Camunda 8 Run extrait dans un répertoire, il suffit de le démarrer en saisissant "c8run start". Le moteur de base de données Elasticsearch démarre avant Camunda, après un nombre aléatoire de tentatives, ce qui est assez surprenant :

La fin du démarrage de Camunda lance automatiquement votre navigateur web préféré avec l'URL "Operate" (Username = Password = demo) :

Avec Camunda Modeler, il faudra choisir la version 8 de Camunda lors de la création d'un nouveau fichier, que ce soit pour BPMN, DMN ou Form (Formulaire). Ces trois types de fichiers devront ensuite être déployés sur Camunda 8 Run de la même façon avant utilisation. Pour cela, il suffit de cliquer sur la petite fusée en bas à gauche de la fenêtre principale de Camunda Modeler, puis sur le bouton Deploy :

Seul le processus métier peut être démarré à partir de Camunda Modeler. Il suffit de cliquer sur la petite flèche en bas à gauche, puis sur le bouton Start. Inutile d'indiquer une variable optionnelle au format JSON, car cette variable va être renseignée lors de la saisie du formulaire.

Pour effectuer cette saisie du formulaire, indiquez l'URL de la Tasklist, choisissez la tâche en attente, cliquez sur le bouton M'assigner, saisissez la Date d'expédition (ou sélectionnez-là dans le calendrier qui s'affiche) et enfin cliquez sur le Bouton du bas "Terminer la tâche" (un message fugace "Tâche terminée" s'affiche) :

Retournez sur l'URL Operate, cliquez sur l'onglet Decisions, puis cliquez sur la Decision Instance Key la plus récente.

La règle qui a été appliquée pour prendre la dernière décision est surlignée (ici la #2).
Cliquez enfin sur l'onglet Result pour voir le résultat, suite à l'application de cette règle.

A la fin de l'utilisation, pour arrêter Camunda 8 Run, saisissez "c8run stop" :

Compléments de lecture

BPMN

CMMN

CMMN (Case Management Model and Notation) : vie et mort d’une norme de l’OMG (Object Management Group)

La rédaction tient à souligner que la plateforme urbanisation-si.com est indépendante de toute organisation et son fonctionnement repose entièrement sur des bénévoles passionnés de pédagogie et désirant partager leur expérience. Vous ne verrez jamais de publicités sur notre plateforme.

Bien que nous encourageons l’open source, il peut nous arriver d’utiliser des logiciels commerciaux qui nous sont gracieusement prêtés sous aucune condition et nous ne touchons aucune rémunération de qui que ce soit.

08/04/2025

3 J'aime 0 Poster un commentaire

Experts métiers, passez-vous de développeurs, modélisez vos règles métiers avec DMN puis générez et exécutez automatiquement le code RedHat Drools et inversement

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 :

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 :

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 :

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 :

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

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 ?

29/11/2017

0 J'aime 0 Poster un commentaire

Améliorations et notions avancées Eclipse Sirius, suite et fin de notre saga : comment concevoir son propre outil de modélisation DMN ? [4/4]

Voici les solutions aux défauts et aux limites de notre outil de modélisation DMN ( Domain Model and Notation ) commencé dans l'article précédent.

Les relations de type InformationRequirement sont remplacées par des « Element Based Edge » qui permettent l'ajout dans la palette des outils la possibilité de créer/modifier/supprimer des relations, des objets à la souris, la belle vie quoi.

On veut réaliser un outil graphique capable de créer un modèle DMN à la souris, respectant la norme de l'OMG.

Ci-dessous le résultat obtenu :

Pour ceux qui aurait manquer le début :

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

Comme d'habitude, vous aurez besoin de votre antisèche DMN, tableau synoptique des entités et des relations :

Les relations sont implémentées par les classes: InformationRequirement, KnowledgeRequirement et AuthorityRequirement, mais un petit rappel sur le métamodèle DMN de l'OMG ne fait pas de mal.

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

Création de relations représentées par une métaclasse => Element Based Edge.

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.

Création de la palette et ajouts des outils de création d'objets par glisser/déposer à la souris.

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

Ajout de l'outil de création de relations dans la palette

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.

Dernière fonctionnalité traitée dans cet article, c'est la suppression d'un élément lorsque l'utilisateur sélectionne un élément et appuie sur la touche "suppr".
L'élément est supprimé de la vue et physiquement du modèle DMN.

Clic droit sur Section Outils - New Element Edition - Delete Element

Clic droit sur Begin - New Operation - Change Conrext - Browse Expression = var:element ( correspond à l'élément source )
Clic droit Change Context var:element - New Operation - Remove

On peut vérifier par exemple que dans une relation entre 2 decisions, la suppression de la source ou de la cible entraine bien la suppression de l'objet et la relation InformationRequirement dans le modèle Ecore DMN de la demande de prêt ( demandeDePret.dmnecore ).

L'exemple vu dans l'article :

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]

09/07/2017

0 J'aime 0 Poster un commentaire

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.

Images pour récupérer les éléments de modélisation DMN

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

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

Annexe
Fichier source du modèle DMN de la demande de prêt

<?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>

06/07/2017

0 J'aime 0 Poster un commentaire

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

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

Articles sur Eclipse Ecore :

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)

Mode Opératoire

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

Annexe

Fichier DMN Ecore

<?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.
Created:8/4/13 9:11 PM.
Title:.
Comment:.
"/>
</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>

04/07/2017

1 J'aime 2 Poster un commentaire

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

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 :

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)

03/07/2017

2 J'aime 0 Poster un commentaire

DMN ( Decision Model Notation ) : Ne serait-ce pas un langage de plus, une contrainte de plus imposée à la MOA par la MOE ?

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 ?

Ci-dessus une table de décision dans Excel, au format du moteur de règles métiers open source Drools, conforme aux spécifications de la norme DMN.

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.

Ci-dessus, un exemple de règle métier ( le fameux "Hello world" pour les apprentis d'un langage ) écrite en DRL ( Drools Rules Language ) , le langage standard du moteur de règles métiers open source Drools, adopté par l'industrie et copié par d'autres éditeurs comme IBM.

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

21/01/2017

0 J'aime 0 Poster un commentaire

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

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.

Exemple de données en entrée : « Applicant Data »

Exemple de données en entrée : « Requested Product »

Exemple de données en entrée : « Bureau Data »

Résultat du service de décision : « Bureau Strategy »

Résultat du service de décision : « Routing »

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

02/01/2017

2 J'aime 0 Poster un commentaire

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

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 :

« Strategy decision » défini une table de decision déduite de « Strategy » allant de « Eligibility » et « Bureau Call Type »

« Bureau Call Type » décision invoque la table « Bureau call type », passant la sortie de « Pre-bureau risk category » décision comme le paramètre « Pre-Bureau Risk Category ».

La table de décision « Bureau call type ». 

« Eligibility » invoque la règle métier « Eligibility », passant « Applicant data », le paramètre « Age » , la sortie de la décision « Pre-bureau risk category » comme le paramètre « Pre-Bureau Risk Category », et la sortie de la décision « Pre-bureau affordability » comme le paramètre « Pre-Bureau Affordability ».

« Eligibility Rules »

« Pre-Bureau Risk Category »

La table de décision « Pre-Bureau Risk Category »

« Application Risk Score »

« Application Risk Score Model »

« Routing decision »

« Routing Rules »

« Post-Bureau Risk Category »

La table de décision « Post-bureau risk category »

« Pre-bureau Affordability »

« Post-bureau affordability »

« Affordability calculation »

La table de décision « Credit contingency factor »

« Required monthly installment »

« Installment calculation »

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

02/01/2017

0 J'aime 0 Poster un commentaire

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

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.