• Aucun résultat trouvé

Construction d’un nœud PolyORB minimal

Le nœud ne peut être utilisé que localement (figure 6.3). Nous retenons qu’un inter- giciel permet d’enregistrer des entités applicatives (“servants”). Dans cette configura- tion,PolyORBjoue alors le rôle d’une infrastructure orientée composants minimale, tel queFractal[Coupaye et al., 2002]. Le code utilisateur que nous avons placé effectue

une requête sur ce composant local. Ceci permet de tester que le chemin d’invocation peut être complété.

6.2.2

Analyse du nœud construit

Cette configuration minimale nous permet de fournir quelques éléments sur la couche neutre, cœur dePolyORB.

Notons d’abord que le code associé à ces modules intergiciels représente 61 paque- tages Ada 95, pour un total 11, 039 lignes de code significatives une fois les commen-

taires et lignes vides supprimées1.

Un second aspect de qualité du code est le type de restrictions du langage qui sont violées ou validées.

Le langage Ada 95 fournit une liste de restrictions du langage qui peuvent être vérifiées par le compilateur ou le système exécutif utilisé. Ces restrictions permettent de s’assurer de la qualité du code écrit, en particulier que certaines constructions du langage jugées dangereuses ne sont pas présentés dans une application jugée critique.

gnatls, outil de la chaîne de compilation de GNAT, permet de déterminer l’en- semble des restrictions violées par les différents paquetages formant un exécutable. Notons que certaines des restrictions violés par PolyORBsont définies parGNAT, et non par le manuel de référence du langage. Il s’agit de restrictions supplémentaires définies pour répondre à des besoins en qualité de code qui ont été formulées par les utilisateurs de ces outils.

Nous avons déterminé que notre configuration minimale viole plusieurs restrictions du langage et deGNAT, que nous classons de la façon suivante :

– Manipulation de types :No_Enumeration_Maps,No_Fixed_Point,

No_Floating_Point,

– Orienté Objet :No_Dispatch,No_Finalization,No_Nested_Finalization

– Manipulation de la mémoire :No_Access_Subprograms,No_Allocators,

No_Local_Allocators,No_Secondary_Stack,

No_Standard_Storage_Pools,No_Unchecked_Access,

No_Unchecked_Conversion,No_Unchecked_Deallocation

– Exceptions :No_Exception_Handlers,No_Exceptions

– Génération implicite de code :No_Elaboration_Code,

No_Implicit_Conditionals,No_Implicit_Loops

– Règles d’écriture de code :No_Direct_Boolean_Operators,No_Recursion

– Dépendance à la chaîne de production :No_Implementation_Attributes,

No_Implementation_Pragmas

Cette liste de vingt-trois restrictions fournit une première vue de la qualité de l’im- plantation réalisée. En particulier, il démontre l’indépendance vis à vis des construc- tions liées aux entrées/sorties, à la concurrence, et à l’ensemble des constructions du langage interdites par le profil Ravenscar. Ces résultats étaient attendus vu le peu de fonctionnalités présentes dans cette configuration.

Notons cependant que certaines constructions jugées “dangereuses” restent pré- sentes, et sont pleinement justifiées par des impératifs de conception. Ceci exclut donc

PolyORBdu cadre d’une certification stricte. Cependant, une analyse précise du code démontre que :

– les fonctions de manipulations de types sont présentes pour l’affichage d’infor- mation de mise au point (No_Enumeration_Mapsinterdit l’utilisation des attri-

buts ’Imagepar exemple), ou nécessaires pour l’emballage de certains types (No_Fixed_Point,No_Floating_Point).

– les gestionnaires d’exception présents le sont à titre de mise au point, et per- mettent le cas échéant de diagnostiquer tout erreur dans le code ; ou pour gérer les erreurs remontées par la bibliothèque de transport basée surGNAT.Sockets. En revanche, certaines constructions restent présentes :

– l’orienté objet est la base de l’architecture, il sera donc difficile d’en faire l’éco- nomie à moins d’un long travail de conception, qui sort du cadre de nos travaux. Notons cependant que les appels dynamiques sont implantés par l’exécutif de sorte qu’ils s’effectuent à temps constant. Ainsi, ces constructions ne remettent pas en cause le déterminisme de l’application.

– la gestion de la mémoire reste dépendante des mécanismes standards du lan- gage. Notons cependant qu’il est possible dansGNATde surcharger les méca- nismes d’allocation mémoire au niveau global, en proposant une nouvelle im- plantation du paquetageSystem.Memory. Ceci permettrait de remplacer l’ap- pel à la fonctionmallocpar un allocateur mémoire déterministe, par exemple

TLSF[Masmano et al., 2003].

Ainsi, nous montrons que le code produit pour cette configuration répond aux contraintes fortes imposées lors de la construction de systèmes critiques. Le travail de vérification formelle effectué au chapitre précédent et cette étude démontrent ainsi la qualité de l’architecture proposée et de l’implantation des éléments centraux dePo- lyORB.

6.3

Construction d’un intergiciel RT-CORBA

Dans cette section, nous nous intéressons à la construction d’un nœud basé sur RT-CORBA. Nous fournissons une analyse des modules nécessaires, puis différentes études faites pour analyser l’application construite.

6.3.1

Définition

RT-CORBA [Schmidt & Kuhns, 2000] est une extension des spécifications COR- BA, utilisant les mécanismes protocolaires mis en place par GIOP pour échanger des informations de qualité de service entre les différents nœuds (priorités des appels, etc). RT-CORBA utilise les mécanismes de concurrence pour modifier les priorités des tâches de chaque nœud, et associer un pool de tâches à chaquePOA. Ainsi, RT-CORBA définit des mécanismes permettant la construction d’applications réparties temps réel, fonctionnant suivant le modèle des objets répartis.

La mise en place d’une application RT-CORBA va nécessiter : – la personnalité GIOP et son instance pour IIOP ;

– un adaptateur d’objets pour le temps réel, – les personnalités CORBA et RT-CORBA,

– une bibliothèque de concurrence compatible avec le changement dynamique de priorité et l’utilisation de plusieurs tâches,

– un exécutif temps réel.

Nous avons présenté au chapitre précédent des briques intergicielles remplissant certaines de ces fonctions. Ainsi, l’implantation de RT-CORBA nécessite :

Service Context

POA

CORBA

RT−POA

RT−CORBA

Lanes

Request_QoS

TCP/IP

IIOP

µBroker

controller

Client

Servant_1Servant_1Servant_1

Configure entités

GIOP+CDR

à RT−CORBA

Spécifique