🙊作者简介：拥有多年开发工作经验，分享技术代码帮助学生学习，独立完成自己的项目或者毕业设计。

1. 代码可以私聊博主获取。🌹
2. 赠送计算机毕业设计600个选题excel文件，帮助大学选题。
3. 赠送开题报告模板，帮助书写开题报告。

作者完整代码目录供你选择：

1. 《Springboot网站项目》400套
2. 《ssm网站项目》800套
3. 《小程序项目》300套
4. 《App项目》500套
5. 《python网站项目》600套

⚡感兴趣大家可以点点关注收藏，后续更新更多项目资料。⚡

项目演示

第1章 绪论

1.1研究背景

生产资料的不断扩大，还采用大量的人工方式处理相关数据，已经阻碍了社会的继续发展，当社会进入到电气时代，家家户户都可以用上了电力照明技术，随着电磁技术的发展，信息的可持续传递取得了蓬勃发展。随着地域的扩大，相关信息完全可以通过电子信号进行传递，不用人为的走动即可获取相关信息，互联网时代的到来，就是这么悄无声息而又水到渠成。国内互联网从无序发展到有序发展，从单机到网络互联，也就这么几十年的时间，而恰好是这几十年的时间，中国的发展取得了辉煌的成就，尤其是互联网的发展，走到了世界前列，从村村通电到村村通网，是一个信息社会发展的重要台阶。采用互联网思维，把现有的一些信息处理流程变成网络化处理，可以极大的提高信息处理速度。在这样的大环境下，针对医务室信息的管理，设计一个医务室管理系统，不仅仅可以更上时代的潮流，还能规范信息处理的流程，提高处理效率，降低信息处理成本，可以让使用者有更多的精力和资源投入其他的方面创造效益。

1.2研究意义

信息时代的到来，与传统农耕社会的不同在于信息的更新以及传递更加的迅速，加快了人们对于信息处理的节奏，如果还是拥抱过去的信息处理技术，比如比较怀古的人还用毛笔来进行记账或者记录一下长篇大论的东西，这个可以称之为情怀，但是不能成为社会的主流。当今社会，不管是课堂还是课外，基本上人人持有可移动终端，可以随时的被动以及主动获取相关信息以及社会舆论，不管是移动终端还是电脑，都只是一个获取以及处理信息的一个窗口，关于数据的服务端处理还是需要专业的软件来进行分发。采用计算机来进行设计某些想要的需求，是可靠的。所以开发医务室管理系统不仅可以实现快速的信息处理，并且不知疲倦，可靠稳定，符合当今社会的发展潮流。

医务室管理系统的开发意义有以下几点：

（1）医务室管理系统不仅规范了操作人员的操作流程，还提高了信息处理的效率。

（2）操作符合正常人们的审美观，并且符合正常的操作逻辑，使用方便。

（3）对比人们以前的信息处理速度，现在的速度是符合社会发展的，也是当前社会最快的信息处理方法。

（4）极大的降低了人工成本，医务室管理系统可以全天候的等待，随时可以查看和处理相关数据。

1.3国内外研究现状

美国等发达国家的医院广泛采用医务室管理系统，通过该系统实现医疗信息的实时共享和协作，提高了医疗效率和工作质量。欧洲的一些研究也表明，医务室管理系统可以提高学生健康管理的效果，为学校提供更好的健康服务。总之，医务室管理系统在国外的研究和应用已经证明了其良好的效果和广泛的适用性，为我国的医务室管理和学生健康管理提供了借鉴和参考。

在国内，医务室管理系统的研究和应用还处于初步阶段。目前，医务室管理系统主要应用于学校和企事业单位内部的医务室管理。国内的相关研究表明，医务室管理系统可以有效提高医务室的服务质量和工作效率，减少和避免医疗风险。另外，市面上也有一些医务室管理系统供学校或企事业单位使用，这些系统主要针对医生的工作流程和学生健康档案管理做了优化和改进。

1.4研究内容

医务室管理系统将使用人员划分为两类，分别是管理员，医师。这些使用者中，管理员的操作权限最大，拥有所有功能的操作权限，其他使用者都是根据工作需要合理的安排部分功能。

对于管理员角色，系统允许其操作所有的功能，其主要包括管理医师信息，审核器材申请信息，管理器材信息以及器材报废信息，管理患者信息，管理患者的就诊记录信息，管理项目信息，管理药品信息，管理药品出售信息等。

对于医师角色，系统允许其登录系统之后，可以申请器材，登记器材报废信息，登记药品出售信息，管理患者，管理患者就诊记录信息，查看器材，查看药品信息等。

1.5论文组织结构

本文从绪论，开发环境与技术，系统分析，设计，实现，测试等方面来描述系统。

绪论：介绍系统的开发意义与背景。

开发环境与技术：介绍系统采用的数据库，选用的编程语言和框架等知识。

系统分析：介绍系统功能需求，可行性以及非功能需求等内容。

系统设计：介绍设计的系统功能结构，设计的数据库等内容。

系统实现：选用部分功能来介绍系统的实现情况。

系统测试：介绍测试内容和测试的部分功能。

第2章 关键技术介绍

2.1 MySQL数据库

MySQL数据库的存储结构是完全符合关系型数据库规则的，并且符合行式数据库的美学，存放的数据是以表格的形式存在的，每一行都会对应相关的字段用来存储相关字段的值，并且可以对每个字段进行数据定义和空间大小定义，数据定义解决了同类数据的存储精度，空间定义则是对数据的大小进行了完美的规划。比如当前国内的手机号码都是不超过11位的纯数字，那么定义手机号的字段完全可以定义为int（11），这样即使表内大量的存储相关数据，最起码在手机号这个字段存储效率上达到了压缩极致，还有其他的字段类型也是一样的考虑。充分分析项目所需要的数据模式，以及当前在现实生活中的具体实例，可以有效的帮助我们定义好相关的数据库存储模块。之所以不使用其他的关系型数据库，比如SQL Server数据库和Oracle数据库，最主要的原因就是它们两个的安装包都好几个G，安装过程和使用过程会占用当前使用的计算机的大量性能，影响使用效果，并且卸载和安装都是很麻烦，稍微有点问题就需要对电脑的操作系统进行重装，这样会浪费时间，并且影响开发效率的。所以最终选择使用了MySQL数据库。

2.2 IDEA开发工具

Idea这款软件也是有二十多年的历史了，Java语言推出之后，刚开始人们开发用的是最简单的记事本来进行编写，随着时间的发展，业务不断的增加，功能也变多了，代码自然而然也就变多了，人们急需一款可以辅助人们管理代码的软件，前期记事本和高级记事本也只是多了些代码标记而已，并没有大的提升，好多环境还是需要手动配置的，随着eclipse的发展，MyEclipse这款商业集成曾经占领了很大一部分市场，当年用Windows XP系统的时候都可以用eclipse和MyEclipse软件，那个时候也有了idea，但是国内用的人比较少，随着国内经济的不断发展，计算机硬件的不断提升，人们的眼界越来越宽阔，所以idea就出现了中文版，然后用的人就越来越多了。Idea能做的事情，MyEclipse都能做到，但是idea首先颜值很高，可以选择好几种开发模式，看起来很漂亮，让程序员使用的时候赏心悦目，功能并不少，还有国人喜欢的绿色功能，不需要安装，解压就可以用，而MyEclipse官网下载的是必须安装才能使用的。

2.3 Java语言

Java语言的流行到现在依然是程序开发行业的标杆之一，就能看出Java语言的魅力所在了。Java语言是强类型语言，特别适合某些大中型企业对于程序运行的稳定要求，之所以说Java稳定，在于Java的可移植性，适合各种类型的服务器平台，像那些嵌入式语言或者其他只能在某个平台上运行的语言，已经逐渐的开始学习Java语言的特性了，各种语言都在不断的吸收对方的优点来强化自身，虽然出现了很多小众的语言来解决特定的业务需求，但是非特定需求还是需要强壮的Java语言来进行开发。Java这个强类型语言，要求对各种数据类型进行强制性的定义，就像考驾照一样，大家必须遵守一定的规则，类似于红灯停绿灯行这样的要求，Java语言比考驾照更严谨，如果出现未定义的变量类型，那么在开发过程中，只能的IDE就会提示你未定义某某变量，甚至不用等你运行程序就能明白错误在哪里。Java语言可移植的特性在于Java程序并不是直接运行在各种服务器平台上面，而是运行在属于自己的Java平台上面，也就是翻译过来的Java虚拟机，Java虚拟机有各种服务器版本，这个由Java语言的公司来进行开发和提供，我们只需要免费使用即可，不用考虑开发出来的程序具体是运行在哪个平台上面。

2.4 Spring Boot 框架

随着计算机语言的不断发展，比如Python或者JavaScript，只需要敲几行命令就可以把一些需要的库文件下载下来，然后敲少许的代码就可以引用，而Java的开发者还需要研究可能会用到哪些JAR包或者哪些Maven里面的库，以及如何在代码里进行引用，这是一个问题。所以，吸收了其他语言的优点，Spring Boot框架就出现了。Spring Boot框架里面内置的一个通用的配置，除非项目比较小众，如果是大众化的项目完全可以不需配置，直接使用内置的配置即可。采用Spring Boot开发一些微型的项目是速度很快的，比如一个只需要登录的功能的项目作为服务，可以直接在官网上下载相关模板，然后进行修改就变成了一个项目。

2.5 本章小结

本章主要介绍项目实现的关键性技术，包含开发必备的软件MySQL和IDEA，以及使用到的关键开发技术Java平台的Spring Boot框架。

第3章 系统需求分析

课题的确定，对本人的后续研究提供了主要方向。通过在各大专业网站上搜索相关文献，了解相关可实现的技术知识以及功能大致相同的实现，结合本课题的具体实现具体分析，才能分析出课题的具体功能。系统分析主要是对功能实现提供最主要的理论支撑，会影响到后续的所有开发环节，所以很重要。

3.1可行性分析

任何系统的开发过程都非常漫长且充满坎坷，所以一旦确定系统进入开发阶段，就不能放弃。为了避免出现中途放弃开发系统这样的现象，提高系统的开发成功率，前期的可行性分析就能够为系统是否能够达到目标提供充分的分析材料，也是为系统能否进入开发阶段提供依据。

（1）技术可行性

医务室管理系统使用的技术有Java技术，MySQL数据库技术等，这些技术目前在网络上进行了公开，且有很多的成功项目的开发都运用了上述技术，开发出来的系统在满足功能实用的前提下，同时具有操作简便，具有很高的互动性的特点。此外，系统为了不局限使用用户，让使用者可以在任意场合和任意时间段操作系统，特意采用B/S模式设计开发，为后期系统的维护提供了方便，也让系统在经过一段时间的市场考验之后，进行系统功能扩展升级提供了可能性。因此，系统技术可行。

（2）经济可行性

在系统开发期间，无论是系统的开发平台，还是系统开发运用的技术目前都能通过网络成功获取，并且不需要支付费用，所以在技术方面不存在费用支出。但是本系统用于计算机代替人工处理种类繁多的数据，在一定程度上方便了管理者，在数据处理效率上也有明显的提升，同时相较于之前的人工管理，该系统也节省了人工成本，所以系统开发经济可行。

（3）操作可行性

每个用户在使用系统过程中，可能运用的浏览器和操作系统都不一样，所以本系统在设计中，需要考虑系统兼容性，让不同用户在不同环境以及不同条件下都能正常使用系统。同时系统的界面布局合理，界面导航功能清晰，用户能够在短期培训之后可以轻松使用系统，对于那些有计算机操作基础的用户，可以免培训即可操作本系统。因此，系统操作可行。

3.2功能需求分析

医务室管理系统将使用人员划分为两类，分别是管理员，医师。这些使用者中，管理员的操作权限最大，拥有所有功能的操作权限，其他使用者都是根据工作需要合理的安排部分功能。

（1）管理员功能分析

图3.1展示了管理员用例图。针对管理员角色，系统允许其操作所有的功能，其主要包括管理医师信息，审核器材申请信息，管理器材信息以及器材报废信息，管理患者信息，管理患者的就诊记录信息，管理项目信息，管理药品信息，管理药品出售信息等。

图3.1管理员用例图

（2）医师功能分析

图3.2展示了医师用例图。针对医师角色，系统允许其登录系统之后，可以申请器材，登记器材报废信息，登记药品出售信息，管理患者，管理患者就诊记录信息，查看器材，查看药品信息等。

图3.2医师用例图

3.3非功能性需求

本节将从接口设计要求，可靠性需求，兼容性需求，安全管理要求等七个角度来分析系统在非功能层面上的需求。

（1）性能需求

本系统投入使用之后，不可能只是单一用户操作使用，因此该系统要支持很多个用户的连接，同时也能支持许多用户同时操作本系统。另外借助网络的优势，对本系统的日常运行时间也进行规范，要求系统能够提供7×24小时不间断的服务。

（2）功能操作故障

当系统运行期间，遇到了功能操作上的故障时，系统应该不能受到任何影响，还能继续提供功能服务。

（3）接口设计要求

本系统在接口的设计上一定要规范化设计，在定义接口时要始终遵循使用方便，扩展方便以及很容易让人理解的原则进行开展。同时设计的接口一定要具备完整性特点，具备灵活性以及开放性等特点，毕竟接口在程序的二次开发中，进行系统功能扩展上是非常重要的。

（4）可用性需求

系统的品质需要通过一遍又一遍测试刚开发完成的系统来进行确保，同时在测试中对系统的性能测试也需要严格执行，测试合格的系统才可以在市场上上线使用。

（5）安全管理要求

系统通常是根据不同角色来呈现不同的功能操作界面，所以系统应该严格管理系统的登录功能，对登录的用户不仅需要校验用户输入的账号，密码等数据，也需要识别用户的身份，所有数据匹配的情况下，系统才能引导用户进入其所操作的功能区域。另外，系统也需要记录一些重要操作，形成专门的系统操作日志，供后期管理人员核对检查，确保数据真实可靠。

（6）兼容性需求

本系统在符合使用者常用的操作习惯的前提下，仍然需要按照常用的业内标准来设计出风格统一的界面，在操作方式的设计上也需要使用者能够简单操作。同时，为了系统能够在今后与其他的子系统进行对接，在接口的设计上也许要合符规范，为系统之间能够实现互联互通打下基础。

（7）可靠性需求

系统的可靠性需求表现在系统可利用性以及系统维护时间上面这两方面的需求。从系统可利用性方面来讲，系统应做到7×24小时连续运行，并且，在一年365天内，该系统正常运行的时间应该达到的比率为98%。从系统计划维护服务时间的层面上来讲，当系统出现故障，需要进行维护时，需要避开人们的上班时间，维护服务工作通常在早上九点至下午六点以外的时间段进行。这样才能不影响用户使用系统，保证系统的可靠性。

3.4系统流程

任何一个流程图都是反应了对应事务的处理逻辑，通常都有开始与结束的标识，中间是事务处理的各种逻辑，包括输入的数据以及判断逻辑等信息。

（1）操作流程如图3.4所示。

图3.4 系统操作流程

医务室管理系统的功能是给需要的用户进行使用，所以任何访客在使用系统的功能前，必须通过登录功能提交验证信息，符合条件的用户才可以进入功能处理的界面。

（2）登录流程如图3.5所示。

图3.5 登录流程

医务室管理系统的登录功能的设置可以直接避免无关用户骚扰系统，降低对系统数据泄露的风险。其主要工作流程则是验证用户提交的账号密码，并进行相应的逻辑判断，只有通过登录功能验证机制的用户才可以收到“登录成功”的系统反馈信息。

（3）添加信息流程如图3.6所示。

图3.6 添加信息流程

用户添加数据不仅需要根据医务室管理系统的界面的提示字段填写信息，还要注意已录入数据的合法性，因为系统只会成功提交合法的数据。

（4）删除信息流程如图3.7所示。

图3.7删除信息流程

医务室管理系统经历了长时间使用之后，用户就需要删除无用或重复的数据。系统为了保护这些数据，也为了避免用户的误删现象，每次在删除数据前则会再三提示用户是否确定删除数据。当用户确定之后，系统才会执行数据删除功能。

3.5本章小结

本章主要从系统需求分析进行具体描述，系统的需求分析从可行性分析和功能分析以及非功能性需求分析，进而分析到系统的实现流程。

第4章 系统设计

4.1体系架构设计

医务室管理系统的设计在体系结构模式的选择上还是比较青睐于用户层，功能层和数据层这样的三层结构，俗称B/S结构。这种结构模式在Internet兴起之后，大部分的应用程序都会将其作为首选结构设计模式。

（1）用户层：医务室管理系统的使用人员通常在用户层登录系统，使用系统，对数据的输入和输出进行处理；

（2）功能层：在用户层和数据层的中间，就分布着功能层，功能层主要就是把用户的请求以SQL语句的方式来对数据库进行检索，最终将数据检索的结果传递给用户层；

（3）数据层：数据层主要就是实现对数据库的操作，一般都是增加，修改，删除，查找数据。每当数据层接收到来自上层的数据操作请求时，就会根据该指令去操作数据库，最终反馈给上层执行结果。

4.2系统设计原则

设计系统期间，需要参照以下原则进行，主要包括安全性原则，标准化原则，稳定性原则等。

（1）先进性原则。医务室管理系统无论是体系结构的选择还是技术的选择上应该认真考虑，技术上可以首选当前环境下的先进技术，体系结构上主要采用成熟的设计结构，同时在保持系统技术上的先进性时，对目前市场上的各种操作系统还有各种软件以及硬件环境要充分适应。

（2）标准化原则。医务室管理系统在管理相应数据期间需要符合相应的工作模式，对国家规范软件工程设计方面提出的要求一定要遵守。

（3）实用性原则。本系统以用户的功能需求为核心进行开发，要解决用户需要解决的实质性问题，同时高效完成对各种数据的处理，此外，设计的界面需要满足用户的操作习惯并且界面友好，让用户方便操作本系统。

（4）可扩展性原则。本系统在开发期间应该预留各种接口，方便系统经过长时间使用之后，为了持续满足用户的不断变化的需求而进行系统功能扩展和升级。

（5）稳定性原则。通过各种技术手段的实施让该系统可以承受7×24小时不间断运行，并在长期使用后，对产生的大量数据有较强的存储能力，因此可以对系统的数据库或者系统采用的网络协议以及使用的操作系统等进行规范，让系统可以稳定运行。

（6）安全性原则。对于本系统保存的数据一定要做好保密措施，在保证数据安全不被泄露的同时，也要对外在的黑客攻击等行为进行防范，保证系统安全。

4.3功能结构设计

前面对医务室管理系统的功能需求的分析只是大致的划分功能模块，接下来的工作就是对这些大致的功能进行细分。让医务室管理系统的内容变得更具体，更丰富。

（1）管理员功能结构设计

图4.1展示的是管理员功能结构。系统将管理员的个人中心模块划分为个人信息管理与修改密码子模块，将基础数据管理功能划分为就诊类型管理，科室管理，职称管理，器材类型管理，器材报废类型管理，器材申请类型管理，项目类型管理，药品类型管理子模块。

图4.1管理员功能结构

（2）医师功能结构设计

图4.2展示的是医师功能结构。系统将医师的器材管理模块划分为器材管理，器材申请管理，器材报废管理子模块。

图4.2医师功能结构

4.4数据库设计

数据库的设计是对系统相关数据要求的具体设计。需要对各个对象进行数据类型具体化，比如每个表都要有自己的主键，有些关键性数据不可以直接采用删除操作，只能采用伪装删除的操作，比如专门设置一个字段就是删除标记字段，默认没删除就是0，如果已经删除则设置为1，这样如果有大量数据的删除，只需要更新相关字段的值就行，不需要大量的对磁盘进行删除操作，在性能上面有很大的提升。目前市场上主流的数据库基本上都符合设计的功能需求，但是一切要根据实际出发，首先开发使用的电脑是自己上学用的，那么首选对电脑性能要求没那么高的数据库，其次尽量使用自己曾经学习过的数据库，这样学习成本会降低，时间上就有空余的时间来安排其他事情。本系统通过数据库设计相关的分析，采用MySQL数据库。

4.4.1数据库概念设计

有一个专门用来描述数据库实体与参数之间的图叫做E-R图，E-R是英文缩写，经过多年的传播，已经变成了数据库实体之间联系的专业名字，一般都用缩写E-R图表示，不再采用英文全称。现实世界有很多相关的数据，如何应用到数据库存放就需要进行归类，实体与属性之间的关系不能混淆，一个实体可以有多个属性，一个属性可能对应多个实体，实体和属性之间的关系是需要用图的形式进行描述的，不然不直观。采用Visio画图工具来画E-R图是一种很明智的选择。Visio是专门用来画图的工具之一，内置了很多图形选项，画E-R图用Visio画是正确的，Visio画的图形可以进行保存，复制到其他地方还可以进行编辑，如果缺少某些属性可以直接用Visio打开进行修改，是非常方便的。接下来展示本系统的部分实体图以及实体关系E-R图。

（1）器材申请实体图如图4.4所示。

图4.4 器材申请实体图

（2）医师实体图如图4.5所示。

图4.5 医师实体图

（3）药品出售实体图如图4.6所示。

图4.6 药品出售实体图

（4）管理员实体图如图4.7所示。

图4.7 管理员实体图

（5）实体间关系E-R图如图4.8所示。

图4.8 实体间关系E-R图

4.4.2数据库物理设计

二维表是传统的用来记录相关表与属性之间关系的一种专业图表。表里面每个字段名称都是唯一的，代表当前表的某一个唯一的属性，如果有多个属性，那么就会多几个字段来进行描述。二维表的概念如下：

关键字：每个表建议有且只有一个主键，用来表达数据的专一性和唯一性。也可以通过设定的关键字与其他表进行关联。

元组：二维表显示数据有行与列的关系，行是可以增加的，列是提前设定好的，每一行数据成为元组。

属性：列的名称一般称为属性，也就是字段，比如一个正常人拥有的属性必然有姓名，性别，不管是姓名还是性别，都可以称之为属性。

关系：有列有行只是一张二维表的表达，这张二维表的名称就是行与列的关系，比如用户表，比如有用户账号的属性也就是列，用户的姓名属性也是列，用户属性都有成为元组，很多用户都在这个表里之间的关系成为用户表。

以上内容表示数据之间的关系，通过对数据进行分析和归纳，二维表用来描述和存储相关数据。医务室管理系统数据表设计结果展示如下：

表4.1 患者表

表4.2 就诊记录表

表4.3 器材表

表4.4 器材报废表

表4.5 器材申请表

表4.6 管理员表

表4.7 项目表

表4.8 药品表

表4.9 药品出售表

表4.10 医师表

4.5本章小结

系统设计主要从体系架构设计出发，从系统设计原则到功能结构设计，以及数据库的概念设计和物理设计，都遵循相应的设计原则。

第5章 系统实现

当需要描述系统具体实现的功能点的时候，一方面肯定是要用文字表达实现的功能，另一方面完全可以从系统的具体实现页面把可以用文字描述的操作界面以图片的形式放到文字的下方，这样的表达方式可谓之言之有物，更容易理解系统实现的功能部分。

5.1 管理员功能实现

5.1.1 操作日志管理

 图5.1展示的是操作日志管理界面。

图5.1 操作日志管理界面

此界面展示了操作人所在表，操作账户，操作内容，操作时间等信息。每条操作日志信息的右侧区域都展示了可供管理员选择的操作，包括修改，删除。

5.1.2 器材申请管理

 图5.2展示的是器材申请管理界面。

图5.2 器材申请管理界面

此界面展示了医师提交的器材申请信息，包括医师姓名，器材申请数量，申请状态等信息。每条器材申请信息的右侧区域都展示了可供管理员选择的操作，包括修改，删除，审核等。

5.1.3 器材管理

 图5.3展示的是器材管理界面。

图5.3 器材管理界面

此界面展示了所有的器材信息，包括器材名称，器材库存，器材编号，器材照片等信息。每条器材信息的右侧区域都展示了可供管理员选择的操作，包括修改器材信息，查看器材的详情，删除器材信息等。

5.1.4 药品管理

 图5.4展示的是药品管理界面。

图5.4 药品管理界面

此界面展示了所有的药品信息，包括药品照片，药品名称，药品库存，到期时间，售价等信息。每条药品信息的右侧区域都展示了可供管理员选择的操作，包括删除，修改。同时，在本界面，允许管理员对药品信息进行导入或导出，或者让管理员新增药品信息。

5.1.5 药品出售管理

 图5.5展示的是药品出售管理界面。

图5.5 药品出售管理界面

此界面主要用于展示所有的已经出售的药品信息，包括出售时间，出售金额，利润，出售数量，医师姓名，药品类型等信息。每条药品出售信息的右侧区域都展示了可供管理员选择的操作，包括修改药品出售信息，删除药品出售信息等。

5.1.6 销售金额统计报表

 图5.6展示的是销售金额统计报表界面。

图5.6 销售金额统计报表界面

此界面主要用于展示在管理员设置的统计时间内，所有已经销售的每种药品的利润信息，每种药品都以不同的颜色进行表示，统计结果以饼图的方式进行展示。

5.1.7 医师管理

 图5.7展示的是医师管理界面。

图5.7 医师管理界面

此界面展示了医务室管理系统所有的医师的信息，包括医师姓名，医师手机号，医师性别，科室，职称等信息。每条医师信息的右侧区域都展示了可供管理员选择的操作，包括重置密码，修改，删除。

5.2 医师功能实现

5.2.1 患者管理

 图5.8展示的是患者管理界面。

图5.8 患者管理界面

此界面展示了患者的基本信息，包括患者姓名，患者手机号，患者编号。患者性别，患者邮箱等信息。每条患者信息的右侧区域都展示了可供医师选择的操作，包括修改，删除。

5.2.2 就诊记录管理

 图5.9展示的是就诊记录管理界面。

图5.9 就诊记录管理界面

此界面展示了患者的就诊记录信息，包括就诊时间，就诊类型，患者姓名，医师姓名，就诊记录编号等信息。作为医师，其可以查看患者就诊记录信息的详情，可以修改患者的就诊记录信息，删除患者的就诊记录信息，以及新增患者的就诊记录信息等。

5.2.3 项目管理

 图5.10展示的是项目管理界面。

图5.10 项目管理界面

此界面展示了所有的项目信息，包括项目类型，项目成果，操作时间，就诊记录编号等信息。每条项目信息的右侧区域都展示了可供医师选择的操作，包括修改，删除。

5.2.4 药品出售管理

 图5.11展示的是药品出售管理界面。

图5.11 药品出售管理界面

此界面展示了医师本人已经出售的所有的药品信息，包括药品名称，医师姓名，患者姓名，出售数量，出售金额等信息。作为医师，其每向患者出售药品之后，就需要在本界面登记药品的出售的详细信息。

5.2.5 器材申请管理

 图5.12展示的是器材申请管理界面。

图5.12 器材申请管理界面

此界面展示了医师本人已经提交的器材申请信息，医师申请器材需要医师本人登记并提交申请器材的详细信息，该信息会得到管理员的查看和审核。

5.2.6 器材报废管理

 图5.13展示的是器材报废管理界面。

图5.13 器材报废管理界面

此界面展示了医师本人已经登记的器材报废信息，医师点击界面上端的“新增”按钮就可以登记器材报废信息。器材报废信息包括医师姓名，器材名称，报废数量，报废标题等信息。

5.3 本章小结

本章主要描述系统实现，从管理员和医师两个角色的角度用语言和图片的形式描述可以实现的功能，并且介绍。

第6章 系统测试

6.1测试任务

测试是有一定的任务的，需要把测试的步骤以及想要达到的测试效果都要有提前量的准备。所谓的测试提前量就是根据系统的设定需求，整理出几种不同的测试方案，测试任务的体现要符合操作人的正常操作逻辑顺序，并且要结合测试项目的具体功能，这样才是符合规范的测试任务。测试出的问题多少，代表着程序的完整度的多少。并且每次程序根据测试结果修复完毕会继续进行下一轮的测试，科学的测试能从侧面协助程序的运行出错几率降到最低。

6.2测试目标

测试任务会规定一些具体的测试对象，也就是测试目标。测试虽然是针对性的测试，但是目标一般是不会进行变更的，不管是什么样子的测试目标都是为了测试目标的编码实现。编码实现过程中，程序开发人员毕竟不是整个程序都是一个人开发的，可能为了实现自己写的某个功能会忽略某些特殊的参数之类的，或者某些功能都不是一个人进行开发的，这样出现问题的几率也比较大，再加上加班加点的编码，可能会出现一些低级的错误，毕竟人为的编码毕竟会出现疲劳。所以会从功能，性能，等各个环节来验证程序的编码问题。

6.3测试方案

本系统的测试方案有模块测试，集成测试以及验收测试。

1.模块测试

单元测试也叫模块测试，主要检测数据在某个模块内的测试或者某个数据流在另一个模块之间的引用测试是否会出现异常。一般模块测试会从下面几个方向来进行测试。

（1）路径测试问题：不管是什么样的程序，不管是数据还是文件，其实只要是在硬盘中都有其位置，也就是是说不管是操作系统还是其他，其实都是文件的集合，既然是文件的集合，那么就会出现路径问题。操作系统对文件的路径有一定的规范，并且对文件属性也有规范，比如路径下面的权限问题，可以对某个文件夹或者文件设置只读或者不可以操作，如果程序的功能有这方面的需求，需要在某个文件里面存储或者操作某些文件，就不可避免要测试路径问题，检查上传文件是否真正把文件写入到指定的目录里面，有权限操作还是没有权限操作，是相对路径还是绝对路径，这些都要进行路径测试。

（2）接口测试问题：每个功能模块之间的接口是否有重复的，是否是唯一的，这些也需要进行测试，举个简单的例子，用户登录的接口与管理员登录的接口是否不一样，如果一样，如何区分，如果不一样，是否引用的有问题，如果管理员账号和用户账号都一样的存在，那么互相登录是否会出现异常还是不会出现异常，这些都需要进行接口测试。

（3）数据结构问题：数据问题主要体现在数据库数据类型与编码语言类型直接的包装盒转换以及计算方面。

（4）异常处理问题：所谓的异常处理问题其实很好理解，用户登录成功和登录失败，其实就是把用户登录的账号和密码进行提交与数据库里面查询相关表里面的内容进行数据比较，那么只会出现两种情况，一种是没有符合的数据，一种是符合的数据。如果查询到符合的数据就提示登录成功即可，如果没有查询到数据就提示登录失败，具体失败的原因是账号还是密码，这个根据异常来进行编辑即可。

（5）边界测试问题：数据分类型，还分数据量的大小，那么就是检测输入的数据最大量和最小量。如果超出设定的最大量就必须要求用户输入合法数据，不能让用户输入超出数据边界的操作还能进行提交，如果不这样，会出现更多的问题。

模块测试是必不可少的，也是不可忽略的环节之一。

2.集成测试

模块测试之后就是集成测试的开始，集成测试会跳过模块测试，专门针对模块之间的联系进行测试，只要是某个数据相关联的模块都要进行测试，这样一个数据的整个流程都测试一遍，才能确定程序开发是否符合需求。渐进式测试是集成测试的一种方式。

优点一：采用数据的生成，以及数据的流通，一站式测试，能更彻底的测试数据之间的逻辑和调用。

优点二：节省时间和成本，能更好的发现是哪个环节的问题。

优点三：更快的反馈并且处理问题。

用渐进式的测试必用混合法，也就是从上到下的测试或者从下到上的测试，从程序的任何一点逻辑进行测试都能测试环节的正义性。这就是集成测试。

3.验收测试

验收测试一般是最后的测试环节了。甲方委托相关人员来进行测试，一般交付之前的必要测试环节，因为甲方不参与具体开发步骤，只是讨论相关需求，而需求只是代表着甲方对于一些必要性必须实现的功能流程的要求，也许在测试环节会提出一些不符合程序开发流程的操作，这些也都是有可能的，毕竟一个需求的设定，编码都是根据这个需求进行编写的，如果更改需求那么就需要重新编码，所以验收测试有时候不代表编码问题，很有可能是需求改变导致的问题。一般经过各项科学测试之后的程序出现的问题很小。

6.4功能测试

系统的功能不仅需要在使用者使用中发挥其价值，并且对一些使用者的错误操作，系统也会及时提醒。如此系统才可以获取使用者的信任。

（1）登录功能测试

表6.1为管理员登录功能测试表。检测此功能主要有两项重要内容，一个是账号，另一个是密码。账号和密码一定要相互匹配才能操作成功。

表6.1 管理员登录功能测试表

（2）修改密码功能测试

表6.2为修改密码功能测试表。成功修改密码的前提条件就是对旧密码一定要正确输入，否则，使用者将操作失败。

表6.2 修改密码功能测试表

6.5系统测试结果

经过科学的系统测试环节，医务室管理系统各项指标符合设计预期，同时在操作性和容易维护方面做的也不错，可以投入生产。

6.6本章小结

本章系统测试，从测试任务，目标，方案都详细进行了描述，对功能测试和系统测试结果描述了关键部分。

第7章 总结和展望

7.1 总结

此次我选择的毕业课题是研究和实现一个医务室管理系统，为了完成医务室管理系统的开发任务，我进行了一系列和课题相关的开发工作。在最初，通过资料查找和分析，大体了解了开发医务室管理系统的流程，先确定系统的开发技术，即运用成熟，安全，高效的面向对象的编程语言Java进行功能上的代码编写，同时采用可以保存上千条数据，支持快速查询数据，管理数据，优化数据的MySQL数据库管理工具来保存医务室管理系统的数据。紧接着把大量精力都用在系统的功能划分，设计系统方案，实现系统功能的工作上。医务室管理系统的开发主要是为了方便使用者管理数据，运用数据，因此其实现的功能主要有操作日志管理，器材管理，器材申请管理，器材报废管理，患者管理，就诊记录管理，项目管理，药品管理，药品出售管理，医师管理等功能。待系统开发并通过检测阶段之后，就可以真正交付用户使用。

通过本次课题，我对开发工具的使用能力提升了很多，比如学会了如何使用IDEA工具，如何使用MySQL设计数据表，如何部署服务器等知识。同时因为应用的编程语言是Java，让我加深了对该语言的认识和理解，发现了很多我之前没有发现的Java语言的特点。总之，这个课题的完成，让我对开发一个项目的经验还是有所积累，对毕业课题与商业项目的认识以及它们之间的区别还是有所提升。相信这些宝贵的知识点会让我受益终身。

7.2 展望

时代在不断变化，信息也在不断整合，人们的需求也在变化，因此，开发的医务室管理系统只是符合当前使用者的需求，但是该系统也需要跟随时间的变化去迎合使用者更多的变化的需求。所以，系统开发期间已经预留了一些可供功能扩展的接口，可以通过这些接口和相应的代码注释去升级系统。尽管医务室管理系统已经结束了开发工作，但还是存在数据库数据重复存储，后台代码重复编写以及界面图片太繁琐等缺点。这些问题还是需要在未来的时间里面去改进，先针对性的学习一些新知识，然后针对性的去完善医务室管理系统才是正确的选择。

参考文献

[1]陈和生.高校医务室信息管理系统的设计与实现探析[J].科学咨询(教育科研),2019,(04):46.

[2]朱珍.高校医务室信息管理系统的设计与实现[J].电脑知识与技术,2018,14(11):23-24.

[3]焦宇,李民,王欢,余开朝.基于MySQL性能调优的推荐系统优化设计[J].软件导刊,2022,21(09):108-112.

[4]郑戟明,董云朝,柳青.MySQL数据库数据导入导出方法的探讨[J].电脑知识与技术,2022,18(22):24-25.

[5]欧阳桂秀.基于Java和MySQL的数据库管理系统的设计与实现[J].信息记录材料,2022,23(09):240-242.

[6]郑歆.Java程序设计课程的教学实践[J].集成电路应用,2022,39(11):94-95.

[7]李乐.Java语言应用研究[J].智慧中国,2022,(09):80-81.

[8]仓业金.基于Java的软件保护技术研究[J].电脑知识与技术,2022,18(23):29-30+52.

[9]宋旸.使用Java语言开发Web应用软件的知识探讨[J].中国设备工程,2022,(14):121-123.

[10]唐小玲. Spring Boot代码自动生成系统设计[J]. 信息技术与信息化,2023,(01):77-80.

[11]王悦. 基于Spring Boot技术的SOA接口研究[J]. 信息技术,2019,43(06):140-143+148.

[12]江雁. 浅谈Spring Boot框架下如何快速进行后台开发[J]. 海峡科技与产业,2019,(02):131-132.

[13]谢志坚.计算机应用软件开发技术支撑思考[J].电子世界,2020(15):53-54.

[14]姬晓鹏.计算机软件开发技术与设计探究[J].电子测试,2020(16):133-134.

[15]Raffi Khatchadourian.Automated refactoring of legacy Java software to enumerated types[J].Automated Software Engineering,2017,24(4).

[16]Ben White.Marx and Chayanov at the margins:understanding agrarian change in Java[J].The Journal of Peasant Studies,2018,45(5-6).

致  谢

 从刚来大学时，对系统开发，系统分析设计一窍不通，到最后毕业时，能够自己完成所选的毕业课题，自己开发系统，撰写论文，我觉得我这四年在大学校园里成长了很多，因此，我要对我的大学校园提供的学习环境还有教授我知识的老师表示感谢。

从拿到毕业课题开始，我一直是一头雾水，不知从何做起，幸好我遇到一位好导师，他帮助我分析我所选课题的侧重点以及需要花大量精力攻克的技术难点，以及在我遇到我自己觉得解决不了的问题时，我的导师一步步指导我寻找到了正确的解决办法，导师的耐心指导才让我在毕业课题的完成上顺利进展。所以，感谢导师！

完成毕业课题的时间很长，在这漫长的时间内，我也曾消极抵抗过面临的种种困难，而让我重新鼓起勇气，开始认真对待毕业课题，这样的态度转变则是多亏了我的室友为我加油打气，他跟我一样，虽然也焦虑撰写论文，以及如何开发系统等问题，但是他的乐观和积极向上的态度打动了我，至少人家焦虑的同时，还在坚持不懈的寻找解决办法，还在向周边朋友，老师等寻求帮助，更重要的是，我的室友还拉着我一起思考问题，分析问题。所以，遇到这样的好室友，我真的很庆幸，感谢这位好室友！

回想完成毕业课题所经历的各个阶段，我不由得感慨自己在大学期间所学知识的不足，尽管设计的作品也用到一些知识点，但大部分知识还需要自己通过查找资料，询问老师和同学去弥补，所以我明白知识的无止境，尽管毕业了，以后不会在校园里学习知识，但是进入社会还是需要保持一颗学习的心，不断让新的知识充实自己，让自己不断成长！

核心代码展示

/**
 * 公告通知
 * 后端接口
 * @author 
 * @email 
 * @date 2021-03-09 11:33:59
 */
@RestController
@RequestMapping("/news")
public class NewsController {
    @Autowired
    private NewsService newsService;
    


    /**
     * 后端列表
     */
    @RequestMapping("/page")
    public R page(@RequestParam Map<String, Object> params,NewsEntity news, HttpServletRequest request){
        EntityWrapper<NewsEntity> ew = new EntityWrapper<NewsEntity>();
		PageUtils page = newsService.queryPage(params, MPUtil.sort(MPUtil.between(MPUtil.likeOrEq(ew, news), params), params));

        return R.ok().put("data", page);
    }
    
    /**
     * 前端列表
     */
	@IgnoreAuth
    @RequestMapping("/list")
    public R list(@RequestParam Map<String, Object> params,NewsEntity news, HttpServletRequest request){
        EntityWrapper<NewsEntity> ew = new EntityWrapper<NewsEntity>();
		PageUtils page = newsService.queryPage(params, MPUtil.sort(MPUtil.between(MPUtil.likeOrEq(ew, news), params), params));
        return R.ok().put("data", page);
    }

	/**
     * 列表
     */
    @RequestMapping("/lists")
    public R list( NewsEntity news){
       	EntityWrapper<NewsEntity> ew = new EntityWrapper<NewsEntity>();
      	ew.allEq(MPUtil.allEQMapPre( news, "news")); 
        return R.ok().put("data", newsService.selectListView(ew));
    }

	 /**
     * 查询
     */
    @RequestMapping("/query")
    public R query(NewsEntity news){
        EntityWrapper< NewsEntity> ew = new EntityWrapper< NewsEntity>();
 		ew.allEq(MPUtil.allEQMapPre( news, "news")); 
		NewsView newsView =  newsService.selectView(ew);
		return R.ok("查询公告通知成功").put("data", newsView);
    }
	
    /**
     * 后端详情
     */
    @RequestMapping("/info/{id}")
    public R info(@PathVariable("id") Long id){
        NewsEntity news = newsService.selectById(id);
        return R.ok().put("data", news);
    }

    /**
     * 前端详情
     */
	@IgnoreAuth
    @RequestMapping("/detail/{id}")
    public R detail(@PathVariable("id") Long id){
        NewsEntity news = newsService.selectById(id);
        return R.ok().put("data", news);
    }
    



    /**
     * 后端保存
     */
    @RequestMapping("/save")
    public R save(@RequestBody NewsEntity news, HttpServletRequest request){
    	news.setId(new Date().getTime()+new Double(Math.floor(Math.random()*1000)).longValue());
    	//ValidatorUtils.validateEntity(news);
        newsService.insert(news);
        return R.ok();
    }
    
    /**
     * 前端保存
     */
    @RequestMapping("/add")
    public R add(@RequestBody NewsEntity news, HttpServletRequest request){
    	news.setId(new Date().getTime()+new Double(Math.floor(Math.random()*1000)).longValue());
    	//ValidatorUtils.validateEntity(news);
        newsService.insert(news);
        return R.ok();
    }

    /**
     * 修改
     */
    @RequestMapping("/update")
    public R update(@RequestBody NewsEntity news, HttpServletRequest request){
        //ValidatorUtils.validateEntity(news);
        newsService.updateById(news);//全部更新
        return R.ok();
    }
    

    /**
     * 删除
     */
    @RequestMapping("/delete")
    public R delete(@RequestBody Long[] ids){
        newsService.deleteBatchIds(Arrays.asList(ids));
        return R.ok();
    }
    
    /**
     * 提醒接口
     */
	@RequestMapping("/remind/{columnName}/{type}")
	public R remindCount(@PathVariable("columnName") String columnName, HttpServletRequest request, 
						 @PathVariable("type") String type,@RequestParam Map<String, Object> map) {
		map.put("column", columnName);
		map.put("type", type);
		
		if(type.equals("2")) {
			SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd");
			Calendar c = Calendar.getInstance();
			Date remindStartDate = null;
			Date remindEndDate = null;
			if(map.get("remindstart")!=null) {
				Integer remindStart = Integer.parseInt(map.get("remindstart").toString());
				c.setTime(new Date()); 
				c.add(Calendar.DAY_OF_MONTH,remindStart);
				remindStartDate = c.getTime();
				map.put("remindstart", sdf.format(remindStartDate));
			}
			if(map.get("remindend")!=null) {
				Integer remindEnd = Integer.parseInt(map.get("remindend").toString());
				c.setTime(new Date());
				c.add(Calendar.DAY_OF_MONTH,remindEnd);
				remindEndDate = c.getTime();
				map.put("remindend", sdf.format(remindEndDate));
			}
		}
		
		Wrapper<NewsEntity> wrapper = new EntityWrapper<NewsEntity>();
		if(map.get("remindstart")!=null) {
			wrapper.ge(columnName, map.get("remindstart"));
		}
		if(map.get("remindend")!=null) {
			wrapper.le(columnName, map.get("remindend"));
		}


		int count = newsService.selectCount(wrapper);
		return R.ok().put("count", count);
	}
	


}