Design of Multi-Agent Systems

Design of Multi-Agent Systems • Teacher • Bart Verheij • Student assistants • Albert Hankel • Elske van der Vaart • Web site • http://www.ai.rug.nl/~verheij/teaching/dmas/ • (Nestor contains a link)

Overview • When is an agent-based solution appropriate? • Agent-oriented analysis and design techniques • Pitfalls of agent development • Mobile agents • Open issues

When is an agent-based solution appropriate? • When the environment is open, dynamic, uncertain, complex • When agents are a natural metaphor • When data, control or expertise are distributed • In case of legacy systems Legacy: technologically obsolete, but functionally essential software

Agent-oriented analysis and design techniques • Goal: • To assist in understanding a system • To assist in designing a system Techniques consist of models and guidelines Kinds: • Inspired by object-oriented development methodologies • Adapted from knowledge engineering or other techniques

AAII Methodology • Australian AI Institute (1990s) • Based on object-oriented methodologies • Aimed at the construction of a set of models which define an agent system specification

Models External model Internal model Intentions Agent model Interaction model Beliefs Desires Agent instance model Agent class model AAII Methodology

AAII Methodology • Identify roles in the application domain and from there develop an agent class hierarchy • Identify the responsibilities, the services needed and provided by each role and determine the goals of each service • Determine plans that can be used to achieve goals and context conditions for the plans • Determine the belief structure of the system, i.e., the information requirements for each plan and goal

Gaia • Gaia’s goal is to allow a systematical route from system requirements to a detailed design that can be implemented directly • A system is analyzed as an organization, which is viewed as a collection of interrelated roles. • A role is defined by its responsibilities, permissions, activities, and protocols. • Responsibilities determine system functionality and can be divided in liveness and safety properties. Something good happens vs. nothing bad happens

Agent UML • Based on the Unified Modelling Language (UML) for object-oriented modelling. The associated methodology is called Rational Unified Process • Agent modifications: • Expression of concurrent interaction threads • Roles To allow that agents can play several roles

Desire • Framework for the design and formal specification of compositional systems • Specifies a graphical notation • Support tools, such as a graphical editor

Cassiopeia • Bottom-up: start with required behaviors • Steps: • Identify elementary behaviors • Identify relationships between elementary behaviors • Identify organizational behaviors of the system, e.g., group formation

Agents in Z • An agent specification framework • Entities with attributes • Objects: entities with capabilities • Agents: objects with goals • Autonomous agents: agents with motivations • Emphasizes agents acting for one another instead of agents as rational systems

Agent-oriented analysis and design techniques • Dominant technique: adapt object-oriented approaches • Disadvantages: • Decomposition in objects at odds with decomposition in agents • Many aspects of agent systems are not allowed in object-oriented methodologies (By the way: where is the environment?)

Pitfalls of agent development • You oversell agents • Agents are not magic! • If you can’t do it with ordinary software, you probably can’t do it with agents • You get religious • Agents are not a universal solution • You don’t know why you want agents • Agents = new technology = lots of hype!

Pitfalls of agent development • You want generic solutions to 1-off problems • Occurs in many software projects • Specific solution may be best • You confuse prototypes with systems • Prototypes are easy, field tested production systems are hard • You believe agents are a silver bullet • “Silver bullet”: an order of magnitude improvement in software development • Good reasons to believe that agents are useful way of tackling some problems, but these arguments are largely untested in practice

Pitfalls of agent development • You forget it’s software • Developing any agent system is essentially experimentation. No tried and trusted techniques • Mundane software engineering (requirements analysis, specification, design, verification, testing) is forgotten • You forget it’s distributed • Distributed systems = one of the most complex classes of computer system to design and implement • Typical multi-agent system will be more complex than a typical distributed system • Make use of DS expertise • You don’t exploit concurrency • If you don’t exploit concurrency, why have an agent solution?

Pitfalls of agent development • You want your own architecture • Great temptation to imagine you need your own • Driving forces behind this belief: • “not designed here” mindset • intellectual property • But architecture development takes years and has no clear payback • You use too much AI • Temptation to focus on the AI aspects of the application • Fuelled by “feature envy”, where one reads about agents that have the ability to learn, plan, talk, sing, dance… • You see agents everywhere • Don’t call your on-off switch an agent! • Agents for addition, subtraction,…

Pitfalls of agent development • You use too many agents • More than 10 agents = big system • Large number of agents: • emergent functionality • chaotic behavior • Lessons: • keep interactions to a minimum • keep protocols simple • You use too few agents • Fails software engineering test of cohesion: software modules have a single coherent function • You want to implement your own infrastructure • By the time this is developed, project resources gone!

Pitfalls of agent development • Your system is anarchic • Most agent systems require system-level engineering • For large systems, or for systems in which the society is supposed to act with some commonality of purpose, this is particularly true • Organization structure (even in the form of formal communication channels) is essential

Mobile agents • Mobile agents can transmit themselves

Mobile agents • Why mobile agents? • Low-bandwidth networks (hand-held PDAs) • Efficient use of network resources • Issues • Serialization (what is sent over the network? The agent program? Its data? Both? In what form?) • Hosting and remote execution • Security for hosts and agents • Heterogeneity of hosts

Telescript • Commercial language-based environment for constructing multi-agent systems • Aim: palm-tops • Main concepts: places and agents

Telescript • Tickets specify a journey: • The journey’s destination • The journey’s completion time • Communication between agents: • Across a network • Meeting • Agents have a permit and resources, such as ‘money’, lifetime, size

Telescript • Agents and places are executed by a Java-style virtual machine • Object-oriented language • Interpreted, not compiled • Two language levels: high (what programmers see)/low (for efficient execution) • Persistent: execution continues after switching a system off and on

Aglets • Java-based mobile agents platform • Some important methods of the Aglet class: • onCreation() • run() • dispatch() e.g., this.dispatch(new URL("atp://some.host.com/context1")); Contexts are ‘hosts’ for agents Agent Transfer Protocol

Open issues • Relationship with other software paradigms • Specifically agent-oriented methodologies • Engineering for open systems • Engineering for scalability

Student presentations

Design of Multi-Agent Systems