| UML软件工程组织 | |||
| |
|||
|
|||
使用业务驱动的开发为卫生保健组织开发 SOA 解决方案
作者：Jean Wang 来源：IBM
使用业务驱动的开发方法的 SOA 解决方案将帮助您集成卫生保健业务流程，从而实现您的业务目标，并能节约时间和成本。本文说明了在典型的卫生保健行业 IT 场景中使用业务驱动的开发实现 SOA 所涉及的详细过程、工具和技术构件。 引言卫生保健行业或许代表了对 IT 解决方案最具挑战性的行业。这是由于卫生保健行业的复杂业务流程、复杂医疗数据、异构组件和彼此独立的软件系统等因素所造成的。提供优质医疗服务的业务需要相应的解决方案与组织的业务目标保持一致，且其 IT 系统高度集成并能灵活地适应动态业务变化。面向服务的体系结构 (SOA) 通常将是应对这些挑战的理想方法。不过，仍然有个问题，即组织如何进行全面采用和实现全面部署。 本文将说明如何使用业务驱动的开发方法来开发高质量 SOA 解决方案，以集成卫生保健业务流程，从而实现业务目标，并同时节约时间和成本。它将帮助业务分析人员、卫生保健领域的主题专家、业务部门和项目经理以及卫生保健 IT 专业人士在集成和协作环境中实现其在开发和实现 SOA 解决方案过程中各自的角色。 卫生保健行业的挑战提高操作效率和减少成本并同时提高卫生保健服务的质量，这是一项全球性的卫生保健挑战。卫生保健市场现已变得更为复杂；自今天所使用的被广泛接受的做法出现以来，业务需求和流程发生了巨大的变化。大部分卫生保健组织都具有不彼此通信的各种 IT 系统和组件。例如，医生不能从门诊系统访问住院系统中的患者数据，护士站无法有效地从门诊获得全面的患者数据，几乎所有部门都以竖井 (silo) 方式工作，并未考虑与其他部门协作。这就带来了各种患者支付系统的问题，无法方便地访问和共享存储在多个遗留索赔系统中的医疗保险索赔。这种类型的环境严重阻碍了卫生保健组织为患者提供高质量服务的工作效率和效益。为了应对这些挑战，需要开发和实现基于面向服务的体系结构 (SOA) 的解决方案。卫生保健行业在采用信息技术方面一直非常缓慢，而这些技术在很多其他行业都带来了质量、效率和性能的革命性提高。这种现象的原因在于业务和 IT 之间存在巨大的差距。卫生保健业务流程属于最复杂的流程，而不仅是简单地在卫生保健专业人士和 IT 专家之间实现简单的双向沟通。 业务驱动的开发：什么是业务驱动的开发以及为何需要它？业务驱动的开发（Business-driven development，BDD）是一种由业务需求驱动的端到端软件开发方法。BDD 支持快速开发和部署能以较少的成本满足业务需求的灵活解决方案。它是一种用于实现 SOA 的机制。 了解一下可以在此过程中使用的 IBM 开发工具以及其充当的角色，可能会有所帮助：
图 1 显示了典型的 BDD 生命周期，其中包括主要的 IBM 工具及其如何与 IBM 的 SOA Foundation 远景保持一致： 图 1. 使用 IBM 软件支持 SOA 的 BDD
业务驱动的开发是用于开发 SOA 解决方案的基于角色的业务流程。它将收集需求和捕获业务分析人员确定的业务流程。所得到的流程模型和构件可以随后用于下游 IT 开发和实现，供架构师用于进行系统设计、供 Java 开发人员用于进行开发、供集成开发人员进行流程编排和部署以及供质保工程师用于进行测试。集成 IBM 软件平台可在协作环境中为每个角色提供支持，如图 2 中所示。 图 2. 使用 IBM 软件为主要角色提供支持的业务驱动开发流程
应该注意，本文仅说明了可在 SOA 生命周期中使用的主要软件工具。 让我们以一个业务案例为例，了解业务驱动的开发如何在解决前面提到的问题时发挥作用。 业务场景——门诊流程纽约的某个医院希望将其门诊流程从基于纸张的医疗记录系统转换为电子医疗记录（Electronic Medical Record，EMR）系统。这将帮助他们改进患者护理、实现操作高效率，从而最终提高收益率。不过，由于存在多个障碍，指导委员会很难作出实现 EMR 的决定。通过开发在 BDD 中使用业务流程管理的业务案例作为试点，使得指导委员会最终一致通过了 EMR 建议方案。 以下部分将说明如何使用 BDD 方法开发使用门诊系统中的 Visit Preparation 流程的 SOA 解决方案。 医院门诊部门的 Visit Preparation 流程是在患者见到医生之前的流程，从患者达到前台开始，依次进行挂号、验证保险或支付信息、检索患者的医疗记录，最后会给患者分配一个医师。 管理需求和优化业务流程管理需求 我两年前曾向一家医院了解过，他们通过其主要健康信息系统（Health Information Systems，HIS）活动，已经获得了完整的 HIS，此系统可提供由医生、护士、药剂师和管理员可访问的集成信息系统。令我感到惊讶的是，一年后与该医院的 IT 经理交谈时，竟了解到他们将要重新创建整个系统，因为之前的系统已不再能够满足其业务需求了。不幸的是，根据 Standish Group 的报告，如果您进行四个 IT 项目，其中三个都会有相似的最终命运。美国公司每年会投入高达 275 亿美元进行大约 20 万个应用程序软件项目，而其中只有 28% 的软件项目取得了成功。有关更多信息，请参见参考资料部分。 为了确保所开发的信息系统满足组织的业务需求，BDD 将首先捕获需求，并分析业务流程，然后才会进行代码开发方面的投资。在一个门诊案例研究中，我们与所有涉众进行了交流，并记录他们的期望和面临的挑战以及已确定的问题和机会。我们使用了 IBM Rational? RequisitePro 来捕获这些信息，并依据业务目标、业务问题和机会（非功能要求）、业务用例和系统用例对这些信息进行组织。通过使用 RequisitePro，我们以结构化的方式对需求进行组织、分析和优化。每个要求都被映射到组织的业务目标，如图 3 和图 4 中所示。同时，它们也被映射到技术功能，从而透明地与产品和解决方案建立联系，如图 5 中所示。例如，实现医生和护士工作的自动化来减少人工数据交换量的需求映射到支持提高操作效率的业务目标（具有高优先级），并同时映射到要求进行协作的技术功能，从而透明地与 IBM 的 Workplace Collaboration Services 解决方案建立联系。RequisitePro 向决策者提供了逻辑关联视图，而最重要的是提供了需求的可跟踪性，如图 6 中所示。 图 3. 在 Rational RequisitePro 中捕获的业务需求，包括优先级、状态及其他重要属性
图 4. 需求被映射到技术功能
图 5. 客户需求被链接到资产
图 6. 在 RequisitePro 中跟踪业务对象、非功能需求、IT 功能和资产
在项目的早期使用 RequisitePro 进行正式需求管理的优势在于，它允许业务目标、管理人员、领域专家和 IT 人员进行整合，清楚地说明其业务观点。而且，它将指导在协作环境中的下一步系统设计和开发工作，从而减少项目风险。Mansurov 和 Probert 的研究表明，如果需求管理阶段所花的时间从 3% 增加到 20%，软件产品的总体上市时间将会减少 30% 到 50%，如图 7 中所示。 图 7. 更好的需求管理可减少产品的上市时间
建模业务流程，以进行流程重新设计 分析业务流程是设计真正满足业务目标的 SOA 解决方案的关键。WebSphere Process Modeler 可帮助捕获和分析业务流程。 首先，在 WebSphere Business Modeler 中捕获和模拟现有的基于纸张的门诊流程（“原始”流程），如图 8 中所示。最后将对模拟结果进行分析，以确定瓶颈、服务和定义性能度量指标。例如，通过流程分析发现，从医疗记录部门检索纸质医疗记录是最耗时、最不具成本效益的流程。通过迁移到 EMR，可以消除此步骤。此外，还会将保险标识为能由保险公司提供的服务。而且，通过使用单点登录门诊协作门户解决方案作为中央平台，以提供有关患者记录和历史的全面视图，医生可以节约非增值任务上所花的时间，从而能够在患者身上花更多的时间。基于对现有纸质流程和业务需求的分析，提出了有关重新设计后的 EMR 流程（“目标”流程）的建议，如图 9 中所示。最后，将“原始”流程和“目标”流程的结果进行比较，如图 10 中所示。正如您所看到的，图 8 和表 1 中的 EMR 流程比基于纸张的流程高效得多，例如，准备时间从 30 分钟减少到了 6 分钟，如图 10 中所示。 图 8. 在 WebSphere Business Modeler 中捕获的基于纸张的现有门诊流程
图 9. WebSphere Business Modeler 中建议的基于 EMR 的门诊流程
图 10. 纸质流程和 EMR 流程的准备阶段流程持续时间的比较
表 1. 纸质流程和 EMR 流程的模拟结果比较
所有涉众都对建议的 IT 解决方案表示满意后，就可以将业务模型转交给 IT 部门，以进行下游 IT 构造和实现工作。 建模业务流程，以进行运行时执行 除了捕获业务流程进行分析之外，流程建模的好处还包括简化系统设计和开发。WebSphere Business Modeler 允许通过将业务规范转换为 IT 来实现业务到 IT 的完美“交接”。首先，会在软件/解决方案体系结构设计过程中将流程模型转换为统一建模语言（Unified Modeling Language，UML）。这将由 IT 架构师使用 Rational Software Architect 完成，随后开发人员将使用 Rational Application Developer 进行代码开发。其次，会将流程模型转换为业务流程执行语言（Business Process Executable Language，BPEL），并提交给集成专家进行流程编排。此外，可以在运行时通过 WebSphere Business Monitor 使用在模型中定义的关键性能指标（Key Performance Index，KPI）监视流程，以便进一步改进流程。 为了稍后能将目标流程模型用于 IT 检查，需要进行额外的工作，通过使用 Modeler 中的高级功能准备构件。
将业务流程模型转换为 UML，以便进行体系结构设计和应用程序开发在业务级别对业务流程进行了验证后，就可以将其提供给 IT 部门进行系统设计和开发了。将流程模型以只读格式导入 Rational Software Architect，保留原始结构，但所有元素将被转换为 UML 等效项。例如，流程将被转换为业务用例，执行业务任务的角色将被转换为操作的参与者，个体资源将被转换为 Java 类，而业务项目将被转换为使用带属性的 Java 类表示的业务实体。Rational Software Architect 还提供了集成的 Requirement 透视图来支持架构师复查和链接之前在 RequisitePro 中建立的业务需求。架构师还需要将 Rational Software Architect 中提供的模式应用到场景中。业务和 IT 间的这种映射为架构师提供了以自己熟悉的语言了解域特定知识的机制，从而消除了经常导致业务和 IT 间不一致的非正式的过渡转换。这样，设计良好的体系结构来支持业务目标的工作就变得容易多了。图 11 显示了在 Rational Software Architect 内构建的 UML 类关系图，此关系图基于 patient Visit Preparation 业务流程。图 12 显示了 Rational Software Architect 中的业务模型、需求和业务用例 UML 关系图的集成视图。 体系结构设计完成后，Java 开发人员可以使用 Rational Application Developer 进行服务、Web 内容和数据库等可重用资产的快速构造。为了创建可重用资产，开发人员可以在 Rational Software Architect 中应用 EJB 转换，生成可以分发和重用的 Enterprise Java? Beans (EJB)。由于已经生成了代码框架，开发人员可以将工作重点放在开发执行特定业务操作的主要逻辑上。这可大幅度提高软件开发的工作效率和质量，并能减轻稍后测试工作的负担。在 patient Visit Preparation 流程中，在业务流程中被标识为重复任务（服务）的“Verify Insurance”被转换为“Insurance System”会话 Bean，作为 Web 服务公开。患者“Address”业务实体被转换为实体 Bean。为了构造 Web 内容，开发人员可以拖放“Patient”Java Bean（之前已经在业务模型中定义了其特征），因此可方便地创建用于输入和提交患者数据的 Java 页，如图 13 中所示。此外，由于业务实体（如 Patient Visit）的属性是在业务级别定义的，并已转换为实体 Bean，因此可以自动生成对应的数据库表，如图 14 中所示。 图 11. Rational Software Architect 中的基于业务流程的 Visit Preparation 业务流程类关系图
图 12. 在 Rational Software Architect 中使用业务用例 UML 关系图集成的需求和业务流程
图 13. 可以方便地通过将 Java Bean 拖放到页面上生成 JSP
图 14. 可以在 Rational Software Architect 中基于模型中定义的业务实体生成数据库模式
将业务模型转换为 BPEL，以进行流程编排另外两个业务流程模型组件是业务流程执行语言 (BPEL) 和 Web 服务描述语言（Web Services Description Language，WSDL）。通过在导出向导中选择 WebSphere Business Monitor (from BPEL process) 导出类型来导出业务模型，就可以直接得到这两个构件。所得的文件包中包含 BPEL 和 WISDL 捕获的所有流程信息，可以提供给集成专家使用 WID 进行流程编排。 WID 一方面接受来自 WB Modeler 的 BPEL 构件，另一方面还可接受在 Rational Software Architect 和 Rational Application Developer 中创建的服务等构件。通过使用 WID，集成开发人员可将各个部分（服务）组装为集成解决方案，然后将其部署到运行时环境 WebSphere Process Server (WPS)。图 15 显示了从业务流程模型生成的 VisitPreparation 流程的 BPEL 和 WSDL 文件。图 16 显示了在 WID 中由 BPEL 流表示的同一流程。 集成流程 Visit Preparation 在 WPS 上部署和执行，如图 17 中所示。 图 15. 导出后得到的 Visit Preparation 流程的 BPEL 和 WSDL 文件
图 16. WID 中用于进行流程编排的 Visit Preparation 流程流
图 17. 已部署到运行时环境的流程
使用 Rational 测试工具测试解决方案通过 BDD，测试工程师可以在完成软件开发前使用 Rational 测试工具进行测试活动。Rational 测试工具与需求管理工具 RequisitePro 进行了集成，以便测试工程师理解业务需求，并允许其提前基于工具中提供的已捕获用例来创建测试计划和测试用例。软件准备好，可以进行测试时，他们就可以根据需求进行测试，以确保解决方案确实是以与业务目标保持一致的原则开发的。在本示例中，使用了 Rational Test Manager 来为 Visit Preparation 流程创建测试计划和测试用例，如图 18 中所示。使用了 Rational Manual Tester 执行和管理手动测试，如图 19 中所示。测试工程师还可以使用 Rational Performance Tester 来评估和验证 Web 服务性能，并确定服务在各种使用负载情况下的性能状况。 图 18. 在 Rational Test Manager 中创建和执行测试用例
图 19. 使用 Rational Manual Tester 进行手动测试
进行监视，以对流程进行持续改进业务流程的性能受到很多因素的影响。组织希望能够监视各个流程，以发现出现的问题并收集用于进行流程优化的智能数据。 WebSphere Business Monitor 支持进行这种实时的流程监视和反馈收集，以进行持续流程改进。业务模型到监视之间的联系纽带是 WB Modeler 中内置的 Business Measure 模型组件。Business Measure 模型允许为流程定义性能指标、计数器、秒表和触发器，并使用其进一步定义 KPI。Business Measure 模型的构件将随后以 XML 格式导出，以供 WebSphere Business Monitor 使用。如图 20 中所示，为 Visit Preparation 流程定义的 KPI 包括患者等待时间、保险验证时间和接收的患者数量。将在 WebSphere Process Server 上收集运行时数据，然后计算并以可视方式显示到 WebSphere Portal 环境中的 WB Monitor。流程所有者（如医生和操作管理人员）可以查看监视仪表板，以了解流程的实时性能，并据此采取相应的措施。 图 20. 在 WB Modeler 中为 Visit Preparation 流程定义的 KPI
总结业务驱动的开发是交付基于面向服务的体系结构的卫生保健解决方案过程中要采用的一个关键方法。本文提供了一个实时示例，从而说明了在此类实现过程中应用
BDD 的基本原则。文中说明了各种工具功能，特别强调了这些工具在 BDD 实现 SOA 的生命周期中的相互关系。本文从需求和与
IBM 平台相互关联的业务流程开始，然后讨论了系统设计和开发、集成、测试及监视，说明了业务与 IT 如何相关以及如何推动 IT
实现，如何确保解决方案满足业务目标，从而在减少时间和人力投入的情况下提高业务的响应能力。 |
| |||
组织简介 | 联系我们 | Copyright 2002 ® UML软件工程组织 京ICP备10020922号 京公海网安备110108001071号 |
