Chapitre 4 Implantation de l’atelier
4.8 Mise en œuvre : ajouter un composant
Les prototypes sont des Logiciels Éducatifs (existants ou futurs). Les Logiciels Éducatifs exis- tants n’ont pas été conçus pour coopérer dans l’atelier. Nous avons résumés dans la section 1.2.4, les propriétés nécessaires à un prototype pour coopérer dans l’atelier.
Les prototypes existants ne possèdent pas toutes les propriétés minimales. C’est pourquoi, nous présentons des propositions pour modifier les prototypes existants. Nous proposons en particulier d’encapsuler les prototypes existants dans une surcouche implantant les propriétés nécessaires. Cette encapsulation est présentée dans la section 4.8. Elle permet en particulier d’assurer la communication avec EduMed et, dans la mesure du possible, de rendre le prototype scriptable, scrutable, traçable et interface-exportable par lui. Dans cette section, nous expliquons comment ajouter un composant à l’atelier. Nous manipulons deux types de composants : les composants de services et les composants constitués autour d’un prototype.
Les composants de services sont actuellement au nombre de deux : le gestionnaire de formats et le gestionnaire d’interfaces graphiques. Nous avons montré dans la section 4.6, l’intégration de l’interprète de macro-définitions en tant que composant CORBA. L’intégration de tout nouveau composant (de services ou prototype) suit le même processus. La section 4.8.1 décrit ce proces- sus. Cependant, l’intégration d’un prototype existant nécessite un travail préparatoire que nous présentons dans la section 4.8.2.
4.8.1 Intégration d’un nouveau composant
Nous expliquons ici le portage CORBA d’un composant écrit dans un langage compta- tible CORBA. Nous avons illustré le processus de portage CORBA avec l’interprète de macro-
57
VNC marche même avec des applications DOS. C’est très intéressant dans notre domaine puisqu’il y a encore
4.8. Mise en÷uvre : ajouter un omposant 135
définitions dans un composant appelé gestionnaire de formats vu à la section 4.6.
Notre travail consiste d’abord à décrire la vitrine du composant. La vitrine du composant ras- semble tous les éléments que le composant peut publier. Il peut publier tout ou partie des infor- mations accessibles depuis une autre application. Ces informations sont des données (variable, états, observables ,et .) et des traitements (fonctions, procédures, méthodes,et .).
Dans cette section, nous supposons que le composant a toutes les «bonnes propriétés», c’est-à-dire qu’il est scriptable, scrutable, traçable et interface-exportable. Pour les composants qui n’auraient pas ces «bonnes propriétés», voir la section suivante.
Rédaction d’une vitrine
La vitrine est d’abord exprimée en langage naturel par le prescripteur. L’administrateur définit alors la vitrine.
Nous créons le composant pour le prototype CHyPre. Alors la vitrine pour ce prototype est
stockée dans le fichier : ChypreC.idl58
. module ChypreCApp { interface ChypreC { ... }; };
Le fichier ChypreC.idl ci-dessus définit un module nommé ChypreCApp et une interface nommée ChypreC. L’administrateur complète les «. . . » en fonction des caractéristiques du pro- totype CHyPre. Ce travail est actuellement réalisé à la main. Cependant il est partiellement
automatisable.
Génération des fichiers CORBA
À partir de la vitrine écrite, le compilateur approprié génère la correspondance vers le langage choisi. La commande idl2java Chypre.idl génère les fichiers nécessaires pour CORBA. Ces fichiers59
, dans notre cas, sont au nombre de cinq : – _ChypreCImplBase.java ;
– _ChypreCStub.java ; – ChypreC.java ;
– ChypreCHelper.java ; – ChypreCHolder.java.
Ils sont placés dans un répertoire portant le nom du module défini dans la vitrine (ici Chypre- CApp). Ce répertoire constitue un package JAVA.
Ces fichiers constituent des coquilles vides auxquelles l’administrateur ajoute les liens avec
CHyPre. Il compile ensuite tous les fichiers correspondants au nouveau module CORBA. Il
dispose alors d’un client et d’un serveur CORBA pour CHyPre. Le composant (ChypreC) est
alors prêt pour être utilisé par l’atelier.
58
Règle de nommage : nom du prototype auquel on accole un C (pour composant CORBA) 59
136 Chapitre 4. Implantation de l'atelier
Utilisation du composant encapsulé
Chaque prototype est inclus dans un objet CORBA, en tant que serveur. Lorsque le ges- tionnaire d’activités est lancé, tous les objets CORBA sont lancés. Lorsqu’un objet CORBA est lancé, il initialise les services CORBA. Ce faisant, une «implantation» de chaque objet est créée. Par exemple, au lancement de l’objet CORBA encapsulant le prototype CHyPre, il est
initialisé et une implantation de l’objet ChypreC est créée. Nous l’appelons ChypreC_Impl. À partir de ce moment là, ChypreC_Impl attend une requête du client. Le client dans notre cas est le gestionnaire d’activités. Quand le gestionnaire d’activités est lancé, il initialise à son tour les services CORBA. Ensuite il «établit le lien» (bind, en anglais) avec chaque objet CORBA.
On dit alors que l’objet est lié. Par exemple, il établit le lien avec l’objet CHyPre . À partir de ce moment là, un proxyest créé pour chaque objet CORBA «lié». Par exemple, le proxypour
CHyPre est créé. Nous l’appelons CHyPre _Proxy. Lors du lancement d’une étape où le prototype CHyPre est lancé, le gestionnaire d’activités utilise leCHyPre_Proxyvia sa vitrine de cette ma-
nière :CHyPre_Proxy.launch(), c’est-à-dire qu’il lance la méthode launch(). Le lancement d’une
méthode est exprimé dans le paradigme objet. Remarquez que le gestionnaire d’activités utilise le proxyCHyPre_Proxyde la même manière qu’il utilise un objet local. Ensuite, CORBA pro-
voque le comportement du proxyCHyPre_Proxy. Il fait la requête à l’implantation CHyPre _Impl.
CHyPre _Impl lance alors le code associé à la méthode «launch». Lorsque la méthode «launch» se termine, elle retourne une valeur. Cette valeur est renvoyée au proxy CHyPre_Proxyqui la
reçoit. Ensuite le proxy CHyPre_Proxyrenvoie ce résultat au gestionnaire d’activités.
Préparer la récupération de résultat d’un prototype
1: pour chaque prototype faire 2: pour chaque fonctionnalité faire
3: /* Administrateur saisit le type du résultat (flux, fichier, string) */
4: /* Administrateur saisit le chemin d’accès du résultat */
5: fin pour 6: fin pour
4.8.2 Encapsulation d’un prototype existant
Cette section répond à la question suivante : que faut-il ajouter ou modifier dans un proto- type existant pour permettre sa coopération avec d’autres prototypes ? Le but est d’obtenir un prototype «commandable» depuis un autre exécutable. Par commandable, nous entendons que le prototype fournisse un point d’accès afin d’agir sur lui. Pour cela le prototype est encapsulé dans un objet CORBA.
Rechercher les caractéristiques du prototype
Le prescripteur qui connaît le prototype (éventuellement avec l’aide de l’administrateur) remplit le formulaire prototype en langage naturel.
Rendre scriptable, scrutable, traçable et interface-exportable
Une fois le formulaire rempli, les points d’accès aux différentes données et au différents trai- tement sont identifiés. Si le prototype est scriptable, scrutable et interface exportable, les infor- mations précédentes sont suffisantes et la vitrine pourra être définie.
4.9. Mise en÷uvre : la base dedonnées d'indexationdes prototypes 137
Si, au contraire, le prototype n’a pas ces bonnes propriétés, nous proposons de l’encapsuler dans un objet, en ajoutant autant que faire se peut les propriétés souhaitées. Ces ajouts dépendent de deux paramètres.
Le premier paramètre est la granularité des traitements et des données accessibles. Ça dépend de la manière dont le prototype est programmé. Si la granularité est fine, le source que nous écrivons permet d’ajouter les méthodes pour accéder aux traitements et données. Ensuite nous publions ces méthodes dans la vitrine et nous ajoutons les liens nécessaires pour atteindre les traitements et les données du prototype.
Si la granularité est grande, nous ne pouvons pas faire grand chose. Par exemple, nous lançons le prototype en entier et attendons son résultat. Dans ce cas, la seule chose que nous publions dans la vitrine est la méthode launch() pour lancer le prototype.
Le second paramètre est l’existence d’observables générés par le prototype.
Si des observables existent, nous ajoutons dans notre surcouche, les méthodes permettant de les ajouter à la vitrine.
S’il n’existent pas, nous devons les construire en utilisant une des solutions décrites dans la section 3.4.4.
Bilan
En résumé, pour ajouter un prototype à l’atelier, il faut :
1. rendre le prototype aussi scriptable, scrutable, traçable et interface-exportable que possible ; 2. remplir le formulaire «prototype»;
3. rédiger la vitrine du composant ;
4. générer les fichiers de la correspondance pour CORBA ;
5. assurer les liens entre les fichiers pour CORBA et le prototype ; 6. compiler les fichiers pour CORBA ;
7. installer le serveur du prototype ;
8. faire les liens dans EduMed avec le client du prototype. Exemple
La figure 4.14 illustre l’architecture de l’atelier dans le cas de l’utilisation deTALC etMen- toniezh. Au moment de cette expérimentation,TALC etMentoniezh étaient deux logiciels qu’on
devait lancer en un seul bloc. Par conséquent, leur vitrine ne contient que la méthode launch() et les énoncés des exercices (HDL_statement et CDL_statement). De plus, la coopération de ces deux logiciels nécessite une traduction de l’énoncé au format approprié. L’annexe C détaille le raisonnement qui conduit à définir le macro-texte adéquat. Il est appelé HDL-CDL_macro-text et est ajouté à la vitrine de Mentoniezh. Sur cette figure apparaît aussi le gestionnaire d’acti-
vités et les constituants d’EduMed. Ces constituants sont l’ORB et les composants de services (gestionnaire de formats et gestionnaire d’interfaces graphiques) avec leur vitrine.