 |
UML
2 object diagrams, sometimes
referred to as instance diagrams, are useful for
exploring “real world” examples of objects and the
relationships between them. Although
UML class diagrams
are very good at describing this very information some
people find them too abstract – a UML object diagram can
be a good option for explaining complex relationships
between classes. |
|
For example, the object diagram of
Figure 1 explores the concepts
that a student can attend a seminar, be wait listed for
a seminar, or can be a teaching assistant within a
seminar. The diagram explores an example where John
Smith and Sally Jones are both students in
CSC 100a whereas Sarah McGrath is the
teaching assistant for it. Sarah is also the
teaching assistant in CSC 100b, Scott Ambler
is an enrolled student, and Ed Maloney is wait
listed. The diagram also shows that the two seminars
are both sections of the Introduction to Computer
Science course. This diagram makes the three
relationships between students and seminars, as well as
the relationship between seminars and courses, much more
explicit.
Figure 1. Object diagram.
The notation used on UML object
diagrams is very simple – they show objects and the
connections between them. When you depict an object you
need to include enough information so that it is a
recognizable instance. As a result I will use one of
two formats: a single box named instance such as
Sarah McGrath: Student or a double box instance
listing one or more identifying attribute values in the
format attribute = value such as name = “Intro
to Computer Science”. Connections between objects
are shown as lines with roles, such as Teaching
Assistant, optionally indicated.
As you can see UML object diagrams
are effectively notational subsets of
UML communication
diagrams, although object diagrams are used to explore
structure whereas communication diagrams explore
behavior. It is common for object diagrams to evolve
into communication diagrams simply by adding messages to
the diagram.
Remaining Agile
I will typically draw object
diagrams on white boards in order to explore the
relationships between objects. Once we’ve explored said
relationships we’ll use whatever we’ve learned to update
our class models or source code as appropriate then
erase the diagram (e.g.
Discard Temporary Models). Remember, the value
is often in the act of modeling and not in the model
itself. I have seen object diagrams retained as part of
the description of a complex business rule but this is
pretty rare in my experience.
This artifact description is excerpted from Chapter 8 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.
 
|
