It is no exaggeration to say that MDA has the potential to revolutionise the way we create and maintain software. Since MDA is becoming so popular, it is important to understand clearly what it is -- and what it is not.

The Essence of MDA
Why do we need MDA? To achieve greater productivity in creating new software. As Figure 1 illustrates, the rate at which we produce software lags the power of hardware by several orders of magnitude.

There are several reasons for this. First, software applications are being written for more and more problem domains, ranging from banking to defence. They are also becoming far more complex. Second, the complexity of software technology itself is exploding, and developers have to grapple with HTML, XML, WML, multi-tier architectures, J2SE, J2EE, J2ME, .NET, components and object models, connectors, message brokers and so on.

Figure 1: The Productivity Challenge
According to the OMG, MDA exhibits the following characteristics:

• Portability
• Cross-platform interoperability
• Platform independence
• Domain specificity
• Productivity

The first three of these qualities help developers cut loose from the shackles of specific computing platforms, such as CORBA, J2EE or .NET. In MDA, the development process starts with the construction of a platform-independent model (PIM) that consists of pure business logic and data definitions. This is gradually refined and transformed into a platform-specific model (PSM) tailored for a middleware "platform" such as CORBA, J2EE or .NET. Finally, the PSM is used to generate source code for one or more applications. In theory, any number of PSMs can be created from the same PIM.

The qualities of portability, interoperability, and platform independence lead to the fourth quality, domain specificity - the ability to focus on solving particular business problems. It could mean designing the best processes and data structures for running a bank or insurance company, or working out the optimum structure for a military command and control system. In either case -- or thousands of others -- there is no need to worry about how these solutions should be coded, or how they will run on a specific platform. That set of worries is deferred till later; although, as we shall see, it can also be greatly reduced.
This is all very well, but what about the fifth quality - productivity? It turns out that almost every aspect of MDA is calculated to boost productivity.

Figure 2: MDA (source: OMG)

In view of the costs involved, no new software technology is adopted unless it can demonstrate obvious benefits at the business level. OMG lists the following benefits of MDA:

• Reduced cost
• Reduced development time
• Improved application quality
• Increased return on investment
• Rapid inclusion of emerging technologies

Reduced development time means reduced cost (other things being equal); and that spells increased ROI. MDA promises better application quality because business logic and data structures are designed once and once only, avoiding inconsistency and errors. Last, but not least, platform independence means that there is no need to worry about becoming locked into specific platforms. Whenever any useful new technique appears, MDA ensures that existing applications will be able to take advantage of it with minimum disruption and delay.

It should be clear from this brief introduction that the qualities and benefits of MDA are extremely advantageous. It therefore makes sense to judge products that claim to implement MDA on the extent to which they deliver these qualities and benefits.
What is it about MDA that offers such drastic improvements over conventional methods of software development? The answer to this question lies in MDA's unique blend of automation and "separation of concerns". In its approach to automation, MDA is not so different from ordinary software modelling tools - but there is one critical difference.

Figure 3: Classic Modelling and Development

In the classic approach (shown in Figure 3), each project is carried out by a team of developers. To write the necessary code, the developers must comprehend the problem domain as well as the features of the chosen platform. Nothing can be added to the application that they have not fully understood - making their minds a bottleneck. Worse still, if the team breaks up, or if its members leave the company, all the knowledge that was so painstakingly collected is lost.
MDA, on the other hand, divides domain knowledge and platform knowledge. The more complete the separation of concerns between these logically independent fields of knowledge, the more truly "MDA" a product is.

Figure 4: The MDA Approach

As shown in Figure 4, MDA allows domain experts, platform experts and application developers to contribute their respective knowledge independently. If business operations change, domain experts can update the corresponding models, with little or no help from anyone else. Platform experts provide technical details of their respective platforms, which are then semi-automatically added to the mix. Finally, developers are free to focus on what they are best at: choosing the most appropriate technology, and tuning it for the best results.
The essential characteristics of MDA, then, are:

• Separation between, and reusability of, domain and platform expertise
• Reuse and leveraging of existing IT technologies
• Quick adaptability of domain and technology changes
• Generation of working, high-quality applications and integrations

Increase Productivity and Control
As Grady Booch remarks in his presentation "The Limits of Software" (2002),"[t]he entire history of software engineering is that of the rise in levels of abstraction". As a software engineering pioneer and one of the architects of UML, Booch is well qualified to have an opinion on the subject.
The first computers were "programmed" with a soldering iron: they had to be rewired for every new task. Then came "machine code", where each individual bit was loaded using switches. Assembly code was a big step forward, even though each statement corresponded to a single machine instruction. Then came "third generation" language (3GL) compilers, which could generate multiple instructions to carry out one program statement. "Fourth generation" languages (4GLs) took the process of abstraction still further: they could generate a whole application, if the developer merely specified a few parameters.

As the level of abstraction rose, programmers could create more and more powerful applications in return for a given investment of time and effort. The drawback was that they sacrificed other desirable factors, such as flexibility and standardisation, for this productivity. That is why, 15 years after 4GLs looked set to replace 3GLs, most of today's programming is done in 3GLs like C, C++, and Java. MDA strikes a compromise between power, flexibility and standardisation. It allows development to move smoothly between levels of abstraction, with much of the work being automated (as shown in Figure 4).

Figure 5: Controllable Incremental Refinement

A schematic view of how MDA works in practice is given in Figure 5. The key process is one of controllable incremental refinement, starting with an abstract specification and yielding a more detailed specification. The translation process is controlled by a refinement definition, which can itself be maintained and updated. This process can be repeated any number of times, with the detailed specification (the output of one stage) becoming the abstract specification (the input of the next stage).

Figure 6: Different Abstraction Levels and Multiple PSMs

Figure 6 adds more details, illustrating how MDA relates to the models and languages used in software development. Domain models are expressed in a business modelling language - normally UML, with some extensions. Through appropriate "technology patterns", domain models are transformed to application models; these are also expressed in UML with extensions - usually in the form of a "UML Profile" for a given platform. Finally, with the help of a set of "implementation patterns", application models are transformed into source code in programming languages such as C++, C#, Java, or CORBA IDL.

What MDA is Not
Dozens of vendors claim to offer MDA tools, but only a handful meet all the requirements. Perhaps the most common shortcoming is the failure to support domain models, application models, and source code generation; many products start at the less abstract application model level. In fact, they are just plain vanilla modelling tools.

Some so-called "MDA tools" support models that contain just as much detail as the source code of the corresponding applications. In fact, these models are not necessarily on a higher level of abstraction than the code that is generated from them. As outlined in Figure 4, the essence of MDA requires the separation of domain and platform expertise, which this approach doesn't allow.

Certain products, typically specialised for the creation of embedded, real-time systems, rely on "Executable UML". This is essentially ordinary UML with the addition of an Action Semantics language (ASL) that allows dynamic operations to be defined within models. OMG is in the process of standardising ASL as an optional part of UML, but this does not mean that ultimately PIMs will contain all the information necessary to generate code. ASL certainly has a useful role -- for instance, it can specify algorithms that are necessary parts of the business model -- but it should not be used to turn UML into just another programming language, as most of the benefits of MDA would be lost in the process.

MDA Specifications
Although OMG has been working on the MDA specifications for at least three years, they are by no means complete as yet. It is true that UML, Meta Object Facility (MOF), Object Constraint Language (OCL), Common Warehouse Metamodel (CWM), and XML Metadata Interchange (XMI) were defined years ago, but they continue to evolve. Moreover, this evolution has had to accelerate sharply to provide even a minimal infrastructure for MDA.

MDA is all about expressing data and process precisely using formal languages like UML. As we have seen, however, it is often necessary to transform models from one language to another -- or even between different "dialects" of UML. This can be done reliably only if all the formal languages involved are logically consistent and compatible; which means that they must all share a common meta-metamodel. That is the role of MOF, which can be seen as the root of the tree whose leaves are UML, CWM, XMI and others. This relationship is depicted graphically in Figure 7.

Figure 7: MOF is the Root of the Language Tree

With MOF in place, new languages can be defined whenever necessary, and existing languages can be extended. Sometimes it can also be advantageous to design new and better ways of doing things that are already possible.
For example, most current MDA tools transform one model to another using UML Profiles. OMG is working on a more methodical way of doing this, through the proposed MOF 2.0 Query/Views/Transformations specification. This will standardise the way in which mappings are achieved between models whose languages are defined using MOF.
At the time of writing UML 2.0 and MOF 2.0 are close to final adoption by OMG. While becoming significantly more complex, they will be fully aligned with one another, thus providing a solid basis for MDA.

Compuware's involvement with the MDA standards process has been first rate. Its representatives participate in the Finalization Task Forces for UML 2.0, OCL 2.0 and MOF 2.0, and the OMG Architecture Board's advisory committee on the new MDA-based Object Model Architecture. Compuware also initiated the MOF 2.0 Query/Views/Transformations Request for Proposal (RFP), and has submitted a specification in response to that RFP.

Conclusion
The core problem of software development is to reconcile increased productivity with flexibility and standardisation. Until the introduction of MDA, existing languages met one or two of these requirements, but never all three. With the advent of MDA, it becomes realistic to expect high productivity within a standard environment, while retaining full flexibility. Application quality is likely to improve too, as less code is written by hand and the use of patterns help to incorporate best practices.

While MDA is consistent with a high degree of automation, it will probably never be 100% automated. Tools -- such as those based on Executable UML -- that create models at the same level of abstraction as source code, may be useful but do not qualify as MDA products. Such models are unlikely to be truly platform-independent; they make it hard to attain the quality and productivity benefits of MDA; and they blur the necessary distinction between domain model and application model.

MDA is a philosophy, not a standard; but it depends on a whole array of standards, many of which are already available. Work continues at OMG, with UML 2.0 and MOF 2.0 approaching standardisation, and other specifications like the UML Profiles, CWM, and XMI already available. New specifications like MOF 2.0 Query/Views/Transformations will enhance the MDA infrastructure still further. "Rome was not built in a day" -- over the next few years MDA promises to deliver a quantum leap in software development technology through its combination of productivity, flexibility and standardisation.