Systèmes en temps réel
Modélisation du comportement en temps réel avec
UML
Comportement (partie 1) - 2
Synopsis
Machines d’état (Hiérarchique) état transitions initialisation points de décision idées de base pour modeler
Diagrammes d’états en RoseRT
Exercice
Comportement (partie 1) - 3
Machines d’états : état
Une condition durant la vie d’un objet dans laquelle il est prêt à traiter un événement
Peut contenir un nombre d’autre états Emboîtés de profondeur n
a Un nom Des actions d’entrée/sortie optionnels
Action d’entrée Action de sortie Actions d’entrée/sortie
Idle Active Error
Comportement (partie 1) - 4
Machines d’états : transitions
Relation entre l’état source et l’état destination
Spécifie les conditions sous lesquelles un objet dans l’état source va changer à l’état destination
Contiens: Un déclencheur (trigger) Une condition de garde Actions
Comportement (partie 1) - 5
Machines d’états : initialisation
État initial (optionnel) – État de départ de la machine d’état est définit explicitement.
Elle a: Une transition initiale – ne peut pas être gardé État de départ – premier état actif
Attente
état initial
transition initiale
état de départ
Comportement (partie 1) - 6
Machines d’états : points de décision
Permet à une seule transition d’être séparée en deux segments de transition sortants
Comportement (partie 1) - 7
Machines d’états : idées de base
Souvent les appareils ont des états en-service (actif) ou hors-service (attente ou passif)
Toutes les capsules devraient avoir un état police (état d’erreur) à la couche supérieure
Passif
Erreur
Actifinitial en-service
hors-service
erreurerreur
Comportement (partie 1) - 8
Machines d’états : idées de base
L’héritage va nous permettre de réutiliser la machine d’états de la couche supérieure La super-classe définit la couche supérieure
des états communs à toutes les sous-classes Bien que les sous-classes fournissent les
détails pour le reste de la machine d’état
Utilisez les diagrammes de séquences pour aider à l’analyse des transitions entre les états
Comportement (partie 1) - 9
Diagrammes d’états en RoseRT
Toutes les capsules ont un diagramme d’états qui leurs est associé
Les ports terminaux doivent être définis sur une capsule pour que les messages qui entrent puissent être utilisés comme événements déclencheurs Ceci inclus tous les ports de système
La sélection du message qui est désigné avec “*” veut dire que tous les messages qui entre sur le port choisi va déclencher la transition.
Le code d’action ajouté dans les diagrammes d’états en RoseRT est en C, C++, ou Java
Comportement (partie 1) - 10
Diagrammes d’états en RoseRT
Pas de code de transition
code de transition
Aucun déclencheur
déclencheur
Code d’action d’entrée
Code d’action d’entrée/sortie
Pas de code d’action d’entrée/sortie
Comportement (partie 1) - 11
Diagrammes d’états en RoseRT
Application de déclencheurs sélectionne port sélectionne signal
Applique gardes Entrez le code de
garde associé avec le déclencheur correspondant
Comportement (partie 1) - 12
Diagrammes d’états en RoseRT
Code d’action Envoie des
messages Appel des
opérations Ports de service Classes passive Capsule
Comportement (partie 1) - 13
Rappel: exemple System Processor
Comportement (partie 1) - 14
Exercice en classe – comportement de ECM
Implémentez ce qui suit: Initialisez un temps de brouillage continue de 250 msec Commencez le brouillage quand le message JamEmitterID
est reçu Après l’écoulement du temps de brouillage initialisez une
séquence d’observation (look-through) Demandez des données de mise à jour de l’émetteur
(pendant la séquence d’observation) Retournez au brouillage quand vous recevez le signal
Continue Retournez à l’état passif (idle) quand le signal StopJam
vous est envoyé
Comment informeriez-vous le Controller de l’état du brouillage?
Comportement (partie 1) - 15
Exercice – comportement de ECM
Comportement (partie 1) - 16
Solution 1
Comportement (partie 1) - 17
Solution 2