简介这是一份UML软件建模复习题PDF面向正在备考软件建模课程或需要系统巩固UML知识的读者。文档以UML标准建模语言为主线覆盖用例图、类图、状态机、状态图、活动图、构件图、部署图等核心内容并按章节整理单项选择题、填空题、名词解释题和简答题多数题目附有参考答案便于自测与查漏补缺。题目涉及UML概念模型、面向对象封装继承多态、关系建模中的关联/聚合/组合、状态机与活动图等高频考点题型从客观题逐步递进到主观题能帮助读者系统检验对建模知识的掌握程度。内容预览显示其结构完整从概述、用例与用例图、类与接口、关系建模到交互图、状态机、活动图、构件及部署图均有覆盖既适合期末考前集中冲刺也可作为日常学习笔记反复翻阅。资源为单个PDF文件大小约2.79MB携带方便目前已有118人学习使用。1. 把“UML软件建模复习题.pdf”当考纲而不是题堆搜索框里出现“UML软件建模复习题.pdf”这个文件名通常意味着两类人一类是软考软件设计师、系统架构设计师的考生一类是软件工程期末备考的高校学生大家拿到一份几十页的PDF第一反应是先翻到最后看有没有答案。把这份复习题当成“题堆”来背效率最低。它真正的价值是帮你划定了UML建模的考点边界类图、用例图、时序图、状态图、包图、六种关系、多重性、建模软件的使用。这几项恰好是平时做设计评审、画技术方案、写接口文档时最常用的能力。这篇内容不走“从头讲UML是什么”的老路直接按复习题的出题逻辑展开先搞定静态结构再套动态图模板最后用PlantUML、Visio、EA这类常用建模软件交付能拿分的答案。软考考生、期末备考者和想补UML功底的初中级开发按这个顺序复现一遍就够了。2. 类图、用例图与包图刷题前先把这三张UML图分清2.1 类图的三格结构名称、属性与方法不是背出来的复习题里最常出现的UML类图考的不是能不能画出漂亮的矩形而是能否把一个类准确转换成标准的三格形式。类图的标准画法是一个矩形分成三格顶部写类名中间写属性底部写方法。属性行建议写成“可见性 名称 : 类型”的格式方法行写成“可见性 名称(参数列表) : 返回类型”的格式。阅卷时先看的就是这个格式是否完整类名漏写、属性不带类型、方法忘写返回类型都属于扣分项。可见性符号是高频选择题考点表示 public-表示 private#表示 protected~表示 package。这四个符号之间没什么高深道理用一段PlantUML就能固化记忆startuml class Order { - orderId : String totalAmount : double # status : int ~ createTime : Date pay() : boolean - calcDiscount() : double } enduml这段代码在PlantUML中生成一个四行属性、两行方法的类图。对应关系是减号映射 private加号映射 public井号映射 protected波浪线映射 package。记忆时可以这么想可见范围越大的符号越“敞开”private 是-表示封闭public 是表示对外开放protected 加了#表示有条件的开放。属性行里的类型写在冒号后方法行里的返回类型也写在冒号后这个顺序和 Java 声明的顺序相反Java 是“类型 名称”但类图标准要求“名称 : 类型”这个颠倒恰恰是阅卷老师最常挑的格式错误。提示属性行不要写初始值不要写号类图只表达结构不表达赋值动作。很多复习题的参考答案里属性带默认值那是把类图和对象图混在一起了。2.2 用例图include 与 extend 的判据要能说给考官听用例图在复习题里的考核点不是画得好看而是 include 和 extend 谁指向谁。UML用例图中include 表示基用例一定会调用被包含用例常用于多个用例共用的子流程箭头从基用例指向被包含用例虚线上标includeextend 表示可选扩展箭头从扩展用例指向基用例标extend。判据就一句话include 是必需品extend 是赠品。基用例可以独立完成主流程时不需要 include但如果基用例内部必须先执行某段逻辑才能继续这段逻辑就是被包含项。startuml left to right direction actor 顾客 as c rectangle 在线商城 { (登录验证) . (结算) : include (优惠券抵扣) . (结算) : extend (结算) -- c } enduml这个例子中“结算”用例内部一定会做身份校验所以“登录验证”被结算包含箭头从“登录验证”指向“结算”。“优惠券抵扣”只有用户主动选择才发生不影响结算主流程所以作为扩展用例存在箭头从“优惠券抵扣”指向“结算”。复习题常考“箭头指向被依赖方”这个规律include 中基用例依赖被包含用例extend 中基用例不依赖扩展用例扩展用例反而依赖基用例的扩展点所以两处箭头方向相反。做题时先把基用例找出来再看谁没谁不行最后落笔标方向。2.3 包图与建模软件的“由粗到细”思路UML包图常以“判断包间的依赖关系”的形式出现在复习题里典型考法是给三个包 A、B、CA 依赖 BB 依赖 C问是否可以认为 A 间接依赖 C。这里的知识点是UML 的依赖不可传递A 直接依赖 C 必须单独画线。包图里的依赖线用虚线箭头箭尾是依赖方箭头指向被依赖方。包图还用来表达架构分层表现层依赖业务层、业务层依赖数据层这种三层结构的依赖图是复习题里最稳定的素材。startuml package 表现层 { class UserController } package 业务层 { class UserService } package 数据层 { class UserMapper } UserController .. UserService : 依赖 UserService .. UserMapper : 依赖 enduml这段代码画的包图解决了一个典型复习场景分层架构下依赖关系的陈述。数据层不依赖任何包所以能单独被替换表现层依赖业务层业务层又依赖数据层但表现层并不直接依赖数据层这是分层架构的边界意义。答题时建议先画包图再画类图包图决定类的归属类图决定类的内部结构这个“由粗到细”的顺序也是建模软件里的标准建包顺序。EA、StarUML 里都是先建包再在包内建类包名必须写在矩形顶部的小标签里。题干关键词应选UML图考察重点下订单、退款流程时序图或活动图消息顺序、工作流用户、角色、权限关联用例图include/extend 方向集合、成员、父子结构类图多重性、聚合/组合系统模块划分、层间依赖包图包间依赖、层次边界状态切换、事件触发状态图迁移条件、动作类之间调用、接口实现时序图或类图消息顺序、可见性题干里的动词决定图的选择不用背 UML 2.5 的全部 14 种图先把这张表刻在脑子里选择题就能拿下一半。3. 类图关系判别复习题里最容易丢分的六种连接线3.1 依赖、关联、聚合、组合一条判断链路讲透复习题分析题最经典的考法是给一段需求描述要求画出类图并标注关系类型。考生易错的不是画线而是区分依赖、关联、聚合、组合、泛化、实现这六种关系。先看依赖与关联的区别依赖是临时使用方法参数、局部变量、静态方法调用都算依赖对应虚线箭头关联是长期持有类的成员变量、字段引用才算关联对应实线。判断顺序推荐三步走先看是不是继承或实现是则停再看是不是整体与部分的关系不是则按关联处理是整体与部分再从生命周期判断聚合或组合。聚合与组合是最迷惑的一对判据是“部分能否脱离整体单独存在”。订单和订单项是聚合还是组合订单被删除订单项失去存在的业务意义这是组合用实心菱形班级和学生班级解散后学生仍以独立个体存在这是聚合用空心菱形。PlantUML中聚合用o--组合用*--startuml class Order class OrderItem class Faculty class Student Order *-- OrderItem : 组合 Faculty o-- Student : 聚合 enduml注意 PlantUML 中菱形位置Order *-- OrderItem表示菱形在 Order 一侧即 Order 是整体OrderItem 是部分。实际复习题里经常给一张画好的图让你判断菱形是实心还是空心答题时先找“整体”和“菱形”是否同侧再把两个类的语义代入“部分能否脱离整体存在”的判据。组合关系在数据库建表时通常对应外键 NOT NULL聚合关系对应外键可空这个映射可以用来反向验证答案是否合理。3.2 多重性1、0..1、* 的位置和含义类图关联线两端的数字叫多重性复习题里常以“1对多”“多对多”的选择题形式出现。标准写法有六档1 表示恰好一个0..1 表示零或一个* 表示零或多个1..* 表示至少一个0..* 表示任意数量n..m 表示固定区间。多重性标注在关联线两端靠近哪个类就表示那个类一侧的实例数量范围。判断核心从哪个类出发就看另一个类的数量。startuml class Department { - name : String } class Employee { - name : String } Department 1 o-- 0..* Employee : 雇佣 enduml这段代码中Department 端标 1Employee 端标 0..含义是“一个部门聚合零到多个员工”反过来说“每个员工必须属于一个部门”。答题时最容易犯的错误是把两端数字写反在 Department 一侧写 0..、在 Employee 一侧写 1语义就变成了一个部门属于零到多个员工一个员工必须有且仅有一个部门这不符合通常的业务理解。所以正确流程是先确定出发的类再看对方数量区间最后把数字写在对方那一端。关联线两端可以同时写多重性也可以只在有歧义的一端写。提示多重性标在“线端”而不是“线中”标在线中的做法是活动图的标记习惯不要混。3.3 泛化与实现别把“接口”画成“父类”泛化和实现都是带空心三角箭头的连接线区别在线型泛化是实线空心三角箭头实现是虚线空心三角箭头。复习题常让考生判断给定连线是泛化还是实现题干里出现“接口”“implements”大概率是实现出现“继承”“extends”“抽象类”大概率是泛化。典型例子ArrayList实现List接口用虚线空心三角ArrayList继承AbstractList抽象类用实线空心三角。在 PlantUML 中泛化直接--|实现用..|startuml interface List class ArrayList abstract class AbstractList AbstractList |-- ArrayList List |.. ArrayList enduml注意实现关系的箭头方向和依赖一样指向被依赖方接口泛化箭头指向父类。有一个阅卷场景接口里声明了两个方法实现类只画了一个方法这就是一个“实现关系缺方法”的考点对应的知识点是实现类必须实现接口的全部抽象方法。答题时可以在接口下方用 note 把方法清单列出来既提示自己也让阅卷老师看清“接口即契约”的兑现程度。4. 时序图、状态图与活动图的答题模板动态建模的三板斧4.1 时序图生命线与激活条的画法时序图考查消息顺序题干里出现“先…然后…最后…”的表述优先考虑时序图也叫序列图。核心元素只有三个生命线是顶部矩形加竖直虚线激活条是生命线上的细长矩形消息是激活条之间的水平箭头。画图顺序从上到下和阅读代码的顺序一致。第一道生命线通常是发起者 Actor 或 Controller复习题的时序图答题模板基本固定在“用户-控制器-服务-数据访问”四层。startuml actor 用户 participant Controller as C participant Service as S participant Mapper as M 用户 - C: 提交订单 C - S: createOrder() S - M: insert(order) M -- S: 主键 S -- C: 订单号 C -- 用户: 下单成功 enduml这段代码展示了完整的调用链。答题时注意三点第一条消息从用户发往控制器写“提交订单”服务层方法名要带括号表示方法调用返回消息全部用虚线不需要写方法名写返回的数据即可。自调用消息画成在自己激活条上回环的箭头代表方法内部递归或调用重载。高频选择题是“时序图里返回消息用什么线”答案是虚线实线只表示普通消息这个规则在所有 UML 动态图里一致。4.2 状态图事件与动作的区分是给分点状态图适合描述单对象生命周期订单状态机是复习题最常用的素材。状态图三要素状态用圆角矩形表示事件是状态迁移的触发条件写在迁移箭头旁的方括号里动作是进入状态后的行为写在状态内部分 entry、do、exit 三种。entry 表示进入状态立即执行do 表示停留期间持续执行exit 表示离开前执行。复习题常拿“支付成功”作为事件“扣减库存”作为动作要求考生判断两者在状态图中各写在哪里。startuml [*] -- 待支付 待支付 : entry/生成订单号 待支付 -- 已支付 : [支付成功] 已支付 : do/扣减库存 已支付 -- 已发货 : [发货] 已发货 -- 已完成 : [确认收货] 已完成 -- [*] enduml这段代码中[支付成功] 是事件写在迁移箭头上entry/生成订单号 和 do/扣减库存 是动作写在状态里。答题时记住“事件推动状态变迁动作跟随状态存在”这个二元结构就能应付绝大多数状态图分析题。另外注意初始状态是实心圆点终止状态是圆环外框两者都不写名称。选择题里把初始状态画成圆角矩形的选项可以直接排除。4.3 活动图泳道与控制流补充动态答案活动图在复习题里的出现频率略低于时序图和状态图但一旦出现就以泳道划分为考点。泳道是垂直划分的活动区域每个泳道代表一个角色或系统模块活动节点在泳道内跨泳道的箭头表示职责交接。活动图与状态图容易混淆判断依据是状态图盯着一个对象看状态迁回活动图盯着一群人看业务流程流转。画活动图时用圆角矩形表示活动菱形表示判断加粗横条表示并发分叉与汇合。startuml |仓管员| start :拣货; :复核; |快递员| :揽收; if (配送范围?) then (是) :送货上门; else (否) :通知自提; endif stop enduml这个例子中泳道按角色划分控制流随时间在泳道间移动。答题模板三步走先列出参与者列表再给每个参与者分配一组活动最后用菱形判断合并分支。这三步能保证卷面不出现交叉控制流。活动图和时序图可以互为验证同一场景用活动图画流程、用时序图画调用顺序如果活动图跨泳道的次数和时序图生命线数量不一致说明参与者有遗漏这是复习时的自查手段。5. 用PlantUML、Visio和EA把答案画成能拿分的图5.1 用Visio怎么画UML类图选对模板比画得快重要用Visio画UML类图被检索得最多原因是考试允许带电脑作图或工作中需要快速交付设计图。这里有一个常见坑Visio 2013 之后的版本新建页里搜“UML”不会直接列出“UML类图”而要搜索“UML Model”打开 UML 模型图模板模板里才有类、用例、序列、状态等模具。打开后拖一个“Class”形状到画布右键选择“属性”打开类编辑器在“属性”页签按“属性名:类型”分行填写字段在“操作”页签写方法右键类形状的显示选项里勾选是否显示属性和操作名。关联线不要用“箭头”形状拼要从“关系”模具里拖“Unidirectional Association”单向关联或“Aggregation”聚合、“Composition”组合。双击关联线能为两端添加多重性文本直接键入*、1..*等值。中文版 Visio 里 Composite 可能翻译成“合成”或“复合”认准实心菱形是组合、空心菱形是聚合不会错。5.2 用EA建模软件离线安装包重装后最该改的两个设置EAEnterprise Architect是复习题里频繁被点名的商业建模软件很多高校机房装的就是它。提到“EA建模软件离线安装包”对应的是机房无法在线安装或激活的场景。离线安装包装完后有两个设置建议优先调整一是 “Settings Project” 里的 Default Language改成 Java属性类型的写法就按 String、int 显示更贴近国内教材习惯二是在 “Start Diagrams” 里勾选 Show diagram legend工作区会常驻可见性符号图例画类图时不用回头查符号含义。用 EA 答类图分析题时先生成包图再在包内建类。双击类名能切换属性和方法编辑器编辑器字段顺序是“可见性、类型、名称”和 PlantUML 的“名称 : 类型”相反填写时不要惯性写反EA 生成代码时会按自己的顺序拼接。5.3 PlantUML答题的三个文本技巧PlantUML 最大的优势是“文字即图”复习时把题干转成代码再导出 PNG。三个技巧能让输出的图更接近试卷印刷标准第一用skinparam classAttributeIconSize 0关闭可见性前的圆形图标让图直接以 - #符号显示避免黑白打印时图标糊成一团第二给关键关系加 note 注记把业务约束写进图里例如note right of Order : 金额由明细行汇总这类业务注释阅卷时能体现理解深度第三代码头部用scale 1.5放大整张图保证多重性数字在 DPI 缩小的答题纸上仍可辨认。startuml scale 1.5 skinparam classAttributeIconSize 0 class Customer { - id : long - name : String } class Order { - orderNo : String - amount : double } Customer 1 o-- 0..* Order : 提交 note right of Order : 金额由明细行汇总 enduml答题时把这段代码丢给 PlantUML导出的 PNG 比手绘或 Visio 拖拽都快。验证输出图的三个维度类名完整不缩写关系线的菱形与整体同侧多重性和可见性符号在 1.5 倍缩放下依然清晰。复习题的产出物能稳定做到这三条就已经超过了大部分只背概念不上手画图的备考者。本文还有配套的精品资源点击获取 
长河君 · 2026/9/17 13:28:13 · 阅读 1.2k UML软件建模复习题精讲：类图、用例图与动态图答题模板
简介这是一份UML软件建模复习题PDF面向正在备考软件建模课程或需要系统巩固UML知识的读者。文档以UML标准建模语言为主线覆盖用例图、类图、状态机、状态图、活动图、构件图、部署图等核心内容并按章节整理单项选择题、填空题、名词解释题和简答题多数题目附有参考答案便于自测与查漏补缺。题目涉及UML概念模型、面向对象封装继承多态、关系建模中的关联/聚合/组合、状态机与活动图等高频考点题型从客观题逐步递进到主观题能帮助读者系统检验对建模知识的掌握程度。内容预览显示其结构完整从概述、用例与用例图、类与接口、关系建模到交互图、状态机、活动图、构件及部署图均有覆盖既适合期末考前集中冲刺也可作为日常学习笔记反复翻阅。资源为单个PDF文件大小约2.79MB携带方便目前已有118人学习使用。1. 把“UML软件建模复习题.pdf”当考纲而不是题堆搜索框里出现“UML软件建模复习题.pdf”这个文件名通常意味着两类人一类是软考软件设计师、系统架构设计师的考生一类是软件工程期末备考的高校学生大家拿到一份几十页的PDF第一反应是先翻到最后看有没有答案。把这份复习题当成“题堆”来背效率最低。它真正的价值是帮你划定了UML建模的考点边界类图、用例图、时序图、状态图、包图、六种关系、多重性、建模软件的使用。这几项恰好是平时做设计评审、画技术方案、写接口文档时最常用的能力。这篇内容不走“从头讲UML是什么”的老路直接按复习题的出题逻辑展开先搞定静态结构再套动态图模板最后用PlantUML、Visio、EA这类常用建模软件交付能拿分的答案。软考考生、期末备考者和想补UML功底的初中级开发按这个顺序复现一遍就够了。2. 类图、用例图与包图刷题前先把这三张UML图分清2.1 类图的三格结构名称、属性与方法不是背出来的复习题里最常出现的UML类图考的不是能不能画出漂亮的矩形而是能否把一个类准确转换成标准的三格形式。类图的标准画法是一个矩形分成三格顶部写类名中间写属性底部写方法。属性行建议写成“可见性 名称 : 类型”的格式方法行写成“可见性 名称(参数列表) : 返回类型”的格式。阅卷时先看的就是这个格式是否完整类名漏写、属性不带类型、方法忘写返回类型都属于扣分项。可见性符号是高频选择题考点表示 public-表示 private#表示 protected~表示 package。这四个符号之间没什么高深道理用一段PlantUML就能固化记忆startuml class Order { - orderId : String totalAmount : double # status : int ~ createTime : Date pay() : boolean - calcDiscount() : double } enduml这段代码在PlantUML中生成一个四行属性、两行方法的类图。对应关系是减号映射 private加号映射 public井号映射 protected波浪线映射 package。记忆时可以这么想可见范围越大的符号越“敞开”private 是-表示封闭public 是表示对外开放protected 加了#表示有条件的开放。属性行里的类型写在冒号后方法行里的返回类型也写在冒号后这个顺序和 Java 声明的顺序相反Java 是“类型 名称”但类图标准要求“名称 : 类型”这个颠倒恰恰是阅卷老师最常挑的格式错误。提示属性行不要写初始值不要写号类图只表达结构不表达赋值动作。很多复习题的参考答案里属性带默认值那是把类图和对象图混在一起了。2.2 用例图include 与 extend 的判据要能说给考官听用例图在复习题里的考核点不是画得好看而是 include 和 extend 谁指向谁。UML用例图中include 表示基用例一定会调用被包含用例常用于多个用例共用的子流程箭头从基用例指向被包含用例虚线上标includeextend 表示可选扩展箭头从扩展用例指向基用例标extend。判据就一句话include 是必需品extend 是赠品。基用例可以独立完成主流程时不需要 include但如果基用例内部必须先执行某段逻辑才能继续这段逻辑就是被包含项。startuml left to right direction actor 顾客 as c rectangle 在线商城 { (登录验证) . (结算) : include (优惠券抵扣) . (结算) : extend (结算) -- c } enduml这个例子中“结算”用例内部一定会做身份校验所以“登录验证”被结算包含箭头从“登录验证”指向“结算”。“优惠券抵扣”只有用户主动选择才发生不影响结算主流程所以作为扩展用例存在箭头从“优惠券抵扣”指向“结算”。复习题常考“箭头指向被依赖方”这个规律include 中基用例依赖被包含用例extend 中基用例不依赖扩展用例扩展用例反而依赖基用例的扩展点所以两处箭头方向相反。做题时先把基用例找出来再看谁没谁不行最后落笔标方向。2.3 包图与建模软件的“由粗到细”思路UML包图常以“判断包间的依赖关系”的形式出现在复习题里典型考法是给三个包 A、B、CA 依赖 BB 依赖 C问是否可以认为 A 间接依赖 C。这里的知识点是UML 的依赖不可传递A 直接依赖 C 必须单独画线。包图里的依赖线用虚线箭头箭尾是依赖方箭头指向被依赖方。包图还用来表达架构分层表现层依赖业务层、业务层依赖数据层这种三层结构的依赖图是复习题里最稳定的素材。startuml package 表现层 { class UserController } package 业务层 { class UserService } package 数据层 { class UserMapper } UserController .. UserService : 依赖 UserService .. UserMapper : 依赖 enduml这段代码画的包图解决了一个典型复习场景分层架构下依赖关系的陈述。数据层不依赖任何包所以能单独被替换表现层依赖业务层业务层又依赖数据层但表现层并不直接依赖数据层这是分层架构的边界意义。答题时建议先画包图再画类图包图决定类的归属类图决定类的内部结构这个“由粗到细”的顺序也是建模软件里的标准建包顺序。EA、StarUML 里都是先建包再在包内建类包名必须写在矩形顶部的小标签里。题干关键词应选UML图考察重点下订单、退款流程时序图或活动图消息顺序、工作流用户、角色、权限关联用例图include/extend 方向集合、成员、父子结构类图多重性、聚合/组合系统模块划分、层间依赖包图包间依赖、层次边界状态切换、事件触发状态图迁移条件、动作类之间调用、接口实现时序图或类图消息顺序、可见性题干里的动词决定图的选择不用背 UML 2.5 的全部 14 种图先把这张表刻在脑子里选择题就能拿下一半。3. 类图关系判别复习题里最容易丢分的六种连接线3.1 依赖、关联、聚合、组合一条判断链路讲透复习题分析题最经典的考法是给一段需求描述要求画出类图并标注关系类型。考生易错的不是画线而是区分依赖、关联、聚合、组合、泛化、实现这六种关系。先看依赖与关联的区别依赖是临时使用方法参数、局部变量、静态方法调用都算依赖对应虚线箭头关联是长期持有类的成员变量、字段引用才算关联对应实线。判断顺序推荐三步走先看是不是继承或实现是则停再看是不是整体与部分的关系不是则按关联处理是整体与部分再从生命周期判断聚合或组合。聚合与组合是最迷惑的一对判据是“部分能否脱离整体单独存在”。订单和订单项是聚合还是组合订单被删除订单项失去存在的业务意义这是组合用实心菱形班级和学生班级解散后学生仍以独立个体存在这是聚合用空心菱形。PlantUML中聚合用o--组合用*--startuml class Order class OrderItem class Faculty class Student Order *-- OrderItem : 组合 Faculty o-- Student : 聚合 enduml注意 PlantUML 中菱形位置Order *-- OrderItem表示菱形在 Order 一侧即 Order 是整体OrderItem 是部分。实际复习题里经常给一张画好的图让你判断菱形是实心还是空心答题时先找“整体”和“菱形”是否同侧再把两个类的语义代入“部分能否脱离整体存在”的判据。组合关系在数据库建表时通常对应外键 NOT NULL聚合关系对应外键可空这个映射可以用来反向验证答案是否合理。3.2 多重性1、0..1、* 的位置和含义类图关联线两端的数字叫多重性复习题里常以“1对多”“多对多”的选择题形式出现。标准写法有六档1 表示恰好一个0..1 表示零或一个* 表示零或多个1..* 表示至少一个0..* 表示任意数量n..m 表示固定区间。多重性标注在关联线两端靠近哪个类就表示那个类一侧的实例数量范围。判断核心从哪个类出发就看另一个类的数量。startuml class Department { - name : String } class Employee { - name : String } Department 1 o-- 0..* Employee : 雇佣 enduml这段代码中Department 端标 1Employee 端标 0..含义是“一个部门聚合零到多个员工”反过来说“每个员工必须属于一个部门”。答题时最容易犯的错误是把两端数字写反在 Department 一侧写 0..、在 Employee 一侧写 1语义就变成了一个部门属于零到多个员工一个员工必须有且仅有一个部门这不符合通常的业务理解。所以正确流程是先确定出发的类再看对方数量区间最后把数字写在对方那一端。关联线两端可以同时写多重性也可以只在有歧义的一端写。提示多重性标在“线端”而不是“线中”标在线中的做法是活动图的标记习惯不要混。3.3 泛化与实现别把“接口”画成“父类”泛化和实现都是带空心三角箭头的连接线区别在线型泛化是实线空心三角箭头实现是虚线空心三角箭头。复习题常让考生判断给定连线是泛化还是实现题干里出现“接口”“implements”大概率是实现出现“继承”“extends”“抽象类”大概率是泛化。典型例子ArrayList实现List接口用虚线空心三角ArrayList继承AbstractList抽象类用实线空心三角。在 PlantUML 中泛化直接--|实现用..|startuml interface List class ArrayList abstract class AbstractList AbstractList |-- ArrayList List |.. ArrayList enduml注意实现关系的箭头方向和依赖一样指向被依赖方接口泛化箭头指向父类。有一个阅卷场景接口里声明了两个方法实现类只画了一个方法这就是一个“实现关系缺方法”的考点对应的知识点是实现类必须实现接口的全部抽象方法。答题时可以在接口下方用 note 把方法清单列出来既提示自己也让阅卷老师看清“接口即契约”的兑现程度。4. 时序图、状态图与活动图的答题模板动态建模的三板斧4.1 时序图生命线与激活条的画法时序图考查消息顺序题干里出现“先…然后…最后…”的表述优先考虑时序图也叫序列图。核心元素只有三个生命线是顶部矩形加竖直虚线激活条是生命线上的细长矩形消息是激活条之间的水平箭头。画图顺序从上到下和阅读代码的顺序一致。第一道生命线通常是发起者 Actor 或 Controller复习题的时序图答题模板基本固定在“用户-控制器-服务-数据访问”四层。startuml actor 用户 participant Controller as C participant Service as S participant Mapper as M 用户 - C: 提交订单 C - S: createOrder() S - M: insert(order) M -- S: 主键 S -- C: 订单号 C -- 用户: 下单成功 enduml这段代码展示了完整的调用链。答题时注意三点第一条消息从用户发往控制器写“提交订单”服务层方法名要带括号表示方法调用返回消息全部用虚线不需要写方法名写返回的数据即可。自调用消息画成在自己激活条上回环的箭头代表方法内部递归或调用重载。高频选择题是“时序图里返回消息用什么线”答案是虚线实线只表示普通消息这个规则在所有 UML 动态图里一致。4.2 状态图事件与动作的区分是给分点状态图适合描述单对象生命周期订单状态机是复习题最常用的素材。状态图三要素状态用圆角矩形表示事件是状态迁移的触发条件写在迁移箭头旁的方括号里动作是进入状态后的行为写在状态内部分 entry、do、exit 三种。entry 表示进入状态立即执行do 表示停留期间持续执行exit 表示离开前执行。复习题常拿“支付成功”作为事件“扣减库存”作为动作要求考生判断两者在状态图中各写在哪里。startuml [*] -- 待支付 待支付 : entry/生成订单号 待支付 -- 已支付 : [支付成功] 已支付 : do/扣减库存 已支付 -- 已发货 : [发货] 已发货 -- 已完成 : [确认收货] 已完成 -- [*] enduml这段代码中[支付成功] 是事件写在迁移箭头上entry/生成订单号 和 do/扣减库存 是动作写在状态里。答题时记住“事件推动状态变迁动作跟随状态存在”这个二元结构就能应付绝大多数状态图分析题。另外注意初始状态是实心圆点终止状态是圆环外框两者都不写名称。选择题里把初始状态画成圆角矩形的选项可以直接排除。4.3 活动图泳道与控制流补充动态答案活动图在复习题里的出现频率略低于时序图和状态图但一旦出现就以泳道划分为考点。泳道是垂直划分的活动区域每个泳道代表一个角色或系统模块活动节点在泳道内跨泳道的箭头表示职责交接。活动图与状态图容易混淆判断依据是状态图盯着一个对象看状态迁回活动图盯着一群人看业务流程流转。画活动图时用圆角矩形表示活动菱形表示判断加粗横条表示并发分叉与汇合。startuml |仓管员| start :拣货; :复核; |快递员| :揽收; if (配送范围?) then (是) :送货上门; else (否) :通知自提; endif stop enduml这个例子中泳道按角色划分控制流随时间在泳道间移动。答题模板三步走先列出参与者列表再给每个参与者分配一组活动最后用菱形判断合并分支。这三步能保证卷面不出现交叉控制流。活动图和时序图可以互为验证同一场景用活动图画流程、用时序图画调用顺序如果活动图跨泳道的次数和时序图生命线数量不一致说明参与者有遗漏这是复习时的自查手段。5. 用PlantUML、Visio和EA把答案画成能拿分的图5.1 用Visio怎么画UML类图选对模板比画得快重要用Visio画UML类图被检索得最多原因是考试允许带电脑作图或工作中需要快速交付设计图。这里有一个常见坑Visio 2013 之后的版本新建页里搜“UML”不会直接列出“UML类图”而要搜索“UML Model”打开 UML 模型图模板模板里才有类、用例、序列、状态等模具。打开后拖一个“Class”形状到画布右键选择“属性”打开类编辑器在“属性”页签按“属性名:类型”分行填写字段在“操作”页签写方法右键类形状的显示选项里勾选是否显示属性和操作名。关联线不要用“箭头”形状拼要从“关系”模具里拖“Unidirectional Association”单向关联或“Aggregation”聚合、“Composition”组合。双击关联线能为两端添加多重性文本直接键入*、1..*等值。中文版 Visio 里 Composite 可能翻译成“合成”或“复合”认准实心菱形是组合、空心菱形是聚合不会错。5.2 用EA建模软件离线安装包重装后最该改的两个设置EAEnterprise Architect是复习题里频繁被点名的商业建模软件很多高校机房装的就是它。提到“EA建模软件离线安装包”对应的是机房无法在线安装或激活的场景。离线安装包装完后有两个设置建议优先调整一是 “Settings Project” 里的 Default Language改成 Java属性类型的写法就按 String、int 显示更贴近国内教材习惯二是在 “Start Diagrams” 里勾选 Show diagram legend工作区会常驻可见性符号图例画类图时不用回头查符号含义。用 EA 答类图分析题时先生成包图再在包内建类。双击类名能切换属性和方法编辑器编辑器字段顺序是“可见性、类型、名称”和 PlantUML 的“名称 : 类型”相反填写时不要惯性写反EA 生成代码时会按自己的顺序拼接。5.3 PlantUML答题的三个文本技巧PlantUML 最大的优势是“文字即图”复习时把题干转成代码再导出 PNG。三个技巧能让输出的图更接近试卷印刷标准第一用skinparam classAttributeIconSize 0关闭可见性前的圆形图标让图直接以 - #符号显示避免黑白打印时图标糊成一团第二给关键关系加 note 注记把业务约束写进图里例如note right of Order : 金额由明细行汇总这类业务注释阅卷时能体现理解深度第三代码头部用scale 1.5放大整张图保证多重性数字在 DPI 缩小的答题纸上仍可辨认。startuml scale 1.5 skinparam classAttributeIconSize 0 class Customer { - id : long - name : String } class Order { - orderNo : String - amount : double } Customer 1 o-- 0..* Order : 提交 note right of Order : 金额由明细行汇总 enduml答题时把这段代码丢给 PlantUML导出的 PNG 比手绘或 Visio 拖拽都快。验证输出图的三个维度类名完整不缩写关系线的菱形与整体同侧多重性和可见性符号在 1.5 倍缩放下依然清晰。复习题的产出物能稳定做到这三条就已经超过了大部分只背概念不上手画图的备考者。本文还有配套的精品资源点击获取