TURTLE-P : un profil UML pour la validation d'architectures distribues

L. Apvrille* P. de Saqui-Sannes**,*** F. Khendek*

*

Concordia University, Electrical and Computer Engineering Department, 1455 de Maisonneuve W., Montreal, QC, H3G 1M8, Canada {apvrille, khendek}@ece.concordia.ca ** ENSICA, 1 place Emile Blouin, 31056 Toulouse Cedex 05, France desaqui@ensica.fr *** LAAS-CNRS, 7 avenue du Colonel Roche, 31077 Toulouse Cedex 04, France

RSUM. Le profil TURTLE (Timed UML and RT-LOTOS Environment) tend les diagrammes de classes UML pour donner une smantique formelle au paralllisme et aux synchronisations entre classes. Il ajoute aux diagrammes dactivit caractrisant le comportement de ces classes, des oprateurs de synchronisation et des oprateurs temporels (dlai dterministe, dlai non dterministe, offre limite dans le temps). Larticle propose dtendre TURTLE dans loptique dune modlisation de protocoles et dune validation darchitectures distribues. Le nouveau profil est appel TURTLE-P. Les diagrammes de composants et de dploiement sont inclus dans la mthodologie propose. Une smantique formelle leur est associe par traduction dans le langage RT-LOTOS. Lapproche propose est illustre sur un systme satellitaire. Le code RT-LOTOS driv des modles TURTLE-P a t simul et vrifi en utilisant loutil RTL dvelopp au LAAS-CNRS. ABSTRACT. TURTLE (Timed UML and RT-LOTOS Environment) is a UML profile, which extends class diagrams to provide formal semantics for parallelism and synchronization between classes. Activity diagrams, which characterize the internal behaviour of classes, are enhanced with synchronization and temporal operators (deterministic delay, non deterministic delay, time-limited offer). This paper proposes to extend TURTLE for protocol modeling and distributed architecture validation purposes. Indeed, the new TURTLE-P profile includes a methodology which takes into account component and deployment diagrams. The formal semantics of these diagrams is given in terms of a mapping to RTLOTOS. The proposed approach is illustrated through an application to a satellite system. The RT-LOTOS code derived from TURTLE-P models has been simulated and verified using the RTL tool developed at LAAS-CNRS.
MOTS-CLS : KEYWORDS:

UML, diagramme de dploiement, validation de protocole, RT-LOTOS. UML, deployment diagram, protocol validation, RT-LOTOS.

Introduction

Le nombre croissant dapplications distribues soulve de nouveaux problmes techniques (gestion des ressources distribues, scurit, etc.) mais aussi mthodologiques. Ainsi, si de nombreuses techniques de description formelles ont t proposes des fins de modlisation de protocoles et de validation darchitectures distribues, force est de constater que leur diffusion auprs des groupes de recherche et des industriels du domaine est loin dtre effective. Paralllement, de nombreux acteurs utilisent des approches beaucoup moins formelles mais qui deviennent des standards de fait. Lexemple type est la notation UML de lOMG (Object Management Group [OMG 03]). UML se pose en candidat naturel au support de conception de systmes distribus [GOM 00]. Pourtant, UML comporte de nombreuses lacunes, notamment en termes de smantique formelle, doprateurs temporels et de mthodologie, ce qui compromet gravement la mise en uvre dune validation formelle dun modle UML. Pour rpondre cette problmatique, nous avons propos en [ASL 01] un profil UML appel TURTLE (Timed UML and RT-LOTOS Environment) qui sest avr efficace pour la conception de logiciels contraintes temps-rel fortes [APV 02] [LOH 02]. Pour autant, ladquation de ce profil pour la modlisation de protocoles et de systmes distribus peut tre questionne. En effet, si TURTLE permet effectivement de dcrire le paralllisme et la synchronisation au sein dune architecture de classes, puis de dtailler le comportement temporel de ces classes, ce profil ne permet pas actuellement de modliser de faon explicite larchitecture gnrale dun systme distribu et encore moins les paramtres de Qualit de Service. Pour remdier ces insuffisances, cet article propose dinclure dans TURTLE les diagrammes de composants et de dploiement. Le profil enrichi est appel TURTLE-P. Larticle est structur de la manire suivante. La section 2 donne une prsentation synthtique du profil TURTLE. La section 3 positionne TURTLE par rapport aux travaux du domaine. La section 4 dcrit lextension propose en termes de diagrammes de dploiement en y incluant la smantique formelle obtenue par traduction vers RT-LOTOS. La section 5 traite de lapplication de TURTLE-P un systme satellitaire. Enfin, la section 6 conclut larticle.

Le profil TURTLE

Le profil TURTLE (Timed UML and RT-LOTOS Environment [ASL 01]) tend deux des diagrammes de la notation UML1.5 [OMG 03], savoir les diagrammes de classes pour la description de la structuration (statique) du logiciel et les diagrammes dactivit pour la description du comportement interne aux classes. La smantique formelle du profil est donne par des algorithmes de traduction [LOH 02] vers le langage formel RT-LOTOS [COU 00], ce qui permet de rutiliser au bnfice de TURTLE loutil de validation RTL [RTL].

TURTLE-P : un profil UML pour la validation d'architectures distribues

Un diagramme de classes TURTLE est constitu de classes normales et de classes strotypes appeles Tclass . Ces dernires peuvent se synchroniser et changer des donnes au travers de portes de communication appeles gates (Figure 1a), qui se drivent en InGate (porte dentre) et OutGate (porte de sortie). La synchronisation mais aussi le paralllisme entre Tclasses sont prcisment dfinis par des oprateurs de composition reprsents par des classes qui attribuent les relations dassociation entre Tclasses. TURTLE emprunte RT-LOTOS quatre oprateurs de composition : Parallel pour lexcution en parallle et sans communication (Figure 1b), Synchro pour la synchronisation par rendez-vous, Sequence pour lexcution en squence, et Preemption qui permet dinterrompre lexcution dune Tclass pour en activer une autre. TURTLE supporte galement loprateur Invocation qui est le pendant de lappel de mthode mais en mode de communication par rendez-vous. A ces cinq oprateurs de base sont venus sajouter deux oprateurs orients systmes logiciels temps rel , savoir Suspend/Resume et Periodic [APV 02]. Notons que les oprateurs Synchro et Invocation doivent tre accompagns de formules OCL prcisant les attributs de type gates mis en relation (par exemple {T1.g1 = T2.g2}).
Tclass Id Attributs classiques Portes (Gate, InGate, OutGate) Mthodes Description du comportement
T1 T2 Parallel

Oprateur de composition Association

Figure 1a. Structure dune Tclass

Figure 1b. Composition de deux Tclasses

Les diagrammes dactivit ont t tendus (Figure 2) pour exprimer les missions et rceptions synchronises, mais aussi des retards dure fixe ou variable et des offres limites dans le temps. Sur la Figure 2, la notation AD reprsente un sous diagramme dactivit interprt la suite de loprateur.
g !x ?y AD

d
AD

t
AD

AD1 AD2

Synchronisation sur g

dlai dterministe

dlai non dterministe

offre limite dans le temps

Figure 2. Nouveaux symboles pour les diagrammes dactivit

Positionnement par rapport aux travaux du domaine

La validation dune architecture distribue passe par la modlisation des protocoles de communication mis en uvre dans cette architecture. Lide dexprimenter UML dans ce contexte est venue ds les prmices de la normalisation du langage UML lOMG. Aux exemples acadmiques traits en [JJP

98] et [JS 00] sont venus sajouter les protocoles de coopration [END 01], le commerce lectronique [SG 01], les systmes multi-agents [KKB 03] [LIN 01] et enfin ODP [HOL 97] [KMP 98] [BHK 00] [HUG 02]. La rutilisation de composants de communication devient un enjeu important [KMP98] [CAR 00]. Ces travaux sappuient dans leur ensemble sur la version normalise dUML. Sen tenir strictement la notation de lOMG est lune des options dfendues [DOU 02] dans le processus de normalisation dun UML temps rel [WAT 02]. Si les outils de validation et tests de protocoles dvelopps antrieurement pour les techniques de description formelles savrent rutilisables dans le contexte dUML 1.4 [LEG 01], la notation de lOMG a fait lobjet de plusieurs analyses critiques donnant lieu des propositions de profils cibls sur la validation darchitectures distribues. Certains profils sont outills. Ainsi, [WCW 01] dcrit lapplication un protocole de commerce lectronique du profil AUML utilis conjointement avec le vrificateur de modles Spin. AUML introduit des Protocol Diagrams qui tendent les diagrammes de squences avec des oprateurs logiques, de causalit, synchronisation et diffusion. La validation avec Spin ncessite une traduction de ces diagrammes dans le langage Promela. Par ailleurs, [Sel 01] prsente le profil implant par loutil Rose-RT de la socit Rational. Rose-RT supporte un langage cousin de SDL [SDL], dot dun seul oprateur temporel de type dlai fixe et permet lanimation de modles. Une autre approche appele ACCORD/UML [GVK 00] savre plus riche en oprateurs temporels pour exprimer des chances, priodes ou priorits au niveau des Statecharts UML. Le profil TURTLE, introduit la section prcdente, dispose doprateurs temporels puissants (diagrammes dactivit) et donne une smantique formelle au paralllisme et la synchronisation entre classes (diagrammes de classes). Par contre, la dfinition donne en [ASL 01] a laiss de ct les diagrammes de squences et les diagrammes de dploiement. Lobjectif du prsent article est prcisment de remdier cette situation, en considrant plus particulirement les diagrammes de dploiement. Notons que loutil UML-AUT [LEG 01] supportait dj les diagrammes de dploiement dans un environnement de conception de systmes distribus mais nous navons pas trouv en [LEG 01] trace de formalisation de ces diagrammes.

4 4.1

Le profil TURTLE-P Description du dploiement de composants logiciels

Le diagramme de dploiement UML permet de mettre en vidence les configurations dexcution dun systme. Ce diagramme est fort peu mis en valeur dans les mthodologies de dveloppement de logiciels. De plus, il nest utilis qu des fins de documentation. Pourtant, nous pensons que ce diagramme est bien adapt la description dune architecture distribue et nous voulons lui donner une smantique formelle.

TURTLE-P : un profil UML pour la validation d'architectures distribues

Un diagramme de dploiement est constitu de : Nuds. Ces nuds constituent les diffrents sites physiques dexcution du systme considr. Composants logiciels. Daprs la norme UML, ces composants logiciels sont des lments logiciels dployables qui encapsulent en leur sein des fonctions et qui offrent leur environnement des interfaces. Liens de communication. Ces liens relient un composant logiciel linterface dentre dun autre composant logiciel. La Figure 3 prsente un diagramme de dploiement UML dans lequel un composant logiciel client communique avec un autre composant logiciel serveur situ sur un autre site physique dexcution.
client:Client <<client>> serveur:Serveur <<serveur>>

Figure 3. Exemple d'un diagramme de dploiement UML.

Nous proposons damliorer le diagramme de dploiement UML comme suit : Les composants logiciels sont constitus de classes TURTLE et deviennent ainsi validables ; Une multiplicit peut tre dclare au niveau des nuds afin de faciliter la modlisation des systmes distribus comportant de nombreux nuds identiques sur lesquels les mmes composants sont dploys ; Les liens de communication peuvent tre caractriss par des paramtres (notamment, dlai de transmission et gigue) qui sont pris en compte lors du processus de validation formelle.

4.2 4.2.1

Composants logiciels du diagramme de dploiement Dfinition des composants

Un composant logiciel regroupe des classes qui ralisent une fonction logicielle sur un mme site dexcution. Cest pourquoi nous proposons de dfinir ces composants logiciels comme un sous-ensemble des classes modlises dans le diagramme de classes. Soit C un composant logiciel tel que C soit un ensemble de n Tclasses = {ci, i 1..n}. C doit respecter la proprit suivante : i 1..n, ci C, c Diagramme de classes, c C c et ci ne sont pas en relation de Synchronisation ou dInvocation. En effet, deux classes ne peuvent communiquer via une synchronisation ou une invocation que dans le cas o elles appartiennent toutes deux au mme composant logiciel.

Sil existe entre deux Tclasses C1 et C2 dun diagramme de classes, une relation de Paralllisme, Squence ou Premption et si un composant logiciel ne contient quune seule de ces deux Tclasses, alors la relation entre ces deux Tclasses est ignore au niveau de ce composant. Notons aussi que deux composants logiciels distincts peuvent contenir la mme Tclass. Par exemple, considrons le diagramme de classes reprsent la Figure 4. Ca = {C1, C3} ne constitue pas un composant logiciel car C1 et C2 sont en relation de synchronisation et C2 nappartient pas Ca. Cb = {C1, C2, C4} est un composant logiciel valide car C4 sexcute en parallle au regard de C1 et C2 et aucune classe de Cb nest en relation de Synchronisation / Invocation avec une classe nappartenant pas Cb. Cc = {C3} est aussi un composant logiciel valide. C3 ne pourra jamais tre prempt par C4 puisque C4 nappartient pas ce composant, mais cela ne nuit pas lexcution de C3.

C1

Synchro

C2

Sequence

C3

Preemption

C4

Figure 4. Exemple d'un diagramme de classes TURTLE.

4.2.2

Interface des composants

Les composants logiciels sont constitus de Tclasses. Pour communiquer, ces Tclasses offrent leur environnement des portes de communication. Nous proposons que les interfaces des composants soient donc constitues des portes de communication des Tclasses de ce composant. Cependant, certaines des portes de communication des Tclasses sont impliques dans des relations de synchronisation lintrieur dun mme composant. Afin de ne pas pouvoir rutiliser ces mmes portes avec des relations extrieures, seules les portes dclares publiques (+) et non impliques dans ces relations de synchronisation internes au composant constituent les interfaces des composants. De plus, il nous faut distinguer les interfaces dentre des interfaces de sortie. Seuls les attributs de type InGate peuvent tre considrs comme des interfaces dentre. De mme, seules les portes de type OutGate peuvent tre considres comme des interfaces de sortie.

4.2.3

Reprsentation des composants

En UML, les composants logiciels reprsents au niveau du diagramme de dploiement peuvent tre dfinis au sein dun diagramme de composants. Nous rendons cette dmarche obligatoire. Au niveau du diagramme des composants, seuls sont reprsents les composants logiciels dploys au niveau du diagramme de dploiement et les interfaces des composants utilises dans ce mme diagramme de dploiement. Une porte g de la

TURTLE-P : un profil UML pour la validation d'architectures distribues

classe c donnera une interface nomme g_c. Enfin, une multiplicit indique au niveau du nud prcise combien de fois lensemble des composants du nud sont dploys sur des nuds distincts. Par exemple, considrons le diagramme de dploiement reprsent la Figure 5. Le diagramme de composants correspondant est reprsent la Figure 6. Ce diagramme sert mettre en vidence les classes logicielles contenues dans le composant, sans rappeler les liens smantiques entre ces classes. La reprsentation des interfaces au niveau du diagramme des composants nous apparat comme facultative dans la mesure o ces interfaces (c--d les portes des Tclasses) sont dj spcifies au niveau du diagramme de classes. Notons que le nud Client de la Figure 5 possde une multiplicit de n ce qui signifie que le composant Cb est dploy sur n nuds de type Client.
:Client <<Cb>> [n] g1_c1 :Serveur <<Cc>> g1_c3

Figure 5. Exemple d'un diagramme de dploiement TURTLE-P

Cb Cc

C1

C2

C4

C3

Figure 6. Diagramme de composants.

4.3

Liens du diagramme de dploiement

En UML 1.5, les liens des diagrammes de dploiement ne sont donns qu titre dinformation. Notre objectif est de leur donner une smantique formelle. Nous nous limitons ici des liens de transmission asynchrone et unidirectionnels et attribus par quatre paramtres : un dlai minimal (delay_min) et maximal (delay_max) de transmission ; une bande passante (max_msg) ; un taux de perte exprim en pourcentage (loss_rate). La Figure 7 reprsente un lien unidirectionnel entre un client et un serveur. La dure minimale de transmission sur ce lien est de 10 units de temps, alors que la dure maximale de transmission est de 15 units de temps. Au plus 100 messages peuvent tre transmis simultanment sur ce lien. De plus, en moyenne 0,001 % des messages de ce lien sont perdus. La multiplicit de 10 prcise que 10 clients peuvent cohabiter simultanment dans le systme lexcution. Le fait dintroduire une multiplicit au niveau des nuds soulve le problme du transit des messages : les messages entre un client et un serveur transitent-t-il sur le mme lien que les messages entre un autre client et ce mme serveur ? Par dfaut, nous proposons que

les liens soient dupliqus i.e. que les messages ne transitent pas sur le mme lien. Graphiquement, cette duplication de lien est identifie par un disque vid, cf. Figure 7. Dans le cas contraire o les messages transitent tous sur le mme lien, ce lien unique est reprsent graphiquement par un disque plein (cf. Client2 sur la Figure 7). De plus, un lien qui relie un nud de multiplicit n vers un nud de multiplicit m signifie que tout message mis sur ce lien est reu par les m nuds rcepteurs. Si linterface de rception du lien possde un disque plein, alors le message est considr dupliqu la rception. Sinon, il est dupliqu lmission. Par exemple, dans le cas de la Figure 7, le nud Client1 est dupliqu 10 exemplaires comportant chacun une instance du composant Cb, les instances communiquant avec le serveur via un lien indpendant. Par contre, les cinq composants Cb du nud Client2 utilisent le mme lien de communication pour envoyer un message au serveur.
Lien commun Lien personnel << dlai_min = 10 >> << dlai_max = 15 >> << max_msg = 100>> <<loss_rate = 0.001>>

:Client1 [10] :Client2 [5] Cb g1_c1 Cb g1_c1

:Serveur g2_c3 Cc

<< dlai_min = 5 >>

Figure 7. Modlisation d'un lien avec gigue et multi-clients.

4.4

Smantique formelle des diagrammes de dploiement

Les algorithmes [LOH 02] de gnration dune spcification RT-LOTOS partir dune modlisation TURTLE acceptent en paramtre un diagramme de classes constitu de classes TURTLE dites Tclasses auxquels sajoutent des diagrammes de comportement inclus dans chacune de ces Tclasses. Nous proposons de nous appuyer sur les algorithmes dfinis dans TURTLE [LOH 02] dans le cadre de TURTLE-P. La premire tape de la traduction en RT-LOTOS consiste transformer les diagrammes de dploiement en diagrammes de classes et dactivits TURTLE par les algorithmes de traduction de TURTLE-P : ce sont les nouveaux algorithmes que nous prsentons ci-dessous. Dans une deuxime tape, nous rutilisons les algorithmes de TURTLE pour gnrer la spcification RT-LOTOS partir des diagrammes construits ltape prcdente. Les algorithmes de traduction TURTLE-P ne seront pas exposs in extenso compte tenu du nombre de pages allou larticle. Nous allons cependant donner une vue gnrale du processus de traduction. Le diagramme de dploiement de TURTLE-P est un 2-uple <N, L> avec N, une liste de nuds = {ni, i 1..n}et L, une liste de liens = {li, i 1..m}.

TURTLE-P : un profil UML pour la validation d'architectures distribues

Un nud ni est un t-uple <C, mult> avec C un ensemble de composants = {cj, j 1..nij} et mult la multiplicit du nud. Un lien est un 10-uple <no, nd, g1, g2, dmin, dmax, max_msg, loss_rate, type_o, type_d> o no et nd dnotent respectivement les nuds origines et destinations, g1 et g2 dnotent les interfaces initiale et destination du lien, dmin et dmax reprsentent les dlais minimum et maximum de transit des messages, max_msg le nombre maximal de messages en transit un instant t sur le lien et loss_rate le taux de perte moyen du lien. Enfin, type_o {lien_personnel, lien_commun} et type_d {dup__origine, dup__destination}. Nous notons Dc le diagramme de classes TURTLE natif que nous construisons partir de la modlisation TURTLE-P. Ce diagramme de classes est construit comme suit :
// Gnration des classes de Dc Pour chaque nud ni de N, pour chaque composant cj de de ni Pour k variant de 1 la multiplicit de ni Les classes de cj sont renommes ni_k_cj_nom_initial Les classes de cj sont ajoutes Dc Fin Fin

de

nom_initial

// Construction des liens Pour tout lien ls = <nop, ndp, gx_cp, gy_cq, dminp dmaxp, max_msgp, loss_ratep, type_originep, type_destp> de L Si type_originep = lien_personnel alors Pour k variant de 1 la multiplicit de nop On ajoute Dc une classe Lgx_k_cp tel que le comportement de Lgx_k_cp reflte le comportement du lien i.e. la gigue, la bande passante, le taux de perte et lventuelle duplication des messages avant ou aprs transmission (voir aprs lalgorithme) On ajoute une relation de Synchronisation entre Lgx_k_cp et la classe cq. La formule OCL {gy} est ajoute lassociation Fin Sinon On ajoute Dc une classe Lgx_cp tel que le comportement de Lgx_cp reprsente le lien Pour k variant de 1 la multiplicit de nop On ajoute une relation de Synchronisation entre la classe ni_k_cj_cp et la classe Lgx_cp. La formule OCL {gx = gk} est ajoute lassociation Fin On ajoute une relation de Synchronisation entre Lgx_cp et la classe cq. La formule OCL {gy} est ajoute lassociation Fin Fin Fin

Finalement, un lien se caractrise par une relation de synchronisation entre, dune part, la classe origine du lien et une classe C dont le comportement reprsente celui du lien et, dautre part, la classe C et la classe dsigne par le lien. Il nest pas possible de dtailler dans le cas gnral le comportement de la classe C, mais simplement, par exemple, dans le cas dun lien entre une classe c1, porte g1, et une

classe c3, porte g2. Le diagramme de dploiement correspondant est celui reprsent la Figure 5 (avec n qui vaut 1). Le diagramme de classes construit par les algorithmes prcdents est reprsent la Figure 8. Le lien est ainsi modlis par deux relations de synchronisation et une classe Lg1_c1 dont le comportement mule celui du lien reprsent la Figure 5.
Lg1_c1 C1
+ g1 : OutGate - m : Message ; n : Integer + g1 : InGate ; +g2 : OutGate

C3
+ g2 : OutGate

[msg1, msg2] n = msg_max ? false true

msg2 msg1 n = n +1 n = n -1 msg1 g1?m

{g1}
Synchro

dmin dmax - dmin

g2!m msg2

{g2}
Synchro

Figure 8. Reprsentation graphique en TURTLE d'un lien exprim en TURTLE-P.

4.5

Mthodologie

Les diagrammes de composant et de dploiement sont intgrs dans une mthodologie dcompose en quatre tapes : (1) analyse du systme, (2) conception, (3) conception dtaille et (4) validation (voirFigure 9).
Conception dtaille Diagramme de composants Diagramme de dploiement Validation (outil RTL) Simulation intensive Analyse daccessibilit

Conception Diagramme de classes Diagrammes dactivits

Analyse Cas dutilisation Scnarios

Figure 9. Mthodologie TURTLE-P danalyse, conception et validation. La phase danalyse consiste construire les cas dutilisation du systme et les scnarios dchanges de messages, notamment entre les entits du systme distribu. La phase de conception consiste construire le diagramme de classes du systme et associer chacune des Tclasses un diagramme de comportement. La phase de conception dtaille utilise un diagramme de dploiement pour dcrire la distribution des composants logiciels du systme sur les diffrents sites

TURTLE-P : un profil UML pour la validation d'architectures distribues

11

physiques dexcution et les moyens de communication entre composants. De plus, par respect de la norme UML [OMG 03], les composants logiciels seront dcrits dans un diagramme de composants qui fait partie intgrante de la mthodologie. Cette mthodologie repose sur un cycle itratif et des raffinages successifs des diagrammes. Dans un premier temps, la conception abstraite et la conception dtaille se bornent produire des diagrammes de classes et dactivits qui sont valids en utilisant lapproche initialement propose en [ASL 2001]. Les diagrammes de composant et de dploiement sont raliss dans un deuxime temps et la validation sappuie une spcification RT-LOTOS obtenue en suivant le processus dcrit la section 4.4). Dans une prochaine tude nous comptons laborer une mthodologie de raffinement qui nous permettra de passer de la conception la conception dtaille dune manire semi-automatique. Cette mthodologie assurera par construction une relation de raffinement entre deux niveaux de spcification. Ce qui nous permettra de valider et de simuler le modle au niveau conception pour certaines proprits abstraites uniquement et de nous focaliser uniquement sur les proprits spcifiques au dploiement lors de la validation de la conception dtaille.

5 5.1

tude de cas Aperu du systme

SAGAM [ROU 99] est un systme de communication par satellite quip dun commutateur embarqu de cellules ATM qui permet de router les cellules entre les diffrents spots. Une connexion utilisateur stablit comme suit. Lorsquun utilisateur requiert une nouvelle connexion avec un autre utilisateur, le systme value la charge requise par cette connexion (mcanisme de CAC) et en cas de succs, admet la connexion. Une fois cette connexion tablie, lutilisateur met priodiquement ses cellules ATM dans des trames montantes. Afin que les slots allous dans cette trame correspondent son trafic rel (nous considrons du trafic VBR, donc variable), lutilisateur peut mettre un signal, appel Dama-sig, qui signale au systme son dsir de passer en mode ATM VBR-PCR (Peak Cell Rate). Le systme repartit alors entre toutes les demandes la bande passante disponible et met un plan de trame qui indique aux utilisateurs lallocation des slots dans la future trame montante. Nous proposons dans cette tude de modliser le mcanisme dallocation de slots dans la trame montante. Ce mcanisme est ralis par trois entits distinctes : la station de lutilisateur, le satellite et le centre de contrle rseau du satellite (cf. Figure 10). Au niveau de lutilisateur (SU pour Station Utilisateur), une entit logicielle (Dama-client) permet dmettre les Dama-sig et dcouter en retour lallocation attribue. Le systme satellite achemine alors les Dama-sig jusqu' lentit Dama Serveur situe dans le centre de contrle rseau du satellite (CR pour Centre

Rseau). Celui-ci value la demande et met ventuellement jour le plan de trame par mission dun signal vers lentit mettrice de ce plan de trame, situe bord du satellite. Enfin, une entit logicielle bord du satellite reoit les ordres de mise a jour du plan de trame depuis le dama serveur et met un plan de trame toutes les 50 millisecondes (entit appele PT).

Plan de Trame

Station Utilisateur (Dama Client)

Dama Serveur

CR

SU

Figure 10. Vue gnrale du systme considr.

5.2

Modlisation TURTLE-P du systme

Le systme tudi a t modlis en respectant les rgles nonces la section 4.1. Cela nous a conduit : 1. Dcrire le diagramme de classes du systme (non dtaill ici) ; 2. Extraire des composants logiciels de ce diagramme de classes et les dcrire au sein dun diagramme de composants. Ces composants sont : o DamaClient constitu de deux Tclasses Dc et Traffic en charge des algorithmes du DAMA et du trafic gnr au niveau de stations sols, respectivement. o DamaServeur constitu de trois classes Dsr, DamaAlgo, Dse qui reoivent, traitent et rpondent aux Dama-sig, respectivement. o PT constitu de la classe Ptm qui traite les demandes de mises jour du plan de trame reues du DamaServeur, et Pte qui met priodiquement le plan de trame. 3. Raliser le diagramme de dploiement (cf. Figure 11). Outre les composants logiciels dcrits prcdemment, le diagramme de dploiement comporte trois liens qui connectent les trois composants situs sur trois nuds distincts. Le nud SU (Station Utilisateur) comporte une multiplicit, n, dont nous discutons plus en dtail par la suite.

5.3

Simulation intensive et validation formelle

Loutil RTL prend en entre une spcification RT-LOTOS et permet de raliser une simulation intensive ou de gnrer un graphe daccessibilit. Dans le cas de

TURTLE-P : un profil UML pour la validation d'architectures distribues

13

SAGAM, nous avons tent une analyse daccessibilit pour diffrentes valeurs de la multiplicit n (voir Figure 11). Pour des valeurs faibles de n (1 3), il nous a t possible de gnrer un graphe daccessibilit comprenant un nombre dtats exploitable (de 195 tats pour n=1 presque 10000 pour n=3). Au-del, lapproche par simulation intensive nous a paru plus adapte.

:Satellite ge_ptm PT gs_pte

<< dlai_min = dlai_max = 125 >> << dlai_min = dlai_max = 125 >>

:SU

[n]

<< dlai_min = dlai_max = 250 >>

:CR

ge_dc DamaClient gs_dc

ge_dsr DamaServeur gs_dse

Figure 11. Diagramme de dploiement du systme.

Outre labsence dtats puits, la phase de validation a pour objectif de prouver le respect de proprits au cours de lexcution du systme. Lors de contributions prcdentes concernant le profil TURTLE, nous avons montr quil tait possible, par insertion de classes TURTLE non-intrusives au niveau du diagramme de classes, danalyser le respect de proprits lors de la validation du systme [APV 02][ASS 02]. Mais cette approche ne peut tre utilise quau niveau du diagramme de classes car elle consiste ajouter un ou plusieurs observateurs en relation de Synchronisation avec les classes observes. Mais les liens de communication ntant dclars quau niveau du diagramme de dploiement, il nest pas possible de leur adjoindre tels observateurs puisque la relation de synchronisation ne sapplique quentre des Tclasses. Nanmoins, afin de rsoudre le problme dobservation de proprits sur les liens, nous proposons lapproche suivante. Considrons un lien tel que celui entre les composant DamaServeur et PT (cf. Figure 11). Dans le cas o lon souhaite observer une proprit du lien qui ncessite lobservation dun seul cot du lien (par exemple, savoir combien de messages ont t mis sur le lien), il suffit dinsrer un observateur dans le composant origine du lien, cest dire dans le composant DamaServeur, au niveau de la classe qui met sur ce lien. Par exemple, dans le cas du lien entre DamaServeur et PT, la classe qui met les messages est la classe Dse : il convient alors dutiliser un observateur O1 au sein du composant DamaServeur qui est en relation de synchro avec Dse et qui est capable de rcuprer le nombre de messages mis sur la porte gs de la classe Dse (cf. Figure 12, partie gauche). Dans le cas o la proprit observe ncessiterait de recueillir la fois des informations lmission et la rception du lien (par exemple, savoir combien de

messages sont actuellement sur le lien), il convient de placer un observateur la fois au niveau de la classe mettrice, mais aussi au niveau de la classe rceptrice. Par exemple, toujours dans le cas du lien entre DamaServeur et PT (cf. Figure 11), il faut placer un observateur au niveau de la classe Dse et un au niveau de la classe Ptm (cf. Figure 12). Ainsi, lobservateur O1 note le nombre de messages entrants ne et lobservateur O2, le nombre de messages sortants ns. Pour calculer le nombre de messages sur le lien, il faut faire la soustraction entre ces deux nombres i.e. entre ne et ns. Pour cela, il convient que O1 envoie ne O2, ou que O2 envoie ns O1 : dans les deux cas, nous proposons linsertion dun lien de communication sans dlai entre les deux observateurs au niveau du diagramme de dploiement (non reprsent la Figure 11).

DamaServeur Synchro Dse

PT O1 Ptm Synchro O2

Figure 12. Observation de proprits sur un lien : diagramme de composants.

Si la solution propose pour observer une proprit est satisfaisante du point de vue rsultat, elle nen demeure pas moins fastidieuse modliser. Aussi, nous travaillons actuellement la dfinition dobservateurs de liens (probes) qui permettront de simplifier la modlisation de lobservation de proprits sur les liens. Le comportement de ces probes sera reprsent au niveau du diagramme de classes tandis que le positionnement de ces probes sur les liens sera dcrit au niveau du diagramme de dploiement.

Conclusion

Le profil TURTLE [ASL 01] tend les diagrammes de classes UML pour donner une smantique formelle au paralllisme et aux synchronisations entre classes. Il ajoute aux diagrammes dactivit caractrisant le comportement de ces classes, des oprateurs de synchronisation et des oprateurs temporels (dlai dterministe, dlai non dterministe, offre limite dans le temps). Si TURTLE a t appliqu avec succs des systmes temps rel [APV 02] [LOH 02], son adquation modliser des protocoles et valider des architectures distribues restait exprimenter. Ce domaine dapplication a motiv lextension TURTLE-P dcrite dans cet article qui ajoute TURTLE les diagrammes de composants et les diagrammes de dploiement. Comme pour les diagrammes de classes et dactivits, la smantique formelle de ces deux nouveaux diagrammes est donne en termes de RT-LOTOS. Lexemple dun systme satellitaire illustre la mthodologie et en particulier la validation au moyen de loutil RTL du LAAS. Si TURTLE-P permet de modliser un systme rel du type de SAGAM trait dans larticle, il savre encore limit sur plusieurs points. Les premires extensions apporter concernent la prise en compte sur les liens de nouvelles contraintes

TURTLE-P : un profil UML pour la validation d'architectures distribues

15

(bande passante, ordre, taux de perte, etc.). Il serait galement souhaitable de pouvoir utiliser un modle de trafic au niveau des liens. Dans la mthodologie propose, les diagrammes de la phase danalyse sont utiliss des fins de documentation. A plus long terme, notre objectif est aussi dutiliser ces diagrammes, soit pour synthtiser automatiquement le comportement des classes TURTLE comme cela peut dj tre ralis pour les conceptions SDL [KGB 98][AKB 99], ou les utiliser comme scnarios de test lors de la phase de validation comme le permet dj loutil ObjectGeode [VER 99].

Remerciements

Le profil TURTLE a t dfini dans le cadre dune coopration ENSICALAAS/CNRS impliquant Jean-Pierre Courtiat, Patrick Snac et Christophe Lohr. Nos remerciements sadressent aussi Michel Diaz (LAAS/CNRS) pour les ides quil nous a suggres.

Bibliographie

[AKB 99] M. M. Abdalla, F. Khendek and G. Butler, New Results on Deriving SDL Specification from MSCs, Proceedings of SDL Forum'99, Montreal, Canada, June 1999. [APV 02] L. Apvrille, Reconfiguration dynamique de services logiciels de tlcommunication par satellite , Thse de doctorat de lInstitut National Polytechnique de Toulouse, juin 2002. [ASL 01] L. Apvrille, P. de Saqui-Sannes, C. Lohr, P. Snac, J.-P. Courtiat, A New UML Profile for Real-time System : Formal Design and Validation, Fourth Intern. Conference on the Unified Modeling Language (UML2001), Toronto, Canada, October 2001. [ASS 02] L. APVRILLE, P. DE SAQUI-SANNES, P. SENAC, C. LOHR, Reconfiguration dynamique de protocoles embarqus bord de satellites , Actes du Colloque Francophone sur lIngnirie des Protocoles (CFIP2002), Montral, Canada, Mai 2002 (Herms ed.). [BHK 00] M. Born, E. Holz, O. Kath, A Method for the Design and Development of Distributed Applications Using UML, TOOLS-Pacific 2000, Sydney, Australia. [CAR 00] E. Cariou, Spcification de composants de communication en UML , OCM 2000, Nantes, France, mai 2000. [COU 00] J.-P. Courtiat, C.A.S. Santos, C. Lohr, B., Outtaj Experience with RT-LOTOS, a Temporal Extension of the LOTOS Formal Description Technique, Computer Communications, vol. 23, n. 12, 2000, p. 1104-1123. [DOU 02] B.P. Douglass, Real-Time UML Tutorial, OMG Real-Time and Embedded Distributed Object Computing Workshop, Arlington, VA, USA, July 2002. [END 01] J. M. M. Espinosa, O. Nabuco, K. Drira, A UML Model for Session Management in Collaborative Design for Space Activities, 8th European Concurrent Engineering Conference (ECEC'2001), Valence (Espagne), pp.170-174, April 2001. [GOM 00] H. Gomaa, Designing Concurrent, Distributed and Real-Time Systems with UML, Addison Wesley, ISBN 0201657937, 2000 [GVK 00] S. Grard, N.K. Voros, C. Koulamas, F. Terrier, Efficient System Modeling of Complex Real-Time Industrial Networks Using the ACCORD/UML methodology,

DIPES 2000, International IFIP WG 10.3/WG10.4/WG10.5 Workshop on Distributed and Parallel Embedded Systems, Paderborn, Germany, October 2000. [HOL 97] E. Holz, Application of UML within the Scope of new Telecommunication Architectures, Humboldt-Universitt zu Berlin, 1997. [HUG 02] M.-P. Huget, Extending Agent UML Protocol Diagrams, Agent Oriented Software Engineering (AOSE-02), Fausto Giunchiglia and James Odell and Gerhard Weiss (eds.), Bologna, Italy, July 2002. [JJP 98] C. Jard, J.-M. Jzquel, F. Pennaneach, Vers lutilisation doutils de validation de protocoles dans UML, Techniques et Sciences Informatiques, v.15,n11, pp. 1-15, 1998. [JS 00] M. Jaragh, K.A. Saleh, Modeling Communications protocols using the Unified Modeling Language, TENCON2000, Intelligent Systems and Technologies for the New Millenium, Kuala Lumpur, Malaysia, September 2000. [KGB 98] F. Khendek, R. Gabriel, G. Butler and P. Grogono, Implementability of Message Sequence Charts, Proceedings of the first SDL Forum Society Workshop on SDL and MSC, Berlin, Germany, June 29 - July 1, 1998. [KKB 03] K. Kavi, D.C. Kung, H. Bhaambhani, G. Pancholi, M. Kanikarla, R. Sah, Extending UML to Modeling and Design of Multi-Agent Systems; submitted to the International Conference on Software Engineering, 2003. [KMP 98] M. M. Kand, S. Mazaher, O. Prnjat, L. Sacks, M. Vittig, Applying UML to Desin an Inter-Domain Service Management Application, UML98, Mulhouse, France, June 1998. [LEG 01] A. Le Guennec, Gnie logiciel et mthodes formelles avec UML : spcification, validation et gnration de tests , doctorat de lUniversit de Rennes I, juin 2001. [LIN 01] J. Lind, Specifying Agent Interaction Protocols with Standard UML, Second International Workshop on Agent-Oriented Software Engineering (AOSE-2001) Volume 2222 of Lecture Notes in Computer Science, Springer Verlag, Heidelberg, March, 2002 [LOH 02] C. Lohr, Contribution la spcification de systmes temps rel en sappuyant sur la technique de description formelle RT-LOTOS , thse de Doctorat de lInstitut National Polytechnique de Toulouse, dcembre 2002. [OMG 03] OMG, Unified Modeling Language Specification, Version 1.5, Object Management Group, http://www.omg.org/technology/documents/formal/uml.htm [ROU 99] L. Roullet, SAGAM Demonstrator of a G.E.O. Satellite Multimedia Access System: Architecture & Integrated Resource Manager, European Conference on Satellite Communication, Toulouse, France, November 1999. [RTL] http://www.laas.fr/RT-LOTOS [SEL 01] B. Selic, A UML Profile for Modeling Complex Real-Time Architectures , http://www.omg.org/news/meetings/workshops/presentations/realtime2001/63%20Selic.presentation.pdf. [SDL] http://www.sdl-forum.org/. [SG 01] I.W. Siu, Z .S. Guo, The Secure Communication Protocol for Electronic Ticket Management System, University of Macau, June 2001. [VER 99], Verilog, ObjectGeode, Toulouse, France, 1999. [WAT 02] B. Watson, The Real-Time UML Standard, OMG Real-Time and Embedded Distributed Object Computing Workshop, Arlington, VA, USA, July 2002. [WCW 01] J. Wei, S.C. Cheung, X. Wang, Exploiting Automatic Analysis of E-Commerce Protocols, 25th Annual Computer Software and Application Conference, Chicago, USA, October 2001.