企业官网建设流程全解析

简介：这份武汉理工大学UML建模技术实验报告，以图书管理系统为案例，面向软件工程专业学生及UML初学者，帮助读者通过完整实验流程掌握用例驱动分析方法与StarUML工具操作。资源为单个PDF文件，压缩包约563KB，内容涵盖实验分析设计、调试过程与结果分析等完整章节。报告细致拆解了系统需求，将图书管理系统划分为学生管理、书籍管理、系统管理三大模块，并完整呈现参与者识别、用例文本编写与用例模型建立的全过程，其中借阅图书、归还图书等用例的主成功场景与扩展流程均有详细描述，还涉及借阅证验证、超期未还等异常处理策略。目前已有792人学习，适合需要参考实验报告结构、理解用例图绘制与用例文本撰写规范的读者，可借此快速把握UML静态建模的实践要点。

1. 从一份 2015 年的 UML 实验报告说起：图书管理系统建模到底练什么

如果你正在搜「uml 图书管理系统」「StarUML 用例图怎么画」「uml 类图箭头含义」，大概率是两种情况：要么课程实验催着交，要么想找个完整案例把 UML 从符号到落地走一遍。这份《武汉理工 UML 实验——图书管理系统》就是后者——它不是一份只贴几张图的作业，而是把四次实验串成了一条完整的建模链路：用例模型、领域模型、顺序图、设计类图，每一步都有需求分析、用例文本、类与关联的推导过程。带队的指导老师是陈明俊，班级是软件 zy1302，时间跨度从 2015 年 4 月到 5 月，四次实验分别对应静态模型 1、静态模型 2、动态模型 1、动态模型 2。它适合谁？适合刚接触 UML、需要一份能照着复现的完整案例的软件工程学生，也适合想用图书管理系统这个经典场景把用例驱动方法走通的从业者。下面我按「这份资源是什么 → 怎么照着做 → 坑在哪」的顺序拆开讲。

2. 用例模型怎么落地：从需求到 UC1/UC2 用例文本的完整推导

2.1 先分清参与者与用例，别一上来就画图

很多人拿到「图书管理系统」这个题目，第一反应是打开 StarUML 直接拖椭圆。这份实验报告的做法相反：先把需求拆成三个功能模块，再从中识别参与者和用例。原文的需求分析写得很清楚——学生管理负责生成借阅证；书籍管理负责借阅、归还、查询借阅信息；系统管理负责办理/删除借阅证、增删管理员、增删图书、增删标题信息。

从这三块需求里，报告识别出三类主要参与者：学生、图书馆管理员、系统管理员。对应的用例是：借阅图书、归还图书、查询借阅信息、系统维护。这里有个容易被忽略的点——参与者不是按「人」分的，而是按「角色」分的。同一个学生，在借阅场景里是「学生」，在系统维护场景里根本不出现。系统管理员则是一个超控角色，可以在任意时刻切入超控模式执行管理操作，这一点在用例文本的扩展流里专门写了。

识别完参与者和用例，下一步是写用例文本。报告里 UC1（借阅图书）和 UC2（归还图书）写得非常完整，包含范围、级别、主要参与者、涉众及关注点、前置条件、成功保证、主成功场景、扩展流程。这套结构其实就是 Alistair Cockburn 的用例模板，做课程实验时直接套用就行。

2.2 用例文本的字段怎么填：以 UC1 借阅图书为例

UC1 的主成功场景一共 9 步，我把它拆成可抄的模板：

用例 UC1：借阅图书 范围：图书管理系统 级别：用户目标 主要参与者：图书管理员 涉众及关注点： - 图书管理员：希望能够准确快捷帮助学生借书 - 学生：希望能够便捷地借阅到图书 - 系统管理员：希望系统能在自己的维护下更加稳定 前置条件：图书管理员必须经过确认与认证；学生拥有借阅证 成功保证：存储书籍信息；更新书目及学生借阅信息 主成功场景： 1. 学生携带所借阅书籍与借阅证到办理处办理 2. 图书管理员开始办理借阅手续 3. 图书管理员向系统输入学生的借阅证号 4. 系统验证借阅证号有效 5. 系统检验该账户中的借阅信息，验证成功 6. 系统显示学生的信息以提示图书管理员输入要借阅的图书信息 7. 图书管理员输入要借阅的图书信息 8. 系统记录一个借阅信息，并更新该学生账户完成借阅图书操作 9. 学生携带所借阅书籍离开

这份文本里最值得学的是扩展流程的编号方式。报告用了*a、*b、2a、4a、5a、5b这种标记：带星号的是可以在任意步骤发生的全局异常（比如系统管理员要求超控、系统失败），数字开头的是挂在特定步骤上的局部异常（比如第 4 步验证借阅证无效、第 5 步检测到借阅超量或超期）。这种编号法在画用例图时不用体现，但在写详细设计文档时非常有用，因为它把「哪一步出问题、怎么处理」钉死了。

UC2（归还图书）的结构和 UC1 对称，主成功场景 6 步，扩展流程里多了「验证该图书不是本馆藏书」和「检测到超期未归还」两个分支。把这两个用例文本写扎实，后面画顺序图时消息从哪来、往哪去就都有依据了。

2.3 用 StarUML 画用例图：参与者、用例、关系的画法

用例文本写完，才轮到 StarUML 上场。报告里实验一用的工具就是 StarUML，实验目的里明确写了「初步了解 StarUML 的使用，了解 StarUML 的界面与功能」。画用例图的操作步骤大致是这样：

第一步，新建项目，在 Model 里添加 Use Case Diagram。第二步，从工具箱拖 Actor 出来，放三个：学生、图书馆管理员、系统管理员。第三步，拖 Use Case 椭圆，放四个：借阅图书、归还图书、查询借阅信息、系统维护。第四步，用 Association 连线把参与者和它参与的用例连起来——注意，学生只连「借阅图书」「归还图书」「查询借阅信息」，系统管理员连「系统维护」，图书管理员连「借阅图书」「归还图书」「查询借阅信息」。

这里有个常见疑问：用例之间要不要画 include 和 extend？这份实验报告里没有展开，但从 UC1 的扩展流来看，「系统维护」里的超控模式其实可以理解为一个 extend 关系。不过课程实验阶段，把参与者和用例的关联画对、把用例文本写全，比纠结 include/extend 更重要。

提示：StarUML 里 Actor 默认是火柴人，Use Case 默认是椭圆，如果画出来是方框，检查一下是不是把 Class 拖进来了。用例图里不应该出现类。

3. 领域模型与设计类图：从用例文本里「抠」出类和关联

3.1 领域类怎么找：名词提取法加用例回溯

实验二的目的是建立领域模型。报告给的方法很直接：根据实验一的用例模型，分析用例文本描述，找到领域关键概念，再用 StarUML 建立领域类图。具体操作是「分析上一实验得到的用例模型，得到领域类；分析各领域类的属性；分析各领域类之间的关联；建立领域模型」。

报告最终提取出的领域类和属性是这样的：

关联则列了 10 条：学生注册账号、账号生成借阅证、图书馆管理员验证账户、图书管理员更新账户、系统管理员添加账户、系统管理员删除账户、系统管理员添加图书管理员、系统管理员删除图书管理员、系统管理员添加图书、系统管理员删除图书。

这里有个值得注意的细节：报告把「账户」和「借阅证」拆成了两个类，而不是合并成一个。为什么？因为账户承载的是借阅状态（借书数目、借书时间、借书书名），借阅证承载的是身份信息（姓名、系别、借阅证号）。一个学生可以有一个账户和一张借阅证，账户是系统内部的借阅记录载体，借阅证是物理凭证。这个拆分在后续设计类图里会体现为不同的操作职责。

3.2 从领域模型到设计类图：补操作、定关联

实验四的核心任务是「继续完善顺序图并建立设计类图」。报告里有一段很关键的说明：实验二建立的领域模型里，每个类只有属性和类与类之间的关联，至于每个类含有什么操作、类与类之间是何种关联，并没有明确定义。实验三的顺序图则强调了类与类之间的相互关联，明确定义了各类之间的行为动作。实验四要做的，就是在前三个实验的基础上，明确定义出各类的属性及各类间的关联，并行完成设计类图与顺序图。

报告里还提到一个实操细节：设计类图里把中文全部改成了英文，希望能有助于与书本接轨。这个做法在课程实验里很常见，因为很多 UML 教材的示例都是英文类名。如果你也要交实验报告，建议类名用英文、属性名用英文、关联名用英文，注释可以保留中文。

设计类图里需要补的操作，可以从顺序图的消息里反推。比如借书顺序图里，图书管理员向系统发消息「输入借阅证号」，系统返回「验证结果」，那系统对应的类（可以是 Account 或 LibrarySystem）就应该有verifyCard(cardId)和checkBorrowStatus(account)这样的操作。还书顺序图里，图书管理员发消息「输入图书信息」，系统返回「验证是否本馆藏书」，那 Book 类就应该有verifyOwnership(bookId)操作。

3.3 顺序图怎么画：借书和还书两条生命线

实验三和实验四都涉及顺序图。报告对顺序图的定义写得很清楚：顺序图就是将交互关系表示为一个二维图，纵向是时间轴，时间沿竖线向下延伸，横向轴代表了在协作中各独立对象的类元角色，类元角色用生命线表示。当对象存在时，角色用一条虚线表示，当对象的过程处于激活状态时，生命线就是一个双道线。

借书顺序图的参与对象大致是：图书管理员、借阅证、账户、图书、借阅记录。消息顺序对应 UC1 的主成功场景：管理员输入借阅证号 → 系统验证借阅证 → 系统检验账户借阅信息 → 系统显示学生信息 → 管理员输入图书信息 → 系统记录借阅信息 → 系统更新学生账户。

还书顺序图的参与对象类似，消息顺序对应 UC2：管理员输入图书信息 → 系统验证是否本馆藏书 → 系统删除借阅信息 → 系统更新学生账户。

在 StarUML 里画顺序图的操作：新建 Sequence Diagram，从工具箱拖 Lifeline 出来，每个对象一条生命线；拖 Message 连线，从发送方生命线拉到接收方生命线；激活状态用 Activation 表示。注意消息的顺序是从上到下的，别画反了。

注意：顺序图里的消息名要和用例文本里的步骤对应上，否则后面做设计类图时会发现操作对不上。我一般会先把用例文本的步骤编号抄在纸上，画图时逐条勾掉。

4. 避坑与排查：四次实验里最容易翻车的五个地方

4.1 参与者识别多了或少了

现象：用例图里画了「数据库」「打印机」这类非人类角色，或者漏掉了「系统管理员」这个超控角色。

原因：把系统内部组件当成了参与者。参与者一定是系统外部、与系统交互的角色，数据库和打印机是系统的一部分，不是参与者。系统管理员虽然在主成功场景里不出现，但扩展流程*a里明确写了「系统管理员在任意时刻要求进行超控模式」，所以它必须是一个独立参与者。

解决：回到需求描述里找「谁使用系统」「谁从系统获取信息」「谁维护系统」。学生、图书管理员、系统管理员三类角色分别对应使用、操作、维护三个层次，缺一不可。

4.2 用例文本的扩展流程编号混乱

现象：扩展流程写成「如果借阅证无效，则提示错误」，没有编号，也没有说明从主成功场景的哪一步触发。

原因：没有按 Cockburn 模板的编号规则来写。扩展流程的编号必须能追溯到主成功场景的步骤号，否则读者不知道这个异常是在哪一步发生的。

解决：全局异常用*a、*b，局部异常用「步骤号 + 字母」，比如第 4 步的异常写4a，第 5 步的第一个异常写5a、第二个写5b。报告里 UC1 的5a和5b就是同一个步骤上的两个不同异常分支，这种写法要学。

4.3 领域类属性里塞了操作

现象：领域模型里给「图书」类加了borrow()、return()这样的方法。

原因：混淆了领域模型和设计类图。实验二建立的领域模型只描述状态（属性和关联），不描述行为（操作）。操作是在实验四的设计类图里才补上的。

解决：实验二阶段，每个类只写属性，不写方法。如果实在想记，可以先用注释标出来，等实验四再正式加到类里。

4.4 顺序图的生命线和消息对不上用例文本

现象：顺序图里出现了用例文本里没有的消息，或者用例文本里的步骤在顺序图里找不到对应的消息。

原因：画顺序图时没有回头对照用例文本，凭感觉加消息。

解决：画之前先把用例文本的主成功场景步骤抄下来，每画一条消息就勾掉一个步骤。如果发现某一步在顺序图里没法用消息表达（比如「学生携带书籍离开」），那这一步就不需要画进顺序图，因为它是系统外部的动作。

4.5 StarUML 里中文类名导致导出乱码

现象：设计类图里用中文类名，导出图片或 PDF 时出现方框或乱码。

原因：StarUML 某些版本的字体渲染对中文支持不好，尤其是导出为矢量图时。

解决：报告里实验四的做法是把中文全部改成英文。如果你必须用中文，导出前先在 Preferences 里把字体改成支持中文的字体（比如微软雅黑），或者直接导出为 PNG 而不是 SVG。我一般会中英文对照着写，类名用英文，注释用中文，这样既不影响导出，也方便自己看。

5. 进阶用法：把四次实验串成一条可复用的建模流水线

四次实验做完，你会发现它们不是孤立的：实验一产出用例模型和用例文本，实验二从用例文本里提取领域类和关联，实验三用顺序图把用例文本的主成功场景展开成对象间的消息交互，实验四在顺序图的基础上补操作、定关联，形成设计类图。这条链路就是用例驱动建模的完整流程。

如果你想把这套方法复用到别的系统上，我建议按这个顺序走：先写用例文本，再画用例图，再从用例文本里提取名词做领域类，再画顺序图验证类的职责，最后补设计类图。不要跳步，尤其是不要跳过用例文本直接画图——没有用例文本，后面的类图和顺序图都是空中楼阁。

验证建模是否完整，可以用一个简单的检查表：

这份实验报告的价值不在于它用了多高级的工具，而在于它把「需求 → 用例 → 领域模型 → 顺序图 → 设计类图」这条链路走通了，而且每一步都有可追溯的文本依据。StarUML 只是画图的工具，真正难的是从需求里识别出正确的参与者和用例，再从用例文本里推导出类和关联。我当年做课程实验时，总想着先把图画出个大概再补文本，结果每次都被老师打回来重写用例文本。从那以后我每次做建模，都强制自己先把用例文本写完整，再打开 StarUML。希望这份拆解能帮到你。

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