简介：这是一份电大计算机科学与技术专业的毕业论文，主题为图书信息管理系统的设计与实现。论文以管理信息系统为背景，详细阐述了系统的需求分析、功能模块划分、数据库结构设计及前端应用程序开发全过程，并选用大连飞扬软件工作室的易语言作为开发工具，展示了全中文可视化编程在实际项目中的具体应用。系统运行结果表明，该设计能满足借阅者、资料管理工作人员和高级管理三方面的需求；针对大量数据库访问时性能下降、共享不便的不足，作者亦提出了以SQL Server作为数据库的改进思路。资源包共1个doc文件，大小约898KB，内容包含中英文摘要、关键词、正文及完整设计思路。目前已有91人学习下载，适合计算机专业学生、从业者用于毕业论文写作借鉴、管理信息系统课程设计参考或易语言开发入门学习。

1. 这个叫“毕业论文 (1).doc”的文件，其实是整个项目的主控文档

无论你是从网上下的范文，还是导师发来的模板，抑或自己草稿被系统自动加了“(1)”，这份文档在接下来两三个月里，会成为你所有工作的终点。电大计算机科学与技术专业的毕业论文，评审逻辑看的是“你完成了一个具体的计算机应用系统”，并用文档把过程讲清楚。论文不是写出来的，是“做出来再写出来”的。代码跑不通，论文吹得天花乱坠也没用；代码删了，只剩设计和需求，评委同样觉得空洞。所以拿到这个 .doc 后第一件事不是改目录，而是判断它的角色：是必须从头填的模板，还是可以修改复用的底稿？这决定了后续所有操作。

2. 先拆论文骨架：计算机专业毕业论文的七段结构与写作顺序

2.1 为什么是“问题-方案-实现-验证”四个大字

电大计算机专业论文虽然要求没那么高，但结构上不能缺胳膊少腿。最常见的通用结构我总结为七段：摘要、绪论（引言）、需求分析、系统设计、系统实现、系统测试、总结与展望。把它们对到软件工程生命周期里，其实就是“问题定义—可行性分析—需求分析—概要设计—详细设计—编码实现—测试交付—维护总结”的缩写。评审老师一天看五六篇论文，拿过目录就能判断这篇论文有没有走完整的流程。缺了需求分析，系统设计就是空中楼阁；缺了系统测试，系统实现就缺乏可信度。

这里有一个很反直觉的点：写作顺序不要从摘要开始。摘要必须最后写，因为它是对全文的概括，你还没写完正文怎么概括。正确的顺序是：先把系统做出来，至少核心功能能跑；然后写系统实现和系统测试，因为这两章最依赖真实数据和代码；回头补需求分析和系统设计，这时候你已经清楚自己做了什么，画用例图、E-R图很容易；再写绪论和总结；最后压缩出摘要和关键词。

我见过一些同学从绪论开始“憋字”，结果写了一个月还在讲“计算机技术发展日新月异”，系统一个字没动。等到最后仓促做个系统，论文里实现章节全是编的，答辩一问就翻车。所以，把系统当龙头，论文当记录，顺序反着写，效率会高很多。

另外，七段结构每一章的标题也要统一风格。比如“绪论”可以叫“引言”或“第1章 绪论”，但整篇只能选一个称呼。有些同学论文里“第二章 相关技术介绍”和“第三章 关键技术分析”同时出现，很容易让评委觉得结构不严谨。所以我会在动手前先把论文模板的章节标题固定下来，后续只写正文，不再改标题。

2.2 摘要与绪论：把“做了什么”压缩成一段话，而不是把背景抄三页

摘要是一篇论文的门面，电大论文摘要一般要求300到500字，不能写成引言。一个好用摘要是四句话：第一句写背景和问题，第二句写本文做了什么，第三句写采用的技术或方法，第四句写达到的结果和意义。关键词三到五个，从摘要里提炼。

这里给一个可套用的例子，假设你做的是一个图书借阅管理系统：

随着高校图书馆藏书量和借阅业务的增长，传统人工登记方式存在效率低、易出错、查询困难等问题。针对该现状，本文设计并实现了一个基于Flask框架和MySQL数据库的图书借阅管理系统。系统采用B/S架构，实现了图书信息管理、读者信息管理、借书还书、逾期统计和公告发布等功能，并设计了基于角色的访问控制机制。经过多轮功能测试与异常测试，系统各模块运行稳定，能够满足中小型图书馆的日常管理需求。

注意这里没有出现具体的学校名，也没有编造参考文献。绪论部分，电大论文通常要求写背景和意义、国内外研究现状、本文的主要工作。所谓“国内外研究现状”，不是让你抄一堆论文标题，而是写清楚“已有系统大概是什么水平，还有什么不足”，你要针对不足来开展工作。写作时不要用“本文主要研究了”这种空话，而要列出一二三：“本文的主要工作包括：（1）完成了……（2）实现了……（3）测试了……”。这三点最好和你的目录对应，让评委一眼看到工作量。

还要提醒一下，摘要中的关键词之间用分号分隔，不要用逗号；关键词按重要程度排，不要把“计算机”这种个大词放第一位。比如上面图书馆管理系统的关键词可以写：图书管理；Flask；B/S架构；数据库；访问控制。这五个词都能在摘要正文中找到依据，不是乱选的。

2.3 需求分析与系统设计：用例图、E-R图与数据库表的落地

需求分析这一章要回答一个问题：系统到底要“干什么”。最常见的写法是先用文字描述业务背景，再画用例图，给系统划分角色和功能模块。用例图我一般用 draw.io 画，比 Visio 轻量，而且能直接导出高清图片。画好之后，在论文里要用一两段话说明每个角色的权限边界，比如“普通用户只能查询和借阅，管理员可以维护图书信息”。

用例图之后就是功能模块图，把系统拆成用户管理、图书管理、借阅管理、统计管理等模块。然后进入系统设计，重点之一是数据库设计。这一步要给出E-R图，再转成数据表。论文里的数据表格式要统一，我一般用“字段、类型、约束、说明”四列，每张表都要配一段文字解释设计理由。

这里给出一个最基础的用户表建表语句，你在论文里可以这样展示：

CREATE TABLE user ( id INT PRIMARY KEY AUTO_INCREMENT COMMENT '用户ID', username VARCHAR(50) NOT NULL UNIQUE COMMENT '登录名', password VARCHAR(255) NOT NULL COMMENT '密码，加密存储', role ENUM('admin','reader') NOT NULL DEFAULT 'reader' COMMENT '角色', created_at DATETIME DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间' ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='系统用户表';

这段SQL出现的意义不只是“我们有表”，而是引出设计讨论点：为什么密码用 VARCHAR(255) 而不是明文？为什么角色用枚举而不是单独建一张权限表？为什么加 created_at？如果你能在表格后面用两三段话解释这些点，评委就会认为你有数据库设计能力，而不是照着模板抄。注意，数据表字段中的注释在论文中可以直接作为“字段说明”列，不用重复录入第二遍。

写需求分析最怕的就是“照抄网上模板”。比如把业务背景写成“随着社会信息化的发展，各个领域都在进行信息化建设……”这种话放到任何专业都成立，完全没有信息量。需求分析必须绑定你自己的项目场景：哪怕你做的就是最普通的库存管理系统，也要说清楚“当前规模有多大、人工记录遇到什么问题、谁去用、一天大概多少次操作”。这些数据来自调研，或你设定的合理假设。在论文里明确写出来，才会让人感觉到你做了分析，而不是复制。

系统设计部分除了数据库，还要界定系统架构。电大计算机论文最常见的架构是B/S架构，你要解释为什么选B/S而不是C/S：B/S无需安装客户端、更新方便、适合多用户访问。然后画一个简单的架构图：浏览器→Web服务器→数据库。技术栈的确定性从第二章就要定下来，后面系统实现章节要与之严格对应，不能前面说是Flask，后面代码却是PHP。

3. 把“系统实现”写实：关键代码、核心逻辑与测试章节的落地

3.1 技术栈怎么选：不要为“新颖”买单，选你三个月内能把系统跑起来的

这是一个经常被忽视的选题问题。很多电大同学喜欢在论文里写“基于Spring Cloud的微服务架构”、“基于深度学习的图像识别系统”，结果开发两个月还在搭环境。我一般建议，除非你本身有很强的编程基础，否则尽量选自己课程里学过的技术栈。Java Web、Python Web、C# .NET 都是电大论文中出现频率最高、资料最全的方向。我个人的建议是：如果你只是需要快速实现一个管理信息系统，用 Python Flask 或 Django 最省力，因为代码量小、数据库操作直观；如果你要应付的是偏“软件工程”方向的导师，Java 的 Spring MVC 更容易对应上架构图。不是说不能用新技术，而是新技术要在论文里体现出“你懂原理”，不是只贴一个 running 图。

这里插一个选型对比，你在论文的前言或设计章节也可以参考：

你在论文里不需要把整个表格放进去，但自己心里要有一本账：所选技术栈必须能支撑系统实现一章的代码篇幅。如果全部代码加起来不到200行，说明系统做得太简单；如果能达到2000行，就要注意论文里不能全部贴出来，只贴核心部分。

3.2 核心代码怎么进论文：登录验证与权限控制片段

系统实现章节是整篇论文中最“实”的部分，评审老师通常会翻到这一章看代码，确认你是不是真的做了开发。代码块要满足三个条件：第一，必须是你自己项目里真实运行的；第二，单个代码块最好不要超过40行；第三，每一行都要有中文注释，或至少在代码块之后用文字解释关键参数。

我以 Flask 写的一个登录验证函数为例，这是论文里最常见的功能：

# 登录验证视图函数 @app.route('/login', methods=['GET', 'POST']) def login(): if request.method == 'POST': username = request.form.get('username').strip() password = request.form.get('password').strip() if not username or not password: return render_template('login.html', error='用户名和密码不能为空') user = User.query.filter_by(username=username).first() if user and check_password_hash(user.password, password): session['user_id'] = user.id session['role'] = user.role return redirect(url_for('index')) return render_template('login.html', error='用户名或密码错误') return render_template('login.html')

这段代码很短，但能引出好几个设计点：第一，输入先调用 strip() 去掉首尾空格，这是最基础的输入校验；第二，密码不用明文比对，用 werkzeug 的 check_password_hash 验证哈希值，安全性更高；第三，session 中只存 user_id 和 role，不存密码，避免会话泄露；第四，验证失败返回统一错误信息，不区分“用户不存在”和“密码错误”，防止信息泄露。

这些点在论文里用一个“关键方法说明”段落写出来，每个点一两句话即可。比如你还可以写：登录成功后跳转到首页，未登录用户访问受保护页面时，通过 before_request 拦截并重定向到登录页。这个拦截逻辑是权限控制的基础，建议在论文中再补充一段装饰器代码。

代码块的格式在Word里要统一设定：等宽字体（Consolas或Courier New），字号小五或五号，行距固定值18磅，中文注释用宋体或楷体。很多同学直接从IDE复制粘贴，到了Word里就变成“宋体+自动换行”，行首缩进全没了。我一般做法是在代码编辑器里先关闭自动换行，再粘贴到Word。但更稳妥的是先把代码粘贴到记事本，再从记事本复制到Word，这样可以去掉大部分IDE带来的格式残留。

3.3 测试章节不是“运行没报错”：测试用例表与结果分析

系统测试是区别“Demo”和“系统”的试金石。很多电大论文把测试写成“经测试，系统运行正常”，这是最让评委反感的写法。正确做法是设计一个测试用例表，逐条列出功能操作、输入数据、预期结果、实际结果和结论。表格可以用Word表格，也可以像我这样在草稿中用Markdown维护，最后粘贴过去：

测试用例不要只写正常流程，还要写异常流程和边界值。比如登录功能，至少测一下空输入、错误密码、特殊字符（引号）、超长用户名。边界值比如图书馆借阅数量通常限5本，那你就要测第6本时系统是否拒绝。测试结果分析不能只看“通过”两个字，要统计一共设计了多条用例、通过多少条、是否存在未通过的项，如果存在，你是如何修复的。这一节可以写“本次共设计测试用例42条，其中功能测试28条、异常测试10条、边界测试4条，全部通过。其中3条在初测时暴露了未处理空值的问题，已通过增加类型校验修复。”

这样测试章节才真正有分量。同时要注意，论文中的测试数据要与你系统演示截图对应。你截图里能看到 user01 登录，那么测试用例表里也要有 user01 这个用户，否则评委翻起来会对不上。

4. 把 .doc 收拾成正式出版物：Word 排版、目录生成与打印前检查

4.1 从“手动改字号”到“用样式”：三步生成一个不会乱的目录

很多电大要求论文以 .doc 格式提交，这本身就是个巨大的坑——因为 Word 2016 以后默认保存为 .docx，而 .doc 是兼容格式。你在编辑时可以先用 .docx，最后“另存为” .doc 即可。但文字样式、导航栏等操作与格式无关，重点是：不要手动逐个修改标题字号，而是用 Word 的“样式”功能。

我一般会这样操作：

1. 在“开始”选项卡里，把“标题1”“标题2”“正文”样式分别设置好。标题1：黑体三号、居中或左对齐，段前段后13磅；标题2：黑体四号，段前段后6磅；正文：宋体小四、首行缩进2字符、行距1.5倍。
2. 对每个章节标题，直接套用“标题1”或“标题2”样式，而不是选中文字后手动调字体。
3. 光标定位到论文最前面，插入“引用→目录”，选择自动目录。目录生成后，每当修改章节标题或页码，只需要右键目录选“更新域”，或者按 Ctrl+A 后按 F9。

注意：目录是“更新”出来的，不是“敲”出来的。

这一套流程能保证你之后调整一个标题，全文的目录、导航窗格、页眉页脚全部自动对齐。很多同学问我“为什么我的目录没有点点点？”因为目录生成后手动改了字体或多了空格，更新域就会失效。

4.2 页码、题注、交叉引用：五个必调细节

Word 排版里最容易出问题的是分节符和页码。电大论文常常要求摘要用罗马数字页码，正文从第1页重新编号阿拉伯数字。实现方式：在摘要前面插入“分节符（下一页）”，然后在第一节、第二节中分别设置页码格式。

细节一：页脚页码要取消“链接到前一条页眉”，否则两个节会同步。 细节二：页码格式在“插入→页码→设置页码格式”中，选择数字格式，并勾选“起始编号”。 细节三：图片、表格一定要用“题注自动编号”（引用→插入题注），例如“图2-1 系统架构图”“表3-2 登录测试用例表”。不要手动输入“图2-1”，否则你删掉前面一张图，后面编号不会自动变，结果就是“图2-1、图2-2、图2-3”中间缺了一个，非常不专业。 细节四：正文中引用图表时，用“交叉引用”功能，插入“图2-1”，这样看图题注变了，正文里的引用也会跟着变。 细节五：参考文献编号建议用“编号列表”或“尾注”，并在正文中用上标引用，而不是手写“[1]”。“插入尾注”能自动编号，但位置在文末，很符合论文要求。

有些同学用 MathType 插入的公式在 .doc 转 PDF 时会变成图片或乱码。如果学校要求提交 .doc，建议把公式转为 OLE 对象保留，或者用 Word 自带的“插入公式”。但最稳妥的是在定稿前把公式逻辑再口算一遍，确认排版没有溢出。公式编号要右对齐，可以在段落格式里用制表位实现，不要手动加空格。

这些细节每一条都可以在答辩前花半小时检查。如果你在交稿前发现“图3-4”后面直接跳到“图3-6”，那十有八九是有人手动删过一张图，而不是题注坏了。

4.3 从 .doc 到 PDF：字体嵌入、兼容性与打印三件事

打印前的检查同样重要。我见过一位同学在实验室电脑用 Word 2019 排好的论文，拿到打印店用老版 Word 打开，所有图片位置偏移，公式变成乱码，目录页码全跑掉。最后只能在打印店重新排版，折腾了三个小时。

避免办法就三条。 第一，在最终定稿后，主动“另存为 PDF”，先自己用 PDF 看一遍。PDF 是打印店最常用的格式，能最大限度保持排版。但注意，PDF 的字体嵌入要开启。Word 的“文件→选项→保存→将字体嵌入文件”一定要勾选，否则换电脑打开 PDF 里中文可能变成方框。 第二，交电子版时，如果学校明确要求 .doc，不要把 .docx 直接改扩展名，要用“另存为”选择 Word 97-2003 文档。另存为之后，重新打开检查一遍，因为 .doc 不支持某些新特性（比如某些 SmartArt 图可能变为图片）。 第三，打印之前检查页边距和装订线。一般 A4 纸默认上下2.54cm、左右3.17cm，但学校模板可能要求页边距2.6cm、左侧额外1cm装订线。在“布局→页边距→自定义页边距”里设置装订线位置为“左”，数值1cm。打印时不要选“缩放打印”，选实际大小。

另外，页眉页脚也是伪装“正规军”的关键。页眉通常放“某某专业毕业论文”或“第X页”，页脚放页码。如果你的论文标题很长，页眉不要用全称，使用“电大计算机科学与技术专业毕业论文”这种固定短句。页眉线要用“边框”里的“下框线”，不要自己用绘图工具画。设置好后，整个文档页眉要统一，不能第一章一个页眉，第三章另一个页眉。这些都可以在“页眉和页脚工具”里设置“链接到前一条”来统一。

5. 避坑：毕业论文写作里的五个常见问题与排查方法

5.1 目录页码错乱：一更新就面目全非

现象：插入的目录在修改后按 F9 更新，结果页码全变了，或者某些标题没出现在目录里。

原因：大多是目录不是用“自动目录”生成，而是手动敲的，或者标题没套用内置标题样式。

解决：删除现有目录，重新“插入引用→目录”，然后逐章检查：所有“标题1”“标题2”是否都套用了样式，有没有把“摘要”“参考文献”也设为标题级别。更新时先全选，再按 F9，选择“更新整个目录”，而不是“只更新页码”。如果更新后目录出现“标题6”这种杂项，说明标题样式用错了，要统一调整。

5.2 代码块在Word里被切断：翻页后代码上下半截分离

现象：一段代码正好位于两页交界处，Word 自动把代码从中间断开，阅读时非常影响观感。

原因：默认段落设置允许跨页断行，代码段又较长。

解决：选中所有代码段，在“段落→换行和分页”中勾选“段中不分页”。如果代码段特别长，可以再勾选“与下段同页”或者给代码段设置“段前分页”。另外，给代码统一使用一个自定义段落样式“代码”，设置缩进、字体和“段中不分页”，这样所有代码都安全。

5.3 查重率居高不下：重复的不只是“现状”，还有技术描述

现象：论文写完查重，重复率超过30%，尤其集中在系统实现、测试描述章节。

原因：很多同学用网上模板的语言来写“系统采用MVC模式，用户通过浏览器发送请求，Controller接收请求并处理，返回结果给视图层。”这种话是教科书原文，查重系统一抓一个准。

解决：不要直接抄教科书或博客。用自己的项目细节重写技术描述。比如“本系统在登录请求到达 Flask 路由后，先调用表单校验函数，再查询 SQLAlchemy 模型对应的 user 表，密码校验成功后将 session 和 Cookie 中的登录标记写入浏览器。”同样的意思，加入自己的项目变量名、函数名、数据表名，重复率会大幅下降。同时，参考文献要按标准格式著录，正文中的引用不要大段复制。

5.4 图表题注对不上：删了一张图后编号全乱

现象：论文写到后期，删除了第2章的一张示意图，后面所有图编号都少了一个，但正文里的引用还写着“如图2-3所示”，实际上图变成图2-2了。

原因：题注和交叉引用都是手动输入的，不是自动编号。

解决：全部改为“插入题注”和“交叉引用”。操作方法：选中图片，右键“插入题注”，选择标签“图”，编号包含章节号，Word 会自动编号，并在删除图片后自动更新。正文引用时，点击“引用→交叉引用”，选择“图”类型，插入的引用会自动跟随题注变化。最后按 F9 全文档更新域即可。

5.5 答辩 PPT 与论文不一致：讲了半小时，评委没看到核心功能

现象：答辩时照着 PPT 念技术原理，没演示系统，或者 PPT 里的功能截图与论文不是同一版本，评委提问时对不上。

原因：没有留出“答辩演示”的统一入口。论文定稿后，系统可能又改了几次，截图已经变化，但论文中没有更新。

解决：答辩前一周，把系统恢复到一个“稳定版本”，重新截图，替换论文中所有关键功能图，同时把这些图重做成 PPT 的演示页。PPT 的目录按论文结构排：背景、功能图、核心代码、测试结果。演示时遵守“两分钟讲完背景，五分钟走完流程，剩下时间等提问”。这样即便 PPT 细节记不清，评委看到的也是与论文一致的证据。

6. 最后的加分技巧：用一次“构建检查”把论文变成可交付的成果

写作、排版、查重都完成之后，不要急着提交。把整个过程想象成一次“编译”：如果你把论文交给打印店，他打开 .doc 后会不会变乱？如果你现场演示，系统会不会因为数据库没启动而崩溃？所以我习惯在最终交付前，给自己列一张“构建检查清单”，一项一项过：

• 目录是否最新：按 F9 更新过一次吗？
• 所有图表题注是否有错号、缺失？
• 代码块是否能用一种等宽字体统一显示？
• 参考文献在正文中是否都有上标引用，一一对应？
• 系统能否在 U 盘里的“免安装”环境直接跑起来？
• PDF 是否嵌入字体，打印店打开不变形？

这个检查清单每次提交前都跑一遍，比临时检查有效率得多。我当年因为没跑这个清单，去了打印店才发现老 Word 把公式显示成“域代码”，只能当场重装公式编辑器，紧张到冒汗。后来我把“文件→选项→保存→将字体嵌入文件”和“另存为PDF”强制写进每次交付流程，再也没出过事。

答辩之前，再花十分钟做一次“演示彩排”：打开系统，按论文里的测试用例顺序，从登录、增删改查到报表输出，全部走一遍，并准备一张“系统环境说明表”，写明操作系统、Python/Java版本、依赖包版本。这是评委常问的“在什么环境跑起来的”。把这张表放在 PPT 结尾，评委问的时候不用翻。

说到底，毕业论文是一个“做完之后才有资格写”的工程任务。如果一开始没有选对技术栈、没有按需求设计完善，后面几个月的写作都会很痛苦。反过来，系统做得靠谱，论文只是把过程讲清楚而已。希望这份基于 .doc 文件的完整思路，能把你的论文从“能交”推到“能打”。希望帮到你。

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