Diagramme d’états-transitions

1. Décrire le comportement d’un objet

Un diagramme d’états-transitions décrit les situations durables d’un objet et les événements qui permettent de passer de l’une à l’autre. Il convient lorsque la réponse à une opération dépend de l’état courant. Accepter un devis envoyé est possible ; accepter le même devis après expiration doit être refusé dans nos règles.

Un état se nomme selon une situation : Brouillon, Envoyé, Accepté. Une action se nomme selon un travail : calculer le total, enregistrer l’accord. Mélanger les deux conduit à dessiner une suite d’opérations au lieu du cycle de vie d’un objet.

Notre machine concerne une version de Devis. Elle ne représente ni toute l’entreprise ni le cycle complet de la demande. Une nouvelle version peut repartir en Brouillon tandis qu’une ancienne version reste Refusée dans l’historique.

2. Événements, gardes et effets

Une transition peut porter la forme déclencheur [garde] / effet. Le déclencheur est l’événement reçu ; la garde est une condition booléenne ; l’effet est le comportement exécuté lorsque la transition est franchie. Par exemple : accepter [encoreValable] / daterAccord.

L’événement n’est pas une condition évaluée en permanence. Le devis ne s’accepte pas tout seul parce qu’il est valable : il faut recevoir accepter. Si la garde est fausse, cette transition ne peut pas être franchie. Il faut préciser la réponse attendue lorsqu’une commande métier est rejetée.

Le disque noir représente un pseudo-état initial ; il désigne le point d’entrée par défaut. La cible finale, avec disque entouré, termine la région concernée. Un état métier terminal, comme Accepté, peut être conservé sans dessiner immédiatement une fin si le comportement de l’objet doit encore traiter d’autres événements.

3. Le cycle de vie retenu pour NKILItech

Dans ce modèle pédagogique, approuverEtEnvoyer est une commande qui réunit l’accord du PDG et l’envoi réussi au portail client. Une réalisation plus détaillée pourrait introduire un état Approuvé si l’approbation et l’envoi doivent être séparés. Le schéma annonce le niveau choisi.

Le montant exactement égal au seuil suit la branche sans approbation supplémentaire, puisque R4 utilise « supérieur à ». Ce cas de frontière doit figurer dans les tests.

4. Entry, do, exit et transitions internes

Un état peut préciser un comportement d’entrée entry, un comportement continu pendant l’état do et un comportement de sortie exit. Dans Envoyé, l’entrée peut dater l’envoi ; une activité en cours peut attendre une réponse selon la conception retenue.

Une transition externe qui revient au même état provoque sa sortie puis sa réentrée. Une transition interne peut traiter un événement sans ces sorties et entrées. Pour « consulter le devis », on ne souhaite pas nécessairement réinitialiser la date d’envoi à chaque consultation.

Une transition de complétion est déclenchée lorsque le comportement concerné s’achève, sans événement métier explicitement écrit. Une temporisation relative, comme after(15 jours), doit avoir un point de départ défini. Pour notre devis, une dateExpiration explicite permet également de contrôler la validité au moment de l’acceptation.

5. États composites, régions et historique

Un état composite contient des sous-états. On pourrait regrouper Envoyé et En relance dans un état « En attente de réponse ». Une transition sortant du composite peut alors s’appliquer à ses sous-états si la sémantique retenue le permet.

Des régions orthogonales décrivent des aspects qui évoluent en parallèle dans un état composite. Elles ne sont pas une simple manière de gagner de la place. Le pseudo-état d’historique permet de reprendre un sous-état antérieur lors d’une réentrée ; l’historique superficiel reprend le niveau direct, l’historique profond peut reprendre une configuration imbriquée.

Ces mécanismes avancés ne sont utiles que si le domaine les exige. Le cycle du devis présenté ici reste volontairement plat : ses règles principales sont déjà lisibles sans ajouter une hiérarchie artificielle.

6. Transformer les transitions en tests

Une couverture des états vérifie que chaque état peut être atteint. Une couverture des transitions vérifie chaque passage autorisé. Aucune ne remplace l’essai des commandes interdites : accepter depuis Brouillon, accepter après expiration ou approuver avec un rôle non autorisé.

Tester aussi deux événements proches : accepter et expiration, ou deux acceptations de versions différentes. Le système doit appliquer une règle cohérente sur la date de référence et l’ordre de validation. La machine définit les transitions possibles ; les transactions et les contrôles d’accès assurent leur application dans le logiciel.

Scénarios illustrés : comparer les situations

Revenir au brouillon après une demande de correction

Le PDG peut demander un complément ou une correction de prix. La version retourne en Brouillon ; l’auteur la prépare à nouveau. La commande approuverEtEnvoyer garde ici le sens retenu dans le cours : accord et envoi au portail sont regroupés au niveau de détail choisi.

Exercices corrigés