Ce chapitre contient des informations sur les diagrammes d’états en UML. Ce sujet est traité dans le chapitre A29/F25 .
Les diagrammes d’états sont aussi connus comme des machines à états. Il s’agit de la modélisation des états d’un processus, d’un système, d’un composant, etc. Un état est une simplification de la réalité de quelque chose qui évolue dans le temps. Cela permet de modéliser le comportement de quelque chose face à un événement.
Les points importants :
- Un diagramme d’états sert à modéliser les comportements. Un concept préalable : Automate fini .
- Un diagramme d’états contient les éléments suivants :
- Événement :
- occurrence d’un fait significatif ou remarquable ;
- État :
- condition d’un objet à un moment donné, jusqu’à l’arrivée d’un nouvel événement ;
- Transition :
- relation état-événement-état ;
- indique que l’objet change d’état.
- Événement :
- La différence entre les objets :
- Un objet répondant de la même manière à un événement donné est un objet état-indépendant (par rapport à l’événement) ;
- Un objet répondant différemment, selon son état, à un événement donné est un objet état-dépendant.
- Les transitions peuvent avoir des actions et des conditions de garde.
- Dans la notation, il y a également la possibilité de faire des états imbriqués.
Voir le livre de Larman (2005) pour un exemple illustrant des éléments d’un diagramme d’états pour un système téléphonique (figure A29.3/F25.10 ).
17.1 Exercices
Exercice 17.1 (États d’un téléphone) Faites un diagramme d’états en UML modélisant les états d’un téléphone intelligent. Considérez une dynamique simplifiée, avec seulement trois états correspondant aux images suivantes :
Pour simplifier encore le modèle : le bouton en haut à droite sert à éteindre et à allumer l’écran. Le téléphone est initialement éteint. Vous pouvez ignorer le bouton rond au centre en bas. On peut brancher l’alimentation pour charger le téléphone à tout moment, mais le bouton n’a aucun effet sur l’écran lorsque le téléphone est connecté à l’alimentation. Lorsque l’on débranche l’alimentation, l’écran est toujours éteint.
Exercice 17.2 (Guichet automatique) Faites un diagramme d’états en UML qui correspond au système décrit par les cas d’utilisation suivants (format bref) :
S’authentifier. Le Client arrive à un guichet automatique bancaire, car il désire effectuer une transaction sur son compte. Le Client introduit sa carte bancaire, et le système attend qu’il saisisse le NIP de la carte. Si le NIP est valide pour la carte, alors le système est prêt à accepter d’autres actions. Sinon, le système enregistre la mauvaise tentative et demande de nouveau au Client de saisir son NIP. À tout moment où le système possède la carte du Client, ce dernier peut annuler la session pour récupérer sa carte.
Gérer guichet. L’Administrateur démarre le système, et le système attend l’introduction d’une carte bancaire du Client. Quand le système est dans cet état, l’Administrateur peut aussi l’éteindre.