In systems in which there is a great deal of user interaction, it is often desirable to represent the entire user
interface as a single analysis class during Use-Case Analysis. These classes are, in reality, composed of many different kinds of other classes: buttons, windows,
menus, sub-panes, controls, etc. Using a single class to represent this complex collaboration is sometimes too great an
over-simplification. While a single class could be used, refining it as we go along, it is often easier to represent
this with a more encompassing concept, the subsystem.
In this case, a single class (or subsystem) was used to represent complex collaborations such as GUI interfaces due to
our limited design vocabulary. This class was regarded, in a sense, as the entry point to complex
collaborations, but it really was not a class in the real sense (it did not have a single well-defined set of
responsibilities, except in a very loose sense) and it often disappeared in the design process. In the end, one
discovers the real classes and collaborations, and distributes the behavior of each place-holder class to
them. Some of the work performed in Prototype the User Interface by the Role: User-Interface Designer when producing the Artifact: User-Interface Prototype may be able to be carried forward
and reused, depending on the nature of that prototype.