UML笔试与建模面试高频考点：图种判定、用例关系与UP四阶段

简介围绕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、泛化选择题的排除顺序可以固定为先排图种明显不符的选项再排把静态动态说反的选项最后排“特例”“子类”“内部结构”这类绝对化表达。简答题按“定义—对比—场景”三段写第一段给定义第二段写两到三条差异第三段写什么时候用。比如顺序图和协作图定义写并列交互图对比写时间顺序与对象组织、布图方式、优缺点场景写讲消息先后用顺序图、讲对象组织用协作图。用例关系题按“是否每次必做—是否可选—是否一般特殊”写阶段题按“初始定范围、细化定大多数需求、构造做其余实现、提交做部署测试”写。押题思路不用撒太宽。图种判定、顺序图与协作图差异、用例 include/extend、UP 四阶段职责、领域模型概念类、高内聚与可见性、组件与部署这几块已经覆盖了大部分选择题和简答题。每道错题只记一个判定词比如“消息编号”对应协作图“大多数需求”对应细化阶段“每次必做”对应 include“黑匣子”对应 SSD。考前翻这些判定词比翻整本笔记有效。我后来每次模考都强制先写图种再写理由哪怕是一道单选题也把“为什么不是协作图、为什么不是初始阶段”写在旁边。这个习惯救过很多次因为 UML 题最容易的不是不会而是看漏一个词就答反。希望帮到你。本文还有配套的精品资源点击获取