企业官网建设流程全解析

简介：围绕图书管理系统建模的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 还是 Python，UML 关心的是逻辑和责任划分，不是 API。大家搜“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对应开始与结束节点。整个脚本按“外部角色 → 内部系统”的泳道顺序展开，读图顺序和业务发生顺序一致。

参数说明：决策条件的写法整张图要统一，我习惯用问句“读者信用状态?”；活动节点命名统一为“动词+宾语”。这里要特别注意，活动图的决策条件在状态图里会被换掉——状态图用的是守卫条件，写在事件后面的括号里，不是画成菱形，这两个参数口径完全不同。

PowerDesigner 画状态图时，新建模型选 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图试题和期末考题的考点并不复杂，考的就是你是否分得清控制流和事件流。

6. 把实验4的图交成“可交付物”：图注、矢量导出与三行说明

6.1 图注、图幅和导出格式：让老师不用放大镜

实验报告里最常见的观感问题是截图背景发黑、线条模糊。我交 .doc 前的习惯是：图都用矢量导出，SVG 或 PDF 再插入 Word；图宽统一设为 14 到 15 厘米，居中对齐；图注格式“图4-1 图书借阅活动图”，放图下方居中。图注和图要绑定，不要出现“如下图所示”却没编号的情况。

6.2 图下三行说明：给老师省时间，给自己留退路

每张图下方加三到五行文字说明。活动图写“本图描述借书主流程，参与角色为读者、管理员、系统；信用异常与副本不在馆作为分支处理”。状态图写“本图以图书副本为对象，展示在馆、已借出、已预约、维修中、注销五个状态及其迁移事件”。这段文字一方面让老师确认你没画错，另一方面答辩时照着说就能讲清楚。

以前我也直接把 PNG 丢进 Word，结果老师把图放大到模糊还反光。后来改成矢量导出加图下说明，实验4一次过。这个习惯到现在还在用：先写一句图题，再画图，最后补说明，顺序三步走完再提交。希望这种建模习惯能帮你的实验4少一点返工、多一点底气，希望帮到你。

本文还有配套的精品资源，点击获取