企业官网建设流程全解析

简介：这份UML试题合集面向正在学习统一建模语言、准备课程考试或面试复习的计算机专业学生与软件设计初学者，围绕用例图、顺序图、协作图等核心图形组织题目，帮助读者在练习中厘清静态视图与动态视图的区别与联系。压缩包内共1个doc文档，约62KB，以问答与选择题形式集中呈现知识点，涵盖交互图两种类型的差异与优缺点、高内聚度的含义、对象间可见性、领域模型与概念类查找方法、统一过程四阶段及核心工作流、增量开发与用况描述方式等内容，并配有参考答案便于自测。该资源已有11274人学习下载，题目贴近课堂与考试常见考法，适合用作章节复习提纲、考前速览或对照查漏补缺的练习材料，也可辅助理解类图、状态图、部署图等图形在面向对象分析与设计中的分工。

1. 从一张“谁先谁后”的图说起：UML 用例图与顺序图到底是什么

很多人第一次翻 UML 资料，都会被一堆图形名字砸晕：用例图、顺序图、协作图、状态图、活动图……光看名字根本分不清谁管什么。其实可以打个特别生活化的比方：把开发一个软件想象成盖一栋楼，UML 就是那套“建筑图纸的标准画法”。它不负责砌砖，只负责把“这楼长什么样、谁从哪个门进、水电怎么走”画成大家都能看懂的图。UML 全称统一建模语言，是一套用图形描述软件系统的通用表达方式，既画静态结构，也画动态行为。

而在这套图纸里，用例图回答的是“系统对外提供哪些服务、谁来用”，顺序图回答的是“这些服务在内部按什么时间顺序、由哪些对象一步步完成”。一个管“做什么、给谁做”，一个管“怎么按时间做”。搞懂这两张图的分工，基本就抓住了 UML 需求与设计阶段的主线，也是各类考试和实际建模里出现频率最高的部分。这份资料把用例图、顺序图以及容易混淆的协作图放在一起梳理，正是冲着这个高频痛点来的。

2. 用例图与顺序图：一个管“谁用”，一个管“怎么走”

2.1 用例图到底在画什么

用例图是 UML 里最“面向用户”的一张图。它由三样东西构成：参与者（Actor）、用例（Use Case）、以及它们之间的关系。参与者不一定是人，也可以是另一个外部系统；用例则是一个个“系统能帮参与者完成的事”，比如“下单”“查询余额”“打印报表”。

通俗地说，用例图就像餐厅门口挂的菜单：菜单上写的是“本店能提供哪些菜”，而不是“厨师怎么切菜、灶台怎么点火”。用例图只定义系统的责任边界——系统必须做什么，不描述系统内部如何工作。这一点在资料里被反复强调：用况（用例）是一个描述性的文档，描述一个参与者使用系统完成某个业务过程时的事件发生顺序，它定义的是系统的功能需求，而不是内部实现。

画用例图时，参与者用小人表示，用例用椭圆表示，二者之间的连线表示“谁发起或参与了哪个用例”。用例之间还有两种常见关系需要分清：包含（include）和扩展（extend）。包含是“每次做 A 都必然要做 B”，比如“创建新订单”和“更新订单”都必须“检查用户账号”，那“检查用户账号”就是被包含的公共用例；扩展则是“特定条件下才额外发生”的可选行为。这个区分在选择题里几乎年年出现，混淆点就在于“必然”和“可选”这两个词。

2.2 顺序图为什么强调“时间轴”

顺序图（也叫序列图）是交互图的一种，它把对象横向排开，每个对象下面垂一条生命线，消息在生命线之间从上往下传递，纵向就是时间。它最擅长表达的是“第几步调用谁、谁先返回”，也就是消息之间的先后顺序和时间关系。

打个比方，顺序图像一段乐谱：横向是不同乐器（对象），纵向是时间，音符（消息）落在哪条线上、在第几拍出现，一目了然。资料里明确指出，顺序图按照时间顺序布图，可以清晰地表示消息之间的顺序和时间关系，但代价是需要较多的水平方向空间——对象一多，图就会横向拉得很长。

顺序图里还有几个固定元素：类角色、生命线、激活期（对象正在处理消息的那段矩形）和消息。消息又分同步、异步、返回等类型。初学者最容易忽略的是激活期——它表示对象“正在干活”的时间段，画不画对理解调用嵌套影响很大。

2.3 两者为什么必须配合使用

单看用例图，你知道系统有“下单”这个功能，但不知道下单过程中订单对象、库存对象、支付对象谁先动。单看顺序图，你知道某次交互的细节，但不知道这个交互对应哪个对外功能、由哪个参与者触发。所以实际建模时，通常先用用例图圈定范围，再对每个关键用例画顺序图展开内部交互。

资料里有一道很典型的题：在画系统顺序图（SSD）时，应该如何对待所涉及的系统？正确答案是“不对系统的内部结构与功能进行描述”。这句话点破了顺序图在需求阶段的定位——它把系统当成一个黑匣子，只画外部参与者与系统之间的消息往来，不急着拆内部对象。等到设计阶段，才把黑匣子打开，画内部对象之间的顺序图。这个“黑匣子”意识，是很多人画图翻车的根源：需求阶段就把内部类全画上去，图是热闹了，但需求边界反而糊了。

提示：判断一张顺序图该画多细，先问自己处在哪个阶段。需求阶段画黑匣子，设计阶段才画内部对象。

3. 顺序图与协作图：同一段交互的两种看法

3.1 协作图强调的“空间组织”是什么

协作图（也叫通信图）和顺序图一样，都是交互图，都描述对象之间为完成某一目的而进行的一系列消息交换。区别在于布图方式：顺序图按时间顺序纵向排布，协作图按空间组织排布——对象像节点一样散在图上，消息沿着对象之间的连线走，用消息编号来体现先后。

通俗地说，顺序图像“时间线”，协作图像“关系网”。协作图除了展示对象之间的关联，还显示出对象之间的消息传递，它强调的是交互的语境和参与交互的对象的整体组织。资料里那句总结很到位：顺序图强调的是交互的时间顺序，协作图强调的是交互的语境和参与交互的对象的整体组织。

3.2 两种图的优缺点对照

这张表基本覆盖了资料里反复考的那道经典问答题。协作图在增加对象时比较容易，分支也比较少；但消息一多，光靠编号去还原先后顺序就很吃力。顺序图则相反，时间线天然清楚，可对象一多就横向铺得太开。

3.3 一个容易忽略的细节：消息编号

协作图里没有纵向时间轴，那怎么表示“谁先谁后”？靠消息编号。资料里专门有一道填空题：在协作图中通过消息编号表示出消息的时间顺序。编号通常写成 1、2、3 这样的层级形式，嵌套调用用 1.1、1.2 表示。这个细节看着小，却是协作图能成立的关键——没有编号，协作图就退化成一张普通的关系图，交互顺序全丢了。

注意：协作图不是顺序图的“简化版”，它是另一种视角。两者可以互相转换，但转换后强调的重点会变。

4. 常见误区：这几组概念最容易搞混

4.1 误区一：把顺序图和协作图当成“新旧替代”

易混点：有人以为协作图是顺序图的升级版或替代品。为什么混：两者都是交互图，画的往往是同一段交互，图形还能互相转换。怎么区分：它们是并列的两种视图，不是替代关系。顺序图看时间，协作图看结构。资料里明确说协作图“与顺序图一样，也展示对象之间的交互关系”，是并列而非从属。选图时看你想突出什么，而不是哪个更“高级”。

4.2 误区二：把用例图和顺序图都当成“功能清单”

易混点：以为顺序图也在列系统功能。为什么混：两者都围绕“系统做什么”展开。怎么区分：用例图列的是对外功能边界，顺序图展示的是某个功能内部的消息时序。资料里那道 SSD 题说得很清楚——画系统顺序图时不对系统内部结构与功能进行描述。顺序图是“演一遍过程”，不是“列一张功能表”。

4.3 误区三：把包含和扩展当成同一种关系

易混点：include 和 extend 都带“关联”意味。为什么混：两者都表示用例之间的依赖。怎么区分：包含是“必然发生”，扩展是“条件发生”。资料里“创建新订单”“更新订单”都要“检查用户账号”，这是包含；而扩展是在基本用例之上按条件追加的行为。记法：包含是“每次都得做”，扩展是“有时才多做”。

4.4 误区四：把高内聚理解成“一个类什么都干”

易混点：以为职责越多越“能干”就是高内聚。为什么混：“内聚”字面像“聚在一起”。怎么区分：高内聚恰恰要求不相关的职责不要分派给同一个类，也不要把太多职责压给一个类。资料的定义是：一个类中各个职责之间相关程度和集中程度的度量，相关职责集中、工作量不过大，才算高内聚。它和“大而全”正好相反。

4.5 误区五：把领域模型当成软件类模型

易混点：画领域模型时直接画成数据库表或代码类。为什么混：两者都叫“类”，都带属性。怎么区分：领域模型是一组表示真实世界概念类的模型，不是软件部件的模型。资料里那道填空题的答案就是“概念类”对“软件部件”。领域模型是“业务世界里的名词”，不是“代码里的 class”。

5. 什么时候该用哪张图：一条判断线和一个习惯

把前面几章收拢成一条可操作的判断线：先问“我要表达的是对外功能，还是内部交互”。对外功能、参与者和系统边界，用用例图；内部交互且关心先后顺序，用顺序图；内部交互但更关心对象之间的组织结构、想方便地增删对象，用协作图。再问“我处在哪个阶段”：需求阶段顺序图只画黑匣子，设计阶段才展开内部对象。

举个具体例子。假设要做一个图书借阅系统。第一步画用例图：参与者有读者、管理员，用例有“借书”“还书”“查询库存”。第二步对“借书”画顺序图：读者发起借书请求，系统依次校验读者资格、检查库存、生成借阅记录，纵向时间线把这几步排清楚。如果这时你更想展示“借阅记录对象、库存对象、读者对象三者之间怎么协作”，那就换协作图，用消息编号标出 1、2、3 的先后。两张图讲的是同一件事，选哪张取决于你想让读者先看到时间还是先看到结构。

需要提醒的是，别为了“图全”而画图。我见过不少建模文档，用例图画了几十张，顺序图却一张没有，结果需求评审时谁也说不清关键流程到底怎么走；也见过反过来，顺序图画得极细，却没人说得清系统到底对谁负责。这两种都是把工具当成了目的。UML 的价值在于让不同角色对同一个系统形成一致理解，图只是载体。

从那以后我每次拿到一个建模任务，都强制自己先画一张用例图把边界钉死，再挑两三个最关键的用例画顺序图，其余的一律不碰。图不在多，在于每张都能回答一个具体问题。希望这套“先边界、再时序、最后看结构”的顺序，能帮你在面对 UML 试题或真实项目时少一点懵、多一点笃定。这份资料把用例图、顺序图、协作图以及高内聚、领域模型、统一过程这些高频考点串在一起，配合大量选择题和问答题，适合拿来对照自查——哪张图该在什么场景出现、哪组概念容易混，翻一遍就能对上号。

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