与网友关于业务工人(business worker)的讨论

  1、business worker 的作用是操作业务实体而非业务用例；

2、business worker 的作用是“实现” 业务用例而不是“使用”业务用例; 
3、business worker "存活"于整个业务用例的执行过程中。换言之，它在业务用例启动之后才会存在，并随着业务用例的消亡而消亡；

近日，有一位网友对我<Thinking in UML早知道 -- 004--参与者基本概念>一文中第4种情况，把人工座席定义为业务工人并放在在系统内部提出了疑议，他的基本观点如下：

***********************

这里，他的问题就出在了把人工座席当作业务工人看待了，在一个计算机系统中，人是不能成为计算机系统内部的一份子的，计算机是为人服务的、是自动化的、是有自己的系统边界的，把人放入计算机系统中，是一种糊涂，一种没有分清系统边界的糊涂；假使我问，你如何对“人工座席”编程？你怎么用代码处理人工座席中的人？如果非要把人看作计算机系统中的一份子，那么餐馆的就成了计算机系统了？可这与后面的系统设计、开发、编码又有何干？

只有把人工座席看作是参与者，才能得到正确的定票系统的服务对象，才能为人工座席提供相应的功能支持，人工座席是这样（参与者），系统的维护人员也是参与者，而不能看作系统内部的一种奇怪的事物。只有这样认识才能说是对usecase的参与者是谁的分析技术真正掌握了。它不难，但却经常有人出错。

******************************

首先很高兴能有类似这样的讨论，其次，由于我觉得这位网友的观点与我的观点出入较大，有必要将我的观点加以一些说明，因而进行了以下回复。网友们也可加入这个讨论：

首先我不知道您对business worker是如何理解的。其次，我不知道您对业务建模与系统建模这两种截然不同的建模过程和建模目标是如何理解的。我文章中的提到的是参与者“是与系统交互的人或物”，请注意这里并未明确系统是“业务系统”还是“计算机系统”，而您所提到的参与者是“谁操作计算机谁就是参与者”，因此冒昧的认为您所讨论的的范畴是系统建模，换言之，您所讲到的参与者是(system) actor，您所提到的用例也是(system) use case。
(顺便解释一下，在我文章里之所以没明确业务系统还是计算机系统，是因为actor这个概念对两种系统都适用，actor在特定的建模阶段有不同含义，体现出了stereotype的不同，而这篇文章是讲actor的通用特性而不是特定的stereotype的特性的。后续的文章才会讨论具体的差别)

假设您是从系统建模出发，当然没有business worker，但是如果从业务建模出发，business worker则是切实的存在。

在RUP的定义中，business worker (下面翻译为业务角色，在我的文章中称为业务工人)的定义是：

业务角色（Business Worker）是对业务中发挥作用的人员的一种抽象。业务角色对象与其他业务角色对象进行交互，操纵业务实体对象，以此来实现业务用例实例。我们使用角色个体作为业务角色对象的同义词。

业务角色代表业务中的一个或一组角色。参与业务用例实现时，一个业务角色和其他角色进行交互，并操纵业务实体。

在以下情况下对角色进行实例化（“分配人员”）：启动其相应用例实例的工作流程时，或者最迟应及时地让相应职责承担者在用例实例中发挥其应有的作用。角色对象通常“存活”（即人员处于工作中）于整个业务用例的执行过程中。

从定义中我们可以看出：
1、business worker 的作用是操作业务实体而非业务用例；
2、business worker 的作用是“实现” 业务用例而不是“使用”业务用例; 
3、business worker "存活"于整个业务用例的执行过程中。换言之，它在业务用例启动之后才会存在，并随着业务用例的消亡而消亡；

回到事例中，在进行业务建模时，机票预定者这一业务主角（business acor）所确定的业务用例是预定机票，他可以使用两个业务场景：通过网站或通过电话。在第二个业务场景中，只有当机票预定者打入电话启动业务用例时，人工座席才被激活而开始工作；当机票预定者得到结果以后，人工座席则停止工作状态。

如果按照您的理解，人工座席位于业务用例，即业务系统之外，则会出现这样的情况：没有机票预定者电话的情况下，人工座席自作主张开始订票。合理么？其次，如果非要将计算机概念加到业务建模过程当中来，那么您如何保证当系统内的一个进程结束时结束系统外的一个对象的生命周期？这才是奇怪的。

至于您所提出的驳斥观点，只能说您站在系统建模的立场上来驳斥业务建模，有点关公战秦琼的味道了。业务建模的目标与计算机实现本来就没有关系，它是用来了解目标组织的业务行为和组织结构形成业务需求，然后作为一项输入来导出系统需求的，它与“你如何对“人工座席”编程？你怎么用代码处理人工座席中的人？”又有何关系？业务建模本来就与编程无关，怎么编程不在业务建模关心的范围之内；如果您坚持“如果非要把人看作计算机系统中的一份子，那么餐馆的就成了计算机系统了？可这与后面的系统设计、开发、编码又有何干？”的观点，很遗憾，您所讨论的是系统建模，而系统建模过程里根本没有business worker这样一个定义，您驳斥的是一个不存在的概念。

最后，您可以参考一下BPEL4People规范中的HumanTask活动定义，也可以参考IBM WID（WebSphere Integration Developer）产品中实现Human Task活动的细节，您应当可以了解到人是如何在计算机系统中定义和实现的。实际上，人作为系统内部的一个对象，它也是可以被计算机call的，并非您所认为的人不能作为计算机的一份子。在BPEL4People规范中，人在计算机当中有这样几种定义：
参与任务（Participating Task）、发起任务（Originating Task）和纯粹的人工任务（Human Task）三类。参与任务又被称为M2H任务 (Machine-to-Human)，即业务人员提供了服务接口实现，可以认为是机器在调用人。发起任务是一种常见的使用场景，人通过输入特定的业务参数，调用系统的业务逻辑并获取计算结果，此时是人在调用机器，所以发起任务又可以被称为H2M任务(Human-to-Machine)。纯粹人工任务则是一种单纯的人调用人的服务，它拥有两种基本的参与角色：服务请求者与服务提供者。服务请求者为服务提供者创建待处理任务，服务提供者提供了该服务接口的具体实现，所以人工任务被称为 H2H任务 (Human-to-Human)。

在我文章的例子中，人工座席恰好就是一种M2H任务。换句话说，人工座席是被呼叫中心调用的，这正是business worker的意义所在

欢迎原观点作者和广大网友参与讨论。

coffeewoo 发表于:2008.01.11 18:12 ::分类: (  系统分析、设计，UML及OO , ) ::阅读:(1146次) ::  评论 (15)