Beruflich Dokumente
Kultur Dokumente
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
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.
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
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
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
Les diffrents Diagrammes dUML2.0
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
Les diffrents Diagrammes dUML2.0
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
Les diffrents Diagrammes dUML2.0
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.
Rappels dUML
Les diffrents Diagrammes dUML2.0
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
Rappels dUML
Description au niveau systme
ECG
Grer
Alarmes
Administrer
Anesthsiant
Suivre signes
vitaux
Traceur
Patient
Ventiler
Patient
Systme danesthsie
169
Rappels dUML
Description au niveau systme
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
Description au niveau systme
Exemple machine danesthsie : scnario dun cas dutilisation
Rsum :
Prconditions :
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
Description au niveau systme
Rappels dUML
Description au niveau systme
173
Rappels dUML
Description de larchitecture logique
Maintenir la vitesse
Marche/Arrt
Moteur
Dmarrer
Arrter
CompteurDeVitesse
174
Rappels dUML
Description de larchitecture logique
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
Description de laspect dynamique du systme
177
Rappels dUML
Description de laspect dynamique du systme
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
Sd nom du diagramme
Reprsentation du diagramme
179
: objet1
: objet2
: objet3
: Client
Message 1()
Message 2()
Possession
du contrle
Message 3()
Ligne de vie
Message 4()
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
Rsoudre()
Dlai
t1
{t2-t1 <2s}
t2
183
: Gestionnaire
Interface
IHM
Client
saisirCommande()
contrlerClient()
Seq ContrleProduit
Produit
contrlerExistenceProduit
ExisteProduit()
184
: Gestionnaire
SaisirAdhrent()
contrlerEtat()
alt EtatEmprunt
[tatemprunt=rendu]
autoriserEmprunt()
[tatemprunt= non rendu]
refuserEmprunt()
185
: Gestionnaire
relancer()
testerArelancer()
retourSituationRelance
opt Relancer
[si relance]
Relancer()
186
Traitement A1 et A2 mens
En parallle au traitement B3
par
:classe3
:classe2
TraiterA1()
TraiterA2()
traiterB3()
187
:classe3
:classe2
critical
Op1()
Op2()
Op3()
189
:classe2
:classe3
: Gestionnaire
saisieIdContrat()
contrlerDroitContrat()
ref
Contrle des droits
190
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
3
5
6
192
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
vnement [garde]/action
E2
195
196
Types de triggers
Appel : appel dopration (message du D.S.). Strotypes: <<Cre>> et
<<Dtruit>>. La cration provoque la transition initiale
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
X
Msg1
Etat
Msg2
vnement
200
Ali
Dcroche
Emet La
Attente
Dcroche
Tonalit
Compose
*[nbr]Compose chiffre
Composition
Compose
Recherche
Connexion
Communication
201
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 Fax
reu
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
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
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
tat final
e1[g]/p()
vnement
dclencheur
E5
E3
E4
Garde logique
Procdure
Choix
dynamique
E6
E7
E9
Choix
dynamique
208
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
Action 2
210
Saisir
commande
Contrler
commande
diter
commande
211
Rception paiement
Envoyer marchandise
Enregistrer cotisation
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
Pin de sortie
p1
facturer
r1
P2
Commander
:commande
Commander
[commande]
:commande
Facturer
214
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
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
client
commande
Nom du fragment
218
ref
Activer systmeContrle Accs
sd
utilisateur
SystmeContrle
contrlerCode
Contrler OK
sd
utilisateur
SystmeContrle
Message Entrer
ref
ouvrirPorte
219
220
: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
: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
Obtenir_paiement
secondary
Detecteur_Piece
Lev ier_Commande
extend
Rendre_Monnaie
Obtenir Choix
secondary
extend
Magasin_Piece
extend
include
Client
Deliv rer_Produit
secondary
Moteur
224
226
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
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
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
Entre Pices
Compte Utilisateur
Interface
Utilisateur
Levier De
Commande
PiceIntroduite(Valeur)
INCR(Montant)
Afficher_Total()
Set_Position(Position)
LibrerPieces()
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
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
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
233
234
235
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
E1
E11
E12
E11
Do/act2()
237
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
Regulateur
Dmarrer (vit : integer)
Arrter()
240
241
MaClasse
signals
Alarme (IN z:Zone)
MarcheArrt()
242
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).
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
Une fois toutes les actions termines, on dit que la machine a effectu un
pas RTC.
246
247
251
after (10ms)/procedure
Description
252
253
Label du
message
O1
O2
a:m1
b:m2
<1sec.
Cotation temporelle
{b.sendTime-a.receiveTime<1sec.}
Contrainte temps-rel
255
256
257
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
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
MOF
Cest un mta-mta-modle
Utiliser pour modliser des mta-modles
4 Niveaux du MOF
Le MOF dfinit 4 niveaux de modlisation
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
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
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
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
275
276
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
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
280
281
282
Etiquette (Dfinition)
283
284
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
286
288
Non-functionnel Properties :
Dfinitions de types de base
Et dunit de temps, de dbits,
Dnergie ainsi que les relations
entre units (1s = 1000 ms)
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
profile
HLAM
profile
HRM
profile
GRM
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
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
Le sous-paquetage TimeUsage
"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
Le sous-paquetage TimeUsage
Occurrence dvnements temporels
296
Le sous-paquetage TimeUsage
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
Le sous-paquetage TimeUsage
Evnements temporels
298
Le sous-paquetage TimeUsage
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
Le sous-paquetage TimeUsage
Excutions temporelles
300
Le sous-paquetage TimeUsage
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
Le sous-paquetage TimeUsage
Traitements temporelles
302
Le sous-paquetage TimeUsage
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
Le sous-paquetage TimeUsage
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
Le sous-paquetage TimeUsage
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
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
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
318
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
Introduction
Rappels dUML
UML2.0 et le temps rel
Mta-modlisation
Les profils UML
Les profils ddis aux SETR : le profil UML MARTE
Les Processus de dveloppement pour les SETR bases
sur UML
8. Les outils de dveloppement UML pour les SETR
322
Dveloppement (rappel)
Modle en cascade
Dveloppement (rappel)
Modle en V
Dveloppement (rappel)
Modle en Spirale
331
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.
-
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.
342
343
- 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 objet
- Identification des objets et des classes essentielles ainsi que leurs proprits
Diagramme de classes, de collaborations, de squences
345
- 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
- La phase de test
- Tests dintgration
- Tests de validation
347
Introduction
Rappels dUML
UML2.0 et le temps rel
Mta-modlisation
Les profils UML
Les profils ddis aux SETR : le profil UML MARTE
Les Processus de dveloppement pour les SETR bases
sur UML
8. Les outils de dveloppement UML pour les SETR
348
349
350