Stereotypes allow you to repurpose an existing UML element, giving it a new meaning. This allows you to use standard UML elements like classes and attributes, and give them meaning within a discipline like Usability Interface Design. The following stereotypes are used in the User Design Model.
| Stereotype |
Extends |
Description |
| Screen |
Class |
An abstraction of a rendered web page in a client browser. |
| Compartment |
Class |
Represents a well-defined region of a screen that is reused by multiple screens. It is an abstraction of a part of a rendered web page in a client browser. |
| Form |
Class |
Represents a group of data fields that can be displayed to and manipulated by the user. |
| Input |
Attribute |
Indicates that a field on a screen is associated with an input form (it is an input form field). |
| Submit |
Attribute |
Indicates that an operation is associated with a command submission. |
Table 2. User Design modeling stereotypes
As a component architecture, JSF is well suited to UI modeling. In the following sub-sections we will cover how each of these stereotype elements is used in a Storyboard design.
Screens
A screen is modeled using a UML class assigned the stereotype screen>.A screen has a name in the top compartment, attributes in the middle compartment, and operations in the lower compartment, as shown in figure 1.

Figure 1. Mapping UML Class to UI Screen
Let's take a closer look at attributes and operations and how they are used to model web pages.
Attributes
Attributes are used to represent dynamic content-information that is held somewhere in the business domain and sent to the presentation screen when it is rendered. Attributes are not used to represent static information such as labels, graphics, or page layout elements. The stereotype <input> is used to indicate that the UI element can be used for user input (bi-directional).
The full form of an attribute is:
visibility name : type multiplicity = default {property-string}
The following attribute notations are useful when constructing storyboards:
- The visibility marker can be used to indicate whether the content is visible (+) or hidden (-) to the user.
- The name of the attribute should roughly correspond to the name used to identify a field. The derivation modifier (/) is used to indicate that the field represents a calculated value derived from two separate domain values. An example is Full Name = First Name + Last Name
- The type of the attribute indicates a restriction on what kind of data model may be placed in the attribute. I recommend creating your own language neutral data types such as "List" or "Tree" to represent more complex UI Content Models.
- The multiplicity indicates the number of instances of the element that should be placed on the screen.
- The "default value" is the value to be used for elements that have no initial assignment.
- The {property-string} notation allows you to indicate additional properties useful to your UI model.
Attributes can be assigned constraints; it is my recommendation to limit your constraints to validations that are associated with data characteristics; length (min, max), range (min, max), type (integer, decimal, string), and format (date, phone #, SSN, currency).
Operations
Operations are used to model user actions and capture the behavioral interfaces associated with the screen. The full form of an operation is:
visible name (parameter-list) : return-type {property-string}
The following notations are useful when creating storyboards:
- The name of the operation should roughly correspond to the name of the field with which it is associated and/or the event with which it is associated.
- The visibility marker can be used to indicate if an operation takes place server-side (+) or client-side (-).
- The parameter-list should be left empty.
- The return-type should be void for most types of JSF operations.
- The {property string} notation is used to indicate property values that apply to the given operation.
Submit
When an operation is NOT associated with a field, the operation should be annotated with the stereotype <submit>. A command is a special type of user input field type that has no data, is not modeled using an attribute, and provides only user interaction semantics. Typical examples include buttons and static links.
Compartments
A compartment represents a well-defined region of a screen and is modeled using a UML class assigned the stereotype <compartment>. A compartment is a re-usable presentation fragment that is part of a screen; it can be included in one or more screens
and/or other compartments and can be used like pre-fabricated building blocks. Typical examples of compartments are headers, footers, menu bars, tabs, and tables as shown in figure 2.

Figure 2. Storyboard Compartment UI Model
Compartment classes use the same mapping between UML and the UI model as screens. Compartments use the association type composition to model the part-of relationship between a Screen and Compartment.
In the compartment model, data flows in only one direction; from the screen to the compartment. Compartments are used to represent complex components (e.g. Button Bar) or reusable page fragments (e.g. sub-views, regions, page fragments). In follow-on article(s) I will discuss how the compartment model can be implemented using a JSF framework such as Trinidad.
Form
An input Form acts as a container for page elements that accept user input and is modeled using a UML class assigned the stereotype <form>. Forms can be shared between screens and use a dependency to model the relationships as shown in figure 3.
Page:
1
2
3