企业官网建设流程全解析

简介：这份UML试题合集面向正在学习统一建模语言、准备课程考试或面试复习的软件工程与计算机专业学生，聚焦用例图、顺序图、协作图等核心交互图，帮助读者在短时间内梳理知识点并检验掌握程度。压缩包内共1个doc文档，约62KB，以问答与选择题形式组织内容，涵盖顺序图与协作图的差别及各自优缺点、高内聚度的含义、对象间可见性、领域模型与概念类查找方法、统一过程四阶段及各阶段主要工作、增量开发、用况的三种描述方式、UML五类图共九种图形的划分等高频考点，并配有标准答案与解析。已有11269人学习下载，说明其题目覆盖面与解析质量经受了较多读者检验。读者可借此逐题自测、对照答案查漏补缺，也可作为考前快速回顾交互图与统一过程知识点的提纲使用。

1. 从一张“外卖小票”说起：UML 用例图和顺序图到底是什么

你有没有拿过外卖小票？上面印着“下单—接单—出餐—取餐—送达”几个节点，旁边还标着时间。如果把这张小票画成图，它其实就同时藏着 UML 里最常被问到的两种图：用例图回答“这个系统能帮谁做什么事”，顺序图回答“这件事按什么先后顺序、在哪些角色之间一步步完成”。UML（Unified Modeling Language，统一建模语言）就是一套画软件蓝图的通用图形语言，它不写代码，而是用图把“系统要做什么、谁来做、按什么顺序做”讲清楚。搞懂用例图和顺序图，你就能看懂大多数软件需求文档里的核心图，也能在面试和课程作业里不再被“交互图”“动态视图”这类词绕晕。这份 UML 试题大集合，正是围绕用例图、顺序图、协作图这些高频考点，把概念、区别和易错点一次讲透。

2. 用例图与顺序图：一个管“谁要什么”，一个管“怎么一步步发生”

2.1 用例图到底在画什么：参与者和系统责任的边界

用例图是 UML 里最像“功能清单”的图，但它不是简单罗列功能，而是把参与者（Actor）和用例（Use Case）放在一起，画出“谁在使用系统、系统对外承诺做什么”。参与者可以是人，也可以是另一个系统；用例则是一个完整的业务目标，比如“创建新订单”“检查用户账号”。这里有个关键认知：用例不描述系统内部怎么实现，它只定义系统的责任，说明系统必须做什么。通俗地说，用例图是站在系统边界外面往里看，画的是“门口挂牌子”的服务项目，而不是后厨的炒菜流程。

正因为如此，用例之间会出现几种关系，试题里反复考。**包含（include）**是指多个用例都要做同一件事，把公共部分抽出来，比如“创建新订单”和“更新订单”都要“检查用户账号”，后者就是被包含的公共用例。**扩展（extend）**则是在主流程之外的可选分支，只有满足条件才发生。很多初学者把这两个搞反，记住一句话：包含是“必须做”，扩展是“可能做”。用例图的价值在于需求阶段对齐范围，让开发者和业务方对“系统负责什么”达成一致，而不是各说各话。

2.2 顺序图为什么按时间竖着排：消息、生命线和激活期

顺序图是交互图的一种，它把参与交互的对象横向排开，每个对象下面垂一条生命线，时间从上往下走，对象之间用消息箭头表示调用。对象生命线上那段窄窄的矩形叫激活期，表示这个对象正在处理某个消息。顺序图最大的优点是时间顺序一目了然：谁先发消息、谁后响应、哪一步是同步等待、哪一步是异步通知，竖着读下来就清楚了。试题里常问“顺序图由什么组成”，标准答案就是类角色、生命线、激活期和消息。

打个比方，顺序图像一场舞台剧的剧本，横向是演员站位，纵向是剧情推进，每一句台词（消息）都标好了谁说给谁听。它特别适合描述一个用例内部的对象协作，比如“用户点击下单”之后，界面对象、订单对象、库存对象、支付对象依次被调用。代价是它很占水平空间，对象一多图就宽得离谱，这也是它和协作图最直观的差别之一。

2.3 协作图为什么按空间组织：对象结构和消息编号

协作图（也叫通信图）同样是交互图，但它不按时间竖排，而是按空间组织：对象像节点一样摆在图上，对象之间的连线表示关联，消息沿着连线走，靠消息编号来体现先后顺序。试题里明确考过“在协作图中通过什么表示消息的时间顺序”，答案就是消息编号。顺序图靠位置表达时间，协作图靠编号表达时间，这是两者最本质的分工。

协作图的好处是对象之间的整体组织关系更清楚，增加对象比较容易，分支也少，适合先想清楚“有哪些对象、它们怎么连”。缺点是消息一多，编号就变得难以追踪，读起来不如顺序图直观。所以实际建模时常见做法是：先用协作图理清对象结构，再转成顺序图看时序；有些工具里顺序图还能直接生成协作图。两者不是替代关系，而是同一段交互的两种视角。

2.4 静态视图和动态视图：别把类图和顺序图混成一类

UML 的图大致分静态和动态两派。类图描述系统的静态设计视图，画的是类、属性、操作以及类之间的关系；用例图虽然常被放在需求阶段，但它描述的是系统行为组织和功能边界，试题里明确把它归为对系统行为建模的图。顺序图和协作图则是描述系统动态视图的交互图，一个管时间顺序，一个管对象组织结构。状态图描述一个对象随事件变化的状态迁移，部署图描述物理节点上的部署。

这个分类之所以重要，是因为试题里经常用“下面哪个不是静态视图”来设陷阱，答案往往是状态图。记住一条主线：类图、对象图、包图偏静态结构；用例图、顺序图、协作图、状态图、活动图偏行为动态。把这条线理清，一大类选择题就能直接排除错误项。

3. 高内聚与低耦合：为什么“一个类别管太多事”是设计底线

3.1 高内聚度的两层含义：职责相关且工作量适中

高内聚度衡量的是一个类内部各个职责之间的相关程度和集中程度。一个类如果承担的职责彼此高度相关，而且总工作量不是特别巨大，它就具有高内聚度。这句话包含两层意思：第一，不要给一个类分派太多职责；第二，不相关的职责不要塞进同一个类，履行职责时尽量把部分工作分派给更有能力完成的其它类。通俗地说，高内聚就是“专业的人做专业的事”，一个类像一个岗位，岗位说明书越聚焦，这个类越好维护。

为什么试题反复考高内聚？因为它是面向对象设计里最容易被忽视又最影响长期成本的点。一个类什么都管，改一处牵动全身，测试也难写。反过来，职责集中、边界清晰的类，改起来局部化，复用也自然。注意高内聚不等于“职责越少越好”，而是相关职责的集中，把一个完整业务能力拆得七零八落同样不是高内聚。

3.2 领域模型不是软件类图：真实世界概念类与软件部件的区别

试题里有一道很典型的题：领域模型是一组表示真实世界概念类的模型，不是软件部件的模型。这个区分特别关键。领域模型画的是业务世界里的概念，比如“订单”“客户”“商品”，它帮助我们在设计软件对象之前先理解业务；而类图里的软件类会包含具体的数据结构、方法签名、可见性修饰符，是面向实现的。把领域模型当成类图来画，是初学者最常见的翻车点之一。

找概念类有两种常用方法：概念类类别表和标识名词短语。前者是按常见类别去套，比如人、地点、事物、事件；后者是从需求描述里把名词圈出来，再筛选哪些是业务概念。领域建模的步骤也常考：列出候选概念类、画出领域模型图、必要时加入概念类之间的关联、必要时加入概念类的属性。注意“必要时”三个字，领域模型不是越全越好，只画对理解业务有帮助的部分。

3.3 对象间可见性：一个对象凭什么“看得到”另一个对象

可见性指的是一个对象能够“看到”或者引用另一个对象的能力。听起来抽象，其实很生活化：你手里有对方的联系方式，你才能给对方发消息；对象之间要发消息，前提是发送方对接收方可见。可见性通常来自几种途径：属性引用、方法参数传入、局部变量创建、全局可见。顺序图里一条消息箭头能画出来，背后就隐含了可见性关系。

这个知识点常和“消息通信”一起考。在面向对象语言里，对象之间的消息通信本质上就是方法调用。所以画顺序图时，如果两个对象之间根本没有可见性路径，那条消息就是空中楼阁。实际建模时先问一句“发送方怎么拿到接收方的引用”，能避免画出看起来漂亮但实现不了的图。

3.4 统一过程的四个阶段：需求范围到底在哪个阶段定

统一过程（UP）把软件生命周期分成四个阶段：初始阶段编制简要的愿景文档、业务案例、确定范围、粗略评估成本；细化阶段细化愿景、迭代实现核心架构、解决高风险问题、定义大多数需求和范围、进一步评估成本；构造阶段迭代实现系统其余部分并准备部署；提交阶段做 beta 测试和部署。试题里反复考“定义大多数需求和范围在哪个阶段完成”，答案是细化阶段，不是初始阶段。

这个点容易混，是因为直觉上“需求不是一开始就定吗”。统一过程的思路是：初始阶段只定粗略范围和业务案例，把大多数需求留到细化阶段，配合短时间盒的迭代、早期解决高风险高价值问题、持续与用户衔接拿反馈。增量开发也在这里体现：复杂用例分多次迭代实现，所有用例按优先级安排到不同迭代。理解这套节奏，比死记阶段名更有用。

4. 常见误区：顺序图、协作图、状态图、活动图到底怎么分

4.1 误区一：顺序图和协作图是两种完全不同的图

易混点在于两者都叫交互图，都能描述对象之间的消息传递，很多人以为要二选一。之所以混，是因为教材常把它们并列讲，却没强调它们是同一段交互的两种视角。区分方法看组织方式：顺序图按时间顺序布图，强调消息的先后和时间关系；协作图按空间组织布图，强调参与交互的对象的整体组织和关联。顺序图占水平空间多，协作图靠消息编号表达顺序、消息多时难读。实际工作中两者可以互相转换，不是对立关系。

4.2 误区二：状态图和活动图都是描述行为，可以随便换

易混点在于两者都描述动态行为，试题里也常放在一起考。之所以混，是因为它们都涉及“状态”和“流转”。区分方法看建模对象：状态图针对单个反应型对象，描述它在不同事件下的状态迁移，比如一个订单从“待支付”到“已支付”再到“已发货”；活动图描述一个活动过程中的控制流，可以有多个参与者、分支、汇合，泳道就是把活动按负责的类、人或部门分组。试题里明确考过“对反应型对象建模一般用什么图”，答案是状态图。记住：状态图盯一个对象的一生，活动图盯一件事的流程。

4.3 误区三：用例图就是功能列表，画得越全越好

易混点在于用例看起来像功能点，很多人把系统每个按钮都画成一个用例。之所以混，是因为“用例”这个词本身容易被理解成“功能”。区分方法看粒度：用例是一个参与者使用系统完成某个完整业务目标的事件顺序，不是单个操作。用例图的价值是划定系统责任边界，画太细反而失去需求对齐的意义。另外用例描述分 Brief、Casual、Fully Dressed 三种详细程度，不是所有用例都要写到最细。

4.4 误区四：领域模型就是数据库表设计或类图草稿

易混点在于领域模型里的概念类最后往往会变成软件类，于是有人直接按数据库字段去画。之所以混，是因为两者名字都带“模型”。区分方法看目的：领域模型表示真实世界的概念类，用于启发设计、对齐业务理解，不包含软件实现细节；类图是软件视角，有属性类型、方法、可见性。试题原话就是“领域模型是一组表示真实世界概念类的模型，不是软件部件的模型”。先画领域模型再设计类，顺序反了就容易把业务概念硬塞进表结构。

4.5 误区五：正向工程和逆向工程的方向记反

易混点在于两个词都带“工程”，方向容易颠倒。之所以混，是因为“正向”听起来像“从代码到模型”也说得通。区分方法记死定义：正向工程是把模型转换为代码，逆向工程是把代码转换为模型。试题里就有一道题把“正向工程是从实现语言映射把代码转换为模型”设为错误选项。理解方向后，工具支持只是手段，核心是模型和代码之间的双向映射关系。

5. 什么时候该用哪张图：一份判断清单和我的踩坑习惯

把前面几章收拢成一句判断：要谈系统对外的责任边界，用例图；要谈一次交互的先后顺序，顺序图；要谈对象之间的组织结构，协作图；要谈单个对象的状态迁移，状态图；要谈跨角色的业务流程，活动图；要谈系统的静态结构，类图。这不是死规矩，而是建模时的第一反应。比如需求评审阶段，先用用例图圈定“谁要什么”，再用顺序图把核心用例走一遍，能提前发现对象之间根本没有可见性路径的问题；如果对象关系复杂、消息不多，协作图反而更清爽。

也有明确不该用的时候。需求还没对齐就急着画顺序图，往往画出一堆实现细节，返工成本高；对象和消息都很多时硬用协作图，编号会乱到没人愿意读；把领域模型当数据库设计来画，会把业务讨论带偏成字段争论。试题里那些“哪个不是静态视图”“哪个阶段定义大多数需求”的陷阱，本质上都在考你有没有建立这张判断地图，而不是背下零散答案。

我自己的血泪经验是：每次画交互图之前，先强制问一遍“发送方凭什么看得到接收方”，可见性没落实的消息一律先不画；每次画用例图之前，先确认这个用例是不是一个完整业务目标，而不是一个按钮。这个习惯帮我避开了不少“图很漂亮、实现时全翻车”的坑。这份 UML 试题大集合把用例图、顺序图、协作图、高内聚、统一过程这些高频考点按概念和易混点整理在一起，适合在复习和面试前对照着把边界厘清。希望帮到你。

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