Model-driven architecture: Difference between revisions

Revision as of 08:30, 4 September 2018

Revision as of 09:11, 26 October 2018

Line 1:

'''Model-driven architecture''' ('''MDA®''') is a [[software design]] approach for the development of [[software system]]s. It provides a set of guidelines for the structuring of specifications, which are expressed as [[model (abstract)|model]]s. 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.<ref name=proposal>[http://www.omg.org/news/releases/pr2001/2001-03-08a.htm "OMG pursues new strategic direction to build on success of past efforts"] {{webarchive|url=https://web.archive.org/web/20060924103531/http://www.omg.org/news/releases/pr2001/2001-03-08a.htm |date=2006-09-24 }}</ref>

== Overview ==

The model-driven architecture approach defines system functionality using a [[platform-independent model]] (PIM) using an appropriate [[___domain-specific language]] (DSL).{{Citation needed|date=January 2011}}

Then, given a [[platform model]] corresponding to [[CORBA]], [[.NET Framework|.NET]], the Web, etc., the PIM is translated to one or more [[platform-specific model]]s (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 programming languages|general purpose language]].{{Citation needed|date=February 2007}}. Automated tools generally perform this translation.

The OMG organization provides rough specifications rather than implementations, often as answers to [[Request for Proposal|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{{Citation needed|date=February 2007}}.

=== Related standards ===

Line 18 ⟶ 12:

=== 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.<ref>http://www.omg.org/legal/tm_list.htm</ref> The main acronym that has not yet been deposited by OMG until now is [[Model-driven engineering|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.{{Citation needed|date=February 2007}}

== Model-driven architecture topics ==

Line 24 ⟶ 18:

OMG focuses Model-driven architecture on forward engineering, i.e. producing code from abstract, human-elaborated modelling diagrams (e.g. class diagrams){{Citation needed|date=February 2007}}. 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.<ref>adm website http://adm.omg.org</ref> [[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{{Citation needed|date=July 2009}}. 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 architecture]]s.

Of particular importance to model-driven architecture is the notion of [[model transformation]]. A specific standard language for model transformation has been defined by [[Object Management Group|OMG]] called [[QVT]].

Line 33 ⟶ 27:

Basically, an MDA tool is a tool used to develop, interpret, compare, align, measure, verify, transform, etc. models or metamodels.<ref>{{cite paper|author=Bézivin, J, Gérard, S, Muller, P-A, and Rioux, L|title=MDA components: Challenges and Opportunities|version=In: Metamodelling for MDA|year=2003|url=http://www.sciences.univ-nantes.fr/lina/atl/www/papers/MDAComponents-ChallengesOpportunities.V1.3.PDF|deadurl=yes|archiveurl=https://web.archive.org/web/20061206191031/http://www.sciences.univ-nantes.fr/lina/atl/www/papers/MDAComponents-ChallengesOpportunities.V1.3.PDF|archivedate=2006-12-06|df=}}</ref> 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 AMDA 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.<ref name="MonperrusJézéquel2008">{{cite journal|last1=Monperrus|first1=Martin|last2=Jézéquel|first2=Jean-Marc|last3=Champeau|first3=Joël|last4=Hoeltzener|first4=Brigitte|title=A Model-Driven Measurement Approach|year=2008|pages=505–519|issn=0302-9743|doi=10.1007/978-3-540-87875-9_36}}</ref>

An MDA tool may be one or more of the following types{{Citation needed|date=February 2007}}:

; 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.<ref name="MonperrusJézéquel2008">{{cite journal|last1=Monperrus|first1=Martin|last2=Jézéquel|first2=Jean-Marc|last3=Champeau|first3=Joël|last4=Hoeltzener|first4=Brigitte|title=A Model-Driven Measurement Approach|year=2008|pages=505–519|issn=0302-9743|doi=10.1007/978-3-540-87875-9_36}}</ref>

; 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 (which tool? which transformation? etc.)) 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.

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{{Citation needed|date=February 2007}}. 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.