学习指导 对服务体系进行UML业务建模

本节和大家学习一下怎样对服务体系进行UML业务建模，从业务系统外部看来，一个业务系统对外提供的服务项目一般不是单一的，而是多项的，并且多个服务项目之间还存在一定的联系。

怎样对服务体系进行UML业务建模

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

从业务系统外部看来，一个业务系统对外提供的服务项目一般不是单一的，而是多项的，并且多个服务项目之间还存在一定的联系。这些服务项目之间的联系，也是客户所知道和所需要的，所谓"一条龙"服务，就是系统性地为客户提供全方位的服务，是最大限度地提高客户的满意度的，体系化的服务。
只有通过特定的客户和服务项目之间的联系，不同服务项目之间的联系，业务系统才能把不同类型的客户或供应商集结起来，这就构成了业务系统对外的服务体系。对于企业来说，只要能够对适当的客户群提供系统性的、体系化的服务，一般就都具备了长盛不衰的基础。

我们已经知道，对客户和供应商等业务系统外部的交互者，UML用"业务主角"的概念来建模，对业务系统对外提供的服务项目，UML用"业务用例"的概念来建模。对上述业务系统的对外服务体系，UML则运用了最基本的模型-"业务用例模型"来表达。
一个组织面对什么客户群，提供怎样的服务体系，是决定一个组织业务架构的基础。比如：供电局和环保局的业务架构就不同，学校和医院的业务架构也不同，商场和工厂的业务架构也不同，原因就是他们各自对外提供的服务体系是非常不同的。

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

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

◆这里有一个交互操作的过程，交互操作的发起者在线段的起始端，响应者则在箭头指向端；
◆这里有一个服务价值转移的过程，服务的请求者、受益者和支付者在线段的起始端，服务的提供者、实现者和受酬者则在箭头的指向端。
◆这里有一个信息流向的过程，在交互操作的过程中，虽然信息一般是双向流动的，但从总的信息流量和信息交换的主被动关系来看，接受信息多的一方往往也是被动交换信息的一方，因此，也是箭头指向的一方。

以上三层含义就分别表达了对外服务体系中的三层关系，即有形的操作交换关系以及无形的价值交换和信息交换关系。这三层关系组合结果，可能出现的情况如下：
这三层的关系的方向指向在绝大多数情况下，可以认为是一致，不出现矛盾的情况，这种情况下，箭头方向选择没有任何疑问；
在某些情况下，某层关系可能不明显和直接，但总有某一层关系是明显的；这时，箭头方向表达最明确的层次关系。
当实际的三个表达层次出现矛盾的时候，则可以取最希望表达的层次来理解，这时，箭头方向的选择代表了建模者在特定场景下主观意图上对某个层次的重视。

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

◆箭头的起始端业务用例与其业务主角的关系，可以顺着箭头线，"传导"到箭头指向的业务用例。也就是说，箭头线起始端业务用例的主角，同样是箭头线指向端业务用例的主角。
◆业务主角在享受一个服务项目的价值的过程中，一定会要享受另一个服务项目的价值；
◆业务主角在享受一个服务项目的价值的基础上，还可以享受更多的别的具有衍生价值的项目服务；
◆业务主角在享受一个服务项目之前，依赖于先前享受过另一个服务项目的服务；
◆一项总的服务项目和组成这个总服务项目中的某个分项目；
◆一种服务项目的操作模式和按这种操作模式实现的具体的服务项目；
◆一个粗略的服务项目可具体化为一个精细的服务项目；
◆一个服务项目的意图过程和实现这个意图过程的具体的服务项目。