企业官网建设流程全解析

简介：围绕UML用例图、顺序图与协作图等交互图知识整理的试题合集，面向正在学习面向对象分析与设计、准备课程考试或面试复习的学生与开发者，帮助梳理UML核心概念并检验掌握程度。压缩包内为1个doc文档，约62KB，内容以问答、选择题和简答题为主，题目与答案相邻编排，便于按知识点查阅和自测。文档涉及顺序图与协作图在时间顺序、空间组织和消息表达上的差异，也覆盖类图、用例图、状态图、部署图等图在静态与动态建模中的定位；同时收录高内聚度、对象间可见性、领域模型与概念类识别、统一过程四阶段、增量开发、用况描述方式及领域建模步骤等高频考点。已有11276人学习，适合用题目串联零散概念，对照答案查漏补缺，逐步形成较完整的UML知识框架。

1. 时间轴还是对象网：从顺序图与协作图差异题看 UML 笔试的拿分点

UML 试题大集合里，用例图、顺序图、协作图这三类图最容易被低估：题干只改一个词，答案就从“时间顺序”切到“对象组织”。这类 UML 笔试和建模面试，真正考的不是死背图符，而是能不能先判图种，再判关系、阶段和职责。顺序图与协作图的差异、用例之间的包含与扩展、统一过程四阶段、领域模型里该不该出现软件部件，都是高频送分题，也是踩坑题。拿分顺序很清楚：先定性图种，再写两句差异，最后落到适用场景；简答题按“定义—对比—场景”三段写，选择题用关键词排除。适合正在准备 UML 相关课程笔试、建模面试和需要快速补漏的人。

2. 图种判定高频考点：用例图、顺序图、协作图一次分清

图种判定是整套题里性价比最高的一块。它不要求写长代码，也不要求画完整系统，只看你能不能从题干里抓住“静态设计视图”“行为组织”“时间顺序”“对象组织”“物理部署”“单对象生命周期”这些关键词。很多人失分不是不会，而是把顺序图和协作图混着答，把状态图硬说成静态视图，把系统顺序图画成内部结构图。下面把九种图、交互图差异和用例关系拆开练，看到题能直接落到判定词上。

2.1 九种图与五类视图：先背“静态看结构，动态看交互”

标准建模语言 UML 的重要内容通常按五类图、九种图形来记：用例图；静态图包括类图、对象图和包图；行为图包括状态图和活动图；交互图包括顺序图和协作图；实现图包括组件图和部署图。这个分类本身就会出选择题，比如问 UML 体系包括哪三部分，答案是基本构造块、规则和公共机制；问 UML 中的事物包括哪几类，要能选出结构事物、分组事物、注释事物和动作事物。记忆时不要按图符背，按“这张图回答什么问题”背。

真题里常见的判定方式是“给定义选图”。题干说“给出系统的静态设计视图”，优先选类图；说“对系统的行为进行组织和建模非常重要”，优先选用例图；说“以时间顺序组织对象之间的交互活动”，选顺序图；说“强调收发消息的对象的组织结构”，选协作图；说“对反应型对象建模”，选状态图；说“类图应该画在哪种视图”，要答逻辑视图，而不是用例视图、组件视图或部署视图。这里没有太多玄学，关键是先把判定词和图的职责绑定。

还有一类题会把“静态视图”当陷阱。下面哪个不是 UML 中的静态视图，选项里放状态图、用例图、对象图、类图，答案应选状态图。原因不复杂：状态图描述对象随时间变化的行为，属于动态建模；用例图虽然从外部看系统行为，但在 UML 分类里常被放在行为建模入口，题目问“静态视图”时不能把它和状态图混为一谈。答题时不要只写答案，选择题也要在题干旁标出“静态/动态”“结构/行为”，这样排除速度会快很多。

建模基本原则也会出选择题。要仔细选择模型、每一种模型可以在不同精度级别表示系统、模型要与现实相联系，这些都是基本原则；说“对一个重要的系统用一个模型就可以充分描述”明显不对。重要系统需要多视图、多模型配合，单一模型只能覆盖一个侧面。这个点放在简答题里同样好用：问为什么 UML 要用多张图描述系统，就答静态与动态、结构与行为、逻辑与实现分别需要不同视图，单一模型无法完整表达。

提示：图种题先写“静态还是动态、结构还是交互、逻辑还是实现”，再选具体图名，比直接凭印象选更稳。

2.2 顺序图与协作图：一道差异题的标准答法

顺序图和协作图是交互图里的双高频。项目题库里有一道很典型的简答题：UML 中的交互图有两种，分别是顺序图和协作图，请分析两者之间的主要差别和各自的优缺点，并掌握利用两种图进行设计的方法。这类题如果只写“一个按时间、一个按空间”，能拿基础分，但拿不满。比较稳的答法是四层：先定性并列关系，再写侧重点，再写布图与优缺点，最后写适用场景。

顺序图强调交互的时间顺序，按照时间顺序布图，有生命线和激活期，能清晰表示消息之间的顺序和时间关系，缺点是水平方向需要较多空间，对象一多图会变宽。协作图强调交互的语境和参与交互的对象的整体组织，按照空间组织布图，除了展示对象之间的关联，还显示对象之间的消息传递，增加对象时比较容易，分支也比较少，缺点是消息一多就难以表示消息之间的顺序，需要靠消息编号辅助。两者都展示对象之间的交互关系，不是谁包含谁。

真题里问“顺序图由类角色、生命线、激活期和什么组成”，答案是消息。这个点常和协作图混：协作图里也有消息，但时间顺序通过消息编号表示，不是看箭头谁高谁低。另一道选择题问“关于协作图的描述哪个不正确”，错误项是“协作图是顺序图的一种特例”。这句话很能区分是否真懂：顺序图和协作图是两种并列的交互图，只是视角不同，不存在特例关系。看到“特例”“子类”这种词，先警惕。

如果面试官问“什么时候用顺序图，什么时候用协作图”，不要只背优缺点。可以这样答：要突出一次业务动作中消息的先后、超时、异步和调用顺序时，用顺序图；要突出参与对象之间的组织结构、谁和谁有连接、消息在对象网里怎么走时，用协作图。设计时先画顺序图梳理时间线，再转成协作图看对象组织，或者反过来从协作关系入手，再用顺序图校验消息顺序。这样答，面试官能听到你知道两张图在建模过程中的分工。

系统顺序图 SSD 也是高频踩坑点。题目问“在画 SSD 图时应该如何对待所涉及的系统”，正确思路是不对系统内部结构与功能进行详细描述，系统在 SSD 里是黑匣子，只画外部参与者、系统边界和系统操作。选“详细描述内部结构并罗列功能”的选项看起来更完整，实际上违背了 SSD 的用途。答这类题要抓住一句话：SSD 关注外部参与者与系统之间的交互，不展开系统内部。

2.3 用例图关系题：include、extend、泛化别靠语感

用例图题最容易靠语感翻车，尤其是包含和扩展。项目题库里有一道典型题：在“某订单场景”中，创建新订单和更新订单都需要检查用户账号是否正确，那么“创建新订单”“更新订单”与“检查用户账号”之间是什么关系。答案应选包含 include，因为检查用户账号是两个用例每次执行时都要走的公共行为，不是可选增强。很多人看到“都需要”就选扩展，方向正好反了。

判断用例关系可以按三步走。第一步问“这个行为是不是基用例每次执行都必做”，如果是，优先考虑包含；第二步问“这个行为是不是只在某些条件下才发生、发生时增强基用例”，如果是，考虑扩展；第三步问“是不是一般与特殊、父与子的分类关系”，如果是，考虑泛化。包含关系通常表示把多个用例中的公共步骤抽出来；扩展关系表示可选或条件触发的增强；泛化表示用例之间的分类。答题时把“必做公共行为”和“可选增强”写在选项旁边，基本不会选反。

用例本身也常出简答。用况是描述一个参与者使用系统完成某个业务过程时的事件发生顺序，它描述系统使用过程和功能需求，不描述系统内部如何工作，而是定义系统责任，说明系统必须做什么。用况模型是需求工作的重要制品。用况一般有 Brief、Casual、Fully Dressed 三种描述方式。这个答案的踩分点在“参与者—系统—事件顺序”“功能需求”“不描述内部工作”“定义责任”几个词上，不要写成“用例就是功能列表”。

如果题目问“如何描述用况”，可以按模板答：先写参与者是谁，再写触发事件，再写主成功场景的步骤，再写异常或备选路径，最后写后置条件。Brief 只写简短摘要，Casual 用非正式段落写主要场景，Fully Dressed 把前置条件、主流程、备选流程、后置条件写全。面试里被追问“用例和功能列表有什么区别”，答用例有参与者、有目标、有事件顺序、有系统边界，功能列表只是功能条目，缺少使用语境。

3. 统一过程与需求建模高频考点：四阶段、核心工作流、领域模型怎么答

统一过程和需求建模是另一条主线。这部分题看起来偏概念，实际考的是阶段职责、制品和建模边界。比如“定义大多数需求和范围”到底在初始阶段还是细化阶段，“领域模型里能不能画软件部件”，“画 SSD 时系统内部要不要展开”，这些点一旦记反，选择题和简答题会一起丢分。下面按阶段和工作流、领域模型和用况两条线拆。

3.1 UP 四阶段与核心工作流：阶段职责题先抓“需求范围”和“架构风险”

统一过程通常分四个阶段：初始阶段、细化阶段、构造阶段、提交阶段。初始阶段做简要愿景文档、业务案例、确定范围、粗略评估成本；细化阶段细化愿景文档、迭代实现核心构架、解决高风险问题、定义大多数需求和范围、进一步评估成本；构造阶段迭代实现系统其余部分并准备部署；提交阶段做 beta 测试和部署。核心工作流包括业务建模、需求分析、设计、实现、测试。这些是简答题的骨架，但选择题更爱考边界：哪些事在初始阶段做，哪些事不在初始阶段做。

真题里问“定义大多数需求和范围的工作是在 UP 中的哪个阶段完成”，答案是细化阶段；问“下列哪项不在 UP 的初始阶段中完成”，如果选项里有“定义大多数需求”，应选它。初始阶段不是把所有需求定完，而是确定范围、愿景、业务案例和粗略成本。这个区别非常高频。记的时候抓两组词：初始阶段对应“愿景、业务案例、范围、粗略成本”；细化阶段对应“细化愿景、核心架构、高风险、大多数需求、进一步成本”。看到“大多数需求”就不要再选初始。

UP 的核心思想也要能答：短时间盒的迭代式开发；开发过程中不断调整；在早期迭代中解决高风险和高价值的主要问题；不断与用户衔接，及时得到反馈；早期注意构造核心体系结构；早期进入实现和测试，不断进行质量检验；使用用况可视化建模；仔细管理需求、控制变更。答简答题时不要只写“迭代”，要把“高风险高价值优先”“核心架构早期构造”“反馈和变更控制”带上。

增量开发也常和迭代一起考。增量开发包括两层意思：对复杂的用况分多次迭代，一部分一部分地实现；将所有用况按优先级分别安排在不同迭代中实现。它不等于想到哪写到哪，也不等于把系统一次性做完再拆成多个版本。答题时可以说：增量解决“分块交付”，迭代解决“反复细化”，两者常配合使用。这个表述比单背定义更容易让阅卷人看到理解。

软件开发生命期和瀑布模型也会作为对比出现。软件开发生命期指软件产品从考虑概念开始，到交付使用为止的整个时期，一般包括概念、需求、设计、实现、测试、安装及交付阶段，这些阶段可以有重复，执行时也可以有迭代。瀑布模型的生存周期常按计划、需求分析、设计、编码、测试、运行维护展开。瀑布模型的缺点是缺乏灵活性，特别是无法解决软件需求不明确或不准确的问题。这个点放在“为什么需要迭代和原型”的简答题里很好用。

提示：阶段题不要背整段，先记“初始定范围和愿景，细化定大多数需求和核心架构，构造做其余实现，提交做测试部署”。

3.2 领域模型与概念类：名词短语题别把软件部件画进去

领域模型是一组表示真实世界的概念类，不是软件部件的模型。项目题库里填空：领域模型是一组表示真实世界的概念类，不是软件部件的模型；找概念类可以用概念类类别表和标识名词短语两种方法。这个点出选择题时，常见陷阱是把“软件部件”“数据库表”“界面控件”放进领域模型。领域模型画的是业务世界里的概念，比如客户、订单、商品、账户，不是系统内部类。

领域建模的步骤可以按四步答：列出候选的概念类；画出领域模型图；必要时加入概念类间的关联；必要时加入概念类的属性。注意顺序，先找概念类，再画关系，再补属性。答题时不要一上来就写属性，也不要把方法写进去。领域模型是概念层面的，属性只加必要的，关联只加有业务含义的。

找概念类的方法要能区分。概念类类别表是按业务类别补漏，标识名词短语是从需求描述里圈名词和名词短语。名词短语法的操作是：把需求句子里的名词圈出来，排除同义词、排除系统外部角色、排除软件部件、排除纯属性词，剩下的候选再按类别表补。这个步骤在简答题里可以写成“先圈名词，再筛概念，最后补类别”。面试里被问“为什么不能把数据库表直接当领域模型”，答数据库表是实现视角，领域模型是业务概念视角，二者可以有映射，但不能混为一谈。

SSD 图与领域模型经常一起考。画 SSD 时，系统是黑匣子，只画外部参与者和系统操作，不对系统内部结构与功能进行描述。领域模型则帮助发现业务概念和关系。两者都不是详细设计图，都不展开类的方法和内部实现。这个共同点可以帮助记忆：需求建模阶段先搞清“系统外部谁交互、业务世界有哪些概念”，不要提前掉进实现细节。

用况和用况模型也在这一块。用况描述参与者使用系统完成业务过程的事件发生顺序，定义系统责任，说明系统必须做什么，不描述系统内部如何工作。用况模型是需求工作的制品。描述方式有 Brief、Casual、Fully Dressed。答题模板是“参与者—目标—事件顺序—系统边界—异常路径”。如果题目问“用况和用例图的关系”，可以答用例图展示参与者、用例和关系，用况描述则把每个用例的事件流写清楚，图是骨架，描述是内容。

4. 静态结构与对象职责高频考点：类图、可见性、内聚、组件与部署

静态结构题看起来零散，实际围绕三个问题：类怎么分、职责怎么放、实现部件怎么落到物理视图。高内聚、可见性、实体类/控制类/边界类、组件、接口、包、节点、部署图、正向逆向工程，都是常考点。答这类题要少写口号，多写判定标准。

4.1 类图与对象职责：高内聚、可见性、实体/控制/边界类

高内聚度是对一个类中的各个职责之间相关程度和集中程度的度量。一个类具有高度相关的职责，并且完成的工作量不是特别巨大，就具有高内聚度。它包括两层意思：不要给一个类分派太多职责，履行职责时尽量把部分职责分派给有能力完成的其它类；不相关的职责不要分派到同一个类。答题时最好分三层写：职责相关、职责不过载、不相关职责拆分。只写“职责少”不准确，高内聚不是类越小越好，而是相关职责集中、不相关职责分离。

对象间的可见性指一个对象能够“看到”或者引用另一个对象的能力。这个定义短，但简答题会追问实现方式。可以答：一个对象要能给另一个对象发消息，必须持有对方的可见性，常见来源包括属性引用、参数传入、局部创建、全局约定等。答题时不要把它写成“能不能看见界面”，可见性是对象之间的引用能力，不是视觉可见。

类通常可以分为实体类、控制类和边界类。实体类承载业务概念和持久信息；控制类协调用例流程；边界类处理系统与外部参与者之间的交互。选择题里常把父类、子类、祖先类混进来，问“类通常可以分为实体类、什么和边界类”，答案是控制类。这个分类和 MVC 不是一回事，答题时不要硬套框架术语。

类图的位置也常考。类图通常画在逻辑视图里，用例视图关注外部行为，组件视图关注实现部件，部署视图关注节点部署。题目如果问“类图应该画在哪种视图”，应选逻辑视图。对象之间通过消息通信，在面向对象语言里通常对应方法调用。这个点可以和顺序图连起来：顺序图里的消息，落到代码层面往往就是一次方法调用。

状态图和活动图的区分也常混进静态结构题。状态图对单个反应型对象的生命周期建模，描述对象随时间变化的行为；活动图更强调流程、并发和多个参与者的活动过程。泳道技术是把活动图中的活动状态分组，每组表示特定类、人或部门负责完成组内活动。动作状态可以理解为方法体中的每一条语句，活动状态更像一次方法执行。这些比喻可以帮助选择题排除，但简答题仍要写标准定义。

4.2 组件、部署、包与实现视图：物理部件题抓“可替换、接口、节点”

组件是系统中遵从一组接口且提供实现的一个物理部件，通常指开发和运行时类的物理实现。软件构件是可复用的、提供明确接口完成特定功能的程序代码块。接口是一组用于描述类或组件服务的操作。包是用于把元素组织成组的通用机制。节点是运行环境的物理或逻辑单元，被节点执行的事物通常是组件。这些定义会以单选或填空出现，关键词要背准：组件看“物理部件、接口、实现”，接口看“服务操作”，包看“组织元素”，节点看“执行环境”。

组件图用于对系统的静态实现视图建模，这种视图主要支持系统部件的配置管理。常见建模方式包括对源代码建模、对事物建模、对物理数据库建模；题目问“哪种不是”，如果出现“对可适应的系统建模”，通常应排除。答题时不要被“可适应”这种听起来合理的词带走，组件图建模对象是源代码、可执行事物、物理数据库等实现制品，不是泛泛的适应能力。

部署图关注节点和物理部署。题目问“哪个是系统中遵从一组接口且提供实现的物理部件”，答案是组件，不是部署图、类或接口。部署图描述这些组件如何分布到节点上运行。组件图和部署图经常成对出现：组件图回答“有哪些实现部件”，部署图回答“这些部件放在哪些节点上”。

正向工程和逆向工程也常考。正向工程是把模型转换为代码的过程，逆向工程是把代码转换为模型的过程。题目里如果写“正向工程是通过从特定实现语言的映射而把代码转换为模型”，这是把逆向工程说成了正向工程，应判错。答题时抓方向：模型到代码是正向，代码到模型是逆向。某建模工具可以支持两者，但方向不能反。

事件类型题也要留意。事件表示对一个在时间和空间上占据一定位置的有意义事情的规格说明，常见类型包括信号、调用事件、时间事件；选项里出现“源事件”通常不是标准事件类型。这个点不常出简答，但选择题容易丢。记法是把事件按“外部信号、调用、时间”三类记，遇到陌生词先排除。

5. 易错题与失分点：五类送分题为什么总答反

易错题不是难题，而是题干里埋了一个反向词。下面五类在 UML 题库里反复出现，错法也很集中。每一条都按“错在哪—为什么错—怎么答对”拆，练的时候不要只看正确选项，要能说出错误选项为什么错。

5.1 图种与交互图：三个高频翻车点

第一类，把协作图当成顺序图的一种特例。错在选择题里看到“协作图是顺序图的一种特例”就选它，或者简答题里写“协作图是顺序图的简化版”。为什么错：顺序图和协作图都是交互图，二者是并列视角，顺序图强调时间顺序，协作图强调对象组织和交互语境，不存在谁是谁的特例。怎么答对：先写“并列交互图”，再写“一个重时间、一个重对象组织”，最后补一句“协作图用消息编号表示时间顺序”。只要这三句在，特例类选项就排除了。

第二类，在协作图里用箭头位置判断消息先后。错在把协作图当顺序图看，认为画在上面的箭头先发生。为什么错：协作图按空间组织布图，时间顺序通过消息编号表示，不靠箭头高低。怎么答对：看到协作图题先找“消息编号”四个字；问“通过什么表示消息时间顺序”，答消息编号。如果题目问顺序图靠什么表示时间顺序，答消息在生命线之间的先后位置。两张图的时间表达方式要分开记。

第三类，画 SSD 时把系统内部结构和功能展开。错在选“详细描述系统内部结构并罗列功能”，觉得这样才完整。为什么错：SSD 是系统顺序图，系统在图中是黑匣子，只画外部参与者、系统边界和系统操作，内部结构与功能不属于这一层。怎么答对：先写“黑匣子原则”，再写“只描述外部交互和系统操作”，最后补“内部结构留给设计阶段”。这个答法在选择题和简答题里都稳。

5.2 过程、关系与职责：两个容易靠语感的坑

第四类，用例关系靠“都需要”就选扩展。错在题目说“创建新订单和更新订单都需要检查用户账号”，考生看到“都”字反而选了 extend。为什么错：include 表示基用例每次执行都会走的公共行为，extend 表示可选或条件触发的增强。两个用例都需要检查账号，说明检查账号是公共必做步骤，应选包含。怎么答对：先问“是不是每次必做”，是则 include；再问“是不是可选增强”，是则 extend；最后看是不是一般特殊，是则泛化。箭头方向也要记：包含关系指向被包含用例，扩展关系指向基用例。

第五类，UP 初始阶段把所有需求定完。错在把“定义大多数需求和范围”选到初始阶段，或者把“粗略评估成本”和“进一步评估成本”混在一起。为什么错：初始阶段只做愿景、业务案例、确定范围、粗略评估成本；细化阶段才细化愿景、迭代实现核心构架、解决高风险问题、定义大多数需求和范围、进一步评估成本。怎么答对：记两组搭配词，初始配“愿景、业务案例、范围、粗略”，细化配“核心架构、高风险、大多数需求、进一步”。看到“大多数需求”直接跳到细化阶段，不要犹豫。

6. 考场答题模板：从选择题排除到简答题踩分

UML 题不需要写长篇大论，但需要每一步都有判定依据。我后来带人练题，会强制走三步：先判图种，再判阶段，最后判关系词。选择题也照走，把排除理由压在题干边上，避免凭印象选。

选择题的排除顺序可以固定为：先排图种明显不符的选项，再排把静态动态说反的选项，最后排“特例”“子类”“内部结构”这类绝对化表达。简答题按“定义—对比—场景”三段写：第一段给定义，第二段写两到三条差异，第三段写什么时候用。比如顺序图和协作图，定义写并列交互图，对比写时间顺序与对象组织、布图方式、优缺点，场景写讲消息先后用顺序图、讲对象组织用协作图。用例关系题按“是否每次必做—是否可选—是否一般特殊”写，阶段题按“初始定范围、细化定大多数需求、构造做其余实现、提交做部署测试”写。

押题思路不用撒太宽。图种判定、顺序图与协作图差异、用例 include/extend、UP 四阶段职责、领域模型概念类、高内聚与可见性、组件与部署，这几块已经覆盖了大部分选择题和简答题。每道错题只记一个判定词，比如“消息编号”对应协作图，“大多数需求”对应细化阶段，“每次必做”对应 include，“黑匣子”对应 SSD。考前翻这些判定词，比翻整本笔记有效。

我后来每次模考都强制先写图种再写理由，哪怕是一道单选题，也把“为什么不是协作图、为什么不是初始阶段”写在旁边。这个习惯救过很多次，因为 UML 题最容易的不是不会，而是看漏一个词就答反。希望帮到你。

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