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-driven engineering of software systems. It was launched by the Object Management Group (OMG) in 2001.
Then, given a platform model corresponding to CORBA, .NET, the Web, etc., the PIM is translated to one or more platform-specific models (PSMs) that computers can run. This requires mappings and transformations and should be modeled too.
The PSM may use different DSLs or a general purpose language.. Automated tools generally perform this translation.
The OMG organization provides rough specifications rather than implementations, often as answers to Requests for Proposals (RFPs). Implementations come from private companies or open source groups.
MDA principles can also apply to other areas such as business process modeling (BPM) where the PIM is translated to either automated or manual processes.
The MDA model is related to multiple standards, including the Unified Modeling Language (UML), the Meta-Object Facility (MOF), XML Metadata Interchange (XMI), Enterprise Distributed Object Computing (EDOC), the Software Process Engineering Metamodel (SPEM), and the Common Warehouse Metamodel (CWM). Note that the term "architecture" in Model-driven architecture does not refer to the architecture of the system being modeled, but rather to the architecture of the various standards and model forms that serve as the technology basis for MDA.
The Object Management Group holds registered trademarks on the term Model Driven Architecture® and its acronym MDA®, as well as trademarks for terms such as: Model Based Application Development(TM), Model Driven Application Development(TM), Model Based Application Development(TM), Model Based Programming(TM), Model Driven Systems(TM) and others. The main acronym that has not yet been deposited by OMG until now is Model-driven engineering (MDE). As a consequence, the research community uses MDE to refer to general model engineering ideas, without committing to strict OMG standards.
OMG focuses Model-driven architecture on forward engineering, i.e. producing code from abstract, human-elaborated modelling diagrams (e.g. class diagrams). OMG's ADTF (Analysis and Design Task Force) group leads this effort. With some humour, the group chose ADM (MDA backwards) to name the study of reverse engineering. ADM decodes to Architecture-Driven Modernization. The objective of ADM is to produce standards for model-based reverse engineering of legacy systems.Knowledge Discovery Metamodel (KDM) is the furthest along of these efforts, and describes information systems in terms of various assets (programs, specifications, data, test files, database schemas, etc.).
One of the main aims of the MDA is to separate design from architecture. As the concepts and technologies used to realize designs and the concepts and technologies used to realize architectures have changed at their own pace, decoupling them allows system developers to choose from the best and most fitting in both domains. The design addresses the functional (use case) requirements while architecture provides the infrastructure through which non-functional requirements like scalability, reliability and performance are realized. MDA envisages that the platform independent model (PIM), which represents a conceptual design realizing the functional requirements, will survive changes in realization technologies and software architectures.
The OMG organization provides rough specifications rather than implementations, often as answers to Requests for Proposals (RFPs). The OMG documents the overall process in a document called the MDA Guide.
Basically, an MDA tool is a tool 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.
Some tools perform more than one of the functions listed above. For example, some creation tools may also have transformation and test capabilities. There are other tools that are solely for creation, solely for graphical presentation, solely for transformation, etc.
One of the characteristics of MDA tools is that they mainly take models (e.g. MOF models or metamodels) as input and generate models as output. In some cases however the parameters may be taken outside the MDA space like in model to text or text to model transformation tools.
Implementations of the OMG specifications come from private companies or open source groups. One important source of implementations for OMG specifications is the Eclipse Foundation (EF). Many implementations of OMG modeling standards may be found in the Eclipse Modeling Framework (EMF) or Graphical Modeling Framework (GMF), the Eclipse foundation is also developing other tools of various profiles as GMT. Eclipse's compliance to OMG specifications is often not strict. This is true for example for OMG's EMOF standard, which Eclipse approximates with its ECORE implementation. More examples may be found in the M2M project implementing the QVT standard or in the M2T project implementing the MOF2Text standard.
One should be careful not to confuse the List of MDA Tools and the List of UML tools, the former being much broader. This distinction can be made more general by distinguishing 'variable metamodel tools' and 'fixed metamodel tools'. A UML CASE tool is typically a 'fixed metamodel tool' since it has been hard-wired to work only with a given version of the UML metamodel (e.g. UML 2.1). On the contrary, other tools have internal generic capabilities allowing them to adapt to arbitrary metamodels or to a particular kind of metamodels.
Usually MDA tools focus rudimentary architecture specification, although in some cases the tools are architecture-independent (or platform independent).
Simple examples of architecture specifications include:
Some key concepts that underpin the MDA approach (launched in 2001) were first elucidated by the Shlaer-Mellor method during the late 1980s. Indeed, a key absent technical standard of the MDA approach (that of an action language syntax for Executable UML) has been bridged by some vendors by adapting the original Shlaer-Mellor Action Language (modified for UML). However, during this period the MDA approach has not gained mainstream industry acceptance; with the Gartner Group still identifying MDA as an "on the rise" technology in its 2006 "Hype Cycle", and Forrester Research declaring MDA to be "D.O.A." in 2006. Potential concerns that have been raised with the OMG MDA approach include:
Among the various conferences on this topic we may mention ECMDA, the European Conference on MDA and also MoDELS, former firmed as <<UML>> conference series (till 2004), the Italian Forum on MDA in collaboration with the OMG. There are also several conferences and workshops (at OOPSLA, ECOOP mainly) focusing on more specific aspects of MDA like model transformation, model composition, and generation.
Code generation means that the user abstractly models solutions, which are connoted by some model data, and then an automated tool derives from the models parts or all of the source code for the software system. In some tools, the user can provide a skeleton of the program source code, in the form of a source code template where predefined tokens are then replaced with program source code parts during the code generation process.
An often cited criticism is that the UML diagrams just lack the detail which is needed to contain the same information as is covered with the program source. Some developers even claim that "the Code is the design".
Manage research, learning and skills at NCR Works. Create an account using LinkedIn to manage and organize your omni-channel knowledge. NCR Works is like a shopping cart for information -- helping you to save, discuss and share.