需求分析的首要任务是要分析用户的需求，知道用户存在的一些情况，并且要明确用户的使用状况，然后设计规划解决的问题。其中在使用定性的分析以及定量的分析，从这两个方面获取用户的需求。一方面定性的分析获得的应该是用户的基本需求，能够发现现在人们的习惯要求。所以定性的需要主要是为了多与用户交流，从而更为深刻的了解一些存在的需求问题；定量的分析则是发现一些潜在的用户，并且获得不一样的反馈内容。所以定量的需求要让用户来阐述一些情况，一定让使用者清晰的进行客观的描述，这样才能够比较全面的获得用户的需求所在[8]。

其中获得用户需求以后，就要可以将用户需求设计为系统的功能模块。在能及时的分析和发现有关需求的情况下，需要系统同时的跟进需求设计。在医护系统过程中还需要创建需求工作的数据分析，以便于后面的分析做总结[9]。写入一个需求的报告内容，其中需要包含完整的描述需求、以及功能需求、模型等后续开发过程中还需要用到的部分资料。

需求的分析中用户需求就是比较的重要，而且可以通过各种的路径，以及各用户对于系统的功能需求，你需要对这些内容做出整理以及分类，然后分析这些需求的现实情况下的可能原因，还需要有认真的分析过程，结合现实的情况下最终做出一系列的需求资料。在有关用户的期望分析中能够明确一些可能实现的情况，医护系统功能是许多个可以测试的功能相结合的，正是由于这些功能可以使得用户能够更加积极的提供出需求，让系统功能可以变得更加的完善。这样就可以保证所有设计的功能模块都是可以用到的，而且也是可测试的，对于后续系统的开发能够有比较关键的作用，也能快速完成用户所提供的需求[10]。

功能需求分析 

医护系统的设计与实现是以医护的状况为起点，综合网络空间开发设计要求。目的是将医护系统通过网络平台变换为在网上操作，完成医护系统的方便快捷、安全性、规范做了保障，目标明确。

这一系统可以分成三种类别的用例实体模型，分别是用户、医生和管理员。这三个角色的作用将在下面详解和叙述。

(1)用户

主要使用者为用户。具备有首页、个人中心、在线问诊管理、药方信息管理功能。用户用例图如图3-1所示。

图3-1 用户用例图

(2)管理员

进行维护，以及平台的后台管理工作都依靠管理员，其可以对信息进行管理。需具备功能有；首页、个人中心、医生管理、用户管理、在线问诊管理、疾病类型管理、医疗信息管理、药方信息管理、交流论坛、系统管理。管理员用例图如图3-2所示。

      图3-2 管理员用例图

(3)医生

使用者包括医生，具备有：首页、个人中心、在线问诊管理、药方信息管理。医生用例图如图3-3所示。

图3-3医生用例图

流程图是用具体的图形符号和相应的线条来表示系统执行的整个过程。因为这种图可以很容易地描述系统的一系列过程，所以它的所有图形符号都是比较关键的，基本上一个图形符号可以表示一个过程的一个步骤。流程图不仅提供了一个比较完整、全面的实施过程，而且可以发现整个团队协同设计过程中可能存在的缺陷和不足，便于在后续过程中及时对系统进行修正和改进。

通过流程图可以对系统的需求和相关流程进行分析，可以详细细分为各个部分的设计。对于设计人员来说在开发过程中要能够以流程图为基础，能够快速的提高自己的逻辑思维，并且也能够指导后续的操作在系统设计中最重要的部分就是程序的设计，然后具体的编写程序，流程图是设计过程中的重要工具，下面是流程图的部分设计。

登录流程是该系统的第一个流程，登录的第一步是输入账号、密码登录，系统会验证账号与密码是否正确，正确时系统会判断账号类型再进入不同的后台；不正确时，会返回到登录的第一步，输入用户重新执行登录流程。该流程如图3-4所示。

图3-4登录流程图

添加新用户的流程是先查询新用户名是否已存在，如已有该用户名，需重拟用户名并同时输入新用户的其它信息，添加新用户到数据库时会先验证数据是否完整，信息都正确且完整时，返回并刷新用户列表；信息不正确时，会返回输入信息的那一步。该流程如图3-5所示。

图3-5添加新用户流程图

设计原理，是指一个系统的设计由来，其将需求合理拆解成功能，抽象的描述系统的模块，以模块下的功能。功能模块化后，变成可组合、可拆解的单元，在设计时，会将所有信息分解存储在各个表中，界面不会显示所有定义的字段。在设计时，会有几大要求，抽象、模块化、信息隐藏、耦合低、内聚等特性，本系统的设计也符合以上几大特性。制作和显示流程都属于程序员需要分析研究的一部分。每个模块都是相对独立的，系统前台不显示账号操作权限范围外的信息。

E-R图即实体-联系图，主要作用是提供了解显示数据类型存在的联系的途径，是藐视现实世界的概念模型，其关键要素是实体型、属性、联系。以下是本系统主要的E-R图如下所示。

用户信息E-R如图4-2所示。

图4-2 用户信息E-R图

医疗信息E-R如图4-3所示。

图4-3医疗信息实体图

在线问诊E-R如图4-4所示。

图4-4在线问诊E-R图

医生信息E-R如图4-5所示。

图4-5医生信息实体图

                                    系统功能实现

5.1前台系统功能的实现

当游客打开系统的网址后，首先看到的就是首页界面。在这里，游客能够看到医护系统的设计与实现的导航条显示首页、医生、医疗信息、交流论坛、系统公告、个人中心。系统首页界面如图5-1所示：

图5-1 系统首页界面

在系统首页点击左边的注册/登录按钮，然后页面跳转到注册登录界面，后来输入信息完成后，单击注册或者登录操作，如图5-2所示：

图5-2 用户注册、用户登录界面

用户点击医生，在医生页面的搜索栏输入医生工号、医生姓名、所属医院等信息，进行查询，还可以查看医生工号、医生姓名、职称、主治方向、性别、医龄、联系电话、头像、坐诊时间、所属医院，如有需要可以收藏等操作；如图5-3所示：

图5-3医生页面

用户点击医疗信息，在医疗信息页面的搜索栏输入疾病名称、疾病类型、传染性等信息，进行查询，还可以查看疾病名称、疾病类型、传染性、封面、高发月份、高发人群、点击次数，如有需要可以收藏等操作；如图5-4所示：

图5-4医疗信息页面

在个人中心页面可以输入用户名、姓名、密码、性别、联系电话、头像等信息，进行信息更新，还可以对我的发布、我的收藏进行详细操作，如图5-5所示：

图5-5 个人中心界面

5.2 后台管理员功能的实现

管理员登录，通过登录页面填写用户名和密码、角色等信息，点击登录操作，如图5-6所示。

图5-6管理员登录界面图

管理员登录进入系统可以查看首页、个人中心、医生管理、用户管理、在线问诊管理、疾病类型管理、医疗信息管理、药方信息管理、交流论坛、系统管理等功能，进行详细操作，如图5-7所示。

图5-7管理员功能界面图

管理员点击用户管理；在用户管理页面输入用户名、姓名、性别、联系电话、头像等信息，进行查询，新增或删除用户信息等操作；如图5-8所示。

图5-8用户管理界面图

管理员点击医生管理；在医生管理页面输入医生工号、医生姓名、职称、主治方向、性别、医龄、联系电话、头像、坐诊时间、所属医院等信息，进行查询，新增或删除医生信息等操作；如图5-9所示。

图5-9医生管理界面图

管理员点击在线问诊管理；在在线问诊管理页面输入医生工号、医生姓名、用户名、姓名、联系电话、问诊时间、回复内容等信息，进行查询或新增、删除在线问诊等操作；如图5-10所示。

图5-10在线问诊管理界面图

管理员点击疾病类型管理；在疾病类型管理页面对疾病类型等信息，进行查询或删除疾病类型等操作；如图5-11所示。

图5-11疾病类型管理界面图

管理员点击医疗信息管理；在医疗信息管理页面对疾病名称、疾病类型、传染性、封面、高发月份、高发人群等信息，进行查询或删除医疗信息等操作；如图5-12所示。

图5-12医疗信息管理界面图

5.3 后台医生功能的实现

医生登录，通过登录页面填写信息完成后，点击登录操作，如图5-13所示。

图5-13医生登录界面图

医生登录到医护系统的设计与实现可以查看首页、个人中心、在线问诊管理、药方信息管理等信息，进行相应操作，如图5-14所示。

图5-14医生功能界面图

5.4 后台用户功能的实现

用户登录，通过登录页面填写信息完成后，点击登录操作，如图5-15所示。

图5-15用户登录界面图

用户登录到医护系统的设计与实现可以查看首页、个人中心、在线问诊管理、药方信息管理等信息，进行相应操作，如图5-16所示。

图5-16用户功能界面图

系统测试

测试是为了发现问题，而不是证明程序没有问题。测试是可编写测试用例来描述测试的步骤、预想的界面或效果与实际的差距，来验证程序是否正确。测试的原则有几条，测试需要输入条件和输出结果，制定测试用例来规范测试的步骤，也会适当的推进测试的进度。正常的测试流程是从项目立项开始，就可按需求先写测试用例，与程序开发同步进行，等程序开发完成，测试用例也可同时完成，等程序开发交接到测试时，可直接展开测试工作[13]。

系统测试用例

性能测试是指通过自动化测试工具模拟系统在不同负载和压力情况下，观察平均响应时间、CPU占用率和内存占用率等性能评价指标的变化情况，以检验系统性能是否能达到预期目标，确保平台上线后稳定运行。

本文采用开源的测试工具JMeter模拟用户对平台API网关的并发请求行为，并发量从200开始逐渐递增，利用JMeter自带的监听器与插件记录平均响应时间、CPU占用率和内存占用率等性能评价指标，具体测试结果如表6.1所示。

表6.1 API网关性能测试结果

由测试结果可知，在系统并发量逐渐递增到1200的过程中，平均响应时间控制在1.5秒内，异常率保持为0%，响应失败率小于5%}  CPU占用率小于80%，内存占用率小于95%，达到了预期的性能目标。当并发量达到1400时，有一部分请求出现异常，各项性能指标也超出以上标准，说明目前系统在1400并发请求时达到了性能瓶颈。