企业官网建设流程全解析

简介：一份针对 UML 系统分析与设计课程的复习试题文档，面向正在备考软件工程、系统分析相关考试的学生，以及需要快速巩固 UML 核心概念的设计人员。资料以 doc 格式整理，压缩包内仅含 1 个文件，大小约 132KB，内容包括关联多重度、组合与聚合、顺序图与协作图的差别、高内聚度、用例图、领域模型、UML 四种基本关系、可见性、统一过程阶段、GRASP 模式、FURPS 需求分类等高频考点。每题均附有参考答案或解析，并配有客户与订单多重度判断、电话用户用例图、销售场景概念类识别、SSD 图绘制等典型例题，能够帮助读者一边练习一边理解建模思路。目前已有 404 人浏览学习，适合考前集中冲刺与查漏补缺，也是自学者检验 UML 掌握程度的实用练习包。

1. UML 复习试题到底在考什么：不是画图，是建模思维

很多人在 UML 系统分析与设计这门课上栽跟头，不是不会画图，而是看不懂题目在问什么。比如一道题给出一段业务描述「一个客户提交 0 个或多个订单」，让你选多重度——四个选项全是「0 个、1 个、1 个或多个、0 个或多个」，看起来像语文阅读理解，实际考的是你对类之间数量约束的理解。这份复习试题覆盖了类图多重度、顺序图与协作图对比、GRASP 职责分配、设计模式辨析、统一过程阶段划分这几个核心板块，题型包含选择、填空和简答，适合期末冲刺、软考复习以及系统设计面试前用来查漏补缺。我的建议是：不要按顺序刷，按「静态建模 → 动态建模 → 职责分配 → 开发流程」这个链路来拆，效果完全不一样。

2. 把多重度相关试题一次吃透：从题干翻译到类图画法

2.1 多重度题干翻译：先确定「站在谁的实例上看」

多重度可以说是 UML 试题里白给分也最容易丢分的点。题目原文有一个很典型的考法：「对应每个订单类的实例，存在____客户类的实例；对应每个客户类的实例，存在____个订单类的实例」，给四个选项让你填。这道题难在它把视角来回切换。

我做这类题的习惯是先在草稿纸上画一条关联线，然后从一端往另一端看。题干说「一个客户提交 0 个或多个订单」——这就是站在客户侧的描述，说明每个客户对应多个订单；「一个订单由一个且仅由一个客户提交」——这是站在订单侧的描述，说明每个订单只归属一个客户。翻译成多重度标在关联线上：客户 1 ———— * 订单，也就是 1 端在客户类上，* 端在订单类上。

那么「对应每个订单类的实例，存在多少个客户类的实例」——从订单侧看过去，答案是 1 个，选 B；「对应每个客户类的实例，存在多少个订单类的实例」——从客户侧看过去，答案是 0 个或多个，选 D。这套视角切换法适用于所有类似考题，遇到「每个 A 有若干 B」「每个 B 属于一个 A」的描述，先分清主体，再写多重度。

多重度符号的含义也值得列一下，考填空和选择都用得上：

2.2 组合与聚合的判别：看部分能不能脱离整体独立存活

试题里有一道很经典的画图题：「已知三个类 A、B 和 C，其中类 A 由类 B 的一个实例和类 C 的 1 个或多个实例构成，请画出正确表示类 A、B 和 C 之间关系的 UML 类图」。

这里涉及一个容易混淆的知识点：组合（Composition）和聚合（Aggregation）都是整体-部分关系，但生命周期约束不同。组合是强拥有关系，部分和整体同生共死；聚合是弱拥有关系，部分可以先于整体存在或脱离整体独立存活。题目说 A 由 B 的实例构成，通常就是组合关系——菱形实心画在 A 这一端，B 端标 1，C 端标 1..*。很多参考答案里把 B 和 C 都画成组合是因为「构成」这个词本身就隐含了不可分割。

实际做题时有一个判断标准：删除整体后，部分还有没有存在的意义？比如「订单包含订单项」，订单删了，订单项没有存在价值，就是组合；「班级包含学生」，班级删了，学生依然存在，是聚合。试题里如果只写「由……构成」，优先按组合处理，除非题目明确说「部分可以独立存在」。

2.3 四种关系图示判定：依赖、关联、泛化、实现

试题里给了一组图配上四种关系名称的连线题，其实考点就一句话：看箭头和线型。UML 里四种基本关系是依赖、关联、泛化和实现，再加上聚集这种特殊关联，总共有五类要区分。

依赖是虚线箭头，从使用者指向被使用者，表示一个类使用了另一个类的某种服务，比如方法参数里出现另一个类的类型。关联是实线，表示对象之间的结构关系，可以标注多重度和方向。泛化是实线空心三角箭头，指向父类，描述继承关系。实现是虚线空心三角箭头，指向接口，描述类实现接口或构件实现接口之间的约束。

考试里最容易混的是依赖和关联：一个类的方法中调用另一个类的方法，这是依赖；一个类持有另一个类的实例属性，这是关联。肉眼可见的区分方式是看箭头的虚实和是否带三角。这几个关系建议建一个对比表：

判断口诀我习惯用「实现看接口、泛化看继承、依赖看参数、关联看属性」——虽然粗糙，但做题快。遇到图中出现菱形，先判断是聚合还是组合，再判断箭头方向标注在哪一端，能拿到这道题的绝大部分分。

3. 顺序图与协作图的对照分析：一道简答题的两个写法

3.1 先分清时间顺序和组织结构

UML 中交互图包含顺序图和协作图两种，它们表达的信息本质上是同一件事，但侧重点完全不同。试题里明确要求分析两者的主要差别并说明各自优缺点，答案需要从三个维度展开：视图侧重点、布局方式、使用场景。

顺序图强调交互的时间顺序，布图时沿水平方向排列参与交互的对象，垂直方向向下展开消息，用生命线和激活条表现时间推进。协作图强调交互的语境和参与交互对象的整体组织，布图时按空间关系摆放对象，用带编号的消息表达式表示顺序。

从优缺点对比说：顺序图在表达消息之间的顺序和时间关系方面极其清晰，弱点是要较多的水平方向空间，对象一多图就拉得很长；协作图在增加对象时比较容易，分支少，但这些好处换来的是当消息数量变多时，难以直观表示消息之间的顺序关系，只能靠消息编号来推测。答案里如果缺了「顺序图需要较多水平空间」「协作图消息多时顺序难辨」这两句，简答分大概率会被扣掉一半。

3.2 协作图的顺序如何表示：消息编号是得分点

试题的另一处考点是「在协作图中通过什么表示出消息的时间顺序」，答案是消息编号。协作图里消息上会标注类似 1:、2:、2.1: 这样的前缀编号，嵌套调用用小数点分隔。画协作图或读协作图时，看一眼编号规则就能还原消息发出顺序。

我一般见到这类题，会在草稿上先列出调用清单：第一条消息整体顺序是 1，第二条是 2；如果消息 2 内部还有嵌套，那么嵌套的第一条子消息是 2.1，第二条是 2.2。对象之间的连线则体现关联关系，连线上可以标多重度。这个规则看起来简单，但考试时很多考生会忘记嵌套编号的小数点写法，丢掉几分。

3.3 SSD 图的画法：把系统当黑匣子

系统顺序图（SSD）是顺序图的一个特殊变体，只在最左侧画一个系统对象，不画系统内部对象。试题 21 给出了一个 POS 机收款场景的操作序列：makeNewSale() → enterItem(itemID, quantity) → endSale() → makePayment(amount)。

画 SSD 的时候要遵守一个原则：不描述系统内部结构，也不列出系统功能，只把系统当作黑匣子处理——外部参与者（收款员）在图上发消息给「系统」对象，消息内容和返回值按题目标注即可。这一点正是试题第 51 题的正确答案：在画 SSD 图时，不对系统的内部结构与功能进行描述。

有个细节值得注意：enterItem 这条消息的参数包含 itemID 和 quantity 两个值，而返回消息会包含商品说明、价格和总金额。画图时不要省略返回消息，简答题里漏了返回消息通常会被扣 1 分。从设计意图来看，SSD 的作用是呈现「系统操作」这个层级的交互，为后续定义系统操作契约和协作图做铺垫。

3.4 操作契约：黑盒视角的收尾动作

操作契约描述系统操作执行后领域模型中对象状态的变化。我在复习时会把顺序图、SSD 和操作契约绑在一起记忆：SSD 找出外部事件，系统操作触发状态变化，操作契约把状态变化写清楚，类代码再按状态变化去实现。整个过程是一个黑匣子逐步打开的过程。

考试如果有综合分析题，通常会给出系统操作规约，要求画出顺序图和协作图，然后配合其他信息写出类代码。这时候建议的作答顺序是：先从规约中提取参与对象，按消息顺序排到顺序图上；再从顺序图改造出协作图，给每个消息加编号；最后按对象和消息映射到类的职责，写方法名和参数。这一步是书上的原题，也是最容易丢大分的综合题。

4. GRASP 与设计模式：职责分配题的做题套路

4.1 GRASP 五模式逐一拆解

GRASP 是考试重点，几乎每年的简答和选择都会出现。试题中给出的五个模式是信息专家、创建者、低耦合、高内聚、控制器，每一个都有对应的核心问题。我不是背答案，而是把问题当成做题的切入口。

信息专家模式解决的问题是「分配职责给对象的基本原则是什么」——把职责分配给拥有完成该职责所需信息的对象。做完一套题后你会发现，信息专家几乎是默认选项，只要某个对象持有大部分数据，职责就应优先分给它。

创建者模式解决的问题是「谁负责创建某个类的新的实例」。判定的依据看谁包含、聚合、密切使用、拥有初始化数据。试题里如果出现「谁应该创建订单对象」，就应该去找包含订单列表或对订单数据最了解的那个对象——通常是顾客或收银会话。

低耦合模式解决的问题是「如何支持低依赖关系和增加重用」，核心是减少类与类之间的连接数量，让一个类的改动不要引发连锁反应。高内聚模式解决的问题是「如何将复杂性保持在可控制的范围内」，意思是不要让一个类承担太多不相关的职责。

控制器模式解决的问题是「谁来负责处理一个输入系统事件」。准则很简单：把系统事件的处理职责分配给一个代表系统、用例或设备控制器的对象，它接收外部事件，协调系统操作，但不承载业务逻辑。

4.2 五种设计模式和它们的「问题标识」

试题 35 列出了单例、策略、组合、观察者、适配器、工厂方法、抽象工厂等模式。考题的呈现方式往往是先描述问题场景，再让你选对应的模式。我总结过一个快速对应表，做题时直接套：

这里有一个高频误区：观察者模式在试题原文里被误写成「Composite」（原文 35 题括号里写的是观察者模式（Composite），实为录入笔误），做题时见到这种错题，要以概念定义为准——观察者关注的是状态变化通知，组合关注的是树形结构一致处理。遇到题干描述混乱的题，先看问题句，再对照上表定位。

4.3 做题防混淆：GRASP 和 GoF 的边界

试题第 52 题问「下面哪一种模式是不属于 GRASP 模式的」，给了多态、纯虚构、中间者、GoF 四个选项，答案是 GoF 不正确——因为 GoF 是设计模式的经典书籍体系，不是某个具体模式。这类题考的是知识框架的边界：GRASP 关注「职责分配」的基本原则，GoF 关注「可复用的解决方案」的模板表达。

容易出现误区的是「纯虚构（Pure Fabrication）」和「中间者（Indirection）」这两个较少见的模式。纯虚构表示不来自领域模型的虚拟类，比如数据访问对象；中间者表示通过中间对象解耦两个组件。考试时可能拿出来跟信息专家对比考你：所有职责都按信息专家分配，会让某些类耦合过高，这时需要纯虚构来承担不属于领域类的职责。理解这层关系比死记回答更重要。

5. 统一过程与高频概念题：避坑与排查清单

5.1 UP 四阶段的时间盒：初始和细化的边界在哪儿

统一过程（UP）四个阶段几乎必考：初始、细化、构造、提交。试题 41 问「定义大多数的需求和范围的工作是在哪个阶段完成」，答案是细化阶段而不是初始阶段，很多考生在这里丢分。

原因在于初始阶段只编制简要愿景文档、确定范围、粗略评估成本和业务案例，需求只是粗略摸底；细化阶段才迭代地实现核心架构、解决高风险问题、定义大多数需求和范围。两者的边界记忆法我常用一句话：初始是「能不能做」的判断，细化是「具体做什么」的定义。类似地，提交阶段做 beta 测试和部署，构造阶段把剩余部分代码写完。

高频考点顺带梳理一遍：

统一过程核心工作流是业务建模、需求分析、设计、实现、测试五条线，这个也考填空。UP 的核心思想强调短时间盒迭代、早期解决高风险问题、用况驱动、以 UML 可视化建模、控制变更，理解后能应对简答题。

5.2 领域模型与概念类：两个寻找策略怎么用

领域模型的定义题考过两个知识点：它是一组「真实世界的概念类」，不是软件部件的模型；识别概念类有两条策略，一是使用概念类类别表，二是标识名词短语。

试题 20 给了一个 POS 收款场景，要求找出其中的概念类。场景原文里能挑出的名词有顾客、POS 收款台、收款员、销售、商品标识、商品、商品说明，这些都是候选概念类。但要注意策略二的边界：不是所有名词都能成为概念类。比如「商品说明」作为商品的属性还是独立的类，取决于它是否承载额外信息。考试时遇到拿不准的，就按「是否需要独立维护、是否需要被引用」来判断，属性包含简单文本的放类内部，被多个对象引用的拆出来。

领域建模的步骤在试题 66 问过：列出候选的概念类 → 画出领域模型图 → 必要时加入概念类间的关联 → 必要时加入概念类的属性。这四个步骤也是简答标准答案，按顺序作答就能拿全分。

5.3 高频坑位排查：现象、原因、解决

把这份试题刷两遍之后，我总结了几个反复出现的坑，按「现象 → 原因 → 解决」列在这里：

坑位一：把组合关系画成普通关联现象：题目说类 A 由类 B 的实例构成，考生画了一条普通实线连过去，多重度标对了，但关系类型错了。 原因：对「构成」一词蕴含的强生命周期没有建立条件反射。 解决：看到「由…构成」「由…组成」这类描述，优先判定为组合，实心菱形画在整体类那一端，再标多重度。如果题干明确说「可以独立存在」，再退化为聚合或普通关联。

坑位二：顺序图和协作图分不清对方的特点现象：简答题写顺序图优点时只写「清晰」，不写「需要较多水平空间」；或协作图优点漏掉「增加对象比较容易」。 原因：只看定义没有对比记忆。 解决：答题时用「顺序图强调时间、协作图强调空间」开场，然后按「优点—缺点」两栏分别罗列，顺序图的空间缺陷恰好对应协作图的空间优势。

坑位三：用例图位置用串行连线现象：画电话用户和两个用况（用电话卡、对方付款）的关系时，把用况之间用带箭头的线连起来。 原因：把参与者与用况之间的关联关系误画成流程关系。 解决：参与者与每个用况分别连一条实线，用况之间如果存在 include 或 extend 关系再单独标注虚线，不要把所有元素串在一条线上。

坑位四：UP 阶段判断题凭直觉作答现象：试题问「下列哪项不在 UP 初始阶段完成」，错选「定义大多数需求」之外的其他项。 原因：把初始阶段想象成「需求大摸底」，事实上细化阶段才是需求细化和核心架构迭代的主场。 解决：把四个阶段的关键词做成表，做题时先定位题干动作再回表核对，看到「大多数需求」直接映射到细化阶段。

坑位五：FURPS 需求分类漏项现象：问需求分类 FURPS 的内容，只答出功能需求，把可用性和可靠性遗漏。 原因：FURPS 每个字母对应一个类别，没有形成字母索引记忆。 解决：按字母拆解记忆——F 功能、U 可用性、R 可靠性、P 性能、S 可维护性，考试时先在草稿写下 FURPS 五个字母再逐个展开。

6. 一套 30 分钟的闭环复习法：从系统操作规约到类代码

分享一个我认为很管用的复习方式：拿一道综合分析题，强制自己按「规约 → SSD → 顺序图/协作图 → 类代码」的顺序走完一遍，限时 30 分钟。这一步走通，选择题里的概念辨析，简答题里的绘图题都会顺手很多。

具体操作是找一道 POS 收款或销售订单相关的系统操作规约——比如收款员启动一次销售、输入商品标识、结束销售并付款——先在白纸上画 SSD，只画参与者和系统两个框；然后从 SSD 的系统侧把每条消息分配给具体对象，展开成完整的顺序图；再根据顺序图消息顺序在协作图上标注 1:、2:、2.1: 这样的编号；最后根据协作图的对象清单和消息调用来确定类的属性与方法名，写出类代码的骨架。

这个方法的厉害之处在于，它把试题里看似分散的多个考点串成了一条完整的建模链路：SSD 考察黑匣子视角，顺序图考察时间顺序，协作图考察空间组织和消息编号，类代码考察职责落地。做完一遍，你会发现之前背的 GRASP 和设计模式不再是孤立的题库答案——系统操作需要一个控制器来接收事件，这是控制器模式；订单项数据要由持有数据的销售对象来维护，这是信息专家；消息之间的编号规则和对象之间的可见性，其实是同一件事的两面。

从那以后，我每次带人复习 UML 都强制走一遍这个闭环，先用 10 分钟画图，再用 20 分钟对照参考答案挑毛病，比从头到尾刷三遍选择题效果好得多。你也不会需要把这份试题背得滚瓜烂熟，只需要把每一类题的答案逻辑搞清楚，让手能跟上脑子，考试时画图和答题的速度自然会上来。希望帮到你。

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