2ème Partie CSTR 2014

2me Partie : UML pour le Temps Rel et
lEmbarqu
1.
2.
3.
4.
5.
6.
7.
Introduction
Rappels dUML
UML2.0 et le temps rel
Mta-modlisation
Les profils UML
Les profils ddis aux SETR : le profil UML MARTE
Les mthodologies de dveloppement des SETR bases
sur UML
8. Les outils de dveloppement UML pour les SETR
156
Introduction
Il ya une explosion du march des systmes embarqus, temps rel
et distribus, qui provoque une pression extrmement forte sur leur
dveloppement.
dveloppement
de plus en plus rapidement avec des cots toujours plus

rduits (notion Time-to Market)
Les approches classiques dites structures :

Simplicit due lapproche totalement descendante
Une modification des bords profondes modifications de la modlisation
Absence du concept de composants : rutilisabilit faible dun projet
un autre
Rutilisation et volutivit deviennent des exigences essentielles

pour les mthodes et techniques de dveloppement.
157
Introduction
Approche objet : modlisation du monde rel et du monde
mtier par des classes/objets regroups sous forme de
composants rutilisables
Prise en main plus complexe, temps de spcification/conception plus
long
Mais moins influences par des modifications, plus flexible
Time-to-Market
o Nombreuses modifications du cahier des charges, volution des normes
& exigences, etc.
De mieux en mieux comprises et outilles

Interface de + en + automatises de transformations de
modles/gnration de code
Effort de normalisation important
Mais toujours une jungle de normes, langages outils, CASE
158

lEmbarqu
1.
2.
3.
4.
5.
6.
7.
Introduction
Rappels dUML
Mta-modlisation
Les profils UML
sur UML
159
Rappels dUML
UML (Unified Modeling Language) est un langage graphique pour la
conception objet, utilis pour :
Spcifier
Visualiser
Construire
Documenter
UML offre :
Une reprsentation indpendante de tout langage de programmation et de
toute mthode de dveloppement
Une analyse des besoins
Un support de modlisation du comportement
UML a t accept comme standard par lOMG (Object Management

Group) en 1997
160
Rappels dUML
Histoire
161
Rappels dUML
Les diffrents Diagrammes dUML2.0
diagramme
Diagrammes
Comportementaux
Diagrammes
Structurels
Diagramme
des Classes
Diagramme
de composants
Diagramme de
Structures
composites
Diagramme
dObjets
Diagramme de
Dploiements
Diagramme
dactivits
Diagramme
des paquetages
Diagramme
De squences
Diagramme des
cas dutilisations
Diagramme
dtats
Diagrammes
dInteractions
Diagramme de
Vue densemble
des Interactions
Diagramme de
communication
Diagramme
temporel
162
Rappels dUML
Description au niveau systme des besoins utilisateurs support
par les diagrammes de cas dutilisation
Transition vers lobjet
cas1
include
cas3
cas2
Approche Objet
Approche
Fonctionnelle
Cas2
Cas3
Systme
Cas2
Cas3
Cas X
E
Cas 1
Fonction
Fonction
Fonction
Fonction
Fonction
Cas1
C
G
163
Fonction
Fonction
Rappels dUML
Description de la structure et de larchitecture logique
(logicielle) du systme :
Elle repose principalement sur
les diagrammes des classes qui effectuent une typologie
des entits constituant le systme et qui prcisent les
relations entre ces diffrents types dentits.
diagrammes dobjets prcisant quelles instances
particulires des classes seront manipules pour mettre en
uvre le systme
Les Paquetages dfinissent un espace de nommage
permettant de regrouper des diagramme
164
Rappels dUML
Description de laspect dynamique du systme : vise deux
aspects :
La description des interactions entre les objets du systme travers
les diagrammes de squence et les diagrammes de collaboration
(communication pour UML2). Ces deux types fournissent une vue
gros grain de la dynamique du systme centr sur les changes entre les
objets qui limplanteront.
Description du fonctionnement dynamique des lments du systme :

elle repose principalement sur des machines tats. Elle peut tre
prcise par des diagrammes dactivits prcisant les flots de donnes
et de contrle. Le diagramme de temps introduit par UML2 permet de
mieux reprsenter des changements dtats et des interactions entre
objets lis des contraintes de temps.
165
Rappels dUML
Description de la ralisation du systme : elle
repose sur les diagrammes de composants et les
diagrammes de dploiement de ces composants sur
larchitecture matrielle supportant le systme.
166
Rappels dUML
Description au niveau systme
Exemple : machine danesthsie
167

Exemple : machine danesthsie
Exemple machine danesthsie

Fonctionnalit principale : administrer au patient un mlange
de gaz (Oxygne + Nitrate doxyde + isoflurane) avec une
pression et un dbit appropri
Inclut un ventilateur et un dispositif de monitoring des signaux
vitaux du patient (Rythme cardiaque, pression sanguine,...)
Inclut un vaporisateur qui permet de contrler finement
laddition de anesthsiant volatile au flux de gaz
La composition des gaz administrs au patient doit tre
contrle en temps rel
168
Rappels dUML
Exemple machine danesthsie

Configurer
Systme
Mdecin
ECG
Grer
Alarmes
Administrer
Anesthsiant
Suivre signes
vitaux
Traceur
Patient
Ventiler
Patient
Systme danesthsie
169
Rappels dUML
Sous-systme
Circuit respiratoire
Sous-systme
Monitoring agent anesthsiant
administrer
gaz
Contrler
concentration
Calibrer
Configurer
Mlanger gaz
Administrer
mdicament
Fixer paramtres
vaporisation
Sous-systme
Vaporisateur
include
Administrer
Anesthsiant
Configurer
Ventilateur
Sous-systme
Ventilateur
Monitorer
Circuit respiratoire
Configurer
Monitor agent
Appliquer
ventilation
Configurer
Vaporisateur
Sous-systme
Interface utilisateur
170
Rappels dUML
Exemple machine danesthsie : scnario dun cas dutilisation
Rsum :
Prconditions :
Nom : Grer alarme

Acteur principal : Mdecin; Acteurs secondaire : ECG, Traceur
Objectif : Ce cas permet didentifier les situations o il existe un danger pour le
patient et dinformer lanesthsiste a fin quil ragisse de faon approprie
Le systme a t configur et initialis correctement
Les paramtres de la fonction dalarme ont t fixs
La fonction dalarme est active
Enchanements :
1. Lorsque une situation dalarme se produit un message (contenant la date/heure
doccurrence, le type de lalarme, la source de lalarme et la cause probable de
lalarme) doit tre affich accompagn dun signal sonore
2. Lorsque plusieurs alarmes se produisent simultanment, elles doivent tre affichs
par ordre de criticit dabord et par ordre doccurrence (la plus rcente en premier)
171
ensuite.
Rappels dUML
Exemple machine danesthsie : scnario dun cas

dutilisation (suite)
3. Les alarmes doivent ncessairement recevoir un accus de rception de la part
des oprateurs qui appuient pour cela sur le bouton Alarm Ack une fois que
lalarme sest produite, mme si les conditions de lalarme nexistent plus
loprateur doit accuser rception de lalarme.
4. Lorsque une alarme ne peut pas tre affiche parce que des alarmes de priorits
suprieure occupent tout lespace daffichage, elle ne peut recevoir un accus de
rception que lorsquelle a t affiche
5. Lorsque les conditions qui ont gnr une alarme ont t corriges mais
lalarme na pas encore reu daccus de rception, elle doit safficher en gris.
Les autres alarmes conservent leur couleur initiale
6. Lappui sur le bouton Alarm Ack pour une alarme pour consquence
dinterrompre le signal sonore mais na pas deffet sur laffichage.
Linterruption dure 2 minutes si avant la fin de linterruption les conditions qui
ont provoqu de lalarme ont disparue, lalarme cesse dtre affiche sinon le
signal sonore reprend
172
Rappels dUML
Exemple machine danesthsie : scnario dun cas

dutilisation (suite)
Contraintes non fonctionnelles
Contraintes temporelles
Il ne doit pas scouler plus de 50 ms entre loccurrence dune situation
dalarme et la signalisation de lalarme
La signalisation dune alarme qui a reu un accus de rception sinterrompt
au plus pendant 2 minutes lorsque les conditions qui lont gnres restent
prsentes
173
Rappels dUML
Description de larchitecture logique
Exemple : systme de rgulation de vitesse

Compos :
dun bouton marche/arrt
dun moteur sur lequel est applique la consigne de couple calcule par le systme
dun compteur de vitesse qui fournit la vitesse courante du vhicule au systme
Diagramme de cas dutilisation
Maintenir la vitesse
Marche/Arrt
Moteur
Dmarrer
Arrter
CompteurDeVitesse
174
Rappels dUML
Description de larchitecture logique
Diagramme des classes
pM>
Regulateur
1..1
pL>
Moteur
LoiDeCtr
1..*
Regulateur
Demarrer (vit:Integer);
Arreter ();
175
Rappels dUML
Description de laspect dynamique du systme
Modle dynamique
Le modle dynamique montre le comportement
du systme et lvolution des objets dans le temps
Le modle dynamique va identifier les diffrents vnements venant du monde
externe et montrer lenchanement dans le systme que provoquent ces
vnements externes.
vnement :
quelque chose se produit un moment donn dans le temps, et qui na pas de
dure. Exemple :
lutilisateur dcroche son tlphone
le conducteur appuie sur un bouton
176
Rappels dUML
But du modle dynamique

Trouver les relations temporelles et vnementielles entre les
objets
Dfinir les tats des objets qui dterminent une raction

diffrente face un vnement
Trouver les actions effectues par les objets suite la rception
dvnements
177
Rappels dUML
Six diagrammes sont proposs par UML2 pour assurer la
description de la partie dynamique des systmes :
Le diagramme des squences
Le diagramme de communication (Le diagramme de collaboration)
Le diagramme dtat-transition (machine dtat)
Le diagramme dactivit
Le diagramme global dinteraction
Le diagramme de temps
178

Prsentation gnrale et concept de base

Le diagramme de squence et le diagramme de collaboration sont trs
similaire : ils permettent tous les deux de dcrire des changes de message
entre objets.
Le diagramme de squences met en avant la dimension chronologique
Le diagramme de squence permet aussi dillustrer les scnarios dfinis
pour les cas dutilisations. Il peut tre vu comme un droulement dun cas
dutilisation.
Formalisme gnrale du cadre
dun diagramme de squence
Sd nom du diagramme
Reprsentation du diagramme
179

Prsentation gnrale et concept de base (suite)

Ligne de vie
Une de vie reprsente lensemble des oprations excutes par un objet. Un message reu par
un objet dclenche lexcution dune opration. Le retour dinformation peut tre implicite
(cas gnral) ou explicite laide dun message de retour.
Message synchrone et asynchrone

Dans un diagramme de squence, deux types de messages peuvent tre distingus :
Message synchrone : dans ce cas lmetteur reste en attente de la rponse son message
avant de poursuive son action (
). Le message de retour (
) peut ne
pas tre reprsent car il est inclus dans la fin dexcution de lopration de lobjet
destinataire du message
Message asynchrone : dans ce cas, lmetteur nattend pas la rponse son message, il
poursuit lexcution de ses oprations (
).
180

: objet1
: objet2
: objet3
: Client
Message 1()
Message 2()
Possession
du contrle
Message 3()
Ligne de vie
Message 4()
Retour message 3()
Message 5()

Oprations particulires
Cration et destruction dobjet
Si un objet est cre par une opration, celui-ci napparat quau moment o il est cr. Si
lobjet est dtruit par une opration, la destruction se reprsente par X
0bjet1: Classe 1
Cration objet 2
0bjet2: Classe 2
Destruction objet 2
182

Oprations particulires (suite)

Contrainte temporelle
Rsoudre()
Des contraintes de chronologie entre les messages

peuvent tre spcifie. De plus lorsque lmission dun
message requiert une certaine dure, il se reprsente
sous la forme dun trait oblique.
Dlai
t1
{t2-t1 <2s}
t2
183

Fragment dinteraction
Des sous ensembles dinteraction constituent des fragments. Un port dentre et un port de
sortie indiquent la manire dont ce fragment peut tre reli au reste du diagramme.
Sd Diagramme densemble
: Gestionnaire
Interface
IHM
Client
saisirCommande()
contrlerClient()
Seq ContrleProduit
Produit
contrlerExistenceProduit
ExisteProduit()
184

Type de fragment dinteraction

Un fragment dinteraction combin correspond un ensemble dinteraction auquel
on applique un oprant. Treize oprateurs ont t dfinis dans UML : alt, opt,
loop, par, strick/weak, ignore/consider, critical, assert et rf.
Oprateur alt : correspond un oprateur de test avec une ou plusieurs

alternatives possibles
:adhrant
:Emprunt
: Gestionnaire
SaisirAdhrent()
contrlerEtat()
alt EtatEmprunt
[tatemprunt=rendu]
autoriserEmprunt()
[tatemprunt= non rendu]
refuserEmprunt()
185

Type de fragment dinteraction (suite)

Oprateur opt (optional) correspond une opration de test sans
alternative (sinon)
:adhrant
:Emprunt
: Gestionnaire
relancer()
testerArelancer()
retourSituationRelance
opt Relancer
[si relance]
Relancer()
186


Oprateur loop correspond une instruction de boucle qui permet
dexcuter une squence dinteraction tant quune condition est satisfaite
Oprateur par (parallel) permet de reprsenter deux sries dinteractions
qui se droulent en parallle.
:classe1
Traitement A1 et A2 mens
En parallle au traitement B3
par
:classe3
:classe2
TraiterA1()
TraiterA2()
traiterB3()
187


Oprateurs strict et weak sequencing : permettent de reprsenter une srie
dinteractions dont certaines soprent sur des objets indpendants.
Lopration strict est utilis quand lordre dexcution des oprations doit
tre strictement respect
Loprateur weak est utilis quand lordre dexcution des oprations na
pas dimportance
Oprateur beak permet de reprsenter une situation exceptionnelle

correspondant un scnario de rupture par rapport au scnario gnral. Le
scnario de rupture sexcute si la condition de garde est satisfaite.
Oprateurs ignore et consider sont utiliss pour des fragments dinteractions
dans lesquels on veut montrer que certains messages peuvent tre soit absents
sans avoir dincidence sur le droulement des interactions (ignore), soit
obligatoirement prsents (consider)
188


Oprateur critical : permet dindiquer quune squence dinteractions ne
peut tre interrompue compte tenu du caractre critique des oprations
traites. On considre que le traitement des interactions comprises dans la
squence critique est atomique.
:classe1
:classe3
:classe2
critical
Op1()
Op2()
Op3()
189

Type de fragment dinteraction
Oprateur neg (ngative) permet dindiquer quune squence dinteractions
est invalide. Une erreur sera dclenche dans le cas de son excution.
Oprateur assert (assertion) permet dindiquer quune squence dinteraction
est lunique squence possible en considrant les messages changs dans le
fragment. Toute autre configuration de message est invalide
Oprateur ref permet dappeler une squence dinteraction dcrite par ailleurs
:classe1
:classe2
:classe3
: Gestionnaire
saisieIdContrat()
contrlerDroitContrat()
ref
Contrle des droits
190

Exemple : systme de rgulation de vitesse (suite)
Diagramme des squences
Instance myReg
de Regulateur
monMoteur/PM : Moteur
monReg : Regulateur
Pl(0) : LoiDeCtr
Dmarrer()
calculerNouveauCouple()
Calcul()
Avancement du temps
MarcheArrt
Message
initiant
la squence
Traitement
du message
dmarrer
Ligne de vie
cpl
fixerCouple(cpl)
Message de retour
Suite un appel
synchrone
191

Le diagramme de collaboration (communication UML2.0)
Le diagramme de collaborations sous une forma distincte du
diagramme des squences reprsente les interactions entre classes en
mettant moins en vidence laspect temporel
Ce modle explique la coopration entre objets pour la ralisation
dune fonctionnalit, cette coopration implique les diffrents
vnements qui se propagent dun objet un autre. Un objet doit
avoir une mthode approprie pour traiter chaque vnement quil
reoit (message).
Laspect temporel nest pas compltement cach car chaque message
est numrot.
2
1
3
5
6
192

Le diagramme de collaboration (communication UML2.0)
Exemple : systme de rgulation de vitesse (suite)
Diagramme de collaborations
paramtres
ordre
1.1: calcul ()
message
1: calculerNouveauCouple()
dmarrer
monReg: Rgulateur
Sens de lappel
/pl(0):loiDeCtrl
1.2: cpl
1.3: fixerCouple (cpl)
monMoteur/pM : Moteur
193

Le diagramme dtat-transition
Prsentation gnrale et concept de base

Inspirs des statecharts de D. Harel et incluent des concepts des machines
de Moore et de Mealy.
Modlisent des aspects contrle et temps des systme
Un (ou plusieurs) diagramme E/T dcrivent le comportement dune classe,
mais ils peuvent aussi dcrire le comportement dun Cas dutilisation, dun
acteur, dun sous-systme ou dune mthode.
Un objet fournit un contexte pour lexcution de la machine dfinissant sa
classe
Certains systmes (ou parties de systmes) sont purement fonctionnels (sans
mmoire : fonction sinus) dautres ont un mode de fonctionnement continu
(sans tats : filtre digital)
Les machines tats sont utiles pour dcrire des objets/classes exhibant un
comportement complexe, ractif et ayant plusieurs interactions avec
lenvironnement.
194

Les oprations possibles dans les tats et les

vnements
E1
entry/ action en entre de ltat
do/ activit pendant ltat
vnement1/ action1
vnement2/ action2
exit/ action en sortie
vnement [garde]/action
E2
195

Evnements (Triggers)
- Un vnement est associ une transition, son metteur nest pas spcifi,
le traitement de lvnement est li ltat courant
- Occurrence dune situation dans le domaine du problme
- Instantan et porteur dinformations :
NomTrigger(par1: type1,parn: typen)
- Peut correspondre un message du diagramme de squences
196

Types de triggers
Appel : appel dopration (message du D.S.). Strotypes: <<Cre>> et
<<Dtruit>>. La cration provoque la transition initiale
La dtection dune situation particulire dans lenvironnement

Une certaine condition devient vraie : Persiste lorsque lexpression
redevient fausse. Syntaxe : quand (Expression boolenne)
Temporel : coulement dun instant temporel relatif ou absolu. Syntaxe
: aprs (x secondes) : x secondes aprs laccs ltat courant. aprs
(x secondes partir de y). quand (date= un instant)
Trigger signal : provoque une raction asynchrone sans rponse
Arrt
Allumage()
Marche
Demande
aprs(3s)
Serv. occup
197

Actions
Traitement atomique instantan (ininterruptible run-to-completion semantic)
pouvant manipuler ltat, tiquetant une transition (Gnration de signaux,
cration dobjet, appel de mthodes, manipulation de proprits ou de liens,)
Chaud
/A2
/A1
E
/A2
/A1
/A2
Surchauffe
E
Entry/ A1
Exit/ A2
Evnt(info) / A
/A1
HausseT(t)/EteindreBruleur()
Evnmt(info) / A
198

Activits
- Traitement associ un tat et ayant une dure
- Lorsque le traitement nest pas termin et quun vnement validant une
transition se produit, il est interrompu
- Lorsque le traitement se termine sans occurrence dvnements, le systme
reste en attente dans ltat.
- Lorsque la transition nest pas tiquet le systme quitte ltat la fin du
traitement
- Ne peuvent pas changer ltat de lobjet concern par la machine
Do Activit
199

Liens avec le diagramme de squences

Diagramme de squence peut se voir comme un chemin dans un diagramme
tat/transition
X
Msg1
Etat
Msg2
vnement
200

Liens avec le diagramme de squences (suite)

: Systme
Ali
Dcroche
Emet La
Attente
Dcroche
Tonalit
Compose
*[nbr]Compose chiffre
Composition
Compose
Recherche
Connexion
Communication
201

Composition et dcomposition dtat-transition

Il est possible de dcrire un diagramme tat-transition plusieurs niveaux
hirarchiques. Ainsi un premier niveau, le diagramme comprendra des
tats lmentaires et des tats composites. Les tats composites seront
ensuite dcrits un niveau lmentaires dans un autre diagramme.
Enregistr/contrl
Reu
Contrl/dcider
Contrl
accept
Symbole de reprsentation
dun tat composite
202

Etat composite
Etat composite
E1
E1
E2
E5
E2
E5
E3
E4
E4
E3
203

Point de jonction
Lorsque lon veut relier plusieurs tats
vers dautres tats, un point de jonction
permet de dcomposer une transition en
deux parties en indiquant si ncessaire
les gardes propres chaque segment de
la transition. A lexcution, un seul
parcours sera emprunt, cest celui pour
lequel toutes les conditions de garde
seront satisfaites.
Points de choix
le point de choix se comporte comme un
test de type : si condition faire action1 si
non faire action 2.
Message vocal
reu
[typeMessage=vocal]
A/R
Message vocal
[typeMessage=sms]
A/R
Message SMS
Message SMS
reu
[typeMessage=Fax]
A/R
Message Fax
Message Fax
reu
Message mobile reu/

Message vocal activer A/R
reu
Message mobile reu/
Message SMS activer A/R
reu
Message Fax
reu
Message mobile reu/

activer A/R
A/R mobile
[typeMobile]
[else]
A/R Fax
204

Concurrence
- dcomposition conjonctive (et), les sous-tats sont groups en rgions
- Le systme est dans plusieurs sous-tat simultanment
- une garde peut prendre la forme [in state X] (synchronisation)
- Lentre dans un tat conjonctif correspond lentre vers tous les tats
initiaux, la sortie fait sortir de toutes les rgions
A
U
W
205

Forme conjonctive et forme disjonctive

Une dcomposition conjonctive peut tre transforme en dcomposition
disjonctive
e1
Z,A
X
e3
e2
e4
e1
Y
Z,B
e3
e3
e4[in state Z]
e1
B
X,B
X,A
e1
e1
Y,B
e2
206

Etat historique
permet de mmoriser le dernier sous tat visit.

Lentre dans un tat ne se fait pas au niveau de ltat
initial mais du dernier tat visit lors
dune entre prcdente.
Exemple
Machine laver
207

Machines tats-transitions
tat composite
concurrent
Rgion orthogonale
E1
tat initial
E11
H
Historique
E12
E2
E8
E21
entry/a1; a2 ;
exit/a3 ;
activity/a4 ; a5 ;
E22
Jonction
Paralllisme
Label dune transition
tat final
e1[g]/p()
vnement
dclencheur
Actions dentre dans E8

Actions de sortie dans E8
Activit de E8
E5
E3
E4
Garde logique
Procdure
Choix
dynamique
E6
E7
E9
Choix
dynamique
208

Prsentation gnrale et concepts de base

Le diagramme dactivit prsente un certain nombre de points communs avec
le diagramme dtat-transition puisquil concerne le comportement interne des
oprations ou des cas dutilisation. Cependant le comportement vis
sapplique aux flots de contrle et aux flots de donnes propres un ensemble
dactivits et non plus relativement une seule classe.
Les concepts commun ou trs proche
entre le diagramme dactivit et le
diagramme dtat-transition sont :
- Transition
nuds initial (tat initial)
nud final (tat final)
nud de fin flot (tat de sortie)
-
nud de dcision (choix)
Les concepts spcifiques au

diagramme dactivits sont :
nud de bifurcation
nud de jonction
nud de fusion
pin dentre et de sortie
flot dobjet
partition
209

Action :
Une action correspond un traitement qui modifient ltat du systme.
Cette action peut tre apprhende soit un niveau lmentaire proche
dune instruction en termes de programmation soit un niveau plus global
correspondant une ou plusieurs oprations.
Saisir commande
Transition et flot de contrle

Ds quune action est acheve, une transition automatique est dclenche
vers laction suivante. Il ny a donc pas dvnement associ la transition.
Lenchainement des actions constituent le flot de contrle
transition
Action 1
Action 2
210

Activit
Une activit reprsente le comportement dune partie du systme en termes dactions et de
transitions. Une activit est compos de trois types de nuds :
Nud dexcution (action, transition)
Nud de contrle (nud initial, nud final, flux de sortie, nud de bifurcation, nud de
jonction, nud de fusion-test, nud de test-dcision, pin dentre et de sortie)
Nud dobjet
Une activit peut recevoir des paramtres en entre et en produire en sortie
Activit : traiter commande
Saisir
commande
Contrler
commande
diter
commande
211

Nud de bifurcation (fourche)
Rception paiement
Un nud de bifurcation permet partir dun flot unique

entrant de crer plusieurs flots concurrents en sortie de la
barre de synchronisation.
comptabiliser
Envoyer marchandise
Nud de jonction (synchronisation)

Un nud de jonction permet, partir de plusieurs flots
concurrents en entres de la synchronisation,
Inscrire adhrent
de produire un flot unique sortant.
Enregistrer cotisation
Envoyer carte adhrent
212

Facturer
particulier
Nud de test-dcision
Un nud de test-dcision permet de faire
un choix entre plusieurs flots sortants en
fonction des conditions de garde de
chaque flot. Un nud de test-dcision na
quun seul flot en entre.
Nud de fusion-test
Un nud de fusion-test permet davoir
plusieurs flots entrants possibles et un seul
flot sortant. Le flot sortant est donc
excut ds quun des flots entrants est
activ.
[particulier]
Saisir
commande
[grossiste]
Facturer
grossiste
Commander
Par tlphone
Commander
Par messagerie
Facturer
Commander
Par courrier
213

Pin dentre et de sortie
Pin dentre
Un pin dentre ou de sortie reprsente un

paramtre que lon peut spcifier en entre
ou en sortie dune action. Un paramtre
peut tre de type objet.
Pin de sortie
p1
facturer
r1
P2
Flot de donnes et nud dobjet

Un nud dobjet permet de reprsenter le
flot de donns vhicul entre les actions.
Facturer
Commander
:commande
Commander
[commande]
:commande
Facturer
214

Partition
UML permet aussi dorganiser la
reprsentation du diagramme
dactivit en couloir dactivits.
Chaque couloir correspond un
domaine de responsabilit dun
certain nombre dactions
Client
Service commercial
Stock
Demander
produit
Rechercher
produit
Contrler
stock
Commander
Enregistrer crer
commande
[Commande]
crer
Facturer
[Facture]
215

Reprsentation dactions de
communication
Dans un diagramme dactivit des interactions de
communication lies certains types
dvnements peuvent se reprsenter.
Les types dvnement concerns sont :
Signal
coulement du temps
Signal reu
Ouvrir portes
Dtecter arrive
vhicule
Actionner
ouverture
Faire clignoter
lampe
Signal envoy
Acceptation dune
Condition lie au
temps
216

Exemple :
Diagrammes dactivits
monCapt.acquerirVitesse(Vit:Vitesse)
[Vit=consigne]
[Vit<>consigne]
tat avec action dappel dopration

acqurirVitesse de lobjet monCapt
avec paramtre vit de type Vitesse
Point de choix
tat atteint ds que laction du prcdent
tat est termine si vit diffrente de consigne
calculerNouveauCouple
Paralllisation
du flot de contrle
pM.fixerCouple(cpl)
Couple
[Valide]
calculerVariationVitesse
MiseA_JourOK
Attente de la rception
Dun signal de type
MiseA_jourOK
Synchronisation
du flot de contrle
mettreA-JourAffichage
Attente de la disponibilit du flot dobjet
Couple dans ltat Valide, avant de
Rejoindre ltat daction suivant
217

Le diagramme global dinteraction

Le diagramme global dinteraction permet de reprsenter une vue gnrale des
interactions dcrites dans le diagramme de squence et des flots de contrle
dcrits dans le diagramme dactivit.
Le diagramme global dinteraction est un diagramme dactivit dans lequel on
reprsente des fragments dinteraction ou des utilisateurs dinteractions
Le diagramme global dinteraction utilise les concepts du diagramme dactivit
auquel on ajoute deux complments :
Sd interaction
client
commande
Les fragments dinteractions

du diagramme de squence
Les utilisateurs de fragments dinteraction : il est aussi possible de faire appel des
fragments dinteraction laide de loprateur ref
ref
Nom du fragment
218
Diagramme global dinteraction
Sd Diagramme global : Utilisateur, systmeContrle
ref
Activer systmeContrle Accs
sd
utilisateur
SystmeContrle
contrlerCode
Contrler OK
sd
utilisateur
SystmeContrle
Message Entrer
ref
ouvrirPorte
219


Le diagramme de temps permet de reprsenter les tats et les interactions
dobjets dans un contexte o le temps a une forte influence sur le
comportement du systme grer.
Autrement dit, le diagramme de temps permet de mieux reprsenter des
changements dtats et des interactions entre objets lis des contraintes de
temps.
Le diagramme de temps utilise en plus des lignes de vie, les concepts
suivants :
Des tats ou des lignes de temps conditionnes avec deux reprsentations
graphiques possibles
Des reprsentations propres aux aspects temporels : chelle de temps,
contraintes de dure, vnements
220

Exemple de diagramme de temps avec reprsentation en escalier
:pompe eau
Sd chauffage vapeur
Vapeur demande
Et rserve eau
insuffisante
Rserve eau
suffisante
activ
:chauffage eau
dsactiv
activ
dsactiv
{t..t+3}
Timer t
221

Exemple de diagramme de temps avec reprsentation linaire
:chauffage eau
:pompe eau
Sd chauffage vapeur
Vapeur demande
et rserve eau
insuffisante
dsactiv
dsactiv
activ
Rserve eau
suffisante
dsactiv
activ
dsactiv
{t..t+3}
timer t
222
Etude de cas :
Machine de vente de produits comestibles
Machine de vente de produits comestibles
Valeur-pice
Dtecteur de
pices
Leurre
Libre_pice
Rendre_pice
Contrleur du
Distributeur
Cmd_Moteur
annulation
Affichage
Choix-client
Interface utilisateur
Sortie
caisse
223
Diagramme des cas dutilisation

uc Use Case Mo...
Controleur de distributeur
Obtenir_paiement
secondary
Detecteur_Piece
Lev ier_Commande
extend
Le Detecteur_Piece est activ par

l'introduction d'un objet par le Cilent
Rendre_Monnaie
Obtenir Choix
secondary
extend
Magasin_Piece
extend
include
Client
Deliv rer_Produit
secondary
Moteur
224

Description des cas dutilisation
Use Case : Obtenir_paiement

Condition de dclenchement : Introduction d'un objet
Squence nominale
Le systme incrmente le total introduit par la valeur de la pice, Il

positionne le levier de commande sur caisse et commande la libration de
la pice
Squence exceptionnelle
a-Si l'objet introduit est un leurre le systme positionne le levier commande sur
sortie et commande la libration de l'objet
b- Si le client appuie sur le bouton annulation le systme droule le C.U
Rendre_Monnaie
225

Use Case : Obtenir_Choix

Condition de dclenchement : Le client a fait un choix de produit
Squence Nominale
1 - Le systme vrifie la disponibilit et le prix du produit
2 - Le systme droule cas d'utilisation "Dlivrer_Produit"
Squence alternative
1-a Lorsque le produit est indisponible le systme affiche le message "Produit
non disponible" et droule le cas d'utilisation Rendre_Monnaie
1-b - lorsque le montant est insuffisant le systme se met en attente d'autres
pices et affiche le message "Montant insuffisant"
A tout moment Lorsque le client appuie sur le bouton annulation le

systme droule aussi le cas d'utilisation Rendre_Monnaie
226

Use Case : Dlivrer_produit

Condition de dclenchement : Un montant suffisant est introduit et le
produit est disponible
Squence Nominale
Le systme dtermine le plateau contenant le produit demand
Il commande la rotation du moteur correspondant.
Il droule le C.U. Rendre_Monnaie pour rendre l'excdent
227

Use case : Rendre_Monnaie

condition de dclenchement : annulation ou dlivrer produit
Squence nominale :
Aprs avoir excuter le CU "dlivrer_produit" dfinir l'excdent rendre
Traduire excdent rendre en vecteur image du magasin pices
commander magasin pices par le vecteur image correspondant
Squence alternative :
Si annulation traduire excdent rendre en vecteur image du magasin pices
commander magasin pices par le vecteur image correspondant
228
Diagramme des classes

class Class Mo...
Lev ier_Commande
Entree_Pieces
+ SetPosition(boolean) : void
+ Leurre() : boolean
+ PieceIntroduite(CodePiece)
Retour_Piece
Magasin_Pieces
-
Detecteur_Pieces
+ LibererPieces() : void
Interface_Utilisateur
Compte_Client
ImagePieces: tab
+ CMDTrappe() : void
+ Rendre(int) : void
+ Affichage_Total() : void
+ AffichageMsg() : void
Compte: int
+ Incrementer(int) : int
+ RAZ() : int
+ Valeur() : int
Produit
Liste_Prod
Controleur_Demande
Moteur_Plateau
+ RetrouverInfo(Code) : Produit
+ Tourner() : void
Cette classe ralise la
livraison du produit
1..*
+
+
+
+
Annuler() : void
DeterminerMoteur() : void
DeterminerReste() : void
Traiter(int) : void
signal
+ annuler() : void
+ PiceIntroduite() : void
1..* +
+
+
+
Code: int
NoPlateau: int
Prix: int
Quantit: int
DECQte() : void
Getcode() : Code
GetPlateau() : NoPlateau
GetPrix() : Prix
229
sd Obtenir Paiment
Dtecteur Pices
opt Pice v alide
Entre Pices
Compte Utilisateur
Interface
Utilisateur
Levier De
Commande
PiceIntroduite(Valeur)
INCR(Montant)
Afficher_Total()
Set_Position(Position)
LibrerPieces()
opt Pice non v alide
Leurre()
Set_Position(Position)
LibrerPiece()
230
sd Squence Globale
Detecteur
Pices
Interface
Utilisateur
Controleur de
Demande
Liste
Produit
Levier de
commande
Produit
Compte
Moteur
Plateau
Retour
Pices
Magazin
Pices
par
ref
Obtenir Paiment
Traiter(Choix )
RetrouverInfo(Code)
Get*()
:InfoProduit
Valeur()
:Compte
alt
[Quantit >= 1 && !Annuler]
alt
[Compte>=Prix]
DeterminerReste()
DECRQte()
DeterminerMoteur()
Tourner()
opt
Rendre(Reste)
[Reste>0]
SetPosition()
cmdTrappe(Tableau)
[Compte<Prix]
[Quantit=0 || Annuler]
AfficherMessage()
Rendre(Compte)
SetPosition()
cmdTrappe(Tableau)
231
stm Class Mo...
Initial
Repos
[Pice Introduite]
Attente
[(Annuler) ou (Quantite=0)]
/Rendre(Compte)
[Traiter Choix]
/RetournerInfo
[Reste=0]
[Si Reste>0]
/Rendre(Reste)
Traitement Choix
[(Quantite>=1) et (Compte>Prix)]
/DCRQte
Determiner Moteur
Determiner Reste
Deliv rer
+
do / TournerMoteur
232

lEmbarqu
1.
2.
3.
4.
5.
6.
7.
Introduction
Rappels dUML
Mta-modlisation
Les profils UML
sur UML
233

Les caractristiques temps rel qualitatives regroupe
les trois aspects :
- La concurrence (ou le paralllisme)
- La communication
- Le comportement (inclut en particulier une partie actions)
Caractristiques temps rel quantitatives
234

Caractristiques temps rel qualitatives
1. Modlisation de la concurrence
Il est possible de dcrire la concurrence en UML diffrents
niveaux de granularit :
Au niveau des classes active : proprit isActive : boolean
Au niveau comportemental dans les machines tats via
des tats concurrents
Au niveau des oprations via un attribut de contrainte
spcifique.
235

Concurrence et objets actifs
Les objets actives dUML sont les instances de classes actives (proprit de classe :
isActive). Ils possdent leur propre ressource dexcution, sexcutent
concurremment avec les autres objets actifs et possdent des mcanismes de contrle
des invocations qui leur arrivent qui prservent lintgrit de lobjet contre des
invocations concurrentes.
Objet actif
Obj:MyActiveClass
MyActiveClass
{active}
Classe active
Les objets passifs sexcutent dans lespace dadresse et sous le contrle de lobjet
actif qui contrle lobjet qui fait appel leurs comportements (oprations, ..).
En complment UML dfinit deux variantes dobjets actifs via les strotypes
process et thread qui spcifient le type de flot de contrle attachs une classe
active.
236

Concurrence et machine tats
Dans UML, la modlisation de la concurrence peut
aussi se dfinir au sein dune machine tat. Deux
moyens sont disponibles :
Les tats concurrents composites
E1
E11
E12
Les activits internes un tat (do-activity)

Rgions concurrentes
E1
Do/act1()
E11
Do/act2()
237

Concurrence des oprations
Proprit concurrecy : sadresse plutt aux classes passives.
Sequential : un seul appel une opration de ce type doit tre trait un instant
donn, mais aucun mcanisme de protection par dfaut. lintgrit de lobjet
nest pas garantie.
Guarded : lobjet ne peut galement traiter quun seul appel la fois, lobjet
garantit cette srialisation par exclusion mutuelle
Concurrent : plusieurs appels doprations peuvent sexcuter concurremment et
lobjet garantie son intgrit dans ce cas.
En plus de ses caractristiques de concurrence, une opration peut possder un
attribut appel isQuery
isQuery concerne limpact de lexcution de lopration sur ltat de lobjet : Sil
est vrai (true), une excution de lopration laisse ltat de lobjet inchang. Sinon
(false), lexcution peut provoquer des modifications sur ltat de lobjet.
Regulateur
Dmarrer (sp : integer); {concurrency = sequentiel}
Arrter() ; {isQuery=true}
238

2. Modlisation des communications

Quelle que soit la mthodologie oriente objets utilises, lapplication
dveloppe est constitue de diffrents objets interagissant afin de raliser
une tche. Cette collaboration entre objets est appele en UML : interaction
La communication dans UML est base sur le paradigme de message.
messages dUML : appel dopration, envoi de signal, cration ou
destruction dobjet (instance).
Une communication par message peut tre synchrone ou asynchrone et
peut transporter des paramtres dentre, de sortie ou dentre-sortie.
Un message possde un metteur et un rcepteur. Lmetteur est une
instance de classe qui aprs avoir excut une action spcifique gnre
lenvoi de ce message.
239

Envoi de message par appel dopration
Une opration en UML est un service offert par un
objet qui peut tre requis depuis un autre objet afin de
raliser un comportement. Une opration possde une
signature qui dcrit les paramtres qui peuvent tre
passs lopration lors de son appel (ventuellement
valeurs de retour)
Regulateur
Dmarrer (vit : integer)
Arrter()
La concurrence modlises avec les contraintes {concurrency},

attribut isQuery Celui-ci concerne limpact de lexcution de lopration
sur ltat de lobjet.
240

Quest-ce quimplique la rception dun tel appel ?

La rception dun appel dopration peut :
Soit tre interprte sous la forme dun vnement dappel dclenchant
une transition dans une machine tats (dans ce cas le rcepteur ralise
la squence dactions spcifies sur la transition qui peut tre
dclenche) ;
Soit tre perue comme un appel dopration classique, cest--dire
dclenchant lexcution dune mthode donne dcrivant le
comportement de lopration appele.
241

Envoi de message par mission de signal
Un signal modlise toujours une communication asynchrone.
Le concept de signal de UML peut convoyer des paramtres et peut tre

spcialis ou gnralis dans un arbre dhritage. Toutefois, un signal est
classifier spcifique qui ne peut pas avoir dopration ni de relation
dassociation avec un autre classifier (classe, acteur, signal, etc.).
Un signal est associ aux classes
prvues pour sa gestion travers la
dclaration
dune
rception
compartiment additionnel marqu par

le strotype Signals o seront
dclars les diffrents types de signaux
pouvant tre reus par la classe.
MaClasse
signals
Alarme (IN z:Zone)
MarcheArrt()
242

Envoi de message par mission de signal (suite)
Comment gnre-t-on un signal ?

Lenvoi dun signal est effectu laide dune primitive daction particulire qui
dirige vers un ensemble de destinataires identifis, soit explicitement, soit
implicitement (typiquement vers toutes les instances de classes sachant grer la
rception de ce type de message).
Quest-ce quimplique la rception de signal ?

La rception dun signal est vue par une instance comme un vnement dclencheur
de transition qui est stock dans une file gre par la machine tats dcrivant le
comportement de la classe de linstance rceptrice.
Comme pour la communication par appel dopration, la communication par signal
soulve quelques questions sur les spcificits de sa smantique :
Les objets passifs peuvent-ils recevoir des signaux ?
Quels types de paramtres peuvent tre vhiculs par un signal ? In, out, inout?
Ces questions ncessitent des rponses de manire viter des interprtations
ambigus des modles
243

3. Modlisation du comportement
La modlisation du comportement dune application est essentiellement
introduit dans UML travers les concepts suivants :
Les machines tats dcrivent le comportement dynamique dun
lment de modle. Il existent deux variantes de ces diagrammes tats :
les diagrammes dtats (State Diagrams) et les diagrammes dactivits
(Activity Diagrams).
Les interactions sont constitues dun ensemble de messages que
diffrents objets schangent afin de raliser une activit ou une tche
donne. Ce concept permet la description du comportement global du
systme. Il est galement exprim sous deux formes : les diagrammes
de collaboration (Collaboration Diagrams) et les diagrammes de
squence (Sequence Diagrams).
Les actions dfinissent le niveau le plus fin de modlisation du

comportement atteignable en UML. Elles sont spcifies par le chapitre
Action semantic de UML.
244

Description de la smantique des
machines tats-transitions de UML
Cette description repose sur une machine dexcution
hypothtique qui reprsente les trois caractristiques
suivantes :
Une file dattente dvnements qui sert

stocker les instances dvnements entrantes en
attendant de les consommer ;
Une politique de choix des vnements qui

dtermine lordre dextraction des instances
dvnement contenue dans la file dattente
Un processeur dvnements qui excute les

traitements associs aux vnements en respectant
la smantique des machines tats de UML et en
particulier, lhypothse dexcution Run-ToCompletion
Mcanisme de choix et de
distribution de lvnement
depuis la queue dvnements
son processeur associ
Queue dvnements
stockant les messages
entrants
UneClasse
Msg (liste_de_params
Processeur
dvnement
245

Description de la smantique des machine tats-transition de UML
Les vnements sont dplis un un la fois et consomms par une machines
tats-transitions. Lordre dans lequel ils sont dplis nest pas prcise dans UML.
Cest la charge de chaque mthode base UML de le prciser par son modle
dexcution. Ceci est un point de variation ouvert de la smantique de UML.
La smantique dexcution des vnements est base sur lhypothse Run-ToCompletion signifiant quun vnement ne peut tre dpli puis consomm que
lorsque le traitement de lvnement prcdent est achev. On parle de pas
RTC lorsque la machine tats-transitions passe dune configuration dtat
stable une autre configuration dtat stable. Un tat est dit stable lorsquil ne
reste plus dactions en cours dexcution. La notion de pas RTC permet
dviter dventuels problmes de concurrence pendant le traitement
dvnements et conduit srialiser les traitements au sein dune mme machine
tat-transitions.
Une fois toutes les actions termines, on dit que la machine a effectu un
pas RTC.
246

En ce qui concerne la concurrence , UML prcise que deux options de
dfinition du RTC sont possibles :
Soit lhypothse dexcution RTC est applique globalement lensemble de la
machine tats- transitions ;
Soit cette contrainte est relche et peut tre applique indpendamment
chaque rgion orthogonale, augmentant ainsi le niveau de concurrence possible
pour le traitement dvnements.
Toute mthode de modlisation temps rel en UML se doit donc de prciser

le choix retenu sur la smantique du RTC vis--vis des tats concurrents.
247

Les machines tat-transitions de UML offrent la possibilit de spcifier une
sorte de comportement automatique laide de transitions spcifiques appeles
completion-transitions . Ce type de transition ne possde pas dvnement
dclencheur explicite, mais peut avoir une garde. Elle est dclenche par un
vnement interne de la machine tats appel completion event .
La machine tat gnre implicitement cet vnement chaque fois quelle a
atteint un tat stable. Un tel vnement est consomm immdiatement ds quil
est gnr sans passer par la file dvnements de la machine tats-transitions,
sinon il est perdu. Si la configuration dtats courantes de la machine tats
possde une transition de completion sortante, le tirage de cette transition est
prioritaire vis--vis de toute autre transition mergeante de cet tat. De plus, si
un tat possde plusieurs transitions de completion, elles doivent tre
mutuellement exclusives de manire assurer quune seule sera effectivement
active. Dans le cas contraire, il y aura une situation indtermine quant la
dynamique de la machine.
248

Diagrammes dactivits
Le diagramme dactivit prsente un certain nombre de points communs avec le diagramme
tats-transitions puisquil concerne le comportement interne des oprations ou des cas
dutilisation. Cependant le comportement vis ici sapplique aux flots de contrle et aux flots
de donnes propres un ensemble dactivits et non plus relativement une seule classe.
Les diagrammes dactivit sont dcrits en termes dtats et de transitions o un tat est
attach une action donne ou une sous-activit reprsentant des activits embots.
Les tats actions sont quitts lorsque laction spcifie est termine. Les tats daction ne
doivent pas avoir de transition interne, ni de transition sortante dclenche par un vnement
explicite, ni daction dentre ou de sortie. Cela signifie que les transitions sont toujours
dclenches par lvnement implicite completion de ltat action dont elle merge . Des
lments complmentaires permettent de prciser sous quelles conditions la transition peut
tre tire :
Les expressions de garde usuelles
La disponibilit dun objet (flot dans un tat donne)
Loccurrence dun signal, dans ce cas, une notation spcifique est attach ltat cible o
la rception du signal est dfinie comme une action atomique
En outre, les diagrammes dactivit permettent de modliser des activits concurrentes et
fournissent les notations associes de paralllisation et de synchronisation
249


UML dfinit deux types de donnes relatives au temps :
Time dfinit une valeur reprsentant un moment absolu ou

relatif du temps ;
TimeExpression permet de spcifier des expressions dont
lvaluation donne une valeur de type Time
Ces donnes peuvent intervenir, en particulier, dans trois types
de diagrammes : les diagrammes dtats, les diagrammes de
squence et le diagramme de temps (UML2)
250

Modlisation de proprits temporelles dans les diagrammes
dtats
Dans le contexte des diagrammes dtats, UML dfinit un vnement
spcifique appel TimeEvent. Il sert modliser lexpiration dune chance
qui peut tre relatif ou absolue :
Un vnement dnotant le passage dune quantit de temps suite
lentre dans ltat contenant la transition est not avec le mot-cl after
suivi dune expression de type TimeExpression qui dnote la valeur
temporel de lvnement ;
Un vnement dnotant loccurrence dune date absolue est not via le
mot-cl when suivi dune date absolue de type Time
251

Exemple de spcification dvnements temporels
Modlisation des vnements temporels
after (10ms)/procedure
Lvnement est gnr 10 ms aprs la date

dentre dans ltat S
after(10ms after the exit of S)/procedure
Lvnement est gnr 10 ms aprs la date de

sortie de ltat S
when(1er janvier 2000, 0h00)/procedure
Lvnement est gnr le 1er janvier 2000

0h00
Description
252

Dans les trois cas du tableau, lorsque le temporisateur arm arrive chance, il
gnre un vnement qui est stock comme tout autre vnement dans la file
dattente associe la machine tats. Si celle-ci est ltat S au moment o
lvnement temporel est slectionn, lvnement est consomm et la transition est
tire. Dans le cas contraire, lvnement temporel est perdu. Contrairement au
autres vnements, les vnements temporels ne peuvent tre diffrs, cest--dire
ajouts la liste des vnements de type defered .
La date doccurrence dun vnement temporel est la mme que sa date de
rception. Cependant, il faut noter quil peut exister un dlai variable et
difficilement mesurable entre la date dmission dun vnement temporel et le
moment auquel il est pris en compte par lobjet rcepteur. En effet, ce dlai est la
consquence de la politique de stockage et de traitement mise en uvre par chaque
approche pour grer la file des vnements reus.
253

Modlisation de proprit temporelles
dans les diagrammes de squence
Le deuxime type de diagramme de UML, particulirement appropri pour la spcification
des systmes temps rel est le diagramme de squence. En effet, un diagramme de squence
possde deux dimensions :
Laxe horizontale qui contient les objets impliqus dans linteractions dcrite dans le
diagramme ;
Laxe verticale qui reprsente le temps. Le temps progresse dans le sens descendant de
cet axe mais sans quil lui soit attach de mtrique.
O1
O2
En rgle gnrale, dans les diagrammes de squence de
UML, on suppose que le dlai de transmission des
messages changs entre les objets de lapplication, ce
C:m3
qui explique que les flches symbolisant les changes
sont horizontales. Cependant, si pour une raison
particulire, lutilisateur ne peut pas se satisfaire de
cette hypothse, il peut incliner vers le bas la flche de
Dlai de propagation
message pour modliser le dlai de transmission de
de message non
message.
ngligeable
254

Modlisation de proprit temporelles
dans les diagrammes de squence
pour faciliter lexpression de ces contraintes de temps, UML

introduit un certain nombre de fonction temporelles ddies
la manipulation du temps dans les changes de messages
raliss dans les diagrammes de squence, comme :
sendTime (date denvoi dun message) et
receiveTime (date de rception dun message).
Lutilisateur peut en adjoindre de nouvelles pour des besoins
spcifiques.
Pour spcifier une contrainte de temps dans les diagrammes

de squence, UML propose deux solutions :
via une cotation sur le diagramme ou
via lexpression de contraintes
quelle que soit la technique de reprsentation du temps
adopte, les moyens proposes par UML ne sont que des
artifices de notation qui demande tre intgrs dans une
approche mthodologique complte prcisant parfaitement
leur smantique et les interactions avec le reste des modles.
Label du
message
O1
O2
a:m1
b:m2
<1sec.
Cotation temporelle
{b.sendTime-a.receiveTime<1sec.}
Contrainte temps-rel
255

Modlisation de proprits temporelles dans le
diagramme de temps (1/2)
Le diagramme de temps permet de reprsenter les tats et les interactions
dobjets dans un contexte o le temps a une forte influence sur le
comportement du systme grer.
Autrement dit, le diagramme de temps permet de mieux reprsenter des
changements dtats et des interactions entre objets lis des contraintes de
temps.
Le diagramme de temps utilise en plus des lignes de vie, les concepts
suivants :
Des tats ou des lignes de temps conditionnes avec deux
reprsentations graphiques possibles
Des reprsentations propres aux aspects temporels : chelle de temps,
contraintes de dure, vnements
256

Modlisation de proprits temporelles dans le diagramme de temps (1/2)
257

Limitations dans UML2.0
Limitations dUML vis--vis du temps rel

- Manque de concepts pour exprimer les contraintes et
proprits temps rel
o Priodes, chance, date de rveil, dure dexcution, priorit, laxit,
- Pas de structures de communications assez volues :

o Ports, connecteurs, protocoles, smaphores
- Pas de techniques dordonnancement proposes

o Round-Robin, FCFS, RM, DM, EDF, LLF,
- Pour les messages, notion de file dattente mais pas de notion

avec/sans crasement
- Pas de rflexion sur la dcomposition en tche

- Expression du temps : pas de temps vrai units de temps
258

Ncessit dtendre UML de faon normalise
Le temps rel nest pas le seul domaine concern par les lacunes
dUML
Suivant le contexte dans le quel on se place, ce ne sont pas les mmes
notions qui font dfaut
Ordonnancement = expression des rythmes, temps absolu, temps considr
comme global, ordonnanceurs, hirarchies dordonnanceurs, calculateurs,
abstraction du rseau en tant que medium de communication en temps born,
etc.
Calcul des dure des traitements = dcoupage du processeur, mmoires,
mmoires caches, instructions, etc.
Rparti = dcoupage du temps synchronisation dhorloges, etc.
Etc.
Solution propritaire = tre li un seul outil/diteur de logiciel

Besoin dune solution normalise simplement implmentable sur
(tous) les ateliers logiciels
Utilisation des mcanismes standards dextension dUML Profil UML
259

lEmbarqu
1.
2.
3.
4.
5.
6.
7.
Introduction
Rappels dUML
Mta-modlisation
Les profils UML
sur UML
260
Mta-modlisation
Introduction/Plan
But de la mta-modlisation
Dfinir des langages de modlisation ou des langages de
manires gnrales
Architecture MOF
4 niveaux de (mta)modlisation
Architecture 4 niveaux gnralisables en dehors du MOF
Syntaxes abstraites et concrte

261
Normes OMG de modlisation

MOF : Meta-Object Facilities
Langage de dfinition de mta-modles
UML : Unified Modelling Language

Langage de modlisation
CWM : Commun Warehouse Metamodel

Modlisation ressources, donnes, gestion dune
entreprise
OCL : Object Constraint Language

Langage de contraintes sur modles
XMI : XML Metadata Interchange

Standard pour changes de modles et mta-modles
262
Normes OMG de modlisation

Plusieurs de ces normes concernent la dfinition et
lutilisation de mta-modles :
MOF : but de la norme
UML et CWM : peuvent tre utiliss pour en dfinir
XMI : pour change de (mta)-modles entre outils
MOF
Cest un mta-mta-modle
Utiliser pour modliser des mta-modles
- Dfinit les concepts de base (22)

Entit/classe, relation/association, type de donnes, rfrences,
package,
- Le MOF peut dfinir le MOF

263
4 Niveaux du MOF
Le MOF dfinit 4 niveaux de modlisation
M0 : systme rel, systme modlis

M1 : modle du systme rel dfini dans un certain langage
M2 : mta-modle dfinissant ce langage
M3 : mta-mta-modle dfinissant le mta-modle
Le niveau M3 est le MOF
Dernier niveau, il est mta-circulaire : il peut se dfinir lui-mme
Le MOF est pour lOMG le mta-mta-modle

unique servant de base la dfinition de tous les
mta-modles
264
4 Niveaux du MOF
265
Hirarchie 4 Niveaux
On retrouve cette hirarchie 4 niveaux en dehors du MOF et
dUML, dans dautres espaces technologique que celui de lOMG
Langage de programmation :
M0 : lexcution du programme
M1 : le programme
M2 : la grammaire du langage dans lequel est crit le programme
M3 : le concept de grammaire EBNF
XML
M0 : donnes du systme
M1 : donnes modlises en XML
M2 : DTD XML
M3 : le langage XML
266
Mta-modlisation UML
Dans UML, on retrouve galement les 4 niveaux
Mais avec le niveau M3 dfinissable en UML directement la
place du MOF
Exemple de systme modliser (niveau M0)

Une pice possde 4 murs, 2 fentres et une porte
Un mur possde une porte ou une fentre mais pas les 2 la
fois
Deux actions sont associes une porte ou une fentre :
ouvrir et fermer
Si on ouvre une porte ou une fentre, elle devient ouverte
Si on ferme une porte ou une fentre ouverte, elle devient
ferme
267
Mta-modlisation UML
Pour modliser ce systme, il faut dfinir 2 diagrammes
UML : niveau M1
Un diagramme de classe pour reprsenter les relations entre
les lments (portes, murs, pices)
Un diagramme dtat pour spcifier le comportement dune
porte ou dune fentre (ouverte, ferme)
On peut abstraire le comportement des portes et des fentres
en spcifiant les oprations douverture fermeture dans une
interface (le diagramme dtat est associ cette interface)
Il faut galement ajouter des contraintes OCL pour prciser les
contraintes entre les lments dune pice
268
M1 : spcification du Systme
269
Mta-modlisation UML
Les 2 diagrammes de ce modle de niveau M1 sont des
diagrammes UML valides
Les contraintes sur les lments des diagrammes UML et
leurs relations sont dfinies :
Dans le mta-modle UML : niveau M2
Un diagramme UML (classe, tat ) doit tre conforme au mtamodle UML
Mta-modle UML
Diagramme de classe spcifiant la structure de tous
types de diagrammes UML
Avec contraintes OCL pour spcification prcise.
270
M2 : Mta-modle UML (simplifi)
271
Mta-modlisation UML
Le mta-modle UML doit aussi tre prcisment dfini
Il doit tre conforme un mta-modle
Cest le mta-mta-modle UML
Quest ce que le mta-modle UML ?

Un diagramme de classe UML (avec contraintes OCL)
Comment spcifier les contraintes dun diagramme de

classe ?
Via le mta-modle UML
Ou plus prcisment : via la partie du mta-modle UML
spcifiant les diagrammes de classes
Mta-mta-modle UML = copie partielle du mtamodle UML : niveau 3

272
M3 : mta-mta-modle UML (simplifi)
273
Syntaxe
Un langage est dfini par un mta-modle
Un langage possde une syntaxe respectant le mtatmodle
Syntaxe textuelle
Ensemble de mot-cl et de mots respectant des contraintes
dfini selon des rgles prcises (notions de syntaxe et de
grammaire dans les langages)
Syntaxe graphique
Notation graphique, chaque lment a une forme graphique
particulire (exemple : associations entre classes/interfaces
sur les diagrammes de classes UML
association
dpendance
implmentation
spcialisation
274
Syntaxe abstraite/concrte
Syntaxe abstraite/concrte :
Abstraite
Les lments et leurs relations sans une notation spcialise
Correspondant ce qui est dfini au niveau du mta-modle
Concrte
Syntaxe graphique ou textuelle dfinie pour un type de modle
Plusieurs syntaxes concrtes possibles pour une mme syntaxe
abstraite
Un modle peut tre dfini via nimporte quelle syntaxe

Labstraite
Une des concrte
MOF : langage pour dfinir des mta-modles

Pas de syntaxe concrte dfinie
275
Syntaxe : exemple diagramme dtat
276

lEmbarqu
1.
2.
3.
4.
5.
6.
7.
Introduction
Rappels dUML
Mta-modlisation
Les profils UML
sur UML
277
Profils UML
Un profil est une spcialisation du mta-modle UML
Ajouts de nouveaux types dlments et des contraintes sur leurs
relations entre eux et avec les lments dUML
Ajouts de contraintes sur les lments existants dUML
Ajouts de contraintes sur les relations existantes entre les lments
dUML
Aucune suppression de contraintes ou dlments
Profil : mcanisme dextension dUML pour ladapter un

contexte mtier ou une technique particulire
Profil pour composants EJB

Profil pour gestion bancaire
Profil pour architecture logicielle
Profil pour les systme temps rel embarqus
.
278
Mcanismes standards dextension

dUML
UML fournit 4 mcanismes dextension du langage :
Les notes :
Apport dun commentaire nayant aucune consquence sur la
smantique du modle
Les strotypes
Cration de nouveaux concepts UML partir des concepts standard
Les tiquettes (tagged values)
Extension des proprits associes un concept UML
Les contraintes (exprimable en OCL)
Extension de la smantique dun concept UML en ajoutant de
nouvelles rgles ou en modifiant les anciennes
Un profil UML est dfini sous la forme dun package

strotyp profile
279
Mcanismes standard dextension

dUML
UML fournit dj des strotypes, des tiquettes et des
contraintes standard
Strotype : extend, use, import, executable, process, thread,
tiquette : persistance, smantique,

Contrainte : sous-ensemble, ordonn, ou, disjoint, chevauchement,
complte,
UML permet de dfinir ses propres strotypes, tiquettes et

contraintes
280
Mcanismes dextension standard

dUML
Note (dfinition)
Une note est un commentaire textuel ou graphique que lon
attache un lment ou un ensemble dlments
Une note ne modifie pas la smantique du modle
Elle est reprsente par un rectangle corn li par un ou plusieurs
traits pointills aux lments quelle commente
281

dUML
Strotype (Dfinition)
Un strotype est une chane de caractre qui associe un lment
UML existant permet de dsigner un nouveau type dlment UML
Un strotype apparat entre guillemets prs du nom de llment
strotyp
On peut reprsenter un strotype au moyen dune nouvelle icne
282

dUML
Etiquette (Dfinition)
Une tiquette est une chane de caractres qui associe un lment

UML permet de lui ajouter une proprit et sa valeur associe
Ltiquette apparat entre {accolade} et prcise le nom de la proprit et
sa valeur
Utiles pour la gnration de code ou la gestion de configuration
283

dUML
Contraintes (Dfinition)
Une contrainte est une chane de caractres qui associe un lment UML
permet dajouter de nouvelles rgles ou de modifier des rgles existantes
La contrainte apparat entre {accolade} et dfinit la rgle appliquer
On peut utiliser du texte informel ou recourir lutilisation dun langage
plus prcis comme OCL (Object Contraint Language)
284
Les Profils UML ddis aux SETR

Les Profils UML ddis aux systmes embarqus et au
temps rel
SPT : Schedulability, Performance and Time
QoS and FT : QoS and Fault-Tolerant
MARTE : Modeling and Analysis of Real-Time and Embedded
systems
TURTLE : Time-UML RT-Lotos Environment
OMEGA : Modlisation et validation des systmes temps rel
Embedded UML : Approche pour le co-design
hardware/software en temps rel
285

lEmbarqu
1.
2.
3.
4.
5.
6.
7.
Introduction
Rappels dUML
Mta-modlisation
Les profils UML
sur UML
286
Le Profil UML MARTE

En fvrier 2005, lOMG a vot la RFP (Request For Proposals). Cette demande
de propositions portait sur un profil UML pour la modlisation et lanalyse des
systmes temps rel et embarqu (UML profile for Modeling and Analysis of
Real Time and Embedded systems). Un consortium appel proMARTE a
soumis une proposition qui a t adopte le 29 juin 2007.
Le profil UML MARTE a pour objectif dtendre UML pour lutiliser dans une
approche de dveloppement dirig par les modles de systmes temps rel et
embarqus.
MARTE fournit des supports pour les tapes de spcification, de conception et de
vrification/validation .
Les retombes attendues de lusage de ce profil sont de :

Fournir une modlisation unifie pour les parties matrielles et logicielles du systme
Permettre linteroprabilit entre les outils de dveloppement utiliss en spcification, en
conception , en vrification et en gnration de code
Faciliter la construction de modle sur lesquels on peut faire des prvisions quantitatives
tenant compte des caractristiques du matriel et du logiciel.
287
Le Profil UML MARTE

Architecture globale de la dcomposition en paquetages du profil MARTE
288
Le Profil UML MARTE

Le profil est structur suivant deux directions :
La modlisation des concepts des systmes embarqus temps-rel
MARTE design model
Lannotation des modles dapplications pour supporter lanalyse des
proprits systmes MARTE analysis model
Ces deux parties majeures partagent des concepts communs, groups

dans MARTE foundations pour exprimer :
-
Des proprits non fonctionnelles (NFPs)

Des notions de temps (Time)
La modlisation des ressources (GRM)
Des composants (GCM)
Des lments dallocation (Alloc)
Un paquetage additionnel contient les annexes du profil dfinie en

MARTE, aussi bien que les librairies prdfinies
289
Architecture globale du Profil UML MARTE

Intgre le VSL la dfinition
de paramtres. Prcise les
comportements et introduit
La notion de mode de
fonctionnement
Non-functionnel Properties :
Dfinitions de types de base
Et dunit de temps, de dbits,
Dnergie ainsi que les relations
entre units (1s = 1000 ms)
Notion dhorloge (logique, discrte,

Continue, )
Allocation dentits des

Generic Resource Modelling : Ressources
(allocation spatialeDf. de ressources logicielles
mmoire, de calcul,
(ex: scheduler) et matrielle
un ordonnanceur, etc.)
(ex: processeur)
MARTE foundations
profile
CoreElements
Generic Component Model
Profil orient composants
(inspir dAADL)
High Level Application
Modeling : dfinit les modules
RtUnit, PpUnit, RtAction, etc.
Software/Hardware Ressource
Modeling : dfinition utiles pour
La modlisation des supports
Dexcution (RTOS, processeur)
profile
NFP
profile
Time
MARTE design model

profile
GCM
profile
SRM
profile
HLAM
profile
HRM
profile
GRM
MARTE analysis model
Generic Quantitative Analysis

Modeling : modles de base pour
Ltude de performances et
lordonnancement RMA
profile
GQAM
profile
SAM
profile
PAM
Schedulability Analysis
Modeling : dfinit des
proprits dordonnanabilit
(but => utiliser dans un
outil dordonnancement)
Performance Analysis
Modeling : proprits
Pour ltude de performances
oriente rseaux
MARTE annexes
profile
VSL
profile
Alloc
profile
RSM
modelLibrary
MARTE_library
290
MARTE design model

MARTE design model
A travers ce paquetage, MARTE fournit des concepts de plus haut niveau pour
modliser les exigences quantitatives et qualitatives des STR.
"Generic Component Model " (GCM) : permet de dcrire les systmes base de
composants. Il prend en charge les protocoles de communications orients
messages et donnes entre les composants.
" High-Level Application Modeling " (HLAM) : fournit des concepts de
modlisation de haut niveau pour traiter les caractristiques quantitatives telles
que lchance et la priode ainsi que les caractristiques qualitatives lies au
comportement, la communication et la concurrence
"Software Resource Modeling " (SRM) : ce paquetage spcifie un ensemble
dartefacts de modlisation qui facilite la description de la structure du support
dexcution comme le systme dexploitation temps rel utiliss lors de
lexcution de systme multi-tches
" Hardware Resource Modeling " (HRM) : ce paquetage est utilis pour spcifier
les plateformes matrielles. Il est dcrits par deux vues complmentaires :
logique et physique. La vue physique classifie les ressources matrielles en se
basant sur leurs proprits physiques. La vue logique classifie les ressources
291
matrielles en se basant sur leurs proprits fonctionnelles.
"MARTE analysis model"

MARTE analysis model
Ce paquetage offre des abstractions spcifiques et des annotations pertinentes
interprtables par des outils danalyse. Il fournit des valuations fiables et
prcises laide de techniques danalyse quantitatives formelle base sur des
modles mathmatiques. Il est divis en trois sous-paquetages :
"Generic Quantitative Analysis Modeling " (GQAM) : fournit les concepts pour
effectuer une analyse quantitative de proprits non fonctionnelles associes au
modle. Ces concepts portent sur lanalyse de lordonnancement et de
performance
"Schedulability Analysis Modeling " (SAM) : Cest un raffinement du paquetage
GQAM afin de pouvoir effectuer des analyses dordonnanabilit sur les modles
de conception. Il aide prvoir si le systme analyser a la capacit rpondre
certaines contraintes temporelles, comme le respect des chances et le temps
de rponse.
"Performance Analysis Modeling " (PAM) : Cest un raffinement du paquetage
GQAM pour supporter une analyse de performance. Il fournit des moyens pour
dterminer si un systme peut fournir une performance adquate en vertu de
conditions comportementales non-dterministes, bases sur des valeurs
statistiques.
292
Le Package de temps de MARTE

Le paquetage de temps de MARTE est dcompos en 4 souspaquetages :
TimeStructure : rassemble les concepts dfinissant le modle de temps
constitu densembles dinstants, les instants tant partiellement
ordonns. On y trouve en particulier le concept de Clock
Time Access : regroupe les moyens daccs la structure de temps
TimeValueSpecification : permet de dnoter instants et dures
TimeUsage : introduit les lments de modlisation couramment
utiliss :
vnements temporels
Comportements temporels
Contraintes temporelles
293
Le sous-paquetage TimeUsage
Le sous-paquetage "TimeUsage", qui dfinit les entits lies au
temps, contient lui-mme six paquetages :
"TimedElement" : le concept dlment temporel est trs gnral. Il
exprime quun lment de modle est li au temps via un ou plusieurs
horloges. La mtaclasse correspondante est abstraite. Les spcialisations concrtes de cette mtaclasse prcisent la smantique de leur
association avec les horloges.
294
"TimedEvent"
TimedEventOccurrence : Des instants peuvent tre associs aux occurrences dun
vnement. MARTE introduit le concept doccurrence dvnement temporel qui
est la fois un lment temporel et une occurrence dvnement. La proprit at
spcifie la valeur dinstant dune occurrence de l(vnement considr. Puisque
plusieurs horloges peuvent tre rfrences (proprit on de llment temporel),
plusieurs valeurs dinstants sont possibles pour la mme occurrence.
Gnralement une seule horloge est retenue.
SimultaneousOccurrenceSet : MARTE introduit un nouveau concept, celui
densemble doccurrences simultanes. Ce concept est indispensable quand
plusieurs vnement doivent tre considrs collectivement car leurs effets ne
peuvent pas tre rduits la srialisation des effets de chacun. Un ensemble
doccurrence simultane est une occurrence (EventOccurrence est une
gnralisation de SimultaneousOccurrenceSet. Du point de vue UML, cet
ensemble peut causer une excution de comportement
295
Occurrence dvnements temporels
296
TmedEvent : un vnement temporel est un vnement dont les occurrences
sont lies au temps via une horloge. Les occurrence dun vnement temporel
sont spcifies par les proprits attaches au TimedEvent.
Lattribut isRelative indique si la valeur temporelle donne par when est relative
ou absolue
La proprit when est une valeur temporelle qui prcise linstant doccurrence.
Cette valeur est une valeur dinstant sil sagit dun temps absolu ; cest une dure
dans le cas contraire
La proprit optionnelle every permet de caractriser les ventuelles occurrences
suivantes du mme vnement. Lorsquelle dfinit, la proprit every est la valeur
de la dure qui spare deux occurrences successives
Lattribut repetition permet, si ncessaire, de limiter le nombre doccurrence
297
Evnements temporels
298
TimeProcessing :
TimedExecution : Une excution temporelle est un lment de
modle qui spcialise une excution de comportement
(BehaviorExecution).
En tant qulment temporel une excution temporelle fait
rfrence une ou plusieurs horloges. Deux valeurs dinstants :
"startInstant" et "finishInstant" sont associes une excution.
Une excution peut tre caractrise par une dure. Une
transmission de message peut tre assimile une excution ; la
valeur dinstant de dbut est alors celle de linstant dmission, la
valeur dinstant de fin tant celle de linstant de rception.
299
Excutions temporelles
300
TimedProcessing : le traitement temporel est un concept gnrique
pour modliser des activits qui ont des instants de dbut et de fin
connus ou une dure. De fait, la donne de deux de ces trois
informations est suffisante pour caractriser une excution
particulire.
Ce concept sapplique immdiatement aux comportements
(TimeBehavior). Il stend facilement aux actions (TimeAction) qui ne
sont pas en UML des comportements, mais des nuds dactivits
primitifs dont lexcution entrane une modification de ltat du
systme ou le retour dune valeur.
Il stend galement aux messages (TimedMessage) ; les vnements
de dbut et de fin sont nomms vnements dmission et de
rception respectivement.
Le retard (Delay) est une action temporelle particulire qui reprsente
une action ne faisant rien mais qui a une dure
301
Traitements temporelles
302
TimedObservation
Une observation temporelle est un TimedElement. Elle est donc associe
explicitement une ou plusieurs horloges. Une observation temporelle
peut rfrencer une excution dun systme ou dune partie dun systme
(CompBehviorexecution) qui sert de contexte pour cette observation
303
TimedObservation (suite)
TimedObservation est une superclasse abstraite pour tre diffrentes pour
lobservations dinstants (TimedInstantObservation) et les observations de
dures (TimedDurationObservation)
lattribut obsKind permet de spcifier le type dvnement considr dans
lobservation temporelle.
Pour un comportement, les vnements observs peuvent tre le dbut (start)
ou la fin (finish) dune excution.
Pour une requte, les vnements, les vnements possibles sont : son mission
(send), sa rception (receive) ou sa prise en compte par le rcepteur (consume).
Puisquune observation dinstant dnote un instant, une occurrence
dvnement est observ sur une horloge donne (proprit eocc).
Dans le cas dune observation de dure, il existe plus de possibilits :
Observation de la dure dexcution (proprit exc)
Lobservation de la dure dune requte, ou plus exactement de sa transmission ou le
retard de sa prise en compte (proprit stim)
304
TimedConstraint
une contrainte temporelle (TimedConstraint) est la fois un lment
temporel et une contrainte impose sur les occurrences dun
vnement (TimedInstantConstraint) ou sur la dure dune excution
ou mme sur la distance temporelle entre deux vnements
(TimedDurationConstraint).
Les contraintes sont spcifies par des prdicats qui contiennent des
usages dobservations temporelles
305
Analyse de lordonnanabilit :
Le package SAM de MARTE
Le sous profil SAM de Marte est destin proposer une
analyse d'ordonnanabilit des systmes temps rel
laide des annotations standardises, qui compltent des
modles UML.
Ce sous profil contient trois packages de bases :
SAM_Workload pour la modlisation de la partie fonctionnelle dun
systme temps rel (les tches, les proprits temporelles, les
relations de dpendances de donnes, etc),
SAM_Resources pour exprimer la partie matrielle (les ressources
dexcution et les ressources de communication) et
SAM_Observers qui permet dannoter et comparer les contraintes
temporelles contre les prdictions fournis par les outils d'analyse.
306
Le Package SAM_Workload
307
Modlisation des ressources Matrielles:

Le Package HRM de MARTE
Le sous profil HRM de MARTE permet de modliser les ressources matrielles
dune plateforme dexcution. Ces ressources matrielles sont rparties en cinq
packages :
Hw_computing : Ressources de calcul ; comprenant lensemble des ressources
fournissant des services dexcution comme les processeurs, les ASIC (Application
Specific Integrated Circuit) ou les PLD (Programmable Logic Device),
Hw_storage : Ressources de mmorisation ; comprenant lensemble des ressources
fournissant des services de mmorisation (persistantes ou non) comme les mmoires
RAM, les caches ou les disques durs,
Hw_Communication : Ressources de communication ; comprenant lensemble des
ressources fournissant des services de transfert de donnes comme les bus ou les
passerelles,
Hw_Timing : Ressources de temps ; comprenant lensemble des ressources
fournissant des services daccs au temps comme les horloges,
Hw_Device : Ressources auxiliaires ; comprenant lensemble des ressources
fournissant des services daccs aux lments extrieurs du systme comme les
ressources dentre / sortie ou les senseurs.
308
Le Package HRM
309
Modlisation dassociation :
Le Package Alloc de MARTE
Ce mta-modle sert placer des lments dapplication sur les ressources
disponibles. Un Marte allocation est une association entre une application et
une plate-forme dexcution.
Lensemble de toutes les allocations du modle dfinit le placement complet.
Le concept principal est reprsent par le strotype Allocated , utilis pour
spcifier des associations entre les lments du modle de lapplication et des
lments du modle de larchitecture.
310
Illustration: Encodeur JPEG

Lencodeur JPEG (Joint Photographic Experts Group) pour la compression
dimages est compos de sept tapes :
Le processus de compressions JPEG accepte en entre une image brute partir

dun priphrique dentre (camra).
la premire tape du processus de compression consiste dcouper limage en
blocs de (8*8) soit 64 pixels.
chaque bloc de pixels est applique une transformation de couleur en luminance
et chrominance.
Ensuite, une transformation DCT est applique chaque bloc de pixels afin
dexprimer les informations de limage en terme de frquence et damplitude.
Le flux de compression passe par la suite par ltape de quantification qui est la base
de la compression.
Lapplication du codage de Hauffman la matrice rsultante de ltape de
quantification amne enfin une image compresse.
311
Modlisation du comportement
fonctionnel
312
Modlisation du comportement
fonctionnel
Le flux de bout en bout de lapplication est instanci JPEG par le strotype
saEndtoEndFlow. Les cinq tches ; rgb, dct, qu, hu et re sont strotypes
SaStep et sont excutes squentiellement (chaque comportement dpend
de celui qui le prcde), par exemple la premire instance dct du composant
DisCoSTran ne peut tre active avant que la premire instance rgb du
composant RGB2YUV soit traite. De la mme manire, les autres instances
(qu, hu, re) sont actives.
Ceci nous permet de dduire des contraintes fonctionnelles, imposes au
niveau application. Ces contraintes reprsentent un ordre dexcution des
tches.
Pour chaque tche la date limite dexcution est indique par la proprit
deadline. Le port dentr ayant la direction in (image brute) et le port de
sortie ayant la direction out (image compress).
Contrainte : Nous souhaitons avoir un dbit de compression de 15 images par
seconde pour un encodage JPEG dimages de taille (256*256) pixels. Cela
signifie que la dure maximale pour encoder une image est de 0.066 secondes.
313
Modlisation de larchitecture
matrielle
314
Modlisation de larchitecture
matrielle
La figure prcdente illustre le modle darchitecture considr dans lexcution
de lapplication JPEG.
Trois units de calcul sont dfinies pour traiter les diffrents composants
fonctionnels de lapplication JPEG.
Les instances cpu_1 et cpu_2 sont strotypes hwProcessor et lunit de
traitement programmable FPGA est strotype hwPLD. Le modle mmoire
instanci Memory par le strotype hwRAM est dfini comme ressource de
stockage et de rcupration des donnes et des instructions du programme.
Lmetteur (linstance de composant Camera) et le rcepteur (linstance de
composant Screen) ont pour rle de produire et de consommer des pixels. Ils
sont respectivement strotyps hwSensor et hwActuator selon le profil Marte.
La communication entre les diffrents lments matriels est assure travers
un bus strotyp hwBus selon les concepts du profil Marte.
Nous fixons dans ce cas dtude les frquences des units de calcul comme suit :
cpu_1 300 MHZ, cpu_2 250 MHZ et FPGA 400 MHZ. Ces frquences sont
utiles pour calculer les facteurs vitesses (SF) des units de traitement et les
dures dexcution des tches.
315
Modlisation dassociation
Lassociation consiste laffectation de chaque composant fonctionnel
de l'application une ressource physique qui va prendre en charge
son excution.
Une bonne association, entre les composants logiciels et matriels,
permet de rduire considrablement le temps dexcution des
fonctionnalits de lapplication et de respecter les contraintes de
dpendances (ordre dexcution), afin de garantir le bon
fonctionnement du systme.
Un exemple dassociation est donne par la figure suivante :
la premire tche rgb est attribue lunit de calcul programmable
FPGA afin dacclrer le traitement.
La tche dct est associe au processeur cpu_1 et les tches qu, hu et re
sont affectes au processeur cpu_2 travers des connecteurs
strotyps allocated.
316
Modlisation dassociation
317
Outils de conception et danalyse des

performances et de lordonnancement
Comme le tmoigne le site web du profil MARTE
(http://www.omgmarte.org/node/31), il existe une panoplie
doutils pour dfinir les modles de conception conforme au
profil MARTE tels que : papurys, Rhapsody 7.5, MagicDraw 15.5
et Rationnal Software Architecture (RSA)
Afin deffectuer des analyses de performances et
dordonnancement, un pluging Eclipse a t dvelopp par
lquipe Thales RT afin de permettre un pont vers loutil Cheddar
318

Processing Schema for Analysis
319

320
Vrification dordonnanabilit
Nous faisons appel au framework de vrification Cheddar et lalgorithme
dordonnancement temps rel EDF afin de vrifier les proprits : utilisation
du CPU et le respect des chances.
Nous commenons par vrifier que le taux dutilisation du processeur cpu_1
est infrieur une borne suprieur, selon la politique dordonnancement,
dans notre cas cette borne est gale 1.
321

lEmbarqu
1.
2.
3.
4.
5.
6.
7.
Introduction
Rappels dUML
Mta-modlisation
Les profils UML
Les Processus de dveloppement pour les SETR bases
sur UML
322
Processus Unifi (Rappel)

Cours :
Conduite de projet
Mthode danalyse et de conception
Processus unifi
G. Picard, Ecole Nationale Suprieur des Mines
Saint-Etienne
Methodologie de Dveloppement objet : UP et
Agile
Christine Solnon, INSA de Lyon
323
Objectifs dun processus de

dveloppement (Rappel)
Un processus dfinit QUI fait QUOI, QUAND et
COMMENT pour atteindre un certain objectif
- Construction des modles dun ou de plusieurs
systmes
- Organisation du projet
- Grer le cycle de vie du projet de A Z
- Grer les risques
- Obtenir de manire rptitive des produits de
qualit constante
Activits de dveloppement (rappel)
Planification (tude de la faisabilit)

Spcification des besoins
Analyse (Spcification formelle)
Conception (Spcification technique)
Implmentation (Codage)
Tests unitaires
Intgration et tests
Livraison
Maintenance
Dveloppement (rappel)
Modle en cascade
Modle en V
Modle en Spirale
Processus Unifi Principes (1)

Il nexiste pas un seul processus de dveloppement,
ni de processus standard
CEPENDANT
des caractristiques essentielles peuvent tre mises
en avant :
- Itratif et incrmental
- Pilotage par les cas dutilisation
- Focalisation sur larchitecture
- Utilisation de patrons de conception (Design
Patterns)
329
Processus unifi Principe (3)

Pilot par les cas dutilisation
331
Processus Centr sur larchitecture

Plusieurs manires de voir un systme
333
Le processus 2TUP
Le processus 2TUP
Branche fonctionnelle
Les principales tapes de la branche fonctionnelle se prsentent comme
suit :
- Ltape capture des besoins fonctionnels produit le modle des besoins
focalis sur le mtier des utilisateurs. Elle qualifie, au plus tt le risque de
produire un systme inadapt aux utilisateurs. Cette phase a pour objectif
de dfinir :
La frontire fonctionnelle entre le systme considr comme une
boite noire et son environnement, cest le niveau contexte.
Les activits attendues des diffrents utilisateurs par rapport au
systme toujours envisag comme une boite noire, cest le niveau
cas dutilisation.
-
Ltape danalyse consiste tudier prcisment les spcifications

fonctionnelles de manire obtenir une ide de ce que va raliser le systme
en terme de mtier.
Le processus 2TUP
Branche technique
Les principales tapes de la branche technique se prsentent comme suit :
- Ltape capture des besoins techniques recense toutes les contraintes
sur les choix de dimensionnement et la conception du systme. Les
outils et le matriel slectionns ainsi que la prise en compte des
contraintes dintgration avec lexistant (pr requis darchitecture
technique). Cette tape permet de dfinir le modle danalyse
technique. Le rle de ce dernier est dtablir les couches logicielles et y
spcifie les activits techniques attendues.
- Ltape conception gnrique dfinit ensuite les composants
ncessaires la construction de larchitecture technique. Cette
conception est compltement indpendante des aspects fonctionnels.
Elle permet de gnrer le modle de conception technique ou design
pattern qui dfinit les Frameworks. Ces derniers, dlivrant les services
techniques, assurent la rponse aux exigences oprationnelles du
systme.
Le processus 2TUP
Branche conception - ralisation
Les principales tapes de cette branche se prsentent comme suit :
- Ltape conception prliminaire est une tape dlicate, car elle intgre le
modle danalyse fonctionnelle dans larchitecture technique de manire
tracer la cartographie des composants du systme dvelopper. Cette tape
permet de produire le modle de conception systme. Ce dernier organise
le systme en composants, dlivrant les services techniques et fonctionnels.
Ce modle regroupe les informations des branches technique et
fonctionnelle.
Ltape conception dtaille permet dtudier comment raliser chaque

composant. Cette tape produit le modle de conception des composants.
Ce modle fournit limage prte fabriquer du systme complet. Cest dans
ltape de codage que seffectue la production des composants et les testes
des units de code au fur et mesure de leur ralisation.
Ltape de recette consiste valider les fonctionnalits du systme

dvelopp.
Les Processus de dveloppement

pour les SETR
- ROPES : Rapid Object-oriented Process for Embedded Systems
- UML-RT (ROOM) : UML Real Time (Real-time Oriented
Modeling)
- ACCORD/UML : Ingnierie des modles pour le dveloppement
de systmes temps re embarqus
- UML/SDL : UML / Software Descrption Langage
342
Processus de dveloppement pour les SETR

La mthodologie ROPES
Le cycle de vie ROPES
343

Les diffrentes tapes cycliques
- Analyse
- Analyse des besoins
- Analyse du systme Architecture
- Analyse objet
- Conception
- Conception architecturale
- Conception mcaniste
- Conception dtaille
- Translation Implmentation
- Tests
344

La phase dAnalyse
- Analyse des besoins
- Identification des exigences et besoins du client
- Analyse au niveau des vues fonctionnelles du systme
Diagramme dutilisation, de squence, dtats-transitions
- Analyse du systme Architecture

- Proposer une vision de larchitecture fonctionnelle du systme
Diagramme de composants, de dploiement
- Analyse objet
- Identification des objets et des classes essentielles ainsi que leurs proprits
Diagramme de classes, de collaborations, de squences
345

La phase de Conception
- Conception architecturale
- Identification et caractrisation des threads
- Dfinition des composants logiciels et leurs distributions
- Application de design patterns pour la gestion des erreurs, de la scurit,
Diagramme des classes, dobjets, de composants, de dploiement
- Conception mcaniste
- Raffinement des objets (contrleurs associs aux objets, )
Diagramme de collaborations, de classes, dobjets
- Conception dtaille
- Dfinition de la structure interne de chaque classes, message, opration,
Diagramme de classes, de collaborations,
346

Les phases de Translation et de test
- La phase de translation implmentation
- Passage des modles conceptuels au code concret
- La phase de test
- Tests dintgration
- Tests de validation
347

lEmbarqu
1.
2.
3.
4.
5.
6.
7.
Introduction
Rappels dUML
Mta-modlisation
Les profils UML
Les Processus de dveloppement pour les SETR bases
sur UML
348
Les outils pour le dveloppement des SETR
349
Les outils pour le dveloppement des SETR
350

2ème Partie CSTR 2014

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

2ème Partie CSTR 2014

Uploaded by

Copyright:

Available Formats

2me Partie : UML pour le Temps Rel et

de plus en plus rapidement avec des cots toujours plus

Les approches classiques dites structures :

Rutilisation et volutivit deviennent des exigences essentielles

De mieux en mieux comprises et outilles

2me Partie : UML pour le Temps Rel et

UML a t accept comme standard par lOMG (Object Management

Description du fonctionnement dynamique des lments du systme :

Description au niveau systme

Exemple machine danesthsie

Exemple machine danesthsie

Nom : Grer alarme

Exemple machine danesthsie : scnario dun cas

Exemple machine danesthsie : scnario dun cas

Exemple : systme de rgulation de vitesse

Diagramme de cas dutilisation

Diagramme des classes

But du modle dynamique

Dfinir les tats des objets qui dterminent une raction

Description de laspect dynamique du systme

Prsentation gnrale et concept de base

Description de laspect dynamique du systme

Prsentation gnrale et concept de base (suite)

Message synchrone et asynchrone

Description de laspect dynamique du systme

Retour message 3()

Description de laspect dynamique du systme

Description de laspect dynamique du systme

Oprations particulires (suite)

Des contraintes de chronologie entre les messages

Description de laspect dynamique du systme

Description de laspect dynamique du systme

Type de fragment dinteraction

Oprateur alt : correspond un oprateur de test avec une ou plusieurs

Description de laspect dynamique du systme

Type de fragment dinteraction (suite)

Description de laspect dynamique du systme

Type de fragment dinteraction (suite)

Description de laspect dynamique du systme

Type de fragment dinteraction (suite)

Oprateur beak permet de reprsenter une situation exceptionnelle

Description de laspect dynamique du systme

Type de fragment dinteraction (suite)

Description de laspect dynamique du systme

Description de laspect dynamique du systme

Description de laspect dynamique du systme

Description de laspect dynamique du systme

Description de laspect dynamique du systme

Prsentation gnrale et concept de base

Description de laspect dynamique du systme

Les oprations possibles dans les tats et les

exit/ action en sortie

Description de laspect dynamique du systme

Description de laspect dynamique du systme

La dtection dune situation particulire dans lenvironnement

Description de laspect dynamique du systme

Description de laspect dynamique du systme

Description de laspect dynamique du systme

Liens avec le diagramme de squences

Description de laspect dynamique du systme

Liens avec le diagramme de squences (suite)

Description de laspect dynamique du systme

Composition et dcomposition dtat-transition

Description de laspect dynamique du systme