2ème Partie CSTR 2014

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



5. Les profils UML



sur UML


159


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


« 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


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


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


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


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


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


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


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


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


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


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


: objet1

Message 1()

Possession

du contrôle

: Client

Message 2()

Message 3()

: objet2 : objet3

Message 4() Message 5()

Retour message 3()

Ligne de vie


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


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}


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()


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()


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()


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


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


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()


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 »


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


• 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


• 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


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)


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()


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é


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


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


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


203

Etat composite

E2

E1

E3

E4

E1 E2

E3E4

E5 E5

Etat composite


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


activer A/R


activer A/R

[typeMobile]

[else]


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


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


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


• 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


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


• 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


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


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


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]


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


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


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


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


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é


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


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


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


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



5. Les profils UML



sur UML


233


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


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()


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}


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


• 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


• 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


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.


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


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


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


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



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



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


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


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


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


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


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


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


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


Modélisation de propriétés temporelles dans le diagramme de temps (1/2)

257


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



5. Les profils UML



sur UML


260


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


M1 : spécification du Système

269


• 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é)


• 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



5. Les profils UML



sur UML


277


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


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


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


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



5. Les profils UML



sur UML


286


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


296


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


Evénements temporels

298


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


Exécutions temporelles

300


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


Traitements temporelles

302


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


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


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


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

http://www.omgmarte.org/node/31

Processing Schema for Analysis

319


320


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



5. Les profils UML


7. Les Processus de développement pour les SETR basées

sur UML


322


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



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


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


1. Introduction

2. Rappels d’UML



5. Les profils UML


7. Les Processus de développement pour les SETR basées

sur UML


348


l’Embarqué

349

Les outils pour le développement des SETR

350

Les outils pour le développement des SETR

Documents

2ème Partie CSTR 2014