 |
For the sake of simplicity, there are three different
categories of approaches for applying AMDD on projects:
|
|
- 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
- I suspect that this represents the approach
taken by 70-80% of all development teams
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.
-
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.
-
I suspect that this represents what 20% of all
development teams do
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.
And it'll mostly be embedded/real-time developers,
not business developers.
Figure 3. An AMDD approach to MDA.

 |
|
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. |
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.
|