111111
This commit is contained in:
307
example/2026届网络工程毕业设计论文撰写规范-（应用开发类).md
Normal file
307
example/2026届网络工程毕业设计论文撰写规范-（应用开发类).md
Normal file
@@ -0,0 +1,307 @@
|
||||
# 2026届网络工程毕业设计
|
||||
|
||||
# 论文撰写规范（应用开发类）
|
||||
|
||||
中文摘要 (3-5 个关键词)
|
||||
|
||||
# 英文摘要
|
||||
|
||||
# 目录
|
||||
|
||||
# 第1章绪论
|
||||
|
||||
1.1 课题来源及意义
|
||||
|
||||
1.2 课题研究现状
|
||||
|
||||
1.3当前存在的问题
|
||||
|
||||
1.4 课题研究目标
|
||||
|
||||
# 第2章主要技术和框架
|
||||
|
||||
2.1 主要技术 (开发系统或平台所需相关技术的介绍)
|
||||
|
||||
# 2.2 框架和开发模式（开发系统或平台所使用的框架和开发模式的介绍）
|
||||
|
||||
# 第3章XXXXX的系统分析
|
||||
|
||||
# 3.1需求分析（包括功能需求分析和性能需求分析）
|
||||
|
||||
3.2可行性分析（包括技术可行性、操作可行性、经济可行性，社会可行性等）
|
||||
|
||||
3.3 用例图（根据系统角色划分用例图，若有两个角色就有两个用例图）
|
||||
|
||||
3.3.1 用户用例图（需先对用例图进行描述，其实也就是对该系统的用户角色进行权限分析，再画出具体用户用例图，用例图如下所示）
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
图3.1用户用例图
|
||||
|
||||
|
||||
3.3.2 管理员用例图（需先对用例图进行描述，其实也就是对该系统的用户角色进行权限分析，再画出具体用户用例图，用例图如下所示）
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
图3.2管理员用例图
|
||||
|
||||
|
||||
3.4 用例描述（用例描述是对用例图中用例的详细说明，它详细阐述了用例的功
|
||||
|
||||
能实现过程、输入输出、前置条件、后置条件以及可能的异常情况等，是对用例图
|
||||
|
||||
的补充和细化，使系统功能更加清晰具体。需分别对每个用例列举3个左右的用
|
||||
|
||||
例描述。）
|
||||
|
||||
例：（1）用户管理地址用例描述如下表3.1所示。
|
||||
|
||||
|
||||
表 3.1 用户管理地址用例描述
|
||||
|
||||
|
||||
<table><tr><td>用例名称：管理地址</td></tr><tr><td>执行者：用户</td></tr><tr><td>简要说明：用户对收货地址进行添加、修改、删除等管理操作</td></tr><tr><td>基本事件流：
|
||||
1.用户登录平台，进入地址管理界面
|
||||
2.系统显示已有地址列表
|
||||
3.用户选择添加新地址，输入详细地址信息，验证通过后存储地址
|
||||
4.若修改地址，系统更新后提示成功，若删除地址，确认操作后数据库移除该地址记录</td></tr><tr><td>(2)用户查看商品用例描述如下表3.2所示。
|
||||
表3.2用户查看商品用例</td></tr><tr><td>用例名称：查看商品</td></tr><tr><td>执行者：用户</td></tr><tr><td>简要说明：用户分类浏览平台上的闲置商品</td></tr><tr><td>基本事件流：
|
||||
1.用户登录平台，进入查看商品界面
|
||||
2.选择商品分类，如闲置书籍、衣服、手机等；
|
||||
3.系统加载并显示该分类下的商品列表
|
||||
4.用户可点击具体商品，查看详细信息，如介绍、图片、价格等</td></tr></table>
|
||||
|
||||
# 3.5 系统性能分析
|
||||
|
||||
# 第4章XXXXX的系统设计
|
||||
|
||||
4.1系统功能设计(先总体概述一段该系统的主要角色有哪几个，分别包含什么主
|
||||
|
||||
要功能，再给出功能结构图。)
|
||||
|
||||
具体如图4.1和图4.2所示。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
图4.1用户功能结构图
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
图4.2管理员功能结构图
|
||||
|
||||
|
||||
4.2 类图（根据给定的初步类图，详细描述每个类的属性、方法以及类之间的具体关系。）
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
图4.3系统类图
|
||||
|
||||
|
||||
4.3 序列图（展示了对象之间随时间顺序发生的消息传递，通常用于描述用例的实现过程或系统中某个功能的动态行为。至少需列举系统角色各一个序列图，在给出序列图之前还需将过程的详细步骤写出。如：用户登录序列图、管理员删除账号序列图。）
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
图4.4用户购买商品功能序列图
|
||||
|
||||
|
||||
4.4 活动图（活动图可以清晰地描述系统的动态行为和工作流程。例如，在描述一个在线购物系统的订单处理流程时，可以通过活动图展示从用户下单到订单完成的各个步骤。论文中至少需描述各个角色各一个活动的活动图，如用户更新个人信息活动图，管理员删除用户信息活动图。）
|
||||
|
||||
# 4.4.1 用户填写个人信息活动图
|
||||
|
||||
用户填写个人信息过程可分为以下几步：
|
||||
|
||||
(1) 用户输入验证账号密码。
|
||||
|
||||
(2) 数据库查询用户数据，并判断用户是否存在。
|
||||
|
||||
(3) 登录成功后，用户填写个人信息并提交。
|
||||
|
||||
(4) 系统接收提交的个人信息后，将其发送至数据库进行更新保存。
|
||||
|
||||
(5) 用户确认信息更新无误后，更新界面。
|
||||
|
||||
用户填写个人信息活动图如下图4.7所示。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
图4.7 用户填写个人信息活动图
|
||||
|
||||
|
||||
# 4.5 数据库设计
|
||||
|
||||
撰写说明：
|
||||
|
||||
本章是重点章节，很多同学搞不清概念设计、逻辑设计和物理设计的关系，请参见另外一个文档《2026届网络工程毕业论文第4章-数据库设计撰写规范（应用开发类补充说明）.docx》：
|
||||
|
||||
4.5.1 概念设计（概念设计包括两部分：实体属性图（不少于8个实体，每个实体
|
||||
|
||||
标明属性图的主码）和总体E-R图）
|
||||
|
||||
# (1) 管理员实体
|
||||
|
||||
管理员实体属性图如图4.9所示。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
图4.9管理员实体属性图
|
||||
|
||||
|
||||
# (2）用户实体
|
||||
|
||||
用户实体属性图如图4.10所示。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
图4.10用户实体属性图
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
图4.系统E-R图（标明各个实体之间的关联）
|
||||
|
||||
|
||||
4.5.2 逻辑设计（将E-R图中的实体关系转换为逻辑结构设计，即关系模式。
|
||||
|
||||
其中，一个实体转换为 1 个单独的关系模式。
|
||||
|
||||
实体间联系有3种，1:1，1:n，n:m。
|
||||
|
||||
1:n 联系要将 1 端实体如用户的主码加入到 n 端如评论实体的关系模式中。
|
||||
|
||||
n:m 联系要将联系如上图中的购买转换成一个单独的关系模式,并将两端的主
|
||||
|
||||
码放入该关系模式作为属性。）关系模式中需标明主外码
|
||||
|
||||
上图转换为逻辑结构如下所示：
|
||||
|
||||
(1) 用户表：(用户 id, 用户账号, 密码, 用户姓名, 性别, 联系电话, 头像, 积分，余额)
|
||||
|
||||
(2) 管理员表: (管理员 id, 创建时间, 管理员名称, 密码, 管理员类型)
|
||||
|
||||
(3) 收货地址表：（收货地址id，用户id，地址，收货人，电话，是否为默认地址）
|
||||
|
||||
(4) 购物车表：（购物车id，商品表名，商品，商品名称，图片，购买数量，单价，会员价，商品类型）
|
||||
|
||||
(5) 订单表：（订单id，订单编号，用户id，规格，上架时间，商品详情，团购价，拼团人数）
|
||||
|
||||
(6) 团购商品表：（团购商品id，购买数量，价格，折扣价，总价，商品类型id，支付类型，物流，购物车id）
|
||||
|
||||
(7) 商品类型表：（商品类型 id，创建时间，类型数量）
|
||||
|
||||
(8) 评论表：（评论id，用户id，头像，用户名，评论内容，回复内容）
|
||||
|
||||
(9) 公告表：（公告id，创建时间，标题，简介，图片，内容，管理员id）
|
||||
|
||||
(10) 购买表：（用户 id，团购商品 id，购买日期，购买时间）（购买表的外键为：
|
||||
|
||||
用户id，团购商品id)
|
||||
|
||||
4.5.3 物理设计（将上述关系模式转换为一个个物理表结构，一个关系模式转换为一个物理表，至少包含8张物理表）
|
||||
|
||||
如：（1）系统根据MySQL数据库数据存储的特性设计数据库关系表：
|
||||
|
||||
|
||||
表 4.1 管理员表 (admin 表)
|
||||
|
||||
|
||||
<table><tr><td>字段名称</td><td>字段意义</td><td>数据类型</td><td>长度</td><td>完整性约束</td></tr><tr><td>admin_id</td><td>管理员 id</td><td>int</td><td>10</td><td>主键</td></tr><tr><td>admin_name</td><td>管理员姓名</td><td>varchar</td><td>10</td><td>非空</td></tr><tr><td>admin_password</td><td>管理员密码</td><td>varchar</td><td>20</td><td>非空</td></tr><tr><td>admin_email</td><td>管理员邮箱</td><td>varchar</td><td>20</td><td>非空</td></tr><tr><td>admin_phone</td><td>管理员手机号</td><td>varchar</td><td>11</td><td>非空</td></tr></table>
|
||||
|
||||
|
||||
表 4.2 用户表 (user 表)
|
||||
|
||||
|
||||
<table><tr><td>字段名称</td><td>字段意义</td><td>数据类型</td><td>长度</td><td>完整性约束</td></tr><tr><td>user_id</td><td>用户id</td><td>int</td><td>10</td><td>主键</td></tr><tr><td>user_name</td><td>用户昵称</td><td>varchar</td><td>10</td><td>非空</td></tr><tr><td>user_password</td><td>用户密码</td><td>varchar</td><td>20</td><td>非空</td></tr><tr><td>user/mobile</td><td>用户电话</td><td>varchar</td><td>11</td><td>非空</td></tr><tr><td>user_realname</td><td>用户真实姓名</td><td>varchar</td><td>10</td><td>非空</td></tr><tr><td>user_score</td><td>信誉分</td><td>int</td><td>4</td><td>非空</td></tr></table>
|
||||
|
||||
|
||||
表4.3商品表 (product表)
|
||||
|
||||
|
||||
<table><tr><td>字段名称</td><td>字段意义</td><td>数据类型</td><td>长度</td><td>完整性约束</td></tr><tr><td>product_id</td><td>商品id</td><td>int</td><td>10</td><td>主键</td></tr><tr><td>product_name</td><td>商品名称</td><td>varchar</td><td>10</td><td>非空</td></tr><tr><td>product_title</td><td>商品概要</td><td>varchar</td><td>50</td><td>非空</td></tr><tr><td>product_intro</td><td>商品详情</td><td>varchar</td><td>100</td><td>非空</td></tr></table>
|
||||
|
||||
4.6图形界面设计（实现某一个具体功能的界面设计，至少系统中各角色各列举1
|
||||
|
||||
# 个功能界面设计)
|
||||
|
||||
如：删除购物车界面设计
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
图4. 删除购物车界面设计图
|
||||
|
||||
|
||||
# 第5章XXXXX的系统实现
|
||||
|
||||
只写出主要功能的实现结果即可，并给出运行截图（不写用户注册、登录），
|
||||
|
||||
运行截图中需输入数据的地方要有数据输入，且输入的数据必须真实，不可输入
|
||||
|
||||
类似 1111 类数据。可按系统角色进行实现，再进行角色详细功能实现。如：
|
||||
|
||||
# 5.1 用户功能模块
|
||||
|
||||
# 5.1.1 购物车
|
||||
|
||||
# 5.1.2 我的订单
|
||||
|
||||
··
|
||||
|
||||
# 5.2 管理员功能模块
|
||||
|
||||
# 5.2.1 账号管理
|
||||
|
||||
# 5.2.2 订单管理
|
||||
|
||||
··
|
||||
|
||||
# 第6章XXXXX的系统测试
|
||||
|
||||
# 6.1 系统测试概述
|
||||
|
||||
6.1.1 测试的背景
|
||||
|
||||
6.1.2 测试的意义
|
||||
|
||||
6.1.3 测试的环境
|
||||
|
||||
# 6.2 系统测试用例设计
|
||||
|
||||
6.2.1XXXX功能测试
|
||||
|
||||
6.2.2XXXX功能测试
|
||||
|
||||
6.2.3XXXX功能测试
|
||||
|
||||
6.2.4 安全性测试
|
||||
|
||||
6.2.5 兼容性测试
|
||||
|
||||
# 第7章结论
|
||||
|
||||
参考文献
|
||||
|
||||
致谢
|
||||
|
||||
附录
|
||||
Reference in New Issue
Block a user