Ce chapitre contient des informations sur les diagrammes d’états en UML. Ce sujet est traité dans le chapitre A29/F25 .
Il s’agit de la modélisation. Un état est une simplification de la réalité de quelque chose qui évolue dans le temps.
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 .
La figure 17.1 est un exemple tiré du livre de Larman (2005) et est fait en PlantUML.
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 l’autre 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 pour accepter d’autres actions. Sinon, le système enregistre la mauvaise tentative et demande de nouveau au Client de saisir son NIP. À tout moment que 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.