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.



RUP (Rational Unified Process)   2003.06.15