Content deleted Content added
m Dating maintenance tags: {{Citation needed}} |
mNo edit summary |
||
| (12 intermediate revisions by 10 users not shown) | |||
Line 1:
{{Short description|Software design approach}}
'''Model-driven
== 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
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 12 ⟶ 13:
=== 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>{{Cite web|url=http://www.omg.org/legal/tm_list.htm|title=OMG Trademarks | Object Management Group}}</ref>
== 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 25 ⟶ 28:
The OMG organization provides rough specifications rather than implementations, often as answers to [[Request for Proposal|Requests for Proposals]] (RFPs). 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.<ref>{{cite
An MDA tool may be a tool used to check models for completeness, inconsistencies, or error and warning conditions.
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.
Line 43 ⟶ 46:
=== MDA concerns ===
Some key concepts that underpin the MDA approach (launched in 2001) were first elucidated by the [[
* 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
* 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://
* 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 – 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>
==See also==
Line 75 ⟶ 72:
* [[Model Transformation Language]]
* [[Modeling Maturity Levels]]
* [[Platform-specific model]]
* [[Software factory]]
Line 83 ⟶ 79:
* [[Web engineering]]
* [[WebML]]
* [[Program Design Language]]
{{colend}}
| |||