Editing Model-driven architecture (section)

=== MDA concerns ===
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){{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 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).
* Specialised Skillsets: Practitioners of MDA based software engineering are (as with other toolsets) required to have a high level of expertise in their field. Current expert MDA practitioners (often referred to as Modeller/Architects) are scarce relative to the availability of traditional developers.<ref name=amblermda>[http://www.agilemodeling.com/essays/readyForMDA.htm "Are You Ready For the MDA?"]</ref>
* OMG Track Record: The OMG consortium who sponsor the MDA approach (and own the MDA trademark) also introduced and sponsored the CORBA standard which itself failed to materialise as a widely utilised standard.<ref name=corba>[http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=396 "The Rise and Fall of CORBA"] {{webarchive|url=https://web.archive.org/web/20081202033636/http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=396 |date=2008-12-02 }}</ref>
* Uncertain Value Proposition (UVP): 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 (program) for a particular computing platform (e.g. .NET). Thus an application that has been successfully developed via a pure MDA approach could theoretically be ported to a newer release .NET platform (or even a Java platform) in a deterministic manner &ndash; although significant questions remain as to real-world practicalities during translation (such as user interface implementation). 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 (e.g. xtUML) is more abstract (than, say, Java or C#) and exists interwoven with traditional UML artifacts (e.g. class diagrams). Whether programming in a language that is more abstract than mainstream [[Third-generation programming language|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.<ref name=mdasim>[https://arxiv.org/ftp/arxiv/papers/1011/1011.6671.pdf "Avoiding Another Green Elephant"]</ref>