Model-driven architecture: Difference between revisions

Revision as of 09:36, 7 July 2024

Latest revision as of 12:58, 7 October 2024

(One intermediate revision by one other user not shown)

Line 3:

== Overview ==

Model Driven Architecture® (MDA®) "provides an approach for deriving value from models and architecture in support of the full life cycle of physical, organizational and I.T. systems". A model is a (representation of) an abstraction of a system. MDA® provides value by producing models at varying levels of abstraction, from a conceptual view down to the smallest implementation detail. OMG literature speaks of three such levels of abstraction, or architectural viewpoints: the Computation-independent Model (CIM), the [[Platform-independent model]] (PIM), and the [[Platform-specific model]] (PSM). The CIM describes a system conceptually, the PIM describes the computational aspects of a system without reference to the technologies that may be used to implement it, and the PSM provides the technical details necessary to implement the system. The OMG Guide notes, though, that these three architectural viewpoints are useful, but are just three of many possible viewpoints.<ref name="omgmdaguide2_0">{{cite web |title=OMG MDA Guide rev. 2.0 |url=https://www.omg.org/cgi-bin/doc?ormsc/14-06-01 |website=OMG {{!}} Object Management Group |publisher=The Object Management Group |access-date=4 September 2021}}</ref>

The OMG organization provides specifications rather than implementations, often as answers to [[Request for Proposal|Requests for Proposals]] (RFPs). Implementations come from private companies or open source groups.

Line 46:

=== MDA concerns ===

Some key concepts that underpin the MDA approach (launched in 2001) were first elucidated by the [[Shlaer-Mellor]]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-MellorShlaer–Mellor Action Language (modified for UML){{Citation needed|date=February 2007}}. 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|Hype Cycle]]",<ref name=gartnermda>[https://web.archive.org/web/20060829123915/http://www.gartner.com/DisplayDocument?ref=g_search&id=494180&subref=simplesearch "Hype Cycle for Emerging Technologies, 2006"] $495.00</ref> and [[Forrester Research]] declaring MDA to be "D.O.A." in 2006.<ref name=forrestermda>[http://www.forrester.com/Research/Document/Excerpt/0,7211,39156,00.html "MDA Is DOA, Partly Thanks To SOA"] {{webarchive|url=https://web.archive.org/web/20071013004355/http://forrester.com/Research/Document/Excerpt/0,7211,39156,00.html |date=2007-10-13 }}</ref> Potential concerns that have been raised with the OMG MDA approach include:

* Incomplete Standards: The MDA approach is underpinned by a variety of technical standards, some of which are yet to be specified (e.g. an action semantic language for [[Executable UML|xtUML]]), or are yet to be implemented in a standard manner (e.g. a [[QVT]] transformation engine or a [[Platform-independent model|PIM]] with a virtual execution environment).<ref name=mdanoaslsyntaxone>[http://www.jot.fm/issues/issue_2003_01/column1 "UML - Unified or Universal Modeling Language? UML2, OCL, MOF, EDOC - The Emperor Has Too Many Clothes"]</ref><ref name=mdanoaslsyntaxtwo>[http://www.theserverside.com/tt/articles/article.tss?l=MDA_Haywood "MDA: Nice Idea. Shame about the..."]</ref>

* Vendor Lock-in: Although MDA was conceived as an approach for achieving (technical) 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.{{Citation needed|date=February 2007}}

* Idealistic: MDA is conceived as a forward engineering approach in which models that incorporate Action Language programming are transformed into implementation artifacts (e.g. executable code, database schema) 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 (and related standards) with subsequent transformation to a complete (executable) application.<ref name=eclipsemda>[http://alt.java-forum-stuttgart.de/jfs/2006/folien/A5_Schoenhage_Compuware.pdf "Bringing MDA to Eclipse, using a pragmatic approach"]</ref> This approach does, however, imply that changes to implementation artifacts (e.g. database schema tuning) 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".<ref name=forresterresponse>[http://www.bptrends.com/publicationfiles/04-06-COL-MDA-ResponseToForrester-Frankel.pdf#search=%22%22pragmatic%20MDA%22%22 "A Response to Forrester"]</ref> Pragmatic MDA blends the literal standards from OMG's MDA with more traditional model driven approaches such as [[round-trip engineering]] that provides support for adapting implementation artifacts (though not without substantial disadvantages).

Line 72:

* [[Model Transformation Language]]

* [[Modeling Maturity Levels]]

* [[Platform-independent model]]

* [[Platform-specific model]]

* [[Software factory]]