UML et RT-LOTOS - LAAS-CNRS

UML et RT-LOTOS
Vers une intégration informel/formel au service de la
validation de systèmes temps réel
P. de Saqui-Sannes*,** — L. Apvrille*,**,*** — C. Lohr** — P. Sénac*,**
— J.-P. Courtiat**
*
ENSICA, 1 place Emile Blouin, 31056 Toulouse Cedex 05, France
{desaqui, apvrille, senac}@ensica.fr
**
LAAS-CNRS, 7 avenue du Colonel Roche, 31077 Toulouse Cedex 04, France
{lohr, courtiat}@laas.fr
***
Alcatel Space Industries, 26 avenue J.-F. Champollion, BP 1187, 31037 Toulouse
Cedex 01, France
RÉSUMÉ. Face aux limitations des solutions UML temps réel actuellement sur le marché,
l’article propose un profil UML qui donne une sémantique formelle aux associations entre
classes, définit des opérateurs temporels de type délai non déterministe et offre limitée dans le
temps et ajoute des facilités de validation de contraintes temporelles. La sémantique formelle
de ce profil est donnée par la traduction dans le langage formel RT-LOTOS dont l’outil de
validation permet de construire des graphes d’accessibilité à partir de diagrammes UML
étendus. Outre l’exemple de la machine à café traité dans l’article, le profil proposé est en
cours d’évaluation sur un système de reconfiguration dynamique de logiciel embarqué à bord
de satellite.
ABSTRACT. The paper proposes a UML profile to overcome the limitations of real-time
solutions currently offered on the market. Associations between classes are given a formal
semantics. New temporal operators are introduced; they include a non deterministic delay
and a time-limited offering. Last but not least, UML models can be validated against time
constraints. The profile’s semantics is given via a translation to formal language RT-LOTOS.
The latter is supported by a validation tool used to generate reachability graphs from
extended UML models. A coffee machine serves as example in the paper. The profile is under
evaluation on a satellite-based software reconfiguration system.
MOTS-CLÉS :
Systèmes temps réel, Méthodes formelles, UML, RT-LOTOS, Validation.
KEY WORDS:
Real-Time Systems, Formal Methods, UML, RT-LOTOS, Validation.
1. Introduction
Le langage de modélisation UML [OMG 99a] a suscité un intérêt croissant
auprès des industriels qui développent des systèmes temps réel. A côté des solutions
« UML temps réel » supportées par quelques grandes sociétés [ART 99, DOU 99,
SEL 98], UML temps réel a également fourni une thématique de recherche sur
l’intégration d’UML et des Techniques de Description Formelle [AND 01][DUP
01][DEL 98]. Une TDF a une sémantique formelle, ce qui permet de mettre en
œuvre une validation a priori. Les modèles UML qui se voient dotés d’une
sémantique formelle peuvent être validés par rapport à des risques d’incohérences
logiques (interblocage par exemple) ou temporelles. D’où l’intérêt accru de la
notation UML pour la conception de systèmes temps contraints.
Cet article propose un profil UML conçu dans un objectif de validation de
systèmes temps réel. Ce profil se caractérise ainsi : primo, une sémantique formelle
est donnée aux associations entre classes ; deusio, des opérateurs temporels avec
délai non déterministe et offre limitée dans le temps sont introduits dans les
descriptions de comportement ; tertio, les classes et leurs descriptions
comportementales sont traduites en une description formelle en RT-LOTOS, algèbre
de processus temporisé supporté par un outil de validation. Un point important est
que la syntaxe RT-LOTOS demeure transparente aux utilisateurs d’UML qui
peuvent ainsi valider des classes UML sans apprendre RT-LOTOS. Le profil est
nommé TURTLE, acronyme anglais de « Timed UML and RT-Lotos Environment ».
L’article est structuré comme suit : le paragraphe 2 fait un tour d’horizon des
travaux du domaine ; le paragraphe 3 introduit RT-LOTOS ; le paragraphe 4 définit
le profil TURTLE ; le paragraphe 5 traite une étude de cas, à savoir un distributeur
de café ; le paragraphe 6 conclut l’article et esquisse les prolongements de ce travail.
2. Travaux du domaine
Forte du support de l’Object Management Group (OMG), la notation UML est
de plus en plus utilisée par les concepteurs de systèmes temps réel. Dans les faits, ce
n’est pas un, mais plusieurs UMLs temps réel qui sont en compétition pour répondre
aux exigences du Request For Proposal [OMG 99b] de l’OMG.
— UML-RT est supporté par Rose RT et inclut dans UML des concepts
importés de ROOM [SEL 98] ;
— RT-UML est supporté par Rhapsody et utilise autant que possible les
constructions natives d’UML 1.3 [DOU 99] ;
— UML en amont de SDL est proposé par Telelogic (outil TAU [BJO 00] );
— Artisan Software Real-Time Studio [ART 99].
Au delà de leurs différences, les solutions implantées par ces outils industriels
présentent des limitations importantes en termes d’expression de contraintes
temporelles. Ainsi, les opérateurs temporels sont limités à des temporisateurs à
durée fixe. L’absence d’opérateurs pour gérer des intervalles rend impossible la
description de la gigue et plus généralement de l’asynchronisme inhérent aux
systèmes multimédia en réseaux [SEN 96]. Enfin, il manque à UML un opérateur
apte à exprimer une offre limitée dans le temps.
Les limitations mentionnées ci-dessus ont été contournées en utilisant des
primitives systèmes dépourvues de sémantique formelle, ce qui empêche de valider
des modèles UML par la confrontation a priori à des exigences temporelles. Des
actions concertées ont vu le jour pour remédier à cette situation et donner une
sémantique précise à UML [BRU 98, BRU 99, EVA 99]. Les travaux de recherche
portent sur l’utilisation conjointe d’UML et d’une méthode formelle : Systèmes de
Transitions Etiquetés [GUE 00, JAR 98], réseaux de Petri [PAL 98], Z [DUP 00],
langages synchrones [AND 01, DUP 01], PVS [TRA 00] et E-LOTOS [CLA 00].
3. RT-LOTOS
LOTOS [BOL 87] est une Technique de Description Formelle pour la
spécification et la conception de systèmes de traitement distribués. Une spécification
LOTOS se présente sous la forme d’un processus structuré en d’autres processus.
Un processus LOTOS est une boite noire qui communique avec son environnement
au travers de portes et sur le principe d’une offre de rendez-vous. Des échanges
mono- ou bi-directionnels de valeurs sont autorisés lors de la synchronisation.
Le parallélisme et la synchronisation entre processus s’expriment par des
opérateurs de composition : mise en séquence, synchronisation sur toutes les portes,
synchronisation sur certaines portes, choix non déterministe et entrelacement
(composition parallèle sans synchronisation). Les opérateurs de composition sont
identifiés par leurs symboles (Tableau 1).
Opérateur Description
Exemple
[]
Choix.
P[a,b,c,d] = P1[a,b] []
P2[c,d]
|||
Composition parallèle sans synchro- P[a,b,c,d] = P1[a,b] |||
nisation.
P2[c,d]
|[b,c,d]|
Composition parallèle avec synchro- P[a,b,c,d,e] =
nisation sur plusieurs portes (b,c,d).
P1[a,b,c,d] |[b,c,d]|
P2[b,c,d,e]
hide b in Composition parallèle avec synchro- P[a,c] =
|[b]|
nisation sur la porte b qui est de plus hide b in P1[a,b] |[b]|
cachée.
P2[b,c]
>>
Composition séquentielle.
P[a,b,c,d] =P1[a,b] >>
P2[c,d]
[>
Préemption.
P[a,b,c,d] = P1[a,b] [>
P2[c,d]
;
Prefixage d’un processus par l’action a.
a; P
stop
Processus qui ne peut communiquer avec aucun autre processus.
exit
Processus qui peut se terminer et se transformer ensuite en stop.
Tableau 1. Opérateurs LOTOS
RT-LOTOS étend LOTOS avec trois opérateurs temporels (Tableau 2). La
combinaison d’un délai déterministe et d’un délai non déterministe permet de traiter
les intervalles temporels. Le langage ainsi étendu conserve la partie « contrôle » de
LOTOS, mais remplace les types de données algébriques par des implantations en
C++ ou Java [COU 00].
Opérateurs
Temporel
a{T}
delay(t1)
latency(t2)
Description
Offre limitée dans le temps.
Délai déterministe.
Délai non déterministe.
Tableau 2. Opérateurs temporels de RT-LOTOS
4. Le profil TURTLE
Un profil UML spécialise le méta-modèle UML en un méta-modèle spécifique à
un domaine d’application [TER 00]. Un profil est composé d’un certain nombre
d’éléments sélectionnés depuis le méta-modèle de référence, de mécanismes
d’extension, d’une description de la sémantique du profil, et enfin, de règles
permettant la présentation, la traduction et la validation du modèle.
Le profil UML proposé dans cet article fournit des outils destinés à améliorer la
description logique et temps-réel des relations entre classes, et les comportement
internes de ces mêmes classes. Cela se traduit, d’une part, au niveau du diagramme
de classes, par l’introduction d’un nouveau stéréotype1 UML au méta-modèle UML
et, d’autre part, au niveau de la description comportementale des classes (diagramme
d’activités), par l’introduction, entre autre, de trois opérateurs temporels.
1
Un stéréotype est un ajout indirect au méta-modèle UML. Le stéréotype TURTLE ainsi que les types
abstraits sont identifiés graphiquement par un symbole « TURTLE » situé dans le coin supérieure droit de
la classe considérée.
Deux types de classes cohabitent au sein des diagrammes de classes du profil
TURTLE : des classes dites « normales », et des classes stéréotypées Tclass. Quatre
relations (association, agrégation, composition et héritage) permettent d’établir des
liens entre les classes. Ces dernières peuvent être, au choix du concepteur, actives ou
passives. Une classe active est une classe dont les instances possèdent leur propre
flux d’exécution (ou processus léger) et peuvent ainsi déclencher une interaction.
4.1. Le type abstrait Gate
En plus des procédés classiques dont disposent habituellement les classes pour
communiquer (appel de méthode, modification d’attributs publics, etc.), les classes
stéréotypées Tclass peuvent communiquer via des portes, un concept pour lequel
nous introduisons le type abstrait Gate (Figure 1a.). Par défaut, une Gate permet des
échanges d’information bidirectionnels. Deux types abstraits sont ajoutés pour
rendre ces échanges mono-directionels (cf. Figure 1b) : on distingue les portes sur
lesquelles des données peuvent être émises (OutGate) et les portes sur lesquelles des
données peuvent être reçues (InGate). Dans la suite de l’article, nous utilisons
l’expression « une Tclass réalise un appel sur une Gate g » pour exprimer qu’une
Tclass désire communiquer sur la porte g de type Gate.
Gate
Ga te
InGate
(a)
OutGate
(b)
Figure 1. Le type abstrait Gate (a) et la distinction entre InGate et OutGate
4.2. Le stéréotype Tclass
La Figure 2 décrit la structure générale d’un stéréotype Tclass : les attributs de
type Gate y sont séparés des autres attributs. Les propriétés principales des Tclass
sont les suivantes :
— prop1 : tous les attributs, sauf ceux de type Gate, doivent être déclarés privés
ou protégés (#).
— prop2 : toutes les méthodes, sauf les constructeurs, doivent être déclarées
privées (-) ou protégées (#). Les constructeurs peuvent être déclarés publics.
— prop3 : un diagramme d’activités2 doit accompagner chaque Tclass et décrire
ainsi son comportement. Ce diagramme peut utiliser tout attribut ou classe déclarés
dans la Tclass ou hérités.
2
Seuls les diagrammes d’activité sont pris en considération dans cet article. Nos travaux futurs
aborderont les machines à états.
Tclass Id
Identificateur de la classe de stéréotype Tclass.
Attributs
Liste d’attributs, excepté les attributs de type Gate.
Portes (Gates)
Méthodes
Description du
comportement
Liste d’attributs de type Gate. Ils peuvent être déclarés
publics (+), privés (-), ou protégés (#).
Liste de méthodes, incluant un constructeur.
Diagramme d’activités qui peut faire référence aux
attributs, portes et méthodes précédemment définis, ou
hérités.
Figure 2. Structure d’un classe stéréotypée « Tclass »
— prop4 : les communications entre Tclass sont nécessairement réalisées au
travers des portes de communication (Gate). Synchrones, ces communications sont
les seules à être prises en compte lors de la validation. Ainsi, une Tclass peut
communiquer avec des classes normales par appel de méthode, modification
d’attributs, signaux, etc., mais ces communications sont ignorées pour la validation.
— prop5 : des attributs de type Gate peuvent être déclarés dans tout type de
classe. Néanmoins, seules les Tclass peuvent les utiliser à des fins de
communication.
— prop6 : une Tclass T peut hériter d’une classe C ssi C et tous ses ascendants
satisfont les propriétés prop1 et prop2.
— prop7 : les relations d’association, de composition et d’héritage sont prises en
compte lors de la validation ssi celles-ci concernent deux Tclass.
— prop8 : deux Tclass ne peuvent être mises en relation que par une seule
relation UML. Si cette relation est une association, alors, elle doit attribuée avec une
classe associative de type Composer.
— prop9 : une classe ou une Tclass peut-être composée de Tclass ou de classes.
— prop10 : la relation d’agrégation n’est pas supportée dès lors qu’une Tclass
est impliquée dans la relation.
— prop11 : Supposons que la Tclass T1 est composée de la Tclass T2, que T1
possède une porte publique g1 et T2 une porte publique g2. Une Tclass T3 qui veut
communiquer avec T2 via g2 a deux solutions : soit T3 communique directement
avec T2 sur la porte g2, soit T3 communique avec T1 sur la porte g1, à la condition
qu’une formule OCL associe g1 et g2. Cette formule doit être attachée à la relation
de composition entre T1 et T2. Elle doit alors être de la forme : {T1.g1 = T2.g2}.
4.3. Le type abstrait Composer
Un diagramme de classes UML est une représentation graphique d’un ensemble
de classes interconnectées par des relations, telles que des associations. Le profil
TURTLE donne une sémantique formelle aux relations d’association. Pour cela,
nous définissions le type abstrait Composer, qui ne doit pas être utilisé directement :
d’autres types héritiers de Composer sont utilisés comme classe associative
attribuant d’une association entre deux Tclass. Ces types sont : Parallel, Synchro,
Invocation, Sequence, Preemption. Deux d’entre eux sont représentés à la Figure 3.
Parallel
Sequence
Opérateur de
composition
Indication de
navigation
Association
T1
T2
T1
T2
(a)
(b)
Figure 3. Utilisation de deux opérateurs de composition héritant de Composer.
Toute association entre deux Tclass doit avoir une seule semantique et ainsi
n’être attribuée que par une seule classe associative de type Composer. Les classes
suivantes héritent de Composer :
Parallel
Les deux Tclass mises en relation par une association à laquelle est
attribué cet opérateur sont exécutées en parallèle et sans
synchronisation. Les deux Tclass doivent être des classes actives.
Synchro
Les deux Tclass mises en relation par une association à laquelle est
attribué cet opérateur, réalisent des synchronisations entre elles dans
deux fluxs d’exécution séparés. Cette synchronisation peut donner
lieu à un échange de données dont le format est précisé lors de
l’appel, dans le diagramme d’activités. Si l’association entre les deux
Tclass comporte un sens de navigation, alors l’échange de données
ne peut se réaliser que dans le sens indiqué par la navigation.
Deux Tclass doivent se synchroniser sur deux Gates, qui doivent être
listées dans une formule OCL. Par exemple, supposons que les portes
g1 et g2, de type Gate et de la Tclass T1, se synchronisent
respectivement avec les portes g3 et g4 de type Gate et de la Tclass
T2. Dans ce cas, la formule OCL qui accompagne la relation
d’association entre T1 et T2 doit être {T1.g1 = T2.g3 and T1.g2 =
T2.g4}. A chaque fois que T1 réalise une action sur g1, elle doit
attendre que la classe T2 réalise une action sur g3 et réciproquement.
Lorsque l’action est enfin réalisée par les deux classes, l’échange de
données a lieu, et les deux classes passent à l’instruction suivante de
l’activité respective.
Invocation Considérons deux Tclass, T1 et T2, mises en relation par une
association dirigée de T1 à T2 et attribuée par la classe associative
Invocation. On dit alors que T2 peut-être invoquée par T1. Tout
comme dans la relation de synchronisation, une porte de chaque
Tclass doit être impliquée dans chaque invocation. Soit g1 (resp. g2)
une porte de T1 (resp. T2). Considérons que la formule OCL suivante
est associée à la relation : {T1.g1 = T2.g2}. Alors, quand T1 réalise
un appel sur g1, elle doit attendre que T2 réalise un appel sur g2.
Quand T2 réalise cet appel, les données sont échangées uniquement
dans le sens de la navigation (c.à.d. de T1 à T2). T1 est bloquée
jusqu’à ce que T2 réalise de nouveau un appel sur g2. Dans ce
deuxième cas, un échange de données peut avoir lieu dans le sens
contraire à celui indiqué par la navigation. Cette invocation est
similaire à l’appel de méthode du paradigme objet. Ainsi, le code de
T2 qui est invoqué par T1 est exécuté dans le flux d’exécution de T1.
Les deux Tclass, mises en relation par une association à laquelle est
attribué cet opérateur, sont exécutées l’une après l’autre, dans le sens
donné par la navigation de l’association. Dans la relation (T1
Sequence T2), T1 doit se terminer3 avant que T2 ne démarre. T2 est
exécutée dans un nouveau flux d’exécution si T2 est une classe
active.
La Tclass T2, désignée par la navigation de l’association reliant deux
Tclass T1 et T2, et dont l’opérateur de composition associé est
Preemption, peut interrompre définitivement et à n’importe quel
instant l’autre Tclass. Cette interruption se produit lorsque la
première instruction de T2 est réalisable (synchronisation sur une
porte par exemple). Les deux Tclass doivent être des classes actives.
Sequence
Preemption
4.4. Comportement interne d’une Tclass
Le tableau 3 illustre, pour toutes les constructions des diagrammes d’activités
[DOU 00], la sémantique associée par transposition en LOTOS. Soit AD la
dénomination pour un diagramme d’activités, et τ(AD) le processus RT-LOTOS
correspondant à la transcription de AD.
Diagramme d’activités Description
Traduction LOTOS
TURTLE
Début
d’un
diagramme
d’activités. En d’autres termes,
τ(AD)
début de la traduction.
AD
g
AD
3
Appel sur la Gate g. AD est
ensuite interprété.
g ; τ(AD)
On dit qu’une Tclass se termine lorsque toutes les activités associées à cette classe ont atteint leur point
de terminaison.
g ?x
AD
g !x
AD
AD
y := x*2
AD
operation(x, y)
AD
or
AD
AD1 AD2 …ADn
[g1, …, gm]
AD1 AD2 … ADn
AD1
[c1]
AD1
AD2 …
[c2]
AD2 …
g ?x:nat ; τ(AD)
Appel sur la Gate g avec
émission de la valeur x. AD est
ensuite interprété.
g !x ; τ(AD)
Appel sur la Gate g avec
émission de la valeur x et
réception de la valeur y. AD est
ensuite interprété.
Assignation d’une valeur à un
attribut. AD est ensuite
interprété.
g !x ?y
AD
Appel sur la Gate g avec
réception de la valeur x. AD est
ensuite interprété.
ADn
[cn]
ADn
g !x ?y:nat ; τ(AD)
let y : YType = x*2 in
τ(AD)
τ(AD)
(appel de méthode non
traduit)
Structure de type boucle. AD process
est interprété à chaque fois que LabelX[g1,…gn]
l’interpréteur entre dans la : noexit := τ(AD)
boucle.
>>LabelX[g1,...gn]
end proc;
Parallélisme entre n sous- τ(AD1) ||| τ(AD2) |||
activités décrites par AD1,
… ||| τ(ADn)
AD2, …, ADn. A des fins de
documentation,
les
sous(swinlanes non
activités peuvent être séparées
traduites)
par des swinlanes.
Synchronisation sur les portes
τ(AD1) |[g1,…gm]|
g1, g2, …, gm entre n sousτ(AD2) |[g1,…gm]|
activités décrites par AD1,
AD2, …, ADn.
… |[g1,…gm]| τ(ADn)
Appel de méthode. AD est
ensuite interprété.
Sélection de la première
activité prête à s’exécuter
parmi les n activités décrites
par AD1, AD2, … , ADn.
Sélection de la première
activité prête à s’exécuter et
dont la garde est vraie, parmi
les n activités décrites par
AD1, AD2, … , ADn.
τ(AD1) [] τ(AD2) []
... [] τ(ADn)
[c1] -> τ(AD1)
[] [c2] -> τ(AD2)
[] …
[] [cn] -> τ(ADn)
AD1 AD2 … ADn
AD’1
AD’2 … AD’m
AD1 AD2.. ADn
[g1,…gk]
AD’1AD’2… AD’m
Une fois que toutes les activités
AD1, AD2, …, ADn ont (τ(AD1) ||| τ(AD2) |||
terminé leur exécution, les m
… τ(ADn) ) >>
activités décrites par AD’1,
AD’2,
…,
AD’m
sont (τ(AD’1) ||| τ(AD’2) |||
exécutées
en
parallèle
… τ(AD’m) )
(entrelacement).4
Une fois que toutes les activités (τ(AD1) ||| τ(AD2) |||
AD1, AD2, …, ADn ont
… τ(ADn) ) >>
terminé leur exécution, les m
activités décrites par AD’1, (τ(AD’1) |[g1, …gk]|
AD’2,
…,
AD’m
sont
exécutées en synchronisation τ(AD’2) |[g1, …gk]| …
sur les k portes g1, g2, …, gk.
τ(AD’m) )
Terminaison d’une activité
exit
Tableau 3. Opérateurs non temporels de TURTLE
Le tableau 4 présente les trois pictogrammes retenus pour les opérateurs
temporels. S’y ajoutent un opérateur de délai applicable à un intervalle temporel,
cumulant ainsi les effets d’une durée fixe égale à la borne inférieure de l’intervalle et
une latence égale à la différence entre les bornes supérieure et inférieure de
l’intervalle.
Opérateurs
temporels
TURTLE
Description
d
AD
Retard déterministe. AD est interprété
après d unités de temps.
Retard
t
Traduction
LOTOS
non
déterministe.
AD
temps.
d m a x - d m in
delay(d) τ(AD)
est
A D interprété après au plus t unités de
d m in
RT-
Délai non déterministe. AD est
interprété après au moins dmin et au
plus dmax unités de temps.
latency(t) τ(AD)
delay(dmin,dmax)
τ(AD)
AD
4
Si le cardinal des ADi vaut 1 et que le cardinal des AD’j vaut aussi 1, alors une simple flèche est utilisée
entre AD1 et AD’1.
a
t
AD1 AD2
l
a
t
AD1 AD2
Offre limitée dans le temps. L’offre sur
la Gate a est offerte pendant une période
inférieure ou égale à t. Si l’offre est
réalisée, alors AD1 est interprété, sinon
AD2 est interprété.
a{t, τ(AD2)};
τ(AD1)
Offre limitée dans le temps. L’offre sur
la Gate a est offert pendant une période
inférieure ou égale à t. A noter que la
latence commence en même temps que
la limitation sur l’offre. Si l’offre est
réalisée, alors AD1 est interprété, sinon
AD2 est interprété.
latency(l) a{t,
τ(AD2)};
τ(AD1)
Tableau 4. Pictogrammes TURTLE pour les opérateurs temporels
4.5. Processus de validation
Ce paragraphe décrit les différents étapes du processus de validation TURTLE
(cf. Figure 4). Tout d’abord, les Tclass ainsi que les relations qui les lient, sont
extraites du diagramme de classes et sauvegardées au format XMI. Ce format
intermédiaire est ensuite converti en RT-LOTOS. A des fins d’analyse, un graphe
d’accessibilité est obtenu en utilisant l’outil RTL. Bien entendu, ce graphe est
généré ssi le système considéré est fini. Sinon, l’analyse se limite à de la simulation
c.à.d. à une exploration partielle des états du système.
Les modèles TURTLE peuvent être réalisés à partir d’atelier logiciels supportant
UML 1.3 et la sauvegarde au format XMI [21].
Transparent aux utilisateurs d’UML
____
____
fichier xmi
Modélisation TURLE
avec un outil UML 1.3
xmi2rtlotos
____
____
fichier
RT-LOTOS
RTL
graphe
d’accessibilité
Figure 4. Processus de validation : du modèle TURTLE au graphe d’accessibilité
5. Application
Par souci de compréhension, nous reprenons un exemple connu de tous : le
distributeur de boissons. Bien que simple, cet exemple nous permet de mettre en
évidence l’utilisation du stéréotypes Tclass, des types abstraits et des trois
opérateurs temporels introduits dans TURTLE.
5.1. Diagramme de classes
Nous considérons ici une machine qui distribue thé et café après insertion de
deux pièces de monnaie identiques (Fig. 5). Un retard excessif dans l’introduction
de la deuxième pièce ou dans le choix de la boisson entraînera le remboursement de
la ou des pièces déjà entrées. Ces deux situations sont modélisées par des offres
limitées dans le temps (coinDelay et buttonDelay). Des délais matérialisent le temps
de réaction du bouton et le temps minimum de préparation d’une boisson. Ce temps
de préparation peut varier, ce qui explique la présence des « ressorts ». Notons enfin
les contraintes ajoutées aux associations entre classes pour désigner les Gates
impliquées dans chacune des synchronisations.
W allet
C oinBox
coin: nat
- x : nat ;
# coinD elay, m axCoin : int
# coin_in : InG ate ;
# eject_coin : OutGate
+
+ putC oin : O utGate
+coinBack : InGate
# coinN b()
+ W allet(int coin)
Synchro
CoffeeM achine
false
coin>0 ?
true
putcoin !1
coin --
{W allet.putC oin =
C offeeM achine.coin_in
and
W allet.coinBack =
C offeeM achine.ejectCoin }
-
buttonD elay : nat
+
coffee, tea : InG ate
coin_in ?1
coinBack ?x
coin += x
coin_in ?1
Button
coinD elay
ejectcoin !1
- delay : nat
Synchro
+ push : Gate
buttonDelay
2
push
delay
{ CoffeeM achine.coffee=
Button.push
or
CoffeeM achine.tea = Button.push }
coffee
100
75
tea
120
ejectC oin !2
80
Figure 5. Diagramme de classes n°1 de la machine à café
5.2. Validation par l’outil RTL
La validation consiste à vérifier que le comportement du système spécifié est
conforme au comportement attendu. Cette analyse se fait par génération du graphe
d’accessibilité du système modélisé. Ce graphe aide à identifier les situations de
blocage et les différents états accessibles du point de vue logique et temporel. Du
graphe d’accessibilité issu du modèle de la Figure 5, considérons la séquence
d’actions qui correspond à un utilisateur désirant un thé. Supposons que cet
utilisateur insère deux pièces mais attende trop longtemps. L’offre de
synchronisation sur tea ou coffee expire, ce qui a pour effet d’éjecter les deux
pièces. L’utilisateur appuie un bref instant plus tard sur le bouton « tea » (classe
Button, porte push). L’offre de synchronisation ne peut plus avoir lieu. L’utilisateur
reprend ses pièces, pensant que la machine est en panne. Supposons qu’un deuxième
utilisateur désirant du café arrive et insère deux pièces. L’offre de synchronisation
sur tea n’ayant pas expiré (offre illimitée), un thé lui est instantanément servi.
Afin de pallier au problème, nous modifions le diagramme selon la Figure 6.
Une synchronisation supplémentaire permet à la machine d’activer les boutons qui
ne peuvent alors être actionnés que pendant un temps limité (offre push limitée à
40). Cette activation de bouton implique un délai de traitement dans le distributeur
(délai de 50).
Co in Bo x
Co ff e e M a ch in e
# co in D e la y, m a xCo in : in t
# co in _in : I n G a te ;
# e je ct_co in : O u tG a te
+ te a , co ffe e : In G a te
- b u tto n D e la y : n a t
# co in N b ()
Syn ch r o
W a lle t
{ W a lle t.p u tCoin =
Co ffe e M a ch in e .co in _in
a nd
W a lle t.co in Ba ck =
co ffe e M a ch in e .e je ctCoin }
Bu tto n
- d e la y : n a t
+
p u sh ,
G a te
a ctive
:
Syn ch r o
co in _in ? 1
co in D e la y
co in _in ?1
a ctive 1
e je ctco in !1
a ctive 2
50
2
a ctive
p u sh
40
d e la y
{ (Coffe e M a ch in e .coffe e =
Butto n .p u sh
a n d Coffe e M a ch in e .a ctiv e 1 =
Butto n .a ctive )
or
(Coffe e M a ch in e .te a =
Butto n .p u sh
a n d Coffe e M a ch in e .a ctiv e 2 =
Butto n .a ctive )
}
co ffe e
100
75
te a
120
80
b u tto n D e la y
e je ctCo in !2
Figure 6. Diagramme de classes n°2 de la machine à café
Cette modification du modèle appelle une nouvelle validation. La Figure 7a
présente le graphe d’accessibilité de la machine à café de la Figure 6 réduite à la
distribution du thé (graphe plus lisible). Un état logique (rectangle) est partitionné en
classes d'états temporels. Les conditions pour quitter un état sont les suivantes : soit
le temps s’est écoulé (transition t), soit une synchronisation a eu lieu sur une porte
RT-LOTOS. Considérons par exemple le graphe d’accessibilité de la Figure 8a.
Quitter l’état initial (état 0) requiert une synchronisation sur la porte putCoin. Dans
l’état 21, aucune synchronisation ne peut avoir lieu à partir des deux premiers états :
un changement d’état correspond exclusivement à une progression du temps
(transition t). Par contre, quand l’offre sur la Gate tea ou coffee expire (délai
buttonDelay), alors la synchronisation sur coinBack permet de passer de l’état 21 à
l’état 7. Une valeur 2 est alors échangée.
Ce graphe met en évidence l’impossibilité pour un utilisateur d’obtenir du thé
(ou du café). En effet, le délai d’activation du bouton (push) expire avant que la
machine ne soit prête à délivrer du café ou du thé. Si ce délai passe de 40 à 60, le
graphe de la Figure 7b montre qu’il est possible d’avoir du thé.
0 -()
i ( p u t C o in < 1 > )
1 3 -(1 5 0 )
1 -(0 )
1 7 -(0 0 )
i(p u tC o in < 1 > )
t
(a )
2 -()
i(p u tC o in < 1 > )
1 7 - ( 4 0 .5 4 0 .5 )
i( a c tiv e )
t
2 1 -(0 0 )
1 2 -(1 5 0 0 )
1 7 -(1 5 0 1 5 0 )
t
2 1 - ( 4 0 . 5 4 0 .5 )
i( c o in B a c k < 2 > )
i(p u tC o in < 1 > )
t
2 1 -(1 5 0 1 5 0 )
i( c o i n B a c k < 2 > )
7 -(1 5 0 )
p iè c e s re je té e s
(b )
0 -()
2 4 -(5 0 )
2 1 -(0 0 )
i(a c t iv e )
i(p u tC o in < 1 > )
t
t
i(a c t iv e )
1-(0)
2 4 -(1 0 0 )
2 1 -(5 0 5 0 )
i(p u t C o in < 1 > )
i(t e a )
2 -()
p o s s i b il i t é
d ’a v o i r d u
th é
i(p u tC o in < 1 > )
i( p u t C o in < 1 > )
2 2 -(0 0 )
t
i ( p u t C o in < 1 > )
2 2 -(5 0 5 0 )
2 3 -(5 0 0 )
2 3 -(1 0 0 0 )
t
2 2 -(1 0 0 1 0 0 )
i( p u t C o i n < 1 > )
Figure 7. Graphe d’accessibilité de la machine à café n°2. (a) : cas où l’offre sur
le bouton est limitée à 40. (b) : cas où l’offre est limitée à 60.
6. Conclusion
Cet article présente TUTLE, un profil UML pour la conception et la validation
de systèmes temps réel. Les digrammes de classes sont étendus avec un stéréotype
(Tclass) et deux types abstraits (Gate et Composer). Une sémantique précise est
donnée aux associations entre classes (voir les classes Parallel, Synchro, Invocation,
Sequence et Preemption). Le comportement d’une Tclass est décrit par un
diagramme d’activités étendu par trois opérateurs temporels : un délai déterministe,
un délai non déterministe et une offre limitée dans le temps. De surcroît, les modèles
TURTLE peuvent être traduits en RT-LOTOS, technique de description formelle
supportée par un outil de validation. Les diagrammes TURTLE peuvent ainsi être
simulés et vérifiés sur la base d’analyses d’accessibilité en faisant en sorte que RTLOTOS reste caché au concepteur du système.
Le profil TURTLE est en cours d’évaluation sur du logiciel temps réel embarqué
et plus spécifiquement pour la validation de la reconfiguration dynamique de
logiciels embarqués à bord de satellites [APV 01].
Le profil UML est maintenant appelé à être étendu. Les machines à états
remplaceront les diagrammes d’activités. De nouvelles classes associatives seront
introduites pour étendre les sémantiques autorisées pour les associations
(resume/suspend, interrupt) [HER 98]. Ceci permettra de mettre en œuvre des
analyse d’ordonnancement sur des modèles TURTLE [TER 00]. Enfin, l’inter
fonctionnement de notre profil avec UML 2.0 est également à l’étude.
7. Bibliographie
[AND 01] ANDRÉ C., « Paradigmes objets et synchrones dans les systèmes temps-réel »,
journée Objets Temps Réel du Club SEE Systèmes Informatiques de Confiance, Paris, 18
janvier 2001. http://www.cert.fr/francais/deri/seguin/SEE/01.01.18/annonce.html.
[APV 01] APVRILLE L., DE SAQUI-SANNES P., SÉNAC P., DIAZ M., « Formal Modeling of
Space-Based Software in the Context of Dynamic Reconfiguration », Proceedings of
DAta Systems In Aerospace (DASIA), 28 May - 1st June, Nice, France, 2001.
[ART 99] Artisan Software Tools,: http://www.artisan-software.com, 1999.
[BJO 00] BJORKANDER M., « Real-Time Systems in UML and SDL », Embedded System
Engineering, October/November 2000 (http://www.telelogic.com).
[BOL 87] BOLOGNESI T., BRINKSMA E., « Introduction to the ISO specification Language
LOTOS », Computer Networks and ISDN Systems, vol 14, No1, 1987.
[BRU 98] BRUEL, J.-M. FRANCE R.B., « Transforming UML Models to Formal
Specifications », Proceedings of the International Conference on Object Oriented
Programming Systems Language and Applications (OOPSLA'98), Vancouver, Canada,
1998.
[BRU 99] BRUEL J.-M., « Integrating Formal and Informal Specification Techniques. Why?
How? », Proceedings of the 2nd IEEE Workshop on Industrial-Strength Formal
Specification Techniques (WIFT'98), Boca Raton, Florida, USA, IEEE Computer Press,
p. 50-57, 1999.
[CLA 00] CLARCK, R.G., MOREIRA, A.M.D., « Use of E-LOTOS in Adding Formality to
UML, Journal of Universal Computer Science », vol.6, no 11, p. 1071-1087, 2000.
[COU 00] COURTIAT J.-P., SANTOS C.A.S., LOHR C., OUTTAJ B., « Experience with RTLOTOS, a Temporal Extension of the LOTOS Formal Description Technique »,
Computer Communications, Vol. 23, No. 12, p. 1104-1123, 2000.
[DEL 98] DELATOUR J., PALUDETTO M., « UML/PNO, a way to merge UML and Petri net
objects for the analysis of real-time systems », OO Technology and Real Time Systems
Workshop (ECOOP'98), Bruxelles, Belgium, 1998.
[DOU 99] DOUGLASS B.P., Doing Hard Time: Developing Real-Time Systems with UML,
Objects,
Frameworks
and
Patterns,
Addison-Wesley
Longman,
1999
(http://www.ilogix.com).
[DUP 00] DUPUY S., LEDRU Y., CHABRE-PECCOUD M., « Vers une intégration utile de
notations semi-formelles et formelles : une expérience en UML et Z », vol.6, n°1, p. 9-32,
Hermès, Paris, 2000.
[DUP 01] Dupuy S., du Bouquet L., « A Multi-formalism Approach for the Validation of
UML Models », Formal Aspects of Computing, No.12, p.228-230, 2001.
[EVA 99] EVANS A.S., COOK S., MELLOR S., WARMER J., WILLS A., « Advanced Methods and
Tools for a Precise UML », Proceedings of the 2nd International Conference on the
Unified Modeling Language, UML’99, Colorado, USA, LNCS 1723, 1999.
[GUE 00] LE GUENNEC A., « Méthodes formelles avec UML : Modélisation, validation et
génération de tests », Actes du 8è Colloque Francophone sur l’Ingénierie des Protocoles
CFIP’2000”, Toulouse, Editions Hermès, Paris, p. 151-166, 17-20 octobre 2000.
[JAR 98] JARD C., JÉZÉQUEL J.-M., PENNANEAC’H F., « Vers l’utilisation d’outils de validation
de protocoles dans UML », Technique et Science Informatiques, vol. 17, n°9, p. 10831098, Hermès, Paris, 1998.
[OMG 99a] OMG, « Unified Modeling Language Specification », Version 1.3, Object
Management Group http://www.omg.org/technology/uml/index.htm, 1999.
[OMG 99b] OBJECT MANAGEMENT GROUP, « UML Profile for Scheduling, Performance, and
Time, Request for Proposal », 1999, ftp://ftp.omg.org/pub/docs/ad/99-03-13.doc
[PAL 99] HERNALSTEEN C., « Specification, Validation and Verification of Real-Time
Systems in ET-LOTOS », Ph.D. dissertation, Université Libre de Bruxelles, Belgium,
1998.
[SAQ 01] DE SAQUI-SANNES P., « Diagramming TURTLE classes using Rhapsody »,
ENSICA internal report, 2001.
[SEL 98] SELIC B., RUMBAUGH J., « Using UML for Modeling Complex Real-Time
Systems », http://www.rational.com, 1998.
[SEN 96] SÉNAC P., DIAZ M., DE SAQUI-SANNES P., LÉGER A., « Modeling Logical and
Temporal Synchronization in Hypermedia Systems », IEEE Journal on Selected Areas in
Communication, special issue on multimedia synchronization, 1996.
[TER 00] TERRIER, F., GÉRARD, S., « Real Time System Modeling with UML: Current Status
and Some Prospects », Proceedings of the 2nd Workshop of the SDL Forum society on
SDL and MSC, SAM 2000, Grenoble, France, 2000.
[TRA 00] TRAORÉ I., « An Outline of PVS Semantics for UML Statecharts », Journal of
Universal Computer Science, Vol. 6, No. 11, p. 1088-1108, 2000.