Nearly everyone in IT knows the old joke about the software project manager who tells his team, “You guys start coding, while I go upstairs and find out what the requirements are.” The joke still seems pretty funny, unfortunately, because we also all know IT shops and individual programmers that continue to think and act exactly this way.

Fortunately, most serious software industry practitioners today know that, even for relatively straightforward programming projects, it is far better and cheaper to invest in at least some kind of formal design process upfront before starting to code. For more complex projects, using formal modeling tools and techniques to develop, capture, manage, and share a clear and concise picture of the underlying software architecture and design early on can be absolutely critical to getting the project done at all, much less on time or budget.

For almost a decade, the advocates of the more rigorous forms of formal software modeling have had a staunch industry ally the Object Management Group (OMG)™. In 1996, the OMG, an international consortium of computer vendors, end users and consultants, adopted the well-known Unified Modeling Language (UML)™. UML has since become far-and-away the dominant standard for software modeling. Today, nearly every software development shop has incorporated some form of UML-style modeling into its development process, and the number of commercially available UML tools has been mushrooming.

Based on the commercial success of UML, the OMG has subsequently developed a number of other broad-based software industry standards around UML, including the Meta Object Facility (MOF)™, used primarily to manage metadata and integrate tools; the Common Warehouse Model (CWM)™, used primarily in data warehousing; and the Enterprise Distributed Object Computing (EDOC) standard, used for the modeling of enterprise computing. The OMG also has begun to develop derivative standards for specific markets real-time, healthcare, financial services, telecom, transportation, manufacturing and the like also based on UML and its derivatives.

As it became clear that a family of UML-based standards was emerging, OMG decided to give that family a name Model Driven Architecture (MDA) which the OMG formally introduced in 2002. Under this new nomenclature, the UML standard itself is now just another member of the MDA family, albeit an important one. The OMG’s goal for MDA is to gradually fill in all areas of the software development and deployment life cycle with an integrated set of model-based standards. Ultimately, this will let end users better control the entire life cycle using best-in-breed commercial tools, platforms and techniques that interoperate through the same model-driven paradigm.

Not surprisingly, a new class of commercial tools has recently begun to emerge, specifically claiming to be based on MDA. Some of these are largely pre-existing UML tools that have recently been spruced up with various extensions to better support MDA, while others are brand-new offerings that have been built with MDA in mind from the start. There are also a number of popular tools with some form of MDA “under the covers,” and a whole new group of MDA-related open source offerings.

Before we begin looking at this new class of products, we need to answer a few questions. What makes MDA different from UML itself? What’s the difference between a “UML tool” and an “MDA tool”? And finally, what does it mean to be “MDA-compliant”? Once we answer those questions, we’ll have enough background to categorize the different kinds of MDA tools currently available, and to speculate a little on the kinds of tools that may be available in the near future.

MDA and UML

From the very start, UML was intended to support virtually any kind of formal software modeling. This approach was successful in that UML quickly became widely adopted and was used to support a variety of modeling. Indeed, as the UML standard has matured, new features have been added to better support important new ways of modeling many of which were never even envisioned by the original UML designers. The latest standard, UML 2.0, allows both vendors and users to go far beyond the limits of earlier versions. In particular, it allows UML to properly support MDA.

All this is clearly in response to rapidly growing market demand. Over the last decade, UML tools and techniques have emerged that support the formal modeling of nearly all aspects of the software life cycle business processes, software architectures, data warehousing, metadata repositories, tool integration and even the software development process itself. Meanwhile, UML domain models have been developed for a seemingly endless variety of vertical and horizontal markets.

But while UML provides a standard language for expressing models of any kind of software, it doesn’t really tell you how or to what model, or what the relationships might be between different models or kinds of models. Once again, this is true to UML’s original intent to be broadly applicable and non-prescriptive. However, this also means that anyone trying to use UML for a specific purpose for example, developing a service-oriented architecture (SOA) or generating platform code from design models for embedded systems has to figure out how to correctly apply UML for themselves, or rely on the proprietary approach of some vendor or consultant.

That’s where MDA comes in. MDA has sometimes been described as UML on steroids, although, as we shall see, it’s really a lot more than that. Taken as a whole, the MDA family of standards is intended to extend UML by providing open specifications that govern how you model and what you model, and in what order. This includes how to best relate different kinds of models or transform one model into another, based on what aspect of the software development life cycle is being modeled.

Furthermore, using some of the new MDA-based features of UML 2.0, UML itself can be readily customized for supporting many different kinds of models. For example, the ability to create UML profiles has been improved, allowing UML to more actively support reusable design patterns. This lets vendors or end users preconfigure their UML 2.0 tools to explicitly support various architectural modeling styles.

As we shall see, other MDA standards now provide support for creating whole new modeling languages, but in a standard way that allows these languages to be readily integrated with each other and with UML tools. For example, some users feel that UML is too complex to effectively support the modeling of business processes directly by business end users. Therefore, MDA supports the creation of Domain Specific Languages that facilitate such modeling without requiring the end user to master all of UML or MDA. Just as importantly, MDA also supports integrating existing modeling languages, such as data modelers and business-process modelers, into the same common language framework. Next, we’ll explain how all these languages can be integrated into a common MDA-based environment.

MDA and Tool Interoperability

Another big improvement of MDA is enhanced support for modeling tool interoperability that is, how different modeling tools can exchange models and work together seamlessly on a related set of models. This is very important because it is unlikely that any one tool or tool vendor will be able to supply the best-in-breed approach for all aspects of a given type of modeling. Therefore, end users will want to be able to buy and use multiple tools and tool add-ons with assurance that these tools can share the model-related information they individually or collectively capture.

Earlier versions of UML did not systematically address tool interoperability. There was simply no standard mechanism that allowed models produced by one UML tool to be transferred to another, much less one that let two or more UML tools actively share the same model. There are still some open issues in this area, but the MDA-based enhancements to UML 2.0 now provide a solid foundation for future universal UML and MDA tool interoperability.

The basis for these improvements is not in UML per se, but rather in UML 2.0’s tight integration with another MDA standard, the OMG’s MOF standard. The MOF is a specialized subset of UML that can be used to define the elements of any modeling language, including UML itself. The resulting model of a given modeling language is referred to as that language’s metamodel.

Given the MOF metamodel of a language such as UML, one can tell precisely how the UML language is constructed. For example, the MOF metamodel for UML precisely defines all the elements of UML, such as Class, Attribute, Operation and Package. Similar metamodels can be developed for any other modeling language, including data-modeling languages, process-modeling languages, and, of course, Domain Specific Languages. These could be brand-new languages defined directly in MOF, or they could be existing languages reverse-engineered into MOF.

But probably nobody would care much about MOF if it were just a way to formalize UML and other modeling languages. Much more importantly, MOF also specifies a standard set of mechanisms for accessing and managing the models that are created using any language described in a MOF metamodel. So, for example, UML 2.0 defines a standard for accessing and managing UML models based on the MOF metamodel for UML.

These MOF mechanisms are generic and can be realized in different ways. Currently, the OMG has standardized mappings to XML, Java, and CORBA®. The mapping XML is called the XML Metadata Interchange (XMI)® standard, and is typically used for bulk transfer of metadata between MOF-compliant tools. Such tools, including those for UML 2.0, now commonly communicate by exchanging streams of XMI conformant XML. The Java and CORBA mappings result in APIs that are useful for exchanging information between tools in a more fine-grained way.

Interestingly, although the MOF standard itself is now one of the linchpins of both MDA and UML, it was not initially developed specifically to support either. The original concepts behind the MOF were even more generic and model-agnostic. That is, they were intended to support the formal definition and management of the many diverse forms of information about systems that is, metadata that result from developing and deploying various kinds of software. This includes everything from business requirements to data models to component models to run-time deployment specifications potentially hundreds of different kinds of metadata.

Now the real value of MOF and its central role in MDA should be clear. Until the MOF was developed, there was no common standard to represent all these different kinds of metadata, much less sharing them across tools. Each vendor’s tools typically managed metadata using unique, proprietary mechanisms, and the poor user had to find a way to manage all these one-off formats. This was a problem for vendors as well, as they struggled to add new tools to existing tool sets, integrate their tools with those of other vendor, or integrate the many different kinds of metadata used in one project. Out of this need, MOF was born.

Even now, MOF has specifically been architected to allow any tool to implement MOF-compliant interchange mappings, even if that tool uses some other modeling language other than UML to represent its models. All that is needed is for the non-UML modeling language itself to be expressed as a MOF-based metamodel, which can be used to automatically generate the correct MOF interface mappings for that language. A utility can then be created to translate between the tool’s native format and the new MOF-compliant mappings.

In this way, the MOF is a kind of “Rosetta Stone” that makes it possible to imagine a very diverse world of MDA tools that can still share common information and become integrated into a common environment. A developer (or tool vendor) can integrate virtually any set of different modeling tools, each doing a discrete set of tasks, but sharing common information through MOF-compliant mappings such as XMI. This allows best-in-breed tool acquisition, and avoids vendor lock-in.

For example, a tool that is great at modeling business processes using a business-friendly Domain Specific Language can be hooked up to a tool that excels at editing UML diagrams, such that they can share common model elements. After a business analyst has specified requirements in a DSL, a software designer then can use the UML tool to edit the shared model elements with additional information pertinent to system design. Subsequently, the edited models can be fed into another tool that generates code from those UML models for various target platforms. Yet other tools could read the same models to generate, for example, test scripts or systems documentation. These examples are just the tip of a tremendous iceberg of tools that can potentially be integrated into an MDA-style environment using MOF-compliant mappings.

MDA and Model Transformations

As our last example suggests, MOF gives us an important foundation for MDA the ability to integrate and then collectively manage all different kinds of models, and, by extension, the exchange of those models among tools. But as that example also suggests, MDA is about more than just managing models and exchanging them across tools. It’s about actually using those models and tools in an orderly and standardized way to get something done.

A classic example of this is the MDA approach to generating code from models. For many years, there have been proprietary tool sets that allowed analysts to model various aspects of a system and generate some or all of the code. The main problem with these products was that they were non-standard and therefore closed and inflexible. A whole industry CASE [computer-aided software engineering] eventually imploded, largely because no single vendor could cost-effectively supply the whole solution, and vendors could not get their highly proprietary tools to collaborate with one another. MDA is already being used extensively to support a new generation of CASE-like code-generating tools, and, as the standards mature, gradually breaking down the proprietary bottleneck that was characteristic of earlier CASE tools.

How does this work? First, MDA breaks the modeling activity down into three distinct model-driven steps. In the first step, a business analyst develops a Computationally Independent Model (CIM), which represents the application’s pure functional business logic without considering any computer-related aspects. The CIM is then transformed by a systems architect into a Platform Independent Model (PIM), which provides a generic computing architecture (for example, an SOA), but no platform specifics. Finally a systems analyst transforms the PIM into a Platform Specific Model (PSM), which includes all the information needed to describe a deployable software system. Code and other development artifacts can then be derived directly from the PSM.

We should note that the CIM-PIM-PSM pattern we’ve just described is not intended to be linear, but iterative. As we will discuss, the transformations from model to model are formalized and therefore traceable. MDA tools therefore can be used to automate or support the development and transformation of each model as needed, and to keep them in sync, similar to the way that many Interactive Development Environments (IDE) today keep models and code in. However, if they follow the MDA standards, these tools will need not be from the same vendor, or even use the same modeling language for example, the CIM may be expressed using business modeling language (for example, Business Process Execution Language), while the PIM and PSM may be expressed in two different UML profiles.

MDA goes even further by standardizing the transformation process itself. The main initiative in this direction is a new OMG standard called Query/View/Transformation (QVT) that is currently under development. QVT will standardize how all model transformations are specified. In true MDA style, each such transformation will be formally modeled in terms of a standard QVT metamodel. So, for example, a given transformation, say from PIM to PSM, could itself be captured in a QVT-compliant transformation model, and potentially executed by any QVT-compliant transformation engine with an appropriate plug-in. So the PIM model, the PSM model, and the PIM-to-PSM transformation model would all be based on formal MDA standards.

When QVT is universally available, the big advantage for end users and tool vendors alike is that a transformation tool based on a QVT-compliant model will be far more adaptable than any proprietary tool. That is, the transformation rules for a given tool can be changed or extended, and exchanged among different QVT-compliant tools. This is done simply by editing and exchanging the associated QVT models rather than reprogramming the tools themselves. For example, if you don’t like how a given tool generates a PSM, you can simply change its PIM-to-PSM transformation model, which will be expressed in industry-standard QVT.

Standardization of the CIM-PIM-PSM pattern is a key target for QVT, but by no means the only one. QVT is intended to be equally applicable to any other useful transformation pattern. A number of vendors in the OMG are working on standards for extracting information from legacy systems and using these to build an integration platform. This process requires the standardization of a variety of different kinds of models (and associated MOF metamodels) that will have their own set of transformations. Once these transformations have been defined in QVT, it should be possible to execute them on any QVT-compliant transformation engine.

What is an MDA Tool?

Before we answer this question, we need to note that currently there is no official certification process, from the OMG or elsewhere, for determining whether a tool is MDA-compliant. Moreover, there isn’t likely to be one anytime soon, although we can probably expect some compliance tests to be forthcoming soon for specific standards that are already pretty stable, such as MOF. Otherwise, many of the MDA standards are still new or, like QVT, still in development. So until a larger core of these standards is more complete and stable, it simply won’t make sense for anyone to invest the resources necessary to develop or administer any kind of broad-ranging MDA compliance test.

Does this mean that there is yet no such thing as a true MDA tool? Certainly not! There might be some vendors who may bend the notion of MDA-ness to suit their needs. At the same time, there will be other vendors who are truly trying to keep up with new MDA developments, but may at any given time be one or two steps behind or even ahead of the current standards. Nevertheless, based on the discussion above, we can apply a few rules of thumb, based on core MDA principles, to tell us whether a tool that claims to implement MDA really does. Here are some rules:

• Implements MOF-compliant mappings for import/export. As we’ve just noted, probably the most fundamental characteristic of an MDA tool is that it has some way of taking input and/or generating output using MOF-compliant mappings. This may not by itself be sufficient to integrate it with other MDA tools, but it is certainly a prerequisite.
• Uses MOF/XMI internally. Many MDA products are themselves just frameworks of related tools that communicate with each other through MOF-compliant mappings, sharing some kind of a common repository. If this is so, it should be much easier to integrate new tools into such a framework, or to integrate any or all of the framework with other MDA tools and frameworks, even those from different vendors and those that use different modeling languages.
• Implements some form of QVT. There’s no final QVT standard yet, but the best MDA products will anticipate the standard by exposing their transformations as editable models of some kind. Products that do should also allow the creation and integration of custom transformations in form of plug-ins to a transformation engine.
• Follows other MDA standards (or emerging standards) as appropriate. The most obvious case is UML tools, which should follow UML 2.0. Some products focused on component-based enterprise computing market also may implement EDOC. Other products may already be supporting emerging MDA standards (see http://www.omg.org/schedule for all OMG standards currently in process).

The Current MDA Tool Market

Since its introduction, interest in MDA has been growing rapidly. This is partly because MDA systematically builds on earlier widely accepted computing technology standards such as UML, XML, Java and CORBA. Therefore, MDA has already received strong endorsements from major systems and software vendors such as IBM, HP, Borland and Sun, which have begun to use MDA to expand their previous commitments to UML-based modeling and XML-based messaging. At the same time, a significant number of smaller vendors have already bet the company on MDA as the backbone for a variety of new products.

A list of vendors whose products currently support MDA explicitly can be found in the accompanying Buyers Guide. For convenience, we have classified the vendors listed in the Buyers Guide into the following focus areas:

Please note that these focus areas are not mutually exclusive many tools support several in some form. Also, these categories are certainly not exhaustive new applications of MDA are being introduced all the time. Indeed, some of the tools listed already support libraries of models, plug-ins, and add-ons for specific industries or technologies. We also should note that a number of open source tools supporting various aspects of MDA have been introduced, which are not covered in the Buyers Guide.

Finally, it may surprise some end users to find out that they are already getting substantial benefit from MDA without even knowing it simply because MDA technology may be embedded in their favorite development and deployment tools. For example, users of Eclipse, the popular open source IDE originally developed by IBM, might not realize that it sits on top of MOF-based metadata management framework called EMF (Eclipse Modeling Framework). EMF supports the exchange of information among Eclipse’s various tools using a version of MDA’s XMI/XML message format. As a result of EMF, new tools can be integrated into the Eclipse framework seamlessly, which provides a real boon for both tool providers and end users.

Getting Started

Most end users will probably get their first experience with using MDA tools through features that are being added to their favorite existing IDEs and/or UML modeling tools. Some may also experiment by downloading one or more Open Source MDA tools, or demo versions of commercial MDA products. Playing around with these tools will certainly help techies get a better understanding of some of the benefits MDA can add to their current development work.

At some point, however, many organizations may want to go further with MDA. They will figure out the best way to use MDA in their organizations, and then use this understanding to select and standardize on an MDA tool set. To help organizations begin the process of adopting MDA and selecting the best-fitting MDA tool set, the OMG has created a special MDA FastStart Program (www.omg.org/faststart).

The FastStart Program has developed a formalized approach to helping organizations get started with MDA. The program also maintains a list of Qualified Service Providers (QSP), who are OMG members offering expert professional services to help end-user organizations get started in MDA and MDA tools. End users who want such help can use the MDA FastStart Program’s convenient referral service to help them find the QSP best for them.

Different FastStart QSPs focus on different MDA target audiences. For example, some are themselves MDA tool vendors that provide a FastStart service offering specifically geared to their particular tool set. Other QSPs have a team of MDA generalists who offer consulting and training that can be adapted to many different applications and tool sets. Still other QSPs focus on applying MDA to specific vertical markets, such as government, defense and financial services, or to specialized technologies, such as embedded systems, real-time systems, or systems integration. Usually these QSPs are experts in adapting MDA to the existing tool sets and best practices in those markets.

With these differences in mind, all QSPs still have the same basic goals to rapidly familiarize an end-user’s IT and business professionals with MDA concepts and to start integrating the MDA approach into mission-critical software development activities as soon as possible. All QSPs are familiar with the process of customizing their tools, processes and professional services to the specific needs of different customers.

During a FastStart engagement, highly qualified MDA consultants and trainers provide an integrated set of assessment, planning, executive seminar and technical practicum activities targeted to both top executives and technical staff. The key goals of a typical FastStart engagement are to:

• Clearly analyze and plan how MDA can best be introduced and applied to gain the most benefit for the organization in the context of its key business drivers.
• Develop a plan for integrating MDA tools and techniques into the organization’s current software development and deployment environment.
• Decisively demonstrate, in a real project, how MDA can provide clear-cut business value sufficient to justify ongoing investment in MDA-related activities.
• Through training and mentoring, support the organization’s MDA-related development efforts until the organization reaches self-sufficiency in MDA.

Michael Guttman is an independent IT consultant and director of the OMG’s FastStart program. Over his career, Guttman has completed dozens of major projects in areas of business and IT strategy and enterprise architecture. He is the author of Developing E-Business Systems and Architectures: A Managers’ Guide. He can be reached at guttman@omg.org.