简介这份UML试题合集面向正在学习统一建模语言、准备课程考试或面试复习的软件工程与计算机专业学生聚焦用例图、顺序图、协作图等核心交互图帮助读者在短时间内梳理知识点并检验掌握程度。压缩包内为1个doc文档约62KB以问答与选择题形式组织内容涵盖顺序图与协作图在时间顺序和空间组织上的差异、高内聚度的含义、对象间可见性、领域模型与概念类查找方法、统一过程四阶段及各阶段主要工作、增量开发、用况的三种描述方式以及UML五类图共九种图形的分类等高频考点。每道题均附有参考答案与简要解析便于对照自测、查漏补缺。该资源已有11269人学习下载适合作为期末复习提纲或建模实践前的知识速查材料也可配合课堂笔记用于巩固静态视图与动态视图的区分。1. 从一张知识地图说起UML 到底在考什么很多人复习 UML 的第一反应是背图符翻到用例图就记小人、椭圆、箭头翻到顺序图就记生命线、激活条、消息箭头背完一圈上考场遇到“顺序图和协作图的主要差别”这种题还是卡壳。问题不在记性在于没先看清这门课的整体骨架。UML 试题大集合这类资料之所以值得系统过一遍是因为它把散落在各章的选择、填空、简答串成了一条线静态视图描述系统长什么样动态视图描述系统怎么动交互图专门刻画对象之间怎么传消息而统一过程UP和领域模型则回答“这些图在开发的哪个阶段画、画给谁看”。把这条线立起来用例图、顺序图、协作图就不再是孤立符号而是同一张地图上的不同图层。这份笔记面向正在系统学 UML、或者临考要快速查漏补缺的人按知识地图、模块要点、易错点、复习清单的顺序往下走。2. 静态与动态两张网九种图的归类与职责UML 的图看着多归起类来其实只有两大阵营一类描述系统“是什么”一类描述系统“怎么动”。考试里最爱考的就是某张图属于哪一类、负责哪个视图这类题一旦归类清楚基本不会翻车。2.1 五类九图的划分逻辑标准建模语言 UML 的重要内容由五类图、共九种图形来定义。这个“五类九图”是简答题的高频考点必须能默写出来并说清每类包含哪些图。类别包含的图描述的是典型用途用例图用例图系统功能与外部参与者的关系需求捕获、界定系统边界静态图类图、对象图、包图系统的静态设计视图结构建模、领域概念表达行为图状态图、活动图对象或流程的动态行为反应型对象建模、业务流程交互图顺序图、协作图对象之间的消息交互动态视图、场景细化实现图组件图、部署图系统的物理实现与部署配置管理、物理架构梳理下来会发现判断一张图属于静态还是动态关键看它描不描述“随时间变化”。类图、对象图、包图、用例图、组件图、部署图都落在静态一侧状态图、活动图、顺序图、协作图落在动态一侧。选择题里常把状态图混进静态视图选项里当干扰项比如问“下面哪个不是 UML 中的静态视图”答案就是状态图——它描述的是对象生命周期中的状态迁移属于动态行为。2.2 每张图的职责边界把九张图逐个定位比死记分类更牢。类图描述系统的静态设计视图是面向对象建模的核心对象图是类图在某一时刻的实例快照包图用于把元素组织成组是一种通用的分组机制。用例图对系统的行为进行组织和建模是需求阶段的主力。状态图针对单个反应型对象的生命周期建模活动图则更适合描述多个对象参与的活动过程两者常被拿来对比。顺序图和协作图都是交互图描述动态视图区别在下一章展开。组件图对系统的静态实现视图建模支持配置管理部署图描述物理节点与组件的部署关系。这里有个容易混的点组件是系统中遵从一组接口且提供实现的物理部件通常指开发和运行时类的物理实现节点是被节点执行的事物部署图里放的是节点和落在节点上的组件。接口则是一组用于描述类或组件某个服务的操作。三者概念不同选择题常把它们放在一起让你挑“哪个是物理部件”答案是组件。提示九图归类建议做成一张默写表正面写图名、背面写“静态/动态 描述什么 典型场景”考前每天过一遍比反复看教材快得多。3. 交互图双雄顺序图与协作图的差别与选型交互图是这套资料的重头戏简答、选择、填空都爱从这里出。核心就一句话顺序图强调时间顺序协作图强调对象组织。但光背这句话拿不到全分得能展开说清布图方式、优缺点和适用场景。3.1 两者的本质差别顺序图和协作图都展示对象之间的交互关系都用于描述系统的动态视图但侧重点完全不同。顺序图按照时间顺序布图纵向是时间轴横向是参与交互的对象消息从上往下依次排列因此能清晰表达消息之间的先后顺序和时间关系。协作图按照空间组织布图重点展示对象之间的关联以及消息如何在对象之间传递它除了展示对象之间的关联还显示出对象之间的消息传递。对比维度顺序图协作图布图依据时间顺序空间组织强调重点交互的时间顺序交互的语境与对象整体组织空间占用需要较多水平方向空间增加对象时比较容易分支较少消息顺序表达直观清晰依赖消息编号表示时间顺序弱点对象多时横向铺开占地方消息多时难以表示先后顺序协作图里表示消息时间顺序靠的是消息编号这是填空题的常客“在协作图中通过____表示出消息的时间顺序”答案就是消息编号。顺序图则由类角色、生命线、激活期和消息四部分组成选择题问“顺序图由类角色、生命线、激活期和什么组成”答案是消息。3.2 优缺点与选型判断顺序图的优点是消息顺序一目了然时间关系表达清晰适合描述单个场景下消息的精确时序缺点是对象一多水平方向空间吃紧图会拉得很宽。协作图的优点是增删对象方便、分支少、结构紧凑适合展示对象之间的静态关联如何支撑交互缺点是消息一多编号再清楚也不如顺序图直观读者要在脑子里还原时序。选型上有个朴素的判断要讲清“先发生什么、后发生什么”用顺序图要讲清“谁和谁有关系、消息走哪条链路”用协作图。两者可以互相转换在建模工具里协作图常常能在顺序图基础上自动生成这也是选择题的一个考点——注意“协作图是顺序图的一种特例”这种说法是错的两者是并列的交互图不存在特例关系。3.3 系统顺序图SSD的画法边界系统顺序图是把系统当成一个黑匣子只描述外部参与者与系统之间的消息往来。画 SSD 时对系统内部结构与功能应当不做描述既不详细展开内部结构也不罗列系统全部功能。这一点在选择题里反复出现四个选项里往往有一个“简单描述内部结构但罗列所有功能”的迷惑项正确做法是把系统当整体只画边界上的输入输出消息。SSD 的价值在于把需求阶段的场景固化成可验证的交互契约而不是提前做设计。4. 用例、领域模型与 UP需求侧的三块硬骨头需求相关的知识点散、名词多但考法集中用例之间的关系、领域模型找概念类的方法、统一过程四阶段各干什么。这三块吃透简答题基本稳了。4.1 用例与用例之间的关系用况是一个描述性的文档用来描述一个参与者使用系统完成某个业务过程时的事件发生顺序。它描述的是系统使用过程定义系统的责任说明系统必须做什么而不描述系统内部如何工作。用况模型是需求工作的重要制品用况一般有 Brief、Casual、Fully Dressed 三种描述方式从简到详逐级展开。用例之间的关系是选择题高频区尤其是包含和扩展。判断口诀如果多个用例都必然要做某件事那件事抽出来做公共用例用包含include如果某个用例只是在特定条件下才附加一段行为用扩展extend。资料里那个订单子系统的例子很典型创建新订单和更新订单都需要检查用户账号是否正确“检查用户账号”是被复用的公共行为所以“创建新订单”“更新订单”与“检查用户账号”之间是包含关系。看到“都需要”“必然执行”就往包含想看到“可选”“特定条件下”就往扩展想。4.2 领域模型与找概念类的两种方法领域模型是一组表示真实世界的概念类不是软件部件的模型。这个“是概念类、不是软件部件”的区分是填空题的固定考点两个空分别填概念类和软件部件。领域模型在设计工作中广泛用来启发设计软件对象它关注的是业务领域里的名词而不是代码里的类。找概念类有两种方法概念类类别表和标识名词短语。前者按常见类别人、地点、事物、事件等逐类筛查后者从需求文本里把名词短语圈出来再筛选。领域建模的步骤可以归纳为四步列出候选的概念类、画出领域模型图、必要时加入概念类间的关联、必要时加入概念类的属性。注意顺序先有类和关联属性是“必要时”才加不要一上来就堆属性。4.3 统一过程四阶段与核心工作流统一过程UP分四个阶段每个阶段的主要工作必须能对号入座。阶段主要工作初始阶段编制简要的愿景文档、业务案例、确定范围、粗略评估成本细化阶段细化愿景文档、迭代实现核心构架、解决高风险问题、定义大多数需求和范围、进一步评估成本构造阶段迭代实现系统其余部分、准备部署提交阶段beta 测试、部署最容易错的是“定义大多数需求和范围”落在哪个阶段。很多人凭直觉选初始阶段正确答案是细化阶段。初始阶段只做粗略评估和范围界定真正的需求和范围细化在细化阶段完成。UP 的核心工作流包括业务建模、需求分析、设计、实现、测试。UP 的核心思想可以概括为短时间盒的迭代式开发、开发过程中不断调整、早期迭代解决高风险高价值问题、不断与用户衔接获取反馈、早期构造核心体系结构、早期进入实现和测试、用况驱动结合 UML 可视化建模、仔细管理需求并控制变更。增量开发有两层意思一是对复杂的用况分多次迭代、一部分一部分实现二是把所有用况按优先级分别安排在不同迭代中实现。这两层常被简答题要求展开只答一层会丢分。5. 易错点清单那些年反复翻车的细节这一章专治“看着都会、一做就错”。下面五条是从选择题和简答题里筛出来的高频翻车点每条按“易漏点 → 为什么漏 → 怎么补”拆开。易错点一把状态图当成静态视图。为什么漏状态图名字里没有“动态”二字又常和类图一起出现在结构建模章节容易顺手归到静态。怎么补记住状态图描述的是对象生命周期中的状态迁移属于行为图、动态视图判断静态动态只看“是否随时间变化”。易错点二混淆顺序图与协作图的特例关系。为什么漏两者能互相转换工具里还能一键生成容易误以为一个是另一个的特例。怎么补明确两者是并列的交互图只是布图依据不同协作图不是顺序图的特例转换关系不等于包含关系。易错点三UP 阶段工作张冠李戴。为什么漏初始阶段和细化阶段的工作描述都带“评估成本”“确定范围”字样不细看就混。怎么补抓住关键词——初始阶段是“简要愿景、业务案例、粗略评估”细化阶段是“细化愿景、核心构架、定义大多数需求和范围”看到“大多数需求”直接锁定细化阶段。易错点四领域模型的对象搞错。为什么漏领域模型和设计类图长得像都是类加关联容易把软件部件当成领域概念。怎么补领域模型表示真实世界的概念类找类用类别表和名词短语两种方法属性是必要时才加别提前进入设计思维。易错点五SSD 里画了系统内部。为什么漏画图时手痒想把系统内部结构也展开觉得这样更完整。怎么补SSD 把系统当黑匣子只画外部参与者与系统的消息内部结构与功能一律不描述这是需求阶段交互契约的边界。注意这五条建议单独抄在一页纸上考前只看这一页比重新翻一遍资料效率高。6. 复习清单从默写到查漏的落地方法复习 UML 最怕的是“看懂了但写不出”。我的做法是把这份资料拆成三层来练每层都有明确的验收标准不达标就回去补。第一层是默写层解决“记没记住”。拿一张白纸默写五类九图的归类表、UP 四阶段工作表、顺序图四要素、协作图消息顺序的表达方式。默完对照资料批改错一个就在旁边标红第二天只默红的部分。这一层大概两三天能过完重点是九图归类和 UP 阶段这两张表它们是选择题的根。第二层是对比层解决“分不分得清”。把容易混的成对概念列成对照表逐对用自己的话讲一遍差别顺序图对协作图、状态图对活动图、包含对扩展、组件对节点对接口、初始阶段对细化阶段。讲不出来的就是没真懂回去看对应章节。这一层的关键是“用自己的话”照读原文不算过。第三层是场景层解决“会不会用”。拿一个虚构的小系统比如某图书借阅模拟项目走一遍完整流程先用用例图圈边界写出两三个用例并标出包含关系再挑一个场景画顺序图标清生命线、激活期和消息然后把同一场景改画成协作图用消息编号标时序最后判断这个场景该在 UP 的哪个阶段细化。走完一遍需求侧和交互图的知识就串起来了。复习层验收标准不达标怎么办默写层两张核心表零错误标红重默只默错项对比层五对概念能脱稿讲清差别回看对应章节再讲一遍场景层一个小系统走通用例到交互图从用例图重新起一遍查漏补缺的诀窍是“错题反查知识点”而不是“错题重做”。每道错的选择题背后都是一个没立住的概念把概念补上同类的题自然不会再错。比如错了“哪个不是静态视图”要补的不是这道题而是整张九图归类表。从那以后我每次复习这类偏记忆又偏理解的科目都强制走一遍“默写—对比—场景”三层先确保地图在脑子里再往细节里填。希望这份梳理能帮到你把散落的题串成自己的知识网。本文还有配套的精品资源点击获取