Dans les systèmes où l'interaction utilisateur est importante, il est souvent souhaitable de représenter l'interface
utilisateur dans son ensemble en tant que classe d'analyse unique lors de l'analyse de
cas d'utilisation. Ces classes sont, en réalité, composées de nombreux types différents d'autres classes : boutons,
fenêtres, menus, sous-fenêtres, commandes, etc. Utiliser une classe unique pour représenter cette collaboration
complexe est parfois beaucoup trop simpliste. Bien qu'il soit possible d'utiliser une classe unique, en l'affinant au
fil du temps, il est souvent plus facile de représenter ceci au moyen d'un concept plus englobant, celui de
sous-système.
Dans ce cas, une classe unique (ou sous-système) a été utilisée pour représenter des collaborations complexes telles
que des interfaces graphiques, du fait des limitations de notre vocabulaire de conception. Cette classe était
considérée, dans un sens, comme le point d'entrée des collaborations complexes, mais ne constituait pas
véritablement une classe au sens exact (elle ne disposait pas d'un ensemble unique et bien défini de responsabilités,
sauf dans un sens très large) et disparaissait souvent lors du processus de conception. Au final, on découvre les
vraies classes et collaborations et on leur distribue le comportement de chaque classe de marque de
réservation. Une partie du travail effectué dans Prototyper l'interface utilisateur par le Rôle : Concepteur d'interface utilisateur lors de la production du Produit : Prototype d'interface utilisateur est susceptible d'être
approfondie et réutilisée, selon la nature de ce prototype.
|