企业官网建设流程全解析

简介：UML系统分析与设计复习题集整理自系统分析与设计课程常见考点，面向准备期末考核或软件工程实践训练的读者，可用于检测对类图、用例图、顺序图、协作图等核心建模知识的掌握程度。资源内为1个doc文档，压缩后约132KB，体积小巧便于考前随查随练。该复习题集发布至今已有404人学习浏览。题目覆盖关联多重度、组合与聚合关系、客户与订单的对应个数判断、顺序图与协作图的时间与空间侧重差异、高内聚度含义，以及依赖、关联、泛化、实现四种UML基本关系等高频选题；并在答案解析中融入概念类识别策略、可见性定义、领域模型作用、FURPS需求分类与GRASP五模式等问题，帮助读者在选择题、简答题与交互图绘制题三类常见题型上同步强化。题目后段还涉及统一过程四阶段、Open-Close原则等面向对象设计与开发流程要点，能够覆盖基础定义与设计应用题两条复习主线，适合考前一周集中复习或边做题边查漏补缺。

1. 复习试题不是背图例：UML 系统分析与设计的正确备考顺序

平时刷“uml系统分析与设计复习试题”的人，大概率都经历过同一种尴尬：选择题选项全认识，一看到“请画出某某系统的用例图”就卡壳。这科的难点从来不在背图例，而在把需求翻译成模型的一整条链路：从用例到分析类图，再演进成设计类图，最后落到构件图和部署图。复习试题的真正价值是标出这条链上的考点，而不是劝你把十几种 uml 图的符号都背一遍。我按“考点地图、系统分析主线、系统设计主线、高频踩坑、自查方法”的顺序把备考路径拆开，适合期末冲刺、软考 UML 图试题备考，以及需要交课程设计文档的开发新手。

2. 考点地图：按出题方式把十来种 uml 图分成三类

第一次复习不推荐按“UML 有哪些图”的顺序去背，那样背完就忘。我习惯先按出题方式把十来种 uml 图分成三类：静态模型、动态模型、实现视图。静态模型管“是什么”，动态模型管“怎么变”，实现视图管“怎么部署”。不同类别的题型差异很大，复习方法自然不同。

2.1 静态模型：用例图、类图、对象图是画图题主力

用例图是需求阶段的门面，几乎所有试卷都考，要么画图，要么让你给用例图找错。画用例图先找参与者，再找参与者的完整业务目标。很多考生把“登录”当成一个操作步骤画进流程，这是最常见的丢分点。复习 uml类图 时则要分清阶段：分析阶段的类图只放概念类，设计阶段才写操作和可见性。对象图考得最少，但常用来考“对象与类的区别”和“链与关联的区别”，这两组概念用一句话就能说清：类是模板，对象是实例；关联是类之间的结构描述，链是对象之间的具体连接。

类图备考的硬指标是六种关系的符号：关联用实线，依赖用虚线箭头，聚合是空心菱形，组合是实心菱形，泛化是空心三角，实现是虚线空心三角。聚合和组合每年都有人记反，我常用一句话记：组合比聚合更“生死相关”，整体销毁时部分也销毁。多重性也别轻视，1、0..1、、1..这些符号在改错题里出现频率很高。复习时建议找一个熟悉的场景练手，比如图书馆借书：先写出“读者”“图书管理员”作为参与者，再列“借书”“还书”“预约取书”等用例，然后判断它们之间是否存在包含、扩展、泛化关系。这个练习能把静态模型的符号记忆直接变成画图能力。

2.2 动态模型：序列图、活动图、状态图是简答题与改错题常客

动态模型描述对象之间在时间上的交互和行为变化。序列图关注“消息按时间顺序流动”，是系统设计阶段重点；活动图适合表达业务流程、分支和并行；状态图适合表达单个对象从创建到销毁的状态切换。简答题往往不让你默写定义，而是给一段业务描述让你选图，比如“描述多个参与者按顺序协作完成一次下单”应选序列图，“描述订单状态在待支付、已支付、已取消之间的转换”应选状态图。

读序列图要先看时间轴：自上而下是时间方向，横向消息从一个生命线跳到另一个生命线。如果题目给你一个有错误的序列图，优先检查三点：消息顺序是否符合业务逻辑、返回消息是否用了虚线、激活条是否标在接收消息的对象上。复习状态图和活动图时还要区分两组概念：活动图里的“动作”是原子步骤，“活动”是子流程；状态图里的“事件”是瞬间发生的刺激，“状态”是稳定持续的条件。“点击提交”是事件，“已提交”才是状态。这两个点在选择题和改错题里反复出现，值得单独记忆。

2.3 实现视图：组件图、部署图、包图是软考选择题的固定考点

先说一个容易绕晕的别名问题：组件图和构件图是同一个图的两种中文译名，英文都是 Component Diagram。软考真题里有时叫组件图，有时叫构件图，要当成一种图来复习。组件图画的是制品（artifact）及其对外提供的接口（provided interface）和需要的接口（required interface），组件之间通过接口连接，而不是直接依赖某个类。部署图画的是节点（node）、设备（device）、执行环境和通信路径，核心题眼是“节点里放制品，而不是直接放类”。如果你在准备软考 UML 图试题，上午选择题几乎必考这两种图的连线语义，下午案例题很少单独画它们，理解比背符号更重要。

用真实部署场景可以帮助理解：把 Web 服务器当作一个节点，把编译出的 war 包当作制品，把数据库当作另一个节点，两个节点之间画一条通信路径。考试时遇到部署图缺节点名或缺制品，按这个映射去补即可。包图考的频率相对低，重点是包与包之间不能循环依赖，一旦形成环，维护成本会指数上升，这个结论经常被塞进选择题选项里。

2.4 从命题规律反推复习优先级：哪些图年年考，哪些图只能用填空带过

结合常见试卷的出题分布，画图题高发区是用例图、类图、序列图，状态图和活动图出现补全、改错的概率次之，组件图、部署图和包图基本只出现在选择和填空里。所以复习顺序建议是“用例图 → 类图 → 序列图 → 状态图”，活动图和实现视图放在后面，按剩余时间安排。

如果你的目标是 uml期末考试试题，尽量把每种图的“符号 + 常见错误”两个点都准备到位，因为期末改错题很喜欢把多个图的错误混在同一道大题里；如果目标是软考，则更侧重符号语义辨析，聚合与组合、包含与扩展、实现与泛化这类对比要特别熟。另一个提高备考效率的办法是从出题人视角反推：很多画图题就是给一段需求文本，要求提取参与者、用例、关系，再画成图。复习时你可以拿同一段需求练三遍，分别画出用例图、领域模型、系统顺序图，一次练习覆盖三个高频题型，比孤立刷题划算得多。

3. 系统分析复习主线：从用例到类图，把分析题答成模型

系统分析阶段的考察核心是“把需求翻译成模型”，三个高频产物是用例模型、领域模型、系统顺序图。做题第一步永远是判断阶段：题目写“需求分析/系统分析阶段”，就不要出现任何设计阶段的界面类、控制类和可见性符号。这本来是送分题，但很多同学在这里翻车，把设计阶段的实现细节提前画进了分析模型。

3.1 include、extend、generalize：用例关系的三步判断法

我见过不少人把用例关系的符号画得比谁都标准，但方向是反的。这里先把方向讲死：include 是基用例指向被包含用例；extend 是扩展用例指向基用例；generalize 是子用例指向父用例，用空心三角表示。方向搞错，整张用例图直接丢一半分。

判断文本题时，我习惯固定成三步：

# 输入：用例A、用例B及需求描述 if A每次执行都必须执行B，或B是A的公共步骤: 判定为 include（包含） B是被包含用例，画图时箭头从A指向B elif 只有在特定条件或异常场景下才会执行B: 判定为 extend（扩展） B是扩展用例，画图时箭头从B指向A elif 语义是“B是一种A”，或A是抽象角色而B是具体实现: 判定为 generalize（泛化） 空心三角从B指向A

这里的参数说明很简单：A、B 是两个用例名，判断依据全部来自需求描述。执行这段逻辑时有一个常见误区：看到“可选”就写 include，但 include 不负责可选性。include 的核心特征是“必需且公共”，比如“借书”用例必须包含“验证读者身份”，因为不验证就不能借；“还书”用例在超期时才执行“计算罚款”应写成扩展，因为不是每次还书都超期。generalize 的判断则看“是一个”关系，比如“现场借书”和“预约取书”都可以泛化成“借书”。

做题时先把需求事件分成“每次都要做”和“特定条件下才做”两组，前者靠 include，后者靠 extend，最后再找“一种、也是、其他类型”这类泛化线索。三步走完，一般不会再犯方向错误。

提示：不同教材对消息箭头线型的约定略有差异，考试时先看试卷图例，再按约定画。

3.2 领域模型与系统顺序图：分析阶段两种必答题的答题节奏

领域模型本质上是“概念类的静态结构”：类名用名词，类之间画关联并标注多重性，不写方法，不写 private/public，不出现界面类。考试给出需求描述后，我按五个步骤来做：

1. 从需求里圈名词，列出候选概念类；
2. 去掉“系统本身”“数据库”“界面按钮”这类实现色彩强的名词；
3. 把行为性短语变成关联，例如“考生参加考试”转成“考生—考试”之间的关联；
4. 给每条关联两端补多重性；
5. 检查一遍：概念类在需求里能找到依据吗？多重性和描述一致吗？

系统顺序图（SSD）则是针对单个用例的“系统黑匣子视角”：上方画参与者和系统两条生命线，消息横向穿过这两条生命线，表达“参与者向系统发指令、系统做响应”。考试里常见的错误是往 SSD 里塞内部对象，比如画出 Controller、DAO，这明显暴露了分析与设计阶段的混淆。SSD 里的系统就是一个整体，内部怎么拆是下一步的事。参与者与系统之间的消息名，建议写成动词短语加参数，例如 submitExam(answers)，既能帮助阅卷老师一眼看懂系统事件，也方便后续映射到设计类图的边界类方法上。

3.3 自编例：在线考试系统的用例描述与领域模型要点

用一个高频课程设计场景把分析阶段串起来。下面是在线考试系统里“参加考试”用例的可复现描述模板：

用例名称：参加考试 主参与者：考生 前置条件：考生已登录，且当前时间在考试时间段内 后置条件：考生答案已提交，答题记录已持久化 基本流程： 1. 考生输入考试码并确认 2. 系统校验考试码与考试时间，生成试卷并开始计时 3. 考生逐题作答，答案临时保存在本地 4. 考生点击提交答案 5. 系统校验未答题数，计算得分并生成答题记录 扩展流程： 3a. 考试时间结束前1分钟，系统弹窗提醒： 系统继续计时直到时间结束并自动提交 5a. 存在未答题时，考生选择强制交卷： 系统标记未答题并在成绩单中显示

这个模板考试时可以直接套用：用例名是“动词 + 宾语”，参与者来自外部角色，前置/后置条件用状态描述，基本流程是动词序列，扩展流程是带编号的变体。把这些写清楚，后面的领域模型才有依据。从描述倒推概念类，可以列出：考生、考试、试卷、题目、答案、答题记录。关联多重性可以写成：

• 考试 1 — 1..* 试卷
• 试卷 1 — 1..* 题目
• 考生 1 — 1..* 答题记录
• 答题记录 1 — 1..* 答案

收尾自查用三个问题：概念类是否都是名词？关联两端是否都标了数量？“校验考试码”这类动作有没有被错画成操作？最后一个问题最关键，分析阶段不写方法，动作留在用例描述里就好。

4. 系统设计复习主线：从分析类图到设计类图与部署视图

系统分析与系统设计的分界，很多复习资料一笔带过，但它恰恰是简答题和画图题的得分分水岭。分析阶段回答“系统要做什么”，设计阶段回答“系统怎么实现”。进入设计阶段，类开始有可见性、有方法、有接口，也会有控制类和边界类，架构在这里成型。

4.1 设计类图怎么从分析类图演进：分层、可见性与接口

我一般把“分析类图 → 设计类图”的演进处理成四步。第一步，把实体类放进领域层，补上主键、外键字段和 getter/setter，但不让它们直接依赖外部框架。第二步，从用例描述抽控制类，比如“试卷生成器”“评分服务”，控制类的职责源自用例基本流程，一个用例对应一到两个控制类，别把每个动作都拆成类。第三步，把参与者交互入口抽成边界类，对应界面或 API。第四步，类之间从宽泛关联改成有依赖方向的协作，能用接口就别直接实现，依赖箭头从调用方指向被调方。

可见性是设计阶段的必考点：+ 表示 public，- 表示 private，# 表示 protected。方法名要能够落在后续序列图的消息上，如果分析阶段的原图直接交上去当设计类图，通常会被批“缺少设计过程”。

4.2 GRASP 九模式：简答题的答题模板与易混点

GRASP 是设计职责分配的经验总结，比二十三种设计模式更贴近“UML 系统分析与设计”这门课。九个模式里，考试频率最高的是信息专家、创建者、高内聚、低耦合、控制器；多态、纯虚构、间接、受保护变化这四个在选择题和简答题里也常出现。

简答题考法通常是“结合场景说明把职责分配给谁”，答题模板我写成这样：

职责被分配给类（谁）。 理由： 1. 信息专家：该类拥有完成职责所需的数据； 2. 创建者：该类包含、聚合或紧密使用目标对象，且拥有初始化数据； 3. 低耦合：分配后类之间的依赖数量下降； 4. 高内聚：职责在同一类内相关性高，满足一个功能目标。

重点看这组易混点。

信息专家和创建者：信息专家关注“谁拥有数据谁处理”，创建者关注“谁有条件创建目标对象”。例如“考生”拥有答题信息，所以“计算本次得分”的职责归考生是信息专家；而“答题记录”对象由谁创建，往往看谁聚合它，这是创建者。

控制器和上帝类：控制器是“接收系统事件并协调用例”的中间层，不要让它包揽所有业务。如果控制类里出现几十个方法，就是上帝类，高内聚和低耦合都会崩。

多态和受保护变化：多态是让行为随类型变化而变化的机制，受保护变化是“把变化点包裹在接口后”的更高层原则。答题时一个写“按子类行为分发”，一个写“通过接口隔离变化”，不要混着写。

如果你还要准备设计模式期末，GRASP 是 GoF 的前置知识：策略、工厂、适配器都能在 GRASP 里找到对应动机。复习时不必 23 个模式全背，优先准备工厂、单例、策略、观察者四个高频场景题即可。

4.3 构件图与部署图：连线规则与选择题题眼

这组属于“会说不会画”的考点，选择题很爱考，画图题很少单独出。备考时用一个表格把两张图的要素钉死：

组件图和构件图只是中文译名差异，英文都是 Component Diagram。答题时如果遇到“一个组件能否直接访问另一个组件的内部类”，答案是不能，只能通过对外接口；遇到“部署图中一个节点是否对应一台物理服务器”，答案是不一定，可以对应虚拟机或容器环境。把这两条理解到位，软考 UML 图试题里的实现视图题基本不丢分。

5. 画图题高频翻车点：现象、原因与批改视角下的纠正

这里集中回顾我踩过的坑和批改作业时最常见的问题，按“现象 → 原因 → 解决”逐条展开，可以对照自己的画图过程体检。

5.1 用例图画成流程图

现象：用例图里出现 A → B → C 的箭头顺序，登录、注册、退出被画成一条流程线，还把“输入密码”单独画成一个用例。 原因：用例图关心“参与者使用系统能获得什么完整价值”，不关心系统内部一步步怎么做；把动作顺序画进去，是把它当成了活动图或流程图。 解决：先问“这个步骤对参与者有独立价值吗？能单独成为一个目标吗？”输入密码没有独立价值，它不是用例，登录才是。用例图里不要出现表示先后顺序的箭头，顺序细节全部写进用例描述的基本流程。画完后用一句口诀自查：每一条用例都是参与者完成的一个目标，而不是内部一步操作。

5.2 include / extend 方向画反

现象：扩展关系总被画成从基用例指向扩展用例，自己还觉得很有道理，因为“我扩展了你，所以我指向你”。 原因：被“扩展”这个词的直觉带偏了。include 的方向是基用例指向被包含用例，extend 的方向是扩展用例指向基用例，箭头方向经常相反，批改时一眼就能筛掉一批人。 解决：用语义背方向，而不是用名词背。include 是“基用例需要 B 才能成立”，所以箭头从主体指向配件；extend 是“B 在条件触发时插入 A”，所以箭头从插入者指向被插入者。画图前先在草稿上写两句话：谁必须包含谁、谁在什么条件下扩展谁，再落笔画箭头。

5.3 序列图返回消息画实线

现象：调用是实线箭头，返回也是实线箭头，整张序列图看起来都是实线，消息语义分不清。 原因：只记住“调用消息是实线”，忘了返回消息是虚线。批改约定里，同步调用用实线箭头，返回用虚线箭头，这个差别的权重比想象中高。 解决：请求消息统一画实线，返回消息统一画虚线开放箭头，消息名常写成 getScore() 或“返回数据”。如果课程教材的约定不同，以教材为准：多数教材采用“实线实心为同步调用、虚线开放为返回”。考试时如果图例里有线型说明，直接按规定画，不要自由发挥。

5.4 状态图把事件写成状态

现象：状态框里写着“点击提交”“正在监听”“处理请求失败”，把瞬间的事件和持续的状态混在同一个状态集合里。 原因：没搞清状态图建模的对象。状态是对象生命周期里的稳定阶段，事件是触发状态跳转的瞬间条件。事件发生在两个状态之间，不会占据一个状态框。 解决：看到动词短语，先问“这个动作发生之后，对象会进入什么稳定状态？”例如“提交”事件发生之后进入“已提交”，那么状态名写“已提交”，事件名写 submit() 并标在转换箭头上。

5.5 类图关联不标多重性

现象：类之间一条直线连接，两端什么都不写；或者只写一头，另一头空着。试卷发下来，关联线旁边全是扣分标记。 原因：复习时注意力都放在六种关系的符号上，多重性默认被忽略。但画图题的评分项里，多重性几乎是每根关联线都要给的点，漏了就是明确丢分。 解决：把多重性当成每个关联的必填项。画完每根线立刻补两端数字：1、0..1、、1..。补数值的依据来自需求原文：一次考试生成几张试卷、一张卷子包含几道题、一个考生能提交几次。对不上就先改图再对答案。

6. 画图题的三遍检查法：十分钟自查别再白丢分

最后说一个我每次考试都用、也推荐学生使用的收尾习惯：画图题答完，留最后十分钟做三遍检查。

第一遍对题。先看题干里的阶段词。写“系统分析”就只给领域模型、系统顺序图，别在类图上写操作和可见性；写“系统设计”就把边界类、控制类、实体类分层表达清楚。最容易丢的分不是不会画，而是画错了题。

第二遍对线型。从上到下检查每种关系：依赖是虚线箭头，关联是实线，聚合是空心菱形，组合是实心菱形，泛化是空心三角，实现是虚线空心三角；序列图的返回消息是不是虚线。这类硬性符号错一个扣一个点，也是最不值得丢的。

第三遍对多重性和命名。看每个关联两端是不是都有数字，类名是不是名词、用例名是不是“动词 + 宾语”，状态图里有没有把事件写成状态。

用一张五分钟自查表做收尾：

这套检查法已经在往年的期末考试和软考案例题里帮我稳定拿到画图题的大部分分数。我自己的血泪教训是：有一次画完类图，觉得关系全对，结果漏标多重性，两个大题的关联线上被扣掉不少分。从那以后我改掉了“画完就交”的毛病，每次答完都先查线型再查多重性，复习试题刷起来才真正见效。希望帮到你。

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