用例图画法举例.ppt

《用例图画法举例.ppt》由会员分享，可在线阅读，更多相关《用例图画法举例.ppt（172页珍藏版）》请在三一办公上搜索。

1、第3章统一建模语言UML,2023/8/21,3章 统一建模语言UML,2,本章内容,3.1 UML概述 3.2 UML的构成 3.3 UML的图3.4 UML的工具软件要点回顾,2023/8/21,3章 统一建模语言UML,3,3.1 UML概述,UML的产生背景 什么是UML UML中的视图,2023/8/21,3章 统一建模语言UML,4,3.1.1 UML的产生背景,UML是一个通用的可视化建模语言，是用于对软件进行描述、可视化处理、构造和建立软件系统的文档。1994年Rational软件公司Rumbaugh与Booch合作，开始合并OMT和Booch方法中使用的概念，并于1995年提

2、出了一个建议。随后Jacobson也加入了Rational公司，开始与Rumbaugh和Booch一同工作，他们共同致力于设计统一建模语言。1996年，OMG(Object Management Group)发布了向外界征集关于OO建模标准方法的消息。,Rumbaugh，1991年提出OMT(面向对象模型技术),2023/8/21,3章 统一建模语言UML,5,UML被OMG采纳为标准,UML的三位创始人设计出一种能被软件开发工具提供者、软件开发方法学家和开发人员这些最终用户所接受的建模语言。1997年9月他们向OMG提交了UML方法。1997年11月，UML被OMG全体成员一致通过，并被采纳

3、为标准。2000年推出了UML 1.4版本，2003年推出了UML 1.5版本，目前最新的版本是UML 2.1。,2023/8/21,3章 统一建模语言UML,6,3.1.2 什么是UML,1.UML是一种语言 2.UML的主要特点,2023/8/21,3章 统一建模语言UML,7,1.UML是一种语言,UML定义了一系列的图形符号来描述软件系统。它们有严格的语义和清晰的语法。图形符号及其背后的语义和语法组成了一个标准，使得软件开发的所有相关人员都能用它来对软件系统的各个侧面进行描述。模型元素代表OO中的类、对象、消息和关系等概念，是构成图的最基本的常用概念。,2023/8/21,3章 统一建

4、模语言UML,8,静态结构、动态行为,UML可描述系统的静态结构和动态行为，从不同但相互联系的角度对系统建立的模型可用于不同的目的。UML将系统描述为一些离散的相互作用的对象，通过静态结构定义系统中对象的属性和操作及这些对象之间的相互关系。动态行为：定义对象的时间特性和对象为完成目标而相互进行通信的机制。,2023/8/21,3章 统一建模语言UML,9,2.UML的主要特点,统一的标准：UML是被OMG接受为标准的建模语言，越来越多的开发人员使用 UML进行软件开发，越来越多的厂商支持UML。面向对象：是支持OO软件开发的建模语言。概念明确，建模表示法简洁，图形结构清晰，可视化、表示能力强大

5、，容易掌握和使用。独立于过程：UML不依赖于特定的软件开发过程。,2023/8/21,3章 统一建模语言UML,10,3.1.3 UML中的视图,0.UML的视图1.用例视图(用户模型视图)2.逻辑视图(结构模型视图)3.交互视图(行为模型视图)4.实现视图(实现模型视图)5.部署视图(环境模型视图),2023/8/21,3章 统一建模语言UML,11,0.UML的视图,UML用视图来表示被建模系统的各个方面，它是在某一个抽象层次上对系统的抽象表示。UML把软件模型划分为5个视图，每一个视图代表完整系统描述的投影，显示系统的一个特定方面。每一个视图又由一种或多种图构成。一个特定视图中的图应该足

6、够简单，便于交流，而且一定要与其他图和视图连贯一致，因而所有视图结合在一起(通过各自的图)就描述了系统的完整画面。,2023/8/21,3章 统一建模语言UML,12,UML的视图,2023/8/21,3章 统一建模语言UML,13,1.用例视图(用户模型视图),由专门描述系统行为的用例组成，是从用户角度来描述系统所应具有的功能。用例视图所描述的系统功能依靠外部用户或者另一系统来激活，为用户或者另一系统提供服务，从而实现用户或另一系统与糸统的交互。系统实现的最终目标是用例视图中描述的功能。组成：用例图。使用者：客户、开发人员、测试人员。,2023/8/21,3章 统一建模语言UML,14,用例

7、视图是核心,它的内容驱动其他视图的开发。系统的最终目标，即系统将提供的功能在用例视图中描述。同时该视图还有其他一些非功能特性的描述，因此，用例视图对所有其他的视图产生影响。通过测试用例视图，可检验和最终校验系统。测试来自：客户(这是您想要的吗?)、已完成的系统(系统是按照要求的方式运作的吗?)。,2023/8/21,3章 统一建模语言UML,15,2.逻辑视图(结构模型视图),描述组成系统的类、对象以及它们之间的关系等静态结构，用来支持系统的功能需求，即描述系统内部的功能是如何设计的。使用者：开发人员、设计人员。它关注系统的内部，既描述系统的静态结构(类、对象及它们之间的关系)，也描述系统内部

8、的动态协作关系。,2023/8/21,3章 统一建模语言UML,16,逻辑视图的图形模型,对逻辑视图的描述在原则上与软件系统的实现平台无关。图形模型包括：类图、对象图、状态图、顺序图、通信图及活动图等。,2023/8/21,3章 统一建模语言UML,17,3.交互视图(行为模型视图),描述形成系统的并发与同步机制的线程和进程，关注重点是系统的性能、易伸缩性和系统的吞吐量等非功能性需求。它利用并发来描述资源的高效实用、并行执行和处理异步事件。使用者：开发人员。组成：顺序图、通信图、状态图、活动图,2023/8/21,3章 统一建模语言UML,18,4.实现视图(实现模型视图),用来描述系统的实现

9、模块、它们之间的依赖关系以及资源分配情况。主要用于系统配置管理。使用者：开发人员、系统集成人员。组成：动态图(状态图、通信图、活动图)和实现图(组件图、部署图)。,2023/8/21,3章 统一建模语言UML,19,5.部署视图(环境模型视图),描述软件系统在计算机硬件系统和网络上的安装、分发和分布情况。描述物理系统的拓扑结构。如：计算机和设备(节点)及它们之间是如何连接。使用者：开发人员、系统集成人员、测试人员组成：部署图部署视图也包括一个显示组件如何在物理结构中部署的映射，例如一个程序或对象在哪台计算机上执行。,2023/8/21,3章 统一建模语言UML,20,每种视图反映系统的一个特定

10、方面，不同人员可以单独使用其中的每一种视图，从而可以关注特定的体系结构问题。每一种UML视图都是由多个图组成的，每一种图都是体系结构某个侧面的表示。,2023/8/21,3章 统一建模语言UML,21,3.2 UML的构成,UML的体系结构 UML的模型元素 UML的模型图 UML的公用机制,3.2.1 UML的体系结构,类、接口、协作、用例、主动类、组件和节点,交互机和状态,包。整个模型可看成是一个根包，它间接包含模型中所有内容。子系统是另一种特殊的包。,给建模者提供信息，提供关于任意信息的文本说明，但没有语义作用。,2023/8/21,3章 统一建模语言UML,23,3.2.2 UML的模

11、型元素,模型元素：可以在图中使用的概念(所有包含语义的元素都是模型元素)。模型元素可以有名字。在UML图中，模型元素用其相应的符号来表示。一个模型元素可以出现在多个不同类型的图中，在不同的图中应该以何种方式出现须遵循一定的UML规则。,2023/8/21,3章 统一建模语言UML,24,模型元素的图形表示,模型元素的符号图例 关系的图示符号示例,2023/8/21,3章 统一建模语言UML,25,模型元素的符号图例,用于表示模型中的某个概念。类、对象、组(构)件、节点、用例、接口等模型元素的符号图例：,2023/8/21,3章 统一建模语言UML,26,类与对象,类是对一组具有相同属性、相同操

12、作、相同关系和相同语义对象的描述，一个类实现了一个或多个接口。在图形上，类用带有类名、属性和操作的矩形框来表示。对象是类的实例，其名字有下划线。,2023/8/21,3章 统一建模语言UML,27,组(构)件,组(构)件是系统中物理的、可替代的部件，它通常是一个描述了一些逻辑元素的物理包。在图形上，构件用一个带有小方框的矩形来表示。,2023/8/21,3章 统一建模语言UML,28,节点,是在运行时存在的物理元素。它代表一种可计算的资源，通常具有一定的记忆能力和处理能力。在图形上，节点用立方体来表示。,2023/8/21,3章 统一建模语言UML,29,用例,用例(use case)是一组动

13、作序列的描述，系统执行这些动作后将产生一个对特定参与者可以观察且有价值的结果。在图形上，用例使用一个通常仅包含其名字的实线椭圆表示。用例描述用户对系统功能的需求，所有用例合在一起构成用例模型，描述系统的功能，回答“系统应该为每个用户做什么”的问题。,2023/8/21,3章 统一建模语言UML,30,用例,是一个行为上相关的步骤序列，既可以时自动的也可以是手工的，其目的是完成一个单一的额业务任务。一个用例代表了系统的一个单一的目标，描述了为实现此目标的活动和用户交互的一个序列。用例是一种理解和记录系统需求的出色技术。一个用例本身并不是一个功能需求，但用例所讲述的故事(场景)包含了一个或多个需求

14、。,2023/8/21,3章 统一建模语言UML,31,接口,描述了一个类或组(构)件的一个服务操作集，亦即定义了元素的外部可见行为。接口定义的是一组操作的描述，而不是操作的实现。在图形上，接口用一端带有小圆圈的直线来表示，它通常依附在实现接口的类或组(构)件之上。,2023/8/21,3章 统一建模语言UML,32,关系的图示符号示例,模型元素之间的连接关系也是模型元素。关系用于表示模型元素之间相互连接的关系。常见关系：关联、聚合、组合、继承(泛化)、依赖、实现。,继承(泛化),2023/8/21,3章 统一建模语言UML,33,关联,是一种结构关系，它描述了一组链，链是用于链接对象的。关联

15、除可以具有方向外，也可以带有多重性标注和角色名这类修饰符。,2023/8/21,3章 统一建模语言UML,34,多重性标注,每个关联的复杂度或维度，称其为重数。重数：定义一个对象/类对应相关对象/类的一个实例关联可能的最小出现次数和最大出现次数。1、0.1、0.*、1.*、7.9,2023/8/21,3章 统一建模语言UML,35,聚合,整体-部分(“is part of”)聚合是一种特殊的关联，它描述了整体和部分之间的结构关系。指明一种类型的对象是另一种类型的对象的一部分。舰队、船只；项目组、成员,一门课程可与任意数目(包括0)的课程表相关，但任何一个课程表至少包括3门课程,2023/8/2

16、1,3章 统一建模语言UML,36,组合,一种强关联关系，它所描述的“部分”对象是依赖于“整体”对象的。组合可以被看作为一个特殊的聚合。,2023/8/21,3章 统一建模语言UML,37,继承(泛化),一种特殊(或一般)关系，特殊元素(子元素)的对象可以替代一般元素(父元素)的对象。子元素可以共享父元素的结构和行为。泛化表示类之间的分类关系，具有层次。,2023/8/21,3章 统一建模语言UML,38,依赖,是两个设施之间的语义关系，其中一个设施的变化会影响到另一个设施的语义，它用一条可带方向的虚线来表示。,2023/8/21,3章 统一建模语言UML,39,实现,通常在接口和实现它们的类

17、或组(构)件之间用到这种关系。,2023/8/21,3章 统一建模语言UML,40,3.2.3 UML的模型图,模型通常作为一组图呈现出来，常用的UML模型图有9种；静态结构：类图、对象图、组件图、部署图；（包图、组合结构图）动态结构：用例图、顺序图、通信图(协作图)、状态图、活动图；（时间图、交互概览图）,2023/8/21,3章 统一建模语言UML,41,UML中的静态图和动态图,2023/8/21,3章 统一建模语言UML,42,3.2.4 UML的公用机制,1.规约 2.修饰符 3.公共划分 4.扩展机制,2023/8/21,3章 统一建模语言UML,43,1.规约,在UML中，每个模

18、型元素的图形表示法之后都存在一个规约(规范说明)，它以文字的形式描述基本模型元素的语法和语义。如，在类的图符之后就有一个全面描述该类所拥有的属性、操作和行为的规约；在视图上，类的图符可能仅展示了部分规约。UML的图形表示法可视化地描述系统，而UML的规约则用来描述系统的细节。,2023/8/21,3章 统一建模语言UML,44,2.修饰,在图的模型元素上添加修饰，可为模型元素附加一定的语义。如，类的图形符号展示了类名、操作和属性这些最重要的信息。但也可以给类增添修饰符以给出类规约的细节。如，用斜体类名表示它是抽象类，用+和#表示属性和操作的可见性。在UML众多的修饰符中，注释是一种最重要的并且

19、能单独存在的修饰符，它是附加在模型元素或元素集上用来表示约束或注解信息的图形符号。,2023/8/21,3章 统一建模语言UML,45,修饰符示例,斜体类名表明这个类是一个抽象类。它有两个公共操作、一个保护操作、一个私有操作。指出priority()的算法细节在文档exe.doc中。,2023/8/21,3章 统一建模语言UML,46,3.公共划分,UML提供了事物的抽象的描绘和具体的实例两种两分法表达，被称为公共划分。对象和类使用同样的图形符号。类用长方形表示，并用名字加以标识，当类的名字带有下划线时，则它代表该类的一个对象。,2023/8/21,3章 统一建模语言UML,47,4.扩展机制

20、,衍型(构造型):对UML的词汇的扩展，用于创建与已有的模型元素相似且针对特定问题的新种类的模型元素。用书名号括起来的名字表示，其位置在其他元素之上。标记值:对UML元素的特性的扩展，用于在模型元素的规约中创建新的信息。用花括号括起来的字符串表示，其位置在其他元素之下。约束:对UML元素的语义的扩展，用于增加新规则或修改已有规则。用花括号括起来的字符串表示，且放在所关联的元素附近或通过依赖关系连接相应元素。,2023/8/21,3章 统一建模语言UML,48,扩展机制示例,衍型exception使得Overflow成为一个模型元素,EventQueue中版本和作者是标记值,add上的约束ord

21、ered使得EvenrQueue中的事件按序排列,2023/8/21,3章 统一建模语言UML,49,3.3 模型图,用例图 类图 对象图 顺序图(序列图)协作图(通信图)状态图 活动图 组件图(构件图)部署图,2023/8/21,3章 统一建模语言UML,50,用例图,用例图是把应满足用户需求的基本功能聚合起来表示的强大工具。构建用例图是通过开发者与客户（或最终使用者）共同协商完成的，他们要反复讨论需求的规格说明，达成共识，明确系统的基本功能，为以后阶段的工作打下基础。,2023/8/21,3章 统一建模语言UML,51,引入用例的主要目的是：,(2)为系统的功能提供清晰一致的描述，以便为后

22、续的开发工作打下良好的交流基础，方便开发人员传递需求的功能。,(3)为系统验证工作打下基础。通过验证最终实现的系统能够执行的功能是否与最初需求的功能相一致，保证系统的实用性。,(1)确定系统应具备哪些功能，这些功能是否满足系统的需求（开发者与用户协商达成共识的东西）。,2023/8/21,3章 统一建模语言UML,52,用例图中显示参与者、用例和用例之间的关系。用例图可以包含注释和约束，还可以包含包，用于将模型中的元素组成更大的模块。用例图如上图所示，参与者用人形图标表示，用例用椭圆符号表示，连线表示它们之间的关系。,2023/8/21,3章 统一建模语言UML,53,2.参与者,（1）参与者

23、的概念 参与者代表与系统交互的任何事物或人，它是指代表某一种特定功能的角色，因此参与者是虚拟的概念，它可以是人，也可以是外部系统或设备。,2023/8/21,3章 统一建模语言UML,54,1)第一类参与者是真实的人，即用户，是最常用的参与者，几乎存在于每一个系统中。命名这类参与者时，应当按照业务而不是位置命名，因为一个人可能有很多业务。,2023/8/21,3章 统一建模语言UML,55,2)第二类参与者是其他的系统。,3)第三类参与者是一些可以运行的进程，如时间。当经过一定时间触发系统中的某个事件时，时间就成了参与者。,2023/8/21,3章 统一建模语言UML,56,（2）确定参与者,

24、(1)谁将使用该系统的主要功能。,(2)谁将需要该系统的支持以完成其工作。,(3)谁将需要维护、管理该系统，以及保持该系统处于工作状态。,(4)与该系统交互的是什么系统。,(5)谁或什么系统对本系统产生的结果感兴趣。,2023/8/21,3章 统一建模语言UML,57,在对参与者建模的过程中，应该注意以下几点：,参与者对于系统而言总是外部的，因此它们可以处于人的控制之外。参与者可以直接或间接地同系统交互，或使用系统提供的服务以完成某件事务。参与者表示人和事物与系统发生交互时所扮演的角色，而不是特定的人或者特定的事物。一个人或事物在与系统发生交互时，可以同时或不同时扮演多个角色。每个参与者需要一

25、个具有业务一样的名字，在建模中不推荐使用类似于“新参与者”的名字。,2023/8/21,3章 统一建模语言UML,58,（3）参与者间的关系,因为参与者是类，所以多个参与者之间可以具有与类之间相同的关系。在用例图中，使用继承关系来描述多个参与者之间的公共行为。,2023/8/21,3章 统一建模语言UML,59,假设一个汽车租赁公司，接受客户的电话预定和网上预定。参与者“客户”描述了参与者“电话客户”和“网上客户”所扮演的一般角色。,2023/8/21,3章 统一建模语言UML,60,3.用例,（1）用例的概念 用例是外部可见的系统功能单元，是对系统行为的动态描述，它可以促进设计人员、开发人员

26、与用户的沟通，理解正确的需求；还可以划分系统与外部实体的界限，是系统设计的起点，是类、对象、操作的来源。,2023/8/21,3章 统一建模语言UML,61,（2）识别用例,识别用例最好的方法就是从分析系统的参与者开始，考虑每个参与者是如何使用系统的。,2023/8/21,3章 统一建模语言UML,62,通过回答以下的几个问题识别用例：,特定参与者希望系统提供什么功能。系统是否存储和检索信息，如果是，由哪个参与者触发。当系统发生改变时，是否通知参与者。是否存在影响系统的外部事件。哪个参与者通知系统这些事件。,2023/8/21,3章 统一建模语言UML,63,用例的粒度 不同的设计者设计的用例

27、的粒度不同。在建立模型时，要注意选取适中的用例粒度，以避免用例数目过多或过少。确定用例的过程是对获取的用例进行提炼和归纳的过程。,选取用例的原则：一个用例应该描述一个从头至尾的完整的功能，用例要与参与者交互。,2023/8/21,3章 统一建模语言UML,64,（3）用例的描述,一个用例是用一个命名的椭圆来表示，但如果没有对这个用例的具体说明，那么还是不清楚该用例到底会完成什么功能。对于每个用例，都可以用事件流来规定用例的行为。用例的事件流是对完成用例规定行为所需要的事件的描述。,2023/8/21,3章 统一建模语言UML,65,事件流文档的建立通常是在迭代过程的细化阶段进行，事件流的目的是

28、为用例的逻辑流程建立文档，这个文档详细描述系统用户的工作和系统本身的工作。虽然事件流很详细，但其仍然是独立于实现方法的。也就是说，事件流描述的是一个系统“做什么”，而不是“怎么做”。,2023/8/21,3章 统一建模语言UML,66,每个项目都需要一个创建事件流文档的标准模版：,X 用例XX(用例名)的事件流X.1 前提条件 X.2 后置条件 X.3 扩充点X.4 事件流X.4.1 基流X.4.2 分支流(可选)X.4.3 替代流,2023/8/21,3章 统一建模语言UML,67,（4）用例间的关系,1）继承关系 用例间的继承关系如同类间的继承关系。,用例“汽车预定”有两个子用例“电话预定

29、”“网上预定”。这两个用例都继承了父用例的行为，并添加了自己的行为。,2023/8/21,3章 统一建模语言UML,68,2）包含关系 一个用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为作为自身行为的一部分，这被称作包含关系。在UML中，包含关系为虚线箭头加include字样，箭头指向被包含的用例。,2023/8/21,3章 统一建模语言UML,69,本例中，“填写电子表格”的功能在“网上预定”过程中使用，不管如何处理“网上预定”用例，总是要运行“填写电子表格”用例，因此具有包含关系。,2023/8/21,3章 统一建模语言UML,70,3）扩充关系,一个用例可以被定义为基础用例

30、的增量扩充，这称作扩充关系，扩充关系是把新的行为插入到已有用例中的方法。同一个基础用例的几个扩充用例可以在一起应用。基础用例提供了一组扩充点，在这些新的扩充点中可以添加新的行为，而扩充用例提供了一组插入片断，这些片断能够被插入到基础用例的扩充点上。,2023/8/21,3章 统一建模语言UML,71,基础用例不必知道扩充用例的任何细节，它仅为其提供扩充点。事实上，基础用例即使没有扩充用例也是完整的，这点与包含关系有所不同。一个用例可能有多个扩充点，每个扩充点也可以出现多次。但是一般情况下，基础用例的执行不会涉及到扩充用例，只有特定的条件发生，扩充用例才被执行。扩充关系为处理异常或构建灵活的系统

31、框架提供了一种十分有效的方法。,2023/8/21,3章 统一建模语言UML,72,在UML中，扩充关系表示为虚线箭头加extend字样，箭头指向被扩展的用例（基础用例）。,本例中，基础用例是“还车”，扩充用例是“交纳罚金”。如果一切顺利汽车可以被归还，那么执行“还车”用例即可。但是如果超过了还车的时间或汽车受损，按规定客户要交纳一定的罚金，这就不能执行用例提供的常规动作。,2023/8/21,3章 统一建模语言UML,73,思考：,假设有这样的需求，在学生档案管理中，管理员经常需要做3件事：增加一条学生记录、修改一条学生记录、删除一条学生记录。如果要画出用例图，下面哪种方法更合适？,A,B,

32、2023/8/21,3章 统一建模语言UML,74,这种类型的问题在进行用例分析时会经常遇到，也被称为CRUD(create,retrieve,update,delete)问题。从捕获用户需求的角度考虑，建议采用A方法。采用B方法的一个主要问题是限制了分析人员的思路。虽然从用例图可以发现，对学生记录的操作有增加、修改和删除，但事实上，用户的这些操作都是对学生记录的管理。解决CRUD问题的要点是从用户需求的角度考虑，而不要从数据处理的角度考虑，这样就不会得到类似方法B中的用例图了。,2023/8/21,3章 统一建模语言UML,75,3.3.2 类图,用于描述一组类、接口、协作及它们间的静态关系

33、(即系统的对象结构，显示构成系统的对象类，以及那些对象类间的关系)。在OO系统的建模中，类图最为常用，它用来阐明系统的静态结构。类是对一组具有相同属性、操作、关系和语义的对象的描述，其中对类的属性和操作进行描述时的一个最重要的细节是它的可见性。,2023/8/21,3章 统一建模语言UML,76,1.类,类是面向对象系统组织结构的核心。类是对一组具有相同属性、操作、关系和语义的对象的描述。这些对象包括了现实世界中的物理实体、商业事物、逻辑事务、应用事物和行为事物等，甚至也包括了纯粹概念性的事物，它们都是类的实例。,2023/8/21,3章 统一建模语言UML,77,类的UML符号表示如下图所示

34、，即类用矩形表示，并且该矩形被划分为3个部分：名称部分、属性部分、操作部分。顶端的部分存放类的名称，中间的部分放类的属性、属性的类型及其值，底部的部分存放类的操作、操作的参数表和返回类型。,2023/8/21,3章 统一建模语言UML,78,（1）名称,类的名称应该来自系统的问题域，并且类的名称应该是一个名词。类的名称可以分为简单名称和路径名称。单独的名称即不包含冒号的字符串叫做简单名；用类所在的包的名称作为前缀的类名叫做路径名。,2023/8/21,3章 统一建模语言UML,79,（2）属性,一个类可以有一个或多个属性或者根本没有属性。属性描述了为类的所有对象所共有的特性。,属性的选取应考虑

35、下列因素：原则上，类的属性应能描述并区分每个特定的对象。只有与系统有关的特性才包含在类的属性中。,2023/8/21,3章 统一建模语言UML,80,类属性的语法为：,可见性：属性可以具有不同的可见性。类中属性的可见性主要包括公有(Public)、私有(Private)和受保护(Protected)3种。在UML中分别表示为“”“”“”。,2023/8/21,3章 统一建模语言UML,81,（3）操作,一个类可以有任何数量的操作或根本没有操作。操作是类的所有对象所共有的行为的抽象。操作用于修改、检索类的属性或执行某些动作。操作通常也被称为功能或方法，但是它们被约束在类的内部，只能作用到该类的对

36、象上。,2023/8/21,3章 统一建模语言UML,82,UML规定操作的语法为：,可见性：类的操作的可见性主要包括公有(Public)“”；私有(Private)“”；受保护(Protected)“”。,2023/8/21,3章 统一建模语言UML,83,2.类之间的关系,类之间的关系最常用的有4种，分别是表示类之间使用关系的依赖关系；表示类之间一般和特殊关系的类属关系；表示对象之间结构关系的关联关系；表示类中规格说明和实现之间关系的实现关系。,2023/8/21,3章 统一建模语言UML,84,2023/8/21,3章 统一建模语言UML,85,UML中有3种主要的类原型，分别是边界类、

37、控制类和实体类。在进行面向对象分析和设计时，如何确定系统中的类是一个比较困难的工作，引入边界类、控制类和实体类的概念有助于分析和设计人员确定系统中的类。,3.边界类、控制类、实体类,2023/8/21,3章 统一建模语言UML,86,（1）边界类(boundary class)边界类位于系统与外界的交界处，用于处理系统与外界的通信。窗体、对话框、报表以及表示通讯协议的类、直接与外部设备交互的类、直接与外部系统交互的类等都是边界类的例子。,2023/8/21,3章 统一建模语言UML,87,（2）控制类(control class),控制类是负责其他类工作的类。每个用例通常有一个控制类，控制用例

38、中的事件顺序，控制类也可在多个用例间共用。其他类并不向控制类发送很多消息，而是由控制类发出很多消息。,2023/8/21,3章 统一建模语言UML,88,（3）实体类(entity class),实体类保存要放进持久存储体的信息。持久存储体就是数据库、文件等可以永久存储数据的介质。通常每个实体类在数据库中有相应的表，实体类中的属性对应数据库中表的字段。但这并不意味着实体类和数据库中的表是一一对应的。,2023/8/21,3章 统一建模语言UML,89,4.类图的划分,虽然在软件开发的不同阶段都使用类图，但这些类图描述了不同层次的抽象。类图分为3个层次：概念层、说明层和实现层。,2023/8/2

39、1,3章 统一建模语言UML,90,概念层类图描述应用领域中的概念，一般这些概念和类有很自然的联系，但两者并没有直接的映射关系。说明层类图描述软件的接口部分，而不是软件的实现部分。这个接口可能因为实现环境、运行特性或者开发商的不同而有多种不同的实现。实现层类图真正考虑类的实现问题，提供类的实现细节。,2023/8/21,3章 统一建模语言UML,91,下图所示是一个类Circle的3个不同层次的情况：,从图中可以看出，概念层类图只有一个类名，说明层类图有类名、属性名和方法名，但对属性没有类型的说明，对方法的参数和返回类型也没有指明，实现层类图则对类的属性和方法都有详细的说明。,2023/8/2

40、1,3章 统一建模语言UML,92,5.类图的构造,根据用例描述中的名词确定类的候选者。根据边界类、控制类和实体类的划分来帮助发现系统中的类。对领域进行分析，或利用已有的领域分析结果得到类。参考设计模式来确定类。根据某些软件开发过程提供的指导原则进行寻找类的工作。,2023/8/21,3章 统一建模语言UML,93,对象图,对象图是类图的实例，用来描述特定运行时刻一组对象间的关系。对象图用于描述交互的静态部分，它由参与协作的有关对象组成，但不包括在对象之间传递的任何消息。对象图为开发人员提供对象在某个时间点上的“快照”，不像类图经常使用，但能帮助开发人员更好的理解系统结构在创建对象图时，建模人

41、员可以选取所感兴趣的对象及其之间的关系来描述。,2023/8/21,3章 统一建模语言UML,94,对象图中的建模元素有对象和链(link)。对象是类的实例，对象之间的链是类之间的关联关系的实例。对象图可以看作是类图的一个实例。,对象图的建模元素,2023/8/21,3章 统一建模语言UML,95,类图和对象图的区别,2023/8/21,3章 统一建模语言UML,96,3.3.4 顺序图(时序图),顺序图表示对象间传送消息的时间顺序。顺序图用来描述对象之间消息发送的先后次序，阐明对象之间的交互过程以及在系统执行过程中的某一具体时刻将会发生什么事件。是一种强调时间顺序的交互图，可用来进行一个场景

42、说明，即一个事务的历史过程。,2023/8/21,3章 统一建模语言UML,97,在时序图中的水平方向为对象维，沿水平方向排列的是参与交互的对象。时序图的垂直方向为时间维，沿垂直向下方向按时间递增顺序列出各对象所发出和接收的消息。,在UML中，时序图将交互关系表示为一个二维图。,2023/8/21,3章 统一建模语言UML,98,时序图中包括的建模元素有：对象(参与者实例也是对象)、生命线(lifeline)、控制焦点(focus of control,FOC)、消息(message)等。,2023/8/21,3章 统一建模语言UML,99,其中垂直虚线是对象的生命线，用于表示在某段时间内对象

43、是存在的。,时序图中的对象用一个带有垂直虚线的矩形框表示。下图表示了三种不同的命名方式。,（1）对象,2023/8/21,3章 统一建模语言UML,100,控制焦点是时序图中表示时间段的符号，在这个时间段内，对象将执行相应的操作。控制焦点表示为生命线上的小矩形。,（2）控制焦点,2023/8/21,3章 统一建模语言UML,101,消息用从一个对象的生命线到另一个对象生命线的直线箭头表示。箭头实线以时间顺序在图中从上到下排列。,消息在生命线上所处的位置并不是消息发生的准确时间，只是一个相对的位置。如果一个消息位于另一个消息的上方，只说明它先于另一个消息被发送。,（3）消息,消息是从一个对象（发

44、送者）向另一个或几个对象（接收者）发送信号，或由一个对象（发送者或调用者）调用另一个对象（接收者）的操作。,2023/8/21,3章 统一建模语言UML,102,对象的创建和撤销,时序图中对象的默认位置是在图的顶部，如果对象在这个位置上，说明对象在交互开始之前已经存在了。如果对象是在交互过程中创建的，那么应当位于图的中间部分。,2023/8/21,3章 统一建模语言UML,103,如果要撤销一个对象，只要在其生命线终止点放置一个“”符号即可，该点通常是对删除或取消消息的回应。,2023/8/21,3章 统一建模语言UML,104,2023/8/21,3章 统一建模语言UML,105,3.3.5

45、 通信图(协作图),通信图也是一种交互图，它强调收发消息的对象的组织结构。通信图描述对象间的协作关系(与顺序图相似)，显示对象间的动态合作关系。通信图包含3个建模元素：对象(object)、链(link)、消息(message)。,2023/8/21,3章 统一建模语言UML,106,（1）对象,通信图与时序图中对象的概念是一样的，只不过在通信图中，无法像时序图一样表示对象的创建和撤销，所以对象在图中的位置没有限制。,如下图所示，图中的矩形代表的就是对象：,2023/8/21,3章 统一建模语言UML,107,多对象：由多个对象组成的对象集合，一般这些对象是属于同一个类的。当需要把消息同时发给

46、多个对象时，使用这个概念。在通信图中，多对象用多个方框的重叠表示。,2023/8/21,3章 统一建模语言UML,108,（2）链,通信图中用链(link)来连接对象，而消息显示在链的旁边，一个链上可以有多个消息。,2023/8/21,3章 统一建模语言UML,109,（3）消息,通信图中的消息类型与时序图中的相同，只不过为了说明交互过程中消息的时间顺序，需要给消息添加顺序号。顺序号是消息的一个数字前缀，是一个整数，由1开始递增，每个消息都必须有唯一的顺序号。,2023/8/21,3章 统一建模语言UML,110,2023/8/21,3章 统一建模语言UML,111,时序图与通信图的比较,时序

47、图和通信图都属于交互作用图，都用于描述系统中对象之间的动态关系。两者可以相互转换，但两者强调的重点不同。时序图强调的是消息的时间顺序，而通信图强调的是参与交互的对象的组织。在两个图所使用的建模元素上，两者也有各自的特点。时序图中有对象生命线和控制焦点，通信图中没有；通信图中有链，并且通信图中的消息必须要有消息顺序号，但时序图中没有这两个特征。,2023/8/21,3章 统一建模语言UML,112,3.3.6 状态图,状态视图是一个类对象所经历的所有历程的模型图。状态由对象的各个状态和连接这些状态的变迁组成。每个状态对一个对象在其生命周期中满足某种条件的一个时间段建模。当一个事件发生时，它会触发

48、状态间的变迁，导致对象从一种状态转化到另一种新的状态。与变迁相关的活动执行时，变迁也同时发生。状态用状态图来表达。在UML中,状态图可用来对一个对象按事件排序的行为建模(建模特定对象的动态行为,说明对象的生命周期)。,2023/8/21,3章 统一建模语言UML,113,2023/8/21,3章 统一建模语言UML,114,状态,状态图中的状态用圆角矩形表示，它由状态名、状态变量和状态活动3部分组成。一般而言，状态变量部分是可以省略的，状态的活动部分由入口动作、出口动作、内部跃迁、延迟事件、内部活动、子状态构成。,2023/8/21,3章 统一建模语言UML,115,入口动作,内部活动,内部跃

49、迁,出口动作,延迟事件,状态的名字是Lighting。当进入这个状态时，做开灯(turnOn)动作，离开这个状态时，做关灯(turnOff)动作，当对象处于这个状态时，灯要闪烁5次(blinkFivetimes)，当电源关闭(powerOff)事件出现时，使用自供应电源(powerSupplySelf)。需要注意的是，对象在Lighting状态时，有一个被延迟处理的事件，即当出现自检(selfTest)事件时，对象将延迟响应这个事件。即不在Lighting这个状态中处理这个事件，而是延迟到以后在别的状态中处理这个事件。,2023/8/21,3章 统一建模语言UML,116,（1）入口/出口动作

50、 入口动作和出口动作表示进入或退出某个状态所要执行的动作。入口动作用“entry/要执行的动作”表达，而出口动作用“exit/要执行的动作”表达。,2023/8/21,3章 统一建模语言UML,117,（2）内部跃迁 内部跃迁是没有引起状态变化的跃迁。也就是建模人员有时候需要在不离开一个状态的情况下处理一些事情，内部跃迁和自跃迁不同。在自跃迁中，跃迁首先离开状态，然后再重新进入同一个状态；而内部跃迁根本没有离开状态。自跃迁在离开状态时会执行状态的出口动作，在跃迁时会执行自跃迁动作，在重新进入状态时执行状态入口动作；而内部跃迁由于没有离开状态，不需要执行出口和入口动作，只需要执行内部跃迁动作。,