|
<name></name>陈宇
2005 年 8 月
MDA的概念来自于OMG的规范，按照它的说法，MDA提供了一种开放的、供应商中立的 方法以应对商业与技术变化的挑战。实际上，在真正应用这种技术的时候，开发人员 面临着更大的挑战，就是需要在面向对象（OO）开发的基础上加入以模型为中心的思想。
1 I.MDA概述
1.1 定义
MDA的概念来自于OMG的规范，按照它的说法，MDA提供了一种开放的、供应商中立的 方法以应对商业与技术变化的挑战。实际上，在真正应用这种技术的时候，开发人员 面临着更大的挑战，就是需要在面向对象（OO）开发的基础上加入以模型为中心的思想。
MDA
是把建模语言作为编程语言来使用而不仅仅作为设计语言， 用模型语言编程能够带来提升生产力，软件质量以及更长远的好处。
1.2 目标
真正达到重用模型，实现以模型为中心的开发方式和使模型真正成为可复用资产。
对于厌倦了一遍遍在编码层解决在建模的抽象层中同样的问题提出彻底的解决办法。
最小成本适应不同平台间的迁移。
1.3 相关概念
UML、MOF、XMI、JMI、XML、J2EE、EJB、.NET、PIM、PSM
1.4 关于MDA的误解
1) MDA不是代码自动生成的规范，相反它的目标是尽量减少自动生成的代码。
2) MDA不是代替RUP,XP等软件工程的传统开发过程，而是对这些开发过程一个有益的补充，特别是直接将分析设计阶段所产生的模型应用于编写程序，并最终影响部署后的系统行为方式。
3) 你所说的这种MDA实现还没有达到开发企业级应用的阶段，换句话说，根本不实际。其实，现在不仅仅有商业化的实现，也有很优秀的开源MDA平台，例如，openMDX
1.5 其他介绍文章
* An introduction to Model Driven Architecture (Part I)
See document: 3100.html
* An introduction to Model Driven Architecture (Part II)
See document: index.html
* An introduction to Model Driven Architecture (Part III)
See document: index.html
2 II.MDA开源产品比较
对于MDA的实现来说，现在有两种不同的途径：I）使用模型驱动应用开发过程；II）直接利用模型驱动运行时应用系统的行为方式。前一种实现，大部分支持从UML模型转换的代码生成工具都可以归入此类，例如AndroMDA，而后一种实现就比较少，例如openMDX。
这两种方式没有优劣之分，只是取决于你的应用目的而有不同的侧重。
2.1 AndroMDA
AndroMDA的功能非常强大，主要用途在于从UML模型生成Hibernate,EJB,Spring,WebServices,和Struts等框架标准对应的代码， 在开发过程的建模阶段可以快速生成可运行原型，就此而言它是非常实用有效的工具，但是它的代价就是增加了很多对应各种框架类的 stereotype,这样的模型事实上已不能再算作PIM了，这样既不利于平台的迁移和模型的复用。而openMDX则仅仅使用了两个用于 语义描述的stereotype,这样的模型显得更加中立，更面向业务建模的视角。
在Struts和Spring已经成为事实上的J2EE框架标准的情况下，AndroMDA能够满足很多J2EE项目的框架要求，并且节约了很多重复性的编码工时，特别是，相对于采用手工编写此种代码，避免了可能出现的"手误"。
AndroMDA的长处也正是它的短处，因为完全面向J2EE平台开发，对于通用、中立的类型没有定义，也缺少对于属性的特性支持，比如持久性属性和导出属性的区分。在模型的表达上，仍然是更倾向于从技术框架的角度进行建模和描述系统行为。
另外还有一个通常的"代码生成器"都有的问题，就是对于模型的修改生成会覆盖掉手工修改的代码， 这仅仅是因为没有哪个流行的架构会完全采用JMI或者接口编程的方式，这样就很难避免在第一次生成代码之后，需要小心再次生成模型可能会影响到的手工编写的代码。
2.2 openMDX
openMDX拥有自己独立的中立性框架，支持J2EE、.Net和CORBA平台等，同时具有极大的灵活性和扩展性。基于openMDX的系统，从桌面应用程序到完全分布式应用的转化, 不需要改变一行代码。在openMDX所使用的模型中，也没有采用私有的模型标签和功能增强。openMDX没有提供UML模型工具，但是支持所有主流的UML模型工具:Rational Rose, MagicDraw, Poseidon, Together等。现有的插件已经提供了基本功能: 持久性,审核，历史记录和角色以及强大的日志功能。携带了一个集成的完整的界面生成引擎。
但是缺点也是显见的，由于采用的框架完全围绕模型来运行和部署，迫使开发人员从习惯的开发方式和设计思考模式转变到完全不同的重心上。例如，不再首先考虑UI，业务层，持久层所采用的方式和数据库结构等在以前的开发过程中作为核心的部分，而是首先考虑业务模型中的对象及其关联关系，当然这在真正的业务建模中是核心部分，OpenMDX将模型的这种核心地位延伸到了开发、部署和交付使用阶段。
另外，openMDX也没有提供一个IDE来支持整个开发测试和配置应用。
对于这种苛刻的MDA实现方式，下面将介绍对于企业应用系统来说所带来的利益。
3 III.openMDX带来的利益
3.1 完全开源
开源软件的好处在这里就不作讨论了，OpenMDX提供了除了源代码以外更多的东西，包括所有模型文件，API文档，以及几个不同使用方式的实例，甚至还有基于openMDX的完全开源的项目--一个企业级CRM应用，openCRX。
3.2 提供了基于标准（J2EE、.NET等）的基础架构
基于openMDX的应用可以很轻松的移植到多个不同平台，采用了MOF，JMI，XRI，XML等标准和协议，不用过多考虑会被绑定于某一平台。
3.3 快速开发、部署和弹性配置
建立了成熟模型之后，开发测试的工作量降低到了难以想象的地步，举例来说，openCRX总共两百天的开发过程中，建模占了100天，界面设计定制用了70天，10天用于实现，20天用于测试部署。
3.4 极强的系统互操作性
openMDX平台上发布的功能模块，对于数据的导入导出都是基于Schema-XML，而且可以方便的发布为Webservice，跟其他异种系统的交互达到了轻松自如的地步。
3.5 降低总体拥有成本（TCO）
不仅仅因为平台本身是开源软件，而且更因为基于MDA规范，使得模型的重用得以实现，并且可以积累对于企业更有价值的部分--业务模型。对模型变更的快速响应，能够在几分钟内实现从模型修改到生成代码并部署运行的整个开发过程。
4 IV.基于openMDX的开发过程
4.1 openMDX开发过程简介
openMDX 是一个OMG Model Driven Architecture(MDA)为起始的高级实现.openMDX是一个工业化的，开放的，模型驱动的运行时引擎和平台独立模型(PIMs)框架。 不象大多数商业工具，openMDX 没有实现PIM到PSM映射的方法。 而是提供了一个普通的，分布式的对象引擎（作为PIM 平台）。商业逻辑(模型的导出属性和方法)是作为插件添加进去的。下图说明了OpenMDX在软件开发过程中所起到的作用：
-
建模: 创建PIM。当前版本中, openMDX 仅仅需要与MOF兼容的类图中的静态模型图，其他对系统行为建模的图则暂不被支持，对于UML动作语义和活动图和状态图的支持将在以后的版本中作为可选项加入。 openMDX 提供了工具将兼容MOF的模型映射, 即采用了JMI和 XMI 的映射。由MOF 映射所定义,类图表达了一个组件对外的行为规范, 例如组件的接口。
-
开发: 在这一步中开发者编写客户端和服务端的代码。要注意，就像以后会看到的，现在手工编写的代码是平台独立的。
-
部署: 将生成的MOF 映射, 手工编写的代码, 部署信息和openMDX运行时环境，在部署阶段集成在一个可运行、可部署的应用服务平台上，例如，J2EE应用服务器、.Net服务器等。
openMDX 并未覆盖整个开发过程。它没有支持诸如需求工程，测试等阶段的工作。 当然，所有这些阶段都是开发应用的基础阶段。
4.2 openMDX模型基础及Hello-World实例简介
在openMDX的发布包中，有一个Hello-World的实例，在文档中有一篇《openMDX Quick Start》是专门介绍这个实例的配置运行方法的，在这里不再赘述，只是讨论以下几个要点，为下一篇的深入介绍做好基本概念的准备：
1．在openMDX中，代码与模型的关系
2．在基于openMDX的模型中所用到的一些UML概念
3．w3c的基本类型介绍
4．openMDX中所用到的stereotype的介绍
5．Hello-World的模型
1．在openMDX中，代码与模型的关系
在基于openMDX的开发过程中，一旦模型创建完毕，并符合openMDX的建模规则，即可使用Ant构建生成基于openMDX的工程。其中，使用generate target可以导出模型，分别生成对应JMI和XMI标准的文档，其中前者是java代码，后者是XML格式的模型定义文件。搭建起Hello-World在Eclipse中的工程环境之后，可以很清晰的看出，自动生成代码和手工编写的代码是分放在两个不同的目录中，而对于导出属性和操作则是通过delegate(委托)的方式去执行手工编写代码的，而其中的委托关系，是以package（包，包括java类中的包和UML/MOF模型中的包的含义）为单位去配置映射关系的。关于JMI和XMI在openMDX中的具体作用和运行调用关系，请参考《openMDX Introduction》。
2．在基于openMDX的模型中所用到的一些UML概念
openMDX的模型是兼容MOF标准的，另外加入了对于quarlifier（限定符）的支持。如果你对UML/MOF建模已经非常了解，那么可能只需要熟悉几种openMDX中常用的关联关系和设计惯例。由于openMDX采用了XRI协议访问所有的应用资源（包括模型、包、类、对象/实例），所以所有类图模型中所定义的实体类都必须被每个包中的Segment直接或者间接的包含并且是可导航的，而其他作为参数或者返回结果定义的类（stereotype为Struct）和作为抽象类用于被继承的类（stereotype为root）则可以单独存在。
3．w3c的基本类型
在openMDX的模型中，有一个org::w3c的包，其中定义了几种标准的原始类型，是作为模型中的基本数据类型存在的，并且具有中立性，由OpenMDX平台负责对这几种基本类型到具体语言平台的映射。
4．openMDX中所用到的stereotype的介绍
"0..1" (针对属性的修饰版类, 表明这是个可选的属性)
"list" (针对属性的修饰版类, 表明这是一个没有空值的排序集合)
"set" (针对属性的修饰版类, 表明这是一个不重复的未排序集合)
"sparsearray" (针对属性的修饰版类, 表明这是一个允许空值的散列数组)
"stream" (针对属性的修饰版类,对于类型是org::w3c::string 和org::w3c::binary 的属性，表明这是字符或者二进制流)
openMDX中的每个包含关系都需要一个类型为org::w3c::string 的quarlifier(限定符) "alias" （针对类的修饰版类,允许通过别名引用到一个给定类）
"root" （针对类的修饰版类，允许其他"root"或者非"root"类由此类继承
"primitive" （针对类的修饰版类，表明了此类是原始类型，并由openMDX核心所支持
5．Hello-World的模型
下图是此实例的初始模型图：
注意在poseidon工具界面左方的面板里面，HelloWorld类的节点下面重复性的包含了SayHelloResult类的定义，如下图所示：
因此，在做模型扩展的时候，需要注意，增加了SayGoodbyeResult类之后，同样要在HelloWorld类中复制一份。否则，在使用Ant构建工程时，会报不匹配建模规则的错误。好在使用其他工具，比如Rose时，不会有这样麻烦的需求。
Hello-World的模型非常简单，没有涉及到类与类之间的关联以及对象实例的持久化等问题，这些将在后面的部分进一步讲述。
|
