Et voici les concepts de bases pour bien comprendre la modélisation des règles métiers avec DMN ( Decision Model Notation )
Une décision est l'action de déterminer une option choisie, un certain nombre de valeurs, en appliquant des règles métiers.
Une décision est l'action de déterminer une option choisie, un certain nombre de valeurs, en appliquant des règles métiers.
Cette logique de décision peut inclure une base de connaissances référentiel d'une expertise.
Il s'agit de règles de gestion, des modèles analytiques, ou d'autres formalismes.
Le diagramme précédent s'appelle un DRD ( Decision Requirements Diagram ).
Dans ce diagramme 2 artefacts de modélisation sont obligatoires :
- les données en entrée ( Input data )
- la Décision ( Decision ) appliquant une logique ( règles ) sur ces données en entrée. Une Décision peut se composer d'autres Décisions.
Les autres éléments :
- Source de connaissance ( Knowledge Source ) modélise une autorité
- Modèle de connaissance métier ( Business Knowledge Model ) modélise une logique de décision réutiisable.
Les relations sont modélisées par des classes :
- InformationRequirement permet de relier des Décisions entre lelles ou une Décision et des InputData
- KnowledgeRequirement permet de relier une Décision et des BusinessKnowledgeModel
- AuthorityRequiremrent permet de relier une Décision et des KnowledgeSource.
La norme DMN, spécifie chaque décision un modèle de connaissance métier ou dans un domaine d'expertise.
La base de connaissance contient la logique de décision. Les experts métiers la formalise. Elle est constituée d'un modèle d'entités métiers ( qui peut être modélisé par un diagramme de classe UML ou un diagramme de bloc SysML ), de règles métiers exprimant des consitions, des tables de décision et le processus d'enchaînement de ces règles.
Une décision ou règle nécessite en entrée des données métiers pour déterminer son résultat.
Les décisions (règles) peuvent donc être connectées dans un réseau appelé un Graphique d'Exigences de Décision ( DRG Decision Requirement Graph ), qui peut être dessiné comme un Diagramme d'Exigences de Décision ( DRD Decision Requirement Diagram ).
Un DRD montre comment un ensemble de décisions dépend l'une de l'autre, de données en entrée et sur des modèles de connaissance.
Une décision peut exiger plusieurs modèles de connaissance et un modèle de connaissance peut exiger de multiple autres modèles de connaissance.
La logique d'une décision, c'est à dire la règle permettant de déterminer la sortie en fonction des données en entrée, peut se formaliser par :
- une expression littérale, une description textuelle
- une expression formelle dans un langage comme FEEL ( Friendly Enough Expression Language ) intégré à la norme DMN, DRL ( Drools Rules Language ) le langage du moteur de règles métiers open source standard de l'industrie, ...
- une table de décision largement utilisée et qui correspond le mieux aux documents des experts métiers.
Rhona Mawxel
@rhona_helena
"Je ne crois pas beaucoup a la loi de la pesanteur, il est en effet plus facile de lever une femme que de la laisser tomber."
Courteline
Articles Conseillés :
Drools le moteur de règles métiers open source (BRMS) : le chaînage arrière (backward chaining)
Qui fait fonctionner un moteur de règles ?
Quand faut il utiliser un moteur de règles ?
A découvrir aussi
- DMN - L'antisèche de la notation complète des composants d'un DRD ( Decision Requirement Diagram ) : notation des exigences d'information
- La norme DMN ( Decision Model and Notation ) pour les tables de décision
- Tutorial Obeo Designer Community : comment concevoir son propre outil de modélisation DMN ? [3/4]
Inscrivez-vous au site
Soyez prévenu par email des prochaines mises à jour
Rejoignez les 754 autres membres