UML分析与设计

参考资料：

九种常见UML图（分类+图解） - HZX↑ - 博客园

UML科普文，一篇文章掌握14种UML图 - 知乎

『这就是UML！』系列内容第8讲：协作图 - ProcessOn知识社区

『这就是UML！』系列内容第6讲：类图 - ProcessOn知识社区

『这就是UML！』系列内容第10讲：活动图 - ProcessOn知识社区

『这就是UML！』系列内容第4讲：用例图 - ProcessOn知识社区

『这就是UML！』系列内容第9讲：状态图 - ProcessOn知识社区

『这就是UML！』系列内容第7讲：时序图 - ProcessOn知识社区

UML学习文档（一）_uml文档-CSDN博客

UML学习文档（二）_uml 语法文档-CSDN博客

一、 UML核心速记

1.1 “4+1”视图（架构设计的灵魂）

UML并不是随便画图的，它是用来描述软件架构的。

业界公认的“4+1”视图模型，你需要知道每个视图用什么图来表达：

用例视图（+1，核心驱动）

从外部用户的角度看系统。

代表图：用例图。

它驱动了其他四个视图的开发。

逻辑视图（系统内部结构）

系统的静态结构和动态行为。

代表图：类图、对象图、状态图、顺序图。

实现视图/开发视图（程序员视角）

系统的物理代码结构。

代表图：构件图。

进程视图（并发与性能）

关注系统的并发性、同步、性能。

代表图：活动图（带泳道和分叉时）、顺序图。

部署视图/物理视图（运维视角）

软件到硬件的映射。

代表图：部署图。

1.2 UML图与开发阶段的映射关系

需求阶段

用例图（捕捉用户需求，这是唯一的产出）。

分析/设计阶段

类图（静态结构）、顺序图/通信图（对象间交互）、状态图（单个对象生命周期）、活动图（业务流程/算法流程）。

实现阶段

构件图（代码打包成组件）、包图（代码模块划分）。

部署阶段

部署图（服务器、网络拓扑）。

二、静态结构建模

静态图描述的是系统的“骨架”，不随时间变化。

2.1 类图与对象图

对象图

类图在某一时刻的“快照”（实例化）。

类图有类名，对象图的名字下面必须带下划线（如张三: Person）。

类图

类的四大核心关系

这四种关系的耦合度从弱到强依次为：

依赖 ➡️ 关联 ➡️ 泛化 ➡️ 实现。

依赖—— 虚线箭头 - - - ->

语义：临时用了一下，用完就散了。

代码体现：方法的参数、局部变量。

例子：人过河，依赖船。Person 类的方法 crossRiver(Boat b)，人就依赖了船。

关联—— 实线箭头 ——> （双向则无箭头）

语义：长期的拥有关系，通常作为类的属性存在。

代码体现：类的成员变量。

例子：学生和课程。学生选了课，这个关系要存起来，所以学生类里有 List<Course> 属性。

关联多重性

在连线两端写数字。

1（只有一个）

0..1（可选）

或 0..（零到多个）

1..（一到多个）。

比如：一个学生可以选 0.. 门课，一门课可以被 1.. 个学生选。

泛化/继承—— 实线空心三角箭头 ——▷ （箭头指向父类）

语义：is-a 关系。

例子：鸟和燕子，燕子指向鸟。

实现—— 虚线空心三角箭头 - - -▷ （箭头指向接口）

语义：实现接口里的方法。

例子：飞行接口和燕子，燕子实现飞行接口，燕子指向飞行接口。

聚合——空心菱形指向整体

语义：整体与部分的关系，且部分可以离开整体而单独存在。

聚合关系是关联关系的一种，是强的关联关系。

组合——实心菱形指向整体

语义：一种整体与部分的关系，但部分不能离开整体而单独存在。

组合关系是关联关系的一种，是比聚合关系还要强的关系。

2.2 包图（管理复杂度）

作用

像Windows的文件夹一样，把相关的类、接口打包装进一个包里。

依赖原则

如果包A里的类用到了包B里的类，就说A依赖B。

要尽量避免循环依赖（A依赖B，B又依赖A）。

导入与访问

import（导入）

不仅看到，还把里面的名字引入到当前命名空间（可以直接用类名）。

access（访问）

只能看到，不能用简名，必须带包名路径（类似Java的完全限定名）。

2.3 构件图（代码级别的物理模块）

提供接口

构件旁边画一条实线，顶端连着一个小圆圈（lollipop，棒棒糖）。表示“我能给别人提供什么服务”。

请求接口

构件旁边画一条实线，顶端连着一个半圆（socket，插座）。表示“我需要别人给我提供什么服务”。

2.4 部署图（软硬件映射）

节点

立体的长方体（代表服务器、电脑、打印机等硬件）。

制品

节点里面画的普通矩形（代表部署在上面的.jar、.exe文件、数据库等）。

通信关联

节点之间的实线，表示网络连接（可以写上协议，如 TCP/IP、HTTP）。

三、动态行为建模

动态图描述的是系统的“动作”，随时间发生变化。

3.1 用例图

用例图由三部分组成：

-系统边界（大方框）

-参与者（小人）

-用例（椭圆）

包含与扩展

这两个关系长得极像，都是虚线箭头，箭头上分别写着<<include>>和<<extend>>。

核心区别在于：谁是主导？箭头往哪指？

包含关系 <<include>>

语义：基础用例必须用到被包含用例。被包含用例是基础用例的“必经之路”或“公共子流程”。

箭头方向：从基础用例指向被包含用例。

例题套路：

“用户登录时，必须包含身份验证”。

箭头：[用户登录] - - -> [身份验证]。

扩展关系 <<extend>>

语义：基础用例在特定条件下，可选地触发扩展用例。扩展用例通常是处理“异常分支”或“可选高级功能”。

箭头方向：从扩展用例指向基础用例！

（千万别记反了！因为扩展用例是“寄生”在基础用例上的，它要去“依附”基础用例）。

例题套路：

“在支付用例中，如果余额不足，则扩展出【提示充值】用例”。

箭头：[提示充值] - - -> [支付]。

泛化关系

用例之间也可以有继承。

比如“线上支付”和“线下支付”泛化出“支付”。

实线空心三角指向“支付”。

3.2 交互图（描述对象之间发消息）

交互图分为两种，它们表达的信息完全一样，只是侧重点不同。

1. 顺序图/时序图

顶部一排对象（:ObjectA），每个对象下面垂下一根虚线（生命线）。

生命线上的细长矩形叫激活期（表示对象正在执行代码，没激活就是空闲）。

同步消息

实心箭头 ▶。

表示调用者发消息后，停在那里等，必须等接收者干完活返回后，调用者才继续往下走。（类似打电话，必须等对方接听）。

异步消息

开放式箭头 > （只有线，没有实心三角）。

表示调用者发完消息就接着干自己的事了，不管接收者死活。（类似发微信）。

返回消息

虚线开放式箭头 > （虚线）。

表示接收者处理完毕，把结果还给调用者。

2. 通信图（原协作图）

一堆对象散落在纸上，对象之间有实线连接（链接），连线上画箭头写消息，旁边标上序号（1, 1.1, 1.2）表示顺序。

它不画生命线，看不出谁先谁后的直观时间感，但能清楚看出哪些对象之间有物理连接（空间结构）。

3.3 状态图（状态机图）

适用场景

当一个对象在不同条件下会有多种状态，且状态之间会来回切换时。

比如：订单（待支付、已支付、已发货、已签收）、电梯（开门、关门、上行、下行）。

基本元素

初始状态：实心圆点 ●。

结束状态：圆圈套实心点 ◎。

状态：圆角矩形。

状态转移线的语法

转移线上必须写：事件 [条件] / 动作

发生了什么“事件”，在什么“条件”下，执行了什么“动作”，然后切换到下一个状态。

例子：

[密码正确] / 开门。

这里没有写事件，说明是系统内部判断。

如果是读卡 / [密码正确] / 开门，读卡就是事件。

3.4 活动图（流程图升级版）

本质：它就是带了泳道的流程图。

状态图看“状态”，活动图看“动作”。

与流程图的区别：活动图有并发的表示方法。

分叉与汇合（粗黑线）

一条粗黑线进入，分出多条箭头出去，叫分叉，表示后面的动作可以同时并发执行。

多条箭头汇聚到一条粗黑线，再出去一条箭头，叫汇合，表示必须等待所有并发分支都执行完，才继续往下走。

避坑：
分叉和汇合必须成对出现！
且分叉出去几条，汇合就必须收几条。
这和流程图里简单的菱形判断框完全不同。

泳道

把活动图用竖线或横线切成几块，每块写上部门或角色名，用来明确“这个动作具体是谁干的”。