一、前言

上一篇我们介绍了UML建模语言，旨在通过图形化符号表示系统的结构、行为和交互。这篇我们来介绍其中的UML类图，它是一种重要的静态建模工具，主要用于展示系统的类及其关系。它能够帮助我们清晰地理解系统的结构并进行合理设计。

二、类图的概念

类图是UML中的一种结构图，它主要展示了系统中的类、接口、类的属性与方法以及类与类之间的关系。类图的核心要素包括：

1、类（Class）：类是对象的模板，定义了对象的属性和行为。类图中，类以矩形框表示，通常分为三部分：类名、属性、方法。

2、接口（Interface）：接口定义了类必须实现的一组操作，通常不包含实现细节，类通过实现接口来遵循约定。接口在类图中通常用带有小圆圈的连接线表示。

3、属性（Attributes）：属性是类的字段，表示类对象的状态或数据。属性通常是类的私有成员，外部通过方法访问或修改其值。

4、方法（Methods/Operations）：方法是类定义的行为，表示类所能执行的操作。方法通常是公开的，可以通过对象调用。

5、关系（Relationships）：类与类之间的关系是类图的关键部分。

类之间的静态关系分为三大类：泛化、关联（基本关联、聚合、组合）、依赖。依次介绍一下：

1、泛化，通常叫做继承（Generalization），这个比较简单，就是我们常用的这个继承类与类之间的一个继承，接口与接口的继承，还有就是类对接口的一个实现，用UML表示法，如上图最左边这两个。继承类与被继承类是一个is-a的关系。

2、关联（Association），这里其实细分了三种：第一个是基本关联，第二个是聚合，第三个是合成也叫组合。然后从左到右是这三种关联关系是依次增强，它们在这个语法上的体现其实就是一个实例变量，一个类拥有另外一个类的实例变量，然后通过这个实例变量可以操作另外一个类的一个属性或方法。它们有三个名字，它们到底有什么区别呢？

首先说基本关联（Association）：表示类之间的联系，可以是单向或双向的，常用于表示类之间的交互。

然后说聚合（Aggregation）：表示“拥有”的关系，但聚合关系中的类可以独立存在。关联的两个对象，一个代表的是整体，另外一个是代表的是部分。它有这种整体部分的关系，用英文就是has-a的关系。而基本关联它是没有这种关系的，两个对象是没有这种层级结构的。

最后说合成（Composition）：是一种强聚合，表示“包含”的关系，其中被包含的类不能独立于包含类存在。它们的关系叫做contains-a的关系。

3、依赖（Dependency）：表示类之间的暂时性关系，通常是类的使用关系。代码里面体现局部变量或者说那个方法的入参出参这种形式。

下边我们会通过一个经典的UML类图大家来再熟悉一下：

说明：

1、继承关系： —?（实线 + 空心三角形） 鸟 —? 动物；鸟继承动物。

实现接口： ???? （虚线 + 空心三角形） 大雁 ???? 飞翔；大雁实现了飞翔接口。

实现接口： —○ （棒棒糖表示法） 唐老鸭 —○ 讲人话；唐老鸭实现讲人话接口。

2、关联关系： —> （实线剪头 ） 企鹅 —> 气候；企鹅需要‘知道’气候的变化。

3、依赖关系： ???> （虚线剪头） 动物 ???> 氧气；动物依赖于氧气。

4、聚合关系： ◇—> (空心菱形 + 实线剪头) 大雁 ◆—> 雁群；A是雁群，B是大雁，A包含B，但B不是A的一部分

5、合成关系： ◆—> (实心菱形 + 实线剪头) 大雁 ◇—> 翅膀；部分和整体的关系，如果这个鸟的生命周期结束了，那翅膀其实也就不复存在了。

类与类之间的关系是我们面向对象设计的基本功，需要吃透。

三、为什么使用类图

类图在软件开发中的作用是多方面的，主要包括以下几点：

1、系统结构清晰化：类图能够直观地展示系统的类结构，使开发人员能够轻松理解系统的组成部分及其相互关系。通过类图，开发团队能够更清晰地了解系统的架构和功能划分。

2、促进团队协作：类图是开发团队、产品经理、架构师和测试人员之间沟通的桥梁。它提供了一种统一的语言来表达系统的设计意图，减少了由于理解差异导致的沟通问题。

3、支持重构与维护：随着项目的演进，系统架构可能会发生变化。类图能够帮助开发人员在修改或重构代码时，快速定位系统中的关键类及其关系，从而确保代码的一致性和稳定性。

4、提升软件质量：类图通过明确展示类的职责、方法和关系，帮助开发人员遵循设计原则（如单一职责、组合聚合复用、封装等），从而提高系统的可维护性、可扩展性和稳定性。

5、文档化设计思路：类图是设计文档的一部分，可以记录系统的设计思路，便于后续开发人员理解和维护代码。对于大型项目或团队，类图是理解系统架构的宝贵参考资料。

6、发现潜在问题：通过类图的设计，开发人员可以识别潜在的设计问题，例如类之间的耦合过高、继承体系设计不合理等。及时发现并解决这些问题，有助于提高系统的质量和可维护性。

四、怎么使用类图

设计类图时，应该遵循一定的方法论和最佳实践，确保图表的清晰性和准确性。以下是设计类图的步骤和最佳实践：

4.1、设计步骤

1、需求分析与类识别：根据需求文档、用例图或业务流程，识别系统中需要建模的类。通常，类的识别是通过找出业务领域中的实体、动作或状态来完成的。

2、确定类之间的关系：分析不同类之间的相互作用，确定它们之间的关系。例如，哪些类是继承关系、哪些类通过关联互相交互、哪些类有聚合或组合关系。

3、定义类的属性与方法：为每个类定义必要的属性和方法，确保它们能够支撑系统的功能需求。在此阶段，需要根据功能需求和职责分配来确定类的行为。

4、绘制类图：使用UML建模工具（如drawio、Visio等）绘制类图。确保每个类、接口、属性、方法及关系都清晰标注，并遵循UML标准。

5、验证与评审：完成初步的类图设计后，进行评审。通过与团队成员的讨论，确保类图反映了需求并没有遗漏关键设计元素。在验证过程中，可以发现一些潜在的设计缺陷或不合理的设计。

6、优化与迭代：类图设计是一个迭代的过程。在项目开发的不同阶段，随着需求的变化或系统设计的改进，类图应进行调整和优化。保持类图与实际代码和需求的一致性。

4.1、最佳实践

具体案例：图书管理系统

在设计一个简单的图书管理系统时，可以使用类图来描述其结构。假设系统的需求包括以下功能：

• 管理书籍（添加、删除、查找）。
• 管理用户（注册、借阅、归还）。
• 管理借阅记录（记录借书、还书时间、借阅状态）。

1、识别类：根据需求，我们可以识别出以下主要类：

Book：表示图书，包含图书信息（如书名、作者、isbn）。User：表示用户，包含用户信息（如姓名、ID、借阅历史）。LoanRecord：表示借阅记录，记录每次借书和还书的时间、状态。Library：表示图书馆，包含管理所有书籍和借阅记录的方法。

2、识别关系，并定义类的属性和方法，绘制类图

Book和LoanRecord之间存在一对多关系，一个图书可以有多个借阅记录。Book和LoanRecord类之间通过关联连接。

User和LoanRecord之间也存在一对多关系，一个用户可以有多个借阅记录。User和LoanRecord 类之间通过关联连接。

Library和Book之间存在聚合关系，因为图书馆包含书籍，但图书可以独立存在。

3、 优化与迭代： 根据团队反馈，我们可能需要进一步拆分类、添加更多的功能或者优化类间的关系。

另在设计时遵循设计原则，如：单一职责原则（每个类应该承担明确的职责，避免类承担过多的功能），组合聚合复用原则（就是在一个对象里面使用一些已有的对象，使之成为新对象的一部分；新的对象通过向这些对象的委派达到复用已有功能的目的。要尽量使用组合/聚合，尽量不要使用继承，避免了继承层次过深或不必要的依赖）等， 从而保证高内聚低耦合。

五、小结

本文介绍了类图的概念（比较重要的一点是对象间的关系），及设计类图的方法和案例实践。类图在实际开发中能够帮助开发团队有效地设计系统的结构，并为软件的后续开发和维护提供清晰的蓝图。