MDA模型驱动开发方法学
MDA模型驱动介绍
MDA模型驱动介绍模型驱动体系架构(Model Driven Architecture, MDA)是由OMG 提出的新的软件方法学,被面向对象技术界预言为未来几年里最重要的软件方法学。
模型驱动体系架构(MDA)把建模语言用作一种编程语言而不仅仅是设计语言,并以一种全新的方式将IT技术的一系列新的趋势性技术整合到一起。
这些技术包括基于组件的开发、设计模式、中间件、说明性约束、抽象、多层系统、企业应用整合以及契约式设计等。
模型驱动体系架构(MDA)的出现，为如何提高软件开发效率，如何增强软件的可移植性、协同工作能力、可维护性，以及如何提高文档编制的便利性指明了解决之道。
MDA概述MDA是“模型驱动体系架构”（Model Driven Architecture）的缩写。
它是由OMG定义的一个软件开发框架。
其关键之处是，模型在软件开发过程中扮演了非常重要的角色。
在MDA中，软件开发过程是由对软件系统的建模行为驱动的。
MDA开发生命周期和传统的生命周期并没有很大的不同。
MDA 的工件是形式化模型，也就是可以被计算机理解的模型。
下面列出的3种模型位于MDA的核心：· 平台独立模型（PIM）：具有高抽象层次、独立于任何实现技术的模型。
· 平台相关模型（PSM）：为某种特定实现技术量身定做，让你用这种技术中可用的实现构造来描述系统的模型。
PIM会被变换成一个或多个PSM。
· 代码：用源代码对系统的描述（规约）。
每个PSM都将被变换成代码。
传统上，从模型到模型的变换，或者从模型到代码的变换，主要是手工完成的。
与此相反，MDA变换总是由工具执行的，许多工具可以把PSM变换成代码，这并不令人惊奇。
MDA的创新之处是把PIM 到PSM的变换也自动化了。
软件开发是什么Alistair Cockburn在他的Agile Software Development一书中归纳了业界对软件开发的看法：以C.A.R Hoare为代表的数学观、以Bertrand Meyer为代表的工程观、以很多程序员为代表的手工艺观，还有一些程序员则认为软件开发是神秘的创造行为。
模型驱动的体系架构MDA
模型驱动的体系架构MDA模型驱动的体系架构（Model-Driven Architecture，MDA）是一种软件开发方法论，旨在实现使用模型来驱动软件系统设计和开发的过程。
它提供了一种将系统的关注点从实现细节转移到概念模型层面的方法，从而提高了系统的可维护性、可扩展性和可重用性。
MDA的体系架构包括三个核心层次：计算独立（CIM）、平台独立（PIM）和平台相关（PSM）。
2. 平台独立模型（Platform Independent Model，PIM）是MDA的中间层模型，用于描述系统的业务逻辑和功能。
PIM是通过将CIM转化为与具体平台无关的模型，以便能够在不同平台上进行重用和扩展。
PIM通常使用统一建模语言（UML）或其他领域特定语言（DSL）进行描述，包括类图、时序图等。
PIM的设计重点是在保持系统功能的不变的同时，将业务逻辑和实现细节分离。
3. 平台相关模型（Platform Specific Model，PSM）是MDA的底层模型，用于描述系统在具体平台上的实现细节。
PSM是通过将PIM转化为特定平台的模型，以便具体实现系统。
PSM可以是特定编程语言、框架或平台的规范，如Java、NET、Eclipse等。
PSM的设计重点是在满足系统需求的同时，考虑特定平台的约束和限制。
MDA的核心思想是通过模型的转换和转化过程，实现从业务需求到具体实现的自动化生成。
MDA使用模型转换技术将CIM转化为PIM，然后将PIM转化为PSM，最终生成可执行的代码。
MDA的优势在于提高了系统的可维护性和可重用性。
通过将业务逻辑和实现细节分离，在需求变更或平台切换时可以更快地进行适应和修改。
同时，MDA的模型驱动方法使得可以在不同项目间共享和重用已验证的模型和模型库。
然而，MDA也存在一些挑战。
首先，准确和完整地捕捉业务需求和领域知识是一项复杂的任务，需要专业的分析和建模技能。
其次，模型转换过程可能会引入一些不一致和错误，导致最终系统的质量问题。
什么是MDA
1
MDA的优势3
0011 0010 1010 1101 0001 0100 1011
• 互操作性 PIM中生成的多个PSM之间可能存在一定的关系，在MDA中， 它们被称为桥接器(bridges)。由于PSM针对一个特定的目标平台 ，所以它们相互之间不能够直接通信。无论如何，我们需要将一 个平台的概念转换到另一个平台的相关概念，这就是我们常说的 互操作性。MDA解决这一问题的方法是，不光从PIM生成PSM，还生 成连接PSM的桥接器。
• 以一中定义良好的符号表示的模型是理解企业级方案 系统的基础。 • 系统的构建能够围绕着一系列模型通过使用在模型之 间的一系列转换被组织的，并且能被组织到一个分层 的和转换的体系架构框架中。 • 以一系列元模型来描述模型的一种正式的支持能够使 在模型中有意义的集成和转换变得容易，并且是通过 工具实现自动化的基础。 • 接受和广泛采纳基于模型的方法需要工业的标准提供 开放性给客户，并鼓励l-driven Architecture
0011 0010 1010 1101 0001 0100 1011
学号：MG0933025 姓名： 沈达宇
1
什么是MDA?
0011 0010 1010 1101 0001 0100 1011
• 模型驱动架构（Model Drive Architecture MDA）是 一个软件开发架构，是由对象管理组织OMG（Object Manage Group）提出的基于模型驱动的新方法学。 • MDA 帮助公司应付软件开发中层出不穷的新标准、新 技术带来的快速变化。MDA是OMG发起的，目的是通过 把系统描述背后的逻辑与它的具体实现相分离，保证 组织机构的信息系统能够适应新的硬件和软件平台。 MDA改进了应用程序的可移植性、互操作性和平台独立 性，提高了开发人员的工作效率。
模型驱动开发（MDD）介绍
模型驱动开发（MDD）介绍 模型驱动开发Model Driven Development (MDD) 是⼀种以模型作为主要⼯件的⾼级别抽象的开发⽅法，模型在⼯具的⽀持下，被作为核⼼资产被转换成代码或者可运⾏配置。
现在软件业存在多种MDD开发⽅法，本篇将对MDD进⾏概要介绍。
定义 在过去多年，软件开发⾯临了多个挑战，新的需求和存在系统不断增长，系统也变得越来越复杂，以⾄于我们很难及时的构建它们。
为了解决这些问题， 就出现了很多新的⽅法，其中最突出的⼀个就是模型驱动开发。
MDD代表了⼀套理论和⼯业化软件开发的⽅法框架，在软件开发全⽣命周期中系统的的使⽤模型作为主要⼯件，它主要为了解决软件的两个根本危机：复杂性和变更能⼒ 。
使⽤模型作为⽂档和规范是有价值的，但是它需要严格的管理⽅式来确保模型是持续更新的。
在实际⼯作中，我们迫于时间压⼒经常会出现于实现不⼀致的模型，这对开发和项⽬其实是不利的。
⽽MDD的基本思想是让开发中⼼从编程转移到⾼级别抽象中去，通过模型转成代码或其他⼯件来驱动部分或全部的⾃动化开发。
模型是⼀种抽象的语⾔多种模型 模型是⼀种建模语⾔，它需要我们⾃⼰根据业务和技术需要去设计它，在架构、分析、设计、实现等不同阶段都会存在多种模型， 如企业架构模型、技术架构模型、领域模型、UI模型、数据库建模、业务规则模型、系统部署模型、测试模型等。
建模的过程是由不同阶段的成员来完成，有些模型之间有引⽤关系，应⽤软件通过所有⼈的建模⼯作⽽构建起来。
三个阶段1. 建⽴模型2. 建模3. 模型转换 模型和建模这两部分内容已经存在很多⽅法，它们在现在软件开发过程中已经处于重要位置，但是在需要哪些表达模型以及如何使⽤这些模型存在着差 异。
传统的模型只是⼀个设计蓝图，⽽MDD必须满⾜额外的要求，这些模型必须是可读的，也就是说必须存在第三个阶段，也就是模型转换：model to model (M2M) 和 model to code (M2C)优势提⾼产能：开发快、降低成本、提⾼质量可维护性：⾼级别模型与技术分类，技术架构的改变意味着只是模型的⼀种新的转换⼀致性：⼿⼯编码和架构决策容易出错，MDD可以确保⽣成的⼯件是⼀致的可重⽤性：模型、转换和架构都是可以重⽤的，由于架构和技术问题已经被解决，所以开发新功能的风险也低改善涉众沟通：模型忽略系统逻辑⾏为的底层实现，⽽直接展现问题域，这样可以保证和涉众使⽤同⼀种语⾔进⾏沟通改善设计沟通：模型与系统是匹配及时更新的，所以可以通过模型来改善系统设计的讨论和沟通捕获领域知识：可以加强领域专家对系统的直接影响，通过模型还可以帮助组织进⾏知识管理Business-IT对齐：关注问题域，关联技术域，⼀种业务和IT对齐的⽅法模型作为⼀种长期的核⼼资产：⾼级别的模型作为核⼼资产管理起来，只有在业务需求变更时才会进⾏更改推迟技术决策：应⽤开发在早期关注业务逻辑问题，对于技术选择可以推迟到后期提供及时的⽂档：通过模型可以⽣成很多同步的⽂档，利于与不同涉众进⾏交流经济模型MDD⽅法相关意图软件 Intentional Software。
MDA模型驱动架构
MDA模型驱动架构MDA（Model-Driven Architecture）是一种软件开发的方法或者框架，它将系统开发的焦点从代码编写转移到了模型的创建和转换上。
MDA的核心思想是将系统的抽象描述转换为具体实现代码的过程自动化，并且强调在不同开发阶段中的模型转换和模型分析。
在MDA中，开发者首先创建CIM，它是对问题域进行抽象，以便更好地理解和定义系统需求。
这个模型与具体实现无关，它只关注问题域的概念和规则。
接下来，开发者使用模型转换器将CIM转换为PIM。
PIM是CIM的具体实现，通常用于描述系统的功能、业务流程等。
PIM与实际的技术和平台无关，因此可以用于多个平台上的开发。
最后，开发者使用另一个模型转换器将PIM转换为PSM，PSM是与特定平台相关的模型，它描述了如何将PIM映射到实际的技术平台上。
PSM通常是使用特定的编程语言、框架或技术进行描述的，因此它是与特定平台的实现相关的。
使用MDA的好处在于解耦开发过程和具体实现。
通过将系统开发分为不同的模型层次，可以实现问题域和技术实现之间的分离，从而降低了系统的复杂性和维护成本。
此外，MDA还提供了模型转换和重用的机制，可以减少重复劳动，并促进在不同平台上的代码重用。
然而，MDA也存在一些挑战和限制。
首先，建立和维护模型需要额外的开发成本和时间。
其次，模型转换可能会引入错误和缺陷，因为在转换过程中可能会丢失一些信息或者忽略一些细节。
此外，MDA一般用于大型系统的开发，对于小规模项目来说，可能过于复杂和冗余。
总的来说，MDA是一种具有潜力的软件开发方法，它通过模型的创建和转换来实现系统的开发。
它可以提高系统的可维护性和复用性，并促进在不同平台上的代码重用。
然而，MDA也面临着一些挑战和限制，需要开发者在实践中权衡其利弊，并根据具体项目的需求来决定是否使用MDA。
mda建库原理
标题：MDA建库原理引言：MDA（Model Driven Architecture，模型驱动架构）是一种软件开发方法论，它提倡以模型为核心驱动软件系统的开发过程。
在软件开发领域，建库（Code Generation）是MDA的核心概念之一，本文将详细介绍MDA建库原理。
一、MDA概述1.1 MDA的定义MDA是由OMG（Object Management Group）提出的一种软件开发方法论，它将软件开发过程从代码层面抽象到模型层面。
MDA通过使用模型来描述问题域和解决方案，实现了从模型生成代码的自动化过程。
1.2 MDA的核心概念- 平台无关性（Platform Independence）：模型应该与特定的技术平台无关，以便可以在不同的平台上重用。
- 可追溯性（Traceability）：模型应该能够和源代码之间建立起双向的关联，从而可以跟踪模型和代码之间的变化。
- 自动化构建（Automation）：通过模型生成代码的自动化过程，减少了手工编写代码的工作量，提高了开发效率。
二、MDA建库的基本原理2.1 建库的概念建库是将模型转换为可执行代码的过程，也称为模型到代码的转换。
它是MDA的核心环节之一，通过自动化的方式将抽象的模型转化为具体的代码。
2.2 建库的基本过程- 模型定义（Model Definition）：首先需要定义模型，包括问题域模型和解决方案模型。
问题域模型描述了实际问题的概念和关系，解决方案模型描述了如何解决这些问题。
- 模型转换（Model Transformation）：将模型转换为中间表示形式，通常是一种称为PIM（Platform Independent Model）的模型。
- 平台特定模型转换（Platform Specific Model Transformation）：根据目标平台的要求，将PIM模型转换为PSM（Platform Specific Model）模型。
MDA白皮书-模型驱动开发和UML+2.0
白皮书模型驱动开发和UML 2.0传统编程方式的终结？本文档包含Telelogic AB专有信息。
未经Telelogic AB书面许可，不得使用本文档内的任何信息，不得复印、影印本文档的任何部分。
前言“模型驱动开发”——体会一下这几个词。
它们说出了这个不断变化的工业中一个新的改变。
这里不是说一种革命，而是一种缓慢的变化，但是肯定会渗透到我们开发系统的方式中。
这种推动将降低代码的重要性，并且专注于一些开发中的真正事情：最终的应用程序被期望怎样工作，并确保你能够根据客户的需求可靠地建立起它来。
模型驱动开发是更伟大视景MDA中的一部分。
MDA是模型驱动体系架构（Model-Dri ven Architecture）的简称，由对象管理组织OMG（Object Management Group）所驱动。
M DA表示了一种模型驱动开发方法的概念框架。
然而，尽管完整的MDA还没有成为现实，模型驱动开发现在已成为可能。
实际上，它已以较低级的形式存在了较长一段时间，所以我们并不是在做某种新的东西（当然，除非你在听某些市场人员的宣传）。
没有魔法如果模型驱动开发这么好的话，为什么不是每个人立刻加入到这个潮流中来呢？首先，模型驱动开发不是一个银子弹，能神奇地解决你所有的问题。
总有某人需要去实现系统的功能，并且还找不到任何工具来完成这一点。
所有你能发现的工具只是使这项工作更容易和直接一些。
第二，采用模型驱动开发，并不只是在开发项目的过程中更换一种工具。
它还必须和已根深蒂固的开发过程结合起来（如果没有的话，你就可以开始使用模型驱动开发了；否则你就只能改善当前的情况），但实际上更重要的是，你还会担心它对现有应用程序的影响。
决定改用基于模型的方法前确实需要有一些仔细的考虑，并且，一般说来，为了不影响当前的工作，你只会在新项目中改变开发方法。
第三，你还需要获得那些使用工具的人们的支持（你需要一些工具来应用模型驱动开发）。
开发人员常会认为“模型驱动开发不是编程”而回避它，并且当心他们的工作难于被接受。
模型驱动架构MDA浅述
模型驱动架构MDA浅述模型驱动架构（MDA，Model Driven Architecture）浅述袁峰 2007年7月10日前言西西弗斯是古希腊神话中的科林斯国王，他被罚将一块巨石推到山上，但无论西西弗斯如何努力，每次石头到达山顶之前都不可避免地滚下来，周而复始，永无休止。
前言西西弗斯是古希腊神话中的科林斯国王，他被罚将一块巨石推到山上，但无论西西弗斯如何努力，每次石头到达山顶之前都不可避免地滚下来，周而复始，永无休止。
在《应用MDA》一书中，作者Frankel将IT人比作现代版的西西弗斯，面对日新月异层出不穷的技术平台，不可避免地不断重复一些工作。
理想的MDAer，试图阻止这一悲剧的继续发生。
今天，我们通过分析MDA的概念，了解其内涵，看看MDA是否有希望完成这个艰巨的任务。
定义MDA是由OMG（Object Management Group，国际对象管理集团）[1]于2001年提出来的。
其核心思想是抽象出与实现技术无关、完整描述业务功能的核心平台无关模型（PIM，Platform Independent Model），然后针对不同实现技术制定多个转换规则，通过这些转换规则及辅助工具将PIM 转换成与具体实现技术相关的平台相关模型（PSM，Platform Specific Model），最后将经过充实的PSM 转换成代码。
通过PIM和PSM，MDA的目的是分离业务建模与底层平台技术，以保护建模的成果不受技术变迁的影响。
图1 MDA结构示意图[1]图1为MDA的结构示意图。
最内环是MDA的核心技术：MOF（Meta Object Facility，元对象设施）、CWM（Common Warehouse Metamodel，公共数据仓库元模型）和UML。
MDA的主要工作就是要把基于这些技术建立的PIM转换到不同的中间件平台上，得到对应的PSM。
中间环上给出的是目前主要针对的实现平台：CORBA、XML、JAVA、Web Services和.NET。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
MDA模型驱动开发方法学
主讲：张文（Jevons）一、传统软件工程方法学
传统的软件开发方式有许多模型，瀑布模型是其中最典型也最受诟病的一种，为了描述一个软件的生命周期，我们暂时以这种模型来阐述一下软件开发的过程。
软件开发要经历可行性分析研究，需求分析，总体设计（概要设计），详细设计，集成和测试等过程。
一个成熟的软件模型在这些环节都需要生成大量的文档，目前的很多CMMI工具能很好的管理好这些文档，比如将需求文档关联到后期的详细设计的过程或编码的过程等。
由于这个过程的生命周期太长，导致了开发过程中发现的问题不能及时反映到模型中来（虽然某些工具能跟踪到需求的变化），这个传统的工作过程虽然在目前遇到了极大的挑战，所以目前非常流行所谓的敏捷开发，本人也非常崇尚这种开发方式，但从我的经验来看，敏捷开发应该更多的体现在小项目或大项目的子模块的开发。
对于一个较大的项目而言，一定的设计和研讨还是必不可少的。
但如何解决之前所提到的开发周期过长，错误反馈不到位的诟病呢？
我认为，在详细设计阶段，如果能有一个好的开发模型将能极大的解决这种问题，而MDA就是这么一个开发模型。
二、MDA的过程
MDA，全称叫模型驱动开发，顾名思义，开发是由模型来推动的，即开发之前需要建立良好的模型。
也许大家现在有了一定的概念了，因为大家在大大小小的开发时都会画一些uml图，建立一定的模型，然后一个软件的雏形就应运而生了。
如果大家能做到这一步，恭喜你，说明你已经具备一定的设计能力了。
但我也要反问你，在工作过程中，请问有哪次的模型是你自己觉得非常满意的，或者说是你的得意之作吧。
面对这个简单问题，我想任何肯定回答都是牵强的，因为小的软件过程基本上不需要良好的设计，而大的软件过程，则很难做到良好的设计，如果没有一个良好的开发机制的话。
而MDA的开发方式则不一样，因为设计和编码可以融为一体，而且任何编码之前都是设计，任何设计都能生成编码，代码中也能访问到设计中的元数据定义，这就是MDA的神奇之处。
三、MDA的具体实施
金蝶的MDA方式建立在金蝶BOS的基础之上，BOS意思是Busingess Operation System，意思是业务定义系统，但远没那么牛，但在这个工具上实施MDA则是恰到好处。
一个典型的开发过程如下：首先定义实体，该实体具有一定的属性，而且从一定的父实体集成过来（如表单，基础数据等），这个实体也有一定的业务方法，在业务方法的定义中可以确定参数、返回值和异常，同时，可以在方法上定义EJB事务属性等。
这些方法都可
以在生成代码时自动生成本地接口，远程接口，工厂方法接口，及工厂方法，而实体则可导出为VO（值对象），VO Collection对象等。
实体是一类重要的模型设计，此模型设计好了后可以导出另外一种模型——表元数据，一种描述数据如何存储的元数据，简单的说就是表的设计。
其中可以按规范定义表名，字段名，主键名，外键名（虽然不建议建外键引用）。
根据这种模型的设计就可以导出在各种数据库中可以运行的数据库脚本。
注意，在金蝶，这种脚本被称作KSql，金蝶sql，因为金蝶有一个sql的中间层，可以屏蔽各种sql的差异。
目前的设计过程更多的是后台的设计，如果我们设计的东东是前后台都有的三层结构，那么还有客户端的设计，即UI设计。
金蝶BOS有一种元数据就称作UI设计，最典型的两种UI就是叙事簿（ListUI）和编辑（EditUI）界面了，前者是个数据的列表，后则则是一条数据的编辑界面，当设计这两种UI时，采用所见即所得的方式，可以精确定位UI中的组建，可以轻松绑定一个查询（Query）到ListUI或绑定一个VO到EditUI，并且可以从ListUI点击Edit按钮弹出EditUI，至于这之间数据是如何传递的，则由模型生成的框架代码来搞定。
经过简单的设计，一个软件的真实模型就出来了，运行模型生成的代码，客户端可以用ejb的方式远程访问服务器，可以在客户端浏览数据库中的数据，可以编辑或新增一条数据，可以准确的处理财务数字，可以定义更多的数据约束，甚至已经集成了权限，事务处理，日志服务，工作流，而我们目前所做的仅仅是设计而已。
完成了这一步，可以说我们建立了模型了，这就意味这可以驱动开发了。
工具生成的代码分抽象层和实现层，实现层是我们需要进一步完善的商业逻辑，而抽象层就是我们的框架代码。
商业逻辑我不想多说了，这是大家最熟悉的编码阶段。
经过一定时间的开发，现在问题来了，经过大家的日夜奋战，需求或产品人员一看，总体满意，但还有些地方不符合用户需求，这个时候怎么办？？
如果是传统的开发方式，可能要重新审视需求或重新修改需求，整个开发过程来重来，包括设计。
如果这样做的话，是一种负责人的开发方式，而我所见到的多数情况是，开发人员跟产品经理谈了后立即在代码中做若干次重大修改，最后达到了产品需求，而后也交互使用了，但你回过头来发现，之前做的设计也许跟现在的实现已经关系不大了，这种代码对日后维护来说是一场灾难。
现在说一下MDA的做法，当发现软件产品与需求不一致时，首先修改的是模型，注意是模型，而不是代码，任何改动都会首先体现在模型上，由于有工具支持，这种过程是迅速而安全可靠的。
模型对应的是框架代码，有着丰富的功能，很多时候，修改了一下模型，不用改写一行商业代码就能通过产品部门的审核了，而且这种软件产品具备了极高的可维护性，因为模型可以做反向工程成为可读性很强的uml图，其实只要看模型就能很直观的窥见整个软件的全貌了。