Unified Scenario Based Design: Putting the Concepts to Work

Document options Document options requiring JavaScript are not displayed Sample code Rate this page Help us improve this content

Level: Intermediate

Alex Donatelli (alex.donatelli@it.ibm.com), Senior Technical Staff Member, IBM Tivoli Software
Rosario Gangemi (rosario.gangemi@it.ibm.com), IBM Tivoli Configuration Manager Architect, IBM Tivoli Software
Claudio Marinelli (claudio.marinelli@it.ibm.com), IBM Tivoli Configuration Manager Designer, IBM Tivoli Software
Roberto Longobardi (roberto.longobardi@it.ibm.com), Interaction Solution Designer, IBM Tivoli Software

05 Feb 2008

This, the last article of a series, describes the UML extensions and support tools for the methodology. This article focuses on the tools that support USBD, namely: the IBM® WebSphere® Business Modeler integration feature for IBM® Rational® Software Architect Version 7 and later, and a set of UML 2.0 extensions, captured into a set of UML profiles. These comprise a UML 2.0 profile and a model template that helps creating the Business Model, Business Analysis Model, Use Case Model and User eXperience Model.

Introduction

The previous articles in this series have described an effective unified design methodology, based on the emerging disciplines of Scenario Based Design (SBD) and Outside-In Design (OID). The methodology has been called Unified Scenario Based Design (USBD). It focuses on the end-to-end business environment where products reside, rather than on just describing the business scenarios that surround a single product. By describing the way to link business needs to software implementation, these articles have outlined the way to capture business processes via process maps, goals, and class diagrams, and how to trace them with actual implementation. The series has also described an approach to a formal representation of user interfaces linked with system analysis.

This article focuses on the tools that support USBD, namely:

• The IBM® WebSphere® Business Modeler integration feature for IBM® Rational® Software Architect Version 7 and later
• A set of UML 2.0 extensions, captured into a set of UML profiles

The WebSphere Business Modeler integration feature comes with Rational Software Architect, and is used to import a business model developed in WebSphere Business Modeler into Rational Software Architect. This feature also includes a UML profile, called IBM® WebSphere® Business Integration Modeler Nav Tree Profile, which provides UML stereotypes that are automatically applied to the UML classes, interfaces, and other elements that are converted during the import.

Rational Software Architect includes another UML profile, called Business Modeling Profile, which provides a complementary set of UML stereotypes to further enrich the business models.

To complete the picture and complement these two profiles with concepts that are specific to the USBD methodology, IBM has developed an additional profile, called the UML 2.0 Profile for USBD. This defines an additional set of stereotypes that, when they are applied to classes, interfaces, and other elements of the model, characterize them with the USBD concepts. The profile is intended to be used within the IBM® Rational® Software Delivery Platform (for example, IBM® Rational Software Modeler or Rational Software Architect).

The next section discusses the concepts in USBD, and the following section outlines how these concepts can be characterized by means of the three profiles mentioned previously.

Back to top

The USBD metamodel

This section helps you to better understand the USBD methodology by means of a metamodel. This is a model that describes the concepts that you will capture using the USBD methodology in the problem space of software design (which comprises the business, the Users, and the systems), and their relationships. The model comprises the USBD taxonomy and ontology.

Concepts like Users, goals, processes, User interface panels, and so on are put all together, and their relationships are identified and described using a model. The metamodel describes what actual models will look like for projects that exploit the USBD methodology. The next sections describe the actual UML extensions that are used to support the modeling of these concepts, and the suggested structure of USBD models.

Figure 1 and Figure 2 show the left and the right parts, respectively, of the overall meta-model diagram.

Referring to these figures, as seen in the previous articles in this series:

• A Business Process Map is composed of a set of Business Processes.
• The Business Processes map 1-to-1 with Business Use Cases started by Business Actors.
• A Business Event is a special case of a Business Actor, and as such it also starts Business Use Cases.
• A specific Business Process Realization sees Business Roles performing a set of Business Process Activities.

The same logical structure (or structural pattern) is then repeated at a lower level:

• Business Process Activities map 1-to-1 with Business Process Use Cases started by Business Roles.
• Business Process Use Cases exist to support Business Goals.
• Business Goals are set by your Customer Stakeholders, and are evaluated by means of Measures.
• A specific Business Process Activity Realization sees Business Workers performing a set of Business Process Tasks that are producing, consuming, and exchanging Business Entities.
• Business Entities also surface at the upper level as entities exchanged between Business Process Realizations.
• Any such Realization by Business Workers is an interaction that actually describes a business scenario.

There are two links between the business layer just outlined and the systems layer.

• Some or all of the activities that the Business Worker performs in a scenario can be automated. The USBD best practice suggests that each operation that has been automated in a Business Process Activity Realization actually determines a System Actor (who calls the operation) and a System (the operation provider), and can be mapped to a corresponding Use Case Realization.
  Therefore, each Business Worker Operation that has been selected for automation maps to a corresponding Use Case Realization at the systems level. The Use Case Realization, of course, links to the Use Case it realizes.
• At the same time, there is a User (a particular type of System Actor) that impersonates a Business Role (or the Business Worker in the scenario), and uses a system to perform the corresponding operation(s).

You can see the Business Worker (with its operations) and the Business Role in both Figure 1 and Figure 2, and they represent the links between the business and the systems layers.

But there is also another aspect of system's design that comes into play as soon as the System Actor is an actual User.

• Entering the field of the User eXperience, you want to capture User archetypes in the form of Personas that have Goals.
• In addition to that, you need to design the User Interface as well, and the rest of Figure 2 shows you how.
• Use Case Storyboards provide an additional way of describing the realization of a Use Case. Storyboards describe the navigation through User Interface elements that realizes the Use Case, and thus supports the corresponding User Goals.

Back to top

UML 2.0 Extensions

Table 1 describes the extensions introduced to the UML 2.0 to support modeling of the USBD concepts. The Business Modeling UML 2.0 profile was introduced with Version 7 of Rational Software Architect, while the WebSphere Business Integration Modeler Nav Tree Profile comes with the integration with WebSphere Business Modeler.

The following sections show you how to add all the needed profiles to a model.

Back to top

The UML 2.0 Profile for Unified Scenario Based Design

Figure 3 shows the new stereotypes that the UML 2.0 profile for USBD defines. You will notice some more stereotypes than those listed in Table 1. These are optional stereotypes that you can use when you organize the elements in your model into different packages, and are in addition to the ones already provided by the WebSphere Business Integration Modeler Nav Tree Profile. As the sample model will demonstrate, organizing a model with characterized packages greatly enhances its usability.

To be able to use the stereotypes in the profile, you need to install it into Rational Software Architect.

Installing the UML 2.0 profile for USBD

You should first download the archive linked in the Downloads section, and extract it locally. Then you can install the profile using the usual procedure to install plug-ins onto the Eclipse platform.

The procedure is as follows:

1. Open the Help menu and select Software Updates > Find and Install.
2. Next, choose Search for New Features to Install, and then New Local Site.
3. Navigate to the directory where you extracted the contents of the archive (where the site.xml file resides).
4. In the next dialog, specify USBD Profile Site for the name.
5. Click Finish.
6. In the next dialog, expand the USBD Profile Site node and select the Unified Scenario Based Design feature 1.2.0 feature.
7. Follow the rest of the wizard steps will allow you to install the UML profile.

In the next section, you will see how to import a business process (modeled in WebSphere Business Modeler Advanced Edition) into Rational Software Architect to derive requirements to automate parts of the process.

Back to top

From the Business down to the Code

Unified Scenario Based Design provides a methodology to derive software requirements out of the business processes you wish to automate, and to ensure that the software meets both the business and the User goals. Assume that your organization has a team of business analysts and designers who have built an asset of business processes modeled with WebSphere Business Modeler.

These may be your own organization's business processes, or your clients'. In the former case, you may want to automate part of your processes to increase the efficiency of your organization. In the latter, you may be a software company facing the task of providing a software solution to automate part of your clients' processes.

Figure 4 shows the contents of the sample business process model in WebSphere Business Modeler.

In particular, Figure 5 shows a sample Batch and Schedule Development business process. To better outline the modeling possibilities in WebSphere Business Modeler, and to understand how each is converted into UML, this example shows:

• Simple tasks for Gather Scheduling Requirements and Gather Batch Requirements
• A global task for Batch Development
• Global processes for Schedule Development and Program Development

We will also outline how the global repositories Schedule Definitions, Batch Definitions, and Program Library will be handled in the conversion.

Figure 6 expands the details of the Schedule Development global process, which will be selected for automation in the next section. For the sake of simplicity, it just contains one activity.

You can improve the value of your business processes asset by importing the WebSphere Business Modeler models into Rational Software Architect to pass the knowledge to your development team. In Rational Software Architect, you can then complement the knowledge with additional semantics from the USBD methodology. In addition, the trace relationships between the model elements give you an integrated view of the business, system, and User experience aspects of the problem.

Importing an WebSphere Business Modeler process model into Rational Software Architect

Before starting, make sure that you have added the WebSphere Business Modeler integration into your Rational Software Architect installation. Usually you specify this option when you install Rational Software Architect. If you did not, you can add it later from the Rational Software Architect installation media using the IBM Installation Manager.

In this section, you will see how to import a sample business process model for a "Rich Company", following the workload scheduling process examples given in the previous articles of the series. We start by launching Rational Software Architect in a new workspace and switching to the modeling perspective. We can now import the WebSphere Business Modeler model as an existing project:

1. From the File menu, select Import. The Import dialog displays, as shown in Figure 7.
   
   Figure 7: Importing the WebSphere Business Modeler projects
   
   
   
2. In the General folder, select Existing Projects into Workspace and click Next.
3. Next, specify the WebSphere Business Modeler workspace directory where the business process model project(s) reside.
4. In the dialog shown in Figure 8, select the project(s) that you want to import, and whether the contents should be copied into the Rational Software Architect workspace or be referenced into the WebSphere Business Modeler one.
   
   Figure 8: Choosing the WebSphere Business Modeler projects to import
   
   
   
5. Click Finish. The business process model is converted into UML and imported into the Rational Software Architect workspace. Figure 9 shows what it looks like at first glance.
   
   
   Figure 9: The imported project converted in UML
   
   
   

Synchronizing model versions Notice that you are currently looking at the original model by using a different representation of it. This "UML look" is actually read-only, meaning that you cannot make changes to the UML model and have these changes reflected in the original WebSphere Business Modeler business model. In practice, you are actually working on an in-memory UML model that does not have a counterpart file in the workspace yet. The first thing to do is to persist the model in a file so that you can keep any change you make to the UML model. This means, of course, that since you save the UML model into a different file, it is your responsibility to keep it aligned with the original WebSphere Business Modeler business model. As soon as you save the model, close the original WebSphere Business Modeler model (actually, the resource.xmi file) and open the new .emx file to continue working on it.

Notice that the business model elements defined in WebSphere Business Modeler have been converted into UML elements, and that no diagram has been created. To do this, create a set of diagrams and drop the converted elements into them to see what you have. First, create a freeform diagram and then drag all the items found in the Business Items and Processes packages into the diagram. Figure 10 shows the result after reorganizing the layout.

Notice that each process has been converted into two items: a <<BusinessUseCase>> and a <<Process>>, the first being a UML Use Case and the second a UML Collaboration. Each business item has been converted into a <<BusinessEntity>>, and each role into a <<BusinessActor>>.

Complementing the business knowledge with USBD concepts

Now that you have imported the knowledge about the business process of interest into Rational Software Architect, you want to augment this knowledge with concepts that WebSphere Business Modeler is not meant to capture. To be able to use the USBD stereotypes in our model, you first need to add the UML 2.0 profile for USBD to the model.

1. To do that, select the UML model in the resource tree on the left, and then in the properties view select the Profiles tab.
2. Click the Add Profile button. This brings up the dialog shown in Figure 11, from which you can choose the USBD Profile.

You will start by modeling the Business Goals that lie behind the organization that you are targeting, and in particular from the goals that impact the business processes that you have described.

1. To do that, first create a package at the top of your UML model and name it Business Goals.
2. Next, characterize the package with the <<Business Goals Catalog>> stereotype from the USBD profile.
3. Then, open the diagram in the package and create two classes, representing two business goals, and stereotype them as <<BusinessGoal>>.
4. You can then add the measures for the goals as attributes of the corresponding classes, and stereotype them as <<Measure>>.
5. Now, you need to model who established these goals for the organization, because this is also who will want to receive reports related to how the organization achieves these goals. You do this by adding a new <<BusinessActor>> to the Processes package. Also add the <<CustomerStakeholder>> stereotype to it.

The result is shown in Figure 12.

You can now drill down to perform business analysis on the business process that you have imported, to further specify the process activities. This will allow you to determine which activities you want to automate, and thus elicit requirements for the corresponding software system.

1. To do this, you first want to examine the Batch and Schedule Development business process. Therefore expand the <<ProcessCatalog>> package, then the Batch and Schedule Development <<Process>> -stereotyped UML Collaboration, and then the UML Activity inside it.
2. You need to create a diagram to look at the Activity, and you do it by simply right-clicking the Activity node, and then select Add Diagram > Activity Diagram.
3. The new diagram is automatically populated with the UML Activity containing it. Open the diagram, an excerpt of which is shown in Figure 13, and you will notice that the original business process has been converted as follows:

• Each simple task, global task, or global process called within the original process becomes a Call Operation Action in the new process form.
• Each such Call Operation Action is put into a swimlane that represents the original actor performing the original task or global process. Each swimlane maps to the corresponding Business Actor.
• Inputs and outputs to the original tasks or global processes are correctly transferred to the corresponding Call Operation Actions.

This example will focus on the Schedule Development global process, and Figure 14 shows what it looks like after you add a corresponding activity diagram in the same way as you just did for the main process. For simplicity, this sub-process only contains one task, here converted into a Call Operation Action called Create a Schedule Definition for the Batch.

You want to analyze this activity and further detail its sub-tasks. You will do this by developing a <<BusinessProcessActivityRealization>>, which is a UML Collaboration as shown in Table 1 previously.

1. Before doing that, you need to allocate a proper package to contain the realizations, so create another top package and characterize it with the <<BusinessProcessActivityRealizations>> stereotype.
2. You will describe the flow of tasks that needs to be done for the Create a Schedule Definition for the Batch activity in a Sequence Diagram this time, as shown in Figure 15.

The realization of an activity in the process is started by the corresponding Business Actor and carried out by means of a set of Business Workers. Drag the various collaborating workers from the model tree into the diagram to describe the sequence of tasks that realize the process activity.

You will notice the presence of a new worker named Workload Scheduler. You have explicitly created this worker in the <<ResourceCatalog>> package, because you have discovered a new actor participating in the realization of this activity. This is where you pass from the business context to the system context: assume that you have decided to automate this Workload Scheduler worker. Perform the following steps:

1. First, add the <<System>> stereotype to this class.
2. You should now understand that each interaction with this worker defines a Use Case of the corresponding system, such as an interaction being a Message depicted in a Sequence Diagram that in turns corresponds to an Operation of the Business Worker class. You can then also create system Actors to map the workers (or actors) that interface with the new system, and add either the <<System>> or the <<User>> stereotypes to them.
3. Figure 16 shows the Use Case Model that comes out of the incoming messages to the Workload Scheduler worker that you find in all activity realizations that you have developed in the model.
4. You can also see one system Actor, which is a <<User>>, that corresponds to the Schedule Developer Business Actor. You can put a link to the use case model directly into the sequence diagram by creating a note and dragging the use case diagram from the model tree into the note.
5. In addition, you can package use cases into a top-level package that can be characterized using the <<UseCases>> stereotype.

You now have a system that will have Users, and we want these Users to have a successful and pleasant experience with the system. The USBD methodology allows you to design a system that integrates into the business processes of its Users, and this should ensure a successful experience. Nevertheless, you may also want to introduce the human factor in the equation, so that you can also provide an efficient, easy, and pleasant interaction.

One approach to this problem is to perform Interaction Design (IaD), which in the end defines Personas and captures User Goals. Figure 17 shows how you can describe User Goals in the model, and tie the system's Use Cases to these goals. Although this example does not discuss it, Personas can also be described and characterized using the USBD stereotypes, as shown in Table 1 above.

Finally, since the interactions between your User and your System will be made through a User Interface of some sort, you can develop a Use Case Storyboard for each Use Case of interest that describes how this interaction will occur, in terms of the User Interface elements that participate and how they will be navigated.

A Use Case Storyboard is another <<Realization>> of a Use Case, like it is the usual realization that you describe in the Analysis model. However, it does not define how the Use Case is realized internally by the System, but how it is realized externally by means of its User Interface. Figure 18 shows how you can model a Use Case Storyboard using a UML Collaboration that is described with a State Machine.

You can stereotype the Collaboration and the State Machine both as <<Storyboard>>, and each state in the state machine as <<UIElement>>. States represent panels of the UI and the transitions between them represent navigational paths in response to User actions on the panels. Storyboards have also been proven effective in designing the test cases for the User Interface, as a set of paths through the state machine. Again, you can package Storyboards into a top-level package that you can characterize using the <<Storyboards>> stereotype.

Back to top

Conclusions

This article completes the series dedicated to a requirements gathering and design methodology that has been successfully practiced in the IBM Rome development laboratory.

The articles in this series have described the reason behind a Unified Scenario Based Design approach that focuses on the end-to-end business environment (where products live), and provides a strong means to link this to the context of the systems that automate the business. 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. The articles have also discussed an approach to a formal representation of user interfaces linked with system analysis.

This last article has focused on the tools that help you put the USBD methodology into practice. The article provides a novel UML profile that, when you use it in IBM Rational Software Architect (V7 and later) in conjunction with the IBM WebSphere Business Modeler integration feature, allows you to capture and describe in a formal way all the relevant concepts of the business, system, and User experience layers.

Back to top

Download

	Information about download methods

Resources

• [1] Usability Engineering Scenario-based Development of Human Computer Interaction, Mary Beth Rosson, John M. Carroll
  
  
• [2] An "outside in" approach to development, Executive corner, from CCR2, Issue 9 - 2005
  
  
• [3] User-Centered Design: An Integrated Approach, Karel Vredenburg, Scott Isensee, Carol Righi - Prentice Hall, 2001
  
  
• [4] User Engineering, http://www.ibm.com/ibm/easy/eou_ext.nsf/publish/1996
  
  
• [5] Learn business process modeling basics for the analyst, http://www.ibm.com/developerworks/webservices/library/ws-bpm4analyst/
  
  
• [6] Effective Business Modeling with UML: Describing Business Use Cases and Realizations, http://www.ibm.com/developerworks/rational/library/content/03July/2000/2256/2256_PWN.pdf
  
  
• [7] Introducing the IBM Rational Unified Process essentials by analogy, http://www.ibm.com/developerworks/rational/library/05/wessberg/
  
  
• [8] Unified Modeling Language version 2.0, http://www.ibm.com/developerworks/rational/library/05/321_uml/
  
  
• [9] UML Distilled: A Brief Guide to the Standard Object Modeling Language, Third Edition, M. Fowler - Addison-Wesley, 2004
  
  
• [10] UML Resource Center, http://www.ibm.com/software/rational/uml/
  
  
• [11] About ITIL, http://www.ogc.gov.uk/index.asp?id=1000367
  
  
• Browse the technology bookstore for books on these and other technical topics.
  
  

• Download IBM Rational Software Architect evaluation versions and get started on analysis, design and development of software.
  
  
• Download trial versions of other IBM Rational software.
  
  
• Download IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Tivoli®, and WebSphere®.
  
  

• Check out developerWorks blogs and get involved in the developerWorks community.
  
  
• Rational Software Architect, Data Architect, Software Modeler, Application Developer and Web Developer forum: Ask questions about Rational Software Architect and other modeling products.

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.

		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.

		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.

Rate this page

Please take a moment to complete this form to help us better serve you. Did the information help you to achieve your goal? Yes No Don't know   Please provide us with comments to help improve this page:   How useful is the information? 1 2 3 4 5 Not useful Extremely useful

Share this.... Digg this story del.icio.us Slashdot it!

Back to top