As a JSF practitioner I have experienced the ups and downs of the technology over the last few years. Success has come when I have been able to deliver the right design with the proper tools, and failure has almost always occurred because of the wrong design. Right away I can hear the grumbling: "JSF tools are garbage, that's why my project failed." JSF tools are less than stellar but the situation in 2008 is not as bad as it was. Most JSF failures are still rooted in the design approach, and not in the technology itself.
Explaining JSF to the business and/or the project team, getting buy-in to use it on your project, or explaining the need for a certain supporting toolset can be a difficult task. As a champion of JSF technology, I notice that its status as a "Java EE Standard" is too often the only positive check mark it receives. All the techno-talk associated with JSF does little to promote the technology and often confuses the evaluation. I have found that the best way to promote and explain JSF to the business is through the design technique called Storyboarding. I leave the technology out and discuss JSF in terms of screens, compartments, and components. We discuss interactions between components on a page (state transitions) and navigation paths between screens. I give the business a component palette they can use, and describe the behaviors associated with the components that can be utilized in the User Interface (UI) design.
The best part about Storyboarding is it is easily understood by the business, and as a design methodology it's acceptable to most UI teams. Unless you have complete decision authority, getting into a battle over which UI framework to use rarely leads to a definitive conclusion within a project, and it's not the conversation the business wants to have. Demonstrating to the business and development groups that you have the right design approach, matched with the appropriate toolset to deliver the application, is always the winning approach.
Part one of this series will focus on the design approach, the storyboard, which provides a methodology that you can present to the business. Storyboards are all about the Presentation Layer, and part two will tackle the View and Controller portions of a Model-View-Controller (MVC) implementation. Part three will build upon the MVC approach,
rounding out with a comprehensive design approach towards building Storyboard models that can be used to implement your Presentation Layer. Then in part four, we will address the final portion of MVC, the business model, and provide strategies for integrating the Storyboard presentation models with the business model(s). Having a design approach that maps to a concise implementation pattern is an effective way to communicate to all layers of the project team that JSF can be used to deliver successful applications.
A storyboard is a design model, typically created by the business, UI designers, and business system analysts, provided to the development team as part of a functional specification. It is used to describe the screens, screen transitions, form content, state, and navigation paths through the end-user views that are used to execute system functionality (use-cases). This Storyboard approach originates from the Rational Unified Process (RUP) which defines a User-Experience model as the screens of a system, the dynamic content that appears on the screens, and how the user navigates through the screens to execute system functionality.
A typical JSF Storyboard consists of five elements:
- A use-case that describes the functional requirements and flow of events.
- One or more UI model(s) specifying screens, components, and user experience elements in an abstract representation.
- A screen flow diagram for each storyboard illustrating screen-flow dependencies between UI modeling elements in the storyboard.
- A mock-up showing the details of specific UI elements: buttons, pull-downs, menus, etc.
- A state model for each screen representing how the Controller interacts with the business model.
I also encourage the creation of a User Interface Style and/or Usability Guide providing detailed information for your application.
Every UI Storyboard begins with a use-case that describes a significant portion of the functionality and provides the narrative on how the user and the system interact. There are no user interface details in a use case, no mention of buttons, text boxes, screens, or pages. A use-case contains one basic (Main) flow and multiple alternative flows.
Remember that use cases describe what the system should do and not how it should be done.
Storyboards use the special requirements section of the use-case to add non-functional requirements (FURPS+) including usability, reliability, performance, scalability, security, legal and regulatory requirements. Examples include formats supported for date/calendar entry and how percentages are to be displayed or input.
User Interface Model
The User Interface (UI) model specifies details that are not specified in the use-case. It is used to determine what will go into the presentation before worrying about the specific details of the elements (buttons, pull-down, menu, etc.) and is constructed using UML modeling elements. The UI model encourages a good interface architecture and serves as a contract between the UI team and the development team, making sure neither of them just "makes things up" as they go.
The mapping of UML modeling elements to a UI Model is described in the table below.
Table 1. Mapping between UML and UI modeling Elements
|UML Modeling Element
||UI Modeling Element
||Screen, Component, Input Form
||UI State Model
||Dynamic Content (do not model static content)
||User Action or Event
||A unidirectional association is used to represent a navigation path between two screens.
Composition is used to form the part-of relationship between screens and components.
||A dependency is used to show the relationship between elements on a Screen and one or more input Forms.