Instructions: Règles métier
Une règle métier représente une exigence concernant la façon dont le métier, y compris ses outils métier, doit fonctionner. Ces instructions expliquent comment identifier et modéliser des règles métier.
Relations
Eléments connexes
Description principale

Explications

Les règles métier sont des types d'exigences concernant la façon dont le métier, y compris ses outils métier, doit fonctionner. Il peut s'agir de lois et de réglementations imposées au métier, mais elles peuvent également résulter du choix d'une architecture métier et d'un style. Il existe deux manières d'enregistrer les règles métier :

  • Par modèle : les règles métier sont enregistrées en tant que contraintes stéréotypées dans des modèles UML. Une règle peut être établie en langage naturel ou au moyen d'une notation plus formelle comme le langage OCL (Object Constraint Language). L'avantage de cette technique consiste dans le fait que les règles métier sont enregistrées et affichées dans la source à laquelle elles s'appliquent. Son principal inconvénient est que les règles métier sont réparties sur l'ensemble du modèle, ce qui ne facilite pas la visualisation des règles métier associées. Le Rapport : Vue d'ensemble des règles métier fournit, comme son nom l'indique, une vue d'ensemble de toutes les règles métier du modèle. 
  • Par document : les règles métier sont enregistrées dans un document distinct. Ce document contient des règles métier, mais il ne s'agit pas des règles métier utilisées dans l'approche par modèle évoquée plus haut. L'approche par document est utile lorsque de grandes quantités de règles métier s'appliquent (par exemple pour des produits financiers). Un inconvénient de cette méthode est que les règles métier sont enregistrées dans un artefact différent de la source à laquelle elles s'appliquent.

Enregistrement des règles métier

Les règles métier peuvent être enregistrées aussi bien dans un modèle que sous forme de document. Pour obtenir une vue d'ensemble des règles métier des modèles, vous pouvez générer un Rapport : Vue d'ensemble des règles métier.

Un document de règles métier est particulièrement utile dans le cas de règles métier contenant de longues descriptions comme les textes de loi. L'inconvénient de la méthode par document est qu'il peut s'avérer nécessaire de continuer à tracer la règle métier vers toutes les parties du modèle auxquelles elle s'applique (s'il y en a plusieurs). On peut contourner le problème en choisissant la méthode par modèle, qui consiste à enregistrer les règles métier directement dans les modèles auxquels elles s'appliquent. Cette dernière méthode présente cependant l'inconvénient de "dissimuler" les règles dans le modèle ; il est alors moins aisé d'obtenir une vue d'ensemble de toutes les règles métier partageant des caractéristiques communes (par exemple l'appartenance à une catégorie donnée).

Niveaux de formalisme

Les règles métier doivent être formulées avec rigueur et de manière formelle, de façon à pouvoir servir de base à l'automatisation. Une autre solution consiste à utiliser le langage OCL tel qu'il est défini dans le langage UML (Unified Modeling Language) [RUM98].  Cherchez toujours à identifier le destinataire des règles métier. Cela vous permettra de vous assurer que la méthode d'enregistrement des règles métier (par document ou par modèle), le style choisi et le niveau de formalisme sont bien adaptés au lecteur cible. Des règles métier inintelligibles pour ceux pour qui elles ont été écrites représentent une perte de temps dans tout projet.

Exemple : 

Vous voulez définir la taille limite d'une équipe à 10 personnes maximum. En langage OCL, vous pouvez établir la règle métier suivante en tant qu'invariant :

context Team inv:

    self.numberOfMembers <= 10

Cependant, vous devez prendre en compte le fait que le formalisme de ce type de langage peut rendre son interprétation difficile pour nombre des parties prenantes ; il peut donc être préférable de recourir à un style de langage plus naturel. Vous pouvez ainsi définir un ensemble d'expressions réservées que vous utiliserez pour écrire les règles. Ces expressions peuvent être calquées sur celles définies dans [ODL98] : 

  • SI
  • SEULEMENT SI
  • QUAND
  • ALORS
  • SINON
  • IL FAUT TOUJOURS CONSIDERER QUE
  • S'EST TERMINE CORRECTEMENT

Exemple : 

Dans ce langage moins formel, l'exemple ci-dessus donnerait :

IL FAUT TOUJOURS CONSIDERER QUE le nombre de membres de l'équipe doit être inférieur ou égal à 10. 

Catégories de règles métier

Les règles peuvent être classées de plusieurs façons, la plus répandue consistant à distinguer les règles de contraintes des règles de dérivation. [ODL98] Ces deux catégories peuvent être à leur tour subdivisées comme suit : 

  • Les règles de contraintes définissent les principes ou conditions limitant la structure ou le comportement d'un objet. Ce type de règles peut s'appliquer de façon systématique ou uniquement dans certaines conditions. Les contraintes s'appliquant de manière systématique sont appelées invariants.
  • Les règles de stimulus et de réponse limitent le comportement en déterminant quand et si les conditions doivent être vraies de façon à déclencher le comportement. 
  • Les règles de contraintes d'opération définissent les conditions devant rester vraies avant et après une opération afin de garantir une exécution correcte de l'opération. 
  • Les règles de contraintes de structure définissent les principes ou conditions concernant des classes, des objets et leurs relations qui doivent être respectées. 
  • Les règles de dérivation définissent les principes ou conditions relatifs à l'inférence ou au calcul de faits à partir d'autres faits. 
  • Les règles d'inférence définissent que, si certains faits sont vrais, une conclusion peut être induite. 
  • Les règles de calcul obtiennent leurs résultats par des algorithmes de traitement, variante plus sophistiquée des règles d'inférence. 

Cette classification est très utile pour expliquer ce que sont les règles métier, comment les trouver et comment les utiliser. Cependant, il n'est pas nécessaire de les envisager comme des regroupements fixes auxquels il convient de toujours se référer. C'est pourquoi le canevas de l'artefact de règles métier que nous proposons ne présente pas cette classification ; votre projet comportera à n'en pas douter d'autres types de regroupements (par domaine, par utilisateur ou par groupe de produits), qui auront beaucoup plus d'intérêt. Pour obtenir plus d'informations sur la classification et l'application des règles métier, voir [ROS97].

Comment les règles métier se reflètent dans les modèles

Une règle métier a une incidence sur l'apparence des modèles. Elle peut également influer sur le séquençage des tâches dans le diagramme d'activité, et même sur les associations existant entre les entités métier. Il n'est pas toujours facile de convertir certaines règles de manière simple de façon à ce qu'elles adoptent l'apparence du diagramme ; il peut alors être nécessaire de les faire résider dans les descriptions des éléments de modèle. 

Les règles métier d'un diagramme UML doivent être liées à l'élément de modèle sur lequel elles influent. 

Il est également utile d'effectuer le suivi des règles métier dans les attributs d'exigence à des fins de traçabilité et de génération de rapports.

Règles de stimulus et de réponse

Ce type de règles métier influe sur l'enchaînement d'activités d'un cas d'utilisation métier et peut être tracé vers le cas d'utilisation métier auquel il s'applique. Vous pouvez afficher un chemin conditionnel ou un chemin alternatif dans l'enchaînement d'activités. Si les actions impliquées sont moins significatives, l'inclusion de l'évaluation de la règle métier dans un état d'activité peut suffire. 

Dans le modèle d'analyse métier, une règle de ce type pourrait par exemple influer sur la façon vous décrivez le cycle de vie d'une entité métier ou faire partie de la description d'une opération sur un travailleur métier. L'examen des événements métier identifiés est une source très utile permettant de définir ces types de règles métier. En général, un événement métier est identifié car quelque chose ou quelqu'un souhaite que cet événement se produise. La question suivante se pose : "Quelles conditions ou quel comportement s'applique lorsque l'événement se produit ?"

Exemple : 

Dans le cas d'une organisation de gestion des commandes, vous pouvez trouver la règle suivante : 

QUAND une Commande est annulée

SI Commande n'est pas expédiée

ALORS fermer Commande. 

Cette règle métier se reflète en affichant deux chemins alternatifs dans un enchaînement d'activités et en utilisant explicitement une condition de décision et de garde sur les transitions émises. 

Diagramme décrit dans le texte d'accompagnement.

Dans ce cas, la règle métier est convertie en chemin alternatif dans l'enchaînement d'activités.

Règles de contraintes d'opération

Les règles métier de ce type sont souvent converties en préconditions et postconditions dans un enchaînement d'activités ou en chemin conditionnel ou alternatif dans un enchaînement d'activités. Il peut également s'agir d'un objectif de performance ou d'une autre règle non comportementale devant être tracée vers les cas d'utilisation métier auxquels elle s'applique. 

Exemple : 

Dans le cas d'une organisation de gestion des commandes, vous pouvez trouver la règle suivante : 

Expédier Commande au Client

SEULEMENT SI Client a une adresse de livraison. 

Diagramme décrit dans le texte d'accompagnement.

La règle métier est convertie en chemin alternatif dans l'enchaînement d'activités.

Exemple : 

Autre règle de contraintes d'opération : 

IL FAUT TOUJOURS CONSIDERER QUE

Toutes les demandes des clients doivent être traitées dans les 24 heures suivant leur réception

Cette règle métier serait convertie en objectif de performance d'un cas d'utilisation métier. Reportez-vous à la section consacrée aux objectifs de performance dans les Instructions : Cas d'utilisation métier

Règles de contraintes de structure

Ce type de règle métier influe sur les relations entre les instances des entités métier. Elles sont exprimées par l'existence d'une association entre les deux entités métier, parfois en tant que multiplicité de l'association.  

Exemple : 

Dans le cas d'une organisation de gestion des commandes, vous pouvez trouver la règle suivante : 

IL FAUT TOUJOURS CONSIDERER QUE

une Commande se réfère à au moins 1 Produit. 

Diagramme décrit dans le texte d'accompagnement.

Cette règle métier est convertie en association dont la multiplicité est de 1..*. 

Règles d'inférence

Les règles d'inférence paraissent souvent semblables aux règles de stimulus et de réponse, ainsi qu'aux règles de contraintes d'opération ou de structure. Mais dans le cas des règles d'inférence, il faut passer par quelques étapes avant d'arriver à la conclusion. Cette règle implique le recours à une méthode qui doit être reflétée dans un état d'activité de l'enchaînement d'activités, puis dans une opération d'un travailleur métier ou d'une entité métier. 

Exemple : 

Vous pouvez définir la règle suivante pour déterminer le statut d'un client :

Un Client est un Bon Client SI ET SEULEMENT SI

les factures impayées envoyées à ce Client ont moins de 30 jours. 

Diagramme décrit dans le texte d'accompagnement.

Cette règle métier correspond à un chemin alternatif dans l'enchaînement d'activités et la méthode prescrite fera partie de la tâche Evaluer le client.

Règles de calcul

Les règles de calcul ressemblent beaucoup aux règles d'inférence. Mais dans le cas des règles de calcul, la méthode est plus formelle et fait penser à un algorithme. Tout comme pour les règles d'inférence, cette méthode doit être tracée vers une tâche de l'enchaînement d'activités, puis vers une opération d'un travailleur métier ou d'une entité métier. 

Exemple : 

Une règle de calcul peut définir le calcul de valeurs : 

Le prix net d'un Produit EST CALCULE COMME SUIT

prix du produit * (1+pourcentage de taxe/100).

L'évaluation du prix net peut faire partie de la tâche Expédier la commande car la facture générée est envoyée avec la commande. Dans le modèle d'analyse métier, cette règle est convertie en associations et opérations. 

Diagramme décrit dans le texte d'accompagnement.

Cette règle doit être reflétée en tant que méthode dans l'opération de calcul du prix net, mais elle implique également l'existence de relations entre les classes du modèle.