=> 
Le cadriciel EulerGUI / Déductions
Mai 2012
Sommaire
Une partie de ce document a été rédigée en s'inspirant de cette présentation: Représentation des connaissances avec Anglais contrôlé, ontologies et règles , et de cette partie de la documentation :
EulerGUI application building Framework .
On s'appuie sur un outil de développement et un framework innovant (cadriciel) en Logiciel Libre, EulerGUI .
EulerGUI est développé par la SARL Déductions.
EulerGUI permet de ne plus coder la logique et les modèles métier dans un langage prodédural tel que Java, ce qui diminue beaucoup la charge de travail et facilite l'adaptation multi-plates-formes, multi-persistence, et multi-langages.
Les points essentiels du framework (cadriciel) sont:
Nous allons détailler tous ces points dans l'ordre.
Tout cet aspect déclaratif apporte de la flexibilité par rapport au déploiement, la persistance, et l'IHM.
En amont du cadriciel, la technologie des Langages naturels contrôlés (CNL) permet de spécifier les modèles, ontologies et règles métier à partir de simples phrases en Anglais formel. Ce sera l'objet de l'avant dernier paragraphe.
Les technologies Orienté Objet (Java, UML, Python, C++, C#, etc) sont actuellement le paradigme dominant du développement logiciel, qui a lui-même remplacé la décomposition en fonctions.
Il y a plusieurs gros problèmes avec cette approche.
D'abord ces langages ne mettent aucune restriction au mélange libre d'éléments métiers et d'infrastructure. Or, une séparation rigoureuse entre métier et infrastructure est reconnue comme un élément capital de la qualité du logiciel et de la traçabilité.
Les tenants de l'Orienté Objet et d'UML ont promis une réutilisation de code et de modèles. Or, cette réutilisation n'a jamais eu lieu, en ce qui concerne les modèles métier. Au contraire (cf infra), l'écosystème du Web Sémantique offre des milliers de modèles métier réutilisables.
Enfin, l'Orienté Objet et UML induisent une rigidité au coeur de leur manière de voir: un objet est créé une fois pour toutes avec un type immuable. Par exemple cela interdit qu'un objet de classe "Chômeur" soit requalifié en "Employé" quand il trouve un emploi. Au contraire avec les Ontologies c'est automatique. Une autre rigidité est liée à la cardinalité des relations. Passer d'une cardinalité 1 à multiple oblige à changer beaucoup de code. Enfin, pas plus que les bases SQL, l'orienté objet n'est pas adapté à ajouter des paires propriétés-valeurs quelconques à un objet quelconque (principe d'extensibilité ou annotation).
En ce qui concerne la persistence des données, l'approche traditionnelle consiste à utiliser une correspondance Objet-Relationnel (ORM) telle que Hibernate. Ce qui revient à cumuler les inconvénients de l'Orienté Objet avec ceux du relationnel, plus les surcoûts liés à la correspondance.
On peut dire que l'Orienté Objet pour les données métier a vécu. Le temps est venu des bases de connaissances!
Cependant, l'Orienté Objet demeure valable pour le code d'infrastructure et algorithmique.
En résumé, il s'agit d'une révolution copernicienne! L'Orienté Objet, qui était au centre, passe à la périphérie. Et les ontologies et règles passent au centre.
Pour se libérer des inconvénients des langages Orientés Objet et procéduraux, le premier "ingrédient" de la solution est d'utiliser un moteur d'inférence, plus précisément un moteur en chaînage avant avec l'algorithme optimisé RETE. Le moteur utilisé est Drools, un projet Java Open Source solide.
Ce qu'on appelle ici moteur d'inférence s'appelle aussi "système expert", "moteur de règles", "système de production". Ce sont des technologies employées avec succès depuis 20 ans pour des problèmes très divers et souvent complexes: configurateur de produits complexes, rabais commerciaux, médecine, droit, filtrage réseau, etc. Grâce au cadriciel qui fait la fusion avec le Web Sémantique, et à l'excellente intégration de Drools avec Java, nous pouvons utiliser le moteur d'inférence non seulement pour des calculs spécialisés, mais systématiquement pour toute la logique applicative.
Techniquement, les données métier en mémoire sont hébergées dans le moteur sous forme de triplets RDF (sujet - propriété - valeur, voir paragraphe suivant Technologies du Web Sémantique ).
Les règles sont interprétées directement par le moteur, et non pas traduites en Java. De même, les définitions de classes et propriétés sont insérées telles quelles dans le moteur, et non pas traduites en Java. Ainsi, grâce à des règles génériques, les conséquences utiles sont déduites au fur et à mesure des modifications de données. Dans l'exemple mentionné ci-dessus, un objet de classe "Chômeur" est requalifié en "Employé" quand il trouve un emploi.
Avec cette technologie, la génération de classes métier POJO (Plain Old Java Object ) est inutile!
On a la possibilité de traiter par règles au choix, du plus restreint au plus étendu :
Il reste reste à gérer par du code écrit à la main:
Le point 1 doit être mis en œuvre par la main, mais dans de nombreux cas cela revient à récupérer la fermeture récursive d'ordre 1 ou 2 à partir des ressources d'intérêt courant. La contrainte est que la base de connaissance doit tenir en mémoire.
Par exemple, dans le domaine médical, ce sera la totalité du dossier patient, plus peut-être des généralités sur ses maladies et ses médecins traitants.
Dans le domaine réseau social, ce sera toutes les connaissances de l'utilisateur courant avec leurs propriétés, éventuellement au 2ème niveau, plus toutes les publications, celles de l'utilisateur courant et de ses connaissances.
Pour automatiser cela, nous prévoyons de concevoir et mettre en œuvre un moteur en chaînage arrière pour l'interrogation des bases de données SPARQL; il va générer une grosse requête SPARQL en accumulant récursivement les critéres de requête, substituant au passage les variables liées, en les renommant si nécessaire.
Pour le point 2, la persistance des données, on peut utiliser une ou plusieurs règles génériques simples, couplées avec des mises à jour avec SPARQL 1.1 .
Il faut noter que pour le point 3, il y existe déjà une base de règles (voir la base de règles pour applications basées sur Swing).
Le Web Sémantique vise à gérer et partager une information sémantiquement transparente, adaptée à la Toile (Web) , interopérable.
Ces technologies apportent un bol d'air salutaire dans le domaine des bases de données, du stockage persistant, et des échanges de données.
Comme son nom l'indique, la sémantique est beaucoup plus apparente et interopérable que dans les bases relationnelles, orientées objet, NoSQL (tableaux associatifs), ou en XML.
De plus, la donnée est considérée d'une manière uniforme, qu'elle soit dans un serveur de base de données, dans un fichier local, dans un document accédé via HTTP, ou même en mémoire de l'ordinateur.
La flexibilité augmente par rapport aux technologies classiques: on peut toujours ajouter n'importe quelle paire propriété-valeur à un objet (alias ressource).
L'objet central, ici appelé resource, est représenté par un URI, qui est un identifiant globablement unique. Il est généralement basé sur HTTP, et généralement on peut y accéder via HTTP et recevoir des informations lisibles par l'homme. Tout est URI, et tout peut avoir son URI : tout ce qu'on met d'habitude dans les bases de données, et aussi les propriétés et les classes. Ainsi les données, concepts et objets ont un point d'ancrage, qui de plus est lié à la Toile.
La donnée est définie par une seule construction: le triplet (alias affectation) ; chaque triplet suit le format <sujet><propriété><valeur>. La valeur (dite "objet") peut être une ressource (URI) ou une chaîne de caractères, éventuellement typée. Cela définit ce qu'on appelle en mathématiques un graphe orienté.
La sémantique est apparente dans chaque triplet : la propriété est un identifiant qui peut avoir une signification acceptée par consensus, assurant ainsi une interopérabilité au niveau des concepts.
De même, le sujet de chaque triplet est un identifiant globalement unique qui, s'il est exporté par une source de données, ou s'il fait l'objet d'un consensus, permet :
En ce qui concerne la flexibilité, la structure de données n'est pas figée au niveau du conteneur, comme c'est le cas en SQL ou XML. En particulier, la cardinalité des relations n'est pas figée, pas plus que la liste des propriétés possibles n'est limitée par l'appartenance à une classe. On peut donc utiliser un conteneur générique, et il n'y a pas besoin de faire un CREATE TABLE, comme en SQL, avant de de stocker des données. Le protocole réseau pour les requêtes sur les bases de données sémantiques est fixé par la recommandation SPARQL, ainsi que le langage de requête bien sûr. La situation est bien différente dans le monde relationnel, où chaque base de données a son propre protocole réseau. De plus, les bases accessibles par requêtes SPARQL ne sont pas la seule possibilité. On peut aussi partir d'un URL HTTP, le télécharger, puis naviguer de proche en proche via les URI qu'il contient. C'est un peu comme un utilisateur humain qui navigue sur la Toile, mais c'est à la portée d'un agent programmable.
Sans contrevenir à la flexibilité, le Web Sémantique permet de spécifier formellement des notions de propriétés et de classes, via RDF Schéma et OWL. Il n'y a pas de limitation au nombre de classes associées à une ressource (URI), ni au nombre de paires propriété-valeurs.
Il existe une famille de syntaxes lisibles et rédigeables par l'homme: N3, Turtle, N-Triples. N3 est un format pour presque tout: données, classes et propriétés, et règles. N3 est le langage principal de facto pour le Web sémantique, beaucoup plus lisible et concis que RDF (Resource Description Format) ; voir Primer: Getting into RDF & Semantic Web using N3 . L'outil Open Source EulerGUI ; partie intégrante du cadricel, est centré sur l'édition textuelle de sources N3.
Grâce à ces fondations solides, et au soutien du W3C, l'écosystème du Web Sémantique offre des milliers de modèles métier (appelés aussi vocabulaires), dont beaucoup sont devenus des standards dans leur domaine (FOAF, Dublin Core, DOAP, Good Relations, etc). Il existe des sources de données ouvertes réutilisables (Linked Open Data) . Elles sont disponibles sur le Web dans tous les domaines: sciences, musique (MusicBrainz), géographie, données gouvernementales (data.gov), encyclopédie DBPedia , etc.
La logique de description est une technologie mûre, fruit de recherches abouties sur la représentation des connaissances en Intelligence Artificielle.
Le World Wide Consortium (W3C), a standardisé OWL, un format d'échange pour la logique de description, avec le souci d'inter-opérabilité qu'on lui connaît.
Une ontologie se présente comme une hiérarchie de classes et propriétés.
L'écosystème du Web Sémantique offre des milliers de modèles métier réutilisables, dont beaucoup sont devenus des standards dans leur domaine (FOAF, Dublin Core, DOAP, Good Relations, etc). Ceci représente un avantage tant pour l'économie de conception, que pour l'interopérabilité.
Au paragraphe "Inconvénients des modèles métier programmés en langages procéduraux", nous avons mentionné les rigidités inhérentes à l'approche traditionnelle ( voir aussi Critiques d'UML ). Au contraire, avec OWL, les instances (individus) associées à un URI sont gérées sémantiquement et dynamiquement. C'est à dire que l'appartenance à une classe peut être définie par les valeurs ou le type de certaines propriétés. Par exemple, supposons que l'ontologie OWL déclare: "un employé est une personne qui a un emploi". On peut alors calculer l'appartenance a la classe "Employé"; c'est dynamique en fonction des données.
La logique de description est donc une "algèbre" définissant des nouvelles classes à partir des anciennes.
On peut aussi, classiquement, affirmer inconditionnellement l'appartenance à une classe.
Une tendance actuelle est aux DSL (Langages Spécifiques à un Domaine), à la place d'UML. Nous pensons cependant qu'il ne faut pas renoncer à un langage général pour les modèles; mais il faut choisir le bon. A l'évidence, une famille de langages se distingue, promue par le W3C, avec le souci d'inter-opérabilité qu'on lui connaît. Il s'agit de RDF, OWL, et N3.
Les modélisateurs n'ont cependant pas à perdre leurs habitudes en conception OO, UML, EMF, SQL; il y a des points communs : notions d'objet, classes, propriété, d'héritage. Mais il y a des possibilités nouvelles: raisonnement logique intégré, modèles (vocabulaires) et sources de données réutilisables (voir 1.4. Technologies du Web Sémantique ), héritage entre propriétés. On peut noter aussi que contrairement à UML, une ontologie est un modèle logique sans aucune référence à des notions informatiques.
Les raisonneurs OWL peuvent prouver que les classes d'une ontologie sont exemptes de contradictions.
Les règles applicatives représentent la manière (plus ou moins spécifique) avec laquelle le monde extérieur interagit avec le noyau de l'application, c'est à dire le moteur d'inférence.
Par exemple, suivant le contexte, l'historique, et les droits de l'utilisateur, les champs de saisie et les actions ne seront pas les mêmes.
Ces règles applicatives jouent sur des classes et propriétés qui modélisent l'interaction, par exemple le fait d'être une alerte ou un simple message, d'afficher un courbe et/ou un tableau de chiffres, etc. Ce "vocabulaire" d'interaction est lui aussi plus ou moins spécifique de l'application construite.
On a besoin ici de plus de flexibilité que n'en permettent les ontologies au format OWL. La logique applicative est donc exprimée par des règles en logique formelle. On utilise ici le format N3 du Web Sémantique, qui a été créé par des membres éminents du W3C pour leur propre usage. On en verra un exemple ci-dessous.
Il existe aussi une base de règles générique, qui crée dynamiquement un formulaire de saisie à partir de la donnée d'une classe ou d'une ressource. Pour beaucoup d'applications, cela peut suffire. Et surtout cela représente une possibilité de RAD (Rapid Application Development) . Ainsi on peut prototyper la logique métier, afin de la faire manipuler par ceux qui l'ont définie. Mais ce RAD, au lieu d'être un prototype jetable, est fondé sur un modèle métier réutilisable.
=>
Le moteur d'inférence traite en parallèle des règles métier, et des règles de bas niveau, mixtes, c'est à dire mélangeant des critères métier avec des conséquences agissant sur les objets Java. On peut voir une vidéo qui montre exactement cet exemple : démoonstration cadriciel EulerGUI : mélanger règles métier et règles Java .
Les règles métier peuvent être séparées en :
Voici par exemple une pure règle métier qui dit que "si une pression sanguine dépasse 70, alors le service 112 passe en état d'alerte":
{ BloodPressure val ?x.
?x math:greaterThan 70
} => {
Service112 alert "true" } .
Ce fait déclenche la règle:
:BloodPressure val 72 .
Avec ces deux éléments la conclusion ajoutée à la base de connaissances est :
Service112 alert "true" .
Maintenant on ajoute une règle applicative, qui dit que "si quelque chose est en état d'alerte, alors l'application doit afficher cet état d'alerte".
{ ?L alert "true"
; log:uri ?LL .
} => {
application displayAlert ?LL . }.
Avec ces trois éléments la conclusion ajoutée à la base de connaissances est :
application displayAlert "http://eulergui.sourceforge.net/examples#Service112".
Voici maintenant la liaison avec la plate-forme Java, c'est à dire une règle "mixte", qui mélange un critère métier avec une conséquences créant et modifiant un objet Java :
{ application displayAlert ?LL .
} => {
?F a java:eulergui-gui-TemporaryFrame # instanciation
; javap:localizedMessage ?LL . # affectation propriété
}.
La bonne pratique est que ces trois types de règles: logique métier pure, logique applicative, et liaison Java, sont dans des fichiers différents. Ainsi on réalise le besoin mentionné ci-dessus de "séparation rigoureuse entre métier et infrastructure" .
De toute manière, les fichiers contenant des règles mixtes sont traçables facilement par leur préfixes d'URI.
Il en sera de même avec les règles applicatives.
Il est possible de spécifier ontologies et règles métier à partir de simples phrases en Anglais formel. Cela combine logique formelle et Anglais standard. En voici un exemple:
Every client is a person.
Everything that a man buys is a good.
Les avantages sont :
Nous préconisons l'outil en logiciel libre ATTEMPTO ACE. Les outils sont : ligne de commande, client Web, client Swing (via Protégé), Wiki Sémantique. Le projet ATTEMPTO est Zurichois, et issu de fonds publics Européens. Voici une vidéo sur ACEWiki, un Wiki sémantique, basé sur l'anglais contrôlé. C'est un exemple de ce qu'il est possible de faire comme application avec un moteur d'inférence en arrière-plan.
Voici un diagramme représentant les flux d'information dans un projet d'application .
Typiquement un cogniticien ( knowledge engineer ) interroge les experts métiers, pour écrire la logique et l'expertise métier en anglais formel ACE. Ce formalisme, lisible par l'homme, exprime aussi bien les règles de gestion, que la structuration en classes et propriétés. Les Ontologies du domaine sont en général disponibles sur Internet. On peut aussi les créer en utilisant un éditeur d'ontologie OWL tel que Protégé, ou l'anglais formel ACE..
Les spécifications fonctionnelles font la liaison entre des évènements et des types de visualisations génériques (tableau, arbre, formulaire, etc) ou spécifiques à l'application.
La logique et l'expertise métier ainsi formalisées sont aussi utilisables pour l'urbanisation du Système d'information.
Notes:
tout ce qui vient de l'utilisateur ayant les droits, validé, est automatiquement sauvé
Le déploiement et typiquement sur une JVM Java, mais il y a d'autres possibilités, voir Deployment of an EulerGUI project .
Voir feuille de route EulerGUI
Cadriciel EulerGUI
e:optional,
etc)