Qu’est-ce qu’une règle métier ?

Une règle métier [Ross, 2009a] est une règle qui n’a de sens que dans la juridiction d’une entreprise (ou d’une organisation) et qui guide la conduite et l’action de celle-ci dans la vie de tous les jours. Elle est très souvent définie sous deux angles. Considérées du point de vue des acteurs métier, les règles sont destinées à contrôler ou à influencer les comportements de l’entre-prise. Et du point de vue du système d’information de l’entreprise, les règles servent à exprimer des contraintes sur la création, la mise à jour et la suppression de ses données persistantes.

C’est sous ce double point de vue qu’il faut comprendre le terme « règle métier »manipulé dans le cadre du projet OntoRule (ainsi que dans cette thèse). Nous nous intéressons à la modélisa-tion des règles métier qui sont représentées dans le système d’informamodélisa-tion de l’entreprise. Cette modélisation couvre tout le cycle de vie des règles métier dans développement du système d’in-formation [Zachman, 1987], de leur spécification par des experts métier à leur mise en œuvre dans des applications fonctionnelles. Les règles y sont représentées sous différentes formes suc-cessives, allant d’un caractère informel à un caractère formel et automatisable. La figure II.2 , tirée des travaux du BRG (Business Rule Group¹) [BRG, 2000], nous décrit ce cycle de vie. Elle montre que toute règle métier ("Business Rule") est définie à partir d’une formulation de règle métier ("Business rule statement") qui elle-même est définie à partir d’une politique ("Policy").

Une politique définit une directive générale de l’entreprise qui caractérise le cadre juridique associé à une règle métier (ex. : "We only rent cars in legal, roadworthy condition to our cus-tomers."). Elle peut être à l’origine d’une ou plusieurs formulations de règle métier. Chacune de ces dernières est un énoncé déclaratif d’une contrainte sur un aspect d’une politique d’une entreprise (ex. :"the car should be scheduled for service when accumulated mileage since the last service is greater than 5000, or the brakes are not satisfactory, or ..."). Une formulation de règle métier peut être à l’origine d’une ou plusieurs règles métier. Une règle métier quant à elle décrit aussi une contrainte d’un aspect d’une politique de l’entreprise. Et contrairement à une formulation de règle métier, une règle métier ne peut être décomposée en plusieurs autres règles plus détaillées. Une règle métier doit alors être atomique (ex. : "A car with accumulated mileage greater than 5000 since its last service must be scheduled for service.").

Ces trois premiers niveaux (politique, formulation de règle métier, et règle métier) consti-tuent la partie informelle de l’usage des règles métier ; à ces niveaux les règles sont transcrites dans un langage humain compréhensible par tout expert métier. Ils précédent le niveau formel des règles métier ("Formal rule statement"), dans lequel les règles sont mises dans une forme automatisable. Pour cela, chaque règle métier est traduite en une représentation respectant une

1. http ://www.businessrulesgroup.org

Chapitre II. Les règles métier

grammaire formelle spécifique.

Figure II.2 – Cycle de vie des règles métier.

Dans cette thèse, nous nous intéressons particulière au caractère atomique des règles métier (voirIV). Cette atomicité d’une règle métier peut se vérifier à travers un ensemble de cinq tests décrits dans [Ross, 2010] :

Test 1: une règle métier doit pouvoir être mise en pratique. Elle doit avoir un sens vital pour le système d’information de l’entreprise c’est-à-dire qu’elle s’exprime en des termes qui trouvent leur sens dans le système d’information. Le fait qu’une règle ait un sens pour l’entreprise n’implique pas forcément qu’elle soit utile pour le système d’information de l’entreprise. Il arrive qu’elle existe uniquement pour des besoins de gestion interne sans avoir un intérêt concret pour le système.

Test 2: une règle métier doit exprimer des faits ou des actions de l’entreprise sur les données persistantes de son système d’information. Elle ne doit pas s’appliquer sur les données propres aux systèmes qui les mettent en œuvre.

Test 3 : une règle métier doit s’exprimer dans un langage métier et non dans un langage système. Autrement dit, un expert métier doit être en mesure de comprendre la règle sans avoir de connaissances significatives des technologies système. L’expert devrait travailler dans les termes métier et non système.

Test 4: une règle métier doit s’exprimer dans la juridiction de l’entreprise suivant les besoins du système d’information.

Test 5 : une règle métier doit contrôler ou restreindre des comportements métier et faciliter la prise de décision.

II.1 Quelques définitions

Considérons les exemples suivants :

Exemple 1 : « Un identifiant doit être annulé si son utilisateur se loggue avec un mot de passe incorrect plus de 5 fois.»

Cet exemple vérifie le test 1 et le test 3, il peut être mis en pratique et est facilement compréhensible par les gens du métier. Mais il ne vérifie pas le test 2, il s’exprime sur des données système, donc ce n’est pas une règle métier.

Exemple 2: « Une personne qui se loggue dans le système comme un arbitre junior ne peut accéder qu’aux informations disponibles sur la base de données du serveur client. » Cet exemple vérifie le test 1 mais ne vérifie pas les tests 2 et 3. Il s’applique sur des données système et de plus nécessite des connaissances en langage technique système pour être compris.

Exemple 3: « Un compte bancaire peut être détenu par une personne quel que soit son âge.» Cet exemple vérifie les trois premiers tests, il a un intérêt concret pour le système d’infor-mation, il s’applique sur des données de ce système et il s’exprime dans un langage métier compréhensible par les gens du métier. Toutefois, même s’il est conforme avec les besoins du système d’information, il ne contraint et ne restreint aucun comportement métier.

Exemple 4: « An order over $1,000 must not be accepted on credit without a credit check » Cet exemple spécifie qu’une commande dont le montant est supérieur à 1000$ n’est accep-tée à crédit que sous réserve d’une vérification de solvabilité. L’exemple vérifie l’ensemble des tests cités et donc il s’agit d’une règle métier valide.

Et enfin, on distingue trois types de règles métier atomiques [BRG, 2000, OMG, 2008] : – Les règles structurelles. Un terme métier est un mot ou un groupe de mots ayant

un sens spécifique pour le métier. Les données persistantes du système d’information décrivent des faits qui relient des termes métier. Une règle structurelle sert à décrire une contrainte sur un fait ("un client peut passer une commande" ou même "un client ne peut passer plus d’une commande à la fois"). Les faits correspondant à des définitions de termes ("Une voiture est un moyen de transport"), à des déclarations d’attributs (propriétés) de termes ("Une ’voiture’ doit avoir une propriété ’couleur’") ou alors à des associations de termes ("location de voiture") sont aussi des règles structurelles. Logiquement, une règle structurelle est une règle qui est toujours vraie, qui décrit des propriétés toujours valides.

Elle est souvent représentée sous la forme : Si condition vraie alors conclusion vraie où la condition est un fait ou une combinaison logique de faits et la conclusion est un fait.

– Les règles opératoires définissent une deuxième catégorie de contraintes qui s’ap-pliquent sur les opérations de manipulation des données persistantes. Elles sont utilisées

Chapitre II. Les règles métier

pour mettre à jour (création, modification, suppression) les données du système d’infor-mation. Elles servent beaucoup à la prise de décision, sont déclenchées par un évènement particulier et conduisent à l’exécution d’une action. Logiquement, elles sont représentées sous la forme Si condition vraie alors Action ou Quand condition vraie Nécessaire Action (la condition et l’action constituent chacune un fait ou une combinaison logique de faits). Par exemple dans cette règle opératoire« Une location de voiture doit être enre-gistrée avec un numéro de registre», ’location de voiture’ est le fait déclencheur et l’action est l’enregistrement de cette location sous un numéro de registre.

– Les règles dérivationnellessont des règles opératoires particulièrement utilisées pour les calculs ou les inférences (déduction à partir d’un fait général ou induction à partir d’un fait particulier) et qui dérivent de nouvelles connaissances (faits) à partir des connaissances existantes. Par exemple : «Le montant de l’assurance de location est calculé à partir du taux de l’assurance et du nombre de jours».