版权声明
类图概述
类图用来描述系统内各种实体的类型以及不同的实体之间是如何彼此关联的，显示了系统的内部静态结构，因此类图的描述对于系统的整个生命周期都是有效的。如果说用例图是系统的“面子”，那么类图就是系统的“里子”。类图不仅包含了系统定义的各种类，还包含了各种关系，如关联、泛化和依赖等。类图大部分涉及对系统的词汇建模、对协作建模或对模式建模。作为面向对象系统的建模中最常见的图,类图是组件图与部署图的基础，它不仅对结构模型的可视化、详述和文档化很重要,而且对通过正向与逆向工程构造可执行的系统也很重要。
类图(class diagram)是显示一组类、接口、协作以及它们之间关系的图。一个类图主要通过系统中的类以及各个类之间的关系来描述系统的静态结构。
类图主要包含七种元素:类、接口、协作、依赖关系、泛化关系、实现关系和关联关系类图中还可以含有包或子系统,用来把模型元素聚集成更大的组块。与其他 UML 图类似类图同样可以创建约束和注释等。
核心知识点
请务必熟悉并掌握以下核心知识点。
类
类(class)是一组拥有相同的属性、操作、方法、关系和行为的对象描述符。
在UML中,类表达成一个有三个分隔区的矩形。其中，顶端显示类名(name)，中间显示类的属性(attribute)，尾端显示类的操作(operation)。
示例如下：
接口
接口(interface)是一个被命名的操作集合,用于描述类或组件的一个服务。接口不同于任何类或类型，它不描述任何结构,因此不包含任何属性；也不描述任何实现,因此不包含任何实现操作的方法。一个接口可以有多个操作，每个操作都是公共的。一个类可以实现多个接口。为了显示接口中的操作，接口可以表示为带有<< interface >>构造型的类。
示例如下：
类图中的关系
类图中涉及了 UML 中最常用的四种关系，即关联关系、泛化关系、依赖关系和实现关系。
关联关系
关联关系是两个或多个类元之间的关系，它描述了这些类元的实例间的连接。
多重性
多重性(multiplicity)放在靠近关联端的部分，表示在关联关系中源端的一个对象可以与目标类的多少个对象之间有关联。在 UML中，多重性的格式为“min…max”。其中，min 和 max分别表示该端最少和最多可以有多少对象与另一端关联。常用的多重性有0，1，0…1(0或1)、0…*(0或更多)、1…*(1或更多)、* (0 或更多)等。
例如，Student 类与 School类的关联关系的多重性,即一个学校可以有一个或更多个学生,而一个学生可能在 0所或更多所学校中学习。
导航性
导航性(navigation)是一个布尔值,用来说明运行时刻是否可能穿越一个关联。对于二元关联，当对一个关联端(目标端)设置了导航性就意味着可以从另一端(源端)指定类型的一个值得到目标端的一个或一组值(取决于关联端的多重性)。
例如，一个订单可以获取到该订单的一份产品列表，但一个产品却无法获取到哪些订单包括了该产品。
聚合与组合
聚合与组合是特殊的关联。
有时候我们需要对“整体-部分”的关系建模，即一个描述整体的对象由一些描述部分的对象组成，这种关系称为聚合(aggregation)。聚合关系是一种特殊形式的关联关系，用来表示一个“整体-部分”的关系。在聚合关系中，“部分”可以独立于“整体”存在。在 UML中，通过在关联路径上靠近表示“整体”的类的一端上使用一个小空心菱形来表示。
例如，ClassRoom(教室)类与 Desk(课桌)类之间构成一个聚合关系即教室中有许多课桌，当教室对象不存在时课桌同样可以作为其他用途，二者是独立存在的。
组合关系(composition)描述的也是整体与部分的关系,它是一种更强形式的聚合关系,又被称为强聚合。与聚合关系的区别在于，在组合关系中的部分要完全依赖于整体。这种依赖性主要表现在两个方面：部分对象在某一特定时刻只能属于一个组合(整体)对象组合对象与部分对象具有重合的生命周期，组合对象销毁的时候，所有从属部分必须同时销毁。
例如，Window(窗口)类与 Frame(架)类之间构成组合关系,Frame必须附加在 Window 中存在当一个 Window 被删除时其中的 Frame 部分也必须被删除。
泛化关系
泛化关系描述了一种“is-a-kind-of”(是··…·.的一种)关系，它的使用有利于简化有些类的描述，可以不必重复添加大量相同的属性和操作等特性而是通过泛化对应的继承机制使子类共享父类的属性和操作。在 UML 中，泛化关系通过一个由子类指向父类的空心三角形箭头表示。
例如，Tiger类和 Bird类继承了Animal类的属性和操作，还添加了属于自己的某些属性和操作。
在最简单的情况下,每个类最多能拥有一个父类，这称为单继承。而在更复杂的情况中,子类可以有多个父类并继承了所有父类的结构、行为和约束。这被称为多重继承(或多重泛化)。
依赖关系
依赖关系表示的是两个元素之间语义上的连接关系。对于两个元素 X和 Y，如果元素X的变化会引起对另一个元素 Y 的变化，则称元素Y 依赖于 X。其中，X 被称为提供者，Y被称为客户。依赖关系使用一个指向提供者的虚线箭头来表示。
由于依赖关系语义的宽泛性，在类图中要标记出所有的依赖关系是一件费时费力的事情并且会降低模型的可读性。因此建议在类图中尽量不使用依赖关系。
实现关系
实现关系用来表示类与实现之间的关系。一个类可以实现多个接口，一个接口也可以被多个类实现。在 UML中实现关系表示为一条指向提供规格说明的元素的虚线三角形箭头。
例如， Wall类实现了 Measurable 接口。即，在 Wall类中要实现接口中声明的三个操作。
分析类
分析类是一个主要用于开发过程中的概念，用来获取系统中主要的“职责簇”，代表系统的原型类，是带有某些构造型的类元素。分析类包括边界类(boundary)、控制类(control)和实体类(entity)三种。
边界类是一种用于对系统外部环境与其内部运作之间的交互进行建模的类。这种交互包括转换事件，并记录系统表示方式中的变更。一般来说，边界类的实例可以是窗口、通信协议、外部设备接口、传感器、终端等。总之，在两个有交互的关键对象之间都应当考虑建立边界类。
控制类是一种对一个或多个用例所特有的控制行为进行建模的类。控制类的实例称为控制对象，用来控制其他对象，体现出应用程序的执行逻辑。
实体类是用于对必须存储的信息和相关行为建模的类。简单来说，实体类就是对来自现实世界的具体事物的抽象。实体类的主要职责是存储和管理系统内部的信息,它也可以有行为，但这些行为必须与它所代表的实体对象密切相关。
航空购票系统类图
根据业务需求，我们应该确定出系统主要可以包括哪些类在航空购票系统类图中可以归结出用户User、管理员Administrator、机场Airport、航班Flight与机票Ticket几个实体类，还应该包括有一个系统控制类TicketManagement来控制整个系统。由于分析阶段尚未进行用户界面设计，因此类图中暂时不涉及边界类，需要在设计阶段再对类图进一步完善。
创建完毕，图示如下：
在类图上右键选择添加图，在弹出的窗口中选择UML Structural，在图的类型中选择Class；再单击确定；图示如下：
创建完毕，图示如下：
此时，点击工具箱就可以看到与类图相关的工具。如果没有与类图相关的工具，那么可以点击右上角更多的工具…即可；图示如下：
我们先来绘制User类。请左键单击Class，鼠标挪至绘图区弹出类的配置界面。请设置类的名字；图示如下：
单击确定后，图示如下：
接下来在项目浏览器中右键单击User实体再选择属性，图示如下：
此处，可以为User实体添加属性和操作。
先添加userID、password、info等三个属性；图示如下：
接下来为User实体添加login、register、searchMyFlight、bookMyTicket、cancleMyTicket、browserTicket、构造函数User等操作。这些操作的参数和返回值均设置为空；图示如下：
User实体绘制完成，图示如下：
