Dans la phase de conception, on recense les différents états du système, ainsi que les transitions possibles entre ces différents états. On précise quel est l'état initial et quels sont les états finaux (c'est-à-dire les états pouvant terminer normalement l'exécution de l'application, sans retour de code d'erreur). On obtient ainsi le schéma d'un automate.

Un tel schéma est extrêmement facile à comprendre et a donc tout à fait sa place dans un rapport d'analyse. Il permet également de repérer très tôt les éventuelles erreurs de conception (ex: problèmes de protocole) et, connaissant les types d'événements possibles, il permet de faire une liste exhaustive des différents comportements du système.

En complément du schéma, on documente les différents états et transitions :

• nom de l'état
• description de l'état, son rôle, ce qui s'y passe
• spécifier s'il est final ou pas. S'il n'est pas final, spécifier les types d'erreur retournés
• spécifier les conditions d'invariant (voir plus loin)

• spécifier les événements déclencheurs de la transition
• spécifier (si applicable) les actions à effectuer lors de la transition (au début ou en fin de transition)

Les conditions d'invariant sont les conditions qui doivent être respectées tout au long de l'exécution d'un programme. Dans le cas des états, une condition d'invariant s'exprimera de la manière suivante: "si le système se trouve dans l'état E_N, alors il vérifiera telles propriétés" (exemple de propriété: "la boite de dialogue est désactivée").

Dans la phase de réalisation, il s'agit de traduire ce qui a été spécifié dans la phase de conception :

• à un état correspond une classe
• implémenter les changements d'état, comme décrit dans la section "implémentation"

Cette phase est donc assez mécanique.

Dans la phase de test, il s'agit de vérifier (entre autres) :

• que les comportements du système correspondent bien au schéma
• que les conditions d'invariant sont respectées pour chaque état
• que les transitions s'effectuent correctement
• que les changements d'états n'occasionnent pas de "fuite mémoire" (c'est-à-dire que les objets Etat sont bien supprimés s'ils ne servent plus)

Pour cela, on utilise :

1. des revues de code
2. des tests permettant de couvrir l'ensemble des chemins du schéma (=tests de recouvrement)
3. des tests permettant de vérifier les conditions d'invariant état par état

Pour élaborer les tests, on s'appuie sur les documents rédigés lors de la phase de conception (schémas + explications complémentaires: description des états, des transitions, de l'invariant...)

Tôt ou tard (généralement plus tôt que prévu), l'application sera amenée à être maintenue ou à évoluer pour s'adapter à de nouveaux besoins. Dans ce contexte, l'utilisation du pattern Etat se révèle incroyablement souple, et faire évoluer l'application se résume souvent à :

• l'ajout de nouveaux états et transitions
• la modification des états et transitions existants

Parfois, il s'agit d'ajouter de nouvelles fonctionalités, et donc de nouvelles méthodes au sein des différents états. Dans ce cas, on commence par déclarer une méthode virtuelle dans la super-classe Etat (celle au sommet de la hiérarchie) avant d'implémenter les comportements spécifiques à chaque état dans les sous-classes.

La super-classe peut éventuellement fournir une implémentation par défaut, l'important étant d'éviter les copier/coller.