从业务系统的服务体系到执行体系-UML软件工程组织-火龙果软件

UML软件工程组织

从业务系统的服务体系到执行体系

作者:babituo 出处：itpub.net

业务系统的服务体系表达的是业务系统的目标、可提供的价值及围绕价值的服务过程。

需要注意的是，并不是所有业务系统的对外价值都可以用流程化的方式提供，但高水平的业务系统，必然会形成流程化的服务来提供其主要的对外价值，这些流程化的服务就可以封装为服务项目，利用UML就将这些服务项目建模为业务用例。

以非流程化方式提供的服务也是常见的，这些服务也可能有明确的价值定位，但由于经验和现实条件的限制，却很难有相对固定的流程来响应，利用UML进行业务用例建模，正好能发现将这些非流程化方式提供的服务进行流程化，找到提高服务水平，提升服务价值的机会。从业务系统的整个服务体系来说，UML业务用例建模抓住了其中可以或已经流程化的服务项目来进行表达，从而为业务自动化提供机会，那些不可流程化的服务内容，则不适合用业务用例模型来表达。

业务系统的执行体系表达的是业务系统的内部执行机构、和内部执行机制。对于业务系统的可流程化的服务项目来说，业务系统内部应该具有或可以具有分工明确的执行单位，组成严谨的执行机构，按照相对固定的流程定义，对业务实体施行一系列的功能操作，最终完成服务的内容，实现服务的价值。

需要指出的是：业务系统的服务体系和执行体系并不是两个分别存在的体系，而是对同一个业务系统的，站在两个不同观察点所得到的视图，站在业务系统的外部看到的是服务体系，站到内部，则看到的是执行体系。

所以，对业务执行体系的建模任务，就主要包含对业务执行体系中的执行单位、执行机构、执行流程、实体对象的建模。

业务执行单位包括业务部门、业务团队、业务的岗位、机器、设备等具有某种执行能力的个体或团体，如：销售部，物资部经理，冲压机等是能做出行为和动作的人或物的个体或团体。

执行机构则是执行体系中所有执行单位及它们之间的关联关系，这些关联关系将所有执行单位组合为一个整体。如：物资部有经理岗位，包含采购组，仓管组，备料组三个工作组，生产车间有12个工人，3台冲压机等。除了组成执行体系的整体结构关系外，执行机构还包含执行单位之间的概念关系，比如分类归属关系等，如，物资部经理和销售部经理都是经理级领导，冲压机，线切机都是生产设备等。有了这些概念关系，对执行机构更容易把握、理解和管理；

执行流程则是为了实现一个服务项目的目标，在执行体系内将发生的不同的执行单位的一系列行为过程的定义。当业务系统面临某个服务项目的一次请求的时候，就会启动一次内部流程的实施过程，相关的执行单位会按流程的定义在适当时候先后做出适当行动。对于不同类型的服务项目可能会对应不同的执行流程，但对同一类服务项目，则只有一个整体的流程。比如，对于售后服务会有一套标准的内部执行流程，销售部、工程部、物资部甚至研发部的资源会参与进来，按一定的步骤和逻辑关系作不同的工作，来保证用户对售后服务满意同时公司得到收益。

执行对象则是组成服务项目交付物的原料、中间产品或组成部分，是被操作的实体，这些实体，在服务项目的实现过程中，其静态的组成结构特征被被动地改变，其可能存在的动态行为特征则基本可以忽略。如生产电视机用的设计图纸、原材料、零部件，生产计划，财务报表，使用说明书等，这些东西是在服务过程中基本上是被操作，被动发生改变而不能作出相应的行为和动作的对象。

朋友们或许还记得,在学习完业务建模的基本概念之后,我举了一个小软件公司财务部业务用例模型的小例子，来让大家对业务建模的概念有感性的认识. 为了让大家对从一个业务系统的服务体系到执行体系的建模过渡过程认识得更清晰,以下继续用这个实例来说明这两个建模阶段的关系。

在那个例子中，被研究的业务系统就是一个小软件公司的财务部，也就是我们要对其进行业务建模的对象。当时我们只研究了财务部发工资的服务项目，现在根据我自己对这个财务部的理解，将比较完整的服务体系建模如下：

图中每个用例对应一项财务部对外提供的服务项目，并且这些服务项目已经成为财务部日常工作的主要内容，具有相对稳定的工作流程。每个服务项目的内部会对应一组过程的定义。找到这些服务项目及其相互的关系，只是完成了业务建模的开始阶段的工作，给出对应每个业务用例的内部流程的详细定义，才是业务建模工作的主体内容。

不同的业务建模方法，都是分层来进行的，结构化的方法往往是按从对过程描述的粗略程度的不同来分层表达的，类似从一幅世界地图详细到国家地图，然后到地区、城市地图这样分层来表达，是一种“非生物形态”的表达。

面向对象方法同样也是对业务系统进行分层来表达的。不同的是，这种层次关系不仅仅表现在空间的粗略和精细程度上，还表现在“目的（需求）-过程-对象-功能”这种“生物形态”的分层表达。

需要重复提醒的是：并不是这个财务部所有的对外服务内容全部都列入了上面的模型，一些重复频率不高的服务过程，如：接受审计。当然，还有就是我作为财务外行所不了解的那些工作。在本文的这里，关键的问题不是我漏掉了多少财务部的业务服务项目，而是如何从已经得到的对业务系统的服务体系的外部描述进入到对业务系统的内部执行体系的描述？

在业务用例建模的第四讲中，我讲述了如何对客户的体验进行UML建模。那一讲所讲的内容，是最接近业务执行体系的。客户的体验来自具体而详实的、享受服务过程中的，每一次与业务系统的交互行为。在关注客户体验的时候，我们是不会深究业务系统内部是如何执行一系列的行为，来满足客户所需求的体验的。在那时，我们正好留下了继续深入分析内部过程的“横断面”接口。

这里人为地给业务系统包上了一个壳界，把业务过程割裂成外部过程和内部过程，就像当时我举的买饭窗口例子一样。内外的过程在这层壳界上进行对接，内部过程必须满足外部过程的需要。所以，我常常把业务用例模型里的椭圆形用例图案，比喻为进入业务系统内部执行体系的每一道“门”，每一扇“窗”或每一个“管道接口”。对业务执行体系进行分析的最好切入点，无疑就是这些“门窗接口”。

下面的示意图表达了上述文字想表达的意思。

客户的过程需求对应客户需要某个对手和自己进行一系列的交互行为的需求, 客户要让某些已经存在的物体对象改变其存在状态的需求实际上也可归结为过程需求。而客户的物质需求则对应客户希望得到什么新的物体对象的需求。过程需求和物质需求是满足客户精神需求的两条物理渠道。而过程需求和物质需求全靠业务系统提供的过程服务来满足，这也正是业务系统生存的价值和依据。