晰可行的一种常常被证明是错误的假设。如果你是第一次设计

ATM 系统，这种模糊的活动

描述可能会让你认为传统形式的证明

(如出示驾照)可以作为识别的基础。 

　　通过将活动放人分区来分配职责，你迫使自己去划分各种活动。这使你去探索这些协作
的本质，定义各个参与者活动和它们间所需的通信。这种探索通常足以暴露和解决业务流程
定义过程中的任何可行性问题。

 

　　

 

　　交互建模

 

　　

 

　　交互发生的方式对业务流程在顺境和逆境下的执行均有影响。你的流程描述要想精确地
指出它们在所有条件下的行为，你就必须在设计中清晰地捕获和描述交互。

 

　　

 

　　生产者

-消费者交互 

　　

 

　　事实上，所有交互都采用的是生产者一消费者交互形式。在这种交互中，一个活动产生
准备被一个或多个活动消费的工件

(在 UML 符号表示法中称为对象)。这个工件可能是具体

事物，如

ATM 产生的现金或收据；也可能是抽象事物，如来自银行的资金支出请求。当然，

在实现设计时，这种抽象通常会有某种具体的表现形式，如消息、数据库记录或甚至是语音
通信。

 

　　

“产生工件”是用活动指向其产生工件(技术上可认为是对象)的箭头(技术上可认为是对

象流

)来表示的。“消费工件”(可能会有不止一个工件)则被表示成由工件指向每个准备消费它

的活动的箭头。工件本身的位置完全没有任何符号上的意义，记住这一点也很重要。因此，
工件被画在角色

A 的活动区或完全在区域之外，图的含义都将保持不变。 

　　严格地说，在分布式系统中，参与者间所有的交互其实都应该被显示成生产者一消费
者关系。这是因为，在现实生活中参与者很少直接交互。相反，它们绝大多数时候都是借助
某种媒介进行交互，如纸张、电子邮件、系统消息、文件、数据库、包裹、管线或某些其他方法。
工件代表了发送者通过媒介传递给接收者的任何事物。例如，

ATM 系统产生支出请求，它

是一条传送给银行的消息。然后，银行产生一个响应，它是一条传回给

ATM 系统的消息。 

　　

 

　　同时交互

 

　　

 

　　参与者之间偶尔确实会有直接交互：它们间真正的同时交互。握手就是这种交互的一个
例子：两个人同时在做完全互补的动作。在现实中，分布式系统中的参与者极少同时直接交
互，例如，即使人们在彼此对话的时候，他或她的声音也要产生别人可以听到的声波

(工

件

)。 

　　了解这两种交互风格的区别非常重要，因为它们可能的出错模式大不相同。在同时交互
中，整个交互要么发生，要么不发生

――它基本上是一个原子动作。前一个活动的完成时间

就是下一个活动的开始时间：要么两个都发生，要么都不发生。但是，如果通过媒介进行交
互，那么前一个活动产生某个工件，随后将其传递给下一个活动。这种交互模式有一种同时
交互所没有的出错模式：工件的传递可能失败。前一个活动可能确实产生了工件，但是在传
递过程中出现问题，导致工件可能永远不会被下一个活动接收到。当你试图设计一个考虑失
败情况的健壮流程的时候，这种失败模式的区别是非常重要的。

 

　　

 

　　简化符号