与网友关于业务工人(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的意义所在

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

最近才看到你的文章，虽然只看了其中一部分，但很有收获，在此表示感谢。
“人工座席”能被当作机票预定系统的内部一员吗？你的回答是，如果该系统是业务系统，则能；如果该系统是“要对之进行系统建模”的那个系统，则不能。你又说，你图中的系统并未明确是业务系统与计算机系统，是因为actor对这两种系统通用。可是，通用吗？如果是第二种系统（计算机系统），那么那张把“人”放入计算机系统这个黑盒子内部的图显然是不对的。一张通用的图怎么能不适合它所涵盖的其中一种情况呢？
如果是业务系统，那么你怎么界定该业务系统的边界？还是无所谓边界？因为你可以轻易的以“如果把呼叫中心看作订票系统的子系统”来扩大业务系统的边界；那么该边界是以人的主观的不同“看作”而有不同边界吗？假如张三每次派李四去为他订票，那么是否李四也应该被划为业务系统的一部分呢？又假如张三总是让旅行社为他订票，旅行社是否也被划为业务系统的一部分呢？
在病人挂号时，流程是这样两步，病人告诉医生挂内科，医生在计算机上进行挂号操作。这里，发起者是病人，那么医生就成了业务工人吗？又比如一个人看到电视里的天气预报明天有雨，她就把自家的衣服收起来了，那么她就是天气预报系统的业务工人吗？如果这个例子显得不够深刻，那么又比如一个工厂的生产非常依赖于天气，所以专门派人每天看天气预报，以合理生产，那么这个人就成为天气预报的业务工人了吗？
在那个呼叫中心的例子中，如果不把呼叫中心看作订票系统的子系统，接线员还被称为业务工人吗？如果答案是否定的，那么业务工人的是否成立是建立在人们的主观的“怎么看”上吗？
是的，现实中的业务有人对机器的任务，有机器对人的任务，也有人对人的任务。而我们的重点应该是在哪里呢？你我应该都同意软件工程比UML更基本，从工程的角度看，需求是设计的依据，设计要瞄准需求，如果需求中充斥着人对人的业务，设计人员又该如何下手去设计系统呢？想必你要把此业务系统再重画一次，才交给设计人员吧，前后两次的不同就是你分化出的业务建模和系统建模吧？那我非常想看一下这两者的转换过程。
而我认为，与系统无关的业务描述，应该放进用例的前置说明或用例的补充说明内。
我还认为，描述业务模型就同于写说明文章，虽然有些大致上的原则，但并无硬性规定，不需要拘泥什么，讲的清楚的就是好的说明文。对于软件工程的需求阶段来说，最终并且最重要的是得到人与机器的交互说明，就是你说的系统建模吧。
我还觉得，软件中的业务建模只是帮助我们更好的理解业务，而如果把流程优化与流程再造也赋予软件业务建模的责任，则它承担不起。
你的文章我只看到一部分，却已经有很多收获，只恨现在才刚看到。虽有不同看法（比如业务工人和你说的分析模型和设计模型的区别）但仍佩服你思考的细致（把概念拆分的很细）与全面。本想周六就回复，但周末事多，昨天睡前想了很久，今早就赶紧回复了。

非常感谢你的回复。我想，你关心的问题有两个，第一个是边界划定的问题，它直接导致业务工人是否成立，在这里边界是否是人的主观决定？第二个是业务建模的意义，以及业务建模到系统建模的转换，它导致业务工人在系统建模中“转移”到计算机系统外。下面就这两个问题谈谈我的看法，以供参考。
关于这两个问题，我想先谈谈我对面向对象分析的理解，对边界问题和业务建模问题的理解都基于我对面向对象分析方法的理解，内容有点多，我尽量言简意赅。面向对象的首要课题是如何将现实世界映射到对象世界。尽管有多种多样的方法，但我认为，最基本的是两个概念：抽象角度和抽象层次。其中，抽象角度决定了建模方向和业务边界，抽象层次则决定边界粒度。一个业务系统（未最终定义之前）可以有许多种可能的抽象角度，我们可以假想为城市中的监控摄像头，尽管拍摄的都是同一个城市，在不同的机位我们会得到不同的展现和描述。因此，对业务系统建模的首先一步是选取适合的机位，这也就是为什么rup里强调涉众(stakeholder)分析的原因，stakeholder就象是城市里遍布的摄像头，而从stakeholder中选择业务主角(business actor)的过程，实际上就是选择适合机位的过程。决定了适合的机位就决定了抽象角度，而所有机位的视界之和构成了业务边界，每个机位所关心的目标则构成了业务边界内的业务范围（business use case）。其次，抽象层次的选择决定我们将从什么粒度来分析业务范围，例如，在较高的抽象层次，我们也许仅描述部门和部门之间的业务关系，在低一些的抽象层次，我们也许描述业务对象在业务过程中的关系，而如果直接将抽象层次定位到了IT级别，那么就是大家通常意义上理解的系统建模。选择什么样和多少个抽象层次依据业务问题领域的规模、复杂程度、分析员的经验、产品策略等而定，没有标准答案。

回到问题上来。边界是否是的主观决定？我的回答是一半一半。为什么这么说？确定业务边界，即确定机位的过程并非是随心所欲的，它来源于涉众分析，可以说是一种算上非常严密的推导过程(毕竟不是解方程)。但是在确定了业务边界后，分析员的确可以根据抽象层次的选择，来产生不同的边界以利于分析，这些小边界是原来的业务边界的子集。用例方法的本质就是分析边界外的事物与边界内的交互，一旦划定边界就内外有别了。换句话说，是边界决定了谁是业务工人谁不是(边界内外)，而不是从“actor”的角度来看谁是业务工人。再准确一点说，抽象角度决定视界，视界构成边界。所谓的业务工人，是指在特定的抽象角度下，位于边界以里，并且贡献于抽象角度关心的业务目标的人。最后，视界的集合构成整个系统边界。

分析一下你所举的几个例子，病人和医生。如果我们选择的抽象角度是病人，那么医院的业务系统就是病人的视界,也就是业务边界，同时决定了边界外是病人，他是主动使用和受益于这个系统的，边界内则是医院的员工、资源、流程等等，而医生是在边界内的，因此他的确是业务工人。从病人看来，他的业务目标是挂号、交费等。如果我们选择的抽象层次是业务层次，那么很自然的，我们会描述病人挂号需要办理的一系列手续，这些手续是不是用计算机，哪些用计算机来实现，怎么实现在这时都不用关心，我们关心的是病人挂号的一切需求是否清楚。

如果选择的抽象角度是医生又如何呢？在医生看来，医院的业务系统就不再是视界，作为挂号处的医生，他除了看到与病人一样的挂号过程外，他还能看到病人所看不到的一些东西，例如挂号单以后的存根处理规定等。换句话说，病人只看到怎样挂号，医生看到的是整个挂号业务操作规程，这也就形成了医生的业务边界。这个业务边界决定了医生在边界外，而将来实现挂号业务的计算机则在边界以内。

看来，不同的抽象角度有不同的业务边界，抽象角度的集合才决定了整个系统的业务边界。因此，在分析过程中，边界是一个相对的概念。由于边界因抽象角度而变，也很有可能，某个人有时在边界外，有时在边界内。这并不矛盾，在现实世界中，某件事我为你服务，另一件事你为我服务，很正常。如果抽象角度很多，那么业务边界也就有很多，边界就很可能交叉、重合、矛盾；而这些信息却正是业务建模除了了解需求之外的另一个主要目标之一：抽象业务架构（虽然国内企业几乎没有做业务架构的习惯）。试想，某A在以某B为主角的任务M中充当了业务工人，而某A作为主角自己也有自己的业务描述N，A在充当业务工人时的行为就成为从M和N中抽象业务架构的关键因素。

[在那个呼叫中心的例子中，如果不把呼叫中心看作订票系统的子系统，接线员还被称为业务工人吗？如果答案是否定的，那么业务工人的是否成立是建立在人们的主观的“怎么看”上吗？]

的确，如果不把呼叫中心看作订票系统的子系统，接线员不能被称为业务工人。但原因并不是人们主观怎么看，而是由定票者的视界来决定的，定票者的视界则由涉众请求决定，关键就在我的那句话：假设定票者可以自主决定是上网还是打电话来定票。就拿携程，E龙来说吧，不管你是打电话还是上网定票，对你来说你都认为你在和携程打交道，你的视界是整个携程。另一方面，打电话时，假设某天AI达到一定程度，可以实现人机语音对话，那么老实说电话另一端的你分不清楚人工座席是人还是机器，但这又有什么关系呢？不管是人还是机器，他们都在你定票的这一业务过程中充当了同样的角色！

假如张三每次派李四去为他订票，那么是否李四也应该被划为业务系统的一部分呢？不能，因为涉众请求里不包含谁派谁这样的请求；合理的涉众请求是通过网站和电话定票。如果张三亲自打电话，张三是业务主角，如果张三派李四去，打电话的人是李四，李四是业务主角，张三的角色完全被李四代替；假如张三总是让旅行社为他订票，旅行社是否也被划为业务系统的一部分呢？这要看涉众请求。如果涉众请求中有将旅行社定位为分销机构，如同火车票的代售网点，彩票销售网点，银行ATM一样，那么旅行社就应该是业务系统的一部分；反之，没有这样的请求，只有电话和网站，那么旅行社的作用等同于李四。我文章里的第三种和第四种情况就是这样区分出来的，第三种情况适用于票务网一类通用服务机构的call center, 而第四种情况适用于携程和E龙自己的专用call center。

至于为什么到了系统建模时就不再有business worker的定义了呢，原因也很简单。因为这时的抽象层次已经细化到了IT级别，就拿挂号的例子来说，到了IT级别，抽象角度是医生而不是病人，边界也变成了隔离计算机与操作者，当然就不再有business worker了。

在国内，业务建模是历来被忽略的，从需求直接到系统建模。今天不讨论业务建模的可实施性、成本、必要性之类的问题，仅从方法上来说，从需求直接到系统模型是一种经验做法，毕竟，现实世界和计算机世界是有gap的，需要靠经验来跨越。业务模型则不同，业务模型是现实世界的直接转化，不存在gap问题，而系统模型可以从业务模型中推导出来。这个话题一说就大了，在未出版的拙著里，有非常多的内容在讨论这个问题。

在我所做的项目中，需求规格说明书有两部分组成，一部分是业务需求说明，主要由业务模型构成，它形成项目的业务范围和开发方与业主就业务领域达成的契约；另一部分是系统需求说明，主要由系统模型构成，它形成项目的系统开发范围和开发方和业务就IT建设达成的契约。当然，系统模型是从业务模型推导而得来的，在需求规格说明书中会指出这一追溯关系。

不同系分员对同一业务有可能会建立不同的业务模型吗？

非常之可能！尤其是面对复杂业务的时候。抽象角度和抽象层次的选择是很考功力的。角度不全需求就不足，角度不对需求就可能错，抽象层次不够主，则可能失之全局，抽象层次不够细，则可能败于细节。
同时，系分员还承担着从需求到设计中间的桥梁，即他还要考虑技术、成本、项目情况等许多因素，甚至需要去影响客户调整原始需求。
这样一来，同样的业务出现很多不同业务模型就是自然而然的了。

不同系分员对同一业务有可能会建立不同的但都正确的业务模型吗？

无从评判何为“正确”。如你所言，描述需求就象是写文章，各有各的精彩。只要没有遗漏需求，各种表述方式都是可接受的，没有对错，只有好坏。如果考虑到项目成本、项目背景和开发策略，简陋的模型有时候都可以说是最好的。

没有遗漏需求但表述方式不同的业务模型，会得到同一系统模型吗？

当然不会。即使没有业务模型，系统设计也是各不相同的。脑力劳动不是机械化生产。

系统模型的不同，是可以看作需求的不同吗？

不能，如同接口相同，实现不同一样的道理。比如同一个需求，系统模型需要考虑技术因素，技术因素不同，得到的模型也就不同。并且系统模型不仅仅要考虑技术因素。

不，不，我们先不要涉及其它因素，分析模型和系统模型都是在需求阶段内（你前面的文章中是这么说的），我们只谈需求，不谈设计。这种情况下，系统模型的不同，可以看作需求的不同吗？

呵呵，还是不能。虽然我说系统模型可以从业务模型中推导出来，但这个推导只是基于需求信息不丢失为条件的，或说系统模型可还原业务模型为判定条件的。而不是数学中的严密解的概念。
例如说一个业务模型表明，填写某申请单需要填写个人信息、职位信息和保证人信息等。在不丢失业务模型信息的情况下，系统模型可以将上述的三个业务对象看作一个申请单系统对象，也可以看作三个系统对象。业务模型表明上填写上述三个业务对象时需要进行数据校验，在不丢失这个信息的情况下，系统模型建模为分步骤，第一步填写并校验个人信息，第二步填写并校验职位信息...也可以建模为一次性填写全部信息，然后一并校验...还可以建模为一次填写，分步校验。虽然建模结果不同，但这些建模方式都可还原业务模型。
评判系统建模好坏如果不考虑技术因素（例如扩展性，可维护性和适用的软件架构），纯从业务角度说，符合客户业务习惯的系统模型是好模型。
上面的例子通俗的理解是，要填写一个单子，在将来的系统中，客户是喜欢分步填写呢，还是一次性填写？
在系统建模过程中，系分员还可以加入一些因素来使系统模型更健康，比如，为了保证当session失效时客户数据不丢失，在系统模型中加入缓存机制。但无论如何，业务模型的信息没有丢失。

第一，我认为你把设计阶段做的事，放进了需求阶段去做了。
第二，为将来的客户可能喜欢如何填写单字而设计，是一种莫须有的臆测。我一向认为它会导致过度设计。
第三，我认为你把可维护性放进需求阶段考虑也是不合适的。

业务是具体的，需求也应该是明确的，如果系统模型属于需求阶段却可以有不同的展示，那么这样的需求一定是不明确的。如果系统模型属于设计阶段，那么你把系统模型放进需求阶段也是不对的。

关于可扩展性，你认为设计的可扩展性来自于哪里？

你这个网站慢，有时还出错，去我那里讨论怎么样？虽然有500字的限制，但既然是讨论，每次不会说太长，应该够了。
http://hi.baidu.com/dapplehou/blog/item/cf7f0f24b710e437c99559ec.html

第一，在rup中，软件过程是迭代的，第一版可运行原型出来的时候，需求甚至还没结束。系统建模细致到人机交互级别没意见吧？人机交互过程是需求的一部分没意见吧？现在做需求时，除了给用户展现界面原型，甚至采用可运行的原型。如何断然区分需求阶段和设计阶段？从rup九个核心工作流就可以看出来，需求过程一直延续到产品化阶段，而分析设计在先启阶段就已经开始。即使采用严格的瀑布过程，在编码甚至试运行时还在调整需求的例子比比皆是。因此我认为，软件过程的各阶段只能强调以什么为主，而不可能截然分开。
第二，既然要用use case，用户的感受就是第一位的，必须清楚。我个人的意见是，与客户打交道的东西马虎不得，至于客户看不到的，可以采用多种策略来避免过度设计。关于这一点，我认为不能一概而论，需要case by case的来看
第三，系统分析员的职责就是把业务需求良好的转换成系统需求，可维护性当然是考虑的一部分。请参看补充用例规约模板,可用性，可靠性，性能，扩展性等标题赫然在目。需求阶段不考虑系统死活，把许多用户不合理的需求带入到设计阶段造成大麻烦的事例不少见！这是系分员的失职行为，如果只考虑需求不考虑系统，系分这个角色就没必要。

呵呵，根据我们前面的讨论，同样的业务模型可以有多个不同的系统模型表述，这是因为不同的系分的经验和观点不同，项目背景不同，因为其他种种原因的综合考虑，而最终决定了最适合的那个模型。何以见得多个系统模型能推论出需求不明确呢？相反，我倒认为一个需求只能推出一个系统模型才奇怪了，建模过程就象是命题作文，天下文章都一样那才糟糕。

系统模型是一项工作，它不属于哪个特定阶段，只能说在某个阶段是主要工作。
关于设计的扩展性，我们暂时不说吧，还是回到需求工程上来，别把话题引得太远了。

ok, 移步...

coffee兄逻辑推理思维了得，把OO分析与设计过程用逻辑推理的方式说明了如何从业务过程过渡到系统模型，进行了总结，经典！同时也把自己思考和总结出的抽象角度和抽象层次的说明通过实例的细致描述，其描述语言更加言简意赅，易懂(敬佩)！抽象角度的描述更加证明了，OO系统商业建模，一切以人为中心的思想，从涉众中找出业务主角，业务主角的视角不同程度的表达了业务领域的问题域，每个业务主角对问题域的视角，体现出问题域的抽象层次！这里想请教一个问题，在业务建模过程中通过业务场景中找到的业务实体对象，是否是与现实世界的对象需要完全对应呢？我在读其它的书中，一些动词也可以作为领域模型中的业务实体，甚至是一些抽象名词业务也可以作为业务实体对象，但个人感觉在业务建模阶段，一切都应该是业务术语，应该用现实世界的实物进行映射，来说明业务实体对象，至于抽象名词或者过渡到系统建模之后的实体对象，是通过不同阶段，分析之后的结果！业务实体类图中可以出现动词，但这些动词应该是类图之间连线说明类图的用意描述，便于让阅读者理解模型表达的意图！coffee兄，不知，我的理解是否正确，给些指点，好吗？其次，还有个问题想请教，业务领域模型是概念模型的一种，可知业务领域模型是概念模型的一个子集，那其具体区别在哪里呢？其职责具体体现是什么呢？望其执教，在此多谢了！最后一个问题，分析模型是为了追溯需求，验证需求，设计模型抽象层次更低，都说分析模型和设计模型用相同的方式进行分析和描述，但由于设计模型抽象层次更低，此时，系统边界已经缩小到真正的参与者与系统的交互，用例描述也完全是用户的请求和决策加入到IT系统，IT的系统的直接回应，此时，是否可以依旧应该考虑设计模式的应用，结合具体设计场景，加以符合场景的设计模式，来保持系统结构的扩展性和可维护性，此时，想请教一个问题，您的分析模型的设计，就用到了设计模式来调整分析模型，那是否说明了，设计模型更贴近了实现，在分析模型考虑设计模式的应用，是站在更高的层次，而在设计模型的描述过程中，需要结合系统成本的需求，周期性，和技术条件等等，同时考虑现有市场已有或成熟并可采用的FrameWork，在更低的层次来考虑如何加以设计模式，是这样的吗？期待您的回复和解答！另附：期待您的大作书籍已经很久了，能告知哪个出版社的，书具体的名称和具体出版时间吗？到时，一定第一时间购买，好期待哦！！！

coffee兄，能否结合你日常的工作和思考问题的方式，给大家一个通用思考问题的抽象角度的描述呢？结合您的这么多文章大作，总有一种感觉，您一直立足于(业务)需求的获取和描述，并且从业务问题域的目标组织的业务需求，来说明业务架构的重要性！想请教一下，何时能多多描述各种建模过程是如何把物的概念鼓起(说明物的重要性)来呢？毕竟我们做的是OO系统，就是如何对现实世界对象的描述用模型来表述出来，好让模型相关人员对模型理解达到一致性，去除理解偏差！请教，如何抓住业务需求，以及如何从业务需求推倒出概念模型和系统需求，这是一个严格而又合理的推导过程，那如何来(说明或表达)描述需求(业务或系统用例内部到底如何来表达用例的行为)用对象之间的交互来实现(业务)用例的目标呢？不知，以后，可否多多结合实例来描述一些设计问题该如何规范化来形成一种通用设计模式呢？(毕竟国内的IT人士更加注重设计嘛！)期待您的解答！！！另附：您今年辛苦了，阅读您的blog，那是种享受，却受益非浅，优秀blog就是优秀！喜欢就是喜欢！希望您闲暇之余，能多解答我们这些水平一般的人士一些无知的问题！喜欢之前大家一起在您的blog中一起探讨问题的感觉，您却总是能把大家规范到正确的分析思路来！您的大作马上就面世了，大家会再一次来探讨软件设计的奥妙的，到时，会结合您的大作，来更深入的请教您问题的！发自内心的谢谢您，coffee兄！

你什么时候出书，我现在想买一本！！！

这两天比较忙，没时间上来了。
第一个问题，我的建议是，在业务建模阶段，还是符合现实世界为好，不要加入过多的“抽象”在里面。业务建模的目的是与用户就业务模式达成理解上的一致，然后来推导需求。因此，最好使用业务术语，你的理解是正确的。至于动词作为实体对象存在我有些疑问，你在哪里看的文章？可以让我看一看吗？我想知道是如何描述的。就我的理解，在业务模型中，动词是不能单独存在的，必须有动作和动作的受体才能描述。或者这里说动词作为实体的意思是这个动作有隐性的受体。具体我看了原文再作回答吧。
第二个问题,业务领域模型是就业务提出一些问题，然后就这一问题建立解决方案模型的建模过程。而概念模型是从原始的业务模型中抽象，整合，提取业务架构的过程。比方说，用户提出分级授权的问题，就这一个问题我们可以建立领域模型，找出解决这个问题的方案。而概念模型则是针对客户的业务模型，提取出一些有效的概念化的东西。比如一项业务流程描述中提取出组织结构定义、操作规程、人员职责、授权模型等概念，再分别建模之。概念模型是产生业务架构的重要输入。它们之间的区别是领域模型针对的是问题，它不一定是具体的业务过程。这些问题通常导致将来分析设计时专门的解决框架。概念模型是抽象业务过程的，它的结果是导致业务架构。
第三个问题，分析模型是不考虑具体实现的，而设计模型则需要。具体实现包括所使用的语言，框架，编程规范等等。其实分析模型也要考虑参与者与系统的交互，但是仅以“概念”表示。例如“登录”。而这个概念到了设计模型，则需要根据具体的实现选择，例如SSL，CA，Single sign on等等来设计，设计模型是伪代码级别的。
第四个问题， 在即将出版的书里，有很多内容是针对如何抓住业务需求，以及如何从业务需求推倒出概念模型和系统需求来讲的。应该能回答你的问题。

书面世的时间不会太长了。稿已经交到出版社了。清华大学出版社。中文名是《你在面向对象吗--UML的思考与实践》

等待你的书，一定非常精彩，只是不要删除太多细节问题
正是你的深入思考使得很多似是而非的东西娓娓到来，让人醍醐灌顶，使困扰我的问题拨开迷雾。
你的文字条理性，逻辑性强，能引导人走上一个理性的思考路线，并且对概念的讲解也非常细。强烈期待，非常感谢你无私的风险，，敬仰！！

另外我想请问一个问题：就是如何划分参与者actor？
我这里有一个管理信息系统，基本就是增删改查，但不同部分有不同的权限，例如部长对每个部门都只有查看权利，而象后勤部门除了对本部门有权利外，还对考勤，系统，文档等有权利。其他部门权利和后勤部门类似。请问如何划分actor呢。
我将actor划分为：部长，后勤科职工，政工科职工，军事科职工。但这样总是觉得别扭。但这两天又思考不出这些actor来，还请赐教。
另外针对你说的，“有一种情况就是只有一个查询是比较特殊的，查询一般不一定只局限于一个actor，也不一定局限这个用例，一般都是所谓的综合查询，是可能跨用例的。所以根据实际情况，查询可以作为一个业务用例出现。”
那如果按照你说的把查询作为一个业务用例，那查询下面的系统用例岂不很多，针对每个部门不都有很多的系统用例吗？望赐教。

书的内容应当是很详细的，呵呵
关于查询用例已经在你的另一个问题中回复了。
你所说的权限问题是业务规则，对用例来说，可以算是一个前置条件。在寻找actor和用例时不需要考虑业务规则，只考虑谁对什么有要求？谁在系统里做什么？
至于业务规则，它是对上述的限制，或者说用例的前置条件，变成谁在什么条件下可以做什么。
通过你的回复，我知道你阅读过关于分析模型的那一篇文章了。那么你应当记得在那一章中我提到过业务规则是控制类的来源之一。在业务模型中，你描述的是actor使用用例，用例拥有某些前置条件（业务规则），在分析模型中，变成actor先访问控制类，由控制类来实现业务规则（只读，可改，可增，可删）等，然后才能真正到达实体类。

对你上面的问题，我的建议是忠实于客户岗位划分（有利于客户理解），然后就权限问题专门建立领域模型来解决。
业务模型+领域模型 在分析模型阶段就结合在一起形成系统分析了。

醍醐灌顶，为什么看你的文字总是有这种感觉，拨云见日！！多谢多谢，
听君一席话，胜读十年书。。
着急盼望你的书，不知道可不可以在郑州买到。

等待咖啡大作发表，别拦着我，我一定要买一本。
吾之良师，敢问咖啡兄在北京哪噶瘩上班啊？
我在上地，中关村软件园

呵呵，远在天边，近在眼前

coffee兄，手下还招人吗？呵呵

我也是一打工的，没权利招人，

请教楼主一个问题：当从面向对象的角度来说，领域模型中的实体对象之间是完全隔离的，它们应当是相互之间没有关系的。所以，此时可以根据对象的内在封装性，分别考虑如何对每个实体对象进行抽象，这个抽象应该如何进行呢？一般，可以从哪些角度来考虑呢？请楼主指点一些方法，多谢啊！

近两日我会在博客里贴一篇书里的内容，讲解业务实体的。应该能解决你的问题。请关注

太好了，多谢楼主！

新年快乐,coffee!

好热闹啊，先留名，再表达

通篇阅读了一下，这里必须要说的是挺coffeewoo。
首先在谈业务工人这个概念的时候，我们必须要明确，我们在做什么。是业务用例还是系统用例。
业务工人（我习惯叫它业务员工），其只应该存在于业务用例，为什么呢，因为它在表达整个业务是怎么做的同时，需要界定在整个业务环境中什么是处于业务内的，什么是处于业务外的角色，处于业务内的角色可能会对业务的某个内部环节有所了解，处于业务外的角色可能只会对业务的外表有部分了解而涉及不到业务的内部。
业务工人的角色之所以要明确，是为了在系统用例的时候能够界定哪些可以由系统来处理而不用人工或者哪些是可以使用接口与另外一个系统进行通讯。
业务用例没有当前未实现的东西，是对当前业务情况的一个描述。
因此业务用例是人或者不是人，有没有与要实现的系统有个交互，这些统统是无关紧要的。

假设一个商品零售企业，需要建设一个网上销售系统。
有二个问题想请教：
1、网上销售是从未有过的业务，那么业务建模应从哪里入手？
2、网上销售本身和计算机关系密切，那么直接进入系统建模是否更方便？