Systèmes de gestion de règles métier

Systèmes de gestion de règles métier

          

« Un système de gestion de règles métier ou SGRM (en anglais Business Rules Management System, ou BRMS) est un logiciel qui gère et supporte les règles métier d'une organisation ou d'une entreprise. Le système de gestion de règles métier est une brique du système d'information durable. »   - Wikipédia

 

A - Les moteurs de règles :

 

  • - Qu’est-ce ?

Un moteur de règles métier permet, entre autres, d’enregistrer, de définir, de classer et de gérer toutes les règles, de vérifier leurs cohérences et associe certaines de ces règles aux applications informatiques concernées ou devant faire l'objet d'une ou plusieurs règles.

 

  1. Les règles métiers?

Ce sont des règles qui servent à définir ou restreindre certaines opérations dans la vie d’une société.

Elles dépendent évidemment du secteur dans lequel évolue l’entreprise (bien que l’on puisse dégager certaines règles communes a beaucoup de secteurs), et sont très importantes pour guider les comportements à adopter. Où, quand, quoi, comment et pourquoi , telle action plutôt qu’une autre ?

Une règle est composée d’un ensemble de conditions et d’un ensemble d’actions exécutées uniquement si les conditions précédentes sont réunies.

Si un ensemble de conditions est vrai…

… alors on exécute un ensemble d’actions

Les règles permettent d’exprimer facilement des solutions à des problèmes difficiles et de les vérifier également. Contrairement aux codes, les règles sont écrites dans un langage moins complexe. Les analystes métier peuvent facilement lire et vérifier un ensemble de règles.                Les données résident dans les objets de domaine et la logique applicative dans les règles. Selon le type de projet, ce type de séparation peut être très avantageux.                S'il y a des demandes de changement fréquentes, on peut ajouter de nouvelles règles sans avoir à modifier les règles existantes : Centralisation de la connaissance.                En utilisant des règles, vous créez un référentiel de connaissances (une base de connaissances) exécutable. C'est un point de vérité unique pour la politique d'entreprise. Idéalement, les règles sont tellement lisibles qu'elles peuvent également servir de documentation.

 

2   -   Pourquoi ?

 

  • La règle métier évolue fréquemment (stratégie de l'entreprise, politique tarifaire, réglementation...)
  • La règle métier est utilisée dans plusieurs applications et donc répliquée plusieurs fois
  • La modification de cette règle métier devrait être rendue possible pour les équipes fonctionnelles
  • La centralisation permet de limiter la duplication de la règle et donc limiter les coûts de maintenance évolutive et corrective
  • La centralisation permet de versionner les règles métiers et simuler l'impact d'une modification dans un environnement de test
  • L'écriture en langage naturel permet de proposer aux fonctionnels de modifier directement les règles métiers et ainsi raccourcir le délai de mise en place d'une évolution

     B -   DROOLS :

         Drools (ou JBoss Rules) est une plateforme d’intégration de logique métier « Buisiness Logic Integration Platform (BLiP), écrit en Java, développé par JBoss, distribué par Red Hat et sous licence Apache 2.0µ. Il se repose sur l’algorithme de Rete, pour optimiser ses performances.

 

  1. Algorithme de Rete :

 

Il a été créé en 1979 par M. Charles L. Forgy de l’université Carnegie-Mellon, et est depuis la base de plusieurs moteurs de règles tels que : Clips, Jess, Drools, Ilog JRules, Soar...etc . Il est écrit en Java et est open source

«  L'algorithme de Rete fournit la représentation logique globale d'une fonctionnalité d'un système de connaissance expert à partir de l'association d'une base des faits(« working memory ») avec une base de règles (« production memory ») dans un système de production de filtrage par motif (pattern matching system, une catégorie de moteur de règle). Une production se compose d'une ou plusieurs conditions et d'un ensemble d'actions qui peuvent être entreprises pour chaque ensemble complet de faits répondant aux conditions. »  - Wikipedia

 

1 ) Installation :

Pour l’installation de Drools, il faut tout d’abord disposer de l’IDE Eclipse, puis se rendre sur le site : https://www.drools.org/.  De là, vous pourrez télécharger la dernière version, aujourd’hui il s’agit de la : 7.15.0.

 

1 - Télécharger le zip indiquer, et dézipper le.

 

  • - Créer un environnement Drools :
  • Allez dans l’onglet « Windows », « Preference », sélectionner « Drools », « Installed Drools Runtime » puis « Add »
  • Choisissez le nom que vous souhaitez, et allez sélectionner le dossier « binaries » de votre archive Drools.
  • Cliquez sur «Ok » et « Apply and Close »

 

  • - Création d’un projet test :
  • Choisissez « File » « New » puis « Drools Project »
  • Là, vous avez plusieurs options, soit créer un projet vide, soit un avec des fichiers d’exemple.

 

2) Projet test :

 

J’ai choisi un fichier d’exemple pour vous montrer un peu à quoi ça ressemble !

Voici un exemple de règle, pour afficher un «Hello world!» et un « Goodbye cruel world »

 

C’est une table de décision, elle permet de définir des règles dans une feuille de calcul Excel pré-formatée. L'avantage des tables de décision fournies par Drools est qu'elles sont faciles à comprendre, même pour une personne non technique. On y accès directement dans l’interface d’Eclipse.

 

Voici les classes Java qui font tourner tout ça !

 

3) Conclusion :

Bien que très pratique dans certaines situations (gros projets, règles amenées à changer régulièrement, visualisation externe de ses dernières, …. ), et open source ! Drools n’est pas évident à prendre en main. Il nécessite un temps de formation pour les développeurs, ce que certaines entreprises ne peuvent pas se permettre (temps, argent).

C’est un logiciel très intéressant, qui mérite que je m’y attarde beaucoup plus longtemps. Et qui je pense, pourrais m’être utile plus tard !

 

Il y a une multitude d’autres moteurs de règles … Mais je souhaite vous parlez d’une solution alternative à ceux-ci : le design pattern « Spécification » !

 

 

 

 

 

B – Le design Pattern «SPECIFICATION» :

 

Formalisé par Éric Evans, créateur du « DDD » et Martin Fowler.

Il permet de :

  • Marquer et identifier les règles métiers,
  • Les centraliser,
  • Les réutiliser,
  • Communiquer entre développeurs et fonctionnels sur ces règles métiers.

Pile poil ce qui nous intéresse ! Mais avant, petit aparté :

a ) Le DDD (Domain Driven Design) :

Le DDD, est une approche de conception logiciel, lancé par Éric Evans en 2003,  il est centré sur le métier de l’application et de code source qui l’implémente.

« Le DDD est une manière de penser et de communiquer les problèmes et leurs solutions, entre les équipes techniques et fonctionnelles.

La conception est conduite par un modèle. Ce modèle est en partie constitué d’un langage de communication commun aux experts fonctionnels et aux équipes de développement. »

  • Nicolas Lecoz

Domain Model.

Les avantages d’avoir un Domain Model sont :

  • Créer un modèle commun et intelligible entre les équipes fonctionnelles et les équipes techniques
  • Le modèle est modulaire, flexible et maintenable car il doit refléter la conception fonctionnelle
  • Améliorer la testabilité et la réutilisation des objets métiers.

En résumé, c’est un langage commun pour tous les acteurs, qu’ils soient techniques ou fonctionnels, pour favoriser la communication au travers des différentes équipes.

  1. Le Pattern Spécification :

Le principe de se pattern est d’avoir une seule classe par règles métiers, on parle de : «Single responsibility principle».

Single responsibility principle (SRP) : 

« Le principe de responsabilité unique est un principe de programmation informatique qui stipule que chaque module ou classe doit assumer la responsabilité d'une partie des fonctionnalités fournies par le logiciel, responsabilité qui doit être entièrement encapsulée par la classe. »

           

 

Je ne vais pas « réinventer la roue », internet fourmille d’exemples pertinent sur ce pattern, mais je vous mets le lien de celui qui à été pour moi, le plus aisé à comprendre : https://blog.xebia.fr/2009/12/29/le-pattern-specification-pour-la-gestion-de-vos-regles-metier/ , il est très bien imagé !

 

Je vais vous faire un résumé sur ce qu’il y a retenir.

 

  • Le problème :

Avec un code « classique » on a de grandes chances d’avoir des règles perdues au milieu de notre code. Si en plus, c’est un projet commencé il y a quelque temps, pour peu que se ne soit pas nous qu’il l’avons fait, qu’il ne soit pas commenté … On a tendance à moins vouloir y toucher, moins on y touche, moins on connait le code, etc.  Ce qui nous pousse à refaire un autre bout de code, qui potentiellement fait quasiment la même chose, et qui nous amène à avoir du code mort disséminer un peu partout … Donc perte de temps, de lisibilité, de réactivité …. Ce n’est pas concevable dans la vie de société ! Il faut donc une excellente connaissance de l'implémentation de la part des développeurs et des fonctionnels.

 

 

  • La solution :

 

Avec le pattern Spécification, on peut bien séparer nos règles, les lier entres elles, et voir si quand on les combine elles conviennent !

On gagne en :

  • Lisibilité
  • Réactivité (On peut vite retrouver la règle à modifier, si on doit ajuster quelque chose !)
  • Plus de bout de code oublié
  • Donc beaucoup de gain de temps !

 

On peut ajouter a tout ça, une bonne documentation de chaque règle, dans ce type-là :

Avec un langage commun entre les acteurs techniques et fonctionnels, comme vu plus haut avec le DDD !

Une bonne organisation de la documentation est nécessaire aussi, toujours dans le but de gagné du temps, et donc en productivité ! 😉

 

Conclusion :

C’est un pattern assez simple à comprendre, je pense qu’il vaut mieux le mettre en place dès le début du projet, sous peine de devoir tout déstructurer en suite (quoique cela permettrait de mieux connaitre le code finalement !) . C’est ce moyen qui a été choisis dans mon entreprise pour la gestion de nos règles, dans un projet à venir. Je serais amenée à y travailler régulièrement, et je suis très enthousiaste à ce sujet ! Je pourrais faire un retour encore plus précis à ce moment-là.

 

Je vous remercie de votre attention, dans l’espoir que ce sujet vous ait plu.

 

Maélie.

 

 

Sources :

http://www.open-source-guide.com/Solutions/Developpement-et-couches-intermediaires/Autres/Drools

https://en.wikipedia.org/wiki/Drools

https://fr.wikipedia.org/wiki/Algorithme_de_Rete

https://docs.jboss.org/drools/release/5.2.0.Final/drools-guvnor-docs/html_single/

https://www.urbanisation-si.com/drools-le-moteur-de-regles-metiers-open-source-brms-representation-des-connaissances-et-des-raisonnements-knowledge-representation-and-reasoning-krr

https://www.tutorialspoint.com/drools/drools_introduction.htm

https://docs.jboss.org/drools/release/7.0.0.Final/drools-docs/html_single/

https://wwu-pi.github.io/tutorials/lectures/lsp/030_install_drools.html

https://www.drools.org/download/download.html

https://www.youtube.com/watch?v=gz0GCUBX3ak&t=122s

https://www.baeldung.com/drools

https://www.duchess-france.org/a-la-decouverte-des-moteurs-de-regles-paris-jug-novembre-partie-1/

https://www.urbanisation-si.com/articles/moteur-de-regles

https://fr.wikipedia.org/wiki/DDD

https://fr.wikipedia.org/wiki/Conception_pilot%C3%A9e_par_le_domaine

https://blog.xebia.fr/2009/01/28/ddd-la-conception-qui-lie-le-fonctionnel-et-le-code/

https://en.wikipedia.org/wiki/Specification_pattern

https://www.martinfowler.com/apsupp/spec.pdf

https://martinfowler.com/eaaCatalog/domainModel.html

https://martinfowler.com/

https://blog.eleven-labs.com/fr/pattern-specification-2/

http://blog.lepine.pro/php/gerer-des-regles-metiers-complexes-etou-changeantes

https://marcaube.ca/2015/05/specifications

https://connect.adfab.fr/dev/comment-gerer-ses-regles-metiers-grace-au-pattern-specification

https://en.wikipedia.org/wiki/Single_responsibility_principle

https://blog.xebia.fr/2009/12/29/le-pattern-specification-pour-la-gestion-de-vos-regles-metier/

 

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *