简介这份资源是一套面向软件工程课程复习与UML建模入门学习者的试题合集围绕用例图、顺序图、协作图等核心图形展开帮助读者梳理统一建模语言的知识框架并检验掌握程度。压缩包内共1个doc文件整体约62KB以文字题目与参考答案为主要内容便于直接阅读、检索和打印成纸质复习材料。资源已有11276人学习下载具备一定的参考热度与口碑基础。内容涵盖顺序图与协作图在时间顺序和空间组织上的差异比较、高内聚度的含义、类图与用例图等九种图形在静态与动态视图中的分工、对象间可见性、领域模型的建模步骤以及统一过程四阶段与增量开发的要点并配有选择、填空与简答等多种题型读者可据此定位薄弱知识点、对照答案理解概念边界也可用作课堂练习或考前自测的题源。1. 反直觉的开场UML 卷面分值最高的往往不是画图卷子发下来多数人第一反应是找画图题觉得能把顺序图、用例图画出来才算本事。真刷过几套 UML 试题就会发现分值最密集的地方是选择题和填空题给一段订单场景判断该用包含还是扩展给一串图名判断哪个不属于静态视图给四个阶段判断“定义大多数需求”落在哪一步。这类题不难却错得离谱因为考的全是边界和归属不是理解深度。这场考试考的是你对 UML 这套符号体系的分类能力——九种图分五类、统一过程四个阶段的分工、用例描述的三种格式、顺序图与协作图的差别。拿分靠把对照关系背成条件反射而不是临场推理。这份笔记适合已经过了一遍教材、正在刷题找手感的人也适合面试前要把 UML 术语说准的人。2. 交互图考点顺序图与协作图的差别一套卷子至少撞三道交互图是这套题里出现频率最高的模块。翻一遍题干就能看出来问两种交互图差别的简答题有问“消息序列可用哪两种图表示”的选择题有问“协作图是不是顺序图特例”的判断题也有。同一个知识点换三种问法说明出题人认定这是必须拿下的分。这一章先把差别讲透再用真题演示怎么排除干扰项最后落到顺序图四要素这种细节题上。2.1 顺序图与协作图的差别背这三句就够用第一句顺序图强调交互的时间顺序协作图强调交互的语境和参与交互的对象的整体组织。第二句顺序图按时间顺序布图纵向是时间轴、横向是对象协作图按空间组织布图对象摆在图上消息沿着对象之间的连接走。第三句顺序图能清晰表达消息之间的先后和时间关系代价是要占掉较多水平方向的空间协作图增加对象容易、分支少可一旦消息多起来消息之间的顺序就很难表示。这三句背后是一组取舍。顺序图把“谁先谁后”写在排版里读图的人不用翻编号就能看出第一步、第二步协作图把“谁跟谁有关系”摆在明面上对象增删不影响整体布局但时间信息只能靠消息编号补。所以题干里出现“强调时间顺序”“按时间顺序组织”答案就是顺序图出现“强调对象组织”“空间结构”“消息编号表示顺序”答案就是协作图。对比维度顺序图协作图强调重点交互的时间顺序交互的语境与对象整体组织布图方式按时间顺序纵向延伸按空间组织对象铺开空间开销水平方向占用大增加对象容易分支少消息顺序排版直接体现靠消息编号体现适用场景消息多、时序要求严格对象多、结构关系复杂提示简答题写差别时先写“强调什么”再写“怎么布图”最后写“各自优缺点”三句话一段阅卷点基本都能踩到。2.2 真题演练三类问法三种排除路径第一类直接问“消息序列可用哪两种图表示”。选项里会混进状态图和活动图。这类题的排除路径很固定交互图只有两种顺序图和协作图其余都是行为图里的其他分支。状态图描述的是单个对象随事件变化的状态迁移活动图描述的是控制流它们都不以“对象之间的消息交换”为核心。看到“消息序列”“对象间交互”这几个字答案就锁死在顺序图加协作图这一组。第二类问“协作图中通过什么表示消息的时间顺序”。这是填空题的常见形态答案是消息编号。很多人在“消息编号”和“消息箭头”之间犹豫箭头只表示消息的方向和存在不带先后协作图没有时间轴先后关系全靠编号标出来。同一道题会顺带考顺序图顺序图里不需要编号因为从上到下就是时间顺序。第三类判断“协作图是顺序图的一种特例”对不对。这是最典型的翻车点答案是错。两种图是并列的交互图只是表达侧重点不同不存在谁包含谁。题干常把它和另一句正确描述放在一起——“协作图作为一种交互图强调的是参加交互的对象的组织”“协作图中有消息流的顺序号”这两句都对就那一句错选“不正确”的时候别被正确选项带跑。再补一道看图定位的题类图应该画在建模工具的哪个视图里。答案是逻辑视图Logic View。这类题考的是视图分工用例视图放用例模型逻辑视图放类图和对象图组件视图放构件部署视图放节点。记不住就按“逻辑视图装类”这五个字背。2.3 顺序图四要素与画图得分点顺序图的组成是四个类角色、生命线、激活期、消息。这四个词要能默写选择题经常挖掉其中一个换成“关系”“用例”“实体”来凑选项。类角色就是参与交互的对象摆在图顶部生命线是从对象往下延伸的虚线表示对象存在的时间段激活期是生命线上的窄条表示对象正在执行某个操作消息是对象之间的箭头分为同步消息、异步消息和返回消息。画图题的得分点通常不在美观而在这几处对象名是否带下划线并写明类型匿名对象也要标、消息箭头方向是否和调用关系一致、激活期是否覆盖了消息处理的那一段、返回消息是否用虚线。自调用要画成折回自身的箭头条件消息要带监护条件。丢分最多的是把返回消息画成实线箭头或者激活期画成贯穿整条生命线。还有一个常被忽略的知识点消息通信在面向对象语言里对应什么。答案是方法调用。消息是建模层面的说法落到代码就是一次方法调用所以顺序图本质上画的是调用链。理解了这一层“对象间的可见性”那道题也就不难了——可见性指一个对象能够看到或者引用另一个对象的能力没有可见性就发不出消息顺序图上的每条箭头背后都得有可见性撑着。3. 用例图与需求建模包含、扩展、泛化的判定和用例描述的三档写法用例图这块的分值分布很集中一道关系判定题一道用例描述格式题一道系统边界题再加一道领域模型的概念类题。四道题共用一套底层逻辑——用例只描述系统对外承担什么责任不描述内部怎么实现。抓住这条线四道题都能推出来。3.1 包含与扩展一个“必须做”一个“可能做”真题里的场景是这样的订单输入子系统里创建新订单和更新订单都需要检查用户账号是否正确。问“创建新订单”“更新订单”与“检查用户账号”之间是什么关系。答案是包含include。判定口诀只有一句被抽出去的那段行为是不是每次执行主用例都必然发生。检查账号在创建和更新两个用例里都必须执行抽出来复用用包含。扩展则相反基用例本身能独立完成扩展用例只在特定条件下才插入。比如“下单”用例只有会员才走“使用积分抵扣”这就是扩展。两者的箭头方向也常考。包含是箭头从基用例指向被包含用例因为基用例依赖那段行为扩展是箭头从扩展用例指向基用例因为扩展用例插进基用例。方向搞反是选择题里最常见的失分记住“谁依赖谁箭头指向被依赖的一方”就不会错。关系触发条件是否必需箭头方向包含 include无条件每次执行必需基用例 → 被包含用例扩展 extend满足监护条件时可选扩展用例 → 基用例泛化子用例是父用例的特化继承关系子 → 父3.2 用例是什么、用例模型是什么、用例怎么写用例的定义要背准用例是一个描述性的文档用来描述一个参与者使用系统完成某个业务过程时的事件发生顺序。它描述系统的使用过程描述功能需求但不描述系统内部如何工作只定义系统责任说明系统必须做什么。这三句话是简答题的骨架缺一句就少一个采分点。用例模型是需求工作中的一个重要制品。这句话经常作为判断题出现把“重要制品”改成“可选文档”就错了。用例描述的格式分三档Brief简短、Casual随意、Fully Dressed详述。三档的差别在于模板完整度——Brief 只有一段话概括Casual 有几个段落覆盖基本流程Fully Dressed 包含前置条件、后置条件、主成功场景、扩展场景、业务规则等完整字段。选择题常问“哪三种类型”答不上来就丢分但也就是三个单词的事。写用例时最容易犯的错是把内部实现写进去。比如把“系统查询数据库并返回结果集”写成用例步骤这就越界了用例应该写“系统显示符合条件的订单列表”。判卷时看到“数据库”“缓存”“接口调用”这类词基本可以判定写偏了。3.3 系统顺序图那道题不描述内部结构真题原题画系统顺序图SSD时该如何对待所涉及的系统。四个选项里三个都在说“详细描述内部结构”“罗列所有功能”正确答案是“不对系统的内部结构与功能进行描述”。这道题考的是系统边界。SSD 把系统当成一个黑盒只画外部参与者发进来的消息和系统返回的响应盒子里面是空的。一旦开始画系统内部的对象那就变成设计阶段的顺序图不是系统顺序图了。面试里问“你怎么理解系统顺序图”答“它站在系统外部视角只关心跨边界的事件不关心内部由谁处理”比背定义更让人信服。3.4 领域模型与概念类两种找法四步建模领域模型的定义有两层一层是“表示真实世界的概念类”一层是“不是软件部件的模型”。这两句经常被拆成填空题问“领域模型是一组表示真实世界的概念类不是软件部件的模型”。记住对比领域模型里的“订单”“客户”是业务里的概念不是代码里的类不带属性和方法的实现细节。找概念类有两种方法概念类类别表、标识名词短语。前者是拿一张现成的分类表逐项对照看系统里有没有对应的事物后者是把需求文档里的名词圈出来再逐个判断是不是概念类。两种方法各有短板类别表容易漏掉行业特有的概念名词短语法容易把“系统”“报表”这类非概念类的东西圈进来所以实际做的时候常常两种一起用。领域建模的步骤是四步列出候选的概念类、画出领域模型图、必要时加入概念类间的关联、必要时加入概念类的属性。这四步的顺序不能乱先有类再有图先有关联再补属性。考试里常把“加入属性”提到第二步来挖坑因为属性是最后才补的细节过早加属性容易把模型带偏。4. 九种图归类静态视图、动态视图、实现图一张判定表通吃UML 的图类题看起来零散其实就考一件事你脑子里有没有一张分类表。标准建模语言的重要内容可以由五类图共九种图形来定义——用例图、静态图包括类图、对象图和包图、行为图、交互图、实现图。这五类九种是总纲所有归类题都是从这里长出来的。4.1 五类九种图对照表类别包含的图主要用途用例图用例图描述系统行为组织与功能需求对系统行为建模静态图类图、对象图、包图描述系统的静态设计视图行为图状态图、活动图描述对象随时间变化的行为与控制流交互图顺序图、协作图描述对象之间的交互与消息传递实现图组件图、部署图描述系统的物理实现与部署结构连线题是这块的经典题型给一组图名和一组描述让你配对。类图对应“系统的静态设计视图”用例图对应“对系统的行为进行组织和建模”顺序图和协作图对应“描述系统动态视图的交互图”其中顺序图描述“以时间顺序组织的对象之间的交互活动”协作图“强调收发消息的对象的组织结构”。这五组配对要背到闭眼能写。容易混的是“静态设计视图”和“静态实现视图”。类图是设计视图组件图是实现视图。设计视图面向逻辑结构实现视图面向物理构件。题干里出现“配置管理”“物理部件”就往实现图上靠出现“类的结构”“属性与操作”就往设计图上靠。4.2 状态图不是静态视图真题里有一道很典型的排除题下面哪个不是 UML 中的静态视图选项是状态图、用例图、对象图、类图答案是状态图。这道题每年换个包装重出因为状态图名字里没有“动”字很多人凭语感就选错了。判断依据是状态图描述的是对象在生命周期中随事件发生的状态迁移属于行为图。行为图和交互图都归到动态这一侧。用例图虽然叫用例但它是对系统行为的组织和建模属于需求侧既不算静态结构图也不算交互图被归在五类里的第一类。对象图和类图是静态图包图也是。再进一步状态图和活动图的区别也常考。状态图对反应型对象建模强调单个对象的状态变化活动图对有几个对象参与的活动过程建模强调控制流和并发。有一道题的选项写“状态图是活动图的一个特例状态图中的多数状态是活动状态”这是错的两者是并列的行为图不是特例关系。正确说法是活动图和状态图都对一个对象的生命周期进行建模描述对象随时间变化的行为只是侧重点不同。4.3 构件、节点、接口、包四个名词别搅在一起构件是系统中遵从一组接口且提供实现的一个物理部件通常指开发和运行时类的物理实现。这句话要能复述选择题里经常把“物理部件”换成“逻辑单元”来设错。构件是可复用的、提供明确接口完成特定功能的程序代码块这个定义和上面那句是同一件事的两种说法。组件图用于对系统的静态实现视图建模这种视图主要支持系统部件的配置管理通常有四种完成方式对源代码建模、对可执行体建模、对物理数据库建模、对可适应系统建模。真题把其中一项换成“对事物建模”让你选哪个不是答案就是它。这里没有太多推理空间四种方式记住就行。节点是被节点执行的事物答案是构件。这个问法有点绕本质是问节点上跑什么跑的是构件。接口是一组用于描述类或组件的一个服务的操作注意是“操作的集合”不是实现。包是用于把元素组织成组的通用机制是分组用的不是运行单元。这四个词经常被放在同一道题的不同选项里靠“物理部件—构件、执行物—构件、操作集合—接口、分组机制—包”这四句对应关系逐个排除。类还可以按职责分成实体类、控制类和边界类。实体类承载业务数据控制类协调用例流程边界类处理与外部参与者的交互。这道题的错误选项通常是“父类”“子类”“祖先类”它们说的是继承层次不是职责分类。4.4 泳道、分叉汇合、动作状态活动图里的细节题泳道技术是把活动图中的活动状态进行分组每一组表示一个特定的类、人或部门他们负责完成组内的活动。这道题的关键词是“分组”和“负责”看到“谁负责哪些活动”就是泳道看到“并行开始或结束”就是分叉汇合看到“从一个活动到另一个活动”就是转移看到“满足条件走不同路径”就是分支。动作状态和活动状态的区分也常出。若把活动状态比作方法那么动作状态即方法体中的每一条语句。这个类比很好用活动状态是可以被分解的粗粒度行为动作状态是不可再分的原子步骤。题目问“动作状态相当于什么”答“方法体中的每一条语句”问“活动状态相当于什么”答“方法”。事件类型那道题事件表示对一个在时间和空间上占据一定位置的有意义的事情的规格说明类型包括信号、调用事件、时间事件不包括“源事件”。信号是异步的显式通信调用事件是同步的方法调用时间事件是超时或绝对时刻触发。按下按钮和打印机中断这类属于外部事件与内部事件相对。这些点单独看很碎但它们共同构成“动态建模”这一块的选择题池子刷题时按图分类整理比逐题死记效率高。5. 易错点五个一考就翻车的 UML 判断题这一章挑的是错得最有规律的五处。共同特征是看起来像常识实际考的是定义边界凭语感答必错。5.1 错点一把协作图当成顺序图的特例错在哪题干写“协作图是顺序图的一种特例”很多人觉得两者都是交互图、都能互转就判对。为什么错特例意味着包含关系和继承关系协作图和顺序图是并列的两种交互图表达同一段交互的不同侧面谁也不是谁的子集。部分建模工具支持从顺序图按快捷键生成协作图那是工具层面的转换功能不是模型层面的包含关系。出题人正是利用“能互转”这个印象设套。怎么答对记住一句话——两种交互图是同一个交互的两种画法不是父子关系。凡是出现“特例”“子类”“包含”这类词描述两者关系的一律判错。5.2 错点二初始阶段和细化阶段的职责张冠李戴错在哪问“定义大多数的需求和范围”在统一过程的哪个阶段完成选项里初始阶段和细化阶段都很有迷惑性。为什么错初始阶段确实要做需求相关的事但只到“确定范围、编制简要的愿景文档、业务案例、粗略评估成本”这个粒度。真正“定义大多数的需求和范围、进一步评估成本”是细化阶段。两者的分界线是粗略和大多数——初始阶段给的是范围边界细化阶段给的是可执行的需求基线。怎么答对把四个阶段的产物列成一条线。初始阶段简要愿景文档、业务案例、确定范围、粗略评估成本。细化阶段细化愿景文档、迭代实现核心构架、解决高风险问题、定义大多数需求和范围、进一步评估成本。构造阶段迭代实现其余部分、准备部署。提交阶段beta 测试、部署。题干里凡是“大多数”“核心架构”“高风险”都指向细化阶段。5.3 错点三高内聚度理解成“一个类干得越多越好”错在哪问什么是高内聚度答“一个类承担的职责越多、功能越全内聚度越高”。为什么错高内聚度度量的是一个类中各个职责之间的相关程度和集中程度不是数量。职责高度相关、工作量又不是特别巨大才叫高内聚。它包含两层意思不要给一个类分派太多职责履行职责时尽量把部分职责分派给有能力完成的其它类不相关的职责不要分派到同一个类。也就是说职责多但不相关那是低内聚。怎么答对答题时先给定义再拆成两句——“职责相关且集中”和“不相关职责不放在一起”。如果题目给了场景判断标准是看这些职责是否围绕同一个业务概念转围着同一个概念转就是高内聚把订单计算和日志记录塞进一个类就是低内聚。5.4 错点四正向工程和逆向工程说反错在哪题干问“下面关于正向工程与逆向工程的描述哪个不正确”选项里把“正向工程是从实现语言映射回模型”写进去很多人读快了就放过。为什么错正向工程是把模型转换为代码方向是模型到代码逆向工程是把代码转换为模型方向是代码到模型。两个词的字面方向感和实际方向感容易打架尤其“正向”听起来像“从代码往前推”。怎么答对绑一个动作记——正向是“生成代码”逆向是“读回模型”。看到“模型→代码”就是正向看到“代码→模型”就是逆向。这两者都能在建模工具里实现所以“可以通过建模工具支持实现”这类描述是对的不要一起判错。5.5 错点五建模基本原则里的“一个模型就够了”错在哪问哪个不是建模的基本原则选项写“对一个重要的系统用一个模型就可以充分描述”有人觉得模型越精简越好就放过了这一项。为什么错建模的基本原则要求仔细选择模型、每一种模型可以在不同的精度级别上表示所要开发的系统、模型要与现实相联系。一个系统需要从多个视角描述静态结构、动态行为、部署结构各是一套模型单一模型无法覆盖。这恰恰是 UML 要定义九种图的原因。怎么答对凡是出现“一个模型足够”“一种图能描述全部”的表述直接判错。与之配套的还有一道题UML 体系包括三个部分基本构造块、规则和公共机制。构造块包括事物、关系、图事物又分结构事物、行为事物、分组事物、注释事物。这棵树的每一层都可能被挖空按层级背比零散记牢。6. 答题技巧三步定位法把选择题压到二十秒考场上最耗时间的不是不会是犹豫。UML 选择题的选项往往都“像那么回事”因为错误选项通常是从相邻知识点借来的。我后来固定用一套三步定位把犹豫压掉。第一步判图类别。题干出现“消息”“交互”“对象之间”先划到交互图这一格答案只可能是顺序图或协作图出现“状态迁移”“事件触发”划到行为图出现“物理部件”“部署”“配置”划到实现图出现“参与者”“系统边界”划到用例图。这一步能干掉一半干扰项。第二步判阶段或职责。题干出现“大多数需求”“核心架构”“高风险”锁细化阶段出现“愿景文档”“业务案例”“粗略成本”锁初始阶段出现“beta 测试”“部署”锁提交阶段。出现“职责相关”“不相关职责”锁高内聚出现“能看到或引用”锁可见性。第三步排除绝对化表述。凡是“特例”“一个模型足够”“完全描述”“必须详细描述内部结构”这类说法优先怀疑。UML 的题很少奖励绝对化它奖励的是边界清晰。题干关键词锁定答案常见干扰项消息序列 / 对象交互顺序图、协作图状态图、活动图消息编号协作图顺序图必须执行的行为复用包含 include扩展 extend条件触发的插入行为扩展 extend包含 include真实世界的概念类领域模型软件部件模型大多数需求与范围细化阶段初始阶段物理部件 / 配置管理组件图类图泳道活动状态分组分叉汇合押题方向我按出现频率排了序交互图差别简答选择、包含与扩展判定、五类九种图归类、统一过程四阶段职责、领域模型与概念类两法、用例描述三档格式、状态图与活动图区别、构件与节点接口包的定义、高内聚度、可见性。前十项覆盖了这套题里绝大多数重复考点考前两小时只看这张表和上面那张分类表性价比最高。最后说个血泪经验。我第一次做这类卷子栽在一道“哪个不是静态视图”的题上选了状态图又改回类图来回两遍还是错原因就是当时靠语感判断没有把“行为图”这一层类别立在脑子里。从那以后我每次做归类题都强制先在草稿上写“用例静态行为交互实现”五个字再把选项往里塞塞不进去的就是答案。这个动作花五秒能省下反复改答案的几分钟也顺带把简答题的分类框架默了一遍。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/11/4 12:18:48 · 阅读 1.2k UML高频考点速记：九种图分类、顺序图协作图与包含扩展判定
简介这份资源是一套面向软件工程课程复习与UML建模入门学习者的试题合集围绕用例图、顺序图、协作图等核心图形展开帮助读者梳理统一建模语言的知识框架并检验掌握程度。压缩包内共1个doc文件整体约62KB以文字题目与参考答案为主要内容便于直接阅读、检索和打印成纸质复习材料。资源已有11276人学习下载具备一定的参考热度与口碑基础。内容涵盖顺序图与协作图在时间顺序和空间组织上的差异比较、高内聚度的含义、类图与用例图等九种图形在静态与动态视图中的分工、对象间可见性、领域模型的建模步骤以及统一过程四阶段与增量开发的要点并配有选择、填空与简答等多种题型读者可据此定位薄弱知识点、对照答案理解概念边界也可用作课堂练习或考前自测的题源。1. 反直觉的开场UML 卷面分值最高的往往不是画图卷子发下来多数人第一反应是找画图题觉得能把顺序图、用例图画出来才算本事。真刷过几套 UML 试题就会发现分值最密集的地方是选择题和填空题给一段订单场景判断该用包含还是扩展给一串图名判断哪个不属于静态视图给四个阶段判断“定义大多数需求”落在哪一步。这类题不难却错得离谱因为考的全是边界和归属不是理解深度。这场考试考的是你对 UML 这套符号体系的分类能力——九种图分五类、统一过程四个阶段的分工、用例描述的三种格式、顺序图与协作图的差别。拿分靠把对照关系背成条件反射而不是临场推理。这份笔记适合已经过了一遍教材、正在刷题找手感的人也适合面试前要把 UML 术语说准的人。2. 交互图考点顺序图与协作图的差别一套卷子至少撞三道交互图是这套题里出现频率最高的模块。翻一遍题干就能看出来问两种交互图差别的简答题有问“消息序列可用哪两种图表示”的选择题有问“协作图是不是顺序图特例”的判断题也有。同一个知识点换三种问法说明出题人认定这是必须拿下的分。这一章先把差别讲透再用真题演示怎么排除干扰项最后落到顺序图四要素这种细节题上。2.1 顺序图与协作图的差别背这三句就够用第一句顺序图强调交互的时间顺序协作图强调交互的语境和参与交互的对象的整体组织。第二句顺序图按时间顺序布图纵向是时间轴、横向是对象协作图按空间组织布图对象摆在图上消息沿着对象之间的连接走。第三句顺序图能清晰表达消息之间的先后和时间关系代价是要占掉较多水平方向的空间协作图增加对象容易、分支少可一旦消息多起来消息之间的顺序就很难表示。这三句背后是一组取舍。顺序图把“谁先谁后”写在排版里读图的人不用翻编号就能看出第一步、第二步协作图把“谁跟谁有关系”摆在明面上对象增删不影响整体布局但时间信息只能靠消息编号补。所以题干里出现“强调时间顺序”“按时间顺序组织”答案就是顺序图出现“强调对象组织”“空间结构”“消息编号表示顺序”答案就是协作图。对比维度顺序图协作图强调重点交互的时间顺序交互的语境与对象整体组织布图方式按时间顺序纵向延伸按空间组织对象铺开空间开销水平方向占用大增加对象容易分支少消息顺序排版直接体现靠消息编号体现适用场景消息多、时序要求严格对象多、结构关系复杂提示简答题写差别时先写“强调什么”再写“怎么布图”最后写“各自优缺点”三句话一段阅卷点基本都能踩到。2.2 真题演练三类问法三种排除路径第一类直接问“消息序列可用哪两种图表示”。选项里会混进状态图和活动图。这类题的排除路径很固定交互图只有两种顺序图和协作图其余都是行为图里的其他分支。状态图描述的是单个对象随事件变化的状态迁移活动图描述的是控制流它们都不以“对象之间的消息交换”为核心。看到“消息序列”“对象间交互”这几个字答案就锁死在顺序图加协作图这一组。第二类问“协作图中通过什么表示消息的时间顺序”。这是填空题的常见形态答案是消息编号。很多人在“消息编号”和“消息箭头”之间犹豫箭头只表示消息的方向和存在不带先后协作图没有时间轴先后关系全靠编号标出来。同一道题会顺带考顺序图顺序图里不需要编号因为从上到下就是时间顺序。第三类判断“协作图是顺序图的一种特例”对不对。这是最典型的翻车点答案是错。两种图是并列的交互图只是表达侧重点不同不存在谁包含谁。题干常把它和另一句正确描述放在一起——“协作图作为一种交互图强调的是参加交互的对象的组织”“协作图中有消息流的顺序号”这两句都对就那一句错选“不正确”的时候别被正确选项带跑。再补一道看图定位的题类图应该画在建模工具的哪个视图里。答案是逻辑视图Logic View。这类题考的是视图分工用例视图放用例模型逻辑视图放类图和对象图组件视图放构件部署视图放节点。记不住就按“逻辑视图装类”这五个字背。2.3 顺序图四要素与画图得分点顺序图的组成是四个类角色、生命线、激活期、消息。这四个词要能默写选择题经常挖掉其中一个换成“关系”“用例”“实体”来凑选项。类角色就是参与交互的对象摆在图顶部生命线是从对象往下延伸的虚线表示对象存在的时间段激活期是生命线上的窄条表示对象正在执行某个操作消息是对象之间的箭头分为同步消息、异步消息和返回消息。画图题的得分点通常不在美观而在这几处对象名是否带下划线并写明类型匿名对象也要标、消息箭头方向是否和调用关系一致、激活期是否覆盖了消息处理的那一段、返回消息是否用虚线。自调用要画成折回自身的箭头条件消息要带监护条件。丢分最多的是把返回消息画成实线箭头或者激活期画成贯穿整条生命线。还有一个常被忽略的知识点消息通信在面向对象语言里对应什么。答案是方法调用。消息是建模层面的说法落到代码就是一次方法调用所以顺序图本质上画的是调用链。理解了这一层“对象间的可见性”那道题也就不难了——可见性指一个对象能够看到或者引用另一个对象的能力没有可见性就发不出消息顺序图上的每条箭头背后都得有可见性撑着。3. 用例图与需求建模包含、扩展、泛化的判定和用例描述的三档写法用例图这块的分值分布很集中一道关系判定题一道用例描述格式题一道系统边界题再加一道领域模型的概念类题。四道题共用一套底层逻辑——用例只描述系统对外承担什么责任不描述内部怎么实现。抓住这条线四道题都能推出来。3.1 包含与扩展一个“必须做”一个“可能做”真题里的场景是这样的订单输入子系统里创建新订单和更新订单都需要检查用户账号是否正确。问“创建新订单”“更新订单”与“检查用户账号”之间是什么关系。答案是包含include。判定口诀只有一句被抽出去的那段行为是不是每次执行主用例都必然发生。检查账号在创建和更新两个用例里都必须执行抽出来复用用包含。扩展则相反基用例本身能独立完成扩展用例只在特定条件下才插入。比如“下单”用例只有会员才走“使用积分抵扣”这就是扩展。两者的箭头方向也常考。包含是箭头从基用例指向被包含用例因为基用例依赖那段行为扩展是箭头从扩展用例指向基用例因为扩展用例插进基用例。方向搞反是选择题里最常见的失分记住“谁依赖谁箭头指向被依赖的一方”就不会错。关系触发条件是否必需箭头方向包含 include无条件每次执行必需基用例 → 被包含用例扩展 extend满足监护条件时可选扩展用例 → 基用例泛化子用例是父用例的特化继承关系子 → 父3.2 用例是什么、用例模型是什么、用例怎么写用例的定义要背准用例是一个描述性的文档用来描述一个参与者使用系统完成某个业务过程时的事件发生顺序。它描述系统的使用过程描述功能需求但不描述系统内部如何工作只定义系统责任说明系统必须做什么。这三句话是简答题的骨架缺一句就少一个采分点。用例模型是需求工作中的一个重要制品。这句话经常作为判断题出现把“重要制品”改成“可选文档”就错了。用例描述的格式分三档Brief简短、Casual随意、Fully Dressed详述。三档的差别在于模板完整度——Brief 只有一段话概括Casual 有几个段落覆盖基本流程Fully Dressed 包含前置条件、后置条件、主成功场景、扩展场景、业务规则等完整字段。选择题常问“哪三种类型”答不上来就丢分但也就是三个单词的事。写用例时最容易犯的错是把内部实现写进去。比如把“系统查询数据库并返回结果集”写成用例步骤这就越界了用例应该写“系统显示符合条件的订单列表”。判卷时看到“数据库”“缓存”“接口调用”这类词基本可以判定写偏了。3.3 系统顺序图那道题不描述内部结构真题原题画系统顺序图SSD时该如何对待所涉及的系统。四个选项里三个都在说“详细描述内部结构”“罗列所有功能”正确答案是“不对系统的内部结构与功能进行描述”。这道题考的是系统边界。SSD 把系统当成一个黑盒只画外部参与者发进来的消息和系统返回的响应盒子里面是空的。一旦开始画系统内部的对象那就变成设计阶段的顺序图不是系统顺序图了。面试里问“你怎么理解系统顺序图”答“它站在系统外部视角只关心跨边界的事件不关心内部由谁处理”比背定义更让人信服。3.4 领域模型与概念类两种找法四步建模领域模型的定义有两层一层是“表示真实世界的概念类”一层是“不是软件部件的模型”。这两句经常被拆成填空题问“领域模型是一组表示真实世界的概念类不是软件部件的模型”。记住对比领域模型里的“订单”“客户”是业务里的概念不是代码里的类不带属性和方法的实现细节。找概念类有两种方法概念类类别表、标识名词短语。前者是拿一张现成的分类表逐项对照看系统里有没有对应的事物后者是把需求文档里的名词圈出来再逐个判断是不是概念类。两种方法各有短板类别表容易漏掉行业特有的概念名词短语法容易把“系统”“报表”这类非概念类的东西圈进来所以实际做的时候常常两种一起用。领域建模的步骤是四步列出候选的概念类、画出领域模型图、必要时加入概念类间的关联、必要时加入概念类的属性。这四步的顺序不能乱先有类再有图先有关联再补属性。考试里常把“加入属性”提到第二步来挖坑因为属性是最后才补的细节过早加属性容易把模型带偏。4. 九种图归类静态视图、动态视图、实现图一张判定表通吃UML 的图类题看起来零散其实就考一件事你脑子里有没有一张分类表。标准建模语言的重要内容可以由五类图共九种图形来定义——用例图、静态图包括类图、对象图和包图、行为图、交互图、实现图。这五类九种是总纲所有归类题都是从这里长出来的。4.1 五类九种图对照表类别包含的图主要用途用例图用例图描述系统行为组织与功能需求对系统行为建模静态图类图、对象图、包图描述系统的静态设计视图行为图状态图、活动图描述对象随时间变化的行为与控制流交互图顺序图、协作图描述对象之间的交互与消息传递实现图组件图、部署图描述系统的物理实现与部署结构连线题是这块的经典题型给一组图名和一组描述让你配对。类图对应“系统的静态设计视图”用例图对应“对系统的行为进行组织和建模”顺序图和协作图对应“描述系统动态视图的交互图”其中顺序图描述“以时间顺序组织的对象之间的交互活动”协作图“强调收发消息的对象的组织结构”。这五组配对要背到闭眼能写。容易混的是“静态设计视图”和“静态实现视图”。类图是设计视图组件图是实现视图。设计视图面向逻辑结构实现视图面向物理构件。题干里出现“配置管理”“物理部件”就往实现图上靠出现“类的结构”“属性与操作”就往设计图上靠。4.2 状态图不是静态视图真题里有一道很典型的排除题下面哪个不是 UML 中的静态视图选项是状态图、用例图、对象图、类图答案是状态图。这道题每年换个包装重出因为状态图名字里没有“动”字很多人凭语感就选错了。判断依据是状态图描述的是对象在生命周期中随事件发生的状态迁移属于行为图。行为图和交互图都归到动态这一侧。用例图虽然叫用例但它是对系统行为的组织和建模属于需求侧既不算静态结构图也不算交互图被归在五类里的第一类。对象图和类图是静态图包图也是。再进一步状态图和活动图的区别也常考。状态图对反应型对象建模强调单个对象的状态变化活动图对有几个对象参与的活动过程建模强调控制流和并发。有一道题的选项写“状态图是活动图的一个特例状态图中的多数状态是活动状态”这是错的两者是并列的行为图不是特例关系。正确说法是活动图和状态图都对一个对象的生命周期进行建模描述对象随时间变化的行为只是侧重点不同。4.3 构件、节点、接口、包四个名词别搅在一起构件是系统中遵从一组接口且提供实现的一个物理部件通常指开发和运行时类的物理实现。这句话要能复述选择题里经常把“物理部件”换成“逻辑单元”来设错。构件是可复用的、提供明确接口完成特定功能的程序代码块这个定义和上面那句是同一件事的两种说法。组件图用于对系统的静态实现视图建模这种视图主要支持系统部件的配置管理通常有四种完成方式对源代码建模、对可执行体建模、对物理数据库建模、对可适应系统建模。真题把其中一项换成“对事物建模”让你选哪个不是答案就是它。这里没有太多推理空间四种方式记住就行。节点是被节点执行的事物答案是构件。这个问法有点绕本质是问节点上跑什么跑的是构件。接口是一组用于描述类或组件的一个服务的操作注意是“操作的集合”不是实现。包是用于把元素组织成组的通用机制是分组用的不是运行单元。这四个词经常被放在同一道题的不同选项里靠“物理部件—构件、执行物—构件、操作集合—接口、分组机制—包”这四句对应关系逐个排除。类还可以按职责分成实体类、控制类和边界类。实体类承载业务数据控制类协调用例流程边界类处理与外部参与者的交互。这道题的错误选项通常是“父类”“子类”“祖先类”它们说的是继承层次不是职责分类。4.4 泳道、分叉汇合、动作状态活动图里的细节题泳道技术是把活动图中的活动状态进行分组每一组表示一个特定的类、人或部门他们负责完成组内的活动。这道题的关键词是“分组”和“负责”看到“谁负责哪些活动”就是泳道看到“并行开始或结束”就是分叉汇合看到“从一个活动到另一个活动”就是转移看到“满足条件走不同路径”就是分支。动作状态和活动状态的区分也常出。若把活动状态比作方法那么动作状态即方法体中的每一条语句。这个类比很好用活动状态是可以被分解的粗粒度行为动作状态是不可再分的原子步骤。题目问“动作状态相当于什么”答“方法体中的每一条语句”问“活动状态相当于什么”答“方法”。事件类型那道题事件表示对一个在时间和空间上占据一定位置的有意义的事情的规格说明类型包括信号、调用事件、时间事件不包括“源事件”。信号是异步的显式通信调用事件是同步的方法调用时间事件是超时或绝对时刻触发。按下按钮和打印机中断这类属于外部事件与内部事件相对。这些点单独看很碎但它们共同构成“动态建模”这一块的选择题池子刷题时按图分类整理比逐题死记效率高。5. 易错点五个一考就翻车的 UML 判断题这一章挑的是错得最有规律的五处。共同特征是看起来像常识实际考的是定义边界凭语感答必错。5.1 错点一把协作图当成顺序图的特例错在哪题干写“协作图是顺序图的一种特例”很多人觉得两者都是交互图、都能互转就判对。为什么错特例意味着包含关系和继承关系协作图和顺序图是并列的两种交互图表达同一段交互的不同侧面谁也不是谁的子集。部分建模工具支持从顺序图按快捷键生成协作图那是工具层面的转换功能不是模型层面的包含关系。出题人正是利用“能互转”这个印象设套。怎么答对记住一句话——两种交互图是同一个交互的两种画法不是父子关系。凡是出现“特例”“子类”“包含”这类词描述两者关系的一律判错。5.2 错点二初始阶段和细化阶段的职责张冠李戴错在哪问“定义大多数的需求和范围”在统一过程的哪个阶段完成选项里初始阶段和细化阶段都很有迷惑性。为什么错初始阶段确实要做需求相关的事但只到“确定范围、编制简要的愿景文档、业务案例、粗略评估成本”这个粒度。真正“定义大多数的需求和范围、进一步评估成本”是细化阶段。两者的分界线是粗略和大多数——初始阶段给的是范围边界细化阶段给的是可执行的需求基线。怎么答对把四个阶段的产物列成一条线。初始阶段简要愿景文档、业务案例、确定范围、粗略评估成本。细化阶段细化愿景文档、迭代实现核心构架、解决高风险问题、定义大多数需求和范围、进一步评估成本。构造阶段迭代实现其余部分、准备部署。提交阶段beta 测试、部署。题干里凡是“大多数”“核心架构”“高风险”都指向细化阶段。5.3 错点三高内聚度理解成“一个类干得越多越好”错在哪问什么是高内聚度答“一个类承担的职责越多、功能越全内聚度越高”。为什么错高内聚度度量的是一个类中各个职责之间的相关程度和集中程度不是数量。职责高度相关、工作量又不是特别巨大才叫高内聚。它包含两层意思不要给一个类分派太多职责履行职责时尽量把部分职责分派给有能力完成的其它类不相关的职责不要分派到同一个类。也就是说职责多但不相关那是低内聚。怎么答对答题时先给定义再拆成两句——“职责相关且集中”和“不相关职责不放在一起”。如果题目给了场景判断标准是看这些职责是否围绕同一个业务概念转围着同一个概念转就是高内聚把订单计算和日志记录塞进一个类就是低内聚。5.4 错点四正向工程和逆向工程说反错在哪题干问“下面关于正向工程与逆向工程的描述哪个不正确”选项里把“正向工程是从实现语言映射回模型”写进去很多人读快了就放过。为什么错正向工程是把模型转换为代码方向是模型到代码逆向工程是把代码转换为模型方向是代码到模型。两个词的字面方向感和实际方向感容易打架尤其“正向”听起来像“从代码往前推”。怎么答对绑一个动作记——正向是“生成代码”逆向是“读回模型”。看到“模型→代码”就是正向看到“代码→模型”就是逆向。这两者都能在建模工具里实现所以“可以通过建模工具支持实现”这类描述是对的不要一起判错。5.5 错点五建模基本原则里的“一个模型就够了”错在哪问哪个不是建模的基本原则选项写“对一个重要的系统用一个模型就可以充分描述”有人觉得模型越精简越好就放过了这一项。为什么错建模的基本原则要求仔细选择模型、每一种模型可以在不同的精度级别上表示所要开发的系统、模型要与现实相联系。一个系统需要从多个视角描述静态结构、动态行为、部署结构各是一套模型单一模型无法覆盖。这恰恰是 UML 要定义九种图的原因。怎么答对凡是出现“一个模型足够”“一种图能描述全部”的表述直接判错。与之配套的还有一道题UML 体系包括三个部分基本构造块、规则和公共机制。构造块包括事物、关系、图事物又分结构事物、行为事物、分组事物、注释事物。这棵树的每一层都可能被挖空按层级背比零散记牢。6. 答题技巧三步定位法把选择题压到二十秒考场上最耗时间的不是不会是犹豫。UML 选择题的选项往往都“像那么回事”因为错误选项通常是从相邻知识点借来的。我后来固定用一套三步定位把犹豫压掉。第一步判图类别。题干出现“消息”“交互”“对象之间”先划到交互图这一格答案只可能是顺序图或协作图出现“状态迁移”“事件触发”划到行为图出现“物理部件”“部署”“配置”划到实现图出现“参与者”“系统边界”划到用例图。这一步能干掉一半干扰项。第二步判阶段或职责。题干出现“大多数需求”“核心架构”“高风险”锁细化阶段出现“愿景文档”“业务案例”“粗略成本”锁初始阶段出现“beta 测试”“部署”锁提交阶段。出现“职责相关”“不相关职责”锁高内聚出现“能看到或引用”锁可见性。第三步排除绝对化表述。凡是“特例”“一个模型足够”“完全描述”“必须详细描述内部结构”这类说法优先怀疑。UML 的题很少奖励绝对化它奖励的是边界清晰。题干关键词锁定答案常见干扰项消息序列 / 对象交互顺序图、协作图状态图、活动图消息编号协作图顺序图必须执行的行为复用包含 include扩展 extend条件触发的插入行为扩展 extend包含 include真实世界的概念类领域模型软件部件模型大多数需求与范围细化阶段初始阶段物理部件 / 配置管理组件图类图泳道活动状态分组分叉汇合押题方向我按出现频率排了序交互图差别简答选择、包含与扩展判定、五类九种图归类、统一过程四阶段职责、领域模型与概念类两法、用例描述三档格式、状态图与活动图区别、构件与节点接口包的定义、高内聚度、可见性。前十项覆盖了这套题里绝大多数重复考点考前两小时只看这张表和上面那张分类表性价比最高。最后说个血泪经验。我第一次做这类卷子栽在一道“哪个不是静态视图”的题上选了状态图又改回类图来回两遍还是错原因就是当时靠语感判断没有把“行为图”这一层类别立在脑子里。从那以后我每次做归类题都强制先在草稿上写“用例静态行为交互实现”五个字再把选项往里塞塞不进去的就是答案。这个动作花五秒能省下反复改答案的几分钟也顺带把简答题的分类框架默了一遍。希望帮到你。本文还有配套的精品资源点击获取