Ar goUML+B : un outil de transformation systématiquedespécificationsUML enB

H. Ledang,J.Souquièreset S.Charles

LORIA - UniversitéNancy 2 - UMR 7503Campusscientifique,BP239

54506Vandœuvre-lès-Nancy Cedex - FranceEmail:{ledang,souquier,charles}@loria.fr

Résumé. Lesschémasdedérivationd’UML enB visentundoubleobjectif.D’unepart,ils permettentd’utili-serlesspécificationsUML commepointdedépartduprocessusdedéveloppementdespécificationsB. D’autrepart, ils permettentd’utliser les outils de B pour analyserles spécificationsB dérivéesafin d’identifier lesdéfautsauseindesspécificationsUML.

Cepapierdécritle prototypeArgoUML+B, uneextensiond’ArgoUML. ArgoUML estunoutil écritenJavadont le sourceestdisponible,permettantd’éditer desdiagrammesUML. ArgoUML+B concernela transfor-mationdediagrammesUML enspécificationsB.

Mots clés: UML, B, schémasdetransformation.

1 Intr oduction

UML [16] etB [1] sontdeuxtechniquesdespécificationreconnuesengénielogiciel ; leur intégrationestmotivéeparle souhaitdepouvoir lesutiliser conjointementdansuneapprochededéveloppementdelogicielspratique,unifiéeetrigoureuse.La pratiquevientdeUML entantquetechniquedespécificationà objetslargementacceptéeenmilieu industriel; la pratiquevient aussideB entantqueméthodefor-melledontlesapplicationsindustriellessonteffectives[5, 2]. La rigueurvientdeB entantqueméthodeformellequi aétévalidéedansdesapplicationsindustrielles[5, 2]. L’unificationvientà la fois deUMLet deB puisquecesdeuxnotationspeuventêtreutiliséesduranttouteslesétapesdedéveloppementdelogiciels,del’expressiondesbesoinsjusqu’àla programmationenpassantparla conception.

La transformationdespécificationsUML en B viseun doubleobjectif : d’unepart, le processusdedéveloppementestinitialisé endécrivantdesspécificationsUML afin de faciliter le développementdespécificationsB. D’autrepart,lesoutilsdesoutienpuissantsdeB (AtelierB, B-Toolkit) sontutiliséspouranalyserles spécificationsB dérivéesafin d’identifier les défautspotentielsau seindesspécificationsUML initiales[9].

Le travail de thèsed’Éric Meyer [13] a initié la dérivation de spécificationsUML en B. Ce travailpartage(enfait il enhérite)denombreuxpointscommunsaveclestravauxdeLano[8] et Nguyen[15]pour dériver unespécificationB à partir desmodèlesOMT. Les schémasde dérivation proposésparMeyer permettentde formaliseren B tous les conceptsstructurelsUML : classe,attribut, associationbinaire(y comprisl’agrégationet la composition),qualificationd’association,héritageet état(auseindesdiagrammesd’état-transition).Grâceàcesschémas,lesdonnéesB (variables,ensembles,constantes)desspécificationsB dérivéessontgénéréessystématiquementvoire automatiquement.Desapprochessimilairesexistentautourd’UML etZ [3, 4], UML etLOTOS[18].

Dans[10, 11] nousavonsprésentéuneapprochebaséesur le raffinementprocéduralsupportépar laméthodeB, pourmodéliserenB desconceptscomportementauxUML, à savoir lesopérationsauseinde diagrammesde classes(dansla suiteuneopérationau seindesclassesest référencéecommeuneoperation UML) et lesévénements.Notreapprochedonnelieu àdeuxprocéduresdedérivationd’unespé-cificationB à partir d’un ensembledediagrammesUML. La premièreprocédurepermetdedériver unespécificationB àpartir d’un ensembledediagrammesdeclasseset dediagrammesdecollaborationquidécrivent l’implémentationéventuelledesopérationsUML. La deuxièmeprocédurepermetdedériverunespécificationB àpartir d’un ensembledediagrammesdeclasseset d’état-transition.

ArgoUML 1 estuneplate-formed’éditionetd’aideà la conceptiondediagrammesUML. Cetteplate-forme permetd’éditer la plupartdesdiagrammesUML ainsi quedescontraintessupplémentairesenOCL surlesdiagrammesédités.Un point intéressantd’ArgoUML estquecetteplate-formeestdévelop-péeenJavaet le sourceestdisponible.NoussouhaitonsajouteràArgoUML uncomposantqui permettede transformerdesdiagrammesUML enspécificationsB. Cepapierdécrit le prototypeArgoUML+B,uneextensiondeArgoUML, qui implantela procédurededérivationd’unespécificationB à partir d’unensembledediagrammesdeclasseset d’état-transition.

Le paragraphe 2 présenteunevuegénéraledu prototypeArgoUML+B à traverssonutilisation pourcréerlesdiagrammesdeclassesetd’état-transitionet la spécificationB correspondante.Le paragraphe 3rappellelesschémasdetransformationd’UML enB implantésdansla versionactuelled’ArgoUML+B.Unecomparaisondenotreoutil avecdesoutilssimilairesdansle paragraphe 4 conclutnotreprésentation.

2 Ar goUML+B : unevisite guidée

La figure 1 présenteunevue généraled’ArgoUML+B. Danscettefigure,ArgoUML+B a étéutilisépourcréerlesdiagrammesUML et la spécificationB correspondanted’un systèmedecontrôled’ascen-seursdontle fonctionnementsuit lesrèglessuivantes:

– lesascenseursdesservent lesétagesd’un bâtiment;

– lesascenseursetlesétagesdisposentd’unensembledeboutons.Chacundecesboutonssymboliseunétage.Lesboutonsà l’intérieur desascenseurssontdesboutonsd’indication,ils précisentlorsqu’unusagerestdansl’ascenseurl’étageoù il souhaiteserendre.Lesboutonssituésà chaqueétagesontdesboutonsd’appeldel’ascenseurpourcetétage;

– demanderla visite d’un ascenseurà un étagedonnécorrespondà un appeld’un ascenseuren ap-puyantsur un desboutonsassociéà cet étage.Quandun boutona étéactivé, il s’allumeet restealluméjusqu’àcequela visite del’étagecorrespondantsoit effective ;

– un ascenseurenmouvementa toujoursun étagededestinationprioritaire.Celui-ci estchangélors-qu’il a étévisité et qu’il y a unedemandedevisite à un autreétage.Ainsi, le mouvementde l’as-censeurdépendde l’ordre desdemandes.On ne traite pasl’optimisation du mouvement.Lorsquel’ascenseurpasseparl’étagededestination,il s’arrête,ouvresaportependantuncertaintempspuisla refermeautomatiquement;

– l’ascenseurestmisenattenteaudernierétagedesservilorsquetouteslesdemandesontétésatisfaites.Une demandeprovenantde l’étageoù l’ascenseuresten attenteprovoquel’ouverturede la portependantuncertaintempspuissafermetureautomatique.

2.1 Interface graphique

Commeon peutle constater(figure 1), l’interfacegraphiqued’ArgoUML+B estdiviséeencinq par-ties:

1. le menu permetde réaliserles opérationstellesquela créationd’un projetArgoUML composédediagrammesUML, la créationd’un diagrammeUML ;

2. la fenetre de navigation (à gaucheenhautdel’écran) permetà l’utilisateurdesélectionnerlesobjetsou d’afficherlesdifférentsdiagrammesUML ;

3. la fenetre d’ edition (à droite enhautdel’écran) permetdedessinerlesdifférentsdiagrammes.Cettefenêtreestcomposéed’une barred’outils pour la créationdesélémentsde différentsdiagrammesUML ;

4. la fenetre de conseils (à gaucheenbasdel’écran) affichelesconseilsdeconception;

1. http://www.ArgoUML.org, danscepapiernousutilisonsla version0.9.7qui estsortiedébut mars2002.

FI G. 1 – L’interfacegraphiqued’ArgoUML+B

5. la fenetre de details (à droite en basde l’écran) permetd’afficher et de saisirdesinformationsduprojet ArgoUML en cours.Parmi les ongletsde cettefenêtre,l’onglet “Properties”permetd’af-ficher et de saisir les informationsde l’élémentsélectionnédansun diagrammeUML et l’onglet“Constraints”permetd’afficher et de saisirdescontraintesadditionnelleséventuelles(en plus descontraintesreprésentéesgraphiquement)pourl’élémentsélectionné.Pourla transformationd’UMLenB, nousavonsajoutéun nouvel onglet“SourceB” pourafficherle codeB généré.

2.2 Création desdiagrammesUML

Le diagramme de classes. La fenêtred’édition de la figure 1 présentele diagrammede classesdusystèmedecontrôled’ascenseurs.Cediagrammesecomposededeuxclasses: Lift pour lesascenseurset Button pour les boutons.Pourun ascenseur, nousconsidéronsles informationsconcernantla direc-tion courantede l’ascenseur(dir : DIRECTION), l’étagede destinationcourantede l’ascenseur(curDest-

Floor : FLOOR) et l’état dela portedel’ascenseur(doorStatus : STATUS). Dansla classeButton, ondéclareseulementunattribut floor qui modélisel’étageassociéàchaquebouton; cetattribut estdetypeFLOOR.

Pourfaciliter la manipulationdesdiagrammesUML, unebarred’outils composéed’icônesestfournieavec la fenêtred’édition. Le contenudecettebarred’outils varieselonle typedu diagrammecourant.Les élémentsdansle diagrammecourantsont sélectionnésen cliquant sur l’élément dansla fenêtred’éditionoubienencliquantsuruneicônereprésentantl’élémentdansla fenêtredenavigation.L’onglet“Properties”et l’onglet “Constraints”dansla fenêtrede détailspermettentd’afficher et de saisir desinformationsrelatives à un élémentsélectionné; il s’agit non seulementdespropriétésvisuellesdesélémentssélectionnésmaisaussidescontraintessupplémentairessurceséléments.

La définition des types se fait à l’aide de l’icône “«DT»” dansl’onglet “Properties”.Dans Ar-goUML+B, le typeénuméréDIRECTION

�{ up, down} estdéfini commeun typeavec deuxattribut up

et down modélisantles deuxvaleurspossiblesdu type. Il en estde mêmepour le type STATUS. En re-vanche,le type intervalle FLOOR

�ground ��� top estdéfini parun type avec un stéréotype“intervalle”

pourindiquerquec’estun typeintervalle.DeuxattributsdeFLOOR serventàbornerl’intervalle.LesopérationsUML danslesdeuxclassessontgroupéesendeuxcatégories: lesopérationsdebase

localesàchaqueclasseetlesopérationsavecle stéréotype“evenement”; il s’agitdesévénementsauseindesdiagrammesd’état-transitiondontnousallonsparlerplustard.Chaqueopérationaunespécificationdécritedansl’onglet “Constraints”.L’onglet “Constraints”permetde créerplusieurscontraintespourchaqueélémentsélectionné.Dansle casd’une opérationUML, nousavons prévudeux contraintes:unepour la préconditionet unepour la postcondition.Dansla versionactuelled’ArgoUML+B, nousexprimonsla spécificationd’uneopérationUML ennotationB. Cecinécessitel’utilisation desschémasdetransformationd’UML enB pourlesconceptsstructurels,à savoir la classe,l’attribut, l’association,l’état lors de la spécificationdesopérationsUML; cependantlors de la transformationd’un ensembledediagrammesdeclassesetd’état-transitionenB, il suffit decopiercescontraintesetdelesmettreà laplaceappropriéedansla spécificationB. Lesschémasdetransformationd’OCL enB ontétédéfinis[12]etnousavonsenvisagéd’implantercesschémasdansArgoUML+B, cequi permettraitderemplacerlescontraintesécritesenB parlescontraintesécritesenOCL lorsdela constructiondespécificationsUMLavecArgoUML+B.

Les diagrammesd’état-transition. Le diagrammed’état-transitiond’uneclasseestcrééensélection-nantl’élémentclasseenquestiondansle diagrammedeclassesetenappelantensuitel’opération“StateDiagram” du sousmenu“CreateDiagram”. La figure 2 présentele diagrammed’état-transitionde laclasseButton créésousArgoUML+B. Chaqueboutona deuxétatson et off qui correspondentà l’état dela lampedu bouton.Quandun boutonestactivé, il passedansl’état on ; quandun ascenseurs’arrêteàun étage,les deuxboutonsassociéssontdansl’état off. Lorsqu’unboutondansl’état off estactivé, unévénementcall estenvoyé de façonasynchrone(le messageestpréfixépar “asyn”) à l’ascenseurasso-cié aubouton; le paramètredecall estl’étagedu bouton.A noterégalementqu’unefois le diagramme

FI G. 2 – Le diagrammed’état-transitiondela classeButton

FI G. 3 – Lediagrammed’état-transitiondela classeLift

d’état-transitiond’uneclassecréé,uneicônereprésentantcediagrammeapparaîtdansl’arborescencedela classe(cf. l’icône “Lift” dela classeLift dansla figure 1).

Le diagrammed’état-transitionde la classeLift (figure 3) a trois étatsready, visit et movement. C’estseulementdansl’état ready quel’ascenseurestprêtà servirun éventuelévénementcall. Si un ascenseurestdansl’état ready et le boutond’appelà l’étagecourantde l’ascenseurestactivé, l’ascenseurpassedansl’état visit. La ported’un ascenseurpassantdansl’état visit doit s’ouvrir, celaveutdirequel’appelàl’opérationopenDoor() estl’action d’entréedel’état visit. Si l’étagedu boutond’appeln’estpascelui del’ascenseur, l’ascenseurpassedansl’état movement ; il peutmonterou descendre,enfonctiondel’étagedu boutond’appelvis à vis de l’étageoù setrouve l’ascenseur. C’est pourquoiil y a deuxtransitionsreliant l’état ready et l’état movement. Un ascenseurdansl’état visit doit passerdansl’état ready avantde traiterun autreévénementcall. A la sortiede l’état visit, la portede l’ascenseurdoit sefermer, celaveutdire quel’appel à l’opérationcloseDoor() estl’action desortiede l’état visit. Dansl’état movement,lorsquel’ascenseurarrive à l’étagede destinationcourante(événementarrive), l’événementrelease estenvoyé defaçonsynchronepouréteindrelesdeuxboutonsassociésà l’étagevisité.

Remarque 1 (Les operations UML pour les actions) Lesactionsdanslesdiagrammesd’état-transitiondesdeuxclassesLift et Button sontdesappelsaux opérationsUML déclaréesdansles deuxclassesLift etButton. Danslesgardeséventuellesdestransitions,il estpossibled’appelerlesopérationsdeconsultationdéclaréesdanslesdeuxclassesLift et Button.

2.3 Passageà une spécificationB

L’onglet“SourceB” (cf. figure 1) permetd’afficherla spécificationB généréeàpartird’un diagrammedeclasseset d’un ensembledediagrammesd’état-transitionassociésauxclasses.La figure 4 montrelahiérarchiedescomposantsde la spécificationB généréeà partir desdiagrammesde classeset d’état-transitiondu paragraphe 2.2. Dansle paragraphesuivant,nousprésentonslesprincipesdela transforma-tion d’UML enB pourlesdiagrammesdeclassesetd’état-transition[13, 11]. Ci-après,nousprésentonsun survol descomposantsB dela spécificationB dérivée.

ButtonLift

Basic

Types

REFINES

System

System_ref

EXTENDSEXTENDS

SEESSEES

SEES

INCLUDESSEES

SEES

USES

FI G. 4 – Les composantsde la spécificationB dérivéeà partir desdiagrammesde classeset d’état-transition du para-graphe 2.2

– Types estunemachineabstraitedanslaquellesontdéclaréslesconstanteset lesensemblesutiliséspar les autrescomposants.Parmi les ensemblesdéfinis dansTypes , il y a l’ensembleB abstrait������� ���

modélisantl’ensembledesinstancespossiblesde toutesles classes.Les typesUML(énumérésou génériques)sontaussimodélisédansTypes par les ensemblesB. DansTypes , il y a

aussidesconstantes; il s’agit desconstantesmodélisantl’ensembledesinstancespossiblespourchaqueclasseet lesconstantesdéfinissantlesbornesdestypesUML intervalle. La machineTypesestvuepartouslesautrescomposantsdela spécificationB dérivéegrâceà la clauseSEES.

– System estunemachineabstraitedont chaqueopérationcorrespondà un événementdansles dia-grammesd’état-transition.Lesvariablesdecettemachinesontdérivéesdesconceptsstructurelsdela spécificationUML, à savoir : classe,attribut, association,état.S’il y a unecommunicationasyn-chroneau seindesdiagrammesd’état-transition,alors il y a desvariablesmodélisantles files demessagesasynchroneséchangés.

– Basic estunemachineabstraitedontlesopérationsmodélisentlestransitionset lesopérationsUMLcorrespondantauxactionsauseindesdiagrammesd’état-transition.Lesdonnéesdela machineBasicsontidentiquesauxdonnéesdela machineSystem. Deplus,parla clauseEXTENDS, la machineBasicsecomposedesmachinesabstraitesdérivéesdesclassesetdeleursassociations.Dansl’exemplepro-posé,il s’agitdela machineLift etdela machineButton : la machineLift estdérivéedela classeLift ;la machineButton estdérivéedela classeButton etdel’associationliftButton entrelesdeuxclassesLiftet Button. La machineLift modéliseégalementles transitionset l’état courantdu diagrammed’état-transitionde la classeLift ; quantà la machineButton , elle déclareles opérationsB modélisantlestransitionset unevariableB modélisantl’état courantdu diagrammed’état-transitionde la classeButton. Ceci permetà Basic de déléguerles opérationspour les actionset pour les transitionsauxmachinesincluses.Parconséquent,dansla machineBasic ondéclareseulementlesvariablescorres-pondantà la communicationasynchroneéventuelleentrelesdiagrammesd’état-transitionainsiquelesopérationspourmanipulercesvariables.

– System ref estun raffinementdela machineSystem. System ref inclut la machineBasic parla clauseINCLUDES. CecipermetderéaliseruneopérationabstraiteB d’un événementenappelantlesopéra-tionsabstraitesB modélisantlestransitionset lesopérationsB pourlesactions.

A noterégalementquechaquecomposantde la spécificationB dérivéeestaffiché dansun champtextuel contenudansl’onglet “SourceB”. Ce champpossèdeégalementun menucontextuel (figure 5)qui permetderéaliseruncertainnombred’actionssurlescomposantsB tellesquela sauvegardeducodeB généré,l’autorisationdemodificationducodeB généré,etc.

FI G. 5 – Menucontextuel

Remarque 2 (a propos de la pr esence de la machine Basic) La machineBasic est indispensable: si elleestomise,le composantderaffinementSystem ref doit avoir les liens“ INCLUDES” auxdeuxmachinesLift et Button . CeciestimpossibleenB àcausedu lien USES dela machineButton à la machineLift .

3 Principes de la transformation d’UML enB

3.1 Génération desdonnéesB

LesdonnéesB sontgénéréesà partir desélémentsstructurelsauseindesdiagrammesdeclassesetdesdiagrammesd’état-transition: classe,attribut, associationetétat.

Classe.Uneclassedonnelieu àuneconstanteetunevariableB. A titre d’exemple,considéronsla classeButton, on créealorsuneconstanteB

�����������et unevariableB ����������� . La constante

��� �������modélisel’ensembledesinstancespossiblesde la classeButton ; elle est considéréecommeun sousensemblede

������� ���; rappelonsque l’ensembleB abstrait

������� ���modélisel’ensembledes

instancespossiblesdetouteslesclasses.La variable ����������� modélisel’ensembledesinstanceseffectivesdela classeButton ; parconséquent����������� estunsousensemblede

��� �������. La constante

��� �������estdéclaréeunefois pour toutedansla machineTypes tandisquela variable ����������� estdéclaréeà lafois dansla machineSystem et dansla machineabstraiteButton dérivéedela classeButton (cf. figure 6).

Attrib ut. Un attribut estmodélisécommeunevariableB définiecommeunerelationdont le domaineestla variableB modélisantla classede l’attribut et le co-domaineestun ensemblemodélisantle typede l’attribut. La relationdéfinissantla variableB d’un attribut peutêtreraffinéeen unefonction, uneinjection, une surjection,une bijection; ceci dépenddespropriétéssupplémentairesde l’attribut. Atitre d’exemple,l’attribut floor de la classeButton estmodélisépar unevariable

� ��������� !��"��# définiecommeune fonction de ���$������ vers %'& �(��) qui est un intervalle !��"��# *�#+���$�-,.�/� !��"��# ���10 modéli-santle type UML intervalle FLOOR

�ground ��� top. L’attribut dir de la classeLift estmodélisépar une

variable &32 45� ,26# définiecommeunefonctionde 782 45� vers 9;: ) � � : ��� qui estun ensembleénuméré{ ,�26#=<=>?�@2@�� �A0 , ,�2B#C<D>"�@2���� ,��EF� } modélisantle typeUML DIRECTION

�{ up, down}. Commelavariable

B d’uneclasse,la variableB pour un attribut estdéclaréedansla machineSystem et dansla machinedérivéedela classecorrespondante.Ainsi,

� ��������� !��"��# estdéclaréedansSystem etButton et &F2 4�� ,�26#estdéclaréedansSystem et Lift (cf. figure 6).

Type. Un type UML estmodéliséen généralpar un ensembleB dansla machineTypes . Si c’est untypeUML énuméré,parexemplecommele typeDIRECTION

�{ up, down}, l’ensembleB correspondant

9;: ) � � : ���HGJI ,�2B#C<D>"�@2���� �A0'KL,26#=<=>?�@2@��� ,���EF�NM estaussiénuméré.Si c’estuntypeUML générique,l’ensembleB correspondantest abstrait.En revanche,si c’est un type intervalle, les deux bornesdel’intervalle sont modéliséescommedeux constantesdansla machineTypes et le type intervalle estmodélisécommeunedéfinition danstous les composantsqui voient Types . Dansl’exempleproposé,pour modéliserle type FLOOR

�ground ��� top, on déclaredeuxconstantes!��"��# *#C���$�-, et !��"��# ���50

dansTypes etondéclaredanstouslescomposantsSystem , System ref , Basic , Lift etButton unedéfinition%3& �(��)OG GQP !��"��# *#C���$�-,R����!��"��# ���50TS (cf. figure 6).

Remarque 3 Le fait de préfixer le nom d’un attribut par le nom de classedansla modélisationen Bpermetd’éviter le conflit de nom entreles variablesB dérivéesdesattributs. Il en estde mêmepourla modélisationB desconstantesdéfiniesdansles typesénuméréset les délimiteursdansles typesintervalle.

Association. La modélisationen B desassociationsbinairesest similaire à la modélisationdesat-tributs. On créepour chaqueassociationbinaireassos entredeuxclassesClass et Class U unevariableB VXWDW��XW définiecommeunerelationentredeuxensemblesdésignéspar les variables >�7/VXWDW et >�7/VXW1WZY :VXWDW��XW�[\>"7]VXW1W_^`>�7/VXW1WZY . Dansl’exempledu systèmedecontrôled’ascenseurs,on créeunevariableB

MACHINE TypesSETS

OBJECTSaDIRECTION bdc direction upe direction downf�aSTATUS bdc statusopene statusclosedf�aLIFT STATE bc lift readye lift movemente lift visitf�aBUTTON STATE bdc button one button off f

CONSTANTSLIFT e BUTTONe floor grounde floor top

PROPERTIESLIFT g OBJECTShBUTTON g OBJECTShfloor ground ikj�hfloor top ilj�hfloor ground m floor top

END

(a) MachineTypes

MACHINE SystemSEESTypesVARIABLES

lift, Lift State, Lift dir, Lift doorStatus,button,Button State, Button floor, liftButton, ...

INVARIANTlift g LIFT hLift State i lift n LIFT STATE hLift dir i lift n DIRECTION hpoqoqobutton g BUTTON hButton State i button n BUTTON STATE hButton floor i button n FLOOR hpoqoroliftButton i lift s button ht

xxoru xx i lift vw�x1y�z u liftButton{ c xxfC|8}�~��5}�}�hliftButton���Ri button n lift ht u ooe fl }�o�u oo i lift h fl i FLOOR vw�x1y�z u liftButton{ c oof+|$� Button floor ��� { c fl f+|]}�b�5}

DEFINITIONSFLOOR bFb�u floor ground o+o ground top}

...END

(b) MachineSystem

MACHINE ButtonSEESTypesUSESLiftVARIABLES

button,Button State, Button Floor, liftButtonINVARIANT

button g BUTTON hButton State i button n BUTTON STATE hButton floor i button n FLOOR h�oqoqoliftButton i lift s button ht

xxoru xx i lift vw�x1y@z u liftButton{ c xxf+|8}�~��1}�}�hliftButton����i button n lift ht u ooe fl }�oru oo i lift h fl i FLOOR vw�x1y@z u liftButton{ c oofC|$� Button floor ��� { c fl fC|8}�b�1}

DEFINITIONSFLOOR bFb�u floor ground o+o ground top}

...END

(c) MachineButton

MACHINE LiftSEESTypesVARIABLES

lift, Lift State, Lift Dir, ...INVARIANT

lift g LIFT hLift State i lift n LIFT STATE hLift dir i lift n DIRECTION hpoqoqo

DEFINITIONSFLOOR bFb�u floor ground o+o ground top}

...END

(d) MachineLift

FI G. 6 – ModélisationenB desconceptsstructurelsd’UML

7�2 4�� � ��������� définiecommeune relationentre 7�2 4�� et ����������� . L’inverse 782 4�� � �$���������� de 782 4�� � ��������� estdéfiniecommeunefonctionde ����������� vers 7�2 4�� (cf. cardinalitédel’associationdansla figure 1).

La variableB d’une associationestdéclaréedansla machineSystem et dansla machineB de basedanslaquellel’associationestmodélisée; dansl’exemple,il s’agit de la machineButton qui déclarelavariableB 782 4�� � ��������� modélisantl’associationentrelesdeuxclassesLift et Button (cf. figure 6).

Remarque 4 (invariants suppl ementaires) En plus de l’invariant généralci-dessus,les invariantsaddi-tionnelssur les variablesB dérivéesdesclasses,attributs et associationsviennentdescontraintessup-plémentairessurceséléments.A titre d’exemple,le fait quechaquepaireétageetascenseuraexactementdeuxboutonsestexpriméparunecontraintesurl’associationliftButton. Cettecontraintedoit êtreajoutéeà l’invariantdesmachinesSystem et Button (cf. figure 6).

Etat. Chaquediagrammed’état-transitiondonnelieu à un ensembleet unevariableB. L’ensembleBmodélisel’ensembledesétatsdu diagrammeet la variableB modélisel’état desobjetsde la classeassociéeau diagramme.A titre d’exemple,pour le diagrammed’état-transitionde la classeButton, oncréedansla machineTypes , un ensembleénuméré

����������� �3��� ����G�I ����������� ��NK6���$������ �+��Met unevariable

� �$������ � ��V��< danslesdeuxmachinesSystem et Button . La variable� ��������� � ��V��< est

définiecommeunefonctiontotaledel’ensemble����������� vers����������� �3��� ���

.

Remarque 5 SelonMeyer [13], la modélisationdessousétatsestréaliséedela mêmemanièrequecelledesétats.

3.2 Génération desopérationsB

ÉtantdonnéeunespécificationUML composéed’un ensemblede diagrammesde classeset d’état-transitionpour chacunedesclasses,les opérationsB sontdérivéesà partir desévénements,desopé-rationsUML au seindesclasses(appeléeslors de la spécificationdesactions),destransitionset de lacommunicationasynchroneéventuelleentrelesdiagrammesd’état-transition.

Transition. UnetransitionestdérivéeformellementenB paruneopérationabstraitedontle rôleestderéaliserle changementd’état.Le nomdel’opérationB modélisantunetransitionestpréfixépar le nomde la classeenquestion; cetteopérationestparamétréeparun argumentqui modélisel’objet cible del’événementdéclenchantla transition.Elle estdéclaréedansla machineB dérivéedela classeassociéeaudiagrammed’état-transitionenquestion.

La figure 7 montrel’opérationB &32 45� �@#CV���W��T26W12@� ) <DV�,�� qui modélisela transitiondel’état visit àl’étatready dansle diagrammed’état-transitionde la classeLift. Cetteopérationestdansla machineLift . Leparamètre7B7 de &F2 4�� �@#CV���W$��26W12@� ) <=V�,� modélisel’objet dela classeLift surlequella transitionseproduit.La variable&F2 4�� � ��V��< modéliselesétatsdesobjetsdela classeLift ; &32 4�� � ��V��< P 767�S modéliseainsil’étatcourantdel’objet cibledela transition.La préconditiondel’opérationvérifie le fait quel’objet cibleestparmilesinstanceseffectivesdela classeLift et l’état decetobjetestbienvisit. Le corpsdela substitutionpreestuneaffectationpourmettreà jour l’état de &32 45� � ��V���< P 7B7@S .Action. La dérivationB courantedesactionstraiteseulementle casoù uneactionestun appeld’opé-ration UML de base.Dansce cas,uneactionestmodéliséepar un appelà l’opérationB modélisantl’opérationUML correspondante.Les opérationsUML pour les actionssontmodéliséesdansla ma-chinedérivéedesclasses.Dansla figure 7, l’opération &32 45� >"7]�XW"<D9��"��# de la machineLift correspondàl’action desortiecloseDoor del’état visit.

Événement. Chaqueévénementestmodélisépar deuxopérationsB : uneopérationabstraitedanslamachineSystem etsonraffinementdansle composantderaffinementSystem ref . Le nomdesopérationsB estpréfixépar le nom de la classeen question.Les opérationsB sontparamétréespar l’objet cibledel’événementainsiquepardesparamètreséventuelsdel’événement.L’opérationabstraitespécifieles

MACHINE Lift...OPERATIONS

Lift transVisitReady(ll)=pre

ll i lift h Lift State(ll) b lift visitthen

Lift State(ll) � b lift readyend;Lift closeDoor(ll)=pre

ll i liftthen

Lift doorStatus(ll):= statusclosedend;

...END

FI G. 7 – ModélisationenB destransitions

effets souhaitésde l’événementdirectementsur les donnéesmodélisées.L’opérationB de raffinementfait appelauxopérationsB abstraitesmodélisantlestransitionset lesopérationsB abstraitesmodélisantles opérationsUML desactions.Ceci explique pourquoila machineBasic , qui inclut les machinesdeclasses,estinclusedansle raffinementSystem ref . La figure 8 montrel’opérationB abstraiteet l’opéra-tion B deraffinementpourl’événementclose. A noterégalementquesi l’opérationB deraffinementpeutêtredérivéeà partir desdiagrammesd’état-transition,l’opérationB abstraiteestconstruiteà partir descontraintesassociéesà l’événemententantqu’opérationdéclaréeauseind’uneclasse.Dansla versionactuelled’ArgoUML+B, commeon utilise lesnotationsB pourécrirelescontraintes,il suffit decopierlescontraintesd’un événementdansl’opérationB abstraitepourl’événement.

MACHINE SystemSEESTypes...VARIABLES

lift, Lift State, Lift doorStatus,..., button,......OPERATIONS

Lift close(ll)=pre ll i lift then

selectLift State(ll) b lift visit thenLift doorStatus(ll) � b statusclosed �Lift State(ll) � b lift ready

elseskip endend;

...END

(a) OpérationB abstraitepourclose

REFINEMENT SystemrefREFINES SystemSEESTypesINCLUDES BasicOPERATIONS

Lift close(ll) bbegin

/ � lesdonnéesdansla machineBasicsont � // � visiblesdansle raffinement� /if Lift State(ll) b lift visit then

Lift closeDoor(ll);Lift transVisitReady(ll)

elseskip endend;

...END

(b) OpérationB deraffinementpourclose

FI G. 8 – ModélisationenB desévénements

Communication. L’événementqui provoqueun messagesynchroned’un diagrammed’état-transitionà un autreet l’événementrésultatde cettecommunicationsontdépendants.C’est-à-direquela récep-

tion de l’événementrésultatest immédiatementsuivie par le traitement.Il estainsi tout à fait natureldeconsidérerquel’effet del’événementqui initie la communicationsynchrone,inclut l’effet del’évé-nementrésultat.Nousproposonsdenepasmodéliserl’événementrésultat.Dansl’exemple,il s’agit del’événementarrive dansle diagrammed’état-transitionLift qui provoquedeuxévénementsrelease dansunmessagesynchroneàdeuxobjetsButton. Onincorporeainsileseffetsdecesdeuxévénementsrelease

danslesopérationsB del’événementarrive (cf. figure 9(a) et figure 9(b)).

MACHINE SystemSEESTypes...OPERATIONS

Lift arrive(ll,fl) =pre

ll i lift h fl i FLOORthen

selectLift State(ll) b lift movementhfl b Lift curDestFloor(ll)

then/ � effetsdel’événementarrive � /Lift State(ll) � b lift visit �Lift doorStatus(ll) � b statusopen �/ � effetsdedeuxévénementsrelease� /any b1,b2where

b1 i button h b2 i button h{b1,b2} b

liftButton��� { c ll f+|�� Button floor ��� { c fl f+|then

Button State � bButton State � � �c b1 �n button off e b2 �n button off f

endelseskip end

end;...END

(a)OpérationB abstraite

REFINEMENT SystemrefREFINES SystemSEESTypes...OPERATIONS

Lift arrive(ll,fl) =var z@� in

dfl   Lift getCurDestFloor(ll)aif Lift State(ll) b lift movementh

fl b dflthen

Lify transMovementVisit(ll);Lift openDoor(ll);var b1,b2 in

b1,b2   getButtons(ll,fl);if Button State(b1) b button on then

Button transOnOff(b1)end;if Button State(b2) b button on then

Button transOnOff(b2)end

endelseskip endend

end;...END

(b) OpérationB deraffinement

FI G. 9 – LesopérationsB dearrive

Remarque 6 (a propos de la diffusion d’un evenement a plusieur s objets) Dansla versionactuelled’Ar-goUML+B, les deux opérationsB pour arrive doivent êtrespécifiéesdansles contraintesassociéesàl’opérationarrive en tantqu’opérationde la classeLift. La raisonestquel’on ne peutpasdériver auto-matiquementlescodesspécifiantl’effet desévénementsrésultatdansle casoù l’événementestdiffuséàplusieursobjetscommec’estle casavecl’événementarrive.

Dansla communicationasynchrone,l’événementqui provoqueun messageasynchroneet l’événe-mentrésultatsontindépendants.Lorsquele messageestenvoyé, l’événementrésultatestenregistrémaisle traitementdecetévénementpeutêtredifféré.Nousproposonsd’utiliser le mécanismede“boîte auxlettres”poursimulerla communicationasynchrone.Pourchaquetypedemessagesasynchrones,unefiled’événementscorrespondanteestcréée.Dansle systèmedecontrôled’ascenseurs,il s’agit de l’événe-mentcall survenulorsd’un messageasynchroneenvoyé parl’événementpress. Le file d’événementscall

estmodéliséeparunevariableB >DV�7B7 ¡¢�L<��L< (cf. la figure 10) dansla machineSystem . L’envoi demes-sagesasynchrones>DV�7B7 estmodélisépar l’écriture d’un élémentdansla file d’événements>DV�7B7 ¡¢�£<��L<

auseinde l’opération� �$������ 0-#C<�WDW . Parcequel’opération

� ��������� 0-#=<5W1W doit êtreraffinée,il fautdé-clarer >1V�7B7 ¡¢�L<��£< dansla machineBasic . Uneopérationauxiliaire 2B��W�<�#5� V767 P �/�/��S aétéintroduitedansBasic , carcetteopérationestappeléelorsdu raffinementde

� �$������ 0-#C<�WDW .

MACHINE SystemSEESTypesVARIABLES

lift,button,...,callQueueINVARIANT

... hcall Queue g lift ¤ FLOOR

OPERATIONSButton press(bt)=pre

bt i buttonthen

selectButton State(bt) b button off then/ � leseffetsdepress � /Button State(bt) � b button on �/ � envoyer call � /call Queue � b

call Queue¥�c liftButton(bt)}L�n Button floor(bt)felseskip end

end;...END

REFINEMENT SystemrefSEESTypesINCLUDES BasicOPERATIONS

Button press(bt) bvar ¦]¦ in

ll  ¨§�©�ª�«£¬ ­�ª�u�®Zª@}�aif button State(bt)=button off then

button transOffOn(bt);insert Call(ll,button floor(bt));

elseskip endend

end;...END

FI G. 10 – LesopérationsB pour l’événementpress

Contrairementà l’événementrelease, l’événementrésultatcall doit êtremodélisépar les opérationsB. La figure 11 présentel’opérationB abstraite>1V�7B7 . On peutnoter la présencedessubstitutionspourenlever un élémentde >1V�767 ¡¢�L<��L< . On omet ici l’opérationde raffinement >DV767 danslaquelleon faitappelà l’opération #C<�¯°��±�< V767 , qui estuneopérationauxiliaireintroduitedansla machineBasic .

4 Conclusion

La traductiond’UML enB afait l’objet denombreuxtravauxetdeuxoutilsd’aideàla transformationd’UML enB ontétédéveloppés.

– U2B[17] estdéveloppéparColin FrankSnooketMichaelButlerà l’universitédeSouthamptondansle cadredu projeteuropéenMatissepour renforcerl’applicationdesméthodesformellesdansl’in-dustrie.U2B estunfichierscriptdeRationalRosepermettantdeconvertir enB le modèlecourantde

MACHINE System...OPERATIONS

lift call(ll,fl) =pre

ll i lift h fl i FLOOR hll �n fl i call Queue

thenselectlift State(ll) b lift ready h fl ² lift curDestFloor(ll) then

/ � spécifierleseffetsdecall surlesdonnéesconcernées.� /...

when lift State(ll) b lift ready h fl b lift curDestFloor(ll) then/ � spécifierleseffetsdecall surlesdonnéesconcernées.� /...

when lift State(ll) b lift ready h fl ³ lift curDestFloor(ll) then/ � spécifierleseffetsdecall surlesdonnéesconcernées.� /...

elseskip end �/ � supprimercall dela file call Queue. � /call Queue � b call Queue �´c ll �n fl f

end;...END

FI G. 11 – L’opération B abstraite w�x ¦]¦

RationalRosecomposédesdiagrammesdeclasseset d’état-transition.L’outil estécrit en"rationalrosescriptinglanguage"etconfigurécommeunmenudansRose.Celapeutêtreconsidérécommeunpoint fort deU2B afin d’interfacerla méthodeformelleB avecl’outil Rosequi estlargementutiliséenpratique.Lesschémasdetransformationd’UML enB sontinspirésd’unepartiedenosschémasde transformationdécritsdans[14, 13]. La communicationentreles diagrammesd’état-transitionn’a pasétéconsidérée.La modélisationdesévénementsnepermetpasdeséquencementdesactionsassociéesàunetransitiondéclenchéeparlesévénements.Deplus,departleslimitationsdu langagescriptdeRosepouraccéderaux informationsdesmodèlesUML, la perspective pourétendreU2BpourlesautresdiagrammesUML nesemblepasévidente.

– L’outil du CNAM. LaleauetMammar[7, 6] auCNAM (Paris)proposentunkit d’outils pourdériverun modèleUML de Roseen un programmeSQL en passantpar une spécificationB. Le kit secomposedetroiscomposants: le premiercomposantextrait lesinformationsdumodèleUML Rose.CecomposantestécritenlangagescriptdeRose; la sortiedececomposantestl’entréedudeuxièmecomposantécrit enOCAML pourgénérerla spécificationB, qui estensuiteraffinéeparle troisièmecomposantpourdériverfinalementunprogrammeSQL.Lesschémasdetransformationsd’UML enB ontétéproposésdansle travail dethèsedeHongPhuongNguyen[15] semblablesàunepartiedenosschémasdetransformation[14, 13]. Le modèleUML considérésecomposeprincipalementdesdiagrammesdeclasseset d’état-transition.LesdéfautsdeformalisationenB desévénementsainsiquela communicationentrelesdiagrammesd’état-transitiondanslesschémasdetransformationdeHongPhuongNguyennesontpasrésolus.

Nousn’avonspasimplanténosschémasde transformationen RationalRoseà causede seslimita-tions. ArgoUML en tant queplate-formepour développerles diagrammesUML paraitun bon choixcar soncodeen java estdisponible.Il estpossibled’accéderau coded’ArgoUML pour faire évoluerles fonctionnalitésde l’outil ainsi quepour accéderaux informationsdesdiagrammesd’UML édités.Dansla versionactuelled’ArgoUML, nousavonsimplanténosschémasde transformationd’UML enB pour les diagrammesde classeset d’état-transition[14, 13, 11] ; par rapportaux schémasde trans-formationimplantésdanslesdeuxoutils ci-dessus,nousn’imposonspasdecontraintesspécialespourles diagrammesde classeset d’état-transition.L’intégrationdesdiagrammesde collaborationdansla

transformationd’UML enB [10] estpossibleetencoursd’implantation.L’implantationdesschémasdetransformationd’OCL enB [12] estégalementconsidérée.

Références

[1] J.R.Abrial. TheB Book- AssigningProgramsto Meanings. CambridgeUniversityPress,1996. ISBN 0-521-49619-5.[2] P. Behm,P. Desforges,andJ.-M. Meynadier. MÉTÉOR: An IndustrialSuccessin Formal Development,April 1998.

An invited talk at the2ndInt. B conference,LNCS 1939.[3] S. Dupuy. Couplage de notationssemi-formelleset formellespour la spécificationdessystèmesd’information. PhD

thesis,UniversitéJosephFourier- Grenoble1, Grenoble(F), septembre2000.[4] R.B. France,J.M. Bruel, M. Larrondo-Petrie,andE. Grant. RigorousObject-OrientedModeling: IntegratingFormal

andInformal Notations.In 6th InternationalAMASTConference, LNCS 1349,Sydney (A), December1997.Springer-Verlag.

[5] H. Habrias,editor. Putting Into PracticeMethodsandTools for InformationSystemDesign- 1stConferenceon theBMethod, Nantes(F), November1996.

[6] R. LaleauandA. Mammar. A GenericProcessto Refinea B Specificationinto a RelationalDatabaseImplementation.In ZB 2000: Formal Specificationand Developmentin Z and B, LNCS 1878,York (UK), August/September2000.Springer-Verlag.

[7] R. LaleauandA. Mammar. An Overview of a Methodandits supportTool for GeneratingB Specificationsfrom UMLNotations.In The15stIEEE Int. Conf. on AutomatedSoftware Engineering, Grenoble(F), September11-15,2000.

[8] K. Lano. TheB Language and Method: A Guideto Practical Formal Development. FACIT. Springer-Verlag,1996.ISBN 3-540-76033-4.

[9] H. LedangandJ. Souquières.FormalizingUML Behavioral Diagramswith B. In the TenthOOPSLAWorkshoponBehavioral Semantics:Back to Basics, pages162–171,TampaBay, Florida (USA), October15, 2001.NotheasternUniversityPress.http://www.loria.fr/ µ ledang/publications/oopsla01.ps.gz.

[10] H. Ledang and J. Souquières. Modeling Class Operations in B: Application to UML Behavioural Dia-grams. In ASE2001: the 16th IEEE International Conference on Automated Software Engineering, pages289–296, Loews Coronado Bay, San Diego (USA), November 26-29, 2001. IEEE Computer Society.http://www.loria.fr/ µ ledang/publications/ase01.ps.gz.

[11] H. LedangandJ. Souquières.Contributionsfor Modelling UML State-Chartsin B. In IFM 2002:Third InternationalConferenceonIntegratedFormalMethods, LNCS2335,pages109–127,Turku(Fin),May15-17,2002.Springer-Verlag.http://www.loria.fr/ µ ledang/publications/ifm2002.ps.gz.

[12] H. LedangandJ. Souquières.Integrationof UML andB SpecificationTechniques:SystematicTransformationfromOCL Expressionsinto B. In APSEC2002:the9th AsiaPacificSoftware EngineeringConference, GoldCoast,Queens-land(AU), December4-6,2002.IEEEComputerSociety. http://www.loria.fr/ µ ledang/publications/apsec02.ps.gz.

[13] E. Meyer. Développementsformelspar objets:utilisation conjointedeB et d’UML. PhDthesis,LORIA - UniversitéNancy 2, Nancy (F), mars2001.

[14] E. MeyerandJ. Souquières.A systematicapproachto transformOMT diagramsto aB specification.In FM’99 : WorldCongresson Formal Methodsin theDevelopmentof ComputingSystems, LNCS 1708,Toulouse(F), September1999.Springer-Verlag.

[15] H.P. Nguyen.DérivationdespécificationsformellesB à partir despécificationssemi-formelles. PhDthesis,Conserva-toire NationaldesArts et Métiers- CEDRIC,Paris(F), décembre1998.

[16] TheObjectManagementGroup(OMG). OMG UnifiedModelingLanguage Specification, June1999.Version1.3.[17] C. Snook and M. Butler. U2B: a tool for combining UML and B. Available at

http://www.ecs.soton.ac.uk/µ cfs98r/U2Bdownloads.htm,2000.[18] E.Y. Wang,H.A. Richter, andB.H.C.Cheng.Formalizingandintegratingthedynamicmodelwithin OMT*. In ICSE’97:

19thInternationalConferenceonSoftware Engineering, Boston(USA), July1997.