1 概述
面向服务体系机构(Service-Oriented Architecture, SOA)是一个面向服务的组件模型，从建模和设计的角度来说，SOA更多地侧重在业务层次上。在业务建模上，业务流程建模标记(Business Process Modeling Notation, BPMN)凭借其图形化、容易被业务人员理解、支持复杂的业务流程设计并且能够直接映射到基于XML 的业务流程执行语言等特点，成为业务分析领域的主要流程建模规范之一。
针对SOA系统的规模估算方面，至今还没有一个有效的解决方案。IFPUG 功能点方法在估算SOA系统规模上也没有取得良好的效果。全功能点方法是一种逐渐被广泛采用的规模估算方法。文献[3]提出使用全功能点方法估算SOA系统的规模，但是它仅从理论上阐述了用全功能点估算SOA系统规模的可行性和定界问题，并没有给出具体的解决方案。
本文在以上研究成果的基础上，根据全功能点和BPMN的特点，建立一套从全功能点到BPMN 的映射规则，给出全功能点估算SOA系统规模的步骤，并通过一个实例说明具体的估算过程。
2 软件规模估算与全功能点方法
功能点方法就是估算软件功能性用户需求的大小，是针对代码行的缺点而提出的一种规模估算方法，独立于具体的开发技术和平台，适应软件开发周期早期。在众多功能点方法中， IFPUG 功能点(International Function Point UserGroup)和COSMC 全功能点(Common Software MeasurementInternational Consortium)已成为ISO 国际标准，并且是目前被广泛应用的2 种功能点估算方法。
IFPUG 功能点方法的主要思想是将软件分解成基本功能组件(内部逻辑文件、外部接口文件、外部输入、外部输出、外部查询)，并对每个基本功能组件计算其复杂度，折算成未调整的功能点个数，求和得到软件总的未调整功能点数。这种方法的“基本功能组件”很难与SOA中的“服务”建立映射关系，因此不适合估算SOA系统的规模，文献[3]也阐述了这一点。
全功能点方法的主要思想是将系统分解成层次，每个层次分解成若干对等组件，每个对等组件又分解成若干功能流程。每个功能流程包含若干数据移动，一个数据移动是一个数据组的传输，一个数据移动记为一个功能点。如图1 所示，有4 种类型的数据移动：输入(Entry)，输出(Exit)，读(Read)和写(Write)。全功能点方法中“层次”、“对等组件”可以与SOA中的“服务”建立映射，而且功能点的“功能流程”可以很容易地与BPMN 中“业务流程”建立映射。基于以上分析，认为全功能点方法最适于估算SOA系统软件的规模。
图1 全功能点方法的数据移动
全功能点方法的主要核心元素是与BPMN 映射的关键，可参照度量手册。这些核心元素包含层次、对等组件、功能用户、边界、功能流程、事件、数据组、数据移动等。
3 SOA系统与BPMN 建模
在SOA体系结构中，服务是最核心的抽象手段，其中一个简化的SOA体系结构如图2 所示。
图2 简化的SOA体系结构
从建模和设计的角度讲，SOA更多地侧重于业务层次上，业务被划分为一系列粗粒度的业务服务和业务流程。业务服务有多种实现方式，其中最流行的实现技术是Web 服务。Web 服务定义了如何在异构系统之间实现通信的标准化方法，使得服务可以跨平台和具体语言实现。业务流程被定义为一个由各种不同功能的活动相连的一组有相互关系的任务，它们依照一定的业务逻辑和顺序依次执行，业务流程有起点和终点，并且它们都是可重复的，业务流程可以按一定逻辑将“服务”组装起来，形成功能更丰富的服务，称为组合服务。
BPMN 通过一套绘图元素为业务流程建模，既能提供给用户直观的模型界面，又能表示复杂的业务流程。其能同时被业务人员和技术人员理解的特点，使之成为沟通业务流程设计和流程实现的桥梁。BPMN 与全功能映射的主要绘图元素包含事件、活动、网关、序列流、消息流、泳池、泳道，数据对象等完整的绘图元素可参考BPMN 规范。
4 全功能点与BPMN 的映射关系
4.1 映射规则
映射的主要任务就是把全功能点的核心元素映射到BPMN 的绘图元素中，目的是估算出以BPMN 图形表示的业务流程包含的全功能点数，从而估算出SOA系统的规模。通过分析研究，是把全功能点方法的核心元素映射到BPMN 主要绘图元素中，如表1 所示。
表1 全功能点与BPMN 的映射关系
为了说明表1 的映射关系，补充了如下映射规则。
规则1 全功能点的层次(Layer)是与软件的体系结构相关的，层次的粒度特别大，通常将整个BPMN 图形表示的功能流程映射为一个层次。
规则2 全功能点的对等组件(Peer Component)和BPMN中的活动(Activity)的共同点是都完成了一部分的功能性用户需求，对等组件可以由多个组件组合而成，活动也可以由多个活动组合而成。从概念上讲，对等组件是粗粒度的，完成相对独立的、较复杂的、有价值的功能。活动既可以完成复杂的功能，也可以完成相对简单的功能，这与业务功能的“粒度”相关。活动分为流程(Process)、子流程(Sub-process)和任务(Task)，通常在任务中引用Web 服务。对等组件和活动能否直接映射，取决于活动能不能提供一个相对独立的、复杂的、有价值的功能。若某个子流程或任务不满足这个条件，那么可以将几个子流程或任务组合起来形成一个更大的流程，使这个流程能完成一部分功能性用户需求，从而映射为一个对等组件。
BPMN 中的泳池(Pool)主要用于2 个独立的实体或者参与者之间的物理划分，泳池内部是一个流程，一般完成较复杂的业务功能。若泳池所代表的实体是系统内的元素，那么这个泳池可以映射为一个对等组件；若泳池所代表的实体是系统以外的用户或软硬件设备，则这个泳池所代表的实体可以映射为一个全功能点的功能用户。
规则3 全功能点的功能用户(Function User)除了可以映射为BPMN 的泳池或泳道所代表的实体外，也可以映射为系统外任意与系统交互的事物。因此，若某个活动已经被映射为全功能点的对等组件，则任何与该活动交互的事物都可以映射为全功能点的功能用户(这个事物可以是另一个活动)。
规则4 全功能点的边界(Boundary)是功能用户与待估算软件的交界处，若2 个泳池交互，其中一个泳池为待估算软件，另一个泳池为功能用户，则2 个泳池的交界就映射成边界。若不存在泳池，则整个业务流程中，被估算的业务流程与其他业务流程交互的界限就是边界。
规则5 全功能点的事件(Event)与BPMN 中的事件都是触发一个功能流程或任务的执行。全功能点的事件可以与BPMN 中的消息、时钟、错误、取消、补偿、信号等各种事件(Event)相映射。另外，一个任务的结束、序列流(SequenceFlow)、消息流(Message Flow)、网关(Gateway)可以触发一个任务的执行，也可以与全功能点的事件映射。
规则6 与对等组件的概念相似，全功能点的功能流程(Function Process)也是功能性用户需求的子集，但功能流程的粒度比对等组件小得多，它通常包含在对等组件中。功能流程通常完成较简单的功能，可以与BPMN 中任务相映射，若任务的粒度较大，则功能流程可以与任务分解出来的流程相映射，这与任务的粒度是相关的。若任务的粒度较小，则功能流程可以与几个任务相映射。
规则7 全功能点的数据组(Data Group)与BPMN 中的数据对象(Data Object)都属于交换的信息，可以映射。另外，只要是2 个事物交换的信息，都可以映射为数据组。
规则8 一般来说，全功能点的数据移动都不能与BPMN中的元素直接映射，要通过分析与任务相映射的功能流程才能得到数据移动。
4.2 估算步骤
基于上述映射关系，本文定义了全功能点估算SOA系统规模的估算步骤作为参考，根据SOA中原子服务与组合服务的关系，将SOA中的业务流程组织成一个图结构。在BMPN中，设置业务流程中的活动为顶点，顶点的类型主要有3 种：收缩的子流程，扩展的子流程和任务。最终，子流程又可以分为任务。通常在任务中调用Web 服务，Web 服务可以自己开发，也可以调用其他组织提供的服务。估算步骤如下：
步骤1 按表2 的映射规则，识别出BPMN 图形所表示的层次、对等组件、功能用户和边界。
步骤2 对于整个BPMN 图形，确定其中一部分待估算的BPMN 图形(通常为一个功能组件及相关功能用户)，建立图结构。从某顶点开始遍历整个图结构，可以按深度优先遍历。步骤3 对于每一个顶点，判断其是子流程还是任务，若该顶点是子流程，重复步骤1、步骤2。
若该顶点是任务，按表1 的映射规则，识别出BPMN 图形所表示的事件、功能流程、数据组和数据移动。然后按全功能点方法提供的估算规则估算功能点数。
若该任务调用了Web 服务，继续判断该Web 服务是自己开发还是调用其他组织提供的服务。若是自己开发，对此Web 服务，重复步骤1、步骤2。
步骤4 待估算的BPMN 图形的功能点数就是此BPMN图形所有顶点的功能点总和。
步骤5 回到步骤2，继续确定剩下的待估算的BPMN 图形，直到整个软件估算结束。
5 案例分析
以某实验室开发的一个商品购物服务(eStore)为例，说明如何使用上述方法估算SOA系统的功能点数。
由于篇幅有限，只能对整个过程进行概要描述。如图3 所示，eStore 组合了一些已发布的原子服务，并添加一些自己开发的Web 服务，形成一个以各大网站提供的服务为基础的购物组合服务。这些原子服务包括亚马逊、eBay 等电子商务公司发布的查询商品、购买商品的原子服务，包括各大银行为了方便用户在网上支付购物费用而开发的相应的Web 服务。
图3 eStore 的业务流程
按照第4 节定义的映射规则和估算步骤，对eStore 的业务流程的具体估算过程如下：
步骤1 在图3 中，包含2 个泳道Customer 和eStore。Customer 并不是待开发软件，所以把eStore 映射为一个功能组件，Customer 映射为功能用户。eStore 和Customer 都处于同一个层次，eStore 的边界就是泳池的边界。
步骤2 确定整个BPMN 图形为待估算的BPMN 图，建立图结构，图的顶点为任务(Task)图元，如“查找商品”和“返回结果”等任务。于是从圆圈符号(开始事件)开始，遍历整个图结构。
步骤3 首先访问到“查找商品”和“返回结果”任务，这2 个任务一起映射为一个功能流程。Customer 的“查询请求”任务映射为触发该功能流程的事件。根据功能点的计算规则得出这个功能流程共有3 个功能点。“查找商品”任务调用了第三方提供的查找商品服务，这个服务不需自己开发，因此，“查找商品”服务本身的功能点数不用估算。
然后用上述方法继续遍历后续任务，直到遇到圆圈符号(结束事件)，于是图中的全部顶点(任务)就都被访问了。“生成订单”和“支付费用”任务调用了第三方提供的服务，“发货”任务调用了组织内部已有的服务。
步骤4 将Customer 的“登录”任务也算在内，此BPMN图所代表的功能点数为31 个。
步骤5 因为步骤2 已经确定了整个BPMN 图形为待估算的BPMN 图，无剩余图形，估算结束。
估算结果表明，开发整个eStore 的业务流程需要的功能点数为31 个，可见，SOA体系结构的采用减小了整个软件项目的开发规模和工作量。
6 结束语
本文在研究全功能点方法及BPMN 的基础上，应用了全功能点方法估算SOA系统的规模，从而为SOA系统的规模估算提供一种新的思路。本文不仅定义了全功能点方法到BPMN 的映射规则，给出了全功能点方法估算SOA系统规模的步骤，并且通过一个实例说明这种方法的使用。实践证明，该方法在SOA系统规模的估算上起到了良好的效果。通过更多的实践继续研究全功能点方法及BPMN 的映射关系，从而能够更精确地估算SOA系统规模，为整个SOA项目估算奠定坚实的基础。
核心关注：拓步ERP系统平台是覆盖了众多的业务领域、行业应用，蕴涵了丰富的ERP管理思想，集成了ERP软件业务管理理念，功能涉及供应链、成本、制造、CRM、HR等众多业务领域的管理，全面涵盖了企业关注ERP管理系统的核心领域，是众多中小企业信息化建设首选的ERP管理软件信赖品牌。
转载请注明出处：拓步ERP资讯网http://www.toberp.com/
本文标题：全功能点在SOA系统规模估算中的应用
相关文章
