Archive

Articles taggués ‘Moteur de règles’

Paris JUG : soirée Moteur de règles

Le 11 novembre 2010, le Paris JUG mettait en avant les moteurs de règles.

Au programme quatre présentations sur un sujet qui ne me parlait pas !

La première présentation nommée « Business Rules Management System », présentée par Emmanuel Bonnet de Genigraph, me permet d’ailleurs de rentrer dans le sujet et comprendre l’intérêt .
Les moteurs de règles ou Business Rules Management System permettent d’écrire, d’exécuter et de gérer (cycle de vie, version …) un ensemble de règles métiers.
Une règle métier ressemble à cela : SI [condition] (ET|OU [autres condtions]) alors [faire telle action]. Par exemple : Si le conducteur n’a pas eu d’accident depuis 3 ans alors appliquer 15% de réduction.

Et la vous me lisez en vous demandant si c’est pas un trop une soirée sur des IF THEN ELSE .. je vous comprends moi aussi j’ai failli me poser la question.

En fait le problème n’est pas dans l’élément unique mais dans l’assemblage d’un très très grand nombre de ces règles ! Il y a un moteur d’inférence pour exécuter les règles métiers. Le BRMS permet d’externaliser, d’expliciter et de gérer ces règles.
Par exemple j’ai une application que je veux concevoir dont une partie que je veux externaliser ou déléguer à des experts du domaine ou pouvoir modifier régulièrement. Par exemple un métier avec de nombreuses offres commerciales régulières (par exemple fournisseur de services mobiles).
On peut alors utiliser un BRMS avec la logique technique de l’application qui englobe une logique métier que l’on veut extraire. L’intérêt est de pouvoir modifier les règles métiers sans refaire un cycle de livraison du socle technique.

Expliciter l’application permet de rendre le code :

  • Compréhensible : métier visible et lisible (langage usuel + grammaire alors un traitement qui s’applique sur un concept)
  • Modifiable sans avoir besoin à des informaticiens
  • Traçable : on peut relire une séquence d’une décision (les conditions menant à une action)

On peut donc récupérer au mieux le savoir du client et l’impliquer dans le projet.

Un moteur de règle exécute les règles de fait, les optimiser et garantit la cohérence. Il est fait pour optimiser beaucoup de faits et beaucoup de règles (Voir algorithme de RETE). Il y a aussi la présence d’outil de monitoring de règles, d’un workflow pour les règles et ainsi mettre en place une logique de décisions.
Les règles peuvent être insérées suivant différents formats : texte, tableur type excel (2 parties : condition et action) ou directement Eclipse.

Les deux plus gros acteurs sont JRules et Drools.

La 2ème intervention de Laurent Magnin – In Fine présente un ensemble de cas concrets et met en avant la formalisation de l’expertise, le pilotage et les possibilité de prises de décisions. Il commence aussi à parler de système expert.

Pour la 3ème présentation, l’intervenant, Daniel Selman, nous vient directement d’IBM et nous présente donc l’outil ILOG JRules BRMS.
Il insiste sur le fait quand un projet Les besoins donc les spécifications changent. Il faut s’y attendre et donc désigner pour !
Un BRMS comme ILOG JRules permet justement cette gestion du changement : qui a demandé un changement ? qu’est ce qui a changé ? Qui a fait le changement ? qu’est ce qui valide le changement ?
ILOG permet aussi d’éxecuter différentes configurations de règles métier pour permettre, par exemple, de gérer en parallèle un serveur de production et de tests.
L’intervenant nous a fait une démo en direct du produit, par exemple du client web pour les experts métiers afin d’éditer les règles métiers.

La 4ème et dernière présentation par Geoffrey de Smet a été pour moi la plus intéressante car elle a mis en valeur l’intérêt des systèmes experts. Oui car l’intérêt des systèmes experts est remonté à ma mémoire (ahh les études ça commence à dater) résoudre ces problèmes si complexes qu’ils sont parfois classés dans le domaine de l’intelligence artificielle.
L’intervenant expose 3 problèmes de planning NP Complexe : un petit problème de rangement de colis dans une voiture dont la place est contrainte, un planning de travail dans un hôpital et la gestion des malades dans les lits d’hôpitaux. C’est sur ce dernier exemple qu’il insiste en montrant qu’à l’échelle d’un grand hôpital, l’algorithme qui donne la réponse parfaite n’existe pas ! Le nombre de combinaison est tout simplement infinie. La solution est donc de partir sur un algorithme déterministe (temps fixe, facile à implémenter) puis d’utiliser des méta-heuristique en « bougeant les éléments » petit à petit (plus on a du temps, meilleure est la solution). Il suffit de gérer les optimum locaux. C’est ce que fait Drools Planner !

Voila pour le compte rendu de la soirée.

Les présentations sont sur le bas de la page du Paris JUG.

Categories: Java EE Tags: ,