En quoi l’approche par règles métier est-elle différente ?

Contrairement à l‟approche traditionnelle décrite plus haut, l‟introduction des règles métier et du BRMS par l‟approche par règles métier apporte plusieurs changements dans le processus de modélisation des applications métier, sur les applications métier elles-mêmes, et finalement sur le domaine métier qui utilise ces applications.

La figure 2.7 montre l‟architecture d‟une application orientée règle métier.

Figure 2.7 : Architecture d‟un système orienté règle métier (Diouf, 2007)

Comme présenté sur la figure 2.7, l‟expert métier travaille en étroite collaboration avec l‟expert système pour la spécification et la conception de l‟application. Durant cette phase, il peut être judicieux de mettre en place une ontologie commune afin d‟éviter les ambigüités

45

dans le vocabulaire métier. Comme nous le verrons plus tard au Chapitre 5, cette ontologie est capitale pour la spécification des règles métier et représente le modèle objet métier qui reflète la vue du métier sur les données de l‟entreprise. Les règles métier pertinentes pour les systèmes d‟information sont gérées et exécutées à l‟extérieur de ces applications métier par le BRMS. Un aspect important et clé de l‟approche est que ces règles métier sont spécifiées de façon déclarative par les experts métier en utilisant un éditeur intuitif (en langage naturel). Elles sont ensuite stockées dans un référentiel de règles et gérées par le BRMS (le BRMS est décrit en détail à la Section 2.4.3). Le BRMS inclut un composant pour l‟exécution des règles métier ou moteur de règles (Rule Engine) qui se charge d‟exécuter des règles métier à la demande des applications métier. Les experts système se chargent de la logique applicative et des infrastructures informatiques qui interagissent avec le moteur de règles du BRMS. On constate ici qu‟avec l‟ARM, la logique métier ou décisionnelle est remplacée par l‟invocation du moteur de règles du BRMS qui fournit le code du programme généré à partir de la règle métier explicitement définie par les experts métier. Ceci permet une séparation nette entre la logique métier et les applications métier qui constitue la clé de la traçabilité et de l‟auditabilité de l‟approche (Von Halle, 2001).

Considérons l‟exemple de la règle métier suivante : «Tout client Platinium qui achète plus de

500 articles aura 10% de remise».

Ainsi avec un éditeur en langage naturel, un expert métier pourra entrer la règle comme présentée à la figure 2.8.

46

En effet, les règles métier exprimées en langage naturel par les experts métier ne sont pas directement exécutables et de ce fait, ne peuvent pas être exploitées par les applications métier. Ainsi, elles doivent être d‟abord transformées vers d‟autres langages formels exécutables par les moteurs de règles. Ces langages formels sont la plupart de temps non compréhensibles par les experts métier. Cette transformation des règles métier du langage naturel vers les langages formels exécutable par le moteur de règles peut être prise en compte ou non par le BRMS. Une fois la règle transformée et représentée dans un langage formel, elle est stockée dans un référentiel de règles (Business rule repository) afin d‟être exécutée plus tard par le moteur de règle du BRMS à la demande des applications métier.

La figure 2.9 montre l‟exemple de notre règle métier citée plus haut transformée et représentée dans un formalisme XML.

Figure 2.9: Exemple de règle dans un formalisme XML

Une bonne conception orientée objet doit généralement assigner à chaque fonction spécifique objet une interface qui à son tour va collaborer avec le moteur de règles pour produire le résultat. En considérant notre exemple cité plus haut, une bonne application métier orientée objet aura une méthode setDiscount(10) définie dans la classe Client qui retourne true si

isPlatiniumCustomer() est true et getQuantity() >= 500 est aussi true et false dans le cas

contraire. Dans une application traditionnelle, la méthode doit implémenter la logique métier décrite par la règle métier dans un langage de programmation (Java, C++ ou C#) de façon procédurale avec des boucles et des conditions if/then/else. Dans une application orientée règles métier, la logique métier (décisionnelle) doit plutôt être dans un langage de règle et son

47

exécution est déléguée au moteur des règles métier du BRMS. La bonne pratique est d‟identifier les applications métier qui sont dépendantes des règles métier et interagissent avec le BRMS. En ce qui concerne le déploiement, une application orientée règle métier diffère d‟une application traditionnelle dans le sens que l‟approche applicative est divisée en deux parties : (1) Les règles métier qui sont gérées par un BRMS et (2) le reste des composants logiciels qui sont responsables des autres parties de l‟application (la gestion des objets, des workflows, des services architecturaux, etc.). Ces deux parties sont packagées et déployées séparément.

La principale implication de l‟ARM sur le métier est que les experts métier sont à la charge de la création et de la maintenance des règles métier. Ceci est l‟une des motivations clés pour l‟ARM sur l‟approche traditionnelle qui a un besoin en agilité et en flexibilité face aux changements. Les applications orientées règles métier peuvent évoluer aussi vite que l‟entreprise en a besoin. Le plus important est que les règles métier peuvent être modifiées à chaud12 _{par les experts métier sans l‟intervention des experts système comme le montre la}

figure 2.10. Ainsi, si la politique métier change et qu‟un expert métier juge nécessaire de mettre à jour les règles métier, il lance son éditeur en langage naturel et fait les modifications qui sont ensuite stockées dans la base de règles. Les applications métier référencient toujours la base de connaissance mise à jour.

48

Figure 2.10 : Processus de modification des règles métier (Diouf, 2007) Plusieurs facteurs rendent la maintenance plus facile et rapide (Boyer et Mili, 2011) :

 La compréhensibilité par le métier : les règles métier sont exprimées dans un langage que les utilisateurs métier peuvent comprendre, leur permettant soit de spécifier eux-mêmes leurs règles métier, soit de les valider facilement.

 Le déploiement séparé : puisque les règles métier sont déployées séparément du code source de l‟application métier, nous pouvons avoir un cycle de maintenance et de déploiement des règles métier qui soit séparé du cycle de maintenance et du déploiement de l‟application elle même. La figure 2.11 illustre les différents cycles de maintenance et de déploiement pour le code source des applications métier et pour les règles métier. La partie inférieure de la figure montre le cycle de maintenance et de déploiement pour le code de base de l‟application métier, qui devrait être assez stable. Après un premier déploiement de l‟application, on peut avoir une version de mise à jour ou deux dans la première année, mais après cela, le rythme de changement ralentit considérablement, souvent une fois ou moins. En ce qui concerne les règles métier, nous pouvons avoir de petites mises à jour aussi souvent que nécessaires, peut être tous les jours, etc.

49

 L’exécution séparée : De la même façon que le déploiement séparé, et comme aussi l‟indique la figure 2.7 ci-dessus, les règles métier sont exécutées par le BRMS, à la demande des applications métier. Cela signifie que nous pouvons avoir un déploiement à chaud de nouvelles règles métier, sans arrêter l'application métier.

Figure 2.11: Maintenance and release cycles for application core versus business rules (Boyer et Mili, 2011)