“doc” (Col. : Science Sup 17x24) — 2007/7/19 — 18:18 — page 302 — #312
i
i
i
i
i
i
i
i
302
6
• La programmation orientée objet
6.4.4 L’utilisation des diagrammes de classe
Le diagramme de classe est un excellent outil pour visualiser la structure de classe
d’une application. Il est au cœur de l’approche populaire UML pour la modélisation
des applications orientées objet. Cette popularité a souvent masquée ses limites. Il y a
trois limites évidentes :
– Il ne spécifie pas la fonctionnalité des classes. Par exemple, si les méthodes d’une
classe maintiennent un invariant, alors cet invariant ne sera pas visible dans le
diagramme de classe.
– Il ne modélise pas le comportement dynamique. Le comportement dynamique
existe à grande échelle et à petite échelle. Les applications passent souvent
par plusieurs phases d’exécution, avec un autre diagramme de classe valable
pour chaque phase. Les applications sont souvent concurrentes, avec des parties
indépendantes qui interagissent de manière coordonnée.
– Il ne modélise qu’un niveau dans la hiérarchie des composants. Comme la section 5.6 l’explique, les applications bien structurées ont une décomposition hiérarchique. Les classes et les objets sont proches de la base de cette hiérarchie. Un
diagramme de classe montre la décomposition à ce niveau.
L’approche UML reconnaît ces limites et fournit des outils pour les alléger partiellement, comme le diagramme d’interaction (« interaction diagram ») et le diagramme
de paquet (« package diagram »). Les diagrammes d’interaction modélisent une partie
du comportement dynamique. Les diagrammes de paquet modélisent les composants
à un niveau d’abstraction plus haut.
6.4.5 Les motifs de conception (« design patterns »)
Pendant la conception d’un système logiciel, il arrive souvent de rencontrer plusieurs
fois les mêmes problèmes. L’approche des motifs de conception reconnaît ce fait et
propose des solutions générales à ces problèmes. Un motif de conception est une
technique qui résout un problème commun et qui peut être réutilisée facilement. Ce
livre contient beaucoup de motifs de conception dans ce sens :
– Dans la programmation déclarative, la section 3.4.2 introduit la technique de
construction d’une fonction en suivant la structure d’un type. Un programme qui
utilise une structure de données récursive peut être écrit facilement en regardant
le type de cette structure. La structure du programme reflète la définition du type.
– La section 5.4.2 introduit une série de techniques pour sécuriser une abstraction
de données en l’emballant dans une couche sécurisée. Ces techniques sont indépendantes de la fonctionnalité de l’abstraction ; elles sont valables pour toute
abstraction.
i
i
i
i
i
i
i
i
302
6
• La programmation orientée objet
6.4.4 L’utilisation des diagrammes de classe
Le diagramme de classe est un excellent outil pour visualiser la structure de classe
d’une application. Il est au cœur de l’approche populaire UML pour la modélisation
des applications orientées objet. Cette popularité a souvent masquée ses limites. Il y a
trois limites évidentes :
– Il ne spécifie pas la fonctionnalité des classes. Par exemple, si les méthodes d’une
classe maintiennent un invariant, alors cet invariant ne sera pas visible dans le
diagramme de classe.
– Il ne modélise pas le comportement dynamique. Le comportement dynamique
existe à grande échelle et à petite échelle. Les applications passent souvent
par plusieurs phases d’exécution, avec un autre diagramme de classe valable
pour chaque phase. Les applications sont souvent concurrentes, avec des parties
indépendantes qui interagissent de manière coordonnée.
– Il ne modélise qu’un niveau dans la hiérarchie des composants. Comme la section 5.6 l’explique, les applications bien structurées ont une décomposition hiérarchique. Les classes et les objets sont proches de la base de cette hiérarchie. Un
diagramme de classe montre la décomposition à ce niveau.
L’approche UML reconnaît ces limites et fournit des outils pour les alléger partiellement, comme le diagramme d’interaction (« interaction diagram ») et le diagramme
de paquet (« package diagram »). Les diagrammes d’interaction modélisent une partie
du comportement dynamique. Les diagrammes de paquet modélisent les composants
à un niveau d’abstraction plus haut.
6.4.5 Les motifs de conception (« design patterns »)
Pendant la conception d’un système logiciel, il arrive souvent de rencontrer plusieurs
fois les mêmes problèmes. L’approche des motifs de conception reconnaît ce fait et
propose des solutions générales à ces problèmes. Un motif de conception est une
technique qui résout un problème commun et qui peut être réutilisée facilement. Ce
livre contient beaucoup de motifs de conception dans ce sens :
– Dans la programmation déclarative, la section 3.4.2 introduit la technique de
construction d’une fonction en suivant la structure d’un type. Un programme qui
utilise une structure de données récursive peut être écrit facilement en regardant
le type de cette structure. La structure du programme reflète la définition du type.
– La section 5.4.2 introduit une série de techniques pour sécuriser une abstraction
de données en l’emballant dans une couche sécurisée. Ces techniques sont indépendantes de la fonctionnalité de l’abstraction ; elles sont valables pour toute
abstraction.