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

1,管理信息系统分析与设计复习与总结,一、信息系统的开发过程,程序设计,信息系统开发,=,高质量的软件是设计出来的,?,二、信息系统的开发方法,信息系统的开发方法,结构化方法,原型法,面向对象的方法,Booch方法OMT方法OOSE方法RDD方法OBA方法,UML,统一,三、UML的概念与发展,UnifiedModelingLanguageUML是软件和系统开发的标准建模语言,“如果你有一只猫，你想把它卖给一个编程者，那么，与其强调其可爱与温顺，或如何能捉老鼠，不如直接告诉买家，这只猫是面向对象的。”关于猫与面向对象的经典名言非常形象的揭示了面向对象在IT界乃至整个学术界的地位。,JimRumbaugh,GradyBooch,IvarJacobson,1986年：GradyBooch（IBM）提出Booch方法1995年：JamesRumbaugh（IBM）提出OMT方法1996年：IvarJacobson（独立咨询师）提出OOSE方法1997年：UML1.1，成为业界标准1998年：UML1.2版1999年：UML1.3版2001年：UML1.4版2003年：UML2.0版,用例图,类图2,状态机图,时序图协信图,类图1,活动图,四、UML中几个图的关系,提示：用例图是起点，类图是中心,五、UML的建模工具,RationalRose2003MicrosoftVisio2003,六、UML的应用现状,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规范本身的不确定性而产生理解上的偏差，它们对UML的自行诠释误导了用户。第四、双向工程支持的语言有限，如Rose不支持C#、Delphi等语言的双向工程，从而影响了学习这些语言的程序员使用UML建模的热情。,2、用户对建模的重要性认识不足UML是用于软件建模的，但是很多人认为UML建模是在浪费时间。这种想法在初级程序员中尤其明显，主要是因为他们所接受的教育仅仅局限于如何编写代码，对于完整的开发流程鲜有接触，而且他们的经验也仅限于如何实现代码。一些高级程序员不愿意使用UML进行建模的原因则是他们过分自信，相信不经过建模也能写出很好的软件。这些对UML建模的错误认识，阻碍了UML的应用。,3、用户对UML的理解不全面一些用户欣赏UML的原因之一就是通过建模软件可以生成代码，对他们来说UML只是一个代码生成工具而已。他们使用UML，只是为了获得UML生成的代码，所以他们完成的UML模型大都没有实际价值，比较形式化。这是对UML的误解，UML的关键在于系统分析和系统设计环节的建模，双向工程不是UML的重点。,4、用户缺乏面向对象的理论基础UML本质上是面向对象的，只有充分理解了面向对象的思想，具备了较强的面向对象分析与设计的能力，才能成功驾驭UML。然而，部分用户由于没有系统地掌握面向对象的基本理论，不会运用UML进行思考，就不可能产生使用UML去表达软件架构和设计方案的需要，因而在项目开发中就很少或根本不使用UML。从这个角度来说，用户的素质不高成了应用UML的障碍之一。,5、项目投入的资源不充分在项目实践中常常面临这样一个严重的问题：许多不是从事系统开发的人员（包括高级经理和用户）不知道软件是如何建成的。其结果是他们给予项目的实际可支配的资源非常有限，无论是开发周期还是资金和人力都只考虑了实施阶段的需要，难以支持项目的开发，造成了项目仓促开始，项目开发人员被迫匆匆完成形式主义的UML建模，然后把模型