by Doug Rosenberg
and Kendall Scott
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
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
1) Packages, which are used to organize your UML models.
2) Class diagrams, which form the static portion of your UML object
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
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
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
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
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
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
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
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.
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
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:
Case Driven Object Modeling with UML--A Practical Approach, by Doug Rosenberg and Kendall Scott
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.