April 15, 2012


MDA basically means using a model as a basis for development.

Model-driven architecture (MDA) is a software design approach for the development of software systems. It provides a set of guidelines for the structuring of specifications, which are expressed as models. Model-driven architecture is a kind of domain engineering, and supports model engineering of software systems. It was launched by the Object Management Group (OMG) in 2001.

Model-Driven Architecture is a philosophy of how models should be used in the software development process. Developers across the software industry are embracing this philosophy as they apply and evolve MDA principles as defined by the OMG.

Model-Driven Architecture (MDA) is a style of enterprise application development and integration, based on using automated tools to build a system-independent model and transform them into efficient implementations. The Object Management Group (OMG) has defined standards for representing MDA models, but the principles and practice of MDA are still evolving.

MDA incorporates several other OMG standards in its definition. These other standards are Unified Modeling Language (UML), Meta-Object Facility (MOF), XML Metadata Interchange (XMI), Enterprise Distributed Object Computing (EDOC), Software Process Engineering Metamodel (SPEM), and the Common Warehouse Metamodel(CWM).

MDA- Different from other

The MDA is a new way of writing specifications, based on a platform-independent model. A complete MDA specification consists of a definitive platform-independent base UML model, plus one or more platform-specific models and interface definition sets, each describing how the base model is implemented on a different middleware platform. The MDA focuses primarily on the functionality and behavior of a distributed application or system, not the technology in which it will be implemented. It divorces implementation details from business functions. Thus, it is not necessary to repeat the process of modeling an application or system’s functionality and behavior each time a new technology (e.g., XML/SOAP) comes along. Other architectures are generally tied to a particular technology. With MDA, functionality and behavior are modeled once and only once. Mapping to the supported MDA platforms will be implemented by tools, easing the task of supporting new or different technologies.

Role of UML in the MDA

UML is the key enabling technology for the Model Driven Architecture. Every application using the MDA is based on a normative, platform-independent UML model. By leveraging this universally accepted modeling standard, 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.

MDA – Cross-platform interoperability

Interfaces and implementations of a specification all derive from a common base UML model. This structure of linked models allows automated building of the bridges that connect implementations on those various middleware platforms. And, when the base model for a new specification is being designed, interoperability with other specifications and services can be designed into it.

MDA Tools:

An MDA tool is a tool that used to develop, interpret, compare, align, measure, verify, transform, etc. models or metamodels. In the following section ‘model’ is interpreted as meaning any kind of model (e.g. a UML model) or metamodel (e.g. the CWM metamodel). In any MDA approach we have essentially two kinds of models: initial models are created manually by human agents while derived models are created automatically by programs. For example an analyst may create a UML initial model from its observation of some loose business situation while a Java model may be automatically derived from this UML model by a Model transformation operation. An MDA tool may be one or more of the following types:

  • Creation Tool: A tool used to elicit initial models and/or edit derived models.
  • Analysis Tool: A tool used to check models for completeness, inconsistencies, or error and warning conditions. Also used to calculate metrics for the model.
  • Transformation Tool: A tool used to transform models into other models or into code and documentation.
  • Composition Tool: A tool used to compose (i.e. to merge according to a given composition semantics) several source models, preferably conforming to the same metamodel.
  • Test Tool: A tool used to test models as described in Model-based testing.
  • Simulation Tool: A tool used to simulate the execution of a system represented by a given model. This is related to the subject of model execution.
  • Metadata Management Tool: A tool intended to handle the general relations between different models, including the metadata on each model (e.g. author, date of creation or modification, method of creation) and the mutual relations between these models (i.e. one metamodel is a version of another one, one model has been derived from another one by a transformation, etc.)
  • Reverse Engineering Tool: A tool intended to transform particular legacy or information artifact portfolios into full-fledged models.

Benefits of using the MDA

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

  • An architecture based on the MDA is always ready to deal with yesterdays, todays and tomorrows “next big thing”.
  • The MDA will make 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.

Who is responsible for the MDA?

Although the original impetus for the MDA came from OMG staff, it is now supported by the membership as demonstrated by unanimous votes of the technical representatives attending the organization’s meeting in late 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. 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. The initial vision was drafted in late 2000 in a paper available at, and subsequently refined with the help of many individual contributors into a technical perspective, available at

MDA Concerns:

Potential concerns that have been raised with the MDA approach include:

  • Incomplete Standards: The MDA approach is underpinned by a variety of technical standards, some of which are yet to be specified.
  • Vendor Lock-in: Although MDA was conceived as an approach for achieving platform independence; current MDA vendors have been reluctant to engineer their MDA toolsets to be interoperable. Such an outcome could result in vendor lock-in for those pursuing an MDA approach.
  • Complexity: There is some complexity of mapping between the various layers.
  • Specialized Skill sets: Practitioners of MDA based software engineering are required to have a high level of expertise in their field.
  • Support in meta model to handle dynamic behavior.


Model Driven Architecture provides an open, vendor-neutral approach to the challenge of business and technology change. MDA separates business and application logic from underlying platform technology. Platform independent models of an application or integrated system’s business functionality and behavior, built using UML and the other associated OMG modeling standards can be realized through the MDA on virtually any platform, open or proprietary, including Web Services, .NET, CORBA, J2EE and others. These platform independent models document the business functionality and behavior of an application separate from the technology-specific code that implements it, insulating the core of the application from technology and its relentless churn cycle while enabling interoperability both within and across platform boundaries.


By: Vishnu Thogaripally


  1. Helen Todd said

    Nice job on the explanation of MDA. Although I honed in on one of the drawbacks — incomplete standards. As a customer that has been left to deal with the aftermath of incomplete standards, it’s not a good place to be. And, while this may not be the exact same thing, it can be a significant drawback.

  2. Megha Goel said

    This is a good post covering a lot of information on MDA. MDA gives the set of guidelines to generate a code from the visual model by using the tools like UML which will increase the overall productivity. But it would be challenging to deal with the development and debugging of the complex code which tool generated.

  3. Dustin Corey said

    Thanks for all the information on MDA, great job putting it together.

  4. Blane McCarthy said

    Good post, obviously a complex topic to distill down to this format. I like the idea of separating business logic from platform requirements. Sounds like vendors are hindering the realization of that goal. Are there other benefits that offset the complexity of the MDA approach?

  5. Krishnan Iyer said

    Good post. I also like the approach of seperating business and application logic from underlying platform technology. Are there any succes stories of the MDA?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: