业务建模中怎么找到业务参与者

[happyjun2000]

一般在业务建模中介绍要找到四个东西：
业务参与者、业务用例、业务工作人员、业务实体。

但是觉得首先要先确立业务参与者，才可以入手，就象要想确立系统边界一样，找到actor

对于电子商务的例子：客户（很容易找到）

但是对于一些例子：
一个系统负责采集数据的登记、处理、生成报告等工作。
部门1的a去采集数据，然后登记，然后交给部门2的b去处理，然后b出具报告。
但是这个系统是给所有部门用的，a是在整个工作流程中的，a好象是系统工作人员，但是这里的系统参与者在那里呢？难道要把a拆分吗？

这个怎么处理？

[happyjun2000]

a不是每个部门都有的，只是特定部门，可以理解为采集部门，但是这个部门可能是几个

现在的问题是找不到驱动数据采集分析的业务参与者。

因为a可能只是因为工作的需要去做了采集工作，然后登记。它本身并不象用例:客户——购物那么明显，但是谁要求它去这么做了呢？系统参与人员在那里？或者说没有？那么不能凭空产生一个采集登记分析的用例啊？

主要是考虑到业务建模是把系统看作一个黑盒子，任何系统工作人员都是在这个黑盒子里面的，这个黑盒子看作是业务用例，a作为黑盒子中的东西，不能拿到外面来吧，但是不那到外面好象业务工作的起源是什么就不清楚了，很明显a不是驱动业务用例的对象？谁才是呢？

概念优点混乱了？大哥指点。

感谢qingrun(青润) ( ) 信誉：101 大哥百忙之中来帮助小弟！

[xinbin1122]

我的看法：任何一个用例对应一个逻辑上的参与者，而在系统分析的时候就是在逻辑层次上的分析。这么说，a当然有可能被拆开了。

[happyjun2000]

看来对这个的理解太浅了，回家好好看书去

但是，将系统看作黑盒子，和系统关系的参与者对有的系统来说好象很难找

对一个组织，自己采集并处理数据，然后存放在系统

那么在系统中查看数据的算是系统的外部参与者

但是是什么驱动了系统来做这些用例实现的呢？查看数据的用户算是驱动系统用例的吗？

[happyjun2000]

对系统的边界认识的不够

能举个类似的例子来分析说明一下吗？

查找业务主角和用例

[happyjun2000]

考虑了一下

说：将系统看作黑盒子, 系统的内部实现不用考虑，那么实际上a的行为只是系统内部的实现，也就是说不用考虑，和这个系统交互的实际上只有需要从系统得到数据的那些参与者。

对于这类系统业务（主要是实现数据的保存和查询，业务组织内部怎么操作先屏蔽），因为他的业务流转基本不需要外界的参与，所以，可以说是没有业务参与者的，要是有也只是从系统获得数据信息的人。如果不考虑他们，实际上就没有了参与者，系统也就没有了存在的价值。

结论：
a只是一个业务工作者，具体他怎么用系统实现数据的登记等用例不是在业务建模是考虑的，是在系统建模时才应该考虑的

有时候系统的运行不一定需要业务参与者的数据行为输入，参与者可能只是需要系统的一些输出。所以这类系统是自发运行的。

所以这个系统的业务参与者：
领导、相关人员、企业——系统

业务用例：
领导、相关人员、企业——查看数据

系统对象模型包括：
业务工作人员：部门1的a，部门2的b
业务实体：登记表、数据报告

系统对象模型来实现系统的内部逻辑，然后从系统对象模型等导出部分的系统模型中用例、角色、实体类等进行细化。

不知道理解的是不是对，大哥们指点一下。

[test1980]

ding

[happyjun2000]

能不能这么理解：

系统描述：
主要接受企业提交的样品或者组织内部主动采集样品，进行分析，然后企业和其他人员能获取样品数据结果。

业务参与者：
企业、领导、规定监测数据时间、其他数据获取者

业务工作人员：
部门1的a、部门2的b

业务用例：
1.企业——请求监测（包括：企业提交样品、a接受样品、b分析及记录）
2.领导、规定监测数据时间——命令监测（包括：a采集样品、b分析及记录）
3.企业、领导、其他数据获取者——获取监测结果

对于1、2中 b分析及记录 这个事情是重复的，所以提议提取出一个用例，与1、2用例是一个包含关系
4.b分析及记录

然后在1234的用例中建立业务对象模型图，来描述系统内部业务的执行。

对于一些系统与外部业务发生很少的情况，就可以不必实现业务建模，直接系统建摸，实际上就是系统内部的业务实现。不知道这个是不是就是领域建摸，对领域建摸没有仔细理解，请指点。

好象业务建模的用例一般不用太复杂，主要是弄清系统（内部业务）和外部业务的关系，用例封装了系统内的业务，实现从简单化入手，然后用业务对象模型来对用例进行描述，明白内部业务中的组织结构，对象及相互关系等，为系统建模积累一定的基础。

[青润]

你的意思是说：a这个角色在每个部门都存在，是么？
如果是这样，a应该在业务说明中作出说明，也就是说，可以不作拆分，但是需要注明这个角色是所有部门都有的（其实在实际业务操作过程中也是如此）。
系统的参与者也有很多种，并不仅限于对系统直接进行操作的人，还包括对系统数据进行浏览和查阅的人，这些人不一定进行直接操作。
另外比如报告的审核者，也是参与者，但是，系统中打上审核标记的人并不一定就是这位实际业务的审核者，可能是一个具体操作员在领导的指示下进行的操作而已。
这样说，是否明白？

[happyjun2000]

封装起来主要是找到系统的边界，既然找到了就要严格的执行

如果不封装，那么就不是研究业务了，那和一般的系统建模就没有区别了，并没有在更高层次上考虑问题

因为是刚学习，所以不敢变通，因为变通也许就走错了:>

[happyjun2000]

实事求是的确很重要，够用就好，呵呵，感谢 qingrun(青润) 大哥！

[amonlans]

业务参与者的查找过程，也就是划分业务系统边界的过程；只要能搞清哪些业务需要研究，那些业务不需要研究，基本上就找到了业务参与者；实际操作时，由于没有很好的确定业务的边界，或者没有理清，往往很迷惑；同意 happyjun2000(蓝色游侠∮是非成败转头空) 2005-04-26 23:05:00 帖子上的分析

[青润]

这个角色既然不是所有部门都有的，那也很正常，就按照实际情况进行设计也就是了。
如果每个部门都有，那就是每个部门都有数据采集功能，如果不是都有，那就考虑有这个业务的部门也就可以了，不要固执得认为，有与没有就是矛盾。
另外，为什么非要把数据采集都封装到黑盒中呢？这很奇怪呀。
我的书中写过一句话：任何事物的行为都必须有驱动力。驱动必须是一个可以主动发出行为的对象，这个对象，可以是人，也可以是时间或者其他具有满足一定条件就发生触发性行为的对象。
关于这个问题在这里也是一样的。
存在的，就是存在的，有些可以合并，有些不能合并，有些可以忽略，有些不能忽略。这都应该根据具体情况进行判断，看看哪种方式更适合解决问题，而不是非要把什么封装起来。
非要把什么封装起来的做法就是为了技术而技术的做法，也就是一种本本主义的表现，而不是解决问题所需要的实事求是的做法——有点大了，但是，事实就是如此。

[青润]

除了上面的问题外,我发现你在思考系统边界上有一些问题.
确定系统边界有很多种方式,不见得非要做封装才能找到系统边界.
在我的书上给出了我建议的一种操作方式.
另外,我最近在研究业务用例的过程中又提出了一种可能更好用的操作方式,等我总结得差不多了,再贴出来.

另外,封装与否与是否研究业务没有关系.
一项具体的业务内部就需要分清楚哪些是需要实现的,哪些是不需要实现的,哪些是用户人工操作的,等等.这就是在划分系统边界.更详细的可以去看看我那本书上介绍的对应内容.

[happyjun2000]

确实理解上是有问题，我再仔细理解一下。

期待大哥的总结。