MDA Specifications

MDA Overview

OMG members voted to establish the MDA (Model Driven Architecture) as the base architecture for our organization's standards in late 2001. Software development in the MDA starts with a Platform-Independent Model (PIM) of an application's business functionality and behavior, constructed using a modeling language based on OMG's MetaObject Facility™ (MOF™). This model remains stable as technology evolves, extending and thereby maximizing software ROI. MDA development tools, available now from many vendors, convert the PIM first to a Platform-Specific Model (PSM) and then to a working implementation on virtually any middleware platform: Web Services, XML/SOAP, EJB, C#/.Net, OMG's own CORBA®, or others. Portability and interoperability are built into the architecture. OMG's industry-standard modeling specifications support the MDA: The MOF; Unified Modeling Language™ (UML®), now at Version 2.0; the Common Warehouse Metamodel™ (CWM™); and XML Metadata Interchange™ (XMI®). OMG Task Forces organized around industries including Finance, Manufacturing, Biotechnology, Space technology, and others use the MDA to standardize facilities in their domains.

The Genesis And History Of MDA

In late 2000, OMG members first reviewed the document entitled "Model Driven Architecture" and decided to form an architecture team to produce a more formal statement of the MDA. This formal but still incomplete definition of the MDA was set out in the 2001 document "Model Driven Architecture - A Technical Perspective", by the OMG Architecture Board MDA Drafting Team. Voted by members in September, 2001, to be the group's base architecture, the MDA was immediately used by many Domain Task Forces to define and adopt standards on multiple middleware platforms. 

In mid-2014, members adopted the revised "MDA Guide Revision 2.0" as a more detailed definition of the architecture. This paper is based on the separate MDA Foundation Model. 

MDA Specification Support

  • Specifications Define The MDA And The MDA Development Environment:
    The MDA Guide, Revision 2.0, just mentioned, defines the MDA. It states that "The Meta Object Facility (MOF) provides a key foundation for OMG's Model-Driven Architecture, which unifies every step of development and integration from business modeling, through architectural and application modeling, to development, deployment, maintenance, and evolution. MOF uses 'meta-models' specified in UML® to describe modeling languages as inter-related objects." (This means, for example, that a suitable development process based on OMG's Common Warehouse Metamodel can be MDA-compliant, since CWM is based on MOF.)  


    Additional OMG specifications, listed on this page, populate the architecture. Development tools, provided by vendors, implement these supporting standards. Working together, these tools constitute the working MDA modeling and development environment where architects and developers create MDA applications.

  • Specifications Are Defined In The MDA:
    Facilities and services defined in the MDA and standardized by OMG take advantage of the MDA's stability and platform-independence. This includes both the Pervasive Services and the Domain Facilities in about a dozen different industries. 

The Meta-Object Facility (MOF)

In the MDA, models are first-class artifacts, integrated into the development process through the chain of transformations from PIM through PSM to coded application. To enable this, the MDA requires models to be expressed in a MOF-based language. This guarantees that the models can be stored in a MOF-compliant repository, parsed and transformed by MOF-compliant tools, and rendered into XMI for transport over a network. This does not constrain the types of models you can use - MOF-based languages today model application structure, behavior (in many different ways), and data; OMG's UML and CWM are good examples of MOF-based modeling languages but are not the only ones. 

Before you download the MOF spec and start reading, think about why you care about MOF, and its versions: If you're an architect or developer, you rely on your tools'  MOF compliance when you move a model from the tool to your corporate repository, or to a transformation tool or code generator. If your tools don't conform to the same version of MOF, you'll encounter trouble when you attempt the transfer. Fortunately, you don't have to read or understand the MOF spec in order to set up a compatible tool chain - just know the version numbers, and make sure they're all the same. (If you're using XMI for transfer, check the XMI versions too.) If you're a tool builder/supplier, your situation is different: You have to build MOF compliance into your products, and test for interoperability by transferring models to and from other vendors' compliant tools (probably using XMI). The MOF specs were written for you, so Happy Reading! 

The current version of the MOF is always available here. 

As you might expect, the foundation for UML 2.0 is MOF 2.0. MOF 2.0 is being adopted in several parts. These adopted, pre-finalization versions are available to everyone for free download; OMG members can access more recent versions and working documents from OMG's work-in-progress web page. 

(There's a MOF 2.0/XMI specification also, which we've discussed separately. Read below.)  

The Unified Modeling Language (UML)

Each MDA-based specification has, as its normative base, two levels of models: a Platform-Independent Model (PIM), and one or more Platform-Specific Models (PSM). For many specifications, these will be defined in UML, making OMG's standard modeling language a foundation of the MDA. (Use of UML, although common, is not a requirement; MOF is the mandatory modeling foundation for MDA.)

UML 2.0 is now the current official version. Tailored to MDA requirements, this new release improves Business, Architectural, Structural, and Behavioral modeling and is being done in four parts. The UML 2.0 Superstructure Specification has been completed, and is available for free download here. The other three parts linked here are finishing up OMG's finalization maintenance process to fix inconsistencies and resolve ambiguities. The maintenance process is not allowed to make major changes, nor to add or delete features or functionality, so you can get a good idea of what the official specification will look like from these documents, even though they don't reflect the final, official version. OMG members can download more recent documents than the ones listed here by following relevant links from the Work in Progress page, which requires an OMG username and password; non-members can download somewhat older public documents for:  

To find out if your company is a member of OMG, click here. If it is, send email to [email protected] requesting your personal OMG username and password if you don't have one already. 

OMG maintains a public UML Resource and Information Page.  

Several additional specifications help tailor the UML to support MDA: 

  • A human-usable Textual Notation enables a new class of model-editing programs and enhances the way models (if they're built using a MOF-based modeling language, of course) can be manipulated.  Notation elements map one-to-one to the more verbose XMI, but the syntax of the HUTN™ is much more human-friendly.  
  • A standard Software & Systems Process Engineering Metamodel™ (SPEM™) defines a framework for describing methodologies in a standard way. It does not standardize any particular methodology, but enhances interoperability from one methodology to another. 

UML Profiles

UML Profiles tailor the language to particular areas of computing (such as Enterprise Distributed Object Computing) or particular platforms (such as EJB or CORBA). There's a working definition of UML Profile in Section 6.2 of this RFP. 

In the MDA, both PIMs and PSMs will be defined using UML profiles; OMG is well along our way defining a suite of profiles that span the entire scope of potential MDA applications. Profiles are official OMG specifications. The current suite of profiles includes: 

  • The UML Profile for CORBA™, which defines the mapping from a PIM to a CORBA-specific PSM. 
  • The UML Profile for CCM™ (the CORBA Component Model), OMG's contribution to component-based programming. Enterprise JavaBeans (EJBs) are the Java mapping of CCM; an initial take on a profile for EJB appears as an appendix of the UML 2.0 Superstructure specification, linked above. 
  • The UML Profile for EDOC™ is used to build PIMs of enterprise applications. It defines representations for entities, events, process, relationships, patterns, and an Enterprise Collaboration Architecture. As a PIM profile, it needs mappings to platform-specific profiles. A mapping to Web Services is underway now; additional mappings will follow.  
  • The UML Profile for EAI™ defines a profile for loosely-coupled systems - that is, those that communicate using either asynchronous or messaging-based methods. These modes are typically used in Enterprise Application Integration, but are used elsewhere as well.  
  • The UML Profile for Quality of Service (QoS) and Fault Tolerance™ defines frameworks for Real-time and high-assurance environments. 
  • The UML Profile for Schedulability, Performance, and Time™ supports precise modeling of predictable - that is, real-time - systems, precisely enough to enable quantitative analysis of their schedulability, performance, and timeliness characteristics.  
  • The UML Testing Profile™ (UTP™) provides important support for automated testing in MDA-based development environments. 

XML Metadata Interchange (XMI)

XMI defines an XML-based interchange format for UML and other MOF-based metamodels and models (since a metamodel is just a special case of a model), by standardizing XML document formats, DTDs, and schemas. In so doing, it also defines a mapping from UML to XML. Because one of OMG's XMI updates reflects the incorporation of XML Schemas, while MOF point updates were made periodically through OMG's established maintenance process, numbering of XMI and MOF versions diverged. Here is a table of corresponding MOF and XMI versions: 

MOF 1.3 XMI 1.1
MOF 1.4 (current) XMI 1.2
MOF 1.4 (current) XMI 1.3 (adds Schema support)
MOF 1.4 (current) XMI 2.0 (current; new format)
MOF 2.0 (in process) XMI 2.1 (in process)

You can access the archived MOF 1.3. here; it's also linked from the Modeling section of OMG's Specification Vault.  The vault is also where you'll find all of the archived versions of XMI. Check out our Modeling Specifications Catalog page for the current MOF 1.4 Specification and XMI 2.0 Specification. 

Common Warehouse MetaModel™ (CWM™)

The CWM standardizes a complete, comprehensive metamodel that enables data mining across database boundaries at an enterprise and goes well beyond. Like a UML profile but in data space instead of application space, it forms the MDA mapping to database schemas. The product of a cooperative effort between OMG and the Meta-Data Coalition (MDC), the CWM does for data modeling what UML does for application modeling. 

The CWM is a formal OMG specification and is available here. 

A supplementary specification, CWM Metadata Interchange Patterns, defines patterns that smooth the way to data modeling tool interoperability. 

CORBA

Although MDA can target every middleware platform and will map to all that have significant market presence, CORBA plays a key role as a target platform because of its programming language-, operating system-, and vendor-independence. The latest CORBA specifications, including the CCM, are available here, as well as specialized CORBA specifications for Real-time, embedded, and high-assurance systems. Don't forget about the various CORBA-UML Profiles, listed a ways up on this page.  

Writing Standards In The MDA

Applications and Frameworks (that is, parts of applications that perform a particular function) can all be defined in the MDA as a base PIM that maps to one or more PSMs and implementations. Standards written this way enjoy two advantages:

  • The base PIM is truly a business specification, defining business functionality and behavior in a technology-independent way. Technological considerations do not intrude at this stage, making it easy for business experts to model exactly the business rules they want into the PIM. 
  • Once business experts have completed the PIM, it can be implemented on virtually any platform, or on multiple platforms with interoperability among them, in order to meet the needs of the industry and companies that use it. 

OMG Domain Task Forces, after years of writing specifications in only CORBA, are now writing their base specifications in the MDA to take advantage of these considerations. 

OMG recognizes (based on analogy to the CORBA-based Object Management Architecture™) three levels of MDA-based specifications:

  • The Pervasive Services, including Enterprise necessities such as Directory Services, Transactions, Security, and Event handling (Notification). 
  • The Domain Facilities, in industries such as Healthcare, Manufacturing, Telecommunications, Biotechnology, and others; and 
  • Applications themselves, perhaps created and maintained by a software vendor or end user company or enterprise using MDA tools to run an MDA-based methodology, but not standardized by OMG. 

The Pervasive Services

This category will include at least: 

  • Directory and Naming Services
  • Event Handling/Notification Services

Additional Pervasive Services may be defined, either from the list of CORBAservices already standardized by OMG or from other suggestions from OMG members. Transactions and Security, the other two most popular CORBAservices, may or may not be part of this group - in the Component world, transactionality and security are attributes of a running system, rather than services that a program calls, because of the way the Component Container or Application Server is set up to run transactionally and securely as part of an application's environment. 

OMG members are already taking the group's well-established CORBAservice specifications and mapping them back to PIMs where they can serve all platforms through the MDA development pathway. 

Domain Facilities

OMG's Domain Task Forces started to write their specifications in the MDA in mid-2001, led by the Life Science Research Domain Task Force, working in Biotechnology, which was the first Domain Task Force to modify its Mission and Goals Statement to reflect its work in MDA. 

All of our Domain specifications are listed on this web page. In addition to the Life Sciences MDA specifications, other notable MDA-based entries are the Software-Defined Radio and Super Distributed (that is, ubiquitous) Objects entries. Our Work in Progress page lists 15+ ongoing processes adopting new MDA-based specifications. 

 

MDA Applications

MDA-based development tools are available now, and enterprises everywhere around the world are starting their application development by building a PIM instead of writing code. Success stories are posted here. Even now, MDA is being used for large, mission-critical applications including the F-16 fighter jet mission software and a two-million-transaction per day bank payment system. If you're not convinced of the value of MDA already, look through these stories. We think you'll be ready to try MDA by the time you've read just a few!