Construire des moteurs de règles métier avec Drools - Power to the SMEople

L'une des choses les plus étonnantes du travail dans le développement de logiciels est la possibilité de travailler dans de nombreux secteurs différents, surtout si vous êtes consultant. La plupart des compétences en développement de logiciels que vous apprenez en travaillant dans une industrie sont directement transférables à un certain nombre d'autres industries, entreprises, projets et niches.

Je parle de sujets tels que la conception de bases de données, les modèles de conception, les dispositions d'interface graphique, la gestion d'événements, etc. Ensuite, bien sûr, il y a des sujets spécifiques à une industrie, une entreprise ou un projet particulier.

La PME rencontre l'informatique, le transfert de connaissances commence

C'est là qu'intervient l'expert en la matière (PME). Une PME sera généralement très impliquée dans la phase de conception du projet.

La PME travaille dans l'industrie depuis longtemps, connaît le jargon et comprend la logique commerciale derrière le codage. La PME peut avoir une certaine compréhension du développement de logiciels, mais cela n'est pas nécessaire pour que le projet réussisse.

Pour de nombreux projets, à moins que le développeur de logiciels n'ait une bonne compréhension de la logique métier, la réalisation d'une application logicielle réussie sera relativement difficile. Le temps qui doit être consacré au transfert de connaissances variera considérablement en fonction de la complexité du projet.

En supposant qu'une approche agile est adoptée et qu'une ou plusieurs PME sont disponibles tout au long de la phase de développement du projet, le transfert de connaissances se poursuivra à toutes les étapes du projet.

Que faire si le transfert complet des connaissances n'est pas possible ?

Selon l'industrie et le projet, il peut ne pas être possible pour une PME d'assurer un transfert de connaissances complet.

Par exemple, imaginez si la PME est un médecin avec 25 ans d'expérience et que vous disposez de 6 mois pour réaliser un projet. Ou, imaginez la PME comme un biologiste avec 40 ans d'expérience - un tel niveau de connaissances ne peut tout simplement pas être transféré dans un délai réaliste pour des projets de développement de logiciels.

Mais que se passe-t-il si le domaine de la connaissance est dynamique ?

En règle générale, les logiciels sont publiés selon un calendrier défini en fonction du temps ou des fonctionnalités. Cependant, les règles commerciales au sein de certaines industries changent beaucoup plus fréquemment.

Dans de nombreux cas, il peut ne pas être possible de publier des logiciels aussi souvent que nécessaire pour suivre les changements de l'industrie. Avoir la possibilité d'externaliser les règles métier au sein d'un moteur de règles métier peut avoir du sens dans de tels scénarios. La capacité d'un projet logiciel à résister au changement contribuera grandement à assurer son succès ultime à long terme.

Quand et où les moteurs de règles ont-ils un sens ?

Pour de nombreux projets logiciels, il est possible d'effectuer un transfert complet des connaissances et de coder la logique métier dans un langage informatique tel que C# ou Java.

Cependant, il existe un sous-ensemble de projets où la quantité de compréhension d'un sujet spécifique est si grande, ou les règles métier sont sujettes à tant de changements qu'il est plus logique pour un non-programmeur d'avoir un accès direct à la logique métier. C'est le sujet de ce tutoriel; Dans cet esprit, discutons en profondeur des moteurs de règles.

Qu'est-ce qu'un moteur de règles métier ?

Un moteur de règles est un outil permettant d'exécuter des règles métier. Les règles métier sont composées de faits et d'instructions conditionnelles. Toute instruction « si-alors » qui apparaît dans la logique métier traditionnelle est considérée comme une règle métier.

Par exemple : si un employé est absent plus de 5 jours consécutifs pour cause de maladie et n'a pas de certificat médical, il doit alors le rédiger. Si un associé commercial n'a pas été contacté depuis plus de 6 mois et qu'il n'a effectué aucun achat pendant cette période, il est peut-être temps de lui envoyer un e-mail cordial. Si un patient a une température corporelle élevée, des problèmes de vision et des antécédents familiaux de glaucome, il est peut-être temps de demander une IRM supplémentaire ou d'autres tests.

Comment les PME rédigent-elles des règles métier ?

Au lieu d'attendre d'une PME qu'elle apprenne Java, C# ou un autre langage de programmation, le service informatique lui créera un mini-langage pour exprimer ses règles métier. Les éléments constitutifs de ces règles consisteront en des faits qui peuvent être interrogés. Voici quelques exemples de faits par industrie/domaine de pratique :

• Ressources humaines : salaire, poste, responsable, années passées dans l'entreprise
• Médical : température, tension artérielle, médication actuelle
• Financière : cours actuel de l'action, prix le plus élevé/le plus bas sur 52 semaines, ratio P/E, date de la prochaine publication des résultats

Essentiellement, les informations nécessaires à la prise de décisions commerciales doivent être mises à la disposition de la PME de manière simplifiée.

À quoi ressemblent ces règles ?

Pour le reste de ce didacticiel sur le moteur de règles, j'utiliserai Drools, un moteur de règles open source basé sur Java, qui peut être trouvé sur www.drools.org et est un projet JBoss. Dans Drools, les règles sont écrites en code Java et ont la structure suivante :

Les déclarations d'importation vont ici :

 rule “Name of rule” when “The if” part of the business logic goes here. then The “then” part of the business logic goes here. end

Bave et mémoire de travail

Drools utilise un concept appelé mémoire de travail.

Le code d'application sera responsable du chargement des faits appropriés dans la mémoire de travail afin que les PME puissent écrire des règles qui interrogent ces faits. Seuls les faits pertinents pour la logique métier de l'application doivent être chargés dans la mémoire de travail, afin de maintenir le moteur de règles à sa vitesse maximale.

Par exemple, si une application détermine s'il convient d'approuver un client pour un prêt, les faits pertinents incluent le salaire, les cotes de crédit et les prêts en cours. Les faits non pertinents incluraient le jour de la semaine ou le sexe.

Évaluation des règles

Une fois que la mémoire de travail de Drools a été chargée de règles et de faits, les règles sont évaluées en fonction de la partie «alors» de leur règle. Si la partie "alors" est évaluée à vrai, la partie "quand" de la règle sera alors exécutée.

En règle générale, toutes les règles sont évaluées en même temps, bien que les règles puissent être regroupées et évaluées par groupe. La partie « alors » de la règle peut modifier le contenu de la mémoire de travail. Lorsque cela se produit, Drools réévaluera toutes les règles pour voir si certaines règles sont maintenant évaluées comme vraies. Si c'est le cas, leurs parties "quand" seront exécutées.

Cette nature récursive des évaluations de règles peut être une bénédiction ou une malédiction. Les règles doivent donc être créées en gardant cette architecture à l'esprit.

Le côté "si" d'une règle de bave

Dans Drools, les faits sont représentés par des objets. L'existence ou la non-existence d'un type d'objet peut être interrogée. De plus, les attributs de l'objet peuvent également être interrogés.

Voici quelques exemples:

Déterminez si un employé gagne plus de 100 000.

 Employee(salary > 100000)

Déterminez si un patient a un taux de cholestérol supérieur à 200 et prend du Lipitor.

 Patient(cholesterol > 200, medications.contains(“lipitor”))

Déterminez si le cours d'une action se situe à moins de 1 % de son sommet annuel.

 Stock(price >= (yearHigh * .99))

Combinaison de requêtes

Lors de l'écriture d'une logique métier complexe, les règles métier peuvent combiner des requêtes à l'aide d'opérateurs booléens AND, OR et NOT et imbriquées à l'aide de parenthèses.

Par exemple:

Déterminez s'il y a un gestionnaire qui gagne moins de 75 000 $ ou un directeur qui gagne moins de 100 000 $.

 Employee(position.Equals(“Manager”),salary<75000) OR Employee(position.Equals(“Directory”),salary<100000)

Utilisation de plusieurs types d'objets

Jusqu'à présent, tous les exemples ont été basés sur un seul type d'objet, tel que Employé ou Patient. Cependant, Drools permet aux requêtes d'être basées sur plusieurs types d'objets.

Par exemple:

Déterminez si le client a un salaire supérieur à 50 000 $ et n'a pas déposé son bilan.

 Customer(salary>50000) AND not exists Bankruptcy()

Le côté "alors" d'une règle

Le côté « alors » d'une règle détermine ce qui se passera lorsqu'il y aura au moins un résultat dans la partie « quand » de la règle.

Dans Drools, tout ce qui peut être écrit en Java peut être écrit dans la partie « alors » de la règle. Cependant, afin de rendre les règles plus réutilisables, il est généralement conseillé de ne pas placer d'E/S, de code de contrôle de flux ou de code d'exécution général dans une règle.

Comme alternative, la partie « alors » d'une règle peut être utilisée pour modifier la mémoire de travail. Une pratique courante consiste à insérer un fait dans la mémoire de travail lorsqu'une règle est évaluée comme vraie.

Par exemple:

 rule “LoanApproved” when Customer(credit>700) && not exist LoanOutstanding() then insert(new LoanApproval()) end

Comment savons-nous quand une règle a été évaluée comme vraie ?

Une fois toutes les règles déclenchées, l'application doit savoir quelles règles sont évaluées comme vraies. Si les règles insèrent des objets dans la mémoire de travail lorsqu'elles sont évaluées comme vraies, du code peut être écrit pour interroger la mémoire de travail pour ces objets.

Dans l'exemple ci-dessus, une fois que toutes les règles ont été déclenchées, une requête peut être effectuée pour voir si un objet LoanApproval() se trouve dans la mémoire de travail.

 query "GetLoanApproval " $result: LoanApproval() end

Comment un moteur de règles métier interagit-il avec une application ?

Les applications typiques contiennent une logique métier, une interface graphique, des E/S et un flux de code de contrôle.

Par exemple, une application peut traiter une requête utilisateur comme ceci :

 GUI ? Flow Control ? I/O ? Business Logic ? I/O ? Flow Control ? GUI

L'intégration d'un moteur de règles ajoute quelques étapes à ce processus :

 GUI ? Flow Control ? I/O ? Create Rules Engine Session ? Add Facts to Working Memory ? Fire Rules ? Determine which rules have evaluated true ? I/O ? Flow Control ? GUI

Comment les PME travaillent-elles avec les règles ?

Création, modification et suppression de règles

Pour que les PME puissent travailler avec des règles, elles auront besoin d'une interface graphique conviviale. Certains moteurs de règles métier sont livrés avec une telle interface.

Par exemple, Drools est livré avec deux interfaces graphiques que je trouve conviviales. Le premier ressemble à une feuille de calcul et permet aux PME de créer des règles sans jamais écrire de code réel. La deuxième interface graphique permet de créer une logique métier plus complexe.

Bien que ces deux interfaces graphiques puissent être utiles pour saisir des conditions simples, elles ne fonctionneront pas car la logique métier devient plus complexe. Dans ce cas, vous devrez créer votre propre interface graphique personnalisée.

Éléments de l'interface graphique personnalisée SME

Pour que les PME travaillent efficacement, envisagez de créer une interface graphique personnalisée avec les fonctionnalités suivantes :

• Vérificateur de syntaxe - un bouton "vérifier la syntaxe" peut appeler le code Drools pour vérifier les erreurs possibles et leurs numéros de ligne.
• Glisser/déposer – au lieu d'exiger d'une PME qu'elle se souvienne des objets et des attributs à sa disposition, envisagez de lui proposer une liste de sélection à partir de laquelle elle peut glisser et déposer.
• Interface Web - une interface client léger sera disponible pour les PME sans problèmes de distribution. Cela sera utile car l'interface graphique a besoin de fonctionnalités supplémentaires et d'une maintenance générale.
• Testeur de règles - avoir la capacité de tester des règles individuelles sans interface avec l'ensemble de l'application augmentera considérablement la productivité des PME. Autorisez l'interface graphique du SME à déterminer les faits, puis déclenchez des règles individuelles.

Où les règles doivent-elles être stockées ?

Dans Drools, il existe généralement deux façons de stocker les règles. Drools fonctionne immédiatement avec des règles basées sur des fichiers qui auront généralement une extension .drl.

Cela fonctionne bien lorsque le nombre de règles est faible. Au fur et à mesure que le nombre de règles augmente, vous souhaiterez utiliser une base de données. Stocker et récupérer des règles à partir d'une base de données nécessite plus de travail, mais devrait vous donner une architecture beaucoup plus gérable.

Ce didacticiel sur le moteur de règles n'a abordé qu'une très petite partie du langage de règles Drools. Pour une description complète, veuillez consulter la documentation de référence officielle.

La décision d'utiliser un moteur de règles ne doit pas être prise à la légère. Si un moteur de règles rendra votre application plus extensible par les PME, elle deviendra également plus compliquée à développer, tester et déployer. Pour des considérations supplémentaires sur ce sujet, vous pouvez consulter les directives suivantes.

Nous pouvons maintenant vous montrer quelque chose d'un peu plus intéressant - un exemple simple et réel de Drools en action, dans un cas d'utilisation que la plupart des lecteurs de blog Toptal devraient trouver familier.

Utiliser Drools dans un scénario réel

Toptal, l'un des principaux fournisseurs de talents de développement de logiciels de haut niveau, utilise actuellement un logiciel de suivi des candidats pour guider les candidats à travers les différentes étapes du processus d'embauche. Voici un organigramme visuel simplifié de ce processus :

Actuellement, la logique métier permettant de décider si un candidat poursuivra le processus d'embauche a été codée en dur dans le logiciel. Chaque fois que les ressources humaines doivent changer la logique métier, elles doivent impliquer l'informatique. Ils aimeraient avoir la possibilité de modifier directement le fonctionnement de leur logiciel.

Le logiciel de suivi des candidatures sera modifié pour exécuter les règles fournies par les RH à chaque point de décision du processus d'embauche. Les RH auront un objet "Candidat" qui représentera un candidat dont le statut vient d'être modifié par une entrée initiale, la réussite d'un examen en ligne ou un certain nombre de facteurs différents. L'objet Candidat aura des champs pour représenter l'expérience, les résultats des tests, les résultats des entretiens, etc.

L'exemple suivant présente un ensemble simplifié de règles à prendre en compte. Il n'a pas été déployé, c'est juste un exemple simple composé de quatre règles interconnectées :

• Soumis -> Test
• Test -> Entretien
• Entretien -> Projet
• Projet -> Embauche

Soumis -> Test

En fonction des besoins actuels des clients, les RH aimeraient rédiger une règle qui déterminera si un candidat doit être programmé pour des tests en ligne.

 Rule “Schedule For Testing” when $candidate: Candidate(status=='Submitted',yrsExperience >= 10, skill(name=='Java', yrsExperience>=5) or Skill(name=='C#', yrsExperience>=5)) then $candidate.setStatus('Testing'); end

Test -> Entretien

Une fois que le candidat a passé l'examen en ligne, son score doit être évalué. Les RH aimeraient également avoir le contrôle sur cette règle. L'examen en ligne teste la capacité d'un candidat à comprendre la théorie du développement logiciel, la résolution de problèmes et la syntaxe. Les RH aimeraient décider quelle combinaison de notes permettra à un candidat d'être considéré pour un entretien technique.

 Rule “Schedule For Interview” when $candidate: Candidate(status=='Testing', testScore(theory>.8 && syntax>.6 && problemSolving>.8); then $candidate.setStatus('Interview'); end

Entretien -> Projet

Un entretien technique testera la capacité d'un candidat à parler de son expérience, à répondre à des questions de résolution de problèmes et à tester sa capacité à communiquer en général. Les RH rédigeront la règle qui détermine une note de passage pour l'entretien technique.

 Rule “Schedule For Project” when $candidate: Candidate(status=='Interview', interviewScore(speakExperience>.9 && problemSolving>.8 && communication>.9 ); then $candidate.setStatus('Project'); end

Projet -> Embauche

Si un candidat réussit l'entretien technique, il se verra attribuer un projet de programmation hors ligne. Ils soumettront le projet et il sera jugé pour l'exhaustivité, l'architecture et l'interface graphique.

 Rule “Schedule For Hiring” when $candidate: Candidate(status=='Project', projectScore(completeness>.8 && architecture>.9 && gui>.7 ); then $candidate.setStatus('Hiring'); end

Comme vous pouvez le constater, même cet exemple de base offre un certain nombre de possibilités pour les RH et peut rationaliser les opérations. Le fait que les RH puissent modifier les règles sans avoir à impliquer l'informatique dans le processus ferait inévitablement gagner du temps et accélérerait le processus de sélection.

Étant donné que les règles peuvent être modifiées à la volée, le service des ressources humaines aurait également beaucoup plus de flexibilité. Par exemple, les RH pourraient étendre ou restreindre le processus de sélection en définissant différents paramètres.

S'il y a trop de candidats qui cochent toutes les bonnes cases, la barre pourrait être relevée en quelques minutes, réduisant ainsi le nombre de candidats. Alternativement, si le processus ne produit que peu ou pas de candidats qui répondent à toutes les exigences, les RH peuvent choisir de réduire ou d'abandonner certaines des normes, en se concentrant sur des compétences plus pertinentes jusqu'à ce qu'un nombre adéquat de candidats répondent à l'exigence.