|
 |
Timing diagrams are one of the new artifacts added to
UML
2. They are used to explore the behaviors of one or
more objects throughout a given period of time. There
are two basic flavors of timing diagram, the concise
notation depicted in Figure 1 and
the robust notation depicted in
Figure 2.
Timing diagrams are often used to design embedded
software, such as control software for fuel injection
system in an automobile, although they occasionally have
their uses for business software too.
|
|
Figure 1
depicts the lifecycle of a single seminar, showing its
timeline quite clearly. The :Seminar label
indicates that the lifeline being explored is that of an
instance of Seminar. The critical states that
the seminar exhibits – Proposed, Scheduled,
Enrolling Students, Being Taught, Final
Exams, Closed – are listed across the
diagram. The two lines surrounding the states are
called a general value lifeline. In this case I’m using
them to show the value of the state of a seminar, but
you could also explore the value of a single attribute
of an object if you so choose. When the two lines cross
one another it indicates a transition point between
states. Along the bottom of the diagram timing
constraints are shown, in this case indicating the
period of time during which the seminar is in each
state.
Figure 1. Timing diagram
(concise notation).
It’s interesting to note the
differences between the timing diagram of
Figure 1 and the
state machine diagram. Several states from the state
machine diagram are encompassed by the Enrolling
Students state of the timing diagram. That’s
perfectly fine because I’m using each diagram for its
individual strengths – concise timing diagrams are good
at exploring one or more objects throughout a period of
time and state machine diagrams are good at exploring
the detailed transitions between states as the result of
events (either external or internal). Remember AM’s
Apply the Right Artifact(s) practice and use the
right model for the job.
Figure 2
depicts a timing diagram which explores the details of
what happens while a seminar is being taught. In this
jaded example the professor delivers the seminar and
marks student work and the teaching assistant develops
the course material just in time for it to be taught. A
UML frame is being used to bound the two lifelines (that
of the professor and the teaching assistant); we could
very easily have modeled more lifelines simply by adding
other sections to the frame. The box lines are called
state timelines, in this case there are discrete
transitions between states resulting in a box line
although had the transitions been continuous in nature
(such as the change in temperature) a curvy line would
have been drawn. The states/conditions applicable to
the lifeline, such as Mark Student Work and Idle, are
listed along the left-hand side of the diagram.
Events/stimuli, such as Holiday Break and
Break Ends, are optionally labeled at transition
points to indicate the reason for the change. The
arrows between timelines are messages between the
objects.
Several ways to indicate time are
shown in Figure 2.
A timing constraint, {Oct 5..Oct 10} is shown as
are time observations (t=Nov 25 and t=Dec 1).
Timing constraints and time observations can be applied
to a variety of UML diagrams, including all forms of
interaction diagrams such as sequence diagrams and
communication diagrams, although I find them most useful
on timing diagrams. Unique to timing diagrams are
timing rulers, depicted as tick mark values along the
bottom of the diagram.
Figure 2.
Timing diagram (robust notation).
Remaining Agile
Both notations have their purposes,
although the robust notation seems the more useful of
the two particularly for objects that move back and
forth between states. The more lifelines you try to
model at once the harder it is to draw the diagram so
two lifelines is about as complex as I like to get. I
draw timing diagrams on whiteboards, I don’t know of any
mainstream modeling tool oriented towards business
application development that supports this kind of
diagram.
In my opinion very few developers
will find that they need UML timing diagrams, so I
really can’t recommend that you invest the time to learn
them. For the few times that you need to explore timing
issues free form diagrams will very likely suffice.
This artifact description is excerpted from Chapter 11 of
The Object Primer 3rd Edition: Agile Model Driven
Development with UML 2.
 |
|
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
of the
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
such as
refactoring and
test-driven development
(TDD). The Object Primer also includes a
chapter overviewing the critical database
development techniques (database refactoring,
object/relational mapping,
legacy analysis, and
database access coding) from my award-winning
Agile Database Techniques
book. |
 |
|
Agile Modeling: Effective Practices for Extreme
Programming and the Unified Process is the seminal
book describing how agile software developers approach
modeling and
documentation. It describes principles and
practices which you can tailor into your existing
software process, such as
XP, the
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
elicit requirements,
architect, and then
design your system in an agile manner. |
 |
|
The Elements of UML 2.0 Style describes a collection
of standards, conventions, and
guidelines
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. |
The notation used in these diagrams, particularly the
hand drawn ones, may not conform perfectly to the
current version of the UML for one or more of reasons:
- The notation may have evolved from when I
originally developed the diagrams. The UML
evolves over time, and I may not have kept the
diagrams up to date.
- I may have gotten it wrong in the first place.
Although these diagrams were thoroughly reviewed for
the book, and have been reviewed by thousands of
people online since then, an error may have gotten
past of us. We're only human.
- I may have chosen to apply the notation in
"non-standard" ways. An agile modeler is more
interested in created models which communicate
effectively than in conforming to notation rules set
by a committee.
- It likely doesn't matter anyway, because the
modeling tool(s) that you're using likely won't
fully support the current version of the UML
notation perfectly anyway. Bottom line is that
you're going to be constrained by your tools anyway.
If you're really concerned about the nuances of
"official" UML notation then read the current version of
the UML
specification.
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.
 
|
