BPMN2.0教程-泳池泳道
泳池和泳道都是BPMN中表示“参与者”的组件，泳道不能单独存在，只能放在泳池中。作为“容器”类型的组件，泳池或泳道中可以放置其他类型的组件：比如活动、网关、事件、顺序流等。
泳池
介绍泳池：乐队的指挥
这里的
指挥是名词，我感觉中文环境中用“指挥”这个词比指挥家或者乐队指挥的效果反而更好。就像“领导”这个词，既可以理解为名词Leader，也可以理解成动词，表示带领。
我们已经描述了如何使用泳道将任务或子流程的职责分配给不同的任务管理员。泳道始终存在于泳池中，泳道的边界就代表示流程从开始到结束的边界。对BPMN而言，泳池表示的是比它的泳道级别更高的实体。泳池承担着流程控制，换句话说，由泳池来分配任务。它的行为就像乐队的指挥一样，因此这种流程称为“编排”。
在下图中，指挥安排Falko，让他在Robert完成任务1后，立即处理任务2。指挥对流程有着最高的控制权，乐队里的每一种乐器都按照指挥的这些决策去演奏曲子：
你会认为这是不现实的吗？许多经验丰富的流程建模者都对这种思维方式存有疑问。在他们的公司里并没有这样一个全能的指挥，各个流程的参与者必须自行协调和合作，他们更愿意建立如下所示的流程模型：
但是要与BPMN协调合作，就需要进行显式的建模。可以为每个任务的管理员分配一个单独的泳池，流程从一个泳池传递到下一个泳池，如下图所示。原则上，这会创建出四个独立的指挥，它们控制着各自的小流程，但是除了发送消息来触发它们的后续流程之外，别的啥也做不了：
这看起来很复杂，但是在实际建模中你不是必须选择这种方法。然而它却展示了一个你必须理解的基本原则。尽管BPMN的泳道看起来非常像那些其它的流程符号，但是它们代表的是完全不同的思维方式。我们将其归因于BPMN在流程自动化世界的起源。在那个世界中流程引擎控制着流程中的所有任务，即使可能是由不同的任务管理员执行它们。所以流程引擎普相当于是那个神秘、全能的流程指挥。
你是否听过关于SOA的服务编排的概念（面向服务的架构）？它几乎完全就是流程引擎中的任务，除了这些服务不仅是完全自动化的Web服务；它们也可以是在流程引擎的指导下由作为流程参与者的人类去执行的任务。然而，对于纯功能的流程建模，这又意味着什么呢？你还可以描述不受流程引擎控制的流程吗？这个问题并没有普遍的答案。
可以去除泳池只用泳道，用前面所示的常规任务来建模消息的交换。这是一种很传统的做法，同时也是在过渡期中的一种实用的解决方案（这是一段让你的同事适应的过渡期）。但是，从中长期来看，回避使用泳池会使你失去一个增强流程建模的强大工具。
我们将通过例子来展示这种新思维的实用性。需要记住的一件事情是，如果你力图调和功能和流程建模技术，以达到更好地实现业务与IT的一致性，那么无论你是否使用BPMN，都不可避免地要面对这种类型的流程建模。
泳池：协作的艺术
现在考虑更广泛的情况，站在Pizza配送服务的角度考虑这个流程是如何发生的。流程大概是这样的：一接到订单，我们就烤披萨。我们的配送员把它送到客户那里，然后收钱，这样整个流程就成功地完成了。
我们希望将这两个流程联系起来，即，从一个中立的角度来审视顾客和配送服务的交互。我们可以尝试着用泳池和泳道对这种交互进行建模，如下所示：
但是这样并不能很好地工作：有些任务和事件引用了泳池中的交互，例如等着收货或收款。其它的任务则是由未察觉到的角色所完成的，例如烤Pizza和吃Pizza。
光从图上看没有办法区分这两者。严格地说，这个图在语义上是不正确的，因为消息事件总是引用流程从外部接收的消息，而在这个示例中并不是这样的。
如果我们使用多个泳池的话，则整个流程看起来就像下图这样。被组合起来展示的每个流程，每个看起来都和以前一样，但是现在它们是通过消息流进行连接的。BPMN把这种形式称为协作图。它显示了两个独立的流程之间的协作。
在两种情况下，消息流并不以活动或事件结束，而是以参与者各自的池边界结束（也就是那个虚线的终点没连接到泳道中的某个事件或活动，而是直接连到了泳池的框框上）。第一种情况：也就是从上图“调用Pizza配送服务“这个任务连接出来的，连接到下面这个泳道；第二种情况：也就是从上图“收钱”这个任务连接出来的，连接到上面的那个泳道。第一种情况背后的原理是我们的查询不会影响配送者的顺序流。Pizza服务可能会提供信息或者加快已有订单的处理速度（假设预计有新订单到来），但烤焙、配送和收钱不会因为有人查询而改变。对于“收款”消息，顾客流程模型存在缺陷：我们在吃Pizza之前必须先付钱，但是任务仍未完成。我们将其添加到下图中，现在我们可以将消息流直接连接到“为Pizza付款”任务（在上面的那个泳道中）。
折叠泳池
我们通常不能详尽的了解到流程的所有部分。例如，我们可能知道自己公司的流程，但是不知道合作伙伴公司的流程。只要我们的合作伙伴和我们都遵守约定好的接口（例如接收或发送特定的消息），事情还是可以顺利进行。
作为Pizza配送服务的顾客，我们希望配送方能够：
- 接收Pizza订单。
- 配送已订购的Pizza并收钱。
- 可以接受查询。
作为顾客，我们对配送方的内部流程不感兴趣。也许他们会自己烤披萨，然后送出去；也许当他们缺货的时候，他会找另一个Pizza店来烤Pizza并送过去（也就是俗称的“串货”）。但这些是他们的问题，我们只是期望收到Pizza。在为此类情况建模时，我们可以隐藏配送者的流程并折叠池：
我们还可以更进一步，把顾客的泳池也折叠起来。现在我们只看到了交换的消息，假定我们标出的箭头可以给出我们大致的意思。它的缺点是我们再也无法知道到相互依赖了。我们无法确定“查询”是否总是执行，还是只是在特定的条件下执行。实际的例子如下：
泳道
我们已经讨论了在流程中要做什么，但是还没有解释谁负责执行哪些任务。在BPMN中，可以用泳道来回答这个问题。
上面这个图显示了我们示例流程中的任务被分配给了特定的人。我们可以从这些分配推导出以下的流程描述：如果Christian饿了，他会选择一种食谱。基于Christian的选择，他要么自己处理这件事，去做意大利面，或者叫他的室友们出马。Falko做牛排，Robert准备沙拉，最后被Christian吃掉。这三条泳道（Christian, Falko, Robert）被统一到“合住公寓社区”这个泳池中。
常见问题：必须用一个具体的人来标记泳道吗？
在本例中泳道相当于人，但是BPMN并没有指定这个含义。你可以随便指定泳道代表什么。在实践中，泳道经常会被用来分配给：
- 组织架构中的职位，例如，会计师。
- 组织架构中的角色，例如，资料保管员。
- 一般角色，例如，顾客。
- 部门，例如，销售。
- IT应用程序，例如，CRM系统。
参考