Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Design

A Road Map to Agile MDA


For the past six months, I’ve harshly criticized the Object Management Group’s Model-Driven Architecture (MDA) vision (www.omg.org/mda). I haven’t been alone: At OOPSLA 2003, Dave Thomas of Pragmatic Programming fame virtually flayed MDA alive, and even Microsoft has questioned MDA’s underpinnings. Why the criticisms? We’ve seen similar visions fail miserably in the past. Also, many correctly believe that MDA could take IT organizations seriously off track if they don’t navigate the software process waters effectively. Until now, I’ve complained loudly about MDA; now I present a viable, albeit challenging, vision for making it work.

From Generic to Specific

MDA separates the specification of system functionality from the specification of its implementation. To do this, MDA defines two categories of models: Platform Independent Models (PIMs) and Platform Specific Models (PSMs). As the name implies, PIMs don’t take technology-specific considerations into account, a concept that’s equivalent to logical models from the structured methodologies of the 1970s and to essential models within modern usage-centered techniques. PSMs bring technology issues into account and should be transformations of PIMs that reflect platform-specific considerations.

There’s far more to MDA than just PIMs and PSMs—it defines guidelines for automated transformation between these models based on metadata-defined mappings. Basically, you should be able to define the business requirements and your analysis of those requirements within a PIM, select the target platform(s) for your system and then automatically translate the PIM into one or more PSMs. Necessary details are added to the PSMs, which are then translated into source code. Ideally, 100 percent of the code would be generated; realistically, you still must write some complex logic that the tools can’t model fully—most modeling tool vendors claim that they’ll generate around 80–90 percent of the code.

The transformations are bidirectional—changes to your code should be captured within the PSMs, and any business-related changes in the PSMs translated back into the PIMs. These “reverse” transformations allow you to work on any artifact at any time.

If realized, MDA promises to increase developer productivity dramatically—but I have several reservations. Here’s my vision for agile MDA.

How to Take an Agile Approach


[click for larger image]

An Agile MDA Overview
Simple diagrams, tests and iterative development are key to making MDA work.

First, you must extend MDA to include modeling activities with your stakeholders. Agile modelers insist on active stakeholder participation—stakeholders should be available to provide information, make decisions and even model the business requirements. To do this, developers need to adopt inclusive modeling tools and techniques: simple tools such as whiteboards and paper that are easy to use, and simple modeling techniques such as essential user interface models and class responsibility collaborator (CRC) cards, which stakeholders can easily grasp. We learned the hard way in the 1980s that stakeholders neither understand complex diagrams nor want to take the time to learn them. This suggests that the models typically supported by MDA-based tools will hinder communication with stakeholders rather than foster it. In the 1980s, we also learned that stakeholders can be active participants in modeling if developers are willing to use inclusive tools: Therefore, you need to extend your MDA modeling efforts with inclusive modeling techniques if you want to be agile. The simple nature of inclusive models often requires agile modelers to manually translate them into their modeling tools; you may be sketching at a whiteboard with stakeholders one minute and then sitting at your workstation translating the information into your CASE tool the next.

Second, the creation of working software is crucial, as it’s the primary goal of software development. Furthermore, agile modelers take a highly evolutionary approach, delivering working software on a regular basis, and with MDA, you’ll generate it from your models. The secret is to model in small increments; don’t try to create the all-encompassing PIM and then generate the all-encompassing PSM. I’d be worried if I modeled for several hours without producing working software, let alone several days or even weeks. Tighten the feedback loop to increase your effectiveness. Agile modelers will focus on a few requirements, generate the PSM for those requirements, and then create the software that fulfills those requirements. The goal is to validate the models with code and obtain feedback from stakeholders as quickly as possible. Never forget that your stakeholders are primarily interested in a system that meets their needs.

Third, you’ll need several models to get the job done. Although the diagram on page 52 indicates a wide range of available models, only a subset may be required. Your modeling tools must support an effective combination so that you can apply the right artifacts for the situation. PIMs and PSMs require sophisticated modeling tools, and luckily, a few such as Bridgepoint, TogetherCC and OptimalJ are available. A good tool is a start, but without skilled developers, it will quickly become shelfware.

Fourth, you must continually test—this is why tests are included in the diagram as potential modeling artifacts. Tests become critical models for you: Acceptance tests capture the fundamental requirements to which your system must conform, and technically oriented tests (unit, system and so on) validate your software’s “innards.” I firmly believe MDA tools must include extensive support for testing.

Fifth, accept the fact that you’ll still need to write some source code. The diagram indicates that you’ll need some form of action language in your PIMs and programming source code in your PSMs to implement functionality not generated by the MDA tools.

Is MDA For You?

For MDA to work in your firm, you must answer yes to each of these questions:

  1. Do you currently have on staff highly skilled modelers or people who could become so; if not, can you hire some?
  2. Can you retain these highly skilled modelers once you have them?
  3. Are your stakeholders sophisticated enough to actively participate in the creation of inclusive models—or can they understand the PIMs that you create?
  4. Can you find a modeling toolset that fulfills your actual needs?
  5. Are you willing to tie your fortunes to that of the tool vendor?

I’m still leery when it comes to MDA, although I recognize that a small number of organizations will be able to succeed with it. Stay agile by actively collaborating with your stakeholders, creating working software on a regular basis, integrating testing into your modeling efforts, and adopting tools that support these concepts. It won’t be easy to succeed with MDA.

My Concerns
Issues you’ll face—even if you take an agile approach.

Recently, in my Agile Modeling newsletter, I expressed several frustrations with MDA that you’ll need to overcome regardless of how agile an approach you take. These concerns are:

  1. MDA requires a significant level of modeling expertise.
  2. It isn’t clear that tool vendors will support the XML Metadata Interchange (XMI) standard for model sharing—experiences with CORBA have shown that vendors are willing to claim support for standards, but in practice may implement unique and incompatible versions.
  3. Many modeling tool vendors focus only on UML, yet you clearly need to go beyond it to adequately model systems.
  4. It isn’t clear how MDA models will be tested.
  5. It’s difficult to model the inherent complexities of legacy systems, yet integration is a critical aspect of most systems. Minimally, you’ll need to model and test the interfaces (Web services, C-APIs, shared data files) to these systems.
  6. Most developers prefer text-based and not visual approaches to modeling—perhaps a focus on UML won’t lead to success.
  7. Only a minority of developers seem to be clamoring for MDA tools.
  8. We need a sophisticated approach to configuration management of models, yet the existing tools don’t seem to reflect this.

—SA

Further Reading

If you’re interested in learning more about MDA, start with MDA Distilled by Steve Mellor, Kendall Scott, Axel Uhl and Dirk Weise (Addison-Wesley, 2004) or Model Driven Architecture by Dave Frankel (OMG Press, 2003). For more thoughts about agile MDA, read Steve Mellor’s paper. A more detailed discussion of my ideas is posted at here.


Scott Ambler is a senior consultant with Ronin International Inc. His latest book is Agile Database Techniques from Wiley Publishing.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.