医院管理住院系统

 

1 项目简介

 

1.1 项目背景

 

医院管理住院系统是当今大部分现代化医院所具备的一个系统，它和医院紧密的联系在一起。由于它的实现，大大的方便了医院的管理，并且为医生和病人提供了很大的便利，缩短了病人求医的时间，为病人和医生之间快速的建立联系提供了一种保障。但是在一些医院，还没有这样的系统，医生、病人和医院之间的关系比较独立，这就大大的影响了医院的效率，给医院的长久发展带来了很不利的因素。

 

1.2 意义

 

近年来医疗行业不断发展，医院规模不断增加。在经济全球化的影响下，我国医疗行业不断借鉴外来经验，不断创新医院的运营模式，改善医院的管理体制，取得了良好的社会反映，发展速度不断加快，给人们的生活带来了很大的便利。

 

医院服务质量和治疗水平的高低，直接影响现代化医院的发展。对于一所现代化的医院，能否全面系统满足病人的需求，如对服务态度，时间安排，治疗水平等的要求是患者选择医院的主要标准。本课题将对医院中的病人管理、医生管理、收费管理和病床管理等方面进行探讨和研究，将现代化医院信息管理系统作为医院管理的核心平台，其管理信息内容作为研究材料与基础。通过此次研究与探讨，主要目的在于目标系统的运用能够全面快速满足病人和医生的需求，为病人提供多方面的便捷。提高医院运行效率，节约病人的时间，减少病人不必要开支。通过目标系统，联系管理者与被管理者，不断反应问题同时可以积极有效解决问题，提高服务质量。利用目标系统带来的收益是多面的，具体表现如下：

 

（1）间接性：利用目标系统，减少人力物力的不必要投入，而非通过计算机信息化系统直接实现经济效益。

 

（2）持久性：目标系统的建立需要投入巨额资金，但并不能收回资金。

 

（3）效益性：医院利用目标系统首先可以满足病人的需求，还能打造良好的现代化医院形象。

 

本课题根据实际需要而产生，为了解决人工计算操作的弊端，开发一套医院管理系统势在必行。本系统的开发主要是根据实际需要而制作，系统整体包括：医生管理模块，病床管理模块，病人管理模块，收费信息管理模块，统计分析模块等功能模块。

 

1.3 必要性论证

 

提高医院工作效率：通过自动化和数字化的医院管理系统，可以显著提高医院的工作效率。系统能够帮助医生和护士快速访问患者信息，减少了手工记录和查询的时间。

 

增强病人体验：系统提供的快速和准确的服务能够改善患者的整体体验。例如，通过系统快速查找自己的治疗信息、病床分配和费用明细，减少了患者等待时间和可能的焦虑。

 

错误减少和数据准确性：电子化记录减少了手写记录的错误。同时，系统可以为医生和护士提供实时的、准确的医疗数据，从而提高治疗的准确性和安全性。

 

资源优化和成本管理：系统能够有效管理医院资源，如病床分配和药品库存管理，从而提高资源利用率。此外，通过准确的费用管理和统计分析，医院可以更好地控制成本和优化预算分配。

 

1.4 可行性论证

 

用户的要求和系统调研是进行系统可行性分析的基础，对将要开发的系统从经济、技术、运行等方面进行全面分析，并得出系统的开发工作能否可行，最后完成可行性分析。

 

1、经济可行性

 

经济预算是系统开发的前提工作中非常重要的部分，以本系统为例，在投入运营之前，本项目始终处于投资阶段，但投资并不大，整个项目的开发都独自完成。与此同时，当今计算机普及率较高，人们的技术水平也较高，如果本系统能够投入实际的使用，则所需的相关准备和培训人员的费用相对较少，但在它投入使用后，将节省大量的人力物力，使原来从事这方面工作的人员可以投入到更为实际的工作中去，提高管理部门的工作效率。所以综上所述，本系统的开发在经济方面是比较可行的。

 

2、技术可行性

 

技术可行性分析其主旨就是确保能够充分利用现有的技术条件，契合开发者的实际需求完成软硬件的开发及配置工作，明确技术人员专业能力等客观因素。网络技术的优势主要体现在：可靠的准确度；较快的传输速度。总之在科学技术飞速发展的今天，有利的推进了系统的发展。就技术层而言，本系统具有较高的可行性。

 

3、操作可行性

 

当今人们对计算机的操作已愈加成熟，对电脑的操作有一定基础，且本系统的操作性不算太复杂，通过简单的键盘输入以及鼠标点击即可完成相应的任务，简单培训以后立马上手，而且本系统可视性非常好，即本系统在操作上不会有太大难度。

 

4、时间可行性

 

从时间上看，在四年时间内学习了大量关于这方面的知识，尽管只是有些遗忘，而且需要在两个月内开发成此系统，但是通过查询相关知识，联系起以前学习的知识，通过这段时间的努力一定可以实现。

 

5、法律可行性

 

① 所有技术资料都为合法。

 

② 在开发过程中，完全不存在任何关于知识产权的问题。

 

③ 不侵犯版权，没有抄袭任何系统。

 

④ 在开发过程中，完全不涉及任何的法律问题，不会担负任何的法律责任。

 

根据以上分析，本系统在各个方面都是可以执行实现的。

 

1.5 过程模型

 

敏捷开发

 

描述：敏捷开发强调快速迭代和适应性强的开发过程。它倡导持续交付、跨职能团队合作和客户反馈。

 

适用性：适用于需求频繁变更或不完全明确的项目。如果医院系统需要快速响应市场和技术变化，敏捷模型可能更合适。

 

优点：灵活性强，能快速适应需求变化，增强客户满意度。

 

缺点：可能缺乏明确的项目方向，且难以预测最终成本和完成时间。

 

2 需求分析

 

2.1 客户需求

 

经过对本系统的研究分析，本系统主要是为了方便让医院更快捷的管理。所面向的对象主要有病人、医生和医院的管理人员。病人运用该系统后，可以根据该系统查看自己所需要的信息，包括治疗自己病症的医生的信息、病床信息、收费信息等。医生运用该系统后，可以根据该系统查看自己病人的信息。而医院管理人员通过该系统可以查看病床利用率和收费明细的情况。^[3]

 

根据面向对象的需求的不同，可以分析出本系统需要的主要功能有：登录、医生信息管理、病人信息管理、收费信息管理、病床信息管理、统计分析管理和系统管理

 

2.2 客户需求分析

 

2.2.1  系统性能需求

 

响应时间尽量短，结果准确。一般业务操作时间在3到5秒，添加以及修改报表时间不超过30到45秒。对于多用户并发访问的问题，系统通过先进缓存技术而解决了相应的问题。

 

 

 

2.2.2  系统安全性需求

 

    

 

    由于医院管理住院系统是基于MVC模式以B/S框架而开发的Web应用，根据用户的确切使用要求以及系统的使用目的分析，医院管理住院系统在安全性方面有着很高的要求。因此医院管理住院系统对系统安全性要求尤为严格。

 

为了保证管理员可以登录本系统进行具体的操作，设立了登录信息界面，在账号与密码相匹配的情况下才可以进入系统进行实质的操作。

 

 

 

2.2.3  系统设计需求

 

 

 

为了达到标准、规范等目标，从而提高软件的复用率，在进行系统设计时，需做到如下。

 

    1. 底层数据统一。对于底层数据采用标准的数据进行设置，对底部对于不符合规范的数据及时进行数据清洗和规范化操作，使得不同的数据资源统一在统一的数据格式之下，达到方便查询存储的效果。

 

    2.界面风格的统一。采用统一的主题模式，不同页面会有不同的应用需求，其界面主题保持基本一致，促进组织采用树形结构，方便数据的浏览和查询。

 

    3.数据服务化。系统中各功能模块既独立，又相互关联，在模块化的同时保证各个功能合理配置。同时预留开放接口，能够适应系统的扩展需求。

 

2.3 产品需求定义

 

2.3.1功能需求

 

经过对本系统的研究分析，本系统主要是为了方便让医院更快捷的管理。所面向的对象主要有病人、医生和医院的管理人员。病人运用该系统后，可以根据该系统查看自己所需要的信息，包括治疗自己病症的医生的信息、病床信息、收费信息等。医生运用该系统后，可以根据该系统查看自己病人的信息。而医院管理人员通过该系统可以查看病床利用率和收费明细的情况。^[3]

 

根据面向对象的需求的不同，可以分析出本系统需要的主要功能有：登录、医生信息管理、病人信息管理、收费信息管理、病床信息管理、统计分析管理和系统管理。

 

2.3.2系统层次结构图

 

该系统主要是医生和病人通过该系统，对整个医院的病床、医生、病人和消费信息进行查看，根据自己的需要进行选择。系统层次结构图如图3-1所示： 

 

 

 

图2-1 系统层次结构图

 

       医院管理系统包括如下功能：

 

l 医生管理

 

业务描述：管理医生信息、包括对医生信息的增加、删除、修改

 

l 病人管理

 

业务描述：管理病人信息、包括对病人信息的增加、删除、修改

 

l 病床管理

 

业务描述：管理病床信息、包括对病床信息的增加、删除、修改

 

l 收费管理

 

业务描述：管理收费信息、包括对收费信息的增加、删除、修改

 

l 统计分析

 

业务描述：病床利用率查询主要是通过对科别、医师和日期的搜索，收费明细查询主要是通过对病人姓名和日期的搜索，来进行对其相对应信息的查询。

 

l 修改密码

 

业务描述：用户可以修改自己的系统登录密码

 

 

 

2.3.3医生信息管理

 

 

 

医生信息管理主要是通过对医生姓名的搜索，来对医生信息进行查询，其中查询的内容包括医生的编号、性别、职称、职务、科别、出生日期和工作日期，还可以对医生信息进行添加、修改、删除。

 

 

 

 

 

图2-2 医生信息管理结构图

 

2.3.4病床信息管理

 

病床信息管理主要是对病床的所属科别、病床号、床位费和使用状态进行查     看，还可以对病床进行添加、修改和删除。             

 

 

 

 

 

图2-3 病床信息管理结构图

 

2.3.5病人信息管理

 

病人信息管理主要是通过对病人姓名的搜索，来对病人信息进行查询，其中   查询的内容包括病人的科别、病床号、性别、年龄、病症、主治医生、入院和出院日期，还可以对病人信息进行添加、修改和删除。

 

 

 

图2-4 病人信息管理结构图

 

2.3.6收费信息管理

 

收费信息管理主要是通过对病人姓名的搜素，来进行对其收费信息的查询，其中查询的内容包括病人的科别、病床号、收费项目、单价、数量、金额和日期，还可以对收费信息进行添加、修改和删除。

 

 

 

 

 

 

 

图2-7 收费信息管理结构图

 

2.3.7统计分析管理

 

统计分析管理其中包括病床利用率查询和收费明细查询，其中病床利用率查询主要是通过对科别、医师和日期的搜索，来进行对其相对应信息的查询，查询的内容包括科别、病床号、病人性别、病人姓名、病人年龄、主治医生、入院日期和出院日期等；收费明细查询主要是通过对病人姓名和日期的搜索，来进行对其相对应信息的查询，查询的内容包括科别、病人姓名、病床号、收费项目、数量、单价和金额。

 

 

 

图2-6 统计分析管理结构图

 

2.3.8系统管理

 

 

 

系统管理其中包括修改密码和退出系统，修改密码的方法是首先是输入原密码，然后输入新密码，最后确认新密码。

 

 

 

图2-7 系统管理结构图

 

2.3.9系统用例分析

 

     在以上需求分析的基础上，本节对它们进行用例分析。

 

（1）医生信息管理

 

     本模块主要针对管理员和病人来实现的，管理员在本模块中能够对医生的信息进行添加、修改和删除，而病人可以在本模块中实现对医生信息的查询，医生信息管理用例分析图如图2-8所示：

 

 

 

图2-8 医生信息管理用例图

 

 

 

（2）病人信息管理

 

 本模块主要针对管理员和医生来实现的，管理员在本模块中能够对病人的信息进行添加、修改和删除，而医生可以在本模块中实现对病人信息的查询，病人信息管理用例分析图如图2-9所示：

 

 

 

图2-9 病人信息管理用例图

 

    

 

   （3）病床信息管理

 

本模块主要针对管理员和病人来实现的，管理员在本模块中能够对病床的信息进行添加、修改、删除，医生可以在本模块中实现对病床信息的查询，病床信息管理用例分析图如图2-10所示：

 

 

 

图2-10 病床信息管理用例图

 

 

 

   （4）收费信息管理

 

本模块主要针对管理员和病人来实现的，管理员在本模块中能够对收费的信息进行添加、修改、删除，病人可以在本模块中实现对收费信息的查询，收费信息管理用例分析图如图2-11所示：

 

 

 

图2-11 收费信息管理用例图

 

 

 

    （5）统计分析管理

 

     本模块主要针对管理员来实现的，管理员在本模块中可以查看病床利用率和收费明细查询，统计分析管理用例分析图如图2-12所示：

 

 

 

图2-12 统计分析管理用例图

 

 

 

 

 

2.4 需求确认

 

考虑到网络环境及系统运行使用的需要，一般而言，系统表现出来的其他需求主要有：一是对各类浏览器友好、兼容性强。二是系统的适应性强。

 

另外，为了更好的用户体验，还应该满足以下条件：

 

1.可靠性需求：用户在使用该系统时，系统无法访问的概率应在5%以下。

 

2.易用性需求：本系统展示给用户的界面应该是友好的且易用的，用户在没有接受培训的情况下也可以使用本系统。

 

3.运行环境约束：由于本系统是B/S架构的Web应用程序，因此要求安装有浏览器的用户才能使用。

 

2.5 需求建模

 

2.5.1 系统E-R图

 

E-R 图能够很直观地表示出概念模型。E-R 图之间联系的种类主要有三种情况，分别为一对一(1:1)、一对多(1:N)和多对多(N:M)。

 

    ER图（实体-联系图）由以下几个固定图形所构成：　　

 

    实体形-矩形表示，矩形内为实体名称。　　

 

    属性-椭圆形或圆角矩形来表示，主属性的下面要相应的添加下划线。 　　

 

    联系-菱形表示，菱形内部为联系的内容。

 

通过对医院管理住院系统的认真分析后，确定了以下六个实体，并标注了其各自的属性（一个实体可能有多个属性）：

 

医生： (编号、姓名、性别、职称、职务、科别、出生日期、工作日期)

 

 

 

图2-1 医生E-R图

 

 

 

    病床： （科别、病床号、床位费、使用状态）

 

 

 

图2-2 病床E-R图

 

 

 

病人： （科别、病床号、姓名、性别、年龄、病症、主治医生、入院日期、出院日期）

 

 

 

 

 

图2-3 病人E-R图

 

 

 

收费信息： （科别、病床号、病人姓名、收费项目、单价、数量、金额、日期）

 

 

 

 

 

图2-4 收费E-R图

 

 

 

整体系统E-R图

 

 

 

图2-5整体E-R图

 

 

 

2.5.2 UML类图

 

将整个系统分为医生信息管理模块、病人信息管理模块、病床管理模块等几个大的模块作为系统的零层。各个模块可以单独运行完成它们的功能，各个模块之间又可以相互调用数据，进而完成数据的综合存储，最终共同协作，从而完成系统的预期功能。医院管理住院系统如图2-6所示 ：

 

 

 

图2-6 UML类图

 

 

 

2.5.3 数据流图

 

数据流程图由四部分构成，它们分别是外部实体、数据处理、数据存储和数据流。

 

 

 

 

 

 

 

 

 

    外部实体                加工             数据流

 

                             

 

根据上一章对原有医院管理住院系统流程图的描述，我们从系统的多个方面进行了分析，希望使系统的管理更加合理，在使用中更具有可行性，并且利用模块化的分析办法，由顶层开始向下对医院管理住院系统逐步分层，逐步细化。我们将系统分为顶层、零层两层，下面就层与层之间的关系（系统关联）和每层的功能详细介绍。

 

2.5.4 系统用例图

 

顶层数据流图，即描述医院管理住院系统的作用范围，故其顶层图如图2-7所示：

 

 

 

图2-7 系统用例图

 

 

 

 

 

2.6 需求过程管理

 

数据字典是对数据流程图中包含的所有元素的定义的集合，存储了系统所有的数据信息。系统逻辑模型是由数据流程图和数据字典共同构成的，数据流图是动态描述，但数据字典是静态描述。数据字典能够更细致的说明和补充数据流程图的逻辑内容，并且能够供人查阅。数据元素、数据流、数据存储以及处理过程等部分组成了数据字典。^[13]

 

（1）数据流

 

数据流名称：用户登录信息

 

别名：无

 

简述：用户登录时填写的信息

 

来源：用户

 

去向：用户登录

 

数据流量：50份/天

 

组成：用户名+密码

 

 

 

数据流名称：医生信息

 

别名：无

 

简述：查看、修改和删除医生信息时显示或填写的信息

 

来源：医生或医生信息的修改、查询和删除

 

去向：医生信息的修改、查询和删除

 

数据流量：30份/天

 

组成：用户名+密码

 

 

 

数据流名称：病人信息

 

别名：无

 

简述：查看、修改和删除病人信息时显示或填写的信息

 

来源：病人信息的修改、查询和删除

 

去向：病人信息的修改、查询和删除

 

数据流量：30份/天

 

组成：用户名+密码

 

 

 

数据流名称：收费信息

 

别名：无

 

简述：查看、修改和删除收费信息时显示或填写的信息

 

来源：收费信息的修改、查询和删除

 

去向：收费信息的修改、查询和删除

 

数据流量：30份/天

 

组成：用户名+密码

 

（2）数据流分量

 

名称：用户名

 

别名：无

 

描述：用户信息中惟一标识某一用户的关键域

 

位置：用户信息表

 

用户登录信息

 

 

 

名称：密码

 

别名：无

 

描述：对用户登录进行验证的关键域

 

位置：用户信息表

 

用户登录信息

 

 

 

名称：病人

 

别名：无

 

描述：病人信息中惟一标识某一病人的关键域

 

位置：病人信息表

 

病人一般信息

 

 

 

名称：医生

 

别名：无

 

描述：医生信息中惟一标识某一医生的关键域

 

位置：医生信息表

 

医生一般信息

 

 

 

名称：病床

 

别名：无

 

描述：病床信息中惟一标识某一病床的关键域

 

位置：病床信息表

 

病床信息

 

 

 

名称：收费

 

别名：无

 

描述：收费信息中惟一标识某一收费情况的关键域

 

位置：收费信息表

 

收费一般情况

 

 

 

（3）数据存储

 

 

 

数据存储的名称: 数据库信息

 

简述: 存放的病人信息、医生信息、病床信息、收费信息等

 

数据存储的组成: 各类信息

 

关键字: 编号

 

相关联的处理: P1（对信息表进行录入）

 

             P2（对信息表进行查询）

 

             P3（对信息表进行修改删除)

 

（4）处理

 

 

 

处理逻辑编号: P03-01

 

处理逻辑名称: 信息录入

 

简述: 对基本信息进行录入.

 

输入的数据流:管理员

 

处理过程: 进行分类录入

 

输出的数据流: 各类数据表

 

 

 

处理逻辑编号: P03-02

 

处理逻辑名称: 查询各类信息

 

简述: 根据条件查询所需的信息.

 

输入的数据流:信息来源于数据库

 

处理过程: 输入查询条件查询,得到符合条件的信息

 

输出的数据流: 查询得到的信息

 

 

 

处理逻辑编号: P03-03

 

处理逻辑名称: 修改、删除信息

 

简述: 对信息做需要的修改后存入数据库中.

 

输入的数据流:数据库信息

 

处理过程: 对需要修改的信息做修改

 

输出的数据流: 修改或删除后得到的信息

 

 

 

3 系统设计

 

3.1 体系结构设计

 

3.1.1 体系结构模型

 

系统采用MVC设计模式。从数据层、视图层、控制层、逻辑层这几个方面进行的。以下将对各个层面的设计进行描述。

 

一、信息系统视图层的设计

 

系统采用B/S开发，这样就可以节约一部分的成本，因为使用这个模式可以减少C/S这个模式的时候进行的安装和升级。通过信息系统的表示层中大量的选项选择可以帮助降低用户数据的输入量，而且还可以减少相应的培训者在培训过程中和操作过程中与软件之间的磨合时间，是其可以更快的熟悉系统的工作，并将系统的作用得到最大程度的发挥。

 

二、控制层与逻辑层的设计

 

在信息系统的开发中，逻辑层需尊重不同用户的不同的需求，而且还要考虑不同层次间的关系。向下依赖是逻辑层的主要设计方式，这样的设计方式不但减少了上下层间信息访问的影响程度，也充分利用了软件开发时向下依赖的设计方法，也利用了其本身的耦合程度。而且，系统在进行进一步的开发和研究时不会在原来的基础上做改变，所以，这是一种具有代表性的可抽取式软件结构。

 

三、设计信息系统数据层

 

MVC模型对于数据的处理是属于比较灵活，因为此模型不会依赖控制部件与视图部件的辅助，这样的数据处理方式就更加有利于更新和优化信息系统，使信息系统的工作效率提升到一个新的层次。对于数据库来说，访问层在数据库的工作过程中起到一个很好的稳定数据的作用，因为访问层可以根据用户的各种不同的需求进行不同程度的改进和适应，从而保证数据库的稳定。MVC的模型设计可以与三层的模式之间做到无缝兼容，而且MVC模型的应用还保证了层次和模块之间不会产生较强的依赖性。而且MVC模型中的模型部可以对用户信息以及软件系统的各个数据进行封装，加强了数据的高处理效率和增强了系统的可操作性

 

3.1.3 体系结构评估

 

提供系统的高层次概述，包括其主要组件、它们如何相互作用，以及每个组件的基本职责。这可以通过图表或模型来辅助说明。

 

3.2 模块设计（详细设计）

 

3.2.1 设计模式

 

本文采用的是自顶向下的分层模块设计方法，由于医院住院管理系统分为：医生信息管理、病人信息管理、病床信息管理、收费信息管理、统计分析和系统管理等功能，我们在设计过程中按其功能把它分成不同的模块。

 

医院管理住院系统的主模块如图所示：

 

 

 

图3-1 程序流程图

 

3.2.1.1系统登录

 

    用户可以在登录页面上登陆。界面如下所示：

 

 

 

图3-2 系统登录图

 

3.2.1.2系统主界面

 

用户登录系统后可以看到系统主界面。

 

 

 

图3-3 系统总界面图

 

3.2.2 通用模块设计

 

3.2.2.1医生信息管理

 

进入医院信息管理中后，可以查看医生的编号、姓名、性别、职称、职务、科别、出生日期和工作日期，可以通过对医生姓名的搜索进行医生信息的查询，还可以对医生的信息进行添加、修改和删除。

 

 

 

图3-4 医生信息管理图

 

 

 

图3-5 医生信息修改图

 

 

 

 

 

图3-6 医生信息添加图

 

3.2.2.2病床管理

 

进入病床信息管理后，可以查看病床的科别、病床号、床位费和使用状态，还可以对病床的信息进行添加、修改和删除。

 

 

 

图3-7 病床信息管理图

 

 

 

 

 

图3-8病床信息修改图

 

 

 

 

 

图3-9 病床信息添加图

 

3.2.2.3病人信息管理

 

进入病人信息管理后，可以查看病人的科别、病床号、病人姓名、病人年龄、病症、主治医生、入院日期和出院日期，还可以通过对病人姓名的搜索来查看病人的信息，也可以对病人的信息进行添加修改和删除。

 

 

 

 

 

图3-10 病人信息管理图

 

 

 

 

 

图3-11 病人信息修改图

 

 

 

图3-12 病人信息添加图

 

3.2.2.4收费管理

 

   进入收费信息管理后，可以查看病人的科别、病床号、病人姓名、收费项目、单价、数量、金额和日期，还可以通过对病人姓名的搜索，来对信息进行查询，也可以对收费信息进行添加、修改和删除。

 

 

 

图3-12 收费信息管理图

 

 

 

图3-13 收费信息添加图

 

 

 

 

 

图3-14 收费信息添加图

 

3.2.2.5统计分析

 

 

 

图3-15 病床利用率查询图

 

 

 

 

 

图3-16 收费信息查询表

 

3.2.2.6修改密码

 

进入系统管理后，可以对密码进行修改，其具体步骤是首先输入原始密码，然后输入新密码，最后确认新密码即可对密码完成修改，如需退出系统，点击退出系统后即可完成，

 

 

 

图3-17 修改密码图

 

  ..........

 

3.2.3 业务模块设计

 

数据库在物理设备上的存储结构与存取方法被称为数据库的物理结构，它依赖与给定的计算机系统。为一个给定的逻辑数据模型选取一个最合适应用要求的物理结构。根据上面的实体关系分析以及ER图，设计医院管理住院系统的数据库表。

 

1. 医生信息表

 

表4-1 医生信息表

 

主键	字段名称	数据类型	长度（字节）
*	编号	varchar	50
	姓名	varchar	50
	性别	varchar	50
	职称	varchar	50
	职务	varchar	50
	科别	varchar	50
	出生日期	varchar	50
	工作日期	varchar	50

 

2.病人信息表

 

表4-2 病人信息表

 

主键	字段名称	数据类型	长度（字节）
*	科别	varchar	50
	病床号	varchar	50
	姓名	varchar	50

 

表4-2 （续）

 

	性别	varchar	50
	年龄	varchar	50
	病症	varchar	50
	主治医师	varchar	50
	入院日期	varchar	50
	出院日期	varchar	50

 

3.病床信息表

 

表4-3 病床信息表

 

主键	字段名称	数据类型	长度（字节）
*	科别	varchar	50
	病床号	varchar	50
	床位费	varchar	50
	使用状态	varchar	50

 

4.收费信息表

 

表4-4 收费信息表

 

主键	字段名称	数据类型	长度（字节）
*	科别	varchar	50
	病床号	varchar	50
	姓名	varchar	50
	收费项目	varchar	50
	单价	varchar	50
	数量	varchar	50
	金额	varchar	50
	日期	varchar	50

 

5.管理员信息表

 

表4-5 管理员信息表

 

主键	字段名称	数据类型	长度（字节）
*	管理员姓名	varchar	50
	密码	varchar	50

 

6.数据库的连接原理

 

 

 

医院管理住院系统数据库连接也是开发该系统的关键环节，主要采用JDBC方式，这些知识在太原理工大学开设的JSP课程中有所学习，具体的操作步骤如图4-6所示：

 

 

 

图4-6 数据库连接具体操作

 

    医院管理住院系统连接数据库的程序采用DAO（数据访问对象）模式来对数据库进行处理操作，其思想如图4-7所示:

 

 

 

图4-7 DAO模式类图

 

4 系统实现

 

5 测试

 

5.1 单元测试

 

5.2

1 项目简介

 

1.1 项目背景

 

医院管理住院系统是当今大部分现代化医院所具备的一个系统，它和医院紧密的联系在一起。由于它的实现，大大的方便了医院的管理，并且为医生和病人提供了很大的便利，缩短了病人求医的时间，为病人和医生之间快速的建立联系提供了一种保障。但是在一些医院，还没有这样的系统，医生、病人和医院之间的关系比较独立，这就大大的影响了医院的效率，给医院的长久发展带来了很不利的因素。

 

1.2 意义

 

近年来医疗行业不断发展，医院规模不断增加。在经济全球化的影响下，我国医疗行业不断借鉴外来经验，不断创新医院的运营模式，改善医院的管理体制，取得了良好的社会反映，发展速度不断加快，给人们的生活带来了很大的便利。

 

医院服务质量和治疗水平的高低，直接影响现代化医院的发展。对于一所现代化的医院，能否全面系统满足病人的需求，如对服务态度，时间安排，治疗水平等的要求是患者选择医院的主要标准。本课题将对医院中的病人管理、医生管理、收费管理和病床管理等方面进行探讨和研究，将现代化医院信息管理系统作为医院管理的核心平台，其管理信息内容作为研究材料与基础。通过此次研究与探讨，主要目的在于目标系统的运用能够全面快速满足病人和医生的需求，为病人提供多方面的便捷。提高医院运行效率，节约病人的时间，减少病人不必要开支。通过目标系统，联系管理者与被管理者，不断反应问题同时可以积极有效解决问题，提高服务质量。利用目标系统带来的收益是多面的，具体表现如下：

 

（1）间接性：利用目标系统，减少人力物力的不必要投入，而非通过计算机信息化系统直接实现经济效益。

 

（2）持久性：目标系统的建立需要投入巨额资金，但并不能收回资金。

 

（3）效益性：医院利用目标系统首先可以满足病人的需求，还能打造良好的现代化医院形象。

 

本课题根据实际需要而产生，为了解决人工计算操作的弊端，开发一套医院管理系统势在必行。本系统的开发主要是根据实际需要而制作，系统整体包括：医生管理模块，病床管理模块，病人管理模块，收费信息管理模块，统计分析模块等功能模块。

 

1.3 必要性论证

 

提高医院工作效率：通过自动化和数字化的医院管理系统，可以显著提高医院的工作效率。系统能够帮助医生和护士快速访问患者信息，减少了手工记录和查询的时间。

 

增强病人体验：系统提供的快速和准确的服务能够改善患者的整体体验。例如，通过系统快速查找自己的治疗信息、病床分配和费用明细，减少了患者等待时间和可能的焦虑。

 

错误减少和数据准确性：电子化记录减少了手写记录的错误。同时，系统可以为医生和护士提供实时的、准确的医疗数据，从而提高治疗的准确性和安全性。

 

资源优化和成本管理：系统能够有效管理医院资源，如病床分配和药品库存管理，从而提高资源利用率。此外，通过准确的费用管理和统计分析，医院可以更好地控制成本和优化预算分配。

 

1.4 可行性论证

 

用户的要求和系统调研是进行系统可行性分析的基础，对将要开发的系统从经济、技术、运行等方面进行全面分析，并得出系统的开发工作能否可行，最后完成可行性分析。

 

1、经济可行性

 

经济预算是系统开发的前提工作中非常重要的部分，以本系统为例，在投入运营之前，本项目始终处于投资阶段，但投资并不大，整个项目的开发都独自完成。与此同时，当今计算机普及率较高，人们的技术水平也较高，如果本系统能够投入实际的使用，则所需的相关准备和培训人员的费用相对较少，但在它投入使用后，将节省大量的人力物力，使原来从事这方面工作的人员可以投入到更为实际的工作中去，提高管理部门的工作效率。所以综上所述，本系统的开发在经济方面是比较可行的。

 

2、技术可行性

 

技术可行性分析其主旨就是确保能够充分利用现有的技术条件，契合开发者的实际需求完成软硬件的开发及配置工作，明确技术人员专业能力等客观因素。网络技术的优势主要体现在：可靠的准确度；较快的传输速度。总之在科学技术飞速发展的今天，有利的推进了系统的发展。就技术层而言，本系统具有较高的可行性。

 

3、操作可行性

 

当今人们对计算机的操作已愈加成熟，对电脑的操作有一定基础，且本系统的操作性不算太复杂，通过简单的键盘输入以及鼠标点击即可完成相应的任务，简单培训以后立马上手，而且本系统可视性非常好，即本系统在操作上不会有太大难度。

 

4、时间可行性

 

从时间上看，在四年时间内学习了大量关于这方面的知识，尽管只是有些遗忘，而且需要在两个月内开发成此系统，但是通过查询相关知识，联系起以前学习的知识，通过这段时间的努力一定可以实现。

 

5、法律可行性

 

① 所有技术资料都为合法。

 

② 在开发过程中，完全不存在任何关于知识产权的问题。

 

③ 不侵犯版权，没有抄袭任何系统。

 

④ 在开发过程中，完全不涉及任何的法律问题，不会担负任何的法律责任。

 

根据以上分析，本系统在各个方面都是可以执行实现的。

 

1.5 过程模型

 

敏捷开发

 

描述：敏捷开发强调快速迭代和适应性强的开发过程。它倡导持续交付、跨职能团队合作和客户反馈。

 

适用性：适用于需求频繁变更或不完全明确的项目。如果医院系统需要快速响应市场和技术变化，敏捷模型可能更合适。

 

优点：灵活性强，能快速适应需求变化，增强客户满意度。

 

缺点：可能缺乏明确的项目方向，且难以预测最终成本和完成时间。

 

2 需求分析

 

2.1 客户需求

 

经过对本系统的研究分析，本系统主要是为了方便让医院更快捷的管理。所面向的对象主要有病人、医生和医院的管理人员。病人运用该系统后，可以根据该系统查看自己所需要的信息，包括治疗自己病症的医生的信息、病床信息、收费信息等。医生运用该系统后，可以根据该系统查看自己病人的信息。而医院管理人员通过该系统可以查看病床利用率和收费明细的情况。^[3]

 

根据面向对象的需求的不同，可以分析出本系统需要的主要功能有：登录、医生信息管理、病人信息管理、收费信息管理、病床信息管理、统计分析管理和系统管理

 

2.2 客户需求分析

 

2.2.1  系统性能需求

 

响应时间尽量短，结果准确。一般业务操作时间在3到5秒，添加以及修改报表时间不超过30到45秒。对于多用户并发访问的问题，系统通过先进缓存技术而解决了相应的问题。

 

 

 

2.2.2  系统安全性需求

 

    

 

    由于医院管理住院系统是基于MVC模式以B/S框架而开发的Web应用，根据用户的确切使用要求以及系统的使用目的分析，医院管理住院系统在安全性方面有着很高的要求。因此医院管理住院系统对系统安全性要求尤为严格。

 

为了保证管理员可以登录本系统进行具体的操作，设立了登录信息界面，在账号与密码相匹配的情况下才可以进入系统进行实质的操作。

 

 

 

2.2.3  系统设计需求

 

 

 

为了达到标准、规范等目标，从而提高软件的复用率，在进行系统设计时，需做到如下。

 

    1. 底层数据统一。对于底层数据采用标准的数据进行设置，对底部对于不符合规范的数据及时进行数据清洗和规范化操作，使得不同的数据资源统一在统一的数据格式之下，达到方便查询存储的效果。

 

    2.界面风格的统一。采用统一的主题模式，不同页面会有不同的应用需求，其界面主题保持基本一致，促进组织采用树形结构，方便数据的浏览和查询。

 

    3.数据服务化。系统中各功能模块既独立，又相互关联，在模块化的同时保证各个功能合理配置。同时预留开放接口，能够适应系统的扩展需求。

 

2.3 产品需求定义

 

2.3.1功能需求

 

经过对本系统的研究分析，本系统主要是为了方便让医院更快捷的管理。所面向的对象主要有病人、医生和医院的管理人员。病人运用该系统后，可以根据该系统查看自己所需要的信息，包括治疗自己病症的医生的信息、病床信息、收费信息等。医生运用该系统后，可以根据该系统查看自己病人的信息。而医院管理人员通过该系统可以查看病床利用率和收费明细的情况。^[3]

 

根据面向对象的需求的不同，可以分析出本系统需要的主要功能有：登录、医生信息管理、病人信息管理、收费信息管理、病床信息管理、统计分析管理和系统管理。

 

2.3.2系统层次结构图

 

该系统主要是医生和病人通过该系统，对整个医院的病床、医生、病人和消费信息进行查看，根据自己的需要进行选择。系统层次结构图如图3-1所示： 

 

 

 

图2-1 系统层次结构图

 

       医院管理系统包括如下功能：

 

l 医生管理

 

业务描述：管理医生信息、包括对医生信息的增加、删除、修改

 

l 病人管理

 

业务描述：管理病人信息、包括对病人信息的增加、删除、修改

 

l 病床管理

 

业务描述：管理病床信息、包括对病床信息的增加、删除、修改

 

l 收费管理

 

业务描述：管理收费信息、包括对收费信息的增加、删除、修改

 

l 统计分析

 

业务描述：病床利用率查询主要是通过对科别、医师和日期的搜索，收费明细查询主要是通过对病人姓名和日期的搜索，来进行对其相对应信息的查询。

 

l 修改密码

 

业务描述：用户可以修改自己的系统登录密码

 

 

 

2.3.3医生信息管理

 

 

 

医生信息管理主要是通过对医生姓名的搜索，来对医生信息进行查询，其中查询的内容包括医生的编号、性别、职称、职务、科别、出生日期和工作日期，还可以对医生信息进行添加、修改、删除。

 

 

 

 

 

图2-2 医生信息管理结构图

 

2.3.4病床信息管理

 

病床信息管理主要是对病床的所属科别、病床号、床位费和使用状态进行查     看，还可以对病床进行添加、修改和删除。             

 

 

 

 

 

图2-3 病床信息管理结构图

 

2.3.5病人信息管理

 

病人信息管理主要是通过对病人姓名的搜索，来对病人信息进行查询，其中   查询的内容包括病人的科别、病床号、性别、年龄、病症、主治医生、入院和出院日期，还可以对病人信息进行添加、修改和删除。

 

 

 

图2-4 病人信息管理结构图

 

2.3.6收费信息管理

 

收费信息管理主要是通过对病人姓名的搜素，来进行对其收费信息的查询，其中查询的内容包括病人的科别、病床号、收费项目、单价、数量、金额和日期，还可以对收费信息进行添加、修改和删除。

 

 

 

 

 

 

 

图2-7 收费信息管理结构图

 

2.3.7统计分析管理

 

统计分析管理其中包括病床利用率查询和收费明细查询，其中病床利用率查询主要是通过对科别、医师和日期的搜索，来进行对其相对应信息的查询，查询的内容包括科别、病床号、病人性别、病人姓名、病人年龄、主治医生、入院日期和出院日期等；收费明细查询主要是通过对病人姓名和日期的搜索，来进行对其相对应信息的查询，查询的内容包括科别、病人姓名、病床号、收费项目、数量、单价和金额。

 

 

 

图2-6 统计分析管理结构图

 

2.3.8系统管理

 

 

 

系统管理其中包括修改密码和退出系统，修改密码的方法是首先是输入原密码，然后输入新密码，最后确认新密码。

 

 

 

图2-7 系统管理结构图

 

2.3.9系统用例分析

 

     在以上需求分析的基础上，本节对它们进行用例分析。

 

（1）医生信息管理

 

     本模块主要针对管理员和病人来实现的，管理员在本模块中能够对医生的信息进行添加、修改和删除，而病人可以在本模块中实现对医生信息的查询，医生信息管理用例分析图如图2-8所示：

 

 

 

图2-8 医生信息管理用例图

 

 

 

（2）病人信息管理

 

 本模块主要针对管理员和医生来实现的，管理员在本模块中能够对病人的信息进行添加、修改和删除，而医生可以在本模块中实现对病人信息的查询，病人信息管理用例分析图如图2-9所示：

 

 

 

图2-9 病人信息管理用例图

 

    

 

   （3）病床信息管理

 

本模块主要针对管理员和病人来实现的，管理员在本模块中能够对病床的信息进行添加、修改、删除，医生可以在本模块中实现对病床信息的查询，病床信息管理用例分析图如图2-10所示：

 

 

 

图2-10 病床信息管理用例图

 

 

 

   （4）收费信息管理

 

本模块主要针对管理员和病人来实现的，管理员在本模块中能够对收费的信息进行添加、修改、删除，病人可以在本模块中实现对收费信息的查询，收费信息管理用例分析图如图2-11所示：

 

 

 

图2-11 收费信息管理用例图

 

 

 

    （5）统计分析管理

 

     本模块主要针对管理员来实现的，管理员在本模块中可以查看病床利用率和收费明细查询，统计分析管理用例分析图如图2-12所示：

 

 

 

图2-12 统计分析管理用例图

 

 

 

 

 

2.4 需求确认

 

考虑到网络环境及系统运行使用的需要，一般而言，系统表现出来的其他需求主要有：一是对各类浏览器友好、兼容性强。二是系统的适应性强。

 

另外，为了更好的用户体验，还应该满足以下条件：

 

1.可靠性需求：用户在使用该系统时，系统无法访问的概率应在5%以下。

 

2.易用性需求：本系统展示给用户的界面应该是友好的且易用的，用户在没有接受培训的情况下也可以使用本系统。

 

3.运行环境约束：由于本系统是B/S架构的Web应用程序，因此要求安装有浏览器的用户才能使用。

 

2.5 需求建模

 

2.5.1 系统E-R图

 

E-R 图能够很直观地表示出概念模型。E-R 图之间联系的种类主要有三种情况，分别为一对一(1:1)、一对多(1:N)和多对多(N:M)。

 

    ER图（实体-联系图）由以下几个固定图形所构成：　　

 

    实体形-矩形表示，矩形内为实体名称。　　

 

    属性-椭圆形或圆角矩形来表示，主属性的下面要相应的添加下划线。 　　

 

    联系-菱形表示，菱形内部为联系的内容。

 

通过对医院管理住院系统的认真分析后，确定了以下六个实体，并标注了其各自的属性（一个实体可能有多个属性）：

 

医生： (编号、姓名、性别、职称、职务、科别、出生日期、工作日期)

 

 

 

图2-1 医生E-R图

 

 

 

    病床： （科别、病床号、床位费、使用状态）

 

 

 

图2-2 病床E-R图

 

 

 

病人： （科别、病床号、姓名、性别、年龄、病症、主治医生、入院日期、出院日期）

 

 

 

 

 

图2-3 病人E-R图

 

 

 

收费信息： （科别、病床号、病人姓名、收费项目、单价、数量、金额、日期）

 

 

 

 

 

图2-4 收费E-R图

 

 

 

整体系统E-R图

 

 

 

图2-5整体E-R图

 

 

 

2.5.2 UML类图

 

将整个系统分为医生信息管理模块、病人信息管理模块、病床管理模块等几个大的模块作为系统的零层。各个模块可以单独运行完成它们的功能，各个模块之间又可以相互调用数据，进而完成数据的综合存储，最终共同协作，从而完成系统的预期功能。医院管理住院系统如图2-6所示 ：

 

 

 

图2-6 UML类图

 

 

 

2.5.3 数据流图

 

数据流程图由四部分构成，它们分别是外部实体、数据处理、数据存储和数据流。

 

 

 

 

 

 

 

 

 

    外部实体                加工             数据流

 

                             

 

根据上一章对原有医院管理住院系统流程图的描述，我们从系统的多个方面进行了分析，希望使系统的管理更加合理，在使用中更具有可行性，并且利用模块化的分析办法，由顶层开始向下对医院管理住院系统逐步分层，逐步细化。我们将系统分为顶层、零层两层，下面就层与层之间的关系（系统关联）和每层的功能详细介绍。

 

2.5.4 系统用例图

 

顶层数据流图，即描述医院管理住院系统的作用范围，故其顶层图如图2-7所示：

 

 

 

图2-7 系统用例图

 

 

 

 

 

2.6 需求过程管理

 

数据字典是对数据流程图中包含的所有元素的定义的集合，存储了系统所有的数据信息。系统逻辑模型是由数据流程图和数据字典共同构成的，数据流图是动态描述，但数据字典是静态描述。数据字典能够更细致的说明和补充数据流程图的逻辑内容，并且能够供人查阅。数据元素、数据流、数据存储以及处理过程等部分组成了数据字典。^[13]

 

（1）数据流

 

数据流名称：用户登录信息

 

别名：无

 

简述：用户登录时填写的信息

 

来源：用户

 

去向：用户登录

 

数据流量：50份/天

 

组成：用户名+密码

 

 

 

数据流名称：医生信息

 

别名：无

 

简述：查看、修改和删除医生信息时显示或填写的信息

 

来源：医生或医生信息的修改、查询和删除

 

去向：医生信息的修改、查询和删除

 

数据流量：30份/天

 

组成：用户名+密码

 

 

 

数据流名称：病人信息

 

别名：无

 

简述：查看、修改和删除病人信息时显示或填写的信息

 

来源：病人信息的修改、查询和删除

 

去向：病人信息的修改、查询和删除

 

数据流量：30份/天

 

组成：用户名+密码

 

 

 

数据流名称：收费信息

 

别名：无

 

简述：查看、修改和删除收费信息时显示或填写的信息

 

来源：收费信息的修改、查询和删除

 

去向：收费信息的修改、查询和删除

 

数据流量：30份/天

 

组成：用户名+密码

 

（2）数据流分量

 

名称：用户名

 

别名：无

 

描述：用户信息中惟一标识某一用户的关键域

 

位置：用户信息表

 

用户登录信息

 

 

 

名称：密码

 

别名：无

 

描述：对用户登录进行验证的关键域

 

位置：用户信息表

 

用户登录信息

 

 

 

名称：病人

 

别名：无

 

描述：病人信息中惟一标识某一病人的关键域

 

位置：病人信息表

 

病人一般信息

 

 

 

名称：医生

 

别名：无

 

描述：医生信息中惟一标识某一医生的关键域

 

位置：医生信息表

 

医生一般信息

 

 

 

名称：病床

 

别名：无

 

描述：病床信息中惟一标识某一病床的关键域

 

位置：病床信息表

 

病床信息

 

 

 

名称：收费

 

别名：无

 

描述：收费信息中惟一标识某一收费情况的关键域

 

位置：收费信息表

 

收费一般情况

 

 

 

（3）数据存储

 

 

 

数据存储的名称: 数据库信息

 

简述: 存放的病人信息、医生信息、病床信息、收费信息等

 

数据存储的组成: 各类信息

 

关键字: 编号

 

相关联的处理: P1（对信息表进行录入）

 

             P2（对信息表进行查询）

 

             P3（对信息表进行修改删除)

 

（4）处理

 

 

 

处理逻辑编号: P03-01

 

处理逻辑名称: 信息录入

 

简述: 对基本信息进行录入.

 

输入的数据流:管理员

 

处理过程: 进行分类录入

 

输出的数据流: 各类数据表

 

 

 

处理逻辑编号: P03-02

 

处理逻辑名称: 查询各类信息

 

简述: 根据条件查询所需的信息.

 

输入的数据流:信息来源于数据库

 

处理过程: 输入查询条件查询,得到符合条件的信息

 

输出的数据流: 查询得到的信息

 

 

 

处理逻辑编号: P03-03

 

处理逻辑名称: 修改、删除信息

 

简述: 对信息做需要的修改后存入数据库中.

 

输入的数据流:数据库信息

 

处理过程: 对需要修改的信息做修改

 

输出的数据流: 修改或删除后得到的信息

 

 

 

3 系统设计

 

3.1 体系结构设计

 

3.1.1 体系结构模型

 

系统采用MVC设计模式。从数据层、视图层、控制层、逻辑层这几个方面进行的。以下将对各个层面的设计进行描述。

 

一、信息系统视图层的设计

 

系统采用B/S开发，这样就可以节约一部分的成本，因为使用这个模式可以减少C/S这个模式的时候进行的安装和升级。通过信息系统的表示层中大量的选项选择可以帮助降低用户数据的输入量，而且还可以减少相应的培训者在培训过程中和操作过程中与软件之间的磨合时间，是其可以更快的熟悉系统的工作，并将系统的作用得到最大程度的发挥。

 

二、控制层与逻辑层的设计

 

在信息系统的开发中，逻辑层需尊重不同用户的不同的需求，而且还要考虑不同层次间的关系。向下依赖是逻辑层的主要设计方式，这样的设计方式不但减少了上下层间信息访问的影响程度，也充分利用了软件开发时向下依赖的设计方法，也利用了其本身的耦合程度。而且，系统在进行进一步的开发和研究时不会在原来的基础上做改变，所以，这是一种具有代表性的可抽取式软件结构。

 

三、设计信息系统数据层

 

MVC模型对于数据的处理是属于比较灵活，因为此模型不会依赖控制部件与视图部件的辅助，这样的数据处理方式就更加有利于更新和优化信息系统，使信息系统的工作效率提升到一个新的层次。对于数据库来说，访问层在数据库的工作过程中起到一个很好的稳定数据的作用，因为访问层可以根据用户的各种不同的需求进行不同程度的改进和适应，从而保证数据库的稳定。MVC的模型设计可以与三层的模式之间做到无缝兼容，而且MVC模型的应用还保证了层次和模块之间不会产生较强的依赖性。而且MVC模型中的模型部可以对用户信息以及软件系统的各个数据进行封装，加强了数据的高处理效率和增强了系统的可操作性

 

3.1.3 体系结构评估

 

提供系统的高层次概述，包括其主要组件、它们如何相互作用，以及每个组件的基本职责。这可以通过图表或模型来辅助说明。

 

3.2 模块设计（详细设计）

 

3.2.1 设计模式

 

本文采用的是自顶向下的分层模块设计方法，由于医院住院管理系统分为：医生信息管理、病人信息管理、病床信息管理、收费信息管理、统计分析和系统管理等功能，我们在设计过程中按其功能把它分成不同的模块。

 

医院管理住院系统的主模块如图所示：

 

 

 

图3-1 程序流程图

 

3.2.1.1系统登录

 

    用户可以在登录页面上登陆。界面如下所示：

 

 

 

图3-2 系统登录图

 

3.2.1.2系统主界面

 

用户登录系统后可以看到系统主界面。

 

 

 

图3-3 系统总界面图

 

3.2.2 通用模块设计

 

3.2.2.1医生信息管理

 

进入医院信息管理中后，可以查看医生的编号、姓名、性别、职称、职务、科别、出生日期和工作日期，可以通过对医生姓名的搜索进行医生信息的查询，还可以对医生的信息进行添加、修改和删除。

 

 

 

图3-4 医生信息管理图

 

 

 

图3-5 医生信息修改图

 

 

 

 

 

图3-6 医生信息添加图

 

3.2.2.2病床管理

 

进入病床信息管理后，可以查看病床的科别、病床号、床位费和使用状态，还可以对病床的信息进行添加、修改和删除。

 

 

 

图3-7 病床信息管理图

 

 

 

 

 

图3-8病床信息修改图

 

 

 

 

 

图3-9 病床信息添加图

 

3.2.2.3病人信息管理

 

进入病人信息管理后，可以查看病人的科别、病床号、病人姓名、病人年龄、病症、主治医生、入院日期和出院日期，还可以通过对病人姓名的搜索来查看病人的信息，也可以对病人的信息进行添加修改和删除。

 

 

 

 

 

图3-10 病人信息管理图

 

 

 

 

 

图3-11 病人信息修改图

 

 

 

图3-12 病人信息添加图

 

3.2.2.4收费管理

 

   进入收费信息管理后，可以查看病人的科别、病床号、病人姓名、收费项目、单价、数量、金额和日期，还可以通过对病人姓名的搜索，来对信息进行查询，也可以对收费信息进行添加、修改和删除。

 

 

 

图3-12 收费信息管理图

 

 

 

图3-13 收费信息添加图

 

 

 

 

 

图3-14 收费信息添加图

 

3.2.2.5统计分析

 

 

 

图3-15 病床利用率查询图

 

 

 

 

 

图3-16 收费信息查询表

 

3.2.2.6修改密码

 

进入系统管理后，可以对密码进行修改，其具体步骤是首先输入原始密码，然后输入新密码，最后确认新密码即可对密码完成修改，如需退出系统，点击退出系统后即可完成，

 

 

 

图3-17 修改密码图

 

  ..........

 

3.2.3 业务模块设计

 

数据库在物理设备上的存储结构与存取方法被称为数据库的物理结构，它依赖与给定的计算机系统。为一个给定的逻辑数据模型选取一个最合适应用要求的物理结构。根据上面的实体关系分析以及ER图，设计医院管理住院系统的数据库表。

 

1. 医生信息表

 

表4-1 医生信息表

 

主键	字段名称	数据类型	长度（字节）
*	编号	varchar	50
	姓名	varchar	50
	性别	varchar	50
	职称	varchar	50
	职务	varchar	50
	科别	varchar	50
	出生日期	varchar	50
	工作日期	varchar	50

 

2.病人信息表

 

表4-2 病人信息表

 

主键	字段名称	数据类型	长度（字节）
*	科别	varchar	50
	病床号	varchar	50
	姓名	varchar	50

 

表4-2 （续）

 

	性别	varchar	50
	年龄	varchar	50
	病症	varchar	50
	主治医师	varchar	50
	入院日期	varchar	50
	出院日期	varchar	50

 

3.病床信息表

 

表4-3 病床信息表

 

主键	字段名称	数据类型	长度（字节）
*	科别	varchar	50
	病床号	varchar	50
	床位费	varchar	50
	使用状态	varchar	50

 

4.收费信息表

 

表4-4 收费信息表

 

主键	字段名称	数据类型	长度（字节）
*	科别	varchar	50
	病床号	varchar	50
	姓名	varchar	50
	收费项目	varchar	50
	单价	varchar	50
	数量	varchar	50
	金额	varchar	50
	日期	varchar	50

 

5.管理员信息表

 

表4-5 管理员信息表

 

主键	字段名称	数据类型	长度（字节）
*	管理员姓名	varchar	50
	密码	varchar	50

 

6.数据库的连接原理

 

 

 

医院管理住院系统数据库连接也是开发该系统的关键环节，主要采用JDBC方式，这些知识在太原理工大学开设的JSP课程中有所学习，具体的操作步骤如图4-6所示：

 

 

 

图4-6 数据库连接具体操作

 

    医院管理住院系统连接数据库的程序采用DAO（数据访问对象）模式来对数据库进行处理操作，其思想如图4-7所示:

 

 

 

图4-7 DAO模式类图

 

4 系统实现

 

5 测试

 

5.1 单元测试

 

5.2 集成测试

 

测试用例

 

5.3 系统测试

 

系统测试，即是一种为了保证程序的正确性而进行的过程，其主要意义是为了发现错误并改正错误。在这样的定义下软件测试有以下的目的：首先，软件测试是实际上是程序的执行一个过程，这样一个过程的目的在于发现系统中目前尚未发现的错误，而不是证明这段程序的正确而进行的过程。其次，在这样的一个目的下，一个好的系统测试用例是帮助程序员发现系统中隐藏的错误和不易发现的错误。总之，我们进行软件测试要以发现错位为目的进行，而不能以证明这段程序写的对而进行，只要我们发现了一个错误，我们这个测试用例就是一个好的测试用例。由上面测试的定义与目的总结出测试有一下几点原则：1.在系统的开发过程中应当尽早地和不断地进行相应部分的软件测试。 2.在测试中一个测试用例应由测试输入数据和与之对应的测试预期输出结果这两部分构成。 3.在设计一个测试用例时，这个测试用例应当包括合理的输入条件以及不合理的输入条件。 4.测试应该严格执行相应的测试计划，排除测试的随意性。 5.测试结束时，应当认真保存测试计划、测试用例和测试报告，方便程序员本人和其他程序员进行后期维护。

 

5.3.1系统测试目标

 

医院住院管理系统最终应完成的测试目标：本文应着重于系统的功能测试，测试的对象则是病人和医生，在实现了预定的系统功能及满足用户需求的前提条件下，尽可能地发现并完善系统中的漏洞与隐患，确保软件的实用性、安全性、可靠性、可扩展性以及经济性，为今后的医院住院提供更便捷的方式。

 

5.3.2测试设计

 

5.3.2测试用例设计

 

测试用例的设计使用错误推测法、边界值法和等价类划分法等方法。

 

5.3.3测试环境与需求

 

测试软件环境：PC 机操作系统：Windows 7；数据库管理系统： Microsoft SQL Server 2005；Microsoft Visual Studio

 

测试需求：对系统进行测试采用黑盒测试法，力求找出程序员在逻辑上，功能实现上的的问题，并且验证该程序输出结果是否正常，是否能对错误输入做出正常的响应。

集成测试

 

测试用例

 

5.3 系统测试

 

系统测试，即是一种为了保证程序的正确性而进行的过程，其主要意义是为了发现错误并改正错误。在这样的定义下软件测试有以下的目的：首先，软件测试是实际上是程序的执行一个过程，这样一个过程的目的在于发现系统中目前尚未发现的错误，而不是证明这段程序的正确而进行的过程。其次，在这样的一个目的下，一个好的系统测试用例是帮助程序员发现系统中隐藏的错误和不易发现的错误。总之，我们进行软件测试要以发现错位为目的进行，而不能以证明这段程序写的对而进行，只要我们发现了一个错误，我们这个测试用例就是一个好的测试用例。由上面测试的定义与目的总结出测试有一下几点原则：1.在系统的开发过程中应当尽早地和不断地进行相应部分的软件测试。 2.在测试中一个测试用例应由测试输入数据和与之对应的测试预期输出结果这两部分构成。 3.在设计一个测试用例时，这个测试用例应当包括合理的输入条件以及不合理的输入条件。 4.测试应该严格执行相应的测试计划，排除测试的随意性。 5.测试结束时，应当认真保存测试计划、测试用例和测试报告，方便程序员本人和其他程序员进行后期维护。

 

5.3.1系统测试目标

 

医院住院管理系统最终应完成的测试目标：本文应着重于系统的功能测试，测试的对象则是病人和医生，在实现了预定的系统功能及满足用户需求的前提条件下，尽可能地发现并完善系统中的漏洞与隐患，确保软件的实用性、安全性、可靠性、可扩展性以及经济性，为今后的医院住院提供更便捷的方式。

 

5.3.2测试设计

 

5.3.2测试用例设计

 

测试用例的设计使用错误推测法、边界值法和等价类划分法等方法。

 

5.3.3测试环境与需求

 

测试软件环境：PC 机操作系统：Windows 7；数据库管理系统： Microsoft SQL Server 2005；Microsoft Visual Studio

 

测试需求：对系统进行测试采用黑盒测试法，力求找出程序员在逻辑上，功能实现上的的问题，并且验证该程序输出结果是否正常，是否能对错误输入做出正常的响应。