图书管理系统课程设计：需求分析、数据库设计与ADO事务避坑

简介《图书管理系统 软件工程》是一份面向软件工程课程设计、毕业设计入门与系统分析学习者的文档型资料围绕图书管理系统的完整开发流程展开可用于梳理需求分析、系统设计、数据库设计与实现测试等环节的写作思路。资料以1个doc文件交付压缩包约535KB篇幅紧凑适合作为课程报告或项目文档的结构参考。内容从课题背景与开发技术切入依次覆盖系统目标、功能与性能需求、读者借还书及管理员维护用例图、时序图、类关系以及数据库E-R图、数据表创建与连接并延伸到VB6.0与Rational ROSE下的工程创建、模块添加、登录窗体和界面设计。现有442人学习便于读者快速把握图书管理系统的软件工程文档框架、建模表达与实现组织方式。1. 需求先立住图书管理系统课设真正卡人的不是代码「图书管理系统」在软件工程课程设计里出现频率极高高到不少人把它当送分题借书、还书、查书三个动作两天把界面拖完就该收工。真正容易出问题的地方在文档的连贯性需求分析里的用例和行为跟时序图对不上类图里的六个类在数据表里找不到对应答辩时随手翻到 E-R 图和建表语句问一句「借阅表和书籍表靠什么关联」答不上来就容易暴露问题。这份资源是一套完整的图书管理系统软件工程文档从绪论、需求分析、用例图与时序图、类图、数据库设计一路写到系统实现与界面设计技术选型是 VB6 SQL Server 2000 ADO Rational ROSE沿用了瀑布模型那一套流程。它适合两类人正在交课程设计、准备毕设开题的学生以及手上有一个中小型 MIS 要交付、需要一份能直接改的文档底稿的从业者。2. 需求分析三类参与者、七张时序图和一份能验收的功能清单很多人写需求分析习惯把「系统要好用、要稳定、要快」写满一页看着挺像回事一到验收就全成了空话。这一章要做的是把「读者能借书」这种自然语言拆成参与者、用例、交互时序和可测条目四层让后面每一张类图、每一张数据表都能在这里找到出处。2.1 参与者识别与三张用例图的边界只要把角色分清楚用例图基本就是照着填。这套系统定的是三类参与者读者、图书管理员、系统管理员。读者的用例是系统登录、查询个人信息、查询图书信息、查询本人借阅信息、借阅图书、图书归还、图书续借图书管理员的用例收敛到两个动作处理借书请求、处理还书请求系统管理员的用例围绕维护增加书籍、删除或更新书籍、添加读者信息、删除或更新读者信息另外还要负责超期提示和馆藏情况发布。这里有个常被忽略的边界问题读者点了「借阅图书」系统只是生成一条借阅申请实际库存扣减由图书管理员确认后才发生。如果用例图上把借书画成读者和管理员各自独立的用例、彼此不相连那后面时序图就没法画因为缺了一次跨角色的消息传递。参与者用例数关键用例对应数据表读者7借阅图书、图书续借user、borrow、book图书管理员2处理借书、处理还书borrow、book系统管理员4增加书籍、读者信息维护book、user、libraryer、admin我一般会把上面这张表直接放进文档 2.6 节前面先给读者一张「角色—用例—表」的对照后面画不画得全一眼就能看出缺口。2.2 七张时序图里只精画一张系统管理员添加图书文档里列了七张时序图添加图书、添加读者、删除或更新图书、删除或更新读者信息、处理借书、处理还书、读者查询图书信息。七张全画细既费时间也没必要精画一张「添加图书」其余六张按它的格式套。这张图的参与者是系统管理员界面对象是维护窗口maintenance window往后依次是书目对象 title、条目对象 item消息顺序是序号消息说明1add item()维护窗口发起添加请求2find(string)按书名在 title 中查重3return true查重结果回传4create(integer, title)建条目同时更新该书目的在馆数量第 2 步的find(string)是这张图的重点。先查重再创建是因为同一个书名可能对应多个副本书的「品种」和「册数」必须是两层概念title 记品种item 记册数。如果省略查重这一步直接 create管理员每次加书都会新建一个品种一年下来书库里同一个书名能有十几条记录检索结果全是重复项。答辩时老师最爱问的就是「为什么加书之前要先查一次」答案就在这。提示其余六张时序图画的时候把参与者、边界对象、控制对象、实体对象这四条泳道固定下来只换消息内容风格统一了整份文档的观感会好很多。2.3 把性能要求写成可验收的条目原文档 2.5 节列了一串正确性、可靠性、效率、完整性、易使用性、可维护性、可测试性、复用性、安全保密性、可理解性、可移植性、互联性。这十二个词本身没错但每一个都不能直接拿去验收。我的做法是只保留能落到动作上的那几条把形容词换成数字或判定条件正确性借书成功后book 表中该条码的 state 必须由「在馆」变为「借出」两秒内可查。完整性一条借阅记录的 bannercode 必须能在 book 中找到找不到时不允许写入。效率按书名、条码、作者三种方式检索1 万条书目数据下单次查询响应不超过 2 秒。易使用性读者从登录到完成一次借阅操作步骤不超过 5 步中途不需要手工输入条码以外的编号。安全保密性三类角色登录后可见的功能菜单互不相同读者无法通过界面进入图书信息维护窗口。剩下那些不好量化的比如可移植性写成一句限定即可数据访问集中在单个模块里更换数据库只改连接串和 SQL 方言界面层不动。这句话在后面的实现章节是有兑现的能看到 modDB 模块被所有窗体共用。借书这个用例建议单独给一份用例规约表它后面会反复被引用项目内容用例名借阅图书参与者读者发起、图书管理员确认前置条件读者登录成功账号状态正常未达可借数量上限基本流读者提交借书请求 → 系统校验图书在馆 → 管理员确认 → 写入借阅记录 → 更新图书状态异常流图书不存在 / 已借出 / 读者有超期未还 / 达上限分别给出提示并中止后置条件borrow 表新增一条记录book 表 state 置为借出这张表看着平淡实际上把后面避坑章节里一半的问题都提前挡掉了异常流里那四条校验就是借书事务里必须先跑完的四个查询。3. 系统设计三层架构、六个核心类与八张表的对应关系需求理完接下来要做的是把「用户能看见的功能」翻译成「程序里的分层」和「数据库里的表」。这一步如果含糊写出来的类图和建表脚本就是两套独立的东西互相对不上答辩一问就断链。3.1 三层架构在 VB6 工程里的具体落点文档里定的是经典三层表现层负责界面与交互业务层负责规则与数据处理数据层负责存储与访问。概念好懂难的是在 VB6 这种老工具里怎么落地因为 VB6 没有现代框架那种分层约束全靠工程结构自觉。我的做法是物理上分目录、逻辑上分模块层次载体典型文件职责表现层窗体frmLogin、frmMain、frmBookQuery、frmBorrow、frmReaderMgr只做控件取值、格式校验、调用业务方法业务层类模块clsBook、clsReader、clsLoan封装校验规则、扣减库存、计算应还日期数据层标准模块modDB、modBookDAO、modLoanDAO连接管理、SQL 执行、记录集转换这条边界值得较真。很多课设版本把 SQL 直接写在按钮的 Click 事件里窗体里十几条Execute代码能跑但一旦要改表结构就得挨个窗体翻。把 SQL 收进 DAO 模块的好处是换数据库只改 DAO界面一行不动这正好呼应了上一章写的那句「可移植性」。工程创建的顺序也有讲究。原文档第 5 章给的顺序是创建工程项目 → 添加模块 → 添加类模块 → 界面设计。这个顺序不是随便排的先有 modDB 才能连库先有 clsBook 这类类模块窗体里才有东西可调反过来先拖界面你会发现每个按钮都缺一个能调用的方法最后只好把逻辑塞进窗体。3.2 六个核心类参与者三个实体三个文档里明确用了六个类item书目条目、title书名/品种、loan借出、reader读者、administrator系统管理员、librarian图书管理员。前三个是实体类后三个是参与者类这个划分在类图上是能看出层次的。参与者类的属性基本一致都是 ID、姓名、地址这一组差别在操作上reader 类读者编号、姓名、性别、年龄、已借书数目、联系电话、地址操作是读者信息查询、图书信息查询、借阅信息查询、借书、还书、续借。librarian 类工作 ID、姓名、地址操作是借书处理、还书处理。administrator 类ID、姓名、地址操作是添加信息、删除信息、更改信息。实体类的字段更细一些。title 有图书名称、作者、ISBN、价格、出版社、数目标识操作是添加、删除、修改、查询item 挂到具体某一册上带图书标号、状态loan 记借出时间、图书标号、关联读者同样带增删改查。三个参与者类共有的那些字段实现上没必要真写三遍。我的处理是抽一个基类思想VB6 没有继承就用一个clsPerson类模块放公共字段和SavePerson方法三个参与者类各自持有它重复代码能砍掉一大半。3.3 从类到表八个表的映射规则类图到数据表的映射规则只有一条但要严格执行一个持久化实体类对应一张表类里的每个属性对应表里的一列类的每个「查询」操作对应一次 SELECT。按这条规则走六个核心类加上分类、登录两类辅助信息正好落成八张表。类 / 来源对应表主键关系title itembookbannercode条码被 borrow 引用1:nloanborrow借阅流水号引用 book 与 userreaderuseruser_cardnumber被 borrow 引用1:nlibrarianlibraryerlibr_name独立表administratoradminAdminname独立表登录信息loginuser_name与 user 按姓名弱关联罚款信息punishmentuser_cardnumber引用 user图书分类kindkindno被 book 引用1:n注意login 表与 user 表按姓名关联本身就是弱设计改名会让两边脱节。稳妥的做法是让 login 增加一列 user_cardnumber 指向 user 表登录成功后直接拿到证件号后续所有业务查询都用证件号走不再用姓名做条件。表定下来之后回过头检查一遍类图loan 类里如果有「读者姓名」这个属性那它在 borrow 表里是不该有对应列的因为姓名可以从 user 表关联出来。冗余列写进表里后面改一次姓名就要同步更新两处这是课设里最常见的隐患。4. 从建表到连库八张数据表的落地语句与 ADO 连接层实现设计图画完接下来要让它能执行。这一章给的是可以直接粘进 SQL Server 查询分析器跑起来的建表语句以及 VB6 里那条能把界面和数据接上的连接层。文档里原有几张表的字段设计存在明显隐患下面在保留原字段命名的前提下做了调整调整理由写在每段代码后面。4.1 E-R 图与主外键的落点E-R 图要表达三组关系读者与借阅是一对多一本书与借阅是一对多图书分类与图书是一对多。落到物理设计上就是 borrow 表持有 user_cardno 和 bannercode 两个外键book 表持有 kindno 外键。原文档在 book 表里把 bookname 设为主键、bannercode 设为唯一约束这个选择在实际使用中会带来麻烦书名重名不是异常而是常态同一本书再版、同名的不同出版社版本都很常见用书名做主键意味着第二次录入同名书会直接失败。而借还书现场靠的是扫码枪读条码业务上真正的唯一标识是 bannercode。所以我一般会把主键换成条码书名只做普通索引用于模糊检索。borrow 表原设计把 user_cardno 设为主键这个问题更严重读者还没还上一本就不能再借第二本。主键应该换成自增的借阅流水号证件号和条码退化成普通外键。4.2 建表语句与字段约束-- 图书表以条码做主键书名重复不影响录入 CREATE TABLE book ( bannercode VARCHAR(30) NOT NULL, -- 图书条码借还书的唯一凭据 bookname VARCHAR(30) NOT NULL, -- 书名允许重名建普通索引 kindno VARCHAR(20) NULL, -- 分类号外键指向 kind 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 (bannercode), CONSTRAINT ck_book_state CHECK (state IN (在馆,借出,注销)) ); CREATE INDEX ix_book_name ON book(bookname); -- 借阅表自增流水号做主键一个人可以有多条在借记录 CREATE TABLE borrow ( loan_no INT IDENTITY(1,1) NOT NULL, -- 借阅流水号 user_cardno VARCHAR(20) NOT NULL, bannercode VARCHAR(30) NOT NULL, borrowdate DATETIME NOT NULL DEFAULT GETDATE(), receivedate DATETIME NULL, -- 为空表示尚未归还 renew CHAR(1) NOT NULL DEFAULT 0,-- 0 未续借1 已续借 CONSTRAINT pk_borrow PRIMARY KEY (loan_no), CONSTRAINT ck_borrow_date CHECK (receivedate IS NULL OR receivedate borrowdate) ); CREATE INDEX ix_borrow_card ON borrow(user_cardno); CREATE INDEX ix_borrow_book ON borrow(bannercode); -- 读者表与登录表登录表用证件号关联避免改名后脱节 CREATE TABLE [user] ( user_cardnumber VARCHAR(20) NOT NULL, user_name VARCHAR(20) NOT NULL, user_sex VARCHAR(2) NULL, user_status VARCHAR(20) NULL, -- 学生 / 教师 / 校外 user_address VARCHAR(30) NULL, user_state VARCHAR(4) NOT NULL DEFAULT 正常, CONSTRAINT pk_user PRIMARY KEY (user_cardnumber) ); CREATE TABLE login ( user_name VARCHAR(10) NOT NULL, psw VARCHAR(15) NOT NULL, user_cardnumber VARCHAR(20) NULL, -- 关联读者或管理员证件号 role_code CHAR(1) NOT NULL DEFAULT R, -- R 读者 L 图书管理员 A 系统管理员 CONSTRAINT pk_login PRIMARY KEY (user_name) );几点说明。state用中文枚举而不是 0/1好处是导出报表时不用再翻译代价是存储占用略大课设这个数据量完全无所谓。renew用 CHAR(1) 而不是原来写的 varchar2——varchar2 是另一种数据库的类型名SQL Server 只认 VARCHAR照抄过去会直接报语法错误这个坑后面避坑章还会提。receivedate允许为空并加了 CHECK 约束保证还书日期不能早于借书日期这一条约束能挡掉手工改数据时的大部分脏记录。至于「一本在馆的书不能同时有两条未还记录」我没有用唯一约束硬卡因为 SQL Server 的唯一约束对多 NULL 的处理容易让人误解。这条规则放在借书事务里用一次 SELECT 判断更直白代码在下一节。4.3 ADO 连接层与登录校验的完整实现原文档 3.4 节给的连接代码是从一个固定路径的 txt 文件里读连接串而且每次取数据都新建一次连接这在课设演示时能跑换台机器路径一变就崩。我的写法是把连接收进一个全局模块工程里自始至终只有一个 Connection 实例。 modDB.bas —— 全工程共用的数据访问入口 Option Explicit Public gConn As ADODB.Connection Public gCurCardNo As String 当前登录人证件号 Public gCurRole As String R / L / A Public Function OpenDB() As Boolean On Error GoTo ErrHandler Dim connStr As String 连接串集中一处换服务器只改这一行生产环境不要用 sa connStr ProviderSQLOLEDB;Server127.0.0.1;DatabaseLibMIS;UIDlibapp;PWD******; Set gConn New ADODB.Connection gConn.ConnectionTimeout 5 连不上时 5 秒内报错不要无限等待 gConn.Open connStr OpenDB True Exit Function ErrHandler: MsgBox 数据库连接失败 Err.Description, vbCritical, 提示 OpenDB False End Function Public Sub CloseDB() If Not gConn Is Nothing Then If gConn.State adStateOpen Then gConn.Close Set gConn Nothing End If End SubProviderSQLOLEDB指定用 SQL Server 的 OLE DB 提供程序Server写实例名或 IPConnectionTimeout是建立连接的超时和命令执行超时CommandTimeout不是一回事两个都要设。登录窗口的校验逻辑放在窗体里但查询方式用参数化命令 frmLogin 登录按钮参数化查询避免书名带单引号时炸掉 Private Sub cmdLogin_Click() Dim cmd As ADODB.Command, rs As ADODB.Recordset If Trim(txtUser.Text) Or Trim(txtPwd.Text) Then MsgBox 用户名和密码不能为空, vbExclamation, 提示: Exit Sub End If Set cmd New ADODB.Command Set cmd.ActiveConnection gConn cmd.CommandType adCmdText cmd.CommandText SELECT user_cardnumber, role_code FROM login WHERE user_name? AND psw? 两个参数的长度要和 login 表字段长度一致否则会被截断 cmd.Parameters.Append cmd.CreateParameter(u, adVarChar, adParamInput, 10, Trim(txtUser.Text)) cmd.Parameters.Append cmd.CreateParameter(p, adVarChar, adParamInput, 15, Trim(txtPwd.Text)) Set rs cmd.Execute If rs.EOF Then MsgBox 用户名或密码错误, vbExclamation, 提示 Else gCurCardNo rs(user_cardnumber) gCurRole rs(role_code) Unload Me Load frmMain frmMain.Show End If rs.Close: Set rs Nothing: Set cmd Nothing End Sub这段代码有两个细节值得说。CreateParameter的第四个参数是长度必须和表字段定义一致psw是 VARCHAR(15) 就写 15写大了不会报错但会浪费写小了密码会被静默截断表现为「密码明明输对了却登不进去」非常难查。第二登录成功后把role_code存进全局变量主窗体加载时按角色隐藏菜单这就把第 2 章写的那条「三类角色可见菜单互不相同」的验收项落实了。5. 避坑借还书链路和界面层最容易翻车的五个点这套系统本身不复杂问题几乎全出在「看起来能跑」和「真的对」之间的差距上。下面五条是我在类似项目里反复见到的每条按现象、原因、解决三步写照着排查基本能省掉一半返工。5.1 借阅表主键选错一个读者只能借一本书现象第一个读者借书成功第二个读者再借同一本书时报主键冲突或者更隐蔽一点读者 A 借完书读者 B 再借时把 A 的记录覆盖掉了界面上看着一切正常。原因borrow 表按原文档的设计把user_cardno设成了主键。主键的唯一性约束意味着一个证件号只能出现一次同一个人借第二本必然失败如果代码里用了 UPDATE 而不是 INSERT就会变成覆盖。同理把bannercode设成主键会导致一本书永远只能被借一次。解决换成自增的loan_no做主键证件号和条码退成普通外键加索引建表语句见 4.2 节。改完之后还要检查所有按证件号查借阅记录的 SQL把「查一条」改成「查未还记录集合」因为一个人同时借三本书是正常状态。5.2 借书只写了借阅表没扣库存现象书架上明明只有一本《数据结构》系统里显示在馆三本三个读者都能借成功或者还书之后 state 一直是「借出」那本书再也借不出去。原因借书这个动作实际要动两张表——borrow 插入一条记录、book 把 state 改成「借出」。代码里只写了第一条或者两条分开写在两个按钮事件里中间出异常就只成功了一半。解决把两条语句包进一个事务任何一步失败就整体回滚。VB6 里用 Connection 对象自带的三个方法就能做到 借书校验、写入、改状态三步在一个事务里 Public Function BorrowBook(ByVal sCard As String, ByVal sBanner As String, ByRef sMsg As String) As Boolean Dim rs As ADODB.Recordset On Error GoTo ErrHandler gConn.BeginTrans 开启事务 1 图书必须存在且在馆 Set rs gConn.Execute(SELECT state FROM book WHERE bannercode sBanner ) If rs.EOF Then sMsg 图书不存在: GoTo Rollback If rs(state) 在馆 Then sMsg 该书已借出: GoTo Rollback rs.Close 2 读者不能有超期未还记录应还日期按 60 天算 Set rs gConn.Execute(SELECT COUNT(*) AS c FROM borrow WHERE user_cardno sCard _ AND receivedate IS NULL AND DATEDIFF(day, borrowdate, GETDATE())60) If rs(c) 0 Then sMsg 存在超期未还图书: GoTo Rollback rs.Close 3 写借阅记录并改状态 gConn.Execute(INSERT INTO borrow(user_cardno,bannercode) VALUES( sCard , sBanner )) gConn.Execute(UPDATE book SET state借出 WHERE bannercode sBanner ) gConn.CommitTrans 全部成功才提交 BorrowBook True Exit Function Rollback: gConn.RollbackTrans BorrowBook False Exit Function ErrHandler: gConn.RollbackTrans sMsg 借书失败 Err.Description BorrowBook False End FunctionBeginTrans / CommitTrans / RollbackTrans三步必须配套ErrHandler里那次回滚不能省否则网络一抖连接断了事务会一直挂着锁住 book 表。另外注意事务里的 SQL 用的是字符串拼接正常流程没问题但书名或备注里带单引号就会炸——演示前把样例数据的引号清掉或者按 4.3 节的写法改成参数化。5.3 类型名照抄varchar2 和日期默认值一起翻车现象建表脚本在查询分析器里执行第一句就报「数据类型 varchar2 无效」改完 varchar2 又报日期默认值语法错误。原因原文档的字段表里出现了varchar2、number这类写法那是另一种关系数据库的类型名SQL Server 里对应的是VARCHAR和NUMERIC。另外日期列的默认值写Date也不行SQL Server 2000 要用GETDATE()而DATETIME本身带 1900-01-01 的默认值不显式声明 DEFAULT 的话没赋值的日期会变成这个古怪的日期而不是空。解决全局替换类型名日期列统一DATETIME NULL加DEFAULT GETDATE()只在借书日期这类需要自动填的列上加并在文档的数据字典里补一列「SQL Server 实际类型」避免读者照着旧表抄。这类问题不难改难的是发现——文档和脚本不一致时通常是以脚本为准去反推文档别反过来。5.4 连接字符串硬编码在某个具体路径现象在自己机器上跑得好好的换到实验室机器或者打包交上去一启动就弹「数据库连接失败」错误信息还只是一串英文。原因连接串写死在代码里或者从F:\conn.txt这种绝对路径读。换台机器没有 F 盘或者数据库实例名不一样有的是默认实例有的是机器名\SQLEXPRESS连接必然失败。解决连接串只保留在 modDB 一个地方部署时改一行进一步可以把它放进注册表或同目录的 ini 文件路径用App.Path拼相对路径不要写盘符。另外记得在启动时先调OpenDB失败就直接退出程序并提示检查配置不要让用户进到主界面点每个按钮都报一次错。5.5 用例图、类图和数据表三份文档各说各话现象答辩时老师指着类图问「loan 类对应哪张表」翻半天找不到或者用例图里读者有「预约图书」的用例翻遍数据表没有预约相关的字段。原因三份图是分三天写的写用例时想得很全写类图时精简了一轮建表时又按字段方便删了一轮三轮下来对不上。这是文档类作业最典型的问题代码能跑文档扣分。解决定一个顺序先出数据字典表名、字段、类型、约束再回填类图的属性和方法最后核对用例图里每个用例是否都能在类的方法上找到入口。核对的笨办法是拿一张纸把用例名一个个划掉划不掉的要么补方法要么删用例。我一般还会在文档最后加一张「需求—类—表」追溯表三列一一对应答辩时直接翻到那一页比口头解释有用得多。6. 验收与答辩用一条主链路把文档和系统同时证完到了这一步系统能不能跑、文档能不能过其实取决于你有没有一条走得通的主链路。我的习惯是只选一条系统管理员登录 → 新增一本书 → 读者登录 → 按书名查到这本书 → 提交借阅 → 管理员确认借出 → 读者查自己的借阅记录 → 归还 → 状态回到在馆。这条链路串起了三类角色、五张表、六个核心类走通了八成的问题都暴露完了。验收前按这张表自查一遍比通读代码快检查项判定标准对应章节角色隔离三类账号登录后菜单不同读者进不去维护窗口2.3 / 4.3借书事务手工制造一次异常book 状态必须回滚5.2重名图书录入两本同名不同条码的书都能查到且互不覆盖4.1超期提示把 borrowdate 改到 61 天前借书时应被拦截5.2文档一致用例图每个用例在类图有方法、在表里有字段5.5换机部署换一台机器只改连接串即可启动5.4答辩时有个技巧值得单独说不要从绪论开始讲。开口先给那条主链路现场演示三十秒让老师看到系统是活的然后倒回去讲需求怎么来的、类怎么划的、表怎么落的每一页都指回刚才演示过的那一步。老师提问大概率会落在两个地方——「这本书借出去了state 谁改的」和「两个读者同时借最后一本怎么办」前者答事务后者答在馆状态校验加重试两个问题都在第 5 章里提前准备好就行。还有一个细节容易被忽略演示数据要提前准备。新库是空的现场录书、录读者、走借还一来费时间二来容易在录数据时手抖出错。我一般会写一个初始化脚本插二十本书、五个读者、三条历史借阅记录其中一条故意设成超期演示超期拦截时直接能用。这个脚本放文档附录里也算交付物的一部分。这套文档按上面六章的结构整理需求、设计、建表、实现、避坑、验收各占一节配套的建表脚本和关键代码都在正文里拿去改改就能当自己项目的底稿。从那以后我每次带人做这类课设都强制先把「需求—类—表」追溯表填完再动手写代码顺序反过来的没有一次不返工。希望帮到你。本文还有配套的精品资源点击获取