An Integration for Real-Time System Validation

Transcription

1 UML and RT-LOTOS An Inegraion for Real-Time Sysem Validaion P. de Saqui-Sannes *,** L. Apvrille *,**,*** C. Lohr ** P. Sénac *,** J.-P. Couria ** * ENSICA, 1 place Emile Blouin, Toulouse Cedex 05, France {desaqui, apvrille, senac}@ensica.fr ** LAAS-CNRS, 7 avenue du Colonel Roche, Toulouse Cedex 04, France {lohr, couria}@laas.fr *** Alcael Space Indusries, 26 avenue J.-F. Champollion, B.P. 1187, Toulouse Cedex 01, France ABSTRACT. The paper presens a UML profile ha overcomes he limiaions of real-ime soluions currenly available on he marke. Associaions beween classes are given a formal semanics. New emporal operaors are inroduced; hey include a non deerminisic delay and a ime-limied offering. UML models can be validaed agains logical and iming consrains. The profile s semanics is given hrough a ranslaion ino he formal language RT-LOTOS. The laer is suppored by a validaion ool which generaes reachabiliy graphs from exended UML models. A coffee machine serves as example in he paper. The profile is under evaluaion on a saellie-based sofware reconfiguraion sysem. RÉSUMÉ. Face aux limiaions des soluions UML emps réel acuellemen sur le marché, l aricle présene un profil UML qui donne une sémanique formelle aux associaions enre classes, défini des opéraeurs emporels de ype délai non déerminise e d offre limiée dans le emps e ajoue des faciliés de validaion de conraines logiques e emporelles. La sémanique formelle de ce profil es donnée par la raducion dans le langage formel RT- LOTOS don l ouil de validaion perme de consruire des graphes d accessibilié à parir de diagrammes UML éendus. Oure l exemple de la machine à café raié dans l aricle, le profil proposé es en cours d évaluaion sur un sysème de reconfiguraion dynamique de logiciel embarqué à bord de saellie. KEYWORDS: Real-Time Sysems, Formal Mehods, UML, RT-LOTOS, Validaion. MOTS-CLÉS : Sysèmes emps réel, Méhodes formelles, UML, RT-LOTOS, Validaion.

2 1. Inroducion Wih he noion of profile 1, he OMG-based Unified Modeling Language [OMG 01] has been defined as a general purpose modeling language ha can be specialized for specific domains. Before a real-ime profile specificaion was released a OMG [OMG 02], several companies have compeed o propose proprieary Real-ime UML soluions [SEL 98, ART 99, DOU 99, EST 02]. Meanwhile, he need for an enhanced UML wih real-ime feaures has simulaed research work on inegraing UML and Formal Descripion Techniques ha had already been applied o imecriical sysems [DEL 98, CLA 00, AND 01, DUP 01]. The TURTLE 2 profile [SAQ 01] presened in he paper exends UML wih conceps borrowed from he Formal Descripion Technique RT-LOTOS 3 [COU 00]. Class diagrams are modified so ha parallelism and synchronizaion beween classes can be expressed explicily. Exended aciviy diagrams wih a non deerminisic delay and a ime-limied offering are used insead of Saechars o describe classes inernal behaviours. Class and aciviy diagrams are ranslaed ino RT-LOTOS, and he resuling specificaion is provided as inpu o he RTL 4 ool. This makes i possible o perform a priori validaion on TURTLE diagrams by checking models agains logical and iming errors. The paper is organized as follows. Secion 2 surveys relaed work. Secion 3 inroduces RT-LOTOS. Secion 4 defines he TURTLE profile. Secion 5 discusses is applicaion o a coffee machine. Secion 6 concludes he paper. 2. Relaed work Several ool manufacurers have compeed o offer real-ime UML soluions wih an enhanced noaion and a mehodology: - Rose RT implemens UML-RT, an enhanced UML wih conceps from he ROOM language [SEL 98]; - Rhapsody by I-Logix uses as much as possible naive UML 1.4 consrucs [DOU 99]; - TAU by Telelogic uses UML as a fron-end for SDL [BJO 00]; - Real-Time Sudio [ART 99] by Arisan Sofware has is own emporal operaor; - Eserel Sudio [EST 02] by Eserel-echnologies combines UML and synchronous language Eserel. 1 A UML profile specializes he UML mea-model ino a specific mea-model dedicaed o a given applicaion domain [TER 00]. A profile may conain seleced elemens of he reference mea-model, exension mechanisms, a descripion of he profile semanics, addiional noaions, and rules for model ranslaion, validaion and presenaion. 2 Timed UML and RT-LOTOS Environmen. 3 Real-Time LOTOS (Language Of Temporal Ordering of evens). 4 RT-LOTOS Laboraory.

3 The firs four ools in he lis above implemen an asynchronous paradigm. They also share in common emporal operaors limied o imers wih a fixed duraion. They miss naive operaors o express ime inerval and ime-limied acions wihin behavioural diagrams. When soluions neverheless exis, hey remain oriened owards code generaion for a specific arge and operaing sysem. A priori and implemenaion-independen validaion of UML models canno be carried ou. On he academic side, a lo of work has been done on providing UML wih a precise semanics [BRU 98, BRU 99, EVA 99] and connecing UML wih a Formal Descripion Technique, such as Labeled Transiion Sysems [JAR 98, GUE 00], Peri Nes [DEL 98], Z [DUP 01], synchronous languages [AND 01], PVS [TRA 00] and E-LOTOS [CLA 00]. Unlike [DEL 98], he profile in Secion 4 remains UML 1.4 complian in he way i inegraes conceps borrowed from he RT-LOTOS FDT. The laer is an asynchronous language, which differs from [AND 01]. Like [DUP 01], [TRA 00] and [CLA 00], he ranslaion procedure from exended UML o RT-LOTOS gives a formal semanics o he profile. Major differences beween RT-LOTOS and E-LOTOS include a non deerminisic delay operaor (see he laency operaor in Secion 3) and validaion echniques implemened by a ool. 3. RT-LOTOS LOTOS [BOL 87] is an ISO-based Formal Descripion Technique for disribued processing sysem specificaion and design. A LOTOS specificaion, iself a process, is srucured ino processes. A LOTOS process is a black box which communicaes wih is environmen hrough gaes using muliple rendezvous. Values can be exchanged a synchronizaion ime. Exchanges can be mono- or bi-direcional. Parallelism and synchronizaion beween processes are expressed by composiion operaors. The laer include process sequencing, synchronizaion on all communicaion gaes and synchronizaion on some gaes, a non deerminisic choice and inerleaving (parallel composiion wih no synchronizaion). Composiion operaors are idenified by heir symbols (Table 1). Operaor Descripion Example [] Choice. P[a,b,c,d] = P1[a,b] [] P2[c,d] Parallel composiion wih no synchronizaion. [b,c,d] Parallel composiion wih synchronizaion on several gaes (b,c,d). hide b in [b] Parallel composiion wih synchronizaion on gae b, which is hidden. P[a,b,c,d] = P1[a,b] P2[c,d] P[a,b,c,d,e] = P1[a,b,c,d] [b,c,d] P2[b,c,d,e] P[a,c] = hide b in P1[a,b] [b] P2[b,c] >> Sequenial composiion. P[a,b,c,d] = P1[a,b] >> P2[c,d] [> Disrup (P2 preemps P1). P[a,b,c,d] = P1[a,b] [> P2[c,d]

4 ; Process prefixing by acion a. a; P sop exi Table 1. LOTOS operaors Process which canno communicae wih any oher process. Process which can erminae and hen ransform iself ino sop. RT-LOTOS exends LOTOS wih hree emporal operaors (Table 2). The combinaion of a deerminisic and a non deerminisic delay makes i possible o handle ime inervals. RT-LOTOS reuses and exends he conrol par of LOTOS, bu replaces algebraic daa ypes by implemenaions in C++ or Java [COU 00]. Temporal operaor a{} delay() laency() Table 2. RT-LOTOS emporal operaors Descripion Time limied offering. Deerminisic delay. Non deerminisic delay. 4. TURTLE profile The TURTLE profile enhances class and aciviy diagrams using he exension mechanisms allowed by UML 1.4, in paricular sereoypes 5. Thus, a TURTLE class diagram conains normal classes and classes sereoyped as Tclass. Two classes can be linked by one of he four following relaionships: use, aggregaion, composiion, and generalizaion. TURTLE class diagrams inroduce wo imporan feaures: firs, wo Tclasses can synchronize on so-called Gaes; second, associaions beween wo Tclasses can be aribued by a composiion operaor. TURTLE aciviy diagrams offer new symbols, in paricular emporal operaors inheried from RT -LOTOS ones (Table 2) Gae Absrac Type Two Tclasses can communicae using inpu and oupu Gaes. A Gae absrac ype (Fig. 1a) serves as super-ype for InGae and OuGae, respecively (Fig. 1b). Gae Gae InGae OuGae (a) (b) Figure 1. Gae absrac ype and differeniaion beween InGae and OuGae 5 A sereoype is an indirec addiion o he mea-model. The TURTLE sereoype and absrac ypes are graphically idenified by a urle symbol in he upper righ corner of he class.

5 In he paper, we say ha a Tclass performs an acion on Gae g o express ha he Tclass wans o communicae on Gae g Tclass Sereoype A Tclass sereoype is a UML class wih wo basic consrains: Gaes are separaed from oher aribues, and he behaviour descripion mus be an aciviy diagram (Fig.2). Oher properies o be saisfied by a Tclass are lised in [SAQ 01]. Tclass Id Aribues Gaes Operaions Behavior Descripion Tclass idenifier. Aribues excep Gae aribues. Aribues of ype Gae. They can be declared as privae, proeced, or public. Operaions, including a consrucor. Aciviy diagram which can use previously defined aribues, Gaes and operaions. Inheried aribues (including Gaes) and operaions can also be used. Figure 2. Tclass componens 4.3. Composer Absrac Type A UML class diagram graphically defines a se of classes inerconneced by relaionships, in paricular associaions. TURTLE furher makes i possible o give an associaion a precise semanics. The Composer absrac ype is inroduced o suppor ha idea. Noe ha Composer is no used direcly; associaions are aribued wih so-called associaive classes (Parallel, Synchro, Invocaion, Sequence, Preempion) ha inheri from Composer. Two inheried classes of Composer are presened in Fig. 3. Parallel Composiion operaor Sequence Associaion P1 P2 P1 P2 Figure 3. Use of wo inheried classes of he Composer absrac ype

6 For each associaion beween wo Tclasses, here exiss one and only one meaning, and herefore one Composer. Le us now review he classes which inheri from Composer. Parallel Two Tclasses relaed by an associaion assigned by he Parallel operaor are execued in parallel, and wihou any synchronizaion. The wo Tclasses should be acive 6 classes. Synchro Two Tclasses relaed by an associaion aribued by he Synchro operaor can synchronize wih each oher. This synchronizaion is execued by he wo Tclasses in wo separae execuion hreads. A synchronizaion possibly includes a daa exchange; inpus and oupus are deailed in he respecive behaviour descripions of he wo classes involved in he synchronizaion. If he associaion beween he wo Tclasses includes a navigaion indicaion, he daa exchange can only ake place in he direcion indicaed by he navigaion. Two Tclasses may synchronize on differen Gaes ha mus be lised in an OCL (Objec Consrain Language) formula. For example, suppose ha Gaes g1 and g2 of Tclass T1 synchronize respecively wih Gaes g3 and g4 of Tclass T2; in ha case, he OCL formula associaed wih he associaion should be {T1.g1 = T2.g3 and T1.g2 = T2.g4}. Each ime T1 performs an acion on g1, i mus wai for T2 o perform an acion on g3, and vice versa. Invocaion Whereas he Synchro operaor denoes a synchronizaion beween wo separae execuion flows, Invocaion denoes a synchronizaion which, like an operaion call in he objec paradigm, is performed wihin he caller s execuion flow. Le us consider wo Tclasses T1 and T2 linked by an associaion direced from T1 o T2 and aribued by he Invocaion associaive class. T2 can be acivaed by T1. Boh T1 and T2 mus have a Gae involved in he invocaion. For example, le us consider ha g1 (resp. g2) is a T1 (resp. T2) Gae and ha he {T1.g1 = T2.g2} OCL formula is added o he associaion. Then, when T1 performs an acion on g1, i mus wai for T2 o perform an acion on g2. When T2 performs an acion on g2, daa can only be exchanged as indicaed by he navigaion. T1 is hen blocked on g1 unil T2 performs again an acion on g2. The second daa exchange can only be performed from he callee o he caller. Sequence Two Tclasses relaed by an associaion o which his operaor is associaed are riggered one afer he oher in he associaion s navigaion direcion. Noe ha in (T1 Sequence T2), T1 mus erminae 7 before T2 sars. The wo Tclasses should be acive classes. 6 A class is acive if i represens an execuion flow of he sysem [DOU 99]. 7 A Tclass erminaes when all is aciviies have reached heir erminaion poins.

7 Preempion A Tclass poined by he navigaion of an associaion aribued by he Preempion operaor may inerrup he oher Tclass a any ime. In pracice, T2 Preempion T1 means ha T2 may preemp T1, i.e. i kills T1 and acivaes T Tclass Behavior Descripion UML aciviy diagrams symbols are suppored, bu operaion calls are no ranslaed o RT-LOTOS, assuming ha wo Tclasses use gae synchronizaion o communicae. Table 3 liss all he symbols, and associaes he relevan ranslaions in RT-LOTOS; (AD) denoes he ranslaion process for he sub-diagram AD which follows he symbol. TURTLE aciviy diagram AD AD1 AD AD Descripion Beginning of he aciviy diagram. Therefore, beginning of he ranslaion. g!x?y Synchronizaion on Gae g, possibly wih emission of value and/or recepion. AD is subsequenly inerpreed. y := x*2 Value assignmen of an aribue. AD is subsequenly AD inerpreed. Loop srucure. AD is or inerpreed each ime he loop AD is enered. AD2 ADn [g1,, gm] [c1] [c2] [cn] AD1 AD2 ADn Condiions are opional Synchronizaion on Gaes g1, gm beween n subaciviies described by AD1, AD2,, ADn. The gae lis is possibly empy. AD1, AD2,, ADn subaciviies for which condiions are rue can be seleced. One ready-o-execue aciviy whose condiion is rue is execued. LOTOS ranslaion [LOH 02] τ(ad) g!x?y:na ; τ(ad) le y : YType = x*2 in τ(ad) process LabelX[g1, gn] : noexi := τ(ad) >>LabelX[g1,...gn] end proc τ(ad1) [g1, gm] τ(ad2) [g1, gm] [g1, gm] τ(adn) [c1] -> τ(ad1) [] [c2] -> τ(ad2) [] [] [cn] -> τ(adn)

8 AD1 AD2.. ADn AD 1 AD 2 AD m [g1, gk] The n sub-aciviies described by AD1, AD2,..., ADn are followed by he execuion of he m sub-aciviies described by AD 1, AD 2,..., AD m. The AD i are execued wih synchronizaion on k Gaes g1, g2,..., gk. Terminaion of an aciviy. (τ(ad1) τ(ad2) τ(adn) ) >> (τ(ad 1) [g1, gk] τ(ad 2) [g1, gk] τ(ad m) ) exi Table 3. Non emporal TURTLE operaors Table 4 liss picograms associaed wih he emporal operaors which exend UML aciviy diagrams. The hird operaor applies o a ime inerval. I is equivalen o wo operaors pu in sequence: firs, a fixed duraion delay equal o he inerval s lower bound, and second, a laency equal o he difference beween he inerval s upper and lower bounds. TURTLE operaor Descripion RT-LOTOS ranslaion d AD Deerminisic delay. AD is inerpreed afer d ime unis. delay(d) τ(ad) AD dmin dmax - dmin AD l a AD1 AD2 Non deerminisic delay. AD is inerpreed a mos afer ime unis. Non deerminisic delay beween dmin and dmax. AD is inerpreed a leas afer dmin and a mos afer dmax ime unis. Time -limied offering. Acion a is offered during a period which is less or equal o. Noe ha laency and ime -limied offering sar a he same ime. If he offer happens, AD1 is inerpreed. Oherwise, AD2 is inerpreed. laency() τ(ad) delay(dmin,dmax) τ(ad) laency(l) a{, τ(ad2)}; τ(ad1) Table 4. TURTLE emporal operaors

9 4.5. Validaion Process The TURTLE profile has been developed o validae real-ime sysem models agains design errors, and iming inconsisencies in paricular. Figure 4 depics he validaion process. TURTLE classes and heir relaionships are exraced from he class diagram, saved under an XMI file, and convered ino RT-LOTOS code which is validaed using he RTL ool. Sysems of reasonable size can be checked using reachabiliy analysis echniques [COU 00]. Oherwise, simulaion is limied o a parial exploraion of he sysem s behaviour. Transparen o UML users TURTLE modeling wih a UML 1.4 ool xmi file xmi2rloos RT-LOTOS file RTL reachabiliy graph Figure 4. From a TURTLE model o validaion 5. Applicaion: a coffee machine The purpose of his secion is o illusrae he TURTLE synax, and o demonsrae he ineres of using he RTL ool o discover logical errors and ime consrains violaions. The TURTLE diagram in Fig.5 models a coffee machine which disribues ea or coffee afer wo coins have been insered by a user. The user has a walle, no described for space reasons. One can noice he inheriance relaion beween Coffee Machine and CoinBox as well as he synchronizaions beween CoffeeMachine and Walle or Buon, respecively. Le us now commen on emporal operaors used in Fig.5. The role of ime limied offering coindelay in CoffeMachine is o guaranee ha a user who wais oo much before insering a second coin will ge he firs one back. Similarly, buondelay manages he siuaion where a user wais oo much before selecing a drink. The deerminisic delay delay in Buon represens a buon s response ime. Join use of deerminisic and non deerminisic delays makes i possible o represen coffee and ea preparaion imes as emporal inervals: [100, ] and [120, ], respecively. Le us now pay aenion o synchronizaions acive1 and acive2 in CoffeeMachine and ime limied offering in Buon. Boh conribue o solve a problem idenified in a simpler model [SAQ 01] of he coffee machine. Le us assume he user insers wo coins and wais oo long. The synchronizaion offer on ea or coffee expires, which means ha boh coins are ejeced. The user pushes he buon ea (Buon class, push Gae) jus aferwards. The synchronizaion offer can no longer ake place. The user akes his coins back, hinking he machine is ou of

10 order. A user wishing o have a coffee arrives and insers wo coins. As he synchronizaion offer on ea has no expired (unlimied offer), he or she is insanly served a ea. The problem is solved as follows: synchronizaion on acive1 and acive2 enables he machine o acivae he wo buons for a limied period of ime (push offer limied o 40). Once he wo buons are acivaed, i sill akes 50 ms (delay = 50) before he machine can synchronize on coffee or ea. CoinBox # coindelay, maxcoin : in # coin_in : InGae ; # ejec_coin : OuGae CoffeeMachine - buondelay : na + ea, coffee : InGae # coinnb() Walle Buon - delay : na + push, acive : Gae acive push 40 delay 2 Synchro {Walle.puCoin = CoffeeMachine.coin_in and Walle.coinBack = coffeemachine.ejeccoin } Synchro { (CoffeeMachine.coffee = Buon.push and CoffeeMachine.acive1 = Buon.acive) or (CoffeeMachine.ea = Buon.push and CoffeeMachine.acive2 = Buon.acive) } coin_in?1 coindelay coin_in?1 acive1 ejeccoin!1 acive2 50 coffee ea buondelay ejeccoin!2 Figure 5. TURTLE class diagram for a coffee machine Logical and iming errors have been found using he RTL ool. For space reasons, Fig.6 depics he reachabiliy graph obained for a machine limied o disribuing ea. For each logical sae (recangle), several classes of emporal saes (circles) may coexis. Condiions for leaving a sae are as follows: eiher ime has elapsed (ransiion ) or a synchronizaion has occurred. Le us ake examples from he reachabiliy graph in Fig.6a. Moving from he iniial sae (sae 0) demands synchronizaion on Gae pucoin. In sae 21, no synchronizaion can occur in he firs wo sub-saes; a sae change corresponds o a ime progression exclusively (ransiion ). When he offer on Gae ea expires (delay buondelay), hen, a synchronizaion on coinback makes i possible o move from Sae 21 o Sae 7; a value equal o wo is exchanged a ha occasion. The graph in Fig. 6.a highlighs ha i is impossible for a user o ge eiher ea or coffee. In fac, he buon acivaion delay (push) expires before he machine is ready o deliver coffee or ea. If his delay is increased from 40 o 60 (Fig. 6.b), i becomes possible o ge ea: he ransiion from sae 21 is now ea.

11 0 - () i(pucoin<1> 1 - (0) 13- (150) i(pucoin<1> 17- (0 0) (a) 2 - () i(acive) 21-(0 0) 17- ( ) 17-( ) i(pucoin<1> 12- (150 0) 21- ( ) i(coinback<2>) i(pucoin<1> 21- ( ) Rejeced coins i(coinback<2>) 7 - (150) (b) 0 -() i(pucoin<1> 1 - (0) i(acive) 21-(0 0) 21- (50 50) i(acive) 24- (50) 24-(100) i(pucoin<1> 2 -() Tea is now offered i(ea) 22- (0 0) 22- (50 50) 22-( ) i(pucoin<1> i(pucoin<1> i(pucoin<1> 23- (50 0) 23- (100 0) i(pucoin<1> Figure 6. Reachabiliy Graph for he coffee machine. (a): case where he offer on he buon is limied o 40. (b): case where he offer is limied o Conclusions and Fuure Work The paper defines TURTLE, a UML profile for real-ime sysem design and validaion. Class diagrams are exended wih a sereoype (Tclass) and wo absrac ypes (Gae and Composer). A precise semanics is given o associaions beween classes (see he Parallel, Synchro, Invocaion, Sequence and Preempion classes). The behaviour of a Tclass is described by an enhanced aciviy diagram wih hree emporal operaors: a deerminisic delay, a non deerminisic delay and a imelimied offering. Las bu no leas, TURTLE models can be ranslaed ino RT- LOTOS, a formal descripion echnique suppored by a validaion ool. RT-LOTOS specificaions derived from TURTLE diagrams can be validaed using reachabiliy analysis echniques. The objecive is o keep RT-LOTOS hidden o he sysem designer.

12 The TURTLE profile is under evaluaion on real-ime embedded sofware. In paricular, i is used for he formal validaion of dynamic reconfiguraion of embedded sofware [APV 01]. The TURTLE profile will be exended in he near fuure. Sae machines will be used in lieu of aciviy diagrams. New associaive classes will be inroduced o exend associaion semanics (resume/suspend, inerrup) [HER 98]. Our inen is o perform schedulabiliy analysis on TURTLE models [AND 97]. Finally, relaionships beween he TURTLE profile and he OMG one [OMG 02] are under sudy. 7. References [AND 01] ANDRE C., "Paradigmes objes e synchrones dans les sysèmes emps-réel", journée Objes Temps Réel du Club SEE Sysèmes Informaiques de Confiance, Paris, 18 janvier hp:// [AND 97] ANDRIANTSIFERANA L., COURTIAT J.-P., DE OLIVEIRA R.C., PICCI L., "An experimen in using RT-LOTOS for he formal specificaion and verificaion of a disribued scheduling algorihm in a nuclear power plan monioring sysem", Proceedings IFIP Formal Descripion Techniques X, Osaka, Japan, November 97, Chapman & Hall (1997) [APV 01] APVRILLE L., de SAQUI-SANNES P., SÉNAC P., DIAZ M., "Formal Modeling of Space- Based Sofware in he Conex of Dynamic Reconfiguraion", Proceedings of DAa Sysems In Aerospace (DASIA), 28 May - 1s June, Nice, France, [ART 99] Arisan Sofware Tools, hp:// [BJO 00] BJORKANDER M., "Real-Time Sysems in UML and SDL", Embedded Sysem Engineering, Ocober/November 2000 (hp:// [BOL 87] BOLOGNESI T., BRINKSMA E., "Inroducion o he ISO specificaion Language LOTOS", Compuer Neworks and ISDN Sysems, Vol 14, No1, [BRU 98] BRUEL, J.-M. FRANCE R.B., "Transforming UML Models o Formal Specificaions", Proceedings of he Conference on Objec Oriened Programming Sysems Language and Applicaions OOPSLA'98, Vancouver, Canada, [BRU 99] BRUEL J.-M., "Inegraing Formal and Informal Specificaion Techniques. Why? How? ", Proceedings of he IEEE Workshop on Indusrial-Srengh Formal Specificaion Techniques WIFT'98, Boca Raon, Florida, USA, IEEE Compuer Press, [CLA 00] CLARCK, R.G., MOREIRA, A.M.D., "Use of E-LOTOS in Adding Formaliy o UML", Journal of Universal Compuer Science, Vol.6, No 11, p , [COU 00] COURTIAT J.-P., SANTOS C.A.S., LOHR C., OUTTAJ B., Experience wih RT- LOTOS, a Temporal Exension of he LOTOS Formal Descripion Technique, Compuer Communicaions, Vol. 23, No. 12, p , [DEL 98] DELATOUR J., PALUDETTO M., "UML/PNO, a way o merge UML and Peri ne objecs for he analysis of real-ime sysems", Proceedings of he workshop on Objec- Oriened Technology and Real Time Sysems ECOOP'98, Brussels, Belgium, [DOU 99] DOUGLASS B.P., Doing Hard Time: Developing Real-Time Sysems wih UML, Objecs, Frameworks and Paerns, Addison-Wesley Longman, 1999 (hp://

13 [DUP 00] DUPUY S., LEDRU Y., CHABRE-PECCOUD M., "Vers une inégraion uile de noaions semi-formelles e formelles : une expérience en UML e Z", Techniques e Sciences Informaiques, Vol.6, No.1, p. 9-32, Hermès, Paris, [DUP 01] Dupuy S., du Bouque L., "A Muli-formalism Approach for he Validaion of UML M odels", Formal Aspecs of Compuing, No.12, p , [EST 02] Eserel Sudio, hp:// [EVA 99] EVANS A.S., COOK S., MELLOR S., WARMER J., WILLS A., "Advanced Mehods and Tools for a Precise UML", Proceedings of he 2nd Inernaional Conference on he Unified Modeling Language UML 99, Colorado, USA, LNCS 1723, [GUE 00] LE GUENNEC A., "Méhodes formelles avec UML : Modélisaion, validaion e généraion de ess", Aces du 8è Colloque Francophone sur l Ingénierie des Proocoles CFIP 2000, Toulouse, Ediions Hermès, Paris, p , ocobre [HER 98] HERNALSTEEN C., "Specificaion, Validaion and Verificaion of Real-Time Sysems in ET-LOTOS, " Ph.D. hesis, Universié Libre de Bruxelles, Belgium (1998). [LOH 02] C. Lohr, L. Apvrille, "Translaion of TURTLE diagrams ino RT-LOTOS," Inernal repor, in preparaion. [JAR 98] JARD C., JEZEQUEL J.-M., PENNANEAC H F., "Vers l uilisaion d ouils de validaion de proocoles dans UML", Technique e Science Informaiques, Vol. 17, No.9, p , Hermès, Paris, [OMG 01] "OMG Unified Modeling Language Specificaion", Version 1.4, hp:// [OMG 02] OBJECT MANAGEMENT GROUP, UML Profile for Scheduling, Performance, and Time, Draf Specificaion, fp://fp.omg.org/pub/docs/pc/ pdf. [PAL 99] HERNALSTEEN C., "Specificaion, Validaion and Verificaion of Real-Time Sysems in ET-LOTOS", Ph.D. hesis, Universié Libre de Bruxelles, Belgium, [SAQ 01] de SAQUI-SANNES P., APVRILLE L., LOHR C., SENAC P., COURTIAT J.-P., "UML e RT-LOTOS : vers une inégraion informel/formel au service de la validaion de sysèmes emps réel", Aces du Colloque Francophone sur la Modélisaion des Sysèmes Réacifs MSR 01, Toulouse, France, Ocobre [SEL 98] SELIC B., RUMBAUGH J., Using UML for Modeling Complex Real-Time Sysems, hp:// [TER 00] TERRIER, F., GÉRARD, S., "Real Time Sysem Modeling wih UML: Curren Saus and Some Prospecs", Proceedings of he 2 nd Workshop of he SDL Forum sociey on SDL and MSC, SAM 2000, Grenoble, France, [TRA 00] TRAORÉ I., "An Ouline of PVS Semanics for UML Saechars", Journal of Universal Compuer Science, Vol. 6, No. 11, p , 2000.