UML关联多重度与交互图解析：顺序图、协作图的应用与避坑

简介：《UML系统分析与设计复习试题详解》是一份面向软件工程、系统分析与设计课程学习者的复习资料，聚焦UML建模核心概念与应试要点，适合期末备考、考研复习及自学巩固。包体仅含1个doc文档，大小132KB，内容紧凑，便于快速查阅。文档从关联多重度、类关系组合、客户与订单实例、顺序图与协作图对比、高内聚度、UML图作用、四种基本关系到概念类识别与GRASP模式等十余个高频考点展开，每题附标准答案与简要解析，并包含构建销售场景的概念类联系、Use Case Diagram及SSD图绘制等实践题型。此外，还系统总结了UML类图、用例图、序列图、协作图等各类图形的作用与适用场景，以及依赖、关联、泛化、实现和聚集等关系类型的识别方法，能够帮助读者建立完整的UML知识体系，提升分析设计类题目的解题速度与准确率。目前已有405人学习，适合需要针对UML系统分析与设计强化练习与查漏补缺的用户。

1. UML 到底是什么：一张能看懂的软件施工图纸

你见过装修师傅手里那叠图纸吗？墙怎么敲、水管怎么走、插座装几个，都画得明明白白。UML（Unified Modeling Language，统一建模语言）就是软件世界的这套图纸：系统里有哪些对象，对象之间怎么联系，事情按什么顺序发生，都用统一规范的图形表达出来。

搞懂它有两个理由。第一，系统分析设计的考试题，几乎都围着这些图和概念转，比如关联的多重度、顺序图和协作图的区别；第二，在实际开发里，只有把模糊的“做个电商系统”翻译成一张张图，前后端同事才不会在联调时吵起来。

2. 关联的多重度：一个对象到底能“搭”几个对象

2.1 先从一道高频题说起：客户和订单

很多复习资料里都有一道几乎必出的选择题：UML 中关联的多重度是指什么？四个选项绕着“方法调用次数”“属性相同”打转，正确答案是B，一个类的实例能够与另一个类的多个实例相关联。

为什么这道题常考？因为它考的不是背概念，而是你是否理解“关联”的本质。在类图中，两个类之间画一条线，表示它们之间存在着某种结构性联系，比如客户下单、员工属于公司、订单包含订单行。多重度就是在这条线的两端标注数量关系：一个客户可以对应几个订单？一个订单可以对应几个客户？这是业务规则在模型上的直接体现。

再看一道变体题：一个客户提交0个或多个订单，一个订单由一个且仅由一个客户提交。问对应每个订单类的实例，存在几个客户类的实例；对应每个客户类的实例，存在几个订单类的实例。答案分别是1个（每个订单都有且只有一个客户）和0个或多个（有的客户可能还没下过单，有的下了很多单）。这里有个容易懵的点：题目先说“0个或多个订单”，所以很多人下意识觉得客户那端是0..*，但题目问的是“每个订单对应几个客户”，要站在订单的角度数客户，因此是“1”。站在哪一端数，答案就会完全不同。

多重度里的“多个”不一定是无限多，也可以是一个有限的范围。比如一个部门有2到4个主管，就写成2..4；一个员工可以暂时没有分配工位，就写成0..1。它表达的不是固定数字，而是一个允许出现的数量范围。

2.2 多重度符号怎么读：一张表记住所有写法

UML 的多重度写起来并不复杂，但考试和画图时经常要快速翻译。把常见写法整理成一张表，比死记定义快得多：

读这些符号有个小技巧：多重度标在关联线的哪一端，就表示“这一端的对象，被另一端的单个对象对应多少个”。比如客户和订单之间画一条线，订单端标1..*，意思是“一个客户可以对应1到多个订单”；客户端标1，意思是“一个订单恰好对应1个客户”。

这个技巧真正用起来时，卡点通常在“到底标在哪一端”。系统分析里有个很常见的例子：商品和订单行。业务说“一个订单行对应一个商品，一个商品会出现在多个订单行里”。画图时，关联线靠近商品那一端标1，靠近订单行那一端标1..*，读作：一个订单行对应一个商品，一个商品对应多个订单行。凡是写反的，几乎都是把业务句子里的主谓顺序直接搬到了图上。

提示：多重度只描述数量范围，不描述业务上“是否一定存在”。0..1 表示“可以有也可以没有”，1 表示“必须有且只有一个”。画图前先分清这两层意思，能少踩很多坑。

多重度也出现在领域模型里。有一道销售实例题，要求为概念类添加联系，答案里给了一组数字：a 是 1，b 是 1..，c 是 1，d 是 1..。这意味着一次销售记录必须关联一个收款员，一个收款员可以处理多笔销售；一次销售发生在一个收款台，一个收款台可以产生多笔销售。把多重度想成“谁拥有谁”的计数，这类题就变成了机械填数。

2.3 为什么总是写反：把一句话翻译成两个数字

“客户提交订单”这句话，正常人都会先想到“客户”是主体，于是顺手在客户那一端写了个大数字，结果一翻答案又错了。原因在于：多重度并不是描述“谁对谁做了什么”，而是描述“站在一个对象的视角，能看到对侧多少个对象”。

假如用代码来对应这个关系，体会会更直观。下面是一段用 Python 表达客户与订单关联的简化模型：

class Customer: def __init__(self, name): self.name = name self.orders = [] # 一个客户对应 0 个或多个订单 class Order: def __init__(self, order_id, customer): self.order_id = order_id self.customer = customer # 一个订单恰好对应 1 个客户

Customer 类里有一个订单列表，对应的就是客户端标着 *；Order 类里有一个 customer 字段，对应的就是订单端标着 1。看代码再看图，多重度其实就是在描述“这个类的对象，被另一个类的对象以什么数量持有”。

反过来说，如果不理解多重度，代码设计很容易写歪。最常见的翻车现场是把一对多写成一堆互相引用的列表：订单里存客户对象，客户里又存所有订单对象，看似灵活，实际上删数据、判空、序列化全是麻烦。先从图上把数量关系定清楚，代码结构才不会一开始就长歪。

另一个考点是把多重度和“方法调用次数”区分开。方法调用是运行时行为，今天调一次、明天调三次都有可能；多重度是结构上的关系约束，跟某个方法执行了几次没有关系。选项里出现“被另一个类调用的次数”这类说法，基本都是用来当干扰项的。

3. 交互图：顺序图和协作图，两种讲同一件事的方式

3.1 顺序图：一根从上到下的时间线

顺序图（Sequence Diagram）的核心是“时间顺序”。它把参与交互的对象一字排开，每个对象下面画一条竖直的生命线，消息从上方往下方发送，越靠上的消息发生得越早，越靠下的发生得越晚。读图时只要顺着生命线往下走，就能看懂一次业务过程里“先做什么、后做什么”。

复习材料里最常见的顺序图例题是销售场景：收款员启动一次销售，输入商品标识，销售结束系统计算并显示总金额，顾客付款，系统处理支付。用顺序图表示，大致是下面这段消息序列：

# 用注释模拟顺序图的消息时间线 收款员 -> 系统 : makeNewSale() # 1. 启动一次销售 收款员 -> 系统 : enterItem(itemID, quantity) # 2. 输入商品标识和数量 收款员 -> 系统 : endSale() # 3. 结束销售，系统计算总额 顾客 -> 系统 : makePayment(amount) # 4. 顾客付款 系统 -> 顾客 : 打印小票 # 5. 确认支付完成

从这个序列里能看到顺序图的两个特点。一是清晰：消息之间的先后关系一目了然，谁先激活谁、谁后响应谁，画出来比文字描述直观得多。二是费空间：对象一多，水平方向会拉得很宽，尤其消息数量大时，整张图又高又长，难以快速聚焦。

正因为它适合表现外部事件流，系统顺序图（SSD）也是用顺序图的思路画的。SSD 有什么特殊要求？复习题里有一道很经典的判断题：画 SSD 时应该怎样对待系统？正确答案是“不对系统的内部结构与功能进行描述”。SSD 把系统当成一个黑匣子，只画外部参与者向系统发消息，不画系统内部对象怎么协作。这跟“顺序图适合描述外部视角的事件流”是同一条逻辑。

3.2 协作图：一张按空间关系排座位的图

协作图（Collaboration Diagram，也叫通信图）和顺序图表达的是同一种交互，但观察角度完全不同。顺序图关心“时间线”，协作图关心“空间关系”：对象之间的关系用连线表示，消息则标在连线上，并用编号表示先后顺序。

打个比方：顺序图像一份会议议程，几点几分谁发言写得清清楚楚；协作图像一张会议室座位图，谁坐在谁旁边一目了然，同时每个座位上贴着发言顺序的便签。看顺序图，你首先注意到时间的推进；看协作图，你首先注意到对象之间怎么连接。

复习材料里有一个关键表述：协作图可视化地表示了对象之间随时间发生的交互，它除了展示对象之间的关联，还显示出对象之间的消息传递。与顺序图一样，协作图也展示对象之间的交互关系，但顺序图强调的是交互的时间顺序，协作图强调的是交互的语境和参与交互的对象的整体组织。

协作图有两个在题目里反复出现的优点：增加对象时比较容易，分支也比较少；但消息很多时，要按编号去对应顺序，读起来比较费劲。相反，顺序图可以清晰地表示消息之间的顺序和时间关系，但需要较多的水平方向空间。两者在表达力上是等价的，同一组交互既可以用顺序图画，也可以用协作图画，而且可以相互转换——这也是常见考题。

3.3 考试和设计里到底怎么选：三个判断标准

复习资料里对这两种图的定位有一句话：顺序图常常用于表示方案，协作图用于过程的详细设计。这句话背下来并不难，但实际画图时该怎么选？

判断依据可以浓缩为三条。第一，如果你要讲清楚“事件发生的先后次序”，比如给别的开发讲一次下单的完整流程，用顺序图；第二，如果你要强调“对象之间的关联结构”，比如让新同事快速了解哪些模块相互依赖，用协作图；第三，如果你已经有一张顺序图，下一步要设计每个对象的职责，可以停在这张图上逐个对象分配方法，没必要特意转成协作图。

题目里常见的填空是：___和___都是描述系统动态视图的交互图，其中___描述了以时间顺序组织的对象之间的交互活动，___强调收发消息的对象的组织结构。答案依次是顺序图、协作图、顺序图、协作图。简称：时间顺序选顺序，组织结构选协作。

另外要注意，交互图不等于用例图。用例图只画用户和系统功能的边界，不画步骤；交互图才画参与交互的对象和消息顺序。题目问“哪个图描述系统与外部系统及用户之间的交互”时，答案是用例图；问“哪个图按时间顺序描述对象间交互”时，答案是序列图。前者描述功能和边界，后者描述内部协作过程，两个考点经常挨在一起出，别选混。

4. 易混概念：UML 关系和各类图，别再把它们搅成一锅

4.1 四种基本关系：依赖、关联、泛化、实现，一句话各配一个例子

UML 的关系类型是另一类高频考点。四种基本关系分别是依赖、关联、泛化和实现，还有一类聚集（聚合），它是一种特殊的关联，表示整体与部分的关系。

• 依赖：一个类临时使用另一个类，比如订单类在计算总价时调用了折扣类的方法。这是最弱的关系，用带箭头的虚线表示。
• 关联：对象之间存在较稳定的结构连接，比如客户和订单，用实线表示。
• 泛化：继承关系，子类是一种父类，用带空心三角箭头的实线表示。
• 实现：类实现接口，类承诺了接口定义的行为，用带空心三角箭头的虚线表示。
• 聚集（聚合/组合）：整体与部分的关系，属于特殊关联。在关联线整体端加一个空心菱形是聚合，实心菱形是组合。

把五种关系放进一张表，记忆压力会小很多：

这里最容易混的是聚合和组合。同样是整体与部分，聚合表示部分可以脱离整体独立存在，比如课程和选修课程的学生，课程没了学生还在；组合表示部分的生命周期跟着整体走，比如订单和订单行，订单被删除，订单行通常也一起删除。素材里有一题：类 A 由类 B 的一个实类和类 C 的一个或多个实类构成，对应的是组合关系，因为 B 和 C 是 A 的组成部分，且与 A 同生共死。

4.2 类图、用例图、状态图、活动图、部署图：先分清结构图和行为图

UML 有十几种常用图，题目里经常挖空让你填“谁给静态设计视图、谁给动态视图”。先记住一个总纲：结构图描述静态方面，行为图描述动态方面，然后再往里面填图。

结构图描述系统的静态方面：类图说明静态设计视图，对象图是类图在某个时刻的实例快照，包图管理类的分组，构件图说明静态实现视图（源代码、可执行文件等），部署图说明体系结构的静态实施视图（物理节点、网络布局）。

行为图描述系统的动态方面：用例图描述系统与外部系统及用户之间的交互，顺序图和协作图描述对象间交互，状态图展示一个特定对象的所有可能状态以及事件引起的状态转移，活动图描述需要做的活动和执行顺序。

对应到真题：给出系统静态设计视图的是类图；对系统的行为组织和建模非常重要的是用例图；描述系统与外部系统及用户之间交互的是用例图；按时间顺序描述对象间交互的是顺序图。还有一个容易漏的点：当需要说明静态实现视图时选构件图，当需要说明体系结构静态实施视图时选部署图。类图管设计，构件图管实现，部署图管物理分布，三者别串。

状态图和活动图也经常放在一起考。状态图针对一个对象，描述它的生命周期里有哪些状态，比如订单从“待支付”到“已支付”再到“已发货”；活动图针对一段工作流，描述多个活动之间的执行顺序和并行关系。一句话：状态图看“一个对象的一生”，活动图看“一堆任务的流程”。

提示：做题时先把题目问的范围圈出来。“静态”看结构图，“动态”看行为图；交互的“时间顺序”归顺序图，“组织结构”归协作图。

4.3 五个最容易踩的坑：易混点、为什么混、怎么区分

坑一：把多重度当成方法调用次数。选择题的干扰项常说“一个类的某个方法被另一个类调用的次数”，很多人觉得“有关系数量”就选了。其实多重度讲的是实例之间的关联数量，方法调用是运行时行为，完全不在一层。区分的办法是看主语：题干问“实例与实例相关联”还是“方法被调用”，前者才是多重度。

坑二：把用例图当作流程图。用例图只是画“谁（Actor）能用系统的哪个功能（Use Case）”，比如电话用户和“使用电话卡”“对方付款”两个用例。它不画操作步骤，也不画界面跳转。顺序图才画步骤。看到“描述系统与外部系统及用户之间的交互”选用例图，看到“按时间顺序描述对象间交互”选顺序图。

坑三：把对象图当成类图的另一种画法。类图描述类及类之间的关系，对象图描述某一时刻具体对象及其关系的快照。类图是一张类型说明书，对象图是一张现场照片。题目里说“对象图表达系统静态设计视图或静态过程视图，反映实例的数据结构和静态快照”，指的就是这个区别。

坑四：聚合和组合都叫“聚集”，于是统一当成普通关联。区分要点是生命周期：部分不能脱离整体而存在，就是组合；可以脱离，就是聚合。画图时看菱形，实心菱形是组合，空心菱形是聚合。这个细节在“类 A 由类 B 的一个实类和类 C 的 1 个或多个实类构成”这类题里，直接决定答案。

坑五：画 SSD 时忍不住描述系统内部。系统顺序图把一个待开发系统当作黑匣子，只画外部参与者向系统发消息。考试题里“详细描述内部结构”“罗列所有功能”都是错误项，正确态度是“不对系统的内部结构与功能进行描述”。这就是为什么 SSD 能快速表达需求，而不是陷入实现细节。

5. 高内聚、GRASP、设计模式：让每一个类都“各司其职”

5.1 高内聚度：一个类到底该管多少事

复习题里“什么是高内聚度”是简答常客。标准说法是：高内聚度是对一个类中的各个职责之间相关程度和集中程度的度量。一个具有高度相关职责的类，并且这个类所能完成的工作量不是特别巨大，它就具有高内聚度。

用大白话翻译：类里的方法应该都围绕同一个主题，而且别让一个类背太多活。计算订单价格的类，就不该同时负责读写数据库、发送短信、渲染页面。这样做好处很明显：第一，改一个需求时，受影响的代码集中在少数类里；第二，类可以独立测试；第三，将来要复用某个功能，拖走一个类就行。

低内聚是什么感觉？打个比方，一个工具箱里塞了扳手、菜刀、牙刷和充电器，看起来什么都能干，但每次找工具都要翻半天，而且换一个工具可能影响其他工具的摆放。代码里这种类被称为“上帝类”，初学阶段很容易写出来，等改到崩溃时才意识到问题。

复习材料里对高内聚还有两句补充：不要给一个类分派太多的职责，在履行职责时尽量将部分职责分派给有能力完成的其它类去完成；不相关的职责不要分派给同一个类。这两句话其实也指向了 GRASP 的另一个模式——低耦合。高内聚是类内部的事，低耦合是类之间的事，它们是一枚硬币的两面：类内部职责聚拢，类之间的依赖自然减少。

5.2 GRASP：把“谁来干活”变成一组可复用的原则

GRASP 是“分配职责中通用原则的模式”的缩写，解决的核心问题只有一个：某个职责到底该分配给哪个类？复习材料里列了五个模式，每个模式对应一个经典问题。

信息专家很好理解，比如计算订单总价，谁最知道商品单价和数量？订单自己或订单行的信息。于是把计算职责交给订单类，而不是让收款员类去手工拼数据。创建者则解决“new 谁”的问题：一个订单行应该由谁来创建？跟它关系最密切的订单来创建，而不是让一个不相干的全局工具类去 new。

控制器模式在系统分析里格外重要，因为它对应 SSD 图中的那个“系统黑盒”。外部参与者发出的每个系统事件，比如 makeNewSale、enterItem、endSale，都需要一个对象来接收和处理，这个对象就是控制器。它像前台接待，把客户需求登记下来，再转给后面真正干活的类。考试里问“谁来负责处理一个输入系统事件”，答案就是控制器。

题目里有一类是“下面哪个不属于 GRASP 模式”，选项中混入 GoF 这类设计模式名。区分方法很简单：GRASP 是职责分配层面的原则，回答“谁该干活”；GoF 是具体实现层面的设计模式，回答“代码怎么组织”。两者层次不同，不要当成一回事。

5.3 设计模式速记：单例、策略、组合、观察者、适配器

设计模式的概念题通常这样定义：富有经验的面向对象专家设计的、作为通用原则和惯用法的解决方案，用于指导软件设计；如果把它们按问题和解决方案描述的结构形式编篡并起一个名字，这就是设计模式。换句话说，设计模式是“遇到什么问题，用什么套路解决”的清单。

复习材料里常考五个模式，可以按“问题到方案”来记：

单例模式解决“如何让一个类严格只有唯一实例”的问题，方案是定义一个静态的返回单例的类方法。系统配置类全程只有一个实例，就是典型的单例。

策略模式解决“设计一种方案适应算法或规则频繁变更”的问题，方案是把每个算法封装成具有公共接口的类，运行时互相替换。计费规则今天按件、明天按重量，就分别写成不同的策略类。

组合模式解决“希望按处理原子对象的方式来处理组合对象”的问题，方案是让组合对象和原子对象实现相同的接口。一个目录既包含文件又包含子目录，无论操作单个文件还是整个目录，调用方式都一致。

观察者模式解决“如何维护对象之间一致性”的问题，方案是当一个对象的状态发生变化时，所有依赖于它的对象都得到通知并被自动更新。购物车数量变了，页面上多个角落的合计数字都要跟着更新，观察者模式让这些角落自动刷新。

适配器模式解决“不兼容的接口如何转成稳定接口”的问题，方案是通过一个中间的适配器对象，使一个组件的原有接口转变成另一个接口。新老系统对接时，不需要改老代码，只需要包一层适配器。

记住这些模式后，还要避免另一种迷思：设计模式不是银弹，不是每个类都要套一个模式。判断题和案例题里常说“某个场景最适合用哪个模式”，这需要看问题特征，而不是背模式名。题目强调“状态变化要通知多方”，才选观察者；强调“算法可替换”，才选策略。模式和 UML 图一样，都是服务于解决问题的工具。

6. 什么时候该画 UML，什么时候别迷信图纸：一个老开发的边界

统一过程（UP）把项目分成四个阶段：初始阶段、细化阶段、构造阶段、提交阶段。初始阶段做愿景文档、业务案例、确定范围和粗略评估成本；细化阶段细化愿景、迭代实现核心架构、解决高风险问题、定义大多数需求和范围；构造阶段迭代实现其余部分、准备部署；提交阶段做 beta 测试和部署。考题里“定义大多数需求和范围”的活儿，记住是细化阶段，不在初始阶段。UP 的核心思想还有一句：短时间盒的迭代式开发，早期解决高风险问题，不断与用户衔接。图在这个过程中是沟通工具，不是流程仪式。

那是不是每个项目每个阶段都要把所有图画一遍？不是。UML 的价值在于把模糊的需求变成可讨论的模型，它不是交付物。什么时候该画：需求多而且参与方多的时候，用用例图和领域模型对齐认知；类职责容易扯皮的时候，先用顺序图画一遍消息传递，再逐个类分配方法；交互复杂、时间顺序容易错的时候，顺序图比文字描述可靠得多。

什么时候别画：只有几十行的脚本，画图成本大于收益；需求每天都在变，先画一堆部署图、构件图只会让图迅速过期；团队把图当成“交差作业”，画完再也不看，那不如不画。换句话说，图是沟通工具，不是存档文件。

我曾在一个小组项目里吃过亏：模块之间约定全靠口头，联调时才发现两个服务之间消息顺序反了，A 等 B 的结果，B 等 A 的通知。从那以后我每次排复杂交互，都强制先画一张顺序图，哪怕只是草草地画在纸上。一张图能替下三小时的争论。希望帮到你。

本文还有配套的精品资源，点击获取