grule rule engine
Release 1.15.0
"Gopher détient les règles"
import "github.com/hyperjumptech/grule-rule-engine" Grule est une bibliothèque de moteurs de règles pour le langage de programmation Go (Golang). Inspiré du célèbre JBOSS Drools et réalisé d'une manière beaucoup plus simple.
Comme Drools , Grule possède son propre langage DSL ou Domain-Specific Language.
Vous trouverez ci-dessous un exemple de Drools's DRL ou Drools Rule Language :
rule "SpeedUp"
salience 10
when
$TestCar : TestCarClass( speedUp == true && speed < maxSpeed )
$DistanceRecord : DistanceRecordClass()
then
$TestCar.setSpeed($TestCar.Speed + $TestCar.SpeedIncrement);
update($TestCar);
$DistanceRecord.setTotalDistance($DistanceRecord.getTotalDistance() + $TestCar.Speed);
update($DistanceRecord);
end
Le GRL de Grule est le suivant :
rule SpeedUp "When testcar is speeding up we keep increase the speed." salience 10 {
when
TestCar . SpeedUp == true && TestCar . Speed < TestCar . MaxSpeed
then
TestCar . Speed = TestCar . Speed + TestCar . SpeedIncrement ;
DistanceRecord . TotalDistance = DistanceRecord . TotalDistance + TestCar . Speed ;
}Il n'y a pas de meilleure explication que l'article rédigé par Martin Fowler. Vous pouvez lire l'article ici (RulesEngine de Martin Fowler).
Tiré du site Web TutorialsPoint (avec de légères modifications),
Le moteur de règles Grule est un système de règles de production qui utilise l'approche basée sur des règles pour implémenter un système expert. Les systèmes experts sont des systèmes basés sur la connaissance qui utilisent des représentations de connaissances pour traiter les connaissances acquises dans une base de connaissances pouvant être utilisée pour le raisonnement.
Turing propose un système de règles de production axé sur la représentation des connaissances pour exprimer la logique propositionnelle et de premier ordre de manière concise, non ambiguë et déclarative.
Le cerveau d’un système de règles de production est un moteur d’inférence capable de s’adapter à un grand nombre de règles et de faits. Le moteur d'inférence compare les faits et les données aux règles de production – également appelées productions ou simplement règles – pour déduire des conclusions qui aboutissent à des actions.
Une règle de production est une structure en deux parties qui utilise la logique du premier ordre pour raisonner sur la représentation des connaissances. Un moteur de règles métier est un système logiciel qui exécute une ou plusieurs règles métier dans un environnement de production d'exécution.
Un moteur de règles vous permet de définir « Que faire » et non « Comment le faire ».
(également tiré de TutorialsPoint)
Les règles sont des éléments de connaissance souvent exprimés par la formule : « Lorsque certaines conditions se produisent, effectuez certaines tâches. »
When
< Condition is true >
Then
< Take desired Action >La partie la plus importante d’une règle est sa partie quand. Si la partie quand est satisfaite, la partie alors est déclenchée.
rule < rule_name > < rule_description >
< attribute > < value > {
when
< conditions >
then
< actions >
}Les règles permettent d'exprimer facilement des solutions à des problèmes difficiles et d'obtenir également des vérifications. Contrairement au code, 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 métier réside dans les règles. Selon le type de projet, ce type de séparation peut être très avantageux.
En utilisant des règles, vous créez un référentiel de connaissances (une base de connaissances) qui est exécutable. C’est un point de vérité unique pour la politique des entreprises. Idéalement, les règles sont si lisibles qu’elles peuvent également servir de documentation.
Puisque les règles métier sont en réalité traitées comme des données. Ajuster la règle en fonction du caractère dynamique de l'entreprise devient trivial. Pas besoin de reconstruire le code ou de le déployer comme le fait le développement logiciel normal : il vous suffit de déployer des ensembles de règles et de les appliquer au référentiel de connaissances.
Les cas suivants sont mieux résolus avec un moteur de règles :
Un système expert qui doit évaluer les faits pour fournir une sorte de conclusion concrète. Si l’on n’utilise pas un moteur de règles de type RETE, on coderait un ensemble en cascade d’instructions if / else , et les permutations des combinaisons de la façon dont celles-ci pourraient être évaluées deviendraient rapidement impossibles à gérer. Un moteur de règles basé sur des tables pourrait suffire, mais il est encore plus fragile face au changement et n'est pas très facile à coder. Un système comme Grule vous permet de décrire les règles et les faits de votre système, vous libérant ainsi de la nécessité de décrire comment les règles sont évaluées par rapport à ces faits et vous cachant l'essentiel de cette complexité.
Un système de notation. Par exemple, un système bancaire peut vouloir créer un « score » pour chaque client sur la base des enregistrements de transactions (faits) du client. Nous pourrions voir leur score changer en fonction de la fréquence à laquelle ils interagissent avec la banque, du montant d'argent qu'ils transfèrent, de la rapidité avec laquelle ils paient leurs factures, du montant des intérêts qu'ils accumulent, du montant qu'ils gagnent pour eux-mêmes ou pour la banque, et bientôt. Un moteur de règles peut être fourni par un développeur, et la spécification des faits et des règles peut ensuite être fournie par des experts en la matière au sein du service d'analyse client de la banque. Le découplage de ces différentes équipes place les responsabilités là où elles devraient être.
Jeux informatiques. Le statut du joueur, les récompenses, les pénalités, les dégâts, les scores et les systèmes de probabilité sont de nombreux exemples différents de cas dans lesquels les règles jouent un rôle important dans la plupart des jeux informatiques. Ces règles peuvent interagir de manière très complexe, souvent d'une manière que le développeur n'avait pas prévue. Le codage de ces situations dynamiques à l'aide d'un langage de script (par exemple Lua) peut devenir assez complexe, et un moteur de règles peut grandement simplifier le travail.
Systèmes de classification. Il s’agit en fait d’une généralisation du système de notation décrit ci-dessus. À l'aide d'un moteur de règles, nous pouvons classer des éléments tels que l'éligibilité au crédit, l'identification biochimique, l'évaluation des risques pour les produits d'assurance, les menaces potentielles pour la sécurité et bien d'autres encore.
Système de conseils/suggestions. Une « règle » est simplement un autre type de données, ce qui en fait un candidat idéal pour une définition par un autre programme. Ce programme peut être un autre système expert ou une intelligence artificielle. Les règles peuvent être manipulées par d'autres systèmes afin de traiter de nouveaux types de faits ou d'informations nouvellement découvertes sur le domaine que l'ensemble de règles vise à modéliser.
Il existe de nombreux autres cas d'utilisation qui bénéficieraient de l'utilisation d'un moteur de règles. Les cas ci-dessus ne représentent qu’un petit nombre de cas potentiels.
Cependant, il est important de se rappeler qu’un Rule-Engine n’est bien sûr pas une solution miracle. Il existe de nombreuses alternatives pour résoudre les problèmes de « connaissance » dans les logiciels, et celles-ci doivent être utilisées là où elles sont les plus appropriées. On n’emploierait pas un moteur de règles où une simple branche if / else suffirait, par exemple.
Il y a autre chose à noter : certaines implémentations de moteurs de règles sont extrêmement coûteuses, mais de nombreuses entreprises en tirent tellement de valeur que le coût de leur fonctionnement est facilement compensé par cette valeur. Même pour des cas d’utilisation modérément complexes, l’avantage d’un moteur de règles puissant, capable de découpler les équipes et de maîtriser la complexité de l’entreprise, semble évident.
Page de documentation ici
Pour plonger dans le didacticiel, consultez la documentation Wiki ici sur Github.
Loading rules into KnowledgeBase :
Pour charger 100 règles dans KnowledgeBase, il a fallu 99342047 ns/op (a pris la valeur la plus élevée), ce qui équivaut à ~99.342047ms et ( 49295906 B/op ) ~49.295906MB de mémoire par opération
Pour charger 1000 règles dans KnowledgeBase, il a fallu 933617752 ns/op (a pris la valeur la plus élevée), ce qui équivaut à ~933.617752ms et ( 488126636 B/op ) ~488.126636 mémoire par opération
Executing rules against a fact :
Pour exécuter un fait contre 100 règles, Grule Engine a pris ~9697 ns/op (a pris la valeur la plus élevée comme base), soit à peine ~0.009697ms et 3957 B/op , ce qui est assez rapide.
Pour exécuter un fait contre 1000 règles, Grule Engine a pris ~568959 ns/op (a pris la valeur la plus élevée comme base), soit à peine ~0.568959ms et 293710 B/op ce qui est également assez rapide.
Vous pouvez lire le rapport détaillé ici
Oui. Nous avons besoin de contributeurs pour rendre Grule encore meilleur et utile à la communauté Open Source.
Si vous voulez vraiment nous aider, Fork simplement le projet et postulez pour Pull Request. Veuillez lire notre manuel de contribution et notre code de conduite.
