JSF Central - Designing JSF Applications - A Storyboard Approach
JSF Central

 Articles & Books 
Designing JSF Applications - A Storyboard Approach
Designing JSF Applications - A Storyboard Approach
by Steven Murray
21 Oct 2008 02:00 EDT

Sometimes the best way to explain JSF to the business is through the design technique called Storyboarding. This series of articles explains how you can use Storyboarding to discuss JSF in terms of screens, compartments, and components as well as state transitions and navigation paths. In this first article, Steven provides an overview of this techique, and explains key elements such as use cases, the User Interface model, Screens, Operations, and Compartments.

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.


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
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 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 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.


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.


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
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.


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.


RSS feed(all feeds)

The Editor's Desk
Inside Facelets
In the Trenches

Site version 1.83  Report web site problems

Copyright (C) 2003-2015 Virtua, Inc. All Rights Reserved. Java, JavaServer Faces, and all Java-based marks are trademarks or registered trademarks of Oracle Corporation. in the United States and other countries. Virtua, Inc. is independent of Oracle Corporation. All other trademarks are the sole property of their respective owners.