1. Introduction
2. Rappels d’UML
3. UML2.0 et le temps réel
4. Méta-modélisation
5. Les profils UML
6. Les profils dédiés aux SETR : le profil UML MARTE
7. Les méthodologies de développement des SETR basées
sur UML
8. Les outils de développement UML pour les SETR
156
2ème Partie : UML pour le Temps Réel et
l’Embarqué
• Il y’a une explosion du marché des systèmes embarqués, temps réel
et distribués, qui provoque une pression extrêmement forte sur leur
développement.
développement de plus en plus rapidement avec des coûts toujours plus
réduits (notion Time-to Market)
• Les approches classiques dites « structurées » :
Simplicité due à l’approche totalement descendante
Une modification des bords profondes modifications de la modélisation
Absence du concept de composants : réutilisabilité faible d’un projet à
un autre
• Réutilisation et évolutivité deviennent des exigences essentielles
pour les méthodes et techniques de développement.
Introduction
157
• Approche objet : modélisation du monde réel et du monde métier par des classes/objets regroupés sous forme de composants réutilisables Prise en main plus complexe, temps de spécification/conception plus
long
Mais moins influencées 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 outillées
Interface de + en + automatisées de transformations de modèles/génération de code
Effort de normalisation important
Mais toujours une « jungle » de normes, langages outils, CASE158
Introduction
1. Introduction
2. Rappels d’UML
3. UML2.0 et le temps réel
4. Méta-modélisation
5. Les profils UML
6. Les profils dédiés aux SETR : le profil UML MARTE
7. Les méthodologies de développement des SETR basées
sur UML
8. Les outils de développement UML pour les SETR
159
2ème Partie : UML pour le Temps Réel et
l’Embarqué
Rappels d’UML
• UML (Unified Modeling Language) est un langage graphique pour la conception objet, utilisé pour :– Spécifier
– Visualiser
– Construire
– Documenter
• UML offre :– Une représentation indépendante de tout langage de programmation et de
toute méthode de développement
– Une analyse des besoins
– Un support de modélisation du comportement
• UML a été accepté comme standard par l’OMG (Object Management Group) en 1997
160
161
Rappels d’UMLHistoire
162
diagramme
Diagramme
d’activités
Diagrammes
Comportementaux
Diagramme des
cas d’utilisations
Diagramme
d’états
Diagrammes
d’Interactions
Diagramme
De séquences
Diagramme de
Structures
composites
Diagrammes
Structurels
Diagramme
d’Objets
Diagramme
des Classes
Diagramme
de composants
Diagramme de
Déploiements
Diagramme
des paquetages
Diagramme de
Vue d’ensemble
des Interactions
Diagramme de
communication
Diagramme
temporel
Rappels d’UMLLes différents Diagrammes d’UML2.0
Description au niveau système des besoins utilisateurs supporté
par les diagrammes de cas d’utilisation
Transition vers l’objet
163
Rappels d’UMLLes différents Diagrammes d’UML2.0
« include »
cas1
cas3
cas2
Approche ObjetApproche
FonctionnelleSystème
Cas2
Cas3 Cas X
FonctionFonctionFonctionCas 1 Fonction Fonction
FonctionFonction
A B
ED
G
C
F
Cas2
Cas1
Cas3
Description de la structure et de l’architecture logique (logicielle) du système :
Elle repose principalement sur
– les diagrammes des classes qui effectuent une typologie des entités constituant le système et qui précisent les relations entre ces différents types d’entités.
– diagrammes d’objets précisant quelles instances particulières des classes seront manipulées pour mettre en œuvre le système
– Les Paquetages définissent un espace de nommage permettant de regrouper des diagramme
164
Rappels d’UMLLes différents Diagrammes d’UML2.0
Description de l’aspect dynamique du système : vise deux
aspects :
– La description des interactions entre les objets du système à travers
les diagrammes de séquence et les diagrammes de collaboration
(communication pour UML2). Ces deux types fournissent une vue
gros grain de la dynamique du système centré sur les échanges entre les
objets qui l’implanteront.
– Description du fonctionnement dynamique des éléments du système :
elle repose principalement sur des machines à états. Elle peut être
précisée par des diagrammes d’activités précisant les flots de données
et de contrôle. Le diagramme de temps introduit par UML2 permet de
mieux représenter des changements d’états et des interactions entre
objets liés à des contraintes de temps.
165
Rappels d’UMLLes différents Diagrammes d’UML2.0
Description de la réalisation du système : elle
repose sur les diagrammes de composants et les
diagrammes de déploiement de ces composants sur
l’architecture matérielle supportant le système.
166
Rappels d’UMLLes différents Diagrammes d’UML2.0
Exemple : machine d’anesthésie
167
Rappels d’UMLDescription au niveau système
Exemple machine d’anesthésie
• Fonctionnalité principale : administrer au patient un mélange
de gaz (Oxygène + Nitrate d’oxyde + isoflurane) avec une
pression et un débit approprié
• Inclut un ventilateur et un dispositif de monitoring des signaux
vitaux du patient (Rythme cardiaque, pression sanguine,...)
• Inclut un vaporisateur qui permet de contrôler finement
l’addition de anesthésiant volatile au flux de gaz
• La composition des gaz administrés au patient doit être
contrôlée en temps réel
168
Description au niveau systèmeExemple : machine d’anesthésie
Exemple machine d’anesthésie
AdministrerAnesthésiant
ConfigurerSystème
Gérer Alarmes
Suivre signesvitaux
VentilerPatient
ECG
Traceur
Médecin
Patient
Système d’anesthésie 169
Rappels d’UMLDescription au niveau système
Configurer
Vaporisateur
Administrer
Anesthésiant
administrer
gaz
Mélanger gaz
« Sous-système »
Circuit respiratoire
Contrôler
concentration Calibrer Configurer
« Sous-système »
Monitoring agent anesthésiant
Configurer
Monitor agent
Configurer
Ventilateur« Sous-système »
Ventilateur
Appliquer ventilation
Monitorer
Circuit respiratoire
Administrer
médicament
Fixer paramètres
vaporisation
« Sous-système »
Vaporisateur
« include »
« Sous-système »
Interface utilisateur170
Rappels d’UMLDescription au niveau système
Exemple machine d’anesthésie : scénario d’un cas d’utilisation
• Résumé :
– Nom : Gérer alarme
– Acteur principal : Médecin; Acteurs secondaire : ECG, Traceur
– Objectif : Ce cas permet d’identifier les situations où il existe un danger pour le
patient et d’informer l’anesthésiste a fin qu’il réagisse de façon appropriée
• Préconditions :
– Le système a été configuré et initialisé correctement
– Les paramètres de la fonction d’alarme ont été fixés
– La fonction d’alarme est activée
• Enchaînements :
1. Lorsque une situation d’alarme se produit un message (contenant la date/heure
d’occurrence, le type de l’alarme, la source de l’alarme et la cause probable de
l’alarme) doit être affiché accompagné d’un signal sonore
2. Lorsque plusieurs alarmes se produisent simultanément, elles doivent être affichés
par ordre de criticité d’abord et par ordre d’occurrence (la plus récente en premier)
ensuite. 171
Rappels d’UMLDescription au niveau système
Exemple machine d’anesthésie : scénario d’un cas
d’utilisation (suite)
3. Les alarmes doivent nécessairement recevoir un accusé de réception de la part
des opérateurs qui appuient pour cela sur le bouton « Alarm Ack » une fois que
l’alarme s’est produite, même si les conditions de l’alarme n’existent plus
l’opérateur doit accuser réception de l’alarme.
4. Lorsque une alarme ne peut pas être affichée parce que des alarmes de priorités
supérieure occupent tout l’espace d’affichage, elle ne peut recevoir un accusé de
réception que lorsqu’elle a été affichée
5. Lorsque les conditions qui ont généré une alarme ont été corrigées mais
l’alarme n’a pas encore reçu d’accusé de réception, elle doit s’afficher en gris.
Les autres alarmes conservent leur couleur initiale
6. L’appui sur le bouton « Alarm Ack » pour une alarme à pour conséquence
d’interrompre le signal sonore mais n’a pas d’effet sur l’affichage.
L’interruption dure 2 minutes si avant la fin de l’interruption les conditions qui
ont provoqué de l’alarme ont disparue, l’alarme cesse d’être affichée sinon le
signal sonore reprend172
Rappels d’UMLDescription au niveau système
Exemple machine d’anesthésie : scénario d’un cas
d’utilisation (suite)
• Contraintes non fonctionnelles
– Contraintes temporelles
• Il ne doit pas s’écouler plus de 50 ms entre l’occurrence d’une situation
d’alarme et la signalisation de l’alarme
• La signalisation d’une alarme qui a reçu un accusé de réception s’interrompt
au plus pendant 2 minutes lorsque les conditions qui l’ont générées restent
présentes
173
Rappels d’UMLDescription au niveau système
Exemple : système de régulation de vitesseComposé :– d’un bouton marche/arrêt– d’un moteur sur lequel est appliquée la consigne de couple calculée par le système– d’un compteur de vitesse qui fournit la vitesse courante du véhicule au système
Diagramme de cas d’utilisation
174
Maintenir la vitesse
Démarrer
Arrêter
Marche/Arrêt
Moteur
CompteurDeVitesse
Rappels d’UMLDescription de l’architecture logique
Diagramme des classes
175
Regulateur Moteur
LoiDeCtr
1..1
1..*
pM>
pL>
Regulateur
Demarrer (vit:Integer);Arreter ();
Rappels d’UMLDescription de l’architecture logique
Modèle dynamiqueLe modèle dynamique montre le comportement
du système et l’évolution des objets dans le temps
Le modèle dynamique va identifier les différents événements venant du monde externe et montrer l’enchaînement dans le système que provoquent ces événements externes.
événement :
quelque chose se produit à un moment donné dans le temps, et qui n’a pas de durée. Exemple :
l’utilisateur décroche son téléphone
le conducteur appuie sur un bouton
176
Rappels d’UMLDescription de l’aspect dynamique du système
But du modèle dynamique
• Trouver les relations temporelles et événementielles entre les
objets
• Définir les états des objets qui déterminent une réaction
différente face à un événement
• Trouver les actions effectuées par les objets suite à la réception
d’événements
177
Rappels d’UMLDescription de l’aspect dynamique du système
Six diagrammes sont proposés par UML2 pour assurer la
description de la partie dynamique des systèmes :
– Le diagramme des séquences
– Le diagramme de communication (Le diagramme de collaboration)
– Le diagramme d’état-transition (machine d’état)
– Le diagramme d’activité
– Le diagramme global d’interaction
– Le diagramme de temps
178
Rappels d’UMLDescription de l’aspect dynamique du système
Présentation générale et concept de base• Le diagramme de séquence et le diagramme de collaboration sont très
similaire : ils permettent tous les deux de décrire des échanges de message
entre objets.
• Le diagramme de séquences met en avant la dimension chronologique
• Le diagramme de séquence permet aussi d’illustrer les scénarios définis
pour les cas d’utilisations. Il peut être vu comme un déroulement d’un cas
d’utilisation.
• Formalisme générale du cadre
d’un diagramme de séquence
179
Sd nom du diagramme
Représentation du diagramme
Description de l’aspect dynamique du systèmeLe diagramme des séquences
Présentation générale et concept de base (suite)• Ligne de vie
Une de vie représente l’ensemble des opérations exécutées par un objet. Un message reçu par
un objet déclenche l’exécution d’une opération. Le retour d’information peut être implicite
(cas général) ou explicite à l’aide d’un message de retour.
• Message synchrone et asynchrone
Dans un diagramme de séquence, deux types de messages peuvent être distingués :
– Message synchrone : dans ce cas l’émetteur reste en attente de la réponse à son message
avant de poursuive son action ( ). Le message de retour ( ) peut ne
pas être représenté car il est inclus dans la fin d’exécution de l’opération de l’objet
destinataire du message
– Message asynchrone : dans ce cas, l’émetteur n’attend pas la réponse à son message, il
poursuit l’exécution de ses opérations ( ).
180
Description de l’aspect dynamique du systèmeLe diagramme des séquences
: objet1
Message 1()
Possession
du contrôle
: Client
Message 2()
Message 3()
: objet2 : objet3
Message 4() Message 5()
Retour message 3()
Ligne de vie
Description de l’aspect dynamique du systèmeLe diagramme des séquences
Opérations particulières– Création et destruction d’objet
Si un objet est crée par une opération, celui-ci n’apparaît qu’au moment où il est créé. Si
l’objet est détruit par une opération, la destruction se représente par « X »
182
0bjet1: Classe 1
0bjet2: Classe 2
Création objet 2
Destruction objet 2
Description de l’aspect dynamique du systèmeLe diagramme des séquences
Opérations particulières (suite)
– Contrainte temporelle
Des contraintes de chronologie entre les messages
peuvent être spécifiée. De plus lorsque l’émission d’un
message requiert une certaine durée, il se représente
sous la forme d’un trait oblique.
183
X Y
Résoudre()
Délai
t1
t2
{t2-t1 <2s}
Description de l’aspect dynamique du systèmeLe diagramme des séquences
Fragment d’interactionDes sous ensembles d’interaction constituent des fragments. Un port d’entrée et un port de
sortie indiquent la manière dont ce fragment peut être relié au reste du diagramme.
184
Sd Diagramme d’ensemble
Interface
IHM
saisirCommande()
: GestionnaireClient
Produit
contrôlerClient()
Seq ContrôleProduit
contrôlerExistenceProduit
ExisteProduit()
Description de l’aspect dynamique du systèmeLe diagramme des séquences
Type de fragment d’interactionUn fragment d’interaction combiné correspond à un ensemble d’interaction auquel on applique un opérant. Treize opérateurs ont été définis dans UML : alt, opt, loop, par, strick/weak, ignore/consider, critical, assert et rf.
• Opérateur alt : correspond à un opérateur de test avec une ou plusieurs alternatives possibles
185
: Gestionnaire
SaisirAdhérent()
:adhérant:Emprunt
contrôlerEtat()
alt EtatEmprunt
[étatemprunt=rendu]
autoriserEmprunt()
[étatemprunt= non rendu]
refuserEmprunt()
Description de l’aspect dynamique du systèmeLe diagramme des séquences
Type de fragment d’interaction (suite)• Opérateur opt (optional) correspond à une opération de test sans
alternative (sinon)
186
:adhérant
: Gestionnaire:Emprunt
relancer()
testerArelancer()
retourSituationRelance
opt Relancer
[si relance]
Relancer()
Description de l’aspect dynamique du systèmeLe diagramme des séquences
Type de fragment d’interaction (suite)• Opérateur loop correspond à une instruction de boucle qui permet
d’exécuter une séquence d’interaction tant qu’une condition est satisfaite
• Opérateur par (parallel) permet de représenter deux séries d’interactions
qui se déroulent en parallèle.
187
:classe1
TraiterA1()par
traiterB3()
:classe2 :classe3
TraiterA2()
Traitement A1 et A2 menés
En parallèle au traitement B3
Description de l’aspect dynamique du systèmeLe diagramme des séquences
Type de fragment d’interaction (suite)
• Opérateurs strict et weak sequencing : permettent de représenter une série
d’interactions dont certaines s’opèrent sur des objets indépendants.
– L’opération strict est utilisé quand l’ordre d’exécution des opérations doit
être strictement respecté
– L’opérateur weak est utilisé quand l’ordre d’exécution des opérations n’a
pas d’importance
• Opérateur beak permet de représenter une situation exceptionnelle
correspondant à un scénario de rupture par rapport au scénario général. Le
scénario de rupture s’exécute si la condition de garde est satisfaite.
• Opérateurs ignore et consider sont utilisés pour des fragments d’interactions
dans lesquels on veut montrer que certains messages peuvent être soit absents
sans avoir d’incidence sur le déroulement des interactions (ignore), soit
obligatoirement présents (consider)188
Description de l’aspect dynamique du systèmeLe diagramme des séquences
Type de fragment d’interaction (suite)
• Opérateur critical : permet d’indiquer qu’une séquence d’interactions ne
peut être interrompue compte tenu du caractère critique des opérations
traitées. On considère que le traitement des interactions comprises dans la
séquence critique est atomique.
189
:classe1
Op1()
critical
Op3()
:classe2 :classe3
Op2()
Description de l’aspect dynamique du systèmeLe diagramme des séquences
Type de fragment d’interaction• Opérateur neg (négative) permet d’indiquer qu’une séquence d’interactions
est invalide. Une erreur sera déclenchée dans le cas de son exécution.
• Opérateur assert (assertion) permet d’indiquer qu’une séquence d’interaction
est l’unique séquence possible en considérant les messages échangés dans le
fragment. Toute autre configuration de message est invalide
• Opérateur ref permet d’appeler une séquence d’interaction décrite par ailleurs
190
:classe1
contrôlerDroitContrat()
ref
saisieIdContrat()
:classe2 :classe3
: Gestionnaire
« Contrôle des droits »
Description de l’aspect dynamique du systèmeLe diagramme des séquences
191
monMoteur/PM : Moteur
MarcheArrêt monReg : Regulateur Pl(0) : LoiDeCtr
Démarrer()
calculerNouveauCouple() Calcul()
cpl
fixerCouple(cpl)
Ligne de vie
Message
initiant
la séquence
Traitement
du message
démarrer
Message de retour
Suite à un appel
synchrone
Av
ance
men
t d
u t
emp
s
Instance myReg
de Regulateur
Exemple : système de régulation de vitesse (suite) Diagramme des séquences
Description de l’aspect dynamique du systèmeLe diagramme des séquences
• Le diagramme de collaborations sous une forma distincte du
diagramme des séquences représente les interactions entre classes en
mettant moins en évidence l’aspect temporel
• Ce modèle explique la coopération entre objets pour la réalisation
d’une fonctionnalité, cette coopération implique les différents
événements qui se propagent d’un objet à un autre. Un objet doit
avoir une méthode appropriée pour traiter chaque événement qu’il
reçoit (message).
• L’aspect temporel n’est pas complètement caché car chaque message
est numéroté.
192
5
2
34
1
6
Description de l’aspect dynamique du systèmeLe diagramme de collaboration (communication UML2.0)
193
monReg: Régulateur/pl(0):loiDeCtrl
monMoteur/pM : Moteur
1: calculerNouveauCouple()démarrer
1.1: calcul ()
1.3: fixerCouple (cpl)
ordre message
paramètres
Sens de l’appel
1.2: cpl
Exemple : système de régulation de vitesse (suite)
Diagramme de collaborations
Description de l’aspect dynamique du systèmeLe diagramme de collaboration (communication UML2.0)
Présentation générale et concept de base• Inspirés des statecharts de D. Harel et incluent des concepts des machines
de Moore et de Mealy.
• Modélisent des aspects contrôle et temps des système
• Un (ou plusieurs) diagramme E/T décrivent le comportement d’une classe, mais ils peuvent aussi décrire le comportement d’un Cas d’utilisation, d’un acteur, d’un sous-système ou d’une méthode.
• Un objet fournit un contexte pour l’exécution de la machine définissant sa classe
• Certains systèmes (ou parties de systèmes) sont purement fonctionnels (sans mémoire : fonction sinus) d’autres ont un mode de fonctionnement continu (sans états : filtre digital)
• Les machines à états sont utiles pour décrire des objets/classes exhibant un comportement complexe, réactif et ayant plusieurs interactions avec l’environnement.
194
Description de l’aspect dynamique du systèmeLe diagramme d’état-transition
Les opérations possibles dans les états et les
événements
195
E1
entry/ action en entrée de l’état
do/ activité pendant l’état
événement1/ action1
événement2/ action2
…
exit/ action en sortie
E2
Événement [garde]/action
Description de l’aspect dynamique du systèmeLe diagramme d’état-transition
• Evénements (Triggers)
- Un événement est associé à une transition, son émetteur n’est pas spécifié,
le traitement de l’événement est lié à l’état courant
- Occurrence d’une situation dans le domaine du problème
- Instantané et porteur d’informations :
NomTrigger(par1: type1,…parn: typen)
- Peut correspondre à un message du diagramme de séquences
196
Description de l’aspect dynamique du systèmeLe diagramme d’état-transition
Types de triggers• Appel : appel d’opération (message du D.S.). Stéréotypes: <<Crée>> et
<<Détruit>>. La création provoque la transition initiale
• La détection d’une situation particulière dans l’environnement
– Une certaine condition devient vraie : Persiste lorsque l’expression redevient fausse. Syntaxe : quand (Expression booléenne)
– Temporel : écoulement d’un instant temporel relatif ou absolu. Syntaxe : après (x secondes) : x secondes après l’accès à l’état courant. après(x secondes à partir de y). quand (date= un instant)
• Trigger « signal » : provoque une réaction asynchrone sans réponse
197
Allumage()Serv. occupéArrêt Marche Demande
après(3s)
Description de l’aspect dynamique du systèmeLe diagramme d’état-transition
ActionsTraitement atomique instantané (ininterruptible – run-to-completion semantic)
pouvant manipuler l’état, étiquetant une transition (Génération de signaux,
création d’objet, appel de méthodes, manipulation de propriétés ou de liens,…)
198
…/A1 …/A1…/A1
…/A2…/A2 …/A2
E
E Entry/ A1Exit/ A2
Evnt(info) / A
Evnmt(info) / A
Chaud SurchauffeHausseT°(t)/EteindreBruleur()
Description de l’aspect dynamique du systèmeLe diagramme d’état-transition
Activités
- Traitement associé à un état et ayant une durée
- Lorsque le traitement n’est pas terminé et qu’un événement validant unetransition se produit, il est interrompu
- Lorsque le traitement se termine sans occurrence d’événements, le systèmereste en attente dans l’état.
- Lorsque la transition n’est pas étiqueté le système quitte l’état à la fin dutraitement
- Ne peuvent pas changer l’état de l’objet concerné par la machine
199
Do Activité
Description de l’aspect dynamique du systèmeLe diagramme d’état-transition
Liens avec le diagramme de séquencesDiagramme de séquence peut se voir comme un chemin dans un diagramme
état/transition
200
X
Etat
Msg1
Msg2
Événement
Description de l’aspect dynamique du systèmeLe diagramme d’état-transition
Liens avec le diagramme de séquences (suite)
201
: Système
Décroche
Ali
Emet ‘La’
*[nbr]Compose chiffre
Connexion
Attente
Tonalité
Composition
Recherche
Communication
Décroche
Compose
Compose
Description de l’aspect dynamique du systèmeLe diagramme d’état-transition
Composition et décomposition d’état-transitionIl est possible de décrire un diagramme état-transition à plusieurs niveaux
hiérarchiques. Ainsi à un premier niveau, le diagramme comprendra des
états élémentaires et des états composites. Les états composites seront
ensuite décrits à un niveau élémentaires dans un autre diagramme.
202
Reçu Contrôlé acceptéEnregistré/contrôlé Contrôlé/décider
Symbole de représentation
d’un état composite
Description de l’aspect dynamique du systèmeLe diagramme d’état-transition
203
Etat composite
E2
E1
E3
E4
E1 E2
E3E4
E5 E5
Etat composite
Description de l’aspect dynamique du systèmeLe diagramme d’état-transition
Point de jonctionLorsque l’on veut relier plusieurs états
vers d’autres états, un point de jonction
permet de décomposer une transition en
deux parties en indiquant si nécessaire
les gardes propres à chaque segment de
la transition. A l’exécution, un seul
parcours sera emprunté, c’est celui pour
lequel toutes les conditions de garde
seront satisfaites.
Points de choixle point de choix se comporte comme un
test de type : si condition faire action1 si
non faire action 2.
204
Message vocal
reçu
Message SMS
reçu
Message Fax
reçu
A/R
Message vocal
A/R
Message SMS
A/R
Message Fax
[typeMessage=Fax]
[typeMessage=sms]
[typeMessage=vocal]
Message vocal
reçu
Message SMS
reçu
Message Fax
reçu
A/R mobile
A/R Fax
Message mobile reçu/
activer A/R
Message mobile reçu/
activer A/R
Message mobile reçu/
activer A/R
[typeMobile]
[else]
Description de l’aspect dynamique du systèmeLe diagramme d’état-transition
Concurrence
- décomposition conjonctive (et), les sous-états sont groupés en régions
- Le système est dans plusieurs sous-état simultanément
- une garde peut prendre la forme [in state X] (synchronisation)
- L’entrée dans un état conjonctif correspond à l’entrée vers tous les états initiaux, la sortie fait sortir de toutes les régions
205
A B C
U V W
Description de l’aspect dynamique du systèmeLe diagramme d’état-transition
Forme conjonctive et forme disjonctiveUne décomposition conjonctive peut être transformée en décomposition
disjonctive
206
e4[in state Z]e1
X
Y
Z
A
B
e1
e2
e3
Z,A Z,B
X,BX,A
Y,B
e1
e4
e3
e1
e2
e3
e1
Description de l’aspect dynamique du systèmeLe diagramme d’état-transition
207
Etat historique• permet de mémoriser le dernier sous état visité.
• L’entrée dans un état ne se fait pas au niveau de l’état
initial mais du dernier état visité lors
d’une entrée précédente.
Exemple :
Machine à laver
Description de l’aspect dynamique du systèmeLe diagramme d’état-transition
• Machines à états-transitions
E1
E11
E12
H
État initial
Historique
E4
e1[g]/p()
Événement
déclencheur
Garde logique
Procédure
E2
E21
E22
État composite
concurrentRégion orthogonale
E8
entry/a1; a2 ;
exit/a3 ;
activity/a4 ; a5 ;
Actions d’entrée dans E8
Actions de sortie dans E8
Activité de E8Jonction
Parallélisme
E5
E6
E7Choix
dynamique
E3
E9Choix
dynamique
État finalLabel d’une transition
208
Description de l’aspect dynamique du systèmeLe diagramme d’état-transition
Présentation générale et concepts de baseLe diagramme d’activité présente un certain nombre de points communs avec
le diagramme d’état-transition puisqu’il concerne le comportement interne des
opérations ou des cas d’utilisation. Cependant le comportement visé
s’applique aux flots de contrôle et aux flots de données propres à un ensemble
d’activités et non plus relativement à une seule classe.
209
Les concepts commun ou très proche
entre le diagramme d’activité et le
diagramme d’état-transition sont :
- Transition
- nœuds initial (état initial)
- nœud final (état final)
- nœud de fin flot (état de sortie)
- nœud de décision (choix)
Les concepts spécifiques au
diagramme d’activités sont :
- nœud de bifurcation
- nœud de jonction
- nœud de fusion
- pin d’entrée et de sortie
- flot d’objet
- partition
Description de l’aspect dynamique du systèmeLe diagramme d’activité
Action :
Une action correspond à un traitement qui modifient l’état du système.
Cette action peut être appréhendée soit à un niveau élémentaire proche
d’une instruction en termes de programmation soit à un niveau plus global
correspondant à une ou plusieurs opérations.
• Transition et flot de contrôleDés qu’une action est achevée, une transition automatique est déclenchée
vers l’action suivante. Il n’y a donc pas d’événement associé à la transition.
L’enchainement des actions constituent le flot de contrôle
210
Saisir commande
Action 1 Action 2
transition
Description de l’aspect dynamique du systèmeLe diagramme d’activité
• Activité
Une activité représente le comportement d’une partie du système en termes d’actions et de
transitions. Une activité est composé de trois types de nœuds :
Nœud d’exécution (action, transition)
Nœud de contrôle (nœud initial, nœud final, flux de sortie, nœud de bifurcation, nœud de
jonction, nœud de fusion-test, nœud de test-décision, pin d’entrée et de sortie)
Nœud d’objet
Une activité peut recevoir des paramètres en entrée et en produire en sortie
211
Saisir
commande
Contrôler
commande
Éditer
commande
Activité : traiter commande
Description de l’aspect dynamique du systèmeLe diagramme d’activité
Nœud de bifurcation (fourche)Un nœud de bifurcation permet à partir d’un flot unique
entrant de créer plusieurs flots concurrents en sortie de la
barre de synchronisation.
Nœud de jonction (synchronisation)Un nœud de jonction permet, à partir de plusieurs flots
concurrents en entrées de la synchronisation,
de produire un flot unique sortant.
212
Réception paiement
comptabiliser Envoyer marchandise
Inscrire adhérent Enregistrer cotisation
Envoyer carte adhérent
Description de l’aspect dynamique du systèmeLe diagramme d’activité
Nœud de test-décisionUn nœud de test-décision permet de faire
un choix entre plusieurs flots sortants en
fonction des conditions de garde de
chaque flot. Un nœud de test-décision n’a
qu’un seul flot en entrée.
• Nœud de fusion-testUn nœud de fusion-test permet d’avoir
plusieurs flots entrants possibles et un seul
flot sortant. Le flot sortant est donc
exécuté dès qu’un des flots entrants est
activé.
213
Saisir
commande
Facturer
particulier
Facturer
grossiste
[particulier]
[grossiste]
Commander
Par téléphone
Commander
Par messagerie
Commander
Par courrier
Facturer
Description de l’aspect dynamique du systèmeLe diagramme d’activité
Pin d’entrée et de sortie
Un pin d’entrée ou de sortie représente un
paramètre que l’on peut spécifier en entrée
ou en sortie d’une action. Un paramètre
peut être de type objet.
• Flot de données et nœud d’objet
Un nœud d’objet permet de représenter le
flot de donnés véhiculé entre les actions.
214
facturerp1
P2r1
Pin d’entréePin de sortie
:commande
Commander
:commande
Facturer
Commander Facturer[commande]
Description de l’aspect dynamique du systèmeLe diagramme d’activité
Partition
UML permet aussi d’organiser la
représentation du diagramme
d’activité en couloir d’activités.
Chaque couloir correspond à un
domaine de responsabilité d’un
certain nombre d’actions
215
Client Service commercial Stock
Demander
produit
Rechercher
produit
Contrôler
stock
Commander
Enregistrer
commande
Facturer
[Commande]
[Facture]
créer
créer
Description de l’aspect dynamique du systèmeLe diagramme d’activité
Représentation d’actions de
communication
Dans un diagramme d’activité des interactions de
communication liées à certains types
d’événements peuvent se représenter.
Les types d’événement concernés sont :
– Signal
– Écoulement du temps
216
Signal reçu
Signal envoyé
Acceptation d’une
Condition liée au
temps
Détecter arrivée
véhicule
Actionner
ouverture
Ouvrir portes Faire clignoter
lampe
Description de l’aspect dynamique du systèmeLe diagramme d’activité
Exemple :
Diagrammes d’activités monCapt.acquerirVitesse(Vit:Vitesse)
[Vit=consigne]
calculerNouveauCouple
[Vit<>consigne]
calculerVariationVitesse
Couple
[Valide]
pM.fixerCouple(cpl)
MiseA_JourOK
mettreA-JourAffichage
Attente de la réception
D’un signal de type
MiseA_jourOK
Point de choix
État atteint dés que l’action du précédent
état est terminée si vit différente de consigne
État avec action d’appel d’opération
acquérirVitesse de l’objet monCapt
avec paramètre vit de type Vitesse
Attente de la disponibilité du flot d’objet
Couple dans l’état Valide, avant de
Rejoindre l’état d’action suivant
Parallélisation
du flot de contrôle
Synchronisation
du flot de contrôle
217
Description de l’aspect dynamique du systèmeLe diagramme d’activité
Présentation générale et concepts de base
Le diagramme global d’interaction permet de représenter une vue générale des
interactions décrites dans le diagramme de séquence et des flots de contrôle
décrits dans le diagramme d’activité.
Le diagramme global d’interaction est un diagramme d’activité dans lequel on
représente des fragments d’interaction ou des utilisateurs d’interactions
Le diagramme global d’interaction utilise les concepts du diagramme d’activité
auquel on ajoute deux compléments :
– Les fragments d’interactions
du diagramme de séquence
– Les utilisateurs de fragments d’interaction : il est aussi possible de faire appel à des
fragments d’interaction à l’aide de l’opérateur ref
218
Sd interactionclient commande
ref
Nom du fragment
Description de l’aspect dynamique du systèmeLe diagramme global d’interaction
219
Sd Diagramme global : Utilisateur, systèmeContrôle
ref
Activer systèmeContrôle Accès
utilisateur SystèmeContrôle
sd
utilisateur SystèmeContrôle
sd
contrôlerCode
Message ¨Entrer¨
Contrôler OK
ref
ouvrirPorteDia
gra
mm
e g
lob
al d
’in
tera
ctio
n
Présentation générale et concepts de baseLe diagramme de temps permet de représenter les états et les interactions
d’objets dans un contexte où le temps a une forte influence sur le
comportement du système à gérer.
Autrement dit, le diagramme de temps permet de mieux représenter des
changements d’états et des interactions entre objets liés à 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 conditionnées avec deux représentations
graphiques possibles
– Des représentations propres aux aspects temporels : échelle de temps,
contraintes de durée, événements
220
Description de l’aspect dynamique du systèmeLe diagramme de temps
221
Sd chauffage vapeur
activé:po
mp
e ea
u
désactivé
Vapeur demandée
Et réserve eau
insuffisante
Réserve eau
suffisante
:ch
au
ffa
ge
eau activé
désactivé
Timer t
{t..t+3}
Exemple de diagramme de temps avec représentation en escalier
Description de l’aspect dynamique du systèmeLe diagramme de temps
Exemple de diagramme de temps avec représentation linéaire
222
Sd chauffage vapeur
:pom
pe
eau
:ch
au
ffa
ge
eau
timer t
{t..t+3}
Vapeur demandée
et réserve eau
insuffisante
Réserve eau
suffisante
désactivé
désactivé
désactivé
désactivé
activé
activé
Description de l’aspect dynamique du systèmeLe diagramme de temps
223
Contrôleur du DistributeurDétecteur de
pièces
Valeur-pièce
Leurre
Libère_pièce
Rendre_pièce
caisseSortie
Interface utilisateur
Choix-client
annulation
Affichage
Cmd_Moteur
Machine de vente de produits comestibles
Etude de cas : Machine de vente de produits comestibles
224
uc Use Case Mo...
Magasin_Piece
Moteur
Deliv rer_Produit
Rendre_Monnaie
Le Detecteur_Piece est activé par
l 'introduction d'un objet par le Cilent
Lev ier_Commande
Obtenir Choix
Detecteur_Piece
Obtenir_paiement
Client
Controleur de distributeur
«secondary»
«secondary»
«extend»
«include»
«extend»
«extend»
«secondary»
Diagramme des cas d’utilisation
Use Case : Obtenir_paiement
Condition de déclenchement : Introduction d'un objet
Séquence nominale
Le système incrémente le total introduit par la valeur de la pièce, Il
positionne le levier de commande sur caisse et commande la libération de
la pièce
Séquence exceptionnelle
a-Si l'objet introduit est un leurre le système positionne le levier commande sur
sortie et commande la libération de l'objet
b- Si le client appuie sur le bouton annulation le système déroule le C.U
Rendre_Monnaie
225
Diagramme des cas d’utilisationDescription des cas d’utilisation
Use Case : Obtenir_Choix
Condition de déclenchement : Le client a fait un choix de produit
Séquence Nominale
1 - Le système vérifie la disponibilité et le prix du produit2 - Le système déroule cas d'utilisation "Délivrer_Produit"
Séquence alternative
1-a Lorsque le produit est indisponible le système affiche le message "Produit
non disponible" et déroule le cas d'utilisation Rendre_Monnaie
1-b - lorsque le montant est insuffisant le système se met en attente d'autres
pièces et affiche le message "Montant insuffisant"
A tout moment Lorsque le client appuie sur le bouton annulation le
système déroule aussi le cas d'utilisation Rendre_Monnaie 226
Diagramme des cas d’utilisationDescription des cas d’utilisation
Use Case : Délivrer_produit
Condition de déclenchement : Un montant suffisant est introduit et le
produit est disponible
Séquence Nominale
Le système détermine le plateau contenant le produit demandé
Il commande la rotation du moteur correspondant.
Il déroule le C.U. Rendre_Monnaie pour rendre l'excédent
227
Diagramme des cas d’utilisationDescription des cas d’utilisation
Use case : Rendre_Monnaie
condition de déclenchement : annulation ou délivrer produit
Séquence nominale :Après avoir exécuter le CU "délivrer_produit" définir l'excédent à rendreTraduire excédent à rendre en vecteur image du magasin piècescommander magasin pièces par le vecteur image correspondant
Séquence alternative :Si annulation traduire excédent à rendre en vecteur image du magasin piècescommander magasin pièces par le vecteur image correspondant
228
Diagramme des cas d’utilisationDescription des cas d’utilisation
229
class Class Mo...
Entree_Pieces
+ Leurre() : boolean
+ PieceIntroduite(CodePiece)
Detecteur_Pieces
+ LibererPieces() : void
Compte_Client
- Compte: int
+ Incrementer(int) : int
+ RAZ() : int
+ Valeur() : int
Lev ier_Commande
+ SetPosition(boolean) : void
Interface_Utilisateur
+ Affichage_Total() : void
+ AffichageMsg() : void
Retour_Piece
- ImagePieces: tab
+ Rendre(int) : void
Magasin_Pieces
+ CMDTrappe() : void
Controleur_Demande
+ Annuler() : void
+ DeterminerMoteur() : void
+ DeterminerReste() : void
+ Traiter(int) : void
«signal»
+ annuler() : void
+ PièceIntroduite() : void
Liste_Prod
+ RetrouverInfo(Code) : Produit
Produit
- Code: int
- NoPlateau: int
- Prix: int
- Quantité: int
+ DECQte() : void
+ Getcode() : Code
+ GetPlateau() : NoPlateau
+ GetPrix() : Prix
Moteur_Plateau
+ Tourner() : void
Cette classe réalise la
l ivraison du produit 1..* 1..*
Diagramme des classes
230
sd Obtenir Paiment
Détecteur Pièces Entrée Pièces Interface
Util isateur
Compte Util isateur Levier De
Commande
opt Pièce v alide
opt Pièce non v alide
PièceIntroduite(Valeur)
INCR(Montant)
Afficher_Total()
Set_Position(Position)
LibérerPieces()
Leurre()
Set_Position(Position)
LibérerPiece()
231
sd Séquence Globale
Detecteur
Pièces
Interface
Util isateur
Controleur de
Demande
ProduitListe
Produit
Compte Moteur
Plateau
Retour
Pièces
Levier de
commande
Magazin
Pièces
par
refObtenir Paiment
alt
[Quantité >= 1 && !Annuler]
[Quantité=0 || Annuler]
alt
[Compte>=Prix]
[Compte<Prix]
opt
[Reste>0]
Traiter(Choix )
RetrouverInfo(Code)
Get*()
:InfoProduit
Valeur()
:Compte
DeterminerReste()
DECRQte()
DeterminerMoteur()
Tourner()
Rendre(Reste)
SetPosition()
cmdTrappe(Tableau)
AfficherMessage()
Rendre(Compte)
SetPosition()
cmdTrappe(Tableau)
232
stm Class Mo...
Initial
Repos
Attente
Traitement Choix
Deliv rer
+ do / TournerMoteur
[Pièce Introduite]
[Traiter Choix]
/RetournerInfo
[(Annuler) ou (Quantite=0)]
/Rendre(Compte)
[(Quantite>=1) et (Compte>Prix)]
/DCRQte
Determiner Moteur
Determiner Reste
[Si Reste>0]
/Rendre(Reste)
[Reste=0]
1. Introduction
2. Rappels d’UML
3. UML2.0 et le temps réel
4. Méta-modélisation
5. Les profils UML
6. Les profils dédiés aux SETR : le profil UML MARTE
7. Les méthodologies de développement des SETR basées
sur UML
8. Les outils de développement UML pour les SETR
233
2ème Partie : UML pour le Temps Réel et
l’Embarqué
UML2.0 et le temps réel
Les caractéristiques temps réel qualitatives regroupe
les trois aspects :
- La concurrence (ou le parallélisme)
- La communication
- Le comportement (inclut en particulier une partie actions)
Caractéristiques temps réel quantitatives
234
1. Modélisation de la concurrence
Il est possible de décrire la concurrence en UML à différents
niveaux de granularité :
Au niveau des classes active : propriété isActive : boolean
Au niveau comportemental dans les machines à états via
des états concurrents
Au niveau des opérations via un attribut de contrainte
spécifique.
UML2.0 et le temps réelCaractéristiques temps réel qualitatives
235
Concurrence et objets actifs
• Les objets actives d’UML sont les instances de classes actives (propriété de classe :isActive). Ils possèdent leur propre ressource d’exécution, s’exécutentconcurremment avec les autres objets actifs et possèdent des mécanismes de contrôledes invocations qui leur arrivent qui préservent l’intégrité de l’objet contre desinvocations concurrentes.
• Les objets passifs s’exécutent dans l’espace d’adresse et sous le contrôle de l’objetactif qui contrôle l’objet qui fait appel à leurs comportements (opérations, ..).
• En complément UML définit deux variantes d’objets actifs via les stéréotypes«process» et «thread» qui spécifient le type de flot de contrôle attachés à une classeactive.
236
Obj:MyActiveClassMyActiveClass
{active}Objet actif Classe active
UML2.0 et le temps réelCaractéristiques temps réel qualitatives
Concurrence et machine à étatsDans UML, la modélisation de la concurrence peut
aussi se définir au sein d’une machine à état. Deux
moyens sont disponibles :
– Les états concurrents composites
– Les activités internes à un état (do-activity)
E1
E11 E12
Régions concurrentes
237
E1
E11Do/act1()
Do/act2()
UML2.0 et le temps réelCaractéristiques temps réel qualitatives
Concurrence des opérationsPropriété concurrecy : s’adresse plutôt aux classes passives.
– Sequential : un seul appel à une opération de ce type doit être traité à un instantdonné, mais aucun mécanisme de protection par défaut. l’intégrité de l’objetn’est pas garantie.
– Guarded : l’objet ne peut également traiter qu’un seul appel à la fois, l’objetgarantit cette sérialisation par exclusion mutuelle
– Concurrent : plusieurs appels d’opérations peuvent s’exécuter concurremment etl’objet garantie son intégrité dans ce cas.
En plus de ses caractéristiques de concurrence, une opération peut posséder unattribut appelé isQuery
isQuery concerne l’impact de l’exécution de l’opération sur l’état de l’objet : S’ilest vrai (true), une exécution de l’opération laisse l’état de l’objet inchangé. Sinon(false), l’exécution peut provoquer des modifications sur l’état de l’objet.
238
Regulateur
Démarrer (sp : integer); {concurrency = sequentiel}
Arrêter() ; {isQuery=true}
UML2.0 et le temps réelCaractéristiques temps réel qualitatives
2. Modélisation des communications
• Quelle que soit la méthodologie orientée objets utilisées, l’applicationdéveloppée est constituée de différents objets interagissant afin de réaliserune tâche. Cette collaboration entre objets est appelée en UML : interaction
• La communication dans UML est basée sur le paradigme de message.
• messages d’UML : appel d’opération, envoi de signal, création oudestruction d’objet (instance).
• Une communication par message peut être synchrone ou asynchrone etpeut transporter des paramètres d’entrée, de sortie ou d’entrée-sortie.
• Un message possède un émetteur et un récepteur. L’émetteur est uneinstance de classe qui après avoir exécuté une action spécifique génèrel’envoi de ce message.
239
UML2.0 et le temps réelCaractéristiques temps réel qualitatives
• Une opération en UML est un service offert par un
objet qui peut être requis depuis un autre objet afin de
réaliser un comportement. Une opération possède une
signature qui décrit les paramètres qui peuvent être
passés à l’opération lors de son appel (éventuellement
valeurs de retour)
Regulateur
Démarrer (vit : integer)
Arrêter()
240
• La concurrence modélisées avec les contraintes {concurrency},
• attribut isQuery Celui-ci concerne l’impact de l’exécution de l’opération
sur l’état de l’objet.
Envoi de message par appel d’opération
UML2.0 et le temps réelCaractéristiques temps réel qualitatives
• Qu’est-ce qu’implique la réception d’un tel appel ?
La réception d’un appel d’opération peut :
– Soit être interprétée sous la forme d’un événement d’appel déclenchant
une transition dans une machine à états (dans ce cas le récepteur réalise
la séquence d’actions spécifiées sur la transition qui peut être
déclenchée) ;
– Soit être perçue comme un appel d’opération classique, c’est-à-dire
déclenchant l’exécution d’une méthode donnée décrivant le
comportement de l’opération appelée.
241
UML2.0 et le temps réelCaractéristiques temps réel qualitatives
Envoi de message par émission de signal
– Un signal modélise toujours une communication asynchrone.
– Le concept de signal de UML peut convoyer des paramètres et peut être
spécialisé ou généralisé dans un arbre d’héritage. Toutefois, un signal est
«classifier» spécifique qui ne peut pas avoir d’opération ni de relation
d’association avec un autre « classifier » (classe, acteur, signal, etc.).
242
MaClasse
« signals »
Alarme (IN z:Zone)
MarcheArrêt()
– Un signal est associé aux classes
prévues pour sa gestion à travers la
déclaration d’une réception
compartiment additionnel marqué par
le stéréotype «Signals» où seront
déclarés les différents types de signaux
pouvant être reçus par la classe.
UML2.0 et le temps réelCaractéristiques temps réel qualitatives
Envoi de message par émission de signal (suite)
• Comment génère-t-on un signal ?
L’envoi d’un signal est effectué à l’aide d’une primitive d’action particulière quidirige vers un ensemble de destinataires identifiés, soit explicitement, soitimplicitement (typiquement vers toutes les instances de classes sachant gérer laréception de ce type de message).
• Qu’est-ce qu’implique la réception de signal ?
La réception d’un signal est vue par une instance comme un événement déclencheurde transition qui est stocké dans une file gérée par la machine à états décrivant lecomportement de la classe de l’instance réceptrice.
Comme pour la communication par appel d’opération, la communication par signalsoulève quelques questions sur les spécificités de sa sémantique :
– Les objets passifs peuvent-ils recevoir des signaux ?
– Quels types de paramètres peuvent être véhiculés par un signal ? In, out, inout?
Ces questions nécessitent des réponses de manière à éviter des interprétationsambiguës des modèles 243
UML2.0 et le temps réelCaractéristiques temps réel qualitatives
3. Modélisation du comportementLa modélisation du comportement d’une application est essentiellementintroduit dans UML à travers les concepts suivants :
– Les machines à états décrivent le comportement dynamique d’unélément de modèle. Il existent deux variantes de ces diagrammes à états :les diagrammes d’états (State Diagrams) et les diagrammes d’activités(Activity Diagrams).
– Les interactions sont constituées d’un ensemble de messages quedifférents objets s’échangent afin de réaliser une activité ou une tâchedonnée. Ce concept permet la description du comportement global dusystème. Il est également exprimé sous deux formes : les diagrammesde collaboration (Collaboration Diagrams) et les diagrammes deséquence (Sequence Diagrams).
– Les actions définissent le niveau le plus fin de modélisation ducomportement atteignable en UML. Elles sont spécifiées par le chapitre«Action semantic » de UML.
244
UML2.0 et le temps réelCaractéristiques temps réel qualitatives
Description de la sémantique des
machines états-transitions de UMLCette description repose sur une machine d’exécution
hypothétique qui représente les trois caractéristiques
suivantes :
• Une file d’attente d’événements qui sert à
stocker les instances d’événements entrantes en
attendant de les consommer ;
• Une politique de choix des événements qui
détermine l’ordre d’extraction des instances
d’événement contenue dans la file d’attente
• Un processeur d’événements qui exécute les
traitements associés aux événements en respectant
la sémantique des machines à états de UML et en
particulier, l’hypothèse d’exécution Run-To-
Completion
Processeur
d’événement
UneClasse
Mécanisme de choix et de
distribution de l’événement
depuis la queue d’événements
à son processeur associéQueue d’événements
stockant les messages
entrants
Msg (‘liste_de_params’
245
UML2.0 et le temps réelCaractéristiques temps réel qualitatives
Description de la sémantique des machine états-transition de UML
Les événements sont dépliés un à un à la fois et consommés par une machines àétats-transitions. L’ordre dans lequel ils sont dépliés n’est pas précise dans UML.C’est à la charge de chaque méthode basée UML de le préciser par son modèled’exécution. Ceci est un point de variation ouvert de la sémantique de UML.
La sémantique d’exécution des événements est basée sur l’hypothèse Run-To-Completion signifiant qu’un événement ne peut être déplié puis consommé quelorsque le traitement de l’événement précédent est achevé. On parle de « pasRTC » lorsque la machine à états-transitions passe d’une configuration d’étatstable à une autre configuration d’état stable. Un état est dit stable lorsqu’il nereste plus d’actions en cours d’exécution. La notion de «pas RTC» permetd’éviter d’éventuels problèmes de concurrence pendant le traitementd’événements et conduit à sérialiser les traitements au sein d’une même machineà état-transitions.
Une fois toutes les actions terminées, on dit que la machine a effectué «un pas RTC».
246
UML2.0 et le temps réelCaractéristiques temps réel qualitatives
Description de la sémantique des machine états-transition de UML
En ce qui concerne la concurrence , UML précise que deux options de
définition du RTC sont possibles :
– Soit l’hypothèse d’exécution RTC est appliquée globalement à l’ensemble de la
machine à états- transitions ;
– Soit cette contrainte est relâchée et peut être appliquée indépendamment à
chaque région orthogonale, augmentant ainsi le niveau de concurrence possible
pour le traitement d’événements.
Toute méthode de modélisation temps réel en UML se doit donc de préciser
le choix retenu sur la sémantique du RTC vis-à-vis des états concurrents.
247
UML2.0 et le temps réelCaractéristiques temps réel qualitatives
Description de la sémantique des machine états-transition de UML
Les machines à état-transitions de UML offrent la possibilité de spécifier unesorte de comportement automatique à l’aide de transitions spécifiques appelées« completion-transitions ». Ce type de transition ne possède pas d’événementdéclencheur explicite, mais peut avoir une garde. Elle est déclenchée par unévénement interne de la machine à états appelé «completion event ».
La machine à état génère implicitement cet événement à chaque fois qu’elle aatteint un état stable. Un tel événement est consommé immédiatement dès qu’ilest généré sans passer par la file d’événements de la machine états-transitions,sinon il est perdu. Si la configuration d’états courantes de la machine à étatspossède une transition de «completion» sortante, le tirage de cette transition estprioritaire vis-à-vis de toute autre transition émergeante de cet état. De plus, siun état possède plusieurs transitions de «completion», elles doivent êtremutuellement exclusives de manière à assurer qu’une seule sera effectivementactivée. Dans le cas contraire, il y aura une situation indéterminée quant à ladynamique de la machine.
248
UML2.0 et le temps réelCaractéristiques temps réel qualitatives
Diagrammes d’activités
Le diagramme d’activité présente un certain nombre de points communs avec le diagrammeétats-transitions puisqu’il concerne le comportement interne des opérations ou des casd’utilisation. Cependant le comportement visé ici s’applique aux flots de contrôle et aux flotsde données propres à un ensemble d’activités et non plus relativement à une seule classe.
Les diagrammes d’activité sont décrits en termes d’états et de transitions où un état estattaché à une action donnée ou à une sous-activité représentant des activités emboîtés.
Les états actions sont quittés lorsque l’action spécifiée est terminée. Les états d’action nedoivent pas avoir de transition interne, ni de transition sortante déclenchée par un événementexplicite, ni d’action d’entrée ou de sortie. Cela signifie que les transitions sont toujoursdéclenchées par l’événement implicite completion de l’état action dont elle émerge . Deséléments complémentaires permettent de préciser sous quelles conditions la transition peutêtre tirée :
– Les expressions de garde usuelles
– La disponibilité d’un objet (flot dans un état donnée)
– L’occurrence d’un signal, dans ce cas, une notation spécifique est attaché à l’état cible oùla réception du signal est définie comme une action atomique
En outre, les diagrammes d’activité permettent de modéliser des activités concurrentes etfournissent les notations associées de parallélisation et de synchronisation
249
UML2.0 et le temps réelCaractéristiques temps réel qualitatives
Caractéristiques temps réel quantitatives
UML définit deux types de données relatives au temps :
– Time définit une valeur représentant un moment absolu ou relatif du temps ;
– TimeExpression permet de spécifier des expressions dont l’évaluation donne une valeur de type Time
Ces données peuvent intervenir, en particulier, dans trois types de diagrammes : les diagrammes d’états, les diagrammes de séquence et le diagramme de temps (UML2)
250
UML2.0 et le temps réelCaractéristiques temps réel quantitatives
Modélisation de propriétés temporelles dans les diagrammes
d’états
Dans le contexte des diagrammes d’états, UML définit un événement
spécifique appelé TimeEvent. Il sert à modéliser l’expiration d’une échéance
qui peut être relatif ou absolue :
– Un événement dénotant le passage d’une quantité de temps suite à
l’entrée dans l’état contenant la transition est noté avec le mot-clé after
suivi d’une expression de type TimeExpression qui dénote la valeur
temporel de l’événement ;
– Un événement dénotant l’occurrence d’une date absolue est noté via le
mot-clé when suivi d’une date absolue de type Time
251
UML2.0 et le temps réelCaractéristiques temps réel quantitatives
Exemple de spécification d’événements temporels
252
Modélisation des événements temporels Description
after (10ms)/’procedure’ L’événement est généré 10 ms après la date
d’entrée dans l’état S
after(10ms after the exit of S)/’procedure’ L’événement est généré 10 ms après la date de
sortie de l’état S
when(1er janvier 2000, 0h00)/’procedure’ L’événement est généré le 1er janvier 2000 à
0h00
S
S
S
UML2.0 et le temps réelCaractéristiques temps réel quantitatives
Dans les trois cas du tableau, lorsque le temporisateur armé arrive à échéance, il
génère un événement qui est stocké comme tout autre événement dans la file
d’attente associée à la machine à états. Si celle-ci est à l’état S au moment où
l’événement temporel est sélectionné, l’événement est consommé et la transition est
tirée. Dans le cas contraire, l’événement temporel est perdu. Contrairement au
autres événements, les événements temporels ne peuvent être différés, c’est-à-dire
ajoutés à la liste des événements de type « defered ».
La date d’occurrence d’un événement temporel est la même que sa date de
réception. Cependant, il faut noter qu’il peut exister un délai variable et
difficilement mesurable entre la date d’émission d’un événement temporel et le
moment auquel il est pris en compte par l’objet récepteur. En effet, ce délai est la
conséquence de la politique de stockage et de traitement mise en œuvre par chaque
approche pour gérer la file des événements reçus.
253
UML2.0 et le temps réelCaractéristiques temps réel quantitatives
Modélisation de propriété temporelles
dans les diagrammes de séquence
Le deuxième type de diagramme de UML, particulièrement approprié pour la spécification
des systèmes temps réel est le diagramme de séquence. En effet, un diagramme de séquence
possède deux dimensions :
– L’axe horizontale qui contient les objets impliqués dans l’interactions décrite dans le
diagramme ;
– L’axe verticale qui représente le temps. Le temps progresse dans le sens descendant de
cet axe mais sans qu’il lui soit attaché de métrique.
254
En règle générale, dans les diagrammes de séquence de
UML, on suppose que le délai de transmission des
messages échangés entre les objets de l’application, ce
qui explique que les flèches symbolisant les échanges
sont horizontales. Cependant, si pour une raison
particulière, l’utilisateur ne peut pas se satisfaire de
cette hypothèse, il peut incliner vers le bas la flèche de
message pour modéliser le délai de transmission de
message.
O1 O2
C:m3
Délai de propagation
de message non
négligeable
UML2.0 et le temps réelCaractéristiques temps réel quantitatives
Modélisation de propriété temporellesdans les diagrammes de séquence
• pour faciliter l’expression de ces contraintes de temps, UML
introduit un certain nombre de fonction temporelles dédiées
à la manipulation du temps dans les échanges de messages
réalisés dans les diagrammes de séquence, comme :
– sendTime (date d’envoi d’un message) et
– receiveTime (date de réception d’un message).
L’utilisateur peut en adjoindre de nouvelles pour des besoins
spécifiques.
• Pour spécifier une contrainte de temps dans les diagrammes
de séquence, UML propose deux solutions :
– via une cotation sur le diagramme ou
– via l’expression de contraintes
• quelle que soit la technique de représentation du temps
adoptée, les moyens proposées par UML ne sont que des
artifices de notation qui demande à être intégrés dans une
approche méthodologique complète précisant parfaitement
leur sémantique et les interactions avec le reste des modèles.255
O1 O2
b:m2
Label du
message
<1sec.
a:m1
Cotation temporelle
{b.sendTime-a.receiveTime<1sec.}
Contrainte temps-réel
UML2.0 et le temps réelCaractéristiques temps réel quantitatives
Modélisation de propriétés temporelles dans le diagramme de temps (1/2)
Le diagramme de temps permet de représenter les états et les interactionsd’objets dans un contexte où le temps a une forte influence sur lecomportement du système à gérer.
Autrement dit, le diagramme de temps permet de mieux représenter deschangements d’états et des interactions entre objets liés à des contraintes detemps.
Le diagramme de temps utilise en plus des lignes de vie, les conceptssuivants :
– Des états ou des lignes de temps conditionnées avec deuxreprésentations graphiques possibles
– Des représentations propres aux aspects temporels : échelle de temps,contraintes de durée, événements
256
UML2.0 et le temps réelCaractéristiques temps réel quantitatives
Modélisation de propriétés temporelles dans le diagramme de temps (1/2)
257
UML2.0 et le temps réelCaractéristiques temps réel quantitatives
Limitations d’UML vis-à-vis du temps réel
- Manque de concepts pour exprimer les contraintes et propriétés temps réelo Périodes, échéance, date de réveil, durée d’exécution, priorité, laxité, …
- Pas de structures de communications assez évoluées :o Ports, connecteurs, protocoles, sémaphores
- Pas de techniques d’ordonnancement proposéeso Round-Robin, FCFS, RM, DM, EDF, LLF, …
- Pour les messages, notion de file d’attente mais pas de notion avec/sans écrasement
- Pas de réflexion sur la décomposition en tâche
- Expression du temps : pas de temps « vrai » unités de temps258
UML2.0 et le temps réelLimitations dans UML2.0
Le temps réel n’est pas le seul domaine concerné par les lacunes d’UML Suivant le contexte dans le quel on se place, ce ne sont pas les mêmes
notions qui font défaut • Ordonnancement = expression des rythmes, temps absolu, temps considéré
comme global, ordonnanceurs, hiérarchies d’ordonnanceurs, calculateurs, abstraction du réseau en tant que medium de communication en temps borné, etc.
• Calcul des durée des traitements = découpage du processeur, mémoires, mémoires caches, instructions, etc.
• Réparti = découpage du temps synchronisation d’horloges, etc.
• Etc.
Solution propriétaire = être lié à un seul outil/éditeur de logiciel
Besoin d’une solution normalisée simplement implémentable sur (tous) les ateliers logiciels
Utilisation des mécanismes standards d’extension d’UML Profil UML259
UML2.0 et le temps réelNécessité d’étendre UML de façon normalisée
1. Introduction
2. Rappels d’UML
3. UML2.0 et le temps réel
4. Méta-modélisation
5. Les profils UML
6. Les profils dédiés aux SETR : le profil UML MARTE
7. Les méthodologies de développement des SETR basées
sur UML
8. Les outils de développement UML pour les SETR
260
2ème Partie : UML pour le Temps Réel et
l’Embarqué
Méta-modélisation
Introduction/Plan
• But de la méta-modélisation
– Définir des langages de modélisation ou des langages de manières générales
• Architecture MOF
– 4 niveaux de (méta)modélisation
– Architecture 4 niveaux généralisables en dehors du MOF
• Syntaxes abstraites et concrète
261
Normes OMG de modélisation
• MOF : Meta-Object Facilities– Langage de définition de méta-modèles
• UML : Unified Modelling Language– Langage de modélisation
• CWM : Commun Warehouse Metamodel– Modélisation ressources, données, gestion d’une
entreprise
• OCL : Object Constraint Language– Langage de contraintes sur modèles
• XMI : XML Metadata Interchange– Standard pour échanges de modèles et méta-modèles
262
• Plusieurs de ces normes concernent la définition et l’utilisation de méta-modèles :
– MOF : but de la norme
– UML et CWM : peuvent être utilisés pour en définir
– XMI : pour échange de (méta)-modèles entre outils
• MOF
– C’est un méta-méta-modèle
Utiliser pour modéliser des méta-modèles
- Définit les concepts de base (22)
Entité/classe, relation/association, type de données, références, package, …
- Le MOF peut définir le MOF263
Normes OMG de modélisation
4 Niveaux du MOF
• Le MOF définit 4 niveaux de modélisation
– M0 : système réel, système modélisé
– M1 : modèle du système réel défini dans un certain langage
– M2 : méta-modèle définissant ce langage
– M3 : méta-méta-modèle définissant le méta-modèle• Le niveau M3 est le MOF
• Dernier niveau, il est méta-circulaire : il peut se définir lui-même
– Le MOF est pour l’OMG le méta-méta-modèle unique servant de base à la définition de tous les méta-modèles
264
265
4 Niveaux du MOF
Hiérarchie 4 Niveaux
• On retrouve cette hiérarchie à 4 niveaux en dehors du MOF et d’UML, dans d’autres espaces technologique que celui de l’OMG
– Langage de programmation :• M0 : l’exécution du programme
• M1 : le programme
• M2 : la grammaire du langage dans lequel est écrit le programme
• M3 : le concept de grammaire EBNF
– XML • M0 : données du système
• M1 : données modélisées en XML
• M2 : DTD XML
• M3 : le langage XML
266
Méta-modélisation UML
• Dans UML, on retrouve également les 4 niveaux – Mais avec le niveau M3 définissable en UML directement à la
place du MOF
• Exemple de système à modéliser (niveau M0)– Une pièce possède 4 murs, 2 fenêtres et une porte
– Un mur possède une porte ou une fenêtre mais pas les 2 à la fois
– Deux actions sont associées à une porte ou une fenêtre : ouvrir et fermer
– Si on ouvre une porte ou une fenêtre, elle devient ouverte
– Si on ferme une porte ou une fenêtre ouverte, elle devient fermée
267
• Pour modéliser ce système, il faut définir 2 diagrammes UML : niveau M1
– Un diagramme de classe pour représenter les relations entre les éléments (portes, murs, pièces)
– Un diagramme d’état pour spécifier le comportement d’une porte ou d’une fenêtre (ouverte, fermée)
– On peut abstraire le comportement des portes et des fenêtres en spécifiant les opérations d’ouverture fermeture dans une interface (le diagramme d’état est associé à cette interface)
– Il faut également ajouter des contraintes OCL pour préciser les contraintes entre les éléments d’une pièce
268
Méta-modélisation UML
M1 : spécification du Système
269
Méta-modélisation UML
• Les 2 diagrammes de ce modèle de niveau M1 sont des diagrammes UML valides
• Les contraintes sur les éléments des diagrammes UML et leurs relations sont définies :– Dans le méta-modèle UML : niveau M2
– Un diagramme UML (classe, état… ) doit être conforme au méta-modèle UML
• Méta-modèle UML– Diagramme de classe spécifiant la structure de tous
types de diagrammes UML
– Avec contraintes OCL pour spécification précise.
270
271
M2 : Méta-modèle UML (simplifié)
Méta-modélisation UML
• Le méta-modèle UML doit aussi être précisément défini– Il doit être conforme à un méta-modèle
– C’est le méta-méta-modèle UML
• Qu’est ce que le méta-modèle UML ?– Un diagramme de classe UML (avec contraintes OCL)
• Comment spécifier les contraintes d’un diagramme de classe ?– Via le méta-modèle UML
– Ou plus précisément : via la partie du méta-modèle UML spécifiant les diagrammes de classes
• Méta-méta-modèle UML = copie partielle du méta-modèle UML : niveau 3
272
M3 : méta-méta-modèle UML (simplifié)
273
Syntaxe
• Un langage est défini par un méta-modèle• Un langage possède une syntaxe respectant le métat-
modèle– Syntaxe textuelle– Ensemble de mot-clé et de mots respectant des contraintes
défini selon des règles précises (notions de syntaxe et de grammaire dans les langages)
• Syntaxe graphique– Notation graphique, chaque élément a une forme graphique
particulière (exemple : associations entre classes/interfaces sur les diagrammes de classes UML
association dépendanceimplémentation spécialisation
274
Syntaxe abstraite/concrète
• Syntaxe abstraite/concrète :
– Abstraite• Les éléments et leurs relations sans une notation spécialisée
• Correspondant à ce qui est défini au niveau du méta-modèle
– Concrète• Syntaxe graphique ou textuelle définie pour un type de modèle
• Plusieurs syntaxes concrètes possibles pour une même syntaxe abstraite
– Un modèle peut être défini via n’importe quelle syntaxe • L’abstraite
• Une des concrète
– MOF : langage pour définir des méta-modèles• Pas de syntaxe concrète définie 275
Syntaxe : exemple diagramme d’état
276
1. Introduction
2. Rappels d’UML
3. UML2.0 et le temps réel
4. Méta-modélisation
5. Les profils UML
6. Les profils dédiés aux SETR : le profil UML MARTE
7. Les méthodologies de développement des SETR basées
sur UML
8. Les outils de développement UML pour les SETR
277
2ème Partie : UML pour le Temps Réel et
l’Embarqué
Profils UML
• Un profil est une spécialisation du méta-modèle UML– Ajouts de nouveaux types d’éléments et des contraintes sur leurs
relations entre eux et avec les éléments d’UML– Ajouts de contraintes sur les éléments existants d’UML– Ajouts de contraintes sur les relations existantes entre les éléments
d’UML– Aucune suppression de contraintes ou d’éléments
• Profil : mécanisme d’extension d’UML pour l’adapter à un contexte métier ou à une technique particulière– Profil pour composants EJB– Profil pour gestion bancaire– Profil pour architecture logicielle – Profil pour les système temps réel embarqués – …….
278
Mécanismes standards d’extension d’UML
• UML fournit 4 mécanismes d’extension du langage : Les notes :
Apport d’un commentaire n’ayant aucune conséquence sur la sémantique du modèle
Les stéréotypes
Création de nouveaux concepts UML à partir des concepts standard
Les étiquettes (tagged values)
Extension des propriétés associées à un concept UML
Les contraintes (exprimable en OCL)
Extension de la sémantique d’un concept UML en ajoutant de nouvelles règles ou en modifiant les anciennes
• Un profil UML est défini sous la forme d’un package stéréotypé « profile »
279
Mécanismes standard d’extension d’UML
• UML fournit déjà des stéréotypes, des étiquettes et des contraintes standard
– Stéréotype : extend, use, import, executable, process, thread, …
– Étiquette : persistance, sémantique, …
– Contrainte : sous-ensemble, ordonné, ou, disjoint, chevauchement, complète, …
• UML permet de définir ses propres stéréotypes, étiquettes et contraintes
280
• Note (définition)
– Une note ne modifie pas la sémantique du modèle
– Elle est représentée par un rectangle écorné lié par un ou plusieurs traits pointillés aux éléments qu’elle commente
281
Mécanismes d’extension standard d’UML
Une note est un commentaire textuel ou graphique que l’on attache à un élément ou à un ensemble d’éléments
• Stéréotype (Définition)
– Un stéréotype apparaît entre « guillemets » près du nom de l’élément stéréotypé
– On peut représenter un stéréotype au moyen d’une nouvelle icône
282
Mécanismes d’extension standard d’UML
Un stéréotype est une chaîne de caractère qui associée à un élément UML existant permet de désigner un nouveau type d’élément UML
• Etiquette (Définition)
– L’étiquette apparaît entre {accolade} et précise le nom de la propriété et sa valeur
– Utiles pour la génération de code ou la gestion de configuration
283
Mécanismes d’extension standard d’UML
Une étiquette est une chaîne de caractères qui associée à un élément UML permet de lui ajouter une propriété et sa valeur associée
• Contraintes (Définition)
– La contrainte apparaît entre {accolade} et définit la règle à appliquer
– On peut utiliser du texte informel ou recourir à l’utilisation d’un langage plus précis comme OCL (Object Contraint Language)
284
Mécanismes d’extension standard d’UML
Une contrainte est une chaîne de caractères qui associée à un élément UML permet d’ajouter de nouvelles règles ou de modifier des règles existantes
Les Profils UML dédiés aux SETR
Les Profils UML dédiés aux systèmes embarqués et au temps réel
– 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 : Modélisation et validation des systèmes temps réel
– Embedded UML : Approche pour le co-design hardware/software en temps réel
285
1. Introduction
2. Rappels d’UML
3. UML2.0 et le temps réel
4. Méta-modélisation
5. Les profils UML
6. Les profils dédiés aux SETR : le profil UML MARTE
7. Les méthodologies de développement des SETR basées
sur UML
8. Les outils de développement UML pour les SETR
286
2ème Partie : UML pour le Temps Réel et
l’Embarqué
En février 2005, l’OMG a voté la RFP (Request For Proposals). Cette demande
de propositions portait sur un profil UML pour la modélisation et l’analyse des
systèmes temps réel 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é adoptée le 29 juin 2007.
Le profil UML MARTE a pour objectif d’étendre UML pour l’utiliser dans une
approche de développement dirigé par les modèles de systèmes temps réel et
embarqués.
MARTE fournit des supports pour les étapes de spécification, de conception et de
vérification/validation .
Les retombées attendues de l’usage de ce profil sont de :
– Fournir une modélisation unifiée pour les parties matérielles et logicielles du système
– Permettre l’interopérabilité entre les outils de développement utilisés en spécification, en
conception , en vérification et en génération de code
– Faciliter la construction de modèle sur lesquels on peut faire des prévisions quantitatives
tenant compte des caractéristiques du matériel et du logiciel. 287
Le Profil UML MARTE
288
Le Profil UML MARTE
Architecture globale de la décomposition en paquetages du profil MARTE
• Le profil est structuré suivant deux directions :
La modélisation des concepts des systèmes embarqués temps-réel MARTE design model
L’annotation des modèles d’applications pour supporter l’analyse des propriétés systèmes MARTE analysis model
• Ces deux parties majeures partagent des concepts communs, groupés dans MARTE foundations pour exprimer :
- Des propriétés non fonctionnelles (NFPs)
- Des notions de temps (Time)
- La modélisation des ressources (GRM)
- Des composants (GCM)
- Des éléments d’allocation (Alloc)
• Un paquetage additionnel contient les annexes du profil définie en MARTE, aussi bien que les librairies prédéfinies
289
Le Profil UML MARTE
290
MARTE foundations
« profile »CoreElements
« profile »NFP
« profile »Time
« profile »GRM
« profile »Alloc
MARTE annexes
« profile »VSL
« profile »RSM
« modelLibrary »MARTE_library
« profile »GCM
« profile »HLAM
« profile »SRM
« profile »HRM
MARTE design model
« profile »GQAM
« profile »SAM
« profile »PAM
MARTE analysis model
Non-functionnel Properties :Définitions de types de base Et d’unité de temps, de débits,D’énergie ainsi que les relations entre unités (1s = 1000 ms)
Notion d’horloge (logique, discrète,Continue, …)
Generic Resource Modelling :Déf. de ressources logicielles(ex: scheduler) et matérielle(ex: processeur)
Allocation d’entités à desRessources(allocation spatiale-mémoire, de calcul,À un ordonnanceur, etc.)
Intègre le VSL à la définitionde paramètres. Précise les comportements et introduitLa notion de mode defonctionnement
Generic Component ModelProfil orienté composants(inspiré d’AADL)
High Level ApplicationModeling : définit les modulesRtUnit, PpUnit, RtAction, etc.
Software/Hardware RessourceModeling : définition utiles pourLa modélisation des supportsD’exécution (RTOS, processeur)
Generic Quantitative AnalysisModeling : modèles de base pourL’étude de performances etl’ordonnancement RMA
Schedulability AnalysisModeling : définit des propriétés d’ordonnan-çabilité(but => utiliser dans un outil d’ordonnancement)
Performance AnalysisModeling : propriétésPour l’étude de performancesorientée réseaux
Architecture globale du Profil UML MARTE
¨MARTE design model¨MARTE design model
A travers ce paquetage, MARTE fournit des concepts de plus haut niveau pour modéliser les exigences quantitatives et qualitatives des STR.
• "Generic Component Model " (GCM) : permet de décrire les systèmes à base de composants. Il prend en charge les protocoles de communications orientés messages et données entre les composants.
• " High-Level Application Modeling " (HLAM) : fournit des concepts de modélisation de haut niveau pour traiter les caractéristiques quantitatives telles que l’échéance et la période ainsi que les caractéristiques qualitatives liées au comportement, à la communication et à la concurrence
• "Software Resource Modeling " (SRM) : ce paquetage spécifie un ensemble d’artefacts de modélisation qui facilite la description de la structure du support d’exécution comme le système d’exploitation temps réel utilisés lors de l’exécution de système multi-tâches
• " Hardware Resource Modeling " (HRM) : ce paquetage est utilisé pour spécifier les plateformes matérielles. Il est décrits par deux vues complémentaires : logique et physique. La vue physique classifie les ressources matérielles en se basant sur leurs propriétés physiques. La vue logique classifie les ressources matérielles en se basant sur leurs propriétés fonctionnelles. 291
"MARTE analysis model"
MARTE analysis model
Ce paquetage offre des abstractions spécifiques et des annotations pertinentes interprétables par des outils d’analyse. Il fournit des évaluations fiables et précises à l’aide de techniques d’analyse quantitatives formelle basée sur des modèles mathématiques. Il est divisé en trois sous-paquetages :
• "Generic Quantitative Analysis Modeling " (GQAM) : fournit les concepts pour effectuer une analyse quantitative de propriétés non fonctionnelles associées au modèle. Ces concepts portent sur l’analyse de l’ordonnancement et de performance
• "Schedulability Analysis Modeling " (SAM) : C’est un raffinement du paquetage GQAM afin de pouvoir effectuer des analyses d’ordonnançabilité sur les modèles de conception. Il aide à prévoir si le système à analyser a la capacité à répondre à certaines contraintes temporelles, comme le respect des échéances et le temps de réponse.
• "Performance Analysis Modeling " (PAM) : C’est un raffinement du paquetage GQAM pour supporter une analyse de performance. Il fournit des moyens pour déterminer si un système peut fournir une performance adéquate en vertu de conditions comportementales non-déterministes, basées sur des valeurs statistiques. 292
Le Package de temps de MARTE
• Le paquetage de temps de MARTE est décomposé en 4 sous-paquetages :– TimeStructure : rassemble les concepts définissant le modèle de temps
constitué d’ensembles d’instants, les instants étant partiellement ordonnés. On y trouve en particulier le concept de ¨Clock¨
– Time Access : regroupe les moyens d’accès à la structure de temps
– TimeValueSpecification : permet de dénoter instants et durées
– TimeUsage : introduit les éléments de modélisation couramment utilisés :
• événements temporels
• Comportements temporels
• Contraintes temporelles
293
Le sous-paquetage "TimeUsage", qui définit les entités liées au temps, contient lui-même six paquetages :
"TimedElement" : le concept d’élément temporel est très général. Il exprime qu’un élément de modèle est lié au temps via un ou plusieurs horloges. La métaclasse correspondante est abstraite. Les spécialisa-tions concrètes de cette métaclasse précisent la sémantique de leur association avec les horloges.
294
Le sous-paquetage ¨TimeUsage¨
"TimedEvent" TimedEventOccurrence : Des instants peuvent être associés aux occurrences d’un
événement. MARTE introduit le concept d’occurrence d’événement temporel qui est à la fois un élément temporel et une occurrence d’événement. La propriété atspécifie la valeur d’instant d’une occurrence de l(événement considéré. Puisque plusieurs horloges peuvent être référencées (propriété on de l’élément temporel), plusieurs valeurs d’instants sont possibles pour la même occurrence. Généralement une seule horloge est retenue.
SimultaneousOccurrenceSet : MARTE introduit un nouveau concept, celui d’ensemble d’occurrences simultanées. Ce concept est indispensable quand plusieurs événement doivent être considérés collectivement car leurs effets ne peuvent pas être réduits à la sérialisation des effets de chacun. Un ensemble d’occurrence simultanée est une occurrence (EventOccurrence est une généralisation de SimultaneousOccurrenceSet. Du point de vue UML, cet ensemble peut causer une exécution de comportement
295
Le sous-paquetage ¨TimeUsage¨
296
Le sous-paquetage ¨TimeUsage¨
Occurrence d’événements temporels
TmedEvent : un événement temporel est un événement dont les occurrences sont liées au temps via une horloge. Les occurrence d’un événement temporel sont spécifiées par les propriétés attachées au TimedEvent.
– L’attribut isRelative indique si la valeur temporelle donnée par when est relative ou absolue
– La propriété when est une valeur temporelle qui précise l’instant d’occurrence. Cette valeur est une valeur d’instant s’il s’agit d’un temps absolu ; c’est une durée dans le cas contraire
– La propriété optionnelle every permet de caractériser les éventuelles occurrences suivantes du même événement. Lorsqu’elle définit, la propriété every est la valeur de la durée qui sépare deux occurrences successives
– L’attribut repetition permet, si nécessaire, de limiter le nombre d’occurrence
297
Le sous-paquetage ¨TimeUsage¨
Evénements temporels
298
Le sous-paquetage ¨TimeUsage¨
TimeProcessing :
TimedExecution : Une exécution temporelle est un élément de modèle qui spécialise une exécution de comportement (BehaviorExecution).
En tant qu’élément temporel une exécution temporelle fait référence à une ou plusieurs horloges. Deux valeurs d’instants : "startInstant" et "finishInstant" sont associées à une exécution.
Une exécution peut être caractérisée par une durée. Une transmission de message peut être assimilée à une exécution ; la valeur d’instant de début est alors celle de l’instant d’émission, la valeur d’instant de fin étant celle de l’instant de réception.
299
Le sous-paquetage ¨TimeUsage¨
Exécutions temporelles
300
Le sous-paquetage ¨TimeUsage¨
TimedProcessing : le traitement temporel est un concept générique pour modéliser des activités qui ont des instants de début et de fin connus ou une durée. De fait, la donnée de deux de ces trois informations est suffisante pour caractériser une exécution particulière.
Ce concept s’applique immédiatement aux comportements (TimeBehavior). Il s’étend facilement aux actions (TimeAction) qui ne sont pas en UML des comportements, mais des nœuds d’activités primitifs dont l’exécution entraîne une modification de l’état du système ou le retour d’une valeur.
Il s’étend également aux messages (TimedMessage) ; les événements de début et de fin sont nommés événements d’émission et de réception respectivement.
Le retard (Delay) est une action temporelle particulière qui représente une action ne faisant rien mais qui a une durée
301
Le sous-paquetage ¨TimeUsage¨
Traitements temporelles
302
Le sous-paquetage ¨TimeUsage¨
TimedObservationUne observation temporelle est un TimedElement. Elle est donc associée explicitement à une ou plusieurs horloges. Une observation temporelle peut référencer une exécution d’un système ou d’une partie d’un système (CompBehviorexecution) qui sert de contexte pour cette observation
303
Le sous-paquetage ¨TimeUsage¨
TimedObservation (suite)TimedObservation est une superclasse abstraite pour être différentes pour l’observations d’instants (TimedInstantObservation) et les observations de durées (TimedDurationObservation)
l’attribut obsKind permet de spécifier le type d’événement considéré dans l’observation temporelle.
Pour un comportement, les événements observés peuvent être le début (start) ou la fin (finish) d’une exécution.
Pour une requête, les événements, les événements possibles sont : son émission (send), sa réception (receive) ou sa prise en compte par le récepteur (consume).
Puisqu’une observation d’instant dénote un instant, une occurrence d’événement est observé sur une horloge donnée (propriété eocc).
Dans le cas d’une observation de durée, il existe plus de possibilités :
– Observation de la durée d’exécution (propriété exc)
– L’observation de la durée d’une requête, ou plus exactement de sa transmission ou le retard de sa prise en compte (propriété stim)
304
Le sous-paquetage ¨TimeUsage¨
TimedConstraint
une contrainte temporelle (TimedConstraint) est à la fois un élément temporel et une contrainte imposée sur les occurrences d’un événement (TimedInstantConstraint) ou sur la durée d’une exécution ou même sur la distance temporelle entre deux événements (TimedDurationConstraint).
Les contraintes sont spécifiées par des prédicats qui contiennent des usages d’observations temporelles
305
Le sous-paquetage ¨TimeUsage¨
Analyse de l’ordonnançabilité :Le package SAM de MARTE
• Le sous profil SAM de Marte est destiné à proposer une analyse d'ordonnançabilité des systèmes temps réel à l’aide des annotations standardisées, qui complètent des modèles UML.
• Ce sous profil contient trois packages de bases :– SAM_Workload pour la modélisation de la partie fonctionnelle d’un
système temps réel (les tâches, les propriétés temporelles, les relations de dépendances de données, etc),
– SAM_Resources pour exprimer la partie matérielle (les ressources d’exécution et les ressources de communication) et
– SAM_Observers qui permet d’annoter et comparer les contraintes temporelles contre les prédictions fournis par les outils d'analyse.
306
Le Package SAM_Workload
307
Modélisation des ressources Matérielles: Le Package HRM de MARTE
Le sous profil HRM de MARTE permet de modéliser les ressources matérielles d’une plateforme d’exécution. Ces ressources matérielles sont réparties en cinq packages :
– Hw_computing : Ressources de calcul ; comprenant l’ensemble des ressources fournissant des services d’exécution comme les processeurs, les ASIC (Application Specific Integrated Circuit) ou les PLD (Programmable Logic Device),
– Hw_storage : Ressources de mémorisation ; comprenant l’ensemble des ressources fournissant des services de mémorisation (persistantes ou non) comme les mémoires RAM, les caches ou les disques durs,
– Hw_Communication : Ressources de communication ; comprenant l’ensemble des ressources fournissant des services de transfert de données comme les bus ou les passerelles,
– Hw_Timing : Ressources de temps ; comprenant l’ensemble des ressources fournissant des services d’accès au temps comme les horloges,
– Hw_Device : Ressources auxiliaires ; comprenant l’ensemble des ressources fournissant des services d’accès aux éléments extérieurs du système comme les ressources d’entrée / sortie ou les senseurs.
308
309
Le Package HRM
Modélisation d’association : Le Package Alloc de MARTE
Ce méta-modèle sert à placer des éléments d’application sur les ressources disponibles. Un Marte allocation est une association entre une application et une plate-forme d’exécution.
L’ensemble de toutes les allocations du modèle définit le placement complet.
Le concept principal est représenté par le stéréotype « Allocated », utilisé pour spécifier des associations entre les éléments du modèle de l’application et des éléments du modèle de l’architecture.
310
Illustration: Encodeur JPEG
• L’encodeur JPEG (Joint Photographic Experts Group) pour la compression d’images est composé de sept étapes :
• Le processus de compressions JPEG accepte en entrée une image brute à partir d’un périphérique d’entrée (caméra).– la première étape du processus de compression consiste à découper l’image en
blocs de (8*8) soit 64 pixels. – À chaque bloc de pixels est appliquée une transformation de couleur en luminance
et chrominance.– Ensuite, une transformation DCT est appliquée à chaque bloc de pixels afin
d’exprimer les informations de l’image en terme de fréquence et d’amplitude. – Le flux de compression passe par la suite par l’étape de quantification qui est la base
de la compression. – L’application du codage de Hauffman à la matrice résultante de l’étape de
quantification amène enfin à une image compressée. 311
312
Modélisation du comportement fonctionnel
Modélisation du comportement fonctionnel
• Le flux de bout en bout de l’application est instancié JPEG par le stéréotype saEndtoEndFlow. Les cinq tâches ; rgb, dct, qu, hu et re sont stéréotypées SaStep et sont exécutées séquentiellement (chaque comportement dépend de celui qui le précède), par exemple la première instance dct du composant DisCoSTran ne peut être activée avant que la première instance rgb du composant RGB2YUV soit traitée. De la même manière, les autres instances (qu, hu, re) sont activées.
• Ceci nous permet de déduire des contraintes fonctionnelles, imposées au niveau application. Ces contraintes représentent un ordre d’exécution des tâches.
• Pour chaque tâche la date limite d’exécution est indiquée par la propriété deadline. Le port d’entré ayant la direction in (image brute) et le port de sortie ayant la direction out (image compressé).
Contrainte : Nous souhaitons avoir un débit de compression de 15 images par seconde pour un encodage JPEG d’images de taille (256*256) pixels. Cela signifie que la durée maximale pour encoder une image est de 0.066 secondes.
313
314
Modélisation de l’architecture matérielle
Modélisation de l’architecture matérielle
• La figure précédente illustre le modèle d’architecture considéré dans l’exécution de l’application JPEG.
• Trois unités de calcul sont définies pour traiter les différents composants fonctionnels de l’application JPEG.
• Les instances cpu_1 et cpu_2 sont stéréotypées hwProcessor et l’unité de traitement programmable FPGA est stéréotypée hwPLD. Le modèle mémoire instancié Memory par le stéréotype hwRAM est défini comme ressource de stockage et de récupération des données et des instructions du programme.
• L’émetteur (l’instance de composant Camera) et le récepteur (l’instance de composant Screen) ont pour rôle de produire et de consommer des pixels. Ils sont respectivement stéréotypés hwSensor et hwActuator selon le profil Marte.
• La communication entre les différents éléments matériels est assurée à travers un bus stéréotypé hwBus selon les concepts du profil Marte.
• Nous fixons dans ce cas d’étude les fréquences des unités de calcul comme suit : cpu_1 à 300 MHZ, cpu_2 à 250 MHZ et FPGA à 400 MHZ. Ces fréquences sont utiles pour calculer les facteurs vitesses (SF) des unités de traitement et les durées d’exécution des tâches.
315
Modélisation d’association
• L’association consiste à l’affectation de chaque composant fonctionnel de l'application à une ressource physique qui va prendre en charge son exécution.
• Une bonne association, entre les composants logiciels et matériels, permet de réduire considérablement le temps d’exécution des fonctionnalités de l’application et de respecter les contraintes de dépendances (ordre d’exécution), afin de garantir le bon fonctionnement du système.
• Un exemple d’association est donnée par la figure suivante :
la première tâche rgb est attribuée à l’unité de calcul programmable FPGA afin d’accélérer le traitement.
La tâche dct est associée au processeur cpu_1 et les tâches qu, hu et resont affectées au processeur cpu_2 à travers des connecteurs stéréotypés allocated.
316
317
Modélisation d’association
Outils de conception et d’analyse des performances et de l’ordonnancement
• Comme le témoigne le site web du profil MARTE (http://www.omgmarte.org/node/31), il existe une panoplie d’outils pour définir les modèles de conception conforme au profil MARTE tels que : papurys, Rhapsody 7.5, MagicDraw 15.5 et Rationnal Software Architecture (RSA)
• Afin d’effectuer des analyses de performances et d’ordonnancement, un pluging Eclipse a été développé par l’équipe Thales RT afin de permettre un pont vers l’outil Cheddar
318
Processing Schema for Analysis
319
Outils de conception et d’analyse des performances et de l’ordonnancement
320
Outils de conception et d’analyse des performances et de l’ordonnancement
Vérification d’ordonnançabilité• Nous faisons appel au framework de vérification Cheddar et l’algorithme
d’ordonnancement temps réel EDF afin de vérifier les propriétés : utilisation du CPU et le respect des échéances.
• Nous commençons par vérifier que le taux d’utilisation du processeur cpu_1 est inférieur à une borne supérieur, selon la politique d’ordonnancement, dans notre cas cette borne est égale à 1.
321
1. Introduction
2. Rappels d’UML
3. UML2.0 et le temps réel
4. Méta-modélisation
5. Les profils UML
6. Les profils dédiés aux SETR : le profil UML MARTE
7. Les Processus de développement pour les SETR basées
sur UML
8. Les outils de développement UML pour les SETR
322
2ème Partie : UML pour le Temps Réel et
l’Embarqué
Processus Unifié (Rappel)
Cours :– Conduite de projet
Méthode d’analyse et de conception Processus unifiéG. Picard, Ecole Nationale Supérieur des Mines Saint-Etienne
– Methodologie de Développement objet : UP et Agile
Christine Solnon, INSA de Lyon
323
Objectifs d’un processus dedéveloppement (Rappel)
• Un processus définit QUI fait QUOI, QUAND et COMMENT pour atteindre un certain objectif
- Construction des modèles d’un ou de plusieurs systèmes
- Organisation du projet
- Gérer le cycle de vie du projet de A à Z
- Gérer les risques
- Obtenir de manière répétitive des produits de qualité constante
Activités de développement (rappel)
• Planification (Étude de la faisabilité)• Spécification des besoins• Analyse (Spécification formelle)• Conception (Spécification technique)• Implémentation (Codage)• Tests unitaires• Intégration et tests• Livraison• Maintenance
Développement (rappel)Modèle en cascade
Développement (rappel)Modèle en V
Développement (rappel)Modèle en Spirale
Processus Unifié – Principes (1)
• Il n’existe pas un seul processus de développement, ni de processus standard
• CEPENDANT
des caractéristiques essentielles peuvent être mises en avant :
- Itératif et incrémental
- Pilotage par les cas d’utilisation
- Focalisation sur l’architecture
- Utilisation de « patrons » de conception (Design Patterns)
329
Processus unifié – Principe (3)Piloté par les cas d’utilisation
331
Processus Centré sur l’architecture
333
Plusieurs manières de voir un système
Le processus 2TUP
Branche fonctionnelleLes principales étapes de la branche fonctionnelle se présentent commesuit :- L’étape capture des besoins fonctionnels produit le modèle des besoinsfocalisé sur le métier des utilisateurs. Elle qualifie, au plus tôt le risque deproduire un système inadapté aux utilisateurs. Cette phase a pour objectifde définir :
· La frontière fonctionnelle entre le système considéré comme uneboite noire et son environnement, c’est le niveau contexte.· Les activités attendues des différents utilisateurs par rapport ausystème toujours envisagé comme une boite noire, c’est le niveaucas d’utilisation.
- L’étape d’analyse consiste à étudier précisément les spécifications fonctionnelles de manière à obtenir une idée de ce que va réaliser le système en terme de métier.
Le processus 2TUP
Branche technique
Les principales étapes de la branche technique se présentent comme suit :- L’étape capture des besoins techniques recense toutes les contraintes
sur les choix de dimensionnement et la conception du système. Les outils et le matériel sélectionnés ainsi que la prise en compte des contraintes d’intégration avec l’existant (pré requis d’architecture technique). Cette étape permet de définir le modèle d’analyse technique. Le rôle de ce dernier est d’établir les couches logicielles et y spécifie les activités techniques attendues.
- L’étape conception générique définit ensuite les composants nécessaires à la construction de l’architecture technique. Cette conception est complètement indépendante des aspects fonctionnels. Elle permet de générer le modèle de conception technique ou design pattern qui définit les Frameworks. Ces derniers, délivrant les services techniques, assurent la réponse aux exigences opérationnelles du système.
Le processus 2TUP
Branche conception - réalisation
Les principales étapes de cette branche se présentent comme suit :- L’étape conception préliminaire est une étape délicate, car elle intègre le
modèle d’analyse fonctionnelle dans l’architecture technique de manière à tracer la cartographie des composants du système à développer. Cette étape permet de produire le modèle de conception système. Ce dernier organise le système en composants, délivrant les services techniques et fonctionnels. Ce modèle regroupe les informations des branches technique et fonctionnelle.
- L’étape conception détaillée permet d’étudier comment réaliser chaque composant. Cette étape produit le modèle de conception des composants. Ce modèle fournit l’image prête à fabriquer du système complet. C’est dans l’étape de codage que s’effectue la production des composants et les testes des unités de code au fur et à mesure de leur réalisation.
- L’étape de recette consiste à valider les fonctionnalités du système développé.
Le processus 2TUP
- ROPES : Rapid Object-oriented Process for Embedded Systems
- UML-RT (ROOM) : UML Real Time (Real-time –OrientedModeling)
- ACCORD/UML : Ingénierie des modèles pour le développement de systèmes temps rée embarqués
- UML/SDL : UML / Software Descrption Langage
342
Les Processus de développement pour les SETR
Le cycle de vie ROPES
343
Processus de développement pour les SETR↘La méthodologie ROPES
Les différentes étapes cycliques
- Analyse- Analyse des besoins
- Analyse du système – Architecture
- Analyse objet
- Conception- Conception architecturale
- Conception mécaniste
- Conception détaillée
- Translation –Implémentation
- Tests344
Processus de développement pour les SETR↘La méthodologie ROPES
Processus de développement pour les SETR↘La méthodologie ROPES
La phase d’Analyse
- Analyse des besoins- Identification des exigences et besoins du client
- Analyse au niveau des vues fonctionnelles du système
→ Diagramme d’utilisation, de séquence, d’états-transitions …
- Analyse du système – Architecture- Proposer une vision de l’architecture fonctionnelle du système
→ Diagramme de composants, de déploiement
- Analyse objet- Identification des objets et des classes essentielles ainsi que leurs propriétés
→ Diagramme de classes, de collaborations, de séquences …345
346
Processus de développement pour les SETR↘La méthodologie ROPES
La phase de Conception
- Conception architecturale
- Identification et caractérisation des threads
- Définition des composants logiciels et leurs distributions
- Application de « design patterns » pour la gestion des erreurs, de la sécurité, …
→ Diagramme des classes, d’objets, de composants, de déploiement …
- Conception mécaniste
- Raffinement des objets (contrôleurs associés aux objets, …)
→ Diagramme de collaborations, de classes, d’objets
- Conception détaillée
- Définition de la structure interne de chaque classes, message, opération, …
→ Diagramme de classes, de collaborations, …
Les phases de Translation et de test
- La phase de translation – implémentation
- Passage des modèles conceptuels au code concret
- La phase de test- Tests d’intégration
- Tests de validation
347
Processus de développement pour les SETR↘La méthodologie ROPES
1. Introduction
2. Rappels d’UML
3. UML2.0 et le temps réel
4. Méta-modélisation
5. Les profils UML
6. Les profils dédiés aux SETR : le profil UML MARTE
7. Les Processus de développement pour les SETR basées
sur UML
8. Les outils de développement UML pour les SETR
348
2ème Partie : UML pour le Temps Réel et
l’Embarqué
349
Les outils pour le développement des SETR
350
Les outils pour le développement des SETR