（计算机应用技术专业论文）基于uml的模型驱动软件开发应用与研究.pdf

摘要 f 7 3 s 5 8 8 摘要 模型驱动架构( 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 ) 是对象管理组织( o b j e c t m a n a g e m e n tg r o u p ，o m g ) 定义的一个软件开发框架。它是软件开发领域的一场 革命。在m d a 中，整个软件开发过程是由对系统的建模行为驱动的。统一建模语 言( u n i f i e d m o d e l i n g l a n g u a g e ，u m l ) 是m d a 使用的种建模语言，它的最新 版本u m l 2 0 对模型的描述更加精确，并允许执行模型，对m d a 提供了更强的 支持。目前出现了一些支持m d a 的基于u m l 2 0 的工具，t e l e l o g i c 公司的t a u d e v e l o p e r 就是其中具有代表性的一个。 为了学习研究这种新的方法、新的语言，以及新的工具，并引入运用到实际 工程中来，以提高工程的质量和效率，论文结合实际工程z m n 软件测试管理系 统，采用模型驱动的开发方法，对t a ud e v e l o p e r 工具的使用进行了学习研究， 完成了z m n 系统中的系统管理配置表模块的建模设计和部分代码自动生成，并 获得了一些关于使用t a ud e v e l o p e r 的见解，为在今后的实际工程中更好的使用 t a ud e v e l o p e r 工具打下坚实的基础。 研究结果表明，使用模型驱动开发工具t a ud e v e l o p e r 可以对系统开发过程 造成重大影响。利用它最强大的模型验证功能，在项目丌发的早期就能够对系统 进行可视化仿真和验证系统行为，以便在开发生命周期中尽早排除错误，并可由 模型自动生成代码，特别适合于有复杂控制逻辑的系统开发和软件丌发。另外， 利用它的代码自动生成功能，不仅能对系统的静态结构生成代码，而且还能对系 统的动态行为生成代码，这也是它与其他工具显著的不同之处。 关键词u m l ：m d a ；模型驱动开发；模型验证；代码自动生成 a b s t r a c t a b s t r a c t m o d e l d r i v e na r c h i t e c t u r ei saf r a m e w o r ko fs o f t w a r ed e v e l o p m e n tw h i c hi s d e f i n e db yo b j e c tm a n a g e m e n tg r o u p i ti sar e v o l u t i o ni nt h ef i l e do fs o f t w a r e d e v e l o p m e n t i nm d a ，a l lt h es o f t w a r ed e v e l o p m e n tp r o c e s si sd r i v e nb ym o d e l i n g a c t i o nt oa s y s t e m u n i f i e dm o d e l i n gl a n g u a g ei sa k i n do f m o d e l i n g l a n g u a g eu s e db y m d a i t sl a t e s tv e r s i o nu m l 2 0c a l ld e s c r i b eam o d e lm o r ea c c u r a t e l y ，a n dp e r m i t s e x e c u t i n gm o d e l ，s oi tg i v e sm d a am o r es t r o n g l ys u p p o r t a tp r e s e n t ，s o m et o o l s b a s e do nu m l 2 0w h i c hs u p p o r tm d aa r ea p p e a r e d t e l e l o g i c st a ud e v e l o p e ri sa r e p r e s e n t a t i v et o o lo f t h e s e t o o l s i no r d e rt os t u d ya n dr e s e a r c ht h i sn e wm e t h o d ，n e wl a n g u a g e ，a n dn e wt o o l ，a n d b r i n gt h e mt o t h er e a l p r o j e c t t o i m p r o v ei t sq u a l i t y a n de f f i c i e n c y ，t h i st h e s i s ， c o m b i n e dw i t ht h er e a lp r o j e c tz m ns o f t w a r et e s t i n gm a n a g e m e n ts y s t e m ，u s i n gt h e m o d e l d r i v e nd e v e l o p m e n tm e t h o d ，r e s e a r c h e dt h eu s a g eo ft a ud e v e l o p e rt o o l ， c o m p l e t e dt h em o d e l i n gd e s i g na n dp a r tc o d eg e n e r a t i o na u t o m a t i c a l l yo f t h es y s t e m m a n a g e m e n ta n dc o n f i g u r a t i o ns u b s y s t e mo f z m n s y s t e m ，a n do b t a i n e ds o m ei d e a s a b o u th o wt ou s et a nd e v e l o p e r t h e s ei d e a sl a i dt h ef o t m d a t i o n so fu s i n gt a u d e v e l o p e r b e r e rf o rt h ef u t u r e t h er e s e a r c hr e s u l ti n d i c a t e su s i n gt h em o d e l - d r i v e nd e v e l o p m e n tt o o l t a u d e v e l o p e rc a ni n f l u e n c et h ed e v e l o p m e n tp r o c e s sg r e a t l y i t sp o w e r f u lf u n c t i o no f m o d e lv e r i f i c a t i o na l l o w sv i s u a ls i m u l a t i o na n dv e r i f i c a t i o no fd y n a m i cb e h a v i o r g i v i n gd e v e l o p e r st h e c h a n c et oe l i m i n a t ea n ye r r o r sa se a r l yi nt h el i f e c y c l ea s p o s s i b l e i ta l s oc a l lg e n e r a t ec o d ef r o mm o d e l s i t sv e r yp r o p e rt ou s et a ud e v e l o p e r i ns y s t e md e v e l o p m e n ta n ds o f t w a r ed e v e l o p m e n tw h i c hh a v ec o m p l e xc o n t r o ll o g i c i na d d i t i o n ，t h et o o lh a st h ea b i l i t yt og e n e r a t ec o d ea u t o m a t i c a l l y i tc a ng e n e r a t e c o d en o to n l yf r o mt h es t a t i cs t r u c t u r eo f s y s t e m ，b u ta l s of r o m t h ed y n a m i ca c t i o no f s y s t e m ，t h i si sd i s t i n c tf r o m o t h e rt o o l s i i 摘要 k e y w o r d s ：u m l ；m o d e l d r i v e na r c h i t e c t u r e ；m o d e l - d r i v e nd e v e l o p m e n t ；m o d e l v e r i f i c a t i o n ；c o d eg e n e r a t i o na u t o m a t i c a l l y l h 第1 章概述 第1 章概述 1 1 选题的背景 通常的系统开发生命周期包括需求、分析、设计、实现、测试这几个阶段。 对开发生命周期的典型说法是把它看作系统开发的不同阶段的总和，但这样做会 使开发者很难评估生命周期对实际工作的真正影响。 当今的项目开发需要不同的小组进行合作，在大型项目的开发中这种合作本 身就是个大问题。开发各个阶段的专业划分导致在不同的生命阶段使用单一的技 术、语言、概念、构件、格式与工具，从而使得开发周期的各个阶段成为孤岛。 这种通常的生命周期的缺点是：生命周期阶段是松散的耦合关系，很难引起项目 团队的关注，各阶段小组的沟通不够顺畅，很难控制项目进度。 传统的开发工具可以提供非常有价值的支持，但是他们太局限于单一的阶 段，只能为这一阶段的工作带来利益。当人们力图把它们扩展到整个开发生命周 期中去的时候，就超出了这些工具的能力范围。早期的计算机辅助软件工程 f c a s e ) 工具就属于这种情况。 现在有了生命周期自动化工具，使用它就可以打破开发各阶段的隔膜，实现 在生命周期各阶段间的合作与信息共享，使组织更好地管理日益复杂的开发项 目。这种自动化的生命周期的特点是：各阶段紧密集成并且能够自动实现，目标 变得清晰可见因此对整个生命周期都更加关注，以u m l 作为可视化建模语言和 公用语言，使得项目变得可视和可监控。 t e l e l o g i c 公司就提供了这样一套生命周期自动化工具，特别适合复杂系统工 程领域和先进软件项目的应用，如国防军事系统、航空航天、通信系统等。 t e l e l o g i c 的生命周期有以下几个阶段，每个阶段都有相应的工具支持： 需求管理d o o r s 系统分析与设计、软件开发与实现t a ua r c h i t e c t ，t a ud e v e l o p e r 配置和变更管理_ c ms y n e r g y ，c h a n g es y n e r g y 基于u m l 的模型驱动软件开发应用与研究 测试_ t a ut e s t e r ，t a ul o g is c o p e 文档自动生成d o c e x p r e s s 本课题重点就是掌握如何用t a ud e v e l o p e r 工具对系统进行可视化建模和设 计，并完成z m n 软件测试管理系统中的系统管理配置表模块。这些工作在生命周 期中处于分析、设计和实现这三个阶段。t a ud e v e l o p e r 工具采用基于u m l 2 0 的模型驱动开发的方法，能够从可视化模型生成关键的源代码，从而减少了贯穿 生命周期不同小组之间的沟通障碍，使从一个开发阶段过渡到另一个阶段变得更 容易。 1 2 研究目的和意义 t a ud e v e l o p e r 工具支持当前最先进的模型驱动开发方法，其使用的统一建模 语言u m l 2 0 也是u m l 当前最新的版本。与传统开发方式相比，模型驱动开发 使得开发人员能集中精力于系统架构、分析和设计，开发过程的各个阶段产生的 工件是正式的精确模型。使用工具，部分或全部模型可以被执行，并可由模型自 动地生成关键代码。为了掌握这种新的方法、新的语言，以及新的工具，并引入 运用到实际工程中来，以提高工程质量和效率，论文结合z m n 软件测试管理系统 这一实际工程，对t a ud e v e l o p e r 工具的实际使用进行了学习研究。 传统的开发必须等到编完代码后才能对需求进行验证，而使用t a ud e v e l o p e r 工具在分析设计阶段就可以验证需求，即在项目的早期就可以发现错误，因为它 实现了模型验证功能，这是t a ud e v e l o p e r 工具和传统开发工具最大的不同之处。 将t a ud e v e l o p e r 工具的模型验证功能运用于实际工程中具有很大的意义。 在系统开发中有这样一个普遍规律：需求修改提出得越迟，系统为修改而耗费的 成本越多，而且基本是呈指数量级上升。而使用t a ud e v e l o p e r 的模型验证功能， 可以执行和调试系统模型，这样开发人员在早期就可以快速的发现系统设计中的 逻辑错误，验证需求的正确性，提供一个清晰、一致和完备的需求，这对项目以 后阶段的开发提供了正确的指导，促使项目的顺利进行，提高系统开发的效率和 质量，减少开发成本。 另外，传统的开发会产生大量的设计文档，编程人员对设计文档的理解与设 第1 章概述 计人员的本意难免有不一致的地方，而且，随着开发的进展，有许多改动不能及 时地反映到文档中，不能保证文档和最后代码的一致性。而t a ud e v e l o p e r 提供 了代码自动生成功能，给模型提供足够的信息，就可以由模型自动生成代码，从 而消除了设计与代码的不一致性。 如果能在实际工程中运用t a ud e v e l o p e r 工具的代码自动生成功能，其意义 也是很大的。由于大部分代码可以自动生成，可以省去一部分编写代码的繁琐工 作，从而提高代码质量和开发效率。另外，在后期发现的错误可以通过修改模型 然后重新生成代码来纠正，这比修改代码要容易多了，尤其便于后期的维护工作。 基于u m l 的模型驱动软件开发应用与研究 第2 章国内外发展情况 本章首先介绍了m d a 框架是在什么样的背景下提出来的，然后介绍了与 m d a 相关的语言、工具、以及开发过程的国内外发展情况。 2 tm d a 框架的提出 传统的软件开发方法都是以手工编码为中心，随着项目的进展，需求分析和 设计阶段产生的文档和u m l 模型与代码之间同步变得越来越困难。代码为了应 付变化的需求和设计而不断变化，文档和模型却一直停留在原地不动，这使得文 档和模型在一段时间之后就失去了它的价值。 时下极限编程( e x t r e m ep r o g r a m m i n g ，x p ) 等敏捷方法广为流行，其背后 的理念是“详尽的模型只不过是一堆纸，与其浪费时间纸上谈兵，还不如把这些 时间用在真刀真枪写代码上面”。而对象管理组织( 0 b j e c tm a n a g e m e n tg r o u p ， 0 m g ) 于2 0 0 2 年初提供了最根本的解决方案：模型驱动架构( m o d e l d r i v e n a r c h i t e c t u r e ，m d a ) ，并把它作为o m g 的战略方向。x p 的核心工件是代码， 而m d a 的核，5 , t 件是模型。最关键的是，在m d a 中，模型不再是一种辅助工 具，而是开发过程的产品。 m d a 的核心思想是抽象出与实现技术无关、完整描述系统的平台独立模型 ( 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 转换成与具体实现技术相关的平台相关模型 ( p 1 a t f o r m - s p e e i f i cm o d e l ，p s m ) ，最后，再通过变换工具将p s m 自动转换成 代码。这样，当需求有变化时，只要修改模型，然后重新自动生成代码就可以了。 由此可见，这种方法最大化了模型的价值。 模型驱动开发是m d a 中的一部分，m d a 是模型驱动开发方法的概念框架。与 传统的开发方式相比，模型驱动开发的整个开发过程是由对系统的建模行为驱动 的，其生命周期各个阶段产生的工件是能够被计算机理解的形式化模型，模型在 整个生命周期中处于核心地位。 6 第2 章国内外发展情况 2 2 语言 o m g 定义了一系列建模语言，用于创建p 1 m 或p s m 。其中使用最广泛的建 模语言是u m l 。 u m l 作为一个形式化规约集合和一种实现商业开发工具的技术，它改进的 速度是决定m d a 前进速度的一个重要因素。当o m g 提出m d a 构架时，u m l 还处于1 x 版本。u m l l x 有很多优点，例如，它使得提升软件开发的抽象层次 成为可能等等，但是也有一些缺点，例如，u m l 和元对象设施( m e t ao b j e c t f a c i l i t y ，m o f ，是o m g 的种特殊语言，专门用来定义其他所有语言的) 有不 协调之处，图形有不同的解释导致分歧等等，影响了它在m d a 中扮演的角色。 2 0 0 3 年6 月，o m g 推荐采用u m l2 0 ，完成了这个工业标准建模语言的一次 大的升级，它简化了u m l l x 的复杂性，归并了不一致的模型，为架构建模和动 态行为的描述提供了更强的支持。u m l 2 0 的基础是m o f ，和m o f 具有很好的 一致性。总之，u m l 2 0 在表示系统规约能力上革命性的进步为m d a 提供了坚 实的基础。 u m l 包含了一个p r o f i l i n g 机制，这个机制允许我们定义派生自u m l 的语言。 用p r o f i l e 定义的语言是一个附带额外约束的u m l 子集，这个子集用于特定目的。 目前使用的大多数p r o f i l e 都是为某种特定平台定义的语言，像c o r b a 、j a v a 或 c + + 的p r o f i l e 。用这样的p r o f i l e ( 及其所用到的构造型) 表述的模型只能用作p s m 。 对象约束语言( o b j e c tc o n s t r a i n tl a n g u a g e ，o c l ) 是一个u m l 查询和表达 语言，它是u m l 标准的一个组成部分。 u m l 的动作语义( a c t i o ns e m a n t i c s ，a s ) 定义了u m l 行为模型的语义。但 是，a s 是在低层次上定义行为的，所以不适合用来直接描述p i m 。它缺乏必要 的高层次抽象。 公共仓库元模型( c o m m o nw a r e h o u s em e t a m o d e l ，c w m ) 是为数据挖掘和 相关系统的建模而特别设计的。 目前，m d a 框架用到的变换定义完全是以非标准化的方式定义的。为了能 把这些变换定义标准化，o m g 正在开发用来编写变换定义的标准语言。这一标 准称为q v t ，意思是查询、视图和变换( q u e r y 、v i e w s a n dt r a n s f o r m a t i o n s ) ， 基于u m l 的模型驱动软件开发应用与研究 它们的语言是用m o f 定义的。 2 3 工具 u m l 目前成为使用最广泛的建模语言，相应地，也出现了很多基于u m l 的建模工具。当m d a 风靡起来后，厂商们又喜欢声称它们的工具支持m d a 。 甚至有的工具在m d a 这个名字发明之前就出现了，现在它们也声称自己支持 m d a 。这些说法中大多数还是有依据的，这些工具至少支持了m d a 的一些方 面，只是支持的程度不同。 对m d a 的支持是多种多样的。我们在1 0 年前就能够从模型生成简单的代码 了，这也包含在m d a 的范畴中。但是，在理想隋况下，m d a 对模型和模型变 换提出了很高的期望。下面主要讨论一下工具对交换所能提供的支持。 p i m 到p s m 的变换工具 这类工具把高层次p i m 变换成一个或多个p s m 。目前，这类工具还很少见， 虽然有一些工具提供了这方面的最基本功能。 p s m 到代码的变换工具 p s m 代码变换工具是最广为人知的支持m d a 的工具。这些工具有内置的变 换定义，把符合某种预定义类型的模型作为输入，并输出符合另一种预定义类型 的模型。源模型是p s m ，目标模型则是代码模型。事实上，传统c a s e 工具就 是按照这个模式生成代码的。 p 1 m 到代码变换工具 这种工具同时支持从p i m 到p s m 和从p s m 到代码的变换。有时候，用户看 到的只是从p i m 到代码的直接变换，p s m 则是隐含的。这种类型的工具把源语 言、目标语言以及变换定义都内置其中了，它们的行为就像黑盒一样。 可调的变换工具 工具应当给变换提供一些微调或者参数化机制。通常不会让你改动变换定义 以满足你自己的需要。目前所能获得的最佳方案是工具“内部使用”的脚本语言 创建的变换定义。要修改这类脚本很耗时间，因为还没有编写变换定义的标准语 言( 参见第2 2 节中关于q v t 的内容) ，变换定义只能是工具相关的。 第2 章国内外发展情况 大多数工具只对预定义的p i m 语言起作用，这里“预定义的p i m 语言”常 常是u m l 的一个受限变体。虽然我们可以用u m l 图表来为p i m 建模，但是工 具内部实际上并不使用u m l 语言定义，而是使用它们自己对u m l 的特殊定义。 因为工具的“土定义”并不能百分之百保证同u m l 的官方语言定义一致，所以 即便u m l 专家也需要先学着使用这种特定于工具的u m l ，而且创建变换定义 时也会遇到困难。 变换定义工具 变换定义工具支持创建和修改变换定义。当你无法使用现成的变换定义时， 你就需要这类工具来创建你自己的变换定义。目前我们看到的唯一变换定义工具 是特殊的脚本语言，这在前段已经提到过了。m d a 非常依赖复杂的变换定义， 这推动了更适合这一工作的变换定义语言( q v t ) 和工具的出现。更灵活的工具 应当允许插入新的语言定义并将其用于变换。这类的工具在市场上还没出现。 虽然现在还无法发挥m d a 的全部潜力，但是我们目前拥有的m d a 工具己 经可以给我们带来足够的实实在在的好处。 因为m d a 目前还处于初级阶段，语言和工具都没有发展到成熟的地步，所 以到目前为止我们看到的工具对m d a 的支持都是比较有限的。 2 4 开发过程 软件工程中的方法学( m e t h o d o l o g y ) 是指一系列你需要照着做的方法，或者 说一系列约束开发人员的规则。按照规则的多少和约束的强弱，可以大致地把方 法学分为重型和轻型两种。“方法学”也可以叫做“过程”，这两个词一般是可互 换的。m d a 并不要求你使用特定的软件开发过程，它是“轻重咸宜”的。o m g 并没有把过程标准化，所以你可以随意。当然，过程应当可以显示模型和交换在 m d a 中的核心地位。下面两小节叙述了一些流行的过程是如何同m d a 配合的。 2 4 1r a t i o n a l 统一过程 重型方法学比较正规和严谨。在采用重型方法学的项目中，开发人员具有较 强的可替换性，因为方法学本身强制要求开发者把他所创造的所有东西按照该方 基于u m l 的模型驱动软件开发应用与研究 法学规定的格式记录在案。项目经理可能会比较偏爱这样的过程，因为这些过程 让他们感觉对项目的控制更牢固，风险比较小。开发人员则不会喜欢这样的方法 学，因为他们会觉得做连篇累牍的文档工作很无聊又很费时间，而且占用的是自 己本可用于开发的时间。一般而言，大型项目采用重型方法学好一些。 比较流行的r a t i o n a l 统一过程( r a t i o n a lu n i f i e dp r o c e s s ，r u p ) 属于重型方法。 u m l 在r u p 中扮演了重要的角色。r u p 中许多工件都表现为u m l 模型。如果 我们可以以m d a 的方式来使用这些模型，那么它们就能够变换为p s m 和代码。 当我们为m d a 项目配置r u p 时，我们需要确保创建的模型满足m d a 的要求。 当我们这样做了，r u p 所使用的模型就不再是“官僚主义”的损耗了，而是 成为“真正”的软件开发的一部分。编写书面文档和编写代码的平衡向后者移动 了，同时，创建的工件也满足了项目经理们保持控制的要求。 2 4 2 极限编程 轻型方法学则具有和重型方法学相反的特质。记录在案的东西不多，交付的 就是代码以及可用的产品，当然还有测试用例。大多数交流是口头的、非正式的， 很高效，但是也只存在于项目人成员的脑海中。如果成员从项目中离去，那么他 脑海中的这些东西也随之带走。因为开发人员往往都希望自己具有不可替代的重 要性，而且一般都觉得写程序比写文档好玩，再者轻装向藏可以走得比较快( 因 为不必把时间浪费于编写正规文档) ，所以开发人员一般都比较偏爱轻型方法学。 一般而言，小型项目采用轻型方法学好一些。 极限编程( e x t r e m e p r o g r a m m i n g ，x p ) 是轻型方法学中非常著名的一个。x p 方法关注焦点是以小幅增量来编写代码，所以你始终拥有个可工作的系统。每 项新需求都必须伴随着一个测试用例，以测试软件。当增加新的功能时，除了新 测试外，所有以往的测试也都会被执行，以确保已经存在的功能没有被破坏。 但是，只有代码和测试用例会给软件系统的维护人员带来很大难度。a l i s t a i r c o c k b u m 曾说过需要留给新人“路标”。这些“路标”常常以文字和高层次图表 的形式出现。没有它们，你就像置身于一个陌生的城市，没有地图，也没有指示 方向的交通标志。在极限编程中，往往把创建路标视为负担。当我们认识到这些 第2 章国内外发展情况 路标可以以m d a 模型的形式出现，而模型又可以直接变换成代码时，刨建这些 路标就不再是负担了。相反，高层次的模型还能加快软件的开发。这意味着，我 们可以把x p 推向更高的层次极限建模( e x t r e m em o d e l i n g ，x m ) ，目前x m 的概念已经出现。 基于u m l 的模型驱动软件开发应用与研究 第3 章模型驱动开发基础理论 本章介绍了与本课题相关的模型驱动开发基础理论，包括模型驱动构架 ( m d a ) 、统一建模语言( u m l ) 、以及相关的工具。m d a 是由o m g 定义的一 个软件开发框架，m d a 方法可以用来创建良好的设计，应付多样化的实现技术， 延长软件的生命期。m d a 基于广为使用的可视化、存储、交换软件设计和模型 的业界标准。在这些标准中，最著名的就是统一建模语言( u m l ) 。o m g 创建 了u m l ，为工程师交换和表达思想提供了通用的、广泛理鳃的可视化语言，从 而为良好设计打下了坚实的基础。可视化建模的工具也因此快速普及。 3 1 模型驱动构架 模型驱动构架( m d a ) 的关键之处是，模型在软件开发过程中扮演了非常重 要的角色，整个开发过程是由对软件系统的建模行为驱动的。在本节中，先解释 基本的m d a 开发生命周期是怎样的，然后介绍m d a 为了实现这个生命周期需 要哪些组成部件，最后介绍m d a 组成部件所涉及的一些主要元素是如何融入到 整个m d a 框架中去的。 3 1 1m d a 开发生命周期 图3 1 描述了m d a 开发生命周期，图中标出了和传统的生命周期相同的几 个阶段。和传统的生命周期相比，一个主要的不同在于开发阶段创建的工件的性 质。从图中可以看出，p i m 、p s m 和代码表现为开发生命周期中不同阶段的工件。 这些工件是形式化模型，也就是可以被计算机理解的模型。它们表现了系统规约 的不同抽象层次，能够把高层次的p i m 变换成低层次的p s m ，这提升了开发者 工作的抽象层次，从而让开发者可以少流汗、多办事，以较少的努力创建更复杂 的系统。下面列出了位于m d a 核心的这三种模型。 平台独立模型 第3 章模型驱动开发基础理论 m d a 定义的第一类模型是具有高抽象层次、独立于任何实现技术的模型。 我们把这类模型叫做平台独立模型( p l a t f o r mi n d e p e n d e n tm o d e l ，p i m ) 。 平台相关模型 下一步，p i m 被变换为一个或多个平台相关模型( p l a t f o r ms p e c i f i cm o d e l ， p s m ) 。p s m 是为某种特定实现技术量身定制的，在p s m 中使用这种技术中可 用的实现构造来描述系统。p i m 可以被变换成一个或多个p s m ，为每个特定的 技术平台生成一个单独的p s m 。今天许多系统跨越了好几种技术，因此一个p i i v l 对应于多个p s m 是很常见的。 代码 开发的最后一步是把每个p s m 变换成代码。因为p s m 同相应技术密切相关， 所以这一变换相对较为直接。 图3 - 1m d a 软件开发生命周期 基于u m l 的模型驱动软件开发应用与研究 m d a 过程看起来很像传统开发过程，但是，实际上有一个关键的不同点： 传统i - _ ，从模型到模型的变换，或者从模型到代码的变换，主要是手工完成的。 许多丁具可以从模型生成部分代码，但是往 手l l 步于生成一些模板代码，大部 分的工作还是需要手工完成。 与此相反，m d a 变换总是由丁具执行的，如图3 - 2 所示。许多工具可以把 p s m 变换成代码，这毫无新奇之处因为p s m 已经和代码很接近了。m d a 的 创新之处是把p i m 到p s m 的变换也自动化了。这是m d a 带来的显著好处。因 为m d a 方法还非常新。现有的工具还没有稳健到可以百分之百地成功转换p i m 到p s m ，并把p s m 再转换到代码。开发者需要手工强化生成的p s m 和( 或) 代码模型。 一昏阻 图3 - 2 m d a 开发过程的3 个主要步骤 3 1 2m d a 组成部件 为了实现上- ，j 、节所述的m d a 过程，我们需要一些“建筑材料”。下面介绍 一下m d a 框架的组成部件： 高层次模型。用标准、精确定义的语言编写，一致而精确，并包含足够 的系统信息。 一种或多种标准、精确定义的语言。用来编写高层次模型。 “如何自动把p i m 变换到特定p s m ”的定义。在依照m d a 过程开发的 项目巾会产生一些各个公司自己的定义，但定义最好还是公有，甚至被 标准化。最好还可以让用户根据需要调整这些定义。 编写这些定义的语言。这种语言必须被变换工具解释执行，因此必须是 形式化语言。 能够执行变换定义的工具。最好这些工具还能让用户灵活按需调整变换 第3 章模型驱动开发基础理论 步骤。 能够执行p s m 到代码的变换的工具。 3 1 3m d a 框架 上一小节所述的m d a 组成部件涉及到m d a 框架的一些主要元素，包括： 模型、p 1 m 、p s m 、语言、变换、变换定义、变换工具、元语言、变换定义语言。 下面给出这些元素的定义以及它们在整个m d a 框架中扮演的角色： 模型是以精确定义的语言对系统( 或系统的一部分) 作出的描述。 - p i m 是平台独立模型，描述了系统，但不涉及最终实现平台的知识。 _ p s m 是平台相关模型，描述了系统，并且包含最终实现平台的全部 知识。 精确定义的语言是具有精确定义的形式( 语法) 和含义( 语义) 的语言， 这样的语言适合计算机自动解释。 变换是按照变换定义从源模型到目标模型的自动生成。 变换定义是一组变换规则，这些规则共同描述了用源语言表述的模型如 何变换为用目标语言表述的模型。 变换规则是对源语言中一个( 或一些) 构造如何变换为目标语言中一个 ( 或些) 构造的描述。 变换工具按照变换定义为特定源模型执行变换。 元语言是描述建模语言的特殊语言。 交换定义语言是用来表述变换定义的语言。 从开发者的角度看，p i m 和p s m 是最重要的元素。所有这些元素以图3 3 所示的方式融入了完整的m d a 框架。请注意，图3 3 只显示了一个p s m ，但是 一个p i m 常常可以生成多个p s m ，而且还会生成它们之间可能的桥接器。图中 只有一个从p 1 m 到p s m 的变换，但另一个变换从p s m 到代码，也是必要 的。 基于u m l 的模型驱动软件开笈应用与研究 表述i 3 2u m l 语言 图3 - 3 完整的m d a 框架 1 表述 m d a 基于广为使用的可视化、存储、交换软件设计和模型的业界标准。在 这些标准申，最著名、也最为广泛使用的就是统一建模语占( u m l ) 。u m l 提 供了单一的、标准化的、强大的语言来全面描述一个系统，是种削于在所有关 注系统的人之间交流的统语言。本节中，我们首先简单回顾。下u m l 的发展 历史，然后介绍u m i ，的组成，最后蒋深入u m l 各种图，介绍一下u m l 的体 系结构，以便更好的理解u m l 。 3 2 1u m l 的历史 2 u 【生纪8 0 年代末9 0 年代初，先后出现了几十种面向对象的分析设计方法。 圈 一 一 圈 第3 章模型驱动开发基础理论 其中，b o o t h ，c o a d y o u r d o n o m t 和j a c o b s o n 等方法得到了面向对象软件开发 界的广泛认可。各种方法对许多面向对象的概念的理解不尽相同，即便概念相同， 各自技术上的表示法也不同。通过9 0 年代不同方法流派之间的争论，人们逐渐 认识到不同的方法既有其容易解决的问题，又有其不容易解决的问题，彼此之间 需要进行融合和借鉴，并且各种方法的表示也有很大的差异，不利于进一步的交 流与协作。在这种情况下，统一建模语言( u m l ) 于9 0 年代中期应运而生。 u m l 的产生离不开三位面向对象的方法论专家gb o o t h ，j r u m b a u g h 和i j a c o b s o n 的通力合作。他们从多种方法中吸取了大量有用的建模概念，使u m l 的概念和表示法在规模上超过了以往任何一种方法，并且提出了允许用户对语言 做进一步扩展的机制。u m l 使不同厂商开发的系统模型能够基于共同的概念， 使用相同的表示法，呈现彼此一致的模型风格。1 9 9 7 年1 1 月u m l 的1 1 版本 被o m g 组织正式采纳为标准的建模语言，并在随后的几年中迅速地发展为事实 上的建模语言国际标准，广泛地用于应用领域和多种类型的系统建模。 2 0 0 2 年初，o m g 提出了m d a 框架概念。而u m l l x 存在一些缺陷，不能 对m d a 提供很好的支持，比如u m l l ，x 太复杂，图形不够精确，在理解上容易 导致分歧等等。为了解决这些问题，2 0 0 3 年6 月，o m g 推荐采用u m l2 0 ， 完成了这个工业标准建模语言的一次大的升级，它简化了u m l i x 的复杂性，归 并了不一致的模型，为架构建模和动态行为的描述提供了更强的支持，为m d a 提供了坚实的基础。将来的u m l 将向着语言家族化、可执行化、精确化等理念 迈进，为软件产业的工程化提供更有力的支撑。 3 2 2u m l 的组成 u m l 包括了一些可以相互组合为图表的图形元素。由于u m l 是一种语言， 所以u m l 具有组合这些元素的规则。这里就不介绍这些元素和规则了，而是直 接介绍一下u m l 的各种图。 对于复杂系统，我们无法从一个单一的视角进行充分和清晰的建模。u m l 提供了各种图，这些图的目的是用多个视图来展示一个系统，这组视图被称为一 个模型。u m l 2 0 提供了1 3 种图，包括：用例图、类图、对象图、顺序图、协 基于u m l 的模型驱动软件开发应用与研究 作图、状态图、活动图、构件图、包图、部署图、组成结构图( 或称为构架图) 、 交互纵览图、计时图。其中组成结构图、交互纵览图、以及计时图是u m l 2 0 新 增的图。其它图也有了更精确更强大的表达能力。尤其是对细节行为的表达与描 述是u m l 被主要增强的一部分。这使得u m l 2 0 可以更精确地表达系统，并使 模型变得可执行。 我们在描述系统的时候可以根据需要有选择的使用几种u m l 图，不一定要 用尽所有的圈来表达系统。这里就不再具体介绍u m l 各种图的用法，我们在后 面的第4 , 3 节中将看到一个运用u m l 图描述系统的应用举例，从中同时也能看 到一些u m l 2 0 的新特性。 另外，u m l 2 0 使得定义新的u m l p r o f i l e 变得更加容易，这样就便于将建模 扩展到新的应用领域。 3 2 3u m l 的体系结构 u m l 具有一个四层体系结构，每个层次是根据该层中元素的一般性程度划 分的。这些层次分别称为m o 、m 1 、m 2 和m 3 。图3 4 给出了该四层体系结构。 m 3 m l m o 图3 - 4u m l 的四层体系结构表示 最具体的一层，m o 层，是运行时实例层。根据u m l 模型生成的代码对应到 该层。 第3 章模型驱动开发基础理论 m i 层叫做模型层。我们使用u m l 建立的模型就在这一层。m 1 层的概念都 是m o 层实例的归类。换句话说，m o 层的元素都是m 1 层的元素的实例。例如， 名字n qw a n g h u a 和z h a n g h o n g 的客户都是m 1 层元素类c u s t o m e r 的实例。 m 2 层叫做元模型层。m 2 层的元素规定了m 1 层的元素，是对m 1 层元素的 归类，例如类( c l a s s ) 和关联( a s s o c i a t i o n ) 。位于m 1 层的元素( 类、属性以 及其余模型元素) 是m 2 层类的实例。我们学习u m l 概念的时候，通常是在这 一层进行。 m 3 层叫做元元模型层。m 2 层的每个元素都是m 3 层元素的实例，m 3 层的 每个元素都是m 2 层元素的归类。o m g 有一种特殊的语言，叫做元对象设施 ( m e t ao b j e c tf a c i l i t y , m o f ) ，它位于该层，是专门用来定义其他所有语言的。 我们日常的基本工作不会接触到该层，但熟悉它的概念能帮助我们更好地理解 u m l 以及方便地应用建模工具。实际上，那些生产u m l 建模工具的厂商必须 从这一层开始。 原则上可以继续增加更多的层次，但是更多的层次没有什么用。o m g 没有 定义m 4 层，而是规定所有m 3 层的元素必须定义为m 3 层本身的概念的实例。 所以m o f 本身是用m o f 定义的。 m d a 中用到的语言必须具有形式化的定义，这样工具才能够对用这些语言 定义的模型进行自动变换。被o m g 标准化的所有语言都有这样的形式化定义。 元对象设旌( m o f ) 是专门用来定义其他所有语言的，这确保了工具可以读写 由o m g 标准化的所有语言。另外，m o f 还被用于为m i 层模型定义基于流或 基于文件的交换格式。该交换格式是基于x m l ( e x t e n s i b l em a r k u pl a n g u a g e ， 可扩展标示语言) 的，被称为x m i ( x m lm e t a d a t ai n t e r c h a n g e ，x m l 元数据交 换) 。x m i 也能用来生成元模型的标准交换格式。 3 3 工具 基于u m l 的模型驱动软件开发应用与研究 u m l 语言的广泛适用性导致了u m l 建模工具的快速普及。自从m d a 成为 时髦用语后，很多厂商又声称它们的工具支持m d a ，同时也涌现出一些新的 m d a 工具。在第2 3 节中我们已经说过对m d a 的支持是多种多样的，并介绍 了工具对变换的支持。在m d a 开发环境中，变换工具处于核心地位，但它们并 不是我们所需要的全部，我们还需要别的相关功能。例如，我们需要用工具来创 建和修改模型。图3 5 显示了一个完整的环境应该提供什么功能。下面对它们作 一个详细的讨论。 图3 - 5m d a 开发环境的功能 代码编辑器( i d e ) ：交互开发环境提供的常用功能，比如调试、编译、 代码编辑，是不容忽视的。 代码文件：虽然我们可以把代码看作模型，但是这个模型一般是存放在 文本文件中的。文本文件不是其他工具能够理解的格式，所以我们需要以下两种 工具 - 代码文件解析器：该解析器读入文本格式的代码文件，并将代码按 照可以让其他工具使用的模型形式保存在模型仓库。 代码文件生成器：该生成器读入模型仓库中的代码并产生文本代码 文件。 模型仓库：为模型提供的数据库，可以保存模型，也可以查询模型。 模型编辑器( c a s e 工具) ：为模型提供的编辑器，可以创建和修改模型。 模型校验器：用来生成其他模型