用例分析技术在医院门诊信息系统需求分析中的应用

周 岩

菏泽医学专科学校网络中心，山东 菏泽 274000

用例分析技术是通过参与者以及用例间的关系来描绘系统内外可见的需求，是用户和开发人员共同塑造系统的合作区间。用例被定义为是一组动作序列的描述，被系统执行后，参与者会获得可见结果。

用例分析可对系统局部进行有效的边界划分，从而独立分析系统局部参与者的对应用例。另外，在整个软件开发过程中，用例驱动模式可贯穿软件的开发全程，可有效避免开发过程中软件需求变更的混乱。用例分析可应用于多种迭代式软件开发过程，可在早期对需求错误加以鉴别和解决。在前期的需求分析中，首先要明确参与者的数量以及每个参与者的参与目标是什么?其参与目标就是我们要分析的角度，这个角度就可以描述成一个用例。这也就是为什么用例会成为建模方法的原因［1］。

用例分析的粗细，应由业务需求的情况决定［2］。复杂的部分细一些，简单的部分粗一些，保证每个用例都保持密切的相关性，以指导后续的功能划分。

1 系统分析

1．1 门诊组织结构的前期分析

在系统需求分析的前期，通常要实地考察业务部门的管理体系，在充分了解和掌握其管理结构的基础上，再逐步进行业务细化和切割，最终划分出独立的业务单元［3］，以便后期借助用例分析。

确定系统边界［4］是用例分析的前提，在实地调查过程中，要找出位于系统外部和内部的事物。在系统外部归纳出参与者，在系统内部总结出用例。在此指导前提下，我们初步分析出医院门诊业务结构组成，其业务可分为:门诊挂号、医师诊疗、门诊收费、门诊药房、检查检验科等。而这些科室的所有日常工作都是围绕着医师诊疗这个核心去进行的。该文将通过以上几个不同方面对系统需求进行分析。

1．2 从参与者入手的系统分析

按需求分析以用例为最终分析模式的要求，首先要对门诊业务由粗到细，由大到小，由繁到简的顺序来进行分析，最终归结到人(参与者)、事(过程)、物(结果)的层面。

按一般规律，寻找参与者是用例分析的首要前提，并且常有一个参与者对应多个用例的特性，先找到参与者也便于从参与者的角度分析用例的内容，使系统分析更贴近应用。那么针对医院门诊信息系统开发的需求分析，寻找其用例的过程就首先变成与参与者(用户)分析交流的过程。这里的用户应是和系统互动及交互信息的个体。所以应该包括病人、挂号员、收款员、医师、护士、药师及其他外部系统与硬件设备等。参与者会启动、参与用例的运行，找到参与者就可以引导我们找到用例，以建立医院门诊管理信息模型。

在与医院门诊各科室业务人员座谈的同时，我们用多种调查表格，以了解记录他们对待开发系统的想法和期望，并从中归纳总结出待开发系统最终需要完成哪些工作。我们在对门诊具体业务调查的基础上，总结出了门诊业务关系:

首先，病人作为挂号事件的驱动者，触发挂号系统，通过交互操作，产生的结果(数据)流向下一个环节(医师诊疗系统);医师和病人是诊疗系统的事件驱动者，医师通过交互操作，产生的结果(数据)流向不同的环节(收费、治疗、门诊药房、检查、检验);收费员和病人是收费事件的驱动者，触发收费系统，通过交互操作，产生的结果(数据)流向相应环节(治疗、门诊药房、检查、检验);各相关事件驱动者驱动治疗、门诊药房、检查、检验等子系统后，通过交互操作，产生的相应结果(数据)返回医师诊疗系统。

1．3 对象模式的需求分析

我们采用面向对象分析方法(object-oriented analysis，OOA)对医院门诊系统的流程进行分析。借用用例建立需求模型来描述各系统的功能，开发人员通过分析系统的各项功能和非功能需求之后，把需求按照统一建模语言(unified modeling language，UML)的规则设计成相应的用例，建立系统的用例图之后，可以再通过活动图和时序图来进一步标示出各个用例间的业务关系和大致流程。通过这种方式来确定模型中的用例和参与者。用例的堆放顺序应体现其发生时间。

在分析门诊总体业务关系的基础上，我们对门诊管理系统所涉及的相关内容以用例的形式进行罗列(如图1所示)。图1中列举了相关参与者和与其对应的用例，在这里我们只列出一些相关的基本内容，用以衔接后面的叙述。

图1 医院门诊相关用例结构图

针对较庞大的信息管理系统分析，系统切分是不可避免的工作。我们把整个系统按业务界线划分出几个信息孤岛，这几个信息孤岛就应该是将来的子系统。而子系统的切分就是每个信息孤岛按功能目标的继续切分。

系统核心功能分为:门诊挂号、医师诊疗、门诊收费、门诊药房、检查、检验治疗五大部分。检查、检验为第三方引进软件，该系统只提供数据接口。其中病人、挂号员、医师、收费员、药剂师为用例参与者［5］。

以上五大功能部分，他们之间的关系既是并列相互独立的，同时也是相互依存的，在系统层面上他们都属于门诊信息系统的子部分，都有平台共用、数据共享的特性，其包含关系如图2所示。

图2 各子系统用例及关系结构图

其实，在前面的分析中，我们获得的系统层面级的用例对系统的切分帮助是巨大的。因为系统级的用例可以清楚地显示出子系统的功能目的和关系。而如果跳过了系统级的用例分析，直接进行子系统的分析，那么分析过程将会是散在的、零乱的、毫无头绪的，并且效率会很低。

经过以上的分析，我们获得了实体子系统，接下来的工作就是对每个子系统进一步的切分和整合。受篇幅所限，以下仅对门诊挂号和医师诊疗用例进行分析说明。

2 系统设计

2．1 门诊挂号

挂号员是用例的参与者。负责启动、运行挂号用例，用例内容应包含卡号及流水号的建立、录入、保存、查询、修改、统计病人基本信息及收费信息;建卡和补卡;最终生成就诊卡。此阶段中的建卡或补卡操作是对病人基本信息的存储和调用。在此环节生成的病人信息数据也会被后续环节调用。

一般来说，对于有经验的系统分析者，用活动图抓用例是一个效率较高的办法。但在实际应用中，应该注意对业务活动的分析不要陷入流程细节，要时刻铭记此阶段的流程分析仅是用来寻找用例，而不是分析出复杂、全面的流程细节［6］。

通过分析门诊挂号发卡业务活动，从中找出了病人信息录入和就诊卡处理2个用例。图3为就诊卡处理用例图。

主题区域:门诊挂号就诊卡子模块

业务功能:门诊建卡、补卡

使用角色:挂号员

功能简述:对就诊卡信息进行查询、添加、修改和存储操作。

发生条件:以挂号室人员身份登录系统，获得所有管理权限;病人挂号;信息查询。

请求结果:获得就诊卡、就诊流水号。

如图3所示为挂号员在门诊建卡/补卡中所包含的内容:①操作员首先进入建卡或补卡界面;②信息录入系统(初次就诊);③或直接查询调出病人信息(复诊);④收费或生成新就诊卡;⑤用例结束。在此用例中，病人和挂号员是参与者。

图3 门诊就诊卡(建卡/补卡)用例图

图3中箭头表示参与者与用例之间的聚合关系［7］，是用来表示参与者与系统双方的通信关系，并不是用来表示信息或数据流向。而目前习惯使用箭头表示单向聚合关系，用以表示参与者扮演的是启动还是支持角色。

在该用例中，挂号员是扮演启动角色的参与者。

2．2 医师诊疗

其中，包括“药品医嘱”、检查/检验医嘱、治疗医嘱等，在此仅以药品医嘱为例进行用例的分析描述。

医师是外部参与者，医师从候诊队列选取病人，获取病人就诊信息，体检后录入药品医嘱。药品信息来源于药品库存信息，生成电子处方保存至数据库。在此环节生成的医嘱数据会被收款和药房等后续环节调用。

主题区域:门诊医师诊疗子模块

业务功能:药品医嘱录入及生成处方

使用角色:医师

功能简述:药品医嘱录入及生成处方。

发生条件:以门诊医师身份登录系统，获得管理权限并成功叫号。

请求结果:生成药品处方。

如图4所示，门诊医师进入诊疗子系统:①从候诊队列选取病人及信息;②进入药品医嘱录入界面;③调取药品医嘱模板并修改;④将表单内容保存至数据库;⑤支持处方打印功能;⑥用例结束。在此用例中，药品信息来源于药品库存数据信息。医师是用例参与者。

图4 药品医嘱用例图

此外，还有门诊收费、门诊药房等用例均有各自的特点，但基本原理相似，在此不做赘述。

3 系统关键技术

首先把系统切分成功能不同的子系统，每个子系统负责完成部分特点较接近的用例。对于需要多个子系统协同实现的大粒度用例可切分成若干个小粒度子用例［8］，由各子系统负责完成相应子用例。其次分析用例的事件流，确定各子系统间依赖关系，定义系统接口［9］。通过用例结合迭代应用分析，考虑到该系统的分布式特点，系统采用三层架构的组件COM+运行模式具有更大的优势。

组件的管理控制更适合于三层架构的瘦客户模式，对用户端资源要求较低，而且可满足用户对软件系统的集中控制和局部升级的需求。

三层组件模式可更好地支持分布式计算环境。逻辑层应用程序可以分布在多个机器上运行，从而迅速提高系统的运行速度。所以组件应用技术将是该信息系统开发的首选技术。

4 系统实现

依据系统用例迭代分析和病人挂号涉及的相关事务行为，我们从中抽象出对象类图，推导出系统数据结构，该文以挂号模块为例进行简要说明。

根据门诊挂号系统类模型可以知，挂号行为涉及到病人的基本信息、挂号类型选择及科室、医疗人员基本信息，最终组合成挂号单信息。

挂号业务规则包括检验数据的合理性和完整性、数学运算、筛选归类等。其中，最基本的处理就是定位查找、显示、修改和保存。但此处的定位查找，修改和保存操作应遵循业务规则进行数据处理，最后与数据库的交互就依靠调用数据访问组件来完成。挂号管理程序时序图如图5所示。

定位查找和修改两个操作可以看作是保存操作的前期步骤，且修改操作只是对用户界面的数据进行了变动，数据库中的数据并不受影响。仅当用户点击了界面的“确认”按键，系统才将对数据库中的数据进行相应的更改。其他类同此。

图5 门诊挂号管理程序时序图

该文通过利用UML(unified modeling language)的概念结合实际应用，分析了如何在系统分析阶段通过用例分析手段由浅到深、由粗到细地去分析用户的业务需求。与传统的系统分析方式相比，用例的分析方法完全是从事务的表象来定义系统的功能，它把需求与设计融合起来。在OOA(object-oriented analysis)面向对象的分析设计方法中，系统的功能性需求主要借用例模型来描述，系统的设计依附于用例模型的记录描述［10］。用例也同时定义了其自身使用的内部与外部环境，每一个用例描述被看作是一个独立的功能服务。用例的分析方法也更易于被用户所理解，可使开发人员和用户之间针对系统需求进行沟通更加有效。

［1］金联，黄霞．用例分析技术在软件开发中的应用［J］．湖南工业职业技术学院学报，2005，5(4):22-24

［2］王枫，石冰心，罗莉敏．UML建模机制研究及在系统需求分析中的应用［J］．计算机工程与设计，2005，26(4):971-975

［3］毋国庆，梁正平，袁梦霆，等．软件需求工程［M］．北京:机械工业出版社，2008:32-81

［4］黄国兴，周勇．软件需求工程［M］．北京:清华大学出版社，2008:55-156

［5］金轶，黄刊迪．利用UML建立医院门诊信息系统的用例模型［J］．医学信息，2007，20(12):2004-2006

［6］邱郁惠．系统分析师UML用例实战［M］．北京:机械工业出版社，2010:20-180

［7］陈建峡．基于UML的分析建模方法［J］．湖北工业大学学报，2005，20(4):45-48

［8］王凤斌．UML面向对象建模在管理信息系统中的应用［J］．计算机与现代化，2005，(2):119-123

［9］谈俊峰．用用例分析技术进行需求分析和构架建模［J］．计算机工程与设计，2004，25(2):252-255

［10］李思广，林子禹，胡峰，等．基于UML的软件过程建模方法研究［J］．计算机工程与应用，2003，(6):76-78