THE OMG'S MODEL DRIVEN ARCHITECTURE

11 June 2002

by Paul Harmon

After considering some of the pioneering work by member organizations, the Object Management Group (OMG) decided to move toward adopting a new architecture, which it named the Model Driven Architecture (MDA). In effect, the OMG decided to raise the level of abstraction and focus on describing how the system should be integrated.

This is not to suggest that the OMG is abandoning Common Object Request Broker Architecture (CORBA). Rather, it will continue to support CORBA and its Object Management Architecture (OMA), while simultaneously developing a second, more comprehensive, UML-based architecture. A developer using the MDA approach begins by creating a UML model that describes how the system should be integrated. (MDA terms this a platform-independent model, or PIM.) Later, this model is used to structure the actual development of code to facilitate the integration described in the PIM. (The actual design is referred to as a platform-specific model, or PSM.) The OMG plans to define a set of profiles to ensure that a given UML model can consistently generate each of the popular middleware APIs.

When the OMG began to work on CORBA in 1990, it started by describing a set of general principles. Over the course of a decade, the principles were converted into specific standards and then implemented in a variety of tools. The OMG is a standards organization and doesn't involve itself in the creation or sale of code. Instead, the companies that are members of the OMG convert OMG standards into actual tools and applications.

In early 2001, the OMG described a set of general principles for MDA. Unlike CORBA development, which started from scratch, many of the elements of the new MDA architecture have already been defined by the OMG and implemented by vendors. The UML specification, for example, was first released in 1997. Several dozen companies have produced software tools that support some or most of the diagrams defined by the UML specification.

Since UML was first released, the OMG has continued to refine and extend it. UML is currently in release 1.4 and will move to version 2.0 sometime in 2002. In addition to extending and refining the UML diagramming conventions, the OMG has done a number of other things to improve UML. Foremost among them, the OMG has created a metamodel for modeling languages, which it called Meta Object Facility (MOF).

UML describes diagrams that are used to model specific software applications. Thus, for example, UML defines a class diagram that can be used to illustrate how classes can be assembled. When you use the class diagram notation to describe an actual class model of an accounting application, you have created a model of the accounting application. The higher-level UML description of a generic class diagram is a metamodel. It's a model that can be used to describe any of thousands of specific software models. UML supports about a dozen different diagrams; for example, class diagrams, use case diagrams, sequence diagrams, activity diagrams, object instance diagrams, and package diagrams. Each of these diagram types is a different type of metamodel. MOF is a meta metamodel, which is used to describe all of the models making up UML. Broadly, MOF is a very abstract model that can describe any other type of model, including non-UML models.

MOF is necessary for UML to ensure that each of the specific UML model types is defined in a consistent way. Thus, MOF ensures that a "class" in a class diagram has a precise relationship to an "activity" or to a "use case" in their respective diagrams. (In effect, each UML diagram is really just a "view" of the common, underlying UML metamodel.) At the same time, MOF is actually defined by a subset of the elements used in the UML metamodel. This can all seem a little overwhelming, but the net result is that MOF maintains that UML is a more precise software development modeling system than any of the earlier software methodologies. IBM, Oracle, Sun, and Unisys have all begun to incorporate MOF elements into their major systems to ensure that their various products can communicate with each other.

In the process of developing UML and MOF, several OMG members were impressed with the ability of these technologies to bring a greater degree of consistency to many other aspects of the OMG's standardization efforts. One task force redefined the OMG's CORBA IDL as a MOF-compliant model. This, in turn, means that a software tool could automatically convert a UML diagram into IDL code. In addition to generating MOF-compliant models, the OMG is also developing extensions of UML, called profiles. UML can be extended with new diagrammatic elements according to rules adopted by the UML and MOF task forces. Specific extensions are called stereotypes, and a set of extensions and tag values is called a profile. Thus, the OMG has defined a profile for CORBA and for IDL. Profiles can be designed to help translate UML diagrams into code and to assist in reverse engineering the code into UML in a consistent manner.

In a related effort, an OMG task force developed a standard for data warehouses, called the Common Warehouse Metamodel (CWM). CWM is a metamodel for data warehouses. At the same time, CWM is a MOF-compliant metamodel. In other words, CWM is defined in terms of MOF.

In still another effort, the OMG's MOF task force defined a XML system that uses rules to generate XML files from any MOF- compliant model. The system is called the XML Metadata Interchange (XMI). In the next release of UML -- once XMI support is added to a UML tool or a database -- UML diagrams and the information contained within the diagrams can be moved from one tool or database to another via the Internet, using XMI. By the same token, using XMI, CWM products can generate XML files and pass them to UML tools, and vice versa.

All of these developments provide an idea of how the OMG was already working to provide more extensive support for UML and to standardize techniques that would make UML diagrams more dynamic and useful.

Most large companies throughout the world already use UML to design new enterprise applications. In most cases, the software development team begins by creating a use case model of the application and one or two generic business models, described via class diagrams or activity diagrams. Then the team moves on and elaborates these initial diagrams into a detailed design by adding more and more specificity to the UML diagrams.

The idea behind the OMG's MDA is simplicity. What the OMG proposes is that companies create high-level UML descriptions of how applications will be structured and integrated (PIMs). These descriptions will be independent of any actual implementation details. From the PIM model, a more constrained UML design, or PSM, can be generated. A PSM design can then be converted into language code designed for a specific platform. The final product, code for a specific platform, is termed an Enterprise Deployment Model (EDM). Put another way, PIMs can be used to generate any of several different PSMs, each of which could generate a different specific application (EDM). Essentially, MDA assumes that companies will create UML descriptions of applications and middleware links and then use those graphical descriptions to generate code.

Consider a concrete example: Each middleware language models a transaction in a slightly different way. But every transaction has a start and an end. At the PIM level, we use UML to specify a generic transaction. Then, at the PSM level, we refine the transaction so that it's appropriate for whatever language and platform we intend to use. Using this approach, a company could create a PIM and then generate several different PSMs, one for the European division that wants to use EJBs, one for the Japanese division that's using Java, and one for the US division that's using XML and .NET middleware.

Conrad Bock of Kabira Technologies explains it this way: Model-driven development frees users from being bound to any particular vendor's APIs. For example, a UML-driven application server does not have a set of APIs to use; it has a model. Since the model is platform independent, it will work on any UML-driven application server. Users are not committing to a specific server when they put their mission-critical business knowledge into an MDA PIM model.

Obviously, if MDA is to fulfill Bock's ambitions, it requires that the OMG not only refine UML and its associated technologies, but also revise existing CORBA services and domain frameworks to provide MDA support. In each case, the existing standard, which is defined in CORBA IDL, will need to be redefined as an abstract UML model. This work has begun and will certainly take two or three years to complete. The MDA approach also assumes that MDA products will support reverse or round-trip engineering, so that any code modified by a developer can be used to change the UML diagram in the appropriate PSM. It further assumes that the revised PSM will be used to revise the PIM, assuring enterprise-wide consistency. The OMG has begun to refer to its MDA approach as a "20-year architecture," stressing that, while middleware and APIs may come and go, a company should be able to maintain a PIM for many, many years.

--Paul Harmon, Senior Consultant, Cutter Consortium