医院管理住院系统的研究与实现（论文+PPT+源码）

医院管理住院系统的研究与实现

摘要

医院管理住院系统是一项集多类学科为一体的系统，其中包含医学、信息、计算机等学科，广泛的应用在当今欧美等发达国家，给治疗患者们提供了很大的便利。假如全面实现了这一系统，能够极大限度的改进医院的治疗水平，在患者面前重新建立起医院的良好形象。

在对本课题进行全面深入研究和分析后，决定采用的数据库库管理系统为SQL SEVER 2005，使用的开发工具为MYECLIPSE的JSP，在面向对象的开发工具中，最主要的是JAVA,在网络查询和开发语言方面都运用了JSP技术。

本篇论文主要通过使用以上工具，来对医院管理住院系统进行更合理的开发和利用。本篇论文在构建新系统的前提下，进行详细的背景分析，并介绍系统开发时将采纳的主要技术和技术难点。利用软件工程思想，在将功能性需求和非功能性需求区分的基础上进行需求分析；利用该需求分析系统的业务流转设计；然后针对上述内容，设计出系统的用例图，描绘系统设计过程。在系统设计完成以后，对系统进行了软件测试，通过多种测试相结合的方式来确保系统的安全性和有效性。本系统主要分为六大模块，分别是医生管理模块、病人管理模块、病床

管理模块、收费管理模块、统计分析模块和系统功能模块，医生、病人和医院的管理人员都可以通过此系统寻找出自己所需要的信息。

关键词：医院管理住院系统，SQL，JSP， 软件工程

Research and Implementation of Hospital Management Hospitalization System

Abstract

Hospital management hospitalization system is a multi-disciplines system, which includes medicine, information, computer and other disciplines. Today, this system is applicated widely in developed countries such as Europe and the United States and provides a great convenience to treat patients. If this system is fully implemented, it can greatly improve the treatment level of hospital, and re-establish a good image in front of patients.

In this article to conduct a comprehensive and in-depth study and analysis, the decision to use the database management system for SQL SEVER 2005, the use of tools for the development of MYECLIPSE JSP, in object-oriented development tools, the most important is JAVA, and JSP technology is used in network query and development language.

This paper mainly uses the above tools to make more rational development and utilization of hospital management hospitalization system. Under the premise that the construction of a new system, this paper takes a detailed analysis of the background and the main technologies and technical difficulties that will be adopted when the system is developed. Then, using the requirments to analysis the business flow design of the system, and then the use case diagram of the system is designed to describe the system design process. After the system design is completed, software testing of the system is carried out to ensure the safety and effectiveness by combining various tests.This system mainly divided into six modules, which includes doctor management module, patient management module, the bed management module, charge management module, statistics analysis module and system function module. And doctors, patients and hospital administrators can find out information what they need through this system.

Keywords: The hospital manages the hospitalization system；SQL; JSP; Software Engineering

目 录

摘要II

AbstractII

第一章 绪论11

1.1 背景11

1.2 系统的开发目的及其意义11

1.3 本文章节安排11

1.4 本章小结22

第二章 相关技术33

2.1 JSP技术33

2.2 “结构化查询语言”（SQL）44

2.3 B/S服务架构44

2.4 MVC设计模式55

2.5 本章小结66

第三章 系统的需求分析和可行性研究77

3.1 功能需求77

3.1.1 系统层次结构图77

3.1.2 医生信息管理88

3.1.3 病床信息管理88

3.1.4 病人信息管理99

3.1.5 收费信息管理99

3.1.6 统计分析管理99

3.1.7 系统管理1010

3.1.8 系统用例分析1010

3.2 非功能性需求1313

3.2.1 系统性能需求1313

3.2.2 系统安全性需求1313

3.2.3 系统设计需求1313

3.2.4 系统其它需求1313

3.3 系统的可行性分析1414

3.4 本章小结1515

第四章 系统总体设计1616

4.1 系统设计原则1616

4.2 系统框架1616

4.3 数据库的分析与设计1717

4.3.1 数据库的概念结构设计1717

4.3.2 E-R图1717

4.3.3 数据库的实现1919

4.3.4 数据库的连接原理2020

4.4 系统软件结构设计2121

4.4.1 数据流程图2121

4.4.2 系统顶层图2222

4.4.3 系统零层图2222

4.5 数据字典2323

4.6 本章小结2525

第五章 系统详细设计与实现2626

5.1 程序流程图2626

5.2 系统登录2626

5.3 系统主界面2727

5.4 医生信息管理2727

5.5 病床管理2828

5.6 病人信息管理3030

5.7 收费管理3131

5.8 统计分析3232

5.9 修改密码3333

5.10 本章小结3333

第六章 系统测试3434

6.1 系统测试目标3434

6.2 测试设计3434

6.2.1 测试用例设计3434

6.2.2 测试环境与需求3434

6.3 测试用例及测试模块3535

6.3.1 测试用例3535

6.3.2 测试模块及案例3737

6.3.3 系统性能测试3939

6.4 缺陷分析4040

6.5 测试结果4040

6.6 本章小结4040

第七章 结束语4141

7.1 体会与收获4141

7.2 不足4141

7.3 今后的发展方向4242

结论4343

参考文献4444

致谢4545

第一章 绪论

1.1 背景

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

1.2 系统的开发目的及其意义

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

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

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

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

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

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

1.3 本文章节安排

本文一共包含六个章节，具体的各个章节安排如下：

第一章:绪论，在该章主要分析本文的研究背景及研究意义，并给出了本文的章节安排。

第二章: 开发技术。这一章节主要介绍了系统开发所要用到的开发工具，并且对系统配置给了具体的要求。

第三章:系统的可行性研究与需求分析。从经济、技术、操作和法律四个方面分析了系统的可行性，从系统的非功能性需求与功能性需求两个角度进行了论述。

第四章:系统总体设计。从系统设计原则开始,从数据库的分析与设计、系统软件结构设计以及数据字典进行了逐步分析。

第五章:系统详细设计与实现。对系统中的重要功能模块给出了部分界面予以展示。

第六章:系统测试。本章研究系统测试的相关技术、测试方法及测试工具，对其进行了具体的系统测试。

第七章：总结了自己在完成论文时的体会，以及自己所收获的知识，总结出自己的不足，确立了自己在今后的发展中所要努力的方向。

1.4 本章小结

本章主要介绍了研究医院管理住院系统的目的，以及医院管理住院系统的开发目的和意义，并且还介绍了本篇论文的章节安排。

第二章 相关技术

2.1 JSP技术

SunMicrosystems公司最早提出了JSP，经过持续地推广，不断地的有计算机和软件公司共同参与其中进行开发。其主要是通过在HTML文件（*.htm，*.html）中嵌入JSP和Scriptlet标签来实现的。这样，内嵌的Java程序就可以生效，对数据库做出请求、或者启用E-mail等。上世纪末，JSP出现了，SunMicrosystems公司建立起动态性的网站就是利用了它的存在，并利用其兼容性和扩展性，来扩大平台应用。从实际效果来看，JSP技术的出现使Web的建设和设计创新不断。其特点大概有以下几点：
依托JSP技术，工程技术人员可利用XML或HTML标识来对web等页面进行修改或推翻设计。这些页面上的内容也可以依托JSP来设计或实现。如此一来，利用JSP编程语言设计的服务器，其内容发送的信息和要求都可以通过JSP索引来解释，或者根据其脚本来设计或建立。当然，这些最终的内容也会通过HTML或XML形式反馈到浏览器中。通过这样的方式，能够使源代码的编写者维护自己的专利和权益，也可以保证web页面的兼容性和可拓展性。
一般来说，单独的JSP页面不发生复杂的数据分析和处理，其一般用于爬虫或索引提炼攫取数据。[14]
JSP是基于Java编程语言来实现的，他的内部具有scriptlets和tags，可以用于储存动态页面运作需要的一套程序方式。另外，JSP将动态页面运作需要的一套程序方式与静态的网页设计分离，这样的模块分块使JSP具有兼容和扩展性，开发性更高。说到底，JSP可以实现动态的页面控制，并且可以让页面运作程序与静态的页面分离。
JSP页面由两部分HTML和Java代码组成。一般来说，上游的服务器如果收到来自外部请求或信息，会对Java代码进行分析或运算处理，从而以HTML的方式回馈到网页浏览器中。其基础是Java Servlet，Java Servlet和JSP这两者是规模较大的JSP项目开发的重要组成部分。在技术上，JSP具有了Java特有的容易理解、容易上手、适用性广，不挑平台、安全性高等特点。这些优势保证了其在整个因特网中广为使用。在上世纪末出现后，如今如IBM、Oracle、Bea等公司都使用其服务器，其逐渐成为电子商务软件开发的“宠儿”。[16]
具体来看，JSP有以下优点：
(1)可以经过多次使用。一般程序经过编码后，可在各类系统内嵌套使用，而不需要重新编写代码。这是其优于PHP之处。
(2)另外，其兼容性比较好。基本不挑平台，常见的平台都能兼容和开发、应用、扩展。这刚好与PHP的不可拓展性互补。
(3)适用性广。无论是war小文件或多层次的平台以及服务器，其都能兼容和运行。对各类规模不一的平台都能进行数据分析、处理，反馈，其展现出极强的适应能力。
(4)可依托种类丰富、功能优异的工具。经过接近20年的发展，JSP如今已拥有了很多开发工具，这些工具功能强大，几乎覆盖了程序开发和设计方方面面，并且几乎不需耗费金钱即可得到，为开发人员提供了便利性。[5]

2.2 “结构化查询语言”（SQL）

SQL意思是Structured Query Language，即为查询语言。SQL相当于各数据库之间的信使，主要是这些数据库之间进交互的工具，也是它们之间信息交流的工具。按照美国ANSI的定义，SQL被纳入了数据库标准化建设中。运用SQL语言，在数据库中可以直接进行操作，比如数据更新、数据攫取等。如今市面上比较具有规模、且与外界连通较大的数据库都是使用SQL语句。另外目前标准化的SQL已经可以执行对数据库大部分的功能操作。[4]SQL Server是这些数据库进行交互和信息交流的工具。一开始是由Microsoft和Sybase 等共同设计建造的，其最早应用在OS/2上。在Windows NT诞生后，微软公司与Sybase公司在SQL Server的设计应用上开始走向不同方向。其中微软公司致力与将SQL Server应用到Windows NT中，而Sybase公司相对地，致力于将SQL Serve融入到其自身开发的UNⅨ中。[2]

2.3 B/S服务架构

随着互联网和浏览器的发展，B/S的开发架构逐渐取代了C/S架构，B/S是浏览器和服务器的开发架构模式，它在服务器端放入了应用程序的大部分功能，浏览器安装在客户机端，对服务器端的安装的数据库通过Web Server进行数据的存储和读取。

B/S架构在技术方向可认为是C/S架构的升级版，用户只有拥有浏览器和互联网络，就可以通过浏览器的界面与系统进行交互，浏览器端只会处理较少的事务，大多数的处理和操作都设计在服务器端。这样做很大程度上降低了客户端的负荷，给用户节约了硬件和系统维护方面的开支。B/S架构的具体流程为：打开浏览器后，输入网址，通过系统界面向服务器端发出请求指令，服务器端接收到浏览器发来的指令做对应的处理，并负责将结果传递到浏览器端，展现给用户。该模式是在牺牲服务器端符合的条件下减少客户端的负荷量。B/S架构在程序运行时，在浏览器向服务器发指令的同时需要借助Web Server，Web Server在这儿主要承担着动态网页生成、数据请求、返回结果等任务。换句话可以这样理解， 将C/S架构中客户端的数据处理模块中的任务分为两个，一个交给B/S架构中客户端的Web Server完成，另一个对数据库的访问交给B/S架构中服务器端完成，可以看出Web Server可以承担客户端的一部分负荷，这样就可以减轻了客户端的工作量。[17]

由此可知，B/S架构较传统的C/S架构开发，有其独特的优势和特点：将应用程序划分为多个独立的层次，每个层次任务不同，相互独立，但又相互关联，目的是有一个完整的系统。B/S架构按照一定的应用功能可划分为三个层次，即功能层、表示层和数据层，三个层次各司其职，为用户展现一个完整友好的应用系统。传统的C/S架构系统在客户端装有数据库，常用的是关系数据库DBMS，而B/S架构的功能层只是为用户提供必要的数据，大量的数据处理都依靠数据层来完成，其在服务器端完成，为缓减这种压力，B/S架构通过采取增添服务器的数量。B/S架构下的数据安全性能也比C/S架构高，它不需要去保存任何数据和信息，只需要在服务器端增加备份服务器，以防万一服务器出现崩溃的情况下用于恢复数据库使用。[7]其B/S架构图如图2-1所示：

医院管理住院系统的研究与实现（论文+PPT+源码）

图2-1 B/S架构图

2.4 MVC设计模式

MVC是英文Model View Controller的缩写，其表示的为：模型-视图-控制器，MVC设计模式将业务逻辑层和数据层单独分离，解决了系统输入、控制和显示的，有助于系统的开发和维护，MVC设计模式是目前系统开发最常用最合适的一种设计模式。下面具体介绍具体每一层的功能。

1. 模型层。该层是应用程序的核心部分，一个模型往往与许多个视图对应着，这样设计的目的是为了应用程序的可重复利用和可移植，只需修改具体业务信息，不需要重新编写相同的代码，从而提高系统的功能，有利于维护系统。该层连接着系统业务层和数据处理层，应用程序通过模型层向数据库读取和存储数据。如果改变了应用程序的业务信息，模型层会同时向业务层和视图层发出指令。
2. 视图层。该层主要是将应用程序中处理的数据通过界面友好的展现给用户，用户只能通过视图层与系统发生交互交流。视图层不对数据进行任何的处理和操作，只是用于接收用户的信息和将信息展现给用户，将模型对数据的更新实时传递给用户。通常视图层一般由HTML组成的代码设计，外加一些Flash和XML等标识语言以及Web Services等。
3. 控制器。该层主要是用于解决系统业务的相关请求，通常负责根据用户的输入调用模型去执行用户的需求，同时可以控制模型中的数据如何通过视图展现给用户。控制器的执行流程是：用户输入相关的请求并通知视图层，控制器从视图层接收到请求通过一定的算法向模型层发出指令，模型层将数据返回，最后再传给视图层，将数据呈现给用户。

MVC的特点及优势主要有以下几点：

①MVC设计模式一般用于ERP和办公等交互性强、用户众多的系统中；

②MVC设计模式可以将多个数据模型用一个视图展现，也可以支持多个视图访问同一个服务器的代码；

③MVC设计模式便于构建模型，易于用户与应用程序的交互和表达。

④MVC设计模式分成三个层次，相对每一层的开发者责任分工明确，每一层的开发者只需专注于相应层次的开发，从而提高了开发速度，缩短了应用程序的交付时间。[1]

2.5 本章小结

本章对系统开发使用的相关技术做了详细的介绍，最终选择B/S开发本系统；并且介绍了JSP技术、结构化语言、B/S服务框架。

---

1. 系统的需求分析和可行性研究

3.1 功能需求

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

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

3.1.1 系统层次结构图

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

医院管理住院系统的研究与实现（论文+PPT+源码）

图3-1 系统层次结构图

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

• 医生管理
  业务描述：管理医生信息、包括对医生信息的增加、删除、修改
• 病人管理
  业务描述：管理病人信息、包括对病人信息的增加、删除、修改
• 病床管理
  业务描述：管理病床信息、包括对病床信息的增加、删除、修改
• 收费管理
  业务描述：管理收费信息、包括对收费信息的增加、删除、修改
• 统计分析
  业务描述：病床利用率查询主要是通过对科别、医师和日期的搜索，收费明细查询主要是通过对病人姓名和日期的搜索，来进行对其相对应信息的查询。
• 修改密码

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

3.1.2 医生信息管理

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

医院管理住院系统的研究与实现（论文+PPT+源码）

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

3.1.3 病床信息管理

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

医院管理住院系统的研究与实现（论文+PPT+源码）

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

3.1.4 病人信息管理

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

医院管理住院系统的研究与实现（论文+PPT+源码）

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

3.1.5 收费信息管理

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

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

3.1.6 统计分析管理

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

医院管理住院系统的研究与实现（论文+PPT+源码）

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

3.1.7 系统管理

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

医院管理住院系统的研究与实现（论文+PPT+源码）

图3-7 系统管理结构图

3.1.8 系统用例分析

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

1. 医生信息管理

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

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

（2）病人信息管理

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

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

（3）病床信息管理

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

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

（4）收费信息管理

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

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

（5）统计分析管理

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

医院管理住院系统的研究与实现（论文+PPT+源码）

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

3.2 非功能性需求

3.2.1 系统性能需求

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

3.2.2 系统安全性需求

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

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

3.2.3 系统设计需求

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

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

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

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

3.2.4 系统其它需求

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

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

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

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

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

3.3 系统的可行性分析

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

1、经济可行性

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

2、技术可行性

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

3、操作可行性

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

4、时间可行性

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

5、法律可行性

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

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

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

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

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

3.4 本章小结

本章主要介绍了系统的需求分析，其中主要包括两个方面：功能性需求分析和非功能性需求分析，并且还对可行性分析做了深入的研究。

第四章 系统总体设计

4.1 系统设计原则

在进行系统软件的设计中，要遵循一些原则和规范，这样才能规范设计流程，便于进行开发。本系统遵循着以下设计原则：

1. 良好的适用性。开发系统的目的是为用户服务的。也就是说我们所设计的软件需要满足用户的需求。因此本文的设计遵循的是用户需求优先的原则。
2. 结构稳定性。开发设计进行之前，需要设计系统的整体结构。一旦确定了体系的结构，这些设计便能流程化的进行。因此，维持一个稳定的结构才能保证后续一系列的工作的进行。
3. 可扩展性。衡量一个系统的好坏需要评估这个系统的可扩展性。如果软件只能实现现有的功能，对其他功能的添加有封闭性，当用户提出新的需求，只能重新设计，这显然是不合理的。因为良好的可扩展性无论对用户还是开发人员而言都是有益的。

(4)复用性。在一个系统中，有很多的模块内容是比较成熟，因此很多类似的工作就可以通过复用来实现，这样不仅提高了效率，而且可靠性也大大提高。

1. 易维护性。系统的维护往往是最耗费精力和金钱的。因此设计出易维护的系统能够使维护人员能够快速查找出问题，能让系统具备自维护的特点是很有必要的。[11]

4.2 系统框架

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

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

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

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

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

三、设计信息系统数据层

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

4.3 数据库的分析与设计

数据库简单的说其实就是长期存储的相关数据的集合，但它又不仅是局限于

对信息的存储，通过建立数据库，我们可以对数据更好的管理、存储以及查询，而且更为重要的是，我们还可以实现共享数据。数据库中的数据结构表明了具体事务之间的关系。而描述实体类型和实体之间关系的则称之为数据库模型，数据库系统主要包含四种数据模型它们分别是：层次模型、关系模型、网状模型和面向对象模型。所有的数据库系统都有它特有的数据模型。在本系统中，经过对系统数据库的功能特点以及对需求的分析，最终选择关系模型作为本系统的数据模型。[12]

4.3.1 数据库的概念结构设计

概念设计是进行系统设计的一个十分重要的阶段，概念设计主要完成的任务是在深入、详细了解系统的功能以后建立整个系统的概念模型和概念结构，然后将概念模型转换成图形的形式，一般来说，描绘概念模型的方法各式各样，比较常用的图形有ER图、类图等等，这里针对医院管理住院系统进行ER图（实体-联系图）来对整个系统进行展示。

4.3.2 E-R图

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

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

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

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

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

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

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

医院管理住院系统的研究与实现（论文+PPT+源码）

图4-1 医生E-R图

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

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

医院管理住院系统的研究与实现（论文+PPT+源码）

图4-3 病人E-R图

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

医院管理住院系统的研究与实现（论文+PPT+源码）

图4-4 收费E-R图

整体系统E-R图

图4-5整体E-R图

4.3.3 数据库的实现

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

1. 医生信息表
   表4-1 医生信息表

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

1. 病人信息表
   表4-2 病人信息表

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

表4-2 （续）

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

1. 病床信息表
   表4-3 病床信息表

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

1. 收费信息表

表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

4.3.4 数据库的连接原理

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

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

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

医院管理住院系统的研究与实现（论文+PPT+源码）

图4-7 DAO模式类图

4.4 系统软件结构设计

4.4.1 数据流程图

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

外部实体 加工 数据流

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

4.4.2 系统顶层图

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

医院管理住院系统的研究与实现（论文+PPT+源码）

图4-8 系统顶层图

4.4.3 系统零层图

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

图4-9 系统零层图

4.5 数据字典

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

1. 数据流

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

别名：无

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

来源：用户

去向：用户登录

数据流量：50份/天

组成：用户名+密码

数据流名称：医生信息

别名：无

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

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

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

数据流量：30份/天

组成：用户名+密码

数据流名称：病人信息

别名：无

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

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

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

数据流量：30份/天

组成：用户名+密码

数据流名称：收费信息

别名：无

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

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

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

数据流量：30份/天

组成：用户名+密码

（2）数据流分量

名称：用户名

别名：无

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

位置：用户信息表

用户登录信息

名称：密码

别名：无

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

位置：用户信息表

用户登录信息

名称：病人

别名：无

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

位置：病人信息表

病人一般信息

名称：医生

别名：无

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

位置：医生信息表

医生一般信息

名称：病床

别名：无

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

位置：病床信息表

病床信息

名称：收费

别名：无

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

位置：收费信息表

收费一般情况

（3）数据存储

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

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

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

关键字: 编号

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

P2（对信息表进行查询）

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

（4）处理

处理逻辑编号: P03-01

处理逻辑名称: 信息录入

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

输入的数据流:管理员

处理过程: 进行分类录入

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

处理逻辑编号: P03-02

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

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

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

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

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

处理逻辑编号: P03-03

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

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

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

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

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

4.6 本章小结

本章主要介绍了系统的总体设计，首先提出了系统设计的原则，然后分别从数据库的总体和设计、系统软件的结构设计以及数据字典三个方面对系统的设计展开了描述。

---

第五章 系统详细设计与实现

5.1 程序流程图

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

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

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

图5-2 系统登录图

5.3 系统主界面

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

图5-3 系统总界面图

5.4 医生信息管理

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

图5-4 医生信息管理图

图5-5 医生信息修改图

图5-6 医生信息添加图

5.5 病床管理

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

图5-7 病床信息管理图

图5-8病床信息修改图

图5-9 病床信息添加图

5.6 病人信息管理

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

图5-10 病人信息管理图

图5-11 病人信息修改图

图5-12 病人信息添加图

5.7 收费管理

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

图5-12 收费信息管理图

图5-13 收费信息添加图

图5-14 收费信息添加图

5.8 统计分析

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

图5-16 收费信息查询表

5.9 修改密码

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

图5-17 修改密码图

5.10 本章小结

本章主要介绍了系统的详细设计与实现，然后从各个模块的不同角度来对它们所要实现的不用功能进行了实现。

---

第六章 系统测试

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

6.1 系统测试目标

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

6.2 测试设计

6.2.1 测试用例设计

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

6.2.2 测试环境与需求

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

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

6.3 测试用例及测试模块

6.3.1 测试用例

注：测试用例的设计只针对病人信息管理功能子模块

表6-1 测试用例表1

测试用例ID	TC0001
测设用例名称	增加相同科别病床号病人的信息
产品名称	医院管理住院系统	产品版本	version 1.0
功能模块	增加病人信息模块	测试平台	所有
用例入库时间	2017.5.1	用例更新时间	2017.5.1
测试功能点	输入相同的科别病床号
测试目的	禁止添加相同科别病床号的病人信息
测试级别	详细功能测试
测试类型	单元测试
预置条件	数据库中已经有放射科科别为1病人的完整信息
测试步骤	输入相应的信息，科别为放射科病床号为1病人的完整的信息2.按“添加”按钮
预期结果	系统拒绝添加
测试结果	系统无法添加放射科病床号为1的病人信息

表6-2测试用例表2

测试用例ID	TC0002
测设用例名称	成功修改病人信息
产品名称	医院管理住院系统	产品版本	version 1.0
功能模块	修改病人信息模块	测试平台	所有
用例入库时间	2017.5.1	用例更新时间	2017.5.1
测试功能点	先查询要修改的病人信息，然后进行修改
测试目的	成功修改病人信息
测试级别	详细功能测试
测试类型	单元测试
预置条件	数据库中有相应的要修改的病人信息
测试步骤	1.输入科别+姓名或者病床，查询到要修改的病人信息2.点击“修改”按钮，对要修改的病人信息进行修改
预期结果	病人信息修改成功
测试结果	系统可以成功对病人信息进行修改并保存

表6-3 测试用例表3

测试用例ID	TC0003
测设用例名称	成功删除病人信息
产品名称	医院管理住院系统	产品版本	version 1.0
功能模块	删除病人信息模块	测试平台	所有
用例入库时间	2017.5.1	用例更新时间	2017.5.1
测试功能点	先查询要修改的病人信息，然后进行删除
测试目的	成功删除病人信息
测试级别	详细功能测试
测试类型	单元测试
预置条件	数据库中有相应的要删除的病人信息
测试步骤	1.输入科别+姓名或者病床，查询到要删除的病人信息2.点击“删除”按钮，删除相应的病人信息
预期结果	相应病人信息被删除
测试结果	系统可以成功删除所要删除的病人的信息

注：测试用例的设计只针对医生信息管理功能子模块

表6-4 测试用例表4

测试用例ID	TC0004
测设用例名称	增加相同科别编号医生的信息
产品名称	医院管理住院系统	产品版本	version 1.0
功能模块	增加医生信息模块	测试平台	所有
用例入库时间	2017.5.1	用例更新时间	2017.5.1
测试功能点	输入相同的科别编号
测试目的	禁止添加相同科别编号的医生信息
测试级别	详细功能测试
测试类型	单元测试
预置条件	数据库中已经有放射科编号为1医生的完整信息
测试步骤	1.输入相应的信息，科别为放射科编号为1医生的完整的信息2.按“添加”按钮
预期结果	系统拒绝添加
测试结果	系统无法添加放射科编号为1的医生的信息

表6-5 测试用例表5

测试用例ID	TC0005
测设用例名称	成功修改医生信息
产品名称	医院管理住院系统	产品版本	version 1.0
功能模块	修改医生信息模块	测试平台	所有
用例入库时间	2017.5.1	用例更新时间	2017.5.1
测试功能点	先查询要修改的医生信息，然后进行修改
测试目的	成功修改医生信息

表6-5 测试用例表5(续）

测试级别	详细功能测试
测试类型	单元测试
预置条件	数据库中有相应的要修改的病人信息
测试步骤	1.输入科别+姓名或者病床，查询到要修改的医生信息2.点击“修改”按钮，对要修改的医生信息进行修改
预期结果	医生信息修改成功
测试结果	系统可以成功修改医生的信息，并对其进行保存

表6-6 测试用例表6

测试用例ID	TC0006
测设用例名称	成功删除医生信息
产品名称	医院管理住院系统	产品版本	version 1.0
功能模块	删除医生信息模块	测试平台	所有
用例入库时间	2017.5.1	用例更新时间	2017.5.1
测试功能点	先查询要修改的医生信息，然后进行删除
测试目的	成功删除医生信息
测试级别	详细功能测试
测试类型	单元测试
预置条件	数据库中有相应的要删除的医生信息
测试步骤	1.输入科别+姓名或者编号，查询到要删除的医生信息2.点击“删除”按钮，删除相应的医生信息
预期结果	相应医生信息被删除
测试结果	系统可以成功删除医生的信息

6.3.2 测试模块及案例

注：此处有效等价类以当前创建表为标准，即我个人电脑中数据库中的内容。

（1） 数据库中病人信息表中的信息为：

医院管理住院系统的研究与实现（论文+PPT+源码）

图6-1 数据库病人信息图

（2）查询病人信息的测试

表6-7 病人信息测试表

输入数据	有效等价类	无效等价类
姓名	汉字（上表中的数据）	(2)字母(3)数字(4)除表中以外的汉字(5)空

用例编号	依次输入	期望结果	覆盖	实际结果
1	张三	通过验证，显示病人信息	1	查询成功
2	ZHANGSAN	不通过验证	2	查询失败
3	数字	不通过验证	3	查询失败
4	张强	不通过验证	4	查询失败
5		不通过验证	5	查询失败

注：此处有效等价类以当前创建表为标准，即我个人电脑中数据库中的内容。

（1） 数据库中医生信息表中的信息为：

、（2）查询医生信息的测试

表6-8 医生信息测试表

输入数据	有效等价类	无效等价类
姓名	汉字（上表中的数据）	(2)字母(3)数字(4)除表中以外的汉字(5)空

用例编号	依次输入	期望结果	覆盖	实际结果
1	李四	通过验证，显示医生信息	1	查询成功
2	LISI	不通过验证	2	查询失败
3	数字	不通过验证	3	查询失败
4	张强	不通过验证	4	查询失败
5		不通过验证	5	查询失败

6.3.3 系统性能测试

功能测试是为了某种的最基本需求，性能测试的目的是保证系统正常运转的关键一环。如表6-9所示：

表6-9 性能测试表

测试内容	测试要求	测试结论
对用户界面的控件以及数据接口的正确性进行测试	能不能使客户满意	通过
测试设计的界面是不是受到人们的喜爱	突出信息，设计新颖、风格一致	通过
测试系统操作是否简单	使客户使用起来比较方便	通过
对网络的安全性进行测试	在这个系统中安全软件能不能正常运转，这个系统能不能对不良信息进行过滤，防止不好的软件窃取它的信息。	通过
测试数据安全性	系统的数据要做到加密，外来的用户不能够进入这个系统获取这些数据。	通过
性能测试压力测试	能够协助人们进行办公。	通过
并发测试	当系统增加用户的时候，系统会产生什么样的反应，会不会出现卡顿的情况。	通过
稳定性测试测试系统的稳定性	长时间处在运行的状态下，系统能不能保证一直处在一种比较好的运行状态。	通过
测试系统的可靠性	当进入这个系统的人过多时，这个系统能不能正常运行。	通过
兼容性测试测试	这个系统能不能在不同的环境、操作系统以及浏览器上能不能正常工作。	通过
功能性测试	系统上的功能能不能满足医院需要的所有的功能。	通过

6.4 缺陷分析

经过测试，该程序中没有严重影响系统运行的错误，没有功能缺陷，也没有不影响运行但必须修改的错误。

测试模块都具有较好的交互性，出现错误可以提示用户哪里出错，使用户可以及时修改。

6.5 测试结果

从最终整体的实际运行效果来看，医院管理住院系统在实际的运行中达到了我们的最初设计目标，可以实现所有原先所预期得功能，满足了用户的需求。并且系统操作起来非常简单，十分易于管理，管理人员可以很容易掌握，再加上系统具有很高的安全性、可靠性和扩展性，完全能够达到医院所要求的各项指标，有效的提高了医院的工作效率和管理水平。

6.6 本章小结

本章主要介绍了系统测试方面的内容，并且通过测试进行了缺陷分析，并且得出了测试结果。

第七章 结束语

7.1 体会与收获

这一段时间的毕业设计使我收获颇多，在指导老师张泽华老师的帮助下，一步步的对整个项目进行了开展。从一开始的无从下手，然后慢慢地对系统的不断的分析和理解，直到最后对思路逐渐的清晰。当遇到一些困难时，会感觉有些迷茫，不知道从何写起；当一步一步把困难解决了以后，就会觉得豁然开朗，自己也收获了很多知识。在论文经过一次次的修改，逐步成型以后，自己也很有成就感。同时，我也在思考，毕业设计的完成预示着即将就要毕业了，踏入社会的大讲堂，开始了又一个人生的新旅程。因此，我应该对毕业设计做一个总结，画上一个完整的句号。其总结主要有以下几点：

1. 首先要做到的是准备充分，要明确自己的想法，而不是一上来就开始动手。选定题目和根据所选择的题目去做需求分析两者所用的时间应当是总开发时间的三分之一。只有充分了解自己的选题，把任务要求等一系列问题搞清楚，才可以做到事半功倍。在整个设计中，系统编码的完成所需要的时间并不会占用多少，占用大量时间的工作是搜集所需的资料和分析系统的设计。
2. 在设计系统的过程中，具体功能的实现要做到灵活，具备可扩展性。在设计的初期，许多设想都是不够合理的，必须得经过一次次的修改，这就需要初始框架具备可拓展性。在功能实现方面，要结合实际的情况，不要过分拘泥于单一的模式，要做到灵活、方便和快捷。

3.整个设计对我影响最深刻的一点就是要善于发现问题，善于提出问题。我们在大学四年的时间里，更多地接触的是理论性的知识，在实际的设计中，我们对于一个项目，要不断在其中寻找问题，并去解决它，只有这样，才可以把它设计的更加的完美，更好的适应市场的需要。

通过这次毕业设计，不仅把大学四年的理论知识重新复习巩固了一遍，而且也积累了一定的实际操作经验。在不断改正新问题的过程中，让我学会了要不断地去坚持，只有一次次的改正，才能把系统做得更加完善。同时也明白了，在设计的过程中，不仅仅要把课本上的知识看明白，还要具备一定的思维能力和动手实践能力，要把学到的知识灵活运用，才能够满足在设计过程中不同的需求。

7.2 不足

由于是第一次独自完成一个程序的设计，在很多方面都有一定的不足，思维不够全面，往往一个模块的实现需要进过很多次的修改，才可以把所想实现的功能全部的实现。在实现过程中，对于一些的功能的合理性并不能完全的把握到位，导致有时候会犹豫不决。而且，对一些大学所学到的知识产生了遗忘，需要不断的查阅课本知识，还有一些知识，自己并没有接触过，导致在完成的过程中会感到一些茫然。

7.3 今后的发展方向

在今后的学习中，要注重在平时对于知识的积累，理论是实践的基础，只有积累了一定的理论知识，才可以为后续的实践作出保障。还要注重对于自己思维能力的培养，在遇到问题时，不能选择逃避，要全面的思考出整个问题的解决方法。当然最重要的是要培养自己的动手能力，只有把自己的想法赋予实践，把真正想要的东西做出来，才是最重要的。

结论

本文主要研究的工作有如下几点：

1. 首先根据研究的课题进行深入的分析，了解清楚本系统的背景以及实现本系统的原因以及目的。根据所了解的内容确定出开发系统所需要采取的开发工具和实现方式。
2. 对系统进行需求分析和可行性研究，通过分析，确定出系统所要完成的具体问题，以及所要达到的具体效果。
3. 通过对整个系统的总体设计，绘制出系统的E-R图和流程图，确定出数据字典中所包含的具体信息。
4. 最后通过对系统的详细设计，完成系统最终的实践。
5. 为了测试出系统中所存在的缺陷，最终还进行了软件测试。

在对整个系统的实现过程中，由于经验的缺失以及能力的局限性，一些功能的实现存在一定的不合理性，距离真正的运用还存在一定的距离，这就需要自己不断地完善知识，掌握更多的方法和技巧，逐步完善本系统，争取让它达到市场的需要。

参考文献

1. 周苏. 王文. 软件工程学教程[M]. 北京: 科学出版社, 2002
2. 萨师煊. 王珊. 数据库系统概论[M]. 北京:高等教育出版社, 2003
3. 张海藩. 软件工程导论[M]. 北京: 清华大学出版社, 2003
4. 赵松涛. 中文版SQL Server 2005应用及实例集锦[M]. 北京: 人民邮电出版社,2005
5. 宣小平. 但正刚，张文毅. JSP数据库系统开发实力导航[M]. 北京:人民邮电出版社, 2003
6. 李明生. 试论医院医学知识管理[J].中华医院管理杂志,2002.
7. 曾长军. 朱剑锋，刘坤. SQL Server 数据库原理及应用[M] . 人民邮电出版社，2005.2.
8. 朱少民. 软件测试[M].人民邮电出版社，2009.8.
9. 徐敬. JSP架构下基于Web的信息管理系统框架研究[J]. 硅谷, 2015(1):84-85.
10. 王英龙. 张伟，杨美红. 软件测试技术[M]. 清华大学出版社，2009.
11. 张海藩. 软件工程[M]. 清华大学出版社，2010.6.
12. 许家珆. 曾翎. 软件工程—理论与实践[M].北京:高等教育出版社,2005.34.211.
13. 周典，陈伯钧. 医院知识管理与技术创新[D].中华医院管理杂志,2003.
14. 赵增敏. JSP动态网页设计[M]. 北京: 电子工业出版社, 2003.
15. Roger S-Pressman.Software Engineering[M].New Delhi:Tata McGraw-Hill PublishingCompany Ltd,2006.
16. C Kirkrgaard,A Ller.Static analysis for java servlets and JSP[M].International Conference on Static Analysis,2006.
17. A Steelman,J Murach.Murach’s Java Servlets and JSP,2nd Edition[M].Mike Murach&Associates,2008.

致谢

时光荏苒，岁月如梭，一眨眼，四年大学生活匆匆而去。驻足回首，紧张忙碌，丰富充实，历历在目，还未来得及仔细品味这同学谊、师生情，就要马上道别了，时下，各自在即将离别的惆怅中，又投入到紧张的论文答辩准备中。此时此刻，我诚挚的感谢对我本次论文指导的

本次论文的写作，从一开始的论文选题到整体内容的结构安排，再到具体文字的润色，老师耐心指导、层层把关，让我得以从一开始的无从下手到最终能够很好地完成论文的写作。在写作过程中，老师不辞辛苦，就论文中存在的问题不厌其烦的给予指导，并且给我提了很多实实在在的修改意见，力求让我的论文得以更加的完善。张泽华老师这种一丝不苟、精益求精的负责精神，让我非常钦佩、非常感动。在整个指导过程中，他一而再、再而三地教导我一定要恪守学术道德和规范，凭借自己的真才实学，认真完成系统的设计及论文的编写，这也为我以后的发展夯实了基础，所以，在此我再次向表示真诚的谢意！

还要感谢的就是实习基地指导老师 在系统的开发过程中就相关的技术性问题给予了许多指导与建议，使我的预期系统得以实现，在此，老师表示衷心的感谢！

除此之外，我还要感谢大学期间我的专业课老师们，正是他们呕心沥血、孜孜不倦的教诲，才让我收获到了丰富的知识，并且从他们身上学习到了很多做人的品质。当然这四年的生活，还要感谢我的大学同学，和他们互相帮助，共同成长，一同度过了这最难忘而又美好的四年时光。

最后，再次感谢老师对我的帮助和指导，感谢所有的同学和老师对我的关心！

外文原文

JSP and Servlets: A powerful pair

As many of you know, Servlet technology arose from the need to replace the Web server CGI with a more efficient, cross-platform mechanism. Servlets are written entirely in the Java TM programming language and often have HTML content embedded within the code. The JavaServer PageTM (JSP) technology takes the alternate approach, providing the developer with the ability to embed special tags and Java programming language code within the HTML. So what is the current state of affairs?

When Sun introduced JSP software, some were quick to claim that Servlets had been replaced as the preferred request-handling mechanism in Web-enabled enterprise architectures. However, if I were a Servlet, I might quote the illustrious Mark Twain; “rumors of my death have been greatly exaggerated.”

Although JSP technology will be a powerful successor to basic Servlets, the two have an evolutionary relationship and can be used in a cooperative and complementary manner. Furthermore, the JSP technology is a key component of the Java 2 Platform Enterprise Edition (J2EE) specification, serving as the preferred request handler/dispatcher and response mechanism. Figure 1 outlines the J2EE model and shows the JSP technology’s positioning among its components and services. My goal is to examine architectural issues as they relate to JSP software and Servlets, and to discuss some effective designs while looking at the tradeoffs of each.

JSP Technology—Why, What, When, and How?

The JSP technology specification has grown out of a technical need to allow developers to better separate dynamic content from static template display data, and to provide the developer with a more tool-friendly environment. Once we move in this direction, we will be able to more cleanly separate the role of a Web production/HTML designer from that of a software developer. In addition, JSP technology is platform independent, unlike some of its counterparts.

Utilizing JSP technology involves the creation of a text page that is compiled into a Servlet able to respond to HTTP requests by default. These compiled pages adhere to the Servlet API (version 2.1 or later), which includes some new useful features. Pages created that adhere to the JSP software specification contain two types of entities: elements, of which there are three, directive, scripting, and action; and template data, which is everything else on the page. The elements are interpreted and processed at runtime, while the template data may simply be static content that is passed through in the response.

Under the covers, the JSP framework actually creates a special type of Servlet whose runtime form is generated from the aforementioned text page via a technique known as page compilation. Thus, the development environment is much more tool-friendly than the basic Servlet environment, because JSP involves the manipulation of custom tags within standard markup. The JSP technology is a Standard Extension, as are Servlets, and both are compatible with the Java Runtime Environment 1.1 and beyond

Listing 1 provides a simple example of a server page that is compliant with JSP software version 1.0. Note that the version 1.0 specification introduces alternative XML syntax, and although this syntax will be preferred as the JSP technology evolves, currently it is optional.

The example in Listing 1 uses the Standard Action Type “usebean” that creates or retrieves the named class and assigns it the given id for use by the page. Expression elements are then used to retrieve data dynamically from the bean, convert the data into Strings, and create the page for display to the user. This simple example may pique your interest in how a page is ultimately transformed into a Servlet. Please refer to the JSP software specification for details.

Architectures

Before discussing architectures that we can use to build systems with these technologies, it is worth mentioning two basic ways of using the JSP technology.

The first method is what I refer to as the “page-centric” approach. This approach involves request invocations being made directly to a page with a .jsp extension. In the second method, which I call the “dispatcher” approach, a basic Servlet acts as a mediator or controller, delegating requests to .jsp pages and beans. Let’s look at some examples of these architectures and discuss their tradeoffs and usage.

Page-Centric

Page-View. This basic architecture involves direct-request invocations to a server page with embedded Java programming language code and/or special tags that dynamically generate output for substitution within the HTML. This approach has many benefits. It is very easy to get started and is a low-overhead approach from a development standpoint. All of the Java programming language code may be embedded within the HTML, so changes are confined to a limited area, reducing complexity. The big tradeoff here is in the level of sophistication. As the scale of the system grows, some limitations of this approach surface, such as repeating too much business logic in the page instead of factoring out to a mediating Servlet. Also, utilizing a Servlet as a mediator facilitates a potentially cleaner separation of developer roles—see the Separation of Developer Roles sidebar for details.

Separation of Developer Roles

On any Web-based project multiple roles and responsibilities will exist.

For example, an individual who designs HTML pages fulfills a Web production role, while someone who writes software in the Java programming language fulfills a software development role.

On small-scale projects, these roles might be filled by the same individual or two individuals working closely together. On a larger project these roles will likely be filled by multiple individuals, who should not necessarily have overlapping skill sets and will be less productive if made too dependent on the workflow of the other.

If code that could be factored out to a mediating Servlet is included instead within the HTML markup, then the potential exists for individuals in the software development role and those in the Web production role to become more dependent than necessary on the progress and workflow of the other.

Dispatcher

Mediator-View. Figure 2 shows the Mediator-View architecture. A Servlet acts as a mediator, working with a .jsp page and worker bean to fulfill a service request. The swimlanes in Figure 2 illustrate how each service is partitioned. The Servlet initially handles the request and delegates to a JSP software page/worker bean combination. The JSP populates bean properties from the request parameters and then uses the bean to prepare the data for presentation. The worker bean interacts with a component that is a client-side business abstraction used to complete the basic business processing. The .jsp page then retrieves the relevant state from the bean to dynamically generate the output view for display.

Using the RequestDispatcher

The Servlet API version 2.1 introduces the RequestDispatcher.
Example usage with a Servlet:

RequestDispatcher dispatcher = getServletContext()

.getRequestDispatcher(“authComplete.jsp”);

request.setAttribute(“auth”, auth);

dispatcher.forward(request, response);

This service is handled first by a basic Servlet that dispatches to a JSP software page for formatting and display. See the RequestDispatcher sidebar for details on how a Servlet handles the dispatching of a request to another resource. The JSP software page is responsible for delegating the processing of business functionality to a client-side business abstraction via a worker bean, which acts as a façade for the back-end resources. The worker bean and the business delegate reduce coupling between the client request and the ultimate back-end resource. In other words, the public interfaces need not change even if the API to the underlying resource changes. The worker beans might communicate through the business delegate with the back end via Enterprise JavaBeanTM (EJB) components running in a scalable, load-balancing container. Also, the worker beans can be combined with different JSP software pages to provide different views of the same underlying information.

An interesting aspect of these “dispatcher” designs is that they can be combined in a flexible and powerful way. For example, if you wanted each page access to be authenticated, you would have to duplicate the authentication code in each accessed .jsp page. Using a Servlet, you can authenticate in one place and forward to the relevant .jsp page. This gives a much cleaner and modular approach

The benefit of a Dispatcher approach is in the control the Servlet has over the request. Because the Servlet acts as the mediator, there is central forwarding control. This also creates a nice role separation between the lower-level coding in the Servlet and the .jsp coding. A drawback of this architecture is that it is more complex and involves more design work and more coding, because individual beans are created instead of code fragments. A very simple project might be burdened by this extra overhead, while more sophisticated efforts will benefit from the cleaner design.

Mediator-Composite View.

This is a variant of the Mediator-View architecture and is useful for building systems with dynamic template text and dynamic content. As shown in Figure 3, the Servlet mediator dispatches to a page with the .jsp extension, which imports static and dynamic resources. A static resource might be an HTML fragment that represents a page header or footer. A dynamic resource could be another marked-up page created with the .jsp extension. This included page might also import static and dynamic resources. Figure 3 shows this nested server page, including dynamic content generated via an invocation on a helper bean, which gets to the business processing through a delegate, which once again acts as a façade to the back-end resource that may be “wrapped” in an EJB component.

The role of the delegate, as a client-side business abstraction layer, is to make business calls on the actual back-end resource, such as remote invocations on an EJB component. The role of the worker bean is to service the .jsp page, preparing data for use and dynamic presentation by the page. We create a more flexible architecture by abstracting out the worker bean and the business delegate, so that the model for the .jsp page is not actually responsible for remote invocations on business resources.

Figure 3 uses the example of a shopping site checkout page, where the user is presented with the contents of a shopping cart. The Servlet might verify the user’s authentication and role before dispatching to the .jsp page. The initial page might have some standard header and footer information for the user about the process of checking out. The body of this page is generated from a nested page that could represent a fairly course-grained entity, such as the complete line-by-line inventory of the items that the cart contains. This nested page might also have some header and footer information, such as the respective tags for starting and ending a table. The body of this page is dynamically generated via indirect communication with a back-end resource.

The Servlet can have overall responsibility for the service, dispatching to the initial .jsp page via a RequestDispatcher.include() method invocation. In this case the Servlet handles the response to the client and thus has the opportunity to do any sort of clean-up after all the nested invocations are completed. Another possibility is that the initial .jsp page will handle the response, as shown in Figure 3, in which case the Servlet will have completed its work once it dispatches to the server page with a RequestDispatcher.forward() method invocation.

A side effect of implementing this architecture is that the JSP software will not need to be recompiled each time the dynamic template text changes. Such flexibility is useful, especially because the current JSP technology specification does not require pre-compilation. This flexibility does, however, come at a price because it involves runtime inclusion of text, which incurs some overhead

Service to Workers.

Figure 4 shows another dispatcher type of architecture. A service is handled first by a basic Servlet that delegates the processing of business functionality to a business delegate via a worker bean and then dispatches to a server page for formatting and display. This type of architecture might be leveraged in cases where the model can be fully populated prior to display; for example, if one wants to fully populate a model and then dispatch to a server page, which will request state from the model to dynamically generate the view.

Unlike the previous architectures, the controller Servlet interfaces initially with worker beans as opposed to a .jsp page. This architecture also provides for a cleaner separation between the view and the controller, because the .jsp page is no longer making business calls, but rather, is accessing the state of the pre-populated worker bean.

Future

Having looked at a variety of ways to use JSP technology and Servlets, it is useful to remember there are more ways to architect systems with these technologies. Utilizing XML as a formatting and conversion tool within the JSP framework is one interesting area that was not discussed. As the JSP technology evolves, XML is sure to play an ever-increasing role, along with XSL/XSLT, which allows for data transformation and conversion. Additionally, the forthcoming tag extension mechanism in version 1.1 of the specification will allow for portable extensions to the environment.

中文翻译

JSP和Servlet：一个强大的组合

正如许多人所知，Servlet技术源于需要对使用更高效的跨平台机制而用来替换Web服务器的CGI。Servlet是完全由在java编程语言编写的TM和经常有HTML内容嵌入的代码。JavaServet的PageTM（JSP）技术作为替代方法，提供给开发者嵌入特殊标签和java编程语言代码的HTML的能力。那么目前的状况是什么？

当sun公司介绍JSP软件，马上有的人声称servlet被作为首选的请求在Web处理机制使企业架构被所取代。然而，如果让我形容servlet，我可以引用著名的Mark Twain的话：“我死的传闻被大大夸大了。”

尽管JSP技术即将是一个对于基本servlet的强大继任者，但是两者进化的关系，可以描述为合作和互补的方式。此外，JSP技术是Java 2平台企业版（J2EE）规范的一个重要组成部分，作为首选的请求处理/调度和响应机制。它概述了J2EE模型，并展示了JSP技术在组件和服务中的定位。我的目标是研究软件工程问题涉及到的JSP软件和servlet，并探讨一些有效的设计并且权衡每个点。

1. JSP技术的3W1H（Why, What, When, and How?）

到目前为止，JSP技术规范已经摆脱了技术上的需要，允许开发人员更好地从静态模板显示的数据中分离动态的内容，并为开发人员提供一个更友好的工具环境。一旦我们朝这个方向前进，我们将能够更清晰地将Web产品/ HTML设计的角色与软件开发人员分开。此外，JSP技术是独立于平台的，不像它的一些同类技术。

利用JSP技术去创建一个文本页，该页面被编译成servlet，默认的情况下能够响应HTTP请求。这些编译的页面使用servlet API（版本2.1或更高版本），其中包括一些新的有用的功能。根据JSP软件规范而创建的页面包含两种实体：一种是元素，元素其中有三类，指令，脚本和动作，另一种是模板数据，这是页面上的所有其他内容。元素在运行时被解释和处理，然而模板数据可能只是静态内容，在响应之中传递。

在覆盖的条件下，JSP框架实际上是创建了一种特殊类型的servlet，其运行时，窗体会由前面的文本页通过一个名为页编译的技术去生成。因此，开发环境比基本的servlet环境更友好，因为JSP涉及到标准标记内制定的标签操作。JSP技术是一种标准的扩展，如servlet都兼容甚至超越java版本的运行环境。

清单1提供了一个与JSP软件版本1兼容的服务器页的简单示例。注意，这里的示例引入了另外一种XML语法，尽管这种语法将随着JSP技术的发展而被逐渐优化代替，但现在它是可利用的。

但是示例中使用标准动作类型的核心，创建或检索指定的类并将其分配给主要使用的页。然后使用表达式元素从bean中动态的检索数据，进一步将数据转换为字符串，并创建表示页面以显示给用户。这个简单的例子可能激起你对页面最终如何转化为servlet的兴趣。详情请参阅JSP软件规范。

2.架构

在讨论如何使用这些技术构建系统的体系结构之前，值得一提的是使用JSP技术的两种基本的方法。

第一种方法是我所说的“以页面为中心”的方法。这种方法涉及到请求调用，这种调用被直接指向一个JSP的扩展。在第二种方法中，我把它称之为“调度”方法，基本的servlet充当调解人或者控制器，将请求分配给JSP页面和bean。让我们了解这些架构的一些例子，并讨论他们的权衡和使用。

3.页面核心

页面极为视图。这一基本的架构涉及到直接请求调用一个嵌入式的java编程语言代码或者是一种特殊的标记，动态生成并且输出替代服务器网页的HTML页面。这种方法有许多好处。从开发的角度来看，它很容易上手，是一种低开销的方法。所有的java编程语言的代码可以被嵌入在HTML页面里，所以变化局限在一个有限的区域力，从而降低了程序的复杂性。这里的平衡在于复杂程度。随着系统规模的增长，这种方法的某些局限性随之出现了，例如在页面中重复过多的业务逻辑，而不是将这些业务逻辑分解为中介的servlet。此外，利用servlet作为调解人有利于一个潜在的更清洁的功能，即是分离开发人员的看到的，还有分离的开发者角色侧边栏的细节。

4.开发者角色区别

在任何基于Web的项目开发中，将存在多个角色或者多个职位。

例如，一个项目团队谁设计的HTML页面，完成网站制作和使用，或者谁来完成软件程序，利用java编程语言完成软件开发中的作用。

在小规模项目中，这些角色可能由同一个人或两个人紧密合作而完成。但是，在一个更大的项目中，这些角色可能会被多个人合作填充完成，他们不一定会有重叠的功能模块，如果过于依赖其他的工作流程，那么他们的工作效率就会大大降低。

如果代码可以分解到中介servlet，而不是在HTML标记，那么潜在的开发人员将在软件开发过程中所扮演的角色和那些在Web生产中的角色会变得更加依赖于必要的进度和工作流程。

5.控制中心

中介视图,就像图中显示的中介视图体系结构一样。servlet充当中介，与JSP页面和工作bean一起完成服务请求。图中的业务说明每个服务的划分。servlet最初将处理这些请求并且委托给JSP软件页面/工作人员bean组合。JSP填充bean的属性从请求参数开始，然后使用bean来准备数据报告。工具bean与用于完成基本业务处理的客户端业务抽象的组件进行相互交互。然后JSP页从bean中检索相关的状态，以动态生成的方式去显示并且输出视图。

6.使用RequestDispatcher

Servlet API 2.1版介绍了RequestDispatcher。

servlet的示例用法：

RequestDispatcher dispatcher = getServletContext()

.getRequestDispatcher(“authComplete.jsp”);

request.setAttribute(“auth”, auth);

dispatcher.forward(request, response);

该服务首先由一个基本的servlet处理，该servlet发送给JSP软件页面进行格式化处理和显示。看看如何处理调度servlet，同时请求另一个资源细节RequestDispatcher的侧边栏。JSP软件页面负责将业务功能处理客户端的业务抽象的通过机器去处理，它充当一个ADE为后端资源开发。业务Bean和业务委托减少客户端请求，并且最终与后端资源之间相耦合。换句话说，即使基础资源的API更改，公共接口也不需要更改。人工处理通过与后端的业务，通过企业javabeantm（EJB）在创建一个可扩展的运行组件负载平衡容器。此外，工作bean可以与不同的JSP软件页面相结合，从而提供相同的基础信息和不同的视图。

这些“调度”设计的一个有趣的地方是，它们可以结合在一个灵活并且强大的地方。例如，如果您希望每个页面访问进行身份的验证，则必须在每个访问的JSP页面中复制验证代码。使用servlet，您可以在一个地方进行身份验证并跳转到相应的JSP页面。这样给出了一个更清洁和模块化的方法。

这种调度方法的好处在于servlet对请求的控制方面。因为servlet充当中介，所以有中央转发控制的特点。这也创造了一个良好的角色分离，同时分离了在servlet和JSP中的编码。这种体系结构的缺点就是，它会更加复杂，并且涉及到更多的设计工作和更多的编码，因为单独的bean被创建，而不是代码片段。一个非常简单的项目可能会负担额外的开销，而更复杂的努力将受益于更简洁的设计。

7.中间合成体系

这是中介视图体系结构的一个变体，对于构建动态模板的文本和动态内容的系统非常有用。就像图中所示的一样，servlet调度到一个带有JSP扩展名的页面，该页面导入静态和动态资源。静态资源可能是用来表示页眉或页脚的HTML片段。然而动态资源可以是由JSP扩展而创建的另一个标记上的页面。包括页面也可能导入静态和动态资源。图中显示了这种嵌套的网页服务器，它包括了动态的内容通过一个辅助bean 的调用而产生，从而通过获取业务处理的一个委托，再次作为一个çADE的后端资源，这种可能是“包裹”在一个EJB组件中。

代理的角色，作为一个客户端的业务抽象层，使业务电话在实际的后端资源中，如何对EJB组件进行远程的调用。工具bean的作用是服务JSP的页面，为页面的使用和动态呈现准备数据。我们通过抽取人工工作和业务委托创建一个更灵活的架构，从而产生这样的模型。JSP页面实际上不负责对企业资源的远程调用。

在图中使用购物网站结帐页的示例，是用户在其中呈现购物车的内容。在发送到JSP页面之前，servlet可能会验证用户的身份信息。初始页面可能有一些标准的页眉和页脚信息，以便用户去检查的过程。此页面的主体试由一个嵌套的页生而生成，该页可以表示一个相当细的粒度实体，如购物车包含的项目中完整的逐行库存。此嵌套页面还可能具有一些页眉和页脚信息，如用于启动和结束表中的相应标签。此页面的主体通过与后端资源的间接通信而动态生成。

Servlet可以作用于服务器的整体，从调度的初始。JSP页面可以通过RequestDispatcher include()方法去调用。在这种情况下，servlet处理完成对客户端的响应，从而有机会做清理任何所有嵌套的调用页面。另一种可能性是，一开始，JSP页面将处理响应，就像图中表示的一样，在这种情况下，一旦部署服务器页面RequestDispatcher forward()方法调用，servlet将已经完成了它的工作。

该体系的实现还存在着一个副作用，即JSP软件不需要重新编译每一次动态模板文本的变化。这种灵活性的性质是有用的，特别是因为当前JSP技术规范不需要预编译的时候。然而，这种灵活性是有代价的，因为它涉及到运行时包含的文本，这会导致一些系统的开销。

8.服务—开发员

图中显示了另一种调度类型的体系结构。服务首先要由基本servlet处理，该基本servlet通过业务bean将业务功能的处理委托给业务功能，然后分派给服务器页面进行格式化过程和显示。这种类型的架构可能会在被利用的情况下，模型可以充分填充之前的显示，例如，如果一个人想完全填充模型，然后调度到服务器的页面，这将要求从模型的状态动态生成视图。

与以前的体系结构不同，控制器servlet最初与工具bean相链接，而不是JSP页面。这种架构还提供了视图和控制器之间的一个更简洁的分离，因为JSP页面不再是业务调用，而是访问预填充的工具bean的状态。

9.未来的发展

看了各种使用JSP技术和Servlet的方式，它们大多数是要记住有更多的方式来架构系统这些有用技术。在JSP框架中使用xml作为格式和转换工具是一个没有讨论作用的领域。随着JSP技术的发展，XML肯定会起到越来越重要的作用，它与XSL / XSLT一起，允许数据的转换。此外，对于即将到来的标签扩展机制，将在1.1版的规范将允许便携式的扩展到环境。