基于面向对象的医院收费管理信息系统的分析与设计.doc

重庆邮电大学移通学院毕业设计（论文） 摘 要 【摘要摘要】医院信息系统属于迄今世界上现存的企业级信息系统中最复杂的一类。 传统的基于客户机/服务器的 HIS 产品开发周期长，而且功能上也不够完善，存 在着诸如系统响应速度慢，难以集中控制，可扩展性差等各种各样的问题。因 此，需要一种科学的方法来分析和设计医院信息系统。本文讨论的医院门诊收 费系统就采用了面向对象建模的技术和方法，能够较好地捕捉用户的需求，为 系统的成功开发和软件的后期维护莫定了良好的基础。 本文利用面向对象技术分析和设计了医院收费管理信息系统，包括从需求 分析、架构设计、测试提交，完成门诊收费系统，具体有：在需求模型中，通 过用例图从外部用户的角度来捕获系统、子系统或类的行为；在系统分析模型 中，主要通过顺序图描述对象间的交互关系、对象的生命周期以及生命周期中 对象可能存在的状态以及状态间的转换约束；在系统设计模型中，通过类图定 义系统对象及对象间的静态关系；在系统体系架构模型中，通过系统体系架构 图来描述系统的多层体系架构；在系统实现模型中，通过配置图描述软件体系 架构、硬件体系架构以及通信机制。 【关键词关键词】门诊收费系统，UML，面向对象 重庆邮电大学移通学院毕业设计（论文） Abstract 【Abstract】Hospital information system is by far the worlds most complex existing enterprise information systems. Traditional client / server-based HIS product development cycle, and the function is not perfect, there is a slow speed, such as system response, it is difficult to centralized control, scalability, and poor variety of problems. Therefore, you need a scientific approach to analysis and design of hospital information systems. This article discusses the hospital outpatient charges on the use of object-oriented modeling techniques and methods, and better able to capture the users needs, and laid a good foundation for the latter part of the success of the system development and software maintenance. In this paper, object-oriented technology analysis and design of hospital charges and management information systems, including requirements analysis, architecture design, test submitted to complete the out-patient charges system, specifically: the demand model, through the use case diagram from the perspective of external users to capture system, subsystem, or class of acts; in the system analysis model, mainly through the sequence diagram describes the interactions between objects, object life cycle, and the status of objects that may exist in the life cycle and transitions between states are constrained; in the system design model defined by the class diagram in the system objects and the static relationships between objects; system architecture model, system architecture diagram to describe the system multi-layer architecture; describes the software architecture, system implementation model, the configuration diagram hardware architecture and communication mechanisms. 【Key Words】 Out-patient charges system; UML; Object-oriented 重庆邮电大学移通学院毕业设计（论文） 目录 目目 录录 前前 言言.1 第第 1 章章 绪论绪论.3 1.1 医院收费管理系统的背景.3 1.2 医院收费管理系统的主流技术.4 1.3 本文的组织结构.4 1.4 本章小结.5 第第 2 章章 面向对象技术面向对象技术.6 2.1 面向对象技术的介绍 .6 2.2 面向对象与结构化比较的优缺点.7 2.3 本章小结.8 第第 3 章章 基基于面于面向向对象的系统分析对象的系统分析.9 3.1 系统问题描述.9 3.2 系统需求分析说明.10 3.2.1 系统功能性需求.10 3.2.2 系统非功能性需求.10 3.3 医疗系统的静态建模.11 3.3.1 确定系统用例图和流程图.12 3.3.2 门诊病人类图.15 3.3.3 收费项目类图.17 3.3.4 用户管理类图.18 3.4 医疗系统的动态建模 .20 3.4.1 病人交费的时序图.20 3.4.2 收费员结账的时序图.21 3.4.3 系统管理员用户维护的时序图.22 3.5 本章小结.23 第第 4 章章 系统设计与布置系统设计与布置.25 4.1 系统设计的原理.25 4.1.1 系统设计的原则.25 4.1.2 基本功能和运行规则.26 4.2 系统的架构布置.27 4.3 本章小结.38 第第 5 章章 结论结论.39 致致 谢谢.41 参考文献参考文献.42 附附 件件.44 重庆邮电大学移通学院毕业设计（论文） 目录 一、英文原文.44 二、英文原文.49 重庆邮电大学移通学院毕业设计（论文） 前言 前前 言言 在研究本文之前，经过调查系统越来越不能适应医疗形势的发展和医院管 理的要求，服务器不堪重负，系统运行速度越来越慢。虽然服务器在 1999 年系 统实施时进行了更换，并于 2003 年又进行了新的更换，但是由于二层架构的固 有的架构性缺陷，业务逻辑、数据库逻辑都集中在服务器上，势必给服务器造 成极大的压力，使系统运行速度过慢，甚至死机1。医院的业务量也不断增长， 门诊量也不断增长，业务量的加大，数据库的不断膨胀，严重地影响了系统的 相应速度。 医疗改革步伐加快，不能提供有效的数据支持。最近几年，国家进行了城 镇医疗制度改革，实行了新型农村合作医疗制度。另外，由于越来越多的病人 加入医疗保险，医院也有责任向保险公司提供病人的治疗说明清单或数据接口。 最后，国家物价管理和医改要求医院严格按照收费细目收费，导致系统检索速 度降低。 不能适应医院信息管理不断深入，管理政策不断调整的需要。随着医院联 网规模的不断扩大，要求实施门诊医生站、医技工作站和实验室系统(LIS),这就 要求门诊收费程序能够直接调用医生站录入的数据，并向医技工作站和 LIS 提 供收费数据供其核对，而原有系统在开发时并没有考虑对这些系统的支持。另 外，医院管理的改革需要门诊收费系统能够向管理者提供更多、更细的报表， 而原有系统没有专门的报表设计软件，要设计新报表就必须修改源程序，作为 购买的商品软件，有没有源代码，因此，对于管理者新提出的报表，系统无法 实现，单位维护人员也无能为力。 系统的开发基于三层 C/S/S 体系架构，并且采用目前比较先进的 COM+技 术规范进行设计实现，加快了开发进度，并且使系统具有高效率，可扩展性， 安全性等优势。本文在分析了体系架构发展过程后，先介绍了客户机/服务器体 系结构及其优缺点。传统的客户机用及务器体系结构把用户界面和业务逻辑都 重庆邮电大学移通学院毕业设计（论文） 前言 放在客户端，虽然结构简单，但带来了难以集中控制、安全性差、客户端负担 大等原生性问题。接着介绍了三层体系架构及其运行机制和优点2。三层体系 架构将应用系统分成三层:用户界面层、业务服务层、数据服务层。用户界面层 提供相应的用户界面，主要负责收集用户提交的数据，检验数据的格式正确性， 调用相应的中间层组件方法;处理组件返回的数据，进行显示等功能，这一层用 Delphi7.0 开发。业务服务层负责处理用户界面层的应用请求，完成商务逻辑的 计算任务，并将处理结果返回给用户。业务服务层是将原先置于客户端的业务 逻辑分离出来，集中置于服务器部分，为所有用户共享。用户服务层、业务服 务层、数据服务层三层的相互独立加上 COM 十组件的三大特性：语言无关性、 进程透明性和可重用性，使系统解决了客户机/服务器体系结构其原生性问题。 在掌握了基于三层 C/S/S 架构体系后，可以使用它来设计系统。在分析医院门 诊收费的主要业务逻辑和工作流程后，设计后台数据库结构，尽量保证数据的 完整性。在实现的过程中，涉及许多与组件开发相关的关键技术。我们给出三 层体系架构中每层的实现方法和关键代码，然后对系统开发中应用程序服务器 的容错性、访问权限的控制、系统的可扩展性和可维护性进行了初步的探讨， 并给出了相应的处理方案。最后对本文进行了总结，说明了系统运行的效果和 设计过程中有待完善的地方。 重庆邮电大学移通学院毕业设计（论文） 第 1 章 绪论 3 第第 1 章章 绪论绪论 1.1 医院收费管理系统的背景医院收费管理系统的背景及意义及意义 随着社会的发展，人们对健康越来越关注，医院的业务不断增长，处理越 来越复杂，简单的人工经营管理，已无法满足医院的需要, 成为医院发展的瓶 颈， 人们对医疗服务的要求也越来越高。传统的手工操作模式，病人账目繁杂， 病人查帐困难, 病区和药房的药品浪费现象严重且无法追踪, 人工传送各种记账 单容易漏错帐，人工划价收费差错也难以避免。因此，如何提高服务水平、提 高工作效率，成为迫待解决的问题。医院管理信息化不仅能提高医务人员的工 作效率和医疗水平，而且能提高医院的服务质量和管理水平，所以，医院对管 理信息系统有着强烈的需求。美国著名教授 Morris.Collen 于 1988 年曾著文为 医院信息系统(HIS)下了如下定义：利用电子计算机和通讯设备，为医院所属各 部门提供病人诊疗信息和行政管理信息的收集、存储、处理、提取和数据医疗 交换的能力，并满足所有授权用户的功能需求3。 开发医院管理信息系统(HIS) 的目标就是立足医院应用实际，着眼于未来发展，以强化医院管理，提高医疗 质量，方便患者就医和查询，提高医院的服务效率和服务质量，设计一套符合 国家功能规范要求，安全稳定，操作简便的医院信息系统，为医院提供一套全 方位的解决方案。 医院管理信息系统是利用计算机软硬件技术、网络通讯技术等现代化手段， 对医院及其所属各部门(本系统不包含门诊部分)的人流、物流、财流进行综合 管理，对在医疗活动各阶段中产生的数据进行采集、存贮、处理、提取、传输、 汇总、加工生成各种信息，从而为医院的整体运行提供全面的、自动化的管理 及各种服务的信息系统。本文简单研究了医院出入院处、挂号、药房、收费的 业务流程，在整体分析医院各部门以及部门之间的实际工作业务的基础之上， 结合管理信息系统开发的理念，利用面向对象软件设计整个信息管理系统。 费用信息是在病人诊治活动背后发生的，是与病人信息并行的一条线。病 重庆邮电大学移通学院毕业设计（论文） 第 1 章 绪论 4 人的费用信息分布在各个业务系统中。这条线包括门诊病人收费、住院病人收 费、药品管理、器械管理、成本核算等。它包括收入和支出两个方面，其中经 济核算是核心。 费用信息是追踪病人整个诊疗过程中产生的费用流动过程，以 押金费用、药品费用、检查检验费用、治疗费用等费用信息为主体，以这些费 用的产生、变化、审核、结账等为主要处理过程、整个费用信息结构以经济核 算为中心。 1.2 开发医院收费管理系统的主流技术开发医院收费管理系统的主流技术 当今社会，在计算机行业中，有着多种开发语言，如 JSP、VC+、VB、OPEGL 等，它们都拥有各自的优势。就 JSP 而言，它是一 种动态网页技术标准，是基于 JAVA 技术的动态网页解决方案，具有良好的可 伸缩性，在网络数据库应用开发方面有得天独厚的优势；又如 VC+,它是面向 对象的可视化集成编程系统。它具有程序框架自动生成、灵活方便的类管理、 代码编写和界面设计集成交互操作、可开发多种程序等优点。对于本系统，本 论文采用了面向对象技术，原因在于它具有抽象性、封装性、继承性和多态性， 若在以后使用过程中出现了问题或者瑕疵，开发者能够在第一时间将其处理。 通过面向对象技术开发此医院收费管理信息系统，能有效的节省人力物力， 对各个中小型医院利益增加百利而无一害。 1.3 本文的组织结构本文的组织结构 第一章是绪论，简要介绍了医院收费管理系统的背景和主要技术，为论文 后面的续写买下伏笔。 第二章主要解释了什么是面向对象技术，并且比较了面向对象技术与结构 化技术的优缺点，体现了本论文研究主题的优越性。 第三章主要利用面向对象技术进行的系统分析，表述了对此技术的需求分 析说明，并给出了系统的静态建模和动态建模。 第四章主要利用面向对象进行系统的设计与布置，辅助 UML 图阐述系统 重庆邮电大学移通学院毕业设计（论文） 第 1 章 绪论 5 设计的原理与步骤。 第五章主要对本文主要工作做了总结。 1.4 本章小结本章小结 本章是论文的第一章，首先介绍了论文的背景和意义，接着简单阐述了开 发医院收费管理系统的主流技术；最后给出了本文的组织结构。 重庆邮电大学移通学院毕业设计（论文） 第 2 章 面向对象技术 6 第第 2 章章 面向对象技术面向对象技术 2.1 面向对象技术的介绍面向对象技术的介绍 面向对象技术强调在软件开发过程中面向客观世界或问题域中的事物，采 用人类在认识客观世界的过程中普遍运用的思维方法，直观、自然地描述客观 世界中的有关事物。面向对象技术的基本特征主要有抽象性、封装性、继承性 和多态性。抽象性是把众多的事物进行归纳、分类是人们在认识客观世界时经 常采用的思维方法， “物以类聚，人以群分”就是分类的意思，分类所依据的原 则是抽象。 抽象（Abstract）就是忽略事物中与当前目标无关的非本质特征，更充分地 注意与当前目标有关的本质特征。从而找出事物的共性，并把具有共性的事物 划为一类，得到一个抽象的概念。封装性是把对象的属性和行为结合成一个独 立的单位，并尽可能隐蔽对象的内部细节。封装有两个含义：一是把对象的全 部属性和行为结合在一起，形成一个不可分割的独立单位。对象的属性值（除 了公有的属性值）只能由这个对象的行为来读取和修改；二是尽可能隐蔽对象 的内部细节，对外形成一道屏障，与外部的联系只能通过外部接口实现。继承 性是是一种联结类与类的层次模型。继承性是指特殊类的对象拥有其一般类的 属性和行为。继承意味着“自动地拥有” ，即特殊类中不必重新定义已在一般类 中定义过的属性和行为，而它却自动地、隐含地拥有其一般类的属性与行为。 继承允许和鼓励类的重用，提供了一种明确表述共性的方法。一个特殊类既有 自己新定义的属性和行为，又有继承下来的属性和行为。尽管继承下来的属性 和行为是隐式的，但无论在概念上还是在实际效果上，都是这个类的属性和行 为。当这个特殊类又被它更下层的特殊类继承时，它继承来的和自己定义的属 性和行为又被下一层的特殊类继承下去。因此，继承是传递的，体现了大自然 中特殊与一般的关系。多态性是是指类中同一函数名对应多个具有相似功能的 不同函数，可以使用相同的调用方式来调用这些具有不同功能的同名函数4。 重庆邮电大学移通学院毕业设计（论文） 第 2 章 面向对象技术 7 继承性和多态性的结合，可以生成一系列虽类似但独一无二的对象。由于继承 性，这些对象共享许多相似的特征；由于多态性，针对相同的消息，不同对象 可以有独特的表现方式，实现特性化的设计。 2.2 面向对象与结构化比较的优缺点面向对象与结构化比较的优缺点 二者在分解和抽象原则上一致；分解和昂是软件中控制问题复杂性的重要 原则。分解即化整为零，将问题剥丝抽茧，层层细化，抽象则是通过分解体现， 在组层分解时，上层是下层的抽象，下层是上层的具体解释和体现，运用抽象 可以不用一次考虑太多细节，而逐渐的有计划有层次的了解更多细节。面向对 象方法与结构化在运用分解和抽象原则上的要求是完全一致的。 局部化和重用性设计上的一致；局部化是软件开发中的一个重要原则，即 不希望软件一部分过多的设计或影响软件的其他部分。也就是说面向对象方法 比结构化方法的运用更加深入更彻底。 处理问题是的出发点不同；结构化方法是强调过程抽象化和模块化，以过 程为中心构造或处理客观世界问题的，它是一种面向过程的开发方法；面向对 象方法强调把问题域的要领直接影射到对象之间的接口上，是用符合人们通常 的思维方式来处理客观世界的问题。 数据处理方式与控制程序方式不同；结构化方法是直接通过程序来处理数 据，处理完毕后即可现实处理结果，在控制程序方式上是按照设计调用或返回 程序不能自由导航，各模块程序之间存在着控制与被控制的关系；面向对象方 法将数据与对应的代码封装成一个整体，原则上其他对象不能直接修改其数据， 即对象的修改只能由自身的成员函数完成，控制程序方式上是通过“事件驱动” 来激活和运行程序。 结构化方法和面向对象方法的优缺点主要体现在如下几个方面：从执行效 率来说；结构化方法比面向对象方法产生的可执行代码更直接、更高，所以对 于一些嵌入式的系统，结构化方法产生的系统更小，运行效率更高。从重用性 方面来说；采用结构化方法的系统难以修改和扩充，结构化分析与设计清楚定 重庆邮电大学移通学院毕业设计（论文） 第 2 章 面向对象技术 8 义了系统的借口，当系统对外界接口发生变动时，往往造成系统结构较大变动， 难以扩充系的功能接口，采用结构化方法的系统可复用性较差，结构化方法将 数据和操作分离，导致一些可中庸的软件构件在特定具体应用环境才能应用， 降低了软件的可重用性5。面向对象方法具有很好的重用性，在遇到类似的问 题，通过应用了抽象继承等技术，来重用代码。从程序语言编译器来说，面向 对象方法通过编译器实现代码的面向对象性，也就是说经过编译器后，代码会 被翻译为相应对应的结构化代码。 所以要熟练开发，还要懂一定的结构化方法作为基础。从掌握的难度来说， 面向对象方法比结构化对象方法复杂，难于理解。面向对象方法的内容广、概 念多、而且很多都难于理解、做到精通更加不已。应用面向对象方法，常常需 要一直支持的分析、设计方法，如 RUP 方法、敏捷方法等。这些支持抽象枯燥， 难于掌握6。面向对象方法要经过长期的开发实践才能很好的理解掌握。相比 之下，结构化方法只是内容少，容易上手。从应用的范围看，结构化方法适用 于数据较少而操作多的问题，实践曾明对于想操作系统这样的以功能为主的系 统，结构化方法比较适应它。面向对象方法正好相反，对于数据库、信息管理 等以数据为主的而操作较少的系统，用面向对象方法描述要好于结构化方法。 2.3 本章小结本章小结 本章是论文的第二章，首先介绍了面向对象技术，其次将面向对象和结构 化进行比较，将两者之间的不同点和相似点一一列出，从执行效率，可重用性， 和语言编译器三个方面对两者进行比较。 重庆邮电大学移通学院毕业设计（论文） 第 3 章 基于面向对象的系统分析 9 第第 3 章章 基于面向对象的系统分析基于面向对象的系统分析 3.1 系统问题描述系统问题描述 1 1、医院收费管理系统的功能描述、医院收费管理系统的功能描述 收费管理信息系统是医院的主要窗口业务之一，通过应用本系统可以实现 收费工作从手工工作模式转到计算机处理模式，有效提高收费工作的效率，尽 可能解决医院门诊中“三长一短”的弊端，杜绝医院收入的流失：本系统可选 择同一种药品的不同的单位收费销售；可支持实收功能，对客户进行拆让处理； 可支持收费挂账处理；可不用挂号直接输入收费明细，完成收费；也可打印门 诊收费清单、门诊发票。门诊收费管理主要实现收费（根据病人性质不同自动 结算） 、单据汇总、单据查询、日账报表汇总打印等。医院门诊收费管理系统是 典型的信息管理系统，其主要包括后台数据库的建立和维护以及前端应用程序 的开发两个方面。 2 2、系统设计中的问题描述、系统设计中的问题描述 面向对象方法学把分析、设计和实现很自然地联系在一起了。虽然面向对 象设计原则上不依赖于特定的实现环境，但是实现结果和实现成本却在很大程 度上取决于实现环境。因此，直接支持面向对象设计范式的面向对象程序语言、 开发环境及类库，对于面向对象实现来说是非常重要的。 为了把面向对象设计结果顺利地转变成面向对象程序，首先应该选择一种 适当的程序设计语言。面向对象的程序设计语言适合用来实现面向对象设计结 果。事实上，具有方便的开发环境和丰富的类库的面向对象程序设计语言，是 实现面向对象设计的最佳选择。 良好的程序设计风格对于面向对象实现来说格外重要。它既包括传统的程 序设计风格准则，也包括与面向对象方法的特点相适应的一些新准则。 面向对象方法学使用独特的概念和完成软件开发工作，因此，在测试面向 重庆邮电大学移通学院毕业设计（论文） 第 3 章 基于面向对象的系统分析 10 对象程序的时候，除了继承传统的测试技术之外，还必须研究与面向对象程序 特点相适应的新的测试技术。在这方面需要做的研究工作还很多，目前已逐渐 成为国内外软件工程界研究的一个新的热门课题。 增加工作量。如果一味地强调封装，当进行修改对象内部时，对象的任何 属性都不允许外部直接存取，则要增加许多没有其他意义、只负责读或写的行 为。这会为编程工作增加负担，增加运行开销，并且使程序显得臃肿。性能低。 由于面向更高的逻辑抽象层，使得面向对象在实现的时候，不得不做出性能上 面的牺牲，计算时间和空间存储大小的都开销很大。 3.2 系统需求分析说明系统需求分析说明 3.2.1 系统功能性需求系统功能性需求 门诊收费系统是医院对门诊病人进行收费管理的系统。具体包括收费员对 病人的处方、检查单、化验单、治疗单等进行划价收费并打印发票；收费员设 定自己登录密码、修改发票起止号、退费、打印退票明细、结账；病人查询收 费记录：收费员组长打印汇总表、收费模板维护；计算机室人员进行系统初始 化管理(包括录入界面初始化、运行参数初始化等)、用户管理(建立用户组，分 配用户组功能，建立、删除用户等)。系统的总体信息确定以后，就可以分析系 统的参与者、确定系统用例了。 3.2.2 系统非功能性需求系统非功能性需求 软件产品的需求除了功能性需求以外，还包括非功能性需求，其中软件产 品的非功能性需求是常常被轻视、甚至被忽视的一个重要方面。其实，软件产 品非功能性定义不仅决定产品的质量，还在很大程度上影响产品的功能需求定 义。如果事先缺乏很好的非功能性需求定义，结果往往是使产品在非功能性需 求面前捉襟见肘，甚至淹没功能性需求给用户带来的价值。 所谓非功能性需求，是指软件产品为满足用户业务需求而必须具有的、除 重庆邮电大学移通学院毕业设计（论文） 第 3 章 基于面向对象的系统分析 11 功能需求以外的特性。软件产品的非功能性需求包括系统的性能可靠性、可维 护性、可扩充性、对技术和对业务的适应性，等等。下面对其中的某些指标加 以说明。 系统的完整性是指为完成业务需求和系统正常运行本身要求而必须具有的 功能，这些功能往往是用户不能提出的。典型的功能有:联机帮助、数据管理、 用户管理、软件发布管理、在线升级，等等。 系统的可扩充性与可维护性是指系统对技术和业务需求变化的支持能力。 当技术变化或业务变化时，不可避免将带来系统的改变不仅要进行设计实现 的修改，甚至要进行产品定义的修改。好的软件设计应在系统构架上考虑能以 尽量少的代价适应这种变化。常用的技术方法有面向对象的分析与设计以及设 计模式。 系统的适应性与系统的可扩充性和可维护性的概念相似，也表现产品的一 种应变能力，但适应性强调的是在不进行系统设计的修改的前提下对技术与应 用需求的适应能力。软件产品的适应性通常表现为产品的可配置能力。好的产 品设计可能要考虑到运行条件的变化，包括技术条件(网络条件、硬件条件、软 件系统平台条件等)的变化和应用方式的变化，如在具体应用中界面的变化、功 能的剪裁、不同用户的职责分配和组合等。 在本系统的设计中，认真分析了变量与不变量，如处方、费别、病人身份、 收费类型等是变量，通过建立数据字典对这些变量来进行维护;另外为了提高录 入速度和满足内容用需求，收费划价的病人信息录入界面也是可以自定义的， 对于病人的姓名、年龄、性别、病人身份等项目，系统维护人员可以设定光标 是否自动跳过。所有这些考虑，都在不同程度上提高了系统的技术适应性与应 用适应性。 3.3 医疗系统的静态建模医疗系统的静态建模 要成功的建立一个软件系统的模型，离不开建模语言、软件过程和建模工 具三方面的支持。对于门诊系统的设计，我选择了 UML 作为建模语言，选择 重庆邮电大学移通学院毕业设计（论文） 第 3 章 基于面向对象的系统分析 12 了 Rational 公司的 Rose2003 作为面向对象的建模工具。 软件过程描述的是做什么，怎么做，什么时候做，以及为什么要做，描述 一组按某种顺序完成的活动。在已出现的软件过程中，Rational 同意过程是目 前最具有普遍意义的开发过程7。RUP 的核心思想是：用力驱动、迭代化开发。 门诊收费系统的建模过程要吸收 RUP 的思想，借鉴 RUP 的系统设计中的工作 流程。 系统的静态结构图，即系统的静态试图是建立其他视图的基础。静态试图 用于对应领域中的概念以及系统市县有关的内部概念建模，它将行为实体描述 成离散的模型元素，但不描述与时间有关的系统行为。降态势图包括内图、对 象图和包图。其中类图描述系统中类的静态结构。他不仅定义系统中的类，表 示类之间的联系，如关联、依赖、聚合等，还包括类的内部结构（类的属性和 操作） 。类图描述的是一种静态关系，在系统的整个生命周期都是有效的，通过 分析用例和问题域，就可以得到相关的类，然后再把逻辑上相关的类封装成包。 这可以很好的体现出系统的分层架构，使人们对系统层次关系一目了然。对象 图是类图的实例，几乎有关与类图相同的标示。他们的不同点在于对象图现实 类图的多个对象实例，而不是实际的类。对象图是类图的一个实例，只能存在 系统某一时间。包图出包或类图组成，用于描述系统的分层架构。对门诊收费 系统的静态结构建模中主要使用类图。 3.3.1 系统用例图和流程图系统用例图和流程图 用例是系统参与者与系统在交互过程中所需要完成的事务，识别用例最好 的方法就是从分析系统的参与者开始，考虑每个参与者是如何使用系统的。鉴 于与系统交互的其它子系统除药库管理系统以外，主要涉及接口问题，在此主 要讨论本系统的主要用户及药库子系统的用例。 收费员划价收费的用例：根据以上分析，其用例包括系统登录、划价收费、 打印发票、打印明细、退费、结帐、发票管理。收费员是门诊收费系统的主要 用户，对其需求的分析，就是对整个系统主要功能的分析。参见如下图 3.1 所 重庆邮电大学移通学院毕业设计（论文） 第 3 章 基于面向对象的系统分析 13 示。 Include Include Include Include Include 系统登录划价收费 发票管理 打印发票 划价收费查询药品字典 收费员 打印明细 查询药品字典查询药品字典 结账 查询收费明细 打印药品明细 打印诊疗项目明细 退费 医院的诊疗过程主要分为住院部份和门诊部分，作为二大组成部份之一的 门诊部分，要完成医院一半的业务收入、每天几千人的诊疗，门诊收费是门诊 部分的重要环节，是医院的重要窗口，也是医院信息化实施较早的系统。随着 医院工作量的不断增长、计算机技术发展及其它 HIS 子系统的相继实施，对门 诊收费系统提出了越来越高的要求。与住院部分相比，门诊收费又具有其自身 的特点，如较高的响应速度、724 小时不间断工作、操作简便等8。根据门诊 图图 3.1 收费员划价收费用例图收费员划价收费用例图 重庆邮电大学移通学院毕业设计（论文） 第 3 章 基于面向对象的系统分析 14 病人的就诊流程，系统主要完成处方接收、处方录入、划价、收费、退费、废 票、预交金管理、IC 卡操作等功能，同时为保证系统完整性，与挂号、门诊药 房子系统相互关联，即收费时可直接取到病人挂号己产生的信息避免数据重复 录入，另外在处方收费或记账后药品细目送入门诊药房子系统同时自动分配药 房窗口处方数量，由其确认发药，退药时首先由药房确认退药数量门诊才能退 药费。考虑医院特殊情况，系统支持单独划价、单独收费和划收合一两种收费 方式，另外考虑病人多种付费方式，程序除支持常用付费方式外，还支持 IC 卡、 预交金、银行卡付费，病人可以用预交金一记账消费(费用在预交金范围内可不 结算直接查、取药)。如下图 3.2 所示。 病人 挂号就诊 划价收费 （本系统） 药房取药 科室检查 离院 图图 3.2 病人就诊流程图病人就诊流程图 第一步，从系统分析中找出门诊收费系统中描述问题与实体的名词，包括： 病人、收费时间、门诊医生、药剂人员、用户、收费员、收费员组长、物价员、 操作员、系统维护人员、门诊账单码、收费项目、药品收藏项目、处方、检查 单、治疗单、诊疗收费项目、单价、收费模块、收费版块内容定义、门诊收费 细目、收费员票据、门诊发票、收费处、财务科、药剂科、门诊药房、医技科 室、网络中心、门诊科室、用户组、用户组功能、子系统、系统功能等。 第二步，从候选对象（类）中筛选去掉一部分名词。收费处、财务科、药 剂科、医技科室、网络中心、门诊科室等都是用户单位所属部门，可以统称为 “部门” 。在门诊收费中， “部门”没有独立存在的必要，他可以识别为“用户 重庆邮电大学移通学院毕业设计（论文） 第 3 章 基于面向对象的系统分析 15 （User） ”的属性。药剂人员、收费员、收费员组长、物价员、系统维护人员都 是系统的用户，操作员与用户是含义相同保留一个这些人员可以识别为一个类 “用户（User） ” 。单价、收费时间没有身份，可以识别为收费细目的属性。经 过筛选初步得到门诊收费系统的一些类，如表 3.1 所示。 表表 3.1 门诊收费系统中的实体类门诊收费系统中的实体类 类含义类含义 xt_user用户Mz_detail_charge门诊收费细目 xt_group用户组Mz_op_receipt收费员发票定义 a_employee_mi职工字典Mz_patient_mi门诊病人 Zd_unit_code科室字典Mz_receipt门诊发票 Mz_bill_item门诊账单码Yp_base药品收费项目 Mz_charge_pattern收费模板Zd_charge-item诊疗收费项目 Mz_charge_pattern_defin e 收费模板内定义yp_group_name门诊药房 xt_user_group用户组功能定义xt_fune系统功能定义 xt_subsys子系统定义 重庆邮电大学移通学院毕业设计（论文） 第 3 章 基于面向对象的系统分析 16 3.3.2 门诊病人（门诊病人（Mz_patient_mi）类图）类图 图图 3.3 门诊病人类图门诊病人类图 Mz_patient_mi 类是门诊就诊病人的记录，每一个门诊病人有一条记录，包 含了每个病人的 ID 号、姓名、性别、身份等基本信息。每个门诊病人如果发生 费用就会在 mz_detail_charge 和 mz_receipt 中分别插入有一条或多条记录；否者 就不会有任何记录。类中每个属性的含义参见表 3.2 所示。 表表 3.2 类类 mz_detail_charge、mz_receipt_mi、mz_receipt 属性含义表属性含义表 类 mz_detail_charge含义类属性含义 patient_id病人主索引patient_id病人主索引 name病人姓名name病人姓名 times就诊次数sex病人性别 order_type处方类型birthday出生日期 item_no处方细目号response_type病人身份 charge_code项目编码charge_type费别 serial_no包装序号balance金额 重庆邮电大学移通学院毕业设计（论文） 第 3 章 基于面向对象的系统分析 17 group_no库房号lv_date最后就诊日期 charge_status收费状态mac_times就诊次数 bill_code账单码 audit_code核算码类 mz_receipt 属性含义 exec_sn执行科室代码patient_id病人主索引 charge_amount数量ledger_sn结账次数 charge_price实际价格receipt_sn发票号 happen_date发生日期pay_unit付款方 enter_opera录入人charge_total总金额 confirm_flag确定目标charge_status收费状态 confim_date确定日期cash_date收费日期 report_date报表日期cash_opera收费员编号 doctor_code医生代码report_date报表日期 apply_unit申请科室代码receipt_no流水号 3.3.3 收费项目类图收费项目类图 如图 3.4 所示为收费项目类图。收费项目包括诊疗收费项目类 (zd_charge_item )、药品收费项目类(yp_base )二类。收费员在进行划价