The Adaptive Agent Model

1. The Adaptive Agent Model Liang Xiao and Des Greer School of Computer Science, Queen's University Belfast, Northern Ireland, UK Software Adaptivity through Dynamic Agents and XML-based Business Rules

2. Background Example Adapting Business Policy Adapting Business Concepts Adapting Business Collaboration Overview Motivation Other Approaches Our Approach Conclusions

3. Motivation • Software maintenance is very expensive • Much of Software Engineering research into making systems easily and economically adaptable • Need to make change easier and cheaper! • Better still is adaptive • Systems change their behaviour according to their context • Combining OO with Agent approach may provide a route to adaptivity

4. Use of design pattern e.g. Strategy Predict future behaviour and write code for it Later select new behaviour Relies on being able to predict behaviour Co-ordination Contract – externalise coordination as contracts Evolve by adding/changing contracts Components still have to be recoded if functionality cannot be achieved via contracts Selected approaches to Adaptivity (i)

5. Selected approaches to Adaptivity (ii) • Adaptive (Active) Object Model (AOM) • Model system as metadata • TypeObject, Property and Strategy patterns • Create new classes at runtime • Behaviour can be adapted if predicted • BUT • Persistence of new objects requires object database • Hard coded classes do not represent business model • Adaptivity only if future behaviour has been predicted • No easily accessible of the ACTUAL system model

6. Selected approaches to Adaptivity (iii) • Main concerns are cost and time for maintenance • Cheapest (ideal) solution is self-adaptivity • Objects are passive • Need new approach to move responsibility for change towards the user

7. What’s important? • Important in OO: modularity, information hiding … • These refer to easy redesign NOT adaptation during operation • Much attention on intelligent/autonomous agents for adaptivity • Agents capable of flexible, autonomous action to meet their own objectives

8. Why Agents and Business Rules? • Our Hypotheses: • system consisting of agents, where the behaviour can be configured dynamically as policies or rules will provide better adaptivity • Agents are active , unlike objects • Objects have static methods, agents have flexibility • Requirements embedded in code are not easily adapted • Rules can be externalised (as XML) and used by agents • Externalisation means ease of change

9. Illustrative Example • Retailer serves students/staff • Policies include certain discounts • e.g. individual students/groups/departments • Customers can become ‘premium’ • Goods ordered have different suppliers and discount may depend on that too • Policies added/amended constantly • Suppose a new attribute ‘credit’ is added later and new policies arise based on the value of that

10. Simple example – change issues • 3 categories of change • New business policy e.g. new discount for a certain group • New business concepts e.g ‘credit’ • New business architecture/ collaboratione.g. change to new supplier • How can we allow these to be changed?

11. Adapting Business Policy • Business policies represented as rules • Business rules traditionally often embedded in code / logic • 2 categories • Global = apply to whole business domain. These refer to business policy • ( Local = apply to individual agents and refer to how they collaborate)

12. Adapting business policy (ii) • We use a simple template for global rules IF objectName1.attribute1 op1 value1THEN objectName2.attribute2 op2 value 2Priority value3 -<rule> <id> ruleId </id> <condition> objectName1.attributeName1 op1 value1 </condition> <action> objectName2.attributeName2 op2 value2 </action> <priority> value3</priority> </rule>

13. Adapting business policy (iii) IF customer.type == premium THEN customer.discount := 5% Priority 5

14. Adapting business policy (iii) • Business Rules Manager Agent (BRMA) oversees the process • BRMA gets top-priority rule • Message sent to initialising agent for context (i.e. <condition> • TRUE: <action. Executed • FALSE: move to next rule

15. Adapting Business Concepts • <object> <name>customer</name> - <attributes> <attribute>name</attribute> <attribute>type</attribute> <!-- … more attributes … --> <attribute>credit</attribute> </attributes> <behaviour/> </object> • New objects, new attributes may arise • Metadata Editor allows these to be added

16. Adapting Business Concepts (ii) • New attribute becomes available to business rules editor

17. Adapting Collaboration • Agent systems work via collaboration of agents • For AAM collaboration should be adaptive • Full architecture independence (two-way encapsulation) is the ideal case • i.e. details of where objects will send messages is hidden • Architecture Editor defines local rules • Adjusts who ‘talks’ to who and what happens when

18. - <event> <type>receipt of message</type> - <message> <from>Retailer.orderProcessing</from> <to>Company.saleProcessing</to> <title>Call for proposal</title>- <content> … </content> </message> </event> <condition> order.isOrderAttractive() = true </condition> Adapting Collaboration (ii) - <local-rule> <name>saleProcessing</name> <business-process>retailer business</business-process> <owner-agent>Company</owner-agent> - <action> <type>send a message</type> - <message> <from>Company.saleProcessing</from> <to>Retailer.proposalProcessing</to> <title>Propose</title> - <content> …</content> </message> </action> <priority>5</priority>

19. Adapting Collaboration(iii) • Rule definitions contain • Causing trigger event • The data content of the message being received • A series of (condition, action, priority) triplets • When an event occurs (usually receipt of a message) • The agent looks at its local rule set and chooses which action to take • Collaboration is dynamic • Via the Architecture editor rules are changed and saved as XML and used immediately

20. Rule Specification Event:  incoming request message M essage Processing:  process the incoming message  Action:  i f one of the e Belief: a rule condition s is the agent that 2 satisfied, then perform executes the rule Rule a corre sponding action updates its belief with with an outgoing the information message received in the c incoming message 1 a Check Rule Condition  1 (business company interest, customer (c , c , … , c ) c 1 2 n 2 shopping habits, etc.) c n a 2 Outgoing m essage a n

21. Evaluation

22. Conclusion • Agents retrieve knowledge from business rules • New business concepts (Metadata editor) • Change of business policy (Business Rules Editor) • Change of business architectures (Architecture editor) • Adaptivity achieved since the editors define the environment and the system reacts

23. Future vision • Some Possibilities • Priorities of rules are learned • Alternative paths are taken as required