刚翻开《UML系统分析与设计》这门课的复习资料时很多人都会有一种错觉UML不就是画图嘛把方框、箭头、虚线记住考试就能应付了。但真正做题就会发现图元只是表面后面藏着的是“关系语义”和“模型视角”这些硬骨头。更麻烦的是复习纲要和习题答案往往分散在不同地方概念讲了一遍题目又是另一套说法合不到一块儿去。这篇内容就是冲着这个问题来的。我会把复习纲要里最容易考、最容易错的点全部拆开再把典型习题的解题思路和参考答案揉到一起讲。不管你是在校备考、做课程设计要画模型图还是工作中想补一下面向对象建模的底子这份复习路线都能直接用。1. 复习纲要的整体思路先搭地图再跑图1.1 UML这门课背后的真正主线UMLUnified Modeling Language统一建模语言这门课名字听起来很大实际上的主线非常清晰用标准化的图形符号把软件系统的“结构”和“行为”表达清楚。建模核心三要素是事物、关系、图。事物是基础元素比如类、接口、用例、组件关系把这些元素连接起来比如依赖、关联、聚合、组合、泛化、实现图则是这些元素和关系在某种视角下的可视化输出。用生活里的语言打个比方事物相当于汉字关系相当于语法图相当于一篇完整的文章。如果复习时只盯着“图长什么样”去背却忽略事物分类和关系语义画出来的图就只是形状堆叠阅卷人一眼就能看出来你不理解模型。反过来把事物和关系弄明白了各种图其实都是同一套元素的不同组合方式看到需求就知道该用哪些事物、哪些关系、画成什么图。1.2 三条主线串起整门课我整理复习纲要的时候不太建议按课件章节顺序一页页过那样特别容易“看完第三张图忘了第一张图”。我自己比较推荐按下面三条主线来搭框架面向对象基础主线对象、类、封装、继承、多态、抽象类、接口。这是建模的理论根基类图里的很多符号都是在表达面向对象的概念。静态建模主线类图、对象图、包图、组件图、部署图。重点放在类图和对象图的区别、类之间的六大关系、多重性、可见性。动态建模主线用例图、活动图、状态机图、时序图、通信图。重点放在用例之间的关系、消息的同步与异步、活动的分叉与汇合、状态迁移的条件。三条主线不是孤立的。静态建模回答“系统里有哪些东西、它们之间长什么样”动态建模回答“这些东西之间怎么协作、在什么条件下怎么变化”。考试的综合题本质上就是让你把这两条线合并成一套完整模型。1.3 根据题型反推复习重点不同学校的期末题型不太一样但大体逃不出四类选择题/判断题考概念辨析比如某图属于结构图还是行为图include和extend的语义区别。简答题考名词解释或者“某图的作用”“某两种关系的区别”。画图题给一段需求文字要求画用例图、类图、时序图。综合设计题给一个完整业务场景要求产出多张图并说明设计理由。对应到复习策略就很清楚了选择题靠刷题巩固简答题靠框架记忆画图题必须动手练综合题需要完整走一遍建模流程。见过不少同学只在选择题和简答题上花时间结果一遇到画图题就手生这是复习纲要里最容易被低估的部分。下面就从最核心的考点开始拆。2. 高频考点拆解图元符号与关系判定是拿分基础2.1 先把“结构图”和“行为图”分清楚UML 2.x 的图形体系可以简单分成两大类。结构图描述系统静态结构类图、对象图、包图、组件图、部署图都算行为图描述系统动态行为用例图、活动图、状态机图、时序图、通信图都算。考试里第一类送分题往往就是“下列哪项属于结构图/行为图”这部分只要分类记清楚基本不会丢分。但真正容易出问题的是一道变种题给出一堆图的名字让你判断“哪一组全部属于行为图”。这种题光背分类还不够你得能认出“通信图是行为图”“组件图是结构图”这类边界性的图。复习时可以在纸上把两张图名清单各写一列每天默写一遍两三天就牢固了。2.2 六大关系一张表记住符号、语义和例句六大关系是UML系统分析与设计里最出题的区域没有之一。关系类型、图形表示、核心语义和典型例句我整理成一张速查表关系类型图形表示核心语义典型例句依赖 (Dependency)虚线 开放箭头一个元素临时使用另一个元素不长期持有方法参数或返回值用到了某个类关联 (Association)实线 普通箭头可无箭头对象之间存在长期稳定的引用用户拥有自己的订单列表聚合 (Aggregation)实线 空心菱形画在整体端整体-部分部分可独立存续车队与车辆车辆拆走后仍是车辆组合 (Composition)实线 实心菱形画在整体端整体-部分部分生命周期依赖整体订单与订单项订单删除后订单项无意义泛化 (Generalization)实线 空心三角箭头指向父类继承关系is-a管理员是一种用户实现 (Realization)虚线 空心三角箭头指向接口类实现接口约定的行为支付服务实现支付接口判断两个类之间该用哪种关系我习惯按顺序问三个问题第一两端对象是不是长期存在于系统里如果是考虑关联族如果只是方法里临时用一下优先依赖。第二两者是不是整体-部分关系如果是再追问一部分能不能离开整体独立存活能独立存活用聚合不能分开用组合。第三是不是“is-a”关系如果是再判断对应的是父类还是接口父类用泛化接口用实现。这三个问题问完绝大多数关系选择题都能定下来。2.3 最容易丢分的三个细节include、聚合组合、依赖关联第一个高频失分点是include和extend。include表示一个用例的执行总是包含另一个用例比如“下单”总是需要“登录”所以“下单”include“登录”extend表示在特定条件下扩展主用例流程比如“下单”在余额不足时“触发充值提醒”这是“充值提醒”extend“下单”。另外箭头方向也常考include是基础用例指向被包含用例extend是扩展用例指向基础用例方向反了直接扣分。第二个高频失分点是聚合和组合。教科书里最经典的区分是“车辆与车轮”用聚合因为车轮可以拆下来单独存在“订单与订单项”用组合因为订单项离开订单就失去业务意义。考试里只要题干强调“随整体一同创建和销毁”或者是“离开整体无法独立存活”基本就是组合。第三个高频失分点是依赖与关联的边界。依赖往往发生在方法内部比如方法里临时构造另一个对象、方法参数、返回值类型关联往往是类的属性级别比如User类里有一个List 属性。把依赖画成关联或把关联画成依赖是画图题里非常常见的失分点。3. 从需求到模型一套完整的建模实操流程3.1 拿到一段需求文字后先做什么考试里的画图题和综合题通常会给类似这样的需求描述“用户可以在系统里下单购买商品下单必须登录库存不足时提示失败。”最忌讳的是拿到题就去找图框脑子里一团乱就开始画。我自己的固定流程是先把文字中的名词圈出来它们是候选类和参与者把动词圈出来它们是候选用例或候选方法把带条件的句子圈出来它们是候选判断节点、扩展用例或状态迁移条件。以刚才那句话为例名词是“用户”“系统”“商品”“订单”“库存”动词是“下单购买”“登录”“提示”条件句是“库存不足时”。整理完这些用例图和类图的基本素材就齐了。这个过程花不了两分钟但能避免后面画图时漏掉关键元素。3.2 用例图从用户视角圈定功能边界用例图像一张系统功能地图回答的是“谁能用这个系统做什么”。画的时候按四步走找参与者谁在使用系统从需求文字里找“用户、管理员、客户、外部系统”这类角色词。找用例参与者要完成的目标是什么把“下单、登录、管理图书”这类动词词组转成用例。画系统边界用一个矩形框把用例包住参与者放在框外。连关系并标注include和extend基础用例和被包含用例之间用include扩展用例与基础用例之间用extend注意带«include»和«extend»构造型。用例图最大的坑是把系统内部细节当成了用例。比如“验证密码”不是用例它只是“登录”的内部步骤。用例必须从参与者价值出发写成一个完整的业务目标比如“登录”“下单”“查询订单”。画之前可以自查这个用例对参与者来说算不算一个完整的目标如果只是中间动作就继续上提。3.3 类图把名词变成系统骨架用例图确定功能边界之后开始做类图。类图是整个UML系统分析与设计里的重中之重几乎每种考试都会出现。以前面的网上书店需求为例。先抽象核心类图书Book属性ISBN、书名、价格、库存量、用户User属性用户名、密码、管理员Admin继承User加管理员编号、订单Order属性订单号、下单时间、总金额、订单项OrderItem属性数量、小计金额、关联图书。然后是关系。管理员与用户之间是泛化管理员是一种用户订单与订单项之间是组合订单删除后订单项失去存在意义图书与订单项之间是关联一个订单项对应一种图书多重性为1对1但一种图书可以被多个订单项引用。这些关系判断依据就是第2章里讲的三个问题。类图里有两个高频细节不能漏。第一个是可见性public用、private用-、protected用#、package用~画图时每属性和方法都要标。第二个是多重性0..1表示零或一个1表示恰好一个1..*表示至少一个*表示零或多个。多重性直接体现业务约束标注错误在综合题里扣分很重。提示画类图时先画核心类再补关联。别一上来就把所有关系线铺满整张纸容易乱。核心类通常是需求名词里出现频率最高的那几个。3.4 时序图把一个场景的动态协作画出来时序图回答的是“某个具体场景下对象之间按什么顺序发消息”。画图步骤固定确定参与对象从上到下排列生命线按时间顺序画消息给关键阶段画激活条。以“用户提交订单”为例用户User向界面对象UI发送“提交订单”消息UI调用OrderController创建订单请求OrderController再调用Order对象执行创建Order访问Book检查库存库存充足进入支付流程支付成功后返回结果给UIUI再返回给User。时序图有三处最容易被扣分。第一返回消息必须用虚线开放箭头很多同学画成同步消息实心箭头。第二生命线顶部的对象名格式要写“对象名:类名”比如order:Order只写一个名字会扣细节分。第三alt判断块里要写明分支条件库存充足和库存不足两个分支都要画全不能只画一半。每次画完重点检查这三个位置正确率会高很多。3.5 活动图和状态机图流程的两种表达方式活动图描述的是业务流程怎么做状态机图描述的是一个对象在其生命周期里怎么变化。两者的区别考试喜欢考简答理解上可以用一句话区分活动图的主角是“动作”状态机图的主角是“状态”。画活动图时起始节点用实心圆终止节点用实心圆外套圆环。判断节点是菱形分叉和汇合用粗横线表示并发。泳道用垂直分区区分不同角色角色多于一个时记得加泳道。考试里经常给“提交订单”这段流程从订单提交开始到库存判断再到支付成功或提示失败分支和汇合都要画清楚。画状态机图时状态用圆角矩形迁移用箭头箭头旁标注触发事件和可选条件。以订单为例状态可以是“待支付→已支付→已发货→已完成”触发事件分别是“支付成功”“仓库发货”“确认收货”另外还有“已取消”状态由“取消订单”触发。把这条迁移路径画出来状态机图的核心分就拿到了。3.6 工具选型复习时怎么画效率最高如果考试是手绘图那就只能纸笔练习没有捷径。平时复习画图我推荐两个路线想快速生成又不折腾版式的用文本类绘图工具输入描述后自动生成UML图适合复习时反复修改想要所见即所得的用免费网页版绘图工具拖拽图元就行适合课程项目交付。无论用什么工具画完都要主动检查菱形方向、箭头虚实、多重性、可见性这几个位置。工具能救你的只有排版不能替你做关系判断。工具绘图只是手段复习的重点永远是“能不能判断出该用哪个关系”。4. 典型习题与答题思路复习时可以直接照做的套题4.1 选择题概念辨析的常见考点选择题考来考去就是概念归属、符号对应、关系语义、图元作用。我把高频题整理成几类附上快速判断思路。题1下列哪个图属于行为图A. 类图 B. 组件图 C. 活动图 D. 部署图。答案C。判断思路行为图描述“怎么做”结构图描述“是什么”活动图明显讲流程属于行为图。题2表示整体-部分关系且部分可以独立存续的关系是A. 组合 B. 聚合 C. 实现 D. 依赖。答案B。关键词是“可以独立存续”这是聚合区别于组合的关键。题3用例图中基础用例“在线购物”总是包含“登录”这种关系应使用A. extend B. include C. generalization D. association。答案B。关键词“总是包含”指向include而不是可选的extend。选择题做错的时候不要只看正确答案就过了。把四个选项里涉及的概念全部对照写一遍比如这道题选B那就把“组合和聚合的区别”顺手写出来。一道错题当四组知识点复习效率高得多。4.2 简答题框架比文采重要简答题是最容易拿分的部分因为它只需要答中要点。我整理了三种高频问法“简述UML系统分析与设计中类图和对象图的主要区别。”参考要点类图描述类的属性、方法和类间关系不针对某个具体时刻对象图描述某一时刻特定对象的属性和对象间链接相当于类图的实例快照。判分点基本落在“类与实例”和“静态结构与时态快照”两个对应关系上。“简述用例图的作用。”参考要点从用户角度描述系统功能识别参与者与用例为需求分析与系统设计之间建立可追踪的桥梁。多写一句“用例图是需求建模的起点”也没问题但三个判分要点必须写全。“简述依赖关系和关联关系的区别。”参考要点依赖是瞬时的、方法级的引用关联是持久的、属性级的引用依赖用虚线关联用实线。简答题的破题方式就是“先给概念定义再说应用价值最后点一句和相邻概念的关系”三步写完分数通常比较稳定。4.3 画图题拿一套“图书借阅系统”练手很多学校爱考图书管理、医院挂号、网上购物这类经典场景。我以“图书借阅系统”为例给出一套可直接套用的参考模型。需求文字“借阅者可以检索图书借阅者可以借书借书前必须出示有效借阅证借阅证可在前台办理图书管理员可以录入新书、处理借还书。”画用例图时参与者有“借阅者”和“管理员”。用例有“检索图书”“借书”“还书”“办理借阅证”“录入新书”。“借书”总是需要“验证借阅证有效性”所以验证借阅证用include挂在“借书”下面。系统边界框把用例包住参与者放在框外。画类图时核心类包括图书Book、借阅者Reader、借阅记录LoanRecord、管理员Admin、借阅证LibraryCard。关系上Reader和LoanRecord是1对多关联Book和LoanRecord是多对多关联借阅证与借阅者按业务语义看如果强调借阅证不能脱离借阅者而独立存在用组合也合理。画完类图别停把“借书成功”的时序图也补上借阅者→借书界面→LoanRecord→Book每个环节的同步消息和返回消息都画全。一套流程练完画图题基本遇不到意外。4.4 综合设计题从需求到四张图的完整路径综合题一般是给一大段需求要求“需求建模静态建模动态建模”实际输出通常包含用例图、类图、时序图和状态机图或活动图。这类题分值大难点不在画图技术而在流程完整性。我固定采用四步走第一步提取需求里的业务名词和业务动词整理成简易词汇表第二步画用例图确定系统对外的功能边界第三步细化类图给每个类补属性和方法逐条确认关系第四步挑核心用例画时序图再补一个活动图或状态机图回答“流程怎么走”或“状态怎么变”。综合题丢分往往不是最后画错了图而是中间跳步。有同学拿到需求直接开画类图类画了不少却没画用例图后面类图上的很多关系就找不到需求依据。模型之间是有依赖链的用例图是类图的依据时序图是类图行为的实例化。把这条链走完整综合题基本能拿大半分值。5. 复习中的常见问题与考场避坑清单5.1 符号总是记不牢怎么办UML符号数量不算少纯靠死记硬背效率很低。我的做法是“按关系成组记忆”把六种关系分成三条线。实线族有关联、聚合、组合、泛化代表长期结构和类型关系虚线族有依赖、实现代表临时使用和接口约定。菱形只出现在聚合和组合里空心还是实心决定了部分是否能独立存在三角箭头只出现在泛化和实现里实线还是虚线决定了是继承还是实现接口。看到任何一个箭头先判断线和箭头类型再定位到对应关系就不容易乱。5.2 画图题总是丢分集中在这四个位置从批改作业的经验看画图题失分高度集中在四块一是菱形的位置不对聚合和组合的菱形必须贴在整体端二是箭头虚实颠倒依赖用虚线、关联用实线泛化实线三角、实现虚线三角三是多重性和可见性漏标四是时序图里的返回消息画错方向或整条漏画。每画完一张图花30秒按这四个位置自查一遍能拦截掉一批扣分点。5.3 考前三天怎么安排最稳如果只剩三天真不建议再从第一页课件开始看。一个比较稳的安排是第一天把关系速查表和各类图的核心图元过一遍配合选择题和判断题巩固第二天专门练画图题选一个经典业务场景从用例图、类图到时序图完整画一遍第三天把简答题模板背熟再刷一套往年真题或模拟题保持手感。这个安排的重点是先把必拿的基础分稳住再集中突破最容易拉分的画图题。5.4 考场上必须提醒自己的几件事拿到画图题不要在正式答题区直接落笔。先在草稿纸上列参与者、用例、类、消息的清单再画正式图。整洁清晰的图本身就有印象分线条歪斜、箭头不齐、文字互相遮挡会严重影响阅卷体验。平时有条件就练练纸笔手绘至少完整画过三张图考场上才不容易手忙脚乱。提示如果题目要求说明设计理由千万不要只写“我觉得应该这样画”。理由要对应到业务约束比如“使用组合是因为订单项的生命周期依赖订单存在”这样的表述才是有效设计说明。说到最后我想多讲一点实际体会。UML系统分析与设计这门课真正能拉开差距的不是记忆力而是你有没有一套“先分析、再建模、最后验证”的思考路径。见过一些人把课件从头背到尾遇到灵活一点的情景题还是懵反而是踏踏实实拿网上书店、图书管理系统这类熟悉场景把用例图、类图、时序图、活动图完整练过几遍的人面对新需求也能快速拆解出该画什么图、用什么关系、标什么符号。复习纲要的作用是给你一条路线习题答案的意义是给你反馈但真正变成你自己能力的是动手建模那几步。考前如果时间实在紧张优先练一套完整案例的手绘比盲目刷几十页题都管用。 
长河君 · 2026/10/17 1:20:06 · 阅读 1.2k UML系统分析与设计复习：从关系语义到建模实战全攻略
刚翻开《UML系统分析与设计》这门课的复习资料时很多人都会有一种错觉UML不就是画图嘛把方框、箭头、虚线记住考试就能应付了。但真正做题就会发现图元只是表面后面藏着的是“关系语义”和“模型视角”这些硬骨头。更麻烦的是复习纲要和习题答案往往分散在不同地方概念讲了一遍题目又是另一套说法合不到一块儿去。这篇内容就是冲着这个问题来的。我会把复习纲要里最容易考、最容易错的点全部拆开再把典型习题的解题思路和参考答案揉到一起讲。不管你是在校备考、做课程设计要画模型图还是工作中想补一下面向对象建模的底子这份复习路线都能直接用。1. 复习纲要的整体思路先搭地图再跑图1.1 UML这门课背后的真正主线UMLUnified Modeling Language统一建模语言这门课名字听起来很大实际上的主线非常清晰用标准化的图形符号把软件系统的“结构”和“行为”表达清楚。建模核心三要素是事物、关系、图。事物是基础元素比如类、接口、用例、组件关系把这些元素连接起来比如依赖、关联、聚合、组合、泛化、实现图则是这些元素和关系在某种视角下的可视化输出。用生活里的语言打个比方事物相当于汉字关系相当于语法图相当于一篇完整的文章。如果复习时只盯着“图长什么样”去背却忽略事物分类和关系语义画出来的图就只是形状堆叠阅卷人一眼就能看出来你不理解模型。反过来把事物和关系弄明白了各种图其实都是同一套元素的不同组合方式看到需求就知道该用哪些事物、哪些关系、画成什么图。1.2 三条主线串起整门课我整理复习纲要的时候不太建议按课件章节顺序一页页过那样特别容易“看完第三张图忘了第一张图”。我自己比较推荐按下面三条主线来搭框架面向对象基础主线对象、类、封装、继承、多态、抽象类、接口。这是建模的理论根基类图里的很多符号都是在表达面向对象的概念。静态建模主线类图、对象图、包图、组件图、部署图。重点放在类图和对象图的区别、类之间的六大关系、多重性、可见性。动态建模主线用例图、活动图、状态机图、时序图、通信图。重点放在用例之间的关系、消息的同步与异步、活动的分叉与汇合、状态迁移的条件。三条主线不是孤立的。静态建模回答“系统里有哪些东西、它们之间长什么样”动态建模回答“这些东西之间怎么协作、在什么条件下怎么变化”。考试的综合题本质上就是让你把这两条线合并成一套完整模型。1.3 根据题型反推复习重点不同学校的期末题型不太一样但大体逃不出四类选择题/判断题考概念辨析比如某图属于结构图还是行为图include和extend的语义区别。简答题考名词解释或者“某图的作用”“某两种关系的区别”。画图题给一段需求文字要求画用例图、类图、时序图。综合设计题给一个完整业务场景要求产出多张图并说明设计理由。对应到复习策略就很清楚了选择题靠刷题巩固简答题靠框架记忆画图题必须动手练综合题需要完整走一遍建模流程。见过不少同学只在选择题和简答题上花时间结果一遇到画图题就手生这是复习纲要里最容易被低估的部分。下面就从最核心的考点开始拆。2. 高频考点拆解图元符号与关系判定是拿分基础2.1 先把“结构图”和“行为图”分清楚UML 2.x 的图形体系可以简单分成两大类。结构图描述系统静态结构类图、对象图、包图、组件图、部署图都算行为图描述系统动态行为用例图、活动图、状态机图、时序图、通信图都算。考试里第一类送分题往往就是“下列哪项属于结构图/行为图”这部分只要分类记清楚基本不会丢分。但真正容易出问题的是一道变种题给出一堆图的名字让你判断“哪一组全部属于行为图”。这种题光背分类还不够你得能认出“通信图是行为图”“组件图是结构图”这类边界性的图。复习时可以在纸上把两张图名清单各写一列每天默写一遍两三天就牢固了。2.2 六大关系一张表记住符号、语义和例句六大关系是UML系统分析与设计里最出题的区域没有之一。关系类型、图形表示、核心语义和典型例句我整理成一张速查表关系类型图形表示核心语义典型例句依赖 (Dependency)虚线 开放箭头一个元素临时使用另一个元素不长期持有方法参数或返回值用到了某个类关联 (Association)实线 普通箭头可无箭头对象之间存在长期稳定的引用用户拥有自己的订单列表聚合 (Aggregation)实线 空心菱形画在整体端整体-部分部分可独立存续车队与车辆车辆拆走后仍是车辆组合 (Composition)实线 实心菱形画在整体端整体-部分部分生命周期依赖整体订单与订单项订单删除后订单项无意义泛化 (Generalization)实线 空心三角箭头指向父类继承关系is-a管理员是一种用户实现 (Realization)虚线 空心三角箭头指向接口类实现接口约定的行为支付服务实现支付接口判断两个类之间该用哪种关系我习惯按顺序问三个问题第一两端对象是不是长期存在于系统里如果是考虑关联族如果只是方法里临时用一下优先依赖。第二两者是不是整体-部分关系如果是再追问一部分能不能离开整体独立存活能独立存活用聚合不能分开用组合。第三是不是“is-a”关系如果是再判断对应的是父类还是接口父类用泛化接口用实现。这三个问题问完绝大多数关系选择题都能定下来。2.3 最容易丢分的三个细节include、聚合组合、依赖关联第一个高频失分点是include和extend。include表示一个用例的执行总是包含另一个用例比如“下单”总是需要“登录”所以“下单”include“登录”extend表示在特定条件下扩展主用例流程比如“下单”在余额不足时“触发充值提醒”这是“充值提醒”extend“下单”。另外箭头方向也常考include是基础用例指向被包含用例extend是扩展用例指向基础用例方向反了直接扣分。第二个高频失分点是聚合和组合。教科书里最经典的区分是“车辆与车轮”用聚合因为车轮可以拆下来单独存在“订单与订单项”用组合因为订单项离开订单就失去业务意义。考试里只要题干强调“随整体一同创建和销毁”或者是“离开整体无法独立存活”基本就是组合。第三个高频失分点是依赖与关联的边界。依赖往往发生在方法内部比如方法里临时构造另一个对象、方法参数、返回值类型关联往往是类的属性级别比如User类里有一个List 属性。把依赖画成关联或把关联画成依赖是画图题里非常常见的失分点。3. 从需求到模型一套完整的建模实操流程3.1 拿到一段需求文字后先做什么考试里的画图题和综合题通常会给类似这样的需求描述“用户可以在系统里下单购买商品下单必须登录库存不足时提示失败。”最忌讳的是拿到题就去找图框脑子里一团乱就开始画。我自己的固定流程是先把文字中的名词圈出来它们是候选类和参与者把动词圈出来它们是候选用例或候选方法把带条件的句子圈出来它们是候选判断节点、扩展用例或状态迁移条件。以刚才那句话为例名词是“用户”“系统”“商品”“订单”“库存”动词是“下单购买”“登录”“提示”条件句是“库存不足时”。整理完这些用例图和类图的基本素材就齐了。这个过程花不了两分钟但能避免后面画图时漏掉关键元素。3.2 用例图从用户视角圈定功能边界用例图像一张系统功能地图回答的是“谁能用这个系统做什么”。画的时候按四步走找参与者谁在使用系统从需求文字里找“用户、管理员、客户、外部系统”这类角色词。找用例参与者要完成的目标是什么把“下单、登录、管理图书”这类动词词组转成用例。画系统边界用一个矩形框把用例包住参与者放在框外。连关系并标注include和extend基础用例和被包含用例之间用include扩展用例与基础用例之间用extend注意带«include»和«extend»构造型。用例图最大的坑是把系统内部细节当成了用例。比如“验证密码”不是用例它只是“登录”的内部步骤。用例必须从参与者价值出发写成一个完整的业务目标比如“登录”“下单”“查询订单”。画之前可以自查这个用例对参与者来说算不算一个完整的目标如果只是中间动作就继续上提。3.3 类图把名词变成系统骨架用例图确定功能边界之后开始做类图。类图是整个UML系统分析与设计里的重中之重几乎每种考试都会出现。以前面的网上书店需求为例。先抽象核心类图书Book属性ISBN、书名、价格、库存量、用户User属性用户名、密码、管理员Admin继承User加管理员编号、订单Order属性订单号、下单时间、总金额、订单项OrderItem属性数量、小计金额、关联图书。然后是关系。管理员与用户之间是泛化管理员是一种用户订单与订单项之间是组合订单删除后订单项失去存在意义图书与订单项之间是关联一个订单项对应一种图书多重性为1对1但一种图书可以被多个订单项引用。这些关系判断依据就是第2章里讲的三个问题。类图里有两个高频细节不能漏。第一个是可见性public用、private用-、protected用#、package用~画图时每属性和方法都要标。第二个是多重性0..1表示零或一个1表示恰好一个1..*表示至少一个*表示零或多个。多重性直接体现业务约束标注错误在综合题里扣分很重。提示画类图时先画核心类再补关联。别一上来就把所有关系线铺满整张纸容易乱。核心类通常是需求名词里出现频率最高的那几个。3.4 时序图把一个场景的动态协作画出来时序图回答的是“某个具体场景下对象之间按什么顺序发消息”。画图步骤固定确定参与对象从上到下排列生命线按时间顺序画消息给关键阶段画激活条。以“用户提交订单”为例用户User向界面对象UI发送“提交订单”消息UI调用OrderController创建订单请求OrderController再调用Order对象执行创建Order访问Book检查库存库存充足进入支付流程支付成功后返回结果给UIUI再返回给User。时序图有三处最容易被扣分。第一返回消息必须用虚线开放箭头很多同学画成同步消息实心箭头。第二生命线顶部的对象名格式要写“对象名:类名”比如order:Order只写一个名字会扣细节分。第三alt判断块里要写明分支条件库存充足和库存不足两个分支都要画全不能只画一半。每次画完重点检查这三个位置正确率会高很多。3.5 活动图和状态机图流程的两种表达方式活动图描述的是业务流程怎么做状态机图描述的是一个对象在其生命周期里怎么变化。两者的区别考试喜欢考简答理解上可以用一句话区分活动图的主角是“动作”状态机图的主角是“状态”。画活动图时起始节点用实心圆终止节点用实心圆外套圆环。判断节点是菱形分叉和汇合用粗横线表示并发。泳道用垂直分区区分不同角色角色多于一个时记得加泳道。考试里经常给“提交订单”这段流程从订单提交开始到库存判断再到支付成功或提示失败分支和汇合都要画清楚。画状态机图时状态用圆角矩形迁移用箭头箭头旁标注触发事件和可选条件。以订单为例状态可以是“待支付→已支付→已发货→已完成”触发事件分别是“支付成功”“仓库发货”“确认收货”另外还有“已取消”状态由“取消订单”触发。把这条迁移路径画出来状态机图的核心分就拿到了。3.6 工具选型复习时怎么画效率最高如果考试是手绘图那就只能纸笔练习没有捷径。平时复习画图我推荐两个路线想快速生成又不折腾版式的用文本类绘图工具输入描述后自动生成UML图适合复习时反复修改想要所见即所得的用免费网页版绘图工具拖拽图元就行适合课程项目交付。无论用什么工具画完都要主动检查菱形方向、箭头虚实、多重性、可见性这几个位置。工具能救你的只有排版不能替你做关系判断。工具绘图只是手段复习的重点永远是“能不能判断出该用哪个关系”。4. 典型习题与答题思路复习时可以直接照做的套题4.1 选择题概念辨析的常见考点选择题考来考去就是概念归属、符号对应、关系语义、图元作用。我把高频题整理成几类附上快速判断思路。题1下列哪个图属于行为图A. 类图 B. 组件图 C. 活动图 D. 部署图。答案C。判断思路行为图描述“怎么做”结构图描述“是什么”活动图明显讲流程属于行为图。题2表示整体-部分关系且部分可以独立存续的关系是A. 组合 B. 聚合 C. 实现 D. 依赖。答案B。关键词是“可以独立存续”这是聚合区别于组合的关键。题3用例图中基础用例“在线购物”总是包含“登录”这种关系应使用A. extend B. include C. generalization D. association。答案B。关键词“总是包含”指向include而不是可选的extend。选择题做错的时候不要只看正确答案就过了。把四个选项里涉及的概念全部对照写一遍比如这道题选B那就把“组合和聚合的区别”顺手写出来。一道错题当四组知识点复习效率高得多。4.2 简答题框架比文采重要简答题是最容易拿分的部分因为它只需要答中要点。我整理了三种高频问法“简述UML系统分析与设计中类图和对象图的主要区别。”参考要点类图描述类的属性、方法和类间关系不针对某个具体时刻对象图描述某一时刻特定对象的属性和对象间链接相当于类图的实例快照。判分点基本落在“类与实例”和“静态结构与时态快照”两个对应关系上。“简述用例图的作用。”参考要点从用户角度描述系统功能识别参与者与用例为需求分析与系统设计之间建立可追踪的桥梁。多写一句“用例图是需求建模的起点”也没问题但三个判分要点必须写全。“简述依赖关系和关联关系的区别。”参考要点依赖是瞬时的、方法级的引用关联是持久的、属性级的引用依赖用虚线关联用实线。简答题的破题方式就是“先给概念定义再说应用价值最后点一句和相邻概念的关系”三步写完分数通常比较稳定。4.3 画图题拿一套“图书借阅系统”练手很多学校爱考图书管理、医院挂号、网上购物这类经典场景。我以“图书借阅系统”为例给出一套可直接套用的参考模型。需求文字“借阅者可以检索图书借阅者可以借书借书前必须出示有效借阅证借阅证可在前台办理图书管理员可以录入新书、处理借还书。”画用例图时参与者有“借阅者”和“管理员”。用例有“检索图书”“借书”“还书”“办理借阅证”“录入新书”。“借书”总是需要“验证借阅证有效性”所以验证借阅证用include挂在“借书”下面。系统边界框把用例包住参与者放在框外。画类图时核心类包括图书Book、借阅者Reader、借阅记录LoanRecord、管理员Admin、借阅证LibraryCard。关系上Reader和LoanRecord是1对多关联Book和LoanRecord是多对多关联借阅证与借阅者按业务语义看如果强调借阅证不能脱离借阅者而独立存在用组合也合理。画完类图别停把“借书成功”的时序图也补上借阅者→借书界面→LoanRecord→Book每个环节的同步消息和返回消息都画全。一套流程练完画图题基本遇不到意外。4.4 综合设计题从需求到四张图的完整路径综合题一般是给一大段需求要求“需求建模静态建模动态建模”实际输出通常包含用例图、类图、时序图和状态机图或活动图。这类题分值大难点不在画图技术而在流程完整性。我固定采用四步走第一步提取需求里的业务名词和业务动词整理成简易词汇表第二步画用例图确定系统对外的功能边界第三步细化类图给每个类补属性和方法逐条确认关系第四步挑核心用例画时序图再补一个活动图或状态机图回答“流程怎么走”或“状态怎么变”。综合题丢分往往不是最后画错了图而是中间跳步。有同学拿到需求直接开画类图类画了不少却没画用例图后面类图上的很多关系就找不到需求依据。模型之间是有依赖链的用例图是类图的依据时序图是类图行为的实例化。把这条链走完整综合题基本能拿大半分值。5. 复习中的常见问题与考场避坑清单5.1 符号总是记不牢怎么办UML符号数量不算少纯靠死记硬背效率很低。我的做法是“按关系成组记忆”把六种关系分成三条线。实线族有关联、聚合、组合、泛化代表长期结构和类型关系虚线族有依赖、实现代表临时使用和接口约定。菱形只出现在聚合和组合里空心还是实心决定了部分是否能独立存在三角箭头只出现在泛化和实现里实线还是虚线决定了是继承还是实现接口。看到任何一个箭头先判断线和箭头类型再定位到对应关系就不容易乱。5.2 画图题总是丢分集中在这四个位置从批改作业的经验看画图题失分高度集中在四块一是菱形的位置不对聚合和组合的菱形必须贴在整体端二是箭头虚实颠倒依赖用虚线、关联用实线泛化实线三角、实现虚线三角三是多重性和可见性漏标四是时序图里的返回消息画错方向或整条漏画。每画完一张图花30秒按这四个位置自查一遍能拦截掉一批扣分点。5.3 考前三天怎么安排最稳如果只剩三天真不建议再从第一页课件开始看。一个比较稳的安排是第一天把关系速查表和各类图的核心图元过一遍配合选择题和判断题巩固第二天专门练画图题选一个经典业务场景从用例图、类图到时序图完整画一遍第三天把简答题模板背熟再刷一套往年真题或模拟题保持手感。这个安排的重点是先把必拿的基础分稳住再集中突破最容易拉分的画图题。5.4 考场上必须提醒自己的几件事拿到画图题不要在正式答题区直接落笔。先在草稿纸上列参与者、用例、类、消息的清单再画正式图。整洁清晰的图本身就有印象分线条歪斜、箭头不齐、文字互相遮挡会严重影响阅卷体验。平时有条件就练练纸笔手绘至少完整画过三张图考场上才不容易手忙脚乱。提示如果题目要求说明设计理由千万不要只写“我觉得应该这样画”。理由要对应到业务约束比如“使用组合是因为订单项的生命周期依赖订单存在”这样的表述才是有效设计说明。说到最后我想多讲一点实际体会。UML系统分析与设计这门课真正能拉开差距的不是记忆力而是你有没有一套“先分析、再建模、最后验证”的思考路径。见过一些人把课件从头背到尾遇到灵活一点的情景题还是懵反而是踏踏实实拿网上书店、图书管理系统这类熟悉场景把用例图、类图、时序图、活动图完整练过几遍的人面对新需求也能快速拆解出该画什么图、用什么关系、标什么符号。复习纲要的作用是给你一条路线习题答案的意义是给你反馈但真正变成你自己能力的是动手建模那几步。考前如果时间实在紧张优先练一套完整案例的手绘比盲目刷几十页题都管用。