简介围绕图书管理系统建模的UML实验4笔记面向正在学习状态图与活动图的软件工程或UML课程学生适合用来理解对象状态变化与业务流程建模。压缩包内为1个doc文档共233KB内容覆盖实验目的、操作分析与绘图步骤可直接用于实验参考或复习。已有5258人浏览学习。笔记详细说明了书和借书证的状态转换书可分为可借、被借、被预约、删除四种状态借书证分为可用、不可用、删除三种状态并给出了相应的状态图同时分析了管理员处理还书、处理借书、处理罚款三类活动绘制了活动图。结合Rose工具的新建状态图、活动图流程讲解能帮助学生独立完成同类UML实验并提升对UML规范的理解。1. 活动图和状态图到底差在哪从图书管理系统的借书场景说起“图书管理系统”几乎承包了UML课程实验的出镜率。实验4一般会同时要求画活动图和状态图很多同学的作业翻车就翻在同一个点两张图画完除了名字不一样结构几乎一模一样老师评语常是“状态图不是流程图”。这背后的核心是建模视角错位——活动图拍的是流程记录谁在什么顺序下做了什么状态图拍的是对象记录一件事物从创建到销毁经历了哪些状态又被什么事件推动。我按图书管理系统的借书、还书场景把这两张图的元素、画法、参数和坑讲透让交出去的实验4既站得住脚也经得起答辩追问。2. 活动图怎么画才像“活动图”借书流程的泳道、节点与工具选型2.1 活动图的元素与语义哪些节点必须用哪些可以省活动图在UML里叫 Activity Diagram它比传统流程图多出来的是泳道Partition、分叉与汇合Fork/Join、对象流等表达能力。图书管理系统这种业务场景用不到那么多高级元素。我一般画系统流程只用这几样开始节点、活动节点、决策节点、合并节点、结束节点再加一组泳道。活动图一旦过载老师看着累自己也难维护。后台用什么语言实现图书管理系统其实不影响建模——不论 Java、PHP 还是 PythonUML 关心的是逻辑和责任划分不是 API。大家搜“uml类图怎么画”时能找到一堆方法但活动图和状态图的资料总是停留在概念层面。这里直接把元素表给出来画图时对照着选就行。元素UML 符号在借书场景中的用途必用程度开始节点实心圆读者发起借书申请必用活动节点圆角矩形验证读者身份、登记借阅记录必用决策/合并菱形读者信用是否正常、副本是否在馆按分支分叉/汇合粗横线借书成功后同时生成记录和更新库存可选泳道分区矩形区分读者 / 管理员 / 系统强烈建议结束节点牛眼流程结束必用泳道是活动图和传统流程图最大的差异练习目标是习惯“任务第一眼就找到责任人”。借书流程里读者负责提交申请管理员负责核对与办理系统负责校验状态和更新数据——谁执行动作活动节点就要落在谁的泳道里。这一步错了后面分支画得再规范也白搭。2.2 从用例到活动图借书流程的四步拆解第一步找用例文本里的基本流和备选流。借书用例的基本流一般是读者提交借书申请 → 管理员核对读者身份 → 系统检查图书状态 → 登记借出 → 更新库存。备选流包括读者信用异常时拒绝借出、图书不在馆时提示可预约。第二步定泳道。图书管理系统我一般画三条泳道读者、图书管理员、图书管理系统。原则很简单谁执行动作活动节点就落在谁的泳道。读者能做“提交借书申请”不能直接“更新库存”管理员能做“办理借出登记”不能替系统“生成借阅记录”。第三步画主干。把基本流按顺序连起来决策节点放在分支出现的位置。菱形后面一定要用分支标签说明条件例如 [信用正常] 和 [信用异常]不然读图的人只能猜。活动节点命名用“动词宾语”比如“核对读者身份”“更新副本状态”而不是“核对”“处理”这种半截话。第四步补备选流和并发。如果实验要求体现并发借出成功后“生成借阅记录”和“更新副本状态为已借出”可以放在分叉/汇合之间。备选流不要无节制地加实验报告里把信用异常和图书不在馆两个分支画清楚就够体现建模能力了。这四步看起来简单但大多数人漏在第2步不相信“系统校验身份”本身是一个活动节点。系统不是背景板它是一个正式的参与者。2.3 工具落地PlantUML 起草PowerDesigner 出图别把时间耗在鼠标上画活动图的常见做法是先用文本工具快速起草再画正式图。PlantUML 能把流程写成纯文本随时可以对比版本这是草稿阶段的利器。下面这段借书流程脚本拷贝到 PlantUML 环境就能导出图片。startuml |读者| start :提交借书申请; |图书管理员| :核对读者身份; if (读者信用状态?) then (正常) :办理借出登记; else (异常) :拒绝借出; stop endif |图书管理系统| :检查图书副本状态; if (副本状态?) then (在馆) :生成借阅记录; :更新副本状态为已借出; :减少可借库存; else (不在馆) :提示可预约; stop endif stop enduml逻辑说明|读者|这样的行创建泳道分区:提交借书申请;是一个活动节点if...then...else...endif生成决策与合并start和stop对应开始与结束节点。整个脚本按“外部角色 → 内部系统”的泳道顺序展开读图顺序和业务发生顺序一致。参数说明决策条件的写法整张图要统一我习惯用问句“读者信用状态?”活动节点命名统一为“动词宾语”。这里要特别注意活动图的决策条件在状态图里会被换掉——状态图用的是守卫条件写在事件后面的括号里不是画成菱形这两个参数口径完全不同。工具适合阶段画状态图支持交付格式PlantUML文本草稿支持 State DiagramPNG / SVGStarUML中等规模图支持状态机图PNG / JPGPowerDesigner正式交付支持 Statechart DiagramPDF / 图片draw.io在线协作支持PNG / SVG / PDFPowerDesigner 画状态图时新建模型选 Statechart Diagram它的状态框体和迁移线样式接近 UML 标准放进实验报告很合适。不必把工具当黑匣子先学会用一种文本方式把逻辑写明白再用图形工具调样式效率高得多。3. 状态图怎么画才不“跑题”以一本书的生命周期为例3.1 状态机图的第一性一张图只有一个主语对象状态图的正式名称叫状态机图State Machine Diagram国内教材和实验文档习惯叫状态图。它描述的是单个对象在不同状态下受事件驱动发生迁移的过程。所以状态图的主语只能有一个。图书管理系统中我推荐拿“图书副本物理册”当主语而不是读者或管理员。原因是副本对象的状态最丰富在馆、已借出、已预约、维修中、注销。读者虽然也有状态但生命周期相对简单画出来单薄撑不起一张完整的实验图。很多翻车现场就是把主语写成“图书馆系统”最后画成了活动图。状态图的元素表比活动图精简但它对语义的精确度要求更高。元素符号含义初始伪状态实心圆对象生命周期的起点状态圆角矩形对象等待事件的一段时期迁移带箭头直线状态变化线上标注事件(守卫)/动作终止状态实心圆加外圈对象生命周期结束状态是“等待事件的一段时期”不是“正在执行的一段工作”。理解这句话状态图就不会画成流程图。“借出”是事件不是状态书被借走后进入的状态叫“已借出”。这个区别很细但实验报告里写得越准越耐看。3.2 图书副本的状态机从状态表到迁移线落地步骤分四步。第一步列候选状态在馆、已借出、已预约、维修中、注销。第二步列触发事件借出、归还、预约、取消预约、报损、修复完成、报废。第三步画迁移表把状态和事件组合起来。第四步把迁移表转成状态图。迁移表是状态图的核心画图前先把表填好能避免连错线。当前状态触发事件守卫条件下一状态动作在馆借出读者信用正常已借出登记借阅、更新库存在馆预约读者无未还书已预约生成预约单已预约取消预约无在馆清除预约单已预约借出预约读者本人已借出登记借阅已借出归还无损坏且无逾期费用在馆更新库存已借出报损损坏确认维修中生成维修单维修中修复完成复检合格在馆重新上架维修中报废审批无法修复注销下架注意表里没有“逾期”这个状态。逾期是借阅记录的一个属性不是图书副本的一个新状态。正确的做法是把相关条件写到归还事件的守卫条件里例如“归还(逾期费用已缴清)”。如果实验要求细化单独加一个“逾期”状态也不难但要补上“逾期→还书→在馆”和“逾期→催还”的迁移工作量会大不少。把迁移表转成状态图脚本在 PlantUML 里是这样写的。startuml [*] -- 在馆 : 采购编目完成 在馆 -- 已借出 : 借出(读者信用正常)/登记借阅记录 在馆 -- 已预约 : 预约(无未还书)/生成预约单 已预约 -- 在馆 : 取消预约/清除预约单 已预约 -- 已借出 : 借出(预约读者本人)/登记借阅 已借出 -- 在馆 : 归还(无损坏且无逾期费)/更新库存 已借出 -- 维修中 : 报损(损坏确认)/生成维修单 维修中 -- 在馆 : 修复完成(复检合格)/重新上架 维修中 -- 注销 : 报废审批(无法修复)/下架 enduml逻辑说明[*]表示初始伪状态--连接状态冒号前面是触发事件括号里是守卫条件斜杠后是进入下一状态时执行的动作。这些写在迁移线上的信息就是状态图区别于活动图的“证据”。参数说明状态命名用名词性短语“在馆”“已借出”别用动宾短语“办理借出”。迁移线命名格式固定为“事件(守卫)/动作”三者都可以视情况缺省但事件不能长期缺失。守卫条件必须放在括号里不要画成菱形判断那是活动图的表达方式。3.3 状态图和活动图的边界三个判断标准判断标准一主语是否唯一。状态图从头到尾只讲一个对象的故事活动图允许多个角色协作。判断标准二边代表什么。活动图的边是控制流表达先后顺序状态图的边必须有事件驱动。判断标准三节点是“期间”还是“动作”。状态是等待事件的一段时期活动是正在执行的工作。如果实验室还要求画类图、组件图或构件图记住每种图只回答一个问题类图回答结构组件图回答部署模块活动图回答流程状态图回答生命周期。把一类图的画法套到另一类图上是实验报告被打回的最常见原因。4. 活动图和状态图的5个踩坑现场现象、原因、解决这一章是实验4上交前最值得读的一章。每个坑都是真实交作业时被老师评语锤过的典型按“现象→原因→解决”写清楚。4.1 思路坑活动图和状态图撞脸泳道乱分现象两张图长得一样。活动图里出现“在馆”“已借出”节点状态图里出现“验证读者身份”节点或者活动图把读者画进系统里直接修改数据库。原因没有先问“这张图的主语是谁”。活动图的叙事主语可以是多个角色状态图的叙事主语只能是一个对象。把流程节点当状态把状态当流程节点本质是把两种视角混在一起。解决画图前先写一句图题。“本活动图描述借书流程参与者为读者、管理员、系统”“本状态图描述图书副本的生命周期”。主语答案不同用哪张图就清楚了。现象活动图里“系统更新库存”画在管理员泳道读者操作直接连到数据库。原因泳道是责任分配不是装饰框。把系统动作塞给管理员等于没做职责边界。解决先画系统边界再填泳道。读者触发“提交申请”系统执行“校验身份”“更新库存”管理员只做线下核对和办理。边界画清楚泳道自然就对了。4.2 表达坑状态迁移线裸奔命名口语化现象状态图里两个状态之间的箭头没有写任何文字活动图里活动节点叫“处理中”“搞一下”。原因把状态图当成了带圆角矩形的流程图。状态迁移必须有触发事件否则审图人不知道对象凭什么从一个状态跳到另一个状态。活动节点命名则缺少“动词宾语”的规范。解决给状态图每条迁移线补上“事件(守卫)/动作”例如“归还(无损坏且无逾期费)/更新库存”。活动节点改成“验证读者身份”“更新副本状态”。命名本身就是建模语言图和文字不一致答辩被追问时很难圆场。现象活动图的决策条件写成“判断读者信用”放在活动节点里而不是放在菱形分支上。原因混淆了“动作”和“判断”。判断是一种路由不是一项工作。解决所有分支判断都用菱形表达条件写在分支标签上。信用异常和信用正常是两个出口不是两个活动节点。4.3 完整性坑初始状态、终止状态和局部图边界现象活动图没有开始节点直接从“读者提交申请”开始状态图没有初始状态也没有说明从哪里进入。原因画局部图时忘了模型需要表达入口和出口。实验里经常只画“借阅生命周期”这一截但不标注起点审图人就不知道前面的状态是什么。解决活动图补start状态图可以用初始伪状态[*]也可以在图下方注释“本图展示图书副本从在馆到注销的生命周期采购编目完成后进入在馆”。加上这句注释老师就知道你不是漏画而是有意截取局部。5. 画完怎么验证场景走查、完整性检查和软考UML题的通用套路5.1 场景走查用一条借书用例把两张图串起来拿一个具体场景读者张三在柜台借《三体II》的副本 B。按活动图走一遍张三提交申请 → 管理员核对 → 系统检查副本 B 状态 → 登记借出 → 更新库存。再按状态图走一遍副本 B 从“在馆”经事件“借出(读者信用正常)”迁到“已借出”。如果活动图里“系统检查副本状态”的结果是在馆而状态图里副本 B 还停在“维修中”那就说明模型和现实对不上。这个双向走查是我最常用的验证方法不用靠猜拿具体场景走一遍就知道哪里断了。验证时还要看事件来源。活动图里的“系统检查副本状态”对应状态图里的守卫条件“读者信用正常”和当前状态“在馆”。两张图对同一个业务事实的描述必须一致否则答辩时老师一问就露馅。5.2 完整性三查状态可达、事件有源、活动有归属第一查状态可达每个状态至少有一条进入路径和一条离开路径终止状态除外。第二查事件有源每条状态迁移线都写事件守卫条件在括号内。第三查活动有归属活动图每个活动节点都落在某个泳道内每个分支最终都汇合。检查“不可达状态”时列状态表逐行查最靠谱。“已预约”状态如果没有“取消预约”或“借出”出口图书就永远卡在预约状态这种细节靠肉眼容易漏。活动图也一样分支如果只分不合并流程就断头了。检查完还有一个收尾动作数状态图的状态数和活动图的活动数是否和用例文本对得上。用例里有“归还时检查损坏情况”状态图里就有“归还”事件加“无损坏且无逾期费”守卫。用例文字覆盖不全的要么补图要么在说明里标注“本图只覆盖主流程”。5.3 软考与期末UML题的读题顺序主语、动词、条件软考下午题和期末试题里UML图补全题通常给一段业务描述。读题顺序很重要。第一步圈主语。题干连用“读者”“管理员”“系统”作主语多半是活动图描述“当图书状态为在馆时执行借出操作后状态变为已借出”多半是状态图。第二步圈动词。动词一般是事件“借出”“归还”“取消”“报损”。把它们对应到迁移线的事件位置。第三步找条件。带“如果”“当…时”“若未…”的文字是守卫条件写入迁移线的括号里。题干关键词UML 位置参与者做某事活动图泳道 / 活动节点状态从 A 变到 B状态图迁移当某条件成立活动图决策条件或状态图守卫条件同时执行活动图分叉 / 汇合对象进入某状态状态图状态节点这个映射表考前看一遍比背十张示例图都管用。软考 Uml图试题和期末考题的考点并不复杂考的就是你是否分得清控制流和事件流。6. 把实验4的图交成“可交付物”图注、矢量导出与三行说明6.1 图注、图幅和导出格式让老师不用放大镜实验报告里最常见的观感问题是截图背景发黑、线条模糊。我交 .doc 前的习惯是图都用矢量导出SVG 或 PDF 再插入 Word图宽统一设为 14 到 15 厘米居中对齐图注格式“图4-1 图书借阅活动图”放图下方居中。图注和图要绑定不要出现“如下图所示”却没编号的情况。检查项标准图幅宽度 14~15cm居中格式矢量导出禁用模糊位图图注图4-x 说明性名称泳道标题每列顶部标注角色名状态命名名词短语无动词6.2 图下三行说明给老师省时间给自己留退路每张图下方加三到五行文字说明。活动图写“本图描述借书主流程参与角色为读者、管理员、系统信用异常与副本不在馆作为分支处理”。状态图写“本图以图书副本为对象展示在馆、已借出、已预约、维修中、注销五个状态及其迁移事件”。这段文字一方面让老师确认你没画错另一方面答辩时照着说就能讲清楚。以前我也直接把 PNG 丢进 Word结果老师把图放大到模糊还反光。后来改成矢量导出加图下说明实验4一次过。这个习惯到现在还在用先写一句图题再画图最后补说明顺序三步走完再提交。希望这种建模习惯能帮你的实验4少一点返工、多一点底气希望帮到你。本文还有配套的精品资源点击获取