Utilisation de l'AI pour le développement logiciel : le nouveau paradigme
© Jean-Marc Vanel - 2009-05-16 - 2011
Table des matières
Modularité intelligente : laissez des valences se relier
Avantages de l'IA pour une société développant du logiciel
Fonctionnalités novatrices dans les produits existants
Introduction
Pour le dire simplement, il y a un grand avantage à fermer la boucle entre Sémantique+Règles d'un côté, et Logiciel et Outils d'un autre côté :
générer, manipuler, transformer, lier
Sémantique ----------------------------------------> Logiciel
+ règles <---------------------------------------- + outils
écrire, manipuler, transformer, lier
En mode plus bavard, un IDE (Environnement de Développement Intégré) est un logiciel et un outil. Du côté logiciel, c'est un éditeur pour Ontologies et règles, et du côté outil il peut fabriquer un autre logiciel, ou lui-même.
Il y a également un autre cercle vertueux, que nous verrons dans le prochain paragraphe « GUI : le bon domestique« :
développer avec sémantique+règles <==> offrir des fonctionalités intelligentes aux utilisateurs
L'aspect principal est de travailler au niveau sémantique, permettant de déduire beaucoup de conséquences des modèles et des données, complétés par quelques connaissances de base et de sens commun. Ces conséquences peuvent être beaucoup de choses : des explications, des éléments à mettre en surbrillance, un graphe entier d'objets et propriétés, une liaison entre composants logiciels, et même une application entière.
Pour un exemple des connaissances de base, UML, Autosar, SCA (architecture de communication de logiciel), et d'autres outils et bibliothèques de modèles partagent beaucoup de concepts et notions, mais cette connaissance n'est actuellement pas explicite et par conséquent non utilisable.
Pour un autre exemple des connaissances de base, beaucoup d'applications de gestion ont une notion de client.
Même pour un domaine particulier, il y a beaucoup de variantes de client, individuel ou compagnie, régulier ou occasionnel, national ou international, etc. C'est dans l'état de l'art d'écrire une ontologie sur le commerce et les clients. Mais à partir de cette connaissance-là il n'y a aucun outil simple pour construire une application de gestion.
Le paradoxe de l'informatique est que, alors que l'informatique consiste à automatiser les choses, le développement logiciel lui-même encore fait largement à la main. Ma conviction est cependant qu'il est possible d'appliquer des techniques d'AI aux tâches courantes de développement, comme produire du code de jointure, refactoriser, détecter et appliquer des modèles de conception. Il y a plus encore: voyez ci-dessous « Modularité intelligente".
Nous voulons être à un niveau sémantique et déclaratif où la spécification d'une solution désirée permet de trouver cette solution; ou au moins de la contraindre assez pour être utile.
Vous pouvez demander : pourquoi cette révolution ne s'est-elle pas déjà produite ?
La raison n'est pas que la technologie soit absente; les outils et les concepts sont ici, en fait beaucoup plus d'outils et de concepts que nécessaire ! Et la recherche en AI ajoute tout le temps. La raison est que la vision manque généralement. Et les personnes compétentes ont assez de travail.
En effet dans le domaine de l'AI et des ontologies, peu de gens s'inquiètent des stratégies de développement de logiciel, ceci est un peu un sujet impur. Les auteurs d'ontologie travaillent à de meilleurs modèles; les réalisateurs le moteurs d'inférence et d'IHM travaillent à leurs outils, les gars du W3C créent des formats d'échange comme le OWL et le RDF, et les praticiens « traditionnels » d'AI font des systèmes experts. Mais tout cela ne donne pas des solutions concrètes. Car la "colle" logicielle est absente. Une autre raison est que les techniques d'AI sont abstraites, complexes, qu'il y a de multiples outils, langages et concepts. Pour reconstruire une simplicité en partant de tout cela, une vaste expérience du génie logiciel, de l'AI, et un dur travail sont nécessaires.
Je ne sais pas si la future manière de programmer sera un nouveau langage (y compris langages naturels contrôlés ), de nouveaux GUI, de nouveaux moteurs d'inférence, ou de nouvelles infrastructures de collaboration. Ce sera probablement un mélange de tout cela, et permettra à différents programmeurs et utilisateurs de voir et développer le même projet dans différentes vues selon leur personnalité et rôle.
Mais une chose que je suis sûr est que la programmation de demain sera très différente et basée sur les modèles logiques formalisés des domaines d'application (appelés les ontologies), étroitement reliés au langage naturel, soulageant des réalisateurs de la nécessité de re-déclarer toujours des connaissances de base que tout le monde a.
Je me rends compte que c'est tout à fait disruptif pour beaucoup de compagnies développant du logiciel, mais c'est en fait complémentaire au procédé classique de développement, comme nous verrons dans le paragraphe « Modularité intelligente".
Il faut trouver le bon mélange des techniques suivantes; elles ont beaucoup d'usages potentiels. C'est comme l'électricité dans les années dix-neuf cents, il y a un grand potentiel, mais ce n'est pas évident quelle utilisation réussira d'abord.
Voici les techniques :
Le Prolog (programmation logique) est une technologie mûre. Le Prolog est le « langage C » de l'AI : mûr, puissant, un bon nombre d'implémentations, et d'extensions.
La programmation logique avec contraintes (CLP) est un mélange de Prolog et de programmation par contrainte, où les réponses à une requête sont plus générales que de simples assignations de variables, et inclut également des contraintes (simplifiées par rapport aux entrées).
Les logiques de description (DL) ont encore moins de puissance expressive que le Prolog mais elles ont l'avantage que la puissance expressive est conçue en fonction de ce que les algorithmes connus peuvent traiter pour les modèles quelconques dans un temps CPU acceptable. Elles correspondent également à une manière tout à fait intuitive de décrire des objets et des classes par leurs propriétés et certains primitives de théorie des ensembles. Ainsi les DL sont employées souvent comme format de base d'ontologie, qui est complété par des règles. Le format OWL du W3C est devenu le format standard pour les DL.
Les prouveurs de théorème (TP) sont une classe des solutionneurs pour la logique du premier ordre (FOL). La FOL peut tout à fait commodément exprimer n'importe quelle connaissance non-probabiliste (le Prolog est moins expressif). L'inconvénient avec les TP est que la complexité est exponentielle (mais des heuristiques sont employées) et que des questions pour des réponses négatives ne sont pas garanties de se terminer en temps fini.
La synthèse de programme signifie de construire un programme répondant à des spécifications données, en prouvant l'existence d'un objet répondant aix conditions indiquées. La preuve est limitée pour être suffisamment constructive.
Après les technologies, parlons de quelques utilisations possibles.
Si nous voulons offrir aux utilisateurs le niveau d'aide et d'intelligence dont ils ont besoin, il y a une manière prometteuse.
Ce que j'appelle paradigme du bon serviteur signifie que chaque action de l'utilisateur doit être enregistrée et avoir une chance d'être exploitée pour en déduire ses intentions, et proposer des actions appropriées. A nouveau, s'appuyer sur des inférences logiques à partir d'ontologies est la manière de réaliser ceci d'une manière flexible et maintenable. Actuellement les Interfaces Homme-Machine "vivent" dans un présent éternel, comme des personnes souffrant de maladies de mémoire.
Les exemples dans les IHM (GUI) qui pourraient tirer bénéfice de ce paradigme sont :
J' insiste sur le fait que, pour tous ces cas d'utilisation de visualisation, le comportement résulte à la fois de l'historique des actions utilisateur et, classiquement, des données instantanées de l'application et de l'état global d'exécution. Cette partie d'une application est implémentée comme modèle de conception "observateur", et peut être comparée à la « conscience » de l'application.
Inférer des formulaires en programmation logique
En utilisant des méta-données sur des classes et des propriétés (UML ou OWL), il est possible d'inférer un formulaire de saisie. Je donne deux exemples de règles. Par exemple, si une propriété a la cardinalité exactement 1, le formulaire se comportera afin de refuser la validation jusqu'à ce qu' une valeur ait été écrite. Si la propriété est composée (dans le sens d'UML), un formulaire inclus pour un objet correspondant doit être créé ; sinon, un menu déroulant ou autre composant de recherche permettra de connecter un objet existant.
À un niveau implémentation, n'importe quelle bibliothèque d'IHM contient des champs d'entrée, boîte combo, rappels de service, etc. Ces widgets/concepts ont à peu près la même sémantique partout, mais différentes API. Ainsi, une fois que vous avez choisi un bibliothèque d'IHM, vous êtes coincé. Ceci nous amène au prochain paragraphe.
Si assez d'ontologies, d'annotations, et de puissance d'inférence sont disponibles, un processus de développement peut arriver à un niveau sémantique où on est indépendant des cadriciels (frameworks) tels que EMF d'eclipse, ou des cadres de GUI tels que Java/Qt/GTK/WxW, et même à eclipse.
Bien que nous soyons indépendant du cadre pendant le développement, mais avons la possibilité de déployer l'application dans différents cadriciels (frameworks) ou plateformes, comme eclipse, J2EE, PHP, Firefox, LibreOffice,…
Suivant la même ligne de pensée une application définie d'une manière déclarative devrait être déployable sur un GUI ou en mode client/serveur avec peu ou pas de modification. C'est vrai non seulement pour le cadre d'application, mais n'importe quel genre de bibliothèque peut être « conceptualisé » : accès aux bases de données, réseau, numérique, …
Ce sont des conséquences à granularité grossière de principes qui sont applicables à n'importe quel niveau de granularité.
L'analogie chimique est : vous avez dans un tube à essai un mélange des composants logiciels (comme des molécules avec les emplacements réactifs), et de cela une application peut prendre la forme, reliant les emplacements réactifs.
La technique implique d'annoter les bibliothèques, les classes et fonctions. L'annotation première est l'objectif, c'est à dire les fonctionnalités fournies et requises.
L'utilisateur peut annoter l'élément logiciel avec le objectif lui-même, mais nous pouvons également récupérer l'objectif par plusieurs autres manières : analyse d'échantillons de programmes et de modèles, analyse linguistique.
L'autre annotation concerne les flux de données; c'est une généralisation des paramètres d'entrée et de retour des fonctions. Cela signifie indiquer une ou plusieurs séquences d'appel typiques échangeant des données entre un conteneur et des composants. C'est comme une machine d'état de protocole en UML 2. Une analyse d'échantillons de programmes peut également permettre de retrouver ces informations, au moins suggérer des flux de données à l'utilisateur.
D'autres outils de développement logiciel peuvent tirer parti de l'approche sémantique et déclarative: appliquer et identifier des modèles de conception, inférer des protocoles, analyser et comparer les modèles pour trouver des redondances.
Sous Linux, on peut trouver et installer très facilement des milliers d'applications.
Mais pour le développeur qui cherche des composants logiciels, ce n'est pas aussi facile.
Même en faisant abstraction de la diversité des langages de programmation, il reste les problèmes suivants :
Nous mettons en avant le concept de "Modularité Intelligente", qui remédie aux deux problèmes ci-dessus:
Nous pensons qu'ainsi tout le pouvoir des milliers de logiciels et composants du Logiciel Libre et Open Source pourra pleinement se réaliser, et laisser sur place le logiciel commercial.
Pour l'instant (juillet 2011) tout ceci est à l'état de projet.
Ce que je propose comme techniques basées sur l'AI est une oportunité à saisir, à la fois en tant qu'outils de développement internes, que de fonctionnalités innovatrices dans les produits existants, et de produits futurs. Afin d'avoir une avance concurrentielle, la formation et les changements du processus de développement devraient commencer dès maintenant.
Il y a des raisons de croire qu'ajouter l'intelligence artificielle au génie logiciel est la prochaine grande révolution dans le développement logiciel.
Après avoir obtenu un succès limité dans les années '90 pour les systèmes experts, l'AI est retournée dans l'obscurité et y est restée. Maintenant dans les années 2000 il y a un élan dû au projet Semantic Web du World Wide Web (W3C). Le Prolog est une technologie mûre et puissante, et le format d'échange OWL du W3C est un format d'échange prometteur. Parmi les autres techniques sont la logique de description, la programmation logique avec contraintes (CLP), et les démonstrateurs de théorèmes. Il y a eu un progrès continu dans les concepts et les algorithmes, illustré par la victoire de l'ordinateur aux échecs sur un champion du monde.
J' ai réfléchi et étudié cela pendant plus de 5 années. Dans ces dix dernières années, j'ai prévu les tendances dans le développements logiciel : Orientation Objet, XML, code source libre. Et maintenant ma prochaine prévision est celle-ci au sujet de l'AI. Il se produira nécessarement; le logiciel devient si complexe, et les espérances des utilisateurs sont si grandes.
Futurs produits
Des fonctionnalités d'AI ont été rarement appliquées aux outils d'AI eux-mêmes. Si vous regardez des éditeurs de OWL comme Protégé et Swoop, il n'y a pas un seul gramme de comportement intelligent, ce qui est un paradoxe pour un outil d'AI.
Il n'y a aucun outil commercial ou code source libre bien établi pour l'ontologie et la programmation basée sur les règles, qui puisse intégrer plusieurs standards comme SQL, OWL, UML, les langages OO classiques, Prolog, CLP, les systèmes de production (moteurs de chaînage avant comme Drools), les ressources linguistiques comme WordNet, et produire une application complète bien-écrite, GUI ou Web.
Ce qui existe, ce sont quelques outils spécialisés pour un des domaines ci-dessus, comme les outils d'Ilog, Protégé, SWI-Prolog, outils aller-retour UML comme Borland, outils XML comme Stylus ou XML-Spy, et outils de gestion de la connaissance.
Un tel IDE construirait une application de l'air du temps, en fait à partir d'une spécification de haut niveau.
C'est plutôt ambitieux, c'est comme la grande unification en physique. Mais finalement au jour le jour, les réalisateurs font cette unification, mais à la main. Ils ont besoin d'outils pour les aider. Étant donné que cet IDE peut s'augmenter en l'utilisant, c'est une manière de réaliser le vieux rêve de l'AI : en ayant un outil qui s'augmentera par l'usage, surpassant finalement l'intelligence humaine. Mais ce n'est certainement pas une machine apprennant par elle-même, c'est l'homme qui enseigne par des approximations successives. Et naturellement il n'y aura pas seul un outil tout-puissant, mais beaucoup d'outils/d'agents spécialisés, qui communiqueront sur Internet par le langage de la logique du premier ordre.
Dans un document compagnon, j'esquisse un programme de développement : "La grande unification dans la technologie de la programmation". Un environnement de développement (fait à la main) a été développé pour démarrer: EulerGUI . Par la suite EulerGUI sera développé en utilisant les techniques exposées dans cet article.
Le projet Déduction vise à réaliser les promesses de cet article. Comme preuve de concept, nous développons un générateur de formulaire à partir d'un modèle métier (ontologie) en OWL, de règles en logique N3, plus quelques spécifications additionelles.
Des services de conseil, développement, et formation sont proposés sur mon site: http://jmvanel.free.fr/ .