IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Améliorez vos logiciels avec le pattern Etat


précédentsommairesuivant

III. Développer avec le Pattern Etat

Cette section montre comment le pattern Etat trouve sa place dans les différentes étapes du cycle de vie d'une application (comment s'intègre-t-il dans les spécifications, l'implémentation ? Quelle est son influence sur les tests et la maintenance ?).

III-A. Conception

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.

Automate
Un exemple d'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 :

Pour les états :

  • 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'erreurs retournés,
  • spécifier les conditions d'invariant (voir plus loin) ;

Pour les transitions :

  • 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 EN, alors il vérifiera telles propriétés » (exemple de propriété: « la boite de dialogue est désactivée »).

III-B. Réalisation

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.

III-C. Test

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…)

III-D. Évolutivité

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.

Section suivante : Bonnes pratiques de conception (organisation en modules…)


précédentsommairesuivant

Copyright © 2006 Pierre Caboche. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.