Notions de base de la modélisation décisionnelle

En tant qu'expert métier, vous pouvez modéliser, définir et déployer un service de decision appelé par des applications clientes pour appliquer une décision métier.

Vous créez le service de décision dans Decision Center et vous le déployez dans un environnement d'exécution. Comme illustré dans le diagramme suivant, une application client appelle ensuite le service de décision pour traiter les données:

Diaram montre les interactions entre les composants.

Dans Decision Center, vous pouvez créer des services de décision de deux manières:
  1. Votre équipe de développement crée le modèle sous-jacent, puis vous créez la logique décisionnelle à l'aide de ce modèle.
  2. Vous créez le modèle et la logique dans un service de modélisation décisionnelle.
Cette rubrique présente les deux aspects de la création d'un service de modélisation décisionnelle:
  • Modéliser la structure en noeuds
  • Créer la logique décisionnelle
Remarque: par souci de simplicité, le terme service de décision est utilisé partout, sauf lorsqu'il est nécessaire de distinguer les deux approches ou lorsqu'il s'agit spécifiquement de la partie modélisation du service de décision.

Modéliser la structure en noeuds

Prenons l'exemple d'un service de décision simple qui accueille un client avec une formule de salutation, par exemple, "Bonne soirée Mme Jones".

Le service de décision doit disposer des informations suivantes pour générer le message d'accueil approprié:
  • Nom du client
  • Sexe préféré et n'importe quel diplôme
  • Moment de la journée

Le diagramme suivant modélise le service de décision:

Le diagramme montre le diagramme de modélisation avec des noeuds de données et des noeuds de décision

Du point de vue de la modélisation, vous créez et définissez la relation entre les représentations visuelles des décisions et les données d'entrée.

Dans le diagramme, ces représentations visuelles se nomment noeuds. Le diagramme suivant illustre le noeud de décision Salutation alimenté par le noeud de données Nom:

Le diagramme montre les noeuds Salutation et Nom.

La formule de salutation renvoyée par votre service de décision lorsqu'il est donné à Jones pour le nom serait "Hello Jones".

Pour faciliter la compréhension et la maintenance du diagramme de votre service de décision, vous pouvez rendre un noeud de décision dépendant d'autres noeuds de décision. Par exemple, pour affiner votre service de décision afin qu'il renvoie une formule de salutation basée sur l'heure de la journée, vous créez un autre noeud de décision appelé Greeting qui utilise l'heure comme entrée, et vous liez le noeud de décision de sorte que son résultat puisse être utilisé par le noeud Salutation:

Le diagramme montre les noeuds du service de décision.

La formule de salutation renvoyée par votre service de décision lorsqu'on lui a donné le nom de Jones à 8PM serait "Bonsoir Jones."

Pour ajouter un titre de courtoisie (par exemple, M., Mme ou Dr) pour personnaliser davantage la formule de salutation, vous créez un noeud de décision appelé Courtesy Title et vous l'alimentez en utilisant deux noeuds de données: le sexe et le degré. Ce noeud de décision alimente le noeud de décision final comme le noeud Greeting:

Le diagramme montre les noeuds du service de décision.

La formule de salutation renvoyée par votre service de décision lorsqu'elle est donnée à Jones à 8PM avec le sexe Mme et aucun diplôme serait "Bonsoir Mme Jones".

Lorsqu'une application client fournit les informations, votre service de décision traite ces données et retourne la décision. Pour résumer la partie modélisation :
  • Vous créez et interconnectez les noeuds de décision et les noeuds de données.
  • Vous concevez chaque noeud de décision pour qu'il accepte des données d'entrée et envoie son résultat au noeud au-dessus de lui ou à l'application client. La manière dont le résultat est obtenu est décrite dans la section Création de la logique décisionnelle ci-dessous.

Modèle de données

Le terme modèle de données peut être utilisé pour distinguer les différents aspects de données du modèle de décision.

La modélisation des données nécessite de créer des noeuds de données, mais aussi d'affecter le type approprié à chacun de ces noeuds. L'affectation d'un type à un noeud spécifie les détails suivants:
  1. Informations que le noeud peut accepter et envoyer, par exemple, un nombre ou une date.
  2. Les possibilités qui s'offrent à vous lorsque vous créez la logique de décision.
Dans l'exemple suivant, quatre noeuds de données différents de différents types alimentent l'approbation du noeud de décision:

Le diagramme montre les noeuds du service de décision.

Dans ce diagramme, les quatre noeuds de données sont disposés à plat. Cependant, il est souvent plus pratique de créer des types personnalisés qui regroupent les données connexes sous une même entité. Le diagramme ci-dessous contient les mêmes données d'entrée que le diagramme ci-dessus, mais tous les noeuds de données relatifs au prêt sont regroupés sous un noeud qui gère les données d'un type personnalisé loan:

Le diagramme montre les noeuds du service de décision.

La modélisation des données est décrite plus en détail dans la rubrique En savoir plus sur la modélisation des données: types personnalisés, valeurs par défaut, listes, qui explique également les valeurs par défaut que vous pouvez définir sur les noeuds de données.

Remarque: Comme le montre le diagramme suivant, l'exemple utilisé jusqu'à présent est simple. Un service de décision plus complexe peut comporter plusieurs noeuds de décision de niveau supérieur pour renvoyer plusieurs décisions à l'application client. De plus, un noeud de données peut alimenter plusieurs noeuds de décision.

Le diagramme montre les noeuds du service de décision.

Créer la logique décisionnelle

Vous créez la logique de chaque noeud de décision en créant une ou plusieurs règles métier pour effectuer les processus suivants:
  • Évaluent les données d'entrée reçues par chaque noeud de décision en les confrontant à des conditions que vous établissez.
  • Exécutent les actions nécessaires pour fixer ou modifier la sortie du noeud de décision, c'est-à-dire la décision.
Ces règles métier sont simplement vos stratégies métier exprimées sous la forme suivante, qui est comprise par un ordinateur:
if 
  <conditions>
then 
  <actions>

Considérez un service de décision qui décide si un client est éligible à une remise pour étudiant, en fonction du fait que le client est âgé de moins de 18 ans et qu'il est étudiant. Le modèle de décision comporte deux noeuds de données (âge du client et catégorie) qui alimentent le noeud de décision Remise Student:

Le diagramme montre les noeuds du service de décision.

Vous implémentez la logique décisionnelle du noeud de remise Student en créant la règle métier suivante:

L'image montre la règle.
Dans cet exemple, le contenu de la règle métier est codé par couleur pour illustrer les différents blocs de construction à votre disposition lors de la création ou de la modification d'une règle métier:
  • Les parties orange représentent les données d'entrée ou de sortie disponibles pour le noeud de décision.
  • Les parties grises représentent les valeurs de données que vous identifiez comme pertinentes pour la création de la logique décisionnelle.
  • Le reste correspond au langage de modélisation lui-même, qui est utilisé pour comparer, évaluer et modifier les différents types de données (voir Decision Center modeling language reference).

Les données traitées par un noeud de décision (sa sortie et les données des noeuds qui l'alimentent directement) peuvent être utilisées immédiatement lors de la création de vos règles métier, sous la forme 'the <data>'. Dans l'exemple, Student discount est utilisable dans les règles en tant que 'the student discount', Customer age est utilisable en tant que 'the customer age'et Category est utilisable en tant que 'the category'.

Pour illustrer ce point important, à chaque fois que vous créez une nouvelle règle, Decision Center évalue les données disponibles en entrée du noeud de décision dans lequel vous créez la règle. Puis il propose comme point de départ :
  1. Une instruction de condition typique (dans la partie if) comparant la donnée d'entrée en fonction de son type. Il propose une instruction de condition pour toutes les données disponibles pour le noeud, mais vous pouvez les effacer, car toutes les règles n'agissent pas sur toutes les données d'entrée en même temps.
  2. Une instruction d'action (dans la partie then) fixant la valeur de la sortie du noeud en fonction de son type.

L'image montre une règle dans l'éditeur.

Remarque: Le langage de modélisation contient des aspects qui rendent vos règles métier plus lisibles. Par exemple, le mot clé decision peut être utilisé de manière interchangeable avec le nom du noeud. Cet aspect important de la règle est ainsi plus facilement identifiable dans un rapport ou autre.

Couverture

Lorsque vous créez un noeud de décision, vous créez les règles métier requises pour prendre une décision pour les cas possibles que l'application client peut fournir en tant que données d'entrée. Il s'agit de la couverture. Généralement, une décision exige que plusieurs règles métier couvrent autant de cas que possible:

Le diagramme présente des noeuds contenant plusieurs règles.

Pour gérer les situations dans lesquelles il existe de nombreuses conditions possibles pour les données d'entrée fournies, vous pouvez utiliser des tables de décision, qui regroupent des règles métier ayant une structure commune mais des valeurs différentes pour les conditions et les actions. Par exemple, pour fixer un score salarial (salary score) d'après le revenu annuel (yearly income), il faut de nombreuses règles métier afin de couvrir les différentes fourchettes de revenus. La table de décision gère ce cas de figure d'une manière plus simple :

L'image montre la table de décision.

Chaque ligne d'une table de décision représente une règle métier complète. Les colonnes de gauche contiennent les conditions (la partie if de la règle) et la colonne de droite affiche la décision renvoyée par la règle.

Pour que la couverture soit complète, la logique décisionnelle peut nécessiter une ou plusieurs tables de décision et quelques règles métier. Notez que dans ces cas, l'ordre dans lequel les règles apparaissent dans votre noeud est important.