I've been pretty harsh with respect to the Model
Driven Architecture (MDA) in previous writings. I
question the viability of the MDA for most
organizations, although respect the fact that many
people are still going to attempt it within their
organization. This begs the question "how do you
take an agile approach to the MDA?"
Figure 1 summarizes what I
believe to be a realistic "agile MDA" approach
which applies the concepts of
Agile Model Driven Development (AMDD) to the MDA. It's
important to note that you need to look beyond MDA-based
modeling tools to make MDA work.
Figure 1 depicts one of three
AMDD approaches, the most complex one in this case.
Figure 1. An AMDD
approach to MDA.
Below are some
point-form thoughts which I will flesh out in the coming
Critical Success Factors:
- You should apply the
practices of Agile Modeling (AM)
- The primary goal is to produce working software
which meets the needs of your stakeholders otherwise
you're not really doing MDA.
- Active stakeholder participation is crucial to
your success, so you need to find ways to work with
your stakeholders effectively (see below).
- Testing is a critical issue throughout the
entire development effort.
should be included in your PIMs and
technically-oriented tests in your PSMs.
- Take an evolutionary (iterative and incremental)
approach. Serial/traditional MDA isn't a very
good option as the focus is often on the
models/documents and not on the working software.
- Developers need to learn fairly sophisticated
skills. People/communication skills are
critical, luckily agile developers are focused on
these skills, but so are modeling skills (which few
developers seem to focus on).
- You'll need a wide range of model to make this
work. Figure 2 maps the
MDA model types to various modeling artifacts.
You don't need to create all of these artifacts, but
you will need some.
Figure 2. Artifacts for Agile MDA.
Working with stakeholders:
Thoughts about UML & MDA:
- If you want to do the full tool-based MDA thing,
you should use the
inclusive techniqiues to gather
info then capture the information in your tools.
Not ideal, but at least you have a bridge to your
- The MDA seems to be missing the concept of
- The transformation between inclusive models and
PIMs is manual, requiring skill on the part of the
- The PIMs and PSMs require a sophisticated
modeling tool, few are out there. Bridgepoint,
TogetherCC, and OptimalJ are leading candidates.
- The UML models seem to be oriented towards PSMs,
not PIMs (hence you need to extend the UML to really
support MDA, something we see the tool vendors do
all the time).
- You'll likely need to go beyond UML even if you
do take a visual approach.
- Figure 3 maps the
model categories to various modeling artifacts,
indicating which techniques are inclusive, which are
complex, and which are "in between".
We need to extend the UML beyond object and
Thoughts about Tools:
- I prefer to use simple tools for "up front"
requirements/analysis activities, more complicated
tools (e.g. CASE) for design.
- For MDA to work, PIMs (the up front models) need
to be captured in the tool.
- You'll still need to code, either in a
high-level action language from which program code
is generated, or program code itself. Depends
on your tool choices. Pick the approach that
works best for you.
- Many tools seem to claim to be MDA, few really
seem to achieve this goal.
- There is far more to succeeding at the MDA than
- It's doubtful that the tools will work together
effectively, integration through XMI will fail in
practice, so pick your poison and move forward.
- MDA is still going to be hard -- you need the
modeling skills, you'll become tied to your tool
vendor, and so on (see the
list of challenges).
- Most developers prefer text-based, not visual,
approaches to "modeling" in my experience.
This makes me question a diagram-based approach for many
Figure 3. Techniques for each
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
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
(TDD). The Object Primer also includes a
chapter overviewing the critical database
development techniques (database refactoring,
legacy analysis, and
database access coding) from my award-winning
Agile Database Techniques
Agile Modeling: Effective Practices for Extreme
Programming and the Unified Process is the seminal
book describing how agile software developers approach
documentation. It describes principles and
practices which you can tailor into your existing
software process, such as
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
architect, and then
design your system in an agile manner.
The Elements of UML 2.0 Style describes a collection
of standards, conventions, and
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.