Développement de l'IHM d'un moteur de règle

Au cours de mon stage au sein de l'entreprise Apave, j'ai eut comme tâche de créer intégralement l'IHM d'un moteur de règle.

Comme je viens de vous le dire, c'est au cours de mon stage dans la société apave que j'ai découvert et développé l'IHM d'un moteur de règles. Pour ne rien cacher ce fut une tache extrêmement difficile pour moi qui m'a demandé à la fois beaucoup de recherches et de lecture que de réflexion et peut être des centaines de brouillons.

Note: Je vous donne ici un exemple de moteur de règles, je n'ai pas la prétention de vous conseiller de faire comme moi

Un moteur de règles c'est quoi?

Alors pour faire simple l'objectif final du moteur de règles que j'ai développé est que sur la base d'un contexte, il doit nous être donné en sortie un ou plusieurs résultats. Pour cela, grâce à l'IHM, l'utilisateur est capable de définir le meta model du contexte ainsi que le meta model du résultat sous un format json-schema.

Petite présentation de ce à quoi doit ressembler l'IHM ou les IHM du moteur de règles car oui il y en a en fait trois:

Ci-dessus vous pouvez apercevoir un modele de la première Ihm. Pour switcher d'une IHM à une autre il suffit d'appuyer sur les boutons en bleus du haut. En haut à gauche sera présent la liste des règles. On peut y voir le code la règle, son libelle(ou son nom) ainsi que son état. Vous l'aurez peut-être remarqué mais dans ce cas il s'agit de développer un véritable CRUD(create, read, update , delete). En effet l'utilisateur de notre IHM doit pouvoir ajouter une règle, voir le détail de celle-ci, l'éditer et la supprimer. La fenêtre en bas à gauche montre montre le CRUD sur les règles. La fenêtre en haut a droite montre les propriété du contexte d'une règle. A la création d'une règle, c'est fenêtre est donc vide puisque c'est à l'utilisateur de crée ses propriétés lui même grâce à la fenêtre en bas à droite de l'écran. Vous l'aurez peut-être compris il s'agit d'un deuxième CRUD mais cette fois ci sur les propriété du contexte. Je vous expliquerai plus tard ce que nous allons faire de ces propriétés. A présent passons à la deuxième IHM, l'IHM des résultats de définition

Je ne vais pas m'attarder plus sur cette IHM puisque qu'elle est sensiblement la même que pour les propriétés du contexte. Passons à la troisième IHM qui est un peu plus complexe que les deux autres.

Pour faire bref, cette IHM est le résultat des deux précédentes. Lorsque l'utilisateur va créer une propriété de contexte et de résultat, celle-ci va venir alimenter un json-schema et un json que je vais appeler json-form que je vous présenterais par la suite. A l'aide de ce json-form et de ce json-schema et à l'aide d'un composant que je vous présenterai également par la suite nous allons pouvoir obtenir un formulaire et c'est ce formulaire que nous allons afficher à l'endroit où vous voyez instances contexte et instances résultat. Je me doute que certains n'arrive pas à me suivre mais je vais tâcher d'expliquer tout dans le détail par la suite.Enfin la vue dynamique en fonction de la définition du résultat est tout simplement un json que nous allons afficher et qui va se remplir au fur et à mesure que l'utilisateur rempli les formulaires dont je vous ai parlé un peu plus tôt.

Structure du dossier moteur-de-regle

J'ai organisé mon site en plusieurs dossiers:

• contexte-definition:

Composants:

1.moteur-propriete-context: Sert à lister l'ensemble des propriétés du contexte

2.moteur-crud-context-properties: CRUD sur les propriétés du contexte

• resultats-définition

Composants:

1.moteur-propriete-resultat: Sert à lister l'ensemble des propriétés du résultat

2.moteur-crud-meta-resultat: CRUD sur les propriétés du résultat

• moteur-main: Vue ou on va pouvoir switcher d'une IHM à une autre et afficher les bons composants en fonction.

• mapping-model-selector: Les composants à l'intérieur de ce dossier vont nous servir à récupérer des modèles depuis le catalogue de service pour pouvoir importer leurs propriétés(le catalogue de service fera l'objet d'un autre article).

• moteur-regles:

Composants:

1.moteur-list: Sert à lister l'ensemble des regles

2.moteur-crud-regles: CRUD sur les regles

• resultats-instances: Résultat de ce que va afficher la troisième IHM qui n'est encore pas opérationnelle pour le moment.

Diagramme de Classe

Le moteur de règle a été conçu sous ce modèle:

Une règle aura donc un code, un nom ou libelle et un Etat actif(Classe Regle).

Les propriétés que nous allons créer vont venir alimenter le modelSchema(json-schema), le viewDefinition(egalement sous forme de json-schema) ou même les deux en fonction de ce que l'utilisateur selectionnera lors de la création de la propriété du contexte(Classe CritereDefinition) ou la propriété du résultat(Classe ResultDefinition).

Liste des règles

Au lancement, l'IHM qui nous est présenté est celle de Contexte Definitions. Comme il n'y a aucune règle sélectionnée, vous n'avez que deux choix: soit décider d'ajouter une règle soit sélectionner une règle. Comme je l'ai dit un peu plus tôt l'utilisateur doit être capable d'ajouter une règle, de la supprimer de voir son contenu et de la modifier. Voici ci-dessous la vue de sur le CRUD des règles.

Place du moteur de règles dans le Workflow

Voici un petit schema qui montre la place du moteur de regles au sein du workflow(enchainement des tâches et des services.

Les fonctionnalité du moteur de règles

• Offrir un service d’application des règles

En effet, le moteur de règle offre un service d’application de règles basées sur un contexte et permettant de déterminer le ou les résultats matchant avec ce contexte.

Ceci parmi une collection des combinaisons.

• Offrir une IHM permettant de modéliser la données de contexte

Cette IHM permet de générer un méta modèle des données de contexte et le méta modele de présentation associé pour une mode visualisation et édition.

Lors de la création ou de la modification d'une propriété du contexte, en fonction du choix de stockage de l'utilisateur(View/Schema ou les deux). On viendra alimenter un json-schema(ses propriétés)dont le modele ressemblerai a ceci.

On y introduit que le nom et le type de cette propriété puis on le stocke dans le modelSchema du diagramme de classe ci-dessus

Ou alors un formulaire qui ressemblerai à ceci.

L'avantage de ce json est que l'on pourra choisir la position(la ligne et la colonne) de la propriété dans le formulaire(dernière IHM) ainsi que le type du composant d'édition(select, input, date, time ect..). On viens transformer ce json en string pour le stocker dans la propriété viewDefinition de la règle.

• Offrir une IHM permettant de modéliser la données de résultat

Une agent installé sur le client pourra être utilisé pour injecter des données de masse sur le router par l’intermédiaire d’un flux tcp. L'IHM est sensiblement la même que pour le Contexte Definition.

• Offrir une IHM permettant la saisie des combinaisons de données et des résultats associés

L’objectif de cette IHM est de proposer à l’utilisateur final, une IHM permettant de définir les combinaisons de données contextuelles respectant le méta model.

A l'heure d'aujourd'hui, cette IHM n'est pas finie, je ne peux vous montrer le résultat final mais j'explique son fonctionnement un peu plus haut.

• Composant d’affichage dynamique

Il s’agit d’un composant graphique permettant de représenter des données respectant un méta modèle au format JSON Schéma et de les disposer en respectant un méta modèle de présentation (aussi au format JSON Schéma).

Depuis le début je vous parle de ce composant graphique, on y est! Le nom de ce composant est: angular4-json-schema-form

Si vous souhaitez l'intégrer à votre projet, voici le code Html qui va vous le permettre:

*schema= votre json-schema

*model= pas obligatoire

*layout= méta modèle de présentation (aussi au format JSON Schéma)

Vous devriez normalement obtenir quelque chose comme ceci(avec la combinaison deux).

Petite note: Il est tout a fait possible de ne mettre que votre schéma mais dans mon cas cela m'étais impossible.

• Intégration du moteur de règles dans designer de workflow

Il s’agit de positionner l’exécution d’une règle dans une l’interface de conception d’un workflow (enchainement de tâches & services). L’étape en question lance l’exécution de la règle en communiquant le contexte de l’étape précédente fin afin de trouver le résultat relatif à ce contexte.

Cas D'usages

On utilise un moteur de règles dans ces deux conditions:

• Si les flux sont synchrones:

• Si ils sont asynchrone(ou fil de l'eau) comme ci dessous:

Difficultés

Comme je l'ai mentionné dans un article précédent(Ma première expérience en entreprise) mes plus grosses difficultés ce sont situées sur le moteur de règles. D'une part, j'ai eut beaucoup de mal à comprendre la finalité du moteur de règles. En effet je ne comprenais ni l'utilité dans le projet, ni comment faire, ni le fonctionnement. J'ai eut besoin de beaucoup d'explications de schémas et de recherches pour comprendre. Au jour d'aujourd'hui, je n'ai pas finie de développer ce moteur de règle. Je ne suis pas satisfaite de mois car a mon sens j'ai mis trop de temps à comprendre et à vraiment me mettre en route sur cette tache. De plus construire et alimenter les json-schemas avec les bonnes informations on été pour moi un vrai casse-tête. Ce qui m'a pris le plus de temps c'est régler le fait que l'utilisateur puisse choisir la position de sa propriété dans le formulaire. Au final je me dis que si je m'étais posé les bonnes questions,les choses auraient probablement avancées plus vite et c'est un de mes regrets. Mis à part ceci, j'ai souvent des erreurs simples qui mettent parfois des heures à débuguer car quand j'essaye d'autres solutions d'autres erreurs apparaissent. Finalement mis à part ceci, je suis ravie d'avoir eut une tâche aussi dure parce que ça m'a appris la patience, à faire des recherches, l'autonomie ect... Si jamais j'en ai un autre à développer dans mes années futures j'aurais plus de facilité.

Au final, ce stage m'a vraiment et avant tout appris le travail d'équipe. De plus je suis ravie d'avoir put développer mes compétences en Angular car je me suis rendue compte que dans le monde de l'entreprise, il y a peu de développeurs Angular donc je pense que ça ne peut être qu'un plus pour moi.