modelling agent knowledge with business rules liang xiao and des greer school of computer science,...

Modelling Agent Knowledge with Business Rules

Liang Xiao and Des GreerSchool of Computer Science,Queen's University Belfast,

UK

Modelling Agent Knowledge with Business Rules – L. Xiao, D.Greer, SEKE 20052

Overview• Introduction and motivation

• Agent/Rule/Class (ARC) Framework

– Rule Specification

– Structural model

– Behavioral model

• ARC Benefits

• Implementation

– Business rules

– Tool Support

• Deployment

• Related Work, Conclusions and Future Work


Software Engineers make changes

Introduction – traditional approach

SoftwareSystem

{Knowledge}

Code

Software Engineers

Requirementsmodels

DesignModels

…

E.g

. UM

L m

odel

s


Make changes

Introduction – current thinking (MDA)

SoftwareSystem

{Knowledge}

Auto-generateModels

E.g

. UM

L m

odel

s

• Models are reused


Introduction – Agent Systems

AgentSoftwareSystemtranslate

• Models are reused

BusinessRules

Make changes

CASE

tool


Belief: the agent that executes the rule updates its belief with the information received in the incoming message (business company interest, customer shopping habits, etc.)

Event: incoming request message

Processing: process the incoming message

Action: if one of the rule conditions is satisfied, then perform a corresponding action with an outgoing message

Rule

Outgoing message

a2

c1

c2

cn

Check Rule Condition (c1, c2, … , cn)

e

Message

a2

a1

an

Agent Rule Class Framework - RulesIs the rule applicable?

Decode incoming message, construct

business objects

Check condition

If ci is true, take action ai,, otherwise do (ci+1,ai+1) etc

Agent adds new knowledge


• Agent + Business Rules = agents with a higher abstraction over objects– For each task the agent has a dedicated rule

– A rule uses classes to perform the task

– Rules can invoke classes and use them

– Added feature is that the rules are configurable

• Rules can be made for agent collaboration– Partners can be changed

– Actions and reactions to rules can be changed

Agent Rule Class Framework – Rules (ii)


ARC - Structural Model• Structural Models are built through Agent

Diagrams (cf Class Diagrams in UML)

• The models show agents, business rules, business classes and their relationship

• Agents manage rules and rules manage the invocation of business classes

• Agent/Rule/Class hierarchy is established


• In OO messages are method invocations. In ARC models they are rule collaborations between agents

• One rule responsible for an agents behavior in for a particular situation.

• Rules use Business objects to do the tasks.

ARC - Structural ModelAgent Symbol

Produce the message

Process the message

constraint

navigable

association

message A

agentName1

o1:className1 o2:className2 o3:className3 ……

ruleName1 (o1, o2) ruleName2 (o2, o3) ……

className1 className2 className3

agentName2



{agentName1.ruleName1.actionMessage () equals to agentName2.ruleName3.eventMessage ()}

Structural Model

Classes/ objects managed

Rules for behaviour

Agent Name

‘association’ indicates message passing

Classes (as per UML)

Message path


ARC - Behavioural Model

• Behavioural Models are built through Agent Communication Diagrams (cf UML Sequence diagrams)

• Models show business processes using– Agents

– rules and

– messages

• Models show agent collaborations– Agents have rules

– Rule elements to form a flow of decision making, process by process

• one decision at each connection point

• Visualizes system function as sequence of agent actions dictated by rules


ARC - Structural Model

Produce the message

Process the message

constraint

navigable

association

message A

agentName1



className1 className2 className3

agentName2



{agentName1.ruleName1.actionMessage () equals to agentName2.ruleName3.eventMessage ()}

Structural Model

• Captures behavioural scenarios (cf UML Sequence diagrams)

• Rules are event driven

• Shows a sequence of actions determined by (condition, action) couplets

ruleName3

Result Receiver Rule

ruleName1

agentName2

Methods of o4, o5

1: message A

4: Response message

True valid? checkCondition i

agentName1

2:

3: Check its validity

Behavioural Model

M

M

A rule in Agent1 sends a message picked up by a rule in Agent 2

Check the incoming rule condition using methods of o4, o5

Is the condition met?Response (in this case) sent back to initiating agent


ARC Framework Benefits• Higher level of abstraction over OO

• Achieves full architecture independence (two-way encapsulation)

– i.e. details of where objects will send messages is hidden

• Agent collaboration is not hard-coded but is configurable via the ARC behaviour model diagram

• Agent Collaboration can be changed at run-time as requirements change

– Business rules sit between agents and classes

– Business rules hold the system knowledge

• Major benefit is ADAPTIVITY


event message

Agent 3

e Rule 3

Agent 2

e Rule 2Agent 1

Rule 1 action

message

c1

c2

e

Class 1 Class 2 Class 3

M

M

M

IF condition 1 THEN action 1 {call business class 1 and business class 2}, send the result to Rule 2 in Agent 2}

ELSE IF condition 2 THEN action 2 {call business class 2 and business class 3}, send the result to Rule 3 in Agent 3}

ELSE IF condition 3 THEN action 3 {……}

……• Adaptive internally – since different behaviour allowed depending on condition

• Adaptive externally –rules edited via tools


ARC Framework Benefits +• Middleware

– Suppose java classes 1/2/3 used by Agent 1

– Agent 2/3 use C++ classes

– Agent layer allows inter-operation

event message

Agent 3

e Rule 3

Agent 2

e Rule 2Agent 1

Rule 1 action

message

c1

c2

e

Class 1 Class 2 Class 3

M

M

M• Crosscutting concerns

– Some agents can be dedicated to concerns e.g. authorisation rules, logging, and so on


Illustrative Example

• Retailer serves students/staff using goods from various suppliers

• Retailer-Retailer, Customer-Retailer, Retailer-Supplier… relationships can change at any time

• Business classes already developed but new versions can be added later

• Decision making in order processing must be flexible

• E.g retailers may accept and order, reject it or forward it depending on different conditions

Customer Agent

Retailer Agent

Company Agent

isOrderAttractive ()

isProposalSatisfactory ()

Call for proposal R2

R4

R1

R3 Propose

Accept proposal

Acknowledge Acknowledge

Place an order

• Agent collaborations in UML diagrams used to generate the inter-agent part of the rules definition, in XML

• Via these rules agent systems are adapted both in collaborations and internally without re-code or regeneration.

Behavioural Model for Illustrative Example


Business Rule definition in XML (context)

• A rule named “saleProcessing” is defined as a rule that controls the behaviour of “CompanyAgent” while the agent participates in the “retailer business” process.


Rule definition (data)

• Business classes “Order” and “Proposal” will be used by the rule “saleProcessing” with their instantiation “order” and “proposal”.


Rule definition (event)

• The rule will fire if its owner agent receives a “Call for proposal” message from the “RetailerAgent”.


Rule definition (processing and condition)

• Construct an “order” object using the information contained in the incoming message.

• Check if isOrderAttractive () method of the created object returns TRUE.


Rule definition in XML (action section)

• If TRUE, then generate a “proposal” object (including price for the order, order dispatch time, etc) using the constructed “order”, encode it into a message and send it to “RetailerAgent”.


Business Rule Processing

• XML stores data to complement the ARC (UML) model

• Each agent– Gets a list of its own managed rules (via <owner-agent> tag

– Filters these using <business-process>

– Gets highest priority rule using <priority>

– Checks applicability of that rule using <event> (i.e. Inside <message><from>)

– If applicable – decode the message and build required objects

– Check <condition>

– If TRUE, perform <action>



1. Get a list of its managed rules using <owner-agent> section.

2. Filter rules - retain applicable ones as per current business process using <business-process> section.

3. Get rule with highest priority using <priority>

4. Check the applicability of rule using <event> – In other words, check the <from> section of the <message> in

<event> matches triggering agent etc. If that is not the case, remove rule from set and go to step 3).

5. Decode the message received and build business objects from it following the <processing> instructions.

– Constructor methods of existing classes will be involved. – Global variables declared in the <global-variable> section will be

used to save the results.



6. Check current condition satisfied using <condition> • Constructed business objects involved, and their methods invoked

to assist. If not satisfied go to Step 9.

7. Execute <action> section. • involves encoding constructed business objects that refer to

<global-variable> into a message.

• Send the message to the agent which is specified in the <to> section of the <message> in <action>.

8. Analyse the business object which has been decoded from the message received and update the agent’s beliefs with the new information available.

9. Remove this selected rule from the rules set obtained in Step 2 and if not the last rule, go to Step 3.

10. Wait for the next event.


Illustration of model adaptivity

• Example 1 – new Business class ‘Order’ replaced by ‘NewOrder’ with a new isOrderAttractive() method– Only need to edit some xml (via tool)

– Intra Agent adaptivity

• Example 2 – different collaborations may be required• An order is attractive, so the company agent returns a

proposal with price, delivery time etc to the retailer agent• But if the customer has bad credit, the company agetn may

reject the proposal• Alternatively, the retailer may forward it to other company

agents for a better price

– Using <action>…<message>…<to> tags the destiantion can be easily changed in XML (or via tool)

– Inter Agent adaptivity


Tool Support


Tool Support• UML style diagrams are good at

showing collaborations among agents

• XML shows precise definition of agent behaviors

Rules can be defined either in XML text or using a more user-friendly tree structure in the left panel of the tool

• XML code is finally generated from the completed tree structure and saved in a rules document


Implementation and deployment• Agent systems are automatically generated

such that each rule maps to an agent behavior

• XML-based rules are plugged in and are subsequently translated by agents at run-time

• While the system is running, rules can be updated through the tool, so that agent behaviors are continuously updated


Agent behaviour pseudo code (R2)

if (order. isOrderAttractive ()) { /* the condition of the rule is satisfied */ proposal = order. createProposal (); Message m2 = new Message (); m2. setContentObject (proposal); Agent toAgent = thisRule. getAction ().getMessage (). getToAgent (); m2. addReceiverAgent (toAgent); thisAgent. send (m2); /* update this agent’s beliefs */ thisAgent. addBelief (System. getCurrentTime (), fromAgent, m); } } m = thisAgent. receiveMessage ();}}

thisAgent. addBehaviour (Rule thisRule) {thisBehaviour. setPriority (thisRule. getPriority ());Order order;Proposal proposal;

Message m = thisAgent. receiveMessage ();

while (m != null) { Agent fromAgent = m. getSenderAgent (); if (fromAgent. equals (thisRule. getEvent (). getMessage ().

getFromAgent())) { /* the rule is applicable to the received message */ BusinessInfo businessInfo = (BusinessInfo) m.getContentObject (); order = new Order (businessInfo);

• Provided by “Rule” code – gets the xml values


Deployment of agent systems (ARC)

ARC model maintenance (Event, Processing, Condition, Action, Priority)

XML-based Business Rule Repository

JavaBeans: XML↔Java Obj converter

Business Knowledge Model

Up-to-date rules from repository get applied at run-time

Agent Model

A

A

A

A

JADE platform

Initial generation

Supporting tool

Agent system generated initially

System runs using Jade, reading XML rules

XML repository updated immediately

Rules updated via tool

ARC models specified along with XML rules


• Alternative approaches to Adaptivity

– Strategy Design Pattern

– Coordination Contract

– Adaptive Object Model

• Why ARC approach

– All of the above are OO

– Agents are by definition ‘active’

– Agents now proven technology

– ARC uses business rules – original objects kept intact

– ARC allows agents to change the way they use the object and also to change the agent collaboration

Related Work


Conclusion• Building agent systems on top of OO systems using the ARC

framework achieves adaptivity

i) by configuring host system components collaboration

ii) Inter-operability is achieved by enabling the collaboration between cross platform components that are written in different languages, in a distributed environment.

iii) Easy maintenance is facilitated by separating crosscutting concerns in dedicated agents.

• Benefits of the OO paradigm are not abandoned

• Features of CORBA and aspect-oriented programming can be introduced via an agent layer coupled with knowledge in business rules.

• The ARC framework will be made more powerful, but work so far indicates that it assists the achievement of adaptivity in systems.

modelling agent knowledge with business rules liang xiao and des greer school of computer science,...

Documents

modelling agent knowledge

uml models models

business rules liang

future work slide

overview introduction

queens university belfast