了解流程模型如何驱动用例模型和服务模型。本文通过家庭购物的案例研究将所有东西联系起来，以演示本系列之前部分中的概念。在本系列中，您将了解一项新的业务流程分解技术，以帮助您指定与面向服务的体系结构（Service-Oriented
Architecture，SOA）一致的业务流程。
在本系列的第
1 部分和第 2 部分，您了解了创建业务流程模型的一种方法，可实现业务流程和基于面向服务的体系结构（Service-Oriented
Architecture，SOA）的目标体系结构的一致性。这些模型与所实现的实际解决方案有更好的对应关系。第
3 部分对此原则进行了扩展，基于流程模型描述了用例建模技术，使其用例与目标体系结构具有类似的一致性。
本文使用虚构的公司 Books R Us 的示例案例研究演示本系列前三部分的概念。了解流程模型如何驱动用例模型和服务模型。
虚构的 Books 'R Us 在线销售书籍。客户可以采用各种方式浏览书目，通过公司的网站订购书籍。第三方零售商可以使用
B2B Web 服务接口订购书籍，可以将其链接到自己的系统。一旦客户或业务合作伙伴通过这两个通道之一下了订单，就将履行订单。履行订单涉及到处理支付和向客户配送产品。在履行订单期间可能出现的与支付和库存相关的特定问题将在案例研究中进行讨论。
关于示例
出于简洁性考虑，并没有记录所有流程，不过提供了每个流程层的示例。记录流程和随附的用例时，它们在关系图中以粗体显示。
用例以大纲形式提供，而不会给出详细的用例规范。例如，流以摘要方式显示，而不是给出详细的逐步主场景和备选场景。业务规则尚未定义。
流程模型本身基于业务流程建模符号（Business Process Modeling Notation，BPMN）V1.1。这个符号与第
2 部分讨论流程模式时使用的略有差别，第 2 部分使用的是 BPMN V1.0。本文还使用特定的命名规则来尽可能保持关系图的清晰和简洁。此示例使用与第
2 部分相同的图标，如下所示。
图 1. 关系图的关键图标
使用 BPMN 1.1
表示用户交互
BPMN 符号有很多微妙的东西。尽管 BPMN 并非设计用于建模用户界面，但它的确支持各种表示用户界面的方法。为了更为紧凑，案例研究使用并不严格遵守
BPMN 标准的符号。图 2 显示了一个示例。
图 2. 屏幕流符号
按照 BPMN 标准的准确解释，这些符号代表可以并行选择的多个路径，但我们并不是这个意思。我们希望您接受图
2 中所示的备选项。
图 3 显示了客户体验流程，这是一个虚拟层。当然，客户体验并不能轻松地建模为明确的流程，只是用于显示上下文中的使用者流程。
图 3. 客户体验流程：购书
本文稍后的部分将介绍客户体验流程“购书”(Shop For Books) 下的流程分解，并给出每个流程的系统用例大纲。所得到的用例模型的摘要如图
4 中所示。在现实中，这是建模练习的输出，而不是工作的起点。
图 4. 家庭购物用例模型（最终结果）
图 5 中所示是端到端流程的“价值链”演示，显示了用例执行的顺序。
图 5. 家庭购物流程摘要
此部分将逐个介绍图
4 顶部的“使用者流程”(Consumer Process) 部分中的编号用例。
用例 UC01：选择产品
客户从在线商店开始，浏览书籍，并可能会将书加入到购物篮中。这个用例可以对多本书重复。
- 目标
- 选择产品，并添加到购物篮。
- 触发
- 用户选择浏览产品目录。
- 主要参与者
- 客户。
- 前提条件
- 客户在线。
- 后续条件
- 产品已添加到之前存在的购物篮中，或新创建的购物篮中（如果没有）。
或者，在超时的情况下，不会发生任何动作。
- 流程
- 用例描述
- 系统向用户显示书店，并提供按目录导航的选项，或进行搜索。用户还可能选择产品来查看产品详细信息。当用户选择将产品添加到购物篮或超时，则用例结束。
用例 UC02：在线结帐
在将书放到购物篮中后，客户将需要结帐。
- 目标
- 对当前购物篮中的物品下订单。
- 触发
- 用户选择进行结帐。
- 主要参与者
- 客户。
- 前提条件
- 客户的购物篮中必须有一个或多个产品。
- 后续条件
- 已经对购物篮中的物品下了订单。
或者，因为以下情况未成功下订单：用户无法登录，不能成功捕获送货或支付详细信息，用户取消，或会话超时。
- 流程
- 用例描述
- 此用例允许用户对购物篮中的物品下订单。系统首先确保用户登录，然后捕获他们的送货地址和支付详细信息。系统向用户显示订单摘要，以便进行确认。订单一旦确认之后，将调用短时间运行的流程“下订单”。成功完成“下订单”后，将向用户显示最终的确认。
- 涉及
- UC04 在线捕获地址；UC05 在线捕获支付详细信息；UC10 下订单；UC12 登录
用例 UC03：下
B2B 订单
Books ‘R Us 还支持业务合作伙伴使用 B2B 接口的订购通道。这个通道和在线通道都使用相同的“下订单”用例。
- 目标
- 通过 B2B 接口下一个或多个订单。
- 触发
- 第三方业务合作伙伴提交批处理作业，包含一个或多个订单。
- 主要参与者
- 第三方零售系统。
- 前提条件
- 无。
- 后续条件
- 已下了零个或多个订单。一批响应已经返回到第三方系统。
- 流程
- 用例描述
- 这个用例允许第三方零售商通过 B2B 接口向书店提交订单。订单从批处理作业中提取，并由“下订单”短时间运行的流程执行。响应将合并并返回到第三方系统。
- 涉及
- UC10 下订单
此部分逐个介绍图
4 中的“长时间运行”(Long Running) 部分的用例。
用例 UC06：履行订单
下了新订单时（通过下订单用例），将启动订单履行流程。这是长时间运行的流程。
- 目标
- 响应已下的订单，将产品派送给客户。
- 触发
- 已经下了新订单。
- 主要参与者
- 无
- 前提条件
- 必须下了新的有效订单。
- 后续条件
- 订单物品已记录为已派送。收取客户支付款项。向客户发送派送确认通知。
或者，所订购的一个或多个物品缺货，或不能进行支付。如果这两个中之一未能解决，客户将会收到订单取消确认。
或者，对订单进行修改，以处理缺货的物品，并按照其他后续条件履行订单。
- 流程
- 用例描述
- 这个用例代表长时间运行的流程，此流程对活动进行编排，以履行已下的订单。如果订单物品在库存中，将调用人员活动将订单路由到仓库，提货和派送，并收取支付款项。然后将向客户发送确认，并更新订单状态，表明已经成功履行订单。
如果订单物品不在库存中，但很快将到货，流程将等待仓库进货。
如果订单物品没有库存，也不会到货，将调用另一个人员活动，以解决缺货的物品。这可能涉及到联系客户进行订单修改。
如果在获取支付详细信息方面有问题，将调用另一个人员活动来解决支付问题。
如果人员活动没有成功解决问题，仍然会向客户发送确认信息，但这次的确认内容将有所不同。例如，它将告知客户取消了订单。
- 涉及
- UC009 提货、派送、收取支付款项；UC011 解决缺货问题；UC012 解决支付问题
此部分讨论图
4 中的“人员活动”(Human Activity) 层。
用例 UC07：提货、派送、收取支付款项
履行订单的主要方面是从库房提货、收取支付款项并派送货物。这些通常由一个人进行，因此归入流程模型中的单个人员活动。
- 目标
- 获取订单支付款项并向客户派送物品。
- 触发
- 订单已分配给用户，用户从工作列表中选择此订单。
- 主要参与者
- 订单提货员。
- 前提条件
- 向流程中传入了有效的新订单的 ID。
- 后续条件
- 已进行了支付，订单物品已经派送。
或者，订单已经暂停（并在传递回进行调用的长时间运行的流程的结果中提供了原因）。
- 流程
- 用例描述
- 这个用例代表由安排订单提货的仓库工作人员执行的人员活动。用户将仓库中有的产品对应的物品记录为已提货。提取了所有货物后，将处理客户的支付，系统将显示运输详细信息，以便订单提货员派送物品。一旦派送确认，此用例就结束了。
如果缺货，或支付不成功，订单可以暂停，用例以失败告终。
用例 UC08：
解决缺货的物品
“履行订单”长时间运行的流程还有解决订单问题的人员活动。其中之一是仓库中物品缺货。
- 目标
- 解决库存问题。
- 触发
- 用户从工作列表中选择订单。
- 主要参与者
- 订单修订人员。
- 前提条件
- 订单必须已经标识了一个或多个物品缺货。
- 后续条件
- 订单已修改，问题记录为已解决。
或者，订单被取消。
- 流程
- 用例描述
- 此用例代表由客户服务代表执行的人员活动，该代表将解决库存问题。用户浏览和搜索内部网商店查找替代商品（或许通过与客户沟通确定），可以修改订单，以替代缺货物品或删除此类物品。一旦用户确认缺货物品的问题已解决，则此用例结束。
或者，用户可以选择取消订单。
此部分逐个介绍图
4 中的“短时间运行”(Short Running) 区域的用例。
用例 UC10：下订单
下订单在我们的场景中是一个重要用例。这个短时间运行的流程遵循本系列第
2 部分中所述的“执行事务”模式。
- 目标
- 验证和存储已提交的订单。
- 触发
- 订单已提交。
- 主要参与者
- 无
- 前提条件
- 已经提交了涉及一个或多个产品的订单。
- 后续条件
- 存储了有效的新订单。
- 流程
- 用例描述
- 此用例代表一个短时间运行的流程，此流程验证所提交的订单的详细信息，并存储新订单，准备供后续处理。所执行的验证包括产品详细信息、地址和支付详细信息。
如果任何验证失败，会向调用方返回错误消息。如果验证成功，将创建订单，并将订单详细信息返回给调用方。新订单
(New Order) 事件触发后续处理。
您可以从流程和上面的用例分解直接派生服务模型。使用者流程层下面的所有流程都通过服务公开。“下 B2B
订单”使用者流程作为服务向第三方零售系统公开。
自动化活动层中的服务从较高层中的详细步骤标识。其中假定人员活动以服务调用方式进行调用。所得到的服务模型如图
6 中所示。
图 6. 家庭购物场景的服务模型
在本系列中，您了解了一项流程驱动的技术，用于定义面向服务的解决方案。我们讨论了面向流程的建模，涵盖从流程图到用例和服务的各个方面。通过本文中的示例，您可以大致了解所带来的好处。
业务一致性
此技术能得到业务涉众很容易理解的模型，这一点已经通过作者实际使用这项技术的体验得到证实。每个流程都代表非技术涉众应该清楚了解的概念。例如，使用者流程代表组织的通道，短时间运行的流程代表其支持的事务，而长时间运行的流程代表工作流。所有这些都可以由采用自动化活动形式的服务加以支持。通过此技术，可以得到简洁（但仍然完整）的流程图，能够避免众多页面上数不清的杂乱连接。
促进重用
图
6 中的服务模型演示了重用，其中多个调用箭头指向同一个服务。例如：
- “下订单”(Place Order) 服务由两个通道重用（在线和 B2B）。
- 各个自动化活动服务由多个流程重用，如“获取订单详细信息”(Get Order Details)。
这个示例并不完整，但您肯定会面临着多得多的重用机会。例如，如果您完成了“修改订单”(Modify Order)
事务，则可以使用“创建订单”(Create Order) 所使用的相同验证服务。
增强的可跟踪性
在 IT 行业，要演示要求解决方案完成的任务有一定的问题。这个问题通常通过以下两种方式之一解决：
- 架构师通常设计与所需的结构紧密一致的解决方案，而这在很多情况下采用的是用例模型的形式。这个结构通常由业务分析人员设计，分析人员主要考虑的是满足其业务客户的要求。他们不关心
IT 体系结构，这样可能会导致糟糕的体系结构，缺乏灵活性，而且随意性较强。
- 为了避免上面的情况，架构师设计独立的解决方案，并维护复杂且昂贵的可跟踪性表来以某种方式说明每个需求得到了满足。可跟踪性构件经常非常巨大、复杂，且缺乏可管理性，掩盖了本来要解决的问题，如“如果我测试系统的这个部分，我测试的是哪些需求？”或“是否满足了所有需求？”
如果所需的东西在解决方案将采用的体系结构的上下文中加以表示，那可跟踪性就会变得简单得多。 如果架构师和业务分析人员紧密合作，而且使用所描述的面向流程的建模技术（结合现有的系统分析），那么可跟踪性就能在
SOA 项目得到极大的增强。
学习
获得产品和技术
- 下载
IBM 产品评估版或在
IBM SOA 沙箱中进行在线试用，获得 DB2®、Lotus®、Rational®、Tivoli®
和 WebSphere® 的应用程序开发工具和中间件产品。
讨论
| 
