Model Driven Engineering is a software development methodology focused on creating domain models that abstract the business knowledge and processes of an application domain. Domain models allow the engineer to pursue a solution to a business problem without considering the eventual platform and implementation technology. Model Driven Development is a paradigm within Model Driven Engineering that uses models as a primary artifact of the development process using automation to go from models to actual implementation. Model Driver Architecture is an approach for developing software within the Model Driven Development paradigm. It was launched in 2001 by the Object Management Group and provides a set of standards for creating and transforming models, generally using UML as the model standard. The intent of MDA is to separate business logic from its implementation in a way that is platform and vendor neutral while transcending technology.
MDA processes the software design through various levels of abstraction employing a series of transformations. Starting with a Computation Independent Model (CIM) which essentially represents the user’s requirements with no reference or concern as to how or where those requirements may be implemented. The CIM represents the business logic through models such as use case diagrams and activity diagrams. The CIM is then transformed into a Platform Independent Model (PIM) which depicts the implementation of the business logic using a domain specific language (DSL) in a form that is not tied to a specific technology platform. This provides a less abstract model of the behavior of the software without committing to the specifics of a particular platform. Sources of information for the PIM include artifacts such as class diagrams and sequence diagrams. The PIM can then be transformed to one or more Platform Specific Model for specific platforms, technologies or vendors. Finally the PSM is translated into actual code that can be compiled and deployed. Transformations rely on a set of mappings that inform the transformer tool with technology or implementation patterns.
Remember that MDA is an approach it is not in and of itself a tool. There are however many commercial and open source tools available to support all aspects of MDA. Some examples of these can be found at  The more automated the process is the more likely it is that productivity and quality benefits will be realized. MDA tools come in many flavors and are used for all facets of model creation, manipulation, transformation and validation. Types of MDA tools available include:
* Creation tools which create new models from user requirements
* Analysis tools which conduct analysis of models for completeness, cross checks, metrics
* Transformation tools which apply patterns to transform from one model to another or to transform from a model to code
* Test and simulation tools which apply model based testing and create simulated executions of the models
* Reverse engineering tools which transform legacy applications into models
It’s not a huge leap to see how MDA could lead to improvements in both productivity and software quality. Automation, high degree of abstraction, reusable artifacts and the use of standards all have potentially significant productivity implications. It also seems obvious that these will not be realized without a substantial investment in tools, talent and training. Some of the areas of potential benefit of MDA include:
* There are various reports that using MDA increases productivity of software projects.  reports on several experiments that for the most part found productivity increases, though the range of results across their experiments found -27% to 69% deltas. The same paper sites Motorola results over 15 years of MDA practice of 2x to 8x though these are not across a common baseline.  cites a study where a 3 person development team using Optimal showed a 35% increase in productivity overt an equally experienced teams using more traditional methods
* Portability is achieved as one PIM can be transformed into multiple PSMs for different platforms
* The use of standards and models ensures that solutions are interoperable and of high quality.
As with all process and productivity improvement initiatives, there are also some potential pitfalls associated with MDAs
* In order to achieve productivity gains there is a necessary investment in tools and training
* MDA requires a specific and specialized skill set that may not be easy to find and may come at a high price
* Although platform independence is an important aspect of MDA, there are not universally applied standards for interoperability so vendor lock in is a possible problem
* In some cases there appears to be a gap between the vision of complete transformation and the reality of post transformation adaptations of transformation artifacts.
As always, it is important to remember the lessons of Fred Bookes in  that there are no silver bullets. While the MDA promise of automated transformations across many level so abstraction will increase the productivity with which code is delivered, these remain the accidental complexities of software engineering; the essential complexity of crafting a software solution to a problem is not something that can be automated.
 Mohagheghi, Parastoo & Dehlan, Vegardm “Where is the Proof? A Review of Experiences from Applying MDE in Industry” , “Quality in Modeling driven Engineering Project at SINTEF”, available at http://quality-mde.org/publications/MDE-experiences-ECMDA08-final.pdf
(retrieved Feb 2012)
 “Model Driven Development for J2EE Utilizing a Model Driven Architecture (MDA) Approach Productivity Analysis, the Middleware Company. June 2003
(retrieved Feb 2012)
, Brooks, Fred; “The Mythical Man Month: Essays on Software Engineering”, Addison-Wesley Publishing Company, Phillipines, 1975