Guideline: Representing Graphical
User-Interfaces
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.
| |
|
