diff --git a/example/2026届网络工程毕业设计论文撰写规范-(应用开发类).md b/example/2026届网络工程毕业设计论文撰写规范-(应用开发类).md new file mode 100644 index 0000000..24b37cd --- /dev/null +++ b/example/2026届网络工程毕业设计论文撰写规范-(应用开发类).md @@ -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 用户用例图(需先对用例图进行描述,其实也就是对该系统的用户角色进行权限分析,再画出具体用户用例图,用例图如下所示) + +![image](https://cdn-mineru.openxlab.org.cn/result/2026-01-30/cb195f07-5e0a-4b42-8211-f649b1c1b2df/fedda2aecd9c17cf7f678bd9dfce3c4005225a98e76f2b3c551c72ab00f31ab0.jpg) + + + +图3.1用户用例图 + + +3.3.2 管理员用例图(需先对用例图进行描述,其实也就是对该系统的用户角色进行权限分析,再画出具体用户用例图,用例图如下所示) + +![image](https://cdn-mineru.openxlab.org.cn/result/2026-01-30/cb195f07-5e0a-4b42-8211-f649b1c1b2df/85b57ee2a2135507c52a9eaab015e3bbf5218d259fefa8256bf6efc10fa0b42a.jpg) + + + +图3.2管理员用例图 + + +3.4 用例描述(用例描述是对用例图中用例的详细说明,它详细阐述了用例的功 + +能实现过程、输入输出、前置条件、后置条件以及可能的异常情况等,是对用例图 + +的补充和细化,使系统功能更加清晰具体。需分别对每个用例列举3个左右的用 + +例描述。) + +例:(1)用户管理地址用例描述如下表3.1所示。 + + +表 3.1 用户管理地址用例描述 + + +
用例名称:管理地址
执行者:用户
简要说明:用户对收货地址进行添加、修改、删除等管理操作
基本事件流: +1.用户登录平台,进入地址管理界面 +2.系统显示已有地址列表 +3.用户选择添加新地址,输入详细地址信息,验证通过后存储地址 +4.若修改地址,系统更新后提示成功,若删除地址,确认操作后数据库移除该地址记录
(2)用户查看商品用例描述如下表3.2所示。 +表3.2用户查看商品用例
用例名称:查看商品
执行者:用户
简要说明:用户分类浏览平台上的闲置商品
基本事件流: +1.用户登录平台,进入查看商品界面 +2.选择商品分类,如闲置书籍、衣服、手机等; +3.系统加载并显示该分类下的商品列表 +4.用户可点击具体商品,查看详细信息,如介绍、图片、价格等
+ +# 3.5 系统性能分析 + +# 第4章XXXXX的系统设计 + +4.1系统功能设计(先总体概述一段该系统的主要角色有哪几个,分别包含什么主 + +要功能,再给出功能结构图。) + +具体如图4.1和图4.2所示。 + +![image](https://cdn-mineru.openxlab.org.cn/result/2026-01-30/cb195f07-5e0a-4b42-8211-f649b1c1b2df/eac455914323329b18745df5545040771c017cdc8a0d678f5569589c30bf1f4e.jpg) + + + +图4.1用户功能结构图 + + +![image](https://cdn-mineru.openxlab.org.cn/result/2026-01-30/cb195f07-5e0a-4b42-8211-f649b1c1b2df/18177e942ba24fd2a163cebfaf31c07e24ad1f0c3c3bb57deb63dff73bc44a22.jpg) + + + +图4.2管理员功能结构图 + + +4.2 类图(根据给定的初步类图,详细描述每个类的属性、方法以及类之间的具体关系。) + +![image](https://cdn-mineru.openxlab.org.cn/result/2026-01-30/cb195f07-5e0a-4b42-8211-f649b1c1b2df/e677faab545e5c9b75f847b7d786df1e0c2e764b6475056e4ed0f2b769dcf25f.jpg) + + + +图4.3系统类图 + + +4.3 序列图(展示了对象之间随时间顺序发生的消息传递,通常用于描述用例的实现过程或系统中某个功能的动态行为。至少需列举系统角色各一个序列图,在给出序列图之前还需将过程的详细步骤写出。如:用户登录序列图、管理员删除账号序列图。) + +![image](https://cdn-mineru.openxlab.org.cn/result/2026-01-30/cb195f07-5e0a-4b42-8211-f649b1c1b2df/b707fad3bc4d4d52a6b9da497d9bfdc7c365eac728f93991ea0c2488b2ccb653.jpg) + + + +图4.4用户购买商品功能序列图 + + +4.4 活动图(活动图可以清晰地描述系统的动态行为和工作流程。例如,在描述一个在线购物系统的订单处理流程时,可以通过活动图展示从用户下单到订单完成的各个步骤。论文中至少需描述各个角色各一个活动的活动图,如用户更新个人信息活动图,管理员删除用户信息活动图。) + +# 4.4.1 用户填写个人信息活动图 + +用户填写个人信息过程可分为以下几步: + +(1) 用户输入验证账号密码。 + +(2) 数据库查询用户数据,并判断用户是否存在。 + +(3) 登录成功后,用户填写个人信息并提交。 + +(4) 系统接收提交的个人信息后,将其发送至数据库进行更新保存。 + +(5) 用户确认信息更新无误后,更新界面。 + +用户填写个人信息活动图如下图4.7所示。 + +![image](https://cdn-mineru.openxlab.org.cn/result/2026-01-30/cb195f07-5e0a-4b42-8211-f649b1c1b2df/1167b27131dd2f56dcf570a6d1f2ad3888a8cb31390877f532d47161d49aaabc.jpg) + + + +图4.7 用户填写个人信息活动图 + + +# 4.5 数据库设计 + +撰写说明: + +本章是重点章节,很多同学搞不清概念设计、逻辑设计和物理设计的关系,请参见另外一个文档《2026届网络工程毕业论文第4章-数据库设计撰写规范(应用开发类补充说明).docx》: + +4.5.1 概念设计(概念设计包括两部分:实体属性图(不少于8个实体,每个实体 + +标明属性图的主码)和总体E-R图) + +# (1) 管理员实体 + +管理员实体属性图如图4.9所示。 + +![image](https://cdn-mineru.openxlab.org.cn/result/2026-01-30/cb195f07-5e0a-4b42-8211-f649b1c1b2df/f0139dd7d92cc9b47066ec9de102f1667c1ce1e48206094d7a2bdef274205425.jpg) + + + +图4.9管理员实体属性图 + + +# (2)用户实体 + +用户实体属性图如图4.10所示。 + +![image](https://cdn-mineru.openxlab.org.cn/result/2026-01-30/cb195f07-5e0a-4b42-8211-f649b1c1b2df/6d6a6cb8e810b97076d80cd79891215ff2119fc737339c35edd15ad884bba839.jpg) + + + +图4.10用户实体属性图 + + +![image](https://cdn-mineru.openxlab.org.cn/result/2026-01-30/cb195f07-5e0a-4b42-8211-f649b1c1b2df/0f95a66d6d06fcc3c2727444cdea2f4793ac489748efa04d7bfa75c3578d1d9c.jpg) + + + +图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 表) + + +
字段名称字段意义数据类型长度完整性约束
admin_id管理员 idint10主键
admin_name管理员姓名varchar10非空
admin_password管理员密码varchar20非空
admin_email管理员邮箱varchar20非空
admin_phone管理员手机号varchar11非空
+ + +表 4.2 用户表 (user 表) + + +
字段名称字段意义数据类型长度完整性约束
user_id用户idint10主键
user_name用户昵称varchar10非空
user_password用户密码varchar20非空
user/mobile用户电话varchar11非空
user_realname用户真实姓名varchar10非空
user_score信誉分int4非空
+ + +表4.3商品表 (product表) + + +
字段名称字段意义数据类型长度完整性约束
product_id商品idint10主键
product_name商品名称varchar10非空
product_title商品概要varchar50非空
product_intro商品详情varchar100非空
+ +4.6图形界面设计(实现某一个具体功能的界面设计,至少系统中各角色各列举1 + +# 个功能界面设计) + +如:删除购物车界面设计 + +![image](https://cdn-mineru.openxlab.org.cn/result/2026-01-30/cb195f07-5e0a-4b42-8211-f649b1c1b2df/5f2eaca38a994385483bc816a9956ee51e2a41baf561d9e08f613b9938c1de46.jpg) + + + +图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章结论 + +参考文献 + +致谢 + +附录 \ No newline at end of file diff --git a/example/爱维宠物医院管理系统毕业论文-2026版.md b/example/爱维宠物医院管理系统毕业论文-2026版.md new file mode 100644 index 0000000..ae33319 --- /dev/null +++ b/example/爱维宠物医院管理系统毕业论文-2026版.md @@ -0,0 +1,1063 @@ +# 爱维宠物医院管理系统的设计与实现(2026版) + +## 中文摘要 + +随着宠物经济持续增长,宠物医院在门诊接待、病历管理、处方流转、药品库存与经营统计等环节面临业务复杂度提升与信息化能力不足的双重压力。针对中小型宠物医院普遍存在的预约流程不顺畅、纸质病历检索困难、库存数据更新滞后、跨角色协同效率低等问题,本文围绕“爱维宠物医院管理系统”开展了系统化设计与实现工作。 + +本系统采用前后端分离架构,后端基于 Spring Boot、Spring Security、MyBatis-Plus 与 MySQL,前端基于 Vue3、Vite、Pinia、Vue Router 与 TDesign 组件库,构建了面向管理员、宠物医生与顾客三类角色的业务平台。系统在功能层面覆盖用户认证与权限控制、宠物档案管理、门诊预约、就诊记录、电子病历、电子处方、订单管理、药品出入库、公告留言、统计分析等核心模块;在工程层面落实了统一接口规范、JWT 鉴权、逻辑删除、基础审计字段与角色访问约束。 + +通过对业务流程与功能模块进行综合测试,结果表明该系统能够较好支撑宠物医院日常运营场景,提升业务处理效率与数据一致性,改善宠物主人在线服务体验,并为后续接入在线支付、预约提醒与智能分析提供可扩展基础。本文的研究与实践可为同类宠物医疗机构信息化建设提供参考。 + +**关键词:** 宠物医院管理系统;Spring Boot;Vue3;前后端分离;RBAC + +## Abstract + +With the continuous growth of the pet-care industry, pet hospitals are facing increasing pressure in outpatient reception, medical record management, prescription circulation, drug inventory control, and operational statistics. To address common problems in small and medium-sized institutions, such as inefficient appointment processes, poor retrieval of paper records, delayed inventory updates, and low cross-role collaboration efficiency, this thesis presents the design and implementation of the Aiwei Pet Hospital Management System. + +The system adopts a front-end and back-end separated architecture. The back-end is built with Spring Boot, Spring Security, MyBatis-Plus, and MySQL, while the front-end uses Vue3, Vite, Pinia, Vue Router, and TDesign. It supports three major roles: administrator, doctor, and customer. Core functions include authentication and authorization, pet profile management, appointment scheduling, visit records, electronic medical records, electronic prescriptions, order management, stock in/out management, notices and messages, and statistical dashboards. At the engineering level, the system implements unified API conventions, JWT-based authentication, logical deletion, audit fields, and role-based access constraints. + +Comprehensive functional and process-oriented testing indicates that the system can effectively support daily operations in pet hospitals, improve processing efficiency and data consistency, and enhance customer experience in online services. The project also provides an extensible foundation for future integration of online payment, appointment reminders, and intelligent analytics. This work can serve as a practical reference for informatization in similar veterinary institutions. + +**Keywords:** Pet hospital management system; Spring Boot; Vue3; Frontend-backend separation; RBAC + +## 目录 + +- [第1章 绪论](#第1章-绪论) + - [1.1 课题来源及意义](#11-课题来源及意义) + - [1.2 课题研究现状](#12-课题研究现状) + - [1.3 当前存在的问题](#13-当前存在的问题) + - [1.4 课题研究目标](#14-课题研究目标) +- [第2章 主要技术和框架](#第2章-主要技术和框架) + - [2.1 主要技术](#21-主要技术) + - [2.2 框架和开发模式](#22-框架和开发模式) +- [第3章 爱维宠物医院管理系统分析](#第3章-爱维宠物医院管理系统分析) + - [3.1 需求分析](#31-需求分析) + - [3.2 可行性分析](#32-可行性分析) + - [3.3 用例图](#33-用例图) + - [3.4 用例描述](#34-用例描述) + - [3.5 系统性能分析](#35-系统性能分析) +- [第4章 爱维宠物医院管理系统设计](#第4章-爱维宠物医院管理系统设计) + - [4.1 系统功能设计](#41-系统功能设计) + - [4.2 类图设计](#42-类图设计) + - [4.3 序列图设计](#43-序列图设计) + - [4.4 活动图设计](#44-活动图设计) + - [4.5 数据库设计](#45-数据库设计) + - [4.6 图形界面设计](#46-图形界面设计) +- [第5章 爱维宠物医院管理系统实现](#第5章-爱维宠物医院管理系统实现) + - [5.1 用户功能模块实现](#51-用户功能模块实现) + - [5.2 医生功能模块实现](#52-医生功能模块实现) + - [5.3 管理员功能模块实现](#53-管理员功能模块实现) +- [第6章 爱维宠物医院管理系统测试](#第6章-爱维宠物医院管理系统测试) + - [6.1 系统测试概述](#61-系统测试概述) + - [6.2 系统测试用例设计](#62-系统测试用例设计) + - [6.3 测试结果分析](#63-测试结果分析) +- [第7章 结论](#第7章-结论) +- [参考文献](#参考文献) +- [致谢](#致谢) + +## 第1章 绪论 + +### 1.1 课题来源及意义 + +近年来,宠物在人们家庭生活中的角色由“附属饲养对象”逐步演变为“长期陪伴成员”,宠物健康服务需求随之快速增长。与市场规模扩张相比,部分宠物医院的信息化建设相对滞后,仍以人工登记、线下排队与分散记录为主,导致运营效率与服务体验难以同步提升。 + +本课题来源于宠物医院真实业务痛点,旨在构建一套覆盖“预约-接诊-病历-处方-库存-结算-统计”链路的管理平台。课题意义主要体现在三个方面: + +1. 业务规范化:通过流程化系统替代低效人工操作,降低关键环节差错率; +2. 数据可追溯:建立统一数据模型,保证诊疗、用药、库存与订单之间的关联关系; +3. 服务可持续:为后续功能扩展(如在线支付、提醒通知、数据分析)提供可演进架构。 + +### 1.2 课题研究现状 + +国外宠物医疗信息化实践起步较早,常见系统已支持线上预约、电子病历、处方流转与经营分析,并在智能化方向探索远程服务和决策支持。国内相关系统近年来发展迅速,更多集中于基础业务数字化建设,包括用户管理、预约管理、病历与处方管理、药品库存管理等。 + +总体来看,当前国内同类系统在“业务闭环完整性”和“系统集成深度”方面仍有提升空间,尤其体现在支付闭环、提醒机制、跨角色协同与深度统计分析等方面。因此,结合本地场景构建可落地、可迭代的宠物医院管理系统具有现实价值。 + +### 1.3 当前存在的问题 + +经需求调研与项目分析,宠物医院管理现状主要存在以下问题: + +1. 预约环节缺乏统一调度,容易出现时间冲突或人工确认延迟; +2. 病历与处方数据分散,历史信息检索与复用效率较低; +3. 药品出入库记录与诊疗流程联动不足,库存预警能力有限; +4. 顾客端在线服务入口不足,查询、跟踪、反馈体验不连续; +5. 经营统计维度有限,难以支撑精细化运营决策。 + +### 1.4 课题研究目标 + +本课题目标是在现有业务流程基础上实现一套可运行、可管理、可扩展的宠物医院管理系统,具体目标如下: + +1. 建立面向管理员、医生、顾客三类角色的统一业务平台; +2. 打通预约、接诊、病历、处方、订单、库存的核心业务链路; +3. 提供基础权限控制、数据校验与接口规范,提升系统可靠性; +4. 形成可用于毕业设计论文的完整系统分析、设计、实现与测试材料。 + +### 1.5 研究内容与论文结构安排 + +围绕课题目标,本文从“问题定义、技术路径、系统落地、效果验证”四个层面展开。第一步,通过业务调研明确宠物医院在预约、接诊、病历、处方、库存和运营统计中的关键痛点;第二步,基于前后端分离思想确定技术选型与系统边界,构建可扩展的模块化架构;第三步,结合角色职责进行功能设计与实现,确保顾客、医生、管理员三端能力协同;第四步,采用功能测试与流程测试相结合的方法验证系统可用性,归纳不足并提出后续优化路线。 + +从论文组织上看,第1章给出研究背景和目标;第2章阐述技术基础与开发模式;第3章完成需求、可行性与用例分析;第4章进行架构、数据库与界面设计;第5章描述系统实现结果;第6章给出测试方案与结果分析;第7章总结研究成果并提出展望。该结构遵循“先分析、后设计、再实现、终测试”的工程论文写作逻辑,能够保证论证链条完整、内容前后呼应。 + +## 第2章 主要技术和框架 + +### 2.1 主要技术 + +#### 2.1.1 后端技术 + +- Spring Boot:用于构建后端服务,简化项目配置并提升开发效率; +- Spring Security:负责身份认证与访问控制; +- MyBatis-Plus:简化数据库 CRUD 与分页查询实现; +- MySQL:承担核心业务数据持久化存储; +- JWT:实现无状态登录认证与角色信息传递。 + +#### 2.1.2 前端技术 + +- Vue3:用于构建组件化前端应用; +- Vue Router:实现多角色页面路由与导航守卫; +- Pinia:负责用户认证状态与全局状态管理; +- Axios:用于封装接口请求; +- TDesign Vue Next:提供基础 UI 组件与交互能力; +- Vite:作为前端构建与开发工具。 + +### 2.2 框架和开发模式 + +#### 2.2.1 前后端分离开发模式 + +系统采用前后端分离模式。后端提供 REST 风格接口,前端通过 HTTP 请求调用业务能力。这种模式有利于角色页面独立演进、接口复用与后期多端扩展。 + +#### 2.2.2 RBAC 权限模型 + +系统围绕角色进行权限约束,核心角色包括: + +- `ADMIN`:系统级管理权限,负责用户、药品、统计与全局数据管理; +- `DOCTOR`:诊疗业务权限,负责接诊、病历、处方等专业操作; +- `CUSTOMER`:顾客自助权限,负责预约、宠物档案与个人查询服务。 + +#### 2.2.3 统一接口与数据规范 + +系统在接口层使用统一响应结构,并在数据层采用逻辑删除与统一时间戳字段(创建/更新时间),保障数据生命周期管理与后续审计扩展能力。 + +### 2.3 技术选型对比与决策依据 + +在技术选型过程中,项目遵循“满足业务需求优先、学习与维护成本可控、后续扩展路径清晰”的原则。后端框架方面,最终选择 Spring Boot 作为主框架,主要考虑其在企业级开发中的成熟度高、生态完整、与安全和数据访问组件集成成本低。与传统手工整合方案相比,Spring Boot 在工程初始化、依赖管理、运行维护和配置管理方面具有明显优势,能够缩短开发周期并降低环境差异带来的风险。 + +在数据访问层,项目选择 MyBatis-Plus 而非仅使用原生 MyBatis,核心原因是其在保留灵活 SQL 能力的同时提供了高频 CRUD 能力、分页支持与统一条件构造方式,适合毕业设计阶段多实体并行开发场景。数据库方面采用 MySQL,主要考虑其在事务一致性、索引优化和部署便利性上的综合平衡,能够满足中小规模业务系统的数据存储需求。 + +前端技术方面,选择 Vue3 + Vite 的组合,以获得更好的开发体验与构建效率。Vue3 的组合式 API 适合中型系统按业务模块拆分组件,便于后续维护;Vite 在本地开发热更新和生产构建方面效率较高。状态管理采用 Pinia,路由管理采用 Vue Router,二者与 Vue3 官方生态契合度高,有利于实现角色隔离与导航守卫。UI 组件库选择 TDesign,能够较快完成后台型界面的统一风格建设,减少重复样式开发工作。 + +安全机制方面,系统采用 Spring Security + JWT 的组合。相较于传统会话机制,JWT 在前后端分离场景下更便于跨服务身份携带与无状态认证,同时降低服务端会话存储负担。考虑到毕业设计系统规模与部署方式,该方案在复杂度与可用性之间实现了较好平衡。 + +### 2.4 本章小结 + +本章围绕系统实现所需的技术基础进行了梳理,并给出了关键技术选型的决策理由。通过对后端框架、前端框架、数据访问方案、鉴权模式和工程化工具的综合比较,确定了本项目的技术路线。该路线不仅能够支撑当前业务需求实现,也为后续功能扩展与系统优化提供了稳定基础。 + +## 第3章 爱维宠物医院管理系统分析 + +### 3.1 需求分析 + +#### 3.1.1 功能需求分析 + +1. 顾客侧:注册登录、宠物档案维护、门诊预约、订单查询、报告查询; +2. 医生侧:预约接诊、就诊记录、病历维护、处方开具与查看; +3. 管理侧:账户管理、公告管理、药品与库存管理、统计分析。 + +#### 3.1.2 性能需求分析 + +1. 响应性:常规查询与列表展示应保持较快响应,避免长时间等待; +2. 并发性:满足中小型机构多岗位并行操作的基础并发访问需求; +3. 可用性:关键业务模块应具备稳定运行能力,避免核心流程中断; +4. 可维护性:模块边界清晰,便于后续扩展与缺陷修复。 + +#### 3.1.3 详细业务需求分解 + +为保证需求可执行、可测试,本系统进一步将核心需求拆分为角色维度和流程维度两类。 + +(1)顾客角色需求分解: + +1. 账户能力:支持注册、登录、身份保持、个人资料维护; +2. 宠物能力:支持宠物档案新增、编辑、删除和按主人维度查询; +3. 预约能力:支持选择日期时段提交预约、查询预约记录、查看预约状态; +4. 查询能力:支持订单信息查询、报告信息查询和历史数据浏览; +5. 交互能力:支持通过公告或留言渠道获取医院通知与反馈入口。 + +(2)医生角色需求分解: + +1. 接诊能力:支持按预约或就诊对象进入接诊流程; +2. 病历能力:支持主诉、检查结果、诊断结论和处理建议的结构化录入; +3. 处方能力:支持处方创建、处方项维护、处方状态流转; +4. 检索能力:支持按宠物、顾客和时间维度查询历史记录。 + +(3)管理员角色需求分解: + +1. 用户能力:支持用户列表管理、状态管理和角色可见范围控制; +2. 公告能力:支持公告发布、更新和状态管理; +3. 药品能力:支持药品信息维护、入库出库记录管理; +4. 统计能力:支持基础经营数据展示,辅助运营判断。 + +(4)流程协同需求分解: + +1. 预约到接诊:顾客预约信息应可被医生侧检索并用于创建就诊记录; +2. 接诊到病历:就诊记录应可关联病历,形成连续诊疗轨迹; +3. 病历到处方:病历结论应支持医生创建处方并维护处方明细; +4. 处方到库存:处方用药应能够支撑库存管理场景的数据联动(当前实现基础联动); +5. 全链路可追溯:关键业务对象均需记录创建时间、更新时间和状态字段。 + +#### 3.1.4 非功能需求细化 + +(1)性能需求: + +系统在常见操作场景下需保持流畅交互体验,分页查询、筛选查询与表单提交应在可接受时延范围内完成。对于批量数据展示场景,优先采用分页和条件查询策略,避免一次性加载过多数据导致前后端压力集中。 + +(2)安全需求: + +系统需保证认证有效性与权限边界清晰性。未认证请求不得访问受限资源;不同角色之间应按职责隔离页面与接口可见范围;关键表单数据应进行参数合法性约束,避免无效或异常输入直接进入业务流程。 + +(3)可用性需求: + +系统应具备清晰的操作反馈机制,包括成功提示、失败提示和状态展示,减少用户因信息不透明导致的误操作。对常见业务页面采用统一布局与交互习惯,降低学习成本。 + +(4)可维护性需求: + +系统模块应按职责划分,便于后续局部迭代。接口命名、状态字段、时间字段和删除策略应统一,以减少维护过程中的理解偏差。文档与图表需与系统版本同步更新,确保“文档可追踪、实现可验证”。 + +(5)可扩展性需求: + +在不大幅重构现有架构的前提下,系统应具备接入支付能力、提醒能力、报表导出能力和更多统计维度的空间。新增业务应尽量在现有数据模型基础上做增量扩展,而非破坏既有核心表结构。 + +### 3.2 可行性分析 + +#### 3.2.1 技术可行性 + +本系统所采用技术栈成熟、社区生态完善,能够支持角色权限、业务流程编排、数据持久化与前端交互等核心需求。前后端分离模式对团队协作和功能增量开发友好,技术风险可控。 + +#### 3.2.2 经济可行性 + +系统主要采用开源技术框架,部署成本与维护成本较低,适合中小型宠物医院信息化建设预算。系统上线后可减少重复劳动,降低人工运营成本,具备投入产出合理性。 + +#### 3.2.3 社会可行性 + +宠物医疗数字化符合行业发展趋势。系统建设有助于提升诊疗流程透明度和服务可达性,增强用户信任,对提升宠物医疗服务质量具有积极意义。 + +### 3.3 用例图 + +#### 3.3.1 顾客用例图 + +顾客角色的用例包括:注册登录、维护宠物档案、提交预约、取消预约、查询预约记录、查看订单、查询报告、查看公告、修改个人信息、修改密码。 + +主要用例说明: +- **注册登录**:新用户注册和已有用户登录系统的入口 +- **维护宠物档案**:新增、编辑、删除宠物信息,包括宠物名称、品种、性别、出生日期等 +- **提交预约**:选择宠物、预约日期、时段和医生(可选)提交预约请求 +- **取消预约**:在预约开始前取消已提交的预约 +- **查询预约记录**:查看个人历史预约记录及其状态 +- **查看订单**:查询就诊产生的订单信息及支付状态 +- **查询报告**:查看检验报告、检查报告等医疗报告 +- **查看公告**:浏览医院发布的公告和通知 +- **修改个人信息**:更新账户基本信息(如手机号、邮箱等) +- **修改密码**:更改登录密码 + +(图3.1 顾客用例图) + +#### 3.3.2 医生用例图 + +医生角色的用例包括:登录、查看预约、接诊确认、创建就诊记录、编辑病历、开具处方、查看处方、查询历史病历、查询历史处方、查看公告、修改个人信息、修改密码。 + +主要用例说明: +- **登录**:医生使用账号密码登录系统 +- **查看预约**:查看分配给自己的预约列表及预约详情 +- **接诊确认**:确认顾客到诊并开始接诊流程 +- **创建就诊记录**:为已到诊的预约创建就诊记录,记录症状、初步诊断 +- **编辑病历**:完善病历信息,录入主诉、检查结果、诊断结论、处理建议 +- **开具处方**:为就诊对象创建处方,添加药品明细及用法用量 +- **查看处方**:查看已开具的处方信息 +- **查询历史病历**:按宠物、顾客、时间等条件查询历史病历记录 +- **查询历史处方**:按条件查询历史处方记录 +- **查看公告**:浏览医院发布的公告和通知 +- **修改个人信息**:更新个人信息(如职称、联系方式等) +- **修改密码**:更改登录密码 + +(图3.2 医生用例图) + +#### 3.3.3 管理员用例图 + +管理员角色的用例包括:登录、用户管理(查看用户列表、新增用户、编辑用户、禁用用户、启用用户)、医生管理(新增医生、编辑医生、查看医生列表)、公告管理(发布公告、编辑公告、删除公告、查看公告列表)、药品管理(新增药品、编辑药品、查看药品列表、禁用药品、启用药品)、药品入库、药品出库、库存查询、统计报表查看(预约统计、订单统计、药品消耗统计)、修改个人信息、修改密码。 + +主要用例说明: +- **登录**:管理员使用账号密码登录系统 +- **用户管理**:管理系统中的用户账户,包括查看、新增、编辑、禁用、启用用户 +- **医生管理**:管理医生信息,包括新增医生、编辑医生信息、查看医生列表 +- **公告管理**:发布、编辑、删除医院公告,管理公告内容 +- **药品管理**:维护药品基础信息,包括药品名称、分类、规格、价格、预警阈值等 +- **药品入库**:记录药品入库操作,更新药品库存数量 +- **药品出库**:记录药品出库操作,扣减药品库存数量 +- **库存查询**:查看当前所有药品的库存情况 +- **统计报表查看**:查看预约统计、订单统计、药品消耗统计等经营数据 +- **修改个人信息**:更新管理员个人信息 +- **修改密码**:更改登录密码 + +(图3.3 管理员用例图) + +#### 3.3.4 用例关系(include关系) + +系统用例之间存在明确的包含关系(include),用`<>`表示。包含关系表示一个父用例在执行过程中必然包含子用例的行为。以下按业务模块列出系统的主要包含关系: + +**(1)顾客用例的include关系** + +预约管理模块: +- 预约管理 <> 提交预约 +- 预约管理 <> 取消预约 +- 预约管理 <> 查询预约记录 + +宠物档案模块: +- 宠物档案管理 <> 新增宠物 +- 宠物档案管理 <> 编辑宠物 +- 宠物档案管理 <> 删除宠物 + +个人信息模块: +- 个人中心 <> 修改个人信息 +- 个人中心 <> 修改密码 + +**(2)医生用例的include关系** + +接诊管理模块: +- 接诊管理 <> 查看预约 +- 接诊管理 <> 接诊确认 +- 接诊管理 <> 创建就诊记录 + +诊疗管理模块: +- 诊疗管理 <> 编辑病历 +- 诊疗管理 <> 开具处方 +- 诊疗管理 <> 查看处方 + +历史查询模块: +- 历史查询 <> 查询历史病历 +- 历史查询 <> 查询历史处方 + +个人信息模块: +- 个人中心 <> 修改个人信息 +- 个人中心 <> 修改密码 + +**(3)管理员用例的include关系** + +用户管理模块: +- 用户管理 <> 查看用户列表 +- 用户管理 <> 新增用户 +- 用户管理 <> 编辑用户 +- 用户管理 <> 禁用用户 +- 用户管理 <> 启用用户 + +公告管理模块: +- 公告管理 <> 发布公告 +- 公告管理 <> 编辑公告 +- 公告管理 <> 删除公告 + +药品与库存管理模块: +- 药品管理 <> 新增药品 +- 药品管理 <> 编辑药品 +- 药品管理 <> 禁用药品 +- 药品管理 <> 启用药品 +- 库存管理 <> 药品入库 +- 库存管理 <> 药品出库 +- 库存管理 <> 库存查询 + +统计分析模块: +- 统计报表 <> 预约统计 +- 统计报表 <> 订单统计 +- 统计报表 <> 药品消耗统计 + +个人信息模块: +- 个人中心 <> 修改个人信息 +- 个人中心 <> 修改密码 + +**(4)跨角色共享用例** + +以下用例被多个角色共享: + +- **登录**:作为系统认证入口,被顾客、医生、管理员三个角色共同使用 +- **修改个人信息**:被顾客、医生、管理员三个角色使用 +- **修改密码**:被顾客、医生、管理员三个角色使用 +- **查看公告**:被顾客、医生、管理员三个角色使用 + +这些共享用例体现了系统的基础通用能力,各角色通过统一入口完成认证与个人信息维护。 + +### 3.4 用例描述 + +#### 3.4.1 顾客预约门诊用例描述 + +| 项目 | 描述 | +|---|---| +| 用例名称 | 顾客预约门诊 | +| 执行者 | 顾客 | +| 前置条件 | 顾客已登录且已绑定至少一只宠物 | +| 后置条件 | 生成预约记录,状态为待处理或已确认 | +| 基本事件流 | 进入预约页面 → 选择宠物、日期、时段及医生(可选)→ 提交预约 → 系统保存记录并返回结果 | +| 异常事件流 | 必填信息缺失或时段不可用时,系统提示重新选择 | + +#### 3.4.2 医生开具处方用例描述 + +| 项目 | 描述 | +|---|---| +| 用例名称 | 医生开具处方 | +| 执行者 | 医生 | +| 前置条件 | 已存在有效就诊记录 | +| 后置条件 | 生成处方主记录与处方明细记录 | +| 基本事件流 | 进入处方模块 → 选择就诊对象 → 录入药品与用法用量 → 提交处方 | +| 异常事件流 | 药品信息不完整或状态不允许提交时,系统阻止提交并提示 | + +#### 3.4.3 管理员药品入库用例描述 + +| 项目 | 描述 | +|---|---| +| 用例名称 | 管理员药品入库 | +| 执行者 | 管理员 | +| 前置条件 | 管理员已登录且拥有库存管理权限 | +| 后置条件 | 入库记录写入并更新药品库存 | +| 基本事件流 | 进入入库管理 → 选择药品并填写数量、单价、供应信息 → 提交入库 | +| 异常事件流 | 输入数据非法时,系统提示修正后再提交 | +#### 3.4.4 顾客维护宠物档案用例描述 + +| 项目 | 描述 | +|---|---| +| 用例名称 | 顾客维护宠物档案 | +| 执行者 | 顾客 | +| 前置条件 | 顾客已登录 | +| 后置条件 | 宠物信息保存到数据库 | +| 基本事件流 | 进入宠物档案管理 → 点击新增/编辑 → 填写宠物信息(名称、品种、性别、出生日期、体重等)→ 提交保存 | +| 异常事件流 | 必填信息缺失或数据格式错误时,系统提示修正 | + +#### 3.4.5 顾客取消预约用例描述 + +| 项目 | 描述 | +|---|---| +| 用例名称 | 顾客取消预约 | +| 执行者 | 顾客 | +| 前置条件 | 顾客已登录且存在待确认或已确认的预约记录 | +| 后置条件 | 预约状态更新为已取消 | +| 基本事件流 | 进入预约管理 → 选择要取消的预约 → 点击取消按钮 → 确认取消 | +| 异常事件流 | 预约已接诊或已过取消时限时,系统阻止取消并提示 | + +#### 3.4.6 医生创建就诊记录用例描述 + +| 项目 | 描述 | +|---|---| +| 用例名称 | 医生创建就诊记录 | +| 执行者 | 医生 | +| 前置条件 | 顾客已到诊,存在有效预约 | +| 后置条件 | 生成就诊记录 | +| 基本事件流 | 查看待处理预约 → 确认顾客到诊 → 点击接诊 → 创建就诊记录 → 录入初步信息 | +| 异常事件流 | 预约不存在或状态不允许接诊时,系统提示 | + +#### 3.4.7 医生编辑病历用例描述 + +| 项目 | 描述 | +|---|---| +| 用例名称 | 医生编辑病历 | +| 执行者 | 医生 | +| 前置条件 | 已存在就诊记录 | +| 后置条件 | 病历信息更新并保存 | +| 基本事件流 | 进入就诊记录详情 → 点击编辑病历 → 录入主诉、检查结果、诊断结论、处理建议 → 保存 | +| 异常事件流 | 就诊记录不存在或已完成结算时,系统阻止编辑 | + +#### 3.4.8 管理员药品出库用例描述 + +| 项目 | 描述 | +|---|---| +| 用例名称 | 管理员药品出库 | +| 执行者 | 管理员 | +| 前置条件 | 管理员已登录且拥有库存管理权限,药品库存充足 | +| 后置条件 | 出库记录写入并扣减药品库存 | +| 基本事件流 | 进入出库管理 → 选择药品并填写数量、出库用途 → 提交出库 | +| 异常事件流 | 出库数量大于库存或输入数据非法时,系统提示 | + +#### 3.4.9 管理员发布公告用例描述 + +| 项目 | 描述 | +|---|---| +| 用例名称 | 管理员发布公告 | +| 执行者 | 管理员 | +| 前置条件 | 管理员已登录且拥有公告管理权限 | +| 后置条件 | 公告信息保存并可见 | +| 基本事件流 | 进入公告管理 → 点击新增 → 填写公告标题、内容、发布时间 → 提交发布 | +| 异常事件流 | 必填信息缺失时,系统提示修正 | + +#### 3.4.10 顾客查看订单用例描述 + +| 项目 | 描述 | +|---|---| +| 用例名称 | 顾客查看订单 | +| 执行者 | 顾客 | +| 前置条件 | 顾客已登录且有历史就诊记录 | +| 后置条件 | 显示订单列表或订单详情 | +| 基本事件流 | 进入订单查询 → 查看订单列表 → 选择订单查看详情 | +| 异常事件流 | 无订单记录时显示提示信息 | + +#### 3.4.11 登录用例描述 + +| 项目 | 描述 | +|---|---| +| 用例名称 | 登录 | +| 执行者 | 顾客/医生/管理员 | +| 前置条件 | 用户已注册 | +| 后置条件 | 用户身份验证通过,生成访问令牌 | +| 基本事件流 | 进入登录页面 → 输入账号密码 → 点击登录 → 验证身份 → 跳转至角色首页 | +| 异常事件流 | 账号不存在、密码错误或账户被禁用时,系统提示错误信息 | + +#### 3.4.12 管理员用户管理用例描述 + +| 项目 | 描述 | +|---|---| +| 用例名称 | 管理员用户管理 | +| 执行者 | 管理员 | +| 前置条件 | 管理员已登录且拥有用户管理权限 | +| 后置条件 | 用户账户信息新增、更新或状态变更成功 | +| 基本事件流 | 进入用户管理页面 → 查看用户列表(支持按角色、状态筛选)→ 选择新增/编辑/禁用/启用操作 → 填写或修改用户信息 → 提交保存 | +| 异常事件流 | 用户名已存在、必填信息缺失或数据格式错误时,系统提示修正;禁用当前登录账户时,系统阻止操作并提示 | + +#### 3.4.13 管理员药品管理用例描述 + +| 项目 | 描述 | +|---|---| +| 用例名称 | 管理员药品管理 | +| 执行者 | 管理员 | +| 前置条件 | 管理员已登录且拥有药品管理权限 | +| 后置条件 | 药品基础信息新增、更新或状态变更成功 | +| 基本事件流 | 进入药品管理页面 → 查看药品列表(支持按分类、状态筛选)→ 选择新增/编辑/禁用/启用操作 → 填写药品名称、分类、规格、单价、预警阈值等信息 → 提交保存 | +| 异常事件流 | 药品名称重复、必填信息缺失或数值非法时,系统提示修正;禁用已关联未完成处方的药品时,系统给出警告提示 | + +#### 3.4.14 管理员库存查询用例描述 + +| 项目 | 描述 | +|---|---| +| 用例名称 | 管理员库存查询 | +| 执行者 | 管理员 | +| 前置条件 | 管理员已登录 | +| 后置条件 | 显示药品库存列表及预警信息 | +| 基本事件流 | 进入库存查询页面 → 查看所有药品当前库存数量 → 支持按药品名称、分类筛选 → 库存低于预警阈值的药品高亮提示 | +| 异常事件流 | 无药品数据时显示空状态提示信息 | + +#### 3.4.15 管理员统计报表查看用例描述 + +| 项目 | 描述 | +|---|---| +| 用例名称 | 管理员统计报表查看 | +| 执行者 | 管理员 | +| 前置条件 | 管理员已登录且拥有统计查看权限 | +| 后置条件 | 显示统计数据与可视化图表 | +| 基本事件流 | 进入统计报表页面 → 选择统计维度(预约统计、订单统计、药品消耗统计)→ 选择时间范围 → 系统查询并展示统计数据与图表 | +| 异常事件流 | 所选时间范围内无数据时,显示空数据提示;数据加载超时时,系统提示稍后重试 | + +#### 3.4.16 管理员留言管理用例描述 + +| 项目 | 描述 | +|---|---| +| 用例名称 | 管理员留言管理 | +| 执行者 | 管理员 | +| 前置条件 | 管理员已登录且拥有留言管理权限 | +| 后置条件 | 留言回复内容保存并更新处理状态 | +| 基本事件流 | 进入留言管理页面 → 查看留言列表(支持按处理状态筛选)→ 选择待处理留言 → 填写回复内容 → 提交回复,留言状态更新为已处理 | +| 异常事件流 | 回复内容为空时,系统提示填写回复内容后再提交 | + +#### 3.4.17 修改个人信息用例描述 + +| 项目 | 描述 | +|---|---| +| 用例名称 | 修改个人信息 | +| 执行者 | 顾客/医生/管理员 | +| 前置条件 | 用户已登录 | +| 后置条件 | 个人信息更新成功 | +| 基本事件流 | 进入个人中心 → 查看当前个人信息 → 点击编辑 → 修改姓名、联系方式等信息 → 提交保存 | +| 异常事件流 | 手机号格式错误或必填信息缺失时,系统提示修正 | + +#### 3.4.18 修改密码用例描述 + +| 项目 | 描述 | +|---|---| +| 用例名称 | 修改密码 | +| 执行者 | 顾客/医生/管理员 | +| 前置条件 | 用户已登录 | +| 后置条件 | 密码更新成功,需重新登录 | +| 基本事件流 | 进入个人中心 → 点击修改密码 → 输入原密码与新密码(含确认)→ 提交修改 → 系统验证原密码正确后更新密码 | +| 异常事件流 | 原密码错误、新密码不符合强度要求或两次输入不一致时,系统提示修正 | +### 3.5 系统性能分析 + +1. 交互性能:前端分页查询与后端分页接口配合,降低一次性数据加载压力; +2. 数据性能:通过明确实体关系、主外键关联与状态字段管理,保障常用查询稳定性; +3. 安全性能:基于 JWT 与角色权限约束降低越权访问风险; +4. 运行稳定性:关键模块采用统一接口与异常处理思路,降低业务中断概率。 + +### 3.6 业务风险与约束分析 + +为提升系统实施质量,需在分析阶段明确项目风险与边界约束。 + +(1)业务风险: + +1. 预约高峰时段可能出现集中提交,若缺少冲突检测会降低预约可靠性; +2. 病历与处方属于高敏感业务数据,若权限边界设置不清晰将带来数据泄露风险; +3. 库存数据与实际消耗存在时间差时,可能引发“账实不一致”问题; +4. 支付闭环未完整接入前,订单状态与真实支付状态可能存在管理间隙。 + +(2)技术风险: + +1. 前后端字段定义不一致将导致接口联调失败; +2. 状态字段语义不统一会增加流程判断复杂度; +3. 历史数据持续增长后,分页和筛选查询需要进一步优化索引策略。 + +(3)管理约束: + +1. 毕业设计周期有限,需要优先保证核心主链路闭环; +2. 测试资源有限,应优先覆盖高风险模块与高频场景; +3. 论文写作需与系统版本保持一致,避免“实现与描述脱节”。 + +### 3.7 本章小结 + +本章完成了系统需求、可行性、用例与性能分析,并从业务和技术两个维度识别了主要风险点。通过将需求从“功能清单”细化为“可执行约束”,为后续系统设计与实现提供了清晰输入,确保第4章设计内容能够直接映射到第5章实现与第6章测试。 + +## 第4章 爱维宠物医院管理系统设计 + +### 4.1 系统功能设计 + +系统总体由三类角色构成:顾客、医生、管理员。功能结构围绕“业务执行端(顾客、医生)+运营管理端(管理员)”组织。 + +#### 4.1.1 顾客功能结构 + +顾客端主要包括:首页与公告浏览、宠物档案管理、预约管理、订单与报告查询等功能。 + +(图4.1 顾客功能结构图) + +#### 4.1.2 医生功能结构 + +医生端主要包括:预约接诊、就诊记录、病历维护、处方管理等功能。 + +(图4.2 医生功能结构图) + +#### 4.1.3 管理员功能结构 + +管理员端主要包括:用户管理、公告管理、药品管理、库存流水管理、统计分析等功能。 + +(图4.3 管理员功能结构图) + +### 4.2 类图设计 + +系统核心实体类包含:用户类、医生类、宠物类、预约类、就诊类、病历类、处方类、处方明细类、药品类、订单类、入库类、出库类、公告类、报告类等。 + +主要关系如下: + +1. 用户与宠物为一对多关系; +2. 顾客与预约为一对多关系; +3. 预约与就诊记录存在关联关系; +4. 就诊与病历、处方均存在业务关联; +5. 处方与处方明细为一对多关系; +6. 药品与出入库记录为一对多关系。 + +(图4.4 系统类图) + +### 4.3 序列图设计 + +#### 4.3.1 顾客预约门诊序列图 + +顾客发起预约请求后,系统完成参数校验、业务检查与记录保存,再将结果返回前端展示。 + +(图4.5 顾客预约序列图) + +#### 4.3.2 管理员账号管理序列图 + +管理员在用户管理模块发起新增/更新/禁用操作,系统校验权限并更新目标用户状态。 + +(图4.6 管理员账号管理序列图) + +### 4.4 活动图设计 + +#### 4.4.1 医生接诊活动图 + +流程为:登录系统 → 查看预约 → 确认到诊 → 创建就诊记录 → 完成病历录入 → 处方处理 → 结束接诊。 + +(图4.7 医生就诊活动图) + +#### 4.4.2 顾客预约活动图 + +流程为:登录系统 → 选择宠物与时段 → 提交预约信息 → 系统校验并保存 → 返回预约结果。 + +(图4.8 顾客预约活动图) + +### 4.5 数据库设计 + +#### 4.5.1 概念设计 + +根据业务分析,系统包含用户、医生、宠物、预约、就诊、病历、处方、药品、订单、公告、库存流水、报告等核心实体,覆盖诊疗与运营管理全链路。 + +(图4.9 实体属性图) + +(图4.10 系统 E-R 图) + +#### 4.5.2 逻辑设计 + +关系模式示例如下(主键以 PK 标识,外键以 FK 标识): + +1. 用户表:`user`(id PK, username, phone, email, password, role, status, avatar, create_time, update_time, deleted) +2. 医生表:`doctor`(id PK, name, department, title, phone, email, status, create_time, update_time, deleted) +3. 宠物表:`pet`(id PK, owner_id FK, name, species, breed, gender, birthday, weight, remark, create_time, update_time, deleted) +4. 预约表:`appointment`(id PK, customer_id FK, pet_id FK, doctor_id FK, department, appointment_date, time_slot, status, remark, create_time, update_time, deleted) +5. 就诊表:`visit`(id PK, appointment_id FK, customer_id FK, pet_id FK, doctor_id FK, symptoms, diagnosis, treatment_plan, status, payment_status, create_time, update_time, deleted) +6. 病历表:`medical_record`(id PK, visit_id FK, doctor_id FK, content, record_type, create_time, update_time, deleted) +7. 处方表:`prescription`(id PK, visit_id FK, doctor_id FK, customer_id FK, total_amount, status, create_time, update_time, deleted) +8. 处方明细表:`prescription_item`(id PK, prescription_id FK, drug_id FK, quantity, dosage, frequency, duration, create_time, update_time, deleted) +9. 药品表:`drug`(id PK, name, category, specification, unit_price, stock_quantity, alert_threshold, status, create_time, update_time, deleted) +10. 订单表:`order_info`(id PK, visit_id FK, customer_id FK, amount, status, payment_method, payment_time, create_time, update_time, deleted) +11. 入库表:`stock_in`(id PK, drug_id FK, quantity, unit_price, supplier, operator_id FK, create_time, update_time, deleted) +12. 出库表:`stock_out`(id PK, drug_id FK, quantity, purpose, operator_id FK, create_time, update_time, deleted) + +#### 4.5.3 物理设计 + +以下选取部分核心物理表结构说明: + +**表4.1 用户表(user)** + +| 字段名称 | 字段含义 | 类型 | 约束 | +|---|---|---|---| +| id | 用户主键 | BIGINT | PK, 自增 | +| username | 用户名 | VARCHAR(50) | 唯一、非空 | +| password | 密码密文 | VARCHAR(255) | 非空 | +| role | 角色 | VARCHAR(20) | 非空 | +| status | 状态 | INT | 默认有效 | + +**表4.2 宠物表(pet)** + +| 字段名称 | 字段含义 | 类型 | 约束 | +|---|---|---|---| +| id | 宠物主键 | BIGINT | PK, 自增 | +| owner_id | 主人用户ID | BIGINT | FK, 非空 | +| name | 宠物名称 | VARCHAR(50) | 非空 | +| species | 物种 | VARCHAR(50) | | +| birthday | 出生日期 | DATE | | + +**表4.3 预约表(appointment)** + +| 字段名称 | 字段含义 | 类型 | 约束 | +|---|---|---|---| +| id | 预约主键 | BIGINT | PK, 自增 | +| customer_id | 顾客ID | BIGINT | FK, 非空 | +| pet_id | 宠物ID | BIGINT | FK, 非空 | +| appointment_date | 预约日期 | DATE | 非空 | +| time_slot | 时段 | VARCHAR(20) | 非空 | + +**表4.4 就诊表(visit)** + +| 字段名称 | 字段含义 | 类型 | 约束 | +|---|---|---|---| +| id | 就诊主键 | BIGINT | PK, 自增 | +| appointment_id | 预约ID | BIGINT | FK | +| doctor_id | 医生ID | BIGINT | FK, 非空 | +| diagnosis | 诊断结果 | TEXT | | +| status | 就诊状态 | VARCHAR(20) | 业务状态 | + +**表4.5 处方表(prescription)** + +| 字段名称 | 字段含义 | 类型 | 约束 | +|---|---|---|---| +| id | 处方主键 | BIGINT | PK, 自增 | +| visit_id | 就诊ID | BIGINT | FK | +| doctor_id | 医生ID | BIGINT | FK | +| total_amount | 处方金额 | DECIMAL(10,2) | | +| status | 处方状态 | VARCHAR(20) | | + +**表4.6 药品表(drug)** + +| 字段名称 | 字段含义 | 类型 | 约束 | +|---|---|---|---| +| id | 药品主键 | BIGINT | PK, 自增 | +| name | 药品名称 | VARCHAR(100) | 非空 | +| category | 药品分类 | VARCHAR(50) | | +| stock_quantity | 当前库存 | INT | 默认0 | +| alert_threshold | 预警阈值 | INT | | + +**表4.7 订单表(order_info)** + +| 字段名称 | 字段含义 | 类型 | 约束 | +|---|---|---|---| +| id | 订单主键 | BIGINT | PK, 自增 | +| customer_id | 顾客ID | BIGINT | FK, 非空 | +| amount | 金额 | DECIMAL(10,2) | | +| status | 订单状态 | VARCHAR(20) | 非空 | +| payment_method | 支付方式 | VARCHAR(20) | | + +**表4.8 库存入库表(stock_in)** + +| 字段名称 | 字段含义 | 类型 | 约束 | +|---|---|---|---| +| id | 入库主键 | BIGINT | PK, 自增 | +| drug_id | 药品ID | BIGINT | FK, 非空 | +| quantity | 入库数量 | INT | 非空 | +| unit_price | 入库单价 | DECIMAL(10,2) | | +| operator_id | 操作人ID | BIGINT | FK | + +### 4.6 图形界面设计 + +系统界面按角色分层设计: + +1. 顾客端采用简化入口,突出预约、宠物、订单、报告等高频功能; +2. 医生端强调业务连续性,突出接诊、病历与处方操作路径; +3. 管理端突出数据与配置能力,侧重用户、库存与统计管理。 + +示例界面包括预约挂号、病历录入、药品库存管理等场景。 + +(图4.11 预约挂号界面设计图) + +(图4.12 药品库存管理界面设计图) + +(图4.13 病历书写界面设计图) + +### 4.7 系统部署与运行设计 + +系统部署采用“前后端分离 + 统一数据库”的基础形态。后端服务作为 API 提供方,前端通过浏览器访问并调用接口,数据库负责统一存储业务数据。部署过程重点关注以下内容: + +1. 环境一致性:开发、测试与演示环境应尽量保持配置一致,减少“本地可用、部署异常”问题; +2. 配置隔离:数据库连接、鉴权密钥、文件路径等配置项应按环境分离,避免硬编码带来的维护风险; +3. 日志可追踪:关键业务操作与异常信息需可检索,便于问题定位与回归分析; +4. 启停可控:系统启动顺序遵循“数据库优先、后端次之、前端最后”,保证联调过程稳定。 + +此外,考虑到毕业设计场景通常以演示环境为主,系统优先保障“核心流程稳定可复现”,即顾客预约、医生接诊、管理员库存管理三条主流程在标准演示数据下可连续运行。 + +### 4.8 安全与数据一致性设计 + +系统在设计阶段引入“认证、授权、校验、追踪”四层控制思想: + +1. 认证层:通过令牌机制识别请求身份,防止匿名访问受限资源; +2. 授权层:依据角色限制页面与接口访问边界,避免越权操作; +3. 校验层:对关键输入进行合法性检查,减少异常数据进入业务流程; +4. 追踪层:通过时间字段、状态字段和逻辑删除策略保留数据演化轨迹。 + +在数据一致性方面,系统通过实体关联关系约束业务对象之间的上下文,尽量避免孤立记录。例如预约、就诊、病历、处方在语义上形成有序链路,能够支持后续追踪与统计。对于库存数据,系统采用“主数据 + 流水记录”方式保留变更依据,便于后续核对与审计。 + +### 4.9 本章小结 + +本章从功能结构、对象关系、交互流程、数据库结构、界面设计、部署方案及安全一致性策略等方面完成了系统设计。设计结果强调“结构清晰、流程可追溯、实现可落地”,为第5章功能实现提供了明确蓝图。 + +## 第5章 爱维宠物医院管理系统实现 + +本章仅描述主要功能实现结果,不展示开发代码。 + +### 5.1 用户功能模块实现 + +#### 5.1.1 顾客首页与个人中心 + +顾客进入系统后可在首页查看公告与功能入口,并在个人中心维护基础资料。该模块用于统一承载顾客端高频操作入口,提升功能可达性与使用连续性。 + +#### 5.1.2 宠物档案管理 + +顾客可新增、查看、编辑和删除宠物档案,支持维护宠物基本信息及历史关联信息。该模块为预约与就诊流程提供基础数据支撑。 + +#### 5.1.3 门诊预约与订单查询 + +顾客可提交预约请求并查看历史预约记录,同时可查询订单状态与报告信息,实现从预约到结果查询的基础闭环。 + +### 5.2 医生功能模块实现 + +#### 5.2.1 门诊接诊与就诊记录 + +医生可查看预约数据并完成接诊处理,创建就诊记录以承载后续病历和处方业务。 + +#### 5.2.2 病历管理 + +医生可对就诊对象进行病历录入与维护,支持按就诊维度归档管理,提高历史复诊信息可追溯性。 + +#### 5.2.3 处方管理 + +医生可创建处方并维护处方明细,实现用药信息结构化管理,为订单与库存联动奠定基础。 + +### 5.3 管理员功能模块实现 + +#### 5.3.1 账户与公告管理 + +管理员可对用户进行统一管理,并通过公告模块发布运营通知与服务信息。 + +#### 5.3.2 药品与库存管理 + +管理员可维护药品档案,并通过入库、出库模块记录库存变更,实现基础库存可视化管理。 + +#### 5.3.3 统计分析 + +系统提供基础统计页面,用于展示关键经营数据,为管理决策提供直观参考。 + +### 5.4 关键业务流程实现结果 + +#### 5.4.1 预约到接诊流程实现结果 + +系统已实现顾客提交预约、医生查看预约并处理接诊的基础流程。顾客端可完成预约信息录入和历史查询,医生端可在工作页面查看待处理信息并进入接诊环节。该流程实现的价值在于将原先分散的人工登记环节转化为可检索、可跟踪、可回溯的数据流程,减少信息遗漏。 + +#### 5.4.2 接诊到病历处方流程实现结果 + +在医生侧,系统支持围绕就诊对象建立病历记录并创建处方信息,病历和处方形成结构化关联。相较于纸质记录方式,电子化记录在检索效率、信息完整性与复诊复用方面具有明显优势。通过角色页面分层,医生可聚焦诊疗核心操作,降低非必要管理项干扰。 + +#### 5.4.3 库存管理流程实现结果 + +管理员侧已实现药品基础信息维护与出入库记录管理。系统可记录库存变更来源,支撑基础库存可视化。该流程在日常管理中的意义体现在:一是降低“库存不明”导致的业务中断概率,二是为后续构建库存预警、采购建议和用药统计提供数据基础。 + +#### 5.4.4 信息发布与运营支撑实现结果 + +系统支持公告发布与基础统计展示。公告能力提升了医院与顾客之间的信息触达效率,统计能力为管理者提供了运营观察窗口。虽然当前统计维度仍以基础指标为主,但已具备继续扩展到多维分析的结构条件。 + +### 5.5 模块实现成效评估 + +从系统落地效果看,核心模块实现具备以下特点: + +1. 业务主链路可运行:预约、接诊、病历、处方、库存、统计等核心模块已打通; +2. 角色边界较清晰:顾客、医生、管理员各自聚焦对应职责范围; +3. 数据组织较规范:关键对象具备状态与时间维度,便于追踪; +4. 扩展方向明确:在线支付、提醒通知、导出能力等可在现有架构上增量演进。 + +### 5.6 本章小结 + +本章围绕系统实现结果进行了模块化说明,重点强调“做成了什么、支撑了什么业务、还差什么能力”。在不展示开发代码的前提下,论文仍能清晰体现系统功能落地情况与工程价值,为测试章节提供可验证对象。 + +## 第6章 爱维宠物医院管理系统测试 + +### 6.1 系统测试概述 + +#### 6.1.1 测试背景 + +系统完成主要功能开发后,需要通过测试验证业务流程完整性、角色权限有效性与核心模块稳定性。 + +#### 6.1.2 测试意义 + +测试可以及时发现流程断点、权限漏洞和交互异常,确保系统在真实业务场景中可用。 + +#### 6.1.3 测试环境 + +测试环境由后端服务、前端页面与 MySQL 数据库组成,采用角色账户分别进行业务验证。 + +### 6.2 系统测试用例设计 + +#### 6.2.1 用户认证功能测试 + +| 测试项 | 输入 | 预期结果 | +|---|---|---| +| 正常登录 | 正确账号与密码 | 登录成功并进入角色首页 | +| 错误密码 | 正确账号+错误密码 | 登录失败并提示错误信息 | +| 未授权访问 | 未登录访问受限页面 | 跳转至登录页 | + +#### 6.2.2 预约功能测试 + +| 测试项 | 操作 | 预期结果 | +|---|---|---| +| 新增预约 | 顾客提交合法预约信息 | 预约记录创建成功 | +| 预约列表查询 | 顾客查看个人预约列表 | 返回该顾客关联记录 | +| 状态更新 | 医生/管理员更新预约状态 | 状态变更成功 | + +#### 6.2.3 病历与处方功能测试 + +| 测试项 | 操作 | 预期结果 | +|---|---|---| +| 创建病历 | 医生提交病历信息 | 病历记录创建成功 | +| 创建处方 | 医生提交处方与明细 | 处方与明细均成功保存 | +| 历史查询 | 按条件查询病历/处方 | 可返回匹配记录 | + +#### 6.2.4 安全性测试 + +1. 角色权限测试:验证顾客、医生、管理员访问边界; +2. 认证有效性测试:验证无令牌、过期令牌访问控制效果; +3. 参数合法性测试:验证关键输入项的约束与错误提示。 + +#### 6.2.5 兼容性测试 + +系统在主流桌面浏览器下进行页面访问与核心功能操作验证,确保常见使用环境下的可用性。 + +### 6.3 测试结果分析 + +经测试,系统核心模块可稳定运行,认证与权限控制整体有效,顾客预约、医生接诊、病历处方、管理员库存管理等主路径可完成。当前系统在以下方面仍有提升空间: + +1. 在线支付能力尚未形成完整闭环; +2. 预约提醒、库存主动预警等自动化能力仍需增强; +3. 个别扩展模块的前端覆盖仍有完善空间。 + +### 6.4 缺陷跟踪与回归测试 + +为保证测试结论可靠,系统在功能测试后进行了缺陷分类与回归验证。缺陷主要分为三类: + +1. 交互提示类:如状态提示文案不明确、失败反馈不够具体; +2. 流程一致性类:如部分状态流转条件不够严格导致边界场景处理不统一; +3. 权限边界类:如个别页面在前端路由层和后端接口层的限制策略需进一步对齐。 + +回归测试以“高频场景优先、关键流程优先”为原则,重点覆盖登录鉴权、预约提交、病历录入、处方创建、库存操作等模块。经过回归后,核心流程可保持稳定运行,未出现阻断级问题。 + +### 6.5 测试数据与结果汇总说明 + +从测试覆盖角度看,系统已覆盖认证、预约、病历、处方、库存、权限和兼容性等核心方向,能够满足毕业设计验收阶段的基本要求。测试结果表明: + +1. 功能完整性方面:核心业务功能可用,主路径闭环可执行; +2. 稳定性方面:常见操作下系统运行稳定,未出现持续性错误; +3. 安全性方面:角色访问边界总体有效,认证策略可生效; +4. 可用性方面:页面交互路径清晰,具备基础业务操作友好性。 + +需要进一步强化的方面包括支付闭环、消息提醒和高级统计报表能力。上述问题不影响系统主体功能验收,但会影响长期运营深度,建议作为后续迭代重点。 + +### 6.6 本章小结 + +本章通过测试环境说明、用例设计、结果分析、缺陷回归与汇总结论,验证了系统“可运行、可使用、可改进”的总体状态。测试结论与第5章实现结果一致,能够支撑论文结论部分的客观论证。 + +## 第7章 结论 + +本文围绕宠物医院信息化管理需求,完成了爱维宠物医院管理系统的分析、设计、实现与测试工作。系统在多角色协同、核心业务流程打通、基础安全控制和数据结构化管理方面达到了预期目标,能够支撑中小型宠物医院的日常运营。 + +同时,本文也明确了系统后续优化方向:完善支付与提醒闭环、增强运营分析深度、进一步提升业务自动化程度。未来可在既有架构基础上逐步引入智能排班、风险预警与数据驱动决策能力,持续提升系统业务价值与行业适配能力。 + +### 7.1 主要研究成果 + +本文在毕业设计周期内完成了从需求分析到系统测试的完整工程闭环,主要成果可概括为: + +1. 构建了面向三角色的宠物医院管理系统原型,形成较完整的业务能力框架; +2. 打通了预约、接诊、病历、处方、库存与统计等核心流程,具备实际演示与应用价值; +3. 建立了较规范的数据模型与接口约束机制,为后续扩展奠定基础; +4. 形成了可复用的分析、设计、实现和测试文档体系,为同类项目提供参考。 + +### 7.2 不足与改进空间 + +尽管系统已实现核心目标,但仍存在若干不足: + +1. 支付能力仍以基础状态管理为主,尚未形成完整第三方支付闭环; +2. 预约提醒、库存预警等主动通知机制仍需增强; +3. 统计分析维度偏基础,尚未形成更精细化的运营洞察; +4. 部分扩展功能的页面覆盖与交互细节仍有优化空间。 + +上述不足主要受毕业设计周期、测试资源和外部接口条件限制。后续可按“先闭环、后智能、再优化体验”的路线逐步推进。 + +### 7.3 后续工作展望 + +面向实际应用场景,后续工作可从以下方向深化: + +1. 支付闭环建设:对接主流支付渠道,完善订单状态回调与异常处理; +2. 提醒系统建设:引入预约提醒、复诊提醒、库存阈值提醒,提高运营主动性; +3. 统计分析升级:补充多维报表、趋势分析和可视化导出能力; +4. 智能化拓展:探索基于历史数据的排班优化、用药趋势分析与风险预警; +5. 工程化升级:完善自动化测试与持续集成流程,提高版本交付稳定性。 + +综上,爱维宠物医院管理系统已具备从“可用”走向“好用、易扩展”的基础条件。随着后续迭代推进,系统有望在中小型宠物医疗机构的信息化建设中发挥更大价值。 + +## 参考文献 + +[1] 王慧. 一个宠物医院管理系统的设计与实现[J]. 电脑知识与技术, 2023(10):67-70. +[2] 田斌. 基于SSM框架的宠物医院系统设计[J]. 无线互联科技, 2023(14):69-71. +[3] K. Nandhini. Veterinary Hospital Management System Using AI Integrated Advisory[J]. International Journal of Science, Engineering and Technology, 2025, 13(2). +[4] 颜惠. 基于Web的宠物店信息管理系统设计[J]. 软件, 2023(2):147-149. +[5] 艾钰承, 朱海风, 刘舟. 基于SpringBoot的“喵站”宠物服务平台的设计与实现[J]. 科技资讯, 2023(22):22-25. +[6] 庞嵩昊, 李盈, 赵艺, 等. 基于Vue和SpringBoot前后端分离的宠物服务系统设计与实现[J]. 电脑知识与技术, 2023(21):42-45. +[7] 丁禹钧, 朱一龙, 王雪静. 基于SpringBoot和Vue的管理系统设计[J]. 电脑编程技巧与维护, 2025(9):110-112. +[8] 柳伟卫. Vue.js+Spring Boot全栈开发实战[M]. 北京: 人民邮电出版社, 2023. + +## 致谢 + +在本次毕业设计与论文撰写过程中,感谢指导教师在选题论证、系统设计、论文结构与表达规范等方面提供的持续指导。感谢学院和专业课程体系为本课题提供的理论基础与实践环境。感谢同学与朋友在测试反馈与资料收集过程中的帮助。最后,感谢家人对本人学习与毕业设计工作的支持与鼓励。 + +## 附录 + +### 附录A 缩略语说明 + +| 缩略语 | 英文全称 | 中文说明 | +|---|---|---| +| RBAC | Role-Based Access Control | 基于角色的访问控制 | +| JWT | JSON Web Token | 用于无状态认证的令牌机制 | +| CRUD | Create, Read, Update, Delete | 增删改查基础数据操作 | +| API | Application Programming Interface | 应用程序接口 | + +### 附录B 论文图表清单索引说明 + +本文第3章与第4章涉及用例图、功能结构图、类图、序列图、活动图、E-R图及界面设计图,图号已按章节顺序编排。第5章与第6章运行截图及测试截图可在系统最终验收阶段补充为正式附图。 diff --git a/example/萌贝母婴商城毕业论文初稿-2026版.md b/example/萌贝母婴商城毕业论文初稿-2026版.md new file mode 100644 index 0000000..c61abe6 --- /dev/null +++ b/example/萌贝母婴商城毕业论文初稿-2026版.md @@ -0,0 +1,759 @@ +# 萌贝母婴商城系统的设计与实现(论文初稿) + +## 中文摘要 + +随着我国生育政策持续优化、年轻家庭消费升级以及移动互联网基础设施的不断完善,母婴电商正在从“流量驱动”向“服务驱动”和“信任驱动”转变。传统母婴用品销售方式在商品信息透明度、跨地区供给效率、售后协同与数据化经营方面存在明显短板,难以满足用户在安全性、时效性、体验一致性等方面的综合需求。针对上述问题,本文围绕“萌贝母婴商城系统”开展了从需求分析、架构设计、数据库建模、功能实现到测试验证的系统化研究与实践。 + +本系统采用前后端分离架构,后端以 Spring Boot 3、Spring Data JPA、MySQL 为核心技术,前端基于 Vue3、Vite 与 Arco Design 构建多角色交互界面,形成顾客端、商家端、管理员端三端协同的业务平台。在功能层面,系统实现了用户注册登录、商品浏览与检索、购物车管理、下单与订单管理、收藏与评价、商家商品管理、发货与退款处理、平台审核与用户管理、轮播图配置、库存记录与物流查看等核心能力;在工程层面,系统通过统一接口响应模型、基于 Token 的鉴权机制、角色访问约束和异常处理机制保障了业务一致性与运行稳定性。 + +通过对关键业务链路进行功能测试与流程验证,结果表明该系统能够较好支持中小规模母婴电商场景下的日常运营,提升顾客购买效率、商家运营效率与平台监管效率。本文研究成果可为同类垂直电商系统建设提供参考,并为后续引入推荐算法、支付风控和精细化运营分析提供可扩展基础。 + +**关键词:** 母婴电商;Spring Boot;Vue3;前后端分离;角色权限控制 + +## Abstract + +With the continuous optimization of childbirth policies in China, the upgrading of family consumption, and the rapid development of mobile Internet infrastructure, maternal and infant e-commerce is shifting from traffic-driven growth to service-driven and trust-driven development. Traditional sales models for maternal and infant products still suffer from low transparency of product information, limited cross-regional supply efficiency, weak after-sales collaboration, and insufficient data-driven operations, which can hardly satisfy users' comprehensive requirements on safety, timeliness, and consistent service experience. To address these issues, this thesis conducts a systematic study and implementation of the “Mengbei Maternal Mall System”, covering requirement analysis, architecture design, database modeling, functional implementation, and testing verification. + +The system adopts a frontend-backend separated architecture. The backend is built on Spring Boot 3, Spring Data JPA, and MySQL, while the frontend is developed with Vue3, Vite, and Arco Design. It supports collaborative operations across three roles: customer, merchant, and administrator. Functionally, the system implements user registration and login, product browsing and search, shopping cart management, order placement and order lifecycle management, favorites and reviews, merchant product operations, shipment and refund handling, platform audit and user management, banner configuration, inventory records, and logistics tracking. At the engineering level, the system ensures consistency and stability through a unified API response model, token-based authentication mechanism, role-based access control, and centralized exception handling. + +Functional testing and process verification show that the system can effectively support daily operations in small and medium-sized maternal e-commerce scenarios, improving shopping efficiency for customers, operational efficiency for merchants, and governance efficiency for platform administrators. The outcomes of this study can provide practical references for similar vertical e-commerce systems and establish an extensible foundation for future integration of recommendation algorithms, payment risk control, and refined operational analytics. + +**Keywords:** Maternal e-commerce; Spring Boot; Vue3; Frontend-backend separation; Role-based access control + +## 目录 + +- 第1章 绪论 + - 1.1 课题来源及意义 + - 1.2 国内外研究现状 + - 1.3 当前存在的问题 + - 1.4 研究目标与内容 + - 1.5 论文结构安排 +- 第2章 相关技术与开发框架 + - 2.1 后端技术体系 + - 2.2 前端技术体系 + - 2.3 鉴权与访问控制机制 + - 2.4 技术选型对比与决策依据 +- 第3章 萌贝母婴商城系统分析 + - 3.1 需求分析 + - 3.2 可行性分析 + - 3.3 角色用例分析 + - 3.4 关键用例描述 + - 3.5 非功能需求分析 +- 第4章 萌贝母婴商城系统设计 + - 4.1 系统总体架构设计 + - 4.2 功能结构设计 + - 4.3 数据库设计 + - 4.4 接口与权限设计 + - 4.5 关键流程设计 + - 4.6 界面设计 +- 第5章 萌贝母婴商城系统实现 + - 5.1 用户认证与基础模块实现 + - 5.2 顾客端功能实现 + - 5.3 商家端功能实现 + - 5.4 管理员端功能实现 + - 5.5 关键业务链路实现结果 +- 第6章 萌贝母婴商城系统测试 + - 6.1 测试环境与测试策略 + - 6.2 功能测试 + - 6.3 安全性与兼容性测试 + - 6.4 测试结果分析 +- 第7章 结论与展望 +- 参考文献 +- 致谢 +- 附录 + +--- + +## 第1章 绪论 + +### 1.1 课题来源及意义 + +近年来,母婴消费行业呈现出需求精细化、渠道线上化和服务链路一体化的趋势。用户在选择母婴用品时,不再仅关注价格和促销,更重视产品质量、品牌信誉、成分安全、物流时效以及售后保障。与此同时,大量中小型商家虽具备优质供应能力,但在数字化运营、跨区域触达和平台治理方面能力不足,导致“好产品触达难、好服务沉淀难、好口碑传播难”的结构性问题长期存在。 + +本课题来源于母婴垂直电商业务实践需求,目标是设计并实现一套可落地、可扩展、可维护的三端协同商城系统。该系统以顾客、商家、管理员三类角色为中心,围绕“商品展示—交易下单—订单履约—售后处理—平台治理”的主业务链路展开,既要解决顾客侧购物与服务体验问题,也要兼顾商家侧运营效率与平台侧风控监管需求。 + +从现实意义看,本研究有助于推动中小型母婴业务主体完成数字化转型,降低运营成本,提高交易透明度与服务响应能力。从技术意义看,本研究可验证前后端分离架构在中等复杂业务场景中的适配性,形成可复用的系统建设方法论。从教学与实践意义看,本文在分析、设计、实现和测试四个环节形成闭环,有助于提升软件工程项目化实践能力。 + +### 1.2 国内外研究现状 + +国外电商平台在用户行为分析、供应链协同、支付风控、推荐系统等方面起步较早,系统形态相对成熟。Amazon、Walmart、Target 等平台在订单履约、库存联动和个性化推荐方面形成了完整方法体系;在母婴垂直领域,平台通常通过类目化管理、质量追溯和会员体系提升用户粘性。近年来,国外研究重点从“交易系统可用性”逐步转向“算法驱动增长”和“合规治理”,尤其重视隐私保护、交易安全与平台透明度。 + +国内母婴电商经过快速发展,已形成综合电商平台母婴频道与垂直母婴平台并行的格局。大量研究围绕 B/S 架构电商系统、Spring Boot + Vue 组合、订单与库存管理、权限控制等主题展开。现有成果在基础交易流程方面较完善,但在多角色协同、审核流程规范化、平台治理可视化以及运营数据沉淀方面仍有较大提升空间。 + +从已有文献和开源项目观察,当前典型问题包括:其一,系统功能多停留在“增删改查”层面,缺少完整业务闭环与跨模块联动;其二,部分系统权限边界不清晰,存在越权风险;其三,文档与实现脱节,导致论文陈述与系统实际不一致。基于此,构建一套与真实代码实现严格对齐、并具有工程可复现性的母婴商城系统,具有明确研究价值。 + +### 1.3 当前存在的问题 + +通过需求调研和项目分析,可归纳出母婴交易场景中的主要问题如下: + +1. **顾客侧体验不连贯。** 商品检索、收藏、加购、下单、查看物流、申请退款等行为分散,若系统设计不统一,用户需要多次跳转,交互成本较高。 +2. **商家侧运营工具不足。** 商家若无法及时查看订单、处理发货、核对库存变更与评价反馈,容易造成履约延迟与售后争议。 +3. **平台侧治理能力薄弱。** 缺少审核、风险订单识别、用户状态管理等能力时,平台难以有效维护交易秩序。 +4. **数据链路不完整。** 若订单、订单明细、物流、库存记录之间关联不清晰,无法支撑后续对账、统计分析和运营优化。 +5. **权限与认证机制不统一。** 如果没有统一鉴权机制和角色约束,系统将面临安全与一致性风险。 + +### 1.4 研究目标与内容 + +本文研究目标是实现一套覆盖顾客端、商家端、管理员端的母婴商城系统,并在论文层面形成“需求—设计—实现—测试”完整论证链条。具体目标包括: + +- 建立清晰的多角色业务边界和访问权限体系; +- 打通商品浏览、购物车、订单、物流、库存、审核等核心业务流程; +- 构建结构化数据库模型,保障关键业务对象的可追踪性; +- 形成可验证的测试方案,证明系统在功能与稳定性方面满足预期; +- 提供可扩展基础,支持后续接入智能推荐、风控与运营分析。 + +围绕上述目标,本文重点研究内容包括:需求建模、体系架构设计、数据库设计、接口设计、关键模块实现、测试验证与结果分析。 + +### 1.5 论文结构安排 + +全文共分七章。第1章介绍研究背景、问题、目标与论文结构;第2章阐述系统实现所需的技术与框架;第3章完成系统需求、可行性与用例分析;第4章进行系统架构、数据库、接口和流程设计;第5章说明系统实现过程与关键模块结果;第6章给出测试策略、测试用例与结果分析;第7章总结研究成果并提出未来改进方向。 + +--- + +## 第2章 相关技术与开发框架 + +### 2.1 后端技术体系 + +#### 2.1.1 Spring Boot 3 + +Spring Boot 3 提供约定优于配置的开发模式,能够快速构建独立运行的企业级 Web 应用。其自动配置机制简化了项目初始化与组件整合过程,使开发者能够将主要精力聚焦于业务逻辑实现。对于本系统而言,Spring Boot 主要承担 REST 接口发布、依赖注入、生命周期管理、异常处理统一化等职责。 + +在工程实现中,系统通过控制器层接收请求、服务层处理业务、仓储层访问数据库,形成分层清晰的后端结构。该模式降低了模块耦合度,提升了维护效率和可测试性。 + +#### 2.1.2 Spring Data JPA + +Spring Data JPA 为数据访问层提供了较高抽象,开发者可通过 Repository 接口快速完成常见持久化操作。相比手写大量 SQL 或样板代码,该技术在中型项目中能够显著提升开发效率。系统中用户、商品、订单、订单明细、物流、库存记录等对象均通过实体映射与仓储接口完成数据读写。 + +#### 2.1.3 MySQL 8 + +MySQL 8 作为关系型数据库,具有成熟稳定、生态完善和部署成本可控的优势,适合本课题中结构化业务数据的持久化存储。系统基于主键、自增、唯一约束等机制保证数据一致性,并通过业务字段(状态、创建时间、更新时间)支撑订单生命周期管理和审计追踪。 + +### 2.2 前端技术体系 + +#### 2.2.1 Vue3 与 Vite + +Vue3 采用组件化开发思想,结合响应式机制可高效构建中大型单页应用。Vite 在开发期提供快速热更新能力,在构建期具备较高效率,适合毕业设计项目的迭代开发需求。系统前端将管理员、商家和顾客页面进行模块化拆分,通过统一组件风格和交互逻辑提升可维护性。 + +#### 2.2.2 Vue Router + +Vue Router 负责路由组织与页面跳转。系统路由结构以角色分区为核心,管理员与商家采用 Layout + 子路由嵌套方式,顾客端以商品、购物车、订单、个人中心为主路径,保证了信息架构清晰和业务导航可理解。 + +#### 2.2.3 Arco Design + +Arco Design 为后台管理与业务型界面提供了较丰富的组件库支持,如表格、表单、卡片、弹窗、标签等。通过统一视觉与交互规范,系统减少了重复样式开发成本,使团队可以将更多精力投入业务功能实现。 + +### 2.3 鉴权与访问控制机制 + +系统采用基于 Token 的鉴权模式。用户登录成功后,服务端生成唯一 Token 并保存至用户记录,前端在后续请求中通过 `X-Token` 请求头携带该凭证。后端拦截器在请求到达控制器前完成 Token 校验、用户状态校验和上下文注入,从而实现统一认证。 + +在授权方面,系统以角色为核心控制粒度,定义了 `ADMIN`、`MERCHANT`、`CUSTOMER` 三类角色。商家和管理员接口在进入业务逻辑前进行角色检查,确保访问边界清晰。该设计虽然较 JWT 方案更轻量,但在单体架构与中小并发场景下能够满足可用性与开发成本之间的平衡。 + +### 2.4 技术选型对比与决策依据 + +在后端框架选型中,Node.js、Django、Spring Boot 均可实现电商业务。综合考虑 Java 生态成熟度、工程化能力、团队技术基础与后续可扩展性,最终选择 Spring Boot 作为核心后端框架。数据访问层选择 JPA 以减少样板代码;数据库采用 MySQL 以获得部署便利和社区支持。 + +在前端选型中,React、Vue、Angular 均具备构建能力。考虑到学习曲线、项目周期、组件生态和开发效率,选择 Vue3 + Vite + Arco Design 的技术组合。该方案能够较快完成三端页面搭建并保持较好维护性。 + +综上,本系统技术路线遵循“实现目标明确、开发效率优先、稳定性可保障、后续扩展可承接”的原则,具有可行性与实践价值。 + +--- + +## 第3章 萌贝母婴商城系统分析 + +### 3.1 需求分析 + +#### 3.1.1 功能需求分析 + +系统功能从角色维度可分为顾客端、商家端、管理员端三个部分。 + +**(1)顾客端需求** + +顾客是平台交易链路的核心参与者,主要功能需求如下: + +- 用户注册与登录; +- 商品浏览、分类筛选与关键字搜索; +- 商品加入购物车、修改数量、移除; +- 直接购买与购物车结算; +- 收藏商品与取消收藏; +- 查看订单、修改收货地址、申请退款、查看物流; +- 对已购买商品进行评价; +- 维护个人信息。 + +**(2)商家端需求** + +商家是商品供给与履约主体,主要功能需求如下: + +- 查看经营概览(订单量、销售额、热门商品等); +- 商品管理(新增、编辑、下架/删除); +- 订单管理(查看订单、执行发货、处理退款); +- 查看评价和物流记录; +- 查看库存变更记录并进行必要清理; +- 维护个人信息。 + +**(3)管理员端需求** + +管理员承担平台治理职责,主要功能需求如下: + +- 平台概览查看; +- 订单管理与风险订单识别; +- 退款审核、发货审核; +- 商家入驻申请审核; +- 用户管理(新增、修改、删除); +- 商品管理与审核; +- 轮播图管理; +- 查看评价、物流、库存数据。 + +#### 3.1.2 业务流程需求分析 + +系统主要业务流程如下: + +1. 顾客登录后浏览商品并加入购物车; +2. 顾客提交订单后,系统生成订单主记录与订单明细; +3. 商家查看订单并执行发货; +4. 顾客在订单生命周期内可查看物流、申请退款或修改地址(满足状态约束时); +5. 管理员对关键环节进行审核和监控; +6. 库存记录与物流记录在业务动作中同步沉淀。 + +该流程强调“交易与治理并重”,兼顾用户体验和平台秩序。 + +### 3.2 可行性分析 + +#### 3.2.1 技术可行性 + +系统采用的技术栈均为成熟开源方案,社区文档丰富、工程案例充足。Spring Boot 与 Vue3 的组合在中小型 Web 应用中具有广泛实践,能够稳定支撑本项目的三端业务功能。MySQL 对于订单、商品等结构化数据管理具备良好适配性。综合评估后,技术风险可控。 + +#### 3.2.2 经济可行性 + +本系统主要依赖开源技术,无商业授权成本,开发与部署对硬件资源要求适中。对于中小团队或教学场景而言,整体投入较低,具备较高性价比。系统上线后可减少人工管理与沟通成本,长期收益明显。 + +#### 3.2.3 操作可行性 + +前端界面采用统一风格,操作路径清晰,用户学习门槛较低。管理员与商家端采用后台布局方式,便于快速定位功能入口。顾客端以购物流程为导向,减少复杂操作。整体上系统符合用户习惯,具备良好的可用性。 + +### 3.3 角色用例分析 + +#### 3.3.1 顾客用例 + +顾客用例包含:注册登录、浏览商品、搜索商品、加入购物车、立即购买、提交订单、查看订单、申请退款、查看物流、收藏商品、商品评价、修改个人信息等。 + +**图3.1 顾客用例图(论文定稿阶段插入)** + +#### 3.3.2 商家用例 + +商家用例包含:登录、查看概览、商品管理、订单管理、发货处理、退款处理、评价查看、物流查看、库存记录查看、个人信息维护。 + +**图3.2 商家用例图(论文定稿阶段插入)** + +#### 3.3.3 管理员用例 + +管理员用例包含:登录、平台概览、订单管理、风险订单查看、退款审核、发货审核、商家申请审核、用户管理、商品审核、轮播图管理、评价/物流/库存查看。 + +**图3.3 管理员用例图(论文定稿阶段插入)** + +### 3.4 关键用例描述 + +#### 3.4.1 顾客下单用例描述 + +| 项目 | 内容 | +|---|---| +| 用例名称 | 顾客下单 | +| 执行者 | 顾客 | +| 前置条件 | 顾客已登录,购物车存在有效商品 | +| 后置条件 | 生成订单与订单明细,购物车对应商品清空 | +| 基本事件流 | 进入购物车→确认商品数量与地址→提交订单→系统校验库存→生成订单→返回成功结果 | +| 异常事件流 | 商品库存不足或商品失效时,系统阻止下单并提示原因 | + +#### 3.4.2 商家发货用例描述 + +| 项目 | 内容 | +|---|---| +| 用例名称 | 商家发货 | +| 执行者 | 商家 | +| 前置条件 | 商家已登录,订单属于当前商家且状态可发货 | +| 后置条件 | 订单状态更新为已发货,新增物流记录 | +| 基本事件流 | 进入订单管理→选择订单→填写发货备注→提交发货→系统更新订单状态和物流信息 | +| 异常事件流 | 订单不属于当前商家或状态不允许发货时,系统拒绝操作 | + +#### 3.4.3 管理员审核退款用例描述 + +| 项目 | 内容 | +|---|---| +| 用例名称 | 管理员审核退款 | +| 执行者 | 管理员 | +| 前置条件 | 管理员已登录,订单存在退款申请 | +| 后置条件 | 订单退款状态更新并记录审核备注 | +| 基本事件流 | 进入订单审核→查看退款原因→选择通过/驳回→提交审核→系统更新状态 | +| 异常事件流 | 订单状态不匹配或参数非法时,系统返回错误提示 | + +#### 3.4.4 管理员审核商家入驻用例描述 + +| 项目 | 内容 | +|---|---| +| 用例名称 | 商家入驻审核 | +| 执行者 | 管理员 | +| 前置条件 | 管理员已登录,存在待审核申请 | +| 后置条件 | 申请状态更新为通过或驳回 | +| 基本事件流 | 进入申请列表→查看资质信息→填写审核意见→提交结果 | +| 异常事件流 | 申请不存在或状态已变更时,系统提示刷新后重试 | + +### 3.5 非功能需求分析 + +#### 3.5.1 性能需求 + +系统应保证常见业务请求具备可接受响应速度,尤其是商品列表、订单列表、后台管理列表等高频查询场景。通过分页展示、条件过滤和必要索引设计,控制查询压力,避免前端一次性加载过多数据。 + +#### 3.5.2 安全需求 + +系统需具备统一认证机制与角色访问边界。未认证请求不得访问受限接口;不同角色仅可访问授权资源。关键业务应进行参数校验与状态校验,降低越权操作和非法输入风险。 + +#### 3.5.3 可维护性需求 + +系统模块应具备清晰边界,接口命名与响应结构保持统一,异常处理集中化。代码层面采用分层架构,文档层面保证“描述与实现一致”,便于后续迭代。 + +#### 3.5.4 可扩展性需求 + +系统应预留推荐、支付、营销活动、消息通知、报表分析等扩展接口。新增业务应在现有数据模型上以增量方式演进,避免大规模重构核心链路。 + +--- + +## 第4章 萌贝母婴商城系统设计 + +### 4.1 系统总体架构设计 + +系统采用典型的前后端分离架构。前端负责交互展示与状态管理,通过 HTTP 请求调用后端 API;后端负责业务逻辑处理、权限校验和数据持久化;数据库负责核心业务数据存储。 + +在部署结构上,前端可通过静态资源服务对外提供页面访问,后端作为独立服务提供 REST 接口,MySQL 提供统一数据存储。该架构具备解耦性强、职责清晰、便于扩展的特点。 + +**图4.1 系统总体架构图(论文定稿阶段插入)** + +### 4.2 功能结构设计 + +#### 4.2.1 顾客端功能结构 + +顾客端围绕购物路径设计:商品浏览/检索 → 收藏/加购 → 下单支付(本系统先实现订单生成)→ 订单管理 → 物流与售后。个人中心提供资料维护能力。 + +#### 4.2.2 商家端功能结构 + +商家端围绕“经营与履约”设计:经营概览 → 商品管理 → 订单处理 → 发货/退款处理 → 评价与物流查看 → 库存记录追踪。该结构强调履约效率与运营透明度。 + +#### 4.2.3 管理员端功能结构 + +管理员端围绕“平台治理”设计:数据概览 → 订单管理与风险识别 → 审核管理(商家入驻、退款、发货)→ 用户管理 → 商品审核 → 轮播图配置 → 数据查看(评价、物流、库存)。 + +**图4.2 三端功能结构图(论文定稿阶段插入)** + +### 4.3 数据库设计 + +#### 4.3.1 概念设计 + +根据业务需求,系统核心实体包括:用户、商品、购物车项、收藏项、订单、订单明细、评价、物流记录、库存记录、商家申请、轮播图。实体间主要关系如下: + +- 用户与订单:一对多; +- 订单与订单明细:一对多; +- 商品与订单明细:一对多; +- 商家与商品:一对多; +- 订单与物流记录:一对多; +- 用户与商家申请:一对多(在业务语义上可视为一次或多次申请记录)。 + +**图4.3 系统 E-R 图(论文定稿阶段插入)** + +#### 4.3.2 逻辑设计 + +依据概念模型转化得到主要关系模式: + +1. `users(id, username, password, role, nickname, phone, address, token, enabled, created_at, updated_at)` +2. `product(id, name, category, description, price, stock, image_url, merchant_id, approved, created_at, updated_at)` +3. `cart_item(id, customer_id, product_id, quantity)` +4. `favorite(id, customer_id, product_id)` +5. `orders(id, order_no, customer_id, merchant_id, total_amount, status, address, logistics_info, refund_reason, created_at, updated_at)` +6. `order_item(id, order_id, product_id, product_name, quantity, unit_price)` +7. `review(id, order_id, product_id, customer_id, rating, content, created_at)` +8. `logistics_record(id, order_id, merchant_id, status, note, created_at)` +9. `inventory_record(id, product_id, merchant_id, change_qty, note, created_at)` +10. `merchant_application(id, user_id, qualification, status, remark, created_at, updated_at)` +11. `banner(id, image_url, link_url, sort_no, enabled)` + +#### 4.3.3 物理设计 + +以下列出部分关键物理表设计示例。 + +**表4.1 用户表(users)** + +| 字段名称 | 字段含义 | 类型 | 约束 | +|---|---|---|---| +| id | 用户ID | BIGINT | 主键,自增 | +| username | 登录账号 | VARCHAR(50) | 唯一,非空 | +| password | 密码 | VARCHAR(100) | 非空 | +| role | 角色 | VARCHAR(20) | 非空 | +| token | 登录令牌 | VARCHAR(100) | 可空 | +| enabled | 启用状态 | BIT | 默认1 | + +**表4.2 商品表(product)** + +| 字段名称 | 字段含义 | 类型 | 约束 | +|---|---|---|---| +| id | 商品ID | BIGINT | 主键,自增 | +| name | 商品名称 | VARCHAR(120) | 非空 | +| category | 类目 | VARCHAR(50) | 可空 | +| price | 价格 | DECIMAL(10,2) | 非空 | +| stock | 库存 | INT | 非空 | +| merchant_id | 商家ID | BIGINT | 非空 | +| approved | 审核状态 | BIT | 默认0 | + +**表4.3 订单表(orders)** + +| 字段名称 | 字段含义 | 类型 | 约束 | +|---|---|---|---| +| id | 订单ID | BIGINT | 主键,自增 | +| order_no | 订单编号 | VARCHAR(50) | 唯一,非空 | +| customer_id | 顾客ID | BIGINT | 非空 | +| merchant_id | 商家ID | BIGINT | 非空 | +| total_amount | 订单总额 | DECIMAL(10,2) | 非空 | +| status | 订单状态 | VARCHAR(30) | 非空 | +| logistics_info | 物流信息 | VARCHAR(255) | 可空 | + +**表4.4 订单明细表(order_item)** + +| 字段名称 | 字段含义 | 类型 | 约束 | +|---|---|---|---| +| id | 明细ID | BIGINT | 主键,自增 | +| order_id | 订单ID | BIGINT | 非空 | +| product_id | 商品ID | BIGINT | 非空 | +| product_name | 商品名称 | VARCHAR(120) | 非空 | +| quantity | 数量 | INT | 非空 | +| unit_price | 单价 | DECIMAL(10,2) | 非空 | + +### 4.4 接口与权限设计 + +#### 4.4.1 接口分层与命名规范 + +系统接口按职责划分为四类: + +- `/api/auth`:认证与个人信息; +- `/api/public`:公开商品与轮播信息; +- `/api/customer`:顾客业务; +- `/api/merchant`:商家业务; +- `/api/admin`:管理员业务。 + +响应模型采用统一包装结构,包含 `success`、`data`、`message` 等字段(依据后端公共响应类实现)。该设计可降低前后端联调复杂度并提高错误处理一致性。 + +#### 4.4.2 认证机制设计 + +请求进入后端时先由拦截器检查路径是否属于公开路径,若非公开路径则读取 `X-Token` 并查找用户记录。若 Token 缺失、无效或用户被禁用,接口返回未授权错误。校验成功后将用户对象注入请求上下文,供控制器和服务层读取。 + +#### 4.4.3 角色权限设计 + +系统角色包括: + +- `CUSTOMER`:顾客权限,主要进行购物相关操作; +- `MERCHANT`:商家权限,主要进行商品与订单履约操作; +- `ADMIN`:管理员权限,负责平台治理与审核。 + +服务层通过统一角色校验方法拦截越权请求,保障业务边界安全。 + +### 4.5 关键流程设计 + +#### 4.5.1 顾客下单流程 + +顾客在购物车确认商品后发起下单请求,系统按商品逐项校验库存并计算总价,创建订单主记录和订单明细记录,同时扣减库存并写入库存变更流水,最后清空对应购物车数据。 + +#### 4.5.2 商家发货流程 + +商家在订单列表中选择目标订单,填写发货备注后提交。系统验证订单归属和状态后更新订单状态为已发货,并新增物流记录。 + +#### 4.5.3 退款处理流程 + +顾客提交退款申请后,订单状态进入退款申请中。商家和管理员可依据业务规则进行审核;审核通过则更新退款状态并记录备注。 + +**图4.4 关键业务序列图(论文定稿阶段插入)** + +### 4.6 界面设计 + +系统界面遵循“角色聚焦、操作路径短、反馈明确”的设计原则: + +- 顾客端页面强调商品展示、加购和订单追踪; +- 商家端页面强调经营概览、订单处理和库存记录; +- 管理员端页面强调审核、治理与数据可视化。 + +界面组件统一采用 Arco Design,保证交互一致性和视觉规范性。关键页面包括登录页、商品列表页、购物车页、订单页、商家后台概览页、管理员审核页等。 + +--- + +## 第5章 萌贝母婴商城系统实现 + +### 5.1 用户认证与基础模块实现 + +#### 5.1.1 注册与登录实现 + +系统在认证模块中提供注册与登录接口。注册时保存用户账号、密码和默认角色;登录时验证账号密码并生成 Token,写入用户记录后返回给前端。前端在本地存储 Token,并在后续请求头中统一携带。 + +该实现方案降低了认证复杂度,适用于教学与中小规模业务场景。相比完全无状态鉴权方案,本系统可通过数据库直接失效 Token,便于运维管理。 + +#### 5.1.2 个人信息维护实现 + +用户登录后可通过个人中心查看并修改昵称、电话、地址等信息。后端通过当前登录用户上下文定位目标记录,避免跨用户修改风险。该模块为后续订单收货与客服沟通提供基础数据支撑。 + +### 5.2 顾客端功能实现 + +#### 5.2.1 商品浏览与搜索 + +顾客可在首页浏览商品列表,并使用关键词进行检索。前端通过公开接口获取商品数据并渲染卡片列表,支持快速查看价格、库存和基础介绍信息。该功能提升了用户找货效率,是交易链路的入口模块。 + +#### 5.2.2 购物车与立即购买 + +购物车模块支持加购、数量调整与删除;立即购买模块支持跳过购物车直接创建订单。下单前顾客需填写或确认收货地址,后端在提交订单时进行库存校验与金额计算,确保交易数据准确。 + +#### 5.2.3 订单管理与售后处理 + +顾客可查看订单列表、订单明细、物流信息,并在允许状态下申请退款、修改地址或删除历史订单。该模块覆盖了订单生命周期中的主要用户操作,显著提升售后体验。 + +#### 5.2.4 收藏与评价 + +收藏模块帮助用户沉淀意向商品,评价模块允许顾客对购买商品进行反馈。评价数据可被商家和管理员查看,为商品优化和平台治理提供参考。 + +### 5.3 商家端功能实现 + +#### 5.3.1 商家概览 + +商家概览模块汇总订单数量、销售额、类目数据与热销趋势,帮助商家快速掌握经营状态。该模块通过后端聚合接口返回统计结果,前端以图表和卡片方式展示。 + +#### 5.3.2 商品管理 + +商家可新增、编辑和删除商品。保存商品时后端会绑定当前商家 ID,防止跨商家数据污染。管理员可对商品进行审核,形成“上架信息可控、商品质量可管”的平台机制。 + +#### 5.3.3 订单履约与退款处理 + +商家在订单管理中可执行发货并记录备注,也可处理退款申请。系统在服务层进行订单归属与状态校验,避免非法操作。履约链路与物流记录联动,提升交易透明度。 + +#### 5.3.4 库存记录与物流查看 + +库存记录模块展示商品库存变更明细,帮助商家进行库存核对。物流查看模块可追踪订单履约过程,减少因信息不对称产生的售后争议。 + +### 5.4 管理员端功能实现 + +#### 5.4.1 订单治理与风控 + +管理员可查看全部订单并执行状态更新,系统支持风险订单列表、退款审核与发货审核等治理能力。通过后台治理机制,平台可对异常交易进行及时干预。 + +#### 5.4.2 商家入驻审核 + +顾客提交商家申请后,管理员可在申请列表中进行审核。审核结果直接影响商家角色业务权限,有助于提升平台商家质量与合规性。 + +#### 5.4.3 用户与商品管理 + +管理员可管理用户账户状态、增删改查用户信息,并对商品进行统一审核和维护。该能力是平台治理的核心基础。 + +#### 5.4.4 轮播图与运营配置 + +管理员可配置首页轮播图,提升运营活动触达能力。该模块在营销场景中具有较高实用价值,便于平台开展阶段性推广活动。 + +### 5.5 关键业务链路实现结果 + +#### 5.5.1 从浏览到下单链路 + +系统已实现完整的顾客购物主链路:浏览商品、加入购物车、提交订单、查看订单。链路中的关键数据对象(商品、订单、订单明细、库存记录)可关联追踪,业务闭环完整。 + +#### 5.5.2 从下单到履约链路 + +商家可查看订单并完成发货,系统同步生成物流记录,顾客可查看物流详情。该链路提升了订单履约的可视化程度。 + +#### 5.5.3 从异常到治理链路 + +退款申请、风险订单、商家审核等场景由管理员侧进行治理,形成“业务执行 + 平台监管”双轮驱动模式,提升平台稳定性与可信度。 + +--- + +## 第6章 萌贝母婴商城系统测试 + +### 6.1 测试环境与测试策略 + +#### 6.1.1 测试环境 + +- 操作系统:macOS / Windows(开发与演示环境); +- JDK 版本:17; +- 后端框架:Spring Boot 3.3.5; +- 前端框架:Vue3 + Vite; +- 数据库:MySQL 8; +- 浏览器:Chrome、Edge(主)。 + +#### 6.1.2 测试策略 + +系统测试采用“模块测试 + 业务流程测试 + 权限测试 + 兼容性测试”组合策略: + +1. 模块测试验证接口功能正确性; +2. 流程测试验证跨模块业务链路完整性; +3. 权限测试验证角色访问控制有效性; +4. 兼容性测试验证主流浏览器访问可用性。 + +### 6.2 功能测试 + +#### 6.2.1 认证功能测试 + +| 测试编号 | 测试内容 | 输入条件 | 预期结果 | 测试结果 | +|---|---|---|---|---| +| T001 | 用户登录成功 | 正确账号密码 | 返回Token并跳转角色主页 | 通过 | +| T002 | 登录失败 | 错误密码 | 返回错误提示 | 通过 | +| T003 | 未登录访问受限接口 | 无Token | 返回未授权 | 通过 | + +#### 6.2.2 商品与购物车测试 + +| 测试编号 | 测试内容 | 输入条件 | 预期结果 | 测试结果 | +|---|---|---|---|---| +| T101 | 商品检索 | 关键字“奶粉” | 返回匹配商品列表 | 通过 | +| T102 | 加入购物车 | productId+quantity | 购物车新增记录 | 通过 | +| T103 | 删除购物车项 | 指定productId | 购物车项移除 | 通过 | + +#### 6.2.3 订单与售后测试 + +| 测试编号 | 测试内容 | 输入条件 | 预期结果 | 测试结果 | +|---|---|---|---|---| +| T201 | 购物车结算下单 | 有效商品与地址 | 生成订单与明细 | 通过 | +| T202 | 修改订单地址 | 可修改状态订单 | 地址更新成功 | 通过 | +| T203 | 申请退款 | 已支付订单 | 状态改为退款申请中 | 通过 | +| T204 | 查看物流 | 已发货订单 | 返回物流记录 | 通过 | + +#### 6.2.4 商家功能测试 + +| 测试编号 | 测试内容 | 输入条件 | 预期结果 | 测试结果 | +|---|---|---|---|---| +| T301 | 商家新增商品 | 合法商品信息 | 商品保存成功 | 通过 | +| T302 | 商家发货 | 商家订单+备注 | 状态更新并写入物流 | 通过 | +| T303 | 商家处理退款 | 退款申请订单 | 状态按操作变更 | 通过 | + +#### 6.2.5 管理员功能测试 + +| 测试编号 | 测试内容 | 输入条件 | 预期结果 | 测试结果 | +|---|---|---|---|---| +| T401 | 用户管理 | 新增/删除用户 | 数据正确变更 | 通过 | +| T402 | 商家申请审核 | 待审核申请 | 状态更新成功 | 通过 | +| T403 | 商品审核 | 审核商品状态 | 审核状态变更 | 通过 | + +### 6.3 安全性与兼容性测试 + +#### 6.3.1 安全性测试 + +- Token 缺失或非法时,受限接口拒绝访问; +- 顾客账号访问商家/管理员接口时,系统返回权限错误; +- 参数缺失、状态不合法的请求会被业务规则拦截; +- 关键操作通过统一异常处理返回可读错误信息。 + +#### 6.3.2 兼容性测试 + +在 Chrome 与 Edge 浏览器下,登录、商品浏览、下单、后台管理等核心页面渲染正常,交互流程可用。不同分辨率下布局保持基本稳定,满足课程项目展示需求。 + +### 6.4 测试结果分析 + +测试结果表明,系统在核心功能、角色权限控制和主要流程链路上运行稳定,能够满足设计预期。当前仍存在可优化空间: + +1. 缺少在线支付闭环,仅实现订单生成与状态流转; +2. 库存预警与自动补货机制尚未实现; +3. 推荐与个性化能力不足,主要依赖基础检索; +4. 运营分析维度可进一步增强。 + +总体而言,系统已达到毕业设计“可运行、可验证、可扩展”的目标。 + +--- + +## 第7章 结论与展望 + +### 7.1 研究结论 + +本文围绕母婴电商场景,完成了萌贝母婴商城系统的分析、设计、实现与测试工作。研究成果主要体现在以下方面: + +1. 构建了面向顾客、商家、管理员三角色的业务系统,形成较完整的交易与治理闭环; +2. 基于 Spring Boot + Vue3 实现了前后端分离架构,模块边界清晰,具备较好可维护性; +3. 完成了用户、商品、订单、物流、库存、审核等关键数据模型设计与落地; +4. 通过测试验证系统在功能完整性、权限有效性和流程可用性方面符合预期。 + +本研究证明了在教学项目与中小规模业务背景下,采用成熟开源技术栈能够快速实现具备工程价值的垂直电商系统。 + +### 7.2 不足与改进方向 + +尽管系统已实现主要目标,但仍存在以下不足: + +- 支付模块未接入真实网关; +- 订单风控规则仍较基础; +- 统计分析多为聚合结果,缺少深度运营看板; +- 缺少自动化测试体系与持续交付流程。 + +未来可从以下方向持续优化: + +1. 接入支付网关并完善退款对账机制; +2. 引入推荐算法与用户画像,提高转化效率; +3. 增加库存预警、活动营销、消息通知等能力; +4. 建立自动化测试与 CI/CD 流程,提高交付质量; +5. 在安全层面引入更完善的 Token 生命周期管理与审计日志体系。 + +--- + +## 参考文献 + +[1] Spring Team. Spring Boot Reference Documentation[EB/OL]. https://docs.spring.io/spring-boot/docs/current/reference/html/, 2026-02-28. + +[2] Spring Team. Spring Security Reference[EB/OL]. https://docs.spring.io/spring-security/reference/, 2026-02-28. + +[3] Oracle. MySQL 8.0 Reference Manual[EB/OL]. https://dev.mysql.com/doc/refman/8.0/en/, 2026-02-28. + +[4] Evan You, Vue Team. Vue.js Documentation[EB/OL]. https://vuejs.org/guide/introduction.html, 2026-02-28. + +[5] Pinia Team. Pinia Official Documentation[EB/OL]. https://pinia.vuejs.org/, 2026-02-28. + +[6] Jones M, Bradley J, Sakimura N. JSON Web Token (JWT): RFC 7519[S]. IETF, 2015. + +[7] Black Horse Programmer. Spring Boot 企业级开发教程[M]. 北京: 人民邮电出版社, 2024. + +[8] 郑阿奇. MySQL 数据库教程[M]. 北京: 人民邮电出版社, 2024. + +[9] 杨玉, 刘杰举. 基于Spring Boot与Vue的物业管理系统设计与实现[J]. 鞋类工艺与设计, 2025, 5(14): 114-116. + +[10] 汤智宏. 基于 SpringBoot+Vue 的线上书店设计与实践[J]. 电脑编程技巧与维护, 2025(09): 71-73. + +[11] 冯赛赛, 郝婷. 影院管理系统的设计与实现[J]. 福建电脑, 2025, 41(05): 68-72. + +[12] 项露芬, 孙佳怡, 李梦婷. 基于Vue和Node.js的音乐门票管理系统的设计与实现[J]. 现代信息科技, 2025, 9(11): 96-101. + +[13] 闫俊甫. 基于 Spring Boot 和 Element UI 的中小型超市 ERP 系统的开发[J]. 电脑知识与技术, 2025, 21(16): 48-50. + +[14] 张磊. 基于 B/S 架构的矿区生态监管系统平台设计与实现[J]. 河南科技, 2025, 52(16): 17-22. + +[15] Gyan O J, Raheem A T, Ogundipe O M, et al. Enhancing Security Practices across the Software Development Lifecycle: The Role of Artificial Intelligence[J]. Asian Journal of Research in Computer Science, 2025, 18(10): 101-114. + +--- + +## 致谢 + +本课题从立项到论文初稿完成,离不开学院老师和同学们的支持。首先感谢指导教师在选题定位、技术路线、文档规范和阶段性评审中的耐心指导,使我能够在有限时间内持续修正方向、完善系统设计并推动实现落地。其次感谢项目组同学在需求讨论、页面联调、测试验证中的配合与建议,许多关键问题都在交流中得到解决。最后感谢家人对我学习与实践的理解和支持,使我能够保持稳定投入并完成本次毕业设计。 + +由于个人经验和时间限制,论文中仍存在不足,后续将继续优化系统功能与文档质量,力求在答辩前形成更高质量的定稿成果。 + +--- + +## 附录 + +### 附录A:项目目录结构(节选) + +- `/backend`:后端工程(控制器、服务、领域模型、仓储、配置) +- `/frontend`:前端工程(视图、路由、接口封装、状态管理) +- `/sql/init.sql`:数据库初始化脚本 +- `/example`:论文规范样例与排版脚本 + +### 附录B:默认测试账号 + +- 管理员:`admin / 123456` +- 商家:`merchant1 / 123456` +- 顾客:`customer1 / 123456` + +### 附录C:主要接口前缀 + +- `/api/auth`:注册登录与个人信息 +- `/api/public`:公开商品与轮播信息 +- `/api/customer`:顾客业务 +- `/api/merchant`:商家业务 +- `/api/admin`:管理员业务 + +### 附录D:术语说明 + +- **前后端分离**:前端界面与后端服务独立部署,通过 API 通信。 +- **角色权限控制**:基于用户角色约束可访问的功能与接口。 +- **业务闭环**:从需求入口到结果反馈形成完整可追踪流程。 +- **库存流水**:记录库存变化来源与数量的日志型数据。