Use Case Driven Object Modeling With UML
Doug Rosenberg and Kendall Scott describe a
technique called robustness analysis. The basic
idea is that you can analyze the steps of a use case to
validate the business logic within it and to ensure that
the terminology is consistent with other use cases that
you have previously analyzed - in other words you can
use them to ensure that your use cases are sufficiently
robust to represent the usage requirements for the
system you're building. Another use is to identify
potential objects or object responsibilities to support
the logic called out in the use case, effectively acting
as a bridge to other diagrams such
UML sequence diagrams and
A robustness diagram is basically a
UML communication/collaboration diagram which uses the
graphical symbols depicted in Figure
1. As you can see robustness diagrams depict
several types of concepts:
- Actors. This is the same
concept as actors on a UML use case diagram.
- Boundary elements. These
represent software elements such as screens, reports,
HTML pages, or system interfaces that actors interact
with. Also called interface elements.
- Control elements. These
serve as the glue between boundary elements and entity
elements, implementing the logic required to manage
the various elements and their interactions. Also
known as process elements or simply as controllers.
It is important to understand that you may decide to
implement controllers within your design as something
other than objects - many controllers are simple
enough to be implemented as a method of an entity or
boundary class for example.
- Entity elements. These
are entity types that are typically found in your
conceptual model, such as Student and
- Use cases (optional).
Because use cases can invoke other use cases you need
to be able to depict this on your robustness diagrams.
Figure 1. Robustness diagram
whiteboard sketch of a robustness diagram
representing the logic contained in the
University system use case.
To create the sketch I merely followed the logic of the
use case and applied the following heuristics:
- Add a boundary element for each
major user interface element such as a screen or a
report. Although some very detailed use cases
will describe how actors work with buttons and edit
fields I prefer to stay at a higher level and not show
these details. I did however choose to show the
Create Student Icon on the diagram although in
hindsight this boundary class would be better labeled
Desktop. I chose not to update the diagram
because I follow the AM practice Update Only When
it Hurts and frankly it isn't important enough to
fix this minor issue. These classes are likely to
appear on your interface-flow diagrams if you choose
to create them.
- Add a controller to manage
the overall process of the scenario being modeled.
In Figure 2 this is the Enroll in University
element. As you can see it provides the glue which
keeps the diagram together. In your design this
element could very likely be implemented as a class,
as one or more operations, or via some sort of
workflow engine if that is part of your overall
- Add a controller for each
business rule. This helps to make the
rules explicit on your diagram. Some people will
not model the business rules at all, keeping their
diagrams simple, but as a result they miss very
important information in their diagrams. Try both
ways and then choose the approach that works best for
- Add a controller for
activities that involve several other elements. An
example of this is the Create Student element
which interacts with a business rule as well as the
- Add an entity for each
business concept. The Student and
Student Fee classes are examples of this. These
elements are likely to appear on your conceptual model
if you chose to create one.
- Add a use case whenever one is
included in the scenario. I chose to depict the
invocation of the Enroll in Seminar use case using
standard UML notation for use cases. Another option
is to depict the use case as a controller although
in my experience this isn't as clear to project
stakeholders. Remember the AM principle
More Important Than Representation and do whatever
is best for your situation.
Figure 2. Example robustness
By drawing a robustness diagram we
quickly gain a sense for the work that we need to do to
implement this use case because it helps to visualize
the potential elements we'll have to build. The boundary
elements will help to bridge your use cases to your user
interface development and your legacy system analysis
efforts. Some of those classes are entity elements,
things that should definitely appear on a conceptual
model. The controllers are much closer to design
concepts, so robustness diagrams help to bridge to your
How do you keep robustness diagrams
agile? My experience is that the following AM practices
are very relevant:
participation. Robustness diagrams can be a very
good technique, in some situations, to perform
analysis with your stakeholders. As you can see in
Figure 2 robustness diagrams
are very straightforward and easy to draw, making them
an inclusive modeling technique.
Discard temporary models.
Robustness diagrams are typically drawn on a
whiteboard in order to analyze the logic of a use
case. Once the use case has been improved the
robustness diagram will be kept around long enough to
act as a bridge to the next development step, see
below, then erased.
Apply the right Artifacts.
Some modelers, including myself, will stop creating
robustness diagrams when their stakeholders get used
to making the logical jump from use cases to other
development artifacts such as
sequence diagrams. In other words robustness
diagrams are used to help train stakeholders to think
abstractly and then abandoned as a technique once this
goal is reached. Other modelers will continue to use
robustness diagrams because the models still add
significant value to their overall efforts.
What is next after robustness
diagrams? Robustness diagrams often act as bridge from
use cases to other models. For example, it is quite
common to create
sequence diagrams which represent the detailed
design logic required to support the use case. It is
also common to focus on the user interface for your
system, perhaps via prototyping or better yet just
getting right into the "real" coding, because robustness
diagrams explicitly include boundary/interface
elements. Furthermore, because robustness diagrams
depict major business entities it is quite common to use
them as an input you're your conceptual/domain modeling
This artifact description is excerpted from Chapter 8 of
The Object Primer 3rd Edition: Agile Model Driven
Development with UML 2.
||This is the best
reference that I know for robustness diagrams.
It goes into robustness analysis in great detail.
The Object Primer 3rd Edition: Agile Model Driven
Development with UML 2 is an
important reference book for agile modelers,
describing how to develop 35
types of agile
models including all 13
UML 2 diagrams.
Furthermore, this book describes the techniques
Full Lifecycle Object Oriented Testing
(FLOOT) methodology to give you the fundamental
testing skills which you require to succeed at
agile software development. The book also
shows how to move from your agile models to
source code (Java examples are provided) as well
as how to succeed at implementation techniques
(TDD). The Object Primer also includes a
chapter overviewing the critical database
development techniques (database refactoring,
legacy analysis, and
database access coding) from my award-winning
Agile Database Techniques
Agile Modeling: Effective Practices for Extreme
Programming and the Unified Process is the seminal
book describing how agile software developers approach
documentation. It describes principles and
practices which you can tailor into your existing
software process, such as
Rational Unified Process (RUP), or the
Agile Unified Process (AUP), to streamline your
modeling and documentation efforts. Modeling and
documentation are important aspects of any software
project, including agile projects, and this book
describes in detail how to
architect, and then
design your system in an agile manner.
The Elements of UML 2.0 Style describes a collection
of standards, conventions, and
for creating effective
UML diagrams. They are based on sound, proven
software engineering principles that lead to diagrams
that are easier to understand and work with. These
conventions exist as a collection of simple, concise
guidelines that if applied consistently, represent an
important first step in increasing your productivity as
a modeler. This book is oriented towards
intermediate to advanced UML modelers, although there
are numerous examples throughout the book it would not
be a good way to learn the UML (instead, consider
The Object Primer). The book is a brief 188
pages long and is conveniently pocket-sized so it's easy
to carry around.
Successful Robustness Analysis
This is a great
overview, written by Doug Rosenberg and Kendall
Scott, of robustness analysis.
||This site includes
links to great articles as well as example models.
We actively work with clients around the world to
improve their information technology (IT) practices,
typically in the role of mentor/coach, team lead, or trainer. A full
description of what we do, and how to contact us, can be
found at Scott W.
Ambler + Associates.