简介这份UML实验资料围绕图书管理系统的状态图与活动图展开适合高校软件工程、信息系统等专业学生完成相关课程实验或复习建模知识时使用。内容从实验目的、实验内容到具体绘图步骤均有清晰梳理重点讲解书及借书证的状态划分包括可借、被借、被预约、删除以及可用、不可用、删除等状态并给出相应状态图同时分析管理员处理还书、处理借书、处理罚款三类活动绘制对应的活动图。包内共1个doc文档整体大小233KB便于直接查阅和参考绘图思路。资源还介绍了使用Rose建模工具进行状态图和活动图绘制的基本流程适合希望快速掌握UML动态建模方法的学习者对照练习。已有5256人浏览学习说明该资料在同类实验指导中有一定参考价值可帮助读者理解状态转换关系与活动流程表达方式提升UML建模实操能力。1. 动态建模为什么实验 4 偏偏落在活动图与状态图上很多人在 UML 实验课上都会有这样一个疑问类图、用例图还没画利索怎么就直接跳到活动图和状态图了等真动手做“图书管理系统”这个题目时才发现前面几张图解决的是“系统有哪些对象、谁来用”而活动图和状态图解决的是“系统到底怎么动、对象在不同时刻处于什么状态”。这是从静态结构走向动态行为的关键一步也是实验 4 放在这个位置的原因。图书管理系统作为教学案例业务边界清晰——借书、还书、预约、续借、读者管理、图书管理——每个业务流程都有明确的分支和并发场景非常适合用活动图表达而图书自身从“在架”到“借出”再到“预约保留”的流转又天然对应状态图的建模语言。这篇文章就按实验报告的实际推进顺序来讲活动图怎么画才不像流程图、状态图怎么画才不变成另一个活动图、两个图怎么协同覆盖系统的动态视图。2. 活动图怎么画才能讲到“借书”的心坎里活动图画的是“用例内部的控制流”它回答的问题是完成一件事步骤有哪些、谁负责、哪些步骤可以同时做、异常情况怎么走。图书管理系统的活动图通常围绕核心用例展开而不是把整个系统画进一张图。常见做法是一个用例一张活动图或者把借书、还书、预约各画成独立的图。2.1 用泳道划分职责而不是画一张“万能流程图”初画活动图最容易犯的错是把所有动作堆在一张图里让读者分不清哪个步骤是读者做的、哪个是系统自动完成的。泳道Swimlane就是用来解决这个问题的横向或纵向划分区域每个区域对应一个参与者或子系统。以“借书”为例一个标准的活动图结构大致是读者 → 提交借书请求 → 系统校验读者身份 → 校验借书额度 → 查询图书状态 ↓ 可借 登记借阅记录 → 更新图书状态 → 完成 ↓ 不可借 返回失败原因在这个流程里泳道分为两条读者、系统。后续加入图书管理员时再加第三条泳道。不要把读者、管理员、系统的所有动作全部塞进同一个泳道那样等于没分。2.1.1 活动图的节点类型别只认识“圆角矩形”活动图里有几个基础元素是必须用对的元素表示作用初始节点实心圆流程的起点一张图只能有一个活动节点圆角矩形执行的具体动作或任务决策节点菱形分支判断通常配合 guard condition监护条件合并节点菱形把多条分支汇聚到一起分叉/汇合粗横线表示并发开始和结束终止节点牛眼形流程的终点可以有多个有些教材把决策和合并都画成菱形区别在于决策节点有一条进入边、多条出边合并节点有多条进入边、一条出边。如果在借书流程中要表达“系统校验读者身份的同时也在查询图书库存”就用分叉横线把两个动作并行展开后面再用汇合横线收拢。2.2 从业务流程里提取活动图的“骨架”拿到“图书管理系统”这个题目时不要急着打开工具画图。我一般先用纯文本把用例的主流程、分支流程和异常流程列出来这个习惯能省下大量修改时间。借书用例的文本描述大概是主流程 1. 读者提交借书请求 2. 系统验证读者身份读者证有效、未挂失 3. 系统检查该读者的借阅数量是否已达上限 4. 系统检查图书状态是否为“可借” 5. 创建借阅记录设置应还日期 6. 图书状态改为“已借出” 7. 返回借书成功信息 分支 3a. 借阅数量已达上限 → 提示“借阅数量已达上限” 4a. 图书状态为“已借出”或“预约保留” → 提示“图书不可借” 2a. 读者证挂失或过期 → 提示“读者证异常”这份文本描述转化为活动图时主流程顺势而下分支通过决策节点展开。注意活动图的初始节点和终止节点不能省这是评分时最容易被挑的毛病。2.2.1 借书活动图的三个“必须画对”的参数点第一决策节点的监护条件要写在分支线上而不是写在菱形里面。第二分叉和汇合必须成对出现有分叉没汇合是常见错误。第三异常分支要画完整不要只画主流程然后直接落到终止节点。一个容易忽略的细节如果“查询读者额度”和“查询图书状态”两个动作没有依赖关系可以放在分叉之后并发执行等两者都完成后再合并进入下一步。这既符合业务语义也在图上展示了活动图区别于流程图的价值——支持并发建模。评审问为什么这样画的时候回答“这两个查询相互独立并发可以减少总耗时”就很扎实。3. 状态图怎么画才能体现“状态”而不是“流程”状态图描述的是“单个对象在其生命周期内因事件触发而产生的状态变化”。关键词是“单个对象”和“事件”。图书管理系统中最有建模价值的是“图书”这个对象其次是“借阅记录”和“读者证”。如果把“读者借书”的完整过程画成状态图那就又把状态图画回活动图了——这是实验 4 里最典型的认知偏差。3.1 图书对象的状态识别从业务规则里找状态要画图书的状态图先想清楚图书有哪些稳定状态。这里的“稳定”指的是对象在某个状态下会停留一段时间等待事件触发。图书的状态大致有在架Available→ 已借出Borrowed→ 预约保留Reserved→ 下架Discarded图书管理系统的状态图通常以“图书”为核心把状态迁移用事件串起来。借书动作触发“在架→已借出”还书动作触发“已借出→在架”如果还书时该书已被其他读者预约则不回到“在架”而是进入“预约保留”预约的读者取走书后“预约保留→已借出”管理员下架则触发到“下架”状态。3.1.1 一张图书状态图的节点与事件表当前状态触发事件后续状态说明在架读者借书借书事件已借出需验证读者资格已借出读者还书还书事件在架无预约时已借出其他读者预约预约事件已借出状态不变但产生预约记录已借出读者还书还书事件预约保留有预约时预约保留预约者取书借书事件已借出完成借阅预约保留预约取消取消事件在架恢复可借在架管理员下架下架事件下架图书淘汰这张表就是状态图的文本原型。画图时每个方框是一个状态箭头是迁移箭头上的文字是触发事件。状态图的方框分两个区域上面写状态名下面可以写状态内部的活动——进入动作entry、退出动作exit、状态内持续活动do。3.2 状态图里的三种“内部活动”怎么写才不虚状态图比活动图多了一个东西状态内部的“动作”。同样是“已借出”状态可以标注“entry / 发送借出通知”“do / 计时借阅期限”“exit / 计算逾期费用”。这样画出来的状态图能直接指导类图中的方法设计——状态图里的 action 往往会对应到类的方法上。“预约保留”状态值得一提。它是从“已借出”迁移过来的产生原因在于业务规则还书时若有预约不直接回到“在架”。这个状态如果漏画实验的完整度会受很大影响。同时“预约保留”还应该有超时处理——有的系统规定预约书保留 3 天3 天未取自动回到“在架”这个时间约束写在迁移的 guard 条件里而不是单独画一个状态。4. 活动图与状态图的协同用一件事串起两条线活动图和状态图不是各自为政的。实验 4 要求两个图都交说明需要展示的是同一系统的两个不同切片活动图展示流程的全貌状态图展示单个对象的状态变迁。又以“借书”这件事来说活动图的动作每一次执行都会推动图书状态图发生一次迁移。4.1 活动图中的一个动作状态图中的一个事件在借书活动图中“登记借阅记录”这个动作执行后“更新图书状态”这个动作把图书的状态从“在架”改成“已借出”。换到状态图的视角“借书”这个事件触发了从“在架”到“已借出”的迁移。两条线在同一业务语义上汇合。还书流程同样是这个道理。活动图里的“还书登记”动作对应状态图里从“已借出”到“在架”或“预约保留”的迁移。区别在于活动图必须通过决策节点判断“是否有预约”来决定分支走向状态图则是在迁移的监护条件里写清楚“归还时无预约”或“归还时有预约”。4.2 两个图的生命周期视角差异评审最爱问一个比较常见的课堂提问是为什么不在活动图里展示图书从“在架”到“预约保留”的状态变化答案在于视角层次不同。活动图展示的是“一次借书过程”的控制流它关心的是这次操作走哪条路径、能不能成功状态图展示的是“图书这个对象”在系统运行期间所有可能经历的状态时间跨度是对象的整个生命周期。活动图是分析一次交互状态图是分析对象的一生。评审如果追问“预约活动中图书状态怎么变化”可以在活动图中加入“预约处理”子流程然后说明“这里对图书产生了一个预约事件”具体迁移交给状态图去表达。这样回答既展示理解了两种图的分工又避免把活动图画成一个大杂烩。5. 实验报告/文档中这两个图该怎么“写”出来实验 4 的交付物是 .doc 文档这意味着除了图本身还要配文字说明。很多实验报告的问题是图占半页、文字只有三行。要在文档中把图示完整表达通常还需要“文字版描述”作辅助——这在需要用文本工具画图的场景下尤其关键。5.1 活动图的文字描述模板借书活动的文字描述可以这样组织活动名称借书 参与者读者、图书管理系统 前置条件读者已注册图书在系统中存在 主流程 1. 读者提交借书请求 2. 系统校验读者状态 3. 系统检查借阅额度 4. 系统检查图书状态 5. 系统创建借阅记录 6. 系统更新图书状态为“已借出” 后置条件读者领取图书借阅记录生效这个模板的好处是评审能对照着文字到图里去核对每一步是否画全。活动图往往画得越细越好但文字描述只需覆盖关键动作不需要把每个 guard 条件都写进去。5.2 状态图的文字描述模板状态图部分建议画一个状态迁移表然后配合图输出。还是以图书状态为例状态图对象图书 初始状态在架 迁移列表 1. 在架 → 已借出事件借出条件读者有效 2. 已借出 → 在架事件归还条件无预约 3. 已借出 → 预约保留事件归还条件有预约 4. 预约保留 → 已借出事件预约者借出 终态下架这部分文字的价值在于一旦状态迁移表写清楚画状态图就变成了“翻译”工作不需要临时考虑状态从哪里来、到哪里去。6. 用 PlantUML 把两个图沉淀为可复用的资产到了进阶阶段可以尝试用 PlantUML 把图用代码管理起来。用 PlantUML 不只是为了“画图方便”更关键的是“评审多轮修改时改文字重新生成图比手动挪框高效太多”。startuml |读者| start :提交借书请求; |系统| :验证读者身份; if (身份有效?) then (是) :检查借阅数量; if (额度足够?) then (是) :检查图书状态; if (可借?) then (是) :创建借阅记录; :更新图书状态; :返回借书成功; stop else (否) :返回“图书不可借”; stop endif else (否) :返回“借阅数量已达上限”; stop endif else (否) :返回“读者证异常”; stop endif enduml这段 PlantUML 代码是对“借书”活动图的可执行描述。直接贴到 PlantUML 线上编辑器或 VS Code 的 PlantUML 插件里就能出图。代码有几点可以微调|读者|和|系统|声明泳道“停止”节点可以在分支里出现多次对应 2.1“一张图可以有多个终止节点”的说法。状态图同样可以用 PlantUML 描述startuml [*] -- 在架 在架 -- 已借出 : 借出 在架 -- 下架 : 管理员下架 已借出 -- 在架 : 归还(无预约) 已借出 -- 预约保留 : 归还(有预约) 预约保留 -- 已借出 : 预约者借出 预约保留 -- 在架 : 预约取消 下架 -- [*] enduml两步操作就能让“文本化”变成日常习惯把 .doc 里的图对应一份 PlantUML 源码保存为.puml文件跟着实验报告一起归档。评审或老师提出问题直接改源码重新渲染不用在绘图工具里反复对齐坐标轴。用惯了 Graphviz 的话也可以用 DOT 语言做同样的事情但实验报告这一步PlantUML 的语法更贴近 UML 语义少踩样式细节的坑。最后一个建议文档定稿前把状态图里的每个状态名跟活动图里的每个动作核对一遍。活动图里出现的“更新图书状态”必须能在状态图里找到对应的事件和迁移——两张图对不上比画得糙更容易失分。本文还有配套的精品资源点击获取