★ FEATURED ARTICLE 简介一份关于UML状态图的系统化讲解PPT主要面向软件工程专业学生、系统分析与设计人员以及需要完成动态建模任务的项目开发者。内容以图书馆管理系统中的借书、还书两个用例作为贯穿案例系统梳理了状态图的基本构成。讲解从事件入手将信号事件、调用事件、变化事件和时间事件分别结合示例说明接着介绍状态的概念、组成部分及入口/出口动作、内部转换、子状态等细节再过渡到转换关系的触发条件与绘制方法并给出打印机状态、图书借还流程等多个示例。资源包仅有1个PPT文件大小285KB内容紧凑适合课堂同步或自学速览。目前已有373人学习使用用于理解对象生命周期和系统动态行为建模。学完可掌握状态图的事件描述、状态划分、转换绘制等核心技能从而更好地完成系统分析与UML建模实践。1. 为什么你的 UML 状态图 PPT 总是让人听完就忘“UML状态图详细介绍PPT”这个标题搜索的人多半是想找一份现成课件直接拿去讲。但我做了这么多年技术评审和内部分享见过太多看起来齐全、讲起来冷场的状态图PPT几十页概念、满屏箭头听众听完记住的只有“状态图很复杂”。真正的问题不是UML状态图难而是PPT的叙事顺序错了——大部分人先堆概念再放图最后用案例硬套结果概念没落进场景案例又反过来解释概念。状态图的核心讲述顺序应该反过来先给一个能看懂的状态切换实例再回过来解释状态、事件、动作三件事最后才引入复合状态和并发。这篇文章就把这条路径拆出来从内容组织到每页排版参数再到现场常踩的坑照做就能做出一份让人听完能上手的状态图PPT。适合谁要给团队做内部分享、讲需求、写设计文档、做方案评审的人。2. UML 状态图拆解先把状态、事件、动作三件事讲清再动手做 PPT在动手做PPT之前得先让“状态图到底在描述什么”这个底层问题站稳。很多PPT听完就忘不是因为案例不够而是因为讲者自己也没有分清状态图、活动图和时序图的边界。这一章先把UML状态图的知识主干拆干净再给出一套与PPT页面一一对应的映射关系后面每一页都有据可依。2.1 状态图与活动图的本质区别什么时候用状态图状态图描述的是一个对象从创建到销毁的生命周期里因事件而发生状态迁移。它强调“在什么状态等待什么事件、满足什么条件、进入什么状态、执行什么动作”。活动图描述的是业务流程的先后步骤强调“做什么、谁来做、按照什么顺序做”。两者最直观的区别是状态图里的每个节点必须是一个可以停留的时段活动图里的每个节点通常是一个执行动作。举个例子。一个订单系统里“待支付”是状态因为订单会一直停留在那里等待支付事件“发送确认邮件”不是状态它是一个动作执行完就结束。如果把动作画成状态图里的节点就会出现“正在发送邮件”这种伪状态——听众会问邮件发送一半卡住了算哪个状态真正的状态应该是“邮件任务已创建”或“已发送”之间的一次切换。这个例子我每次讲都会重复两遍因为大部分人对状态和动作的混淆远比自己以为的严重。那么在PPT里怎么向听众讲清这个边界我一般会放一张对照表。完整版放在备注脚本里PPT上只保留精简版三行否则就成了信息搬运而不是讲解。维度UML状态图UML活动图描述对象单个对象的状态变迁业务流程的步骤流转节点含义稳定状态可停留等待动作或活动执行后进入下一步转移条件事件与守卫条件流程分支与汇合典型问题对象会不会死锁、能否重入流程是否有遗漏、职责是否清晰PPT讲述重点事件驱动、状态转换、动作时机步骤顺序、分支条件、角色分工为什么要坚持讲这个区别因为状态图PPT最常见的翻车就是“画成了流程图”从登录、浏览、下单到支付依次排开每个步骤画成圆角矩形再连上箭头。这不是状态图只是带箭头的步骤条它丢失了“状态可停留”这个核心属性。流程图里节点之间是“做完上一步做下一步”状态图里节点之间是“停在某个状态直到某件事发生”这两种思维方式完全不同。什么时候真正需要用状态图当你关心一个对象在多个稳定状态之间切换而且切换依赖外部事件或条件时应该用状态图。如果只是业务流程审批链用活动图或泳道图更合适。这个判断最好在PPT的第2页就明确告诉听众并在第3页用一个错误对比强调一遍否则后面所有案例都可能被听众用流程图的思维质疑。我习惯给一句口诀画完图后问自己“每个节点是否能停下来等待”能是状态不能是动作。这句口诀可以直接写在PPT页脚的备注里现场讲的时候多说一遍通常能打断一波习惯性追问。2.2 状态图的核心元素和一套 PPT 页面映射每个元素对应哪一页标准UML状态图的核心元素虽然语法细节有不少分支但做一次面向团队的详细介绍只需要讲透这10个点状态、初始伪状态、终止伪状态、事件、转换、守卫条件、动作、复合状态、并发区域、历史状态。每一个都应该在PPT里有一个明确的登场位置而不是一次性全部堆出来。我通常把这些元素拆成四组对应四页PPT顺序从静态到动态。第一组是“状态”本身包括初始伪状态和终止伪状态。PPT上只放一个简单例子一台设备处于待机、运行、故障三个状态初始伪状态指向待机故障可以指向终止。这一页的目标是让听众理解状态是一个稳定停留点生命周期有起点和终点。第二组是“事件与转换”这是状态图的动态核心。PPT上在同一个例子里给待机添加一个事件“启动指令”转换箭头指向运行。这里要强调转换箭头上必须写事件名否则箭头就没有意义。守卫条件用方括号动作用斜杠例如“启动指令 [参数校验通过] / 设备自检”这个语法要作为全PPT的统一规则放在页角。第三组是“动作的三种时机”entry进入状态时、do状态内持续、exit离开状态时。这一页建议用同一个状态框展开列出三个动作文字比如进入“运行”时执行“读取配置”运行中执行“周期上报”退出时执行“释放端口”。目的是让听众区分“状态”和“动作”不要把它们混在一起。很多新手把“正在读取配置”画成一个状态其实就是没理解动作时机。第四组是“复合状态、并发区域与历史状态”属于进阶结构。复合状态就是一个状态框内部再嵌套一张子状态图并发区域用虚线把状态框分成两个以上同时运行的部分历史状态用一个小圆圈加字母H表示记录离开复合状态时的子状态便于返回时恢复。这组内容最容易讲糊所以我给它们的页数也最多。为了让你直接拿到就能用我给出这套页面映射。页码从第3页开始是因为第1页是封面第2页是“为什么用状态图”的导入页。如果你时间紧张可以合并第6和第7页但不要合并前五页否则认知负荷会失控。PPT页码页面主题页面内容要点讲解时长3状态与生命周期状态框、初始/终止伪状态、三种状态示例3分钟4事件与转换转换箭头、事件名、守卫条件、动作语法4分钟5动作的三种时机entry/do/exit 在同一个状态框上展开3分钟6复合状态大框套子状态图给出“处理中”的展开4分钟7并发与历史双虚线分区、历史状态符号3分钟这个映射不是死规定核心原则是一个元素一个焦点每页PPT只负责让听众记住一个新概念其余元素在页面上只作为上下文出现不作为讲解主体。如果你一页里既讲事件又讲动作又讲复合状态听众的短期记忆会溢出后面讲完整案例时他们就连不上了。我在做“UML状态图详细介绍PPT”时会先按这个映射把页面框架搭好再填充文字和图例而不是先把图画好再想怎么排页那样容易被图牵着走。2.3 常见状态图错误画法会误导听众的三种结构做“详细介绍PPT”有一个很大的优势可以在PPT里专门放一页“错误示例”这是教科书很少给、但现场讲解效果极好的内容。三个错误结构最值得讲。它们分别对应了状态图新手最容易踩的三个坑把动作写成状态、丢失事件标签、把守卫条件和事件混写在一起。第一个错误结构是把动作写成状态。例如“正在付款”被画成一个状态框箭头从“待支付”指向“正在付款”再指向“已支付”。这个模型表面上能解释流程但一旦付款过程持续几分钟中间状态就变成一个说不清的黑匣子它到底是不是稳定状态它需要什么事件离开如果支付网关一直没有回调这个状态会不会永远卡住正确做法是把“正在付款”作为“待支付”状态下的一次动作或子状态而不是一个独立的稳定状态。如果需要等待第三方回调应该有一个“支付处理中”的稳定状态并且这个状态本身要定义超时事件。第二个错误结构是缺少事件标签的转换。很多PPT为了让图看起来干净只在箭头上写“下一步”或什么都不写。这会丢失最关键的信息什么事件触发了这次转换。没有事件的状态图退化成流程图完全失去状态机的严谨性。正确做法是每个转换箭头都必须有事件名没有事件的默认转换至少也要写“完成”或“超时”这样的明确触发源。如果一张图里出现三根以上没有事件名的箭头我基本可以判定这张图没有经过状态建模只是流程草稿。第三个错误结构是把守卫条件和事件混写在一起。比如箭头上写“点击按钮且库存大于0且用户已登录然后创建订单”读起来像一段代码而不是状态图。正确写法是“点击下单 [库存校验通过 用户已登录] / 创建订单”事件在最前守卫条件用方括号动作用斜杠。这里有个小技巧在PPT上把这三个部分分三行排版而不是挤在同一行听众更容易按顺序吸收。这个“错误示例页”放在第7页比较合适正好在讲完所有元素之后、进入完整案例之前。它起到的是一个免疫作用让听众先看到坏味道再看到标准图就不会把PPT里的图误读成流程图。这一页的设计也很简单左侧放一张错误图右侧放同一需求的标准图中间用一个红叉和绿勾标识差异。讲解时我通常请听众先自己找错误再揭示答案这样的参与感比单向灌输好很多。3. 从零做一份状态图 PPT一页一页的内容脚本与排版参数知道了知识主干这一章进入制作流程。重点不是审美而是如何把状态图的内容结构变成逐页推进的叙事。很多PPT翻车是在素材阶段就乱了所以第一步不是打开工具而是先在纸上把状态清单列清楚。3.1 做 PPT 前的信息架构先梳理状态再安排页序我一般会在做PPT前先用七步把状态图的内容骨架做出来。这个骨架不直接上PPT但它决定PPT到底要讲什么避免在制作中途反复改图。第一步确定要描述的对象。一个状态图最好只描述一个对象例如订单、工单、用户会话或设备。如果PPT想覆盖多个对象就拆成多个独立案例不要混在同一张图里。第二步列出对象的所有稳定状态。稳定状态的定义是对象保持在这个状态时不会自发变化必须等某个事件或条件发生才能离开。把想得到的都写出来先不要管先后顺序。第三步找触发事件。针对每个状态问“什么东西能让这个对象离开当前状态”结果可能是用户点击、系统回调、超时、外部消息。事件就是转换的唯一入口。第四步找守卫条件和动作。守卫条件决定事件发生后能否真的切换动作决定切换后要执行什么副作用把这两类信息分别记录不要混在事件名里。第五步识别复合状态和并发区域。如果某个状态内部还有明显的子状态就把它标记为复合状态单独展开一张子图。如果对象在某个状态内同时做两件独立的事情就用并发区域。第六步按对象生命周期把上述素材排成页序。通常的页序是导入为什么用状态图 - 状态与生命周期 - 事件与转换 - 动作时机 - 复合/并发 - 完整案例 - 错误对照 - 验收清单。这个顺序比“概念字典”式排序更符合记忆曲线。第七步写讲解脚本。不要写在PPT正文里写在备注页。每页PPT只保留三行以内的核心文字其余全部放到备注中现场照着备注讲而不是照着PPT念。这七步里最容易跳过的是第二步的状态清单。状态清单没做好后面画图就会一边画一边改。我常用的状态清单模板长这样重点是“是否稳定停留”这一列状态名是否稳定停留进入方式退出事件entry动作exit动作待支付是创建订单支付成功/取消生成订单号记录取消时间支付处理中是收到支付回调回调完成/超时锁定库存释放库存已支付是支付回调完成开始发货通知仓储无注意“支付处理中”虽然看起来是短暂的但因为它需要等待第三方回调是可以停留的状态所以要单独列出来。状态清单的价值在于它强迫你区分“状态”和“动作”。做完清单再画图箭头上的事件名基本不会乱。这个习惯我保持了多年每次做状态图相关PPT都会先把表格填完再打开绘图工具省掉了大量返工。3.2 逐页内容模板封面、概念页、元素页、案例页、总结页的文案与排版有了清单接下来把每一页的内容和排版参数定下来。这里给出一套我在内部分享里反复用过的模板总共九页覆盖一场30分钟的介绍。你可以按需增删但骨架建议保留。页序页面标题页面内容排版建议建议时长1UML状态图详细介绍主标题、副标题“用状态机思维讲清对象的一生”、一个简化状态图缩略图标题居中缩略图占右半屏1分钟2为什么用状态图与流程图对比的结论、适用场景左右对比左侧流程图右侧状态图3分钟3状态与生命周期状态框、初始/终止伪状态、订单三状态小例顶部一行定义下方一张小图3分钟4事件与转换事件名、守卫条件、动作的书写语法中部放一个转换箭头三行标注4分钟5动作的三种时机entry/do/exit 定义中间一个状态框旁边三个标注3分钟6复合状态与并发大框嵌套子状态、虚线分区左右分栏左侧复合右侧并发4分钟7错误对照常见三种错误画法 vs 正确画法上下分栏上图错误下图正确4分钟8完整案例订单生命周期从创建到完成的主路径加异常分支全屏一张大图编号标注讲解顺序5分钟9验收清单用三个问题检查状态图表格或勾选列表1分钟排版参数方面几个关键数字建议直接固定下来。状态框用圆角矩形边框2.25磅填充色只用一种浅色不要每个状态一个颜色。转换箭头用实线宽度2.25磅事件标签用等宽字体中文用等线或微软雅黑加粗即可字号至少18磅保证投影后能看清。整页PPT同时出现的颜色不超过三种否则听众会把注意力放在区分颜色而不是理解转移关系上。有一个排版习惯特别值得提所有转换箭头的标签统一采用“事件 [守卫条件] / 动作”三行排版。事件名第一行守卫条件第二行并用方括号括起动作第三行以斜杠开头。这样做的好处是在讲到复杂案例时听众可以快速扫描每根箭头上发生了什么而不是在一行文字里找关键信息。页面右下角可以放一个小图例说明这个三行格式遇到复杂案例时听众会自己回看而不是反复打断你提问。3.3 用表格和对比替代大段文字状态转换表、事件表、责任分配表PPT正文里最忌讳成段文字。状态图本身就是图形语言再用大段文字解释图形听众会面临双重解码负担。我的做法是能用表格说清的关系不用段落能在图上标注的信息不放在正文。先说状态转换表。它的作用是把一张状态图压缩成表格方便听众在需求评审时逐行核对。表头建议设为当前状态、事件、守卫条件、目标状态、动作、备注。以下单场景为例PPT上只放前几行后两行放在备注里。讲解时按行读从当前状态出发因为发生了什么事件在什么条件下跳到哪个状态做什么动作。这个过程本身就是在讲状态图比指着箭头说“这条线”清晰得多。当前状态事件守卫条件目标状态动作备注待支付支付成功金额校验通过已支付创建支付凭证主路径待支付取消订单无已取消释放优惠券用户主动支付处理中支付超时超过3分钟待支付释放库存需要定时器再说事件表。它和状态转换表互补转换表以状态为行事件表以事件为行。表头为事件名、触发方、携带数据、影响的转换。比如“支付成功回调”由支付网关触发携带订单号和支付金额影响的转换是“待支付 - 已支付”。在涉及多个系统对接时事件表能帮助确认是否有遗漏的触发源。很多时候需求漏了“超时事件”就是因为只从状态出发看转换没有从事件反向排查。责任分配表用于多人协作的PPT场景。如果你不是一个人做这份PPT建一个责任表会少踩很多坑表格列出“元素页由谁维护、案例页由谁提供真实数据、错误对照页由谁评审”。这份表不放在观众版PPT里放在团队共享文档中。它虽然不直接提升讲解质量但能避免最后一天发现案例图和数据对不上。另外状态转换表还有一个额外作用当PPT上的图因为尺寸限制看不清某些箭头时表格可以作为备用的“文字版状态图”发给听众效果比发PDF还好。3.4 动画与步骤条控制讲解节奏的常用参数状态图PPT的动画不是为了炫技而是为了控制注意力。一张复杂的状态图如果一次性全部显示听众的眼神会在10秒钟内失去焦点。我的做法是把完整案例图拆成“当前状态 - 事件标签 - 转换箭头 - 目标状态 - 动作”五个层次按讲解顺序逐个出现。具体的动画参数是所有元素统一使用“出现”效果不用飞入、旋转或弹跳持续时间设置为0.5秒触发方式为“单击鼠标”而不是自动触发。为什么不用飞入因为飞入会让听众先注意动画轨迹而不是注意事件名和状态切换之间的关系。在技术分享里动画越接近于“无感”越合适。这个参数我几乎从不变更它经过多次现场验证最能维持讲解节奏。设置方法以微软PPT为例先选中转换箭头和它的事件标签在动画窗格里添加“出现”然后在效果选项里把持续时间改成0.5秒再在“开始”里选择“单击鼠标”。如果一个转换要拆成三步讲解就把“事件标签”、“箭头”、“动作文字”分成三个动画对象按顺序排列。现场放映时每点一次鼠标只增加一个信息点听众的视线能一直跟着你的指示走而不是在图上来回寻找。另一个实用技巧是“步骤条”在完整案例页的顶部放一个最小化的生命周期条从左到右标出“创建 - 支付 - 发货 - 完成”用色块覆盖当前讲到的位置。随着动画推进覆盖块移动。这个步骤条不依赖复杂动画本质是在一组色块上切换填充色。它能让听众始终知道“现在讲到生命周期哪个阶段”尤其适合30分钟的长分享。如果某个案例有三条分支步骤条也可以做成三段进度每段对应一条分支讲哪个分支就把哪个分支的高亮色块点亮。4. 状态图 PPT 制作与讲解避坑5 个让现场翻车的常见问题这一章专门写踩坑记录。每一条都是我在真实评审现场见过、自己也犯过的毛病按“现象 - 原因 - 解决”的格式写。准备PPT时可以拿它当检查清单现场讲完也可以拿它复盘。下面五个问题按出现频率排序越靠前越常见。4.1 状态爆炸一页塞不下听众直接放弃现象一份订单模型PPT里把“已创建”“待支付”“支付中”“支付成功”“支付失败”“待发货”“发货中”“已发货”“已签收”“已关闭”全画成状态框再加上并发分支一页A4大小的画布挤了22个状态、38根箭头。台下的人只能看到一团线我指着某个箭头解释时听众的眼睛已经不知道跟到哪里了后面的内容基本白讲。原因没有做状态抽象把所有业务阶段都当成了状态。尤其“支付中”“发货中”这类带进行时的词被直觉地画成状态框但它们往往是动作区间不是稳定状态。状态图表达的是“对象在哪里停下来等待”而不是“系统正在做什么事情”。一旦把动作区间当成状态状态数量就会成倍膨胀PPT自然塞不下。解决做PPT前用状态清单先过滤一遍。凡是“如果系统突然断电恢复后需不需要重新处理”的对象特征可以用来判断稳定性需要恢复或重新开始说明它不是一个稳定的等待点。其次把“进行中”的语义拆成两种如果等待外部回调可以建立一个“处理中”状态但必须同时定义超时事件如果只是本地动作且在毫秒级完成就不要画成状态。最后如果状态仍然很多用复合状态把子流程收进一个大框例如把“支付相关”折叠成“支付处理”复合状态内部的细分子状态放到单独一页展开。自查时问一句这张图最少需要几个状态才能讲清需求答案通常比你画的一半还少。4.2 把状态画成步骤伪状态图让用例失真现象一张大图从左到右依次排列“登录 - 浏览商品 - 加入购物车 - 下单 - 支付 - 完成”每个环节都用圆角矩形表示箭头连接看起来像状态图实际是流程图。讲的时候听众提了一个问题“登录之后如果未付款这个会话停在哪个状态”全场安静因为图里根本没有这个概念。原因把功能步骤直接翻译成了状态节点。登录只是身份认证动作的结果“已登录”是状态但“登录”不是状态支付是动作“已支付”是状态但“支付”不是状态。伪状态图丢失了最重要的等待语义一旦需求里出现取消、超时、回退图就无法演进。任何需要表达异常分支的需求如果用这种伪状态图讲每加一个分支都要调整一次布局最后图就乱了。解决给每个节点做一个“能否停留”测试。能停留的保留为状态不能停留的改成动作文字放在转换箭头上。例如“登录”应该改成“匿名 - 已登录”转换事件是“认证通过”“下单”改成“浏览中 - 待支付”转换事件是“提交订单”。在PPT里专门保留一页“伪状态图 vs 真实状态图”对照让别人看到差异这能显著减少后续讨论里的概念争执。现场如果有人质疑你的图你直接问“这个节点能不能停下来等待”问题就解决了大半。4.3 事件命名混乱trigger 与 guard 混写在转换箭头上现象转换箭头上写“点击支付且金额大于0且不过期然后创建订单凭证”所有条件、触发和动作堆成一句话。台下不同人开始争论这个条件到底算入参还是算业务规则箭头代表的转换到底在什么时候执行场面从技术讲解变成了语义辩论PPT后面的内容根本没时间讲。原因讲者没有统一UML转换语法。标准写法是“事件 [守卫条件] / 动作”事件是外部触发守卫条件是布尔判断动作是转换后的副作用。不区分这三者状态图就退化成一段口语描述。尤其是守卫条件如果五个条件全写在事件名旁边听众根本分不清哪些是触发前提、哪些是动作结果讨论自然发散。解决在PPT第4页就立一个书写规范并在后续每一页箭头标签上执行“事件名”写在第一行守卫条件用方括号写在第二行动作以斜杠开头写在第三行。例如“支付回调 [订单金额校验通过] / 生成支付凭证”。如果守卫条件复杂可以在备注里写完整逻辑PPT上只保留几个关键条件。另一个习惯所有事件名统一用“动词结果”的短语比如“支付成功”而不是“支付完成回调”后者容易和动作混淆。复查时只看一条规则把箭头上的文字单独读一遍能否清楚说出“什么发生、什么条件、导致什么动作”读不通就重写。4.4 动画顺序与讲解顺序不一致放映节奏失控现象讲“待支付 - 已支付”这个转换时动画顺序是先让“已支付”状态框出现再让事件标签出现最后让箭头出现。结果放映现场听众先看到目标状态注意力马上跳到结果等再讲事件时已经有人开始追问“那超时呢”节奏全乱。这种问题在正式评审前很难发现只有讲的时候才能意识到典型的“PPT没有彩排”。原因动画默认按元素添加顺序播放而不是按叙述逻辑。我添加动画时习惯性地先选中目标状态框后选中事件标签导致放映顺序和讲解倒挂。状态图讲解的核心是“当前状态 事件 - 转换 - 目标状态”动画顺序必须复刻这个因果链。如果你让结果先出现听众会自动脑补原因你后补的解释在他们听来都是多余的。解决做动画前先画一条讲解顺序列表比如1 显示当前状态“待支付”并默认可见2 显示事件标签“支付成功”3 显示守卫条件“金额校验通过”4 显示转换箭头5 显示目标状态“已支付”6 显示动作“创建凭证”。然后按这个序号在动画窗格里重新排序。技巧是所有状态框先设为“无动画”并默认显示只有事件、箭头、动作文字使用“出现”动画。这样画面一开始就展示两个状态框和一条虚线占位讲解时依次填入触发条件听众不会丢失上下文。每次彩排时我至少完整放映一遍只听自己口头讲的顺序和动画顺序是否一致。4.5 复合状态和并发区域讲不清直接跳过反而更糟现象PPT提到某个订单状态图里有“履约中”复合状态但只在页面上画了一个大框内部没有任何子状态。讲到后面一个大分支里的“物流已签收”和另一个分支里的“退款完成”之间到底什么关系台下完全无法判断。最后只能含糊带过听众感觉这页就是不重要的边角料。还有更常见的情况把并发区域画成两个普通分支没有双虚线听众问“这两个分支是不是二选一”讲者自己也答不上来。原因复合状态的价值在于封装内部应该是一张完整的子状态图。只画一个大框等于告诉听众“这里有一堆东西但我不讲”反而比不画更引发好奇心。并发区域更麻烦如果不画双虚线听众会把两条分支理解成二选一。复合状态和并发是状态图相对进阶的内容但既然标题写的是“详细介绍PPT”就不该回避。回避会让整份PPT的深度出现断层听众会觉得前面的认真都是偶然。解决复合状态单独设置一页用“嵌套展开”的方式讲先在总图上看到一个大框然后点击动画展开内部子状态图。内部至少包含两个稳定状态和相应事件。并发区域一定要画双虚线并在图上标注“两个区域同时运行互不阻塞”。如果页数确实紧张宁可不把复合状态放进案例图也不画一个空壳。可以在收尾的验收清单里留一句话“复合状态内部必须展开过”用来提醒自己不要偷懒。讲并发时我通常举一个“同时记录日志和扣减库存”的例子强调两个区域不需要同步各自有各自的初始状态和终止状态。5. 让这份状态图 PPT 真正被用起来一页验收清单和讲法技巧做一份状态图PPT不难难的是讲完之后听众真的能自己画。我的收尾习惯是在最后放一页验收清单而不是“谢谢观看”。清单只留三组问题。第一组图里每个节点都能停住吗第二组每个箭头都有事件名守卫条件和动作分开写了吗第三组复合状态打开过、并发区域画了双虚线吗这三条覆盖了80%的现场翻车点也适合评审前自查。讲法技巧方面有一个“两遍法”很管用。第一遍只讲主路径从初始状态出发沿一条正常成功路径走到终止状态不打断不展开分支。第二遍回过来讲分支和异常把“取消”“超时”“失败”作为事件补到对应状态上。这样做的好处是听众先建立了整体骨架再听细节不会迷路。很多讲者一上来就按箭头编号逐条念结果主路径和异常混在一起听众记住的只有最后一个状态前面的全忘了。还有一个关于动画的验证习惯把PPT导出成一张长图放在屏幕上缩小看。如果整张图上看不清某个箭头上的字就说明不是字号问题而是排版信息密度过高应该砍掉内容而不是放大字体。如果某一页的动画顺序和我的口头顺序对不上就重新排动画窗格。这个习惯救了我很多次尤其是评审前熬夜改图的时候它比任何理论都可靠。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
