Principes et conseils : Représentation
des interfaces utilisateur graphiques
Dans les systèmes dans lesquels l'interaction utilisateur est importante,
il est souvent préférable de représenter l'interface utilisateur complète
comme une seule classe d'analyse au cours de l'Analyse de cas d'utilisation. Ces
classes sont, en réalité, composées de nombreux types de classes différents :
boutons, fenêtres, menus, sous-volets, commandes, etc.
L'utilisation d'une seule classe pour représenter cette collaboration complexe
est parfois une sur-simplification trop importante.
Bien qu'une seule classe puisse être utilisée, la détaillant au fur et à mesure,
il est souvent plus simple de la représenter à l'aide d'un concept plus
détaillé, le sous-système.
Dans ce cas, une seule classe (ou sous-système) a été utilisée
pour représenter des collaborations complexes, tels que des interfaces
utilisateur du fait de notre lexique de conception limité.
Cette classe a été considérée, dans un sens, comme le point d'entrée à
des collaborations complexes, mais il ne s'agissait pas vraiment d'une classe
dans le sens réel du terme (elle n'avait pas un seul ensemble de
responsabilités bien défini, excepté dans un sens très lâche) et elle
disparaissait souvent dans le processus de conception.
A la fin, les classes et les collaborations réelles sont découvertes
et le comportement de chaque classe de signet leur est diffusé.
Une partie du travail effectué dans le
prototype de l'interface utilisateur
par le Rôle : concepteur d'interface
utilisateur lors de la production de
l'Artefact : prototype d'interface
utilisateur peut être utilisé et réutilisé, en fonction de la nature du prototype.
| |
|