UML讲义14-第14章复习与总结.ppt

一、信息系统的开发过程 二、信息系统的开发方法 三、 UML的概念与发展 Unified Modeling Language UML是软件和系统开发的标准建模语言 1986年：Grady Booch（IBM）提出Booch方法 1995年：James Rumbaugh（IBM）提出OMT方法 1996年：Ivar Jacobson（独立咨询师）提出OOSE方法 1997年：UML1.1，成为业界标准 1998年：UML1.2版 1999年：UML1.3版 2001年：UML1.4版 2003年：UML2.0版 四、UML中几个图的关系 五、UML的建模工具 Rational Rose 2003 Microsoft Visio 2003 六、UML的应用现状 课 程 结 束 ! 管理信息系统分析与设计复习与总结 程序设计 信息系统开发 高质量的软件是设计出来的…… ? 信 息 系 统 的 开 发 方 法 结构化方法 原型法 面向对象的方法 Booch方法 OMT方法 OOSE方法 RDD方法 OBA方法 UML 统一 “如果你有一只猫，你想把它卖给一个编程者，那么，与其强调其可爱与温顺，或如何能捉老鼠，不如直接告诉买家，这只猫是面向对象的。” 关于猫与面向对象的经典名言非常形象的揭示了面向对象在IT界乃至整个学术界的地位。 Jim Rumbaugh Grady Booch Ivar Jacobson 用例图 类图2 状态机图 时序图 协信图 类图1 活动图 提示：用例图是起点，类图是中心 ——《UML在实践中的现状和一些建议》 UML在国内不少地方获得了应用。这应该说是个好事，然而背后我们也看到，这种应用大多属于不够冷静的炒作和跟风，UML在很多时候已经变成了一种形式主义的东西。实际上，UML本身所倡导的主旨是很好的，它保证了程序员之间的交流语言，RUP之类的工具也保证了软件开发过程的规范性，严格保证了先设计后开发，设计阶段有翔实的规范化的文档等。 中国期刊全文数据库 一、UML的理论缺陷 1、UML的概念存在不精确性和二义性 UML中的一些概念不够精确，甚至存在二义性，使用户感到困惑。例如，状态机图中的事件和动作这两个概念都表示了一个与转移有关的行为，二者有什么区别？ UML只是在字面上解释它们之间的不同——事件是引起状态转移的原因或条件，后者是在状态转移时对象要做的事情。状态的变化从根本上讲表现为对象属性值的变化，而封装的原则决定了对象外部的任何事件都必须通过对象的操作才能修改对象的属性值。从这个角度来讲，事件和动作就没有什么区别。那么，二者到底是不是一个概念呢？类似的这种概念上的模糊性和二义性，给UML的学习和应用造成了很大的困难。 2、UML存在重复和无用的模型元素 UML的部分模型元素没有实际的用途，或者与其他元素是重复的。例如，UML中既有类图又有对象图，而后者在是多余的，没有什么实际的作用。类是对象的抽象，一个类可以描述属于该类的全部对象的共同特征，对象的差别体现在属性值的不同。当一个类的对象很多时，我们不可能逐个地描述每个对象的值，也就没有必要建立对象图。再如，UML中定义了4种依赖的类型，分别是使用依赖、抽象依赖、绑定依赖、授权依赖，每一种依赖又可以进一步细分，这些依赖看上去似乎作了更全面、更详细的考虑，但是在建模中根本用不上这些模型元素。像这样一些模型元素的引入，不但没有增加UML的表达能力，反而增加了它的臃肿和复杂。 3、UML缺少一个精练的核心 由于UML在形成规范的过程中，不得不照顾多种方法流派的观点和多家公司的利益，再加上UML被用于多个领域和多种类型的系统建模，使得UML过于庞大和复杂，用户常抱怨很难全面地、熟练地理解和运用它。对此，我们认为应该提供一个精练的核心，将核心与外围分开，?这样UML的用户就只需要学会UML的核心和与自己相关的外围部分。那么，UML的核心是什么？关于这个问题，我们可以用“80-20-80”法则来进行判定，即80%的人用UML20%的内容可以完成80%的问题建模，也就是说大部分人只用UML最核心的部分就可以完成大部分的建模工作。我们在实践中发现，用例图、类图、时序图这三种图应该包含在UML的核心之内，其他图可以进入某种扩展机制。 二、UML在应用中存在的问题 1、UML建模软件不完善 这些问题大致可分为以下几个方面： 第一、对UML实现的不完备性，一些工具只提供了对UML的部分支持，如在顺序图建模时，Rose就没有提供分支、从属流、循环、引用等建模元素； 第二、一致性检测功能不完善，目前UML建模工具所提供的模型一致性检查功能比较有限，不能满足用户的需求。 第三、工具开发商因为UML规范本身的不确定性而产生理解上的偏