During the course of the last few decades, experienced programmers have learned to be cautious of new technologies and methodologies in the field of software design. After living to see the hopeful rise and then decline of CASE, object-oriented design, and the various methods that eventually flowed into UML, developers cannot help but feel skepticism to new approaches, including the newly emerging model-driven architecture (MDA).

Fortunately, however, MDA is not a fundamentally new approach, rather it is a way of using UML more effectively. This alone should be a big relief.

Today, UML is often used as the common language to describe program design. In this sense it is not used "strictly," as a tight and integrated way of detailing the specifications for a program in a provably correct set of documents. Rather it is employed more loosely: Use cases, for example, are drawn and recorded and the UML notation serves as a conventional way of discussing the captured data. From these notes and discussions, designs are developed using tools and techniques that frequently do not rely on UML technology at all. In these cases, UML's primary values lies in what it calls artifacts (the boxes, lines, arrowheads, and the like), which serve as lingua franca for representing business rules, user interactions, and other aspects of program activity and data movement.

When used formally, UML produces designs from which some tools today can generate C/C++ or Java code that implements the software. But these tools are the exception rather than the rule. Generally, the usefulness of UML in the enterprise stops short of coding. MDA proposes to extend the formal use of UML in several interesting ways.

It does so by specifying how the design should be implemented. MDA represents diagrammatically the deployment and hosting architectures for applications (especially those that reside on application servers or are implemented as Web services). Beyond using this information for code-generation, sites can employ it for maintenance, as well as for evolutionary considerations such as porting to new platforms. In essence MDA extends UML to cover the full lifecycle of the application.

What is MDA?

MDA begins its work where standard UML designs leave off. It starts by specifying a platform-independent model (PIM) of the application. The PIM discusses architecturally important features without yet descending to the specific implementing technologies. For example, the PIM provides an abstract way of designing the use of: directory services, security, transactionality, and persistence, among others. Once such an implementation overview is penciled out, designers find it less difficult to establish the platform-specific details and technologies that optimally implement the design. Collectively, these details are gathered into the platform-specific model (or PSM). MDA proponents hope that eventually vertical industries will publish a set of established component libraries that are used to implement many of the PIM features on a variety of platforms. RosettaNet (for electronics parts) and the Open Travel Alliance (OTA), for example, would be vertical technology specifications relied on by PIMs and MDA.

Using these vertical standards, it would not be difficult for an IT analyst to plug the correct elements into the PIM. And, it is the eventual hope that code could be generated from the PIMs for implementations of the design for a specific platform by combining it with information from the PSM. Want to target another platform? Plug in another aspect to the PIM and regenerate the code. At present, this re-creation cannot be done, but it is the goal. Achieving this goal would enable analysts to focus only on the design, the business logic, and the overarching architecture. These aspects should change only to reflect new developments at the business level. And code would always be re-generated automatically when such tweaks to the design are made. Some proponents dream of two-way code engineering, so that the touch-ups that programmers are always obliged to do to generated code can be reflected up the chain in the higher levels of the design. However, this prospect is a good way off. In fact, the full implementation of all the parts of MDA are only now coming into being. What are these elements?

Inside MDA

MDA is under the custodianship of the Object Management Group (OMG), the Framingham, Mass. consortium of major IT vendors that rose to fame on the basis of its specification of the Common Object Request Broker Architecture (or CORBA). Today, the OMG is also the keeper of UML. (Longtime developers will recall, of course, that UML was first specified by Rational Software Corp., after the company managed to merge the three major competing design methodologies of the 1990s — specifically, those of Grady Booch, Ivar Jacobson, and Joseph Rumbaugh. Rational turned over custody of UML to the OMG in 1997.) And it's the OMG that first promulgated MDA.

As specified so far, MDA is based on three modeling technologies, all of which are themselves based on UML. These are:

• The Meta-Object Facility (or MOF) which provides a standard repository for the PIM and helps identify how groups view the PIM, that is, the interfaces groups of users can have to it.
• The Common Warehouse Metamodel (CWM) which, in the words of the OMG, "standardizes a basis for data modeling commonality within an enterprise, across databases and data stores. Building on a foundation metamodel, it adds metamodels for relational, record, and multidimensional data; transformations, OLAP, and data mining; and warehouse functions including process and operation. CWM maps to existing schemas, supporting automated schema generation and database loading. This makes it the basis for data mining and OLAP across the enterprise."
• XML Metadata Interchange (XMI), which is a mapping that expresses UML-based models in XML. By so doing, XMI enables the UML documents to serve as the basis for other tools, such as code generators.

With these technologies, MDA can specify the objects, the data, and the design of any given project. When combined with platform information, it's clear that all the data necessary for implementation is now gathered and specified. Such a comprehensive inventory of all pre-implementation details (and in the case of the PIM and the PSM, some actual implementation data) is the larger goal of MDA.

Future-Facing Proposal

This point underscores the key aspect of MDA: it's still under development, although much of the technology is already in place. And the parts that are usable are clearly useful. As developers and managers begin to see monolithic or even client-server applications migrate to a Web services architecture, the need for a way to describe program functionality and implementation across these different architectures will become pressing. MDA as it exists now and as it will evolve is likely to be the best available solution. Moreover, for analysts already familiar with UML, the learning curve to move up to MDA should not be particularly long.

Further Information

Being the custodian of MDA means the OMG's site is certain to be a central repository on MDA matters. It is. I suggest focusing on: Developing in OMG's Model-Driven Architecture by Jon Siegel and the OMG Staff, rev. 2.6 . Other papers of similar usefulness can be found on the OMG site.

Another excellent paper on MDA is entitled MDA: Vision, Standards, and Emerging Technologies, by John Poole of Hyperion Corp. This paper is an excellent technical explanation without the promotional tone that runs through the OMG presentations.

Andrew Binstock is the principal analyst at Pacific Data Works LLC, a technology analysis firm. Previously, he was the editorial director of global technology forecasts for PricewaterhouseCoopers. Earlier, he was the editor in chief of UNIX Review. He can be reached at abinstock@pacificdataworks.com