商务随需应变与用例分析方法网友关于工作流类型应用的建模方法问题的回复

网友 oneway_01 问了我一个问题，对于工作流形业务建模提出了一些疑问。这是好问题，值得讨论，特意将它发表出来。另一方面，能够做出这样的思考，说明oneway_01同学对用例方法的认知已经很深入了。恭喜一下！

***************************网友oneway_01的问题*******************

系统建模时经常遇到的工作流类型应用的建模方法

在企业应用建模中，我们经常遇到的一种情况：某种业务，它由一系列顺序相关的业务活动组成，这些业务活动一般由不同的人甚至不同的部门负责，也就是说为了实现一个业务目标需要不同的职责的人或部门协作。

我们考虑一个315服务系统处理顾客投诉的应用，在业务模型中，它只是一个业务用例，我们就把它叫“顾客投诉”。

“顾客投诉”可以这样一种场景来描述：张大头最近买了一部手机，刚用了没多久发觉是一部水货，张大头很是气愤，找到商家要求退货，不料售货员态度蛮横，不理睬他，张大头没办法，只得向315热线投诉。

315的受理人员接受了他的投诉，并记录了投诉人的信息以及投诉案件的一般情况，如手机型号、商家、购买时间等，然后要求张大头在家等消息。315协会的管理人员很快接到了新的投诉案件信息，并将它分配给处理人员李曲去处理。然后，李曲开始处理这件事情，李曲找到李大头，把它的手机首先拿去鉴定，仅确认确实是水货，然后李曲和张大头拿着检验报告到商家，要求他们退货，几番交涉，商家退货了事。然后李曲将这个的处理结果写了报告交给管理人员。管理人员向张大头进行了回访，确认了此事，并签署了审批意见，然后结束了这件案子。

好了，现在要求开发这个应用，需求人员认为有以下几个业务活动：

（前台）电话受理
（主管）分派任务
（调查人员）处理案件并编写案件处理报告
（主管）电话回访用户，签署审批意见，结束案件

需求人员同样认为采用用例来描述需求既能够比较清晰又符合项目开发的要求，按照以前的习惯，我们获得了以下用例模型：

按照用例的定义，它应该是合理的，但用例之间没有关系，总让人觉得没有更好地反映出业务之间的密切的关系，实际上我们不难发现，这些业务都是围绕着一个投诉案件来进行的，如果能够很好的描述它们的关系对于业务的理解和用户的最后价值是有帮助的，毕竟谁会使用一个只有电话受理，却不处理的业务应用呢。当然这种关系在业务模型是中可以看出来的，因为都包括在“顾客投诉”业务用例中，但问题是并不是所有系统都建立业务模型，而且怎样在系统用例中反映它们的关系呢，同时用例的事件流描述也会出现像“受理后将案件传给主管”等“将...传递给...”的描述，因为它们确实关系密切。

当然有人提出这种方式：将用例之间加上带箭头的连接线来表示：

但遗憾的是这并不是一种正确语义的表示方法，有些UML的CASE工具（像TogetherJ）甚至根本不让绘制这样的图形。更为重要的是如果主管需要根据“填写处理报告”用例的结果来决定是“结案”，还是需要“案件转移”到其它部门，又应该在什么地方描述呢。

当然也可以考虑单独绘制一张活动图来描述。但是这些仅仅都是关注在表示方法上的改进，更为重要的是如何从功能（业务）的关系上如何更好地反映它本来具有的自然依赖关系。

请问coffewoo兄这种情况下如何进行用例建模。

另外，该系统实现时（姑且不考虑数据与逻辑分离原则），可否实现为一个《顾客投诉类》，其中该类中有四个方法：

（前台）电话受理；

（主管）分派任务；

（调查人员处理案件）编写案件处理报告；

（主管电话回访用户）签署审批意见，结束案件。

这里姑且将《案件处理报告》实现为《顾客投诉类》的多个属性。

***************************网友oneway_01的问题*******************

好问题！！这些思考是你自己的吗？真的非常棒！能够思考这些问题，可以说你对用例方法的理解已经非深刻了！

在回答你的问题之前我先扯点别的东西，与这个问题的答案相关。昨天晚上我跟一个同事闲聊SOA，天马行空的扯了很多将来可能的商务模式和应用模型。尽管聊天的内容玩笑和吹牛皮的成份居多，不过观点总结起来就是一个：on demand business，也就是所谓的商务随需应变。在我们的牛皮里，将来的应用系统处于一种“不确定”状态，例如，假设你想交手机费，你会请求一个交费服务，但是你不知道这个交费服务最后将你的费用交到了哪家银行，还是哪家运营商，还是某个中介机构，你只知道你的交费成功了。甚至，交费服务的开发者自己也不知道会交到哪里，它按照一定的规则（例如目速度最快的、最稳定的、手续费最低的...等等）搜索可以接受交费请求的其他服务提供商提供的服务，并调用它们。这个过程是动态而不是事先定义的。社会上的各个服务机构都提供了各式各样的服务，而个人或中服务中介则可以自己定义自己的综合服务以获得赢利。例如，你可以定义一个集交手机费、交水电费、交有线电视费、纳税....等等服务于一身的一榄子交费服务。换句话说，业务流程由使用者决定而不是服务提供商！于是，应用系统模型变为服务机构提供服务，而使用者在使用时自行定制业务流程。

之所以扯上面的故事是因为在你的思考中，你的疑虑在于你认为如果功能之间的业务关系不能够清晰的表示出来，那么业务模型不能成立，随之编写程序也变为不可能。正如你所说：但是这些仅仅都是关注在表示方法上的改进，更为重要的是如何从功能（业务）的关系上如何更好地反映它本来具有的自然依赖关系。

不过我并不这样看。功能（业务）之间的关系真的是“自然依赖关系”么？不，功能（业务）之间的关系是因需而存的。用你所举的例子来说，如“主管需要根据“填写处理报告”用例的结果来决定是“结案”，还是需要“案件转移”到其它部门”之类的业务关系并不是自然依赖的，而是由315案件处理条例之类的规则来决定的，更本质的说，这样的规则也是因为处理顾客投诉的需求而产生的。回到我之前的故事，商务随需应变，怎么理解？需是本质，商务是形式，商务随需而变。一旦顾客投诉需求有变，你所说的“关系密切的、自然依赖的”业务就完全有可能不再关系密切，不再相互依赖。如果这样，你还认为必须要把用例之间因为当前业务而产生的关系当做“天然、本质”的内容来定义吗？

将用例定义为“独立”的，不定义它们之间的关系的道理就在这里。用例之间本来没有所谓的自然形成的客观关系，它们之所以发生关系，是因为业务场景的需要，换言之，是因为需求的需要。需求变了，业务场景就变了，但业务场景变了却不意味着用例会变。举个最简单的例子，现在很多大中城市已经合并了110，119，112等应急电话，原来打110只能报匪警，打119只能报火警。但现在打110既可以报匪警也可以报火警。我们发现，需求变了，业务场景变了，但是用例却没变，我们不会看到民警挥舞着警棍冲入火场，也不会看到消防警拖着消防栓狂追小偷。由是得出结论：110不等于匪警，它只是匪警出警用例的一个业务场景而已，因为这个业务场景，110应急程序和匪警产生了关系，但这个关系不是天然的。或许有一天我们每个人手机上都有一个紧急事件按钮，一按就可以与所谓城市应急处理中心联系，而110，119，112等等服务程序则可能光荣下岗，而民警、消防警、急救中心还是一个都不能少。

不知你得到答案了吗？这种情况下进行用例建模跟你现在习惯的做法一般无二，用例仍然是独立的；它们之间的“关系”仍然体现在各种场景中；不要试图在用例之间用什么线来表示用例之间有业务关系；不要将现在的业务关系认为是用例之间的天然关系。

大胆展望一下，如果真的实现了我与同事海吹的那个将来，你所能做的是提供适合的用例，将其实现为服务；而业务场景，则是由顾客自己来决定，通过服务搜索引擎从海量用例（服务）中挑出自己中意的，拖拖拽拽，定义出一些个性化的诸如“购房一条龙服务”、“生活费用一条龙服务”、“挑选女朋友一条龙服务”之类的业务流程供自己使用，那才是真正的商务随需应变，on demand business! 呵呵，无限憧憬ing...每个网虫都是CEO...

对于最后一个问题，我认为不妥。面向对象一个非常重要的考量是职责单一。如果《顾客投诉类》做了那么多事，显然它的职责是混乱的。如果非要这样做，我建议按职责单一的原则分为四个类，然后构造一《顾客投诉服务接口》来代理。

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