Précédent : Logiciels Remonter : ACTION ECOO, Environnements pour la Suivant : Actions industrielles
Précédent : Logiciels Remonter : ACTION ECOO, Environnements pour
la Suivant : Actions industrielles
Résumé : Nous fondons la correction des exécutions coopératives sur un modèle de transactions coopératives qui met en oeuvre un nouveau modèle de correction (la COO-sérialisabilité). Nous avons achevé cette année un environnement de développement coopératif de logiciel (COO) implantant ce modèle dans le cadre d'un environnement de développement de logiciel. En particulier, nous y avons mis en oeuvre l'algorithme d'évaluation de contraintes en présence de résultats intermédiaires éventuellement incohérents développé dans le cadre de la thèse de Hala Skaf. Cette année a été aussi le démarrage d'une action d'évolution de COO d'une architecture hiérarchique à une architecture distribuée et d'une infrastructure PCTE à une infrastructure légère (type Windows). Enfin nous avons démarré une action pour la définition simple par des utilisateurs non spécialistes de protocoles de coopération.
96].
Partant de là, l'essentiel du travail réalisé cette année sur ce thème a eu pour objectif de répondre à deux questions :
Les résultats sur ces aspects sont très préliminaires et concernent essentiellement des aspects systèmes. En particulier, nous avons développé un démonstrateur mettant en oeuvre un service de coopération à la CORBA permettant d'illustrer la construction d'applications coopératives par assemblage de briques de coopération. D'autre part, une évolution réseau des espaces de travail de COO (appelée Tua Motu) est en cours de développement.
On retrouve donc l'approche transactionnelle traditionelle, mais le problème n'est pas si simple du fait de la coopération. Nous l'avons étudié dans le cadre de la COO-sérialisabilité et du protocole COO.
Le premier problème est lié à la visibilité de résultats intermédiaires qui, par définition, échappent aux contraintes (nous considérons l'échange de résultats intermédiaires comme un des principes de base de la coopération). La question est : que faire lorsqu'un des objets impliqués dans l'évaluation d'une contrainte est dans un état intermédiaire ?
Nous avons étudié différentes stratégies [3]. En préliminaire, soulignons que, classiquement, une tâche évalue ses contraintes critiques lorsqu'elle se termine. La première stratégie consiste à déléguer l'évaluation de la contrainte à la transaction émettrice du résultat intermédiaire, et donc de faire l'hypothèse qu'elle est capable de compenser, en cas de problème, le travail réalisé jusque là par la transaction qui termine. La seconde stratégie consiste à évaluer la contrainte avec la dernière valeur cohérente correspondant au résultat intermédiaire, et donc d'évaluer une contrainte sur des valeurs d'objets de génération différentes. La troisième est de retarder l'évaluation de la contrainte en bloquant la terminaison de la transaction qui veut terminer, ce qui impose pratiquement aux deux transactions de coopérer pour terminer.
Un second problème est lié au groupement de transactions par le protocole COO. En conséquence de l'axiome de Convergence de groupe de la COO-sérialisabilité [7], lorsqu'une transaction a lu (directement ou indirectement) un résultat intermédiaire d'une autre transaction, qui elle même a lu un résultat intermédiaire de la première transaction, les deux transactions doivent produire un seul et même état final cohérent. Cela peut poser un problème si une contrainte de vivacité impose un ordre entre les deux transactions. En d'autres termes, il peut y avoir incompatibilité entre l'ordre induit par les contraintes et celui imposé par le protocole de contrôle de la correction des interactions.
Pour résoudre ces problème, nous avons développé un algorithme mettant en oeuvre la troisième stratégie, pour résoudre le problème de l'évaluation de contraintes en présence de résultats intermédiaires, et un algorithme de décomposition de transactions, inspiré de [PKH88] pour résoudre le second problème. Il s'agit de recréer l'ordre intial, induit par les contraintes, lorsqu'un groupe de transactions s'est mis d'accord pour terminer.
Nous avons mis en oeuvre cet algorithme dans l'environnement COO. Les contraintes y sont des formules de logique temporelle ([8]).
Résumé : Cette année, nous avons consolidé le noyau d'applications coopératives CPCE, au niveau applicatif et au niveau système. D'autre part, nous avons démarré une action pour la définition simple par des utilisateurs non spécialistes de protocoles de coopération. Enfin, nous mettons en place une infrastructure permettant de mieux connaitre les usages.
Résumé : Cette année a été une année de validation des expériences menées dans les année précédentes : formalisation des principes essentiels utilisés dans SmallEiffel. SmallEiffel est devenu << the GNU Eiffel Compiler >>.
Un second résultat [2] concerne l'implantation de la liaison dynamique elle-même. Nous montrons que l'utilisation des tables de fonction peut-être avantageusement remplacée par du code de sélection dichotomique. De plus, nous montrons que l'utilisation de cette technique permet de résoudre, après l'utilisation de l'inférence de type, un nombre non négligeable de sites supplémentaires (3,8 % avec nos tests).
SmallEiffel est devenu << the GNU Eiffel Compiler >>.
Précédent : Logiciels Remonter : ACTION ECOO, Environnements pour
la Suivant : Actions industrielles