Preface

The first article of this set provided an end-to-end view of the Unified Scenario-Based Design (USBD) methodology, while the second article focused on explaining the artifacts needed to model the Customer and the User of an automated system supporting the business. This article describes the last set of artifacts that USBD uses to detail the design of the automated system and its user interfaces. Figure 1 shows the overall set of artifacts produced while using the USBD methodology.

This article is going to focus on the bottom right part of Figure 1, providing more details on the artifacts shown there.

Back to top

Conceptual design

The activities categorized as conceptual design are the usual activities of System Analysis and System Design. In this article, a major focus is the importance of designing the User interactions in a formal way, leveraging what is described in the "Building J2EE applications with RUP" book as a base, and then modifying it according to the guidelines contained in the IBM® Rational Unified Process® (RUP®) customization adopted in the Rome Development Laboratory.

The second article of this series described six steps to formally understand the Customers and the Users of the system you are building, and to capture this knowledge in rigorous artifacts. This article completes the description of that modeling process with two other steps that help detail the functional and presentational aspects of the systems being built.

Step seven

During the seventh step, the system use cases are realized in two different ways, as shown in Figure 2.

The first way the system use cases are realized is the traditional use case realization, which shows how the use case is realized in terms of a set of cooperating classes. It is worth noting that this is a model of the internal behavior of the system. Two UML artifacts model this aspect: the Participants class and Interaction diagrams.

The Participants class diagram gives a static view of the use case participants. In particular, the interaction between the main actor and the system involves a boundary class. This class will typically be mirrored by a main screen in the use case storyboard (see next point). This relation may also be modeled explicitly through a direct dependency. Figure 3 shows the Participants class diagram for the Create Job Template use case realization.

The Interaction diagram(s) are one or more UML collaboration diagrams describing the interactions among the participants shown in the previous diagram. Figure 4 shows the basic flow of interactions among the participants in the Create Job Template use case realization.

Because the system needs to interact with a person, and therefore typically requires a graphical user interface (GUI), a use case storyboard is also realized (in addition to the traditional use case realization). This part logically applies only to those parts of a system where an interaction with a person is present, which is the case at hand. Unlike the traditional use case realization, the use case storyboard describes the external behavior of the system, showing how it realizes the use case requirements by means of the User interface interactions.

The use case storyboard is also modeled by two major UML artifacts, the User Interface Screens class and Interaction diagrams. The User Interface Screens class diagram represents the static view of the use case participants in terms of the screens that make up the User interaction. The classes are stereotyped as screen for a main interface screen, compartment for a panel containing information and perhaps more panels (typically the majority of classes), and input form for a panel that accepts input from the User.

Each piece of information that a panel displays is represented by an attribute of the corresponding class, and each operation that the panel provides to the User is modeled as an operation. The diagram shows the static as well as the dynamic relations among the screens. An example of each type of relation follows:

• A static relation is the composition of several compartments into a screen
• A dynamic association is the navigation between one screen and another as determined by a User action

In addition, this diagram captures the relationship between the two different aspects of the same interface, as represented respectively in the Analysis model and in the User Experience model. In the former, a use case realization typically starts with the system actor interacting with a boundary class. In the latter, the corresponding use case storyboard typically starts with the system actor interacting with a screen class. The relation between the two classes is also represented in this diagram. Figure 5 shows the Screens class diagram for the Create Job Template use case realization.

The Interaction diagram(s) consist of one or more UML Sequence diagrams (each one representing a different use case flow) representing the actual interactions among the User and the screens, including the information exchanged. Figure 6 shows the basic flow of interactions among the Create Job Template use case storyboard screens.

Finally, one additional artifact is introduced to provide a comprehensive view of all the GUI elements that are identified by realizing all the use cases. This artifact is the Navigation Map, and it is a UML class diagram representing all of the screens of the User interface, along with their static and dynamic relationships. See Figure 7 for an example of such a diagram.

Step eight

Once the logical part of the GUI design has been completed using UML storyboards, the actual graphical interface needs to be designed. It is worth noting that at this point the conceptual design is completely technology-neutral. This means, for example, that the same design may be implemented as a standalone Java™ GUI, a simple Web application, or a portlet application. The decisions related to which technology to use for the actual implementation of the User interface can be delayed, and the design remains valid.

During the visual design phase, it is key to involve selected real and potential users to validate the effectiveness and usability of the proposal. However, while UML is the right choice as a way to convey information within the technical community, a different means of communicating is desirable when the design is to be validated by non-technical stakeholders.

Thus, in the eighth step you create a visual storyboard; for example, the format may be a presentation, a set of static HTML pages that the User can navigate, or even a simple prototype. The visual storyboard should be created around the User scenarios that have been identified during the Business Modeling phase and that are the core of USBD. Using concrete examples of the realization of User Goals and using Personas as the actors, each visual storyboard shows how the GUI provides the ease of use and the necessary power to solve the problem at hand.

The visual storyboards should be validated, focusing the verifications on the correctness of the main design ideas behind the GUI. An example of a visual storyboard is shown in Figure 8.

Summary

These articles have described an eight-step approach that constitutes the proposed methodology, referred to as Unified Scenario-Based Design. Let's briefly review these steps and their main intent.

• Understanding the Customer
1. Model the Customer Stakeholders and their definition of the Business Goals. Model the Business Process Map and the individual Business Processes, and identify the Business Actors that participate in them.
2. Define the Business Use Cases, and model how each supports one or more Business Goals. Highlight the Business Use Case Realizations for each Business Use Case, and define how they link back to the Business Process Map activities.
3. Describe the Business Use Case Realizations in terms of Business Workers and the messages that they exchange.
4. Select the Business Workers that will be automated. This also defines a set of Users.
5. Link the Business Model to the System Model by means of dependencies between the System Use Case Realizations and the Business Use Case Realizations. This activity identifies System Use Cases and System Actors, which in the end are User Roles.
• Understanding the User
6. Create User Personas, identify and model User Roles and User Goals, and understand through dependencies how the User Goals achieve the original Business Goals.
• Conceptual Design
7. Develop the Use Case Realizations and the Use Case Storyboards. Make sure that each Use Case supports User Goals.
8. Design the User interface. Use Visual Storyboards to describe the scenarios, and validate them with Customer representatives.

As an additional resource, Table 1: Enabling Artifacts summarizes the UML artifacts that support the methodology. It provides an indication of which artifacts are considered required and which optional, as well as the steps during which they are created.

Conclusions and benefits

The three articles published so far have discussed the desirability of a USBD approach that focuses on the end-to-end business environment where products live, rather than on just describing the business scenarios that surround a single product. By explaining how to link business needs to software implementation, the articles have described the way to capture business processes via process maps, goals via class diagrams, and how to trace them with system implementations. An approach to a formal representation of user interfaces linked with system analysis has been described as well.

In contrast, the approach that is generally adopted these days is characterized by a substantial lack of formality when rendering the product specifications. This is really evident when you consider the inability to formally trace two fundamental specification artifacts (business processes and business goals) against the application layer. This lack of formality is a showstopper when the business system must quickly react to new or updated requirements.

The following list summarizes the problem statement and outlines the major concerns with the current process:

• Modeling a system with only use-case driven UML specifications does not allow a good level of business reactivity. Even if this practice provides many benefits by concentrating the analysis and design efforts on the usage dimension of a system, it is still not enough.
• Implementing changes in reaction to new or modified business requirements is still a major challenge, both from a time-to-market and a quality perspective
• Application Development cannot efficiently react to changes happening in the business layer. The inhibiting factor is that the business specifications are not sufficiently structured at the business definition layer, and they are not efficiently traced to the application layer
• A gap exists between the business and application layers
• Business analysts and application analysts do not use the same language (UML) to formalize their systems
• Specifications are not precisely identifiable in the UML diagrams
• There is a lack of traceability between abstraction layers
• It is not easy for analysts to specify the evolution of the requirements when facing changes, and for designers to implement the required corrections to the systems supporting those requirements
• As a direct impact of this lack of traceability, analysts are not encouraged to formalize business reactions in separate models: both business rules and their usage constraints are mixed arbitrarily in application use cases
• The quality of the User experience is generally low
• There is a poor understanding of the Users of the products, their goals and tasks, and most importantly of how the products fit into the Customer business process
• User Interface designers and System designers do not use the same language (UML) to formalize their systems
• User Interface specifications can be ambiguous and are not traceable to the actual system's UML diagrams

In support of the previous statements, consider another example: Figure 9 depicts three different scenarios, described verbally as the current best practices suggest. The figure also shows the list of requirements that have been identified based on the scenarios, but without any links between the requirements and the scenarios.

Suppose that the Update Software Stack scenario will no longer include Step 8 as a consequence of a change in the process. In the current methodology, removing this one step leads to two major problems. First of all, the process to determine the requirement set associated with the change is not deterministic and is therefore error prone, because the link between scenarios and requirements is neither formally expressed nor supported by any tools. Secondly, removing associated requirements and related use cases may have side effects on other scenarios, and there is no way to determine such effects.

To address these problems, the methodology presented in this series of articles provides a way to describe scenarios and requirements in a formal manner, and to create traceability between the User interface design, the system, the scenarios, and the requirements. The method was initially piloted on the redesign of the Tivoli Workload Scheduler user interface, and is now being adopted in several projects. The benefits achieved through the new approach are tangible:

• All parties involved in the product development cycle -- including the executives that must make decisions about strategic directions, the product managers who must keep in constant communication with the customer community, and, of course, the development team -- have a clear understanding of the business context where the product line lives. Everyone is on the same page when discussing requirements, features, and product positioning.
• The development team finally has the means to achieve the customer orientation that it has always been asked for.
• Defining which parts of a business process are common among all customers, and which are implemented optionally, helps guide the prioritization of the product's features.
• User scenarios are no longer pure conjectures, but have been derived from the business process and validated with the user community.
• In addition, by means of the traces in the models, the development team can be sure that the use cases it is addressing actually support the targeted subset of scenarios.
• As far as the user experience is concerned, because the team has described users and their goals in a formal way, they can be sure that the use cases being implemented support the user goals, and that the visual realization provides the desired functionality in a usable way, matching the users' skills.
• The links between the user interface and the system models allow for more efficient reviews, thus resulting in more errors found earlier in the development cycle.
• The development team can now apply all the knowledge and best practices for designing software systems to the design of the user interface.
• The development organization can react more quickly to changes in the business context. The introduction of the formal traces between the business and the system models allow development to understand the impact on the system(s) caused by a change in the business needs. This enhances the always sought-after business agility and takes one step further towards being an on-demand development organization.

All the figures shown in this article come from work done in the Tivoli Workload Scheduling area to study improvements to its operational GUI. The next article in this series describes the practical use of the IBM® Rational® Software Architect tool to show you how to leverage the plug-in developed as part of the USBD methodology.

Resources

Learn

• Unified Scenario-Based Design, Part 1: Methodological principles The first in this series of four articles on the Unified Scenario-Based Design methodology.
  
  
• Unified Scenario-Based Design, Part 2: Understanding the customer and the user The second part of this series of four articles on the Unified Scenario-Based Design methodology.
  
  
• Building J2EE applications with the Rational Unified Process, Object Technology S., Peter Eeles, Kelli Houston, Wojtek Kozaczynski - Addison-Wesley, 2002
  
  
• IBM Rational Software Architect product page: Find technical documentation, how-to articles, education, downloads, and product information about Rational Software Architect.
  
  

Get products and technologies

• IBM Rational Software Architect: Download a trial version from developerWorks. Provides the tools needed to view the Business Contract Model and develop service realization models that can be used to generate implementation code for different architectural styles.
  
  

Discuss

• Rational Software Architect, Data Architect, Software Modeler, Application Developer and Web Developer forum: Ask questions about Rational Software Architect.
  
  

About the authors

Alex Donatelli is a Senior Technical Staff Member at IBM. He is the Chief Architect of the Tivoli Laboratory in Rome, Italy and the Manager of the Rome Central Architectural Team. He has been working with both his staff and the overall technical community in Rome and in Tivoli to improve the quality of the products. The Unified Scenario-Based Design work is one example of such efforts.

Roberto Longobardi is an Interaction Solution Designer at IBM. He has been working in several Tivoli development projects, in the areas of performance and availability and of workload management. Recently challenged to provide a redesign hypothesis for the IBM Tivoli Workload Scheduler user interface, he sought to greatly enhance the consumability of the solution by getting it nearer to its business and operational contexts. Unified Scenario-Based Design is the result of this joint experience with the Rome Central Architectural Team.

Rosario is a Senior Software Engineer in the Tivoli Laboratory in Rome, Italy. He is the lead Architect for IBM Tivoli Configuration Manager, with 15 years experience in software development as a software engineer, market manager, and people manager. In his various roles he has been architecting, designing, sponsoring, and driving implementation of complex enterprise applications. He works with partners and customers and has lengthy experience translating business needs into product and solution requirements. He received his master's degree in Physics from the Universita' di Messina.

Claudio is currently a Senior Software Engineer and the chief designer for IBM Tivoli Configuration Manager, with 14 years of experience in developing and designing enterprise applications in the system management arena. He is considered a key expert in the RUP and J2EE, and his current focus is in software engineering best practices and Model-Driven Architecture.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Preface
• Conceptual design
• Resources
• About the authors
• Comments

Next steps from IBM

• Try: Rational Software Architect
• Demo: Model Rational RequisitePro requirements in Rational Software Architect
• Webcast: Harnessing the power of enterprise architecture
• Briefing: Architecture, design, and construction using the IBM Rational Software Delivery Platform
• Buy: Rational Software Architect

My developerWorks community

Dig deeper into Rational on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers