Model-driven architecture
Model-driven architecture 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 in 2001.
Overview
Then, given a platform model corresponding to CORBA,.NET, the Web, etc., the platform independent model is translated to one or more platform-specific models that computers can run. This requires mappings and transformations and should be modeled too.The OMG organization provides rough specifications rather than implementations, often as answers to Requests for Proposals. Implementations come from private companies or open source groups.
Related standards
The MDA model is related to multiple standards, including the Unified Modeling Language, the Meta-Object Facility, XML Metadata Interchange, Enterprise Distributed Object Computing, the Software Process Engineering Metamodel, and the Common Warehouse Metamodel. 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.Executable UML was the UML profile used when MDA was born. Now, the OMG is promoting fUML, instead.
Trademark
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, Model Driven Application Development, Model Based Application Development, Model Based Programming, Model Driven Systems, and others.Model-driven architecture topics
MDA approach
OMG focuses Model-driven architecture on forward engineering, i.e. producing code from abstract, human-elaborated modelling diagrams. OMG's ADTF group leads this effort. With some humour, the group chose ADM 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 is the furthest along of these efforts, and describes information systems in terms of various assets.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 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, which represents a conceptual design realizing the functional requirements, will survive changes in realization technologies and software architectures.
Of particular importance to model-driven architecture is the notion of model transformation. A specific standard language for model transformation has been defined by OMG called QVT.
MDA tools
The OMG organization provides rough specifications rather than implementations, often as answers to Requests for Proposals. 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 or 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 a tool used to check models for completeness, inconsistencies, or error and warning conditions. Also used to calculate metrics for the model.
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.
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. Many implementations of OMG modeling standards may be found in the Eclipse Modeling Framework or Graphical Modeling Framework, 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 EMF 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. 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.
Simple examples of architecture specifications include:
- Selecting one of a number of supported reference architectures like Java EE or Microsoft.NET,
- Specifying the architecture at a finer level including the choice of presentation layer technology, business logic layer technology, persistence technology and persistence mapping technology.
- Metadata: information about data.
MDA concerns
- Incomplete Standards: The MDA approach is underpinned by a variety of technical standards, some of which are yet to be specified, or are yet to be implemented in a standard manner.
- 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.
- Idealistic: MDA is conceived as a forward engineering approach in which models that incorporate Action Language programming are transformed into implementation artifacts in one direction via a fully or partially automated "generation" step. This aligns with OMG's vision that MDA should allow modelling of a problem domain's full complexity in UML with subsequent transformation to a complete application. This approach does, however, imply that changes to implementation artifacts are not supported. This constitutes a problem in situations where such post-transformation "adapting" of implementation artifacts is seen to be necessary. Evidence that the full MDA approach may be too idealistic for some real world deployments has been seen in the rise of so-called "pragmatic MDA". Pragmatic MDA blends the literal standards from OMG's MDA with more traditional model driven mechanisms such as round-trip engineering that provides support for adapting implementation artifacts.
- Specialised Skillsets: Practitioners of MDA based software engineering are required to have a high level of expertise in their field. Current expert MDA practitioners are scarce relative to the availability of traditional developers.
- OMG Track Record: The OMG consortium who sponsor the MDA approach also introduced and sponsored the CORBA standard which itself failed to materialise as a widely utilised standard.
- Uncertain Value Proposition : As discussed, the vision of MDA allows for the specification of a system as an abstract model, which may be realized as a concrete implementation for a particular computing platform. Thus an application that has been successfully developed via a pure MDA approach could theoretically be ported to a newer release.NET platform in a deterministic manner - although significant questions remain as to real-world practicalities during translation. Whether this capability represents a significant value proposition remains a question for particular adopters. Regardless, adopters of MDA who are seeking value via an "alternative to programming" should be very careful when assessing this approach. The complexity of any given problem domain will always remain, and the programming of business logic needs to be undertaken in MDA as with any other approach. The difference with MDA is that the programming language used is more abstract and exists interwoven with traditional UML artifacts. Whether programming in a language that is more abstract than mainstream 3GL languages will result in systems of better quality, cheaper cost or faster delivery, is a question that has yet to be adequately answered.
- MDA was recognized as a possible way to bring various independently developed standardized solutions together. For the simulation community, it was recommended as a business and industry based alternative to yet another US DoD mandated standard.
Code generation controversy
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".