《UML建模语言》PPT课件.ppt

《《UML建模语言》PPT课件.ppt》由会员分享，可在线阅读，更多相关《《UML建模语言》PPT课件.ppt（156页珍藏版）》请在三一办公上搜索。

1、1,UML建模语言,2,UML建模语言目录,5.1 UML概述,5.2 通用模型元素,5.3 用例建模,5.4静态建模,5.5 动态建模,5.6 实现模型,5,UML建模语言,3,概 述,软件工程领域在1995年至1997年取得了前所未有的进展,其成果超过软件工程领域过去15年来的成就总和。其中最重要的、具有划时代重大意义的成果之一就是统一建模语言 UML(Unified Modeling Language)的出现。在世界范围内,至少在近10年内，UML将是面向对象技术领域内占主导地位的标准建模语言。,概 述,4,5.1 UML概述,5.1 UML概述,UML（Unified Modeling

2、 Language）是软件界第一个统一的建模语言，该方法结合了Booch,OMT,和OOSE方法的优点，统一了符号体系，并从其它的方法和工程实践中吸收了许多经过实际检验的概念和技术。它是一种标准的表示,已成为国际软件界广泛承认的标准。它是第三代面向对象的开发方法，是一种基于面向对象的可视化的通用(General)建模语言。为不同领域的用户提供了统一的交流标准 UML图。UML应用领域很广泛，可用于软件开发建模的各个阶段，商业建模（Business Modeling）,也可用于其它类型的系统。,5,什么是模型？为什么要建模？,什么是模型？,模型是一个系统的完整的抽象。人们对某个领域特定问题的求解

3、及解决方案，对它们的理解和认识都蕴涵在模型中。通常，开发一个计算机系统是为了解决某个领域特定问题，问题的求解过程，就是从领域问题到计算机系统的映射。,领域问题,概念模型,分析、抽取,系统需求,解决方案,分析、设计,提取,UML作为一种可视化的建模语言，提供了丰富的基于面向对象概念的模型元素及其图形表示元素。,6,5.1.1 UML的形成,九十年代中，面向对象方法已经成为软件分析和设计方法的主流。1994年10月Jim Rumbaugh和Grady Booch共同合作把他们的OMT和Booch方法统一起来，到1995年成为“统一方法”（Unified Method）版本0.8。随后，Ivar J

4、acobson加入，并采用他的用例(User case)思想,到1996年，成为“统一建模语言”版本0.9。1997年1月，UML版本1.0被提交给OMG组织，作为软件建模语言标准的候选。其后的半年多时间里，一些重要的软件开发商和系统集成商都成为“UML伙伴”，如IBM,Mircrosoft,HP等.1997年11月7日被正式采纳作为业界标准。,5.1.1 UML的形成,7,图5.1,5.1.1 UML的形成,8,5.1.2 UML的主要内容,UML的定义包括UML语义和UML表示法两个部分。(1)UML语义 描述基于UML的精确元模型(meta-model)定义。元模型为UML的所有元素在语

5、法和语义上提供了简单、一致、通用的定义性说明,使开发者能在语义上取得一致,消除了因人而异的表达方法所造成的影响。此外UML还支持对元模型的扩展定义。UML支持各种类型的语义。如布尔、表达式、列表、阶、名字、坐标、字符串和时间等，还允许用户自定义类型。(2)UML表示法定义UML符号的表示法,为开发者或开发工具使用这些图形符号和文本语法,进行系统建模提供了标准。这些图形符号和文字所表达的是应用级的模型,在语义上它是UML元模型的实例。,5.1.2 UML的主要内容,9,5.1.2 UML的主要构成,UML是一种标准化的图形建模语言，它是面向对象分析与设计的一种标准表示。由:视图(views),图

6、(Diagrams),模型元素(Model elements)通用机制(general mechanism)等几个部分构成。,UML的主要构成,10,UML的主要内容,一个系统应从不同的角度进行描述,从一个角度观察到的系统称为一个视图（view）。视图由多个图（Diagrams）构成，它不是一个图表（Graph）,而是在某一个抽象层上，对系统的抽象表示。如果要为系统建立一个完整的模型图，需定义一定数量的视图，每个视图表示系统的一个特殊的方面。另外，视图还把建模语言和系统开发时选择的方法或过程连接起来。,5.1.2 UML的主要内容,视图(views),11,Use case View描述系统的

7、外部特性、系统功能等。,Implementation View 表示系统的实现特征，常用构件图表示。,Design View 描述系统设计特征，包括结构模型视图和行为模型视图，前者描述系统的静态结构(类图、对象图)，后者描述系统的动态行为(交互图、状态图、活动图)。,Process View 表示系统内部的控制机制。常用类图描述过程结构，用交互图描述过程行为。,Deployment View 配置视图描述系统的物理配置特征。用配置图表示。,5.1.2 UML的主要内容,UML常用视图,12,UML语言定义了五种类型，9种不同的图，把它们有机的结合起来就可以描述系统的所有视图。用例图(Use c

8、ase diagram)从用户角度描述系统功能,并指出各功能的操作者。静态图(Static diagram),表示系统的静态结构。包括类图、对象图、包图。行为图(Behavior diagram)，描述系统的动态模型和组成对象间的交互关系。包括状态图、活动图。交互图(Interactive diagram),描述对象间的交互关系。包括顺序图、合作图。实现图(Implementation diagram)用于描述系统的物理实现。包括构件图、部件图。,5.1.2 UML的主要内容,UML提供的图(Diagrams),图,13,代表面向对象中的类，对象，关系和消息等概念，是构成图的最基本的常用的元素

9、。一个模型元素可以用在多个不同的图中，无论怎样使用，它总是具有相同的含义和相同的符号表示。通用机制(general mechanism)用于表示其他信息，比如注释，模型元素的语义等。另外，为了适应用户的需求，它还提供了扩展机制(Extensibility mechanisms)，包括构造型(Stereotype)、标记值(Tagged value)和约束(Constraint).,5.1.2 UML的主要内容,模型元素(Model elements),14,UML在演变过程中还提出了一些新的概念。在UML标准中新加了模板(Stereotypes)、职责(Responsibilities)、扩展

10、机制(Extensibility mechanisms)、线程(Threads)、过程(Processes)、分布式(Distribution)、并发(Concurrency)、模式(Patterns)、合作(Collaborations)、活动图(Activity diagram)等新概念,并清晰地区分类型(Type)、类(Class)和实例(Instance)、细化(Refinement)、接口(Interfaces)和组件(Components)等概念。,5.1.2 UML的主要内容,15,(1)统一标准UML统一了Booch、OMT和OOSE等方法中的基本概念，已成为OMG的正式标准，

11、提供了标准的面向对象的模型元素的定义和表示。(2)面向对象UML还吸取了面向对象技术领域中其他流派的长处。UML符号表示考虑了各种方法的图形表示,删掉了大量易引起混乱的、多余的和极少使用的符号,也添加了一些新符号。(3)可视化、表示能力强系统的逻辑模型或实现模型都能用UML模型清晰的表示，可用于复杂软件系统的建模。(4)独立于过程UML是系统建模语言，独立于开发过程。(5)易掌握、易用由于UML的概念明确，建模表示法简洁明了，图形结构清晰，易于掌握使用。,5.1.3 UML的特点,5.1.3 UML的特点,16,5.2 通用模型元素,5.2 通用模型元素,模型元素是UML构造系统的各种元素，是

12、UML构建模型的基本单位。模型元素代表面向对象中的类，对象，关系和消息等概念，是构成图的最基本的常用的概念。分为以下两类：1、基元素 是已由UML定义的模型元素。如：类、结点、构件、注释、关联、依赖和泛化等。2、构造型元素(版类)在基元素的基础上构造的新的模型元素，是由基元素增加了新的定义而构成的，如扩展基元素的语义（不能扩展语法结构）,也允许用户自定义。构造型用括在双尖括号中的字符串表示。目前UML提供了40多个预定义的带构造型元素。如使用Use、扩展 Extend。,17,5.2.1 模型元素,5.2.1 模型元素,图5.2,可以在图中使用的概念统称为模型元素。模型元素在图中用其相应的视图

13、元素（符号）表示，图5.2给出了常用的元素符号：类、对象、结点、包和组件等。,18,模型元素,关联：连接（connect）模型元素及链接(link)实例。依赖：表示一个元素以某种方式依赖于另一种元素。泛化：表示一般与特殊的关系，即“一般”元素是“特殊”关系的泛化。聚合：表示整体与部分的关系。除了上述的模型元素外，模型元素还包括消息，动作和版类（stereotype）等。,图5.3,3.2.1 模型元素,模型元素与模型元素之间的连接关系也是模型元素，常见的关系有关联（association）、泛化（generalization）、依赖(dependency)和聚合(aggregation)，其中

14、聚合是关联的一种特殊形式。这些关系的图示符号如图5.3所示。,19,5.2.2 关联和链,关联（association）是两个或多个类之间的一个关系。链（link)是关联的具体体现。,5.2.2 关联和链,关联的表示如图3.(a)(b)所示，关联有二元关联(binary)、三元关联(ternary)、多元关联(higher order)。,图5.,（a）二元关联,（b）三元关联,20,3.2.3 关联的表示,关联的重数重数(multiplicity)表示多少个对象与对方对象相连接(图5.5)，常用的重数符号有：“0.1”表示零或1“0.*”或“*”表示零或多个“1.*”表示1或多个“1,3,7

15、”表示1或3或7（枚举型）重数的默认值为1。,5.2.3 关联的表示,图5.5 带有多重性关联,有序关联与导航（导引）在关联的多端标注ordered指明这些对象是有序的(图5.6）。关联可以用箭头，表示该关联使用的方向(单向或双向)，称为导引或导航(navigation)。,重数02 表示每个人（Person）在指定的年度（Year），最多可以参加两个委员会（Committee），而重数35 表示每个委员会由3 到5 个委员组成，重数14 表示在一个委员会中，一个人的任期不超过4 年。,note,21,受限关联(qualified association)使用限定词对该关联的另一端的对象进行明

16、确的标识和鉴别（图5.7）。,图5.7 受限关联,5.3.1 关联的表示5,关联的表示,22,5.2.4 约束,UML中提供了一种简便、统一和一致的约束（constraint），是各种模型元素的一种语义条件或限制。一条约束只能应用于同一类的元素。,约束的表示如果约束应用于一种具有相应视图元素的模型元素，它可以出现在它所约束元素视图元素的旁边。通常一个约束由一对花括号括起来（constraint），花括号中为约束内容。,图5.8,5.2.4 约束,23,约束,图5.9 对泛化的约束的两种表示方法,对泛化的约束应用于泛化的约束，显示在大括号里，若有多个约束，用逗号隔开。如果没有共享，则用一条虚线通

17、过所有继承线，并在虚线的旁边显示约束，如图3.9所示：,5.3.2 约束,P214,24,对泛化有以下常用的约束：1、complete:说明泛化中所有子元素都已在模型中说明，不允许再增加其它子元素。2、disjoint:父类对象不能有多于一个型的子对象。3、incomplete:说明不是泛化中所有子元素都已说明，允许再增加其它子元素。4、overlapping:给定父类对象可有多于一个型的子对象，表示重载。,5.3.2 约束,返回,教材:P213,25,对消息，链接角色和对象的约束 自定义约束,图5.10 对象类的xor关联,5.3.2 约束,关联的约束 对关联有以下常用的约束：1、impli

18、cit:该关联只是概念性的，在对模型进行精化时不再用。2、ordered:具有多重性的关联一端的对象是有序的。3、changeable:关联对象之间的链(Link)是可变的（添加、修改、删除）。4、addonly:可在任意时刻增加新的链接。5、frozen:冻结已创建的对象，不能再添加、删除和修改它的链接。6、xor:“或约束”，某时刻只有一个当前的关联实例。,26,5.2.6 依赖,依赖关系描述的是两个模型元素（类，组合，用例等）之间的语义上的连接关系，其中一个模型元素是独立的，另一个模型元素是非独立的（或依赖的）。如图5.11表示类A依赖于类B的一个友元依赖关系。,类A,类 B,友元,5.

19、2.6 依赖,图5.11,教材:P214,27,5.2.7 细化,有两个元素A和B，若B元素是A元素的详细描述，则称B,A元素之间的关系为B元素细化A元素。细化与类的抽象层次有密切的关系，在构造模型时要经过逐步细化,逐步求精的过程。如图3.9所示，类B是类A细化的结果。,5.2.7 细化,5.2.8 注释,注释用于对UML语言的元素或实体进行说明，解释和描述。通常用自然语言进行注释。,P214,28,5.3 用例建模,1992年由Jacobson提出了Use case 的概念及可视化的表示方法Use case图，受到了IT界的欢迎，被广泛应用到了面向对象的系统分析中。用例驱动的系统分析与设计方

20、法已成为面向对象的系统分析与设计方法的主流。用例模型由Jacobson在开发AXE系统中首先使用,并加入由他所倡导的OOSE和Objectory方法中。用例方法引起了面向对象领域的极大关注。自1994年Ivar Jacobson的著作出版后,面向对象领域已广泛接纳了用例这一概念,并认为它是第二代面向对象技术的标志。,5.3 用例建模,29,用例建模技术，用于描述系统的功能需求。在宏观上给出模型的总体轮廓。通过对典型用例的分析，使开发者能够有效地了解用户的需求。,5.3.1 用例建模概述,5.3.1 用例建模概述,图3.14,签定一份保险单,客户,保险销售人员,销售统计,客户统计,30,3.3.

21、2 用例模型(Use case model)用例模型描述的是外部执行者(Actor)所理解的系统功能。它描述了待开发系统的功能需求。它驱动了需求分析之后各阶段的开发工作,不仅在开发过程中保证了系统所有功能的实现,而且被用于验证和检测所开发的系统,从而影响到开发工作的各个阶段和 UML 的各个模型。用例模型由若干个用例图构成，用例图中主要描述执行者和用例之间的关系。在UML中,构成用例图的主要元素是用例和执行者及其它们之间的联系。,3.3.2 用例模型,创建用例模型的工作包括：定义系统、确定执行者和用例、描述用例、定义用例间的关系、确认模型。,P216,31,一、执行者(Actor)执行者是指用

22、户在系统中所扮演的角色。执行者在用例图中是用类似人的图形来表示,但执行者可以是人，也可以是一个外界系统。,注意：用例总是由执行者启动的。,如何确定执行者：1、谁使用系统的主要功能(主执行者)?2、谁需要从系统获得对日常工作的支持和服务？3、需要谁维护管理系统的日常运行（副执行者）？4、系统需要控制哪些硬件设备？5、系统需要与其它哪些系统交互？6、谁需要使用系统产生的结果（值）？,一、执行者,5.3.2 用例模型,回例1,32,二、用例,二、用例(use case)从本质上讲,一个用例是用户与计算机之间的一次典型交互作用。在UML中,用例被定义成系统执行的一系列动作（功能）。用例有以下特点:用例

23、捕获某些用户可见的需求,实现一个具体用户目标。用例由执行者激活,并将结果值反馈给执行者。用例必须具有功能上的完整描述。,如何确定用例：1、与系统实现有关的主要问题是什么？2、系统需要哪些输入/输出？这些输入/输出从何而来？到哪里去？3、执行者需要系统提供哪些功能？4、执行者是否需要对系统中的信息进行读、创建、修改、删除或存储？,二、用例,5.3.2 用例模型,回例1,33,用例图,图5.16 用例图的元素,用例图,用例图描述了系统的功能需求，它是从执行者的角度来理解系统，由“执行者”、“用例”和“用例之间的关系”3类模型元素构成。图中还有另外两种类型的连接,即使用和扩展关系，是两种不同形式的泛

24、化关系。,Use表示一个用例使用另一个用例。Extend通过向被扩展的用例添加动作来扩展用例。,教材:P218,用例图实例,用例图实例,5.3.4 用例图实例,图书销售管理功能用例图,35,5.3.4 用例图实例,例1 建立项目与资源管理系统的Use case图,系统的主要功能是：项目管理，资源管理和系统管理。项目管理包括项目的增加、删除、更新。资源管理包括对资源和技能的添加、删除和更新。系统管理包括系统的启动和关闭，数据的存储和备份等功能。,1、分析确定系统的执行者(角色),到确定,到确定,项目管理员、资源管理员、系统管理员、备份数据系统。,项目管理，资源管理和系统管理。,2、确定用例,3、

25、对用例进行分解，画出下层的Use case图 对上层的用例进行分解,并将执行者分配到各层次的Use case图中。,图5.19角色描述模板,还应画出相应的执行者描述模板及用例描述模板。,36,例1 项目与资源管理系统（PRMS）,Use Case图可以自顶而下不断精化，抽象出不同层次的Use Case图。,5.3.4 用例图实例,37,例1 项目与资源管理系统（PRMS）,图5.22 项目管理Use Case图,5.3.4 用例图实例,系统管理员,图5.23 系统管理Use Case图,38,作 业,现有一医院病房监护系统，病症监视器安置在每个病房，将病人的病症信号实时传送到中央监视系统进行分

26、析处理。在中心值班室里，值班护士使用中央监视系统对病员的情况进行监控，根据医生的要求随时打印病人的病情报告，定期更新病历，当病症出现异常时，系统会立即自动报警,并实时打印病人的病情报告，立及更新病历。要求根据现场情景，对医院病房监护系统进行需求分析，建立系统的Use case model。,请对系统需求进行分析！,经过初步的需求分析，得到系统功能要求：1、监视病员的病症（血压、体温、脉搏等）2、定时更新病历3、病员出现异常情况时报警。4、随机地产生某一病员的病情报告。,例2 医院病房监护系统,监视病情,更新病历,情景教学,二、简单的需求分析说明 系统名称：医院病房监护系统 根据分析系统主要实现

27、以下功能：1、病症监视器可以将采集到的病症信号（组合），格式化后实时的传送到中央监护系统。2、中央监护系统将病人的病症信号分解后与标准的病症信号库里的病症信号的正常值进行比较，当病症出现异常时系统自动报警。3、当病症信号异常时，系统自动更新病历并打印病情报告。4、值班护士可以查看病情报告并进行打印。5、医生可以查看病情报告，要求打印病情报告，也可以查看或要求打印病历。6、系统定期自动更新病历。,退出,上页,首页,下页,末页,需求分析,三、用UML的静态建模机制定义并描述系统的静态结构（一）建立系统的用例图1、通过以下六个问题识别角色(1)谁使用系统的主要功能？(2)谁需要系统的支持以完成日常工

28、作任务？(3)谁负责维护，管理并保持系统正常运行？(4)系统需要应付（或处理）哪些硬设备？(5)系统需要和哪些外部系统交互？(6)谁（或什么）对系统运行产生的结果（值）感兴趣？,需求分析,Uestc p12-13,通过回答这六个问题以后，再进一步分析可以识别出本系统的四个角色：值班护士，医生，病人，标准病症信号库。角色描述模板,通过分析可以初步识别出系统的用例为：中央监护，病症监护，提供标准病症信号，病历管理，病情报告管理。顶层用例图为：,角色描述,通过分析可以初步识别出系统的用例为：中央监护，病症监护，提供标准病症信号，病历管理，病情报告管理。顶层用例图为：,角色描述,将用例细化，可以得到分

29、解的用例：1、中央监护 分解为：a 分解信号 将从病症监护器传送来的组合病症信号分解为系统可以处理的信号。b 比较信号 将病人的病症信号与标准信号比较。c 报警 如果病症信号发生异常（即高于峰值），发出报警信号。d 数据格式化 将处理后的数据格式化以便写入病历库。2、病症监护 分解为：e 信号采集 采集病人的病症信号。f 模数转化 将采集来的模拟信号转化为数字信号。g 信号数据组合 将采集到的脉搏，血压等信号数据组合为一组信号数据。h 采样频率改变 根据病人的情况改变监视器采样频率。3、提供标准病症信号 i（此用例不分解）,用例细化,4、病历管理 分解为：j 生成病历k 查看病历l 更新病历

30、m 打印病历 5、病情报告 分解为：n 显示病情报告 在显示器上显示病情o 打印病情报告 在打印机打印病情报告,用例细化,给出细化的用例图,细化的用例图,47,任何建模语言都以静态建模机制为基础,标准建模语言UML也不例外。所谓静态建模是指对象之间通过属性互相联系，而这些关系不随时间而转移。类和对象的建模，是UML建模的基础。我们认为,熟练掌握基本概念、区分不同抽象层次以及在实践中灵活运用,是三条最值得注意的建模基本原则。UML的静态建模机制包括：用例图(Use case diagram)类图(Class diagram)对象图(Object diagram)包图(Package diagra

31、m)构件图(Component diagram)配置图(Deployment diagram),5.4 静态建模,5.4 静态建模,48,5.4.1 类与对象,5.4.1 对象类与对象,面向对象的开发方法的基本任务是建立对象模型，是软件系统开发的基础。UML中的类图(Class Diagram)与对象图(Object Diagram)表达了对象模型的静态结构，能够有效地建立专业领域的计算机系统对象模型。,一、类图与对象图类是面向对象模型的最基本的模型元素，用类图来描述。类图(Class diagram)由系统中使用的类以及它们之间的关系组成，是描述系统的一种图式，分为长式和短式。类及类型名均用

32、英文大写字母开头，属性及操作名为小写字母开头。常见类型有：Char,Boolean,Double,Float,Integer,Object,Short,String等。类图是构建其它图的基础。,49,5.4.1 对象类与对象,类名,对象是类的实例(instance),用对象图来描述。对象图亦分长式和短式。,对象名,图5.24 类图与对象图,图5.25 对象图,50,(1)属性(attribute)属性用来描述类的特征，表示需要处理的数据。属性定义：visibility attribute-name:type=initial-value property-string 可见性 属性名：类型=缺省

33、值约束特性 其中：可见性(visibility)表示该属性对类外的元素是否可见。分为：public（+）公有的，即模型中的任何类都可以访问。private（-）私有的，表示不能被别的类访问。protected（#）受保护的，表示只能被该类及其子类访问。如果可见性未申明，表示其可见性不确定。,5.4.1 对象类与对象,51,(2)操作 对数据的具体处理方法的描述则放在操作部分，操作说明了该类能做些什么工作。操作通常称为函数，它是类的一个组成部分，只能作用于该类的对象上。操作定义：visibility operating-name(parameter-list):return-type prope

34、rty-string 可见性 操作名（参数表）：返回类型约束特性 其中：可见性同上。参数表：参数名：类型，Parameter-name:type=default-value 返回类型：操作返回的结果类型。,5.4.1 对象类与对象,类图的描述,52,5.4.1 对象类与对象,二、类的识别 是面向对象方法的一个难点，但又是建模的关键。常用的方法有：1、名词识别法 2、系统实体识别法 3、从用例中识别类 4、利用分解与抽象技术,关键是要定义类的“属性”及“操作”。,53,1名词识别法,该方法的关键是识别问题域中的实体，由于问题域中的实体通常是以名词或者名词短语来描述的，通过对系统简要描述的分析，在

35、提出实体对应名词的基础上识别类。名词识别法的步骤如下：按照指定语言，对系统进行描述。描述过程应与领域专家共同合作完成，并遵循问题域中的概念和命名。从系统中标识名词、代词、名词短语。其中，单数名词（代词）可以标识为对象，而复数名词则可标识为类。识别确定（取、舍）类。并非所有列出的名词、代词、名词短语都是类，应根据一定的原则进行识别确定。例1：确定银行网络系统ATM(Auto Trade Machine)的类，,54,系统简要描述,银行网络系统包括人工出纳和分行共享的自动出纳机；各分理处用自己的计算机处理业务（保存帐户、处理事务等）；各分理处与出纳站通过网络通信；出纳站录入帐户和事务数据；自动出纳

36、机与分行计算机通信；自动出纳机与用户接口，接受现金卡；发放现金；打印收据；分行计算机与拨款分理处结帐。要求系统正确处理同一帐户的并发访问；网络费用平均摊派给各分理处。,55,类的识别,采用名词识别法：检查问题陈述中的所有名词，得到初始类：软件 银行网络 分行计算机 系统 分行 出纳站出纳员 分理处 分理处计算机 自动出纳机 帐户 帐户数据现金卡 事务 事务数据 用户 顾客 现金收据 访问 费用 安全措施 记录保管,56,根据下述原则进一步确定类：去掉冗余类：如两个类表述同一信息，应保留最具有描述能力的类，如“用户”与“顾客”是重复的描述，由于“顾客”更具有描述性，故保留它，删除“用户”。去掉不

37、相干的类：删除与问题无关或关系不大的类，如“费用”。删除模糊的类：有些初始类边界定义不确切，或范围太广，应该删除。如“系统”、“安全措施”、“记录保管”、“银行网络”。删除那些性质独立性不强的，而应该是类“属性”的候选类：如“帐户数据”、“收据”、“现金”、“事务数据”。所描述的操作不适宜作为对象类，并被其自身所操纵，所描述的只是实现过程中的暂时的对象，应删去。如“软件”，“访问”,57,最后确定的类为：分行计算机 分行 出纳站 出纳员 分理处 分理处计算机自动出纳机 帐户 现金卡 事务 顾客,58,2系统实体识别法,该方法不关心系统的运作流程及实体之间的通信状态，而只考虑系统中的人员、组织、

38、地点、表格、报告等实体，经过分析将他们识别为类（或对象）。被标识的实体有：系统需要存储、分析、处理的信息实体、系统内部需要处理的设备、与系统交互的外部系统、系统相关人员、系统的组织实体等。下面举例说明系统实体识别法的应用：例2 有一个购物超市，顾客可在货架上自由挑选商品，由收款机收款，收款机读取商品上的条型码标签，并计算商品价格。收款机应保留所有交易的记录，以备帐务复查及汇总使用。,59,通过分析问题的陈述，确定以下几类实体：信息实体：交易记录、商品、税务信息、销售记录、货存记录。设备：收款机、条型码扫描器。交互系统：信用卡付款系统。人员职责：收款员、顾客、会计、经理。系统的组织实体：本例不考

39、虑。以上列出的实体，都可以直接识别为类。,60,3 从用例中识别类,用例图本质上是一种系统的描述形式，可以根据用例的描述来识别类。通过用例识别类的方法与实体识别法很相似，只不过实体识别法是针对整个系统考虑，而用例识别法是分别对每一个用例进行识别，因此，用例识别法可能会识别出使用实体识别法未识别出来的类。针对每个用例，可通过回答以下问题来识别类：对用例描述中出现了哪些实体？或者用例的完成需要哪些实体的合作？用例在执行过程中会产生并存储了哪些信息？用例要求与之关联的角色应该向该用例输入什么信息？用例向与之关联的角色输出什么信息？用例需要对哪些硬设备进行操作？,61,4利用分解与抽象技术,无论使用哪

40、种方法确定类时，还常使用分解和抽象两类技术：分解技术通过上述方法，可以得到一系列反映问题域的类，但往往有的类还未被识别出来，有的“小类”可能被包含在“大类”中。实际上，所谓“大类”常以整体类和组合类的形式出现，所以分解技术是对整体类和组合类进行分解的技术，可控制单个类的规模。通过分析对已标识出来的“大类”进行分解，得到新的类。例如已经识别了“汽车”类，可以通过分解技术得到“卡车”类、“小轿车”类、“客车”类等。,62,抽象技术,如果在所识别的类中，存在着一些具有相似性的类，所谓相似性是指在信息和动作上的相似性。例如“汽车”类与“摩托车”类之间的相似性是都有“发动机”。根据这些类的相似性建立抽象

41、类，并建立抽象类与这些类之间的继承关系。如可以建立抽象类“机动车”类，而“汽车”类与“摩托车”类都是通过继承关系而得到的子类。抽象类实现了系统内部的重用，很好地控制了复杂性，并为所有子类定义了一个公共的界面，使设计局部化，提高系统的可修改性和可维护性。,63,5.4.2 UML中类之间的关系,UML中类的关系有关联(association)、聚集(aggregation)、泛化(generalization)、依赖(depending)和细化(refinement)。,一、关联 关联是类之间的连结,分为：1、常规关联(图5.26)2、多元关联3、有序关联4、受限关联5、或关联(图5.27)6、

42、关联类(图5.28),图5.26 雇佣关联,图5.27 或关联,图5.28 关联类,5.4.2 UML中类之间的关系,教材:P210,64,5.4.2 UML中类之间的关系,7、其它关联 递归关联(Recursive association)即一个类到自身的关联。,图5.29 递归关联,人,治疗,病人,医生,图5.30 带有职责的递归关联,P210,65,二、聚集(aggregation),聚集是一种特殊的关联，它指出类间的“整体-部分”关系。又分为：,1、共享聚集(shared aggregation)其“部分”对象可以是任意“整体”对象的一部分。当“整体”端的重数不是1时，称聚集是共享的。

43、,、组合聚集(composition aggregation)其“整体”(重数为0、1)拥有它的“部分”。部分仅属于同一对象，整体与部分同时存在。,图3.31 共享聚集,图3.32 组合聚集,3.4.2 UML中类之间的关系,p211,66,三、泛化,泛化指出类之间的“一般与特殊关系”，即继承关系。父类与子类之间构成类的分层结构。,5.4.2 UML中类之间的关系,抽象类 指没有实例的类，定义一些抽象的操作，即不提供实现方法的操作，只提供操作的特征。并附以abstract。交叠泛化 在继承树中，若存在某种具有公共父类的多重继承，称为是交叠(overlapping)的。否则是不交的(disjoi

44、nt)。完全泛化 一般类特化出它所有的子类，称为完全泛化，记为complete。不完全泛化 即未特化出它所有的子类，称为是不完全泛化 的，表示为incomplete.,有关泛化的约束,P213,67,5.4.2 UML中类之间的关系,三、泛化,图3.34 完全泛化,图3.35 泛化中的多态性及带识别名称的泛化,驱动方式,驱动方式,当Person对象使用交通工具的drive操作时，具体结果取决于所操作的对象，如果是汽车对象，则drive对应启动轮子转动，若是轮船对象，则drive对应启动螺旋浆。这种称为多态性。此外，在泛化关系中还可采用识别名称来指明泛化中一般化到具体化的主要依椐。因此，交通工具

45、与汽车和轮船的泛化关系中，识别名称为驱动方式,继承性的实例,图5.36 泛化关系,5.4.2 UML中类之间的关系,69,5.4.2 UML中类之间的关系,1,*,1,*,1,*,0.1,项,图5.37 泛化关系,PDF P28-29,*,一个关于订单的类图，其中，订单类（Order）与订单行类（OrderLine）之间有对多的关联，角色LineItem（行项目）表示订单行是订单的一个行项目。,（二）识别系统的类 通过名词识别法和系统实体识别法等方法可以识别出系统的十二个类,以下用类图这种简单明了的方法分别表示出类的名称，属性操作。见下图：,退出,上页,首页,下页,末页,类的识别,值班护士 医

46、生 病人 病症监视 中央监护系统 报警信号 标准病症信号库 病历库 病人病症信号 病情报告 病历 标准病症信号,退出,上页,首页,下页,末页,类的识别,在类图中标明类之间的关系：,退出,上页,首页,下页,末页,系统类图,73,5.4.3 包图,一个最古老的软件方法问题是:怎样将大系统拆分成小系统。UML中解决该问题的思路之一是将许多类集合成一个更高层次的单位,形成一个高内聚、低耦合的类的集合。UML中这种分组机制叫包(Package)。引入包是为了降低系统的复杂性。包是一种组合机制，把各种各样的模型元素通过内在的语义连在一起成为一个整体就叫包，构成包的模型元素称为包的内容，包通常用于对模型的组

47、织管理，因此有时又将包称为子系统（subsystem）。包拥有自己的模型元素，包与包之间不能共用一个相同的模型元素，包的实例没有任何语义（含义）。仅在模型执行期间包才有意义。,5.4.3 包图,74,包的内容：可以是类的列表,也可以是另一个包图,还可以是一个类图。包之间的关系有依赖和泛化（继承）。,5.4.3 包图,包,75,和类一样包也有可见性，利用可见性控制外部包对包的内容的存取方式，UML中定义了四种可见性：私有(private)，公有(public)，保护(protected)和实现(implementation)。缺省值为公有。包也可以有接口，接口与包之间用实线相连，接口通常由包的一

48、个或多个类实现。,5.4.3 包图,图5.39 包图举例,76,包的继承,5.4.3 包图,图5.40 包图,77,包图举例,5.4.3 包图,图5.41 包图举例,78,客户支持系统,客户维护子系统,包图示例,库存管理子系统,订单输入子系统,目录维护子系统,订单执行子系统,79,客户支持系统,包括设计类的包图示例,客户维护子系统,订单输入子系统,目录维护子系统,订单执行子系统,客户,目录,包,订单条目,订单交易,订单,退货条目,发运人,运输,（三）用包图描述医院监护系统的体系结构,退出,上页,首页,下页,末页,包图,81,5.5动态建模,9.5动态模型,5.5 UML动态建模,图5.42,动

49、态模型主要描述系统的动态行为和控制结构。动态行为包括系统中对象生存期内可能的状态以及事件发生时状态的转移，对象之间动态合作关系，显示对象之间的交互过程以及交互顺序，同时描述了为满足用例要求所进行的活动以及活动间的约束关系。,在动态模型中,对象间的交互是通过对象间消息的传递来完成的。对象通过相互间的通信(消息传递)进行合作,并在其生命周期中根据通信的结果不断改变自身的状态。,UML消息的图形表示是用带有箭头的线段。,82,动态模型,状态图(state diagram)：状态图用来描述对象，子系统，系统的生命周期。活动图(activity diagram)：着重描述操作实现中完成的工作以及用例实例

50、或对象中的活动，活动图是状态图的一个变种。顺序图(sequence diagram)：是一种交互图，主要描述对象之间的动态合作关系以及合作过程中的行为次序，常用来描述一个用例的行为。合作图(collaboration diagram)：用于描述相互合作的对象间的交互关系，它描述的交互关系是对象间的消息连接关系。,9.5动态模型,5.5 UML动态建模,动态模型主要描述系统的动态行为和控制结构。包括4类图：状态图、活动图、顺序图、合作图。,83,UML中的消息,一、简单消息(simple)表示控制流，描述控制如何从一个对象传递到另一个对象，但不描述通信的细节。,二、同步消息(synchronou