UML pour le temps réel et l`embarqué

Transcription

UML pour le temps-réel et l’embarqué
1
Module ME1 : Ingénierie du logiciel
Audrey Marchand 2005-2006
Plan du cours
Introduction
Rappels d’UML
Les designs patterns pour le temps-réel
Les apports de la nouvelle norme UML 2.0
Les profils UML dédiés aux SETR
Les méthodologies de développement des SETR basées sur UML
Les outils de développement UML pour les SETR
Conclusion
2
Introduction
Les contraintes de modélisation pour le temps-réel
- Résultat fourni dans le respect des contraintes temporelles (échéances)
- Pseudo-concurrence (monoprocesseur) et concurrence réelle (multiprocesseur)
- Ordonnancement des activités périodiques / apériodiques
- Partage de ressources
- Prédictibilité, ordonnançabilité et déterminisme
- Tolérance aux fautes et sûreté de fonctionnement
3
Introduction
Les contraintes de modélisation pour l’embarqué
- Fiabilité
- Sécurité
- Modularité
- Spécificité (support hardware)
- Encombrement
- Energie
- Coût
4
Introduction
Avantages de la modélisation objet
- Consistance des vues du modèle
- Abstraction adaptée au domaine du problème
- Flexibilité accrue
- Modularité
- Réutilisation facilitée
- Evolutivité aisée
- Facilité pour le déploiement d’applications
5
Rappels d’UML
UML : Unified Modeling Language
- UML 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 de besoins
- un support de modélisation du comportement
- UML a été accepté comme standard par l’OMG (Object Management
Group) en 1997
6
Rappels d’UML
UML : l’historique
7
Rappels d’UML
UML : objets, classes et interfaces
- Un objet est une entité d’exécution qui occupe de la mémoire à un moment
donné dans le temps (instance de classe)
- possède un comportement (méthodes)
- possède des données (attributs)
- Une classe est un concept qui définit la structure et le comportement d’un
ensemble d’objets créés à l’exécution
- spécifie un comportement (méthodes)
- spécifie des données (attributs)
- Une interface est un concept qui spécifie les messages qu’une classe reçoit
- possède seulement un comportement (opérations)
8
Rappels d’UML
UML : les diagrammes
- UML 1.4 comporte 9 types de diagrammes :
Diagramme
de séquence
Diagramme
d’activité
Diagramme
d’état-transition
Diagramme des
cas d’utilisation
MODELE
Diagramme
de
collaboration
Diagramme
de classe
Diagramme
d’objets
Diagramme de
composants
Diagramme
de
déploiement
9
Rappels d’UML
Diagramme des cas d’utilisation
Se déplacer
Ecouter de la musique
GARAGISTE
Téléphoner
CONDUCTEUR
Faire la vidange
Changer les bougies
- Comment spécifier des contraintes temporelles ?
« Lorsque l’acteur CONDUCTEUR envoie une commande ClignotantDroit, le temps de
réponse du système ne doit pas excéder 10ms »
10
Rappels d’UML
Diagramme de séquence
: Appelant
: Ligne
téléphonique
: Appelé
Décroche
Tonalité
Numérotation
Indication de sonnerie
Sonnerie
Décroche
Allô
- Spécification temporelle sur un diagramme de séquence :
Délai de propagation ?
: O1
: O2
Spécification informelle !
m1
<1 sec.
m2
11
Rappels d’UML
Diagramme d’activité
Client
Serveur
EntreResto
AttenteClient
[Resto complet]
AttenteTable
[tables libres]
PrendTable
Commande
PrendsCommande et sert
Mange
Attend facture
Paie et sort
12
Rappels d’UML
Diagramme d’état-transition
éteindre
AppuyerTouche
Disponible
EnMarche
termine
Non-déterministe car traité comme tous les autres événements !
- Spécification temporelle sur un diagramme d’état-transition : TimeEvent
Spécification de temps relatif :
Spécification de temps absolu :
Etat 1
Etat 1
after (10 ms) / ‘action-list’
Etat 2
when (t=now+10s) / ‘action-list’
Etat 2
13
Rappels d’UML
Diagramme de collaboration
: Ascenseur
1 : Monter
3 : Fermer
: Cabine
: Porte
2 : Allumer
: Lumière
Un objet Ascenseur envoie un message Monter à un objet Cabine, puis
l’objet Cabine envoie un message Allumer à un objet Lumière, et enfin
Cabine envoie un message Fermer à un objet Porte.
14
Rappels d’UML
Diagramme de classes
1
AD_Convert
contrôleur
1
*
1
*
Actionneur
Capteur
controlRegister
CapteurPression
CapteurTemperature
controlRegister
valve
MoteurPas
15
Rappels d’UML
Diagramme d’objets
: Fenêtre
Fenêtre
2
Ascenseur
1
1
: Zone de dessin
: Ascenseur
1
Zone de dessin
Diagramme de classes
: Ascenseur
Diagramme d’objets
16
Rappels d’UML
Diagramme de composants
<<file>>
<<file>>
Contrôleur_machine.h
Contrôleur_machine.c
<<Exécutable>>
Contrôleur_machine.exe
17
Rappels d’UML
Diagramme de déploiement
1
PC
<<Processeur>>
<<RS-232>>
1
Imprimante
*
<<dispositif>>
Console
1
1
*
Robot
*
18
Rappels d’UML
Utilisation des modèles UML
Modèle
Exemple d’utilisation
Nature
Use case
Expression du besoin
Dynamique
Classe
Modèle conceptuel, modèle de données,
Statique
organisation
Séquence
Exemple de fonctionnement
Dynamique
Collaboration
Coopération entre objets
Dynamique
Explication d’architecture
Etat/transition
Dynamique de fonctionnement
Dynamique
Activité
Workflow, Dynamique de fonctionnement
Dynamique
Composant
Modèle physique, organisation des ressources
Statique
Déploiement
Distribution, diagramme d’architecture
Statique
19
Rappels d’UML
Classification échelle des diagrammes (B. P. DOUGLASS)
- Modélisation medium scale :
• Diagramme de classe et d’objets
• Diagramme de séquences
• Diagramme statechart
– Modélisation large scale :
• Diagramme d’utilisation
• Diagramme de package
• Diagramme de déploiement
– Modélisation small scale :
• Diagramme d’activité
20
Rappels d’UML
Faiblesses générales d’UML 1.4
- Manque de sémantique formelle
- Multiplicité des modèles : nombre écrasant de diagrammes et de symboles
- Peu de relations bien définies entre les diagrammes d’un modèle
- Pas de structure hiérarchique dans la composition des modèles
- Implémentations du langage différentes selon les outils
21
Rappels d’UML
Faiblesses d’UML 1.4 vis-à-vis du temps-réel
- Manque de concepts pour exprimer les contraintes et propriétés temps-réel
- période, échéance, date de réveil, durée d’exécution, priorité, laxité…
- Pas de structures de communication assez évoluées
- ports, connecteurs, protocoles, sémaphores…
- Pas de techniques d’ordonnancement proposées
- Round-Robin, FCFS, RM, DM, EDF, LLF…
- Spécification de temps informelle
22
Les design patterns pour le temps-réel
Les Design Patterns
Class
name
- Solution généralisée d’un
problème commun
Class
name
Pattern Name
Package
- Approche pour le reuse
Class
name
- Mécanismes paramétrables lors de
la création d’une collaboration
Class
name
Package
- Un design pattern se décompose en 3 parties :
Class
name
- un contexte du problème
- une approche généralisée de la solution
- un ensemble de conséquences pour le design
23
Design Patterns architecturaux (1)
24
Design Patterns architecturaux (2)
25
Execution Control Pattern
26
Static Allocation Pattern
27
Priority Ceiling Pattern
28
Watchdog Pattern
: Watchdog
: Channel
Service
Service
Service
Timeout
Reset
29
Safety Executive Pattern
30
Les apports de la nouvelle norme 2.0
L’UML 2.0
- Standard officiellement adopté en Juin 2003 lors d’un meeting de l’OMG
- Origine :
- 4 RFPs (Request For Proposals) émis par l’OMG
- Caractéristiques générales :
- 4 documents de spécifications différents (au lieu d’un seul) :
- UML 2.0 Infrastructure
- UML 2.0 Superstructure
Scission entre le cœur du langage
et les éléments de modélisation
- UML 2.0 OCL
- UML 2.0 Diagram Interchange
- Approche de méta-modèles à 4 couches
31
4 documents de spécifications
- UML 2.0 Infrastructure
- Améliore l’alignement d’UML sur les autres standards de modélisation de l’OMG
- Rend UML plus facile à comprendre, implémenter et étendre
- Améliore les mécanismes d’extensibilité d’UML
- UML2.0 Superstructure
- Supporte l’ingénierie logicielle à base de composants
- Clarifie les sémantiques de généralisation, dépendances et relations
- Supporte l’encapsulation dans la modélisation du comportement
- UML 2.0 OCL
- Définit un méta-modèle OCL (Object Constraint Language) consistant avec UML
- UML 2.0 Diagram Interchange
- Cible le problème de l’échange des diagrammes
32
Approche de méta-modèles à 4 couches
33
UML 2.0 : les nouveaux diagrammes
34
Les diagrammes de modélisation structurelle (1)
- Le diagramme de classes (peu modifié) :
PC
1
Carte mère
1
Carte graphique
1
1
1
1
Carte USB
35
- Le diagramme de structure composite (nouveau diagramme) :
PC
Carte mère
Carte graphique
Interface fournie
clavier
Interface requise
IKeybListener
video
clavier
Carte USB
video
IDisplay
usb
Port
usb
Comportement
IUSB_in
IUSB_out
36
- Le diagramme de paquetages (nouveau diagramme) :
Interface
Utilisateur
Liste des
chansons
dépendance
paquetage
Playlist
Playback
Paiement
37
- Le diagramme de composants (modifié) :
- notation condensée :
- notation intermédiaire :
- notation avec le détail
des interfaces :
38
- Le diagramme de déploiement (peu modifié):
39
Les diagrammes de modélisation comportementale (1)
- Le diagramme de séquence (modifié) :
- avec contraintes sd choisirboisson
de temps :
:paiementContrôleur
:machineContrôleur
pièce(1)
unEuro()/t1=now
tea()/t2=now
{t2..t2+3}
retourmonnaie()
- avec alternative :
{t1..t1+5}
sd paiementboisson
:paiementContrôleur
:machineContrôleur
alt
pièce(50)
[valeurPièce==50]cinquantecent()
pièce(1)
else
UnEuro()
40
- Le diagramme de vue d’ensemble des interactions (nouveau diagramme) :
td machine_à_boisson
sd choixboisson
:machineContrôleur
alt
thé()
café()
ref
paiementBoisson
[timeout]
[paid]
41
- Le diagramme de timing (nouveau diagramme) :
sd contrBehavior
{t2..t2+2}
:machineContrôleur attente paiement
payé 1
préparation café
0
5
10
sd contrBehavior
Vue
compacte :
{t2..t2+2}
:machineContrôleur attente paiement
payé 1
0
5
préparation café
42 10
Application à la modélisation de tâches temps-réel
Task A
period = 20ms
exec time = 6ms
priority = élevée
Task B
period = 80ms
exec time = 2ms
priority = moyenne
Task C
period = 100ms
exec time = 10ms
priority = faible
task_A
task_B
task_C
1
1
1
{task_A utilise la
ressource durant 5ms}
DataClass
1
{task_C utilise la
ressource durant 4ms}
Æ Tracer le diagramme de timing correspondant
43
Profils UML : définition
- Profil : Mécanisme d’extension permettant d’effectuer des extensions
courantes sans avoir à modifier le langage de modélisation
- Possibilité de réaliser des extensions limitées d’UML pour l’adapter à un
domaine, une technologie ou une implémentation spécifiques
- Un profil se compose de différents mécanismes d’extensibilité :
- des stéréotypes : nouveaux
types d’éléments de modèle fondés
sur des types de modèles existants
- des contraintes : instructions
textuelles de la relation sémantique
- des valeurs étiquetées :
éléments d’information désignés,
attachés à un élément de modèle
Borne
Spectacle
Nom : Chaîne
« réalisation »
Programmation
« ethernet »
Serveur
{les noms pour une saison
doivent être uniques}
« réalisation »
auteur = "Franck Martin"
remise = 31 déc. 2005
44
Les profils dédiés aux systèmes embarqués et au temps-réel
- Profils adoptés par l’OMG :
- SPT : Schedulability, Performance and Time
- QoS and FT : QoS and Fault-Tolerant
- Profils en cours de soumission :
- MARTE : Modeling and Analysis of Real-Time and Embedded systems
- TURTLE : Timed-UML RT-Lotos Environment
- OMEGA : Modélisation et validation de systèmes temps-réel
- Embedded UML : Approche pour le co-design hardware/software en temps-réel
45
Ê Le profil « Schedulability, Performance and Time »
Origine
- Premier d’une série d’appels à soumission (RFPs) dédiés au temps-réel
- RFP émis en Mars 1999 : demande d’« un paradigme basé sur UML pour la
modélisation des aspects liés au temps, à l’ordonnancement et à la performance
dans les systèmes temps-réel »
- Proposition initiale soumise en Août 2000
- Consortium :
- ARTiSAN
- Telelogic
- I-Logix
- TimeSys
- Rational
- Tri-Pacific Software
- Standard adopté en Septembre 2001
46
Objectifs de contenu
- Méthodes considérées pour le profil :
Analyse d’ordonnançabilité
Toutes les échéances
temporelles du système
seront-elles respectées ?
Analyse de performance
Quel type de réponse le
système fournira-t-il en fonction
de la charge d’exécution ?
- Aspects considérés pour les méthodes :
- temps physique
- spécifications temporelles
- services et mécanismes temporels
- ressources (logiques et physiques)
- ordonnancement et concurrence
- infrastructure logicielle et matérielle ainsi que leurs relations
47
Structure
48
Structure : partie normative
Stéréotypes et valeurs
étiquetées
pour la modélisation des
ressources et de la QoS
étiquetées
pour la modélisation de
la concurrence
étiquetées
pour la modélistion
du temps
étiquetées
pour l’analyse
d’ordonnançabilité
Extension du SAprofil
étiquetées
pour l’analyse de
performance
49
La modélisation des ressources et de la QoS
Ressource : élément dont la capacité de service est limitée, directement ou
indirectement, par les capacités finies de l’environnement d’exécution physique
sous-jacent
Quality of Service (QoS) : spécification (généralement quantitative) de la
manière selon laquelle un service est assuré (bande passante, temps de
réponse…)
50
51
La modélisation du temps : vue générale
52
La modélisation du temps : les stéréotypes (1)
53
La modélisation du temps : les stéréotypes (2)
- Les valeurs de temps peuvent être représentées par un stéréotype
particulier de valeurs, appelé « RTtime », regroupant différents formats :
- 12:04 (heure)
- 5.3 ms (intervalle)
- 07/12/2005 (date)
- Wed (jour)
- $param ms (valeur paramétrable)
- ‘poisson’, 5.1 sec (valeur avec une distribution de Poisson)
- ‘histogram’, 0, 0.3 1, 0.4 2, 0.3 (histogramme)
54
La modélisation de la concurrence : vue générale
55
La modélisation de la concurrence : les stéréotypes
56
Le sous-profil d’ordonnançabilité : vue générale
57
Le sous-profil d’ordonnançabilité : les stéréotypes (1)
58
59
60
61
Les processus de développement pour les SETR
- ROPES : Rapid Object-oriented Process for Embedded Systems
- UML-RT (ROOM) : UML Real-Time (Real-time Object-Oriented Modeling)
- ACCORD/UML : Ingénierie des modèles pour le développement de
systèmes temps réel embarqués
- UML/SDL : UML / Software Description Language
62
Ê La méthodologie ROPES
Le cycle de vie en V
Il consiste à associer à chaque étape de conception une autre étape de test
63
Le cycle de vie ROPES
64
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
- Tests
65
La phase d’analyse
- Analyse des besoins
- Identification des exigences et besoins du client
- analyse au niveau des vues fonctionnelles du système
Æ Diagrammes d’utilisation, de séquence, d’état-transition…
- Analyse du système - Architecture
- proposer une vision de l’architecture fonctionnelle du système
Æ Diagrammes de composants, de déploiement
- Analyse objet
- identification des objets et des classes essentiels ainsi que leurs propriétés
Æ Diagrammes de classes, de collaborations, de séquence…
66
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é
Æ Diagrammes de classes, d’objets, de composants, de déploiement…
- Conception mécaniste
- raffinement des objets (contrôleurs associés aux objets…)
Æ Diagrammes de collaborations, de classes, d’objets…
- Conception détaillée
- définition de la structure interne de chaque classe, message, opération…
Æ Diagrammes de classes, de collaborations…
67
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
68
Illustration
69
Les outils de développement UML pour les SETR
Les outils du marché pour le développement des SETR (1)
- Les outils propriétaires :
- Rhapsody (UML 2.0) de chez I-Logix (http://www.ilogix.com)
- Rational Rose Real-Time (UML-RT) de chez IBM (http://www.rational.com)
- Real-Time Studio (ACCORD/UML) de chez ARTiSAN (http://www.artisansw.com)
- Tau Generation 2 (UML/SDL) de chez Telelogic (http://www.telelogic.com)
- Metamill (UML 2.0) de Metamill Software (http://www.metamill.com)
- Visual Paradigm for UML (UML 2.0) de chez Visual Paradigm…
(http://www.visual-paradigm.com)
70
Les outils de développement UML pour des SETR
Les outils du marché pour le développement des SETR (1)
- Les outils open-source :
- ArgoUML (UML 1.3) (http://www.argouml.tigris.org)
- Poseidon (UML 1.3 / UML 2.0 partiel) (http://www.gentleware.com)
- StarUML (UML 2.0 partiel) (http://www.staruml.com)
71
Conclusion
Conclusion
- UML 1.x ne possède pas de concepts de modélisation de contraintes et de
propriétés temps-réel
- Utilisation des design patterns pour le temps-réel
- UML 2.0 permet de modéliser des contraintes et des propriétés temps-réel
mais la norme reste un peu juste
- Le profil SPT offre des constructions pour modéliser différents aspects des
systèmes temps-réel (ressources, temps, ordonnancement, performance, etc.)
Æ focalisé sur des aspects plus syntaxiques que sémantiques
Æ pas de lien avec la sémantique de la partie fonctionnelle du modèle UML
- Futur : évaluation des propositions en réponse au dernier RFP de l’OMG du
06 février 2005 pour le temps-réel et l’embarqué :
ÆUML Profile for Modeling and Analysis of Real-Time and Embedded
Systems (MARTE), deadline : 14 novembre 2005
72
Références
Références
- B. P. Douglass, Doing Hard Time: Developing Real-Time Systems with
UML, Objects, Frameworks and Patterns, Addison Wesley, 1999
- B. P. Douglass, Real-Time UML : Developping Efficient Objects for
Embedded Systems, Addison Wesley, 1999
- J. Rumbaugh, I. Jacobson, G. Booch, UML 2.0 Guide de Référence,
CampusPress, 2004
- C. Larman, UML 2 et les design patterns, Pearson Education, 2005
- P. Roques, F. Vallée, UML 2 en action : De l’analyse des besoins à la
conception J2EE, Eyrolles, 2004
- http://www.omg.org
73

UML pour le temps réel et l`embarqué

Transcription

Documents pareils

Six ans de formations avec de grands fleuristes

Fiat Ducato 2.3 JTD L2 H1

Fiat Ducato 2.8 JTD MAXI / BENNE / MOTEUR CASSE / HS

ingénieur consultant électronique hw – h/f

INGÉNIEUR CONSULTANT QUALITÉ – H/F

ingénieur consultant en achats h/f

ingénieur consultant en électrotechnique h/f

INGÉNIEUR CONSULTANT MISE EN SERVICE

DM Génie Logiciel Projet Serious Game

centre hospitalier sainte-anne organigramme de direction 2013