第五章 类图和对象图

类和对象的定义 类：描述了拥有相同特性（属性）、行为（操作）、关系的种别以及语义的一组对象。 对象：具有标识的一个概念、一种抽象或事物，标识对于某项应用而言是有意义的。

结构模型视图 结构模型视图由类图和对象图组成，其中，类图用来描述系统中类之间的静态关系，它对系统的静态结构进行描述。 对象图实际上提供的是系统的“快照”，用来描述在特定时刻存在的对象以及它们的关系。每一个对象图用来描述系统在一个特定时刻的状态。一个类图相当于对象图的无限集合。

类图和其他图的关系

类的定义 类是具有相似结构、行为和关系的一组对象的描述符。 UML中类用带三个预定义分栏的矩形表示,三个分栏分别是名称分栏、属性分栏、操作分栏。 名称分栏提供了惟一标志一个类的方法，它用一个名词或名词短语。 当类在类图中显示时，名称分栏是惟一必须可见的部分，属性和操作分栏可以是可见的，也可以是不可见的，取决于类的目的。

类图示例

类图

名称分栏 类的名称非常重要，是人们识别模型中基本资源的主要方法，名称应该精确并且简短，能够描述类所代表的对象的类型。名称通常是一个单独的名词或名词短语。 类名的大小写规则通常和编程语言的规则相对应。 在一个包里，类名必须是独一无二的，但是在不同的包里可以有相同的类名，因此，为了明确说明引用的是哪个类，必须指明拥有类的包名。类的完全名称应该是“包名::类名”。

可见性 可见性指的是对类的某个成员可以访问的范围。 Private：在一个类之内； Package：在相同的包内； Public：在整个系统内； Protected：在一个继承树内；

多重性 多重性说明了可能和一个模型元素关联的取值的数目。多重性通常表示为一个取值表达式，当它用于字符串（如对象属性）时，取值表达式被中括号括起来，当用于装饰某个图的符号（如关联）时，不需要中括号。多重性可以规定连续的取值范围、某个特定的值、没有限定的取值范围或一组离散值。

多重性 可能的多重值 描述表示含义 0..1 0个或1个 1 只能1个 0..* 0个或多个 * 0个或多个 1..* 1个或多个 只能3个 可能的多重值 描述表示含义 0..1 0个或1个 1 只能1个 0..* 0个或多个 * 0个或多个 1..* 1个或多个 只能3个 0..5 0到5个 5..15 5到15个

多重性 连续的取值范围：包括一个下限值和一个上限值，中间用两个点连接起来。如[4..20]。 特定的取值：如[2]。 无限定的取值：如[1..*] 离散值集合：[2,3,8] 定序：定序的选项被放在大括号里，置于多重性的取值后面，定序被定义成一个叫isOrdered的布尔特性，如[1..*]{isOrdered}.

属性分栏 属性分栏包含一个对象所拥有的全部信息的定义。属性分栏有两个特征：第一，它包含的只能是对象的属性；第二，它必须放在名称分栏的下面。 一个对象可以拥有三种类型的信息。首先，对象必须了解自身，即它自己的结果和当前的状态；其次，对象必须了解它的直接关系；再次，对象有时还要负责监视特定的信息（如系统出错信息）。

类的属性 属性的格式 [可见性]属性名[：类型][‘[’多重性[次序]’]’][=初始值][{特性}] 举例见教材P49例5.1

类的操作 用于修改、检索类的属性或执行某些操作，通常也称作功能。 操作的格式 [可见性]操作名[(参数列表)][：返回值][{特性}] 例子见P49例5.2

抽象类的表示

类之间的关系 关联 聚合 组合 泛化 依赖

关联（1） 关联是模型元素间的一种语义联系，它是对具有共同的结构特性、行为特性、关系和语义的链的描述。 一个关联可以有两个或多个关联端，每个关联端连接到一个类。 关联可以有方向，可以是单向关联活双向关联。 一个完整的关联包含三个部分，即类之间的关联直线和两个关联端点。其中关联直线及其名称定义了该关系的标志和目的，关联端点定义了参与关联的对象遵循的规则。

关联名 关联名用来描述关联的作用，通常使用一个动词或动词短语命名关联。 在类图中，并不需要给每个关联都加上关联名，给关联命名的原则是该命名有助于理解该模型。

关联的角色 关联两端的类可以某种角色参与关联，如果在关联上没有标出角色名，则隐含地用类的名称作为角色名。 角色还具有多重性，表示可以有多少个对象参与关联。多重性用非负整数地一个子集表示。

关联类 关联本身也可以有特性，通过关联类可以进一步描述关联的属性、操作以及其他信息。 关联类通过一条虚线和关联连接。 关联类和其他类非常相似，两者之间的区别就在于它们的使用需求不同。一般的类描述的都是某个实体，即看得见摸的着的东西，而关联类描述的则是关系，因为关联类也是一个类，并非关联本身，所以它自己也可以参与其他的关联。 例子见教材P52图5.6.

关联类

关联的约束 见教材P53图5.7

限定关联 在关联端紧靠源类图标处可以有限定符，带有限定符的关联称为限定关联，限定符的作用就是在给定关联一端的一个对象和限定符值以后，可确定另一端的一个对象或对象集。 限定符定义了被参考对象的一个属性，并使用该属性作为直接访问被参考对象的关键字。

限定关联的意义 引入限定符的一个目的就是把多重性从n降为0..1，这样如果查询操作，则返回的对象至多是一个，而不会是一个对象集。 如果限定符不是一个惟一的值，查询的结果会是一个对象集，即所有事件对象的一个子集，当使用具有惟一值的限定符时，对端的多重性可以是零个或一个，表示可能会没有任何对象符合该限定符。

关联的种类 自返关联：又称递归关联，是一个类与自身的关联，即同一个类的两个对象间的关系。 自返关联虽然只有一个被关联的类，但有两个关联端，每个关联端的角色不同。 二元关联 N元关联

自返关联

聚合和组合 聚合是一种特殊形式的关联，聚合表示类之间整体与部分的关系。聚合是关联的子集，是关联的特化，引入普通关联所不具备的特征，这些特征是： 聚合主要用于定义和保护对象配置的完整性。 聚合定义了一种构造关系，从而可以把对象的集合看成一个统一的单元处理，就好像该集合是一个大一些的对象一样。 聚合将其中的一个对象定义成控制对象，它为整个集合提供接口，控制对象对集合内部对象的行为起指导作用，以满足接口的需要。

关联和聚合的区别

聚合 聚合定义了一个单独的控制点，如果有人要对集合中的某个对象执行一个动作，必须通过控制点进行，动作是否可以执行，聚合有最终的决定权。 当接收到一条可能影响所有对象的指令时，聚合对象指示各成员对象如何应对，以便使集合像一个单独的对象那样运作。

聚合的表示 在代表成员的类和代表聚合的类之间画一个关联（直线）； 在靠近聚合类的地方画一个中空的菱形； 对每个关联端点赋予恰当的多重性，并且添加所需的角色名称、约束等规则。

聚合

组合关系 组合是聚合的一种特殊情况，在组合中，成员对象的生命周期取决于组合而且控制着成员对象的创建和析构，即成员对象不能脱离聚合而独立存在。

关联、聚合、组合的关系

组合

组合、聚合的区别 聚合关系是“has a”关系，组合关系是“contains a”关系； 聚合关系表示事物的整体/部分关系的较弱的情况，组合关系表示事物的整体/部分关系的较强的情况； 聚合关系中，代表部分事物的对象可以属于多个聚合对象，可以为多个聚合对象所共享，而且可以随时改变它所从属的聚合对象。代表部分事物的对象与代表聚合事物的对象的生存期无关，一旦删除了它的一个聚合对象，不一定也就随机删除了代表部分事物的对象。组合关系中，代表整体事物的对象负责创建和删除代表部分事物的对象，代表部分事物的对象只属于一个组合对象，一旦删除了组合对象，也就随即删除了相应地代表部分事物的对象。

泛化关系 泛化定义了一般元素和特殊元素之间的分类关系，如果从面象对象程序设计语言的角度来说，类与类之间的泛化关系就是类与类之间的继承关系。泛化关系是“is a kind of”关系。 泛化的表示：空心三角形的连线表示泛化关系，箭头指向超类。

泛化

泛化和关联关系的区别 关联定义了对象之间的相互关系。 泛化描述的是对目的相同的各种对象的特性进行组织的过程。

依赖关系 假设有两个元素x、y，如果修改元素x的定义可能会导致对另一个元素y的定义的修改，则称元素y依赖于元素x。 依赖性代表的是一种客户/提供者的关系，如果提供者发生了变动，那么客户也要做出相应的改动。 表示：虚线箭头由依赖方指向被依赖方。 不只是类之间存在依赖关系，用例间、包之间也存在依赖关系。

派生属性和派生关联 派生属性和派生关联是指可以从其他属性和关联计算推演得到的属性和关联。 生成代码时，派生属性和派生关联不产生相应的代码。 指明某些属性和关联是派生的有助于保持数据的一致性。

派生关联示例

抽象类和接口 抽象类表示不能直接产生实例的类，因为抽象类中的方法往往只是一些声明，而没有具体的实现，因此不能对抽象类实例化。 表示：把类名写成斜体表示抽象类，对抽象方法也要写成斜体。

接口和抽象类的比较 接口不能含有属性，而抽象类可以含有属性； 接口中声明的所有方法都没有实现部分，而抽象类中某些方法可以有具体的实现。

UML的扩展机制 UML的扩展机制是指版型、标记值和约束。这三种构造能对UML的图进行定制以适应特定的科目或平台，是标准UML符号的扩展。

版型 UML里已经定义了一些版型，这些版型被称为标准元素，因为它们是作为UML标准的一部分被提供的。虽然这些已有的版型非常有用，但这并不能阻止开发者创建自己的版型。通过定义版型可以扩展UML，加入新的概念以定制标准的UML元素或扩大其功能，提供版型这种机制的目的就是使用户能够对UML进行定制使用，而不必创建新的模型元素甚至是建模语言来适应特定的领域或平台。 版型的表示方法是将标签放在尖括号中。

标记值 标记值的目的是赋予某个模型元素新的特征，而且这个特征是不包含在元模型已经定义的特征里面的。使得开发人员可以对某个模型元素进行裁减或增强，同时仍忠实于UML元模型的定义，标记值不能和已有的元模型的定义相抵触或者改变它们的定义，而只能往其中添加定义。 例如：author＝“Tom”，last_update=“07-3-24”

约束 约束是一个语义条件或限制，约束被放在大括号里表示。

分布式体系结构 客户机过程负责在用户的屏幕上控制信息的显示并处理用户事件。 服务器过程是任何带有一个数据库的计算机结点，其中的数据可能被客户机过程请求。 分布式处理系统中，客户机可以多次访问服务器，但客户机一次只允许访问一台服务器。

客户/服务器风格 ◇ 体系结构

三层客户/服务器风格 ◇ 体系结构

浏览器/服务器风格 ◇ 体系结构

MVC的提出 用户界面承担着向用户显示问题模型、与用户进行操作、输入/输出交互的作用。用户希望交互操作界面的相对稳定，但更希望根据需要改变和调整显示的内容和形式。例如要求支持不同的界面标准或得到不同的显示效果，适应不同的操作需求，这就要求界面能够在不改变软件功能的情况下，支持用户对界面结构的调整。

MVC模式 MVC把交互系统的组成分解成模型、视图、控制三种构件，其中模型构件独立于外在的显示内容和形式，是软件所处理的问题逻辑的内在抽象，它封装了问题的核心数据、逻辑和功能的计算关系，独立于具体的界面表达和输入输出操作；视图构件把表示模型数据及逻辑关系和状态以特定形式展示给用户，它从模型获得显示信息，对于相同的信息可以有多个不同的显示形式和视图；控制构件处理用户与软件的交互操作，其职责是决定软件的控制流程，确保用户界面与模型间的对应联系，它接收用户的输入，将输出反馈给模型，进而实现对模型的计算控制，它是使模型和视图协调工作的部件。

三层体系结构 BCE方法（类似于MVC方法） 边界类描述参与者和系统之间的交互。对应于GUI设计中出现的类，边界对象通过控制对象依赖于实体对象，实体对象将它的变化传播到边界对象的状态中，从而使得边界对象能更新GUI的显示。 控制类描述解释用户输入事件并控制业务进程执行的对象。控制对象处理用户生成事件和受到影响的实体对象及边界对象之间的交互。每个允许交互的边界对象总有一个控制对象与之关联。 实体类描述那些表示一个应用领域中的实体语义的对象。对应于数据库中的数据结构。

三层体系结构

三层体系结构 BCE方法和三层客户/服务器模型完全对应，数据管理（实体）通过应用逻辑中间层（控制）而独立于表现（边界）。 同客户机和服务器过程一样，应用过程也是一个逻辑概念，应用逻辑可以等价地在客户机和服务器结点上运行，当应用逻辑被编译进客户机时，称为胖客户机体系结构，当应用逻辑被编译进服务器时，称为廋客户机体系结构，应用逻辑还可以被部分编译进客户机，部分被编译进服务器。

边界类 边界类位于系统与外界的交接处，窗体、对话框、报表以及通信协议的类、直接与外部设备交互的类、直接与外部系统交互的类等是边界类的例子。 边界类的表示见教材60页图5.22。 通过用例图可以确定需要的边界类。每个参与者/用例对至少要有一个边界类，但并非每个参与者/用例对都要生成惟一边界类。

控制类 是负责其他类工作的类。 表示方法见教材62页图5.25。 每个用例通常有一个控制类，控制用例中事件顺序，控制类可在多个用例间共用。其他类并不向控制类发送很多消息，而是由控制类发出很多消息。

实体类 实体类保存要放进持久存储体的信息。所谓持久存储体就是数据库、文件等可以永久存储数据的介质。 表示方法见教材61页图5.24。 一般实体类可以通过事件流和交互图发现，实体类通常用领域术语命名。 通常每个实体类在数据库中有相应的表，实体类中的属性对应数据库中表的字段。但并不表明实体类和数据库中的表是一一对应的。有可能一个实体类对应多个表，也可能多个实体类对应一个表。

如何识别类 名词识别法 从用例中识别类 使用CRC分析法 根据边界类、控制类、实体类帮助分析系统中的类

名词识别法 对系统进行描述，描述应该使用问题域中的概念和命名，从系统描述中标识名词及名词短语，其中的名词往往可以标识为对象，复数名词往往可以标识为类。

从用例中识别类 用例描述中出现了那些实体？ 用例的完成需要哪些实体合作？ 用例执行过程中会产生并存储哪些信息？ 用例要求与之关联的每个角色的输入是什么？ 用例反馈与之关联的每个角色的输出是什么？ 用例需要操作哪些硬设备？

CRC分析法 类(Class)、职责(Responsibility)、协作(Collaborator)。 找出需求中存在的名词和名词词组 ，把第一次想到的所有概念都写在白板或纸上； 筛选。把对象分为三类，核心对象（必须首先实现），可选的（目前不能确定），以及不需要的对象。 建卡。取出CRC卡，把核心类写在每一张卡上，把可选的类和排除的类分别写在不同的纸上。 角色扮演 。

边界类、控制类、实体类 边界类位于系统与外界的交界处，窗体、报表、以及表示通讯协议的类、直接与外部设备交互的类、直接与外部系统交互的类等都是边界类。 实体类保存要放进持久存储体的信息。 控制类是控制其他类工作的类。

类图 类加上它们之间的关系构成了类图，类图中可以包含接口、包、关系等建模元素，也可以包含对象、链等实例。类图是UML中的核心。 类图描述的是类和类之间的静态关系。

◇ 类图 表示系统中的类和类与类之间的关系，它是对系统静态结构的描述

类图的抽象层次（1） 在开发的不同阶段使用的类图具有不同的抽象层次。一般类图可分为3个层次：概念层、说明层和实现层。 概念层类图描述应用领域中的概念，一般这些概念和类有很自然的联系，但两者并没有直接的映射关系。在概念层类图中很少考虑或不考虑实现问题。因此，概念层类图应独立于具体的程序设计语言。

类图的抽象层次（2） 说明层类图描述软件的接口部分，而不是软件的实现部分。这个接口可能因实现环境、运行特性或者开发商的不同而有多种不同而有多种不同的实现。 实现层类图才真正考虑类的实现问题，提供类的实现细节。 三个不同层次的类图见教材62页图5.26。

类图的抽象层次（3） 概念层类图只有一个类名，说明层类图有类名、属性名和方法名，但对属性没有类型的说明，对方法的参数和返回类型也没有指明，实现层类图则对类的属性和方法都有详细的说明。 三个类图层次没有一个很清晰的界限，类图从概念层到实现层的过渡是一个渐进的过程。

构造类图（1） 确定系统中的类是OO分些和设计的核心工作。寻找类的一些技巧包括： 根据用例描述中的名词确定类的候选者； 使用CRC分析法寻找类，CRC方法根据类所扮演的职责来确定类。 根据边界类、控制类和实体类的划分来帮助发现系统中的类。 参考设计模式确定类。（14章） 根据某些软件开发过程提供的指导原则寻找类。

构造类图（2） 注意事项： 构造类图时不要试图使用所有的符号，注意20％、80％原则； 构造类图时不要过早陷入实现细节，应根据项目开发的不同阶段，采用不同层次的类图。分析阶段应使用概念类图，设计阶段使用说明层类图，当考虑特定的实现细节时，应使用实现层类图。 对于初步构造好的类图，要审核是否真是地反映了应用领域的实际，另外要根据实际合并或拆分不合适的类。

构造类图（3） 建立类图的步骤： 研究分析问题，确定系统的需求。 确定类，明确类的含义和职责，确定属性和操作； 确定类之间的关系。把类之间的关系用关联、泛化、聚合、组合、依赖等关系表示出来； 调整和细化已得到的类图，解决命名冲突、功能重复等问题； 绘制类图并增加相应的说明。

领域分析 （1）通过对某一领域中的已有应用系统、理论、技术、开发历史等的研究，来标识、收集、组织、分析和表示领域模型及软件体系结构的过程； （2）根据（1）中进行的过程得到的结果； 根据层次任务分析图（HTA）表示具体例子见教材64页图5.27。

OO设计原则 开闭原则 Liskov替换原则 依赖倒置原则 接口分离原则

开闭原则 开闭原则指的是一个模块在扩展性方面应该是开放的，而在更改性方面应该是封闭的。 在写模块的时候，应该尽量使得模块可以扩展，并且扩展时不需要对模块的整个源代码进行修改。 在设计时要有意识地使用接口进行封装等，采用抽象机制，并利用OO中的多态技术。 举例见教材66页图5.29。

Liskov替换原则 指的是子类可以替换父类出现在父类能出现的任何地方。 举例见教材66页图5.30。

依赖倒置原则 指的是依赖关系应该尽量依赖接口（或抽象类），而不是依赖于具体类。 结构化设计中抽象的模块要依赖与具体实现有关的模块。面向对象中，依赖关系正好是相反，即与具体实现有关的类是依赖于抽象类或接口。 举例见教材67页图5.31、5.32。

接口分离原则 指的是在设计时采用多个与客户类有关的接口比采用一个通用的接口要好。即一个类要给多个客户类使用，那么可以为每个客户类建一个接口，然后这个类实现所有这些接口，而不要只创建一个接口，其中包含了所有客户类需要的方法，然后这个类实现这个接口。 举例见教材68页图5.33、5.34。

其他设计注意问题 不同类中相似方法的名字应该相同。 遵守已有的约定俗成的习惯； 尽量减少消息模式的数目； 设计简单的类；类的职责要明确，不要在类中提供太多的服务，应该从类名就可以较容易的推断出类的用途。 泛化结构的深度要适当。 定义简单的方法。一个类中的方法不应太复杂。

对象图 对象图表示一组对象及它们之间的联系，对象图是系统的详细状态在某一时刻的快照，常用户表示复杂的类图的一个实例。 UML中对象图和类图具有相同的表示形式，对象图中的元素有对象和链。对象是类地实例，对象之间的链是类之间关联的实例，对象图实质上是类图的实例。 对象图主要用于表达数据结构的示例，以及了解系统在某个特定时刻的具体情况。

对象图 软件系统的运行是动态的； 从面向对象的角度看，动态行为是系统内部诸对象的交互实现的。 在交互中， 各对象担负着不同的职责； 互相合作； 为软件系统的用户提供给定的使用价值； 它涉及到 分析软件系统内部参与交互的诸对象； 在特定时刻的状态及互相联系。

对象图 对象图包含了在某一时间点上，一组对象的状态及其中的关系。 类图是为了支持某一交互，系统内应具备的对象的本质属性及其关系的静态抽象。 交互图描述了类图内的类的对象在交互过程中控制的动态交换。 对象图则捕获了类图中包含的类的对象在交互图描述的动态控制流中某一时刻的状态。 可以把对象图看作是类图在某一特定时刻的实例。 它表达的是交互图在某一特定时刻其中的原型对象的状态； 因此对象图内包含的对象也是交互图中的对象，但其中没有消息的传递。

标准建模语言UML （对象图） 类图 对象图 作者 计算机 Uses 名字：String 年龄：Integer 名字：String 内存：Ineger 0..1 1..* 类图 小王的工作PC： 计算机 小王：作者 名字 = “Dell486” 内存 = 64 名字 = “王小影” 年龄 = 32 小王的工作PC： 计算机 名字 = “Compaq X” 内存 = 32 对象图

小结（1） 类图在UML中处于核心地位； 类之间的关系有关联、聚合、组合、泛化、依赖。 关联类是用于描述关联本身的特性； 带有限定符的关联称为限定关联，限定符的作用就是在给定关联一端的一个对象和限定符值以后，可确定另一端的一个对象或对象集。

小结（2） 派生属性和派生关联是指可以从其他属性和关联计算推演得到的属性和关联，在生成代码时不产生相应的代码； 抽象类和接口为OO设计提供了抽象机制； 边界类、实体类、控制类是对类的一种划分； 类图可分为概念层、说明层和实现层，分别在软件开发的不同阶段使用； OO中确定类没有固定的方法；

小结（3） 领域分析是帮助发现类的一个有效方法； OO设计应遵守开闭原则、Liskov替换原则、依赖倒置原则、接口分离原则等； 友好性、可靠性、可扩展性、可移植性、可伸缩性、可重用性、简单性等属性要综合考虑； 对象图是类图的实例，是系统详细状态在某一时刻的快照。

思考题 汽车和自行车都是交通工具。一辆自行车只能归一个人拥有，但一辆汽车可归一个人或两个人拥有。一个人可能没有自行车或汽车，也可能拥有多辆自行车或汽车。人分男人和女人两类，每个人都有自己的年龄和姓名。在任何时候，一辆汽车上可能载有0个或多个乘客。每辆汽车都有自己的颜色和商标。特别地，每辆汽车都只有两个前灯和一台发动机。请画出类图。