畅享博客 > Smarthings事脉顺-业务建模的目标 > 业务建模和流程改进 > [原创]基础知识第三讲:怎样对服务体系进行UML业务建模
2006-8-26 14:39:42

[原创]基础知识第三讲:怎样对服务体系进行UML业务建模

 

我们知道,客户是从业务系统的外部启动并享用服务项目的人或机构,在现代供应链管理模式下,服务过程是客户驱动的,即,如果没有客户出现,服务项目的实例服务过程就不会被启动和执行,否则,我们就找不到"谁让你做这事的?"的答案,自然没有人愿意来为你的劳动买单。此外,客户可以分为很多类型,不同类型的客户,需要的服务项目可能有相同的部分,也可能有不同的部分。

从业务系统外部看来,一个业务系统对外提供的服务项目一般不是单一的,而是多项的,并且多个服务项目之间还存在一定的联系。这些服务项目之间的联系,也是客户所知道和所需要的,所谓"一条龙"服务,就是系统性地为客户提供全方位的服务,是最大限度地提高客户的满意度的,体系化的服务。

只有通过特定的客户和服务项目之间的联系,不同服务项目之间的联系,业务系统才能把不同类型的客户或供应商集结起来,这就构成了业务系统对外的服务体系。对于企业来说,只要能够对适当的客户群提供系统性的、体系化的服务,一般就都具备了长盛不衰的基础。

我们已经知道,对客户和供应商等业务系统外部的交互者,UML用"业务主角"的概念来建模,对业务系统对外提供的服务项目,UML用"业务用例"的概念来建模。对上述业务系统的对外服务体系,UML则运用了最基本的模型-"业务用例模型"来表达。

一个组织面对什么客户群,提供怎样的服务体系,是决定一个组织业务架构的基础。比如:供电局和环保局的业务架构就不同,学校和医院的业务架构也不同,商场和工厂的业务架构也不同,原因就是他们各自对外提供的服务体系是非常不同的。

UML业务用例模型用一个带箭头的线段来连接业务主角和业务用例,或连接一个业务用例到另一个业务用例。这样就把分散独立的业务主角和业务用例连接成了一个网络关系的图。也就是"业务用例图"。业务用例图是业务用例模型的图示化的表达,能清晰、完整细致地表现业务系统对外的服务体系。

这个带箭头的线段,用于连接业务主角和业务用例的时候,表达了如下的含义:

1.  这里有一个交互操作的过程,交互操作的发起者在线段的起始端,响应者则在箭头指向端;

2.  这里有一个服务价值转移的过程,服务的请求者、受益者和支付者在线段的起始端,服务的提供者、实现者和受酬者则在箭头的指向端。

3.  这里有一个信息流向的过程,在交互操作的过程中,虽然信息一般是双向流动的,但从总的信息流量和信息交换的主被动关系来看,接受信息多的一方往往也是被动交换信息的一方,因此,也是箭头指向的一方。

以上三层含义就分别表达了对外服务体系中的三层关系,即有形的操作交换关系以及无形的价值交换和信息交换关系。这三层关系组合结果,可能出现的情况如下:

1.  这三层的关系的方向指向在绝大多数情况下,可以认为是一致,不出现矛盾的情况,这种情况下,箭头方向选择没有任何疑问;

2.  在某些情况下,某层关系可能不明显和直接,但总有某一层关系是明显的;这时,箭头方向表达最明确的层次关系。

3.  当实际的三个表达层次出现矛盾的时候,则可以取最希望表达的层次来理解,这时,箭头方向的选择代表了建模者在特定场景下主观意图上对某个层次的重视。

当箭头线用于连接两个不同的业务用例的时候,表示在两个业务用例所表达的服务项目之间存在某种关联关系,可能的关系含义包括但不限于如下几种:

1.  箭头的起始端业务用例与其业务主角的关系,可以顺着箭头线,"传导"到箭头指向的业务用例。也就是说,箭头线起始端业务用例的主角,同样是箭头线指向端业务用例的主角。

2.  业务主角在享受一个服务项目的价值的过程中,一定会要享受另一个服务项目的价值;

3.  业务主角在享受一个服务项目的价值的基础上,还可以享受更多的别的具有衍生价值的项目服务;

4.  业务主角在享受一个服务项目之前,依赖于先前享受过另一个服务项目的服务;

5.  一项总的服务项目和组成这个总服务项目中的某个分项目;

6.  一种服务项目的操作模式和按这种操作模式实现的具体的服务项目;

7.  一个粗略的服务项目可具体化为一个精细的服务项目;

8.  一个服务项目的意图过程和实现这个意图过程的具体的服务项目。

用来表达以上多种业务用例关系的箭头线有不同的画法,为了能区分到底表达的是哪种用例的关系,可能在线的旁边用文字来标识,也可能用不同的箭头形状,线型表示不同的关系类型。详细的表达方法我们在讨论具体的用例关系表达时做专题讨论。

最后需要强调的是:业务用例模型只需要表达一个业务系统对外界的服务体系,不需要对业务系统内部的服务和协作关系进行表达。对于后者,UML业务建模会用"业务对象模型"这种更适合表达协作过程的模型来表达,这是UML业务建模的最基本的模型分工。这样分工带来的好处是:一方面可以让我们在建立业务用例模型的时候,把主要精力集中到要满足的客户业务需求上面来;另一方面使得模型的表达内外有别,内外呼应,使模型信息的组织更加具有系统性,并符合我们认识事物由远而进,由外向内的一般规律。

推荐到鲜果: 查阅更多相关主题的帖子: UML 业务模型

评论

读了几篇您的文章,真是感到兴奋啊,因为对于我这个初学者学到了很多东西,真是有点爱不释手的感觉

发布者 abel_zhyb
2006-9-6 13:07:25


真懂和学过真是两回事呀,就得听高手讲呀,否则就越来越二糊.

发布者 yushan
2006-9-28 14:11:38


多谢余山老师捧场,我曾经邀请余山老师参考的一篇文章是:"计划就比变化快".

http://www.vsharing.com/Blog/Smarthings/A409794.html


发布者 babituo
2006-10-8 15:34:57


在开始对业务对象模型基础知识讲解之前,我也需要重温一下之前的帖子.重温读者对我的鼓励,这是我更好发挥的动力,多谢过录留言的读者.


发布者 babituo
2007-4-24 11:49:52


读一篇精彩的文章入引一杯香醇佳酿~回味无穷!继续学习中~

发布者 从头再来
2007-6-22 11:18:13


看了您的文章,真的是受益匪浅。。。谢谢


发布者 kissall
2007-8-9 16:22:59


您正在以 匿名用户 的身份发表评论  快速登录
(不得超过 50 个汉字)
       看不清,换一个
提示消息
(输入完内容可以直接按Ctrl+Enter提交)