模型驱动的体系结构
模型驱动体系结构（ MDA ）是一种用于开发软件系统的软件设计方法。它为规范结构提供了一组指南，这些准则表示为模型。模型驱动的体系结构是一种域工程，并支持软件系统模型驱动的工程。它是由对像管理小组（OMG）于2001年启动的。
概述
Model DriveArchitecture®（MDA®）“提供了一种从模型和体系结构中获得价值的方法，以支持物理，组织和IT系统的整个生命周期”。模型是系统抽象的（表示）。 MDA®通过以不同级别的抽象级别生产模型来提供价值，从概念视图到最小的实现细节。 OMG文献讲述了三个这样的抽像或体系结构观点：与计算无关的模型（CIM），独立于平台的模型（PIM）和平台特异性模型（PSM）。 CIM在概念上描述了一个系统，PIM描述了系统的计算方面，而无需参考可用于实施它的技术，并且PSM提供了实施系统所需的技术细节。不过，《 OMG指南》指出，这三个架构观点很有用，但只是许多可能的观点中的三个。
OMG组织提供规格而不是实施，通常是对提案请求（RFP）的答案。实施来自私人公司或开源组。
相关标准
MDA模型与多个标准有关，包括统一建模语言（UML），元对象设施（MOF）， XML元数据交换（XMI），企业分布式对象计算（EDOC），软件过程工程工程MetAmodel （SPEM） ，以及普通的仓库元模型（CWM）。请注意，模型驱动的体系结构中的“体系结构”一词并不是指为建模的系统的体系结构，而是指作为MDA技术基础的各种标准和模型形式的体系结构。
可执行的UML是MDA出生时使用的UML轮廓。现在，OMG正在促进FUML 。 （FUML的动作语言是Alf。）
商标
对像管理小组在“模型驱动的架构及其首字母缩写MDA”中持有注册的商标，以及诸如基于模型的应用程序开发，基于模型驱动的应用程序开发，基于模型的应用程序开发，基于模型的应用程序，基于模型的编程，模型驱动的系统，模型驱动系统，，模型驱动系统，基于模型的应用程序开发，诸如术语的商标。和别的。
模型驱动的建筑主题
MDA方法
OMG将模型驱动的体系结构®集中在前进工程上，即从抽象的，人类修饰的建模图（例如类图）中生成代码。 OMG的ADTF（分析和设计工作组）小组领导了这一努力。有些幽默，该小组选择了ADM（MDA向后）来命名逆向工程的研究。 ADM解码以建筑为导向的现代化。 ADM的目的是为旧系统的基于模型的逆向工程制定标准。知识发现元模型（KDM）是这些工作中最远的，并用各种资产（程序，规格，数据，测试文件，数据库模式等）描述了信息系统。
由于用来实现设计的概念和技术，以及用于实现建筑的概念和技术以自己的节奏发生了变化，因此使系统开发人员可以从两个领域中最合适，最合适的选择。该设计解决了功能（用例）要求，而体系结构提供了基础架构，通过这些基础结构，可以实现非功能性要求，例如可伸缩性，可靠性和性能。 MDA设想，代表实现功能需求的概念设计的平台独立模型（PIM）将在实现技术和软件体系结构中幸存下来。
对于模型驱动的体系结构而言，特别重要的是模型转换的概念。模型转换的特定标准语言已由OMG称为QVT 。
MDA工具
OMG组织提供粗略的规格而不是实施，通常是对提案请求（RFP）的答案。 OMG记录了称为MDA指南的文档中的整体过程。
基本上，MDA工具是一种用于开发，解释，比较，测量，验证，转换等的工具。模型或元模型。在下一节中，“模型”被解释为含义任何类型的模型（例如UML模型）或metamodel（例如CWM Metamodel）。在任何MDA方法中，我们都具有两种模型：初始模型是由人类代理人手动创建的，而派生模型是由程序自动创建的。例如，分析师可以通过观察到一些松散的业务状况创建UML初始模型，而Java模型可以通过模型转换操作自动从该UML模型衍生而来。
MDA工具可能是用于检查模型的完整性，不一致或错误和警告条件的工具。
某些工具执行以上列出的功能之一。例如，某些创建工具也可能具有转换和测试功能。还有其他仅用于创建的工具，仅用于图形演示，仅用于转换等。
OMG规格的实施来自私人公司或开源组。 OMG规格实施的一个重要来源是Eclipse Foundation （EF）。 OMG建模标准的许多实现都可以在Eclipse建模框架（EMF）或图形建模框架（GMF）中找到，Eclipse Foundation也正在开发其他各种配置文件的其他工具，例如GMT。 Eclipse遵守OMG规格通常并不严格。例如，对于OMG的EMOF标准而言，EMF与其生态实现近似。可以在实施QVT标准的M2M项目中找到更多示例或实施MOF2Text标准的M2T项目。
应该注意不要混淆MDA工具列表和UML工具列表，前者更广泛。通过区分“可变元模型工具”和“固定的元模型工具”，可以使这种区别更加笼统。 UML案例工具通常是“固定的元模型工具”，因为它仅与给定版本的UML MetAmodel（例如UML 2.1）一起工作。相反，其他工具具有内部通用功能，使其可以适应任意的元模型或特定类型的元模型。
通常，MDA工具将重点的基本体系结构规范集中在某些情况下，尽管这些工具是独立的（或平台独立的）。
体系结构规范的简单示例包括：
- 选择许多受支持的参考体系结构之一，例如Java EE或Microsoft .NET ，
- 在更优质的层面上指定体系结构，包括选择演示层技术，业务逻辑层技术，持久技术和持久映射技术（例如对象相关映射器）。
- 元数据：有关数据的信息。
MDA关注
在1980年代后期，Shlaer-Mellor方法首先通过Shlaer-Mellor方法阐明了一些基于MDA方法的关键概念。实际上，一些供应商通过调整原始的Shlaer-Mellor Action语言（为UML修改）来桥接MDA方法的关键技术标准（用于可执行UML的动作语言语法）。但是，在此期间，MDA方法尚未获得主流行业的接受。由于Gartner集团仍将MDA确定为2006年“炒作周期”的“兴起”技术，而Forrester Research在2006年宣布MDA为“ DOA”。通过OMG MDA方法提出的潜在问题包括：
- 不完整的标准：MDA方法的基础是各种技术标准的基础，其中一些标准尚未指定（例如， XTUML的动作语义语言），或者尚未以标准方式实施（例如QVT变换引擎或具有虚拟执行环境的PIM ）。
- 供应商锁定：尽管MDA被认为是实现（技术）平台独立性的一种方法，但当前的MDA供应商一直不愿设计其MDA工具集可互操作。这样的结果可能会导致供应商锁定的人，因为那些采用MDA方法的人。
- 理想主义：MDA被认为是一种向前的工程方法，其中包含动作语言编程的模型通过完全或部分自动化的“生成”步骤转换为一个方向的实现工件（例如可执行代码，数据库架构）。这与OMG的愿景相吻合，即MDA应允许对问题域（及相关标准）的完全复杂性进行建模，并随后转换为完整的（可执行性）应用程序。但是，这种方法确实意味着不支持实施工件的变化（例如数据库架构调整）。在这种情况下，这种转变后“适应”实施工件是必要的，这是一个问题。在所谓的“实用MDA”的兴起中，已经看到了某些现实世界部署的完整MDA方法可能太理想主义的证据。务实的MDA将OMG的MDA的字面标准与更传统的模型驱动方法（例如往返工程）相结合，该方法为适应实施工件提供了支持（尽管并非没有实质性的缺点）。
- 专业技能：基于MDA的软件工程的从业者（与其他工具集一样）在其领域具有高水平的专业知识。相对于传统开发人员的可用性，当前专家MDA从业人员（通常称为Modeller/Architects）很少。
- OMG往绩记录：赞助MDA方法（并拥有MDA商标）的OMG财团还引入并赞助了Corba标准，该标准本身未能作为广泛使用的标准实现。
- 不确定的价值主张（UVP）：如所讨论的，MDA的愿景允许将系统作为抽像模型的规范，该模型可以实现为特定计算平台（例如.NET）的具体实现（程序）。因此，从理论上讲，通过纯MDA方法成功开发的应用程序可以以确定性的方式移植到较新的版本.NET平台（甚至是Java平台） - 尽管在翻译过程中仍然存在重大问题（例如，在翻译过程中仍然存在重大问题（这样）作为用户界面实现）。对于特定采用者而言，这种能力是否代表着重要的价值主张仍然是一个问题。无论如何，在评估这种方法时，通过“替代编程”寻求价值的MDA采用者应该非常小心。任何给定问题领域的复杂性将始终保留，并且需要与任何其他方法一样在MDA中进行业务逻辑编程。与MDA的不同之处在于，所使用的编程语言（例如XTUML）更抽象（例如Java或C＃），并且与传统的UML伪像（例如类图）交织在一起。与主流3GL语言更抽象的语言编程是否会导致质量更高，成本更低或更快交付的系统，这是一个尚未得到充分回答的问题。
- MDA被认为是将各种独立开发标准化解决方案融合在一起的可能方法。对于模拟社区，建议作为基于商业和行业的替代品，替代了另一个美国国防部规定的标准。