医院业务建模整理.pdfVIP

3.5 业务模型 业务建模是在针对医院内各项业务活动梳理分析前提下，阐述基于信息交换 与共享目的的业务流转模式，展示各业务活动通过医院信息平台进行信息交互的 过程，为各医院开展医院信息系统建设提供参考和指导。值得注意的是，本业务 建模并非用于规范医院内各项业务的具体流程，但各地在开展医院信息化建设过 程中，可参照本建模方法进一步深入细化、制定医院信息系统有关业务流程规范。 3.5.1 业务模型描述方法 本章采用 UML 语言，遵循 UML2.0 规范，利用建模工具，以“业务活动”为 核心建立医院信息平台各应用系统业务模型， 主要通过用例图 （Use Case Diagram） 和活动图（ Activity Diagram ）描述。 业务用例图从用户角度出发，描述医院信息平台可以为用户（业务领域内的 个人、管理人员及其他领域的业务参与者）提供的服务；活动图描述每个业务用 例中的业务流程、业务活动所产生的信息及业务活动执行者；从而实现活动与机 构关系、活动与活动之间关系的可视化表达。 （1）业务用例图 图 3- 4 典型业务用例图示例 在用例图中，应用的元素如下： 75 1）参与者 业务用例的参与者表示一个业务项目的执行者或与业务领域相关联的外部角 色。在医院信息平台中，以“用户（角色） ”描述参与者执行某项业务职能活动。 与医院信息平台业务相关的外部人员或系统也被描述为业务参与者，如服务对象、 区域卫生信息平台等。 2 ）业务用例 业务用例描述的是参与者与业务领域之间在业务过程执行时可能产生的交 互，典型的业务用例表现为参与者进行的业务工作。业务用例是从参与者的视角 来描述的。除了业务用例应用于业务领域之外与普通的系统用例并无区别。业务 用例用版式《业务用例》来区分业务用例与普通的系统用例。 产生交互记录的业务用例用黄色填充，如： 不产生交互记录的业务用例用白色填充，如： 3 ）关联 关联是参与者和业务用例之间的关系。关联表示这个参与者可以执行该业务 用例或与参与者与用例间的交互。 4 ）包含关系与扩展关系 包含关系与扩展关系都被描述为两个用例之间的关系。其中，包含关系表示 箭头发起端的用例包含箭头指向的用例，即在执行某用例时，如果该用例包含另 一用例，那么这个用例必须被执行；扩展关系则表示箭头发起端的用例可以从箭 头指向用例扩展执行，即在执业某用例时，如果有扩展用例指向该用例，可以从 该用例导向到扩展用例。 实例上，包含用例与扩展用例都是依赖关系，起始用例依据被包含用例，扩 展用例依赖起始用例。 76 5 ）业务边界 表示业务域内业务主题所定义的业务范围。 （2）业务活动图 在业务建模过程中，一般采用带有泳道的活动图来描述业务的活动过程场景， 用于表示完成业务用例所需执行的业务过程。 图 3- 5 典型活动图示例 活动图的基本元素包括： 1）活动（ Activity ）：活动是完成整个业务用例的独立步骤，例如无法进一步 分解的操作。但这并不意味着该操作在现实世界中无法再进行分解而是在该图中 无法需进一步细化。业务活动能处理业务过程的输入和输出信息，在活动中某个 操作的输出可以是后续操作的输入。活动还能调用另一个活动，接受一个事件可 发送一个消息。 产生交互记录的业务活动用黄色填充，如： 不产生交互记录的业务活动用白色填充，如： 77 2 ）复合活动：标识为“ ”的活动被认为是嵌套一系列其它活动的复合活 动。可以在其它活动图中详细展开。如： 3 ）活动转移：用箭头表示，用来连接活动图中各个独立的组件，表达活动的 控制流。在活动转移中，输入箭头将激活活动中的某个步骤：在该步骤执行完成 后，控制流将沿着输出箭头继续。活动转移可以被赋予名称。 4 ）决定：一个决定一般至少包含一个输入和两个输出，对于每个输出