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.

1. Manual AMDD

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

2. Agile CASE

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.

3. Agile MDA

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.

4. Real-World Statistics

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.

Recommended Resources

		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.

Let Us Help

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.