the adaptive agent model n.
Skip this Video
Loading SlideShow in 5 Seconds..
The Adaptive Agent Model PowerPoint Presentation
Download Presentation
The Adaptive Agent Model

The Adaptive Agent Model

187 Vues Download Presentation
Télécharger la présentation

The Adaptive Agent Model

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  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 := 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