UML图书管理系统建模全流程：StarUML用例图、类图与顺序图实战

简介：武汉理工大学《UML建模技术》课程实验报告，以图书管理系统为例，记录了从系统需求分析、参与者与用例识别到用例文本编写、StarUML用例模型建立的全过程，适合软件工程专业学生、UML初学者及需要完成类似课程设计的人群参考。报告将系统划分为学生管理、书籍管理、系统管理三大模块，识别出学生、图书馆管理员、系统管理员三类参与者，并围绕借阅图书、归还图书、查询借阅信息、系统维护等核心用例展开，给出了详细的主事件流与备选事件流处理，便于读者对照理解用例图落地时的细节。资源为单份PDF文件，约563KB，内容含实验目的、方案、调试过程、用例文本、用例图及小结，结构完整，可快速定位到建模每一步成果。目前已有792人学习，可作为UML实验报告模板、StarUML工具实践参考或软件建模课程复习材料。

1. 一份能照着复现的 UML 实验报告：图书管理系统建模全流程

如果你的 UML 课程作业正好落在“图书管理系统”上，这份武汉理工的实验报告值得花半小时拆一遍。它记录的不是高深理论，而是一个软件工程专业学生用 StarUML 完成图书管理系统建模的全过程：先写用例文本，再画用例图、领域类图，最后落到顺序图和设计类图，四轮实验一环扣一环。对还在纠结“用例图怎么画才规范”“类图要不要写操作”的人，这份报告提供了可以直接照抄的答案，也是期末和软考案例分析题的现成范本。它适合三类人：正在被 UML 作业追赶的学生、准备期末考或软考的考生，以及想把 UML 建模规范重新捡起来的一线开发。

2. 用例文本先行：参与者、事件流与用例图落地

实验一叫“静态模型 1”，做的却是用例模型，这个命名是学校课程的叫法，不用较真。真正值得学的是它的顺序：先分析需求，再识别参与者与用例，然后写用例文本，最后才打开 StarUML 画图。很多人在这一步就翻了车，一上来就拖图元，结果画出来的用例图逻辑站不住。这份报告给出的正确姿势是把用例文本当成核心产物，图形只是它的可视化表达。

2.1 需求拆解：三大模块如何映射到参与者

报告把图书管理系统的需求分成三大块：学生管理、书籍管理、系统管理。这三个模块不是平行关系，学生管理只负责生成借阅证，书籍管理覆盖借阅、归还和查询借阅信息，系统管理则是后台的“管理员的管理”，包括办理借阅证、删除借阅证、添加或删除管理员、添加或删除图书和标题信息。注意这里有个小重叠：学生管理里说生成借阅证，系统管理里又出现办理借阅证，复现时我会把借阅证的生成和办理统一归到系统管理，避免用例归属扯不清。

基于这三块需求，报告识别出三个参与者：学生、图书管理员、系统管理员。参与者不是“人”本身，而是人在系统里扮演的角色。学生是借阅业务的发起者，但在用例图里他并不直接操作系统；图书管理员是借还书两个核心用例的主要参与者；系统管理员只在“超控模式”和系统维护时出现。搞清楚这个边界，后面画用例图时才知道谁跟谁连线，不会把学生直接连到“系统维护”上。

判断参与者的最简标准是看两条：他是否直接与系统交互，他是否有独立于其他人的目标。按这个标准，“图书”不是参与者，它是被操作的对象；“借阅证”也不是参与者，它是学生身份的凭证。这三个参与者的划分，直接对应到用例图里三个最外层的角色框。

2.2 借阅用例文本：主成功场景和五条扩展流

报告最值钱的部分是实验一里的用例文本，尤其是“借阅图书”这个用例。它完整写了范围、级别、主要参与者、涉众及关注点、前置条件、成功保证，以及主成功场景的九个步骤。这个格式本身就是 UML 用例描述的规范模板，期末卷子和软考案例分析里让你“补全用例描述”，补的就是这些东西。

用例 UC1：借阅图书 前置条件：图书管理员已经过确认与认证，学生拥有借阅证 主成功场景： 1 学生携带所借书籍与借阅证到办理处 2 图书管理员开始办理借阅手续 3 图书管理员向系统输入学生的借阅证号 4 系统验证借阅证号有效 5 系统检验该账户中的借阅信息，验证成功 6 系统显示学生信息，提示管理员输入图书信息 7 图书管理员输入要借阅的图书信息 8 系统记录借阅信息，更新学生账户，完成借书 9 学生携带书籍离开 扩展流： *a 系统管理员在任何时刻要求进入超控模式，执行系统管理操作 *b 系统在任何时刻失败，管理员重启系统并请求恢复上次状态 2a 恢复过程中检测到异常，系统提示错误并进入初始状态 4a 系统验证借阅证无效，提示不存在该账户，管理员让学生重新注册 5a 系统检测到借阅数量超过规定，提示并结束本次借阅 5b 系统检测到有超期未归还图书，提示并结束本次借阅

这段模板有两点值得抄。第一，扩展流的编号直接挂到主流程的步骤号上，比如 4a 挂在“系统验证借阅证号有效”这一步，5a、5b 挂在“系统检验借阅信息”这一步。这样评审老师一眼就能看出异常发生在哪一个环节。第二，扩展流分成了两类：一类是环境和权限异常，比如系统失败、管理员超控；另一类是业务规则异常，比如借阅证无效、借阅超量、超期未还。考试写用例文本时，两类各写一到两条就足够拿分，这份报告写了五类，已经超出课程要求了。

唯一的小瑕疵是编号嵌套：2a 是挂在 *b 系统失败下的一层子扩展，报告直接写成“2a”，真正规范的写法应该是 *b 之下的 *b1 或 *b.1。复现时把这种子扩展单独编号，清晰度会明显提升。

2.3 StarUML 里把文本变成用例图

用例文本写完后，画用例图就是纯粹的搬运工作。常见做法是打开 StarUML，新建一个 Use Case Diagram，从左侧工具箱拖出 Actor 和 UseCase 图元，再按文本里的关系连线。参与者“学生”“图书管理员”“系统管理员”放在矩形框外，四个用例“借阅图书”“归还图书”“查询借阅信息”“系统维护”放在框内，然后按参与者与用例的交互关系画关联线。

借阅和归还都由图书管理员发起，所以这两个用例只连图书管理员，不直接连学生。系统维护连系统管理员。查询借阅信息这一类需要 include 关系标注成借阅流程的子流程，扩展流用 extend 关系挂在主流程的扩展点上。include 和 extend 的方向不要画反——include 指向被包含的公共子用例，extend 从扩展用例指向被扩展的基础用例，具体判断方法放到避坑章细说。

提示：先写完用例文本再画用例图，画图只是把文本搬到图形里。文本里一句话对应图上一条线，文本里没有的流程，图上也别硬加。

3. 领域模型搭建：把用例文本翻成类图的关键动作

实验二的产出是领域模型，用的是类图表达。这一步的核心不是画图，而是从用例文本里抽领域类和关联。报告里已经给出了完整的结果，但很多读者抄完类图却说不清这些类是怎么来的。这里拆一下推导过程。

3.1 名词划线法：从用例文本里捞领域类

最常见的做法是“名词划线法”：把用例文本里的业务名词全部圈出来，去掉明显属于属性描述的词汇，剩下的独立业务概念就是领域类。报告从借阅、归还、查询、维护这些用例里圈出了六个领域类：图书、账户、借阅证、学生、图书管理员、系统管理员。

原文的属性粒度很粗糙，但方向是对的。图书只给书名和在馆信息，这是借用例文本本身出现过的词；账户里放了借书数目、借书时间、借书书名，严格说这三样东西应该拆成一个“借阅记录”类，课程实验没拆可以接受，但如果你要拿这套模型去做后续的设计，我建议拆。借阅记录关联账户和图书两个类，才是真正的借阅关系表达。

3.2 关联如何提取：从动词短语找出关系

领域类的第二类是关联。报告列了十个关联，全部是从用例文本的动词短语里找出来的：学生注册账号、账号生成借阅证、图书管理员验证账户、图书管理员更新账户、系统管理员添加账户、系统管理员删除账户、系统管理员添加图书管理员、系统管理员删除图书管理员、系统管理员添加图书、系统管理员删除图书。

这些短语可以直接转成类图上的关联线。规则很简单：名词短语两端各对应一个类，动词短语决定关联名，方向由句子主宾决定。“学生注册账号”就是 Student 到 Account 的一条关联，方向上学生是发起者；“账号生成借阅证”就是 Account 到 LibraryCard 的关联。像“系统管理员添加图书管理员”这类后台维护操作，在领域模型阶段也可以先不画，因为它是权限操作而不是业务实体关系，画多了会把类图搞乱。

报告没有标关联的多重性，这是比较吃亏的地方。正式类图里多重性是需要标注的，我一般会补：学生和账户是 1 对 1，账户和借阅证是 1 对 1，账户和图书是多对多（一个账户可以借多本，一本图书可以被多人借过），图书管理员和图书之间是 1 对多（一个管理员可以处理多本图书的借还）。标上多重性，这张图才算真正具备了面向对象建模的信息量。

3.3 领域类图与设计类图的第一次分界

实验二到实验四之间有一个很容易被忽略的分界：领域类图只关心属性和关联，不关心操作；设计类图必须补上操作。报告在实验四里也点明了这一点——实验二的模型里每个类只有相应属性与类间关联，每个类含有什么操作并没有明确。很多学生就是在这一步把两张图画成了一样的东西。

领域模型回答的是“系统里有什么”，设计模型回答的是“这些对象能做什么”。图书在领域模型里只有书名和在馆信息，到了设计类图里就要有查询库存、更新在馆状态这类操作；账户在领域模型里只有账号密码和借阅信息，到了设计类图里就要有验证借阅证、增加借阅记录、删除借阅记录这些方法。如果在画领域类图的时候过早加操作，图的层次就乱了。

4. 动态模型补全：顺序图、设计类图与消息的来回校验

实验三和实验四合起来完成了动态模型。报告先用顺序图描述借书和还书的交互过程，再把顺序图里的消息转成设计类图的操作。这两步是连在一起做的：顺序图告诉你要有哪些操作，设计类图告诉你要有谁来执行这些操作。

4.1 借书顺序图和还书顺序图怎么读

顺序图的读法在报告里写得很清楚：纵向是时间轴，时间沿竖线向下延伸；横向是参与协作的对象的生命线。当对象存在时用一条虚线表示生命线，当对象的过程处于激活状态时，生命线变成双道线。理解了这个二维结构，再看图和画图都不会跑偏。

借书顺序图的消息序列可以还原成这样：学生把书交给图书管理员；图书管理员向系统输入借阅证号；系统验证借阅证有效；系统显示学生信息；图书管理员输入图书信息；系统记录借阅信息并更新学生账户。这一串消息和用例文本 UC1 的主成功场景几乎是一一对应的，只是把文本里的自然语言换成了对象之间的消息。

还书顺序图的消息序列则相对简单：学生把书交给管理员；管理员向系统输入图书信息；系统验证该图书是本馆藏书；系统删除相应的借阅信息；系统更新学生账户。注意归还流程里没有“验证借阅证”这一步，因为还书不强制要求验证学生身份，但借书必须验证。这个差异很容易画错，照抄文本时往往会把两套消息画成一模一样。

4.2 从顺序图反推设计类图的操作

顺序图画完，设计类图的操作就有来源了。核心方法很机械：顺序图里每个指向接收对象的入向消息，几乎都会变成接收对象类上的一个操作。这是顺序图和设计类图之间的“翻译规则”。

报告在实验四里把类图里的中文全部改成了英文，还特别说了一句“希望能有助于与书本接轨”。这个动作看起来只是翻译，实际上是一条必由之路：类图一旦进入设计阶段，类名、属性名、操作名必须按代码规范来写，中文类名在后面的编码阶段没法直接用。所以你在复现的时候，直接从设计类图阶段就用英文命名，省得后面返工。

4.3 顺序图和设计类图的协同校验

静态模型和动态模型不是两张孤立的图。顺序图新增一条消息，设计类图就要有对应的操作；反过来，如果设计类图上某个操作在顺序图里找不到任何消息来源，说明这个操作是多余的，要么删掉，要么回顺序图里补交互。报告虽然没有把这条规则写出来，但它的实验四是“完善顺序图并建立设计类图”，这两个动作本来就应该交替进行。

我做这类建模时有个习惯：顺序图画完先不急着画类图，而是先把消息清单列出来，每个消息写成“接收对象.操作名”的格式，再把清单贴到设计类图旁边逐条比对。这样两套图能做到消息和操作一一对上，老师挑毛病也挑不出来。如果想进一步把扩展流也表达出来，可以在顺序图里用 Combined Fragment 的 alt 框表示“借阅证无效”和“超期未还”这两个分支，课程作业做到这一步已经属于加分水平了。

5. StarUML 建模避坑：四个最容易翻车的地方

这一章写的是血泪经验。报告本身没有踩坑记录，但凡是自己动手用 StarUML 画过一遍的人，基本都在这几个地方栽过跟头。

5.1 include 和 extend 方向画反

现象：用例图上“借阅图书”和“查询借阅信息”之间、以及借阅流程和超期处理之间的连线方向经常画反。查询借阅信息被 extend 到借阅图书上，超期处理被 include 进来，图看起来就特别别扭。

原因：include 和 extend 的语义容易混淆。include 表示基础用例在执行时必须包含某个子流程；extend 表示在某些条件下可能会进入的扩展流程。查询借阅信息是借阅流程里必然要走的一个步骤，所以是 include；超期检测是满足特定条件才触发，所以是 extend。

解决：画之前先问一句“这个用例是不是每次都会执行”。每次都会执行的，用 include，箭头从基础用例指向被包含用例；有条件才触发的，用 extend，箭头从扩展用例指向基础用例。

5.2 设计类图只画属性不画操作

现象：实验四交上去的设计类图，老师看了一眼说“这不就是实验二的领域类图吗”。领域类和设计类连评价都没有，直接被打回。

原因：很多人照抄实验二的类图，属性照样填，关联照样连，就是忘了加操作。设计类图的价值就在于把顺序图里的消息沉淀成方法，没有操作的方法，类图就退回了领域模型。

解决：做完顺序图之后，按照 4.2 的“消息转操作”规则逐个类去补。每个类至少有一个操作，操作名用英文动词开头。补完再反向检查一遍：顺序图里出现的每条消息，是否都能在设计类图上找到对应操作。

5.3 顺序图消息顺序和用例文本对不上

现象：顺序图画得很漂亮，但一比对用例文本，发现验证账号的步骤跑到了输入图书信息之后，还书流程里多了一步验证学生身份，消息顺序完全对不上文本。

原因：画顺序图时凭印象画，没有再翻回用例文本逐步对照。顺序图的消息序列本质就是用例文本主成功场景的重新排版，文本里的步骤顺序是不能随便调整的。

解决：画每条消息时都标注它对应主成功场景的第几步，按编号从小到大排。还书顺序图尤其要注意，UC2 里没有验证学生借阅证这个步骤，别凭借书经验脑补进去。

5.4 StarUML 版本差异导致导出图没法用

现象：同一个 .mdj 文件，在旧版本 StarUML 里打开后中文变乱码，导出图片时文字重叠，图元位置全乱。换到新版打开又出现工具栏找不到的情况。

原因：StarUML 各个大版本的界面和渲染逻辑有差异，早期版本对中文支持不完整，导出图片的分辨率和比例控制也很差，属于“能用但不好用”的级别。

解决：建模文件用哪个版本建的，就一直用同一个版本打开。导出图片之前先在编辑器里把注释和文字字号统一调大，再调整图元间距，最后用 File → Export Diagram 导出，不要直接截图。如果你用的是老版本且中文乱码，可以全部改用英文命名，这也是报告里实验四采用的思路。

5.5 关联名偷懒把动词丢掉

现象：类图上的关联线只有一条线，没有关联名，或者直接写“关联”“关系”这种没有信息量的词。老师问这条线是什么意思，答不上来。

原因：画关联线时只关心类之间“有关系”，不关心具体是什么关系。关联名的价值在于精确表达关系语义，“学生注册账号”和“系统管理员删除账号”虽然都连接学生和账户两个类，但语义完全不同，类图上必须区分。

解决：每条关联线都标上动词短语。如果一条线上有两三个动词并列，比如“添加/删除”，说明这个关联承载了太多职责，应该把后台管理类操作从业务实体关联里拆掉，保持类图的单一语义。

6. 拿到手的验证路径：按四步把报告复现一遍

6.1 一周目复现清单

拿到这份 PDF，别急着从头到尾读一遍就完事。最有效的用法是把它当参考答案，自己动手把四个实验完整走一遍。下面这份检查清单是我从报告里提炼的验收标准，每完成一个环节就勾一项：

[ ] 用例文本：每个重要用例都有前置条件、主成功场景、扩展流三件套 [ ] 用例图：参与者和用例能对照文本逐条对上，include/extend 方向正确 [ ] 领域类图：每个领域类有属性，类间有带动词的关联名 [ ] 顺序图：消息顺序与用例文本主成功场景逐条对应 [ ] 设计类图：每个类有操作，操作来源可追溯到顺序图消息

6.2 这套流程怎么变成课程设计和软考能力

这套方法的可迁移性很强。下一次课程设计不管换成“学生选课系统”还是“网上商城订单管理”，建模步骤都是这五步：拆需求模块、识别参与者、写用例文本、画用例图、抽领域类、补动态模型。软考系统分析师和系统架构设计师的案例分析题里，经常给一段需求描述让你补全用例图或类图，答题范式跟这份报告完全一致——先在草稿纸上把参与者和用例列出来，再写事件流，最后才动笔画图。

我后来做任何一个小系统的设计，都强制自己先把用例文本写满一张 A4 纸再打开建模工具。这个习惯帮我避开了很多返工：文本写清楚了，图只是搬运；文本没写清楚，图一定是乱画。希望这份报告的拆解对你有用，也希望你复现完之后，能比照着抄多走一步——把图书管理系统换成你自己手头的项目，重新走一遍这五步，那才算真正把 UML 建模装进了自己的工具箱。

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