1064 lines
56 KiB
Markdown
1064 lines
56 KiB
Markdown
# 爱维宠物医院管理系统的设计与实现（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），用`<<include>>`表示。包含关系表示一个父用例在执行过程中必然包含子用例的行为。以下按业务模块列出系统的主要包含关系：
|
||
|
||
**（1）顾客用例的include关系**
|
||
|
||
预约管理模块：
|
||
- 预约管理 <<include>> 提交预约
|
||
- 预约管理 <<include>> 取消预约
|
||
- 预约管理 <<include>> 查询预约记录
|
||
|
||
宠物档案模块：
|
||
- 宠物档案管理 <<include>> 新增宠物
|
||
- 宠物档案管理 <<include>> 编辑宠物
|
||
- 宠物档案管理 <<include>> 删除宠物
|
||
|
||
个人信息模块：
|
||
- 个人中心 <<include>> 修改个人信息
|
||
- 个人中心 <<include>> 修改密码
|
||
|
||
**（2）医生用例的include关系**
|
||
|
||
接诊管理模块：
|
||
- 接诊管理 <<include>> 查看预约
|
||
- 接诊管理 <<include>> 接诊确认
|
||
- 接诊管理 <<include>> 创建就诊记录
|
||
|
||
诊疗管理模块：
|
||
- 诊疗管理 <<include>> 编辑病历
|
||
- 诊疗管理 <<include>> 开具处方
|
||
- 诊疗管理 <<include>> 查看处方
|
||
|
||
历史查询模块：
|
||
- 历史查询 <<include>> 查询历史病历
|
||
- 历史查询 <<include>> 查询历史处方
|
||
|
||
个人信息模块：
|
||
- 个人中心 <<include>> 修改个人信息
|
||
- 个人中心 <<include>> 修改密码
|
||
|
||
**（3）管理员用例的include关系**
|
||
|
||
用户管理模块：
|
||
- 用户管理 <<include>> 查看用户列表
|
||
- 用户管理 <<include>> 新增用户
|
||
- 用户管理 <<include>> 编辑用户
|
||
- 用户管理 <<include>> 禁用用户
|
||
- 用户管理 <<include>> 启用用户
|
||
|
||
公告管理模块：
|
||
- 公告管理 <<include>> 发布公告
|
||
- 公告管理 <<include>> 编辑公告
|
||
- 公告管理 <<include>> 删除公告
|
||
|
||
药品与库存管理模块：
|
||
- 药品管理 <<include>> 新增药品
|
||
- 药品管理 <<include>> 编辑药品
|
||
- 药品管理 <<include>> 禁用药品
|
||
- 药品管理 <<include>> 启用药品
|
||
- 库存管理 <<include>> 药品入库
|
||
- 库存管理 <<include>> 药品出库
|
||
- 库存管理 <<include>> 库存查询
|
||
|
||
统计分析模块：
|
||
- 统计报表 <<include>> 预约统计
|
||
- 统计报表 <<include>> 订单统计
|
||
- 统计报表 <<include>> 药品消耗统计
|
||
|
||
个人信息模块：
|
||
- 个人中心 <<include>> 修改个人信息
|
||
- 个人中心 <<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章运行截图及测试截图可在系统最终验收阶段补充为正式附图。
|