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 :
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 :
propose le DRG ( Decision Requirement Graph )
Le troisième article :
détaille le modèle précédent en montrant les tables de décision et les règles métiers.
L'objectif de cet article est d'illustrer par un exemple de données en entrée, le fonctionnement du modèle de décisions.
Ce scénario de test, termine notre série d'articles sur la norme de modélisation des règles métiers DMN.
Rhona Maxwel
@rhona_helena
"Je veux être tout ce que je peux devenir."
Katherine Mansfield
Articles conseillés :
Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : Le niveau logique de décision
Exemple de tables de décision liées à un DRG ( Decision Requirement Graph )
Le DRG de notre article précédent : Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : La vue des exigences des décisions est complété en détail par les expressions associées aux décisions et modèles de connaissances :
Rhona Maxwel
@rhona_helena
"Nul ne peut atteindre l'aube sans passer par le chemin de la nuit."
Khalil Gibran
Articles conseillés :
La norme DMN ( Decision Model and Notation ) pour les tables 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
DRD ( Decision Requirement Diagram ) des prises de décisions
Le schéma ci-dessus montre un DRD ( Decision Requirement Diagram ) des prises de décisions dans le processus métier vu dans l'article précédent : Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : le processus métier BPMN
Il y a quatre sources de données en entrée pour la prise de décisions (Requested product, Applicant data, Bureau data and Supporting documents) et quatre décisions dont les résultats sont utilisés dans le processus métier (Strategy, Bureau call type, Routing and Adjudication). Entre les deux sont des décisions intermédiaires : « evaluations of risk », « affordability » et « eligibility ».
Les caractéristiques de ce DRD incluent :
-
Il couvre les prises de décisions automatisées et humaine.
-
Des décisions (par exemple, « Pre-bureau risk category ») et des données en entrée (par exemple, « Applicant data) » sont exigées par de multiples décisions, cela signifie que le réseau d'exigences de l'information n'est pas un arbre.
-
Des modèles de connaissance métiers (voir « Affordability calculation ») peut être invoqué par de multiples décisions.
-
Les modèles de connaissance métiers (voir « Credit contingency factor ») peut être invoqué par d'autres modèles de connaissance métiers.
-
Quelques décisions n'ont pas de modèles de connaissance associés.
-
Les sources de connaissance peuvent fournir les aspects légaux (autorité) pour de multiples décisions et-ou des modèles de connaissance métiers.
Il est conseillé de séparer les DRDs pour les 3 décisions :
Les 2 services de décisions nécessaires par le processus métier doit être modélisé :
Rhona Maxwel
@rhona_helena
"Accomplis chaque acte de ta vie comme s'il devait être le dernier."
Marc Aurèle
Articles conseillés :
La norme DMN ( Decision Model and Notation ) pour les tables de décision
Tutoriel – didacticiel – exemple complet sur la norme de modélisation des règles métiers DMN ( Decision Model Notation ) : le processus métier BPMN
Pour notre tutoriel sur la norme DMN ( Decision Model Notation ) de modélisation des règles métiers, voici un exemple complet basé sur le processus de création de prêt, modélisé avec BPMN 2 ( Business Process Model Notation ) .
Le processus métier est implémenté par une application qui a pour but de gérer une demande de prêt, obtenant des données d'un bureau de crédit seulement si c'est nécessaire et décide automatiquement si la demande doit être acceptée, ou renvoyée pour étude par un gestionnaire. Si elle est renvoyée, les documents du demandeur sont rassemblés et un gestionnaire du domaine crédit juge le cas. Cela consiste dans les composants suivants :
-
La tâche « Collect application data » rassemble des données décrivant le produit demandé et le demandeur) (par exemple, par un formulaire de demande en ligne).
-
La tâche de type décision « bureau Strategy » appelle un service de décision en lui transmettant en entrée passant le produit demandé et les données du demandeur. Le service produit deux décisions : « Strategy » et « Bureau call type ».
-
Une passerelle utilise la valeur de « Strategy » pour aiguiller vers les tâches « Decline application », « Collect bureau data » ou « Decide routing ».
-
La tâche « Collect bureau data » rassemble les données d'un bureau de crédit selon la décision de la tâche « Bureau call type », alors le cas est passé à la tâche « Decide routing ».
-
La tâche « Decide routing » appelle un service de décision, en lui transmettant le produit demandé, les données du demandeur et les données du bureau (si la tâche « Collect bureau data » n'a pas été exécutée, les données de bureau sont mises à nulle). Le service rend une décision seule: « Routing ».
-
Une passerelle utilise la valeur « Routing » pour aiguiller pour « Accept application », « Review application » ou « Decline application ».
-
La tâche « Collect documents » récupère et télcharge les documents du demandeur.
-
La tâche « Review application » permet au gestionnaire du domaine crédit d'étudier le cas et décider s'il doit être accepté ou refusé.
-
Une passerelle utilise la décision du gestionnaire du domaine crédit pour aiguiller le cas vers « Accept application » or « Decline application ».
-
La tâche « Accept application » informe le demandeur que sa demande est acceptée et initialise le prêt avec le produit de crédit.
-
La tâche « Decline application » informe le demandeur que l'on refuse sa demande.
Notez que dans cet exemple deux décisions (automatisées avec des appels aux services de décision) qui ont représentés en BPMN 2 comme des tâches de règle métiers ; la troisième décision (qui est la prise de décisions humaine) est représenté comme une tâche d'utilisateur.
Rhona Maxwel
@rhona_helena
"Mille victoires sur mille ennemis ne valent pas une seule victoire sur soi-même"
Bouddha
Articles conseillés :
La norme DMN ( Decision Model and Notation ) pour les tables de décision
La norme DMN ( Decision Model and Notation ) pour les tables de décision
Une des manières de représenter la logique de décision correspondant à l'artefact de modélisation des règles métiers DRD ( Decision Requirement Diagram ) est une table de décision.
Une table de décision est une représentation tabulaire d'un ensemble d'expressions, organisées dans des règles métiers indiquant quelles données en entrées vont s'appliquer au système.
La table de décision contient toutes les expressions nécessaires pour déterminer les données en sortie. De plus, une table complète contient toutes les combinaisons possibles d'expressions.
Un des buts de DMN de normaliser des formes différentes et les types de tables de décision.
Une table de décision consiste en :
-
Un nom : usuellement c'est le nom du modèle de connaissance métier pour lequel la table de décision fournit la logique de décision.
-
Un libellé, décrivant les données produites par la table de décision. Le résultat d'une table de décision est référencé utilisant le nom de l'information.
-
Un ensemble d'expressions en entrée.
-
Un ensemble de données en sortie. Chaque donnée produite en sortie SERA nommée.
-
Une liste de règles (un ou plus) en lignes ( ou en colonnes ) de la table (selon l'orientation), où chaque règle est composée des expressions en entrée spécifiques et les données produites en sortie ligne de la table (ou la colonne). Si les règles sont exprimées comme des lignes , les colonnes sont des clauses et vice versa.
La table de décision montre les règles dans une notation synthétique en arrangeant les expressions d'entrées dans des cellules. Cette notation montre toutes les expressions dans le même ordre dans chaque règle et facilite la vérification par une meilleure lisibilité.
Par exemple:
De manière générale :
Si la valeur de l'expression 1 d'entrée "input expression 1" satisfait la condition "input entry a"
et la valeur de l'expression 2 d'entrée "input expression 1" satisfait la condition "input entry b"
alors la règle est satisfaite et le résultat de la table de décision est la donnée en sortie "output entry c"
Exemples complets :
Rhona Maxwel
@rhona_helena
"L'absence n'est-elle pas, pour qui aime, la plus certaine, la plus efficace, la plus vivace, la plus indestructible, la plus fidèle des présences ?"
Marcel Proust
Articles conseillés :
DMN - L'antisèche de la notation complète des composants d'un DRD ( Decision Requirement Diagram ) : le service de décision
Le service de décision
Un Service de Décision est représenté dans un DRD comme un rectangle avec des coins arrondis, dessiné avec un contour épais.
Si l'ensemble de décisions de production est plus petit que l'ensemble de décisions encapsulées, le Service de Décision sera divisé dans deux parties avec une ligne solide droite. Une partie inclura seulement les décisions de production et le libellé ; l'autre partie inclura toutes les décisions encapsulées qui ne sont pas dans l'ensemble de décisions de production.
L'une ou l'autre partie peuvent inclure d'autres éléments de DRG mais ceux-ci ne feront pas partie de la définition du service de décision.
Pour plus la clarté, le rectangle ou ses parties peuvent être hachurés et tous les éléments comprenant son interface (les décisions de production, des décisions d'apport et les données en entrée) peuvent être dessinées avec une ligne qui correspond à la frontière. Le schéma montre un service de décision avec deux décisions de production ainsi que d'autres exemples.
Rhona Maxwel
@rhona_helena
"L'absence diminue les médiocres passions et augmente les grandes, comme le vent éteint les bougies et allume le feu."
La Rochefoucauld
Articles conseillés :
DMN - L'antisèche de la notation complète des composants d'un DRD ( Decision Requirement Diagram ) : vues partielles et informations masquées
Vues partielles et informations masquées
Le métamodèle fournit des propriétés pour chacun des éléments d'un DRG qui ne seraient pas normalement montrés sur le DRD, et des informations supplémentaires sur leur nature ou fonction.
Par exemple, pour une décision, on a des propriétés spécifiant qu'un processus BPMN et des tâches utilisent la décision.
Les implémentations fourniront des réalisations permettant de spécifier et de montrer de telles propriétés.
Pour n'importe quel domaine significatif de prise de décisions d'un DRD, la représentation du DRG complet peut être un diagramme complexe.
Les mises en œuvre peuvent fournir des vues partielles ou filtrées du DRG, par exemple, en cachant les catégories d'éléments, ou en cachant des zones du graphe.
DMN ne spécifie pas comment de telles vues devraient être représentées, mais quand les informations sont cachées, les implémentations devraient fournir une indication visuelle claire.
Dans le schéma ci-dessous, deux exemples de DRD fournissent des vues partielles d'un DRG :
Le premier DRD représente les exigences immédiates d'une décision seule
Le deuxième DRD représente des exigences d'information et des éléments connectés. Dans le but d'illustration seulement, l'approche prise est d'utiliser le contour brisé pour n'importe quel élément avec quelques exigences cachées.
Rhona Maxwel
@rhona_helena
"Mille raisons de s'affliger, mille raisons d'avoir peur s'emparent jour après jour du sot, mais non
du sage."
Hitopadesa De Narayana
Articles conseillés :
DMN - L'antisèche de la notation complète des composants d'un DRD ( Decision Requirement Diagram ) : notation des règles de connexions
Les règles décrivant les possibilités permises connectant les éléments avec des exigences dans un DRD
Pour plus de clarté, on montre un simple DRD pour chaque connexion permise.
Dans chacun de ces diagrammes, l'élément supérieur exige l'élément inférieur.
Notez qu'aucune exigence ne peut être dessinée en se terminant avec des données en entrée, en somme, les données en entrée ne peuvent avoir aucune exigence.
Notez aussi que le type de l'exigence est uniquement déterminé par les types des deux éléments connectés.
Rhona Maxwel
@rhona_maxwel
"Nous naissons, pour ainsi dire, provisoirement quelque part, c'est peu à peu que nous composons en nous le lieu de notre origine, pour y renaître chaque jour plus définitivement."
Rainer Maria Rilke
Articles conseillés :
DMN - L'antisèche de la notation complète des composants d'un DRD Decision Requirement Diagram : notation des exigences qui font autorité
Notation des exigences qui font autorité
Les exigences qui font autorité peuvent être utilisées de deux façons :
1)
Elles peuvent être dessinés à partir de sources de connaissance jusqu'aux décisions, à partir des modèles de connaissance métiers jusqu'à d'autres sources de connaissance, où elles représentent la dépendance de l'élément DRD à la source de connaissance.
Utile pour enregistrer le fait qu'un ensemble de règles de gestion doit être compatible avec un document publié ( par exemple de législation ), ou une personne spécifique ou un groupe organisationnel responsables de définir un ensemble logique de décision, ou qu'une décision est gérée par une personne ou un groupe.
On montre un exemple de cette utilisation de sources de connaissance dans le schéma ci-dessous, dans ce cas le modèle de connaissances métiers exige deux sources d'autorité - un décret politique lié à un groupe et une loi.
2)
Elles peuvent être dessinées à partir de données en entrée et des décisions jusqu'aux sources de connaissance, où elles représentent la dérivation de modèles de connaissance métiers avec des cas de données en entrée et la décision résultante en utilisant un processus analytique.
La source de connaissance représente typiquement le modèle de processus analytique ; le modèle de connaissance métiers représente la logique exécutable produite dépendant du modèle.
Un exemple de cette utilisation d'une source de connaissance est montré dans le schéma ci-dessous : dans ce cas un modèle de connaissance d'affaires est basé sur un modèle analytique qui est tiré de données en entrée et les résultats d'une décision dépendante.
Il y a beaucoup d'autres cas d'utilisation possibles pour des exigences d'autorité (et puisque les sources de connaissance et des exigences d'autorité n'ont aucune sémantique d'exécution leur interprétation est nécessairement vague), donc cette spécification laisse les détails de leur implémentation au réalisateur.
Une exigence d'autorité est représentée dans un DRD comme une flèche dessinée avec une ligne pointillée et une tête circulaire remplie, comme indiqué dans le tableau ci-dessous.
Les flèches sont dessinées de la source d'autorité à l'élément dirigé elle.
Rhona Maxwel
@rhona_helena
Articles conseillés :
DMN - L'antisèche de la notation complète des composants d'un DRD ( Decision Requirement Diagram ) : notation des exigences de connaissances
Notation des exigences de connaissances
Les exigences de connaissances peuvent être représentées à partir d'un modèles de connaissance métiers jusqu'aux Décisions et à partir d'un modèles de connaissance métiers jusqu'à d'autres modèles de connaissance métiers.
Elles représentent l'invocation de connaissance métiers quand une décision doit être prise.
Elles peuvent aussi être interprétées comme des appels de fonction : un DRD représente seulement des décisions, des connaissance métiers, des modèles et des exigences de connaissance équivalentes à une hiérarchie de fonctionss montrant les appels de fonction impliquées dans l'évaluation des décisions.
Les Exigences de Connaissance d'un DRG valable forment un graphique acyclique dirigé.
Une exigence de connaissance est représentée dans un DRD comme une flèche dessinée avec une ligne pointillée et une pointe de flèche ouverte, comme indiqué dans le tableau ci-dessous.
Les flèches sont dessinées dans la direction du flux d'information du résultat évalué par la fonction, c'est-à-dire vers l'élément qui exige la connaissance métiers.
Rhona Maxwel
@rhona_helena
Articles conseillés :