Model-driven architecture: Difference between revisions

Content deleted Content added
rm COI / citespam
Disadvantages: new; add source
Line 16:
 
== Model Driven Architecture topics ==
{{See also|Round-trip engineering}}
 
=== MDA approach ===
OMG focuses Model Driven Architecture® on forward engineering, i.e. producing code from abstract, human-elaborated modeling 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.).
Line 47 ⟶ 49:
* 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://www.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 mechanismsapproaches 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>
Line 53 ⟶ 55:
* 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>
 
== Controversies ==
== Code generation controversy ==
 
<!-- MDA isn't just about UML - this section needs to be rewritten -->
=== Code generation controversy ===
[[Automatic programming|Code generation]] (forward-engineering) from models 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 (programming)|template]] where predefined tokens are then replaced with program source code parts during the code generation process.
 
An[[UML]] often(if citedused criticismfor isMDA) thatdiagrams thespecification UMLwas diagramscriticized justfor 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".<ref>http://www.developerdotstar.com/mag/articles/reeves_design_main.html by Jack W. Reeves</ref><ref>[{{Cite web |last=Reeves |first=Jack W. |date=1992 |title=What is software engineering |url=http://www.bleading-edge.com/Publications/C++Journal/Cpjour2.htm Bleading|access-Edge<!date=2023-07-25 Bot|website=www.bleading-edge.com generated|publisher=C++ title -->]Journal}}</ref>
 
== Disadvantages ==
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".<ref>http://www.developerdotstar.com/mag/articles/reeves_design_main.html by Jack W. Reeves</ref><ref>[http://www.bleading-edge.com/ Bleading-Edge<!-- Bot generated title -->]</ref>
There is a serious risk that the generated code will rapidly differ from the model or that the reverse-engineered model will lose its overview or a mix of these two problems as result of cycled reengineering efforts.<ref>{{Cite web |title=Help - |url=https://www.modeliosoft.com/modelio-help/41/en/index.jsp?topic=/csdesigner-doc/html/Csdesigner_choose_functional_mode_round_trip.html |access-date=2023-07-25 |website=www.modeliosoft.com}}</ref>
 
==See also==
Line 84 ⟶ 90:
* [[Web engineering]]
* [[WebML]]
* [[Program Design Language]]
{{colend}}