[ Home ][ Executive Overview ][ MDA FAQ ][ Presentations and Papers ][ Specifications ][ Education ]
[ Committed Companies & Their Products ][ Success Stories ][ Vendor Directory ]

"The Architecture of Choice for a Changing World"

 Model Driven Architecture (MDA) FAQ...

Q: What is the Model Driven Architecture® (MDA®) and how is it different from other architectures?

A: The MDA is a new way of developing applications and writing specifications, based on a platform-independent model (PIM) of the application or specification's business functionality and behavior. A complete MDA specification consists of a definitive platform-independent base model, plus one or more platform-specific models (PSM) and sets of interface definitions, each describing how the base model is implemented on a different middleware platform. A complete MDA application consists of a definitive PIM, plus one or more PSMs and complete implementations, one on each platform that the application developer decides to support. 

MDA development focuses first on the functionality and behavior of a distributed application or system, undistorted by idiosyncrasies of the technology platform or platforms on which it will be implemented. In this way, MDA divorces implementation details from business functions. Thus, it is not necessary to repeat the process of defining an application or system's functionality and behavior each time a new technology (Web Services, for example) comes along. Other architectures are generally tied to a particular technology. With MDA, functionality and behavior are modeled once and only once. Mapping from a PIM through a PSM to the supported MDA platforms is being implemented by tools, easing the task of supporting new or different technologies.

This article in SD Times, by OMG's Dr. Jon Siegel, explains the MDA development process in more detail. 

Top

Q: Can you tell me something about the history of the MDA?

A: In 1996, OMG expanded its scope to include modeling and in 1997 adopted the Unified Modeling Language (UML)® and Meta-Object Facility (MOF™). Although it has always been true that UML models can be implemented on any platform, the continuing proliferation of middleware "silver bullets" suggested that a platform-independent MOF-based model is the secret to software stability and ROI - a stake that remains fixed in the ground while the infrastructure landscape around it shifts over time. The MDA unites OMG's well-established modeling standards with every middleware technology - past, present, and future - to integrate what you've built, with what you're building, with what you're going to build. Rather than focusing on yet another "next best thing," MDA raises the bar and designs portability and interoperability into the application at the model level.

Top

Q: What is the role of UML and MOF in the MDA?

A: Even though UML is usually thought of as the basis for MDA because of its visibility, it is actually MetaObject Facility (MOF) compliance that is formally required in order for a tool or tool chain to be labeled "MDA Compliant". The MOF is OMG's foundation specification for modeling languages; MOF compliance allows UML structural and behavioral models, and CWM data models, to be transmitted via XMI, stored in MOF-compliant repositories, and transformed and manipulated by MOF-compliant tools and code generators. 

Although not formally required, UML is still a key enabling technology for the Model Driven Architecture and the basis for 99% of MDA development projects. (Work in some specialized fields requires specially tailored modeling languages, although the additional capabilities added to UML by the 2.0 revision satisfies this need in many cases.) So, application development using the MDA is typically based on a normative, platform-independent UML model. By leveraging OMG's universally accepted MOF and UML standards, the MDA allows creation of applications that are portable across, and interoperate naturally across, a broad spectrum of systems from embedded, to desktop, to server, to mainframe, and across the Internet.

The basis on MOF was made official in August, 2004, when OMG's Object and Reference Model Subcommittee (ORMSC) unanimously adopted the definition of MDA that is being used to revise the official MDA Guide (from this current version). The August definition states: 

Any modeling language used in MDA must be described in terms of the MOF language, to enable the metadata to be understood in a standard manner, which is a precondition for any ability to perform automated transformations.

Top

Q: What is the role of Patterns in the MDA?

A: Patterns play a critical role in most MDA-based development projects. Successful transformation from PIM to PSM, and from PSM to code, requires that the PIM contain enough detail to completely guide the software tools through the process. By incorporating this detail through the use of patterns, instead of inserting it by hand, we gain multiple benefits: Our architects do less work, the resulting PIM reflects the collective wisdom of many contributors, and the tools can work the pattern (parameterized as necessary in our UML models) through the transformations, ultimately pulling implementation code from a library written by experts and inserting it into the application. 

Top

Q: What is the role of middleware platforms in the MDA?

A: In the MDA, middleware-specific models and implementations are secondary, rather than primary, artifacts: A specification's PIM - the primary artifact - defines one or more PSMs and sets of interface definition, each specifying how the base model is implemented on a different middleware platform. 

Because the PIM, PSMs, and interface definitions are all part of an MDA specification, OMG now adopts specifications in multiple middleware platforms under the MDA. Suitable targets for MDA development projects and OMG specifications includes Web Services, XML, .NET, EJB, and of course OMG's own favorite, CORBA. 

Top

Q: How does MDA enable cross-platform interoperability?

A: In the MDA, the base specification of every service, facility, and application is a platform-independent model. Architects specify links from an application to needed services and facilities, and to other applications, as part of its model. As the PIM for the new MDA specification or application is transformed into a PSM and then a coded application by the MDA tool chain, interoperability with other applications and services is built into it according to these links which are implemented properly regardless of the target's native middleware. 

Top

Q: What services will be available in the MDA environment?

A: OMG members are well aware of the extensive services necessary to support distributed computing, both within an enterprise and among many over the Internet. In CORBA, OMG's answer to this need was originally the CORBAservices, already defined and available here. In the MDA, these have been renamed the Pervasive Services because a single implementation of each, regardless of the platform on which it runs, can service every application or client that needs its capabilities via MDA-generated cross-platform bridges. Enterprises struggling to maintain and synchronize large directory services replicated on multiple platforms will surely appreciate the opportunity to trim down to a single instance! 

OMG plans to define four Pervasive Services:

• Directory Services

• Transaction Services

• Security Services

• Distributed Event and Notification Services

Additional services, as suggested by the list of CORBAservices already available, will be added as needed to keep the environment complete. 

Top

Q: How will Domain-Specific Software and Standards take advantage of the MDA? 

A: The MDA has so many advantages for industry-specific software that some of OMG's Domain Task Forces started writing specifications in the MDA before it became an official part of our architecture! 

In order to benefit an industry, a standard must be used by a critical mass of companies. Technology-specific standards will have trouble getting established where platform incompatibility prevents achieving this critical mass. Sometimes the problem is even deeper than this: In some industries, architecturally excellent standards have been adopted in the formal sense but failed to gain hold because they were written for a platform that few companies were willing to support. 

MDA completely removes these roadblocks. Under MDA, the functional description of every standard is technology independent, and the architecture is capable of producing interoperating implementations on multiple platforms. This allows an industry to define the business functionality and behavior of its standards as a PIM, and then produce PSMs and implementations on whatever platforms the participants require. 

In addition, technology-based standards become obsolete as their base platform ages; in fact they lose some of their appeal as soon as a new platform gets some play in the industry press. This is not a problem for MDA-based specifications: Because they are based on platform-independent PIMs and can be made to interoperate with new platforms, or even re-implemented on them, through the MDA development process, MDA-based applications and specifications are truly "future-proof". 

Bottom line: Using MDA, the industry gets a standard, every company uses it, none are forced to switch platforms in order to benefit, and the standard lasts as long as the industry process that it serves. Everybody wins! 

Top

Q: How does MDA compare or compete with Microsoft's .NET or Web Services?

A: MDA works at a different level than .NET and Web Services. These are individual platforms, aimed at specific albeit broad application targets, while the MDA is (as its name declares) a Model Driven Architecture that works above the level of every middleware platform, .NET and Web Services included. A middleware platform is incorporated into the MDA as a platform-specific profile. As .NET and Web Services establish market share, OMG members will define platform-specific profiles for them, allowing them to participate in the MDA along with the other platforms which will almost certainly include Java/EJB and additional protocols and platforms dictated by the industry or the marketplace.

Top

Q: Who is responsible for the MDA?

A: The MDA became the official base architecture for OMG specifications by unanimous votes of the technical representatives attending the organization's meeting in February, 2001. Like all the other work of the OMG, MDA was defined and will be developed by the OMG membership which includes a diverse cross-section of computer vendors, software suppliers, and many end-users. (If your company is an OMG member, please come to our meetings and get involved! If it's not, here is information about membership and an invitation to join us.) The wealth of experience contributed by these hundreds of organizations is one of the great strengths of OMG's process, and has been put to good use in defining and refining the MDA. This technical architecture document is the current MDA specification. The initial vision was drafted in late 2000 in this OMG white paper, and subsequently refined with the help of many individual contributors into this technical perspective. 

Top

Q: What are the top three benefits of the MDA to enterprises trying to cope with today's computing environment?

A: There are many benefits to using the MDA approach, with the most important being:

• In an MDA development project, attention focuses first on the application's business functionality and behavior, allowing stakeholders' investment to concentrate on the aspects that critically affect core business processes. Technical aspects, also critical but secondary to business functions, are well-handled by automated or semi-automated development tools. 

• An architecture based on the MDA is always ready to deal with yesterday's, today's and tomorrow's "next big thing" and makes it easier to integrate applications and facilities across middleware boundaries.

• Domain facilities defined in the MDA by OMG's Domain Task Forces will provide much wider interoperability by always being available on a domain's preferred platform, and on multiple platforms whenever there is a need.

Top

Q: How is the MDA being delivered? In what kind of tools? 

A: All of the key parts of the MDA vision have already been standardized, including not only UML 2.0, the MOF, XMI and CWM, but also a number of middleware mappings (including one to OMG's own CORBA and a middleware-independent mapping for enterprise systems called "UML Profile for Enterprise Distributed Object Computing"). 

In terms of products, MDA is being implemented by tools - or tool chains, which may come from a single vendor or a number of vendors - that integrate modeling and development into a single environment that carries an application from the PIM, through the PSM, and then via code generation to a set of language and configuration files implementing interfaces, bridges to services and facilities, and possibly even business functionality. Several vendors already provide tools that support integration at about this level, including substantial code generation. OMG has collected links to MDA products and vendors that we know about here. Today's tools typically automate 50% to 70% of the PIM-to-PSM transformation; because the industry got started on the second step much earlier, automation of the PSM-to-code transformation is typically 100% or nearly so. 

Top

Last updated on 11/16/2007