简介这份UML试题合集面向正在学习统一建模语言、准备课程考试或面试复习的软件工程学习者围绕用例图、顺序图、协作图等核心图形组织题目与知识点解析帮助读者在静态结构与动态交互之间建立清晰对应。压缩包内共1个doc文档约62KB以问答与选择题形式集中呈现交互图差异、高内聚度、对象可见性、领域模型、统一过程四阶段及增量开发等高频考点并配有参考答案便于自测。已有11274人学习下载说明其题目覆盖面与解析方式在备考人群中具有一定认可度。读者可借此梳理顺序图与协作图在时间顺序和空间组织上的取舍理解用例图对系统行为的建模作用并通过统一过程各阶段职责、领域建模步骤等条目查漏补缺适合作为考前速览与知识点串联的练习材料。1. 从一张“图种地图”切入UML 到底在考什么很多人复习 UML 的第一反应是背图符小人、方框、箭头、虚线。真到做题才发现考的不是画图而是“什么场景该用哪张图、这张图强调什么、两张长得像的图差别在哪”。这份试题集合把用例图、顺序图、协作图、状态图、类图、部署图、组件图全串了一遍还夹着统一过程、领域模型、高内聚度这些容易混的概念题。梳理下来会发现它其实是一张“静态视图 动态视图 过程模型”的三层地图静态看类图、对象图、包图、组件图、部署图动态看用例图、顺序图、协作图、状态图、活动图过程层看统一过程的四个阶段和核心工作流。复习时先认地图再抠每张图的“强调点”最后拿选择题查漏比从头背定义高效得多。适合正在系统学面向对象分析与设计、或者临考要快速过一遍的人。2. 交互图双雄顺序图与协作图的取舍与易错点2.1 两张图到底差在哪时间轴 vs 空间组织顺序图和协作图是这份试题里出现频率最高的一对几乎每套题都要问差别。核心只有一句话顺序图强调交互的时间顺序协作图强调交互的语境和参与对象的整体组织。顺序图按时间顺序布图消息从上往下排协作图按空间组织布图对象围绕消息连线摆放靠消息编号体现先后。对比维度顺序图协作图布图依据时间顺序纵向空间组织对象关系消息先后位置直接体现靠消息编号体现空间占用水平方向需要较多空间增加对象较容易分支少弱点对象多时横向拉得很长消息多时难表示顺序共同点都是交互图都展示对象间的消息传递同左这里最容易翻车的是“协作图是顺序图的一种特例”这种说法——试题里明确把它列为错误项。两者是并列的交互图不是包含关系。另一个高频点在协作图中通过消息编号表示消息的时间顺序而不是靠上下位置。还有一道常考的工具题说协作图可在顺序图基础上按某功能键自动生成这类题记住“可转换”即可别把方向记反。2.2 顺序图的组成与 SSD 的画法边界顺序图由类角色、生命线、激活期和消息四部分组成这是选择题的固定考点四个要素缺一不可。复习时把“消息”当成顺序图的灵魂同步消息、异步消息、返回消息的画法不同但试题层面更爱考“顺序图由哪几部分组成”这种识记题。系统顺序图SSD是另一个易混点。题目问画 SSD 时该如何对待所涉及的系统正确答案是“不对系统的内部结构与功能进行描述”。原因很直接SSD 把系统当成一个黑匣子只关心外部参与者与系统之间的消息往来一旦画了内部结构就变成了设计阶段的图越界了。这个点血泪经验是看到“详细描述内部结构”的选项基本可以排除SSD 的立场永远是外部视角。2.3 交互图相关的易漏点易漏点一把协作图当成顺序图的子类。为什么漏两张图都能画消息长得像就默认有继承关系。怎么补记住“并列的两种交互图”一个管时间一个管空间做题先问“这题强调的是顺序还是对象组织”。易漏点二以为协作图靠位置表示顺序。为什么漏顺序图看惯了上下位置。怎么补协作图认“消息编号”编号才是时间顺序的唯一依据。易漏点三SSD 里画系统内部。为什么漏平时画设计图习惯展开内部。怎么补SSD 只画参与者和系统边界系统内部一律不展开。易漏点四混淆交互图与行为图。为什么漏状态图、活动图也描述动态行为。怎么补交互图专指顺序图和协作图状态图、活动图属于行为图别混进“交互图”这个筐。3. 用例图与需求建模参与者、用况与三种描述粒度3.1 用况的本质定义责任而不是定义实现用况是一个描述性的文档描述一个参与者使用系统完成某个业务过程时的事件发生顺序。它描述的是系统的功能需求不描述系统内部如何工作只定义系统的责任说明系统必须做什么。这句话是判断题和简答题的高频答案关键词是“不描述内部如何工作”。用况模型是需求工作的重要制品用况一般有 Brief、Casual、Fully Dressed 三种描述方式从简到繁。复习时按粒度记Brief 一两句话概括Casual 用松散格式写主流程Fully Dressed 把前置条件、主成功场景、扩展场景全写全。试题爱考“用况有哪三种描述方式”答全三个英文词即可。用例之间的关系也是必考项。试题里给了一个典型场景创建新订单和更新订单都需要检查用户帐号是否正确问“创建新订单”“更新订单”与“检查用户帐号”是什么关系答案是包含include。判断口诀多个用例共同复用的公共行为用 include只在特定条件下才插入的附加行为用 extend。前者是“必须做”后者是“可能做”方向别搞反。3.2 用例图在九种图中的定位UML 的重要内容由五类图共九种图形定义用例图、静态图类图、对象图、包图、行为图、交互图、实现图。用例图的定位是“对系统的行为进行组织和建模”它给出系统的静态设计视图之外的另一个视角——从外部看系统能做什么。这里有个反复出现的陷阱题目问“哪个不是 UML 中的静态视图”选项里混进状态图正确答案就是状态图。静态视图包括用例图、类图、对象图状态图是动态的。另一道题问“类图应该画在哪种视图”答案是逻辑视图Logic View不是用例视图也不是组件视图。把“图”和“视图”分开记图是画出来的东西视图是工具里的组织容器两者不是一一对应。3.3 用例建模的易错点易错点一include 和 extend 方向反了。为什么错两个词都表示“用到”。怎么错补include 是基础用例指向被包含用例箭头朝被包含方extend 是扩展用例指向基础用例箭头朝基础方。记“包含是必须扩展是可选”。易错点二把用例图当静态视图排除在外。为什么错用例图看起来像“功能列表”容易归到动态。怎么补试题明确用例图属于静态视图范畴状态图才是动态。易错点三用况描述里写实现细节。为什么错写需求时顺手写了“系统调用某接口”。怎么补用况只写参与者与系统的交互事件顺序内部实现留给设计阶段。4. 静态结构建模类、领域模型与高内聚度4.1 领域模型找概念类的两条路领域模型是一组表示真实世界概念类的模型不是软件部件的模型。这个“不是软件部件”是选择题的固定干扰项题目会把“真实世界的概念类”和“软件部件的模型”摆在一起让你选。领域模型在设计工作中广泛用来启发设计软件对象它的立场是问题域不是解域。找概念类有两种方法概念类类别表和标识名词短语。前者按常见类别人、地点、事物、事件等去套后者从需求文本里把名词圈出来再筛选。领域建模的步骤是四步列出候选概念类、画出领域模型图、必要时加入概念类间的关联、必要时加入概念类的属性。注意“必要时”三个字属性和关联不是越多越好只加对理解问题域有用的。4.2 高内聚度两个“不要”和一个度量高内聚度是对一个类中各个职责之间相关程度和集中程度的度量。一个类职责高度相关、且完成的工作量不是特别巨大就具有高内聚度。它包含两层意思一是不要给一个类分派太多职责履行职责时尽量把部分职责分派给有能力完成的其它类二是不相关的职责不要分派到同一个类。复习时把它和“单一职责”对照记高内聚说的是“类内部职责的相关程度”不是“类越小越好”。试题常把“给一个类分派尽可能多的职责”作为错误选项正确方向是职责相关且工作量适中。这里有个容易忽略的细节高内聚度同时约束“相关性”和“工作量”只强调相关不控制体量也会走向 god class。4.3 类、组件与部署静态视图的三层落点类通常分为实体类、控制类和边界类这是类图题的固定三分类。实体类承载数据边界类处理系统与外部交互控制类协调业务逻辑。组件是系统中遵从一组接口且提供实现的物理部件通常指开发和运行时类的物理实现组件图用于对系统静态实现视图建模支持配置管理。部署图描述物理部署节点是被节点执行的事物的宿主。组件图的四种建模方式里试题问“哪种不是其中之一”答案是“对可适应的系统建模”——组件图建模的是源代码、可执行体、物理数据库这类实体不是抽象的系统适应性。这类题靠排除法凡是听起来很虚、不像“物理部件”的选项基本就是错误项。4.4 静态建模的易漏点易漏点一领域模型里塞软件类。为什么漏画着画着就想到实现。怎么补领域模型只放真实世界概念类软件部件留给设计类图。易漏点二高内聚理解成“职责越少越好”。为什么漏只记住“不要太多职责”。怎么补高内聚是相关性和工作量的平衡不是单纯减职责。易漏点三组件图建模对象搞错。为什么漏组件和类都叫“部件”。怎么补组件是物理实现建模对象是源代码、可执行体、物理数据库不是抽象适应能力。易漏点四类图画在错误视图。为什么漏工具视图名不熟。怎么补类图放逻辑视图用例图放用例视图组件图放组件视图部署图放部署视图。5. 动态行为与过程模型状态图、活动图与统一过程5.1 状态图与活动图一个对象 vs 多个对象状态图和活动图都描述对象随时间变化的行为但侧重点不同。状态图对单个反应型对象建模强调一个对象在生命周期中的状态迁移活动图强调对有几个对象参与的活动过程建模用泳道把活动按负责的类、人或部门分组。试题里那道“状态图强调对几个对象建模、活动图强调单个对象”的选项是反的正确说法正好颠倒。泳道是活动图的高频考点把活动状态分组每组表示一个特定的类、人或部门负责完成组内活动。分叉汇合、分支、转移是活动图的控制节点别和泳道混。对反应型对象建模一般用状态图这是“反应型对象—状态图”的固定搭配。5.2 统一过程四阶段与核心工作流统一过程UP分四个阶段初始、细化、构造、提交。各阶段主要工作要能对上号阶段主要工作初始编制简要愿景文档、业务案例、确定范围、粗略评估成本细化细化愿景文档、迭代实现核心构架、解决高风险问题、定义大多数需求和范围、进一步评估成本构造迭代实现系统其余部分、准备部署提交beta 测试、部署两道经典题定义大多数需求和范围在哪个阶段完成答细化阶段。哪个不在初始阶段完成答定义大多数需求。这两题其实是一体两面记住“细化阶段才定大多数需求”就能同时拿下。UP 的核心工作流有五个业务建模、需求分析、设计、实现、测试。UP 的核心思想可以压缩成几条短时间盒的迭代式开发、开发过程中不断调整、早期迭代解决高风险高价值问题、不断与用户衔接获取反馈、早期构造核心体系结构、早期进入实现和测试、用况驱动、UML 可视化建模、仔细管理需求控制变更。增量开发则有两层意思复杂用况分多次迭代一部分一部分实现所有用况按优先级安排在不同迭代中实现。5.3 过程与行为建模的易错点易错点一状态图和活动图的建模对象记反。为什么错两张图都画“状态”和“活动”名字接近。怎么补状态图对单个反应型对象活动图对多对象参与的过程泳道是活动图的标志。易错点二把“定义大多数需求”放到初始阶段。为什么错初始阶段听起来像“定需求”。怎么补初始只做愿景、范围、粗略成本细化阶段才定义大多数需求和范围。易错点三UP 核心工作流漏项。为什么错只记设计实现测试。怎么补五个工作流从业务建模起头需求分析、设计、实现、测试收尾。易错点四增量开发只记“分多次”。为什么错漏了按优先级排迭代。怎么补增量开发两层含义分次实现 按优先级分配迭代。6. 查漏补缺一份可执行的复习清单复习到这一步最有效的动作不是再刷一遍定义而是拿一张空白纸把“图—强调点—易错项”三列默写出来写不出的就是漏洞。下面这份清单按“先地图后细节”排照着过一遍基本能把这份试题集合里的高频点全覆盖。复习模块必须能脱口而出的点自检方式九种图分类五类图共九种用例图、静态图类/对象/包、行为图、交互图、实现图默写分类标出哪些是静态、哪些是动态交互图顺序图管时间、协作图管空间协作图靠消息编号定顺序做两道“哪个说法错误”的判断题用例图用况定义责任不定义实现include 必须、extend 可选画一个 include 和一个 extend 的箭头方向领域模型真实世界概念类不是软件部件两种找法、四步建模从一段需求文本圈名词筛出概念类高内聚度职责相关 工作量适中两个“不要”判断“职责越多越好”这类选项的对错状态图/活动图状态图对单对象活动图对多对象泳道分组区分两道建模对象题的正误选项统一过程四阶段工作、五核心工作流、细化阶段定大多数需求默写四阶段各自的主要工作静态实现组件是物理部件类图在逻辑视图排除“对可适应系统建模”这类错误项具体操作上我习惯分三轮。第一轮只过地图把九种图和四阶段画成一张关系草图不抠细节第二轮按上表逐行自检凡是卡壳的模块回到对应章节重读重点看“为什么错”而不是“正确答案是什么”第三轮只做错题把每道错题归到“记混了”“没记住”“理解反了”三类前两类靠重复第三类必须回到概念本身重新推一遍。最容易忽略的是“图”和“视图”的对应关系以及 SSD 的边界。这两块题量不大但几乎每次都出现属于典型的低投入高回报点。另一个后悔药是统一过程阶段题很多人背了四阶段名字却记不住“定义大多数需求在细化阶段”结果两道题一起丢分。从那以后我每次复习这类建模题都强制先默写一遍“图种地图”再动笔做题地图写不全就不碰细节题。希望这份梳理能帮到你把散落的试题收成一张能随时调出来的网。本文还有配套的精品资源点击获取
