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.