图书管理系统软件工程文档：从需求用例到八张表的完整落地

简介《图书管理系统 软件工程》面向软件工程课程设计、毕业设计及信息系统开发初学者提供一套贯穿需求分析、系统设计、数据库设计、编码实现与测试的文档范例可用于梳理图书管理业务、规划系统模块和撰写项目报告。压缩包内为1个doc文档约535KB篇幅集中、便于检索适合作为课程作业或小型管理系统的参考底稿。目前已有442人学习。文档目录覆盖绪论、系统目标与性能要求、读者借还书和系统管理员维护等用例图、时序图、类关系以及数据库E-R图、数据表创建与连接、Visual Basic 6.0和Rational Rose实现思路、登录窗体详细设计等内容可帮助读者快速搭建报告框架、对照关键建模产物并补齐需求到实现的文档链条。目录按软件工程阶段组织也适合准备课程答辩、检查文档完整性和复盘小型系统开发流程的读者参考。1. 从「三类角色、八张表」倒推这套图书管理系统软件工程文档解决什么问题「图书管理系统」这个题目每年都有人做难点在于需求分析里画的用例系统设计里有没有对应的类类图的属性数据库里有没有对应的字段。这份图书管理系统软件工程文档把 VB6.0、SQL Server 2000、Rational ROSE 这条技术栈走完整从读者、图书管理员、系统管理员三类角色出发落到八张数据表和一套 ADO 连接层中间用用例图、时序图、类图、E-R 图把需求到实现串起来。适合要交软件工程课程设计或毕设的人照着搭结构也适合代码已经写完、正在补文档的人对照补漏。2. 需求分析落地三类参与者切成九个用例再用时序图和类图接住需求分析最怕写成功能清单。把「能借书、能还书、能查书」一条条列出来读起来像产品说明画用例图时又会发现每个功能都能再拆三层最后图上一团线。我一般按参与者切每个参与者只保留他真正发起或确认的动作细粒度的检索方式、字段校验都塞进用例描述的业务规则里图就干净了。2.1 角色切分读者、图书管理员、系统管理员各自的边界原文把需求定义写得比较散归拢之后三类角色的诉求是这样的读者要能按书名、编号、作者查藏书要能借、续借、还要能看自己的资料和借阅记录图书管理员是系统的高频使用者核心只有两件事处理借出、处理返还顺带维护图书信息系统管理员管的是「人和书」的基础数据注册新读者、改读者信息、注销读者增加书目、更新书目、下架过期图书另外还要能发布超期名单和馆藏统计。按这个边界切出来的用例清单如下编号在后面的追溯矩阵里还会用到编号用例主要参与者说明UC-01系统登录三类角色共用一个入口登录后按角色跳不同主界面UC-02查询图书信息读者书名、图书编号、作者三种检索条件UC-03查询个人借阅信息读者在借书目、应还日期、是否超期UC-04借阅图书读者、图书管理员读者发起管理员在借书窗口确认UC-05续借图书读者未超期且未续借过的记录延一期UC-06归还图书读者、图书管理员管理员确认系统计算逾期天数UC-07读者信息维护系统管理员注册、修改、注销UC-08图书信息维护系统管理员新增书目、增加复本、下架UC-09系统状态维护系统管理员超期名单、馆藏统计、罚款汇总这里有取舍。原文对读者的检索写得很细「按书名、编号、作者」三种方式如果每种画一个用例用例图会膨胀到十几个椭圆但读者真正做的决策只有一个我要不要借这本书。所以 UC-02 只保留一个三种检索方式写进用例描述的前置规则。反过来借阅和归还不能合并成「借还书」因为前者要校验读者资格后者要算逾期和罚款异常流完全不同合并了答辩时说不清。2.2 从用例到时序图以「管理员添加图书」为例拆交互用例图说明谁做什么时序图说明内部怎么响应。原文给了七个时序图添加图书、添加读者、删除更新图书、删除更新读者、处理借书、处理还书、读者查询全覆盖了但真正需要画细的是带分支的那几个。以系统管理员添加图书为例消息序列是四步维护窗口收到add item()向书目数据发find(string)查重返回 true 或 false再决定是否调create(integer, title)。很多人画时序图习惯直接从界面画到数据库再画回来三个箭头结束看不出业务判断在哪。这四个消息的价值在于把「先查重、再入库」这个规则显式化了——find返回 true 说明同名书目已经存在此时不该新建书目只应该给这本书加一个复本返回 false 才走create。对应的实现骨架放在窗体的事件处理里逻辑很短但顺序不能错 frmBook.frm —— 添加图书按钮的处理 Public Function AddItem(ByVal sTitle As String, ByVal sBookNo As String) As Boolean 第一步永远是查重同名书目存在就只加复本不新建书目记录 If TitleExists(sTitle) Then AddCopy sTitle, sBookNo 复本数 1写入新的条码号 AddItem True Else CreateTitle sTitle, sBookNo 新建书目 第一条复本 AddItem True End If End FunctionTitleExists参数是书名走的是 title 表的唯一性检查AddCopy的第二个参数是条码号也就是每本实体书的唯一标识CreateTitle一次写两张表书目信息和第一条馆藏记录这两步必须放在同一个事务里否则会出现「有书目没复本」的空记录读者永远借不到。把添加图书的用例描述补全文档里就有东西可查了项目内容用例编号UC-04 借阅图书参与者读者发起、图书管理员确认前置条件读者已登录且状态正常图书状态为在馆主流程1 读者提交借阅请求2 系统校验读者状态与在借数量3 系统校验图书状态4 管理员确认5 写借阅记录并把图书状态置为借出6 返回应还日期异常流2a 读者有超期未还或欠费拒绝并提示原因3a 图书已借出提示可预约5a 写库失败事务回滚后置条件borrow 表新增一条记录book.state 变为借出时序图上的每个箭头都应该能在主流程或异常流里找到出处找不到就说明这个箭头是凑数的。2.3 类图与多重性为什么要把 title 和 item 拆成两个类原文列了六个核心类item书目/馆藏、title书名、loan借出、reader读者、librarian图书管理员、administrator系统管理员。这个拆分是整套设计里最值得讲的一点。同一本《数据结构》馆里可能有五本读者借走的是其中某一本实体书不是「《数据结构》」这个概念。所以 title 表示书目信息书名、作者、出版社、分类号item 表示具体的那一本条码号、入库日期、价格、状态一个 title 对应一到多个 item借阅记录 loan 关联的是 item 而不是 title。读者类的定义可以直接落成 VB 的类模块属性和行为一一对应 clsReader.cls —— 读者类只放属性和与自身相关的行为 Private mCardNo As String 证件号码和 user 表主键同名 Private mName As String Private mSex As String Private mStatus As String 正常 / 冻结 / 注销 Private mBorrowCount As Integer 当前在借数量 Public Property Get CardNo() As String CardNo mCardNo End Property Public Property Let CardNo(ByVal v As String) mCardNo v End Property 能否借阅状态正常且在借数未达上限默认 5 本 Public Function CanBorrow() As Boolean CanBorrow (mStatus 正常) And (mBorrowCount 5) End FunctionmCardNo的命名特意和数据库字段user_cardnumber做了一层对应后面对字段的时候不容易错位CanBorrow里把上限 5 写成常量更规范这里为了代码短直接硬编码实际做的时候会放到配置表里因为不同馆的借阅上限不一样。类之间的关系用文字描述清楚比画一堆箭头更有用reader 与 loan 是一对多一个读者可以有多条借阅记录item 与 loan 也是一对多一本书历史上会被借多次librarian 与 loan 是「处理」关系一条借还记录一定有一个经办人administrator 与 title、item、reader 都是「维护」关系。写论文的时候把这几句话放在类图下面比只丢一张图要稳得多。3. 数据库设计八张表、一张 E-R 图和一层 ADO 封装数据库这一章是文档里最容易注水的地方把建表语句贴一遍就交差。其实评委看的是三件事字段口径统一没有实体和联系拆对了没有连接层有没有把访问逻辑收口。这三件事做不好后面代码写得再漂亮也会在答辩时被追问。3.1 表结构与字段字典八张表各自管什么正文里点明要建八张表落到字段清单上是七张有明确字段定义第八张是书籍类别表功能说明里提到的类别编号、类别名称、关键词、备注恰好就是它的字段。八张表的职责划分如下表名用途主键关键字段book馆藏图书bookname建议改为 bannercode书名、条码号、分类号、作者、出版社、出版日期、入库日期、价格、状态、简介bookkind书籍类别kindno类别编号、类别名称、关键词、备注borrow借阅记录无联合唯一证件号码、图书编号、借书日期、还书日期、是否续借user读者信息user_cardnumber姓名、性别、身份、地址、注册日期、有效期、状态login登录账号user_name用户名、密码、角色punishment罚款记录user_cardnumber证件号码、罚款总额libraryer图书管理员libr_name姓名、性别、地址admin系统管理员Adminname姓名、性别、地址book 表的字段最密这里有几个设计点值得在文档里写一句。原文把bookname书名设成主键bannercode图书编号设成唯一约束实际做的时候我一般反过来条码号做主键书名只做普通索引。原因很实际同一书名会有不同版本、不同出版社书名做主键会导致重复入库失败而且 varchar 类型的主键会被 borrow 表当外键带着走长度一长索引就重。这个改动在文档里写清楚动机反而是加分项。borrow 表的字段少但每条都关键列名类型允许为空说明user_cardnovarchar(20)否证件号码对应 user 表主键bannercodevarchar(30)否图书编号对应 book 表唯一约束borrowdatedate否借书日期receivedatedate是还书日期未还时为空renewvarchar(2)是是否续借是/否receivedate允许为空是这套设计的关键一条记录只要还书日期为空就代表这本书还在读者手上还书日期一填这条记录就归档成历史。判断「某本书是否可借」不用去翻 book.state直接看 borrow 表里有没有未归还记录就够了多一条校验路径能挡掉不少脏数据。3.2 E-R 图到物理表联系怎么落成外键和独立表E-R 图上有四个实体读者、图书、图书管理员、系统管理员。读者和图书之间是多对多一个人借多本书一本书被多人借过图书管理员和借阅之间是一对多一个人处理多笔借还系统管理员和读者、图书之间都是维护关系一对多。多对多不能直接落表必须拆成独立的联系表这就是 borrow 表存在的原因borrowdate、receivedate、renew是联系上的属性不是任何一个实体的属性。这一步在文档里画成 E-R 图之后一定要补一句话说明「读者与图书的多对多联系被拆解为 borrow 表」否则评委无法从图上看出你是懂还是蒙的。另一个需要交代的是冗余字段。原始需求里写着借书信息要包含读者姓名和书籍名称也就是 borrow 表里除了两个外键还存了姓名和书名。这是典型的反范式设计好处是借阅列表页不用 join 三张表查询快代价是读者改名、图书改名之后历史记录会对不上。我的处理是姓名和书名作为展示冗余字段存下来但所有业务校验一律走外键姓名只用于显示改读者信息时不做级联更新因为借阅记录本来就是历史快照当时叫什么名字就该记什么名字。这个理由在文档里写清楚比删掉冗余字段更站得住。3.3 ADO 连接层连接串别写死访问逻辑收口到一个模块原文的连接类把连接串放在F://conn.txt里读这个做法在开发机上没问题换台机器或者刻成光盘交作业的时候就崩了盘符根本不存在。我一般改成放在程序目录下的 ini 文件里用App.Path取相对路径。 modDB.bas —— 全局数据访问模块所有窗体都通过它拿连接 Private mConn As ADODB.Connection Public Function OpenDB() As Boolean Dim sIni As String sIni App.Path \db.ini 程序目录不依赖盘符 连接串从 ini 的 [DB] 段读切换服务器只改配置不改代码 mConn New ADODB.Connection mConn.ConnectionTimeout 5 连不上 5 秒就报错别让界面卡死 mConn.CommandTimeout 10 mConn.Open ReadIni(sIni, DB, ConnStr) OpenDB (mConn.State adStateOpen) End Function Public Function QueryParam(ByVal sSQL As String, ParamArray vArgs() As Variant) As ADODB.Recordset Dim cmd As ADODB.Command Set cmd New ADODB.Command Set cmd.ActiveConnection mConn cmd.CommandType adCmdText cmd.CommandText sSQL AppendParams cmd, vArgs 把参数按顺序追加成 adVarChar 参数 Set QueryParam cmd.Execute End FunctionOpenDB里两个超时参数是有意义的ConnectionTimeout设 5 秒数据库服务没启动时界面不会假死几分钟CommandTimeout设 10 秒防止某条统计 SQL 拖住整个窗体。QueryParam用ADODB.Command而不是字符串拼接参数化之后单引号、日期格式这些老问题基本就消掉了后面登录和借书的代码全部走这条通道。借书这条业务在库层面是两条语句一条改状态一条写记录必须放在同一个事务里-- 借书条件更新 插入借阅记录两条语句同一事务 UPDATE book SET state 借出 WHERE bannercode ? -- 参数 1图书编号 AND state 在馆; -- 只有还在馆的才更新得动 INSERT INTO borrow (user_cardno, bannercode, borrowdate, receivedate, renew) VALUES (?, ?, ?, NULL, 否); -- 参数 2、3、4证件号、条码号、借书日期第一条语句的AND state 在馆是整个借书逻辑的安全阀。如果两个管理员同时给同一本书办借出手续第二条执行时更新影响行数会是 0程序据此回滚并提示「该书已被借出」不需要加锁也不用担心并发。这个技巧在后面排查章节还会提到它比「先查再写」可靠得多。4. 系统实现VB6 工程结构、登录窗体与借还书事务实现这一章如果只贴界面截图文档价值会掉一半。评委真正想知道的是代码有没有分层窗体里是不是塞满了 SQL业务规则写在哪。VB6 虽然没有现代框架但用标准模块加类模块照样能把三层的意思做出来。4.1 工程结构与模块划分窗体、类模块、标准模块各管一摊工程建的是一个标准 EXE按职责拆成三块和三层架构大致对应文件类型职责frmLogin.frm窗体登录界面只做输入采集和跳转frmMain.frm窗体主框架按角色挂不同菜单frmBook.frm窗体图书信息维护增删改查frmBorrow.frm窗体借书、还书窗口frmReader.frm窗体读者信息维护clsReader.cls类模块读者属性与 CanBorrow 等自身规则clsBook.cls类模块图书属性与状态流转clsLoan.cls类模块借阅记录含逾期天数计算modDB.bas标准模块连接、参数化查询、事务封装modCommon.bas标准模块日期格式化、字符串校验、密码哈希窗体层只做三件事取值、调业务函数、显示结果。任何一条 SQL 都不允许出现在窗体里全部走 modDB。这条规矩看起来死板但它的好处在改需求的时候会立刻体现——借期从 30 天改成 60 天只需要改 clsLoan 里的一个常量不用去翻十几个窗体找硬编码的数字。4.2 以登录窗体为例的详细设计思路登录看着简单其实是整个系统里分支最多的一个界面三类角色共用一个入口登录成功后要跳到不同主界面还要把当前用户信息存到全局变量供后续窗体使用。校验顺序也有讲究先空值、再账号、再密码、最后分流顺序错了会泄露「哪些账号存在」这种信息。 frmLogin.frm —— 登录按钮 Private Sub cmdLogin_Click() Dim rs As ADODB.Recordset Dim sUser As String, sPwd As String sUser Trim(txtUser.Text) sPwd Trim(txtPwd.Text) 1. 空值校验别把空串丢给数据库 If Len(sUser) 0 Or Len(sPwd) 0 Then MsgBox 用户名和密码不能为空, vbExclamation Exit Sub End If 2. 参数化查询用户名带单引号也不会把 SQL 拼坏 Set rs QueryParam(SELECT user_name, psw, role FROM login WHERE user_name ?, sUser) If rs.EOF Then MsgBox 账号或密码错误, vbExclamation 不区分「账号不存在」和「密码错」 rs.Close: Exit Sub End If 3. 密码比对走哈希库里不存明文 If StrComp(rs(psw), HashPwd(sPwd), vbBinaryCompare) 0 Then MsgBox 账号或密码错误, vbExclamation rs.Close: Exit Sub End If 4. 记下当前身份按角色分流 gUser rs(user_name) gRole rs(role) rs.Close Unload Me Select Case gRole Case reader: frmReaderMain.Show Case librarian: frmLibMain.Show Case admin: frmAdminMain.Show Case Else: MsgBox 账号角色配置异常请联系管理员, vbCritical End Select End SubHashPwd在 modCommon 里实现登录表里存的是哈希值而不是明文这一点在文档里写一句就够但在答辩现场被问到「密码怎么存的」时能直接接住。gUser、gRole是标准模块里的全局变量后续窗体靠它们判断当前是谁在操作借还书窗口的经办人字段就是从gUser取的。vbBinaryCompare保证密码比对区分大小写默认的文本比较在某些区域设置下会把大小写抹平。4.3 借书与还书条件更新、事务和逾期计算借书的核心不是插入一条记录而是「确保这本书在插入的瞬间还在馆」。前面 SQL 里那句AND state 在馆就是这个保证落到 VB 代码里要配合事务使用 clsLoan.cls —— 借书返回空串表示成功否则返回失败原因 Public Function Borrow(ByVal sCard As String, ByVal sBookNo As String) As String Dim cmd As ADODB.Command Dim lAffected As Long Dim dDue As Date 读者资格校验放在事务外读操作不需要占锁 If Not GetReaderByCard(sCard).CanBorrow() Then Borrow 读者状态异常或已达借阅上限 Exit Function End If On Error GoTo Rollback 任何一步出错都回滚 mConn.BeginTrans 条件更新只有仍在馆的书才更新得动影响行数为 0 说明已被借走 Set cmd New ADODB.Command Set cmd.ActiveConnection mConn cmd.CommandText UPDATE book SET state借出 WHERE bannercode? AND state在馆 cmd.Parameters.Append cmd.CreateParameter(p1, adVarChar, adParamInput, 30, sBookNo) cmd.Execute lAffected If lAffected 0 Then mConn.RollbackTrans Borrow 该书已被借出或已下架 Exit Function End If 写借阅记录应还日期 借书日期 借期 30 天 dDue DateAdd(d, 30, Date) Set cmd New ADODB.Command Set cmd.ActiveConnection mConn cmd.CommandText INSERT INTO borrow(user_cardno,bannercode,borrowdate,receivedate,renew) _ VALUES(?,?,?,NULL,否) cmd.Parameters.Append cmd.CreateParameter(p1, adVarChar, adParamInput, 20, sCard) cmd.Parameters.Append cmd.CreateParameter(p2, adVarChar, adParamInput, 30, sBookNo) cmd.Parameters.Append cmd.CreateParameter(p3, adDate, adParamInput, , Date) cmd.Execute mConn.CommitTrans Borrow Exit Function Rollback: mConn.RollbackTrans Borrow 借阅失败 Err.Description End Function参数说明一下sCard是读者证件号sBookNo是图书条码号两者都不允许为空借期 30 天写成DateAdd里的常量实际项目会从 bookkind 表按类别取不同类别借期不同lAffected是Execute返回的影响行数它是判断并发冲突的唯一依据不能省。还书反过来先更新借阅记录的还书日期再把图书状态改回在馆同时算逾期 还书时计算逾期天数超过借期按天计罚 lOverdue DateDiff(d, rs(borrowdate), Date) - 30 If lOverdue 0 Then lFine lOverdue * 0.2 每天 0.2 元按各自馆的规定改 mConn.Execute UPDATE punishment SET sum_account sum_account lFine _ WHERE user_cardnumber sCard End If这段里的 0.2 是演示参数写文档时把它标成「可配置项」就行。逾期计算用buyDate到当前日期的天数差减借期而不是去比应还日期因为应还日期在库里根本没存——它是算出来的。这个设计选择也要在文档里提一句应还日期属于派生数据不入库避免借期调整后历史记录全部失真。5. 常见问题排查这套老技术栈最容易翻车的五个点VB6 加 SQL Server 2000 这套组合出问题的位置高度集中。下面五条是我见过最多的每条按现象、原因、解决写照着排查能省掉大半天。5.1 数据库与连接层连接串写死盘符换台机器就起不来。现象是程序在自己电脑上好好的拷到别人机器或者答辩现场的电脑上一启动就报「未找到提供程序」或者直接闪退。原因就是连接串放在F://conn.txt这类绝对路径里那个盘符在别的机器上根本不存在。解决方式是改成程序目录下的 ini用App.Path拼相对路径并且在OpenDB里加一个文件存在性判断读不到配置就弹一个明确的提示框而不是让程序静默退出。字段名冒出两套写法SQL 报「列名无效」。现象是某条查询在开发时通过换一个窗体调用就报列名不存在。原因是设计阶段同一张表在文档里写user_cardnumber代码里写成user_cardnoborrow 表又用了user_cardno三处不一致。解决办法是建一份字段字典主键统一用xxx_no后缀外键和主键同名写完立刻用 grep 把所有出现的位置过一遍。这个坑我踩过一次改到凌晨两点血泪经验就是字段字典要在建表之前定不是建完之后补。日期在中文区域设置下变成 1900-01-01。现象是借书日期存进去变成 1900 年或者插入时报「将 varchar 转换为 datetime 时出错」。原因是 VB 的日期字面量和 SQL 的日期格式在区域设置不同时解析不一致#2024/3/5#这种写法换个环境就不认。解决办法是所有日期一律走参数化参数类型用adDate而不是拼字符串实在要拼格式固定成yyyy-mm-dd。5.2 业务逻辑与文档一致性同一条码被两个人同时借走。现象是借阅记录里出现两条同一本书、还书日期都为空的记录书架上只有一本。原因是代码写成了「先 SELECT 查状态判断在馆再 UPDATE」两步之间有空隙。解决办法就是 4.3 里那种条件更新UPDATE ... WHERE state在馆看影响行数决定成败必要时再给 borrow 表加一个「未归还记录唯一」的约束兜底。用例图和类图对不上答辩被追着问。现象是评委指着用例图问「这个续借用例你类图里哪个方法实现的」翻半天找不到。原因是需求分析和系统设计是分两次写的中间没有对照。解决办法是做一张追溯矩阵用例编号一列对应的类和方法一列UC-05 续借对应clsLoan.Renew()写不出来就说明设计漏了。这张表在文档末尾放一页答辩时能救命。还有一条不算坑但值得提密码明文存 login 表。这在课程设计里很常见改起来也就十几行代码加个哈希函数登录时比对哈希值。这一点被问到的时候答「知道应该哈希演示环境为了便于查看数据暂时保留明文」也行但代码里有哈希会更有说服力。6. 验收与答辩用三条主流程和一页类图讲完整套系统验收这件事很多人理解成「功能点跑一遍」其实评委看的是系统的一致性。我给自己的验收清单是这样的每一条都有明确的判定方式验收项判定标准检查方式需求覆盖九个用例至少八条能在界面上走通按用例编号逐个点模型一致类图里每个类在代码中有对应文件对照类图数文件表结构完整八张表全部建好主键唯一约束齐全打开企业管理器逐表看借书主流程正常借书成功图书状态变为借出新读者 在馆图书借书异常流已借出的书再次借阅被拒绝同一本书连借两次还书与逾期逾期记录能算出天数并写罚款表手工把借书日期改早权限隔离读者登录看不到维护菜单三类账号各登一次数据一致性还书后图书状态回到在馆还书后查 book.state答辩的技巧说到底就一句话别按界面上有什么讲按数据怎么流讲。我一般准备三条主线第一条借书从读者点借阅开始经过资格校验、条件更新、写借阅记录最后落到 book.state 变成借出第二条还书与逾期从管理员确认还书到算天数、写罚款、状态复位第三条管理员维护新增书目、加复本、下架讲清楚 title 和 item 为什么分开。三条线讲完系统的骨架就出来了。讲的时候把类图打印成一页 A4 拿在手上讲到借书就用手指从 reader 划到 loan再划到 item嘴里说「这条记录关联的是具体某一本不是书名」。评委看到你的模型和代码是同一套东西后面基本不会再为难你。反过来如果类图只是论文里的一张插图讲的时候完全不提那它就成了摆设问一句就露馅。还有个小细节答辩前把数据库里的演示数据清一遍留三五个读者、十来本书、两条历史借阅记录。数据太干净显得没跑过数据太乱自己讲的时候都找不到重点。我吃过一次亏演示库里有一百多条乱七八糟的测试记录讲借书讲到一半翻不到那本目标书场面很尴尬。从那以后我每次答辩前都强制走一遍「清库、灌演示数据、三条主线各跑一次」的流程跑通了才敢上台。这套图书管理系统软件工程的文档结构从需求到数据库到实现再到验收每一层都有可以对照检查的落点照着改改字段和业务规则就能用在自己的题目上。希望帮到你。本文还有配套的精品资源点击获取