图书管理系统课程设计：需求建模、数据库设计与借阅并发实现

简介：《软件工程课程设计图书管理系统》是一份面向高校软件工程课程设计、项目实训与课程报告撰写的完整文档资料，适合需要完成图书管理系统选题、需求建模和系统设计的学生及指导教师参考。文档围绕管理员与读者两类参与者展开，依次覆盖绪论、需求分析、系统设计等章节，包含项目背景与编写目的、功能需求、用例图、用例一览表、用例规约、时序图、系统实体总类图、E-R图、数据库表设计以及登录注册、管理员操作、读者管理等界面设计与代码设计，可帮助读者梳理从需求收集、建模到数据库与界面落地的完整流程。资源包内含1个doc文件，压缩包约455KB，以Word文档形式集中呈现课程设计报告正文，便于直接阅读、摘录和二次整理。目前已有157人学习，适合作为课程设计选题参考、报告框架模仿与答辩材料准备的案例资料，也能为图书管理系统的需求分析、数据库设计和界面规划提供可复用的思路。

1. 一份图书管理系统课程设计文档，真正的交付物是什么

每年到学期后半段，总会有人拿着一份叫「软件工程课程设计图书管理系统.doc」的文件问我：这份文档到底要写到什么程度才算过关。常见的翻车现场是这样的——文档里用例图画得挺漂亮，一到答辩现场，老师随手点开系统，问「你这里借书失败了会怎样」，代码里只有一个System.out.println("借书失败")，文档和实现对不上，分数直接掉一档。

图书管理系统这个题目被选烂了，但它的坑不在业务复杂度，而在于它同时要求学生交付三样东西：一份能自证设计过程的文档、一套能跑起来的最小系统、一份能被追问的测试记录。软件工程课程设计考的就是这三样能不能闭环。写这份文档的人，可能是刚学完软件工程导论、第一次画用例图的大三学生，也可能是毕业设计选题定成图书管理系统、需要把详细设计写扎实的人。这篇内容按「需求建模 → 数据库设计 → 核心代码 → 测试与答辩」的顺序走一遍，每一步都给可直接抄的结构、SQL 和代码，语言上以 Java 为主线，Python 和 PHP 的等价写法也会点到，方便按课程要求换技术栈。

2. 图书管理系统用例图与需求规约：从角色清单到可答辩的用例表

需求分析这一章是文档里最容易被写虚的部分。很多人的做法是把「读者可以借书、还书、查询图书」写成一段话，再贴一张全是气泡的用例图，看着热闹，实际没有一个用例能被验证。要经得起追问，得像写接口文档一样写需求。

2.1 先定角色与用例边界，别让用例图变成菜单截图

图书管理系统的参与者数量要克制。把「超级管理员」和「普通管理员」拆成两套角色，是新手最容易做的过度设计；而把「借书」「还书」「续借」「预约」都塞进一个「图书流通」用例，又会让后续的详细设计无话可写。常见做法是固定三类参与者，边界清晰、职责不重叠：

画用例图时有两个硬规则：一是所有用例都必须能追溯到某个参与者的某个明确目标，二是系统边界框里不允许出现「登录」这种技术动作作为独立用例——登录是前置条件，不是业务价值。把这两条守住，用例图就不会退化成菜单结构图。另外一个提醒：图书管理员和系统管理员可以共用一套登录入口，但用例图中不要画出继承箭头然后不加说明，答辩时这是高频提问点。

2.2 用例规约的字段设计：把借书这个用例拆到操作级

用例图只说明「谁做什么」，用例规约才说明「怎么做、做不成怎么办」。软件工程课程设计里，规约写满三个主用例就够撑起一章：借书、还书、图书入库。字段不用贪多，但异常流必须写。下面这份 YAML 化的规约模板可以直接搬到文档附录里，也方便后续生成需求追踪矩阵：

# 用例规约模板：每个字段都对应文档里的一个表格列 use_case: id: UC-02 # 编号，后续追踪矩阵靠它对齐 name: 借阅图书 actor: 读者 goal: 把在架副本借给读者，生成一条状态为 BORROWED 的借阅记录 preconditions: - 读者已登录且账号状态为正常 - 读者当前在借数量小于其读者类型对应的可借上限 main_flow: - 读者输入书名/ISBN/作者进行检索，系统返回在架副本列表 - 读者选择目标副本，提交借阅申请 - 系统校验读者状态、借阅额度、副本状态 - 系统计算应还日期 due_date = 当前日期 + 借阅天数 - 系统写入借阅记录，并把副本状态置为 BORROWED - 系统向读者返回借阅成功与应还日期 alt_flows: - 条件: 副本状态不是 IN_SHELF 处理: 提示"该副本已被借出或下架"，返回检索列表 - 条件: 在借数量已达上限 处理: 提示"已达可借上限 N 本"，引导先归还 - 条件: 读者存在未缴罚款 处理: 拦截借阅，跳转罚款缴纳页 postconditions: - 借阅记录表新增一行，状态 BORROWED - 副本状态变为 BORROWED，副本与借阅记录互相可查

这里的due_date不是冗余字段。很多实现只在借阅记录里存借出日期和天数，运行时再算应还日期，结果改一次借阅规则历史记录全变，报表对不上。把应还日期落库，是让超期统计和罚款计算可复现的关键设计。

2.3 借书与还书流程图的画法：只画两条主链

流程图不需要把系统每个动作都塞进去，文档里画两张就够：一张借书，一张还书。每张图控制在 8 到 12 个节点，判定点显式标出。借书主链的判定点按顺序是：读者是否登录 → 账号是否正常 → 是否有未缴罚款 → 在借数是否超限 → 副本是否在架 → 是否重复借同一副本 → 是否预约了他人副本。这七个判定点写清楚，用例规约里的异常流就都有出处，代码里的分支也就一条条对得上。

还书这条链更容易被写漏：还的是不是本馆的书（副本条码能否识别）、是不是自己的借阅记录、是否超期、超期天数怎么算、罚款是否当场缴、副本是否直接回到在架状态还是先进待上架区。最后这个「待上架」状态，是区分课程设计及格线和良好线的小细节——它对应真实图书馆的分拣流程，写进文档是加分项。

2.4 需求追踪矩阵：让文档每一节都能被反向检查

追踪矩阵是软件详细设计章节的核心表格，它的作用是让老师不用翻代码就能判断你有没有漏做需求。

这张表建议在文档定稿前最后再写一遍。写的过程就是自检的过程：如果某个用例找不到对应的类，说明详细设计缺了一块；如果某个类找不到测试用例，答辩时被问到「这个功能你测过吗」就答不上来。

3. 图书管理系统数据库设计：从 ER 图到可执行建表语句

数据库这一章最常见的写法是画一张 ER 图、列几个实体，然后直接跳到界面截图。中间缺了最关键的一步：把实体拆成能建表的字段，并解释每一个字段为什么这么定。这一章按「概念模型 → 逻辑模型 → 物理模型」走，最后给出能直接跑的 MySQL 语句。

3.1 书目与副本分离：数据建模的第一道坎

《数据结构》馆藏 5 本，这 5 本共享同一个 ISBN、同一个书名，但条码不同、状态不同、借出时间不同。如果把书名和条码放在一张表里，就会出现同一本书录 5 行的冗余；如果只留一张表，又没法记录某一本的具体状态。正确做法是拆成book（书目）和book_copy（副本）两张表，一对多关系。这是整个设计里唯一不能省的范式拆解，也是答辩时最容易被问到「为什么不做成一张表」的地方。

读者类型这张表别用枚举硬编码在代码里。reader_type表里放borrow_limit和borrow_days两个字段，借阅规则就从代码里搬到了数据里，系统管理员配规则的用例才有落点。

3.2 MySQL 建表语句与索引取舍

下面这段 DDL 可以直接导入 MySQL 8 执行，字段类型按常见馆藏规模（十万级副本、百万级借阅记录）选，不需要再调。

-- 书目表：冗余保存可借副本数，用触发器或应用层维护，避免每次检索都做 count CREATE TABLE book ( id BIGINT PRIMARY KEY AUTO_INCREMENT, isbn VARCHAR(20) NOT NULL, title VARCHAR(200) NOT NULL, author VARCHAR(100) NOT NULL, publisher VARCHAR(100), category_id INT NOT NULL, total_copies INT NOT NULL DEFAULT 0, available_copies INT NOT NULL DEFAULT 0, KEY idx_title (title), -- 支持按书名前缀检索 KEY idx_category (category_id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 副本表：条码全局唯一，status 用字符串而非数字，日志可读性优先 CREATE TABLE book_copy ( id BIGINT PRIMARY KEY AUTO_INCREMENT, book_id BIGINT NOT NULL, barcode VARCHAR(32) NOT NULL, location VARCHAR(50), -- 馆藏位置，如 A区-3排-2层 status VARCHAR(16) NOT NULL DEFAULT 'IN_SHELF', version INT NOT NULL DEFAULT 0, -- 乐观锁版本号 UNIQUE KEY uk_barcode (barcode), KEY idx_book_status (book_id, status), CONSTRAINT fk_copy_book FOREIGN KEY (book_id) REFERENCES book(id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; -- 借阅记录：应还日期落库，归还日期为空表示未还 CREATE TABLE borrow_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, reader_id BIGINT NOT NULL, copy_id BIGINT NOT NULL, borrow_date DATE NOT NULL, due_date DATE NOT NULL, return_date DATE NULL, renew_count INT NOT NULL DEFAULT 0, status VARCHAR(16) NOT NULL DEFAULT 'BORROWED', KEY idx_reader_open (reader_id, return_date), -- 快速统计在借数量 KEY idx_due (due_date, status) -- 供超期扫描任务使用 ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

参数和索引的取舍说明：idx_reader_open用的是(reader_id, return_date)而不是(reader_id, status)，因为「统计某读者当前在借数量」这条 SQL 的条件是return_date IS NULL，走前者的区分度更高；idx_due的列顺序把due_date放在前面，是因为超期扫描任务按日期范围扫描，选择性最好。version字段先加上，后面第 4 章讲并发时要靠它。

3.3 借阅状态机与超期判定

副本状态和借阅记录状态是两套独立的状态机，不要混用一张状态表。副本状态流转是IN_SHELF → BORROWED → IN_SHELF，中间插入PENDING_SHELF（还回待上架）和LOST（丢失）两个终态分支；借阅记录状态是BORROWED → RETURNED，超期不改变状态，只由due_date < CURRENT_DATE AND return_date IS NULL推导，罚款则单独落fine表。

注意：不要把「超期」做成一个需要定时任务去写的状态字段。定时任务只负责生成罚款记录和推送通知，状态判定永远由due_date实时推导，否则任务挂掉一天，数据就永久错了。

重复借阅的防护不要只靠代码里的 if 判断。在应用层校验之前，先用一条查询兜底：SELECT COUNT(*) FROM borrow_record WHERE reader_id=? AND copy_id=? AND return_date IS NULL，返回大于 0 就拒绝。这个查询走idx_reader_open的部分前缀，成本极低，却能挡掉绝大多数重复提交。

4. 借阅核心功能的 Java 实现：事务、并发与超期计算

文档里的详细设计写到类图和方法签名往往就停了，代码留到最后几天补。更稳的顺序是先把借阅这一个核心用例从接口到 SQL 打通，其余功能照着套。这一章给出一套 Spring Boot 的分层写法，重点在两个地方：事务边界怎么划、并发借同一本书怎么处理。

4.1 接口清单与分层职责

接口按资源划分，不要按页面划分。页面上一个「借阅」按钮可能调用两个接口，那是前端的事。

分层上，Controller 只做参数校验和结果包装，Service 承担事务与业务规则，Mapper 只写 SQL。业务异常统一用BizException抛出，由全局异常处理器转成带错误码的响应，这样前端能按错误码显示不同提示，测试用例也能按错误码断言。

4.2 借书事务：先锁副本还是先查读者

顺序很关键。先查读者再锁副本，两台并发请求可能都通过了额度校验，最后多借出一本；先锁副本再查读者，锁的持有时间变长但不会出错。课程设计的数据量下，选择后者更安全。

@Transactional(rollbackFor = Exception.class) public BorrowResult borrow(Long readerId, String barcode) { // 1. 行锁锁定副本，两个并发请求在这里串行化 BookCopy copy = copyMapper.selectForUpdate(barcode); if (copy == null || !"IN_SHELF".equals(copy.getStatus())) { throw new BizException("COPY_NOT_AVAILABLE", "该副本不可借"); } // 2. 校验读者状态与在借额度，额度从 reader_type 表读取而非硬编码 Reader reader = readerMapper.selectById(readerId); if (reader == null || reader.getStatus() != 1) { throw new BizException("READER_FROZEN", "读者账号异常"); } ReaderType type = readerTypeMapper.selectById(reader.getTypeId()); int holding = borrowMapper.countHolding(readerId); // 走 idx_reader_open if (holding >= type.getBorrowLimit()) { throw new BizException("LIMIT_EXCEEDED", "已达可借上限 " + type.getBorrowLimit()); } // 3. 应还日期落库，后续所有超期判断都以它为准 LocalDate today = LocalDate.now(); BorrowRecord record = BorrowRecord.builder() .readerId(readerId).copyId(copy.getId()) .borrowDate(today).dueDate(today.plusDays(type.getBorrowDays())) .status("BORROWED").build(); borrowMapper.insert(record); // 4. 更新副本状态与版本号，affected rows 为 0 说明被其他事务改过 if (copyMapper.markBorrowed(copy.getId(), copy.getVersion(), record.getId()) == 0) { throw new BizException("CONCURRENT_MODIFIED", "副本状态已变更，请重试"); } bookMapper.decreaseAvailable(copy.getBookId()); // available_copies - 1 return new BorrowResult(record.getId(), record.getDueDate()); }

逻辑说明：第 1 步的selectForUpdate对应 SQL 是SELECT * FROM book_copy WHERE barcode = #{barcode} FOR UPDATE，它在 InnoDB 下对唯一索引命中的那一行加排他锁，事务提交前其他事务只能等；第 4 步的markBorrowed带version条件，即UPDATE book_copy SET status='BORROWED', current_borrow_id=?, version=version+1 WHERE id=? AND version=? AND status='IN_SHELF'，这是双保险——万一有人绕过了第一步的行锁（比如在别的入口直接更新副本），版本号不匹配也会拦住。available_copies用自减而不是重新 count，是为了让检索接口不承担统计开销，代价是需要保证增减成对出现，归还和注销时都要记得加回去。

4.3 超期罚款计算与定时扫描

罚款金额不要写在 Java 常量里。规则表fine_rule放daily_amount（每日金额）、max_amount（封顶金额）、grace_days（宽限天数）三个字段，超期天数按ChronoUnit.DAYS.between(dueDate, returnDate)算，再减去宽限天数。封顶很必要，否则一本超期两年的书能算出吓人的数字，演示时不好看也不好解释。

扫描任务每天凌晨跑一次，把已超期但没生成罚款的记录补齐：

-- 每天 01:00 执行：为超期未还且尚无罚款行的记录插入罚款（金额在应用层按规则计算） INSERT INTO fine (record_id, reader_id, amount, status, created_at) SELECT r.id, r.reader_id, 0, 'UNPAID', NOW() FROM borrow_record r LEFT JOIN fine f ON f.record_id = r.id WHERE r.return_date IS NULL AND r.due_date < CURRENT_DATE AND f.id IS NULL;

金额留到应用层填，是因为它依赖fine_rule的当前值和读者类型，放在 SQL 里会让规则变更时难以追溯。这条语句用LEFT JOIN ... IS NULL做幂等，任务重复执行不会产生重复罚款行，这是课程设计里很容易被忽略但很好讲的一个细节。

4.4 Python 和 PHP 的等价写法对照

如果课程要求用 Python 或 PHP，事务逻辑完全一致，差别只在语法。Python 用 Flask + SQLAlchemy 时，锁要靠显式语句：

# SQLAlchemy 写法：with_for_update() 对应 SELECT ... FOR UPDATE with db.session.begin(): copy = db.session.query(BookCopy).filter_by(barcode=barcode) \ .with_for_update().one_or_none() if copy is None or copy.status != 'IN_SHELF': raise BizError('COPY_NOT_AVAILABLE') # 后续校验与写入同上，事务由 begin() 上下文统一提交或回滚

PHP 用 PDO 时要手动关掉自动提交，否则FOR UPDATE的锁会立刻释放：$pdo->beginTransaction();之后执行SELECT ... FOR UPDATE，再commit()。这一点在 PHP 图书管理系统的实现里出错率最高，因为 PDO 默认是自动提交模式，代码看起来没错，压测时才会出现同一本书被借两次。

5. 让文档与代码对得上：测试用例、演示脚本与答辩自检

前面几章把需求和实现写通了，最后一公里是证明它真的能跑。课程设计的评分表里，测试与验证通常占 15% 到 20%，但这部分恰恰是文档里最空洞的——满篇「系统运行正常」。把它写实，成本很低。

5.1 测试用例表：每个用例至少一条异常流

测试用例按第 2 章的追踪矩阵编号，正常流和异常流各占一半。异常流才是区分度所在。

并发场景单独列一条：开两个线程同时借同一本在架副本，断言只有一个成功、另一个拿到异常，且available_copies最终只减 1。这条用例写进文档，基本能覆盖老师对「你有没有想过并发」的追问。

5.2 演示脚本：答辩前十分钟的自检流程

别在答辩现场手点界面验证。准备一段脚本，按顺序把主链跑一遍，输出对得上就行。

# 1. 借书：预期返回 borrowId 与 dueDate curl -s -X POST localhost:8080/api/borrows \ -H "Content-Type: application/json" \ -d '{"readerId":1001,"barcode":"BC000123"}' # 2. 重复借同一副本：预期返回 COPY_NOT_AVAILABLE curl -s -X POST localhost:8080/api/borrows \ -H "Content-Type: application/json" \ -d '{"readerId":1001,"barcode":"BC000123"}' # 3. 归还：预期返回超期天数与罚款金额 curl -s -X PUT localhost:8080/api/borrows/1/return

先把第一条手工改成超期状态（直接UPDATE borrow_record SET due_date = DATE_SUB(CURDATE(), INTERVAL 10 DAY) WHERE id = 1;），再跑第三条，罚款逻辑就能当场演示，不用等真实的十天。

5.3 文档与代码对齐的三个检查点

定稿前做三件事。第一，把第 2 章追踪矩阵里的每个类名，用 IDE 全局搜索一遍，确认类和方法真实存在且命名一致，改名后忘了同步文档是最高频的低级失分点。第二，把用例规约里的每个错误码，在代码里搜一遍，确认BizException的第一个参数和文档里写的字符串完全相同。第三，把文档中所有图表的编号重排一遍，并确保正文里每处「见图 3-2」指向的图确实存在——.doc里插入图片后重新排版，编号错位几乎必然发生。

答辩被问到「这个功能如果数据量涨十倍会怎样」时，别空谈优化。直接说出具体的量级判断：borrow_record到百万行时，idx_reader_open仍能覆盖在借数量统计；真正会先出问题的是按书名模糊检索，因为idx_title对%关键词%这种前导通配符失效，那时候要换的是全文索引或者前缀检索方案。把这句话准备在手边，比任何泛泛的性能描述都有说服力。

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