• Aucun résultat trouvé

Nous présentons les différents éléments Z de la spécification de l’intergiciel. Cela passe par la spéci-fication des types de base, des types plus complexes et des schémas représentant des éléments cruciaux du système. Il est aussi nécessaire de spécifier les opérations modifiant l’état de ces éléments, ainsi que leurs combinaisons possibles.

Dans un premier temps, nous allons nous concentrer sur la partie dite «serveur» de l’intergiciel, et les mécanismes mis en œuvre pour l’enregistrement des servants, la création et la diffusion de références, la réception de requêtes et enfin leur traitement.

Par convention, nous préfixons les noms (de schémas ou non) introduisant un type Xyz par «T» (TXyz), un schéma opération Op par «op» (opOp).

Nous présentons l’élément central de l’intergiciel, l’ORB, ainsi que les différents éléments qui lui sont attachés, comme l’adaptateur d’objet (Object Adapter). Nous définissons chacun de ces composants, et précisons nos choix de modélisation ainsi que les propriétés que ces éléments doivent respecter. Ensuite, nous spécifions les opérations qui modifient l’état d’un ORB, via la création de servant ou encore l’envoi ou la réception de requêtes. Nous présentons ensuite la définition du système global comme étant un ensemble de nœuds sur chacun desquels fonctionne un ORB. Les opérations précédemment spécifiées ne sont pas suffisantes car elles ne permettent pas de cibler spécifiquement un ORB particulier au sein du système, afin d’en modifier l’espace d’états. Nous définissons donc de nouvelles opérations dont la portée est étendue à l’ensemble du système par différents mécanismes, et qui sont basées sur les opérations dont la portée est limitée à un ORB.

Nous terminons par la combinaison de tous ces modules pour construire la spécification finale, atten-dant d’être configurée par l’utilisateur. Nous abordons enfin les obligations de preuves de la spécification (pour s’assurer que le système respecte les propriétés évoquées précédemment), et les scenarii permettant de procéder à des vérifications plus approfondies du système configuré.

ORB

5.4. Patrons Z : ORB et types de base

TOrb

OrbConfiguration

TObjectAdapter tsapName: TTsapId

requestQueue: seq TRequest tapList : F TTransportAccessPoint memory: TMemory

#managedServants ≤ MaxServant #requestQueue ≤ MaxRequestQueue

Un ORB est assimilé à un ensemble contenant les variables6suivantes :

– OrbConfiguration : ce schéma définit un ensemble de variables limitant certains éléments de l’ORB, comme la taille maximale de mémoire à disposition, la capacité maximale en nombre de servant que peut gérer l’adaptateur d’objet, le nombre maximal de requêtes que peut recevoir l’ORB. OrbConfiguration MaxRequestQueue: N MaxServant: N MaxMethod: N MaxMemory: N

Inclure le schéma OrbConfiguration dans celui de TOrb permet d’inclure ces variables dans tout élément manipulant TOrb. Le regroupement de ces variables dans un schéma distinct permet de limiter à celui-ci l’impact des modifications dues à la configuration de l’ORB.

– TObjectAdapter (OA) : l’adaptateur d’objet associé à l’ORB, qui va gérer les servants. Les travaux de [Ver06] ont montré que la notion d’OA non hiérarchique était suffisante pour décrire un exécutif AADL. Donc même si PolyORB supporte de tels OAs, comme le POA (Portable Object Adap-ter) de CORBA, nous définissons l’adaptateur d’objet comme un schéma contenant une unique variable, la table permettant d’enregistrer des servants :

TObjectAdapter

managedServants: seq TServant

Les servants gérés sont représentés sous la forme d’une séquence (identifiée par managedServants). La place d’un servant dans la séquence permet de leur attribuer implicitement un identifiant unique. En Z, une séquence est définie formellement comme suit :

seq X == {f : N 7→ X | ∃ n : N • dom f = 1..n}

Les séquences d’éléments de type X sont des fonctions partielles ( 7→) ayant pour domaine de définition les entiers naturels, et pour domaine d’image l’ensemble X. Le domaine de définition de ces fonctions est borné.

Chaque élément de la séquence est associé à un entier donnant sa position dans la séquence. Un servant est associé à une paire (objet, identifiant) :

TServant== (TObject × N)

Cela met en évidence le fait qu’un servant est une surcouche pour un objet applicatif, et qu’il est identifiable simplement.

On définit un objet comme suit : TMethod== N

TObject== F TMethod

Un objet est ramené à un ensemble fini de méthodes, elles-mêmes ramenées à un simple entier (à la façon d’un pointeur sur une fonction, qui prend ses valeurs dans N).

– tsapName : l’identifiant de l’ORB au sein du système. Il est utilisé pour contacter le nœud à distance. Nous introduisons le type de base TTsapId comme suit :

[TTsapId]

Il s’agit d’un ensemble non-vide d’éléments distincts.

– requestQueue : l’ORB reçoit des requêtes qu’il insère dans une file d’attente pour ensuite les traiter. Le type de cet attribut est «séquence» de requêtes.

Nous spécifions le type d’une requête comme suit : TRequest== (TReference × N)

Une requête est une paire contenant une référence sur un objet distant (de type TReference), et un identifiant de méthode (prenant ses valeurs dans N). Une méthode est caractérisée par un identifiant et une signature. Pour les analyses que nous souhaitons effectuer, la signature de la méthode n’a pas d’impact. Elle pourra être prise en compte dans des travaux ultérieurs, par la spécification précise de ses paramètres par exemple.

Nous introduisons donc le type d’une référence et les types associés : TReference== F TProfile

Une référence est donc un ensemble fini de profils, dont le rôle est de rassembler toutes les infor-mations nécessaires pour interagir avec un objet distant :

TProfile

orbId: TTsapId servantId: N

protocolStack: TProtocol

Les informations utiles que sont l’identifiant du nœud distant, l’identifiant du servant sur ce nœud ainsi que le protocole à utiliser sont présentes.

– tapList : l’ensemble des points d’accès de l’ORB, nécessaires à la réception de requêtes. Il s’agit d’un ensemble fini (F) : par définition, un même point d’accès ne peut (et ne doit) pas être enre-gistré plus d’une fois auprès de l’ORB.