Article Introduction

There are many styles of doing UML modeling, but one of the more popular and more successful approaches involves driving the object modeling process by exploring the use cases (usage scenarios) of the system being modeled. ICONIX has been teaching use-case-driven object modeling since about 1993, shortly after the pioneering book on the topic by Ivar Jacobson. More recently, we've been leveraging the extensibility mechanisms within Rose to provide better support for a use case driven approach.

This article will take you through the most important elements of a use case driven UML model, and introduce you to a variety of tips and tricks that we've developed as we've taught UML modeling workshops with Rose.

There are a number of UML diagramming elements, but when following a use case driven style, five of them have proven to be the most important. While we're not suggesting the other elements are not important, we'll focus mainly on the following elements within this article:

1) Packages, which are used to organize your UML models.

2) Class diagrams, which form the static portion of your UML object model.

3) Use Case Diagrams, which are used to organize the use cases within a package.

4) Robustness Analysis diagrams, for which you will need to use the Objectory stereotypes

5) Sequence Diagrams, which form the core of your UML dynamic object model.

We'll be explaining these different elements of a UML model, how they relate to each other, and how they fit together within Rose.

Organize your models into packages

Packages, represented by tabbed folder icons within the Rose browser, and on the use case diagramming palette, are used as containers for other UML modeling elements. Packages can contain both use cases and classes. In a use-case driven process, both robustness analysis diagrams and sequence diagrams are done for each use case, and are organized in this manner in the Rose broswer.

Rose allows import and export of packages. This becomes especially significant when working in a multi-user, configuration controlled environment. The package becomes the fundamental unit of control; that is, check-in and check-out are done on a package by package basis. Rose provides two default packages at the high level (Use case view and Logical view), but it's often desirable to group a set of related use cases and the classes which they are closely related to within a single package inside the use case view. Keep in mind that you can't import and export the top level packages such as Logical View or Use Case View, so it's a good idea to keep your diagrams, classes, and use cases in subpackages. This organization facilitates partitioning of work across a team of developers.

Build a model of the conceptual objects in your problem domain

Generally, you'll start your UML static modeling efforts with what's called a domain model, which contains the conceptual objects from the problem domain you're trying to address, and then evolve this domain model into a detailed static class model, which you can generate code from.

Classes are the basic building blocks of a UML design. They are the fundamental organizing units for software, grouping together a set of data attributes with the operations that access them. There are many details about a class that are captured using the class specification dialog within Rose. These include attributes, operations, and other descriptive information about a class, as well as information needed during code generation. Later in this article, you'll learn how you can tailor the information in the specification dialog using custom properties.

Classes are linked by associations, and there are a number of these to choose from, including generalization (a superclass/subclass relationship used to describe different kinds of objects), aggregation (used to describe complex objects that are broken into piece parts), and link classes (which are used to capture properties that belong to the association between two classes rather than to either of the classes themselves).

Keep focused on what the users are doing on the screen

If you're driving your UML modeling effort from use cases, that means you're breaking your system apart according to the ways that the users of the system are interacting with it, and using this this breakdown to organize your modeling efforts. Details about the objects within your system are uncovered by exploring the use cases...first in narrative text, then on robustness analysis diagrams using the Objectory stereotypes, and finally in great detail on sequence diagrams. The associations between a group of related use cases are shown on a use case diagram.

There's a certain style of writing use cases that works very effectively for this kind of development, which we've covered in depth in our process tutorials. Briefly, this involves writing the narrative text of the use cases in active voice, driven from the point of view of the user of the system, and working inwards from the user interface to uncover the functionaity required for a given usage scenario, and ultimately the objects that are needed to provide that functionality. Unfortunately, much confusion exists about the right and wrong ways to write use cases, and a lack of understanding in this area is a common cause of failure and inefficiency when doing modeling.

There is a little known feature of Rose that allows you to link pictures of the screens (perhaps from a prototype) directly to the use cases within your Rose model. We've found this to be a very useful technique for keeping your use case modeling efforts focused on user interactions and system responses.

Don't skip preliminary design

Robustness Analysis diagrams, part of the Objectory process, serve a number of useful purposes in a use case driven modeling effort. Robustness analysis involves working through the text of a use case, and taking a preliminary peek at how you might design some software to implement a given use case, using the objects you've discovered up to this point. Obviously one of the main purposes of this activity is to discover when you don't have all the objects you need, and then add them to your class diagram. While you're exploring possible designs, its useful to classify objects into one of the three stereotypes (boundary, control, entity) provided.

The robustness model provides a bridge between the "analysis level" view provided by the text of the use case and the "detailed design" view shown on a sequence diagram. Since it's very difficult to jump from analysis directly to detailed design, it's hard to do modeling successfully without this step.

In order to do robustness analysis, you'll need to extend Rose with the Objectory Add-In from Rational, which contains everything you need to quickly install and make use of the Objectory stereotypes, which are a key element of Rational's Objectory process. Once you've installed the Add-In, you can easily add these stereotypes for boundary, control, and entity objects to Rose, to extend the drawing palette within Rose with the icons for these stereotypes. This will be extremely helpful to your UML modeing efforts.

A robustness diagram provides a graphical view that matches the narrative text of a use case. The use case is described in terms of boundary objects (these are often GUI elements, although they don't have to be), control objects, and entity objects.

Drawing the robustness diagram for a use case provides a visual completeness check that shows that the entire use case has been accounted for. It also serves to enforce the "active voice" style that is most effective when writing use cases.

Making the transition from preliminary design to detailed design

Sequence diagrams show a detailed description of the runtime behavior of a collaborating set of objects. This view show all objects that participate in the scenario, and the messages that are passed between them. Having taught many UML training classes, I can assure you that one of the most common places for people to get stuck in modeling is when they're trying to get a sequence diagram started. If you've followed the steps we've shown you, first writing your use cases correctly, and then drawing the robustness diagram for the use case, you'll find that there are three easy steps to get started.

Step 1) copy/paste narrative text from the use case
Step 2) drag actors and boundary objects from the rose browser onto your sequence diagram
Step 3) drag entity objects from the robustness models onto your sequence diagram

Once you've done these three simple steps, you're off to a good start on your sequence diagram. You've still got to go through the hard work of deciding which messages should go to which objects, but at least you're started.

By using RoseScript, you can automate the process of getting a sequence diagram started from a robustness analysis diagram. The following script, from the "Rose for Power Users" multimedia tutorial CD-ROM, creates a new sequence diagram and automatically populates it with selected actors, boundary objects, and entity objects from a robustness diagram:

Update your classes with operations as you draw the sequence diagrams

In object-oriented programming languages, operations belonging to classes are invoked by passing messages between objects as the program runs. This message passing is shown on the sequence diagram, and deciding where to draw the message arrows is the "hard part" of drawing the sequence diagram (now that we've automated the process of getting it started).

As you are drawing the message arrows between objects, be sure to take advantage of another feature of Rose, which allows you to add operations to the classes in the static model directly from the sequence diagram. This is accomplished by simply right-clicking the mouse on the arrow on the sequence diagram. Make sure you don't just type the message name on the arrow after you draw it as this does not update the static model (class diagram) -- you MUST right-click near the arrowhead on the message arrow and either pick an operation from the pop-up menu or select "New Operation" in order for this to work. When you add a new operation, you'll have to right-click again in order to see the operation name on the message arrow.

What you're really doing when you do this is driving the design of your classes from the sequence diagram, which is simply a refinement of the use case. This is what use-case-driven object modeling is all about.

Measure your progress

As you proceed through use case driven object modeling on your project, you're going to want to easily be able to get an idea of how much progress your project team is making in working through the use cases. The following code segment shows how easy it is to leverage Rose's OLE Automation capabilities to export the names of use cases within a Rose model, along with information about whether robustness and sequence diagrams exist for that use case into a Microsoft Excel spreadsheet. When sequence diagrams have been drawn for every use case, and the message arrows labeled with operations from classes in the static model, we're getting very close to being able to generate code, so this is a very useful "management window" into the project.

Note that Rose can function as both an OLE server and an OLE client. This means that data from your Rose model can be output into productivity tools such as Word and Excel, or imported from those or other OLE compliant applications, and that the data transfers can be controlled either from RoseScript or from Visual Basic scripts running inside other OLE clients.

Verify requirements traceability across use cases and classes

It's important to be able to verify that the system we're modeling will satisfy it's requirements. We can extend Rose to support this capability by using custom property files.

Properties define data that is stored within elements of a Rose model. It's possible to change the schema definition of a model, either by script, or by using a custom property file. These property file have a .pty extension. Within the specification dialog, groups of properties appear on "Tools", which are the tabbed "pages" within the dialog. Properties are essentially "name-value pairs" which can appear and be edited when the tabs are clicked. Both visible and invisible properties can be accessed from your scripts.

The following is an example of a custom property called Requirements, that we've added to use cases. The complete property file also adds the Requirements property tab to the Class specification dialog. This allows us to write scripts that verify that requirements are satisfied in both the static and dynamic parts of the model.

Summary and additional resources

In this article, we've introduced you to a number of useful features that are built into Rose, as it comes out of the box, that can directly support a use case driven approach to UML modeling. We've also tried to provide useful guidance on some strategies for making the most effective use of the product, including a number of tips and tricks that we've found make Rose work better. At the same time, we've given you an introduction to several extensibility mechanisms which allow you to tailor Rose to your environment and to the use case driven modeling style.

Over the years, we've learned that lots of folks think that use case driven object modeling is a good idea, for some obvious reasons, but that many people don't quite understand all the details of how to do it. We've been working for several years to provide this information, in a variety of different ways. These include:

Book:Use Case Driven Object Modeling with UML--A Practical Approach, by Doug Rosenberg and Kendall Scott

Workbook:Applying Use Case Driven Object Modeling with UML by Doug Rosenberg and Kendall Scott

Training on CD-ROMs:http://www.iconixsw.com/CDcourses.html

On-Site Training: http://www.iconixsw.com/UMLTraining.html

We've been teaching use case driven object modeling since 1993. When you need to get your project team moving forward with UML modeling and Rose as quickly as possible, we're ready.