UML系统分析与设计复习：知识地图、多重度与设计模式考点

简介：这份资料是面向计算机专业学生与软件开发初学者的UML系统分析与设计复习试题文档，用于备考与知识梳理，适合正在学习面向对象建模、准备课程考试或面试复习的人群使用。内容围绕关联多重度、类之间的组合与聚合关系、客户与订单的数量对应、顺序图与协作图的差异、高内聚低耦合、用例图与类图的静态动态视图划分、对象间可见性、领域模型与概念类识别、GRASP职责分配模式及统一过程四阶段等核心考点展开，每道题均配有答案解析与画图思路，可直接对照查漏补缺。资源共1个doc文件，压缩包约132KB，体积轻便，便于离线阅读与打印。目前已有406人学习，适合作为UML考前冲刺与建模方法复盘的辅助材料。

1. UML系统分析与设计复习：先把知识地图铺开

UML 这张图很多人背得很熟，一到“给业务陈述，问多重度”就卡壳。原因不在记性，而在这门课的考点本来就是两条线交织：一条是建模产物（类图、用例图、顺序图、协作图、状态图、活动图、构件图、部署图），另一条是设计原则与模式（内聚耦合、GRASP、GoF、UP 阶段）。复习试题翻下来会发现，选择题爱考“哪张图干什么用”，大题爱考“给场景画图、给关系填多重度”，简答题则反复回到高内聚、可见性、领域模型这些概念。这份笔记按知识地图、逐模块要点、易漏点、最后落到复习清单的顺序梳理，适合正在系统学这门课、或者临考想把散点串成网的人。

2. 结构建模：类图、关系与多重度是选择题重灾区

结构建模是整门课的地基，考试里分值未必最高，但错得最冤。类图考的不是“会不会画个方框”，而是关系语义和多重度这两件事能不能落到业务句子上。

2.1 四种关系加一种特殊关联，先把定义钉死

UML 里常说的关系有依赖、关联、泛化、实现四种，聚集（聚合）是关联的一种特殊形态。这几个词在题干里经常混着出现，认错一个整道题就废。

题目里“类 A 由类 B 的一个实例和类 C 的一个或多个实例构成”，关键词是“构成”。如果 B、C 是 A 的组成部分且随 A 一起消亡，就是组合；如果 C 能被别的整体共享，就往聚合上靠。做题时先判断“部分能不能脱离整体活着”，再决定菱形是空心还是实心，这一步比背图形有效。

2.2 多重度：把业务句子翻译成数字区间

多重度是失分最集中的地方，因为它考的是阅读理解和建模习惯，不是记忆。核心口诀只有一句：多重度写在被指向的那一端，表示“对方的一个实例对应我这边多少个实例”。

以客户与订单为例：一个客户提交 0 个或多个订单；一个订单由一个且仅由一个客户提交。于是：

• 订单端看客户：每个订单实例对应1 个客户实例；
• 客户端看订单：每个客户实例对应0 个或多个订单实例。

客户 1 ―――――――― 0..* 订单 (一个订单必属于一个客户) (一个客户可无单也可多单)

书写顺序上，靠近“客户”那一端的数字描述的是订单数量，靠近“订单”那一端的数字描述的是客户数量，这一点和直觉相反，也是绝大多数人填反的地方。常见取值的含义要吃透：1表示恰好一个，0..1表示可选的一个，1..*表示至少一个，0..*或*表示任意个。判断题里出现“1 个或多个”和“0 个或多个”的选项，本质上就是在区分“是否允许为空”。

2.3 找概念类：两条策略和一次筛选

领域模型描述的是真实世界中的概念类，不是软件部件，这个区分几乎是必考的一句话。找概念类有两条现成策略：一是查概念类类别表（人、地点、事物、事件、组织等），二是从需求文本里标识名词短语。

以收银场景为例：顾客带着商品来到收款台，收款员启动一次销售，输入商品标识，系统显示说明与价格并计算总额。名词短语筛下来得到顾客、收款台、收款员、销售、商品标识、商品、商品说明。接下来要做减法：商品说明是商品的属性还是独立概念？如果它有独立的生命周期和多条记录，就保留为类；如果只是商品的若干字段，就降级成属性。这一步是“是什么”和“重点在哪”的分界：概念类识别不难，难在是否该把候选名词提升为类。

3. 行为建模：用例、交互图与状态机怎么选

行为建模的考点集中在两张图上：用例图负责边界，顺序图和协作图负责交互。考试喜欢把几种图的功能打乱让你配对，所以每张图要有一个“一句话定位”。

3.1 用例图：系统边界与参与者的关系

用例图描述系统与外部系统及用户之间的交互，是需求阶段的核心产物。参与者（actor）是系统外部与系统交互的角色，不一定是人，也可以是外部系统；用例描述的是一个参与者使用系统完成某个业务过程时的事件发生顺序，它定义系统责任，不描述系统内部怎么实现。

用况的描述有 brief、casual、fully dressed 三种详略程度，考试里问“用况描述方式”时按这三档答。场景（scenario）是用况的一个具体实例，是用况的一条执行路径。以电话卡场景为例，参与者是电话用户，用例包括“使用电话卡打电话”和“对方付款打电话”，画图时只画参与者和用例以及它们之间的关联，不要把内部流程画进去。

一个高频判断题：用例图用于按时间顺序描述对象间交互吗？不是，那是顺序图。这类“张冠李戴”的选项几乎每套题都有。

3.2 顺序图与协作图：一个看时间，一个看结构

两张图都是交互图，描述的都是对象之间的消息传递，区别在布图逻辑。

协作图里消息的时间顺序靠消息编号表示，这是填空常客。两者可以相互转换，转换时把编号顺序对应到顺序图的纵向位置即可。

顺序图示意（收银）： 收款员 -> 系统 : makeNewSale() 收款员 -> 系统 : enterItem(itemID, quantity) 收款员 -> 系统 : endSale() 顾客 -> 系统 : makePayment(amount)

这四个操作对应系统顺序图（SSD）的典型画法：把系统当成一个黑盒，只画参与者和系统之间的输入事件，不描述系统内部结构与功能。这一条几乎年年出选择题，选项里凡是“详细描述系统内部结构”的都是错的。

3.3 其余几张图的一句话定位

状态图展示一个特定对象的所有可能状态以及事件引起的状态转移，适合给接口、类或协作的行为建模，也用来描述用况实例的生命周期。活动图是特殊的状态图，描述需要做的活动及其执行顺序，强调控制流，高层活动图用于分析用况与业务流程，低层用于描述类的方法；但它不适合描述动作与对象的关系。构件图描述构件之间的组织与依赖，用于对源代码、可执行发布、物理数据库建模；部署图描述运行时处理节点及构件在节点上的分布，说明系统的物理拓扑与静态实施视图。

配对题常用这三句：说明静态设计视图选类图，说明静态实现视图选构件图，说明体系结构静态实施视图选部署图。

4. 设计原则与模式：内聚耦合、GRASP 与 GoF 的分层

这一块是简答题的主战场，也是很多人背了却答不全的地方。原因是没有分层：职责分配原则（GRASP）解决“职责给谁”，GoF 解决“常见结构怎么复用”，两条线不能混着答。

4.1 高内聚与低耦合：一对要一起答的概念

高内聚是对一个类中各个职责之间相关程度和集中程度的度量。一个类职责高度相关、且完成的工作量不是特别巨大，就具有高内聚。它包含两层意思：不要给一个类分派太多职责，履行时尽量把部分职责分派给更有能力完成的类；不相关的职责不要塞进同一个类。

低耦合解决的是如何支持低依赖关系、增加重用。答题时把两者绑在一起写：高内聚让类内部稳定，低耦合让类之间独立，二者共同把复杂度控制在可管理的范围内。只答一句“高内聚就是职责单一”通常拿不到全分。

4.2 GRASP 五个模式：模式名加解决的问题

GRASP 是通用职责分配原则，考试要求的是“模式名 + 它解决什么问题”这个配对。

判断题常挖的坑是“以下哪个不属于 GRASP 模式”，答案往往落在 GoF 的模式名上，比如多态、纯虚构、中介、间接性都是 GRASP，而工厂方法、单例属于 GoF。这个边界要划清楚。

4.3 GoF 常用模式：问题与解决方案成对记

设计模式是经验丰富的面向对象设计者给出的、作为通用原则和惯用法的解决方案；把问题与解决方案按结构形式整理并命名，就是模式。考试常考这几个：

• 单例：如何使一个类严格只有一个实例？定义静态方法返回唯一实例。
• 策略：如何适应算法或规则的频繁变更？把每个算法封装成实现同一接口的类，可互相替换。
• 组合：希望按处理原子对象的方式处理组合对象？组合对象与原子对象实现相同接口。
• 观察者：如何维护对象之间的一致性？状态变化时通知所有依赖它的对象并自动更新。
• 适配器：如何解决接口不兼容？用中间适配器对象把原接口转成目标接口。
• 工厂方法与抽象工厂：把对象创建延迟到子类（工厂方法），或创建一系列相关对象（抽象工厂）。

# 策略模式的最小骨架：算法可替换，调用方不关心具体实现 class PricingStrategy: def price(self, base): ... class NormalPricing(PricingStrategy): def price(self, base): return base class DiscountPricing(PricingStrategy): def price(self, base): return base * 0.8 class Sale: def __init__(self, strategy): self.strategy = strategy # 注入策略 def total(self, base): return self.strategy.price(base) # 委托计算

这段代码示范的是“面向接口编程”如何落到类图上：Sale 依赖 PricingStrategy 接口，而不依赖具体计价规则，新增规则时只加类不改 Sale，这正是开闭原则想表达的东西——对扩展开放、对修改关闭。答题时把“新增算法不修改原有类”这句话点上，比空谈定义得分高。

4.4 UP 四阶段与核心工作流

统一过程的四个阶段是初始、细化、构造、提交。初始阶段做愿景文档、业务案例、确定范围、粗略评估成本；细化阶段细化愿景、迭代实现核心架构、解决高风险问题、定义大多数的需求和范围、进一步评估成本；构造阶段迭代实现其余部分并准备部署；提交阶段做 beta 测试与部署。

这里最易混的一题是“定义大多数需求和范围在哪个阶段完成”，答案是细化阶段，不是初始阶段；反过来问“下列哪项不在初始阶段完成”，答案就是“定义大多数需求”。UP 的核心思想包括短时间盒的迭代开发、早期迭代解决高风险高价值问题、持续与用户衔接获取反馈、早期构造核心架构、早期进入实现与测试、用用例驱动并以 UML 可视化建模、仔细管理需求控制变更。增量开发则有两层含义：复杂用况分多次迭代实现，全部用况按优先级安排到不同迭代。

5. 易错点清单：五个翻车频率最高的地方

5.1 易错点一：多重度写反

为什么错：习惯性把“一个客户多个订单”直接写成客户端为1，忽略多重度标注的是对端实例数。怎么补：每写一个数字前先默念一遍“站在我这个类的一个实例上，能看到对方几个实例”，填完再反读一次检验。

5.2 易错点二：聚合与组合混用

为什么错：两者图形只差菱形空心实心，语义差别却在生命周期。怎么补：判断“整体销毁时部分是否一起消失”，是则组合，否则聚合；再判断部分能否被多个整体共享，可共享则更偏聚合。

5.3 易错点三：顺序图与协作图的适用场景颠倒

为什么错：两者都能描述交互，只记“一个看时间一个看结构”不够，题目会给具体情境问选哪个。怎么补：记住顺序图用于表示方案、协作图用于过程详细设计；消息多选顺序图，对象关系复杂选协作图，协作图的时间顺序靠编号。

5.4 易错点四：SSD 里画了系统内部

为什么错：画图时手痒，把内部类和流程一并画上。怎么补：SSD 的系统是黑盒、是单一对象，只有参与者和系统之间的输入事件；操作契约才描述操作执行后领域对象状态的变化，两者分工不同。

5.5 易错点五：GRASP 与 GoF 混答

为什么错：都以“模式”命名，答题时容易把工厂方法塞进 GRASP 五点里。怎么补：GRASP 记五个名字（信息专家、创建者、低耦合、高内聚、控制器），多态、纯虚构、中介属于 GRASP 扩展项但不在五点之列；GoF 记问题与解法成对，两者分栏背诵。

6. 复习清单：考前一周怎么把散点收成网

第一轮按“图”扫一遍，目标是看到图名能说出定位句。把八种图摆在一起，各写一句：类图——静态设计视图；对象图——某一时刻的对象快照；用例图——系统与外部参与者的交互；顺序图——按时间顺序的对象交互；协作图——强调对象组织结构、时间靠编号；状态图——单对象状态与转移；活动图——活动与控制流，适合流程与并行；构件图——构件组织与依赖，静态实现视图；部署图——节点与构件分布，静态实施视图。写完遮住再默写一遍，错的那张单独抄三遍。

第二轮按“关系与多重度”做专项。把所有涉及客户、订单、销售、商品这类业务陈述的题目集中做，每道题强制写出“站在哪一端看哪一端”，画出简短连线再对答案。这一轮不要贪多，二十道题做透胜过一百道扫过。

第三轮做模式配对卡：正面写“如何适应算法频繁变更”，背面写“策略”，正反面各二十张，通勤路上过。第四轮把 UP 四阶段做成阶段与产物的对照：初始—愿景与业务案例，细化—核心架构与多数需求，构造—其余实现与部署准备，提交—beta 测试与部署。第五轮练简答，重点压在高内聚、可见性、领域模型与软件部件的区别、用况与场景与参与者的定义、愿景文档内容这几道，每题限时五分钟手写。

最后补一句我自己的血泪经验：多重度这类题，看答案觉得懂了不算懂，必须动手画。我第一遍复习就是光看题不做图，考场上遇到“a、b、c、d 分别填什么”的销售实例题，脑子里的连线全糊成一团。从那以后我每次碰到业务陈述题，都强制先在草稿纸上画一条线、标两个数字、再反读一遍语义，才允许自己看选项。希望帮到你。

这套复习试题的价值就在于它把考点按题型排布好了：选择题覆盖图的定位与关系语义，填空题锁定多重度与消息编号，简答与画图题压住 GRASP、设计模式和 UP 阶段。按上面五轮走完，再回头刷这份题，会发现错的题基本都落在第 5 章那五个坑里，照着补就行。

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