 |
Because XP has reached buzz word
status within the IT community, whatever that means,
many people are now asking two typical questions “Can
you use buzzword1 with buzzword2?” and if yes then
“How do you use buzzword1 and buzzword2?” together.
Hence, we’re starting to see people asking about
using XP with web services, CORBA,
Enterprise JavaBeans
(EJB),
.NET, Linux, open source software (OSS), and of course
the
Unified Modeling Language (UML).
The relationship that I want to explore is that
between XP and UML, so let’s ask the two typical
questions: |
|
-
Can you use UML with XP? Yes. You can
apply the artifacts of the UML – activity
diagrams, class diagrams, collaboration diagrams,
component diagrams, deployment diagrams, sequence
diagrams, statechart diagrams, and use case diagrams
– when you are taking an XP approach to
development.
-
How do you use UML with XP? Minimally you should apply AM’s practice of
Apply the
Right Artifact(s) and use UML artifacts on your
XP project only where appropriate.
Ideally you should apply all of the
principles and practices of AM when doing so.
Wait a minute.
One of AM’s principles is
Multiple Models,
which tells you that you need to have modeling skills
pertaining to a wide variety of artifacts within your
intellectual toolkit.
Yes, the artifacts of the UML are a good start
but unfortunately not enough: As I argue in the article Be
Realistic About the UML the UML is not sufficient
for the real-world needs of business application
developers, although luckily the article Artifacts
for Agile Modeling: The UML and Beyond shows we have far more than the
artifacts of the UML at our disposal.
Seems to me that we have a problem here.
If the UML is not sufficient for the development
of business applications, and if you trying to develop
such an application following the XP methodology, then
perhaps “How do you use UML with XP?” is the wrong
question to be asking.
One of the problems with the buzzword approach to
software development is that when you limit your
vocabulary to buzzwords you correspondingly limit your
solution space to whatever can be described by those
buzzwords.
Therefore, I believe that two more questions need to be
added to the buzzword approach: “Is using buzzword1 with
buzzword2 the right question to be asking?” and if not
“What is the right question?” When you ask these
questions about XP and UML you quickly realize that the
right question to be asking is more along the lines of
“How do you model effectively on an XP project?” This is
a question addressed by AM, and in particular the
article Agile
Modeling (AM) and eXtreme Programming (XP).
Another interesting question to is
is whether all of the UML artifacts are appropriate for
an XP project. I suspect not.
User stories are an important part of XP - user stories
form the foundation of the requirements for your system,
they are a primary input into your
project planning
efforts (referred to as The Planning Game), they are the
primary artifact used to define what your team will be
working on in a given construction iteration, and they
are used to drive the development of your acceptance
test cases. The UML does not include user stories
but instead describes an artifact called a
Use Case
Diagram that depicts the interrelationships between
actors that interact with the system and use cases which
describe usage-based requirements for your system.
As I argue in the article Artifacts
for Agile Modeling: The UML and Beyond use cases
and user stories are alternatives
to each other, if you
are using one you very likely won't be using another.
The implication is that because user stories are an
integral part of XP you clearly will not want to apply
use cases on your project, hence you will not need to
create UML use case diagrams. Once again, remember
to follow the AM practice
Apply the
Right Artifact(s).
| Another interesting buzzword
combination to consider is how do you use the
Model Driven Architecture (MDA) approach with XP? The
MDA is part of the Object Management Group (OMG)'s
vision to support interoperability with specifications,
defining the relationships among OMG standards (such as
the UML and CORBA) and how they can be used together in
a coordinated manner. The MDA defines an approach
to system specification that distinguishes between
platform independent models (PIMs) that specify the
system in a manner that abstracts away technical
details, models that are in turn realized by platform
specific models (PSMs) that take into account technical
considerations. The MDA also distinguishes between
formal models and informal models. Formal models
are based on a language, such as the UML, that has a
well-defined syntax and semantics and possibly a defined
way to show the validity of its constructs such as rules
of analysis, inference, or proof. Informal models,
as you would expect, do not have a sufficient definition
behind them. The MDA
requires the use of formal models and not informal ones
because of its focus on
specifying the interoperability between systems.
In short, the MDA defines a set of guidelines for
structuring system specifications expressed as formal
models. |
 |
Now to my question "Can XP and the MDA be used
together?" Following the strict definition of
the MDA, the answer would have to be no. Models
such as
Class Responsibility Collaborator (CRC) cards and user stories are an integral
part of the XP development process and because they are
not formerly defined that academically disallows the use
of MDA and XP. Practically, however, the answer
may in fact be yes. The MDA is being used by CASE
tool companies as a conceptual framework from which they
are borrowing ideas, frankly the idea of having platform
independent and platform specific models has been around
for decades, and conceivably it will be common to see
MDA-compliant tools just as well see UML-compliant tools
today. Just like UML-compliancy is in the eye of
the beholder, every CASE tool has its idiosyncratic
implementation of the UML, we will also see the same
thing with the MDA. Because an XP team is free to
adopt any tool that it wishes, granted that it should be
a tool that improves the productivity of the people
using it, an XP team could in fact work with an
MDA-compliant tool if the situation warrants it.
Of course that MDA-compliant tool would need to automate
user stories and CRC cards in such a way as to not lose
the benefits that these artifacts currently provide,
many of which are derived from the fact that these
artifacts are created using simple tools such as index
cards, leading me to suspect that in practice the answer
will likely still prove to be no.
 |
|
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. |
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.
 
|
