企业官网建设流程全解析

简介：《图书管理系统 软件工程》是一份面向软件工程课程设计、毕业设计入门与系统分析学习者的项目文档，围绕图书管理业务展开需求分析、系统设计、数据库设计与实现测试等环节，适合需要参考规范化开发流程、理解UML建模与VB6.0实现思路的读者。压缩包内仅含1个doc文件，约535KB，篇幅集中于课程设计报告式内容，便于直接查阅与整理。目录涵盖绪论与关键技术介绍、系统目标与性能要求、读者借阅与管理员维护等用例图、时序图、类图及类间关系，并给出数据库建立、E-R图、数据表创建与连接方式，随后说明工程项目创建、模块与类模块添加、登录窗体等界面设计。已有441人学习，可作为图书管理系统课程设计的需求分析、建模和数据库设计参考底稿。

1. 选题与交付压力：图书管理系统为什么要在两周内跑通「图—表—码」闭环

「图书管理系统」在软件工程课程设计的选题表里出现的频率，大概和学生成绩管理不相上下。真正让人为难的从来不是选题，而是时间：两周之内要交出一份从用例图、类图、时序图、E-R 图一路自洽到建表脚本和可运行窗体的完整文档。我见过大量方案栽在同一个地方——UML 图画得很漂亮，数据库表却对不上号；文档里写着三层架构，工程目录里只有一个窗体文件。这套基于 VB6.0 + SQL Server 2000 + Rational ROSE 的方案看起来不新，优势恰恰在于每个图形符号都能在代码里找到落点，答辩时经得起一句句追问。适合正在做毕设或课程设计、需要一份能照着搭、也能照着讲的完整软件工程文档的人。

2. 需求分析：三类参与者、三张用例图与可验收的功能条款

需求分析这一章最容易写成散文。翻十份课程设计，八份都在复述「系统应方便快捷」，答辩老师扫一眼就翻过去了。真正有价值的是把需求压成可以打勾的条款，让后面每一张图、每一张表都能追溯回某一句话。

2.1 三类参与者的诉求边界先划清

先不做图，先用三行字把「谁干什么」写死：读者查书、查自己的借阅记录、续借、借书、还书；图书管理员处理借书和还书；系统管理员维护读者信息、图书信息和系统状态。这三行是后面所有图形和表结构的源头，改一个字就要往下游同步。

这三类人的权限边界必须在这一步就明确，否则到了编码阶段会出现读者菜单里混进「删除图书」这种尴尬。我的做法是给每个参与者列一张两列表：左边是他能做的动作，右边是他绝对不能碰的动作。读者的禁止项包括修改图书状态、删除任何记录；图书管理员不能新增读者，也不能删除书目；系统管理员不做具体的借还操作。禁止项写进需求文档之后，登录模块的角色判断就有了依据，不用等做到一半再回头补。

2.2 三张用例图：读者请求服务、借还书处理、系统维护

用例图按参与者拆成三张，不要贪图省事画成一张大图。三张图各自闭合，答辩时指哪打哪，也方便分别对应后面的三个主菜单。

读者的用例包含系统登录、查询个人信息、查询图书信息、查询借阅信息、图书续借、借阅图书、图书归还。图书管理员的用例只有两个，处理图书借阅和处理图书归还，看起来单薄，但它是整个系统里唯一涉及并发和事务的地方，权重不低。系统管理员的用例是增加书籍、删除或更新书籍、添加读者信息、删除或更新读者信息。

画的时候有个细节常被忽略：用例之间不要滥用包含和扩展关系。只有当两个用例确实共享一段必须复用的步骤时才用包含，比如「借阅图书」和「图书续借」都包含「校验读者状态」。为了好看硬拉几条虚线过去，老师第一个问的就是「这条 extend 的触发条件是什么」，答不上来反而扣分。

2.3 性能要求不能只写形容词

原始需求里列了一串词：正确性、可靠性、效率、完整性、易使用性、可维护性、可测试性、复用性、安全保密性、可理解性、可移植性、互联性。这十二个词写在文档里没问题，但它们没法验收，因为它们没有阈值。

我一般会把其中能落地的四五条量化：书目表累积到一万条记录时，按书名或作者模糊查询的结果要在两秒内返回；三个终端同时发起借书请求，同一本书不允许出现两条有效借阅记录；从点击借书按钮到弹出成功提示，正常网络环境下不超过三秒；任意一张核心表被误删单条记录后，能从备份脚本恢复到前一天的状态。剩下那些确实不好量化的，就写清楚保障手段，比如可维护性靠统一的数据库连接模块保证，可移植性靠把所有连接串集中在一个配置文件里保证。写清楚手段，比罗列形容词有说服力得多。

2.4 时序图：以系统管理员添加图书为例

时序图不必每张都画，挑最能说明问题的那几条。系统管理员添加图书这条链路比较典型，涉及查重、写入、返回三步，正好覆盖「先查后写」这个通用模式。

交互顺序是这样：管理员在书目维护窗体点击「添加」，窗体向控制层发出 add item() 请求；控制层拿到书名后调用 find(string)，拿书名去书目表里查是否已存在同名书目；数据层返回查找结果，如果存在则提示重复并终止，如果不存在则调用 create(integer, title) 生成新书目记录并更新该类书的数量；最后把成功与否回传给窗体。这里的 find 和 create 之间必须有一次判空，否则同一种书会被反复插入，库存数量越加越多，到后期书目列表里全是重复行。剩下的几条时序图按同样思路补：添加读者、删除或更新图书、删除或更新读者、处理借书、处理还书、读者查询图书信息。每条图的消息编号要连续，返回消息用虚线，别把同步调用和异步消息混在一起。

3. 系统设计：六个核心类、时序图与三层架构的对应关系

需求定完边界，接下来要解决的是「这些东西在代码里长什么样」。类图是这一章的核心，但类图画完不是挂着好看，它得能直接翻译成表结构，否则就成了摆设。

3.1 六个核心类与各自的职责

系统里立得住的核心类有六个：item（书目）、title（书名，也就是书的品种）、loan（借出记录）、reader（读者）、administrator（系统管理员）、librarian（图书管理员）。

reader 类持有读者编号、姓名、性别、年龄、已借书数目、联系电话、地址，操作有读者信息查询、图书信息查询、借阅信息查询、借书、还书、续借。librarian 类持有工作编号、姓名、地址，操作是借书处理和还书处理。administrator 类同样持有编号、姓名、地址，操作是添加、删除、更改信息。item 类持有图书书目和图书类别，操作是增删改查。title 类持有图书名称、作者、ISBN、价格、出版社、数目。loan 类持有已借出图书的名称、借出时间和图书编号，操作是增删改查。

这里有个容易犯的错：把「书的品种」和「书的副本」合成一个类。一个 ISBN 对应五本实体书，五本都能独立借出、独立归还、独立破损。合成一个类之后，借出一本就只能把整个品种标成借出，剩下四本没法借。所以 title 和 item 必须分开，比例关系是一对多。

3.2 类关系到表关系：一对多怎么落成外键

类图里的连线最终要变成数据库里的外键。reader 和 loan 是一对多，一个读者可以有多条借阅记录，落到表上就是 borrow 表里存 reader 的证件号作为外键。title 和 item 是一对多，book 表用一个自增主键区分每一本实体书，ISBN 只做普通字段。

一条经验：一对多的「多」那边永远放外键。有些同学把借阅记录列表塞进读者表，用逗号拼接一长串编号，查询的时候靠字符串切割。这种做法在演示时能跑通，一旦要查「这本书现在在谁手上」就得全表扫描加字符串匹配，而且第一个字段长度溢出就崩了。关系型数据库的规范化不是形式主义，是把这类查询成本提前摊掉。

多对多的情况这套系统里不多，但书和分类之间勉强算一个：一本书属于一个分类，一个分类下有多个书。严格说这是一对多，分类号作为外键放在 book 表就够，不需要中间表。如果需求文档里写了「一本书可以同时属于多个分类」，那才需要 bookkind 中间表，这一点要在设计阶段确认清楚，不要到建表时才改。

3.3 三层架构在 VB6 工程里到底怎么摆

三层架构写到文档里只有三行字，落到 VB6 工程里要有明确的目录和文件对应，否则老师追问「你的业务层在哪个文件」会答得很虚。

表现层就是所有 frm 文件，frmLogin 负责登录，frmMain 是主菜单，frmBookQuery、frmBorrow、frmReturn 分别对应查询、借书、还书。这一层只做三件事：收集控件输入、调用业务层函数、把返回值显示到控件上，不写 SQL。

业务层用标准模块 bas 和类模块 cls 承担。basBorrow 里放借书校验和库存扣减的函数，basPunish 里放超期天数计算和罚款金额计算，clsReader 里封着装读者对象的属性读写。这一层接收表现层传来的参数，拼装业务规则，再调用数据层。

数据层只有一个 basDB 模块，对外暴露一个全局连接对象和若干查询函数。所有 SQL 语句集中在这一层，换数据库只需要改这一个文件。

把这条线摆清楚，好处不只是答辩好讲。开发到第三天你一定会遇到「同一个查询在三个窗体里各写了一遍，改字段名要改三处」的局面，有了分层，改动点收敛到一处。

3.4 活动图与借还书状态流转

书的实体状态只有三个：在架、借出、下架。所有业务动作都是在三个状态之间迁移。

借书：从在架到借出，前置条件是读者可借数量未超上限、无超期未还记录、书状态为在架。还书：从借出到在架，同时写回收日期、判断是否超期、超期则生成罚款记录。续借：状态不变，只改应还日期，且只能续借一次。下架：从在架到下架，仅系统管理员可操作，已被借出的书不能下架。

这四个迁移写进文档时要配一张状态表，标明触发事件、前置条件和后置结果。表比图更实用，因为测试用例可以直接照着这张表逐行设计。

4. 数据库与编码落地：八张表的建表脚本、ADO 连接与登录窗体

到这一章，图纸要变成能跑的东西。数据库设计得对不对，决定了后面编码阶段是顺利还是天天救火。

4.1 八张表的分工与主键设计

系统需要八张表：book（书籍）、borrow（借书）、login（登录）、punishment（罚款）、user（读者信息）、libraryer（图书管理员）、admin（系统管理员），外加一张 bookkind（图书分类）承接分类号和分类名。

这里有两处我通常会和原始设计不一样，理由很实在。第一，书名不适合做主键，同名书（比如两版同名的教材）根本录不进去，所以 book 表加一个自增 book_id 做物理主键，bannercode 保持唯一约束。第二，借书表不能拿读者证件号做主键，一个读者同时借五本书就冲突了，主键要么用流水号，要么用证件号加图书编号的联合主键。这两点在答辩时属于高频追问点，提前改掉能省很多解释。

4.2 建表脚本：book 与 borrow 两张核心表

-- 书籍表：物理主键用自增，业务编号 bannercode 加唯一约束 CREATE TABLE book ( book_id INT IDENTITY(1,1) NOT NULL, -- 自增主键，解决同名书问题 bookname VARCHAR(30) NOT NULL, -- 书名 bannercode VARCHAR(30) NOT NULL, -- 图书编号，业务唯一 kindno VARCHAR(20) NOT NULL, -- 分类号，外键指向 bookkind author VARCHAR(10) NULL, -- 作者 publishing VARCHAR(30) NULL, -- 出版社 publishtime DATETIME NULL, -- 出版日期 putintime DATETIME NULL, -- 入库日期 price NUMERIC(10,2) NULL, -- 价格 state VARCHAR(4) NOT NULL DEFAULT '在架', -- 在架/借出/下架 introduction VARCHAR(50) NULL, -- 简介 CONSTRAINT pk_book PRIMARY KEY (book_id), CONSTRAINT uq_book_code UNIQUE (bannercode) ); -- 借阅表：主键用流水号，读者与书各自是外键 CREATE TABLE borrow ( loan_id INT IDENTITY(1,1) NOT NULL, -- 借阅流水号 user_cardno VARCHAR(20) NOT NULL, -- 读者证件号 bannercode VARCHAR(30) NOT NULL, -- 图书编号 borrowdate DATETIME NOT NULL, -- 借出日期 receivedate DATETIME NULL, -- 应还/已还日期 renew VARCHAR(2) NOT NULL DEFAULT '否', -- 是否已续借 CONSTRAINT pk_borrow PRIMARY KEY (loan_id), CONSTRAINT fk_borrow_user FOREIGN KEY (user_cardno) REFERENCES user(user_cardnumber), CONSTRAINT fk_borrow_book FOREIGN KEY (bannercode) REFERENCES book(bannercode) );

关于这些字段：bannercode 长度取 30 是因为不少课程设计的编号规则里带年份和分类前缀，短了后期会溢出；state 用四个字符存中文是为了在 VB6 的表格控件里直接显示，省去映射转换；receivedate 允许为空，因为借出时它只是「应还日期」，还书时才写成实际归还时间，一个字段承担两个语义是这类系统的常见简化，写文档时要注明，否则测试阶段会出现「还没还书怎么有归还日期」的疑问。

4.3 E-R 图到关系模式：冗余字段的取舍

E-R 图里的实体和联系转成表之后，要不要在 borrow 表里冗余存书名，是个需要表态的问题。原始设计里借书信息确实同时记了读者姓名和书籍名称。

我的处理是：冗余存，但只作为展示快照，所有判断逻辑一律走外键。理由是借阅查询页面要显示的书名和读者名，如果每行都去做关联查询，一张一万条的借阅表在低配机器上翻页会明显卡顿；而快照字段一旦参与业务判断，就会出现「书改名了，历史记录对不上」的麻烦。所以写清楚：显示用它，逻辑不用它。这个取舍在文档里说明白，比单纯画一张漂亮的 E-R 图更能体现设计思考。

4.4 VB6 里用 ADO 连上 SQL Server

连接代码集中在一个标准模块里，全工程共用，不要在十二个窗体里各写一份不同的连接串。

' 模块 basDB.bas：全局数据库连接与通用查询 Public gConn As ADODB.Connection Public Function OpenDB() As Boolean On Error GoTo ErrHandler Set gConn = New ADODB.Connection ' Provider 指定驱动；Data Source 是实例地址；Initial Catalog 是库名 gConn.ConnectionString = "Provider=SQLOLEDB.1;Persist Security Info=False;" & _ "User ID=sa;Password=;Initial Catalog=LibraryDB;" & _ "Data Source=127.0.0.1" gConn.CursorLocation = adUseClient ' 客户端游标，窗体关闭后记录集仍可读 gConn.Open OpenDB = True Exit Function ErrHandler: MsgBox "数据库连接失败：" & Err.Description, vbCritical, "提示" OpenDB = False End Function Public Function QueryRS(ByVal sql As String) As ADODB.Recordset Dim rs As New ADODB.Recordset rs.Open sql, gConn, adOpenStatic, adLockReadOnly ' 只读静态游标，适合列表展示 Set QueryRS = rs End Function

说明几点。CursorLocation 设为 adUseClient 之后，记录集的数据会一次性拉到本地，界面绑定和翻页都更顺，代价是数据量大时内存占用高，书目一万条以内问题不大。adOpenStatic 加 adLockReadOnly 用于所有列表展示场景，需要改数据时另开一个可更新的记录集，不要图省事全用 adLockOptimistic，学生在单机上测不出问题，多终端一测就露馅。

连接串里出现明文 sa 账号和空密码，这是课程设计的常见妥协。文档里必须写明生产环境应改为独立账号加密码并限制权限，否则答辩时被问到安全性会很难接。

4.5 登录窗体的详细设计：从控件到校验顺序

登录窗体看似简单，却是整个系统里唯一同时涉及账号校验、角色分流和全局状态写入的地方，值得单独画一页详细设计。

界面上放两个标签、两个文本框（txtUser、txtPwd）、两个按钮（cmdOK、cmdCancel）。密码框的 PasswordChar 属性要设置，回车键通过窗体的 Default 属性绑定到确认按钮。校验顺序固定为：非空校验、账号存在性校验、密码匹配校验、角色读取、分流跳转。顺序不能反，先查密码再查账号存在性，会给暴力尝试提供「账号不存在」和「密码错误」的区分信息。

' 窗体 frmLogin：确认按钮逻辑 Private Sub cmdOK_Click() Dim rs As ADODB.Recordset Dim sql As String If Trim(txtUser.Text) = "" Or Trim(txtPwd.Text) = "" Then MsgBox "账号和密码不能为空", vbExclamation, "提示" Exit Sub End If ' 单引号转义，避免 ' or '1'='1 这类输入直接绕过 sql = "SELECT user_name, psw, role FROM login WHERE user_name='" & _ Replace(Trim(txtUser.Text), "'", "''") & "'" Set rs = QueryRS(sql) If rs.EOF Then MsgBox "账号不存在", vbExclamation, "提示" ElseIf Trim(rs("psw")) <> Trim(txtPwd.Text) Then MsgBox "密码错误", vbExclamation, "提示" Else gRole = Trim(rs("role")) ' 全局变量，主窗体据此决定显示哪套菜单 gUser = Trim(rs("user_name")) Unload Me frmMain.Show End If rs.Close Set rs = Nothing End Sub

role 字段是我在原始登录表基础上补的。原设计里 login 表只有用户名和密码，三类角色共用一张表却没有任何字段区分身份，读者登录进来看到的就是管理员菜单。这个缺口不补，后面所有权限判断都无从谈起。role 取值通常是 reader、librarian、admin 三个字符串，主窗体 Load 事件里按它逐个设置菜单项的 Enabled 属性。

5. 常见问题排查：从登录角色到借书事务的五处翻车点

这一章是我这些年看课程设计和带新人时反复遇到的坑，几乎每年都有人踩。按「现象—原因—解决」的顺序写，对着自己的文档查一遍，能省掉答辩现场一半的尴尬。

5.1 三类用户登录后看到同一套菜单

现象：读者登录进去，菜单里有「删除图书」「添加读者」，点下去还能用。

原因：登录表只有用户名和密码，没有角色字段，主窗体也没做权限判断，登录成功后无条件显示全部菜单。更深一层的原因是需求阶段没写「禁止项」，只写了「能做什么」。

解决：login 表补 role 字段，取值限定三个；主窗体 Load 事件里遍历菜单控件，按角色设置 Enabled；关键操作在业务层再做一次角色校验，别只依赖界面隐藏——学生演示时常用快捷键或直接调用函数绕过界面。

5.2 同一种书只能录一次

现象：系统管理员录入第二版同名教材时提示主键冲突，换一个字才能存进去。

原因：book 表拿书名做物理主键。书名在现实中完全不唯一，同一本书不同出版社、不同版次都同名。

解决：加自增 book_id 做物理主键，书名降为普通字段，业务编号 bannercode 加唯一约束。已经建好表的需要做一次数据迁移：新建表、导入旧数据、补 book_id、重建外键，别直接改字段，容易把关联关系弄断。

5.3 一个读者借了五本书，记录只剩一条

现象：借阅查询页面里，读者明明借了五本，只显示最后一条。

原因：borrow 表用读者证件号做单字段主键，插入第二条借阅记录时主键冲突，被错误处理逻辑吞掉了，或者干脆覆盖了前一条。

解决：主键改成自增流水号，或者用证件号加图书编号组成联合主键。同时检查借书按钮的异常处理，VB6 里 On Error Resume Next 用多了会把主键冲突悄悄跳过，表面成功实际没写进去，这种「静默失败」最难查，建议只在明确知道会出什么错的语句上加错误处理。

5.4 借书成功了，库存还显示在架

现象：借阅记录已经写进 borrow 表，book 表的 state 还是「在架」，同一本书能被两个人同时借走。

原因：借书操作分两步执行——改状态、写记录，中间没有事务包起来。任一步失败，另一步已经生效。多终端环境下，两个终端同时读到「在架」，都判断可借。

解决：两步放进同一个事务，用带条件的 UPDATE 判断受影响行数，行数为零说明被别人抢先借走，立即回滚。下面这段是核心逻辑：

' 借书按钮：状态更新和记录写入必须在同一事务内 Private Sub cmdBorrow_Click() On Error GoTo ErrHandler gConn.BeginTrans ' 带 state='在架' 条件，受影响行数为 0 说明已被抢借 gConn.Execute "UPDATE book SET state='借出' WHERE bannercode='" & txtCode.Text & "' AND state='在架'" If gConn.Execute("SELECT @@ROWCOUNT").Fields(0).Value = 0 Then gConn.RollbackTrans MsgBox "该书已借出或不存在", vbExclamation, "提示" Exit Sub End If ' 应还日期按借出日加 30 天计算，续借标记默认「否」 gConn.Execute "INSERT INTO borrow(user_cardno,bannercode,borrowdate,receivedate,renew) " & _ "VALUES('" & gCard & "','" & txtCode.Text & "',GETDATE()," & _ "DATEADD(day,30,GETDATE()),'否')" gConn.CommitTrans MsgBox "借书成功", vbInformation, "提示" Exit Sub ErrHandler: gConn.RollbackTrans MsgBox "借书失败：" & Err.Description, vbCritical, "提示" End Sub

参数说明：gCard 是登录后写入全局变量的读者证件号；DATEADD(day,30,GETDATE()) 生成应还日期，30 这个数字来自借阅规则，改规则只改这一处；@@ROWCOUNT 必须在 UPDATE 之后立刻读，中间插任何语句都会失效。这段逻辑还漏了一个前置校验：读者已借数量和超期未还，应该放在事务开始之前，避免开了事务才发现不合规又要回滚。

5.5 文档里的连接代码和工程里的语言对不上

现象：数据库连接那一节贴了一段带 using 和 namespace 的代码，工程里却是 VB6 的 frm 文件，答辩时被问「这段代码怎么编译」。

原因：写文档时从网上找了段现成的 ADO 示例直接粘贴，没注意语言环境。这类问题在软件工程文档里极常见，因为文档和代码往往是两个人写的，或者一个人隔着几天分两次写的。

解决：文档里每一段代码都必须来自实际工程，哪怕是删减版也要标明出处文件和函数名。连接部分统一改成 VB6 的标准模块写法，与工程里 basDB 模块逐行对应。我一般会在文档最后加一张「代码与文件对照表」，左边写章节号，右边写工程里的文件名，交付前逐行核一遍，五分钟能挡掉一类硬伤。

6. 验收与答辩：把文档里每张图都问一遍的自查清单

交付前留出半天做一轮自查，比再改一遍界面有用。方法是把自己当成答辩老师，从文档第一页开始，凡是有图形的地方就问三个问题：这东西在数据库里落在哪张表？在代码里落在哪个函数？如果这里出错了，界面上会看到什么现象。三问答不上来的地方就是漏洞。

下面这张表是我常用的验收清单，逐项打勾，打不了勾的回去补。

答辩现场的必答题基本固定在三个。第一个是「为什么选 VB6 而不是 Java Web」，可以这样回答：课程设计的核心是把软件工程的全流程走完，从需求到用例图、类图、E-R 图再到编码测试，工具链越短，每个环节能落到的细节越多；同时说明如果要扩展成多人协作的 B/S 系统，数据层和业务层的设计可以直接平移，表现层需要重写，这样既承认了技术栈的边界，又体现了对分层的理解。第二个是「三层架构具体体现在哪」，直接翻到工程目录，指 basDB、basBorrow、frmLogin 三个文件讲数据、业务、表现的分工，不要背定义。第三个是「两个人同时借同一本书怎么办」，答案就是第 5.4 节那段带条件的 UPDATE 加事务，把 @@ROWCOUNT 的作用讲清楚即可。

有一件事我吃过亏：第一次做这类文档，把时间几乎全花在画图上，代码只是勉强跑通，结果答辩时被要求现场演示还书并解释罚款怎么算，卡了整整两分钟。从那以后我每次交付前都强制走一遍「关掉开发环境、重新打开工程、从登录到借还书完整走一遍」的流程，把能想到的异常输入都试一次，包括空输入、重复借、超期还、不存在的图书编号。这套动作只需要二十分钟，但它能把文档里所有经不起推敲的地方提前暴露出来。希望帮到你。

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