UML系统分析与设计绪论课件.ppt

上传人:rrsccc 文档编号:9808965 上传时间:2021-03-27 格式:PPT 页数:54 大小:202.50KB
返回 下载 相关 举报
UML系统分析与设计绪论课件.ppt_第1页
第1页 / 共54页
UML系统分析与设计绪论课件.ppt_第2页
第2页 / 共54页
UML系统分析与设计绪论课件.ppt_第3页
第3页 / 共54页
UML系统分析与设计绪论课件.ppt_第4页
第4页 / 共54页
UML系统分析与设计绪论课件.ppt_第5页
第5页 / 共54页
点击查看更多>>
资源描述

《UML系统分析与设计绪论课件.ppt》由会员分享,可在线阅读,更多相关《UML系统分析与设计绪论课件.ppt(54页珍藏版)》请在三一文库上搜索。

1、第一章 绪 论,UML系统分析与设计,1,UML系统分析与设计绪论,1. 面向对象2. UML简介3. UML发展史,2,UML系统分析与设计绪论,1.1 面向对象,20 世纪 60 年代提出概念到现在,逐步发展成为开发领域的主流技术。,3,UML系统分析与设计绪论,面向对象是UML的基础,UML建模语言的出现正是由于面向对象建模思想发展的产物,它是软件工程领域公认的面向对象的建模语言。 可以毫不夸张的说,没有面向对象,就没有 UML,它们的关系密不可分。,4,UML系统分析与设计绪论,面向对象方法经历了这样的发展过程,它首先在编程领域兴起,作为一种崭新的程序设计范型引起世人瞩目。 20世纪8

2、0年代一大批面向对象编程语言问世,标志着面向对象方法走向成熟和实用。此时面向对象方法开始向系统分析与设计阶段延伸,出现了一批早期的面向对象设计方法。 至1994年,公开发表并具有一定影响力的面向对象分析与设计方法达到 50 余种。这些方法的主导思想及原则大体上是一致的,但也存在不同差异,这阻碍了面向对象方法一致的方向发展,给用户选择带来困惑。则这种形势下,统一建模语言应运而生。,面向对象是UML的基础,5,UML系统分析与设计绪论,面向对象基本概念,什么叫面向对象? 面向对象技术是一种以对象为基础,以事件或消息来驱动对象执行处理的程序设计技术。 从程序设计方法上来讲,它是一种自下而上的程序设计

3、方法,它不像面向过程程序设计那样一开始就需要使用一个主函数来概括出整个程序,面向对象程序设计往往从问题的一部分着手,一点一点地构建出整个程序。,6,UML系统分析与设计绪论,软件,计算机软件是计算机系统中的程序以及有关的文档。 程序是计算任务的处理对象(数据)与处理规则(算法)的描述。 文档是为了便于人们理解程序所需的资料说明,供程序开发与维护使用。,7,UML系统分析与设计绪论,软件的生命周期,软件需求分析 软件设计 编程实现 测试 运行 维护,8,UML系统分析与设计绪论,程序设计,程序设计就是为计算机编制程序的过程。 程序设计的本质是对计算进行描述,这里的计算是指广义上的计算,而不是简单

4、的加、减、乘、除等算术运算。以不同的方式来给出计算的描述就形成了程序设计的范型。程序包括数据以及对数据的加工两部分,程序设计范型就是指以何种观点来看待、组织和描述他们。 目前典型的程序设计范型:过程式和对象式。,9,UML系统分析与设计绪论,过程式程序设计,过程式程序设计以功能为中心,基于功能进行分解。过程式程序由一些子程序(功能单位)构成。子程序是操作的封装体,每个子程序对应一个功能,实现了功能的抽象。过程式程序的执行过程体现为一系列的子程序调用。 在过程式程序中,数据处于附属地位,它独立于子程序,在子程序调用时作为参数传给子程序使用, 下面公式刻画了过程式程序设计的本质特征 程序 = 算法

5、 + 数据结构 早期的程序大多采用过程式设计。,10,UML系统分析与设计绪论,对象式程序设计,对象式程序设计是一种以数据为中心、基于数据抽象的程序设计范型。一个对象式程序有一些对象构成,对象是由一些数据及可施于这些数据上的操作所构成的封装体,对象的特征有相应的类来描述。面向对象程序的执行过程体现各个对象之间相互发送和处理消息。 面向对象程序可简单地表示成下面的公式: 程序 = 对象/类 + 对象/类 + 对象/类 = 数据 + 操作,11,UML系统分析与设计绪论,面向对象程序设计,面向对象程序设计就是把程序构造成若干对象组成,每个对象由一些数据和对这些数据所实施的操作构成; 对数据的操作通

6、过向包含数据的对象发送消息来实现(调用对象的操作); 对象的特性(数据与操作)由(对象)类来描述,一个类的特性可以从其它的类继承。,12,UML系统分析与设计绪论,面向对象程序设计,包含以下基本概念: 对象:对象式计算的基本单位,由:接口,数据,操作构成。 通信:引起对象式计算的唯一方式 类 :对象特性的描述 继承:复用机制。,13,UML系统分析与设计绪论,为什么要面向对象,一个好的软件开发方法或技术的评价标准:开发效率和软件质量保证。 开发效率指方法使用的难易程度和方法缩短开发周期的程度; 软件质量包括:外部质量和内部质量; 外部质量:与用户有关的质量因素,包括正确性、效率、可靠性、可用性

7、和可扩展性等方面 内部质量:与软件开发人员有关的质量因素,包括可读性和可维护性等。,14,UML系统分析与设计绪论,为什么要面向对象,在面向对象程序设计之前,面向过程结构化程序设计占据主要的地位,结构化程序设计是一种自上而下的设计方法,以函数为中心,用一个主程序来概括出整个程序需要做的事,主函数是由一系列子函数组成。 对于比较复杂的问题或在开发中需求变化比较多的时候,结构化程序设计往往显得力不从心。事实上,在问题比较复杂的时候,要求设计者自上而下一开始就对需要解决的问题有全面的理解会比较困难。当需求发生变化时,以前的问题理解也许会变得不在适用。,15,UML系统分析与设计绪论,为什么要面向对象

8、,面向过程程序设计把数据和对数据的操作分离,使得大型程序的编写比较困难,难于调试和修改。在很多人进行协同开发的项目组中,程序员之间很难读懂对方的代码,代码的重用变得十分困难。 面向对象以对象为基础,以事件和消息来驱动对象执行处理的程序设计。是一种自下而上的程序设计方法,往往从问题的一部分着手,一点点地构建整个程序。,16,UML系统分析与设计绪论,(1)抽 象,过程抽象来源于子程序的概念。 子程序的作用有两个:节省劳动力和过程抽象。过程抽象把子程序的接口和实现分开,使用者只需要知道知道子程序的接口(功能和参数)而不需要关心其内部实现,适合于基于功能分解、逐步精化的过程式程序设计。 缺点与不足:

9、数据与操作的描述分离,不能适应需求的改变。,17,UML系统分析与设计绪论,数据抽象以数据为中心,把数据及其操作作为一个整体(对象)来进行描述,对数据的操作由包含数据的对象来提供。 面向对象程序设计强调的是数据抽象,一方面加强了数据保护,另一方面实现了对世界活动的直接模拟,能较好的适应需求的变化。 不足之处:对系统的整体功能缺乏清楚的描述。,(1)抽 象,18,UML系统分析与设计绪论,把具体实现细节作为一个黑匣子,对使用者隐藏的一种机制。过多的暴露实现细节,无论对使用者还是对实现者都是不利的。 对于使用者而言,如果其功能的执行要依赖所使用的语言结构的内部实现,那么,当使用的语言结构的内部实现

10、变化时,其必须也要做相应的改变; 对于实现者而言,如果过多地暴露实现细节,则不得不谨慎的处理任何实现上的改变,从而不至于影响太多的使用者。封装考虑的是内部实现,抽象考虑的是外部行为。,(2)封 装,19,UML系统分析与设计绪论,过程封装实现了操作的封装,而数据是公开的,缺乏数据的保护。 数据封装实现了数据及其操作的封装,加强了数据的保护。 面向对象程序设计实现了数据封装。,(2)封 装,20,UML系统分析与设计绪论,(3)模块化,模块化是处理大而复杂问题的重要手段,同时也是保证软件质量的有力措施,一个好的软件开发方法应能支持模块化。 程序设计中的模块是指可以分别编译的程序单位或程序在物理上

11、的划分。 模块包含接口和实现两部分。 模块化的目标:可分解、可结合、可理解、连续性和保护性。 面向对象对模块有更好的支持:对象/类,21,UML系统分析与设计绪论,软件复用的层次:代码复用、设计过程复用和分析方案复用,代码复用最直接、最广泛。 传统的复用机制:源代码的剪裁和子程序库 面向对象的复用机制:继承和类库,(4)软件复用,22,UML系统分析与设计绪论,传统的软件开发方法通常是基于自顶向下、功能分解的方法,面临的问题是:由于功能分解模型较难与现实世界的实际系统相吻合,开发的软件系统难以适应需求的变化。 面向对象方法开发软件能够减小个阶段之间的语义间隙,使得开发过程平稳过渡,提高软件的可

12、维护性,特别是对需求变化的适应性。,(5)软件开发过程,23,UML系统分析与设计绪论,面向对象程序设计的基本内容,1. 对象与类 对象由数据变量及其操作方法所构成的封装体。 类是对象特性的描述,一个类刻画了具有相同特性的对象,是创建对象的模板。对象是类的实例。 对象属于值的范畴,而类属于类型的范畴。 对象与类实现数据抽象、封装、模块。,24,UML系统分析与设计绪论,面向对象基本概念,2. 消息与事件 消息是指描述事件发生的信息,是对象间相互联系和相互作用的方式。一个消息主要由 5 部分组成:消息的发送对象、消息的接收对象、消息传递方式、消息内容、消息的返回。事件通常是指一种由系统预先定义而

13、由用户或系统发出的动作。事件作用于对象,对象识别事件并作出相应反应。 对象通过对外提供的方法在系统中发挥自己的作用,当系统中的其它对象请求这个对象执行某个方法时,就向该对象发送一个消息,对象响应这个请求,完成指定的操作。程序的执行取决于事件发生的顺序,由消息来驱动程序的执行。,25,UML系统分析与设计绪论,3. 继承 继承是一种连接类与类之间的层次模型。继承是指特殊类的对象拥有其一般类的属性和行为。 继承意味着“自动地拥有”,即在特殊类中不必重新对已经在一般类中所定义过的属性和行为进行定义,而是特殊类自动地、隐含地拥有其一般类的属性和行为。 继承实现了对类的重用性,提供一种明确表述共性的方法

14、。即一个特殊类既有自己定义的属性和行为,又有继承下来的属性和行为。,面向对象程序设计的基本内容,26,UML系统分析与设计绪论,面向对象程序设计的基本内容,3. 继承 继承是实现软件复用的重要机制。 在继承机制中,类分为父类(基类)与子类(派生类),子类除了包含父类的属性以外,也可以定义新的属性,或重新定义父类的属性。可以是单继承(一个类最多有一个直接父类)与多继承(一个类可以有多个直接父类)。,27,UML系统分析与设计绪论,4. 多态 多态性是指在两个或多个属于不同类中同一函数名对应多个具有相似功能的不同函数,可以使用相同的调用方式来调用这些具有不同功能的同名函数。,面向对象程序设计的基本

15、内容,28,UML系统分析与设计绪论,面向对象程序设计的基本内容,4. 多态 多态是程序设计的一个重要概念,指一个元素可以有多种解释。 一名多用或重载,如:操作符重载或函数重载。 类属,类属函数与类属类型。 消息的多态:一个公共消息可以发送到不同种类对象,得到不同的处理。 对象类型的多态:一个对象可以属于多种类型,如:派生类的对象也属于基类。 对象标识符的多态:基类的指针或引用可以指向或引用基类和派生类对象。 多态可以提高语言的可扩充性以及高层软件的复用。,29,UML系统分析与设计绪论,面向对象和项目设计,1. 用面向对象方法分析项目需求,30,UML系统分析与设计绪论,面向对象和项目设计,

16、2. 用面向对象的方法设计系统 面向对象设计的准则包括模块化、抽象、信息隐藏、低耦合和高内聚等特征。 系统设计是问题求解及建立解答的高级策略。必须制定解决问题的基本方法,系统的高层结构形式包括子系统的分解、子系统分配硬软件、数据存储管理、人机交互接口等等。系统设计一般是先从高层入手,然后细化。 系统设计要决定整个结构及风格,这种结构为后面设计阶段更详细策略的设计提供了基础。,31,UML系统分析与设计绪论,用面向对象思想建立模型,瀑布模型 瀑布模型也被称为生存周期模型,其核心思想是按照相应的工序将问题进行简化,将系统功能的实现与系统的设计工作分开,便于项目之间的分工与协作,即采用结构化的分析与

17、设计方法将逻辑实现与物理实现分开。瀑布模型将软件生命周期划分为软件计划、需求分析和定义、软件设计、软件实现、软件测试、软件运行和维护这6个阶段,并且规定了它们自上而下的次序,如同瀑布一样下落。每一个阶段都是依次衔接的。,32,UML系统分析与设计绪论,用面向对象思想建立模型,喷泉模型 喷泉模型是一种以对象为驱动、以用户需求为动力的模型,主要用于描述面向对象的软件开发过程。该模型认为软件开发过程自下而上,周期的各阶段是相互重叠和多次反复的,就像水喷上去又可以落下来,类似一个喷泉。,33,UML系统分析与设计绪论,用面向对象思想建立模型,基于组件的开发模型 基于组件的开发模型利用模块化方法将整个系

18、统模块化,并在一定组件模型的支持下复用构件库中的一个或多个软件组件,通过组合手段高效率、高质量地构造应用软件系统的过程。,34,UML系统分析与设计绪论,用面向对象思想建立模型,XP开发模型 敏捷方法强调适应性而非预测性、强调以人为中心,而不以流程为中心的软件开发过程。其特点是轻载、基于时间、紧凑、并行并基于构件。 在所有的敏捷方法中,XP(eXtreme Programming)方法是最引人注目的一种轻型开发方法。它规定了一组核心价值和方法,消除了大多数重量型开发过程中的不必要产物,建立了一个渐进型开发过程。,35,UML系统分析与设计绪论,1.2 UML简介,36,UML系统分析与设计绪论

19、,UML简介,Unified Modeling Language ,“统一建模语言” 近十几年来面向对象程序设计最重要的成果 主要由 Grady Booch, James Rumbaugh, Ivar Jacobson 等贡献者于1995年推出 中文网站 http:/www. ,37,UML系统分析与设计绪论,UML 用来对软件密集系统进行可视化建模的一种语言,也是为面向对象开发系统的产品进行说明、可视化、构造和编制文档的一种标准语言。 UML 作为一种模型语言,它使开发人会专注于建立产品的模型和结构,而不是选择什么程序和算法实现。当模型建立后,模型可以被 UML 工具转化成指定的程序语言代码

20、。,UML简介,38,UML系统分析与设计绪论,常见的UML建模工具: Rational Rose Microsoft Visio,UML简介,39,UML系统分析与设计绪论,统一建模语言UML是一组图形表示法。这些表示法的背后有共同的元模型。 UML帮助描述和设计软件系统,特别是面向对象风格建造的软件系统。 图形建模语言在软件业已经出现很长时间了。背后的基本驱动力就是:编程语言的抽象级别不够高,不方便讨论设计。,UML简介,40,UML系统分析与设计绪论,UML 拥有一套完整而成熟的建模技术,被广泛的运用于各种不同的领域。借助于基于面向对象的UML可以帮助软件工程的开发人员更好的了解业务流程

21、,建立更可靠、更完善的系统模型,从而方便我们对各种软件工程进行正确的描述和交流。,UML简介,41,UML系统分析与设计绪论,为什么要花时间学UML,图形设计表示法已经出现了一段时间了,UML的首要价值是沟通和理解。好的图形经常可以帮助沟通设计思想,特别是当你要回避许多细节时,也可以帮助你理解软件系统和业务流程。作为团队的一份子,图形有助于理解和沟通整个团队所理解到的东西。 在这些图形表示法中,UML的重要性来自它在面向对象程序设计内部的广泛使用和标准化,而且UML不仅已经是面向对象世界中占支配地位的图形表示法,而且在非面向对象圈子里也非常流行。,42,UML系统分析与设计绪论,使用UML的方

22、式,草稿 蓝图 编程语言,43,UML系统分析与设计绪论,使用UML的方式,把UML当做草稿:开发人员使用 UML 协助沟通系统的某些方面,可以粗略的画出即将要编码的东西,通常要和团队中的一群人讨论。使用草稿的目的是来帮助沟通想法或展示所要作的事情的可选方案。你不会谈论即将要写的所有代码,只会和同事谈论一下重要的东西,像这样的会议可以很短,如花10分钟来讨论需要几个小时进行的编程,或者用半天来讨论一个需要几周来进行的编程。,44,UML系统分析与设计绪论,把UML当作蓝图:需要关心完整性。一般由一名设计人员开发蓝图,为程序员建造详细设计,然后程序员在此基础上编码。设计应该足够完整,列出所有设计

23、决策,程序员应该能够跟随设计,把编码当做相当直接的活动。设计人员和程序员可以是同一个人,但通常设计人员是一名更高级的开发人员,他为一个团队的程序作设计。就如同设计师出设计图纸,移交建筑公司来建造。设计人员开发蓝图级模型一般只做到子系统的接口,而开发人员负责实现细节。 蓝图和草稿之间的界限有些模糊,但是,两者的区别基于这个事实:草稿故意画成不完整,强调重要信息,而蓝图倾向于全面,目的是把编程缩减成简单的机械活动。草稿是探索性的,蓝图是定义性的。,使用UML的方式,45,UML系统分析与设计绪论,把UML当作编程语言:在UML方面做的越多,编程变得越机械,显然这时编程应该被自动化,事实上,有很多C

24、ASE工具是生成某些形式的代码,自动化的建造系统的重要部分,最终达到一个境界整个系统可以用UML来表述。在这个环境下,开发人员画UML图,直接编译为可执行代码UML变成了源代码。,使用UML的方式,46,UML系统分析与设计绪论,1.3 UML简史,47,UML系统分析与设计绪论,UML的产生和成长,UML统一建模语言是一种建模语言是第三代用来为面向对象开发系统的产品进行说明可视化和编制文档的方法。它是由信息系统和面向对象领域的三位著名的方法学家Grady Booch、James Rumbaug和Ivar Jacobson提出的,这种建模语言得到了UML伙伴联盟的应用与反馈,并得到工业界的广泛

25、支持,并由OMG组织采纳作为业界标准。 这是软件界第一次有了一个统一的建模语言。,48,UML系统分析与设计绪论,20 世纪 80 年代,对象开始离开实验室,迈出走向真实世界的第一步,C+诞生了,这时,各种人开始考虑面向对象图形设计语言。 面向对象图形建模语言的关键书籍出现在1988年到1992年之间。领导人物包括Grady Booch、 Peter Coad、 Ivar Jacobson、Jim Odell、Jim Rumbaugh、Sally Shally等。这些作者的每一位现在都非正式地领导着一组喜欢他们的思想的实践者。所有这些方法都非常相似,然而它们之间包含许多经常会让人恼火的细小差别

26、。同一个基本概念以差别很大的表示法出现,导致了客户产生混淆。,UML的产生和成长,49,UML系统分析与设计绪论,在这个艰难的时期,也有人谈到标准化,但没人理睬。 首次引发创建UML的催化剂事件是Jim Rumbaugh 离开 GE 加盟 Grady Booch所在的Rational。 Booch/Rumbaugh联盟从一开始就被视为可以达到市场份额的临界值。Grady 和 Jim宣称“方法战争结束了我们赢了”,基本上就宣布了他们打算“以微软的方式”达成标准化。许多其他方法学家建议成立一个反Booch同盟。,UML的产生和成长,50,UML系统分析与设计绪论,在OOPSLA 95大会上,Gra

27、dy和Jim首次公开描述他们合并的方法:统一方法文档版本0.8。他们宣布Rational软件购买了Objectory,因此,Ivar Jacobson将加入统一团队。 接下来的一年更加开放的合并过程出现了,此时需要花时间和其他伙伴沟通。此时OMG担当主角。导致OMG介入的是软件工具厂商的呼吁,他们害怕标准被Rational控制, Rational工具会得到不公平的竞争优势。 1997年1月,各种组织一起提交了方法标准的建议书,以方便模型的交换。Rational和其他许多组织一起协作,发布了UML文档版本1.0作为他们的建议,这时UML第一次被叫做统一建模语言。,UML的产生和成长,51,UML

28、系统分析与设计绪论,接下来是短回合的掰手腕的过程,各种建议书被合并。OMG采纳1.1版本作为官方的OMG标准。稍后又做了一些修订。 修订1.2完全是走走过场。 修订1.3更加重要。 修订1.4围绕组件和扩展机制添加了许多详细的概念。 修订1.5添加了动作语义。,UML的产生和成长,52,UML系统分析与设计绪论,当人们谈论UML时,会把创造者的功劳主要归于Grady Booch、Ivar Jacobson和Jim Rumbaugh,他们一般被称为“三友”。但实际上,UML表示法首先成型于Booch/ Rumbaugh统一方法,从那时候开始很多工作就由OMG委员会领导了。在后来这些阶段中, Jim Rumbaugh是“三友”中唯一做出重要贡献的。UML过程委员会的那些成员称得上首要的UML功臣。,UML的产生和成长,53,UML系统分析与设计绪论,54,UML系统分析与设计绪论,

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 社会民生


经营许可证编号:宁ICP备18001539号-1