EURODECISION publie le livre blanc « Le BRMS, brique par brique », guide pédagogique dont l’objectif est d’aider toute personne curieuse des systèmes de règles à entrevoir la pratique des Business Rules Management Systems de manière simple et ludique.
Découvrez ci-dessous un résumé de ce livre blanc, qui vous incitera peut-être à employer les systèmes experts lors d’un prochain projet !
Téléchargez le livre blanc Le BRMS, brique par brique
Le BRMS, ou « moteur de règles », ou « système de règles », ou bien d’autres noms encore, est un outil de travail pour le développement d’applications, qui permet de séparer la logique métier, représentée par les règles, de la logique informatique, représentée par un socle technique directement écrit dans le langage sous-jacent (Java, en général).
Il permet de prendre des décisions complexes – complexes en termes de règles, de cas et d’exceptions – tout en facilitant l’évolution de la logique derrière ces décisions. La maintenance de la « base de connaissances » est aisée et – vous me pardonnerez ce terme de consultant – agile ; elle peut même être pratiquée par un non-développeur si la modélisation adoptée est suffisamment bonne.
Dans un BRMS, il y a : un dialecte pour écrire les règles, un moteur d’inférence pour les interpréter, différents outils permettant d’ordonner, structurer, déployer, etc., et une interface user-friendly pour que l’écriture des règles ne soit pas l’apanage des seuls développeurs (ils sont bien assez prétentieux). Pour apprendre à utiliser tout ce joyeux bazar, nous allons parler Lego©.
La base de notre travail, la pièce plus élémentaire, semblable au bloc 2-2, c’est l’objet Java. Tout comme il faut bien choisir ses blocs simples avant de se lancer dans une construction libre en Lego©, il faut bien constituer son modèle objet avant de se lancer dans l’écriture d’un système de règles. Chaque objet doit refléter un concept métier bien identifié, ayant un rôle bien défini dans la prise de décision que l’on veut automatiser. L’écueil classique est d’écrire la règle dans sa tête, puis de créer un objet qui représente une partie de ce que fait la règle, sans qu’il n’ait une vraie signification pour l’utilisateur. Il importe aussi de savoir à quelle échelle opère l’objet ; par exemple, est-ce que l’on considère un volume par produit, ou par catégorie de produit ?
La prochaine pièce dont on va parler est une simple plaque rectangulaire, représentant la partie condition de la règle. Elle rassemble des patterns de condition, qui ne sont autres que nos blocs/objets Java, et les bitoniaux avec lesquels on les agrémente. Le premier genre de bitoniau est le test logique, qui ajoute une condition simple au déclenchement de la règle ; par exemple : l’âge du capitaine est supérieur à 12. La seconde catégorie est la captation de valeur, qui permet d’enregistrer une valeur de l’objet considéré pour l’utiliser dans un autre test, d’un autre pattern. On peut donc la voir comme un bitoniau permettant d’attacher ensemble deux briques simples Lego (les deux patterns). Par exemple : on capte l’âge dans le pattern « capitaine », et on le compare à l’âge dans le pattern « second » pour former la condition « si le capitaine est plus vieux que le second».
Ensuite vient la partie conséquence de la règle, une plaque toute en longueur, puisque les éléments qu’on accroche dessus – de simples instructions Java – sont à considérer dans l’ordre où ils ont été écrits. Tout ce qu’on peut écrire en Java, on peut le mettre dans une règle.
Une règle de BRMS n’est rien de plus que cela : une condition, rassemblant des patterns, eux-mêmes affectés de tests et éventuellement liés entre eux, et une conséquence, qui n’est autre qu’une série d’instructions dans le langage informatique sous-jacent. À chaque fois que l’ensemble de patterns est reconnu parmi les objets que manipule le moteur d’inférence, celui-ci déclenche la règle et commande une série d’actions pour modifier lesdits objets, ou en créer de nouveau, ou en retirer.
Bien sûr, à cela viennent s’ajouter quelques pièces plus subtiles. La négation est une sorte de brique transparente à travers laquelle on regarde un bloc-pattern et tous ses bitoniaux, pour finalement prendre leur inverse (« il n’y a pas de Visiteur de plus de 12 ans »). L’accumulation est une grande pièce d’allure étrange sur laquelle on vient greffer un pattern, ou plusieurs patterns liés par des bitoniaux, pour capter ou tester une information globale (la somme des prix de Billet de tous les Visiteurs par exemple). La salience, ou priorisation, est une façon de définir un sens au sein de votre construction, comme en lui ajoutant une entrée et une sortie. C’est pratique, mais fondamentalement, il s’agit d’introduire une composante procédurale dans un système qui n’est pas en ordre chronologique. Comme la pizza au petit dej, ça peut être mal vu, mais tout le monde le fait à un moment ou un autre.
Et… on a à peu près fait le tour du matériel. À vous d’utiliser ces différentes pièces pour représenter le plus fidèlement – et le plus simplement possible – les processus de décision de votre client, de vos collègues ou de votre coloc si vous êtes désœuvré. Tout en prenant garde à ne pas créer de boucle logique entre vos règles, et à ne pas évaluer trop souvent vos patterns parmi les objets à disposition pour ne pas encrasser le moteur d’inférence et ternir les performances de votre outil.
Le reste n’est que de la structuration – rassembler les règles en grandes étapes et chaîner les étapes pour faire un processus de décision – et de l’habillage, c’est-à-dire la constitution d’une application autour du moteur d’inférence, pour savoir quand et comment il déclenche tel ou tel processus, et sur quelles données. Mais bon, comme chacun sait, c’est le travail de détail qui est le plus fastidieux quand on fait des Lego©. L’assemblage final est chose aisée. À noter que les BRMS jouissent d’une modularité bien pratique : tout comme on peut transposer le réacteur d’un vaisseau Lego© sur un autre, on peut utiliser un même ruleflow group (une étape de décision) au sein de plusieurs processus de décision. Ou encore incorporer un processus de décision à un autre.
Les possibilités de modélisation sont nombreuses avec cet outil, mais surtout, il permet de faire évoluer sans cesse lesdits modèles pour épouser les besoins variables et les humeurs changeantes de l’expert métier. En ce qui me concerne, les BRMS, pas plus que les Lego©, ne sont faits pour suivre un mode emploi et poser sa création sur une étagère où elle prendra la poussière.
