|We need to see more use case and
Unified Modeling Language examples" is a demand we hear fairly
often these days. Although we present a fairly extensive example in
our first book, Use Case Driven Object Modeling with UML
(Addison-Wesley, 1999), we recently convinced Addison-Wesley to let
us produce a companion workbook, in which we will dissect the design
of an Internet bookstore, step-by-step, in great detail. This will
involve showing many common mistakes, and then showing the model
with its mistakes corrected.
This article is the first in a series of five that will provide a
prepublication look at the annotated example from the workbook (to
be called Applied Use Case Driven Object Modeling,
conveniently enough) as it evolves. We'll be following the process
detailed in our book (also known as the ICONIX process), which sits
somewhere between the very large Rational Unified Process (RUP) and
the very small Extreme Programming (XP) approach.
The ICONIX process is use case driven, like RUP, but lacks a lot
of the overhead that RUP brings to the table. It's also relatively
small and tight, like XP, but it doesn't discard analysis and design
like XP does. This process also makes streamlined use of UML while
keeping a sharp focus on the traceability of requirements. And, the
process stays true to Jacobson's original vision of what "use
case driven" means, in that it results in concrete, specific,
readily understandable use cases that a project team can actually
use to drive the development effort.
Each of the articles that follow this one will address an
essential aspect of the process by focusing on one of the four
critical diagrams used in the Iconix process. These four articles
will have the same basic look and feel, with these shared elements:
- A "top 10" list that describes modeling errors to
- A diagram that shows two or three violations of these top 10
rules, as committed by students in classes that we've taught.
- Another diagram that shows corrections of the erroneous
Best of Breed
Figure 1 shows the "big picture" for the process. The
diagram portrays the essence of a streamlined approach to software
development that includes a minimal set of UML diagrams and some
valuable techniques that take you from use cases to code quickly and
efficiently. The approach is flexible and open; you can always
select from the other aspects of UML to supplement the basic
Figure 1. The "Big Picture" for Use Case
Driven Object Modeling
The diagram portrays the essence of a
streamlined approach to software development that includes a
minimal set of UML diagrams and some valuable techniques
that take you from use cases to code quickly and
The second article will discuss domain modeling. This is the task
of discovering classes that represent the things and concepts
related to the problem that a system is being designed to solve.
We'll describe how the domain model serves as a glossary of terms
that people can use in writing use cases.
Domain modeling involves working outward from the data
requirements to build a static model of the problem domain
relevant to the proposed system. We'll point out how the approach
emphasizes domain modeling more than RUP, and certainly more than
The third article will discuss how to write use cases that detail
the scenarios that the users will be performing. We'll describe how
to write complete and unambiguous use cases that describe individual
aspects of system usage without presuming any specific design or
Use case modeling involves working inward from the user
requirements to start building a dynamic model of the
solution space for the proposed system. We'll talk about how use
cases, by extension, drive the entire development effort.
The Forgotten Diagram
The fourth article in the series will discuss robustness analysis, a
practice that originated with Ivar Jacobson but was dropped from the
Rational implementation of UML. This involves analyzing the
narrative text of use cases, identifying a first-guess set of
objects that will participate in those use cases, and classifying
these objects based on the roles they play.
- Boundary objects are what actors use in communicating with the
- Entity objects are usually objects from the domain model.
- Controllers serve as the "glue" between boundary
objects and entity objects.
We'll show how robustness analysis, which serves as preliminary
design within the process, provides the missing link between
analysis and detailed design.
The fifth and last article will discuss interaction modeling, the
phase in which people build the threads that weave their objects
together and enable them to start seeing how the new system will
perform useful behavior. We'll demonstrate how to build sequence
diagrams, which enable designers to perform three key tasks:
- Allocate behavior among boundary objects, entity objects, and
controllers that will become full objects in the model.
- Show the detailed interactions that occur over time among the
objects associated with each use case.
- Finalize the distribution of operations among classes.
We'll explain how the detailed, design-level class diagrams that
result from interaction modeling represent a suitable foundation for
moving into the coding phase of a project.
We'd like to point out three significant features of this
First, it's iterative and incremental. Multiple iterations occur
between developing the domain model and identifying and analyzing
the use cases. Other iterations exist, as well, as the team proceeds
through the life cycle. The static model gets refined incrementally
during the successive iterations through the dynamic model (composed
of use cases, robustness analysis and sequence diagrams). Please
note, though, that the approach doesn't require formal milestones
and lots of bookkeeping; rather, the refinement efforts result in
natural milestones as the project team gains knowledge and
Second, the approach offers a high degree of traceability. At
every step along the way, you refer back to the requirements in some
way. There is never a point at which the process allows you to stray
too far from the user's needs. Traceability also refers to the fact
that you can track objects from step to step as analysis melds into
Third, the approach offers streamlined usage of UML. The steps
that we'll describe in the upcoming articles represent a
"minimalist" approach-they comprise the minimal set of
steps that we've found to be necessary and sufficient on the road to
a successful OO development project. By focusing on a subset of the
large and often unwieldy UML, a project team can also head off
"analysis paralysis" at the pass.
We'll demonstrate these aspects of the ICONIX process in the context
of an on-line bookstore. The focus will be on the customer's view of
Article two will describe how to build a domain model that has
loosely coupled classes, each of which does one thing well.
Article three will discuss how to write small, concise use cases
system responses in a way that's easy for readers to understand at a
Article four will demonstrate how to do robustness analysis in
order to tighten up use cases and make it easier to head into
Article five will explore sequence diagrams, which we'll use to
allocate the behavior specified by use cases to the objects
mentioned in those use cases.
See you next month.