场景建模与交互建模

　　
    场景建模的下一步是在活动中引入参与者角色。交互发生的方式对业务流程在顺境和逆境
下的执行均有影响。

 

　　

 

　　场景建模的一开始需要对从产生结果所需基本活动流的理解进行抽象。这时还没有角
色

――只有对所需活动的理解，活动所需、源自流程外部的输入以及活动产生、为其他流程

预备的结果。这种抽象理解常常可由分析产生相同结果的其他业务流程得到，如已经讨论过
的

“通过柜员取款”例子。这个特殊表示法使用 UML 20 活动符号，它是我们熟悉的流程图的

增强版本。

 

　　在这个抽象流程视图中，最初的焦点是识别为完成业务流程而必须发生的活动。针对它
们中的每个活动，你需要确定它是否需要来自流程外部的输入，以及它是否产生输出到流
程外部的结果。

 

　　你还得确定所需的活动顺序，并且要非常小心地完成这一步，因为在这里指定的任何
顺序都必须随流程的细化而保留。因此，假如多个活动可以同时发生，那么就必须在你的流
程描述中清楚地指出这一点。可以使用活动图符号

Fork 和 Join 节点来表示这种机制。Fork 节

点的语义是，在前一个活动完成后，随后的活动允许并行执行。与此相反，

Join 节点表示只

有前面所有活动都结束之后，后面的活动才能开始。参与者角色划分

 

　　场景建模的下一步是在活动中引入参与者角色。每个角色由一个活动区

(通常称为泳道)

表示。每个区使用它代表的参与者名字标出。如果你在使用一个

UML 建模工具，请记得使

用分区的描述

(represents)属性引用你在协作中定义的角色。一旦这么做了之后，假如你想重

命名一个角色

(很可能是由于你细化业务流程定义引起的)，你只需编辑协作中的名字即可，

所有的分区名将自动更新。

 

　　

 

　　活动职责分配

 

　　

 

　　流程建模接下来的步骤就是将活动放到活动区。将活动放入分区相当于分配职责。它表
示扮演那个角色的参与者负责执行这个活动。把活动放入泳道的行为迫使你清晰地理解每个
参与者在流程中所做的事。它强制你把抽象活动划分成各个参与者能够执行的具体活动。这
些活动分配标识了参与者之间所需的交互，以及这些交互涉及的工件。

 

　　抽象的

“认证客户”活动变成比较客户提供的 PIN 和银行记录中与 cardID 关联的 PIN；

抽象的

“验证鉴权”活动变成查找与卡关联的账户。 

　　虽然余额管理器

(即银行)制定与“认证客户”和“验证鉴权”关联的决策，但是其他参与者

角色也有各自的职责。客户必须提供

cardID(通过插入 ATM 卡)和输入 PIN。柜员(即 ATM 系

统

)必须汇总这些信息并把它传给余额管理器。 

　　为了从业务流程的角度更容易处理这些情况，

ATM 必须与余额管理器进行两次交互。

第一次交互，金额支出被鉴权，并且在账户资金上冻结了相应的取款金额。这部分冻结资金
防止了其他目的的取款。资金成功支出之后，发生第二次交互，在这次交互中

ATM 系统报

告支出，而余额管理器更新余额并删除冻结资金。因为该账户可能还有其他冻结资金

(来自

其他交易

)，支出报告必须和被删除的特定冻结资金相关联。在这个设计中，关于冻结资金

的信息和支出鉴权一起返回给

ATM 系统，冻结资金的标识符随支出报告一起返回。还要注

意，冻结账户资金有意地影响了其他业务流程的执行。它还代表了另一种流程间的交互。

 

　　案例中的

“认证客户”活动说明了，如果不给参与者角色分配活动，就很容易创建出一

个实际是两个或多个参与者间协作努力的活动。这种协作活动习惯假设参与者间的对话是清