8.3.2 类图
类图是描述系统中的类，以及各个类之间关系的静态视图。能够在正确编写代码以前对系统有一个全面的认识。类图是一种模型类型，确切地说，是一种静态模型类型。类图表示类、接口和它们之间的协作关系。
数千年以前，人类就已经开始采用分类的方法有效地简化复杂问题，以了解客观世界。在面向对象建模的技术中，使用同样的方法将客观的实体映射为对象，并归纳成一个个类。类、对象和他们之间的关联式面向对象技术中最基本的元素。对于一个要描述的系统，其类模型和对象模型揭示了系统的结构，指明了一组对象的属性和行为。
（1）类图概述。
类图是描述类、协作（类或对象间的协作）、接口及其关系的图，是逻辑视图的重要组成部分，用于对系统的静态结构建模，涉及具体的实现细节。
在系统分析阶段，类图主要用于显示角色和提供系统行为实体的职责。
在系统设计阶段，类图主要用于捕捉组成系统体系结构的类结构。
在系统编码阶段，根据类图中的类及它们之间的关系实现系统的功能。
（2）类图的组成。
类图（Class Diagram）描述类和类之间的静态关系。与数据模型不同，它不仅显示了信息的结构，同时还描述了系统的行为。类图是定义其他图的基础，在类图的基础上，状态图、协作图等进一步描述了系统其他方面的特性。
类描述一类对象的属性和行为。在UML中，类的可视化表示为一个划分成三个格子的长方形（下面两个格子可以省略）。其中，上面的格子中包含类名，中间的格子中包含属性，下面的格子中包含类的操作，如图8.15所示。
图8.15 类的图形符号
类图描述了类和类之间的静态关系。定义了类之后，就可以定义类之间的各种关系了。类与类之间通常有关联、泛化（继承）、依赖和细化等关系。
1）关联关系。关联表示两个类之间存在某种语义上的联系。例如，学生使用计算机，就认为在学生和计算机之间存在某种语义上的联系，因此，在类图中应该在学生类和计算机类之间建立关联关系。
①普通关联。普通关联是最常见的关联关系，只要在类与类之间存在链接关系就可以用普通关联表示。普通关联的图示符号是链接两个类表之间的直线，如图8.16所示。图8.16所示的关联是双向的，可在一个方向上为关联起一个名字（也可不起）。为避免混淆，在名字前面（或后面）加一个表示关联方向的黑三角。
图8.16 普通关联
如果关联是单向的，则成为导航关联，其符号是用实际箭头链接两个类。仅在箭头所指的方向上才有这种关联关系，如图8.17所示，图中只表示某人可以拥有汽车，但汽车被人拥有的情况未表示出来。
图8.17 导航关联
在类图中还可以表示关联中的数量关系，即参与关联的对象的个数或数量范围。例如：
0..1 表示0到1个对象
0..*或* 表示0到多个对象
1..15 表示1到15个对象
3 表示3个对象
图8.16表示一个学生可以使用1到多台计算机，一台计算机可被0至多个学生使用。
②聚集。聚集也称为集合，是关联的特例。聚集表示的是类与类之间是整个与部分的关系。在陈述需求时使用的“包含”“组成”“分为……部分”等字句，往往意味着存在聚集关系。除了一般聚集之外，还有两种特殊的聚集关系，分别是共享聚集和复合聚集。
共享聚集：如果在聚集关系中处于部分方的对象可同时参与多个处于整体方对象的构成，则该聚集称为共享聚集。例如，一个社团包含许多学生，每个学生又可以是另一个社团的成员，则社团和学生之间的共享聚集关系，如图8.18所示。一般聚集和共享聚集的图示符号，都是在表示关联关系的直线末端紧挨着整体类的地方画一个空心菱形。
图8.18 共享聚集
复合聚集：如果部分类完全隶属于整体类，部分与整体共存，整体不存在了部分也会随之消失（或失去存在价值），则该聚集称为复合聚集（简称为组成）。例如，我们在屏幕上打开一个窗口，它由文本框、列表框、按钮和菜单组成，一旦关闭了窗口，各个组成部分也同时消失，窗口和他的组成部分之间就存在着复合聚集关系，如图8.19所示。组成关系用实心菱形表示。
图8.19 复合聚集
图8.20 泛化关系
2）泛化关系。UML中的泛化关系就是通常所说的继承关系，它是通用元素和具体元素之间的一种分类关系。具体元素完全拥有通用元素的信息，并且还可以附加一些其他信息。如图8.20所示，汽车类包含客车与货车两个子类，它们之间具有泛化关系。
在UML中，用一端为空心三角形的连线表示泛化关系，三角形的顶角紧挨着通用元素。
注意，泛化针对类型而不针对实例，一个类可以继承另一个类，但一个对象不能继承另一个对象。
3）依赖关系。依赖关系描述两个模型元素（类、用例等）之间的语义连接关系。其中一个模型元素是独立的，另一个模型元素不是独立的，它依赖于独立的模型元素，如果独立的模型元素改变了，将影响依赖于它的模型元素。例如，一个类使用另一个类的对象作为操作的参数，一个类用另一个类的对象作为它的数据成员，一个类向另一个类发消息等，这样的两个类之间都存在依赖关系。
在UML的类图中，用带箭头的虚线连接有依赖关系的两个类，箭头指向独立的类。在虚线上可以带一个版本的标签，具体说明依赖的种类。例如，如图8.21表示一个友元依赖关系，该关系使得B类的操作可以使用A类中私有的或保护的成员。
图8.21 友元依赖关系
（3）建立类图。建立类图主要遵守以下步骤：
1）分析问题域，确定需求；
2）寻找类，确定类的含义和职责；
3）定义类的属性和操作；
4）确定类之间的关系；(https://www.daowen.com)
5）精化类和类间的关系；
6）绘制类图。
在以上步骤中重点是如何寻找类：
UML中类有三种主要的板型：边界类、控制类和实体类。
1）边界类：边界类位于系统与外界的交界处，包括：
①用户界面类，如窗口、对话框、报表类等；
②通信协议类，如TCP/IP的类；
③直接与外部设备交互的类；
④直接与外部系统交互的类。
边界类如图8.22所示。
图8.22 边界类1
通过用例图可以确定需要的边界类，每个Actor/User case对至少需要一个边界类。边界类一般可以没有属性，只有操作。但并不是每个Actor/Use case都需要生成唯一边界类，多个Actor启动同一use case，可以使用同一边界类。如图8.23所示。
图8.23 边界类2
2）实体类：实体类保存要放进持久存储体（数据库/文件等）的信息。如图8.24所示。
图8.24 实体类
实体类采用目标领域术语命名。
通常实体类对应数据库中的表，其属性对应表的字段，但实体类与数据库中的表不一定是一一对应关系。
3）控制类是负责管理或控制其他类工作的类。控制类如图8.25所示。
图8.25 控制类
每个用例通常有一个控制类，控制用例中的事件顺序，控制类也可以在多个用例间共用。控制类较少接收消息，发出较多消息。
例8.4 通过以下实例来说明如何建立类图。
张同学是一个爱书之人，家里各类书籍已过千册，而平时又时常有朋友外借，因此需要一个个人图书管理系统。该系统应该能够将书籍的基本信息按计算机类、非计算机类分别建档，实现按书名、作者、类别、出版社等关键字的组合查询功能。在使用该系统录入新书籍时系统会自动按规则生成书号，可以修改信息，但一经创建就不允许删除。该系统还应该能够对书籍的外借情况进行记录，可对外借情况列表打印。另外，还希望能够对书籍的购买金额、册数按特定时间周期进行统计。
第一步：发现类。下面标注下划线的为已发现的类。
张同学是一个爱书之人，家里各类书籍已过千册，而平时又时常有朋友外借，因此需要一个个人图书管理系统。该系统应该能够将书籍的基本信息按计算机类、非计算机类分别建档，实现按书名、作者、类别、出版社等关键字的组合查询功能。在使用该系统录入新书籍时系统会自动按规则生成书号，可以修改信息，但一经创建就不允许删除。该系统还应该能够对书籍的外借情况进行记录，可对外借情况列表打印。另外，还希望能够对书籍的购买金额、册数按特定时间周期进行统计。
第二步：筛选修改已选类。
“计算机类”“非计算机类”是该系统中图书的两大分类，因此应该对其建模，并改名为“计算机类书籍”和“非计算机类书籍”，以减少歧义。
“外借情况”则是用来表示一次借阅行为，应该成为一个候选类，多个外借情况将组成“外借情况列表”，而外借情况中一个很重要的角色是“朋友”这一借阅主体。虽然到本系统中并不需要建立“朋友”的资料库，但考虑到可能会需要列出某个朋友的借阅情况，因此还是将其列为候选类。为了能够更好地表述，将“外借情况”改名为“借阅记录”，而将“外借情况列表”改名为“借阅记录列表”。
“购买金额”“册数”都是统计的结果，都是一个数字，因此不用将其建模，而“特定时限”则是统计的范围，也无须将其建模；不过从这里的分析中，可以发现，在该需求描述中隐藏着一个关键类“书籍列表”，也就是执行统计的主体。
第三步：得到候选类。
书籍（Book）、计算机类书籍（BookList）、非计算机类书籍（OtherBook）、借阅记录（BorrowRecord）、借阅记录列表（BorrowList）、书籍列表（ItBook）。
在使用“名词动词法”寻找类的时候，很多团队会在此耗费大量的时间，特别是对于中大型项目，这样很容易迷失方向。其实在此主要的目的是对问题领域建立概要的了解，无须太过咬文嚼字。
第四步：关联分析，建模，如图8.26所示。
图8.26 关联分析
第五步：多重性分析，再建模。如图8.27所示。
图8.27 多重分析
第六步：职责分析。
书籍类：从需求描述中，可找到书名、类别、作者、出版社；同时从统计的需要中，可得知“定价”也是一个关键的成员变量。
书籍列表类：书籍列表就是全部的藏书列表，其主要的成员方法是新增、修改、查询（按关键字查询）、统计（按特定时限统计册数与金额）。借阅记录类：借阅人（朋友）、借阅时间。借阅记录列表类：主要职责就是添加记录（借出）、删除记录（归还）以及打印借阅记录，如图8.28所示。
图8.28 职责分析
