★ FEATURED ARTICLE 改字段这件事麻烦的从来不是改本身。把专业改成系别E-R 图改完了。过了两天发现数据字典里还写着专业三线表里也是旧的设计文档的数据库设计章节引用了旧名称答辩 PPT 里那张图还是上一版导出的。于是又花一晚上挨个文件搜替换。这篇讲的不是怎么生成材料而是这些材料之间到底是什么关系以及改完之后按什么顺序核对才能避免版本散掉。一套毕设材料里哪些内容其实是同一份数据先看清这一点后面就顺了。毕设要交的东西看起来很多但大部分内容来源于同一份项目结构实体、字段、关系、角色、技术栈材料它引用的项目结构结构改了会不会跟着变E-R 图实体、字段、关系、基数会数据字典表名、列名、中文名、类型、约束会建库 SQL 脚本表结构、主外键、索引、视图会三线表字段清单换一种排版会设计文档上面全部 章节文字部分开题报告研究目标、技术路线、进度基本不变答辩 PPT图纸 实现证据 测试结果部分测试用例表功能模块、预期行为部分项目源码实体类、接口、页面会看这张表能得出一个结论上游改一次下游有一半以上要跟着动。所以核对的顺序应该是从上游往下游而不是拿到哪份改哪份。下面按这个顺序说每份材料只需要关注它特有的那部分问题。起点的图和数据字典先确认两者一致所有下游材料的问题追到源头大多在这里。项目结构和这几类图纸都在同一个工作区里维护可以从 捷码AI工作台 打开项目逐项核对。这张图前面几篇都提到过这里换个角度用它是核对的起点不是终点。左边图上的实体关系和右边字典里的表名字段必须一一对应。图上有的表字典里没有或者反过来都说明中间有一次修改没同步。具体查四个地方图上的实体有没有对应表有没有字典表被当成业务实体画进去了关键联系能不能在字段里找到外键支撑没写外键但实际有关联的情况最容易漏。中文名是否统一图和文档对同一个字段的称呼要一致。角色是否只出现在真实需求里凭空多出来的角色会在权限设计部分露馅。建库脚本能生成不等于能执行脚本承担的任务是让结构真正落到数据库。这张图里能看出脚本是按小节组织的数据库创建、表结构创建、视图、索引、测试数据载入、数据库操作、查询、存储过程、触发器、用户授权。这种组织方式的好处是可以按小节和课程设计的要求逐条对照。拿到脚本之后必须做的事在目标数据库里实际执行一遍。需要核对的包括数据库方言对不对MySQL 和 SQL Server 的建表语句不通用主外键能不能建起来有没有循环依赖字段长度够不够装下真实数据初始数据有没有主键冲突索引建在正确的列上报了错就回头改结构不要在脚本里手改。手改脚本之后脚本和 E-R 图又对不上了。三线表和测试用例表论文里最容易脱节的两张表三线表是字段清单的学术排版形式。它的数据来源就是数据字典不应该另外编一套字段。需要手工调整的是排版部分学校模板要求哪些列列名、中文含义、类型、长度、是否主键、是否为空、备注、列的顺序、表题格式。这些各家要求不同工具给的是通用形式。测试用例表要单独说因为这里有个容易踩的坑看这张图最右边那一列——“实际结果全部标着未执行”。这不是缺陷而是正确的做法。测试用例表里“对象”“场景/输入条件”预期行为这三列属于测试计划可以在写代码之前就设计出来但实际结果必须真的把系统跑一遍才能填。把没跑过的用例标成通过是答辩里风险很高的行为——导师让你现场演示其中一条当场就露馅了。所以看到未执行不用急着改先去看哪些功能已经跑通了跑通的再填结果没跑的就老实留着。设计文档章节骨架好搭正文内容要自己写设计文档是这些材料里生成部分和自写部分边界最清楚的一份这张图分三块各有各的用途左侧章节目录能看到文档的骨架。图里这份是六章结构——需求分析、总体结构设计、逻辑结构设计、物理结构设计、数据实施、总结每章下面还有二级节。中间预览A4 排版的成品效果可以直接看出篇幅和排版问题。右侧模板按章节深度分了几档切换会改变章节骨架。模板决定的是章节结构不决定内容对不对。需求分析要解释角色和业务总体设计要对上功能结构图和架构图数据库设计要对上 E-R 图、数据字典和 SQL详细设计要能找到流程图、时序图和类图。这些对应关系得自己逐章检查。学校模板的封面、摘要、目录、页码、图号、表号、参考文献格式工具不会替你适配要手工调。另外文档里出现系统已实现这类表述时要以真实运行结果为依据。开题报告和答辩 PPT一份讲计划一份讲结果这两份最容易混着写实际上性质不同。开题报告讨论的是为什么做、准备做什么、打算怎么做、计划怎么推进。它的特点是写在动手之前所以里面的功能描述是计划不是已完成的事实。这张图右侧值得留意开题报告按学校样表分了四种版式——独立封面型、双页表单型、全程表格式、封面编号型图里选中了双页表单型。先看学校发的最新样表再挑最接近的版式不要凭印象选。生成初稿后要动手改的研究现状要换成真实检索到的文献技术路线要和实际采用的方法一致进度安排要和学校给的周次对得上。别把将来才会做的功能写成已经完成。答辩 PPT讲的是我做了什么、怎么设计的、怎么验证的。这张图左边是页面缩略图右边是当前页的内容编辑区标题、正文、核心要点。它的结构适合先搭框架背景、需求、设计、实现、测试、总结。但页面里的内容要换成你自己项目的东西——运行截图、真实的核心图纸、实际跑出来的测试结果。初稿给的是页序和章节结构不是可以直接讲的内容。一次综合导出之后文件长什么样如果把材料一起下载得到的是一组按类型分目录的文件这是大学生就业咨询系统这个案例的实际下载目录能看到几件事分了01-SQL脚本、02-设计资料、03-交付目录三个文件夹再往下才是具体文件数据字典有.xls、.xlsx和.md三种格式——用途不同表格类给 Excel说明类给 Markdown答辩 PPT 有可编辑版.pptx和演示版.pdf两份开题报告和设计文档各有.docx和.doc两种格式这份目录说明这些是不同文件类型不是一张图里嵌着所有内容。其他课题的文件数量和命名会不同以实际导出为准。另外源码目录也在这个交付包里下面那两行是解压后的工程结构但拿到源码不等于项目跑通了——依赖、数据库、端口都要自己配。倒查法从一个业务事实反推所有材料材料都改完最后做一次一致性检查。方法很简单挑一个具体的业务事实拿着它去问每一份材料。以用人单位提交需求为例问这份材料应该查到什么建库脚本有没有存需求信息的表字段是否齐全E-R 图用人单位和需求信息之间的连线和基数对不对数据字典中文名和类型是否和脚本一致三线表字段清单是否来自同一份数据字典设计文档数据库设计章节的描述和图是否一致用例图提交需求这个用例给了用人单位角色吗时序图提交之后的调用顺序和校验时机对不对答辩 PPT相关页面的描述和实际运行结果是否相符只要有一处说法不同就回到项目结构改再重新导出受影响的那几份。挨个文件手工改只会让差异越积越多——改到第三份的时候你已经记不清第一份改的是什么了。
阅读完成 · 觉得有帮助？
