Guidelines: Boundary Class (Modeling the User Interface)

Boundary Class

A boundary class models the interaction between one or more actors and the system.

Topics

Explanation

Boundary classes are used to model the interaction between a system and its surroundings, i.e., its actors. The following aspects of the interaction are captured on boundary classes:

coordinating the actor's behavior with the "internals" of the system;
receiving input from the actor to the system, e.g., information or requests;
providing output from the system to the actor, e.g., stored information or derived results.

Boundary classes can thus be used to capture the requirements on a user interface. Making an object model of the user interface is normally very worthwhile, since many user interfaces created today are object-oriented, and the trend is towards even more object orientation, because of its benefits with regard to natural and efficient use. Although many of the user-interface design decisions are best made during prototyping and rapid development of the user interface itself, reasoning about the structure and usability requirements on the user interface is natural to do in terms of an object model.

Using Boundary Classes to Model the User Interface

To understand the rest of these guidelines, please refer to the section "Windows Fundamentals: Setting the
Context" in Guidelines: User Interface (General).

A window-based user interface can be modeled by boundary classes; this can be described at a high level in the following points:

Use one boundary class to represent one primary window.
Use one boundary class to represent each relevant and logical object (type) manipulated by the actor within the primary windows; recall that each such object also often has its own secondary windows, such as property windows.
Use responsibilities on boundary classes to describe the required operations on their corresponding windows and objects.
Use attributes on boundary classes to describe properties of their corresponding windows and objects.
Use relationships between boundary classes to represent relationships such as aggregation hierarchies and navigation paths of their corresponding windows and objects.
Use special requirements on boundary classes to capture usability requirements, and also other types of requirements such as design and implementation requirements, on their corresponding windows and objects.

Given the windows and their objects in the examples above, we identify the following boundary classes, responsibilities, attributes, relationships, and special requirements.

Examples of Boundary Classes

The following boundary classes can be identified for a document editor:

Note that Character is included just because it is essential to view a character as an object of its own in this particular application, i.e., in the document editor. Character classes should of course not be used if not considered essential in the application being modeled. In such cases, Character is probably of too fine a granularity.

The following boundary classes can be identified for a mail application:

The following boundary classes can be identified for file manipulation:

Examples of Boundary Class Responsibilities

The following responsibilities can be identified for a document editor:

The Split responsibility is to split a Document in two (sub) windows. The Find(Text) responsibility is to find some Text in the Document.

The following responsibilities can be identified for a mail application:

The Arrange(Criteria) responsibility is to arrange the Mail Messages of a Mail Box according to various Criteria, such as sender, subject, receive time, etc.

The following responsibilities can be identified for file manipulation:

Examples of Boundary Class Attributes

The following attributes can be identified for a document editor:

Note that the attribute types are on a conceptual level here, and may be realized by various units of measure such as centimeters, inches, etc. in the actual user interface.

The following attributes can be identified for a mail application:

Examples of Boundary Class Relationships

The following aggregation relationships can be identified for a document editor:

Note that the primary window, here the Document, is often an aggregate, since it contains an arbitrary number of other objects. However, aggregates (such as the Paragraph) also exist within other aggregates and do not necessarily represent primary windows.

The following aggregation relationships can be identified for a mail application.

Regarding the files, the relationship between Folder and File could also be modeled as an aggregate:

The following association relationships can be identified for a document editor:

A Footnote must always be anchored to one Character. On the other hand, a Character can associate one or several Footnotes.

Note the difference between aggregations and (ordinary) associations. Aggregations are often used to model containment hierarchies, whereas associations can model relations and alternative navigation paths between different containment hierarchies.

A slightly more advanced use of associations is to model user-controlled inheritance. Then, an association should go between the inherited object and the inheriting object; an example is when a Paragraph inherits a Style:

The following generalization relationship can be identified for a document editor:

A Document is also a File, implying that it inherits all its responsibilities and attributes.

The following generalization relationships can be identified for a mail application:

Examples of Special Requirements on Boundary Classes

Special requirements on boundary classes can be:

Usability requirements, like user execution times, learning times, and error rates associated with the boundary class.
Non-functional requirements, that are captured on the class but that need to be handled when the corresponding user interface is designed and implemented. An example of such a requirement is that a boundary class should be implemented using a specific component, such as an ActiveX control.

Example:

A usability requirement regarding the Character class could be:

A Character should provide navigation to any associated Footnote by a single mouse move.

A usability requirement regarding the Mail Message class could be:

The Mail User should not be disturbed by incoming Mail Messages when reading existing Mail Messages.

A usability requirement regarding the Mail Box class could be:

The Mail User should be able to arrange Mail Messages with a single mouse click.

Other usability requirements have to do with attribute values and object volumes. This is because the user interface often has a requirement to provide a readable interface regarding a specific range of an attribute value, or to provide usable management of a range of a specific object volume. Such ranges should then represent the normal cases, and cover up to 90% of them. The user interface will in turn cover all values, including those exceeding the ranges, but can be optimized for values in the normal ranges.

Example:

A usability requirement regarding object volumes contained by the Document class could be:

A Document should be able to manage 1000 Paragraphs without delaying the scrolling mechanism.

A usability requirement regarding attribute values of the Mail Message class could be:

A Subject should be able to include 40 characters without being hyphenated.

Relating Actors and Boundary Classes

Since the boundary classes model interactions between the actors and the system, we make this clear by associating each actor with the boundary classes handling the interaction with the actor.

Example:

For the document editor, we have identified a Writer actor that interacts with Documents.

A Writer can work with several different Documents. A Document can be created by several different Writers. Note that this probably implies that a Document needs to be able to discriminate between different Writers.

Moreover, in this case we let it be understood from the context that a Writer interacts with all objects contained in the aggregation hierarchy under Document.

For the mail application, we have identified a Mail User actor that interacts with Mail Boxes.

In this case, we also let it be understood from the context that a Mail User interacts with all objects contained in the aggregation hierarchy under Mail Box.

Goodness Criteria on Boundary Classes and their Relationships

A problem with many user interfaces is that they have too many windows, and window navigation paths that are too long. In addition to adding needless interaction overhead, window navigation paths that are too long make it more likely that the user will "get lost" in the system. Ideally, all windows should be opened from one single primary window, often called the main window. Then you have a maximum navigation length of two. Avoid navigation lengths greater than three.

It is thus an important goal when building the user interface to have only one primary window per actor, if possible containing all objects that the actor needs to access. If this is not possible, the window should provide navigation to all objects that the actor needs to access. It is important that the actor spends a considerable part of his "use time" interacting with this primary window.

As a result, this has the following impact on the object model of the user interface:

Each actor should if possible be related to only one boundary class (aggregate) representing the primary window.
All boundary classes used by the same actor should be related some way, often via an aggregation hierarchy, starting with the boundary class representing the primary window.
Aggregation hierarchies should be as wide and shallow as possible.
Boundary classes should, in general, be part of one (and-only one) aggregation hierarchy, so the actor knows where to find it.
There should be as few aggregation hierarchies as possible, because they complicate the actors' mental model.
If you have an association with a multiplicity of one, and the associated classes are part of different aggregation hierarchies, you should consider replacing the association with an aggregation, if the two aggregation hierarchies can be merged. However, note that this may lead to a compromise between one deep aggregation hierarchy, and two more shallow ones.

The goodness criteria presented above are on quite a detailed level. On a higher level, we can list the following criteria, which may not provide as much detail, but at least communicate the intent of the boundary classes:

The boundary classes should contribute to good system usability.
The boundary classes should be kept on as high a conceptual level as possible.
The boundary classes should provide a sound encapsulation of the interaction between the system and the actor.
The boundary classes should be the only objects that need to change if actors change the way they provide input to the system.
The boundary classes should be the only objects that need to change if the system changes the way it provides output to the actors.
The boundary classes must be "aware" of the requirements from other object types (such as control and entity objects) so that they can be implemented and still be usable and efficient with respect to the "inside of the system."

Rational Unified Process 5.1 (build 43)