 |
ORM diagrams, thoroughly described
in
Information Modeling and Relational Databases
(Halpin 2001) and at
www.orm.net, are in my opinion an incredibly
effective way to explore domain concepts with your
stakeholders. An ORM diagram depicts objects (entity
types), the relationships (fact types) between them, the
roles that the objects play in those relationships,
constraints within the problem domain, and optionally
examples (called fact type tables). |
|
Figure 1
depicts a simple example of an ORM diagram. The ovals
represent entity types (Halpin uses the term object
although ORM diagrams can be used to model systems which
don’t use object technology at all) and the rectangles
roles that the objects play in relationships. Notice
how the roles are described in both directions, in the
top relationship the Student is in the takes
role and Seminar is in the is taken by
role. The double arrowhead above the roles indicates
uniqueness constraints. Because the arrowhead is above
both the takes/is taken by roles it indicates
that the combination of student/seminar must be unique
in this relationship – a student can take many seminars
and a seminar is taken by many students, but a student
can take a given seminar once and once only. Consider
the other relationship. In this case the double
arrowhead is only above the assisted by role,
indicating that a seminar may only appear once in the
fact type table (in other words this is a one-to-many
relationship). As you can see in the fact table each
seminar appears once yet Sally Jones appears twice –
there’s no uniqueness constraint over the assists
role so this is allowed. Had there been individual
arrowheads over each role this would model a one-to-one
relationship because each object could only appear at
most once in each role. Where there are no arrowheads
at all above the roles that indicates an unrestricted
many-to-many relationship (e.g. a student could take the
same seminar several times).
In Figure 1
each object has an attribute listed in the oval – name
for Student and number for Seminar –
indicating the example information listed in the fact
type tables immediately below the roles. This style of
ORM diagram is often referred to as a knowledgebase
diagram although for the sake of simplicity I don’t
bother to differentiate between various styles of ORM
diagrams. Knowledgebases are used to provide examples of
the relationships that the entity types experience when
they are fulfilling the given roles, enabling you to
easily and explicitly explore the relationship with your
stakeholders. I will often draw a knowledgebase when
the relationship isn’t clear, particularly when we’re
trying to explore the multiplicity of the relationship.
Figure 1. Simple ORM Diagram.
Figure 2
presents a more complex example. It doesn’t include
fact type tables and as a result explores a wider range
of concepts – you can only fit so much on a
white board, and AM recommends that you Model in
Small Increments regardless. The relationships
between Student and Seminar have been
fleshed out a bit. The top relationship has evolved
from a binary relationship to a ternary relationship
which involves three entity types (Mark was
added). It is possible to model n-ary relationships on
ORM diagrams simply by adding more roles to the
relationship although I rarely find the need to do so.
You see that there is an exclusive or (XOR)
relationship, depicted by the dotted circle with the X
through it, between the takes role and the
assists role, indicating that a student can either
take a seminar or they can assist it but not both. A
dotted circle without the X would indicate a simple OR
relationship.
Figure 2. More complex ORM
Diagram.
You see that there is a large black
dot on the line between Professor and the teaches
role, indicating that it is mandatory for a professor to
teach a seminar. The dot can appear at either end of
the line, although I prefer to place it on the object
end (sometimes an object will be involved in many
mandatory relationships which can clutter your object
symbols so it’s good to have the option to move the dot
to the other end of the line).
The dashed oval represents an
attribute of an object, showing a more detailed way to
represent the concept that seminars have seminar numbers
than the short form that we used in Figure 1. I prefer to follow the
Depict Models Simply practice and use the short
form but I wanted to provide an example of the long form
for you.
Another interesting concept is the
recursive/self relationship that Professor is
involved with. One professor may mentor other
professors and a professor may be junior to several
professors that mentor her.
How do you remain agile when
working with ORM diagrams? I prefer to use ORM diagrams
with my stakeholders, modeling around a whiteboard with
them in order to explore the problem domain. Although
the notation is rather complex I’ve found that
stakeholders quickly pick up the basics, particularly
when fact tables are used frequently at the beginning.
Once we understand the issue that we’re exploring with
an ORM diagram I typically capture the information in
another artifact, such as a
UML class diagram or source code, and erase the
diagram once I’m through with it.
This artifact description is excerpted from Chapter 8 of
The Object Primer 3rd Edition: Agile Model Driven
Development with UML 2.
 |
|
This is the book to
read about ORM. I highly recommend this book
to anyone who is interested in becoming skilled at
conceptual modeling. |
 |
|
This is is also a
pretty good book which I highly recommend. |
|
|
|
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. |
|
www.orm.net |
|
This site provides
links to whitepapers, books, and tools which support
ORM. |
 |
|
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. |
I actively work with clients around the world to
improve their information technology (IT) practices as
both a mentor/coach and trainer. A full
description of what I do, and how to contact me, can be
found here.
|
