Welcome to Software Development magazine's Agile Modeling newsletter. This monthly e-mail newsletter is a free service for Software Development and SD Online subscribers. If you do not wish to get this newsletter, please follow the unsubscribe directions at the bottom of this message.
>>Approaches to Agile Model-Driven Development
Three flavors of AMDD will serve your project well.
The thing most misunderstood about Agile Model-Driven Development (AMDD) is the various ways in which it can be applied on a project. One of Agile Modeling (AM)'s principles is Local Adaptation, adopted from Extreme Programming (XP), which demands that you tailor AM to meet the needs of your environment. Some project teams have a light hand in modeling, whereas others are more modeling-intensive -- you can take an AMDD approach in both of these extremes as well as a more moderate approach. In this newsletter, I'll examine all three approaches: The light, manual approach that uses simple modeling tools; the middle-ground approach that uses computer-aided system engineering (CASE) tools for design modeling and code generation; and the more complex approach using Model-Driven Architecture (MDA)-based modeling tools that I'll refer to as Agile MDA.
The three approaches share common themes. First, they take a highly iterative and incremental approach to software development. Second, they focus on developing working software, not on the creation of documentation (documentation is still important; just not a primary focus). Third, all three approaches include the use of inclusive modeling to enable active stakeholder participation. Inclusive models use simple tools (whiteboards, paper and so on) and simple techniques (essential user interfaces, user stories, CRC cards and so on) that stakeholders can easily learn and use to help capture and analyze requirements for your system.
With the manual approach, simple tools are used for all modeling efforts, although when needed, drawing tools such as Visio or CorelDraw may be used to create "clean" diagrams for official documentation. Yes, documentation is still written, but the team is likely to travel lightly and create only high-value, agile documents. Digital photos of whiteboard sketches or even just handwritten notes are often used as official documentation. The philosophy that guides this approach is simple: The code is the design. The manual AMDD approach is common in the XP community, although some XPers also use design-level CASE tools as appropriate.
With the design CASE tool approach, software-based modeling tools are used for detailed design. Object developers may use tools such as Compuware's OptimalJ or Borland's TogetherCC when creating their object schemas, whereas Agile DBAs may use tools such as Computer Associates' Erwin or Oracle Designer to develop their data schemas. A critical feature of these tools is support for "round-trip engineering" -- developers should be able to model or write code, and have the corresponding code/models updated automatically. Documentation is written by teams taking this approach and is often generated by the tool. Documentation generation has its advantages and disadvantages -- although it provides an easy way to supply the mound of documentation to keep the paper-pushers happy, it can also motivate you to over-model just to generate better documentation. As always, be sure you can justify every document that you create. This approach can be taken by any agile project and is common in Feature-Driven Development (FDD) teams.
With an Agile MDA approach, you use sophisticated, MDA-based modeling tools to create extensive models from which working software is generated. Inclusive models are still used to explore and analyze requirements with stakeholders, although these must be translated into a platform-independent model (PIM) to get the requirements into your tool. The modeling tool(s) translate the PIM into platform-specific models (PSMs), which capture technology-dependent information. The developer will also need to write code, as needed, to address functionality not generated via translation from the PIM. Critical system documentation is captured in the PIM and PSMs; other documents, such as user manuals and support information, are likely to be captured externally. My June 2004 column (The Agile Edge, "A Road Map to Agile MDA") describes this approach in detail.
Among the three AMDD approaches, you'll need to choose the one that best meets your situation. When it comes to business application development, gut feel tells me that 60-75 percent of all projects work well with a manual approach, 20-30 percent with a design CASE tool approach, and perhaps 1-5 percent with an Agile MDA approach. Over time, we may see a shift away from the design CASE tool approach in favor of an Agile MDA approach, but I expect that to be a slow transition.
>>RECENTLY ON THE AM MAILING LIST
Freedom
The Freedom methodology has recently been touted on several agile forums
to be a modeling-rich agile approach to software development. I invited one
of Freedom's principal authors to share the methodology on the AM list so
that we may debate its merits. The discussion has been lively and interesting,
and will probably continue for some time.
Tests as User Requirements
One poster questioned the philosophy that tests should be considered user
requirements. There was some confusion in the original post; he seemed to
think that people were promoting the idea of unit tests as requirements, so
the discussion quickly explored the idea that user acceptance tests should
be considered requirements because they define criteria against which the
system is validated. Unit tests, on the other hand, should probably be
considered detailed design artifacts.
Mailing List Changeover
When the folks at Topica.com started inserting advertising at both the top
and the bottom of mailing list postings (previously advertisements were
inserted at the bottom of the postings), I decided to move the list to Yahoo
Groups. The mailing list is now [email protected]
I apologize for an inconvenience this may have caused list members.
>>HOT LINKS
If you want to look at overview diagrams for the approaches discussed
in this newsletter, visit
http://www.agilemodeling.com/essays/amddApproaches.htm
The Agile Alliance homepage is the best starting point for anyone
interested in learning more about agile software development.
http://www.agilealliance.org
With Agile Model-Driven Development (AMDD), you create models
that are just barely good enough to drive your implementation efforts.
http://www.agilemodeling.com/essays/amdd.htm
Check out the Agile Modeling mailing list at
http://www.agilemodeling.com/feedback.htm
Get agile modeling training resources at
http://www.agilemodeling.com/training.htm
Check out the official MDA spec at the OMG's site:
ftp://ftp.omg.org/pub/docs/ormsc/01-07-01.pdf
For a hard look at the MDA, as well as links to critical MDA overview
pages, visit my "Examining the MDA" page at
http://www.agilemodeling.com/essays/mda.htm
Steve Mellor's discussion of Agile MDA is worth considering. Find it at
http://www.omg.org/mda/mda_files/Agile_MDA.pdf
Find the Freedom methodology home page at
http://www.jreality.com/freedom/
For a discussion of why simple modeling tools are important, read my
"Use The Simplest Tools" essay at
http://www.agilemodeling.com/essays/simpleTools.htm
It's possible to take an agile approach to documentation; read
"Agile Documentation" at
http://www.agilemodeling.com/essays/agileDocumentation.htm
For tips on software modeling on whiteboards, read the essay posted at
http://www.agilemodeling.com/essays/whiteBoardModeling.htm
