用例图画法举例.pptx

《用例图画法举例.pptx》由会员分享，可在线阅读，更多相关《用例图画法举例.pptx（172页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、23 二月 20231/172本章内容本章内容3.1 UML概述 3.2 UML的构成 3.3 UML的图3.4 UML的工具软件要点回顾第1页/共172页23 二月 20232/1723.1 UML概述概述3.1.1 UML的产生背景 3.1.2 什么是UML 3.1.3 UML中的视图第2页/共172页23 二月 20233/1723.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(面向对象模型技术)第3页/共172页23 二月 20234/172 UML被被OMG采纳为标准采纳为标准UML的三位创始人设计出一种能被软件开发工具提供者、软件开发方法学家和开发人员这些最终用户所接受的建模语言。1997年9月他们向OMG提交了UML方法。1997年11月，UML被OMG全体成员一致通过，并被

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

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

5、晰，可视化、表示能力强大，容易掌握和使用。独立于过程：UML不依赖于特定的软件开发过程。第8页/共172页23 二月 20239/1723.1.3 UML中的视图中的视图0.UML的视图1.用例视图(用户模型视图)2.逻辑视图(结构模型视图)3.交互视图(行为模型视图)4.实现视图(实现模型视图)5.部署视图(环境模型视图)第9页/共172页23 二月 202310/1720.UML的视图的视图UML用视图来表示被建模系统的各个方面，它是在某一个抽象层次上对系统的抽象表示。UML把软件模型划分为5个视图，每一个视图代表完整系统描述的投影，显示系统的一个特定方面。每一个视图又由一种或多种图构成。

6、一个特定视图中的图应该足够简单，便于交流，而且一定要与其他图和视图连贯一致，因而所有视图结合在一起(通过各自的图)就描述了系统的完整画面。第10页/共172页23 二月 202311/172UML的视图的视图 逻辑(结构)视图实现视图部署(环境)视图交互(行为)视图用例(用户)视图性能、稳定性、吞吐率系统拓扑、分布、安装设计词汇、功能描述系统组装、配置管理第11页/共172页23 二月 202312/1721.用例视图用例视图(用户模型视图用户模型视图)由专门描述系统行为的用例组成，是从用户角度来描述系统所应具有的功能。用例视图所描述的系统功能依靠外部用户或者另一系统来激活，为用户或者另一系统

7、提供服务，从而实现用户或另一系统与糸统的交互。系统实现的最终目标是用例视图中描述的功能。组成：用例图。使用者：客户、开发人员、测试人员。第12页/共172页23 二月 202313/172用例视图是核心用例视图是核心它的内容驱动其他视图的开发。系统的最终目标，即系统将提供的功能在用例视图中描述。同时该视图还有其他一些非功能特性的描述，因此，用例视图对所有其他的视图产生影响。通过测试用例视图，可检验和最终校验系统。测试来自：客户(这是您想要的吗?)、已完成的系统(系统是按照要求的方式运作的吗?)。第13页/共172页23 二月 202314/1722.逻辑视图逻辑视图(结构模型视图结构模型视图)

8、描述组成系统的类、对象以及它们之间的关系等静态结构，用来支持系统的功能需求，即描述系统内部的功能是如何设计的。使用者：开发人员、设计人员。它关注系统的内部，既描述系统的静态结构(类、对象及它们之间的关系)，也描述系统内部的动态协作关系。第14页/共172页23 二月 202315/172逻辑视图的图形模型逻辑视图的图形模型对逻辑视图的描述在原则上与软件系统的实现平台无关。图形模型包括：类图、对象图、状态图、顺序图、通信图及活动图等。第15页/共172页23 二月 202316/1723.交互视图交互视图(行为模型视图行为模型视图)描述形成系统的并发与同步机制的线程和进程，关注重点是系统的性能、

9、易伸缩性和系统的吞吐量等非功能性需求。它利用并发来描述资源的高效实用、并行执行和处理异步事件。使用者：开发人员。组成：顺序图、通信图、状态图、活动图第16页/共172页23 二月 202317/1724.实现视图实现视图(实现模型视图实现模型视图)用来描述系统的实现模块、它们之间的依赖关系以及资源分配情况。主要用于系统配置管理。使用者：开发人员、系统集成人员。组成：动态图(状态图、通信图、活动图)和实现图(组件图、部署图)。第17页/共172页23 二月 202318/1725.部署视图部署视图(环境模型视图环境模型视图)描述软件系统在计算机硬件系统和网络上的安装、分发和分布情况。描述物理系统

10、的拓扑结构。如：计算机和设备(节点)及它们之间是如何连接。使用者：开发人员、系统集成人员、测试人员组成：部署图部署视图也包括一个显示组件如何在物理结构中部署的映射，例如一个程序或对象在哪台计算机上执行。第18页/共172页23 二月 202319/172每种视图反映系统的一个特定方面，不同人员可以单独使用其中的每一种视图，从而可以关注特定的体系结构问题。每一种UML视图都是由多个图组成的，每一种图都是体系结构某个侧面的表示。第19页/共172页23 二月 202320/1723.2 UML的的构成构成3.2.1 UML的体系结构 3.2.2 UML的模型元素 3.2.3 UML的模型图 3.2

11、.4 UML的公用机制第20页/共172页3.2.1 UML的体系结构的体系结构类、接口、协作、用例、主动类、组件和节点 交互机和状态 包。整个模型可看成是一个根包，它间接包含模型中所有内容。子系统是另一种特殊的包。给建模者提供信息，提供关于任意信息的文本说明，但没有语义作用。第21页/共172页23 二月 202322/1723.2.2 UML的模型元素的模型元素模型元素：可以在图中使用的概念(所有包含语义的元素都是模型元素)。模型元素可以有名字。在UML图中，模型元素用其相应的符号来表示。一个模型元素可以出现在多个不同类型的图中，在不同的图中应该以何种方式出现须遵循一定的UML规则。第22

12、页/共172页23 二月 202323/172模型元素的图形表示模型元素的图形表示模型元素的符号图例关系的图示符号示例第23页/共172页23 二月 202324/172模型元素的符号图例模型元素的符号图例用于表示模型中的某个概念。类、对象、组(构)件、节点、用例、接口等模型元素的符号图例：第24页/共172页23 二月 202325/172类与对象类与对象类是对一组具有相同属性、相同操作、相同关系和相同语义对象的描述，一个类实现了一个或多个接口。在图形上，类用带有类名、属性和操作的矩形框来表示。对象是类的实例，其名字有下划线。第25页/共172页23 二月 202326/172组组(构构)件

13、件组(构)件是系统中物理的、可替代的部件，它通常是一个描述了一些逻辑元素的物理包。在图形上，构件用一个带有小方框的矩形来表示。第26页/共172页23 二月 202327/172节点节点是在运行时存在的物理元素。它代表一种可计算的资源，通常具有一定的记忆能力和处理能力。在图形上，节点用立方体来表示。第27页/共172页23 二月 202328/172用例用例用例(use case)是一组动作序列的描述，系统执行这些动作后将产生一个对特定参与者可以观察且有价值的结果。在图形上，用例使用一个通常仅包含其名字的实线椭圆表示。用例描述用户对系统功能的需求，所有用例合在一起构成用例模型，描述系统的功能，

14、回答“系统应该为每个用户做什么”的问题。第28页/共172页23 二月 202329/172用例用例是一个行为上相关的步骤序列，既可以时自动的也可以是手工的，其目的是完成一个单一的额业务任务。一个用例代表了系统的一个单一的目标，描述了为实现此目标的活动和用户交互的一个序列。用例是一种理解和记录系统需求的出色技术。一个用例本身并不是一个功能需求，但用例所讲述的故事(场景)包含了一个或多个需求。第29页/共172页23 二月 202330/172接口接口描述了一个类或组(构)件的一个服务操作集，亦即定义了元素的外部可见行为。接口定义的是一组操作的描述，而不是操作的实现。在图形上，接口用一端带有小圆

15、圈的直线来表示，它通常依附在实现接口的类或组(构)件之上。第30页/共172页23 二月 202331/172关系的图示符号示例关系的图示符号示例 模型元素之间的连接关系也是模型元素。关系用于表示模型元素之间相互连接的关系。常见关系：关联、聚合、组合、继承(泛化)、依赖、实现。继承继承(泛化泛化)第31页/共172页23 二月 202332/172关联关联是一种结构关系，它描述了一组链，链是用于链接对象的。关联除可以具有方向外，也可以带有多重性标注和角色名这类修饰符。Professor Student 0.*1Project Employee 0.*0.1学生计算机 *1使用第32页/共172

16、页23 二月 202333/172多重性标注多重性标注每个关联的复杂度或维度，称其为重数。重数：定义一个对象/类对应相关对象/类的一个实例关联可能的最小出现次数和最大出现次数。1、0.1、0.*、1.*、7.9第33页/共172页23 二月 202334/172聚合聚合整体-部分(“is part of”)聚合是一种特殊的关联，它描述了整体和部分之间的结构关系。指明一种类型的对象是另一种类型的对象的一部分。舰队、船只；项目组、成员CarWheel0.14ProgramCourse0.*3.*一门课程可与任意数目(包括0)的课程表相关，但任何一个课程表至少包括3门课程第34页/共172页23 二

17、月 202335/172组合组合一种强关联关系，它所描述的“部分”对象是依赖于“整体”对象的。组合可以被看作为一个特殊的聚合。BuildingRoom1*第35页/共172页23 二月 202336/172继承继承(泛化泛化)一种特殊(或一般)关系，特殊元素(子元素)的对象可以替代一般元素(父元素)的对象。子元素可以共享父元素的结构和行为。泛化表示类之间的分类关系，具有层次。两栖动物哺乳动物爬行动物马牛羊动物第36页/共172页23 二月 202337/172依赖依赖是两个设施之间的语义关系，其中一个设施的变化会影响到另一个设施的语义，它用一条可带方向的虚线来表示。课程计划增加(课程X)删除(

18、课程X)课程第37页/共172页23 二月 202338/172实现实现通常在接口和实现它们的类或组(构)件之间用到这种关系。第38页/共172页23 二月 202339/1723.2.3 UML的模型图的模型图模型通常作为一组图呈现出来，常用的UML模型图有9种；静态结构：类图、对象图、组件图、部署图；（包图、组合结构图）动态结构：用例图、顺序图、通信图(协作图)、状态图、活动图；（时间图、交互概览图）第39页/共172页23 二月 202340/172UML中的静态图和动态图中的静态图和动态图用例图用例图顺序图顺序图第40页/共172页23 二月 202341/1723.2.4 UML的公

19、用机制的公用机制 1.规约 2.修饰符 3.公共划分 4.扩展机制第41页/共172页23 二月 202342/1721.规约规约在UML中，每个模型元素的图形表示法之后都存在一个规约(规范说明)，它以文字的形式描述基本模型元素的语法和语义。如，在类的图符之后就有一个全面描述该类所拥有的属性、操作和行为的规约；在视图上，类的图符可能仅展示了部分规约。UML的图形表示法可视化地描述系统，而UML的规约则用来描述系统的细节。第42页/共172页23 二月 202343/1722.修饰修饰在图的模型元素上添加修饰，可为模型元素附加一定的语义。如，类的图形符号展示了类名、操作和属性这些最重要的信息。但

20、也可以给类增添修饰符以给出类规约的细节。如，用斜体类名表示它是抽象类，用+和#表示属性和操作的可见性。在UML众多的修饰符中，注释是一种最重要的并且能单独存在的修饰符，它是附加在模型元素或元素集上用来表示约束或注解信息的图形符号。第43页/共172页23 二月 202344/172修饰符示例修饰符示例斜体类名表明这个类是一个抽象类。它有两个公共操作、一个保护操作、一个私有操作。指出priority()的算法细节在文档exe.doc中。第44页/共172页23 二月 202345/1723.公共划分公共划分UML提供了事物的抽象的描绘和具体的实例两种两分法表达，被称为公共划分。对象和类使用同样的

21、图形符号。类用长方形表示，并用名字加以标识，当类的名字带有下划线时，则它代表该类的一个对象。第45页/共172页23 二月 202346/1724.扩展机制扩展机制衍型(构造型):对UML的词汇的扩展，用于创建与已有的模型元素相似且针对特定问题的新种类的模型元素。用书名号括起来的名字表示，其位置在其他元素之上。标记值:对UML元素的特性的扩展，用于在模型元素的规约中创建新的信息。用花括号括起来的字符串表示，其位置在其他元素之下。约束:对UML元素的语义的扩展，用于增加新规则或修改已有规则。用花括号括起来的字符串表示，且放在所关联的元素附近或通过依赖关系连接相应元素。第46页/共172页23 二

22、月 202347/172扩展机制示例扩展机制示例 衍型exception使得Overflow成为一个模型元素EventQueue中版本和作者是标记值add上的约束ordered使得EvenrQueue中的事件按序排列第47页/共172页23 二月 202348/1723.3 模型模型图图3.3.1 用例图3.3.2 类图 3.3.3 对象图3.3.4 顺序图(序列图)3.3.5 协作图(通信图)3.3.6 状态图 3.3.7 活动图 3.3.8 组件图(构件图)3.3.9 部署图 第48页/共172页23 二月 202349/1723.3.1用例图用例图 用例图是把应满足用户需求的基本功能聚合

23、起来表示的强大工具。构建用例图是通过开发者与客户（或最终使用者）共同协商完成的，他们要反复讨论需求的规格说明，达成共识，明确系统的基本功能，为以后阶段的工作打下基础。第49页/共172页23 二月 202350/172引入用例的主要目的是：引入用例的主要目的是：(2)为系统的功能提供清晰一致的描述，以便为后续的开发工作打下良好的交流基础，方便开发人员传递需求的功能。(3)为系统验证工作打下基础。通过验证最终实现的系统能够执行的功能是否与最初需求的功能相一致，保证系统的实用性。(1)确定系统应具备哪些功能，这些功能是否满足系统的需求（开发者与用户协商达成共识的东西）。第50页/共172页23 二

24、月 202351/172 用例图中显示参与者、用例和用例之间的关系。用例图可以包含注释和约束，还可以包含包，用于将模型中的元素组成更大的模块。用例图如上图所示，参与者用人形图标表示，用例用椭圆符号表示，连线表示它们之间的关系。第51页/共172页23 二月 202352/1722.参与者参与者（1）参与者的概念参与者代表与系统交互的任何事物或人，它是指代表某一种特定功能的角色，因此参与者是虚拟的概念，它可以是人，也可以是外部系统或设备。第52页/共172页23 二月 202353/1721)第一类参与者是真实的人，即用户，是最常用的参与者，几乎存在于每一个系统中。命名这类参与者时，应当按照业务

25、而不是位置命名，因为一个人可能有很多业务。第53页/共172页23 二月 202354/1722)第二类参与者是其他的系统。3)第三类参与者是一些可以运行的进程，如时间。当经过一定时间触发系统中的某个事件时，时间就成了参与者。第54页/共172页23 二月 202355/172（2）确定参与者）确定参与者(1)谁将使用该系统的主要功能。(2)谁将需要该系统的支持以完成其工作。(3)谁将需要维护、管理该系统，以及保持该系统处于工作状态。(4)与该系统交互的是什么系统。(5)谁或什么系统对本系统产生的结果感兴趣。第55页/共172页23 二月 202356/172在对参与者建模的过程中，应该注意以

26、下几点：在对参与者建模的过程中，应该注意以下几点：参与者对于系统而言总是外部的，因此它们可以处于人的控制之外。参与者可以直接或间接地同系统交互，或使用系统提供的服务以完成某件事务。参与者表示人和事物与系统发生交互时所扮演的角色，而不是特定的人或者特定的事物。一个人或事物在与系统发生交互时，可以同时或不同时扮演多个角色。每个参与者需要一个具有业务一样的名字，在建模中不推荐使用类似于“新参与者”的名字。第56页/共172页23 二月 202357/172（3）参与者间的关系）参与者间的关系 因为参与者是类，所以多个参与者之间可以具有与类之间相同的关系。在用例图中，使用继承关系来描述多个参与者之间的

27、公共行为。第57页/共172页23 二月 202358/172 假设一个汽车租赁公司，接受客户的电话预定和网上预定。参与者“客户”描述了参与者“电话客户”和“网上客户”所扮演的一般角色。第58页/共172页23 二月 202359/1723.用例用例（1）用例的概念用例是外部可见的系统功能单元，是对系统行为的动态描述，它可以促进设计人员、开发人员与用户的沟通，理解正确的需求；还可以划分系统与外部实体的界限，是系统设计的起点，是类、对象、操作的来源。第59页/共172页23 二月 202360/172（2）识别用例）识别用例 识别用例最好的方法就是从分析系统的参与者开始，考虑每个参与者是如何使用

28、系统的。第60页/共172页23 二月 202361/172通过回答以下的几个问题识别用例：通过回答以下的几个问题识别用例：特定参与者希望系统提供什么功能。系统是否存储和检索信息，如果是，由哪个参与者触发。当系统发生改变时，是否通知参与者。是否存在影响系统的外部事件。哪个参与者通知系统这些事件。第61页/共172页23 二月 202362/172 用例的粒度 不同的设计者设计的用例的粒度不同。在建立模型时，要注意选取适中的用例粒度，以避免用例数目过多或过少。确定用例的过程是对获取的用例进行提炼和归纳的过程。选取用例的原则：一个用例应该描述一个从头至尾的完整的功能，用例要与参与者交互。第62页/

29、共172页23 二月 202363/172（3）用例的描述）用例的描述 一个用例是用一个命名的椭圆来表示，但如果没有对这个用例的具体说明，那么还是不清楚该用例到底会完成什么功能。对于每个用例，都可以用事件流来规定用例的行为。用例的事件流是对完成用例规定行为所需要的事件的描述。第63页/共172页23 二月 202364/172 事件流文档的建立通常是在迭代过程的细化阶段进行，事件流的目的是为用例的逻辑流程建立文档，这个文档详细描述系统用户的工作和系统本身的工作。虽然事件流很详细，但其仍然是独立于实现方法的。也就是说，事件流描述的是一个系统“做什么”，而不是“怎么做”。第64页/共172页23

30、二月 202365/172 每个项目都需要一个创建事件流文档的标准模版：每个项目都需要一个创建事件流文档的标准模版：X 用例XX(用例名)的事件流X.1 前提条件 X.2 后置条件 X.3 扩充点X.4 事件流X.4.1 基流X.4.2 分支流(可选)X.4.3 替代流第65页/共172页23 二月 202366/172（4）用例间的关系）用例间的关系 1）继承关系 用例间的继承关系如同类间的继承关系。用例“汽车预定”有两个子用例“电话预定”“网上预定”。这两个用例都继承了父用例的行为，并添加了自己的行为。第66页/共172页23 二月 202367/1722）包含关系 一个用例可以简单地包含

31、其他用例具有的行为，并把它所包含的用例行为作为自身行为的一部分，这被称作包含关系。在UML中，包含关系为虚线箭头加include字样，箭头指向被包含的用例。第67页/共172页23 二月 202368/172 本例中，“填写电子表格”的功能在“网上预定”过程中使用，不管如何处理“网上预定”用例，总是要运行“填写电子表格”用例，因此具有包含关系。第68页/共172页23 二月 202369/1723）扩充关系）扩充关系 一个用例可以被定义为基础用例的增量扩充，这称作扩充关系，扩充关系是把新的行为插入到已有用例中的方法。同一个基础用例的几个扩充用例可以在一起应用。基础用例提供了一组扩充点，在这些新

32、的扩充点中可以添加新的行为，而扩充用例提供了一组插入片断，这些片断能够被插入到基础用例的扩充点上。第69页/共172页23 二月 202370/172 基础用例不必知道扩充用例的任何细节，它仅为其提供扩充点。事实上，基础用例即使没有扩充用例也是完整的，这点与包含关系有所不同。一个用例可能有多个扩充点，每个扩充点也可以出现多次。但是一般情况下，基础用例的执行不会涉及到扩充用例，只有特定的条件发生，扩充用例才被执行。扩充关系为处理异常或构建灵活的系统框架提供了一种十分有效的方法。第70页/共172页23 二月 202371/172 在 UML中，扩 充 关 系 表 示 为 虚 线 箭 头 加ext

33、end字样，箭头指向被扩展的用例（基础用例）。本例中，基础用例是“还车”，扩充用例是“交纳罚金”。如果一切顺利汽车可以被归还，那么执行“还车”用例即可。但是如果超过了还车的时间或汽车受损，按规定客户要交纳一定的罚金，这就不能执行用例提供的常规动作。第71页/共172页23 二月 202372/172思考：思考：假设有这样的需求，在学生档案管理中，管理员经常需要做3件事：增加一条学生记录、修改一条学生记录、删除一条学生记录。如果要画出用例图，下面哪种方法更合适？AB第72页/共172页23 二月 202373/172 这种类型的问题在进行用例分析时会经常遇到，也被称为CRUD(create,re

34、trieve,update,delete)问题。从捕获用户需求的角度考虑，建议采用A方法。采用B方法的一个主要问题是限制了分析人员的思路。虽然从用例图可以发现，对学生记录的操作有增加、修改和删除，但事实上，用户的这些操作都是对学生记录的管理。解决CRUD问题的要点是从用户需求的角度考虑，而不要从数据处理的角度考虑，这样就不会得到类似方法B中的用例图了。第73页/共172页23 二月 202374/1723.3.2 类图类图用于描述一组类、接口、协作及它们间的静态关系(即系统的对象结构，显示构成系统的对象类，以及那些对象类间的关系)。在OO系统的建模中，类图最为常用，它用来阐明系统的静态结构。类

35、是对一组具有相同属性、操作、关系和语义的对象的描述，其中对类的属性和操作进行描述时的一个最重要的细节是它的可见性。第74页/共172页23 二月 202375/1721.1.类类 类是面向对象系统组织结构的核心。类是对一组具有相同属性、操作、关系和语义的对象的描述。这些对象包括了现实世界中的物理实体、商业事物、逻辑事务、应用事物和行为事物等，甚至也包括了纯粹概念性的事物，它们都是类的实例。第75页/共172页23 二月 202376/172类的UML符号表示如下图所示，即类用矩形表示，并且该矩形被划分为3个部分：名称部分、属性部分、操作部分。顶端的部分存放类的名称，中间的部分放类的属性、属性的

36、类型及其值，底部的部分存放类的操作、操作的参数表和返回类型。第76页/共172页23 二月 202377/172（1）名称）名称 类的名称应该来自系统的问题域，并且类的名称应该是一个名词。类的名称可以分为简单名称和路径名称。单独的名称即不包含冒号的字符串叫做简单名；用类所在的包的名称作为前缀的类名叫做路径名。第77页/共172页23 二月 202378/172（2）属性）属性 一个类可以有一个或多个属性或者根本没有属性。属性描述了为类的所有对象所共有的特性。属性的选取应考虑下列因素：原则上，类的属性应能描述并区分每个特定的对象。只有与系统有关的特性才包含在类的属性中。第78页/共172页23

37、二月 202379/172类属性的语法为：类属性的语法为：可见性：属性可以具有不同的可见性。类中属性的可见性主要包括公有(Public)、私有(Private)和受保护(Protected)3种。在UML中分别表示为“”“”“”。第79页/共172页23 二月 202380/172（3）操作）操作 一个类可以有任何数量的操作或根本没有操作。操作是类的所有对象所共有的行为的抽象。操作用于修改、检索类的属性或执行某些动作。操作通常也被称为功能或方法，但是它们被约束在类的内部，只能作用到该类的对象上。第80页/共172页23 二月 202381/172UML规定操作的语法为：规定操作的语法为：可见性

38、：类的操作的可见性主要包括公有(Public)“”；私有(Private)“”；受保护(Protected)“”。第81页/共172页23 二月 202382/1722.2.类之间的关系类之间的关系类之间的关系最常用的有4种，分别是表示类之间使用关系的依赖关系；表示类之间一般和特殊关系的类属关系；表示对象之间结构关系的关联关系；表示类中规格说明和实现之间关系的实现关系。第82页/共172页23 二月 202383/172第83页/共172页23 二月 202384/172 UML中有3种主要的类原型，分别是边界类、控制类和实体类。在进行面向对象分析和设计时，如何确定系统中的类是一个比较困难的工

39、作，引入边界类、控制类和实体类的概念有助于分析和设计人员确定系统中的类。3.边界类边界类、控制类、实体类、控制类、实体类第84页/共172页23 二月 202385/172（1）边界类(boundary class)边界类位于系统与外界的交界处，用于处理系统与外界的通信。窗体、对话框、报表以及表示通讯协议的类、直接与外部设备交互的类、直接与外部系统交互的类等都是边界类的例子。第85页/共172页23 二月 202386/172（2）控制类）控制类(control class)控制类是负责其他类工作的类。每个用例通常有一个控制类，控制用例中的事件顺序，控制类也可在多个用例间共用。其他类并不向控制

40、类发送很多消息，而是由控制类发出很多消息。第86页/共172页23 二月 202387/172（3）实体类）实体类(entity class)实体类保存要放进持久存储体的信息。持久存储体就是数据库、文件等可以永久存储数据的介质。通常每个实体类在数据库中有相应的表，实体类中的属性对应数据库中表的字段。但这并不意味着实体类和数据库中的表是一一对应的。第87页/共172页23 二月 202388/1724.4.类图的划分类图的划分 虽然在软件开发的不同阶段都使用类图，但这些类图描述了不同层次的抽象。类图分为3个层次：概念层、说明层和实现层。第88页/共172页23 二月 202389/172概念层类

41、图描述应用领域中的概念，一般这些概念和类有很自然的联系，但两者并没有直接的映射关系。说明层类图描述软件的接口部分，而不是软件的实现部分。这个接口可能因为实现环境、运行特性或者开发商的不同而有多种不同的实现。实现层类图真正考虑类的实现问题，提供类的实现细节。第89页/共172页23 二月 202390/172下图所示是一个类Circle的3个不同层次的情况：从图中可以看出，概念层类图只有一个类名，说明层类图有类名、属性名和方法名，但对属性没有类型的说明，对方法的参数和返回类型也没有指明，实现层类图则对类的属性和方法都有详细的说明。第90页/共172页23 二月 202391/1725.类图的构造

42、类图的构造根据用例描述中的名词确定类的候选者。根据边界类、控制类和实体类的划分来帮助发现系统中的类。对领域进行分析，或利用已有的领域分析结果得到类。参考设计模式来确定类。根据某些软件开发过程提供的指导原则进行寻找类的工作。第91页/共172页23 二月 202392/1723.3.3 对象图对象图对象图是类图的实例，用来描述特定运行时刻一组对象间的关系。对象图用于描述交互的静态部分，它由参与协作的有关对象组成，但不包括在对象之间传递的任何消息。对象图为开发人员提供对象在某个时间点上的“快照”，不像类图经常使用，但能帮助开发人员更好的理解系统结构在创建对象图时，建模人员可以选取所感兴趣的对象及其

43、之间的关系来描述。第92页/共172页23 二月 202393/172对象图中的建模元素有对象和链(link)。对象是类的实例，对象之间的链是类之间的关联关系的实例。对象图可以看作是类图的一个实例。对象图的建模元素对象图的建模元素第93页/共172页23 二月 202394/172类图和对象图的区别类图和对象图的区别 类图类图 对象图对象图 类类具具有有三三个个分分栏栏：名名称称、属属性性和和操作操作对象只有两个分栏：名称和属性对象只有两个分栏：名称和属性在类的名称分栏中只有类名在类的名称分栏中只有类名对对象象的的名名称称形形式式为为“对对象象名名：类类名名”，匿匿名名对对象象的的名名称称形形

44、式式为为“：类名：类名”类中列出了操作类中列出了操作对对象象图图中中不不包包含含操操作作，因因为为对对于于属属于于同同一一个个类类的的对对象象而而言言，其其操操作是相同的作是相同的类类使使用用关关联联连连接接，关关联联使使用用名名称称、角角色色、阶阶元元等等特特征征定定义义。类类代代表表的的是是对对对对象象的的分分类类，所所以以必必须须说说明可以参与关联的对象的数目明可以参与关联的对象的数目对对象象使使用用链链连连接接，链链拥拥有有名名称称、角角色色，但但是是没没有有阶阶元元。对对象象代代表表的的是是单单独独的的实实体体，所所有有的的链链都都是是一对一的，因此不涉及到阶元一对一的，因此不涉及到

45、阶元类类的的属属性性分分栏栏定定义义了了所所有有属属性性的的特征特征对对象象则则只只定定义义了了属属性性的的当当前前值值，以用于测试用例或例子中以用于测试用例或例子中第94页/共172页23 二月 202395/1723.3.4 顺序图顺序图(时序图时序图)顺序图表示对象间传送消息的时间顺序。顺序图用来描述对象之间消息发送的先后次序，阐明对象之间的交互过程以及在系统执行过程中的某一具体时刻将会发生什么事件。是一种强调时间顺序的交互图，可用来进行一个场景说明，即一个事务的历史过程。第95页/共172页23 二月 202396/172在时序图中的水平方向为对象维，沿水平方向排列的是参与交互的对象。

46、时序图的垂直方向为时间维，沿垂直向下方向按时间递增顺序列出各对象所发出和接收的消息。在UML中，时序图将交互关系表示为一个二维图。第96页/共172页23 二月 202397/172 时序图中包括的建模元素有：对象(参与者实例也是对象)、生命线(lifeline)、控制焦点(focus of control,FOC)、消息(message)等。第97页/共172页23 二月 202398/172 其中垂直虚线是对象的生命线，用于表示在某段时间内对象是存在的。时序图中的对象用一个带有垂直虚线的矩形框表示。下图表示了三种不同的命名方式。（1）对象第98页/共172页23 二月 202399/172

47、 控制焦点是时序图中表示时间段的符号，在这个时间段内，对象将执行相应的操作。控制焦点表示为生命线上的小矩形。（2）控制焦点第99页/共172页23 二月 2023100/172 消息用从一个对象的生命线到另一个对象生命线的直线箭头表示。箭头实线以时间顺序在图中从上到下排列。消息在生命线上所处的位置并不是消息发生的准确时间，只是一个相对的位置。如果一个消息位于另一个消息的上方，只说明它先于另一个消息被发送。（3）消息 消息是从一个对象（发送者）向另一个或几个对象（接收者）发送信号，或由一个对象（发送者或调用者）调用另一个对象（接收者）的操作。第100页/共172页23 二月 2023101/17

48、2对象的创建和撤销对象的创建和撤销 时序图中对象的默认位置是在图的顶部，如果对象在这个位置上，说明对象在交互开始之前已经存在了。如果对象是在交互过程中创建的，那么应当位于图的中间部分。第101页/共172页23 二月 2023102/172 如果要撤销一个对象，只要在其生命线终止点放置一个“”符号即可，该点通常是对删除或取消消息的回应。第102页/共172页23 二月 2023103/172第103页/共172页23 二月 2023104/1723.3.5 通信图通信图(协作图协作图)通信图也是一种交互图，它强调收发消息的对象的组织结构。通信图描述对象间的协作关系(与顺序图相似)，显示对象间的

49、动态合作关系。通信图包含3个建模元素：对象(object)、链(link)、消息(message)。第104页/共172页23 二月 2023105/172（1）对象 通信图与时序图中对象的概念是一样的，只不过在通信图中，无法像时序图一样表示对象的创建和撤销，所以对象在图中的位置没有限制。如下图所示，图中的矩形代表的就是对象：第105页/共172页23 二月 2023106/172 多对象：由多个对象组成的对象集合，一般这些对象是属于同一个类的。当需要把消息同时发给多个对象时，使用这个概念。在通信图中，多对象用多个方框的重叠表示。第106页/共172页23 二月 2023107/172（2）链

50、 通信图中用链(link)来连接对象，而消息显示在链的旁边，一个链上可以有多个消息。第107页/共172页23 二月 2023108/172（3）消息 通信图中的消息类型与时序图中的相同，只不过为了说明交互过程中消息的时间顺序，需要给消息添加顺序号。顺序号是消息的一个数字前缀，是一个整数，由1开始递增，每个消息都必须有唯一的顺序号。第108页/共172页23 二月 2023109/172第109页/共172页23 二月 2023110/172时序图与通信图的比较时序图与通信图的比较 时序图和通信图都属于交互作用图，都用于描述系统中对象之间的动态关系。两者可以相互转换，但两者强调的重点不同。时序