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的意义所在
欢迎原观点作者和广大网友参与讨论。
re: 与网友关于业务工人(business worker)的讨论 [回复]coffee兄逻辑推理思维了得，把OO分析与设计过程用逻辑推理的方式说明了如何从业务过程过渡到系统模型，进行了总结，经典！同时也把自己思考和总结出的抽象角度和抽象层次的说明通过实例的细致描述，其描述语言更加言简意赅，易懂(敬佩)！抽象角度的描述更加证明了，OO系统商业建模，一切以人为中心的思想，从涉众中找出业务主角，业务主角的视角不同程度的表达了业务领域的问题域，每个业务主角对问题域的视角，体现出问题域的抽象层次！这里想请教一个问题，在业务建模过程中通过业务场景中找到的业务实体对象，是否是与现实世界的对象需要完全对应呢？我在读其它的书中，一些动词也可以作为领域模型中的业务实体，甚至是一些抽象名词业务也可以作为业务实体对象，但个人感觉在业务建模阶段，一切都应该是业务术语，应该用现实世界的实物进行映射，来说明业务实体对象，至于抽象名词或者过渡到系统建模之后的实体对象，是通过不同阶段，分析之后的结果！业务实体类图中可以出现动词，但这些动词应该是类图之间连线说明类图的用意描述，便于让阅读者理解模型表达的意图！coffee兄，不知，我的理解是否正确，给些指点，好吗？其次，还有个问题想请教，业务领域模型是概念模型的一种，可知业务领域模型是概念模型的一个子集，那其具体区别在哪里呢？其职责具体体现是什么呢？望其执教，在此多谢了！最后一个问题，分析模型是为了追溯需求，验证需求，设计模型抽象层次更低，都说分析模型和设计模型用相同的方式进行分析和描述，但由于设计模型抽象层次更低，此时，系统边界已经缩小到真正的参与者与系统的交互，用例描述也完全是用户的请求和决策加入到IT系统，IT的系统的直接回应，此时，是否可以依旧应该考虑设计模式的应用，结合具体设计场景，加以符合场景的设计模式，来保持系统结构的扩展性和可维护性，此时，想请教一个问题，您的分析模型的设计，就用到了设计模式来调整分析模型，那是否说明了，设计模型更贴近了实现，在分析模型考虑设计模式的应用，是站在更高的层次，而在设计模型的描述过程中，需要结合系统成本的需求，周期性，和技术条件等等，同时考虑现有市场已有或成熟并可采用的FrameWork，在更低的层次来考虑如何加以设计模式，是这样的吗？期待您的回复和解答！另附：期待您的大作书籍已经很久了，能告知哪个出版社的，书具体的名称和具体出版时间吗？到时，一定第一时间购买，好期待哦！！！
re: 与网友关于业务工人(business worker)的讨论 [回复]coffee兄，能否结合你日常的工作和思考问题的方式，给大家一个通用思考问题的抽象角度的描述呢？结合您的这么多文章大作，总有一种感觉，您一直立足于(业务)需求的获取和描述，并且从业务问题域的目标组织的业务需求，来说明业务架构的重要性！想请教一下，何时能多多描述各种建模过程是如何把物的概念鼓起(说明物的重要性)来呢？毕竟我们做的是OO系统，就是如何对现实世界对象的描述用模型来表述出来，好让模型相关人员对模型理解达到一致性，去除理解偏差！请教，如何抓住业务需求，以及如何从业务需求推倒出概念模型和系统需求，这是一个严格而又合理的推导过程，那如何来(说明或表达)描述需求(业务或系统用例内部到底如何来表达用例的行为)用对象之间的交互来实现(业务)用例的目标呢？不知，以后，可否多多结合实例来描述一些设计问题该如何规范化来形成一种通用设计模式呢？(
毕竟国内的IT人士更加注重设计嘛！)期待您的解答！！！另附：您今年辛苦了，阅读您的blog，那是种享受，却受益非浅，优秀blog就是优秀！喜欢就是喜欢！希望您闲暇之余，能多解答我们这些水平一般的人士一些无知的问题！喜欢之前大家一起在您的blog中一起探讨问题的感觉，您却总是能把大家规范到正确的分析思路来！您的大作马上就面世了，大家会再一次来探讨软件设计的奥妙的，到时，会结合您的大作，来更深入的请教您问题的！发自内心的谢谢您，coffee兄！
re: 与网友关于业务工人(business worker)的讨论 [回复]等待你的书，一定非常精彩，只是不要删除太多细节问题
正是你的深入思考使得很多似是而非的东西娓娓到来，让人醍醐灌顶，使困扰我的问题拨开迷雾。
你的文字条理性，逻辑性强，能引导人走上一个理性的思考路线，并且对概念的讲解也非常细。强烈期待，非常感谢你无私的风险，，敬仰！！
re: 与网友关于业务工人(business worker)的讨论 [回复]另外我想请问一个问题：就是如何划分参与者actor？
我这里有一个管理信息系统，基本就是增删改查，但不同部分有不同的权限，例如部长对每个部门都只有查看权利，而象后勤部门除了对本部门有权利外，还对考勤，系统，文档等有权利。其他部门权利和后勤部门类似。请问如何划分actor呢。
我将actor划分为：部长，后勤科职工，政工科职工，军事科职工。但这样总是觉得别扭。但这两天又思考不出这些actor来，还请赐教。
另外针对你说的，“有一种情况就是只有一个查询是比较特殊的，查询一般不一定只局限于一个actor，也不一定局限这个用例，一般都是所谓的综合查询，是可能跨用例的。所以根据实际情况，查询可以作为一个业务用例出现。”
那如果按照你说的把查询作为一个业务用例，那查询下面的系统用例岂不很多，针对每个部门不都有很多的系统用例吗？望赐教。
re: 与网友关于业务工人(business worker)的讨论 [回复]醍醐灌顶，为什么看你的文字总是有这种感觉，拨云见日！！多谢多谢，
听君一席话，胜读十年书。。
着急盼望你的书，不知道可不可以在郑州买到。
re: 与网友关于业务工人(business worker)的讨论 [回复]等待咖啡大作发表，别拦着我，我一定要买一本。
吾之良师，敢问咖啡兄在北京哪噶瘩上班啊？
我在上地，中关村软件园
实体对象如何进行抽象？ [回复]请教楼主一个问题：当从面向对象的角度来说，领域模型中的实体对象之间是完全隔离的，它们应当是相互之间没有关系的。所以，此时可以根据对象的内在封装性，分别考虑如何对每个实体对象进行抽象，这个抽象应该如何进行呢？一般，可以从哪些角度来考虑呢？请楼主指点一些方法，多谢啊！
re: 与网友关于业务工人(business worker)的讨论 [回复]通篇阅读了一下，这里必须要说的是挺coffeewoo。
首先在谈业务工人这个概念的时候，我们必须要明确，我们在做什么。是业务用例还是系统用例。
业务工人（我习惯叫它业务员工），其只应该存在于业务用例，为什么呢，因为它在表达整个业务是怎么做的同时，需要界定在整个业务环境中什么是处于业务内的，什么是处于业务外的角色，处于业务内的角色可能会对业务的某个内部环节有所了解，处于业务外的角色可能只会对业务的外表有部分了解而涉及不到业务的内部。
业务工人的角色之所以要明确，是为了在系统用例的时候能够界定哪些可以由系统来处理而不用人工或者哪些是可以使用接口与另外一个系统进行通讯。
业务用例没有当前未实现的东西，是对当前业务情况的一个描述。
因此业务用例是人或者不是人，有没有与要实现的系统有个交互，这些统统是无关紧要的。
re: 与网友关于业务工人(business worker)的讨论 [回复]假设一个商品零售企业，需要建设一个网上销售系统。
有二个问题想请教：
1、网上销售是从未有过的业务，那么业务建模应从哪里入手？
2、网上销售本身和计算机关系密切，那么直接进入系统建模是否更方便？