（计算机软件与理论专业论文）uml建模过程中的不一致性分析.pdf

山东大学硕士学位论文 摘要 为一个大型复杂系统建模通常是一件非常烦琐和相当困难的工作，为了控制 和降低系统模型的复杂程度，人们通常采用多视图方法来有效地简化模型的表达。 一个软件系统模型由多个不同的视图来描述，每一个视图只展现某一个视角所关 心的内容，其结果是一个模型的复杂性被分割并被分配到一个个视图中。但在通 常情况下，一个视图仍然复杂得需要绘制多个范图才可以描述清楚，就这样，软 件系统模型被分解为一个个视图，视图又由一个个范图来表达，因此，在这些视 图和范图之间，存在着复杂的协作和约束关系，而我们处理这些复杂关系的能力 有限，所以多个视图之间、视图的多个范图之间就难免会出现不一致的情况。 本文就是主要对u m l 建模过程中的各个视图之间的不一致性问题进行了探讨， 不一致性是不同视图或范图之间对同一事物的描述发生冲突的现象，它的产生主 要是由于系统的复杂性和参与开发团体间开发规范的不同或考虑问题方式不同而 引起的。初期的开发阶段我们要在具有正确引导和自动维护的开发工具中进行， 并且要遵守一定的建模规则以最大限度的避免不一致性的出现。如果我们需要对 开发出的图表进行不一致性检测，可以使用实时检查、动态检查、静态检查和辅 助技术，也可以使用一种视图融合的方法进行检测，这种方法将不一致性转换与 不一致比较分开，将要检测的图表转换成同一种图表类型再进行比较，使检测工 作的时间复杂度由o ( n 2 ) 降为o ( n ) 。这种思想将所有的图表分为三个层次：从底层 到高层，从行为到结构，从一般到特殊。这三个层次间的图表在进行转换时使用 的技巧都是相似的。其次通过对订单管理子系统进行建模验证了前述的保证一致 性的规则是非常实用而且是非常有效的。最后部分对论文进行了总结并对未来发 展作了展望，支持u m l 建模的c a s e 工具有很多，但大部分还都不能很好地将不一致 性检测机制融入其中，而且不同工具其兼容性也很差，因此需要我们要根据软件 开发实际情况选择合适的开发工具。对待图表之b j 的不一致性问题要本着早发现 早消除的原则，如果设计中的不一致性在后续的开发过程中发现解决，需要的人 力物力都是相当大的，而且对软件的开发质量也有很大影响，因此，系统分析和 开发人员必须具备了解、识别、检测、删除图表日j 不一致性的能力，为软件的高 质量开发提供保证。 关键词：u m l 、不一致性、建模 山东大学硕士学位论文 a n a l y z eo fu 地m o d e li n c o n s i s t e n c y a b s t r a c t i ti sv e r yd i f f i c u l ta n df u s s yt om o d e lac o m p l e xs y s t e m i no r d e rt o c o n t r o la n dd e c r e a s et h ec o m p l e x i t yo fs y s t e mm o d e l 。m u l t i v i e w sa r eu s e d t os i m p l i f yt h ee x p r e s s i o no fm o d e l s as o f t w a r es y s t e mm o d e li sd e s c r i b e d b ym a n yd i f f e r e n tv i e w s ，b u te a c hv i e wo n l ys h o wc e r t a i nc o n t e n tf r o ms o m e a s p e c t s ，a sar e s u l t ，c o m p l e x i t yo fam o d e li ss e p a r a t e di n t om a n yd i f f e r e n t v i e w s i nc o m m o nc a s e ，m a n ys u b v i e w sa r en e c e s s a r yt oe x p r e s st h ev i e w c l e a r l y ，t h u s ，s o f t w a r es y s t e mi ss e p a r a t e dt om a n yd i f f e r e n tv i e w sa n d v i e w sa r es e p a r a t e dt om a n yd i f f e r e n ts u b v i e w s t h e r ea r ec o m p l e x c 0 1 1 a b o r a t i o na n dr e s t r i c tr e l a t i o n s h i pa m o n gt h o s ev i e w sa n ds u b v i e w s a n db e c a u s eo u r1 l i m i t e da b i l i t yt od e a lw i t h t h a tr e l a t i o n s h i p ， i n c o n s i s t e n c yi sh a r dt oa v o i d e d t h ei n c o n s i s t e n c yi nu m lm o d e l i n gp r o c e s si sm a i n l yd i s c u s s e di nt h i s p a p e r i ti st h ec o l l i s i o np h e n o m e n ao fd e s c r i b i n gt h es a m et h i n gb y d i f f e r e n tv i e w sa n ds u b v i e w s ，c a u s e db yt h ec o m p l e x i t yo f s y s t e ma n d d i f f e r e n td e v e l o p m e n tc r i t e r i o no rt h i n k i n gs t y l ea m o n g d e v e l o p m e n tg r o u p s i nt h eb e g i n n i n gs t a g e ，w es h o u l dd e v e l o pu n d e rc e r t a i nt o o lw i t hc o r r e c t 1 e a da n da t o m i cm a i n t e n a n c ea b i l i t y ，a n ds h o u l da b i d es o m em o d e l i n gr u l e s t oa v o i di n c o n s i s t e n c ya ss o o na sp o s s i b l e ：w ec a nm a k eu s eo fr e a l t i m e e x a m i n a t i o n 、d y n a m i ce x a m i n a t i o n 、s t a t i ce x a m i n a t i o na n da s s i s t a n t t e c h n i q u et od e t e c td i a g r a m s ，a l s oc a nw eu s eam e t h o dn a m e dv i e w i n t e g r a a p p r o a c h ，t h i sm e t h o ds e p a r a t et h ei n c o n s i s t e n c yc o m p a r i s o nf r o m i n c o n s i s t e n c yd i v e r s i o n ，a n dc o m p a r i s o no c c u r r e da f t e rs w i t c h i n gt h o s e i n t ot h es a m ed i a g r a ms t y l e ，b yt h i sw a y ，w ed e c r e a s ec o m p l e x i t yf r o mo ( n 2 ) t oo ( n ) w i t ht h i si d e a ，a l ld i a g r a m sa r ed i v i d e di n t ot h r e ec a t e g o r i e s a n dt r a n s f o r m i n gb e t w e e nt h o s ec a t e g o r i e so f t e ni n v o l v e ss i m i l a r i i 山东大学硕士学伊论文 t e c h n i q u e s ，g o i n gf r o ml o w l e v e lt om g h l e v e l ，f r o mb e h a v i o rt o s t r u c t u r e ，a n df r o mg e n e r i ct os p e c i f i c a tl a s tw ev a l i d a t et h e p r a c t i c a b i l i t yo ff o r e m e n t i o n e dr u l e sv i at h ee x a m p l eo fo r d e r i n ga n dm a k e as u m m a r i z a t i o no ft h i sp a p e r a l t h o u g ht h e r ea r em a n yt o o l sa b e tu m l m o d e l i n g ，m o s to ft h e mc a nn o tc o m b i n em e c h a n i z eo fi n c o n s i s t e n c yw i t h t h e m s e l v e ss u c c e s s f u l l ya n dc o m p a t i b i l i t ya m o n gt h e ma r en o t v e r yg o o d s ow es h o u l dc h o o s ee x a c tt o o la c c o r d i n gt oa c t u a ls i t u a t i o n t h ea t t i t u d et od e a l w i t hi n c o n s i s t e n c yi sd e l e t i n gi ta ss o o na s p o s s i b l y ，m u c hm a n p o w e ra n dm a t e r i a lr e s o u r c e sw i l lb ew a s t e di f i n c o n s i s t e n c yd i s c o v e r e di nl a t e rd e v e l o ps t a g e ，a n di ta l s oc a ni n f l u e n c e t h eq u a l i t yo fs o f t w a r e s o ，d e v e l o p e ra n da n a l y z e rm u s th a v et h ea b i l i t y o fk n o w i n g 、i d e n t i f y i n g 、d e t e c t i n ga n dd e l e t i n gi n c o n s i s t e n c ya m o n g d i a g r a m si no r d e rt oe n s u r eh i g hq u a l i t yo fs o f t w a r e k e yw o r d ：u m l ，i n c o n s i s t e n c y ，m o d e l 原创性声明 本人郑重声明：所呈交的学位论文，是本人在导师的指导下，独立进 行研究所取得的成果。除文中已经注明引用的内容外，本论文不包含任何 其他个人或集体已经发表或撰写过的科研成果。对本文的研究作出重要贡 献的个人和集体，均已在文中以明确方式标明。本声明的法律责任由本人 承担。 论文作者签名：至盔邀日期：猃! ! ! ! 关于学位论文使用授权的声明 本人完全了解山东大学有关保留、使用学位论文的规定，同意学校保 留或向国家有关部门或机构送交论文的复印件和电子版，允许论文被查阅 和借阅；本人授权山东大学可以将本学位论文的全部或部分内容编入有关 数据库进行检索，可以采用影印、缩印或其他复制手段保存论文和汇编本 学位论文。 ( 保密论文在解密后应遵守此规定) 论文作者签名：至趣导师签名： 山东人学硕士学位论文 1 1 研究背景 第1 章绪论 随着面向对象技术的广泛使用，面向对象的建模语言也取得很大进展。它是指 在软件开发过程中，用来描述和刻画目标软件系统的种描述性语言。它包括建 模元素的表示法( 建模符号) 和建模元素的语义。公认的面向对象建模语言出现 于7 0 年代中期，其发展在8 0 年代末至9 0 年代中出现了一个高潮，出现了一批新 方法，其中最引人注目的是b o o c h l 9 9 3 ，o o s e 和o m t 一2 等。各种建模语言各有千 秋，但存在某些差别，极大的妨碍了用户间的交流，人们普遍认为，软件工程领 域在最近的两、三年内取得了前所未有的进展，其成果超过软件工程领域过去十 至十五年来的成就总和，其中最重要的成果之一就是标准建模语言u m l 的出现。 u m l 是由著名的面向对象技术专家g r a d yb o o c h ，i v a rj a c o b s o n 和j i m e sr u m b a u g h 发起，在b o o c h 表示法、o o s e 方法和o m t 方法的基础上，广泛征求意见，集众家 之长，反复修改而完成的在美国，嘣l 已经获得工业界、科技界和应用界的广泛 支持，已有数百家公司表示支持采用u m l 作为建模语言。1 9 9 7 年1 1 月1 7 日，u j l 被o 崛( o b j e c tm a n a g e m e n tg r o u p ) 批准为标准，这标志着面向对象技术领域中 关于建模语言的争论暂告一段落，标准建模语言u m l 为可视化建模软件的开发奠 定了坚实的基础u ， u m l 在统一b o o c h 、o m t 、o o s e 等方法的基本概念和表示符号的基础上，溶入 了软件工程领域的新思想、新方法和新技术，是一种通用、易于表达、描述能力 强大的可视化建模语言，具有很宽的应用领域，可以对任何具有静态结构和动态 行为的系统建模，如：信息系统、机械系统、企业结构等。它消除了数十种面向 对象建模语言之间的差异。对于软件开发过程中各个阶段之问的相互交互、统一 开发人员对系统的认识，具有天然的优势。它的出现是软件工程领域最重要的成 果之一，为建立统一的面向对象开发方法学走出了曝实的步伐。在世界范围内， 至少在近l o 年内，u m l 将是面向对象技术领域内占主导地位的建模语言。 山东人学硕士学位论文 u m l 为系统设计提供了各种各样的图表类型。由于一种图表不可能面面俱到地 描述整个系统所包含的所有信息，因此对系统要从它的需求、静态结构、动态行 为以及实现等不同方面来描述，这些不同的描述就构成系统的不同视图。由于不 同的视图在系统允许的行为中均加入了一些特定的限制，这些限制i 日j 存在着矛盾， 因此就导致了不同视图表达的系统内容之问的不一致性。在开发大型的模型系统 时保持一致性是比较困难的，对模型的任何改变都可能会导致不一致性的出现。 当设计模型包含了与系统相冲突的信息或违背了先前定义的限制时，就会产生不 一致性，这类限制主要包括特定的设计原则和用户对系统的特定要求。检测一致 性既可以通过手动执行，也可以由系统自动进行检测。 1 2 研究现状 当前，国内外对u m l 模型一致性关系的研究，主要有三类方法： 第一种，人工审查技术“3 ：以人工方式自项向下对模型进于亍阅读，对模型中任 何可能导致信息不一致的因素进行评审。这种方法的检查结果受人为因素影响较 大，而且审查过程比较繁琐。 第二种，形式化方法。1 ：将u m l 模型转换为某种形式化语言描述，从而对u m l 模型赋予严格的语义，然后借助第三方工具对模型进行验证。但是目前对u m l 模 型进行全部的形式化还难以实现。而且形式化方法与工具的集成性较差。 一 ， 第三种，规则法：首先定义一致性规则，然后通过硬编码方式将规则嵌入到 工具的实现中。这种方法可以在模型创建过程中，对可能导致模型不一致的行为 实时地进行检查和预防，能够大大降低出现不一致的机会，而且有利于非计算机 专业人员掌握使用。 许多研究者通过多条途径对软件设计中的不一致问题进行了深入研究。对此最 显著的贡献包括a r g o u m l 8 ”使用设计评判。1 ；x l i n k i t 。_ ”使用第一逻辑来验证用拓 展型标记语言( l ) “”来表达的u m l 设计模型；其基于一致性管理的设计指导1 遵守l i t t l e - j i t 过程语言的形式过程“。关于不一致性研究的主要贡献还包括需 求分析。虽然他们主要关注需求的定义，但是其背后的思想都是相似的并且在真 正解决问题时都是相关的。 2 山东大学硕士学位论文 a r g o u m l 提供了一种集成的u m l 建摸工具，不仪允许使片j 者创建和编辑模型， 还通过建议的方式向使用者提供模型信息反馈“1 。这些建议是关于模型的正确性、 完整性、一致性、最优性、可选择性、可进化性、表达、工具、试验性和组织性 等问题的。然而，整个建模过程只关注于提供一种智能化的用户界面，虽然范围 覆盖了设计中的十种图表，但每种图表类型中的覆盖范围都较窄。而不一致性是 被看作设计中发现矛盾冲突存在的普遍问题的。另外，a r g o u m l 现今的完善机制 也仅仅局限于建议建模行为类型和用户目标模型之间关系的松散定义，最终所有 的建议都会被循环利用，这样会引进一些额外的不必要的工作。 x l i n k i t 一致性管理提供了种基于一维逻辑的，通过用x m l 来定义一致性规 则的语言。这种规则语言使用x p a t h “”来选择某些元素作为每个规则的主体，规则 的所有条件都是适用于这些选择元素的。规则按照一致性的需求特性来定义，如 果违反了这些规则。用x m l 描述的不一致关联就被加入到关联库中，如果满足了， 一致性的关联同样也加入到关联库中，其中的所有关联都是用x l i n k “”语言来描述 的。x l i n k i tt 具要求用x m i 来表达堋l 模型“嚣，但是大部分u m l 编辑器都是最后 将模型转换为用x m l 来表达，只有很少数编辑器使用x m l 作为内部的模型表达语 言。现在，如果用户要求输出u m l 模型，只需手动的运行一致性检测工具，然后 一项项的查看关联库结果就可以了。另外，瑚l 版本的不同也会导致工具的使用失 败。因此，为了使用x l i n k i t ，用户仅仅只能使用几个特定的u m l 建模工具。 为克服人为操作的问题，m a s s a c h u s e t t s 大学的研究者提出了一种新的集成环 境，这种环境将使用x l i n k i t 的建模过程与对u m l 设计模型的一致性检测结合了 起来。建模过程是根据使用形式化过程语言l i t t l e j i t 进行建模的步骤定义的， 这些设计步骤是根据从上到下、从左到右的树的方式来组织的。例如，过程以步 骤开发开始然后按顺序分支成两步：需求和设计。从需求步骤，可以按顺序分支 成创建用例图表和创建活动图步骤，而且产生分支时都不必是二元的。 不管是x l i n k i t 还是设计指导方法都是针对设计中的不一致性问题的。然而， 他们都没有对软件设计中的不一致进行分类。 ( 2 ) 其余相关工作 在早期的研发中，一些学者提出了在系统丌发中将多样视角用观点表达的一种 框架结构“”。所谓观点就是包含着执行者或代理者对系统某些元素的观察的对象， 封装了系统的部分知识和设计过程，以特定的概念或模式表示出来。这种框架结 3 山东大学硕士学位论文 逻辑方法来管理和解决需求说明中的不一致性问题。 1 3 论文组织结构 随着开发软件规模的扩大和软件结构复杂性的提高，设计分析模型间不一致 的产生是不可避免的，如何将这种不一致性消除在初期，降低开发代价，是现今 开发中一个非常重要的问题，因此本文主要就一致性的含义、分类、如何避免不 一致性的产生以及模型间产生不一致之后可以采取的措施进行了分析。 第一部分：主要介绍了u m l 建模中不一致性课题产生的背景和近段时间国内 外对这一课题的研究现状。 第二部分：由于现今u m l 的不一致已经成为软件开发过程中非常重要的一个 问题，因此了解并解决它是开发人员的一个重要任务，在这一部分主要对不一致 性进行了综述，包括概念、分类和产生原因。 第三部分：消除不一致性要尽量在开发前期，因此这一章阐述了初期建模时我 们要遵守的保证一致性的规则及系统的保证机制。 第四部分：主要介绍建模过程中不一致性的检测机制，包括实时检查、动态检 查、静态检查和辅助技术，以及检测不一致性的方法一视图融合方法。 第五部分：通过一个实例订单管理子系统进行静态结构、动态行为和实现 三个方面的建模，同时给出了十种图表类型的实例图表。 第六部分：通过实例建模对上述列出的一致性规则进行验证。 第七部分：对u m l 的发展作了一个展望，现在已经有好多支持u m l 建模的工具， 不同工具各有优缺点，因此要根据自己从事的软件具体情况决定选用哪一类建模 工具。 最后附录部分主要介绍了u m l 的一些基础知识。 1 4 本章小结 本章主要对u m l 建模中的不一致性这一课题的产生及现今国内外对这一课题 的研究现状作了简要论述，由于不一致性的消除对于软件丌发质量的提高起着至 山东大学硕士学位论文 关重要的作用，凶此许多学者致力于寻求消除小一致性的最佳途径，并开发出多 种融合了检测不一致性机制的建模工具，为此领域做出了突出贡献。 山东大学硕士学位论文 第2 章u m l 建模中不一致性概述 由于消除建模中的不一致性对于提高软件开发质量起着至关重要的作用，因此 研究u m l 一致性具有十分重要的意义。首先，保证建模的正确性，一致性问题通 常反映了建模中的设计问题或对u m l 的误用，及时识别模型中存在的不一致性问 题并加以解决可以大大提高工作效率，减少开发费用。其次，保证u m l 的实现能 力，这包括将u m l 模型转换成程序语言及精确的符号的过程，能否很好她将软件 用u m l 模型表达出来是软件开发成功的重要因素。软件开发是个迭代的过程，不 断的经历着从需求到代码的子过程，每一个子过程中都包含着用不同技术表达的 多种视角和说明文档，如果没有致性分析，将很难确保建模实现和多种技术的 结合。因此。现今u m l 的一致性问题已成为软件开发中的首要问题，必须予以充 分重视。 2 1 不一致性概念 u m l 的不致性存在于不同视图和设计图表之间，其含义是指在面向对象模型 的不同视图和范图之间出现的对同一事物描述的相互冲突的现象“1 。例如类图中 定义了某个类的所有方法，但在顺序图中却没有完全表达出来，这就产生了不一 致性。由于视图是从不同的角度来描述系统模型，他们侧重点和出发点不相同， 这样视图之间必然存在一定的重叠，出现不同视图和范图对同一事物重复描述的 现象。面檑互冲突则可以认为是对同一事物的描述有遗漏、冗余、逻辑错误等现 象。 模型的一致性问题可以说自从人们试图采用多视图的方法来描述复杂模型时 就已经存在了，所以，这一问题的研究始终得到人们的关注“”1 。从软件开发的整 个过程来说，模型一致性问题对软件体系结构模型来说意义更是重大哪捧1 ，因为软 件体系结构模型作为系统开发前期的重要工作，其中的任何微小的错误或不一致 的地方都有可能给其后续工作带来灾难的影响，正所谓“失之毫厘，谬以千里”， 消除不一致性意义非凡。 6 山东大学硕士学位论文 2 2 不一致性分类 我们这里主要分两个层次来讨论软件设计中的不致性。第一层指设计表达 中的不一致性，由于u m l 的图表化、半正式化及易学习的特点，现正广泛应用于 表达设计描述中，它的设计多视角表达是信息完整的充分条件，同时也是不一致 性产生的必要条件。第二层是指真正系统设计中的不一致性，它圭要源于设计概 念的完成阶段，例如隐藏一致性。”和数据恢复恤1 。为便于讨论，我们将这两个层 次的不一致性分为三个类：冗余、符合和变化。他们之间的不一致性大部分是指 水平不一致性，但也不乏垂直不一致性的实例。 ( 1 ) 冗余 。 经常导致不一致性的原因是信息的冗余。特别的，当从不同的视角对设计制 品进行表达时，特别容易产生冗余，它不但出现在设计表达中，也出现在数据表 达中。 a 设计表达中的冗余： 当两个设计单元在表达中具有相同元素或信息重叠时就会产生设计相关冗 余。但是，这样的冗余并不一定会产生表达的不一致。因为冗余是从多个侧面提 供关于需求定义的信息或在多种情景下描述设计单元的行为。从此种意义上说， 信息是通过多视角的集成来表现的，这种冗余不会产生不一致性因此，设计单 元的重叠是冗余不一致性产生的必要条件，而不是充分条件，这对数据表达中的 冗余也同样适用，我们从结构和行为两方面进行分析1 。 a 结构冗余 结构冗余是指在建模中用各种结构图表和行为图表进行表达的设计元素问的 冗余。它主要发生在两个结构图表中或结构图表和行为图表中。第一种情况主要 表现在结构元素如包、类、对象、关联、实例，方法和属性名称的重复，这种类 型的冗余很容易识别且可被大多数u 札建模工具所阻止第二种情况用订货实例 进行说明，订货这个类要求具有能创建新的订货的特性，还可延伸为能够创建具 有特定货物和数量的新订货。创建一个新订货的用例用图2 1 的顺序图表述，创 建一个特殊订货的特殊用例用顺序图图2 2 来表述。图2 - 2 是图2 - 1 的子图，当 子图特性改变时，两个图中特性化关联的特性脚就会产生不一致性。例如，创建 山东大学硕士学位论文 二次新订货继承了创建一个订货，因此后者必须具有前者所有的方法，若图2 2 在生成新的订货后没有返回值，就违背了前面的思想，产生了不一致性。 固国匡雪国 ； ； i 皿q 皿u 口m 缸q i；! ； ；竺! 竺：2 1 竺竖 ； ； ； ； 型竺! ! ； ； ir e t u m o 竺堂l f 一 图2 - 1 ：创建订货用例顺序图 国国 ；。硼。 匡雪囤 ；垫! 竺! 旦唑竺! 一 ! i 卜坐盟一 b 特性冲突 当两个特性具有相重叠的说明时，若平行共同使用他们就会产生状态冲突。 例如，在状态图中，当从原状态引发的两个状态转变的触发条件同时满足时，特 性冲突的不一致性就会发生，并且最终状态也是相互矛盾的。 b 数据表达中的冗余 数据表达的一个特点就是数据对象间的关联是双向的，当关系r 被看作对象间 的关系时，其反向关系r 1 可被看作r 关联的2 个对象位置颠倒后所具有的关联 如果反相关联定义得非常复杂，我们就称这里存在表达冗余。 ( 2 ) 符合： 一一一 一；| | | | | 山东大学硕士学位论文 这里的符合是指对限制和标准的符合，在软件设计中，会有很多超出系统高求 范围的需求，这些额外的需求必须保证对限制、标准和行为的符合。所建模型与 文档不符合的类型主要有下面几种。 a 系统内的冲突 系统内的冲突可以导致系统的某些需求特性不能被同时满足，这种冲突不仅存 在于局部条件和全局条件中，也可能存在于局部条件或全局条件间。例如，在工 厂库存设计中有一个安全条件：当库存量低于某个值时，就应该立即订货增加库 存，但由于当时整个工厂库存系统资金问题不能立即进货，这样先前定义的进货 的前提条件就与全局限制不能相符，局部条件和全局限制就发生了冲突。 b 系统内的不匹配： 对现存系统或元素的重用是软件工程设计的一个重要方面，但系统是由不同 的团队经过不同的设计过程协作完成的。因此，两个系统经常在操作界面、对环 境的假设、每个设计单元的前提、后置条件等方面存在不匹配。但这些问题比较 好识另i j ，在设计层就可以予以解决。 c 建模语言的限制： 在u m l 中，限制是用o c l 语言定义的比如：关联两端的实体必须具有不 同的名字；任意属性都不能与类具有相同的名称。 d 设计标准： 在许多不同的软件开发发展文化中，都有一个共同的需求，就是最大程度上符 合相应的工业标准、团体标准。虽然团队问，企业问的标准存在差别，但都要确 保在设计实践中遵守标准。 e 设计模式： 婶 图2 3 ：模式比较 9 山东大学硕士学位论文 软件设计模式在文档和实践中都有所体现，为了能更好的应用他们，设计者 必须深入地进行学习以确定哪种模式适合于当前问题。因此，我们要提供给设计 者在设计中识别模式的自动帮助，并能指出设计者对模式的错误使用。例如；会 话设计模式是一个对象结构模式，用来为子系统提供访问界面以方便对子系统的 访问。使用这种模式可减少子系统之间的关联和依赖性，缩减整个系统的复杂性。 图2 - 3 描述了在子系统访问模型中会话模式的应用。图2 3 中左图表示一类图， 类间的交互错综复杂，适合于用右边的会话模式进行改进。但如果你没有应用的 话，就会很容易产生不一致性。 ( 3 ) 变化： 软件设计在完成之前会根据需求变化、行为调整和环境假定的完善而进行诸 多修改。在进行设计修改过程中，非常容易引发不致性。 a 编辑块： 产生不一致性的一个源泉是做改变时编辑块的使用。编辑块是完成对整个模 型的需求改变的编辑步骤的集合。如果步骤不能作为一个整体进行操作，说明遗 失了一些步骤，就会使整个设计模型处于不一致性状态。 b 设计模式转换： 变化中产生不一致性的另一个源泉是将设计模型从一种表达转换成另一种表 达。转换进行的整个期间系统都会处于一种不一致性状态。如果在改变过程中接 收到不相关联的新变化需求时，新变化会被置起直至整个改变完成以后再进行处 理，否则会引入新的不一致。 2 3 不一致性产生原因 探究不一致性问题出现的根本原因，主要有两点：第一，系统本身的复杂性# 第二，不同视图代表不同开发者的观点。 2 3 1 系统的复杂性 软件系统复杂程度的同益增加使人们意识到系统模型在软件丌发中的重要 性，但是，即使是系统模型在大多数情况下也是非常的复杂。于是，人们采用多 视图建模方法来简化模型的表达、理解和应用。于是，一个完整的模型被分割成 1 0 山东人学硕士学位论文 为一个个切片( 视图) ，由于切片是对同一模型的不同角度、卜同方向的认识， 因此视图之间必然存在内容相互关联与重叠、关系相互约束与协作，因此难免出 现模型不一致性问题。 为了避免出现模型不一致性问题，在为复杂系统建模( 尤其是软件体系结构 建模) 时，需要一种既足够精确，同时又足够简单，而且还可以代表所有相关开 发人员的观点的模型。所谓足够精确是指模型本身简单易懂以及对它的理解和应 用都不存在什么障碍。所谓还可以代表所有相关开发人员的观点是指所有与系统 相关的开发人员对模型都比较满意。但是不幸的是，这种理想状态的模型现阶段 是不存在的：因此，系统模型的复杂性正是导致产生模型不一致性现象的根本原 因之一 2 3 2 不同视图代表不同开发人员的观点 多视图模型中每一个视图代表了一个开发人员从一个特殊的视角所观察多j 或 认识到的模型内容。这样每一个视图处理的都是模型的一个子集，从而有效地简 化了模型的复杂性。 但是，多视图建模的结果常常是建立起一些具有松散耦合甚至是相互独立的 视图，视图之间的相互关系不明显。视图之间的这种缺乏关联的状态严重割裂了 模型原有的整体性和一致性。 处理模型的不一致性问题，保持模型的整体性与一致性。需要建立相互之间 具有紧密耦合关系的视图，因为毕竟视图只表现模型的一个方面。将这些视图“集 成”起来才可以全面而完整的反映系统模型的全部信息。但是由于视图代表不同 开发者的不同观点，我们一方面希望视图之间紧密关联，另一方面又希望视图保 持各自的足够的独立性以期可以清晰地表达不同开发人员的观点。因此，在多视 图模型中，各视图之间不仅需要保持相互之间紧密地约束与协作，同时也需要保 持一定的独立性，并可以自成体系以便于应用。这似乎相当的矛盾并难以调和处 理，正是这种矛盾产生了模型的一致性问题。但是如果着眼于视图所表达的内容 之问的紧密耦合和独立的要求，保证模型在概念上的完整性，一致性问题还是依 然存在。 山东大学硕士学位论文 因此，可以说，正是因为视图反映了不同开发者对模型的不同观点，即使视 图之间存在某种程度的重叠，也因表达方式以及关心的侧重点不同而产生表达结 果上的差异，对同一事物的这种不同表达正是另一个产生模型不一致性现象的根 本原因。 2 4 本章小结 本章对不一致性的概念、分类和产生原因进行了深入探讨，只有充分了解不 一致性的各方面，才能针对其特点找到解决的方法。不一致性主要指不同设计模 型中信息表达发生了冲突，它存在于设计中的不同层次和不同视图中，其产生既 具有客观原因又有主观原因。，对不一致性的分类不同阶段不同学者给出了不同的 分类方式，但通常我们可将其分为冗余、符合和变化三大类，不一致性的产生与 系统的复杂性和参与的开发团体个数有很大关系，随着复杂性提高和团体个数增 大不一致性产生机率随之增大。 山东大学硕士学位论文 第3 章u m l 建模中不一致性保证机制 3 1 保证一致性的规则 我们主要从分析模型间信息冗余和交织方式入手，识别出模型间基本的一致 性原则l r m l 共有l o 种图表类型：用例图、类图、对象图、包图、顺序图、协 作图、状态图、活动图、构件图、配置图，它们共同描述了系统静态结构、动态 行为和最终实现，由于一致性问题主要存在于前8 类图表之间，因此这里主要说 明这8 类图之间的一致性关系问题。 3 1 1 用例图与其余图表之间的一致性 用例图被用来描绘一个系统外在可见的需求情况，常用在项目的需求分析阶 段，主要确定系统边界、系统范围、系统内活动和整个系统的参与者。因此它的 确定对后面的各类图表的建立起着至关重要的指导作用，它与后续图表在建立时 需要遵守的一致性规则如下： 规则l ：类图中的类须从用例图中的参与者进行抽取，参与者的活动与系统内 部的关联要么表现为类图中类的方法，要么表现为活动图中的活动。 规则2 ：包图中包的分类取决于用例图中描述的系统范围和边界。 3 1 2 类图和对象图之间的一致性 对象图是对类图的一种实例化：对象图中的对象是类图中类的实例，对象问 的链接是类问关系的实例，如图3 1 所示。可以用追踪关系m 1 来描述对象对类、 链接对类间关系的这种实例化，这种追踪关系构成了对象图与类图的联系链路。 通过这条链路对象可以获得相关类的所有信息，类图对对象图的制约作用是通过 这条链路施加的，因此对象图和类图之间一致性关系的保持也必定要借助这条链 路来实现。 山东大学硕士学位论文 系。 冒3 - 1 ：类图和对象图的关系 通过分析，得到类图和对象图之间如下的一致性规则： 规则1 对象的类型属性如果被指定，则所指定的类型必须在类图中已经定义。 规则2 抽象类不能被实例化，即对象所属的类不能是抽象类。 规则3 如果两个对象之间存在链接，则这两个对象所属的类之闽存在关联关 规则4 链接端点处的角色必须与对应的关联端点处的角色名相匹配。 规则5 对象的属性值必须符合类图中相应类的属性的定义。 规则6 链接一端的实例数目应与类图中相应关联一端的多重性定义相符。 3 1 3 类图和交互图之间的一致性 交互图包括顺序图和合作图，这两种图本质上是等价的。交互图中的基本模型 元素由对象和对象间的消息组成，主要描述了对象之间通过互相发送消息而进行 交互的场景。对象图可以看作交互图，尤其是合作图的简化版本。对象图中的一 致性规则对交互图同样适用。此外，交互图还展示了比对象图更为丰富的动态特 性。交互图与类图的关系不仅包括对象到类、链接到类之间关系的追踪，还包括 消息到类的操作的追踪。交互图中对象间传递的消息必须与类图中的定义相一致。 如图3 - 2 ，类t i t l e 没有对类m o d i f y 进行定义，交互图中a b o o k 却向c u r t i t l e 发送了这样的消息，造成信息不致。 1 6 山东大学硕士学位论文 图3 - 2 ：类图和交互图的关系 类图和交互图( 顺序图、合作图) 之间存在如下一致性规则： 规则1 如果两个对象之间有消息传递，则这两个对象所属的类之间应有关联。 规则2 接收消息的对象所属的类中应有与该消息相应的操作，并且该操作对 调用对象应该是可见的。 规则3 交互图中消息的参数类型和次序，应与类图中定义的参数类型和次序 一致。 3 1 4 类图和状态图之间的一致性 状态图是对类的一种补充描述，展示某类对象所具有的所有可能的状态以及某 些事件发生时其状态的转移情况状态图中的基本元素由各种状态以及状态问的 转移组成，其中转移又可以拥有转移条件( g u a r d ) 、触发事件( e v e n t ) 和一系 列转换动作( a c t i o n ) ；状态可以具有若干内部转移。在状态图中，状态转移上 动作表达式依据类的操作和属性来编写状态图中有相应的操作和事件定义与之 对应。状态图到类图的联系链路包括状态图到其类的追踪关系以及状态图中触发 事件或转移动作到类的操作的追踪关系。 类图与其状态图之日j 的一致性规则如下： 规则1 类被删除时，其状态图要一同被删除 规则2 状态图中的每一个触发事件，在类中必须有相应的操作与之对应。 山东大学硕士学位论文 进行定义，动作的参数类型和次序必须与定义时的参数类型和次序一致。 状态图中，如果某个转移动作是向其他类的对象发送消息，还必须遵守如下规 则： 规则4 目标对象所属的类与该状态图所属的类之间必须存在关联关系。 规则5 目标对象所属的类中必须有与该消息相应的操作，且该操作对该状态 所属的类来说必须是可见的。 3 1 5 对象图与其余图表之间的一致性 似。 由于对象图是类图的实例化，因此对象图与其余图表的一致性关系与类图相 3 1 6 顺序图和合作图之间的一致性 顺序图与合作图本质上是等价的，只是侧重点略有点差别：顺序图侧重于消息 交互的时间顺序；合作图则侧重于对象的联系，即哪个对象与哪个对象发生交互。 这两种图是可以相互转换的，他们之间基本上有着实体的一一对应关系。 顺序图和合作图之间的一致性规则如下： 规则1 在一个图中创建或删除对象时，另一个图中也应相应的创建或删除该对 象。 规则2 在一个图中创建或删除消息时，另一个图中也应相应的创建或删除该消 息。 规则3 在一个图中对某个对象作了修改后，另一个图也应相应的修改该对象。 规则4 在一个图中对某个消息作了修改后，另一个图也应相应的修改该消息。 3 1 7 状态图和状态图之间的一致性 在一个类的状态图中，如果某个转移动作是向其他类的对象发送消息，则该 类的状态图与其他类的状态图将存在一致性约束，即它们必须遵守如下规则： 1 8 山东大学硕士学位论文 规则：如果一个类的状念图中的某个转移动作是向另一个类的实例发送消息， 则在另一个类的状态图中应存在用该消息触发的转移。 3 1 ，8 交互图和状态图之间的一致性 交互图和状态图分别展示对象的外部动态特性和内部动态特性。交互图中描述 了一个对象同其他对象之间接收和发送消息的情况；状态图则描述该对象接收和 发送这些消息时自身内部状态如何变化。因此，交互图中的消息与状态图中的触 发事件、转移动作密切相关，在交互图和状态图之间应存在如下一致性规则： 规则：某个类的状态图中每一个状态转移，都应能有交互图中该类的实例所接 受或发送的消息完成。 3 1 9 活动图和其余图表之间的一致性 在u m l 的当前版本中，活动图被作为状态图的一种特殊形式来对待，它与其 他图的一致性关系与状态图相似。 3 2 保证一致性的机制 保证一致性机制的关键在于：如何将保证一致性的工作有机的加入到u m l 建 模系统中，所以首先要分析：( 1 ) 建模者在建立系统模型的过程中，实施何种编 辑操作可能产生模型的哪些不一致；( 2 ) 建模系统如何避免不一致的出现； ( 3 ) 建模系统采取什么措施可以有助于消除已出现的不一致，最后根据分析结果相应 的制定一致性检查的实现策略，给出实现方案并对每一条检查规则进行具体实现。 在建立模型的过程中，如果未遵守文本制定的致性规则而进行违背规则的 操作时就会出现不一致，具体表现为：( 1 ) 未遵守规则实施图形元素的创建操作， 包括创建图元以及创建图元日j 的连接，例如，在对象之间创建了链接，但在对象 所属的类之间根本不存在任何关联，这一操作违反了结构一致性的规则；( 2 ) 删 除图形元素以及图形元素间的连结，例如，删除一个类后，该类的状态图未做相 应的删除，将该类的操作作为事件、消息、动作的地方未做相应的删除，这违反 了行为一致性的规则；( 3 ) 编辑图形元素的规格说明，例如，用例图中的动作未 山东大学硕士学位论文 分配给某个类的操作，从而违反了功能一致性的规则，再如，修改了某个类的名 称后，在属于该类的对象的规格说明中未相应的修改对象所属类的名称，这违反 了标识一致性的规则。 由于在建模过程中随时都有可能出现不一致，无法完全由建模者自己去维护 模型的一致性，建模系统应该对模型具备以下能力： ( 1 ) 检测能力：检测可能导致模型不一致的编辑操作和当前已经存在的模型 间的不一致； ( 2 ) 一定程度的自动修正能力：当检测到导致模型不一致的编辑操作后，搜 索它所涉及到的所有地方，依据编辑结果相应的进行一致性修正，例如，当检测 到类中的操作被修改时，开始搜索所有引用该操作的地方，一旦找到立即修改对