基于规则的软件过程主体自动协商系统和方法

摘要

一种基于规则的软件过程主体自动协商系统和方法，该系统由平等的软件过程主体互连而成，过程主体包括以下功能模块：协商规则编辑器、协商模型分析器、协商规则引擎、协商过程引擎、协商规则库、协商过程库。该方法包括步骤：依次处理接收到的消息，检验消息的合法性；根据合法的消息，通过状态转换函数转换过程主体的状态；触发协商规则引擎，并载入协商规则以及相关数据；根据约定的算法，将数据与协商规则进行匹配，并对其进行排序、冲突检测和解决；执行处理过的规则，生成新的数据，将结果提交给协商过程引擎。该方法将传统协商协议分为静态的通用协议和动态的协商规则，以较低的成本为软件过程agent的协商提供了灵活性和动态性。

说明书

技术领域

本发明涉及一种软件过程建模技术，特别涉及一种基于规则的软件过程主体自动协商系统和方法，属于计算机软件生产技术领域。

背景技术

近年来，计算机技术的发展越来越侧重于软件的开发和应用，软件技术的发展已经成为衡量计算机技术水平的重要标志之一。软件的生产规模越来越大，使软件过程建模技术日益成为关系到软件生产成本和质量的关键因素。传统的软件过程建模方法往往将软件过程建模为活动或任务之间的相互关系，且这些活动之间的相互关系是预定义的。在实际的软件开发过程中，一个软件过程通常由一组开发者作为基本组成元素，这些开发者首先相互协商各自承担的任务，达成一致后形成开发小组，从而相互协作以完成软件过程的目标。基于主体(agent)的软件过程建模方法将软件过程建模为一组可代表软件开发者(可以是单个开发者、也可以是团队或组织)、具有软件过程知识、能够实施软件过程活动(如系统设计、编码以及测试等)的主体之间的相互协作关系，这些主体被称为软件过程主体，简称过程主体。这种强调软件过程中软件开发者为主要构成元素，且构成元素之间的关系通过主动、灵活的协商而建立的软件过程，更接近软件开发的实际情况，具有较好的灵活性和对环境的适应性。

在已知的现有技术中，基于主体的自动协商方法考虑三个基本要素：协商协议、协商参数以及决策策略。目前基于主体的大多协商方法都是非灵活的：预定义和固定协商协议、固定协商参数的数量，甚至所有协商参与者均采用单一、相同的决策策略，当这些因素发生改变时，相应系统的维护成本就很昂贵。过程主体的协商过程是多形式和变化的，依赖于环境、业务目标、项目特点等因素。例如，组织间关于软件外包项目的协作关系的建立，可以采用一对多的拍卖式协商，也可采用一对一的谈判式协商；而不同等级的协商主体(比如个人、团队和组织就属于不同等级的协商主体)之间的协商明显不同。因此，在协商的过程中，代表协商主体的过程主体(Agent)需自主决定其所使用的协商协议、所协商的协商目标以及所采用的决策策略，而那些非灵活的、静态的、变更代价昂贵的协商方法显然不适用于过程主体。

还有一些方法将控制协商过程某些方面的规则与协商过程本身分离表示，在获取协商灵活性和动态性方面取得了一定的成果，如将时间控制和拍卖过程分别表示和处理，从而在时间控制方面取得了一定的灵活性；用规则表示决策策略，并采用相应技术使规则能够在系统运行时间被动态添加和修改，从而决策策略可动态、灵活地变化；将协商协议中的某些规则提取、分类，为协商协议提供一定的灵活性。然而，当这些方法应用到过程主体时，存在两个主要问题：(1)它们仅提供了协商中某一方面的灵活性和动态性，而过程主体需要一个完整的解决方案，能够基于自身需求，环境变化等因素适应地、灵活地、动态地决定它们所需采用的协商协议、需要协商的协商目标及数量、以及所使用的决策策略；(2)它们大多针对电子商务领域，因而不能完全适应过程主体的需求。

发明内容

为了解决上述问题，本发明的目的在于提供一种基于规则的软件过程主体自动协商系统和方法，用于软件过程建模。发明构思为：在相互连接组成分布式网络的计算机终端上部署软件过程主体(Agent)，每个过程主体都具有唯一的标识，并可以基于规则独立地建立协商模型。所有软件过程主体既可以通过该系统发布协商目标，也可以根据其他过程主体发布的协商目标进行响应。

在所述的过程主体自动协商系统中，软件过程主体之间建立协商的主要过程描述如下：当过程主体接收到一个目标的时候，首先对该目标进行规划，根据自身的知识库，建立基于该目标的任务树，树上的每个节点表示满足该目标所需完成的任务。所述任务树的层次和粒度取决于过程主体的知识库。例如，某一过程主体a接收到一个关于开发Web的目标A，该目标需要10人月(即，10个开发人员一个月的工作量)。该过程主体根据知识库所提供的经验，分析出实现该目标需要4项子任务：需求、分析、实现、测试；然后进一步根据知识库所提供的关于该过程主体自身能力的信息，决定将需求、分析和实现作为自身的任务，而将自身无法完成的测试作为协商目标B发布给系统中的其他过程主体。所有接收到该协商目标B的过程主体都重复和过程主体a相同的步骤，假设其中的过程主体b将测试任务拆分成单元测试和集成测试两部分，并判断出自身只能够完成集成测试的任务，则将另一任务再发布出去。此时，假设过程主体c接受了该任务并给予确定的反馈信息，则过程主体b和c就该任务的属性，比如该任务的工作量、质量进行协商并达成一致。在协商的过程中，过程主体根据各自的规则库进行决策。当过程主体b和c协商一致之后，b向a发出确定接受任务的消息，然后b和a就测试任务的属性进行协商。

对于每个过程主体而言，其首先要建立一可执行的协商模型，然后参与协商。所述的协商模型包含三个基本元素和两个控制元素，两个控制元素是通用协议和协商规则。所述三个基本元素是：可能参与协商的主体集合、协商原语集合、协作合同模板。协商原语集合用于过程主体之间的话语通信，由通用协议控制，通用协议作为信息流的静态控制，可支持过程主体大多形式的协商过程。协作合同模板是针对传统模型固定协商目标以及协商目标数量的问题而提出的一种组织协商目标的方式，合同模板包括协商目标和协商参数，由协商规则控制，过程主体的协商过程是过程主体就合同模板中的某些参数交替发送自己认可的参数值，直至协商参与者对这些参数值达成一致的过程。因协商参与者对该结构及内容有一致的理解，当协商目标在运行时间被加入时，过程主体能够知道并处理这种被动添加的协商目标。这样为用户提供了更大的协商灵活性。

如图3所示，协商模型建立后，过程主体参与协商的具体步骤包括：

1、依次处理接收到的消息，检验消息的合法性，并将消息传输给状态转换器；

2、状态转换器接收到消息后，根据状态转换函数转换过程主体的状态；

3、过程主体的状态变化后，其随后的行为取决于协商规则，因此此时规则触发器触发协商规则引擎，并将协商规则引擎所需的信息传输给规则事件管理器，由事件管理器触发数据载入器；

4、数据载入器载入协商规则以及相关数据，供规则匹配器推理使用；

5、规则匹配器根据约定的算法，将数据与协商规则进行匹配，被匹配的规则进入规则匹配队列；

6、规则匹配队列管理器接收规则匹配器生成的规则并对其进行排序、冲突检测和解决等，将处理后的规则递交给规则执行器执行；

7、规则执行器依次执行规则匹配队列管理器传递过来的规则，生成新的数据，将结果提交给协商过程引擎。

相应地，自动协商系统中的软件过程主体包括以下功能模块：

协商规则编辑器，用于编辑、管理协商规则，包括控制规则和决策规则，显示协商规则的分析结果，提示用户进行规则冲突处理；

协商模型分析器，用于检查由协商规则编辑器所定义的协商规则与通用协议构成的协商模型的正确性和合理性；

协商规则引擎，用于对协商规则进行推理，根据协商过程引擎调用时给定的参数值，将结果返回给协商过程引擎，以实现对协商过程的控制和决策；

协商过程引擎，用于驱动可执行的协商过程模型，包含对协商规则引擎的调用；其相当于一个工作流引擎，按照通用协商协议解析协商过程的全部活动，并通过调用协商规则引擎触发符合协商规则的活动；

协商规则库，用于存储协商规则，包括过程控制规则和决策规则；

协商过程库，用于存储协商过程产生的消息流数据，主要包括每次交互的过程主体、发送的协商原语、协作合同以及发送时间等。

其中，协商过程引擎模块还包括：消息处理器，用于接收、发送消息，并对所接收到消息的合法性进行检查；状态转换器，用于过程主体的状态转换控制，该控制遵循通用协议GProtocol；规则触发器，用于触发协商规则引擎。协商规则引擎模块还包括：规则事件管理器，用于响应协商过程引擎对规则引擎的触发事件；数据载入器，用于载入协商规则以及相关数据；规则匹配器，用于将数据与协商规则进行匹配；规则匹配队列管理器，用于接收规则匹配器生成的实例化数据队列，进行冲突检测和解决，提交给协商过程引擎；规则执行器，用于执行协商规则，依次执行规则匹配队列管理器传递过来的规则，生成新的数据，将结果提交给协商过程引擎。

本发明的技术效果在于：(1)将传统协商协议分为两部分：一个通用协议和规则。通用协议是静态的，能够支持多种形式的协商过程。规则是变化的，为协商协议带来灵活性和可变性；(2)将决策策略表示成规则，由此决策策略能够被定以和修改以适应环境状态等影响因素的变化；(3)协商目标以结构化协作合同的方式组织，能够被动态添加；(4)协商规则独立存储和演化，与模型的其它部分以一种低耦合的方式交互，从而以较低的成本为软件过程agent的协商提供灵活性和动态性。

附图说明

图1是基于规则的软件过程协商模型中的通用协议；

图2是系统的构架示意图；

图3是协商过程的执行步骤以及系统的主要功能模块详细结构示意图。

具体实施方式

以下结合附图，通过优选的具体实施方式对本发明作进一步的说明，但不构成对本发明的限制。

以企业间就软件外包项目进行协商的过程为例，企业就软件外包项目进行协商的过程一般是：某需要将某软件项目向外承包的企业向其它企业发送协商请求，响应的企业与其建立协商关系后，开始就彼此关心的协商参数值进行协商，直至彼此就这些值达成一致的意见，从而建立起彼此的合作关系。

首先时软件过程主体自动协商系统的建立，所有参与协商的企业被建模成软件过程主体并互连成一自动协商系统，每个过程主体在系统中都具有唯一的标识。如图2所示，过程主体的基本功能模块包括：协商规则编辑器、协商模型分析器、协商规则引擎及其拥有的协商规则库、协商过程引擎及其拥有的协商过程库、以及用于发布消息的Web服务器。其中，协商规则编辑器和协商模型分析器位于用户可见的访问界面。

其次是建立可执行的协商过程模型，每个过程主体都可以基于自身的知识和能力定义和修改协商规则；所述的知识和能力可以包括：组织能力(如承担某类项目的能力)、个人能力(如编码能力)、资源(时间资源)等；协商规则的编辑、管理功能由协商规则编辑器实现，且协商规则存储于协商规则库。协商规则包含控制规则和决策规则，控制规则可以由协商发起者定义，例如：协商过程的超时时间、答复的超时时间、什么条件下协商正常终止、什么条件下意外终止。决策规则可以由协商参与者自定义，例如：什么条件下接受对方提出的参数值、什么条件下拒绝以及什么条件下修改对方提出的参数值且自己提出的新参数值如何确定等。协商规则定义后，需进行协商规则合法性分析，分析正确后，将协商规则输出到协商过程引擎和协商规则引擎。

所述协商模型的基本元素由通用协议和协商规则控制，以执行协商过程。所述通用协议命名为GProtocol，是协商过程的静态、不可变控制部分，其通用性使其能够支持过程主体大多形式的协商过程。所述通用协议由一个状态转换图表示，如图1所示，其中：

(1)GProtocol包含5个状态，状态集由S表示，S＝{Start，S₁，S₂，S₃，End}，其中，状态Start是初始状态，状态End是结束状态，状态S1、S2、S3是三种中间状态；

(2)GProtocol包含9种状态转换：

图中状态转换(1)表明：协商发起者提出一个协商请求；

图中状态转换(2)表明：协商发起者发起另一个协商请求，还未收到其他agent对其上一次协商请求的答复；

图中状态转换(3)表明：接到消息的agent接受协商请求；

图中状态转换(4)表明：接到消息的agent拒绝协商请求；

图中状态转换(5)表明：协商过程结束，如果达到限定时间，或者参与协商的agent终止该过程；

图中状态转换(6)表明：协商发起者提出初始协作合同；

图中状态转换(7)表明：协商双方交替发送协作合同，可添加、修改或拒绝其中的协商目标值；

图中状态转换(8)表明：协商过程结束，如果达到限定时间，或者参与协商的agent终止该过程；

图中状态转换(9)表明：协商过程结束，如果达到限定时间，或者agent接受协作合同的内容，或者agent终止该过程。

所述协商规则命名为NR，是协商过程的动态控制以及决策部分。协商规则分为控制规则(CR)和决策规则(DR)。两种规则的定义均基于Horn子句。Horn子句由两部分组成：条件部分和结论部分，条件部分包含多个Horn原子，而结论部分只允许包含一个Horn原子。一个协商规则表示当所有条件为真时，结论为真。控制规则负责协商过程消息流的公共控制，与通用协议GProtocol的主要区别在于其可随环境、目标等因素的变化而被改变或调整。其通常对所有协商参与者公开。决策规则用于确定(大多情况下非公开地)发送的协商原语和包含协商目标值的协作合同，通常非公开，对协商的对方是不可见的。

协商模型的执行与有限状态机的执行类似，包含如下步骤：

步骤一：构建状态转化算法：s×NPrim→s，具体状态转换算法由通用协议GProtocol决定，如图一所示；

步骤二：构建消息流集MF， $>>MF>=>$$>\underset{}{{}_{}}$>mf_i是一个消息流，是一个参与协商的主体向另一个发送的一条消息，一个消息流mf_i由包含以下元素：

(1)发送消息的主体；

(2)接收消息的主体；

(3)被发送的协商原语；

(4)被发送的协作合同；

(5)发送原语和协作合同的时间点。

步骤三：构建协商历史H，H＝{h₁，h₂，...，h_n}，h_i是MF的子集，反映的是主体发送和接收的所有消息流；

步骤四：构建知识K，K由一些关于软件过程的知识组成，如环境知识、组织或个人能力(如编码能力)等；

步骤五：构建有限输入集I：I＝NPrim×CC×H×K；

步骤六：构建有限输出集：Out＝NPrim×CC；

步骤七：构建状态转换函数GProtocol：S×NPrim→S；

步骤八：构建输出函数OF：I→Out，其中，OF有两个子函数：CR：I→Out和DR：I→Out。

OF的最后输出为CR(I)∩DR(I)(≠)。

在任何时间点，一个协商过程的一个参与协商的主体都在集合S中的一个状态中。当其收到一个原语时，在通用协议GProtocol(参见图1)的控制下，被转换到另一个状态。进一步，遵从OF，其输出一个协商原语和协作合同，其中，子函数CR和DR亦即控制规则和决策规则。

协商规则定义后，经协商模型分析器分析正确和合理的协商规则作为数据源载入协商过程引擎中，一个协商过程开始。

过程主体之间的协商过程话语通信采用协商原语，而协商原语以消息的方式实现，消息的类别与协商原语名称一致。所述的协商原语的集合命名为NPrim：NPrim＝{Propose_N，Accept_N，Reject_N，Terminate_N，Propose_CC，Accept_CC，Reject_CC，Modify_CC}，其中各原语的含义如下：Propose_N表示提出一个协商请求，Accept_N表示接受一个协商请求，Reject_N表示拒绝一个协商请求，Propose_CC表示发送一个协作合同，Accept_CC表示接受当前收到的协作合同CC(不再进行修改)，Reject_CC表示拒绝当前收到的协作合同，Modify_CC表示修改收到的协作合同，Terminate_N表示终止当前的协商过程。协商原语的分析和处理实现于协商过程引擎中的消息处理器。

在协商的过程中，所有过程主体基于相同的协作合同模板进行协商，所述的协作合同模板采用XML(网络标记语言)文档方式实现，定义相应的XML Schema；协作合同模板的分析和处理实现于协商过程引擎中的消息处理器。协作合同模板为协商目标，即协商参数的组织形式。协作合同模板命名为CC，包含以下内容：

(1)合同类型：描述合同类别，如企业间外包、项目任务分配等类别；

(2)合同描述：用于说明合同的主要内容，如“J2EE”表明该合同关于一个J2EE项目；

(3)协商参数集：协商参数表明协商参与者感兴趣的具体协商内容，如项目所需人月数，代码质量；协商参数集作为整体反映了协商参与者对感兴趣的协商内容的共同理解；

(4)协商参数值集：协商参数值即协商参数对应的值；协商参数值集表明了协商参数的取值域；

(5)协商目标类别集：协商目标类别用于表明一个协商目标是否可协商，N表示可协商，NN表示不可协商。

协作合同模板中加入了具体内容后就成为一个协作合同，由CC表示。在本实施例中，协商参数包含软件外包项目所需的人月数、代码质量、所提交的文档数量等。

如图3所示，协商过程引擎模块包括消息处理器、状态转换(控制)器和规则触发器。当协商开始后，消息处理器接收消息和协作合同，状态处理器遵从状态转换函数GProtocol，转换过程主体状态；状态处理器接着触发规则处发器，由规则处发器触发协商规则引擎并向其输送参数值，即消息和协作合同，等待返回结果并将结果返回给状态处理器，状态处理器触发消息处理器，待消息处理器发送消息成功后，状态处理器改变过程主体状态等待下一次消息处理器的触发；

协商规则控制实现于协商规则引擎：数据载入器载入协商规则、知识(即事实)、协商历史以及接收协商过程引擎的规则处发器传递过来的参数，然后规则匹配器将事实、参数值与规则进行匹配，规则匹配队列管理器对匹配后数据进行处理后，将处理后的数据交给协商过程引擎的规则触发器。

上述过程重复，直至协商双方达成一致或超时，协商过程结束。