Visual Rules édité par Bosch Software dispose d’un outil de modélisation dont l’ergonomie est particulièrement intéressante. Cette ergonomie permet de spécifier des raisonnements logiques de manière très intuitive c’est-à-dire sans nécessiter beaucoup de préalables techniques.
Vous n’avez ni besoin d’avoir préalablement formalisé votre vocabulaire, ni besoin d’avoir défini la structure de données, ni besoin d’avoir préalablement conçu votre modèle exécutable (XOM), ni non plus, besoin dans dans un premier temps, d’utiliser un langage formel prédéfini.
Dans une perspective de réappropriation de l’outil informatique par les métiers, le fait de nécessiter peu de préalables est intéressant à plusieurs titres, il permet à de nombreux acteurs de démarrer sans beaucoup d’investissements intellectuels et surtout il permet d’éviter ou de limiter le passage par des experts techniques souvent peu disponibles et pouvant, parfois, manquer d’expertise pédagogique.
Pour décrire votre logique vous utilisez une représentation arborescente et vous décrivez le sens de chaque noeud dans le langage de votre choix.
Un noeud de l’arbre équivaut à un test et une feuille à un résultat ou une action à lancer.
A tout moment vous pouvez écrire à côté du texte en clair un texte plus formel destiné à être interprété par la machine.
Bien que le formalisme “arbre de décisions” soit aussi utilisable avec jrules (ilog-ibm) ou de drools (red-hat). Cette approche est assez différente de celles de jrules (ilog-ibm) ou de drools (red-hat), elle est n’a pas que des avantages mais elle a celui de la simplicité. Les outils comme jrules ou drools ont plus tendance à nécessiter la mise en place préalable de domaines métiers (vocabulaire métier + structure objet ), sans pour autant d’ailleurs que ce soit indispensable.
Il faut signaler que visual rules n’utilise pas de moteur de règles à proprement parler, il permet d’éditer des règles sous des formes claires et lisibles, il permet de concevoir des logiques de décisions ou de raisonnement mais lorsque vous placez un test vous devez déterminer à l’avance où ce test ce déclenchera.
A titre d’exemple voici un arbre de décision qui permet de décider si une personne est ou n’est pas l’oncle d’une autre personne. La définition du concept “oncle” ou “tante” est réalisée à partir des relations de parenté “soeur”, frère, “fils” et fille.
Cette arborescence n’est pas exécutable au sens où les noeuds de l’arbre ne contiennent pas encore de code formel (cet exercice sera réalisé dans un autre billet) mais elle constitue une première de familiarisation avec l’outil et avec la modélisation des logiques de raisonnement.
L’étape suivante est l’écriture d’expressions formelles avec son ensemble de préalables (structures de donnée, structures objets) exécutables par la machine. Cette deuxième étape aura tendance à remettre en cause, au moins partiellement une partie des travaux déjà réalisés. Que cela ne vous incite pas, pour autant,à sacrifier la première étape, elle est très utile pour éviter quelques allers-retours des plus ennuyeux !
Vous n’avez ni besoin d’avoir préalablement formalisé votre vocabulaire, ni besoin d’avoir défini la structure de données, ni besoin d’avoir préalablement conçu votre modèle exécutable (XOM), ni non plus, besoin dans dans un premier temps, d’utiliser un langage formel prédéfini.
Dans une perspective de réappropriation de l’outil informatique par les métiers, le fait de nécessiter peu de préalables est intéressant à plusieurs titres, il permet à de nombreux acteurs de démarrer sans beaucoup d’investissements intellectuels et surtout il permet d’éviter ou de limiter le passage par des experts techniques souvent peu disponibles et pouvant, parfois, manquer d’expertise pédagogique.
Pour décrire votre logique vous utilisez une représentation arborescente et vous décrivez le sens de chaque noeud dans le langage de votre choix.
Un noeud de l’arbre équivaut à un test et une feuille à un résultat ou une action à lancer.
A tout moment vous pouvez écrire à côté du texte en clair un texte plus formel destiné à être interprété par la machine.
Bien que le formalisme “arbre de décisions” soit aussi utilisable avec jrules (ilog-ibm) ou de drools (red-hat). Cette approche est assez différente de celles de jrules (ilog-ibm) ou de drools (red-hat), elle est n’a pas que des avantages mais elle a celui de la simplicité. Les outils comme jrules ou drools ont plus tendance à nécessiter la mise en place préalable de domaines métiers (vocabulaire métier + structure objet ), sans pour autant d’ailleurs que ce soit indispensable.
Il faut signaler que visual rules n’utilise pas de moteur de règles à proprement parler, il permet d’éditer des règles sous des formes claires et lisibles, il permet de concevoir des logiques de décisions ou de raisonnement mais lorsque vous placez un test vous devez déterminer à l’avance où ce test ce déclenchera.
A titre d’exemple voici un arbre de décision qui permet de décider si une personne est ou n’est pas l’oncle d’une autre personne. La définition du concept “oncle” ou “tante” est réalisée à partir des relations de parenté “soeur”, frère, “fils” et fille.
Cette arborescence n’est pas exécutable au sens où les noeuds de l’arbre ne contiennent pas encore de code formel (cet exercice sera réalisé dans un autre billet) mais elle constitue une première de familiarisation avec l’outil et avec la modélisation des logiques de raisonnement.
L’étape suivante est l’écriture d’expressions formelles avec son ensemble de préalables (structures de donnée, structures objets) exécutables par la machine. Cette deuxième étape aura tendance à remettre en cause, au moins partiellement une partie des travaux déjà réalisés. Que cela ne vous incite pas, pour autant,à sacrifier la première étape, elle est très utile pour éviter quelques allers-retours des plus ennuyeux !
