Sous-projet OCL/IREC.

Ce projet vise la gestion de l'évolution d'entités logicielles interdépendantes, développées dans un monde Eiffel persistant : classes, instances persistantes, bibliothèques, applications.

L'étude de l'état de l'art sur les problèmes d'évolution montre que la plupart des travaux portent sur l'identification, la mémorisation, et la gestion des variations (gestion de versions ou de configurations), dans un cadre sémantique faible, ce qui explique un manque d'aptitude pour le problème fondamental de la réactualisation des entités dépendantes.

Pour réactualiser, de la manière la plus automatiquement possible, les entités qui dépendent de changements, il faut un cadre qui permette :

• une perception des changements à un grain assez fin, éventuellement jusqu'au niveau des instructions des routines,

• une compréhension de la signification des changements et leurs conséquences sur les objets dépendants.

Le langage Eiffel offre un cadre bien adapté à ces deux prérequis :

• En tant que langage à objets, il donne la possibilité de réifier n'importe quelle construction ou concept du langage. Cela permet une expression fine des des changements (deltas) en exploitant l'identité des objets, ce qui manque aux outils traditionnels d'expression des deltas, tels que la commande diff de Unix.

• Sur le plan sémantique, le langage Eiffel a une approche pragmatique originale qui repose en grande partie sur l'utilisation d' assertions exécutables embarquées dans le code. À défaut de proposer une sémantique complète comme dans le cas des spécifications algébriques, la technique des assertions à le mérite d'être à la portée ---aussi bien en lecture qu'en écriture--- de la plupart des programmeurs et peut donc s'utiliser systématiquement, même pour des codes volumineux comme celui du projet K2.

Dans le projet IREC, les assertions jouent un double rôle pour :

• comprendre l' évolution de classes et la compatibilités des entités qui en dépendent, grâce à la sémantique de l'héritage renforcée par les assertions placées dans le code des applications,

• exprimer les métarègles sémantiques du langage Eiffel, grâce aux assertions placées dans les classes qui réifient toutes les constructions d'Eiffel.

Le caractère partiel des assertions d'Eiffel et leur mode d'expression ne permettent pas d'expliquer tous les cas d'évolution, mais on peut déjà interpréter de nombreux cas, parmi les plus fréquents.

Pour réifier toutes les constructions d'Eiffel, ce qui constitue une base de métaconnaissances, le projet IREC a adapté un interprète du langage Eiffel, écrit en Eiffel en 1991 dans cette équipe. Cette réification n'utilise pas de métaclasse, concept absent de façon explicite en Eiffel, mais construit des vues complètes ou partielles, selon divers points de vue, par des classes ordinaires en Eiffel qui jouent le rôle de composants de langage.

Les instances des composants IREC (environ 250 pour Eiffel) décrivent ainsi, non seulement l'équivalent d'un arbre de syntaxe abstraite décoré d'attributs sémantiques, mais aussi les méthodes des principales actions de manipulations des composants logiciels durant leur cycle de vie : expression des ``deltas sémantiques'', méthodes de réactualisations semi-automatiques, évaluation des assertions, interprétation du code, calcul de vues, etc... Cette approche ``tout objet'', qui rassemble au niveau de chaque composant de langage toute la connaissance et le savoir faire en matière de manipulation, se démarque des approches classiques comme Centaur qui manipulent les programmes de manière globale à partir de métadescriptions syntaxico-sémantiques dans des langages spécifiques (par exemple Typol).

La réification IREC du langage Eiffel a d'autre part été réécrite en Smalltalk par l'équipe de Jean-François Perrot du Laforia, à partir de la version de l'I3S. L'objectif était d'explorer des possibilités d'interopérabilité entre les environnements Eiffel et Smalltalk, notamment pour bénéficier des outils et du savoir faire de l'équipe du Laforia dans le domaine de l'intelligence artificielle (notamment le système de règles NeOpus), pour une explication plus fine de l'évolution, des contrôles statiques renforcés, un optimisation plus poussée du code...

En dehors des communications au sein du projet ESPRIT Business Classs (rapports techniques, démonstrations, comités d'évaluation) et de présentations diverses en séminaires, le projet IREC, n'a encore fait l'objet que d'une publication [BR95b], car il est momentanément arrêté depuis septembre 1994, suite à la maladie de Philippe Brissi qui est tragiquement décédé en mai 1995.