Un environnement formel d'assistance à la modélisation de protocoles

To

form

Inter

This

Epri

Any

adm

cite this

mel d'assi

rnationale

s is a pu

ints ID: 2

y corresp

ministrato

s docum

stance à

e sur les N

ublisher-278

pondence

or:

staff-o

ent:

APV

à la modé

NOuvelles

-deposite

e concer

oatao@in

VRILLE L

élisation

s TEchno

ed versio

rning thi

np-toulo

udovic, S

de protoc

ologies de

on publis

is servic

use.fr

SAQUI-SA

coles. In:

e la REpar

shed in:

ce should

ANNES P

: NOTER

rtition, 23

http://oa

d be sen

Pierre (de)

RE 2008

-27 June

atao.univ

nt to the

). Un env

: 8ème

2008, Ly

v-toulous

e reposito

vironneme

Conféren

on, Franc

se.fr/

ory

ent

nce

ce.

Un environnement formel d’assistance à la modélisation

de protocoles

Ludovic Apvrille

Institut TELECOM, TELECOM ParisTech, LTCI

CNRS

2229 route des crêtes, B.P.193

F-06904, Sophia-Antipolis Cedex, France

ludovic.apvrille@telecom-paristech.fr

Pierre de Saqui-Sannes

Université de Toulouse, ISAE, LAAS-CNRS

10 avenue Edouard Belin, B.P. 54032

31055 Toulouse Cedex 4, France

pdss@isae.fr

ABSTRACT

Les outils UML appli ables en on eption deproto oles n'intègrentgénéralementau unlogi ield'assistan eàlamise en÷uvre d'une méthodologie adaptée.Ce onstat s'appli-quaitjusqu'i i auprol UMLTURTLE (TimedUMLand RT-LOTOS Environment)supportépar l'outil TTool. Cet arti le dé ritl'introdu tion dansTToold'unassistant mé-thodologique basé en parti ulier sur des "patterns" large-ment a eptés. L'arti le fo alise la dis ussion sur les dia-grammes d'analyse que TTool utilise pour générer auto-matiquementles diagrammes de on eption. L'outilTTool étendutrouve uneappli ationdire tedansl'ingénierie des proto oles, etnotamment son enseignement. La démar he proposéepeuts'appliqueràd'autreslangages de modélisa-tionetpro essusguidésparles as d'utilisation.

Categories and Subject Descriptors

H.4[InformationSystemsAppli ations℄:Mis ellaneous; D.2.11[SoftwareEngineering ℄:SoftwareAr hite tures Dataabstra tion,Domain-spe i ar hite tures,Information hiding,Languages(e.g.,des ription,inter onne tion, deni-tion),Patterns(e.g., lient/server, pipeline,bla kboard)

General Terms

Languages

Keywords

Modélisation objets, patrons, proto oles, te hniques de des riptionformelle,véri ationformelle

1.

INTRODUCTION

La omplexité des systèmes répartis justie le re oursà deslangagesdemodélisationsupportéspardesoutilsde vé-ri ationformelle.La dénitiondeprolsUMLtempsréel adossésàdes méthodesformelles[?℄ répondà ebesoinen

Permission to make digital or hard copies of all or part of this work for

personal or classroom use is granted without fee provided that copies are

not made or distributed for profit or commercial advantage and that copies

bear this notice and the full citation on the first page. To copy otherwise, to

republish, to post on servers or to redistribute to lists, requires prior specific

permission and/or a fee.

NOTERE’08 June 23-27, 2008, Lyon, France

Copyright 200X ACM X-XXXXX-XX-X/XX/XX ...$5.00.

dotant lanotation UML de l'OMG [11℄ d'une sémantique formelle etd'outils permettantde validerunear hite ture de ommuni ation. Un de esprols UML temps réel est TURTLE(TimedUMLandRT-LOTOS Environment) in-troduiten[3℄etétenduen[4℄.

LeprolTURTLEestmaintenant stabiliséentermesde syntaxeetdesémantique.A ontrario, levolet méthodolo-giquemérited'êtreapprofondi.Enparti ulier,lelien entre uneméthodologieexposéeinextenso[?℄ousurdesexemples d'unepart,etl'outilOpenSour e TTool[9℄quisupportele prold'autrepart,resteàétablir.

C'estpourquoileprésentarti lejettelesbasesdu dévelop-pementd'un assistant méthodologiqueà intégrer àTTool. A titre de omparaison, et assistant sera débrayable par la personne qui modélise en TURTLE, à l'instar du GPS installé surnombre devoitures. Ilne remettrapar ailleurs pasen ause lefaitquetous lesdiagrammes TURTLEont unesémantiqueformelle etque l'environnement TTool est fortement, mais pas ex lusivement, orientévers les phases amontdu y lededéveloppementetlavéri ationformelle d'exigen estemporelles.

L'arti leproposededémarrerl'assistan eméthodologique enphased'analyse.Celapasseparunemeilleure ompréhen-siondestroisdiagrammesUML2.1quesontlesdiagrammes de as d'utilisation (UCD),les diagrammes devue globale (IOD)etlesdiagrammesdeséquen es(SD).Eneet,siles UCD et SD sont relativement bien onnus, il n'en va pas demêmedesIOD,endépitdel'intérêtde esderniers lors-qu'il s'agit destru turer(sousforme d'organigrammes)les s énariiquido umententles asd'utilisation.Unepremière ontribution de l'arti le réside dans la proposition de pa-trons(patternsenanglais)quia ouplentUCDetIODsur unebase formelle. La deuxième ontribution sesitue dans l'instan iationde espatronsàla on eptiondeproto oles. Enn, la troisième ontribution sepla e sur le terrain de l'outillage:unassistantméthodologiqueest(partiellement) implantédansTTooletl'arti ledé ritsamiseenoeuvresur unproto oleissuduprojeteuropéenMastro.

L'arti leeststru turédelamanièresuivante. Lase tion 2passeenrevuedestravauxdudomaine.Lase tion3 pré-senteleprolTURTLEen iblantlesdiagrammesd'analyse utilisés danslasuite del'arti le. La se tion 4propose des patterns a ouplant UCD et IOD. La se tion 5 spé ialise lapropositionverslesproto oles.Lase tion6présenteune étudede asréaliséeave lapremièreversiondel'outilTTool étendue.Lase tion7 on lutl'arti leetannon elestravaux àvenir.

2.

TRAVAUX CONNEXES

2.1

Patterns prouvés

Danslesillagedel'ouvrage fondateurdeGamma[7℄, de nombreuxauteursontproposédespatternsd'analyseoude on eption dédiés à un domaine d'appli ation parti ulier. Ainsi,Douglass[6℄etRising[12℄ontrespe tivementadressé lessystèmestempsréeletlelogi ielde ommuni ation. Au-jourd'hui,l'idéedepartagersousformedepatterndes arté-fa tslargementadoptésparune ommunautédeprati iens, nesesutplusàelle-même.Plusieursauteursexprimentle besoindeformaliserles patternsetproposent d'adosserun travailsurlespatternsàuneméthodeformelle.Ainsi,[8℄ as-so iepatternsetlogiquetemporelle.[10℄intègrelespatterns dansunedémar hede" orre tpar onstru tion"àbasedu langageB.

2.2

Introduction d’un assistant dans un outil

3.

LE PROFIL UML TURTLE

3.1

Vue d’ensemble du profil

Commelesuggèrel'a ronymeTURTLE(TimedUMLand RT-LOTOSEnvironment),leprolUMLtempsréelTURTLE estadossé à l'algèbre depro essustemporiséeRT-LOTOS [5℄.Sasémantiqueestdonnéepartradu tionversRT-LOTOS. L'asso iationàl'outilTTool(TURTLEToolkit supportant leprol[9℄)del'outildevéri ationformelleRTL (suppor-tant RT-LOTOS)fait de TURTLE un langage de modéli-sationparti ulièrement adaptéàlavéri ationd'exigen es temporelles.Ungénérateurde odeJavaouvredes perspe -tivesversleprototypaged'appli ationsréparties.

Supportantlesdiagrammesd'exigen esétenduspardes hro-nogrammesaptes à représenter des exigen es temporelles, TTool permet de traiter les exigen es avant d'entamer la phased'analyse.Celle- idémarre lassiquementparun dia-grammede as d'utilisationquidénitlepérimètredu sys-tème à modéliser, isole les a teurs etidentie les grandes fon tionnalitésque lesystèmedoitorir. Les as d'utilisa-tion représentatifs de es fon tionnalités sont do umentés par des s enarii représentés à l'aide dediagrammes de sé-quen es

1

(voirlaFigure8pourunexempledeSD).Là inter-viennentlesIOD

2

quipermettentdestru turerlesSDsous formed'organigramme.Généralement,unepremièrefamille de s enarii est réalisé n de mettre en éviden e les inter-a tionsa teurs-système.Dansundeuxièmetemps,une ité-rationméthodologique supplémentairepermetd'é later les premiers enarii etde faire apparaître lastru tureinterne du système. Cette analyse fon tionnelle assistée aubesoin d'une re her hedes objets -par exemplepar la tradition-nelleméthodedesmotsdansletexte-débou heensuitesur une on eptionobjets.

Ladénitiondel'ar hite turestatiquedusystèmereposesur un diagramme de lasses/objets TURTLE qui étend eux d'UML2.1 pourformaliser letypederelationentreobjets (parallélisme,syn hronisation,préemption)etautoriser es mêmesobjetsà ommuniquerparrendez-vous.Les ompor-tementsdesobjetssontexpriméspardesdiagrammes d'a -tivitésqui,outreles a tionsdesyn hronisationpar rendez-vous,orentdesopérateurstemporelsaptesàexprimerdes 1.Sequen eDiagram,notéSDdanslasuitedutexte 2.Intera tionOverviewDiagram,ouIOD danslasuite du texte

délaisxesetdes intervallestemporels,maisausside limi-ter temporellement les ores de rendez-vous. La dénition dediagrammesd'a tivitésrendle modèleTURTLE exé u-table. Une dernière étape onsiste enn àee tuer un dé-ploiementdusystèmeàl'aidedediagrammesdedéploiement TURTLE.

Leprin ipedeTURTLEestdefournirunesémantique for-melleàdesensemblesdediagrammesTURTLE.Ainsi,une analyse TURTLE (i.e.un IOD prin ipalettout e quiest liédepuis etIOD),une on eption TURTLE (i.e.un dia-grammede lassesetunensembledediagrammes d'a tivi-tés) ouenn un diagrammededéploiementpossèdentune sémantique formellement dénie en (RT-)LOTOS (le RT s'applique si le système utilise des opérateurs temporels). L'outil TTool sait ee tuer ette tradu tion automatique, et invoquer les outils de véri ation formelle sous-ja ents (RTL[2℄,CADP[1℄).Uneinterfa e onvivialepermetainsi de onfronterlesdiagrammesauxexigen estemporelles.

La suite de etarti le fo alise la dis ussionsurles deux premiersdiagrammesd'analyse,àsavoirlesdiagrammesde asd'utilisationetlesIOD.

3.2

Diagrammes de cas d’utilisation

Undiagrammede asd'utilisationmetenéviden ele sys-tèmeàmodélisersouslaformedefon tionsetsoninterfa e ave l'environnement extérieur représenté par des a teurs ( f.laFigure1).

 Unefrontièrereprésentéesouslaformed'unre tangle délimite lairementlesa teursdesfon tions.

 Lesfon tionspeuventêtremisesenrelationd'in lusion (

<< include >>

),d'extension (

<< extend >>

, l'ex-tensionest engénéral déniepar rapportà unpoint d'extension), ou de spé ialisation ( onne teur UML pourmodéliserl'héritage).L'in lusion permetde mo-déliser des sous-fon tions d'une fon tion; l'extension permet de modéliser les fon tions optionnelles d'une fon tiondeplushautniveau.

 Lesa teurspeuventêtremisenrelationave des fon -tionsave lesquellesilsinter-agissent.

3.3

IOD

UndiagrammeIOD s'apparenteà undiagramme d'a ti-vités UML(unorganigramme, enfait)dontles a tions se-raient rempla ées pardes référen es à des diagrammes de séquen es ou à d'autres IOD. Notons que depuis un dia-grammedeséquen es,iln'estpaspossiblederéféren erun IOD.

Ces organigrammes sont onstitués de noeuds ( hoix, sé-quen e,parallélisme).TURTLEajouteunnoeudde préemp-tionà esIODsand'autoriserlapréemptiond'unebran he d'unIODparunebran hed'unIOD.Unexempled'IODest donnéàlaFigure4.CetIODmetenéviden edesréféren es versd'autresIODs(par exemple,Conne tionsetup estune référen e vers unIOD),des hoixentre IODs(le losange), et un opérateur de préemption (la barre horizontale ave lesymbole

[>

àsonextrémitédroite)quipermetde spé i-erque lesIODsConne tionrelease ouConne tion broken peuventàtout momentinterromprelabran hepartant de lagau hedel'opérateurdepréemption.

Finalement, les IODs, bien que relativement mé onnus et don peuusités,ontlabonnepropriétésdepouvoir stru tu-rerentreeuxdess enarii,etdon deréduireparlàmêmela

omplexitéde ess enarii.Eneet, esderniersont omme avantage d'être un guide visuel d'é hanges d'informations entreinstan es.LesIODsajoutentlapossibilité visuellede pouvoir stru turer des s enarios, enomettant la visualisa-tiondire tede es"détails"d'é hangesd'informationentre instan es. Malheureusement,En UML, ertains opérateurs d'IODs ont lamêmesémantique que eux d'opérateurs de s énario, equiimpliquequelemodeleuralapossibilitéde fairegurer ertainesinformationssoitauniveaudel'IOD, soitauniveaudes énario, equi asseunpeu emodèledual stru ture/ omportement.EnTURTLE,nousavonslimités ertains de espossibilités en rendant obligatoire l'emploi d'unopérateurd'IODoudeSd pour unesémantique don-nées(parexemple,les référen esdes s énariosontété sup-primées des s énarios, maissont onservées auniveau des IODs).Nous avons par ontre gardé l'opérateur d'alterna-tiveauxdeuxniveauxdemodélisation(IODetSD).

4.

UNE MÉTHODOLOGIE BASÉE SUR LES

PATRONS

4.1

Approche générale

L'appro he que nous proposons dans et arti le sebase surlanotiondepatronsUMLformellementdénis.Chaque patron

P

est onstituédedeuxdiagrammes quiservent de anevas à l'utilisateur du patron. Un patron est onstitué d'un UCD et d'un IOD (appelé IODh pour IOD de haut niveau):P=

(U CD,IODh)

,etpossèdelesrèglessuivantes:  A toute fon tion de haut niveau de l'UCD - 'est à dire àtoutefon tionnon in luse dansuneautre-et àtoutefon tionoptionnelleestasso iéeaumoinsune référen e vers un IODdans l'IODhquiporte lenom de ettefon tion.

 Unutilisateurdel'UCDaledroitd'ajouterdes sous-fon tions à des fon tions déjà présentes. A partir de es nouvelles fon tions, il peut spé ialiser es fon -tions(héritage),ajouterdesfon tionsoptionnelles,et . Comme l'IODhn'est pas modiableparl'utilisateur, il n'est paspossible de donnerune orrespondan e à es nouvelles fon tions dansl'IODh,que e soit sous forme de référen e àun IOD, ousous formede réfé-ren eàundiagrammedeséquen es.Ainsi,Cesajouts de fon tionssont représentées uniquementautravers deréféren esversdessous-IODs(ouSDs)deIODh.

 Dansl'IODh,les référen esvers desIODs orrespon-dantàdes fon tionsdehautniveaudoiventêtre obli-gatoirement omplétéi.e.undiagrammeIODdoitêtre fourni. En e qui on erneles autresréféren esà des IODsdel'IODh, ettepro édureestfa ultative, 'est àdirequ'ilspeuventêtrelaissésvides.

 L'IODhnepeutêtremodiéparl'utilisateur,saufau niveaudesnoeudsdetype hoixdontlesgardespeuvent, si elles sont laissées non renseignées par le patron - 'est à dire que le patron possèdedes hoix non dé-terministes - être renseignées selon e qu'autorise la syntaxeTURTLE.

Cespatronsontvo ationàêtreutilisés ommesuit(voirla Figure2):

1. L'utilisateur hoisitunpatron

P

enfon tiondutypede proto olequ'ildoitimplémenter(modenon onne té, mode onne té,diusiondedonnéesdansun groupe, et .).

2. L'utilisateurpeutéventuellementmodierlediagramme de as d'utilisation selon les règles listées plushaut. Pour ela, il est autorisé à utiliser l'opérateur UML

<< include >>

etdes nouveaux asd'utilisation liés à es

<< include >>

.Ilnepeutenau un asajouter desfon tionsdehautniveau 'estàdirenonliéespar un

<< include >>

ave les fon tions déjà fournies dans le diagramme de as d'utilisation. Dans le as ontraire, les garanties donnéespar notreappro he -etexpliquéesplusloin-nesont plusvalables. 3. Pour haqueIOD référen é dans l'IODh deux

possi-bilités s'orent à lui: ompléter et IOD ou bien le laisservide.Lefaitde ompléterunIODveutdirelui donnerunesémantiqueautravers desen haînements d'autresIODsoudes énarios. Lesfon tionsajoutées audiagrammede asd'utilisationdoiventseretrouver auniveaudes IODsréféren éespar l'IODh,soitsous laforme d'un s énario, soit sous laforme d'un IOD. Notonsenn que la stru turegénérale del'IODh ne peutpasêtremodiéeparl'utilisateur.

4. Unefoisquel'utilisateuraterminéderemplirles réfé-ren esqu'il souhaitedansl'IODh,unalgorithme-dit algorithmedeltrage-estappliquéannotammentde débarrasserl'IODhderéféren esversdesIODsvides, etd'éliminerunéventuelparamétragedesdiagrammes deséquen esréféren éspar esIODs(voirplusloin). 5. Nospatrons garantissent par onstru tion un ertain

tréessurdesexemples.Bienentendu,desvéri ations formelles supplémentairespeuventêtre ee tuéespar générationde ode(RT-)LOTOS.

6. Ladernièreétapeestlagénérationautomatiqued'une on eption àpartirdel'analyseee tuée.Leprin ipe de ettegénérationautomatiquen'estpastraitéedans etarti lemaispeut-être onsultéedans[4℄.Rappelons que ettegénérationautomatiquepréserveles proprié-tés du modèled'analysesi etseulementsi e dernier estimplémentable.

4.2

Sémantique

Lespatronsquenousproposonspossèdentunesémantique formellementdéniepartradu tionen(RT-)LOTOS.Cette tradu tionestee tuéeentroisétapes:

1. Filtrage

L'IODhest"ltré" selonlapro éduresuivante. Tout d'abord,lesréféren esversdesIODsquiontété lais-séesvidessontéliminéesdel'IODh, 'estàdirequeles onne teursmenant etpartant de esréféren essont supprimées, et les référen es elles-mêmesont suppri-méesdel'IODh.L'UCDestutilisépar etalgorithme de ltrage pour savoir si une référen e vers un IOD orrespondantàunefon tiondehautniveau-oupas. Siuneréféren e orrespondantàunefon tiondehaut niveaua étélaissée vide,alors la tradu tion nepeut avoirlieu.

Une autre pro édure a lieu à ette étape, que nous nedétaillons dans etarti le.Elle on ernelefaitque lesdiagrammesdeséquen espeuventêtreparamétrés. Plus exa tement, uneinstan epars enario peut-être paramétrée, 'est à dire qu'elle orrespond en fait à ninstan es, uneinstan e étant unélément ommuni-quantdess énarios.Cetteparamétrisationest parti u-lièrementutiledansle asdesystèmesdediusionde donnéesvers

n

lients.L'algorithme deltrage prend enentréepour haqueinstan eparamétréeunevaleur d'instantiationetutilise esvaleurspourinstan ier au-tant defois que né essaire haqueinstan e, et dupli-querlesmessagesarrivantetpartantde esinstan es paramétrées.

2. Génération d'une spé i ation TIF

TIF-TURTLEIntermediateFormat -est unformat intermediaire formel utilisé par TTool etqui sert de base à la génération de ode RT-LOTOS, LOTOS, UPPAALetJava.Notreappro he onfèreainsiàtout ensembleIODs,Diagrammesdeséquen esune séman-tiqueformelle[4℄.

3. Génération d'une spé i ation (RT-)LOTOS Cette générationest ee tuéedepuisle format inter-médiaireenTIF.

Ces tradu tion formelle onfère par onstru tion à tout modèlebasésurnospatrons lapropriétésuivante:

 Propriété 1

Pour toutes les instan es dess énariosqui ee tuent au moinsune a tiondans haque heminpossibledes sous-iods de l'IODh, et si e hemin est unique (pas de parallélisme), et si les référen es entre IODs ne omportentderéféren esversdesIODsréféren éspar l'IODh,alors la séquen e entre desa tions ee tuées dans des sousIODs en séquen e, etpour haque ins-tan e,estgarantiepar onstru tion.

ne té - présenté dans la se tion suivante -, si l'ins-tan e lienteee tuedesa tionsdanstousles hemins possibles des sous-iods, alors le patron garantit par onstru tionquelesdonnéesnepeuventêtrereçues-si etteré eptionestimplantéedansl'iodDataex hange -qu'unefoisla onnexionétablie-sila onnexionest réellementétabliedansConne tionsetup.

La preuve de ette propriété repose notamment surla sé-mantiquedesnoeudsdesIODs( hoix,séquen e,premption), le parallélisme étant ex lu parhypothèse, etsur les possi-bilité de référen ement de s énario et d'IOD.En eet, de façon assez informelle, si l'on onsidère deux IODs

IOD1

et

IOD2

référen ésdansl'

IODh

,quisontenséquen el'un aprèsl'autre.Sil'on onsidère uneinstan e

instance1

d'un s énarioquiee tueaumoinsunea tion

action1

danstous les heminspossiblesde

IOD1

et

IOD2

.Dans haque he-minpossibledel'

IOD1

,

instance1

faitaumoinsunea tion

action1

, eten raison de l'absen e deparallélisme, et l'ab-sen ederéféren ementde

IOD2

depuis

IOD1

(hypothèse), lorsque

instance1

feraunea tion

action2

dans

IOD2

,alors

instance1

ne possédera plus au une a tion en ours dans

IOD1.Don

action2

nepourraêtreee tuéequ'aprèstoute a tion

action1

.

Notonsquelapropriétépré édenterestevalablemêmesiles gardesdes hoixdel'IODdupatronsontrenseignées(etnon laisséesvidesi.e.totalementnondéterministes).

Nousavons outumede omparernospatronsàunGPSde voiture.Lesrèglesd'utilisationdespatrons,ainsiquela mé-thodologiegénéraleprésentées i-dessuspermettentde don-nerunguideaumodeleur.Cedernieralapossibilitéaussi, s'ilnemodiepaslepatron,d'obtenirdespropriétésdeson modèlequisontvraiespar onstru tion.Aladiéren ed'un GPSdevoiturequipeutre al ulerentempsréelun heminà suivresilapersonnedéviedutrajetre ommandé,notre ap-pro henepermetpasdere- al ulerdespropriétésvraiespar onstru tionsilemodeleurn'appliquepasles règles itées. Par ontre,lasémantiquedes modèlesd'analyse TURTLE restevraie-silapersonnese onformeauxrèglessyntaxique TURLE-:l'utilisateurpourratoujoursee tuerdes véri- ationsformellesaposteriorisursonmodèle.

4.3

Outillage supports aux patrons

L'outil TTool [9℄ permetla sauvegarde etl'importation delibrairies /modèles ontenantdes modélisationsTTool. C'est sous ette forme que les patrons présentés à la se -tionsuivantepeuventêtre hargésdansTToolpuisutilisés. Ainsi, un utilisateur, unefois TTool lan é, pourra utiliser unpatron ommesuit:

1. il hargelepatron orrespondant;

2. il omplètele diagramme de as d'utilisation du pa-tron, omme expliqué dans la méthodologie exposée lorsdelase tionpré édente;

3. il omplètelesdiérentsIODsobligatoires,et éventuel-lement euxfa ultatifs, enajoutant àlamodélisation TToollesdiagrammesglobauxd'intera tionsetde sé-quen esné essaires;

4. TTooln'està ejourpas apabledevérierquela per-sonnearespe télepatron,etanotammentfourniles diagrammesobligatoires.Par ontre,TToolvérieque lasyntaxedesdiagrammesest orre te,parrapportau méta-modèleTURTLE.Unefois ettevéri ation syn-taxiqueee tuée,TTool onstruitunemodélisation

in-terneenformatTIFquitient omptedesdiagrammes fournisparl'utilisateur,etquitient omptedupatron. Apartirde eformatinterne,l'utilisateuradeux pos-sibilités:

 Ee tuer dela véri ationformelle, par généra-tionde odeLOTOSouRT-LOTOS;Cette véri- ationformellepeut-êtreréaliséedire tement de-puisTToolsans au une onnaissan ede es lan-gages formels, oudes outilsde véri ation asso- iés.

 Générer automatiquement une premier on ep-tion,quitient omptebienentendudela modéli-sationdel'utilisateur,etdupatron.

Ainsi,à ejour,l'appro hegénéralepré édemmentprésentés n'estquepartiellementimplémentée.Deuxpointsmanquent plusparti ulièrement:

 la véri ationque l'utilisateur s'est bien ins rit dans lepatronqu'ila hargédansTTool;

 la gestion du paramétrage n'est pas en ore possible. Ainsi,a tuellement,unesolution onsisteàutiliserun modèle omportant unnombre d'utilisateurxe. No-tonsqueleproblèmeduparamétragen'estpasun pro-blèmeliéàl'appro heparpatronsengénéral,maisun problème liéàlasémantiquedu prol TURTLE.Par exemple, les diagrammes de on eption TURTLE ne sont pasparamétrés.Onpeututiliser lanotion d'ob-jets,ouinstan ierdynamiquementdesobjetsdansles on eptionsTURTLE,maispasparamétrerles lasses, par exemple,exprimerque

n

lientssont onne tésà

m

serveurs.

5.

PATRONS TURTLE POUR LES

PROTO-COLES

Dans ette se tion,l'idée n'est pasdefaire un atalogue des patrons que nous proposons sous TTool, mais plutt

demettreenéviden el'intérêtde espatrons ommeguide méthodologique formel de on eption de proto oles et de systèmesdistribués.

5.1

Patron pour les protocoles en mode connecté

Ce patron vise l'analyse des proto oles omportant une phase de onnexion avant tout é hange dedonnées. Cette phase d'é hange de données a lieu jusqu'à la fermeture -voulueounon-dela onnexion.

Lepatronest onstruit ommesuit:

 Sondiagrammede asd'utilisation(voirFigure3)met enéviden etroisprin ipalesfon tions:

1. l'établissementdela onnexion,ave négo iation delaqualitédeservi e(option);

2. l'é hangededonnées,quipeutéventuellement om-porterdesdéséquen ementsetdespertesde don-nées, qui sont alors gérés par le proto ole (par exemple Data transfer with loss in lutData re-transmission);

3. landela onnexionquipeutêtresoitvolontaire, soitdueàunerupturede onnexion.L'utilisation d'une relation héritageentre as d'utilisation si-gnie qu'un des deux IODs orrespondant à la terminaisondela onnexiondevraultérieurement êtrerenseignéi.e.êtrenonvide( f.lespropriétés despatrons).

 Sondiagrammeglobald'intera tions omporteluiaussi troisprin ipales parties:

1. lapartieduhautmetenéviden elefaitque l'ou-verturede onnexionsefaitave ounon négo ia-tiondeservi e;

2. Lapartiesituéeenbasàgau hemetenéviden e les é hangesdedonnées, ave éventuellement re-négo iation de laqualité de servi e en ours de onnexion;

3. enn, lapartie en bas à droite met enéviden e qu'une fois la onnexion établie, elle peut être rompueourelâ hée non volontairement. Notons l'opérateurdepréemption-àlaLOTOS-qui per-met demodéliser ela. Cette extensionaux dia-grammesglobaux d'intera tions UMLaété pré-sentéedans[4℄.

Une première remarque on ernant le patron est que les fon tionsin lusesdel'UCD(Datareordering,Data retrans-mission)nedoiventêtreimplantéessousformed'IODsetde SDsque siles fon tions optionnelles les in luant sont-elles mêmerenseignées.AussibiennospatronsqueTToolnefont au une véri ation en e sens, et rien n'interdit d'ailleurs d'aller mettre dans un l'IOD appelé Conne tion setup un é hangededonnées:lesnomsdesfon tionsdel'UCDetdes IODsnesontquedesassistantsàl'analysequilaissentlibre oursàl'utilisateur,àl'instard'unGPSdevoituredontles indi ationssontdébrayables.

Unedeuxièmeremarquesur epatronestrelativeàla pro-priété1despatrons.Sil'onsupposequenoss énarios om-portent une instan e Server et que ette instan e Server ee tueaumoinsunea tiondans ha undesIODs obliga-toires,alors,par onstru tion,l'on garantitqueles a tions ee tuéesdansData Ex hange,dansConne tion broken et dansConne tionrelease lesontfor émentaprès lesa tions ee tuéesparServer dansConne tionsetup.

5.2

Patron pour les protocoles de diffusion

Lepatronproposé estdestiné àlamodélisationdes pro-to oles de diusion d'un serveur vers

n

lients abonnés à ungroupedediusion.Cepatronestainsiparamétré,nous expliquons eparamétrageparlasuite.

Cepatronest onstitué:

 d'undiagrammede asd'utilisation.Cederniermeten éviden ed'unepartdesfon tionsdemanipulationdu groupedediusion,etd'autrepartd'é hangesde don-néesdans egroupedediusion.En equi on ernela manipulationdugroupedediusion,ungroupe peut-être réé-ave éventuellementdesparamètresliésàde laqualitédeservi e-oudétruit.Un lientpeut s'ajou-teràungroupedefaçonstandard,ouenpré isantses propresparamètresdequalitédeservi e.Auniveaude l'é hange dedonnées, despertes oudéséquen ements peuventapparaître.

 D'un diagramme global d'intera tions ( f. Figure 6). Cederniermetenéviden ela réationdugroupe.Une fois le groupe réé, des ajouts ou retrait de lients peuvent intervenir sur le groupe. Aussi,des données peuvent êtreémisesau seindu groupe. Enn, la dif-fusion dedonnéesetl'ajout /le retrait de lients au sein du groupe esse lorsque le groupe est supprimé (opérateurdepréemption).

Ilserapossiblededirequ'un utilisateurnepeut sejoindre augroupequesilenombremaximald'utilisateurdugroupe n'est pas atteint par un simple ajout d'une garde sur le hoix pré édant l'ajout des utilisateurs. C'est d'ailleurs e quenousavonsfaitdansl'étudede asàsuivre,quipermet enoutredemieuxexpli iter epatron.

6.

ETUDE DE CAS : UN PROTOCOLE

MUL-TICAST

6.1

Présentation du protocole

Dans etteétudede as,nousavonsreprislepatron pro-posédansle adredeladiusiondedonnées,etnousl'avons appliquéàuneversionsimpliéed'unproto oledediusion de données multimédia proposé dans le adre d'un projet Européen(projetMaestro).

Dans eproto ole,unémetteurdeuxmultimédiademande àun serveur prin ipalla réation d'ungroupe dediusion auxquels desutilisateurspeuventparlasuitesejoindreen onta tant le dit serveur. Lorsqu'au moins un utilisateur est présent dans legroupe, les donnéessont régulièrement émisesversunsatellitedediusionmulti-fais eauxqui pos-sède un routeurembarqué apable de diuserdes données vers ertainsfais eaux:ladiusiondansun fais eaudonné n'alieuquedansle asoùaumoinsunutilisateurde e fais- eauestins ritaugroupedediusion.Notonsennqueles donnéesé hangéesentreles lientsdugroupe etle serveur sontee tuéesparunevoieretourterrestre.

6.2

Analyse basée sur les patrons

Lepatronquenousavonsutilisédans etexempleest elui orrespondantauxsystèmesmulti ast.Nousavonsfourniles omportementdesIODssuivants:

 Créationd'ungroupe.Cette réationestréaliséelorsque un serveurdedonnéesmultimédiadésireémettre des donnéessurlesystèmesatellite

 Ajoutd'unutilisateuràungroupe.Nousnoussommes limités,pourdesraisonsde omplexité,àtrois utilisa-teurssituésdansdeuxfais eauxdiérents

 Retraitd'unutilisateurd'un groupe.

 Émission de données. Le serveur multimédia met à jourlesdonnéesàémettreauniveaudusystème satel-lite(Gateway).Cesdonnéesnesontréellement trans-mises que si au moins un utilisateur s'est ajouté au groupe. Si tel est le as, les données sont envoyées, a ompagnées deFEC

3

,àborddusatellite, ave des informationsstatiquesderoutage.LesdonnéesetFEC sontalorsroutésverslesfais eaux orrespondantsaux utilisateurs du groupe. Notons que es données sont émisesverstousles utilisateursins ritsaugroupeau moment de leur émission sur leur satellite, même si entretempsles utilisateursesont désins rits. L'émis-siondedonnéessetermineparl'envoid'a quittements des lientsversleserveurdegroupe.

 Destru tion d'un groupe. Le serveur de groupe peut dé iderdefermerlegroupe,soitpouruneraison d'er-reur,soitpar equeleserveurdedonnéesmultimédiaa terminésadiusion.Les lientssontinformésde ette fermeture,maispeuvent ontinuer à re evoirles der-nièresdonnéesémisesparleserveurmultimédia. Pluspré isément,etàtitred'exemplebasique,nous fournis-sonsle ontenudel'IODA lientjoinsthegroup àlaFigure 7.CetIOD omportelui-mêmetroisréféren esversdes s é-narios.Ces s énariospermettentà haque lient de s'ajou-teraugroupe.Par exemple,laFigure8montre ommentle lient1 peut s'ajouter au groupe . Certains sous IODs et s énariossontbienentenduplus omplexesque euxfournis dans esdeuxgures.

6.3

Vérification formelle

Fig.6 Patron pour les proto oles de diusion: diagramme global d'intera tions (IOD)

Aprèsavoirremplilepatrontelquedé ritpré édemment, nousavons utilisé legénérateur automatique de ode LO-TOSdeTTooletl'outilCADPande onstruirelegraphe d'a essibilitédenotreappli ation.Cedernier omporte en-viron6millionsd'étatset25millionsdetransitions. Nousavonsaussiréalisélegraphed'a essibilitéde ette ap-pli ationdépourvudurebou lage auniveaudel'IOD prin- ipal(i.e.leliensentreladestru tiondugroupe,etsa réa-tion).Latailleplusmodestedugrapherésultantnousa per-misderéaliserdespreuvesdepropriétés.Atitred'exemple, la Figure 9 représente le graphe minimisé aux a tions de lient1.Cegraphemetenéviden equelesdonnéesnesont reçuespar lient1quelorsque edernierfaitpartiedugroupe (joinDone esttoujoursavantdata).Deplus, lorsquele sys-tèmes'arrête,l'utilisateurreçoitundernierpaquetde don-néesnona quitté.

Finalement,nousavonspuprouver,que:

 unutilisateurnepeutre evoirdedonnéess'iln'estpas membredugroupe;

 un utilisateurpeutre evoiraumaximumunedonnée supplémentaireaprèsfermeturedugroupe.Ils'agitde ladonnéeen oursd'émissionavantl'ordrede ferme-turedugroupe.

6.4

Génération d’une conception

TToolpermetlagénérationd'une on eptionéquivalente àl'analyse,auxproblèmedenon-implémentabilitéprès[4℄. Pournotresystème,nousavonsainsigénéréune on eption qui omprend 8 lasses qui orrespondent aux 8 instan es des s énarii dé rites lors de l'analyse (diagrammes de sé-quen es).Le omportantde es lasses est al uléà partir desIODsets énariosdel'analyse.

6.5

Discussions et limitations

Nous avons appliquéave su èsnotreappro hepar pa-tron à un systèmedistribué que l'on pourrait qualier de omplexe (plusieurs médiums de ommuni ation, routage statique,buerisation,gestion degroupe,et .).Mêmesi la véri ationn'a pusefairequedansun ontexte ave assez peu d'utilisateurs, l'analyse du système, en se basant sur lepatron,aétéréaliséeenunpeumoins d'unejournée, e quidémontreapriorilapertinen edel'appro he.Toutefois, nousavonsren ontréun ertainsnombredelimitationsqui sontdis utéesparlasuite

Toutd'abord,leproblèmedelanon-implémentabilité,quia étéabordéauparavant[4℄dansle adredel'analyseTURTLE. Les patrons que nous fournissons ne garantissent en rien ettenon-implémentabilité.Cettedernièreprovenantde hoix dits distribués,nousnous sommeseor és lors de

l'utilisa-tiondenotrepatron,etdansnotreétudede as, denepas utiliser detels hoix. Cette ontrainteestapparue omme assez forte, et nous a amené à utiliser des messages syn- hronespluttquedesmessagesasyn hronesdans ertaines situations,notammentdanslamodélisationdesintera tions lient-serveurdegroupe.

Ledeuxièmeproblèmeren ontré on ernelerebou lage.Les patrons fournis font l'hypothèse d'un rebou lage vers une nouvelle onnexion lorsque la onnexion en ours est ter-minée. Ce rebou lage a étéprévu pour s'ins rire dansun adregénéraldemodélisation,maisnuitàlavéri ation for-melle.Parexemple,dansle adredenotresystème,legraphe d'a essibilité ave rebou lage omporte plusieurs millions d'états,etseulement30000sans erebou lage.Ceproblème est bien entenduplus généralque eluide l'utilisation des patrons,etestpluttinhérentàlavéri ationdesystèmes dé ritsave desLTS.

Le troisième limitation on erne le paramétrage. Dans le adre de systèmesdistribués, ilest utilede pouvoir spé i-er un nombre

n

d'utilisateurs du système. Malheureuse-ment,l'appro heUMLne omportepasdes énarios para-métrables,ausensoùlenombred'instan ede ess énarios pourraitêtreparamétré.Celafaitpartiedenostravaux fu-turs que d'ajouter e paramétrage à la fois au niveau de l'analyseTURTLE,etauniveaudenospatrons.

7.

CONCLUSIONS

Fairesespremierspasenmodélisationdeproto olesdans un environnement UMLestunetâ hedéroutantepourqui se onfronteauxtreizediagrammessupportésparlanorme 2.1etàunesimpledes riptioné rited'unpro essus métho-dologique.L'idéedéfenduedans etarti leestd'in lureaux ateliers logi iels UML autorisant la validation de modèles de on eption,un assistant méthodologique quiserait àla modélisation UMLoutillée equ'estunGPS àla onduite automobile.Sanspertedegénéralité, etteidéeestmiseen oeuvresurleprolUMLtempsréelTURTLEsupportépar l'outilTTool.

L'arti le propose tout d'abord d'introduire des patrons al-liantdiagrammesde asd'utilisationetdiagrammesd'aperçu général,respe tivementdédiésàl'identi ationdes fon tion-nalitésdusystèmeetàlastru turationdes énariiexprimés pardesdiagrammesdeséquen es.L'appro heestappliquée aux proto oles en distinguant les modes sans onnexion ,  onne té , et  multi ast (l'arti le ne détaille que les deux derniers, maislepremier est bien disponiblesous TTool).Enn, e adreméthodologiqueformeletsa spé ia-lisationauxproto olessontimplantésdansTTool.Cetoutil

aétéutilisé pour traiter le as d'un proto ole dediusion dedonnéesmultimédia.

L'implantationdansTToolutiliselegestionnairede biblio-thèquedel'outilpourgérerlespatrons.Letravail d'implan-tation sepoursuivra par l'implantation del'algorithme de ltrage,etparlapossibilitédeparamétrerlesinstan esdes s enarii.

D'unpointdevueplus on eptuel,letravaildeformalisation du adreméthodologiquevasepoursuivreparlaréalisation depatronspourlessystèmesdistribués,etparuneréexion plusgénéralesurlapossibilitéd'orir,ave ertaines restri -tion,plusdepropriétéssatisfaites par onstru tion.

8.

REFERENCES

[1℄ The adptoolkit.http://www.inrialpes.fr/vasy/ adp. [2℄ Thertltoolkit.

http://www.laas.fr/RT-LOTOS/index.html.en. [3℄ L.Apvrille,J.-P.Courtiat,C.Lohr,and

P.deSaqui-Sannes.TURTLE:AReal-TimeUML ProleSupportedbyaFormalValidationToolkit.In IEEEtransa tionsonSoftwareEngineering,

volume30,pages473487,Jul2004.

[4℄ L.Apvrille,P.deSaqui-Sannes,andF.Khendek. Synthèsed'une on eptionUMLtemps-réelàpartirde diagrammedeséquen es.InColloqueFran ophone sur l'IngéniériedesProto oles,Bordeaux,Fran e,mar 2005.

[5℄ J.-P.Courtiat,C.Santos,C.Lohr,andB.Outtaj. Experien ewithRT-LOTOS,aTemporalExtensionof theLOTOSFormalDes riptionTe hnique.In

ComputerCommuni ations,volume23,pages 1104123,2000.

[6℄ B.P.Douglass.Real-TimeDesignPatterns:Robust S alableAr hite ture forReal-TimeSystems.Addison wesley,2002.

[7℄ E.Gamma.DesignPatterns.Addisonwesley,1995. [8℄ S.KonradandB. H.C.Cheng.Real-timespe i ation

patterns.InPro eedingsof the27thinternational onferen eonSoftwareengineering,pages372381,St. Louis,MO,USA,May2005.

[9℄ LabSo .TheTURTLEToolkit.In

http://labso . omele .enst.fr/turtle/ttool.html. [10℄ T.Le omte,D.Cansell,andD.Méry.Patronsde

on eption prouvés.InJournéesNEPTUNE,May 2007.

[11℄ OMG.UML2.0 Superstru tureSpe i ation.In http://www.omg.org/do s/pt /03-08-02.pdf,Geneva, 2003.

[12℄ L. Rising.DesignPatternsinCommuni ations Software.CambridgeUniversityPress,2001.