 |
For the sake of simplicity, there are three different
categories of approaches for applying AMDD on projects:
- Manual Modeling
- Agile CASE
- Agile MDA
To bring a bit of reality to the modeling conversation,
something that has been sorely missed the past few decades, I've gathered some
real-world statistics around modeling and
documentation strategies. |
|
- Overviewed in Figure 1
-
Simple tools and
inclusive models are used for modeling
- "The code is the design" philosophy is prevalent
-
Documents are still created, but the team is
likely to travel very lightly
- Drawing tools such as Visio may be used to
create "clean" diagrams, although digital photos of
whiteboard sketches are also common
- This approach is basically what the Extreme
Programming (XP) community follows
- For years I suspected that this represents the approach
taken by 70-80% of all development teams, and as you
can see in Figure 4 this
appears to be true (the light blue and dark blue
colours represent this strategy)
Figure 1. Manual AMDD.

- Figure 2 overviews this
approach
-
Inclusive models are used to explore
requirements with stakeholders, and to analyze those
requirements
- Sophisticated modeling tools are used for
detailed design
- Tool integration/interfacing may not be very
good -- object developers may use tools such as
OptimalJ or TogetherCC when creating their object
schemas whereas Agile DBAs may use tools such as
Erwin or Oracle Designer to developer their data
schemas.
- The modeling tools should support "round-trip
engineering" with the code -- developers should be
able to model or write code and have the
corresponding code/models updated automatically.
- This approach can be taken by any type of agile
team, including
XP teams.
- This approach is common for
Feature Driven
Development (FDD) teams.
- Ideally the modeling tool should work with your
unit testing tool(s) so that detailed design
information can be captured as
executable specifications.
-
Documents are still created, the team should
still travel lightly, although more documentation is
likely to be written because the tool "makes it
easy" to do so. This may not be a good thing,
so be careful and ensure you can justify every
document that you create.
-
For years
I suspected that this represents what 20% of all
development teams do, but as
Figure 4 shows this guess was a bit high
(although not too far off)
|
 |
Figure 2. AMDD with a
sophisticated design tool.

- Figure 3 overviews this
approach
- Sophisticated, MDA-based modeling tools used to
create extensive models from which the working
software is generated
-
Inclusive models are used to explore
requirements with stakeholders, and to analyze those
requirements
- The inclusive models must be translated into
PIMs by the agile modeler
- This approach is described in detail in
Roadmap to Agile MDA
- At best, I suspect we'll see roughly 5% of
development teams achieve this vision, and frankly
I'm being very generous with this estimate (Figure
4 appears to bear this out).
And it'll mostly be embedded/real-time developers,
not business developers.
|
 |
Figure 3. An AMDD approach to MDA.

The
DDJ 2008
Modeling
and
Documentation
survey
explored
how
people
approach
modeling
and
documentation.
Figure
4
summarizes
the
results
of the
question
that
looked
into the
primary
approach
to
modeling,
and
regardless
of
development
paradigm
sketching
was the
most
common
approach
to
modeling
(SBMT =
Software
Based
Modeling
Tool, my
term for
CASE).
Figure
4.
Primary
approaches
to
modeling.

I
invite
the
research
community
to do
some
ethnographic
research
into the
issues
surrounding
how
development
teams
model in
practice
so that
we can
get
solid
figures
around
the
issues
that I
explored
in the
DDJ
survey.
I'd
really
like to
put an
end to
the
incredibly
naive
modeling
strategies
that the
modeling
theory
wonks
keep
trying
to foist
on us.
 |
|
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.


|