企业官网建设流程全解析

简介：《UML建模——图书管理系统需求分析报告》是一份面向软件工程课程设计、UML建模入门与需求分析练习的文档型资料，适合需要完成图书管理系统建模作业或参考报告写法的学生与自学者。文档围绕借书者、图书管理员、系统管理员三类角色展开，依次给出需求分析描述、用例模型、类图静态模型、顺序图等动态模型，以及构件图与部署图实现模型，并提及Rational Rose 2003生成VB代码框架的思路。压缩包共1个doc文件，约265KB，篇幅集中、结构完整，便于直接查阅和改写。目前已有2497人学习。读者可从中获得一套较完整的UML建模流程范例，理解角色划分、用例识别、类与关系设计、对象交互表达及实现模型组织方式，也能参考出版社信息、客户信息、库存管理与图书销售统计等功能模块的描述，用于课程报告撰写、答辩准备和建模思路梳理。

1. 一份被退回两次的需求分析报告：UML 建模到底该先画哪张图

某高校图书馆要换掉跑了十年的借还系统，需求分析报告写了四十多页，把“借书、还书、续借、预约、罚金”逐条列成章节。评审会上三个问题就把报告问停了：一个人最多同时借几本？逾期罚金按自然日还是开馆日算？预约到书后几天不取算放弃？报告里全没有。问题不在于文笔，而在于这份需求分析报告从头到尾是自然语言堆出来的，没有一处能做逻辑校验。

UML 建模在这里的价值，是把业务话术翻译成能被逐条追问的结构：用例说清谁在什么条件下做什么，活动图和顺序图钉住时序与异常分支，类图和状态机划出数据边界与合法迁移。它不适合那种“需求方说一句、开发写一句”的小改动，但凡涉及三方（业务、开发、测试）对不齐口径的图书管理系统，这套图就是验收时的底稿。

2. 用例视图先立骨架：图书管理系统里 4 类参与者与 12 个用例怎么切

需求分析报告最容易写崩的地方，是一上来就写功能列表。“图书管理”“读者管理”“借阅管理”这种词看着齐全，实际上谁都能往里塞东西，评审时无法判断做没做完。用例视图的作用是先固定边界：谁站在系统外面，他想达成什么目标，系统承诺响应什么事件。这一步做扎实，后面的活动图、顺序图、类图才有唯一的分母。

2.1 参与者不一定是人：把外部系统也算进边界外

新手画用例图，参与者全是小人图标，这是最常见的窄化。图书管理系统里至少有四类参与者，其中两类根本不是人。

第一类是借阅者。这里有个必须处理的细节：学生和教职工的借阅额度、借期往往不同。做法是把“借阅者”作为抽象父类，学生和教职工泛化继承它，额度差异写在业务规则里，而不是画两个几乎一样的用例。如果团队对 UML 泛化不熟，退化方案是用一个参与者加一个“读者类型”属性，但要在规约里注明额度按类型取值。

第二类是馆员，负责前台代办（代借、代还、处理争议）、预约到书确认。第三类是采访编目人员，本次范围如果只做流通，就把他画在系统边界外，不列用例。第四类是外部系统：统一身份认证、财务结算、消息通知渠道。它们不是人，但确实会主动或被动地与系统交互，必须画进来，否则接口需求会在设计阶段凭空冒出来。

边界的画法直接决定工作量。我一般会在一张表里把参与者、目标、触发频率、是否本次范围内四列写全，评审时逐行过。

这张表的价值在于，“采访编目不在范围内”这句话必须在报告里显式出现。不写，评审时一定有人问“新书怎么进系统”，然后范围被悄悄扩大。

2.2 用例规约模板：主流程、异常流、后置条件三段必填

用例图只说明“有这件事”，说不清“这件事怎么算完成”。真正撑起需求分析报告的是用例规约。我的模板固定八个字段，缺一个都算没写完。

拿“UC-03 借阅图书”举例，主流程七步：读者在自助终端扫描读者码；系统校验身份有效且状态正常；读者扫描图书条码；系统查询该书目可借副本；系统校验借阅额度、是否有超期未还、是否有预约冲突、罚金是否超阈值；系统生成借阅记录并置副本为外借；系统返回应还日期。

异常流要编号到能与主流程对应：A1 身份失效（分叉于步骤 2）；A2 无可借副本（分叉于步骤 4）；A3 额度已满或存在超期未还（分叉于步骤 5）；A4 该书已被他人预约且未到保留截止时间（分叉于步骤 5）；A5 条码无法识别，允许手工输入并记录操作人（分叉于步骤 3）。

后置条件写两条：成功时新增一条借阅记录、副本状态迁移为外借、应还日期按读者类型计算；失败时不产生任何记录，副本状态不变。

这里有个血泪经验：异常流必须写“从哪一步分叉”。只写“校验失败则提示”，开发会把它实现成在最后一步统一拦截，前面的副作用已经产生，回滚逻辑没人写。编号分叉点是最省事的后悔药。

2.3 include 与 extend：借书流程里哪两个是必走、哪一个是可选

用例之间的关系只有三种值得在需求阶段用：泛化、包含（include）、扩展（extend）。前两个词被误用最多。

包含的意思是“每次执行都必须走”，被包含用例不能独立发起。图书管理系统里适合抽成包含用例的有两个：身份与状态校验（借书、续借、预约都要走）、可借性判定（额度、超期、预约冲突、罚金阈值的组合校验）。它们被三四个用例重复引用，抽出来能显著减少规约里的重复段落。

扩展的意思是“特定条件下才插入”，扩展用例本身是一个完整用例，只是它挂在基础用例的某个扩展点上。适合做成扩展的有：逾期罚金试算提示（只在读者存在超期时出现）、馆员代借（只有馆员角色触发）、预约到书短信补发。

最常见的翻车画法是把条件分支画成 include。比如“借书”里包含“额度校验”和“超期校验”，其实这两件事应该合并进一个“可借性判定”，再把失败分支写进异常流 A3。用 include 表达“如果……就……”，等于把流程逻辑塞进了用例图，图会越画越大，最后没人看。

@startuml left to right direction actor 借阅者 actor 馆员 actor 统一身份认证 as IdP rectangle "图书流通系统" { usecase "借阅图书" as UC03 usecase "归还图书" as UC04 usecase "续借图书" as UC05 usecase "预约图书" as UC06 usecase "身份与状态校验" as UC01 usecase "可借性判定" as UC02 usecase "罚金试算提示" as UC07 usecase "馆员代借" as UC08 } 借阅者 --> UC03 借阅者 --> UC04 借阅者 --> UC05 借阅者 --> UC06 馆员 --> UC08 UC03 ..> UC01 : <<include>> UC03 ..> UC02 : <<include>> UC05 ..> UC01 : <<include>> UC04 ..> UC07 : <<extend>> UC08 ..> UC03 : <<extend>> UC01 --> IdP @enduml

这段 PlantUML 的写法要点：包含关系用虚线箭头加<<include>>，箭头方向从基础用例指向被包含用例；扩展关系方向相反，从扩展用例指向基础用例，别画反，这是评审时最容易被抓的形式错误。left to right direction只是排版，不影响语义。参与者与外部系统的连线用实线，表示关联，不要加箭头，参与者发起的方向靠用例规约里的触发事件表达。

图里刻意没有画“查询借阅历史”“修改读者信息”这类功能。用例图不是功能清单，判断标准是：这个用例有没有明确的参与者和可观测的结束状态。查询类需求更适合放进补充规约的“数据视图”章节，画进用例图只会稀释信息密度。

3. 活动图与顺序图钉死借还时序：每条消息都要能追到一个需求编号

用例规约写的是“做什么”，还没解决“按什么顺序、在哪个对象上做”。需求分析报告里最容易埋雷的就是时序：并行还是串行、先扣库存还是先写记录、失败后谁负责回滚。这些问题在自然语言里怎么读都通顺，一旦开发照着实现，测试就能挑出一堆边界。活动图和顺序图是把这个模糊地带压掉的工具，注意它们服务的对象不同，别混用。

3.1 泳道按角色分四道，判定节点写成可二值回答的疑问句

活动图解决的是流程视角的问题：一件事从触发到结束，经过哪些判定，谁负责。泳道划分我一般按“责任边界”而不是按“界面”来分，图书借阅流程分四道：借阅者、自助终端、业务服务、库存与账务。

判定节点的写法有硬要求：必须是一个能用“是/否”回答的疑问句，并且两个分支都有明确去向。写“校验借阅资格”是错的，因为无法判断走了哪条路；写“当前在借数量 < 借阅额度？”才对。以下是我在图书借阅活动图里固定的判定节点。

六道判定按“代价从低到高”排序：身份校验最便宜先做，罚金判定涉及财务接口放最后。这个顺序写进规约，开发实现时不需要再猜。

活动图还要写清并发与合并。图书管理系统里有一个必须显式处理的点：生成借阅记录和置副本为外借，这两步必须在同一事务里，活动图用同步条（fork/join）表达，而不是画成两条并列箭头。并列箭头在 UML 里表示可并发执行，照此实现的代码可能出现副本已置外借、借阅记录写入失败的情况，第二天盘点就多出一本“消失的书”。

活动图的收尾条件也要写。只写“结束”不够，要写“成功结束：生成借阅记录且副本状态为外借”“取消结束：无任何数据变更”。这两种结束态直接对应后面追踪矩阵里的验收标准。

3.2 顺序图的对象从哪来：生命线、消息编号与返回值的写法

活动图回答“顺序和分支”，顺序图回答“谁调用谁、传什么、返回什么”。新手最常见的做法是打开工具现编对象名，结果图上的对象和类图对不上，评审时被追问“这个BookManager是哪来的”。正确做法是：顺序图里的生命线只能从两个来源取，一是用例规约里出现的外部参与者，二是候选类清单里的实体。

借阅图书这个场景，我固定用五条生命线：借阅终端（边界）、借阅服务（控制）、馆藏仓储（实体访问）、借阅记录仓储（实体访问）、通知网关（外部）。不画数据库，数据库是部署视图的事，画进来会让需求报告和设计文档的职责混在一起。

消息编号用层级制：1、2、3 是主流程步骤，1.1、1.2 是第 1 步内部的子调用。返回值用虚线箭头，且必须写明返回内容，不能只画一根空箭头。返回内容写什么？——成功、失败原因码、业务数据三者的组合。比如“可借性判定”返回的是{可借: true, 应还日期: 2025-06-30}或{可借: false, 原因码: QUOTA_EXCEEDED}。这个原因码就是异常流 A3 的落地形式。

@startuml actor 借阅者 participant "借阅终端" as UI participant "借阅服务" as SVC participant "馆藏仓储" as CAT participant "借阅记录仓储" as LOAN participant "通知网关" as MSG 借阅者 -> UI : 扫描读者码 UI -> SVC : 1 校验身份(读者码) SVC --> UI : 1.1 {有效, 读者类型, 额度} 借阅者 -> UI : 扫描图书条码 UI -> SVC : 2 借阅(读者ID, 条码) SVC -> CAT : 2.1 查可借副本(条码) CAT --> SVC : 2.1.1 副本ID / 无可用 SVC -> SVC : 2.2 可借性判定(额度, 超期, 预约, 罚金) SVC -> LOAN : 3 创建借阅记录(读者ID, 副本ID, 应还日期) LOAN --> SVC : 3.1 记录ID SVC -> CAT : 4 置副本为外借(副本ID) CAT --> SVC : 4.1 OK SVC -> MSG : 5 发送借阅成功通知(读者ID, 应还日期) SVC --> UI : 6 {成功, 应还日期} UI --> 借阅者 : 打印凭条 @enduml

这段顺序图的四个细节值得逐条对照。第一，2.1 和 2.2 是串行的，必须先查副本再判定可借性，反过来的话副本可能在被判定的间隙被别的终端借走。第二，第 3 步和第 4 步在同一个事务边界内，顺序图上用注释标出事务起止，不标注就等于允许分两次提交。第三，第 5 步发通知是异步的，写在事务之外，通知失败不能导致借阅失败，这一点必须显式画出来，否则开发会把它串进主链路。第四，2.2 是服务内部的自调用，用自消息表达，说明它不产生跨进程调用，别画成对另一个服务的请求。

关于alt组合片段，我的建议是需求阶段少用。异常流已经写在规约里了，顺序图里堆一堆alt会让图难以阅读。保留主流程一张、关键异常一张（比如“可借性判定失败”），足够。

3.3 从顺序图反推接口清单：消息到方法签名的一一映射

顺序图真正的产出不是那张图，而是图下面这张表。每条跨生命线的消息，都要落成一个接口条目，否则顺序图就是画着好看的。

这张表里有两列是需求阶段就该定的，不能推给设计：幂等要求和“期望原状态”。第 4 行的updateCopyStatus如果只传目标状态，两个终端同时借同一本书时后写入的会覆盖前者，正确做法是带期望原状态=在馆的条件更新，影响行数为 0 就说明被人抢先了，返回 A2 异常。这类并发语义写在需求分析报告里，测试才能设计出并发用例；不写，测试只能测单线程，上线后偶发超借，属于典型的玄学问题，排查成本极高。

4. 领域类图与状态机：书目、副本、借阅记录三者的关系怎么定

前两章都在讲行为，这一章讲结构。图书管理系统的领域类图有一个经典陷阱：把“书”当成一个类。现实里一本书是两层概念——书目（书名、作者、ISBN）和副本（条码、馆藏地、状态）。分不清这两层，后面的借阅记录、预约、遗失赔偿全部会错位。类图在需求分析报告里的作用不是指导建表，而是暴露这种概念歧义，让业务方在评审时确认“我们说的是同一件事”。

4.1 名词提取法的三道过滤：哪些词该进类图，哪些只是属性

找类最稳的办法是从用例规约里把名词全捞出来，然后过三道筛。这个方法笨但可复现，比凭经验拍脑袋可靠。

第一道筛：它在系统边界外吗？在外的不是类，是外部参与者，比如“身份系统”“财务系统”。第二道筛：它只是一个描述性取值吗？是的话降级为属性，比如“借阅额度”“罚金费率”“馆藏地编号”。第三道筛：它和其他候选是同义或上下位吗？合并，比如“读者”“借阅人”“用户”合并为读者，“罚金”“欠款”合并为罚金记录。

下面这张表是我通常会留在需求报告附录里的判定过程，评审时非常省事，因为业务方可以直接指着某一行说“这个我们其实不关心”。

“馆藏地”这一行是分水岭：讲不清楚时先做属性，等出现“按馆藏地统计借阅量”的需求再升级为类。需求阶段过度建模的代价比建模不足更大，因为每多一个类，评审就要多确认一轮。

4.2 多重性写错的代价：0..1 和 1..* 直接影响唯一约束

类之间的关系在需求阶段只用四种：关联、聚合、组合、泛化。图书管理系统里绝大多数关系是普通关联，真正需要斟酌的是多重性和所有权。

先看核心三者的关系。书目与图书副本是一对多，且副本不能脱离书目独立存在，这是组合关系，副本被删除时书目保留；借阅记录与图书副本是关联，一条借阅记录指向一个具体副本；读者与借阅记录是一对多，但任意时刻一个副本最多只有一条“未归还”的借阅记录——这条约束是状态机带来的，不是靠多重性表达的，必须写成文字约束。

多重性写错的后果非常具体。把“借阅记录—副本”写成0..*，意味着一个副本可以同时被多条借阅记录引用，开发就没有理由在建表时加“未归还记录唯一”的部分索引，超借问题在数据层失去最后一道防线。把“书目—副本”写成0..1，意味着一个书目最多一本副本，多副本入库直接被模型否掉。

表格最后一列才是需求分析报告真正的价值所在。UML 语法只能表达“多对多”，表达不了“同一时刻最多一条”，这类约束必须用文字或 OCL 写清楚。我一般把它们统一编号成 BR-xx，放进业务规则清单，后面追踪矩阵会引用这些编号。

聚合和组合在评审时经常被追问。判据很简单：整体销毁时部分是否必须一起销毁。罚金记录随借阅记录归档，是组合；读者被注销后借阅记录仍需保留，所以读者和借阅记录是普通关联，不能画成组合。这条判断错，后面归档策略就会写错，历史数据被级联删掉，属于典型的无法回滚的事故。

4.3 图书副本的 6 个状态与状态迁移表

图书副本是整个系统里状态最复杂的实体，也是最值得单独画状态机的地方。六个状态：在馆、预约锁定、外借、逾期、遗失、下架。

状态机有三条硬规则。第一，每个状态必须能从初始状态到达，且能到达终止状态，否则就是死状态。第二，每个迁移必须有触发事件，不能靠定时任务默默改状态，定时任务也是事件，要写出来。第三，非法迁移要显式拒绝，而不是“不处理”。

这张表要跟类图对照看：状态不是副本的一个字符串字段随便赋值，每次迁移都伴随记录写入或罚金计算。如果报告里只写“副本有在馆/外借/遗失三种状态”，开发和测试就只能覆盖三条路径，剩下七条迁移里的罚金、冻结、释放预约全部漏掉。

还有一个必须写进报告的点：状态迁移的并发控制。同一副本的“借出”和“预约锁定”可能同时发生，守卫条件必须在同一次条件更新里判断，不能先查后改。

5. 评审现场的 5 处翻车点与自查清单

需求分析报告的问题很少是“写错了”，多数是“写得看起来对”。下面五条是这类报告在评审里被挑出来的高频项，每一条都能在半小时内改掉，但拖到开发阶段就是返工。

5.1 五条踩坑记录：现象、原因、改法

第一处：用例图变成功能清单。现象是图上挂着二十多个用例，一半叫“XX管理”，参与者连了一圈。原因是没有用“参与者 + 可观测结束状态”这个标准过滤。改法是把所有“管理”类用例拆成具体动作，拆不出来的移出用例图，写进数据维护章节。一个用例如果说不清“结束后系统里多了或变了什么”，它就不是用例。

第二处：顺序图里出现数据库对象。现象是生命线里有“MySQL”“Redis”，消息全是 SQL。原因是在需求阶段混入了设计细节。改法是把它们替换成仓储接口，具体存储方案留给设计文档。这不只是形式问题：需求报告一旦出现表名，评审焦点会从业务规则滑向字段设计，该确认的异常流反而没人问。

第三处：多重性全写成0..*。现象是所有连线都是星号，看起来都很宽松。原因是作者不确定，索性写最宽的。改法是对每条关联追问“一端固定时，另一端最少几个、最多几个”，然后检查这些数字能否推出唯一约束。宽松的多重性会让所有数据完整性问题推到代码层，而代码层往往只有开发一个人知道。

第四处：没有版本和变更记录。现象是评审提了十二条修改意见，第二轮评审时没人知道改了哪几条，图上出现了两个版本的用例编号。原因是报告当成文档写，没当成受控物件。改法是首页放变更表（版本号、日期、变更条目、影响的需求编号），用例编号一旦分配永不复用，删除的用例保留编号并标注废弃。

第五处：非功能需求写成形容词。现象是“系统响应要快”“数据要安全”“并发要强”。原因是没量化。改法是每条非功能需求带度量口径：借阅操作在 300 并发下 95 分位响应时间不超过 2 秒；读者手机号在列表页脱敏展示；单副本并发借出冲突必须由数据库条件更新拦截，不允许应用层加锁。非功能需求如果无法验证，就等于没写。

5.2 提交评审前逐条打勾的 12 项自查表

自查表的作用不是走流程，是在评审前把明显的洞补掉，让评审时间花在业务规则上，而不是格式问题上。

十二项里第 6、7、10 三项最容易空着，也最容易在开发阶段爆炸。我的习惯是评审前一天只做这三项，其他项交给同事交叉检查，因为自己写的图自己看不出时序问题。

6. 把需求分析报告做成可验收物：追踪矩阵与一本真实图书的走查

需求分析报告写完，最难的判断是“够不够”。我的做法是做一个追踪矩阵，用需求编号把用例、类与状态、业务规则、验收标准串成一条线，然后拿一本真实的书走一遍全流程，看这条线断在哪里。

矩阵的行是需求编号，列固定五列。下面截取四行示意。

矩阵的价值在第三列和第五列的对应关系。如果某一行的“类/状态”列填不出来，说明用例里描述的行为没有落到任何实体上；如果“验收标准”列写不出可执行的判断，说明这条需求还没想清楚。我在一个项目里靠这一列发现“预约到书通知”根本没有对应的数据实体承载通知状态，导致保留期无法计算，属于典型的黑匣子区域——图上画了，数据里没有。

走查环节，我一般找业务方要一本真实存在、且当前处于外借状态的书，用它的条码把借出、续借、逾期、归还、产生罚金、结清罚金六步走一遍，每一步对照矩阵问三个问题：这一步改了哪些实体的状态？失败时哪些数据不该变？谁能在界面上看到这个变化？三个问题里有任何一个答不上，就说明报告缺一段。

有个技巧值得单独说：把罚金规则做成可配置项而不是写死在规约里。罚金费率、单日上限、免罚天数在不同馆之间差异很大，需求阶段最容易在这里被业务方改三次。我的做法是规约里只写计算口径和取整规则，具体数值进配置表并标注“由业务方在验收前确认”。这样改数值不需要动报告版本，评审也少一轮。

我自己的教训是，前几年做这类报告总想一次写全，图越画越多，结果评审时没人看得完。后来固定成“四张图加两张表”：用例图、关键流程活动图、借阅顺序图、副本状态图，加用例规约表、追踪矩阵。图和表之外的内容一律进附录，评审只过主线。报告的价值不在于覆盖多少页，而在于业务方能在两小时内确认完所有边界。希望帮到你。

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