了解业务分析人员和架构师如何指定与面向服务的体系结构一致的用例。本文基于第
1 部分中描述的流程建模技术描述用例建模。在本系列中，您将了解一项新的业务流程分解技术，以帮助您指定与面向服务的体系结构（Service-Oriented
Architecture，SOA）一致的业务流程。
在本系列的第
1 部分和第
2 部分，您了解了指定业务流程模型的一种方法，可实现业务流程和基于面向服务的体系结构（Service-Oriented
Architecture，SOA）的目标体系结构的一致性。这些模型与所实现的实际解决方案有更好的对应关系。本文将此原则扩展到了用例模型的定义中。
了解基于流程模型的用例分解技术，使其用例与目标体系结构具有类似的一致性。
用例建模在 IT 项目中用于捕获系统的功能需求。用例模型基于支持重用的构造，而这应该很容易转换为促进重用的体系结构（如
SOA）。不过，目前使用的大多数用例建模技术基于 SOA 和业务流程管理（Business Process
Management，BPM） 之前的概念，会产生以下后果：
- 用例经常过于照字面转换为技术构件（如流和服务），从而会导致系统设计不佳，无法提供 SOA 的优势。
- 出于必要，设计经常涉及对用例模型中定义的结构的重构，得到的系统所实现的功能无法方便地追溯到需求。原始用例的生命周期缩短，其有用性降低。客户期望管理、IT
交付流程的效率、端到端可跟踪性测试和未来的重用也都存在问题。
功能模型与体系结构的一致性提高可带来很多好处。可以促进业务涉众和技术人员之间的沟通，加速项目交付，并极大地提高重用潜能。需求领域的重用可以直接与体系结构中的重用对应。
您使用本文中描述的技术开发的用例模型可以在交付之后保持有效，继续有用。他们将与所交付的实际系统构件对应，如服务、流程或用户界面组件。用例模型可以作为新项目的参考，寻求单个交付项目生命周期之外的重用。所得到的用例经常与服务类似，因此，指定用例是指定服务的第一步。
图 1 显示了第
1 部分中建议的流程分解结构。每个流程属于其中的一个层。流程只能调用或订阅到下游层中的子流程的事件，如箭头所示。每个流程应该不知道上游层中的流程。
图 1. 流程分解框架
使用者流程和其下层中的所有流程都在技术解决方案中实现。手动或“客户体验”流程层是虚拟层，显示了业务中的所有非自动化活动；它说明了系统支持的流程如何适合此上下文。
您现在可以使用流程分解结构来驱动需求指定的方式。模型中的每个流程都以用例的形式指定进一步的细节，所得到的用例结构能反映流程分解结构。
应用这些原则，会得到与流程模型相似的分层化用例结构，如图 2 中所示。
图 2. 分层用例模型
每个用例对对应的流程进行更为详细的定义。另外，还定义将用于调用该流程的服务 的特征。例如，用例的前置及后置条件、输入和输出定义服务依赖关系、边界和数据要求。
手动流程和客户体验流程
图
1 顶部的“手动流程和客户体验流程”层用于为较低层的流程设置上下文。它用于说明系统流程如何适合总体业务流程。这个层中的流程位于系统边界之外，并不描述系统功能，因此不需要对应的系统用例。
流程摘要
除了手动和客户体验流程及用例模型外，另一个有用的沟通工具是端到端流程的摘要，可显示总体用例顺序。摘要之所以有帮助，是因为：
- 用例模型是静态的，并不显示用例执行的顺序。在较为简单的模型中，顺序经常可以推断出来，但对于更为复杂的模型，这样并不现实。
- 客户体验流程遵循分层原则，因此并不显示使用者层之下的任何流程。其价值在于，显示外部使用者“看到”的内容，但并不作为摘要供需要对整个流程进行审查的涉众使用。
为摘要选择的符号可能会有所不同，不过，您应该谨慎使用 BPMN，因为这可能意味着丧失准确性。例如，可以使用价值链
样式的符号。
使用者流程用例
使用者流程（请参见图
1）可以很方便地转换为用例的传统视图，因为他们的重点是参与者（最终用户或外部系统）和系统之间的交互。这些用例包括
其下层的可重用业务流程（长时间运行或短时间运行）。
长时间运行和短时间运行的流程用例
第 1 部分说明了长时间运行和短时间运行的流程在体系结构的业务流程层中执行，可能通过业务流程编排引擎执行。对于长时间运行和短时间运行的流程用例，并没有主要参与者；它们始终由其他用例触发，并不直接涉及任何用户交互。所有步骤都将描述系统处理或包括其他用例（例如，长时间运行的流程用例可能包括人员活动用例）。
短时间运行的流程用例还可以通过生成的事件由长时间运行的流程用例进行扩展。您应该清楚地注意到，在以“即发即弃”(Fire
and Forget) 模式调用流程的流程关系图和用例流中，includes
关系通常意味着必须在继续之前完成所包括的用例。
等同于长时间运行的流程的用例相当于传统的用例标识规则（一个参与者、一个地方，一个时间）。您可以将长时间运行的流程视为工作流流程；它可能会等待外部事件发生，或呼叫一个或多个人员执行任务。不过，指定长时间运行的流程所需的信息与其他用例指定工作相同。通过将长时间运行的流程表示为用例，用例模型可以清楚地表明长时间运行的流程所编排
的其他活动。
由事件触发的长时间运行的流程在 extends
关系中描述。除了启动长时间运行的流程的 start
外，还可能通过事件提示长时间运行的流程在等待 continue。根据建议，extends
关系也应该用于表示这种继续关系。通过这样，所有基于依赖关系的事件都能够在用例模型中得到表示。图 3 显示了不同的
extends 关系使用示例。
图 3. extends 关系的使用
这对 extends 关系的传统含义进行了一些修改，因为长时间运行的流程打破了通常的“一个参与者、一个地方、一个时间”规则，因此非常有必要进行修改。或许这个实例中更为有意义的术语是
is informed by 或
waits for，不过我们要暂停针对此目的建议新的构造型。
人员活动用例
对于使用者流程，人员活动用例描述用户和系统间的交互。人员活动有时候也称为工作流活动，是由长时间运行的流程启动，可能通常从用户在工作列表中选择活动时开始。用户完成了活动后，所有后续业务处理都应该由长时间运行的流程进行。人员活动的范围应该限于用户交互。人员活动用例的输出（成功或失败）必须由将其包括在其中的长时间运行的流程用例进行检测和处理。
自动化活动用例
通常，自动化活动与用例流（主场景和备选流）中的步骤对应。自动化活动可能与业务规则对应，在用例中引用，可以为重用或数据操作。此类自动化活动经常过于精细，以保证自己的用例。
不过，在有些情况下，将自动化活动定义为独立的用例可能会有用。例如，涉及到复杂交付的外部系统的接口可能要求定义多个步骤或备选流。这些应该作为独立用例记录，以促进接口的重用。
正如第
1 部分中所述，长时间运行的流程、短时间运行的流程和自动化活动都由服务进行调用。使用者流程通常不是如此（它们使用服务），除非流程向外部使用者公开，如使用
B2B 接口的业务合作伙伴。
如果您应用本文中描述的用例建模技术，用例（使用者用例除外）将以相同的方式与服务对应。非常方便的是，用例规范和服务规范有很多相同的特征，可以将用例规范视为服务规范的早期版本。二者都具有：
- 唯一的名称
- 目标或目的
- 输入和输出
- 前置和后置条件
- 关联的流程流
- 依赖于其他用例或服务
在本文中，您了解了如何将本系列的第 1 部分和第 2 部分的流程分解技术扩展到用例。用例的标识是由与
SOA 相一致的流程模型驱动。用例中所述的需求在 SOA 中以服务的形式更进一步接近具体的实现。
业务分析和 IT
体系结构
与 SOA 一致的流程驱动的用例建模工作如果完成得当，能够提高需求规范与实际解决方案的对应关系。由于联系密切，最好有业务分析师和架构师一起进行此工作，或由在这两个领域都非常擅长的人员进行。我们预计，通过应用本系列中的这类技术，将会使业务分析师和架构师角色之间的区别变得模糊。将会越来越需要同时具有这两方面技能的人员。
自顶向下和自底向上
用于用例建模的方法可以视为 SOA 设计的自顶向下方法，服务操作基于所需的场合进行标识。在 IBM 的面向服务的建模和体系结构（Service-Oriented
Modeling and Architecture，SOMA）方法中，这将是“域分解”(Domain Decompositon)
步骤的一部分。
业务分析师或架构师是否正确地选择了服务取决于其他因素，如组织的现有系统支持哪些服务等。在成熟的 SOA
环境中，关于服务的信息在服务存储库中提供，可以“包括”在功能需求模型中。在成熟度较低的环境中，需要对现有系统进行分析，以完全了解已经提供哪些服务。在
SOMA 中，这归入“现有系统分析”(Existing System Analysis) 中。
请继续关注第 4 部分，我们将使用一个案例研究来演示前三个部分中的技术。
作者要感谢 Richard Solly、Pete Cripps、Bruce Anderson 和 Sunny
Shah 对本文的早期版本提出了建设性的反馈意见。
学习
获得产品和技术
讨论
| 
