Logiciels

TGV: un outil de génération automatique de tests de conformité

Participants : Thierry Jéron , Pierre Morel , César Viho , Claude Jard , Sébastien Encognère (stagiaire IFSIC/DEA)

Mots-clés : Test de conformité, TGV, ObjectGÉODE, TJava, SDL, LOTOS, TTCN, Java

Résumé : TGV (Test Generation with Verification technology) est un prototype de génération automatique de tests de conformité dont les algorithmes sont adaptés d'algorithmes issus du domaine de la vérification. TGV a été développé en commun par l'équipe Pampa et le laboratoire Verimag Grenoble et utilise des bibliothèques de la boîte à outils CADP de Vérimag et de l'Inria Rhône-Alpes. TGV a été déposé par l'Inria à l'Agence de Protection des Programmes en 97. TGV n'est pas pour l'instant distribué par FTP mais une version de démonstration sur Internet en Java est en cours de développement à Grenoble et accessible actuellement seulement pour Pampa et Verimag. Quelques versions de TGV ont été distribuées au coup par coup à des universitaires. TGV est utilisé par les membres du projet sur plusieurs études de cas. Un effort important a été entrepris pour le transfert industriel des algorithmes de TGV dans l'outil ObjectGÉODE de Vérilog. Ce transfert sera effectif courant 98.

Une première version de TGV a vu le jour en 95 lors d'un contrat financé par le STEI regroupant Vérilog, Cap Sesa Région Rennes, le CNET Lannion et le Celar de Bruz, Vérimag et Pampa. Cette première version développée par Vérimag et Pampa était utilisable sur les graphes d'états de spécifications LDS produits par GÉODE. Dans le cadre de ce contrat, TGV a été expérimenté sur le protocole DREX et a montré le bien fondé de l'approche [4].

TGV a été étendu en 97 pour fonctionner complètement à la volée, à la fois sur des spécifications LDS grâce à sa connexion à ObjectGÉODE, et sur des spécifications LOTOS grâce à sa connexion à l'environnement CADP. TGV est donc relativement indépendant du langage de spécification puisque LDS et LOTOS sont des langages respectivement fondés sur les automates communicants et les algèbres de processus. En sortie, TGV construit un cas de test dans un format général qui peut actuellement être traduit dans le langage TTCN, langage de description de tests standard de fait dans le monde des télécoms.

TGV est construit autour d'un coeur qui effectue le parcours de l'IOLTS modélisant un objectif de test et de l'IOLTS $S_{vis}$ représentant le comportement visible de la spécification. Autour de ce coeur, TGV est structuré en couches par l'intermédiaire d'API. Une première couche permet l'abstraction et la déterminisation à la volée de l'IOLTS de la spécification et fournit les primitives de parcours de $S_{vis}$ .Une deuxième couche effectue le découpage des transitions en entrées, sorties, actions internes, l'effacement des actions internes remplacées par des $\tau$ et la transformation du système de transition permettant de prendre en compte l'architecture du test (asynchronisme par exemple). Une dernière couche spécifique au langage d'entrée permet de connecter TGV soit à l'API du simulateur ObjectGÉODE pour LDS, soit à l'API fournie par le compilateur LOTOS Caesar de la boîte à outils CADP. D'autre part ces différentes couches utilisent des bibliothèques de stockage de graphes de CADP [29].

La version connectée à ObjectGÉODE est pour l'instant uniquement expérimentale. Son but est de montrer la faisabilité de la connexion. Cette expérience verra son aboutissement dans une opération de transfert industriel de TGV courant 98 avec la société Vérilog et le soutien de France Telecom. L'objet du transfert industriel de TGV est de définir précisément l'API de ObjectGÉODE nécessaire à la connexion de TGV et d'effectuer cette connexion.

Par ailleurs une interface JAVA pour TGV appelée TJava est en cours de réalisation à Grenoble. L'objectif est de permettre une démonstration de TGV par Internet. Il s'agira alors de permettre à l'utilisateur d'expérimenter TGV sur une spécification et quelques objectifs de tests fournis. Une première version existe déjà, installée à Vérimag. Les membres de Pampa et Vérimag l'utilisent localement sur leurs spécifications ou à distance pour effectuer des démonstrations.

Les différentes études de cas dans lesquelles TGV est utilisé nous permettent constamment d'enrichir et d'améliorer TGV sur différents aspects: l'expression des objectifs de test, de l'architecture de test, l'algorithmique de génération de test, la connexion avec d'autres outils.

EPEE : Environnement Parallèle d'Exécution de Eiffel

Participants : Jean-Marc Jézéquel , Jean-Lin Pacherie

Mots-clés : frameworks, objets, parallélisme, Eiffel

Résumé : EPEE (Environnement Parallèle d'Exécution de Eiffel) constitue un cadre de conception pour la programmation par objets des machines parallèles à mémoire partagée ou distribuée. EPEE offre un environnement de programmation dans lequel le parallélisme de données et le parallélisme de contrôle sont complètement encapsulés dans des classes Eiffel régulières, sans aucune extension du langage ni aucune modification de sa sémantique. Des schémas génériques de distribution et de calcul parallèle ont été factorisés et encapsulés dans des classes abstraites parallèles, qui peuvent ainsi être réutilisées grace au mécanisme de l'héritage multiple. Des composants parallèles réutilisables offrent des algorithmes parallèles généraux pouvant être paramétrés pour parcourir et agir sur des collections génériques de données. EPEE a notamment permis la construction de Paladin, une bibliothèque parallèle orientée objets dédiée au calcul d'algèbre linéaire.

Aboutissement de travaux entamés en 1991, EPEE constitue aujourd'hui un cadre de conception (``framework'') pour la programmation par objets des machines parallèles à mémoire distribuée qui s'appuie sur le principe de l'encapsulation des aspects liés au parallélisme dans des classes d'un langage à objets séquentiel. Il s'appuie sur un modèle d'exécution SPMD qui permet de décomposer naturellement une application en un entrelacement de phases séquentielles et de phases parallèles. Ces dernières étaient initialement obtenues par réutilisation de composants logiciels encapsulant un parallélisme de données.

Figure: Architecture du «framework» EPEE

$\begin{figure} \centerline{ \psfig {figure=epeeframework.ps,width=0.6\textwidth} }\end{figure}$

Diffusé de manière limitée dans le cadre de nos collaborations de recherche, EPEE est une maquette visant à démontrer l'intérêt de cette approche pour faciliter la programmation d'architectures parallèles réparties : elle permet de présenter un modèle de programmation séquentiel au programmeur d'application, qui ne voit alors la machine parallèle que comme un processeur de calcul plus puissant. Ce modèle s'adapte bien à l'expression d'un parallélisme massif pourvu que les problèmes à résoudre soient de taille assez grande. Comme l'illustre la figure , nous utilisons aussi maintenant EPEE comme une plate-forme pour mener nos recherches sur la notion de modèles de conception s'abstrayant des particularités de l'architecture répartie sous-jacente.

En termes de logiciels, les travaux autour de EPEE s'articulent à trois niveaux :

Exécutif :: Outre l'interfaçage avec diverses bibliothèques de communication inter-processeurs dépendantes des plate-formes, l'introduction d'objets partagés dans un langage muni d'un ramasse-miettes au sein de son exécutif nous a demandé de modifier son comportement afin de disposer du ramasse-miettes pour les objets partagés de la même façon que pour les objets alloués dans l'espace d'adressage local de chaque processus.
Boite à outils :: La transformation du code séquentiel vers du code réparti se fait à l'aide de composants réutilisables intégrant la notion de distribution de données et de contrôle, tout en la masquant par une interface identique à leurs versions séquentielles.
Motifs de conception :: Les motifs de conception, ou design patterns sont des modèles de solutions permettant de résoudre des problèmes de conception particuliers, notamment dans un contexte de conception par objets de logiciels. Dans le cadre du parallélisme de données, auquel nous nous attachons ici, nous proposons le motif de conception des OPéRATEURS PARALLèLES permettant de construire des bibliothèques de composants qui soient à la fois réutilisables, extensibles et permettant une exécution parallèle.
Il s'agit d'opérer une séparation entre les classes liées au domaine de l'application et celles liées au domaine de l'implantation. Pour cela, les opérations appliquées aux structures de données sont réifiées, c'est à dire définies comme des classes propres et non plus comme des méthodes des agrégats manipulés [38,13]. Ces opérations peuvent alors être réalisées par combinaison algébrique d'un petit nombre d'opérateurs fondamentaux, qui, lorsqu'on leur substitue (par héritage) une interprétation parallèle, fournissent automatiquement une implantation parallèle de l'opération extrinsèque.

Du fait du découplage opéré entre les abstractions du domaine de l'application et celles du domaines de l'implantation, la distribution des données se fait de façon transparente vis-à-vis de l'utilisateur. Ainsi, les applications ne dépendent pas d'une architecture particulière et sont facilement extensibles ou modifiables, toutes les fonctions de gestion du parallélisme (synchronisations, etc.) étant intégrées dans les méthodes d'accès aux données réparties ou partagées.

L'utilisation du schéma de conception de l'opérateur dans le cadre d'EPEE permet donc de paralléliser des applications existantes de façon simple et efficace, sans l'utilisation de compilateur spécialisé ou de macro-instructions mais uniquement en tirant parti des propriétés des langages à objets telles que l'héritage multiple, le polymorphisme ou la liaison dynamique. EPEE est utilisé à l'EPFL et à l'université de Tokyo.

Précédent : Grands domaines d'application Remonter : Projet PAMPA, Modèles et outils Suivant : Résultats nouveaux