CN1900906A - Software process main body automatic consulting system and method based on rulls - Google Patents

Abstract

A rule-based software process subject automatic negotiation system and method, the system is formed by interconnecting equal software process subjects, the process subject includes the following functional modules: negotiation rule editor, negotiation model analyzer, negotiation rule engine, negotiation process engine, negotiation rule library, and negotiation process library. The method includes the steps of: sequentially processing the received messages, and checking the legitimacy of the messages; converting the state of the process subject through a state transition function according to the legal messages; triggering the negotiation rule engine, and loading the negotiation rules and related data; according to the agreed Algorithm, match the data with the negotiation rules, sort them, detect and resolve the conflicts; execute the processed rules, generate new data, and submit the results to the negotiation process engine. This method divides traditional negotiation protocol into static common protocol and dynamic negotiation rules, and provides flexibility and dynamics for software process agent negotiation at a lower cost.

Description

System and method for automatic negotiation of software process subjects based on rules

technical field

The invention relates to a software process modeling technology, in particular to a rule-based software process subject automatic negotiation system and method, and belongs to the technical field of computer software production.

Background technique

In recent years, the development of computer technology has increasingly focused on the development and application of software, and the development of software technology has become one of the important symbols to measure the level of computer technology. The scale of software production is getting larger and larger, making software process modeling technology increasingly a key factor related to software production cost and quality. Traditional software process modeling methods often model software process as the interrelationships between activities or tasks, and the interrelationships between these activities are predefined. In the actual software development process, a software process usually consists of a group of developers as the basic components. These developers first negotiate with each other about their respective tasks, and after reaching an agreement, they form a development team to cooperate with each other to complete the goals of the software process. The software process modeling method based on the agent (agent) models the software process as a group of representative software developers (it can be a single developer, or a team or organization), has software process knowledge, and can implement software process activities ( Such as system design, coding and testing, etc.), these subjects are called software process subjects, referred to as process subjects. This kind of software process, which emphasizes that the software developer is the main constituent element in the software process, and the relationship between the constituent elements is established through active and flexible negotiation, is closer to the actual situation of software development, and has better flexibility and environmental protection. adaptability.

In the known prior art, the subject-based auto-negotiation method considers three basic elements: negotiation protocol, negotiation parameters, and decision-making strategy. Most of the current agent-based negotiation methods are inflexible: predefined and fixed negotiation protocols, fixed number of negotiation parameters, and even a single, same decision-making strategy for all negotiation participants. When these factors change, the maintenance of the corresponding system The cost is very expensive. The negotiation process of the process subject is multiform and variable, depending on factors such as the environment, business objectives, and project characteristics. For example, one-to-many auction negotiation or one-to-one negotiation negotiation can be used to establish the collaborative relationship between organizations on software outsourcing projects; while different levels of negotiation subjects (such as individuals, teams and organizations belong to Negotiation between different levels of negotiating subjects) is obviously different. Therefore, in the negotiation process, the process subject (Agent) representing the negotiation subject needs to independently decide the negotiation protocol it uses, the negotiation goal it negotiates, and the decision-making strategy it adopts, while those inflexible, static, and change costs Expensive negotiation methods are clearly not suitable for process bodies.

There are also some methods that separate the rules that control certain aspects of the negotiation process from the negotiation process itself, and have achieved certain results in obtaining negotiation flexibility and dynamics. A certain degree of flexibility has been achieved in control; the decision-making strategy is represented by rules, and the corresponding technology is used to enable the rules to be dynamically added and modified during system runtime, so that the decision-making strategy can be changed dynamically and flexibly; certain rules in the agreement will be negotiated Extract, classify, and provide some flexibility for negotiating agreements. However, when these methods are applied to the process body, there are two main problems: (1) They only provide flexibility and dynamics in one aspect of the negotiation, while the process body needs a complete solution that can , factors such as environmental changes adaptively, flexibly, and dynamically determine the negotiation protocols they need to adopt, the negotiation goals and quantities that need to be negotiated, and the decision-making strategies used; (2) Most of them are aimed at the e-commerce field, so they cannot be completely Adapt to the needs of the subject of the process.

Contents of the invention

In order to solve the above problems, the object of the present invention is to provide a rule-based system and method for automatically negotiating software process subjects, which are used for software process modeling. The inventive idea is: to deploy software process agents (Agents) on computer terminals connected to each other to form a distributed network, each process agent has a unique identifier, and can independently establish a negotiation model based on rules. All software process subjects can issue negotiation goals through this system, and can also respond according to the negotiation goals released by other process subjects.

In the process subject auto-negotiation system, the main process of establishing negotiation among software process subjects is described as follows: when the process subject receives a target, it first plans the target, and establishes a process based on the target based on its own knowledge base. A task tree for a goal, where each node on the tree represents a task that needs to be done to meet that goal. The level and granularity of the task tree depend on the knowledge base of the process subject. For example, a certain process subject a receives a goal A about developing the Web, and the goal requires 10 man-months (that is, the workload of 10 developers for one month). Based on the experience provided by the knowledge base, the subject of the process analyzes that four subtasks are required to achieve the goal: requirements, analysis, implementation, and testing; , analysis and implementation as their own tasks, and release the tests that cannot be completed by themselves as negotiation goals B to other process subjects in the system. All process subjects receiving the negotiation target B repeat the same steps as process subject a, assuming that process subject b splits the test task into two parts: unit test and integration test, and judges that it can only complete the integration test task, then publish another task. At this time, assuming that process subject c accepts the task and gives certain feedback information, process subjects b and c negotiate and reach an agreement on the attributes of the task, such as the workload and quality of the task. During the negotiation process, the process subjects make decisions according to their respective rule bases. After the process subjects b and c reach a consensus, b sends a message to a to confirm the acceptance of the task, and then b and a negotiate on the attributes of the test task.

For each process subject, it must first establish an executable negotiation model, and then participate in the negotiation. The negotiation model includes three basic elements and two control elements, the two control elements are general agreement and negotiation rules. The three basic elements are: a set of subjects that may participate in the negotiation, a set of negotiation primitives, and a collaboration contract template. The set of negotiation primitives is used for discourse communication between process subjects, and is controlled by a general protocol. As a static control of information flow, the general protocol can support most forms of negotiation processes of process subjects. Collaboration contract template is a way to organize negotiation goals for the fixed negotiation goals and the number of negotiation goals in the traditional model. The contract template includes negotiation goals and negotiation parameters, which are controlled by negotiation rules. The negotiation process of the process subject is the process subject Some parameters in the contract template alternately send their own approved parameter values until the negotiation participants agree on these parameter values. Because the negotiation participants have a consistent understanding of the structure and content, when the negotiation object is added at runtime, the process subject can know and handle this passively added negotiation object. This provides users with greater negotiation flexibility.

As shown in Figure 3, after the negotiation model is established, the specific steps for the process subject to participate in the negotiation include:

1. Process the received messages in sequence, check the legitimacy of the messages, and transmit the messages to the state converter;

2. After the state converter receives the message, it converts the state of the process subject according to the state transition function;

3. After the state of the process subject changes, its subsequent behavior depends on the negotiation rules. Therefore, at this time, the rule trigger triggers the negotiation rule engine, and transmits the information required by the negotiation rule engine to the rule event manager, which is triggered by the event manager data loader;

4. The data loader loads the negotiation rules and related data for the reasoning of the rule matcher;

5. The rule matcher matches the data with the negotiation rules according to the agreed algorithm, and the matched rules enter the rule matching queue;

6. The rule matching queue manager receives the rules generated by the rule matcher, sorts them, detects and resolves conflicts, and submits the processed rules to the rule executor for execution;

7. The rule executor sequentially executes the rules to match the rules passed by the queue manager, generates new data, and submits the results to the negotiation process engine.

Correspondingly, the software process body in the auto-negotiation system includes the following functional modules:

Negotiation rule editor, used to edit and manage negotiation rules, including control rules and decision rules, display the analysis results of negotiation rules, and prompt users to deal with rule conflicts;

The negotiation model analyzer is used to check the correctness and rationality of the negotiation model formed by the negotiation rules defined by the negotiation rule editor and the general agreement;

The negotiation rule engine is used to reason the negotiation rules, and return the result to the negotiation process engine according to the parameter value given when the negotiation process engine is invoked, so as to realize the control and decision-making of the negotiation process;

The negotiation process engine is used to drive the executable negotiation process model, including the call to the negotiation rule engine; it is equivalent to a workflow engine, which analyzes all the activities of the negotiation process according to the general negotiation protocol, and triggers the negotiation by calling the negotiation rule engine regular activities;

Negotiation rule library, used to store negotiation rules, including process control rules and decision rules;

The negotiation process library is used to store the message flow data generated during the negotiation process, mainly including the process subject of each interaction, the negotiation primitives sent, the cooperation contract, and the sending time.

Among them, the negotiation process engine module also includes: a message processor, used to receive and send messages, and check the validity of the received messages; a state converter, used to control the state transition of the process subject, and the control follows the general protocol GProtocol; rule trigger, used to trigger the negotiation rule engine. The negotiation rule engine module also includes: a rule event manager, which is used to respond to the trigger event of the negotiation process engine to the rule engine; a data loader, which is used to load the negotiation rules and related data; a rule matcher, which is used to combine the data with the negotiation Match the rules; the rule matching queue manager is used to receive the instantiated data queue generated by the rule matcher, perform conflict detection and resolution, and submit it to the negotiation process engine; the rule executor is used to execute the negotiation rules, and execute the rule matching queue in turn The rules passed by the manager generate new data and submit the results to the negotiation process engine.

The technical effects of the present invention are: (1) The traditional negotiation protocol is divided into two parts: a general protocol and rules. The common protocol is static and can support various forms of negotiation process. The rules are changing, bringing flexibility and variability to the negotiation agreement; (2) Expressing the decision-making strategy as a rule, so that the decision-making strategy can be determined and modified to adapt to changes in environmental conditions and other influencing factors; (3) Negotiation Objectives are organized in the form of structured collaboration contracts, which can be added dynamically; (4) Negotiation rules are stored and evolved independently, and interact with other parts of the model in a low-coupling manner, thereby providing a low-cost support for the software process agent. Negotiation provides flexibility and dynamism.

Description of drawings

Figure 1 is the general protocol in the rule-based software process negotiation model;

Fig. 2 is a schematic diagram of the framework of the system;

Fig. 3 is a schematic diagram of the execution steps of the negotiation process and the detailed structure of the main functional modules of the system.

Detailed ways

The present invention will be further described through preferred specific embodiments below in conjunction with the accompanying drawings, but this does not constitute a limitation to the present invention.

Taking the negotiation process between enterprises on software outsourcing projects as an example, the process of enterprise negotiation on software outsourcing projects is generally as follows: an enterprise that needs to outsource a certain software project sends a negotiation request to other enterprises, and the responding enterprise establishes a negotiation agreement with it. After establishing a relationship, they start to negotiate on the negotiation parameter values that they care about until they reach an agreement on these values, thus establishing a cooperative relationship with each other.

First of all, the software process subject auto-negotiation system is established. All enterprises participating in the negotiation are modeled as software process subjects and interconnected into an auto-negotiation system. Each process subject has a unique identifier in the system. As shown in Figure 2, the basic functional modules of the process body include: a negotiation rule editor, a negotiation model analyzer, a negotiation rule engine and its own negotiation rule library, a negotiation process engine and its own negotiation process library, and a tool for publishing Web server for messages. Among them, the negotiation rule editor and the negotiation model analyzer are located on the access interface visible to the user.

The second is to establish an executable negotiation process model. Each process subject can define and modify negotiation rules based on its own knowledge and ability; the knowledge and ability can include: organizational capabilities (such as the ability to undertake certain types of projects), individual Capabilities (such as coding capabilities), resources (time resources), etc.; the editing and management functions of negotiation rules are implemented by the negotiation rule editor, and the negotiation rules are stored in the negotiation rule library. Negotiation rules include control rules and decision rules. Control rules can be defined by the negotiation initiator, such as: the timeout period of the negotiation process, the timeout period of the reply, the conditions under which the negotiation is terminated normally, and the conditions under which it is terminated unexpectedly. The decision-making rules can be customized by the negotiation participants, for example: under what conditions accept the parameter value proposed by the other party, under what conditions reject it, under what conditions modify the parameter value proposed by the other party and how to determine the new parameter value proposed by the other party, etc. After the negotiation rules are defined, it is necessary to analyze the legality of the negotiation rules. After the analysis is correct, the negotiation rules are output to the negotiation process engine and the negotiation rule engine.

The basic elements of the negotiation model are governed by general protocols and negotiation rules to carry out the negotiation process. The general protocol is named GProtocol, which is a static and immutable control part of the negotiation process, and its versatility enables it to support most forms of negotiation processes of the process subject. The general protocol is represented by a state transition diagram, as shown in Figure 1, wherein:

(1) GProtocol contains 5 states, and the state set is represented by S, S={Start, S ₁ , S ₂ , S ₃ , End}, wherein, the state Start is the initial state, the state End is the end state, and the states S1 and S2 , S3 are three intermediate states;

(2) GProtocol contains 9 state transitions:

The state transition (1) in the figure shows that: the negotiation initiator proposes a negotiation request;

The state transition (2) in the figure shows that: the negotiation initiator initiates another negotiation request, and has not yet received a reply from other agents to its last negotiation request;

State transition (3) in the figure shows: the agent receiving the message accepts the negotiation request;

State transition (4) in the figure shows: the agent that receives the message rejects the negotiation request;

The state transition (5) in the figure shows that: the negotiation process ends, if the time limit is reached, or the agent participating in the negotiation terminates the process;

The state transition (6) in the figure shows that: the initiator of the negotiation proposes an initial cooperation contract;

The state transition (7) in the figure shows that: the negotiating parties alternately send cooperation contracts, and can add, modify or reject the negotiation target value;

The state transition (8) in the figure shows that: the negotiation process ends, if the time limit is reached, or the agent participating in the negotiation terminates the process;

The state transition (9) in the figure shows that: the negotiation process ends, and if the time limit is reached, the agent accepts the content of the cooperation contract, or the agent terminates the process.

The negotiation rule is named NR, which is a dynamic control and decision-making part of the negotiation process. Negotiation rules are divided into control rules (CR) and decision rules (DR). Both rules are defined based on Horn clauses. The Horn clause consists of two parts: the condition part and the conclusion part. The condition part contains multiple Horn atoms, and the conclusion part only allows one Horn atom. A negotiation rule states that the conclusion is true when all conditions are true. The control rule is responsible for the common control of the negotiation process message flow, and the main difference from the general protocol GProtocol is that it can be changed or adjusted with changes in the environment, goals and other factors. It is usually public to all negotiation participants. Decision rules are used to determine (mostly privately) sent negotiation primitives and collaboration contracts containing negotiated target values, usually privately and invisible to the negotiating counterparts.

The execution of the negotiation model is similar to the execution of the finite state machine, including the following steps:

Step 1: Build a state transition algorithm: s×NPrim→s, the specific state transition algorithm is determined by the general protocol GProtocol, as shown in Figure 1;

Step 2: Construct message flow set MF, $\mathrm{MF}=$ $\underset{i}{\mathrm{\Σ}}{\mathrm{mf}}_i,$ mf _i is a message flow, which is a message sent by one subject participating in the negotiation to another. A message flow mf _i consists of the following elements:

(1) The subject of the message;

(2) The subject receiving the message;

(3) The negotiation primitive to be sent;

(4) Collaboration contract sent;

(5) The time point at which primitives and collaboration contracts are sent.

Step 3: Construct the negotiation history H, H={h ₁ , h ₂ ,...,h _n }, h _i is a subset of MF, reflecting all message flows sent and received by the subject;

Step 4: Construct knowledge K, K consists of some knowledge about the software process, such as environmental knowledge, organizational or personal ability (such as coding ability), etc.;

Step 5: Construct a finite input set I: I=NPrim×CC×H×K;

Step 6: Construct a finite output set: Out=NPrim×CC;

Step 7: Construct the state transition function GProtocol: S×NPrim→S;

Step 8: Construct the output function OF: I→Out, wherein, OF has two sub-functions: CR: I→Out and DR: I→Out.

The final output of OF is CR(I)∩DR(I)(≠).

At any point in time, a negotiating agent of a negotiating process is in a state in the set S. When it receives a primitive, it is transferred to another state under the control of the general protocol GProtocol (see Figure 1). Further, following OF, it outputs a negotiation primitive and a cooperation contract, wherein the sub-functions CR and DR are control rules and decision rules.

After the negotiation rules are defined, the correct and reasonable negotiation rules analyzed by the negotiation model analyzer are loaded into the negotiation process engine as a data source, and a negotiation process starts.

Negotiation process discourse communication between process subjects adopts negotiation primitives, which are implemented in the form of messages, and the types of messages are consistent with the names of negotiation primitives. The set of negotiation primitives is named NPrim: NPrim={Propose_N, Accept_N, Reject_N, Terminate_N, Propose_CC, Accept_CC, Reject_CC, Modify_CC}, wherein the meanings of each primitive are as follows: Propose_N means to propose a negotiation request, and Accept_N means to accept A negotiation request, Reject_N means rejecting a negotiation request, Propose_CC means sending a collaboration contract, Accept_CC means accepting the currently received collaboration contract CC (no modification), Reject_CC means rejecting the currently received collaboration contract, Modify_CC means modifying received Collaboration contract, Terminate_N means to terminate the current negotiation process. The analysis and processing of negotiation primitives are implemented in the message processor in the negotiation process engine.

During the negotiation process, all process subjects negotiate based on the same collaboration contract template, which is implemented in XML (Web Markup Language) documents and defines the corresponding XML Schema; the analysis and processing of the collaboration contract template is implemented in Message handler in the negotiation process engine. The collaboration contract template is the negotiation target, that is, the organizational form of the negotiation parameters. The collaboration contract template is named CC and contains the following contents:

(1) Contract type: describe the type of contract, such as inter-enterprise outsourcing, project task assignment, etc.;

(2) Contract description: used to explain the main content of the contract, such as "J2EE" indicates that the contract is about a J2EE project;

(3) Negotiation parameter set: The negotiation parameters indicate the specific negotiation content that the negotiation participants are interested in, such as the number of man-months required for the project, code quality; the negotiation parameter set as a whole reflects the common understanding of the negotiation participants on the negotiation content of interest ;

(4) Negotiation parameter value set: the negotiation parameter value is the value corresponding to the negotiation parameter; the negotiation parameter value set indicates the value range of the negotiation parameter;

(5) Negotiation target category set: The negotiation target category is used to indicate whether a negotiation target is negotiable, N indicates that it is negotiable, and NN indicates that it is not negotiable.

After specific content is added to the collaboration contract template, it becomes a collaboration contract, represented by CC. In this embodiment, the negotiation parameters include man-months required for the software outsourcing project, code quality, number of submitted documents, and the like.

As shown in Figure 3, the negotiation process engine module includes a message processor, a state transition (controller) and a rule trigger. When the negotiation starts, the message processor receives the message and the cooperation contract, and the state processor follows the state transition function GProtocol to convert the state of the process subject; the state processor then triggers the rule dispatcher, which triggers the negotiation rule engine and sends it Send parameter values, that is, messages and collaboration contracts, wait for the result to be returned and return the result to the state processor, the state processor triggers the message processor, and after the message processor sends the message successfully, the state processor changes the state of the process body and waits for the next message Processor triggers;

Negotiation rule control is implemented in the negotiation rule engine: the data loader loads the negotiation rules, knowledge (that is, facts), negotiation history, and receives the parameters passed by the rule processor of the negotiation process engine, and then the rule matcher converts the facts and parameter values Matching with the rules, the rule matching queue manager processes the matched data, and delivers the processed data to the rule trigger of the negotiation process engine.

The above process is repeated until the negotiating parties reach an agreement or the timeout expires, and the negotiation process ends.

Claims (7)

1. A software process subject auto-negotiation system, which is formed by interconnecting equal process subjects, characterized in that the process subject includes the following functional modules: The negotiation rule editor is used to edit and manage the negotiation rules, display the analysis results of the negotiation rules, and prompt the user to deal with rule conflicts; Negotiation model analyzer, used to check the correctness, enforceability and termination of the negotiation model formed by the negotiation rules defined by the negotiation rule editor and the general agreement; The negotiation rule engine is used to reason the negotiation rules analyzed by the negotiation model analyzer, and return the result to the negotiation process engine according to the parameter values given when the negotiation process engine is invoked, so as to realize the control and decision-making of the negotiation process; The negotiation process engine is equivalent to a workflow engine, which analyzes all the activities of the negotiation process according to the general negotiation protocol, and triggers activities that meet the negotiation rules by calling the negotiation rule engine; Negotiation rule library, used to store negotiation rules, including process control rules and decision rules; The negotiation process library is used to store the message flow data generated by the negotiation process. 2. The system according to claim 1, wherein the negotiation process engine module further comprises: a message processor for receiving and sending messages, and checking the validity of the received messages; state transition The controller is used for the state transition control of the process subject, and the control follows the common protocol; the rule trigger is used to trigger the negotiation rule engine. 3. The system according to claim 1, wherein said negotiation rule engine further comprises: The rule event manager is used to respond to the trigger event of the negotiation process engine to the rule engine; Data loader, used to load negotiation rules and related data; A rule matcher for matching data with negotiated rules; The rule matching queue manager is used to receive the instantiated data queue generated by the rule matcher, perform conflict detection and resolution, and submit it to the negotiation process engine; The rule executor is used to execute the negotiation rules, execute the rules in turn to match the rules passed by the queue manager, generate new data, and submit the results to the negotiation process engine. 4. The system according to claim 1, further comprising a Web server, used for the process subject to issue messages. 5. The system according to claim 1, wherein the negotiation model includes three basic elements: a set of subjects that may participate in the negotiation, a set of negotiation primitives, and a collaboration contract template. 6. A process subject automatic negotiation method, comprising the steps of: 1) Process the received messages in sequence to check the legitimacy of the messages; 2) According to the legal message, the state of the process subject is converted through the state transition function; 3) Trigger the negotiation rule engine, and load the negotiation rules and related data; 4) According to the agreed algorithm, match the data with the negotiation rules, sort them, detect and resolve conflicts; 5) Execute the processed rules, generate new data, and submit the results to the negotiation process engine. 7. The method according to claim 5, wherein said message communication adopts negotiation primitives, and said negotiation primitives stipulate the basic semantics of conversations between process subjects.

Images