（计算机软件与理论专业论文）模型驱动架构mda中的方法与实现技术的研究.pdf

摘要 摘要 模型驱动体系结构( m d a ) 是由对象管理组织( o m g ) 于2 0 0 1 年提出的 软件开发方法。传统的软件开发方法可以被看着是以编码为中心的开发方法， m d a 则可以看作是以模型为中心，它将模型在软件开发过程的作用提到前所未 有的高度。在传统以编码为中心的开发方法中，模型在需求分析、系统设计阶 段被创建出来，开发阶段对于指导程序员完成编码工作。在m d a 方法中，模 型不只是起到指导作用，而是应用模型转换工具从模型生成代码，前提条件是 模型足够精确信息足够完备。可见，建模和模型转换是m d a 开发方法学中的 两个重要环节。因此，本文的工作围绕着建模和模型转换展开。 在建模部分，本文将构造一个支持分布式协同类建模的u m l 工具原型。 目前市场上已经有许多u m l 建模工具，但是这些建模工具只支f 二单机使用， 、 并未提供协同建模的功能。随着m d a 的逐步发展，建模将变为软件开发的核 心工作，提供协同功能的建模工具将有助于开发人员远距离跨地区协作完成建 模工作。本文将在总结协同建模动作的形式描述的基础上完成一个协同建模工 具的原型。 在w c b 开发领域，没有一种可视化描述页面处理流程的机制。u m l 中的 活动图用于描述用例或商业过程的逻辑流程。可以通过扩展u m l 的活动图， 使之能够描述w c b 页面的处理流程。因此，在本文的模型转换部分将创建一个 组件，该组件能够将u m l 活动图所描述的页面处理流程转换成s p f i n g m v c 组 件。 关键词模型驱动体系结构；协同建模；模型转换；a n d r o m d a a b s t r a c t a b s t r a c t m o d e ld r i v e na r c h i t e c t u r c ( m d a ) w a sp r o m p t e db yo b j e c tm a n a g e m n tg r o u pi n 2 0 0 1 t r a d i t i o n a ls o f t w a r ed e v e l o p m e n tm e t h o d sa r ea l lc o d e - c e n t r i c , b u tm d ac a n b es 嘲蠲am o d e l c e n t r i cm e t h o d m d at r e a t sm o d e l 硇f i r s t - c l a s sc i t i z e n i n t r a d i t i o n a l c o d e c e n t r i cm e t h o d s ，m o d e li sc r e a t e di ns y s t e md e s i g np h a s ea n di su s e d a sar e f e r e n c ei nc o d i n gp h a s e i nm d am e t h o d ，m o d e li sn o to n l yar e f e r e n c eb u t a l s oai n p u to f m o d e lt r a n s f o r m a t i t o o lw h i c hc a l lg e n e r a t ee x e c u t a b l es o u r c ec o d e m o d e l i n ga n dm o d e lu a n s f o r m a t i o ni st w oi m p o r t a n tt e c h n o l o g yo f m d a t h ew o r k o f t h i sp a p e ri sr e l a t e dt om o d e l i n ga n dm o d e lt r a n s f o r m a t i o n i nt h ep a r to fm o d e l i n gr e l a t e dw o r k , t h i sp a p e rw i l lc o n s t r u c tac c o l l a b o r a t i v eu m l m o d e l i n gt o o l sw h i c hs u p p o r t sd i s t r i b u t em o d e l i n g t h e r ea r em a n yu m lm o d e l i n g t o o l si nt h em a r k e t b u tn o n eo ft h e ms u p p o r t sc o l l a b o r a t i v e w i t ht h em a r i r eo f m d a , i ti sm o d e l i n gt h a tw i l lb et h ep r i m a r yw o r ko fs o f t w a r ed e v e l o p m e n t a c o l l a b o r a t i v eu m lt o o l sw i l le n a b l ec o l l a b o r a t i o no fd e v e l o p e r sw h oa r ew o r k i n ga t d i f f e r e n tp l a c e s oam e a n so f c r e a t i n gac o l l a b o r a t i v eu m l t o o l si sd e s c r i b e di nt h e f i r s tp a r to f t h i sp a p e r i nt h ed o m a i no fw e bd e v e l o p m e n tt h e r ei sn ot o o l sw h i c hc a l ld e s c r i b ew e b p a g e w o r kf l o wi ng r a p h i cm a n n e r u m l a c t i v i t y & a 伊a mi su s e dt om o d e ll o g i c a lf l o wo f u s ec a s eo rb u s i n e s sp r o c e s s t od e s c r i b ew e bp a g ew o r kn o w u m la c t i v i t y d i a g r a mm u s tb ee x t e n d e d i nt h ep a r to fm o d e lm m s f o m a t i o n , t h i sp a p e rw i l l i m p l e m e n tat e m p l a t e - b a s ea n d r o m d am o d e lt r a n s f o r m a t i o np h i # nw h i c h 啪 c o n v e r tu m l a c t i v i t yd i a g r a mt os p r i n g m v cc o m p o n e n t s k e y w o r d sm d a ；c o l l a b o r a t i i vm o d e l i n g ；m o d e lt r a n s f o r m a t i o n ；a n d r o m d a i 独创性声明 本人声明所呈交的论文是我个人在导师指导下进行的研究工作及取得的研 究成果。尽我所知，除了文中特别加以标注和致谢的地方外，论文中不包含其他 人已经发表或撰写过的研究成果，也不包含为获得北京工业大学或其它教育机构 的学位或证书而使用过的材料。与我一同工作的同志对本研究所做的任何贡献均 已在论文中作了明确的说明并表示了谢意。 签名： 筮! 日期：型z 么z 关于论文使用授权的说明 本人完全了解北京工业大学有关保留、使用学位论文的规定，即：学按有权 保留送交论文的复印件，允许论文被查阅和借阅；学校可以公布论文的全部或部 分内容，可以采用影印、缩印或其他复制手段保存论文。 ( 保密的论文在解密后应遵守此规定) 签名：土筐壅，导师签名：卫主垒土日期：2 盟7 第1 章绪论 第1 章绪论 1 1 课题背景 模型驱动架构m d a ( m o d e ld r i v e na r c h i t e c t u r e ) 是由对象管理组织o m g ( o b j e c t m a n a g e m e n t g r o u p ) 提出的新型的软件开发方法学。它是以模型为中心 的开发过程，实现由模型到实现的自动转换，从而简化软件开发。m d a 的关键 之处就是软件开发过程是由对软件系统的建模行为驱动的。m d a 将抽象层次提 高到模型的高度，在m d a 环境中开发者把重心转移到业务逻辑的建模上，目标 平台的技术不需要太多关心。m d a 将软件系统的模型分为平台无关模型( p i m ) 和 平台相关模型( p s m ) ，p i m 具有高抽象层次，不包括任何与实现技术相关的信息。 p s m 是跟特定平台相关的模型。在m d a 开发过程中，首先使用平台无关的建模 语言来搭建p i m ，然后根据特定平台和实现语言的转换规则，将p i m 转换成一个 或多个p s m ，然后再由p s m 生成应用程序代码和测试框架。 1 2 研究现状 1 2 1m d a 研究现状 m d a 由四个基础技术构成，分别是u m l ( u n i f i e dm o d e l i n gl a n g u a g e ) 、 m o f ( m c t a o b j e c tf a c i l i t y ) 、x m i ( x m lm c t a d a t ai n t e r c h a n g e ) 和c w m ( c o m m o n w a r e h o u s em e t a m o d e l ) 啦】。u m l i p 统一建模语言，用于创建软件模型，是u m l 中非常重要的组成部分【6 】。m o f b p 源对象设施，用于描述元建模语言。x m i 即基 于x m l 的元数据交换，用于将模型转换成x m l 文档利于交换。c w m 及公共仓库 原模型，用于描述数据模型之间的变换。 自从2 0 0 1 年7 月，o m g 提出m d a 方法以后，m d a 以及辅助支撑技术都在不 断的发展和完善。 u m l 经历了从1 4 到1 5 再到2 0 的发展过程。u m l i 4 到u m l l 5 变化不大。而 u m l 2 0 较之1 4 和1 5 有较大的变化。u m l 2 0 的变化主要包括以下几点：活动图 不再是状态图的特例；协作图( c o l l a b o r a t i o nd i a g r a m s ) 更名为通讯图 ( c o m m u n i c a t i o nd i a g r a m s ) ；增加了一种专为复合结构设计的标识，使用该标 识，用户可以分级地对类进行描述；对于m o f 不兼容之处做了修改；增强了动 态语义的表示。 m o f 的最新版本是2 0 ，之前的版本是1 4 。在2 0 中，m o f 为了与u m l 兼容， 也做了相应的修改。除此之外，为了为模型转换提供一种标准的方法，o m g 提 出了m o f 下的子协议q v t ( q u e r y ，v i e w ，t r a n s f o r m a t i o n ) ，其中文译名是查询 北京下业大学t 学硕十学位论文 视图和转换。q v t 共收到了8 个不同的提案，目前还处在讨论制定过程中，尚未 最终定稿。 支持m d a 开发的工具也有不少。商业m d a 开发工具有b o r l a n dt o g e t h e r 、 i n t e r a c t i v eo b j e c t sa r c s t y l c r 和c o m p u w a r eo p t i m a l j 等。开源的m d a 开发工具包括 o p e n m d x j 0 a n d r o m d a 。此外，在国内有金蝶的b o s 、浪潮的楼上和楚凡的t r u f u n 都提供了m d a 开发的支持。 1 2 2 协同建模工具的研究现状 目前，市场已经存在许多建模工具，比如b o r l a n dt o g e t h e r 、m mr a t i o n a l r o s e 、n o m a g i cm a g i c d r a w 等等，但是还没有支持协同的建模工具出现。在集 成开发工具中已经带有协同功能。其中包括b o r l a n dj b u i l d c r2 0 0 6 和i n t e l l i ji d e a 6 。在j b u i l d e r 2 0 0 6 和i d e a6 中都集成了一个类似于m s n 的及时聊天工具。开发 人员可以利用该工具进行简单的文字交流。除此之外，j b u i l d e r 2 0 0 6 提供了更强 大的协同功能。它支持多个开发人员同时参与一个项目的开发。在协同模式下， 当主控端对一文件进行协同编辑，其编辑结果会及时的显示在其余各端。当主控 端进行调试时，其余各端也会进入调试状态，可以参与调试过程。从集成开发环 境支持协同来看，未来支持协同开发建模工具也会出现。 1 2 3 模型之间转换方法研究现状 模型间的转换是m d a 的中心和灵魂p 】。已经提出了很多种转换方法。这些转 换方法大致上可以分为三类：直接操纵模型、中间形式和专用转换语言。直接操 纵模型是指建模工具向外界提供一套访问模型的a p l ( a p p l i c a t i o np r o g r a m m i n g i n t e r f a c e ) ，转换工具通过这些a p i 访问模型，完成转换。中间形式是指建模工具 将模型导出成标准格式，比如x m i ，转换工具读取标准格式文件，完成转换。专 用转换语言是指转换工具提供一套描述、组合和使用模型转换方法的机制。在众 多的建模工具中，r a t i o n a lx d e 提供了访问模型的a p i ，可以是通过c 、c + + 、j a v a 以及v b 等编程语言访问模型，编写模型转换规则。显然。这种方法属于直接操 纵模型类。属于中间形式的工具有m t r a n s 和a n d r o m d a 等。m t r a n s 使用x s l t 语 言描述模型转换。a n d r o m d a 贝l j 通过j a v a 语言读取x m i 文件。属于专用转换语言 的是前面提到的q v t 。因为q v t 的标准化工作还没有结束，所以支持q v t 的工 具还不多。 1 3 本文的工作 1 3 1 研究工作 在前面。协同建模工具研究现状”小节中提到过，目前还没有支持协同建模 的u m l t 具。随着m d a 技术的发展和成熟，跨地区分布式协同建模的需求会出 2 第1 章绪论 现，支持分布式协同的建模工具将成为必须，因此本文将实现一个支持协同建模 的u m l i 具原型。该原型相对简单，只实现协同类建模。建模工具由三部分组 成，分别是，图形绘制、模型存储和协同交互。其中协同交互是重点。在构建协 同机制时，先对协同操作进行了抽象，给出了形式化描述，用以指导协同机制的 创建。 模型转换是m d a 中的另一个重点。目前支持w e b 开发的m d a 工具所支持的 目标平台是s 仃u t 吾。s t r u t s 经过五年的发展已经和w e b w o r k s 合并，改称s t r u t s 2 。 s p r i n g m v c 是与s t r u t s 2 类似的一个w 曲开发框架，本文将创建一个支持 s p r i n g m v c 的模型转换组件，该组件的功能是将u m l 活动图所描述的用例处理 流程转换成s 研n g m v c 组件。 。 m d a 的开发流程与传统开发流程一样，同样包含需求分析、系统设计、编 码、测试和发布。如图1 1 所示。系统设计时，使用u m l 建模工具构建软件模型。 本文完成的协同建模工具应用在这一阶段。编码阶段主要由转换工具完成，转换 工具根据软件模型生成代码。本文实现的模型转换组件用在这一阶段。 图1 - 1 研究内容说明 f i g u r e1 - 1i n v e s t i g a t i o ni l l u s t r a t i o n 1 3 2 论文组织 文章的组织结构如下： 第二章，介绍m d a 及相关技术，包括m d a 的由来、开发模型和核心技术。 北京t 业大学t 学硕十学位论文 第三章，首先提出了协同建模操作的形式化描述，为协同建模操作寻找精确 的数学描述。然后分析了协同建模总体需求，然后详细描述了协同建模工具的用 例，最后描述协同建模工具构建过程中遇到的问题以及解决方法。 第四章，转入另一个议题：模型转换。首先简要介绍了模型转换的概念和常 用转换方法，然后描述了a n d r o m d a 中的模型转换方法。 第五章，首先描述了一般c a r t r i d g e 的开发过程，随后按照c a r t d d g e 的开 发过程完成支持s p r i n g m v c 的c a r t r i d g e 的开发。最后通过一个实际应用的案 例模型，来演示模型转换的结果。 4 第2 章m d a 及相关技术概述 一第2 章m d a 及相关技术概述 2 1 m d a 概述 2 1 1m d a 的由来 软件开发可行性变量包括三个因素：生产成本、全生命期和软件质量。软件 开发的终极目的就是用最低的生产成本开发出最高质量最长全生命期的软件。然 而，事与愿违，建立高质量、长寿命的软件事代价高昂的。结果是，我们不得不 再质量、全寿命期和开发成本之间做出难以接受的折衷 5 1 。 回首软件产业的发展历史，我们会看到当不断增长的需求触及当时开发方法 的极限时，总会出现新的方法来替代或者补充已经存在的方法，一开始很缓慢， 然后势头越来越猛。这些方法推动质量、全寿命期和生产成本朝更好的方向发展。 以机器为中心的计算 早期的程序员以0 和l 书写计算机指令，费力地把c p u 使用的指令的比特 模式车出来。这在今天看来奇怪而低效。这种“劳动密集型”编码方式天生就代 价高昂，在加上高硬件成本，极大的限制了可计算的任务数量。 软件领域的一个重要创举时汇编语言，它延长了以机器为中心的计算方法的 寿命。汇编语言允许程序员使用简单的助记符来表示计算机所能理解的本地指 令。程序员可以使用m o va x ，d x 来把数据从d 寄存器移到a 寄存器，而不 必写出执行移动数据指令的二进制代码。这样的助记符是对二进制指令的抽象。 汇编语言的出现极大的改变了经济可行性方程。与使用0 和1 编程相比，使 用汇编语言编写程序耗时更少，因此降低了生产成本。另外，使用助记符而不是 0 和l 使程序员更不容易犯错，程序的质量也提高了。使用汇编语言编写的程序 对于构成本地指令的0 和l 模式的改变也不太敏感。比如，如果某个版本的处理 器的m o v 指令的比特模式改变了，那么一个修改过的汇编器可以把m o v 指令 汇编成新的比特模式，以前编写的汇编程序则不需要修改。因此，程序的寿命会 变得长一点。由此可见，在0 和1 上增加一层抽象使可行性方程中的所有三个变 量朝好的方向变化了。 以应用为中心的计算 汇编程序的成功指明了通向以应用为中心的世界的道路。在那个世界中，更 为复杂的应用程序在解决更为广泛的业务问题，这样的问题可能伴随着多个步 骤、更复杂的数据结构、更复杂的人机界面。但是，对更复杂的计算的需求，就 在经济可行性上给“以机器为中心”的计算方式带来了极大压力。 第三代编程语言( 3 g l ) 的出现使得生产力出现了飞跃。开发者可以用比汇编 更高层次的结构来编程。第三代编程语言简单指令代替了几十行甚至上百行汇编 北京丁业大学t 学硕十学位论文 代码，这极大地提高了程序员的生产率，从而降低了生产成本。同时，实现业务 功能所需编写的代码大幅减少，这也提高了计算机程序的质量。3 g l 还延长了程 序的全寿命期。3 g l 程序所使用的指令同本地处理器指令集细节相隔更远。如果 硬件发生了变化，一个新的编译器可以处理己存在的3 g l 程序，为新的目标处 理器产生不同的指令集。再一次，所有三个可行性变量都朝正确的方向做出了改 变。 以企业为中心的计算 随着时间的推移，人们对计算所能实现的自动化程度的期望越来越高。人们 己经不再满足于在企业内部建立自动化的“孤岛”。这些“孤岛”有重叠的功能， 这造成了重复的信息，而且将稀缺资源多次用于解决同一问题。因此，有必要在 企业内将这些“孤岛”连接整合。 软件界先后提出了基于组件开发、分布式计算、中间件、说明性规约、企业 构架、企业应用集成、契约式设计等等不同的方法，并且一些己付诸实践，不论 采用何种方法，无不期望能够在整合企业内部这些“孤岛”方面有所作为，然而 事实上这些方法在某些方面比较有效，但还不能够从根本上解决软件开发过程所 出现的问题。 以模型为中心的计算 为了提高软件开发的抽象层次，使三个可行性都朝正确的方向做出了改变， 对象管理组织于2 0 0 1 年提出了m d a 。m d a 将抽象层次提升到了模型层次。m d a 使用基于标准的建模语言作为形式化开发语言。形式化模型驱动产生3 g l 代码、 h m t l 、x m l 、w s d l 、i d l 以及其他工件的生成器。 传统开发方法把软件建模看作设计工作，而把3 g l 程序看作开发工作，把 建模人员和编码人员的角色分离。这样做的结果是，模型经常是非正式的，他们 不能被机器处理。程序员把他们看作“指南”和“说明书”，而不直接作用于编 码。m d a 使用可以被机器处理的形式化模型。这样的模型是生产过程的直接部 分。在这样的环境中，建模人员和编码人员的角色区分就不再那么明显了。建模 行为即是编程行为。 2 1 2m d a 开发过程的生命周期 m d a 开发生命周期与传统的软件开发生命周期并无太大的区别，主要分为 六个阶段，即需求捕获阶段、需求分析阶段、低层设计阶段、代码阶段、测试阶 段和发布阶段。其中主要不同是工件( a r t i f i c i a l i t y ，泛指人工建模后的电子文档 及代码) 在开发的需求设计阶段的表现和作用。 在传统的软件开发生命周期中，从需求捕获到需求分析，再到低层设计都是 靠文档支持的，存在于文本的形式上( 如图2 1 所示) 。这些文档对最终代码开 发只是形式上的参考。当编码开始的时候，前三个阶段所产生的文档和相关图表 6 第2 章m d a 及相关技术概述 就会迅速失去它们当初的价值。随着编码阶段的继续进行，图表和代码之间的关 联关系逐渐减弱甚至消失，文档和图表不再承担对代码进行精确描述的责任。随 着时间的推移，系统不断地被修改，文档、设计图表和代码之间的关系也越来越 疏远。于是相当多的开发人员便放弃了文档的维护及更新，仅对代码进行修改维 护，开发迭代过程仅在代码阶段循环，最初的文档常会因形同虚设而束之高阁了 址张 图2 1 传统软件开发生命周期n j f i g u r e2 - 1t r a d i t i o n a ls o f t w a r ed e v e l o p m e n t l i f ec y c l e 【6 】 然而在m d a 开发的生命周期中，上面提到的局面得到了扭转。需求分析和 低层设计不再是文档，而是形式化的模型，并可以被计算机处理，用于代码生成。 在m d a 开发中，其迭代过程的工件改动又回馈到需求分析，这种闭环的工作方 式正是传统软件开发所期盼的理想状态，如图2 2 所示。 7 北京工业大学丁学硕士学位论文 图2 - 2m d a 软件开发生命周期嘲 f i g u r e 2 - 2m d a s o f t w a r ed e v e l o p m e n tl i f ec y c l e 【6 】 总结m d a 的开发过程，其工作状态的转换过程如图2 3 所示。整个开发过 程是一个建模、精化模型、转换模型的过程。 辅化模型使扎更好 精化横墅撕导其 的直持惫务定斜乍墟两质量代码 图2 - 3 m d a 开发过程州 f i g u r e2 - 3m d ad e v e l o p m e n tp r o c e s s 【6 l 第一步：开发人员与领域专业人员共同搭建计算无关模型( c o m p u t i n g i n d e p e n d e n t m o d e l ，c d “) ，确定客户需求及系统在特定领域内的应用； 第二步：将c i m 模型转换成平台无关模型( p l a t e f o r mi n d e p e n d e n tm o d e l ， p i m ) ，并对p i m 模型进一步精化，使其能够更好的支持商业逻辑； 第三步：通过m d a 转换工具将p i m 转换到不同的特定平台上，生成平台相 关模型( p l a t e f o r ms p e c i f i cm o d e l ，p s m ) ，继续精化p s m 模型，以指导其生成高质 量的代码： 第四步：最后，通过转换工具将p s m 模型直接转换生成代码。 8 第2 章m d a 及相关技术概述 在开发过程中，c i m 建模工作和从c i m 到p i m 转换过程都需要人工完成， 是体现软件工程师创造性价值的工作；其余的模型、代码及相互转换的工作大部 分由m d a 工具自动完成。 2 1 3 与m d a 有关的概念 平台无关模型【5 l 平台无关模型是具有高抽象层次、独立于任何实现技术的模型。平台无关模 型描述支撑某些业务的软件系统。在平台无关模型中，对系统的建模视角是“系 统如何才能最好的支撑业务”。平台无关模型包含应用系统的信息、结构和行为 以及不同数据结构问的关系。平台无关模型是一个业务为中心的模型，不包含实 现和代码细节。开发和完善平台无关模型时，设计人员以声明方式定义业务规则， 例如初始值的设置和级联删除约束。平台无关模型的所有定义在低层的应用模型 和实际的代码中被重用和继承。设计人员在平台无关模型定义的内容越多，从平 台无关模型自动生产的内容越多。 平台相关模型【5 】 平台相关模型是由平台无关模型经过变换得到的、对应于某种特定平台的模 型。平台相关模型描述了最终实现平台的全部知识。例如，e j b ( e n t e r p r i s e j a v a b e a n ) p s m 是用e j b 结构表述的系统模型。它通常会包含e j b 特有的术语， 比如“r e m o t e i n t e r f a c e ”，”e n t i t y b e a n ”，”s e s s i o n b e a n ”等。平台无关模型可以被变 换成一个或几个平台相关模型，为每个特定的技术平台生成一个单独的平台相关 模型。 模型变换f 5 】 m d a 中各种模型扮演着不同的角色，我们希望从一种模型( 源模型) 自动得 到另一种模型( 目标模型) ，这就是模型变换。模型变换由一系列的变换规则组成， 形式上可以看作一个函数。这些变化规则是无歧义的规约，规定了如何从源语言 描述的源模型转换到目标语言描述的目标模型，目标模型的含义必须和源模型的 含义一致。m d a 软件开发过程中一般有两次变换：平台无关模型到平台相关模型 变换和平台相关模型到代码模型的变换。 2 2m d a 所涉及的核心技术 2 2 1u m l 简述 u m l 是一种面向对象的建模语言，它融合了8 0 0 c h , o m t 和d o s e 方法中 的基本概念，成为一种定义良好、易于表达、标准图形、功能强大且广泛适用的 建模语言。u m l 提供了九种可视化建模技术来描述系统的不同方面。这些建模 技术的可视化表示分别为用例图、类图、包图、状态图、活动图、顺序图、合作 9 北京r f = 业大学t 学硕十学位论文 图、组件图和部署图【1 9 】。从大的方面可以将这些图分为两类，即用于描述系统 静态结构的静态图和用于描述系统动态行为的动态图。静态图反映了系统的整体 结构、构成系统的个体以及个体之间的联系等信息。这些信息是系统的本质特征， 它们不受系统行为状态改变的影响。这些信息包括：类的组织结构( 属性和行为) 、 类的接1 2 、类之间的相互关系( 继承、聚合) 、包的结构、以及系统的物理结构等。 动态图描述了系统运行时系统中对象间的通信( 消息交互) 过程。动态图包括顺序 图、合作图、状态图和活动图，它们各自的侧重点不同。顺序图、合作图主要用 于描述对象之间的交互，而状态图、活动图主要用于描述对象的内部行为f 7 】。 虽然在m d a 中并没有强行规定必须使用u m l 来建模，但它与其他建模语言相 比表现出了极大的优势，因而m d a 最为重要的p i m 和p s m 这两层模型一般来 说都是通过u m l 来定义，可以说u m l 是m d a 的基础。 虽然使用u m l 可以较好地对系统结构方面进行建模，但它对系统动态内容 的描述能力较差，这样用u m l 建立的p i m 相对来说质量也不高，为了获得完美 的p i m ，有必要增加u m l 在系统动态方面的描述能力。目前有两种方法可以解 决这一问题：一种方法是使用可执行u m l ( e x e c u t a b l eu m l ) ，它被定义为普通 u m l 和动作语义的动态行为组合。在u m l 2 0 中新增的可执行特性使得模型在 需求分析方面如虎添翼，不但可以有效地描述需求，在系统编码之前就可以让模 型运转起来，提前验证用户需求。其次，它切实加强了u m l 在细节表达能力上 的欠缺，使u m l 在分解设计复杂度的同时，不丢失实现上的细节。但由于动作 语言的抽象层次较低，可执行u m l 一般只适用在一些专门领域，而不太适用于 高抽象层次的p i m ；另一种方法就是将u m l 和对象约束语言( o b j e c tc o n s t r a i n t l a n g u a g e ，o c l ) 相组合来创建p i m 。o c l 可以用于在u m l 模型上形式化地书写 表达式，表达式的内容可以包括属性的派生条件、查询操作体、前置、后置条件 等。其中系统的动态内容可以用o c l 加在操作上的前置、后置条件来表达，业 务规则也可以使用o c l 中的动态触发器来规约。在u m l 基础上使用o c l 表达 式的方法不仅扩展了u m l 的表达能力，而且有效地减少建模过程中的信息失真， 从而生成高质量和高层次的p i m 。目前后一种方法使用较多。 为了避免u m l 语言整体的复杂性，u m l 没有吸收所以的面向对象的建模 机制和技术而是设计了扩展机制，通过扩展机制用户可以定义使用自己的元素。 u m l 提供了两种扩展形式：u m lp r o f i l e 和通过m o f 扩展u m l 7 1 。 ( 1 ) u m lp r o f i l e ：在u m lp r o f i l e 中包含三种扩展机制：构造型( s t e r e o t y p e ) 、 标记值( t a g g e dv a l u e ) 和约束( c o n s t r a i n t ) 。在很多情况下我们利用u m l 的构 造型这种机制对u m l 进行扩展，使其能够应用到更广泛的领域。 构造型是建模元素的一种类型，扩展u m l 的语义。构造型必须以u m l 中 已经定义的元素为基础，可以扩展语义但不能扩展已存在的元素结构。构造型不 是给元素增加新的属性或约束，而是直接在已有元素中增加新的语义，这种机制 i o 第2 章m d a 及相关技术概述 可以看作是已有元素进行专有化。构造型的表示方法是在模型元素的旁边添加一 个构造型的名称，构造型名称使用双括号括起来，构造型名。构造型是一种 非常好的扩展机制他避免了u m l 语义过于复杂化，同时也使得u m l 能够适应 各种需求。 标记值是一对字符串包括标记字符串和值字符串也就是一个键值对，它存储 着有关元素的一些信息。标记值可以与任何元素相关联，包括模型元素和表达元 素。标记表示建模者想要记录的名字，值是给定元素的值。通常使用类似下面的 方式表示： n a m e = t o m ) 如果标记是个布尔类型，可以省略其值，默认为真。除了布尔类型以外其它 的类型都必须明确写出值。 。 约束是用文字表达式表示的语义限制，它应用于元素。约束显示在( ) 内， 可以直接放在图中或者独立出来。约束可以是u m l 预定义的，也可以之自定义 的。描述约束的语言可以是正式的数学符号、o c l 语言、伪代码或自然语言。 如果这种语言是非正式的，那么它的解释也是非正式的，并且要由人来解释。即 使约束由一种正式语言来表示，也不意味着它自动为有效约束。 ( 2 ) 通过m o f 扩展u m l u m l 元模型位于m 2 层，是通过m o f 定义的， 因此可以通过m o f 来扩展它。通过m o f 丰富的建模机制，可以建立特定领域 的扩展元模型，并建立这些扩展元模型与u m l 元模型之间的关系。简单说通过 m o f 来扩展u m l 相当于定义了一个新的元模型而不再是复用u m l 元模型了。 虽然最新u m l 2 0 的p r o f i l e 机制会更完善，但在实际应用中是使用轻型扩 展还是重型扩展或是二者结合的方式来扩展u m l 则要根据具体情况来决定。目 前大多数u m l 工具是支持轻型扩展机制。 2 2 2 m o f 概述 描述不同的功能需要不同的建模结构集。关系数据建模所需的建模结构集包 括表、列、键等等。工作流建模所需的建模结构集包括活动、执行者、变化、分 割、连接等等。u m l 类建模所需要的建模结构集包括类、属性、操作、关联等 等。 为了描述某一特定类型的模型，我们必须描述组成该类模型的建模结构集。 能有一种一致的方法来描述语言结构是非常有用的。 业界正在使用全然不同的方法来描述不同类型建模结构的本质。例如，用来 表述“表拥有列”的机制同表述“面向对象的类拥有它的操作”的机制大相径庭。 把不同的建模结构集合并成个集合，这就意味着把所有语言合并为一种， 这是不可行的。定义一种统一方式来描述不同类型的建模结构，这样我们就可以 用一种统一的方式来描述组成某类模型的建模结构属性以及建模结构间的关系。 北京t 业大学丁学硕十学位论文 m o f 就是描述建模结构的统一方式。m o f 被用来描述关系数据模型的建模 结构，也被用来描述u m l 类模型的建模结构，他还被用来描述其他类型的建模 所用到的结构。 m o f 包含4 个层次。按照抽象层次的到底，这四个层次分别被命名为m 3 、 m 2 、m i 和m 0 1 8 。 m 0 层是实例层。运行的系统位于m 0 层。举例来说，这些实例可以是“住 在英国伦敦市统一路1 舛号的j o en o b o d y 客户”或者“住在美国丹佛市林荫南 路6 6 5 号b 栋的m a r k e v e r y m a n 客户”。 m 1 层是模型层。在m 1 层的模型中定义了诸如c u s t o m e r 这样的概念及其 n a m e 、s t r e e t 、c i t y 属性。m i 层元素描述了m 0 层的“世界”看上去什么样。比 如，u m l 类c u s t o m e r 描述了m 0 层客户实例是什么样的。 m 2 层是是元模型层，也就是模型的模型。m 2 层中的元素描述m i 层的“世 界”看上去是什么样的。m 1 层的每个元素都是m 2 层元素的实例，m 2 层的每 个元素都是m i 层元素的归类。u m l 元模型就位于m 2 层。 m 3 层就是m o f 。我们可以把m 2 层元素看成是m 3 层元素的实例。m o 层 和m 1 层元素以及m i 层和m 2 层元素之间的关系同样也存在于m 2 层和m 3 层 之间。m 2 层的每个元素都是m 3 层元素的实例，m 3 层的每个元素都是m 2 层元 素的归类。m 3 层定义了思考m 2 层概念所需的概念。 一一；一、_ 一一一一一一一一一 ， m 0 层 图2 - 4 m o f 抽象层次嘲 f i g u r e2 -