浅谈UML类图

Posted 2021-04-17 IT汪

“ 带着感恩的心启程”

01

—

前言

    在所有面向对象的编程语言中，都离不开类的概念，如果把程序中类的关系梳理清楚了，那么你就把握了程序的骨架，甚至可以说你把握了程序的灵魂。其实大多数和小汪一样的程序猿，无论你是高级猿（架构师）还是低级猿（码农），合理使用和绘制类图都是大有益处的，特别是大型复杂的程序，类图更是必不可少。前期设计阶段，类图扮演着从业务抽象到框架细节之间的重要桥梁角色，从类图的设计中，不仅能反映出业务抽象是否合理，而且能清楚的评判出程序耦合度的高低，更好的反应出设计中存在的一些问题。在软件开发阶段，类图更是能指导我们快速编码构建程序。在维护复用或者工作交接时，可以作为重要的指导资料，让开发人员快速理解前人程序。尤其在这开源的时代，当我们想要快速理解源码的时候，源码的贡献者，不可能给每位使用者面授讲解，那么这时借助类图，也许能帮助我们更快更好的理解开源代码。我们知道类的具体描述方式在不同的编程语言中是不一样的，UML类图的作用就是脱离语言的限制，清楚地描述各个类以及各个类之间的关系。下面我们从类的UML图表示，UML类图模型元素，UML类图关系几个方面介绍UML类图。

02

—

类的UML图表示

    在UML类图中，类使用包含类名、属性和方法且带有分隔线的长方形来表示，请看下图使用类图表示类信息的示例：

我们通常将类图表示的类分为三个部分：

第一部分为类名，如果类名用正体书写则说明这是可以实例化的普通类。如果类名用斜体书写，则说明这是抽象类。如果类名有下划线修饰则说明这是静态类。

第二部分为类属性，格式为修饰符属性名 ：属性类型。修饰符为“+”说明该属性为public型，“#”说明该属性为protected型，“-”说明该属性为private型。

第三部分为类方法，格式为修饰符方法名 （参数名1：参数类型1，……）：方法返回值类型。修饰符为“+”说明该方法为public型，“#”说明该方法为protected型，“-”说明该方法为private型。如果方法名有下划线修饰则说明这是静态方法。

03

—

UML类图模型元素

    在UML类图中一共包含三种模型元素，分别是：类（Class）、接口（Interface）以及类之间的关系。我们在上述People类图的基础上来说明这三种模型元素，将会更加直观，请见下图：

04

—

UML类图关系

    在UML类图中，最重要的就是类图之间的关系，顾名思义就是通过类图的方式把类与类之间的关系表述清楚。面向对象的编程中，类与类之间关系通俗点讲就两大类关系，一类是我中有你，你中有我的关系，另一类是父与子的关系，个人喜欢将其分为横向关系和纵向关系，横向就是依赖和关联，纵向就是泛化和实现，其中聚合和组合也属于特殊的关联关系。

泛化关系：

定义：表示类与类之间/接口与接口之间的一种继承关系，指定了子类如何特化父类的所有特征和行为

表示方式：使用带三角箭头的实线表示，箭头指向父类

示例：老虎是动物的一种，老鹰是动物的一种，动物都有Move方法，但是老虎和老鹰的Move是有差异的，老虎是奔跑，老鹰是飞翔。

实现关系：

定义：表示类是接口所有特征和行为的实现，也是一种继承关系，是指类对接口的实现。

表示方式：使用带三角箭头的虚线表示，箭头指向接口类。

示例：鼠标事件的监听接口类，Button控件实现该接口类，ListView控件实现该接口类，那么Button控件类和ListView控件类都是鼠标监听事件的实现类。

依赖关系：

定义：对于两个相对独立的对象，当一个对象负责构造另一个对象的实例，或者依赖另一个对象的服务时，这两个对象之间主要体现为依赖关系。我们可以将依赖关系理解为一种使用的关系，也就是“Use-a”的关系，我们在设计类时，尽量避免双向的互相依赖。

表示方式：带箭头的虚线，指向被使用者或者被创建者

示例：做地铁上班，依赖地铁的服务；使用螺丝刀将螺丝拧紧，依赖螺丝刀；驾驶员开车，依赖汽车；这些都是典型的依赖关系。依赖关系通常通过三种方式来实现：

1）  某个类的方法使用另一个类的对象作为参数

2）  在一个类的方法中将另一个类的对象作为其局部变量

3）  在一个类的方法中调用另一个类的静态方法

再简单一点理解，类 A 使用到了类 B，并且这种使用关系具有偶然性，临时性，是非常弱的关系，但是 B 类中的变化会影响到类 A。比如，班车司机每天开着班车接送公司员工上下班，每天班车可能不同，但是班车司机只是一个司机，公司给配哪辆班车，司机就是使用哪辆班车接送员工。

关联关系：

定义：对于两个相对独立的对象，当一个对象的实例与另一个对象的一些特定实例存在固定的对应关系时，这两个对象之间为关联关系。关联关系体现的是两个类一种强的依赖关系，不存在依赖关系中的偶然性，关系也不是临时的，一般是长期性的。可以理解为一种拥有或者对应关系，我们也称作为“Has-a”的关系。再直白点讲，其实所谓的关联就是某个对象会长期的持有另一个对象的引用，而二者的关联往往也是相互的。关联的两个对象彼此间没有任何强制性的约束，只要二者同意，可以随时解除关系或是进行关联，它们在生命期问题上没有任何约定。被关联的对象还可以再被别的对象关联，所以关联是可以共享的，并且关联关系可以是单向的，也可以是双向的。

单向关联表现为：

    类 A 当中使用了类 B，其中类 B 是作为类 A 的成员变量。

双向关联表现为：

    类 A 当中使用了类 B 作为成员变量，同时类 B 中也使用了类 A 作为成员变量。

表示方式：单向关联，使用带普通箭头的实心线表示，指向被拥有者

双向关联，可以使用有两个箭头或者没有箭头实心线表示

示例：员工和公司，员工属于某个公司，公司有多个员工；订单和客户，订单属于客户，客户可能有多个订单；车主人和车，车属于车主人，车主人可以拥有多辆车，其实上述依赖关系的类图稍加修改，即可变成关联关系。

聚合关系：

定义：属于关联关系的一种，耦合度强于关联，他们的代码表现是相同的，仅仅是在语义上有所区别，关联关系的对象间是相互独立的，而聚合关系的对象之间存在着包容关系，他们之间是“整体-个体”或者“整体-部分”的相互关系，且部分可以离开整体而单独存在。聚合关系是比关联关系更亲密的一种关系。

表示方式：带空心菱形的实心线，菱形指向整体。

示例：我们还是以车为例，比如车和轮胎，轮胎离开车可以单独存在，车和发动机，发动机可以离开车单独存在。其实上述司机和汽车的关系稍加修改就可理解为聚合关系。通过Set接口来设置这个司机具体开哪个车，可以理解为整体和个体的关系，车也可以脱离司机而单独存在。

组合关系：

定义：是比聚合关系还要强的关系，它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期，即“整体”负责“部分”的生命周期，他们之间是共生共死的，并且“部分”单独存在时没有任何意义。

表示方法：带实心菱形的实线，菱形指向整体

示例：比如公司事业部BU与公司的关系，如果公司不存在了，那么事业部BU就失去了单独存在的意义。其实还是以上述司机和汽车的例子来说明，只不过此时我们司机和汽车的意义和之前不太一样，我们先看类图，再来解释其意义，看看是不是属于组合关系。

我们这样理解这个类图：

1. Car作为Driver财产属性的一部分；

2. Car是Driver必须要有的财产，要想成为Driver必须要有Car，而且Car要是没了，Driver悲伤欲绝，也轻生了。而且Driver要是开车了，Car也就没了。

05

—

UML类图总结

• 各种类关系强弱顺序总的来说继承大于关联，关联大于依赖，具体强弱顺序如下：泛化 = 实现 > 组合 > 聚合 > 关联 > 依赖。
  

• 通常关联、聚合、组合只能配合语义，结合上下文才能够判断出来，只给出一段代码，通常是无法判断的。

• 我们要明白不是为了学类图而学类图，所以我们在掌握类图的表达形式后，应该多多实践和理解，与实际项目关联起来，收获才会更多。

• 我们一定要熟记类图关系的表示方法，这样我们在自己画类图或者看别人类图时，才能游刃有余，并且不会出现理解偏差。

06

—

UML类图实践

    这里小汪偷下懒，借用网上看到的一个实例，来帮助大家更好的理解下UML类图。如有问题可在评论区留言，共同探讨，共同学习。

场景：

用户通过登录界面(LoginForm)输入账号和密码，系统将输入的账号和密码与存储在数据库(User)表中的用户信息进行比较，验证用户输入是否正确，如果输入正确则进入主界面(MainForm)，否则提示“输入错误”。

类图：

类说明：

类 名	说 明
LoginForm	登录窗口，省略界面组件和按钮事件处理方法（边界类）
LoginBO	登录业务逻辑类，封装实现登录功能的业务逻辑（控制类）
IUserDAO	抽象数据访问类接口，声明对User表的数据操作方法，省略除查询外的其他方法（实体类）
UserDAO	具体数据访问类，实现对User表的数据操作方法，省略除查询外的其他方法（实体类）
MainForm	主窗口（边界类）