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