Modeling , Auto-generation and Adaptation of Multi-Agent Systems

1. Modeling, Auto-generation and Adaptation ofMulti-Agent Systems Liang Xiao and Des Greer School of Computer Science, Queen's University Belfast, UK June 2005

2. Overview • Introduction and motivation • Related Work • The Adaptive Agent Model • Structural model • Behavioral model • Tool Support • Implementation and deployment • Adaptation • Conclusion and future work

3. Introduction and motivation Agent-oriented systems • Agents are active as opposed to passive objects. • Agents must have dynamic behaviors and be adaptable. • Existing agent platforms, like JADE, require to code agent behavior in fixed class methods. • It is lack of uniformity in developing agent-oriented systems. • Maintenance cost of such systems is high.

4. Related work • Agent Patterns - better code encapsulation and reuse, but the chance that a pattern can be reused without change is low. • Extensible Agent Behavior Specification Language (XABSL) – good at specifying individual agent behavior, but not sufficient for expressing inter-agent collaboration. • Agent Behavior Representation Language (ABRL) – a convenient way to compose agent behaviors visually, but no assistance on the overall system modeling, and no agent system generation capability.

5. Solution – The Adaptive Agent Model (AAM) • Our approach of AAM generates agent systems from models. • AAM uses UML diagrams to model agent interactions and XML-based business rules to encode agent behaviors. • Business customers are empowered to configure the models at run-time using a provided tool. • Agent systems are easily maintained since AAM continuously reflects new requirements in customer revised models.

6. Structural Model • Structural Models are built through Agent Diagrams – the counterpart of Class Diagrams in OO models. • 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.

7. Asample Agent Diagram for case study • Agent interactions are modeled as message passing between them. • One rule is responsible for the behavior of an agent in dealing with a particular situation. • Business objects are used by rules to do the tasks.

8. Behavioral Model • Behavioral Models are based on Structural Models, and built through Agent Communication Diagrams. • The models organize agents, rules and messages around business processes. • UML is used to model agent collaborations. Rule elements in UML are connected to form a flow of decision making, process by process, one decision being made at each connection point. • The models visualize the actual system function in a sequence of agent actions dictated by rules.

9. Asample Agent Communication Diagram for case study User specified agent collaborations in UML diagrams are used to generate the inter-agent part of the rules definition, in XML format. It is through these rules that agent systems are adapted both in collaborations and internally without re-code or regeneration.

10. ① Event:“Call for proposal” message received from RetailerAgent Condition:check this “order” object of its attractiveness ③ Processing:construct a new “order” object from the message ② order. isOrderAttractive () Sale Processing ⑤ Action:If the order is attractive, create a “proposal” object for the order,encode it into a message and send the message to RetailerAgent ④ Belief:RetailerAgent has placed an order at this moment M M Elements of rule • A rule defines that on receipt of an event (normally modeled as a message), how an agent would act on it if the condition of the rule is satisfied. • Note that to make full use of a rule, multiple {condition, action} pairs can be used, so that, in different conditions, agents can take different actions.

11. Rule definition in XML (identification section) • A rule named “saleProcessing” is defined as a rule that controls the behavior of “CompanyAgent” while the agent participates in the “retailer business” process.

12. Rule definition in XML (business object section) • Business classes “Order” and “Proposal” will be used by the rule “saleProcessing” with their instantiation “order” and “proposal”.

13. Rule definition in XML (event section) • The rule will fire if its owner agent receives a “Call for proposal” message from the “RetailerAgent”.

14. Rule definition in XML (processing and condition section) • Construct an “order” object using the information contained in the incoming message. • Check if isOrderAttractive () method of the created object returns TRUE.

15. 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”.

16. AAM Tool Support • UML diagrams are good at showing collaborations among agents, while XML rules are good at precise definition of agent behaviors. • An AAM CASE tool is developed for the specification of agent communication models in UML and rule definitions in XML. • Rules can be defined either in XML text or using a more user-friendly tree structure in the left panel of the tool. • Part of the <event> and <action> sections of rules can be generated when incoming/outgoing messages are specified in the tool and, <processing>, <condition> and <priority> sections are given afterwards by users. • XML code is eventually generated from the completed tree structure and saved in a rules document.

18. Implementation and deployment • Once business processes are specified graphically in the tool, agent interaction models, rule reaction patterns and message flows are established accordingly. • 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.

19. Pseudo code of one agent behavior transformed from a rule • All agents access a central XML-based rules document via a parsing package. • A shared module called “Rule” is used by all behaviors with its ability to access the XML definition of rules and assemble corresponding objects. • The methods getPriority(), getEvent(), and getAction() are provided by “Rule”.

21. Adaptation • Inter-agent collaboration • Intra-agent behavior • Agent vocabularies

22. Adaptation- inter-agent collaboration level • At inter-agent collaboration level, agent behaviors are guided by rules so that they do not need to know who they will contact in advance. • Change <event>/<message>/<from> and <action>/<message>/<to> sections allows agents in the running system have their partners changed in order to accomplish the updated business processes. • Suppose now we wish to introduce a new occasion where if the current “CompanyAgent” can not fulfill the order request, it forwards the order to another “CompanyAgent”. • This new agent communication partnership can thus be established by adding another {condition, action} pair. • The achievement of this dynamic collaboration is through painless model adjustment rather than expensive code change.

23. Adaptation – Intra-agent behavior level • At intra-agent behavior level, configure rules to invoke other class methods allow agents to take different actions or use different condition evaluation methods. • By change the <event>, <processing>, <condition>, and <action> fields, alternative methods of the managed business objects can be selected for invocation. • The rule “saleProcessing” can be re-configured to invoke a new evaluation method of the “Order” class or even a method of a new “Order” class to check the attractiveness of the order. • It can also be re-configured with two pairs of {condition, action}, so that for ordinary customers and company customers, different ways to generate sale proposals can be used.

24. Adaptation – agent vocabularies • Only business concepts registered through the tool and saved in the rules document may appear in agent messages. • A new business class with attributes will be generated by the tool once a new business concept with its properties is registered with the tool. • New vocabularies can become available for the specification of agent rules through the tree structure on the left panel of the tool. • At run-time these new classes with new methods can become available for invocation by the running agent system. • All agents will be able to understand the new vocabularies the other agents in the system are using even those registered after the system has been running for a while.

25. Conclusion • In Adaptive Agent Model, agent behaviors are modeled and externalized as rules, and represented in UML diagrams. • They are centrally managed and easy to be changed through the models or the XML-based definitions. • Because rules are easy to edit, deploying new requirements requires minimal effort. • The rules are, in effect, executable requirements.

26. Future work • In the future, we expect to achieve self-adaptivity in the AAM where, as agents interact with end users they perceive their behaviors and preferences. • This allows agents to update their beliefs, and so deduce rules that can be added to the central rules document. • These inferred rules can be shared and executed by all agents and are subject to amendment. • After some time, a mature and reliable rule set, independent of those acquired through the tool can be established.

27. Future vision

28. Questions?