As a UML instructor, I
find that learning UML presents a paradox: UML is not a process, but
rather a notation that can be used in a process; and yet without a process,
students don't know where to start with UML. They might see some meaning in a
given diagram, but they don't know which diagram to draw when. And without
knowing what to draw, they don't draw anything. And of course, without
practice, they never master UML, so they never learn to apply it within their
own processes.
So to resolve this paradox, I developed Five Step UML, a
simple, small process that you can master right away, and then apply
immediately to a problem of your choice. As the name implies, Five Step UML is
very closely based on UML itself, and is intentionally designed as a learning
process for UML. It's not robust enough for a production process -- for
instance, it lacks any support for testing, documentation, or management -- but
it's just enough process to show UML as a tool from requirements gathering all
the way through to code design. It shows my students (especially my programmer
students) a few ways in which UML can help them to think about a problem and
communicate their thoughts to each other. After all, UML is all about
communication.
In case you don't know UML, I have included Five Step UML as a tutorial exercise
with Tablet UML. This can also serve as a guide to Tablet UML itself, helping
you to explore its features. In the tutorial, I'll both discuss the process and
include specific instructions for performing the tutorial using Tablet UML.
I'll also include a running example of a sample project analyzed and designed
with Five Step UML.
To run this tutorial, I strongly recommend three things:
Get Tablet UML. You
can work the tutorial with paper and pencil, or with any UML tool; but the
examples and instructions will be specific to Tablet UML.
Find a team. UML is all about communication, about expressing your ideas in a
graphical format that lets others review them and help to improve them. I
recommend 4 to 6 people: with 3 or fewer, one person can dominate the
conversation too easily; and with 7 or more, one person can blend into the
background and not really participate. You can do this exercise alone, but you
may not appreciate the results as much.
Pick a problem to analyze and solve. You'll be tempted to pick your current
system, but I advise against this: you'll be strongly inclined to design what
you already have, rather than analyzing and solving something new. You'll get
bogged down in minutiae and not spend time analyzing the whole system. And
you'll tend to work on the stuff you already know well, when UML is best at
expressing and refining new ideas that need group feedback. It's better to pick
a new problem domain. (If you have no ideas for a test problem, consider these
suggestions: on-line travel reservations; on-line pizza orders; on-line
greeting cards; university course enrollment; on-line banking; delivery
tracking; order entry and processing; or an auction system.) But there's one
related recommendation: one person on your team should feel confident acting as
the customer for that system. That's the person who decides what the system should
do; the rest of the team has to figure that out and design how the system will
work.
Once you have your team and your problem, you're ready to work the tutorial. It
consists of (roughly) five steps:
Define . Define the features you have to implement.
You'll rely primarily on use case diagrams
for this.
Refine. Refine a feature to capture the rules for how
it must operate. You'll rely primary on activity
diagrams and state diagrams
for this. Repeat for each feature.
