（计算机应用技术专业论文）模型驱动的信息系统开发.pdfVIP

摘要 随着软件产业的不断发展，软件生产过程中又出现一些阻碍软件产业进一步发展的问 题。为处理这些问题，对象管理组织o m g 近两年提出了基丁模型驱动的体系结构( m o d e l d r i v e na r c h i t e c t u r e ，m d a ) 技术，这是一种通过模型驱动米建立软件系统的方法。目前， m d a 的研究是建立在m o f 、u m l 、c w m 等基础之上，虽然目前没有形成实用技术，但模 型驱动软什开发的思想，对于软件系统的开发还是有指导性意义的。 本文描述了软件发展的过程，通过分析m d a 的局限性，提出了一种应用层面上的模型 驱动软件开发方法从而提高了软件的生产率和软件质量，并延长了软件的寿命。该方法根 据系统开发中积累的经验，对现实世界事物的活动过程进行抽象，形成模型，使用模型驱动 的方式构建软件系统。文章以高校信息系统为例描述了一个基于模型驱动的信息系统建设 方案。该方案将系统建设分成模型构造和系统构建两个阶段。本文详细描述了模型构造的过 程，该过程建立了业务层模型和平台层模型，以及定义两者之间的映射关系，并通过平台层 模型中的应用定义文档，将业务层模型映射到晟终代码中。在系统构建阶段。通过对业务层 模型进行动态的修改和配置，制导代码的生成，从而用模型驱动的方式实现信息系统。论文 最后，对模型驱动的信息系统开发方法进行了展望。 关键字：m d a 、模型驱动、业务层模型、平台层模型、应用定义文档 t h ec o n s t r u c t i o no fi sb a s e do nm o d e ld r i v e n a b s t r a c t s e v e r a lp r o b l e m se m e r g ea sn e w d r a g so n t h ef u r t h e rp r o g r e s so fs o f t w a r ei n d u s t r y i no r d e r t os e t t l et h e s ep r o b l e m s ，t h eo b j e c tm a n a g e m e n tg o v e r n m e n t ( o m g ) p r e s e n t san e w t e c h n o l o g y c a l l e dm o d e ld r i v e na r c h i t e c t u r e ( m d a ) ，w h i c hs h o w st h ei d e at ob u i l ds y s t e m st h r o u g hm o d e l s a tp r e s e n t ，t h er e s e a r c ho fm d ai sm a i n l yg r o u n do nm o f , u m la n dc w m ，w h i c hs e e m st ob e r a t h e rt h e o r e t i c a lt h a ns u i t a b l ef o rt h es o l u t i o no nt h ea p p l i c a t i o nl e v e l h o w e v e r , t h et h o u g h to f m d ai si n s t r u c t i v e i nt h i sp a p e r , w ef i r s tr e v i e wt h ed e v e l o p m e n to fs o f t w a r e ，t h e n ，w ep r o p o s eam o d e ld r i v e n s o f t w a r e d e v e l o p i n gm e t h o do na p p l i c a t i o n - l e v e lt h r o u g ht h ea n a l y s i s o nl i m i t a t i o no fm d a ， w h i c he n h a n c e st h es o f t w a r ep r o d u c t i v i t ya n dq u a l i t y , a n dp r o l o n g st h es o f t w a r el i f e a c c o r d i n gt o t h ee x p e r i e n c ea c c u m u l a t e di ns y s t e md e v e l o p i n g ，o u rm e t h o da b s t r a c t st h er e a lw o r l d ，f o r m s m o d e l sa n dc o n s t r u c t ss y s t e m so nt h e s em o d e l s t a k i n gt h ec a m p u s1 sa sa 1 1e x a m p l e w ed e s c r i b e t h ec o n s t r u c t i o no fa ni n f o r m a t i o ns y s t e m ( i s ) b a s e do nm d a o u rs c h e m ad i v i d e st h e c o n s t r u c t i o ni n t ot w o s t e p s ，t h a ti s ，m o d e lc o n s t r u c t i o na n ds y s t e mc o n s t r u c t i o n w ee l a b o r a t et h e p r o c e s so f m o d e lc o n s t r u c t i o n ，w h i c hs e t su p t h eo p e r a t i o nm o d e lc o n s t r u c t i o na n dp l a t f o r mm o d e l c o n s t r u c t i o n ，a n dd e f i n e st h e i rr e l a t i o n s h i p s i ta l s om a p st h eo p e r a t i o nm o d e li n t of i n a lc o d e s b a s e do nt h ed o c u m e n td e f i n e di np l a t f o r mm o d e l i ns y s t e mc o n s t r u c t i o n ，w ec o u l dg e n e r a t e c o d e s b ym o d i f y i n ga n dc o n f i g u r i n gt h eo p e r a t i o nm o d e l ；t h u s ，r e a l i z et oc r e a t ei su s i n g m d a i n t h ee n d ，w ed i s c u s st h ef u t u r eo fm d a - b a s e d1 s k e yw o r d s ：m d a ( m o d e ld r i v e na r c h i t e c t u r e ) ，m o d e ld r i v e n ，o p e r a t i o nm o d e l ，p l a t f o r m m o d e l ，a p p l i c a t i o nd e f i n i t i o nd o c u m e n t i i 1 y6 4 4 7 0 9 东南大学学位论文 独创性声明及使用授权的说明 一、学位论文独创性声明 本人声明所呈交的学位论文是我个人在导师指导下进行的研究工作及取得的研究成果。 尽我所知，除了文中特别加以标注和致谢的地方外，论文中不包含其它人已经发表或撰写过 的研究成果，也不包含为获得东南大学或其它教育机构的学位或证书而使用过的材料。与我 一同工作的同志对本研究所做的任何贡献均已在论文中作了明确的说明并表示了谢意。 二、关于学位论文使用授权的说明 签名 日期 眄枞 p d 4 铮j j ，o 且 东南大学、中国科学技术信息研究所、国家图二悟馆有权保留本人所送交学位论文的复印 i 4 ： 1 1 电子文档，可以采用影印、缩印或其它复制手段保存论文。本人电子文档的内容币纸质 论文的内容相一致。除在保密期内的保密论文外，允许论文被查阅和借阅，可以公布( 包括 刊登) 论文的全部或部分内容。论文的公布( 包括刊登) 授权东南大学研究生院办理。 签名：蝌 东南大学硕士学位论文 1 1 软件开发过程 第一章、引言 本世纪中叶软件产业从零开始起步，在短短的5 0 年里迅进发展成为推动人类社会发展的龙头产 业。作为新兴产业，软件开发业在发展的过程中也遇到行业方法学上的问题。经历了：十世纪 、 七十年代产生的“软件危机”( s o f t w a r ec r i s i s ) 后，1 9 6 8 年秋，北约的科技委员会第一次提出了 软件工程( s o f t w a r ee n g i n e e r i n g ) 的概念。软件工程经过3 0 多年的发展。人们针对软件危机的表 现和原因。经过实践和总结从而认识到：按照工程化的原则和方法组织软件开发工作，是摆脱软件 危机的一个主要出路。按照工程化的原则和方法，软件开发被视为一个问题的解决过程，其中，“需 求”可以被认为是相关领域有待解决的问题，软件工作者捕获“需求”、理解面l j 自的问题，提出问 题的解决方案并实现它。由此，人们提出了软件生命周期的概念，它通常包括以下几个阶段： 需求调查：需求调查阶段，根据目标来确认需要处理的问题，回答“问题是什么”，“它 是否值得解决”等。这阶段得到对需要处理问题的详细描述。 分析：分析阶段，分析和理解需求，了解软件应用领域，以及需求的功能、行为、性能和 接口，理解需要构造程序的本质。需求调查和分析都需要有文档和用户进行交流。 设计：设计阶段，将需求转换成软件表示，集中于四个完全不同的要素上：数据结构、软 件体系结构、界面表示和算法细节。设计也是文档化的。 编码实现：编码实现阶段。将设计变成机器可读的形式，用计算机编程语言对它进行描述。 测试：测试阶段，对程序的测试，保证程序的正确性。 部署和维护：部署和维护工作使得软件程序对用户可用，并且保证程序的保持正确性。 此外，现在还有很多其它类型的生命周期模型，例如瀑布式、迭代式开发模型，它们都需要涉 及上述一些阶段的活动。总的来说，当今软件开发过程主要是以非形式化的需求驱动软件的开发 如图1 所示： 软件开发理论上是一个迭代的过程开发人员喜欢走的捷径 1 2 存在的问题 图1 当今软件开发过程 通过以上工程化的软件开发方法解决一些困扰软件开发过程的问题，但是，随时代发展，软件 开发领域又出现新问题。当前，建立软件系统仍需要训练有素的程序员进行艰难琐细的工作，而这 些开发人员依然是昂贵的资源，这使得如果对软件开发项目采取“人海战术”的方案将代价高昂。 另外，许多软件开发的投资带米的是令人失望的结果：很多的项目以失败而告终；其它一些项目大 大超出了预算，以至于管理层只好中止它们；有些系统在一开始看上去很成功，但是时间久了，它 们就被证明是不稳定的，或者不具有灵活的扩展性。产生这些令人失望的结果的原因体现在以下几 方面： l 东南大学硕= e 学位论文 1 2 1 需求的不断变更 由于经济全球化和竞争越来越激烈，导致在研发应用软件系统时，需要考虑的因素越来越多。 由于竞争的残酷，企业的管理与业务经常变化。虽然，应用软件开发人员与客户交互需求时总会规 定应用系统实现的范围，并把该范围落实在合同上。但事实上，开发方往往会经受不住客户的压力 而扩大系统实现的范围；同时，在需求范围内的变更则更多。客户熟悉的是企业的业务，他们并不 关心需求的更改对整个系统开发过程的影响。 需求的变更直接影响软件开发过程的初始阶段，这会导致软件最终实现的重大修改。对客户的 要求说不，明显是不可取的方法。因此，应用软件系统开发人员会疲丁处理变更产生的影响。如何 处理不断变更的需求是困扰软件开发人员的一道难题。 i 2 2 文档维护 传统软什开发过程中，文档和相关的设计图表都是在前三个阶段产生。需求分析往往使用文本 和图的方式对需求进行描述，这会产生很多纸面的说明文件，不过，当编码开始时，前三个阶段产 生的文档和图表就迅速失去了它们的价值。随着编码的深入，文档、设计图表与代码之间的关联逐 渐减弱，它们不再是对代码的精确描述。随时间的推移，系统被不断地修改，文档、没计图表与代 码之间的距离就越米越远。事实上，工程中往往只修改代码。因为，代码修改之后必须手工在文档 中找出设计图纸中需要修改的地方，这样做十分烦琐而且低效；并且，能够检查文档质量的也只能 是开发团酞的人员，他们完成这项工作要花费的时间和精力也是整个软件开发团队无法容忍的。一 种解决方案是从代码层次入手，从代码中产生文档，这样文档就变成代码不可分割的一部分。但这 种方案只能解决概要设计文档的问题，详细的设计文档仍然需要手工维护。 极限编程x p ( e x t r e m ep r o g r a m m i n g ) 迅速地流行起来，它承认代码是真正驱动软件开发的力量。 但极限编程只能解决软件开发中的部分问题：当个团队开始开发一个系统的时，保存在团队成员 大脑中的设计思想足以使他们理解这个系统。但是，当第一个版本发布之后，团队可能会解散，后 来维护这个系统的人可能是一个新人，那么他就只有代码和测试结果，这使得系统维护极其困难。 所以，要么花时间在开发的前三个阶段写详细设计文档和设计图表；要么花时间在维护阶段， 理解的系统如何工作。这些与文档维护有关的工作，降低了软件的生产力。所以，文档维护到什么 程度，既能很好地指导编码和测试，又不降低生产率，也是困扰应用系统开发人员的一道难题。 1 2 3 软件的轻便性 软件工业与传统t 业相比有其特殊性，它的发展速度令人吃惊。每年都有新技术被发明弗迅速 流行起来，例如( j a v a l i n u x ，x m l ，f f t m l ，s o a p ，【j m l ，j 2 e e ，n e t ，j s p ，a s p ，f l a s h ，w e bs e r v i c e s 等等) 。新技术的确能够真正解决一些问题( 例如，x m l 解决异构系统间的数据交换) 。但面临的困境 就是，应用系统开发商必须快迷跳跃前进，而且必须忍受前期投资的丢失，这无疑是非常痛苦的。 更复杂的是，新技术本身也在发生变化，它们也会不断推出不同的版本，而且并不能保证能完全做 到向后兼容。 现有的系统，或者通过接口与用新技术开发的系统相连接，或者转向新技术。如果系统和某种 技术紧密绑定，那么该系统注定在随技术发展的道路上是步履沉重的。那么，系统开发人员该如何 设计系统才能够使得系统足够轻便，从而跟上技术前进的步伐? 2 东南人学硕士学位论文 1 2 4 重复开发 现阶段，面向企业应刚系统的定制项目在一定范围内依然存在，应用软件供应商往往会为同行 业的企业定制类似的应用系统。但由于各企业的业务之间的存在细微差别，如果按传统软件开发方 法操作，应用软件供应商不得不依然付出相当多的精力去完成类似的系统，这造成了软件生产效率 的低r 。原因就是，软件供应商对自己已产生软件的重用力度不够。9 0 年代中期热捧的面向对象程 序设计( o b j e c to r i e n t e dp r o g r a m ，o o p ) 的一个很大的目标就是实现可复用的软件。但是，事实 上没有多少人进行类层次上的重用，每个程序员在编程的时候，都习惯用自己创建的类，并在此基 础上进行进一步的开发，这并没有从根本上解决软件重用的问题。从软件开发的经验来看，被复用 得虽好的都是一个个相对完整的、独立实现一定功能的模块。但是，企业问业务上的区别导致了这 些模块并不能如期望中那样，被方便的重用到多个应用软件系统中。 所以，在建设类似的系统时，减小重复开发才能使软件开发的效率提高。如何提高软件的复用 度，构造适合不同企业业务的模块，也是困扰系统开发者的一个难题。 以上是一些软件开发过程中的新问题，它们给软件开发者带来了很大的压力：用密集的劳动力 处理复杂的需求给软件生产成本带来了压力；软件复杂性的增加给软件的质量带来了压力，而软件 业界对编码的执著使得质量方面的压力更为沉重；多种新计算平台的出现，使得软件寿命方面的压 力不断增大。企业经理人已经不太可能把宝贵的资本投不会带米显著效益的项目上。这样的压力以 前也出现过。计算机产业的发展经历了一次次循环：压力，然后是解除压力、带来崭新可能性的进 步，然后又开始出现压力。 东南大学硕士学位论文 第二章、缓解软件开发压力的方法 行业发展过程中面临了危机，一般是由于该行业的操作( 运作) 方式不能适应行业发展的客观 情况而产生的。所以，当今应用软件开发中面临的压力并不是突然出现在行业从业者面前，它是行 业发展到一定阶段的结果，是有规律可循的。此外，软件开发有其可行性问题。软件开发的可行性 是指软件产业经济上的可行性，通常以软件质量、寿命期与软件开发成本等三个方面作为衡量依据。 建立高质量、长寿命的业务软件是代价昂贵的，因此，软件需要在质量、寿命期、开发成本之间做 出相应的折衷。从这三方面回顾软件发展过程，并探寻发展的规律，寻找缓解压力的些思路。 2 1 软件发展历程的回顾 机器语言和汇编语言 早期程序员以0 和l 书写计算机指令，费力的写出本地c p u 使用的指令的比特模式。这种“劳 动力密集型”编码方式天生就代价高昂，再加上高硬件成本，极大地制约了可计算的任务的数量。 接着汇编语言出现了，它允许程序员使用助记符来表示计算机能理解的本地指令。这样，编写 程序的耗时的减少降低了生产成本。另外，助记符的出现使得程序员编程时不容易犯错，程序的 质量也提高了。最后，用汇编语言编写的程序对于构成本地指令的0 和1 的模式的改变不太敏感。 处理器指令的变化可以通过汇编器的改变来适应，从而，汇编语言源代码可以经受这一比特模式的 改变，程序寿命会变得长一点。 汇编语言到第三代编程语言 汇编语言程序员虽然不再需要与机械简单的0 和1 打交道，但他们还是要使用处理器本地指令 集米编程。本地指令集是一个相当低层的概念集，简单的过程需要很复杂的指令描述。早期的第三 代编程语言( 3 g l ) ，如f o r t r a n 和c o b o l ，提高了处理器指令集的抽象层次。例如，f o r t r a n 中一 个简单的p r i n t 指令代替了几十行甚至上百行汇编代码。于是，开发者可以用更高层次的指令来编 写程序，使用较少的指令完成一个计算逻辑，极大地提高了程序员的生产率，从而降低了生产成本。 3 g l 语言产生初期，程序员质疑3 6 l 编译器翻译得到机器代码的优化性，另外，早期的编译器 在翻译过程中的确会偶尔会引入错误。但随着时间的推移，生产力的提高足以弥补这些问题。使用 3 g l 来产生“在某种程度上不是那么优化”的程序，本质上是把一些计算的负担从程序员肩上转移 给成本相对低廉的机器资源，从而节省了高昂的程序员人力成本。编译器技术的进步也渐渐能够产 生更可靠、更优化的机器代码。到这时，相对丁| 汇编程序3 g l 语言实现业务功能时手工编写的代 码大幅减少，从而减少了出错机会，使得程序的质量得到了提高。此外，3 g l 程序所用的指令同本 地处理器指令集细节相隔很远。如果硬件发生了变化，新的处理器使用不同的指令集，那么一个新 的编译器可以处理已经存在的3 g l 程序，并为新的目标处理器产生机器代码。在这个过程中，源程 序无需进行修改，或者修改很少，这就延长了程序的寿命，人们称这种代码具有可移植性。 操作系统的支持和面向对象语言的出现 3 g l 进步提升了编程环境的抽象层次，而操作系统则提升了计算平台的抽象层次。当c 和 p a s c a l 引入了更强有力的编程模型后，系统开发商开始使用3 g l 来代替汇编语言定义操作系统服务。 因此，3 g l 编译器可以调用系统服务的代码，而不用为磁盘和显示操作程序产生详细的机器代码， 因此程序的效率和质量提高很多。 接着结构化3 g l 进化到了面向对象3 g k ，包括s m a l t t a l k 和c + + ，这些新的编程语言使得在 不同场合复用程序的一部分变得简单；一些面向对象语言引入了“虚拟机”的解释器。虚拟机执行 语言编译器产生的中间代码，中间代码独立于处理器和操作系统。因此，通过使用在不同处理器和 操作系统上实现的虚拟机，可以在不同计算环境间移植应用程序，更高的可移植性迸一步提高了程 序的寿命。 4 东南大学硕士学位论文 基于组件开发 基于组件开发( c o m p o n e n t b a s e dd e v e l o p m e n t ，c b d ) 吸取了工业生产过程的经验，致力丁通 过j i i j 可互换的组件来组装应用程序。组件化方式提高了软件的复用度，从而提高了生产率，降低了 生产成本。组件化软件生产还有助于提高质量，因为它把软什功能分离开来，使得团队调试和升级 某个功能时可以不必顾虑其余部分。 分布式计算和中间件 计算机网络山现之后，网络内多台机器之间进行的计算的称为分布式计算。为解决操作系统分 布异构和分布式计算的问题，人们提出了中间件( m i d d l e w a r e ) 的概念。中问件是位于平台( 硬件和操 作系统) 与应用之间的通 j 服务，这些服务具有标准的程序接口和协议。针对不同的操作系统和硬件 平台，它们有符合接口和协议规范的多种实现。随着互联网的发展，中间件逐渐开始扮演分布式操 作系统的角色，它提供了一个位于传统操作系统层之上的计算抽象层。 此外，中间件还提升了操作平台的抽象。c o r b a 、j 2 e e 和n e t 都是中间件平台的重要例子，它 们提供了比所有特定计算机的操作系统都更为强大的服务。中间件使得应用程序员可以把更多精力 集中在业务逻辑上，而不必太费心于如何提供，如消息机制、事务处理和安全性这样的功能。中间 件可以提供不依赖于特定操作系统或者编程语言的服务，这些服务可以在多个操作系统上实现，使 用这些服务的应用程序可移植性更强，因此寿命期也长了。 软件构架和关注点分离 软件构架通过分离关注点来组织复杂系统，它也经历了一个不断发展的过程。最初的构架是由 大型主机与用户桌面终端组成，然后发展到两层的客户服务器构架，再转向三层构架，最终转到现 在提出的四层构架系统，它将软件分成用户显示逻辑，用户交互逻辑，业务逻辑，资源层层等四个 部分。这个发展过程伴随着关注点的分离，这样做有助于将对系统的修改局限在系统的一个层次内。 因此，局部化的系统变更降低了系统的脆弱性，从而延长了系统的寿命。同时一旦某个构架以及 支持它的基础构架已就绪，那么，系统的变更可以更快的被实施，因此，局部化的系统变更还提升 了软件的生产效率。此外，如果某一层次的变更影响到其它层次，那么关注点的分离有助于跟踪变 更产生的结果，这从一个方面提高了软件的质量。 其它软件技术 说明性规范( d e c l a r a t i v es p e c i f i c a t i o n ) 指通过设置一些属性值来编写系统。说明性规范不 仅提高了生产效率，还提高了软件质量。这是复用已编写和已验证的逻辑代码的另一种形式。不少 开发工具程序，如d e l p h i ，v i s u a lb a s i c 这样的4 g l 提供可视化的开发环境，提供了编写如用户界 面等更高级的抽象环境。它们会自动产生例如显示和管理可视化组件的代码，程序员只要进一步给 产生的代码添加功能，就可以完成软件产品。在e j b 、n e t 和c o r b a 组件模型中，描述信息 ( d e s c r i p t o r ) 包含了组件的各属性的说明。这些中间件依照属性说明来动作。例如，为了让组件 支持a c i d 交易处理规则，程序员只需要在描述信息中说明需要实现对a c i d 的支持，然后，中间件 接管了剩下的事情。 x m l 支持不同3 g l 编写的程序之间的互操作性。因此，如同c o r b a ，x m l 促进了分布性。 契约式设计( d e s i g nb yc o n t r a c t ，d b c ) 是一种建立可靠软件的方法，它强迫程序员显式、形 式化地指定软件组件之间的契约关系，从而直接对软件质量产生影响。 2 2 提高软件开发的可行性 上文从三个方面描述了软件发展的过程，这三个方面衡量了软件开发的可行性。下文从这三方 面入手，寻找提高软件开发可行性中有规律性的方法。 东南大学硕上学位论文 2 2 1 降低生产成本 从软件开发的同顽可以看出，降低软件生产成本的通用方法是成本的转嫁将高昂的程序员 成本转嫁到成本相对低廉的机器资源上去。这就是要在软件开发中让机器代替人做更多的事情。从 本质上来看，为了将程序员的工作交给机器完成，就需要对客观事物的进行抽象，将复杂的过程用 简单的方式进行描述，形成同定模型，再交给机器完成。这样。能以较少的代码描述以前需要复杂 描述的过程从而减小了人工开发的工作量，降低了生产成本。同时，这种通过抽象得到的模型也 可以理解为，将成熟的良好设计的规范代码( 如组件) 引入项目中，减少程序员在优化和改错方面 的工作，可以降低生产成本。 2 2 2 提高软件质量 为了提高软件代码的质量，人们在软件方法学方面作了很多的努力，如o o p 改变了程序员对客 观世界的认识方式，通过使用对象模型对客观世界进行抽象；通过如规约式设计等软件开发方法， 规范编程的方式使得程序的质量得到提高。此外，优秀代码的复用也是保证程序质量的好办法，基 于组件的编程在这方面起了很大的作用。 2 2 3 提高软件寿命 一般情况下，实现软件代码在平台间的可移植性是提高软件寿命的主要方法。如果对软件系统 进行进一步的抽象，将软件视为于独立于平台的模型，这样软件的寿命无疑会大大延长。 2 3 建模技术 从上述的论述可以看出，对软件开发过程中的对象进行抽象，将复杂的事件抽象成描述简单、 使用良好的模型是软件发展过程中的必经之路。并且，随着模型抽象的不断提升，开发人员就更加 接近于想要表达的业务逻辑，同时，在运行期间活动的动态模型增j u t 系统的灵活性，这样就可以 提高软件的可行性。由此可以设想，软件发展演化到一定阶段甚至客户中的业务入员也可以设计 软件了。 软件开发通常分为开发层次和设计层次。现阶段，开发层次的模型抽象已经达到组件的级别， 而在设计层次，则是使用如l m l 等建模工具实现软件模型的构造。但大多数人都习惯于把这种软件 模型看作设计工件，而把3 g l 程序看作开发工件。很多公司把建模人员和编码人员的角色完全分离。 其结果就是，模型比如u m l 模型，经常是非正式的，这意味着它们不能被机器处理。编码人员把它 们当作“指南”和“说明书”使用，不直接作用于编码过程。如果一些形式化的模型可被机器处理， 这样的模型就是生产过程的直接部分，这就会提高软件的可行性。 6 东南大学顾_ _ 学位论文 第三章、模型驱动开发方法综述 对象管理组o m g 近两年提山了基于模型驱动的体系结构( m o d e ld r i v e na r c h i t e e t u r em d a ) 技 术，m d a 是一种在软件开发中使用模型米建立软什系统和解决互操作性等问题的途径。简单地说， m d a 是o m g 在实现模型的可执行性上的努力，其目的是为了“把建模语言当编程语言来用”。为了实 现这个目的，o m g 制定了模型的精确形式化表示、模型存储以及模型交换方面的各种规范如u m l 2 、 m o f ( m e t ao b j e c t f a c i l i t y ) 、( e l ( o b j e c tc o n s t r a i n tl a n g u a g e ) 、q v t ( o u e r y v i e w t r a n s f o r m a t i o n s ) 、) ( m i ( x m lm e t a - d a t ai n t e r c h a n g e ) 等。 3 1m d a 的开发过程 b i d a 开发模式关注的是对系统的建模，包括对模型的理解、设计、创建、维护和修改。图2 显 示了模型驱动开发方法解决问题的过程： m d a 开发过程r 以平台无关的模型p i m 作为驱动 图2 模型驱动的开发途径的解决问题的过程 m d a 开发模式的生命周期与传统的方式看起来区别并不大。它们具有相同的开发阶段，主要的 区别是各个阶段的设计工件不同的。m d a 的设计工件是精确的模型，它们能够被机器理解。m d a 开发 过程通常包含以下几个阶段： 1 首先，与普通的应用开发一样要对需求进行了解，获取需求相关的文档。 2 其次，使用平台无关模型p i m ( p l a t f o r m i n d e p e n d e n tm o d e l ) 从支持商业逻辑的角度来对系 统进行建模。p i m 是对系统的一种高层次的抽象，与具体的实现技术无关。在此过程中，会不 断根据客户需求和其它因素对p i m 进行精化，使得它能够更加精确的描述系统。 3 然后，p i m 可以被转换到一个或者多个特定业务层模型p s m s ( p l a t f o r m s p e c i f i e d m o d e l ) 。p s m 是针对确定的实现技术、平台为系统度身定做的模型。例如，j 2 e e - p s m 是对使用j 2 e e 结构 的系统的建模，它包含一些e j b 相关的名称，例如”h o m ei n t e r f a c e ”、“e n t i t yb e a n ”、”s e s s i o n b e a n ”等。由于，如今很多系统都跨越多种技术，所以对于一个p i m 拥有多个p s m 是很正常的。 这是m d a 中最复杂，也是最重要的一步。有时，由p i m 自动生成的p s m 并不能使挑剔的程序员 满意，他们可以根据平台的特性对p s m 加以修改，对p s m 的修改能够反映到p i m 中去。 4 对p s m 进行不断的精化，以指导生成器生成质量更高的代码。 5 最后一步就是将每个p s m 都转换到代码，由于p s m 跟具体的系统实现技术已经很接近，因此这 种转换来得比较直接。 3 2m d a 的相关技术和思想 m d a 不是某种具体的技术，也不是一种具体的方法论，它是包含了诸多规范的一个集合，是o m g 东南大学硕士学位论文 提山的在模型驱动软什开发方面的一个总的架构。 0 组织提出m d a 在两方面作了很大韵努力： m d a 提供了统一的元数据管理框架。 m d a 是o m g 在实现模型的可执行上进行的努力。 m d a 提供了统一的元数据管理框架 国际标准化组织o m g ( o b j e c tm a n a g e m e n tg r o u p ) 是独立_ 丁各厂商的非盈利性组织，其宗旨是 统一不同商业产鼎与标准之间的数据交换与互操作，从而改善各厂商软件产品之间的不兼容性。公 共对象请求代理结构( c o m m o no b j e c tr e q u e s tb r o k e ra r c h i t e c t u r e ，c o r b a ) 是o m g 以往的一个 重要的 ：作成果，c o r b a 致力于提供一个跨平台和跨语言的对象互操作框架，在中间件层次上统一 不兼容的平台和不同语言开发的对象。但由于，在中间件级别涌现出来的m s m 和n e t 造成了新的层 次上的不兼容，o m g 的这个努力已经被证明没有达到预期的效果。从这个意义上看，m d a 是一种在比 c o r b a 更高抽象层次上，提供的实现软件间互操作的方法，它是o m g 一贯思想的自然延续。 如图3 所示，在考虑互操作性问题时，通常将不兼容情况分为纵向和横向两个维度，x m i 可以 解决不同数据之间的不兼容，c o r b a 可以在一定程度上可以解决不同对象之间的不兼容。但不同软 件产品之间的交互，不仅限于数据与数据之间、对象与对象之间、或者模型与模型之间，不同层次 之间的交互也同样非常多，比如模型和源代码的交互( 由模型生成代码) ，模型和应用的交互等。以 往的解决思路都没有考虑到不同层次间不兼容问题的解决，m d a 则在这方面做了重要的工作。 应用 对象 模型 数据 平台 应用 应用 对象对象 模型模型 数据数据 u 平台平台 图3 层次之间的不兼容性 同层次之间的不兼容，实质上是元数据的不兼容。m d a 的一个重要贡献在于提供了管理不同元 数据的统一框架。m d a 允许使用不同格式( 不同元数据描述) 的数据存在，并为描述这些数据的语 言( 其元数据) 提供了统一的定义语言即m o f 。m d a 通过基于m o f 的四层元模型( 如图4 ) 架构 对元数据进行统一管理不但能解决图3 中不同抽象层次上的不兼容的问题，还可以在更广泛范围 元数据的管理上发挥作用。举例来说，考虑一个软件开发过程，对于相同的组件在需求阶段，使 用需求模型来描述：在开发阶段，使用u m l 模型来描述；在测试阶段，使用测试模型来描述由 于侧重点的不同，不同阶段对这个组件的描述使用了不同的元模型。但是，在m d a 统一的元数据管 理框架f ，这些由元模型描述得到的模型，就可以进行交互和转换等工作。这样，模型就可以与应 用进行互操作，由模型生成应用程序。 m 3 m o f 。b p 定义元模型的m o f 类、属 构造纂合性、关联等 m 2 元模型由m o f 椅造u m l 粪、属 的实例坦成性、状态等； e w m 袭列等p m 1模型。由m 2 元横型构“c u s t o n ，e r ” 造的实例组成类、“v e n d o r ” 表等 m o对象和数据，也即m 1 客户j a n e 、账 模型构造的实例 户2 3 4 4 、员工 a 3 9 4 9 等 图4m o f 的四层模型 8 东南火学硕1 一学位论文 m d a 是o m g 在实现模型的可执行上进行的努力 m d a 的一个重要目标是加强模型在开发中的作用，简单地说，就是实现模型的可执行。m d a 技 术的核心概念均是o m g 的一系列标准：统一建模语言u m l 、元对象设施m o f 、x m l 元数据交换x ) 4 i 、 公共数据仓库元模型c w m 。m d a 的核心标准组成了创建模式驱动软件开发方法的基础。m d a 将抽象层 次提高到模型的高度，其理想情况是：开发人员只要考虑与业务逻辑相关的模型设计，而模型到应 用的实现是和业务无关的、重复的、低层次的工作，它可以交由机器来实现。目前，m d a 要做的是 将业务逻辑从不同的中问件平台( j 2 e e 、n e t 、c o r b a 、w e bs e r v i c e ) 中剥离出来，开发人员只要 考虑业务逻辑的建模，得到和具体中间件技术细节无关的p i m 。在m d a 提供的支持下，将p i m 转换 成加入了技术细节的不同平台上的p s m 。最后，由p s m 生成应用程序，其表现形式可能是一个可运 行的j a v a 程序，或者是w i n d o w 系统上部署的w e bs e r v i c e ，这样，m d a 的模型可执行得到了满足。 3 。3m d a 的局限性 为了精确定义模型到代码的生成，在使用u m l 定义p i m 的过程中，o m g 作了很多规范上的约束。 它使用专业化的方法描述一个特定领域的模型，其中，包括应用程序使用的信息结构，如，类 ( c l a s s e s ) 关联( a s s o c i a t i o n s ) ，泛化( g e n e r a l i z a t i o n s ) ，操作( o p e r a t i o n s ) 等，具体来说就是 会生成如c u s t o m e r 、o r d e r 、p r o d u c t 和它们的属性、关联、聚合等。此外还需要定义应用程序的 事务、信息的动作类型，它包含属性、操作和应用领域的视图。具体来说，比如订单、物品计价和 其它典型的业务作业。通过这两个方面的描述组成了一个p i m 模型，现阶段m d a 工具，如o p t i m a l j 等都是通过这种方式实现p i m 。使用这种方式描述应用系统，需要有u m l 等元模型的技术知识背景， 并且需要很强的使用u m l 构造p i m 的能力。因此，m d a 还不是很实用的技术。考虑，如果一开始就 提供给业务人员( 而不是应用系统设计人员) 一个模型描述工具，让他们去定义自己的业务。这样 的建模工具就符合他们的思维习惯，用现实世界中的概念去建立软件，这样，业务人员就可以真正 参与软件的开发，而软件也直接反映他们的需求。 面向对象、u m l 建模能帮助程序员去理解模型驱动的软件开发。但模型驱动的软件开发并不是 o o d 、o o a 。在这个世界里。人认识和看到的是实体，实体和对象并不一样。实体可以是一个对象、 一个构件、一个系统，实体在更多的时候被理解为诸如：报表、物料单、生产计划、客户等。u l l l l 是帮助系统分析人员进行软件设计的，它更贴近代码这个层面。复杂的图形与文字说明并没有减少 业务人员对软件的神秘和抵触心理。暂且不说业务人员需要去学习u 札，至少在国内能看懂u m l 图 的系统分析员就不多。以一个软件专业人士的眼光去理解客户的业务需求，这本身是有问题的。如 果，系统分析人员与业务人员去谈该如何处理物料单的时，他会表现出很高的积极性。因为这就是 他的日常工作。模型就是要帮助业务人员去设计自己的系统，它是软件中的虚拟业务与现实业务之 间的映射。模型需要通过对实体、规则、业务进行描述，实现以用户的思维方式去理解软件中的业 务操作。而现阶段的m d a ，借助u m l 工具使用类、关联、泛化、操作等关系建立的模型，距离理想 状况懂业务就能编程，还是有一定差距。下文中提出了按业务模式进行建模的方法，它在一定 范围内解决了m d a 建立业务层模型存在的问题。 目前，o m g 的研究是建立在m o f 、o m l 、c 脯等基础之上，没有形式实用技术，暂时还不是应用 层面的解决方案；此外，m i ) a 面向整个软件行业，如果能够真正实施而不只是停于思想层次上，就 需要i t 企业对规范进行支持，但是，由于商业利益及其它一些原因，各厂商可能不太可能会为自己 的产品实现相应的规范，c o r b a 就是这样一个失败的例子。要实现m d a 的理想，o m g 还有很长的路要 走。 9 东南大学硕士学位论文 第四章、m d a 在信息系统中的应用 m d a 是一个面向整个软件行业提高软件可行性的解决方案，但由于其实用性不强，当前看还不 清m d a 的应用前景。但对于面向特定领域的应用，如企业的信息系统等，模型驱动思想还是值得 借鉴的。高校校园信息化建设是如今信息化建设的一个热点。和一般企业相比，高校内的业务有其 特殊性，但系统的目的是处理日常业务，与企业信息系统相比只是在处理业务的手段上有所不同。 所以，通过模型驱动方式开发的高校信息系统，可以为一般企业信息的开发提供思路。下文以高校 信息系统为例，描述了基于模型驱动的软件开发方法。 4 1 信息系统简述 从上个世纪5 0 年代起，信息系统就开始了它的发展。信息是企业中最重要、最有价值的资源。 它和数据不同，数据是由原始事实( 如员工的姓名，每周的工作时间等) 组成而信息是按照特定 方式组织在一起的事实的集合。信息系统是一系列相互关联可以进行收集( 输入) 、操作和存储( 处 理) 、传播( 输出) 的数据和信息，并提供反馈机制以实现其目标的元素或者组成部分的集合。企业 信息系统中通常包括：事务处理系统t p s ( t r a n s a c t i o np r o c e s s i n gs y s t e m s ) ，管理信息系统m i s ( m a n a g e m e m i n f o r m a t i o ns y s t e m s ) ，决策支持系统d s s ( d e c i s i o ns u p p o r ts y s t e m s ) 等。 t p s 系统是其它信息系统的基础，它不需要综合和复杂的处理，但要进行大量的数据输入和输 出。事务是所有与企业有关的交易，如对员工的支付薪水、学生的成绩录入等。事务处理是企业中 用来记录完成企业交易的人员、过程和数据库以及各种数据的有组织的集合。事务处理系统代表的 是信息的应用，处理日常的、重复的、普通的企业事务，并操作企业的基本业务纪录、更新所需的 详细数据等。 m i s 系统的主要目标是帮助管理者了解日常的业务，以便进行高效的控制、组织、计划最终达 到企业的目标。针对各不同的行业或部门，使用不同的m i s 系统，例如，财务m i s 、制造业m i s 、 营销m i s 、人力资源m i s 等。从制造业m i s 发展的物料需求计划m r p ( m a t e r i a lr e q u i r e m e n t s p l a n n i n g ) 思想，经过不断的演化，产生了企业资源计划e r p ( e n t e r p r i s e r e s o u r c ep l a n n i n g ) 的管理 思想。e r p 是一种基于企业内部供应链的管理思想，将企业的业务流程视为一个紧密联接的供应链， 并将企业内部划分成几个相互协同作业的支持子系统，并对企业内部供应链上的所有环节如订单、 采购、库存、计划、生产制造、质量控制、运输、分销、服务与维护、财务、成本控制、经营风险