“doc” (Col. : Science Sup 17x24) — 2007/7/19 — 18:18 — page 258 — #268
i
i
i
i
i
i
i
i
258
5
• La programmation avec état explicite
5.6.3 La maintenance
Une fois que le système est construit et fonctionne bien, il faut s’assurer qu’il continue
de bien fonctionner. Maintenir un système en bon état de fonctionnement après son
déploiement s’appelle la maintenance. Quelle est la meilleure manière de structurer
les systèmes pour faciliter la maintenance ? Nous donnons quelques principes importants tirés de notre expérience. Nous considérons le problème du point de vue des
composants et du point de vue du système.
La conception des composants
Il y a des bonnes et des mauvaises manières pour concevoir des composants. Une
mauvaise manière est de construire un organigramme et de le découper en morceaux
devenant chacun un composant. Il est beaucoup mieux de concevoir un composant
comme une abstraction. Par exemple, supposons que nous écrivions un programme
qui utilise les listes. Il faut rassembler les opérations sur les listes dans un composant qui définit l’abstraction des listes. Avec cette conception, les listes peuvent être
implémentées, déboguées, changées et étendues sans toucher le reste du programme.
Si nous voulons utiliser des listes qui sont trop grandes pour la mémoire, il suffira de
changer le composant des listes pour qu’il les enregistre dans des fichiers plutôt qu’en
mémoire.
➤ L’encapsulation des décisions de conception
Plus généralement, nous pouvons dire qu’un composant devrait encapsuler une décision de conception.
7 Ainsi, quand la décision de conception est changée, il ne faut
changer que ce composant. C’est une forme puissante de modularité. L’utilité d’un
composant peut être évaluée par rapport à l’étendu des changements qu’il peut accommoder. Par exemple, considérez un programme qui calcule avec des caractères, comme
l’application qui compte la fréquence des mots de la section 3.8.4. Idéalement, la
décision quant au code de caractères à utiliser (par exemple, l’ASCII, le Latin-1 ou
l’Unicode) doit être encapsulée dans un composant. Cela simplifie le changement du
code.
➤ La stabilité des interfaces des composants
Un composant peut être modifié en changeant son implémentation ou son interface.
Changer l’interface est problématique car tous les composants qui dépendent de l’interface doivent être réécrits ou recompilés. Il faut donc éviter de changer l’interface.
Mais en pratique, les changements d’interface ne peuvent pas être évités pendant la
conception d’un composant. Tout ce que l’on peut faire est de réduire leur fréquence.
7. De façon plus romantique, on dit parfois que le composant a un « secret ».
i
i
i
i
i
i
i
i
258
5
• La programmation avec état explicite
5.6.3 La maintenance
Une fois que le système est construit et fonctionne bien, il faut s’assurer qu’il continue
de bien fonctionner. Maintenir un système en bon état de fonctionnement après son
déploiement s’appelle la maintenance. Quelle est la meilleure manière de structurer
les systèmes pour faciliter la maintenance ? Nous donnons quelques principes importants tirés de notre expérience. Nous considérons le problème du point de vue des
composants et du point de vue du système.
La conception des composants
Il y a des bonnes et des mauvaises manières pour concevoir des composants. Une
mauvaise manière est de construire un organigramme et de le découper en morceaux
devenant chacun un composant. Il est beaucoup mieux de concevoir un composant
comme une abstraction. Par exemple, supposons que nous écrivions un programme
qui utilise les listes. Il faut rassembler les opérations sur les listes dans un composant qui définit l’abstraction des listes. Avec cette conception, les listes peuvent être
implémentées, déboguées, changées et étendues sans toucher le reste du programme.
Si nous voulons utiliser des listes qui sont trop grandes pour la mémoire, il suffira de
changer le composant des listes pour qu’il les enregistre dans des fichiers plutôt qu’en
mémoire.
➤ L’encapsulation des décisions de conception
Plus généralement, nous pouvons dire qu’un composant devrait encapsuler une décision de conception.
7 Ainsi, quand la décision de conception est changée, il ne faut
changer que ce composant. C’est une forme puissante de modularité. L’utilité d’un
composant peut être évaluée par rapport à l’étendu des changements qu’il peut accommoder. Par exemple, considérez un programme qui calcule avec des caractères, comme
l’application qui compte la fréquence des mots de la section 3.8.4. Idéalement, la
décision quant au code de caractères à utiliser (par exemple, l’ASCII, le Latin-1 ou
l’Unicode) doit être encapsulée dans un composant. Cela simplifie le changement du
code.
➤ La stabilité des interfaces des composants
Un composant peut être modifié en changeant son implémentation ou son interface.
Changer l’interface est problématique car tous les composants qui dépendent de l’interface doivent être réécrits ou recompilés. Il faut donc éviter de changer l’interface.
Mais en pratique, les changements d’interface ne peuvent pas être évités pendant la
conception d’un composant. Tout ce que l’on peut faire est de réduire leur fréquence.
7. De façon plus romantique, on dit parfois que le composant a un « secret ».