企业官网建设流程全解析

简介：面向软件工程课程设计与系统分析实践，这份约194KB的压缩包内含1个DOCX文档，完整呈现图书管理系统从需求到设计的UML建模过程。文档围绕读者管理、书籍管理、借阅管理和系统管理四大功能模块，给出了用例图、类图、顺序图、协作图、活动图、状态图及项目部署图，并配有借书、还书、预订等场景的用例规约与事件流说明，便于理解各图之间的对应关系。内容既可作为高校《UML面向对象分析与设计》《软件工程》等课程的配套参考资料，也可作为开发图书管理系统的设计蓝本。文档共11页，目前已由2125人学习浏览。对需要完成课程设计、毕业设计或准备系统分析报告的读者而言，可直接对照图中角色、类结构、消息顺序与状态流转来梳理业务逻辑，省去从零绘制UML图的摸索时间。

1. 一份 11 页的图书管理系统 UML 图，能不能撑起你的课设答辩

需求文档写了六页，图一张都画不出来，这是课程设计里最常见的卡点。这份 11 页的图书管理系统 UML 图把整条链路走完了：从功能描述拆出用例图，用名词分析法得到类图，再顺着借书、还书两条主事件流推顺序图和协作图，最后把活动图、状态图、部署图补齐。它不是什么高深的设计模式，胜在链条完整、粒度统一，做高校课设、软件工程实验报告、毕业设计的建模参考都能直接对上。适合两类人：一类是要交 UML 作业、拿不准类图箭头往哪边画的同学；另一类是接手老系统，想把存量逻辑倒推成模型图、方便跟产品对齐需求的在职开发。真正值钱的地方是它把「借书」这一条业务从用例规约一路推到消息序列，中间没有断点。

2. 用例图先立骨架：两个参与者、12 个用例，extend 箭头别画反

2.1 参与者怎么定：自动借还机为什么没进 Actor 名单

判定参与者只看一件事：谁跟系统交互，并且从交互结果里拿到价值。按这个标准筛，图书管理系统只剩两个：读者和管理员。管理员负责书籍管理、借阅管理、读者管理和登录，读者侧有借书、还书、查询、预订、逾期处理、丢失处理、自动借书机使用和登录，两边加起来 12 个椭圆。

自动借还机在功能描述和读者用例里都出现过，但它没被建模成参与者。理由很实在：借还机上的每一次操作，实际发起人还是读者本人，它本质上是系统边界内的一个终端设备。如果硬把它提成 Actor，那读者侧的「自动借书机的使用」就要重画成设备与系统之间的交互，整张图会凭空多出一套平行的借书流程，粒度立刻失控。

提示：判断某台设备该不该当参与者，就问一句「它会不会在没有人的情况下自己发起一笔业务」。会，就是参与者；不会，就是系统内部的节点。

2.2 用例粒度：登录、续借、缴纳罚金该不该单独一个椭圆

粒度是这份资料里最容易被追问的地方。登录系统被两个参与者各挂了一个，这样画不算错，但更省事的做法是合并成一个登录用例，再让业务用例通过 include 去引用它，图面能干净不少。

续借值得单独成椭圆。读者可以在应还日期之前主动决定续借，这是一个能独立发起、有独立结果的行为，和借书不是同一件事。缴纳罚金就不一样了，它只在图书逾期这个条件下才被触发，脱离逾期处理它没有意义，所以用<<extend>>挂在逾期处理上是对的。找回密码同理，它是登录在「用户忘记密码」这个条件下的可选分支，箭头从找回密码指向登录。

箭头方向记一句话：泛化和扩展都从「特殊」指向「一般」，也就是从子指向父、从扩展指向基础。很多人凭直觉画成调用方向，一画就反。

粒度还有个经验值：一个用例的基本事件流控制在五到十步。少于三步的，往上层合并；超过十五步的，说明里面藏了两件事，拆开。照这个尺子量，这份资料的 12 个用例基本都落在合理区间，只有「自动借书机的使用」偏薄，它其实可以理解成借书 / 还书在自助终端上的一个变体。

2.3 从用例图到用例规约：借书 UC01 的六条基本流逐条对齐

用例图画完只是骨架，真正决定后面几张图能不能推下去的是用例规约。资料的借书用例（UC01）主角是管理员，前置条件是管理员已登录，六条基本流写得很规整：

后置条件写「无」是个可以改进的点。借书成功以后，借阅记录表多了一条，图书的可借数量减一，这两个都是系统状态的变化，写进后置条件里，后面验收和测试用例都能直接对应上。我一般会把它补成「读者借阅记录新增一条，对应图书可借数量减一」。

从功能描述推到这一步的方法很机械：把功能描述里带「管理」的粗颗粒词逐条拆开，每条问三个问题——谁发起、什么时候结束、结束之后系统状态变没变。三个问题都能答上来，这条就是一个合格用例；答不上来的，多半是功能描述里的修饰性描述，不该进用例图。

3. 类图落地：名词分析法筛出 6 个类，属性方法与箭头一次讲透

3.1 名词分析法走一遍：哪些名词进类图，哪些降级成属性

资料里写明用名词分析法，操作步骤是三步：从功能描述和事件流里抄出所有名词，筛选出候选类，再确定类之间的关系。抄名词这一步不要偷懒，把功能描述、用例规约的基本流异常流全部过一遍，宁可多抄。

筛选规则有三条。有独立生命周期、需要单独存一张表的，升级成类；只是描述某个类、没有自己独立编号的，降级成属性；动词一律变成方法。同义词先合并再用，比如借阅人、读者、用户在这个场景里指的是同一批人，留一个「读者」就够。

筛选完剩 6 个核心类，跟资料的类图规模一致。多出来的候选名词不是废料，它们全都有去向——要么变成属性，要么变成方法，丢掉任何一个都会在后面的图里留坑。

3.2 属性与方法清单：读者、图书、借阅信息三张表的字段粒度

资料给出的属性如下：读者有姓名（String）、学号、班号、借书证号；图书有编号、书名、价格、作者、出版社、出版时间；出版社有名称、联系电话、联系地址、联系人；管理员有工号、姓名、出生日期；借阅信息有书号、借阅人、借阅日期、应还日期、操作员。

这里有个明显的不一致：功能描述里明确写了读者要记录姓名、编号、班级、年龄、性别、地址、电话七项，类图里的读者只剩四项。这类不一致是答辩时最容易被翻出来的，补法很简单，把功能描述里「记录 / 查询 / 修改」后面跟着的字段逐项抄进类图，多的删、少的补。

另一个更值得说的问题是方法挂在哪里。资料把借书()、还书()、预定图书()、续借()全挂在图书类上。图书是一个纯粹的信息对象，它不该知道「怎么被借走」。常见的三种改法：

一是把行为挪到借阅信息类上，让借阅记录自己管状态流转；二是抽一个控制类「借阅管理器」，用它承载用例驱动的业务动作；三是引入馆藏册的概念，每一本实体书一个对象。课设场景我一般选第二种，借阅管理器加借阅信息实体，职责划分清楚，被问到「为什么图书自己会借书」的时候也答得上来。

属性还要补可见性符号。-表示私有、+表示公有、#表示受保护。资料里写的是「姓名 : String」，没带符号，严格判卷是要扣分的，统一加上-最稳妥。

3.3 uml 类图箭头含义：关联、聚合、组合、继承在图书系统里的落点

箭头是搜索量最高的一个问题，也是这份资料最值得反复看的部分。把常见的几种记熟，看书上的图就不费劲了。

多重性写在对方那一端：读者 1 对 n 借阅信息，n 写在借阅信息这头，表示一个读者对应多条借阅记录。方向别搞反，这是判卷老师第一眼会扫的地方。

借阅信息同时挂在读者和图书之间，而且自己带属性，这种情况用关联类表达最准确——画成普通的类，再用虚线连到读者与图书的关联线上。聚合和组合的分界也在这个案例里能说清：出版社被停用了，图书还在，所以是聚合；借阅记录被删了，挂在它下面的罚金明细没有意义，所以是组合。

3.4 类图映射到 MySQL：一份借阅记录建表语句与参数说明

类图画完不能只停在纸上，落到数据库才是能跑的东西。借阅信息是这套模型里最关键的关联类，它的建表语句大致长这样：

CREATE TABLE borrow_record ( borrow_id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '借阅记录主键', book_no VARCHAR(20) NOT NULL COMMENT '图书编号，关联 book 表', reader_no VARCHAR(20) NOT NULL COMMENT '借书证号，关联 reader 表', operator_no VARCHAR(20) DEFAULT NULL COMMENT '操作员工号，自助借还时为 NULL', borrow_date DATE NOT NULL COMMENT '借阅日期', due_date DATE NOT NULL COMMENT '应还日期，用于逾期判定', return_date DATE DEFAULT NULL COMMENT '实际归还日期，未还为空', fine DECIMAL(8,2) NOT NULL DEFAULT 0.00 COMMENT '罚金', status TINYINT NOT NULL DEFAULT 0 COMMENT '0 借出中，1 已归还，2 丢失', PRIMARY KEY (borrow_id), KEY idx_reader_status (reader_no, status), KEY idx_book_status (book_no, status), CONSTRAINT fk_borrow_book FOREIGN KEY (book_no) REFERENCES book (book_no), CONSTRAINT fk_borrow_reader FOREIGN KEY (reader_no) REFERENCES reader (reader_no) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='借阅记录';

这段 DDL 的逻辑对应关系很清楚：reader_no和book_no两个外键，正好把类图里读者与图书之间的多对多，通过关联类拆成了两条一对多。status字段承接的是状态图里的图书状态与用例图里的丢失处理，一个字段把三张图串在了一起。

参数上几个点值得留意。idx_reader_status和idx_book_status是组合索引，专门服务「某读者当前在借几本」「某本书是否在架」这两类高频查询，比单列索引省事。fine用DECIMAL(8,2)而不是 FLOAT，金额计算不能有浮点误差。外键用默认的 RESTRICT，图书和读者不允许在有借阅记录的情况下被直接删除，这是业务上的硬约束。return_date允许为空，因为借出状态下它还没有值，这一点和类图里属性标注的可空性要对得上。

4. 顺序图、协作图、活动图、状态图：借书与还书两条主线怎么拆

4.1 借书用例规约拆成消息序列：六条基本流对应哪几根生命线

顺序图的输入就是用例规约的基本事件流，输出是一条条消息。资料里借书流程的生命线有六根：管理员、借书界面、借书处理管理器、读者、图书、借阅信息。这个划分是对的，界面负责显示、管理器负责逻辑、读者和图书是被查询的实体、借阅信息负责记录。

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