陈宇
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。 这两种方式没有优劣之分,只是取决于你的应用目的而有不同的侧重。 - 商业软件不作讨论,因为手头 只有IBM rational modeler的评估版
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 并未覆盖整个开发过程。它没有支持诸如需求工程,测试等阶段的工作。 当然,所有这些阶段都是开发应用的基础阶段。 |