Qui fait fonctionner un moteur de règles ?

La mise en place d’un moteur de règles requiert la collaboration étroite entre 3 grands types d’acteurs : l’expert métier, le développeur de règles, l’administrateur du moteur de règles.

L’expert métier :

• Définit le modèle de règles en collaboration avec l’administrateur du moteur de règles
• Conçoit les règles selon le modèle défini, si elles répondent aux critères définis par l’administrateur (granularité, complexité, style, correspondance avec un modèle, table de décision, …)
  • Si une règle ne correspond pas aux critères, elle devra être écrite par le développeur
• Effectue les tests unitaires

Le développeur de règles :

• Injecte le modèle métier (classes Java JAR) dans le référentiel des règles (Guvnor)
• Conçoit le langage métier (DSL = Domain Specific Language) qui servira à l’expert métier pour écrire ses règles
• Conçoit, réalise et teste :
  • les classes Java à partir du modèle de données métier MEGA
  • le composant générique pour lancer le moteur de règles
  • les fonctions utilitaires (conversions, …) et les formules de calculs (l’expert métier peut écrire des fonctions et des expressions)
  • ajouter des « import » de packages et des variables globales
  • le DSL
  • les modèles de règles à destination des experts métiers
  • les tables de décision à destination des experts métiers
• Teste les règles écrites par l’expert métier, à l’aide de scénarios (valeurs en entrée et valeurs attendus), ainsi que les tests de non régression
• Met à jour les règles (versionning) et gère les impacts d’une modification du modèle métier
  • Méta-modèle, généricité (code, libellé, valeur, type, …)
• Ordonnance les règles (rule flow ou processus avec un BPM= Business Process Management)
• Conçoit le service technique pour le lancement du moteur de règle

L’administrateur du moteur de règles :

• Etablit une méthode et la fait valider par le Métier
  • Périmètre
  • Modèle de règles
• Définit la granularité des objets
  • Objets spécifiques ne contenant que les données nécessaires au moteur de règles
• Définit le passage par lots (1 ou plusieurs objets avec leurs grappes par ex. un dossier et ses dossiers liés)
  • Ex : IHM du traitement d’un sinistre, traitement batch de plusieurs sinistres…
• Réalise une 1ère itération de l’application avec les développeurs…
• … puis une 2e itération avec le métier et les développeurs (ajout de nouvelles règles)

Retour d'expérience : pendant la 1ère itération, les développeurs doivent implémenter les règles dans le langage technique du moteur puis dans les itérations suivantes on communique la méthode mise au point comprenant la structure et les granularités des règles aux experts métier pour qu'ils se lancent à leur tour dans l'aventure.

urbanisation des SI, processus métier, règles métier, bonnes pratiques SI, MDA, génération d'applica

Urbanisation des SI, processus métier, moteur de processus, règles métier, moteur de règles, BPM, BRMS, SOA, génération d'application, MDA, méthode agile, Scrum, Kanban, bonnes pratiques SI

http://urbanisation-si.blog4ever.net/

Urbanisation des SI

Abandonnez le classicisme, relookez votre SI -

Par Rhona Maxwel dans Architecture technique le 14 Septembre 2014 à 12:49 11/11 Projet informatique, passer du moyen âge à l'ère industrielle. Devenez parano en vérifiant chaque jour votre ...

http://bonnes-pratiques-si.eklablog.com/

Bonnes pratiques SI

Urbanisation des SI

http://urbanisation-des-si.blogspot.fr/

Urbanisation des SI