Test de l’architecture

Le test de notre architecture est un élément important qui influe grandement sur la confiance que l’on porte dans les systèmes basés sur celle-ci. Ce test est actuelle- ment à l’étude et fait l’objet d’une thèse, nous essayons toutefois ici d’en donner les principes.

Au sein de cette architecture, on peut identifier plusieurs éléments différents qui feront l’objet de tests séparés :

• l’application proprement dite, qui est indépendante de l’architecture,

• les services fournis : fabriques d’objets et de métaobjets ainsi que service de groupe, qui sont tous trois relativement indépendants du reste de l’architecture et qui peuvent être utilisés dans d’autres contextes,

• le protocole à métaobjet, dont l’implémentation dépend de l’application puisqu’il est en partie intégré aux classes qui la composent,

• et les mécanismes de tolérance aux fautes, qui dépendent d’autres éléments de l’architecture : protocole et services.

En ce qui concerne le test de l’application, celui-ci peut-être mené de façon classi- que suivant les approches de test orienté-objet. Il faut toutefois noter que pour pren- dre place au sein de notre architecture, les classes de l’application sont modifiées (pour les rendre réflexives). Il faudra donc tester les classes issues de notre compila- teur et non les classes originales, afin de tester les classes effectivement utilisées. Pour cela, l’approche présentée en V.1.3, qui consiste à utiliser un métaobjet comme driver de test, peut éventuellement être utilisée.

Les différents services de l’architecture peuvent quant à eux être testés de façon totalement séparée. Ils sont, en effet, indépendants des autres éléments de l’archi- tecture.

Des différentes entités à tester, c’est le protocole à métaobjets qui soulève le plus d’interrogations. A notre connaissance, il n’existe pas de travaux portant actuelle- ment sur ce sujet. Bien qu’il soit défini de manière générale, l’implémentation du protocole à métaobjets dépend, dans la pratique, des classes auxquelles il est appli- qué. Bien qu’une modélisation de haut-niveau soit possible et permette de l’étudier (une telle modélisation en Pi-Calcul a été étudiée dans [Marsden et Ruíz-García 1999]), chacune de ses réalisations concrètes doit, dans l’absolu, être testée.

V.1.4- Test de l’architecture 129

Comme lors de sa conception, on peut, pour son test, décomposer le protocole à métaobjets en deux parties distinctes : la gestion comportementale et celle de l’état. Tester la partie comportementale consiste à s’assurer d’une part que toutes les méthodes publiques sont bien réifiées au métaobjet (réification) et d’autre part, que les méthodes originales puissent être activées par celui-ci (intercession) ; dans les deux cas il faut également s’assurer de l’empaquetage et du dépaquetage correct des arguments. Pour tester la réification, un driver de test qui active les méthodes publi- ques au niveau de base et un métaobjet qui observe leur réification peuvent s’avérer suffisants. En revanche, en ce qui concerne l’intercession, il est difficile d’observer l’activation des méthodes de manière non-intrusive pour la classe de base. Pour tes- ter la gestion de l’état, nous pensons que les accesseurs peuvent être utiles : de sub- tiles modifications de ceux-ci à des fins d’observation permettraient d’évaluer la validité des méthodes de sauvegarde et de restauration de l´état.

Enfin, pour le test des mécanismes de tolérance aux fautes, c’est à dire des métaob- jets de l’architecture, seule l’injection de fautes permet de tester leur fonctionne- ment. Le type de fautes et la technique d’injection dépend des hypothèses et du modèle de fautes considéré lors de la conception et de la réalisation du système. La mise en œuvre de l’injection de fautes par logiciel peut se faire en utilisant le proto- cole à métaobjets. En effet, comme présenté en V.1.3.2, un métaobjet possède tous les moyens d’action et d’observation nécessaires à l’injection de fautes. Un exem- ple d’une telle utilisation est donné en figure 38.

Figure 38 - Test des mécanismes de tolérance aux fautes-

injection de fautes logicielles par un métaobjet

Le mécanisme présenté dans cette section, qui se base sur l’hypothèse de silence sur défaillance, ainsi que le mécanisme de détection utilisé, permettent uniquement de tolérer les fautes physiques conduisant à une défaillance par arrêt. Par conséquent la technique d’injection de fautes à utiliser ne nécessite pas, à proprement parler, de métaobjets. S MFT MG MInj injection observation campagne d’injection protocole à métaobjet

V.1.5 Conclusion

Dans ce chapitre, nous avons montré les multiples intérêts du protocole à métaob- jets pour mettre en œuvre des mécanismes et des techniques de sûreté de fonction- nement sur une architecture CORBA. Nous avons ainsi défini une architecture articulée autour de CORBA et du protocole à métaobjets proposé (cf. figure 39). La plate-forme sur laquelle s’appuie cette architecture est constituée d’un système d’exploitation, d’un ORB, d’un protocole de communication de groupe et enfin,

d’un ou plusieurs environnements d’exécution de langage. Cette architecture, outre le protocole à métaobjets qui a été conçu et décrit dans les chapitres précédents, est composée de différents services, d’un métaniveau où se placent les différents métaobjets (les mécanismes non-fonctionnels) et de l’application. Le lien entre application et métaniveau est entretenu de façon transparente par le protocole à métaobjet.

Figure 39 - L’architecture, ses composants et moyens

d’extension

Du point de vue de l’application et du métaniveau, la plate-forme de l’architecture est abstraite :

• L’application s’appuie sur les mécanismes fournis par son langage d’implémen- tation et par CORBA.

• Les services proposés rendent indépendant le métaniveau du système d’exploi- tation et du protocole de groupe sous-jacents : la fabrique d’objets permet de créer des objets actifs sans se soucier du modèle d’exécution du système et le service de groupe peut aisément s’adapter à différents protocoles de communi- cation de groupe.

• CORBA rend transparent le langage d’implémentation de l’application pour le métaniveau. Nous avons montré au chapitre précédent que le protocole à métaobjets pouvait être implémenté avec C++ et Java grâce aux compilateurs ouverts OpenC++ et OpenJava.

ORB Système d’Exploitation Protocole de Groupe Environnement Langage Services Application Protocole à métaobjets

Métaniveau Orb ouvert

Compilateur

Langage ouvert

Système ouvert ouvert

V.1.5- Conclusion 131

• Le protocole à métaobjets permet de contrôler de façon transparente le compor- tement et l’état des objets applicatifs au métaniveau. De plus, grâce à la notion d’interface, il est aisé de changer le métaobjet d’un objet de façon dynamique. Il suffit pour cela que le métaobjet n’ait pas d’état ou qu’il puisse le fournir au métaobjet qui le remplace, ce qui est relativement aisé pour un métaobjet de tolérance aux fautes.

Notre approche tendant à considérer une plate-forme COTS, l’architecture et le pro-

tocole à métaobjets ne dépendent que très peu de celle-ci. On peut néanmoins iden- tifier certains points pour lesquels une adaptation à la plate-forme est nécessaire :

• La fabrique d’objets dépend du système d’exploitation puisque son rôle est de faire le lien entre objet CORBA et entité active du système. Grâce à la notion

d’interface, la modification de l’implémentation de la fabrique est transparente pour ses clients.

• Le service de groupe repose sur le protocole de groupe utilisé, ici xAMp [Verís- simo et Marques 1990]. Néanmoins l’architecture du service permet de rendre ses clients indépendants de tout changement interne.

• Le protocole à métaobjet, quant à lui, dépend un peu de l’ORB utilisé. En effet, il utilise certaines fonctions de l’ORB, notamment lors de l’initialisation, qui,

bien que normalisées, sont parfois quelque peu différentes selon l’ORB utilisé. En tout état de cause, les modifications nécessaires à l’utilisation d’un nouvel ORB sont minimes et très localisées.

Les différents éléments constitutifs de la plate-forme sont donc aisément interchan- geables. De plus, le protocole à métaobjets peut s’adapter aux caractéristiques de ces différents éléments :

• Si le système d’exploitation est suffisamment ouvert pour fournir certaines informations relatives à l’état externe des objets (fichiers, tâches, etc.), le proto- cole à métaobjets peut inclure ces informations dans l’état des objets.

• Si la norme CORBA évolue, et, par exemple, que les intercepteurs (spécification CORBA 3.0) soient implémentés dans l’ORB utilisé, ils peuvent être utilisés pour

le contrôle du comportement des objets applicatifs.

• Lorsque le langage utilisé pour l’implémentation des objets est réflexif, le pro- tocole à métaobjets peut également en tirer parti, comme c’est le cas avec la sérialisation des objets en Java.

• Enfin, quand toutes les informations nécessaires aux mécanismes de tolérance aux fautes (cf. chapitre III) ne sont pas disponibles à partir des éléments de la plate-forme, la réflexivité à la compilation est utilisée pour les exhiber.

• En tout état de cause, la réflexivité à la compilation est utilisée pour assurer que certaines conventions de programmation sont respectées. Ces conventions peu- vent également évoluer, en particulier pour s’adapter à certaines hypothèses que pourraient nécessiter divers éléments du système.

L’architecture et le protocole à métaobjets peuvent donc non seulement s’adapter facilement aux différentes évolutions technologiques de la plate-forme utilisée, mais sont également suffisamment ouverts pour pouvoir tirer profit de ces évolu- tions.

V.2 Résultats

L’implémentation partielle de l’architecture proposée permet de donner ici quelques résultats préliminaires sur l’utilisation du protocole à métaobjets. Nous proposons ici quelques relevés de performances pour plusieurs types d’activités du protocole à métaobjets : la création des objets, l’invocation de méthodes et l’obtention ou la res- tauration de l’état.

Ces différentes mesures ont été obtenues sur une plate-forme constituée de : • Sun Ultra Enterprise 450 et Sun SparcStation 20,

• Solaris 2.6, • Orbacus 3.1, • G++ 2.8.1,

• Réseau Ethernet 100Mbits.