Application-Specific Reuse in Multi-Agent System Development. Tom Holvoet, Elke Steegmans. Dept. of Computer Science, KULeuven. Celestijnenlaan, 200A.
Application-Specific Reuse in Multi-Agent System Development Tom Holvoet, Elke Steegmans Dept. of Computer Science, KULeuven Celestijnenlaan, 200A B-3001 Leuven, Belgium +32 16/32.76.38
[tom,elke]@cs.kuleuven.ac.be ABSTRACT In this position paper, we argue that “programming in the large” for reactive multi-agent systems (MAS) should imply a reuse method that allows two things: (1) to describe multi-agent systems in an abstract, application-independent way, and (2) to reuse such abstract MAS through application-specific adoptions. This allows reuse not only of code and design, but also of behavioural aspects, experiments, tests of the abstract MAS. We present part of our work on MASORG, focussing on the specification and reuse of roles in reactive MAS.
Categories and Subject Descriptors D.2.13 [Reusable Software].
General Terms Design, Reliability, Experimentation.
Keywords Multi-agent systems, reuse, roles, MASORG, ant algorithms.
1. MOTIVATION This position paper reflects on reuse in multi-agent system development as a key element in software development as an engineering task. In particular, we focus on MAS with relatively simple, mainly reactive agents, as opposed to the purely cognitive agents that use classical (or adopted) AI techniques for reasoning, planning and learning. The overall behaviour of a reactive MAS emerges from the individual, simple actions of the constituent agents. However, the use of relatively simple agents does not imply that a simple method suffices to do “programming in the large”. MAS are typically very complex, hard to develop and reason upon, debug, and so on. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. ICSE-SELMAS’2002, May, 2002, Orlando, Florida.
Today, there is almost no reuse in reactive MAS software development, except for “the ideas”. E.g. several applications (such as active networking, ant colony optimisation applications, manufacturing control) make use of “the ideas” known from biological systems, e.g. social insects such as ants, bees, termites [6]. However, there are no methods to assist the development of applications based on these concepts. Almost all current implementations incorporate the corresponding concepts in an ad hoc, hard-coded fashion. The past few years, several approaches for agent-oriented software engineering are being investigated (for one overview, see [12]). Most approaches, however, focus on reuse of applicationspecific concepts at the design and implementation level (roles, protocols, agent architectures). Little research is conducted towards “organisational abstractions” [14] – such as structures and patterns – for generic (i.e. application-independent) models. That is a real pity, as there is a large potential of reusing generic multi-agent systems is concrete application domains. An overview of possible reuse: ?? design and code reuse: similar as for “traditional” software systems, reuse of design and implementation abstractions is the prime requirement for any software development method; ?? reuse of organisations: rather than consisting of separate, individual entities, a MAS is typically an organisation consisting of several kinds of agents which exhibit particular roles in a particular environment [2]; a MAS development methodology should therefore support each of these abstractions equally; ?? extendibility, adaptability, manageability, …: any software development method should support the wellknown “-ities” known from software engineering; ?? reliability and correctness: correctly reusing software to build a new application entails that the application can rely on the outcome of the analysis of the software by its original developers: o
correctness tests and experiments for a large range of side conditions can be applied in concrete applications with concrete side conditions;
o
if the software is provided with formal specifications, new applications based on this software can rely on formal analysis results, such as behaviour of the system, resistance to change, and so on.
This is especially important for highly complex systems. In short, we aim to support reuse of generic multi-agent systems in a variety of application-specific contexts. We do not claim to propose one single method for software engineering that is suitable for all kinds of multi-agent systems. It seems obvious that the development of “intelligent, cognitive expert agents” requires concepts, support and analysis techniques that are completely inappropriate for developing “purely reactive multi-agent systems”, and vice versa. Our work focuses on mainly reactive, cooperative multi-agent systems. As such, we do not presume a particular agent architecture (in the sense of [8,13]). Instead, we consider agents to be primarily entities with autonomous, proactive behaviour, possibly exhibiting different roles, and which can communicate with other agents through the environment. This paper is a first report on research on an entire method for MAS development, called MASORG. The main point of the paper is that it is important to describe abstract, applicationindependent MAS separately, and that applications may reuse these abstract MAS in order to reuse the organisations, autonomous behaviour, formal results, experiments, and so on. We elaborate on a particular approach to augment generic role specifications through statechart extension mechanisms. This paper presents work performed within the project “Agents for Coordination and Control (AgCo2)”, funded by the Research Fund of the K.U.Leuven.
2. REUSE OF MAS 2.1 Background Our approach (called MASORG – MAS Organisations) is largely inspired by three pillars of today’s software engineering practice and research, namely object-oriented mechanisms, separation of concerns and design patters and frameworks. Object-oriented mechanisms Object-orientation has proven its advantages (and deficiencies) during the last two decades. Encapsulation and reuse through subtyping (inheritance) are two essential mechanisms that are responsible for its success. Although we adopt these mechanisms, and we do work in an object-oriented setting (as a programming paradigm), we refuse, however, to consider MASORG to be an extension of objectorientation towards agent systems. Agent-orientation is a completely different paradigm, and as such has its own specific requirements and concepts that are not present in objectorientation.
Separation of concerns (SOC) Separation of concerns is the generic idea that indicates that by identifying “concerns” as separate software units makes them more suitable for reuse and adaptation. Besides the fact that this is a general characteristic of object-orientation, this term has been exploited (with success) in the latest developments on aspect-oriented programming (AOP) and other advanced SOC ideas and techniques. Frameworks and design patters Reuse of generic – application-independent – software is recognized within the object-oriented community and has lead to the concepts such as design patterns and frameworks. We want to apply similar ideas in MAS development.
2.2 Our approach … The starting point of our position is that the two most interesting and fundamental concerns in MAS are: (1) the generic – application-independent – MAS model / organisation on the one hand, and (2) application-specific adaptations of this model on the other hand.There is a large body of work in the area of “separation of concerns” under the name of aspect-oriented programming. Originally, aspects were considered as concerns that are scattered around over different classes or modules of an application design or implementation. Nowadays, the scope of aspects has been broadened, and [18] convincingly discusses two necessary conditions for AOP, namely quantification and obliviousness. Obliviousness refers to the fact that developers of a base class or module should do so obliviously of anything related to the aspect. Quantification is then used to indicate under which conditions, aspect-related behaviour is added to the base class or module. In a way, we are aiming to achieve an aspect-oriented approach in that we want developers of generic MAS to be oblivious about any application-specific details. Quantification can then be used by application developers to indicate how the behaviour of the generic MAS is to be adopted to cope with application-specific behaviour. In MASORG, there are two phases or levels in the development of a MAS. On an abstract level, an applicationindependent MAS is modelled. As a multi-agent system is an organisation consisting of several kinds of agents which exhibit particular roles in a particular environment, modelling a multiagent systems consists of (1) defining (or reusing existing) roles – partial behaviours – which are active in a particular environment, and (2) assigning roles to agents, either statically or dynamically. At the level of concrete application building, the developer starts from an abstract MAS and complements it with applicationspecific functionality and behaviour. This means that the developers needs to map the abstract units in the model (the abstract environment, roles and organisation) onto very specific application logic. In this position paper, due to space limitation, we only focus on the description and reuse of “roles”.
Foraging
be -born
observe
unborn
die
new@node
g o t-a -view
move
dead
d o-work d r o p-pheromone done
done-working
Figure 1: the statechart model of a food foraging ant role moving in a graph environment.
The concept of roles as defined by Depke e.a. [15,16] is close to our definition of roles. A role is a partial specification of agent behaviour. Roles represent more than a set of interface operations, but rather incorporate their own autonomous behaviour. An agent may exhibit several roles at one time, and several agents may play an identical role in an multi-agent system. The existence of a role depends on the existence of the agent that performs the role. An agent and its roles have one identity. Depke e.a. have investigated this concept of roles and inspected whether or how roles are supported in the UML. This illustrated that the concept of roles is richer than their adoption in generally accepted object-oriented mechanisms. Moreover, as our concern is mainly in augmenting pre-defined roles with application-specific behaviour, standard object-oriented techniques do even worse. We give one small example of a typical way to realize behaviour extension of roles. This will illustrate the typical problem we occur when reusing generic concepts in an application-specific context. A role and its application-specific implementation could be modelled using the strategy pattern. An algorithm for the behaviour of this role would rely on abstract operations, which could later be implemented in concrete, application-specific classes. Specific patterns for modelling roles are proposed in [11], but for simplicity, we only consider the most simple way to model roles, using the strategy pattern. This approach however lacks flexibility, and does not separate the concerns completely. The lack of flexibility stems from the fact that the abstract algorithm must foresee all possibly useful application-specific additions. Our experience is that it is hard to write algorithms that cover all possible uses, and that application developers are quite demanding on how to add application-specific items. This also entails that the abstract algorithm is polluted by aspects that are irrelevant at that generic level. Moreover, the only interface between the abstract and the specific classes is a set of operations. This is clearly deficient, as the application developer must understand the entire autonomous behaviour of the role before it can be reused successfully, and not just the points – the operations – in which new code can be added. An
informal documentation that describes the autonomous behaviour is mostly ambiguous and insufficient for non-trivial behaviour. Aspect-oriented programming seems like a better approach to seamlessly add new “slices of behaviour” to existing entities. However, employing only a programming level approach (e.g. by applying AspectJ [17]), does not suffice either. First, this does not provide a model of the autonomous behaviour of the role. Second, it is actually unclear whether either the roles should be described as aspects and the application-specific parts as plain objects and close, or whether the application-independent MAS should be developed using plain objects and classes, and application-specific parts are modelled as aspects. A justification can be found for both alternatives. However, for both alternatives, specifying a concrete application is a cumbersome, error-prone job, often requiring artificial constructs. Attempts in this direction [3,4] are hence only partially useful as a reuse method. Mind that we are not implying that these problems cannot be overcome using a programming language approach only, but rather a conceptual mismatch exists between pointcuts and advices on the one hand, and roles with their own autonomous behaviour on the other. What is required is an abstract, but explicit representation of the behaviour of the roles, which is part of the specification of the role – besides the interface operations. This entire abstract representation is the contract between the developers and the reusers of the agent roles. At best, the abstract representation is a formal one, which allows formal reasoning on the behaviour of the role as well as on the behaviour of the entire multi-agent system. A visual yet simple formalism makes the specifications accessible to application developers. Moreover, the formalism should provide a form of refinement that allows to specify the behaviour at different levels of abstraction. Besides the abstract specification, we need to provide mechanisms to add application-specific functionality. These requirements are met by the well-known formalism called statecharts [7], which we extend with reuse mechanisms. For now, we consider only Mealy-like statecharts, in which actions are associated with transitions, and not with states.
ForagingActiveNetworking die
observe
…
…
g o t -a -view
post-action: build local data structure of network
pre -action: clean up local data do -w o r k ? Figure 2: the statechart model of a food foraging ant. pre -action: update local protocol stack p o s t-action: signal update to operating system
structures pre-condition: nothing useful to do at this node
…
Figure 2: reusing the foraging role in an active networking application
The behaviour of every role is specified by means of a statechart. In object-oriented methodologies, a statechart specification describes the correct sequences of method invocations on the object. The interpretation of a statechart in our approach is completely different. The statechart describes the autonomous behaviour of the role. An agent exhibiting a role may decide to perform any of the (autonomous) actions that are “enabled” in its current state. Non-deterministic behaviour of the agent (role) is limited to performing any of the enabled actions in the current state. The hierarchical nature of statecharts allows us to define subtyping of roles through refinement of states in a statechart. As one agent consists of several roles, the entire behaviour of an agent can be conceived as the composition of the respective statecharts as “orthogonal states”. It also allows to synchronize the behaviour of different roles within one agent. Besides the formalism for modelling the abstract behaviour of a role, we need mechanisms for applications to reuse this behaviour. In particular, we want application developers to be able to indicate where / when / what application specific add-ons needs to be performed by the agent exhibiting this role (called quantification in [18]). In specific, the mechanisms offered are: ??
application-specific preconditions: applications may influence the non-deterministic behaviour of the role by specifying additional action preconditions;
??
pre-actions and post-actions: an application developer may indicate that particular application-specific code must be performed before (resp. after) a particular action is executed;
??
pre-state-actions and post-state actions: an application developer may indicate that particular application-specific code must be performed just before the role arrives in a particular state, or just before it leaves a particular state;
2.3 An example … We illustrate this through a short example. In Figure 1, the behaviour model of the role “Foraging” is depicted. It describes the behaviour of an ant-like role, namely foraging for food in an environment consisting of a graph (a number of nodes which are connected through channels). In this explanation, we assume that the reader is familiar with ant-like multi-agent systems [1,5,9]. However, rather than a life-like ant behaviour, this is only an abstract, simple role that is useful enough to illustrate our point. Initially, an agent performing this role is in state “unborn”, from which it can perform (autonomously) the action “be-born” in order to find itself in the state “new@node”. When arrived at a node, the agent will “observe” the environment by inspecting the node on which it resides, leading to the state “got-a-view”. Based on the observations, it can either “die” (if its job is over), or perform the work it is supposed to do at this node. After working, the ant-agent may deposit a chemical substance, called a pheromone, to communicate its findings to other ants that may pass this node. Finally, the ant moves to another node to continue its role. This abstract version of the foraging role allows to develop, experiment, test and reason upon the behaviour of a multi-agent system consisting of a graph environment and a number of agents performing the foraging role. Ant-like multi-agent systems are successfully deployed (a.o.) in the application domains of active networking and manufacturing control. To evaluate our approach, we developed one application for both domains by reusing the above abstract role and adding application-specific functionality. Here, we give a first hint on how we can reuse the abstract role to define an active networking application that is used to update router protocol stacks. The idea is that ant-like agents crawl over the network and update the various router protocol stacks.
The foraging role as it is reused and adopted by the application is shown (informally and partially) in Figure 2: one precondition is added for the action “die”, and several pre- and post-actions are added to different actions. In this figure, these additions are written in plain text for explanation purposes. These additions should typically correspond to pieces of code.
2.4 A first evaluation … Reusing an abstract MAS allows to reuse not only software design and implementation, but also behaviour, formal analysis, experiments and tests. Actually, in the above application, we could reuse (1) the (simple) design of the MAS (a graph environment that can host one kind of agents – foraging behaviour), (2) the implementation of the abstract, autonomous behaviour (which schedules the different actions the agent may take), and (3) experiments (and ideally also formal results) with the MAS which ensures the “good” emergent behaviour of the system. The application developer must study the abstract MAS, and then indicate when / what / where application-specific aspects must be added.
[4]
[5]
[6]
[7]
[8]
[9]
3. Conclusion In this paper we presented ongoing research about a reuse methodology for reactive multi-agent systems. In particular, our aim is to support reuse of generically described multi-agent systems. Building a concrete application based on a generic MAS is reduced to augmenting the generic agent roles with applicationspecific aspects and provide a mapping of other generic concepts onto an application-specific counterpart. We focussed on application-specific reuse of roles. A role is generically described by a Mealy-like statechart that specify their autonomous behaviour. Concrete application agents can are built as a set of roles that are augmented with application-specific functionality. Therefore, we provided five mechanisms to add functionality to statecharts: preconditions, pre- and post-actions, and pre- and post-state actions. This approach allows to separate completely the generic agent behaviour from application behaviour. We performed a first validation of the approach by building two applications that reuse a simple ant-like multi-agent system.
[10]
[11]
[12]
[13]
[14]
[15]
References [1]
[2]
[3]
J. Ferber. Multi-Agent Systems: An Introduction to Distributed Artificial Intelligence. Addison-Wesley. ISBN 0201-36048-9, 1999. T. Holvoet, Y. Berbers and E. Steegmans. Organisation = Roles + Environment. Technical report, KULeuven, Belgium, 11 pages, 2001. Elizabeth A. Kendall. Role Modeling for Agent System Analysis, Design, and Implementation. IEEE Concurrency, Agents and Multi-Agent Systems, Vol. 8-2, 34-41, 2000.
[16]
[17]
[18]
A. Garcia, C.J. Lucena. An Aspect-Based Object-Oriented Model for Multi-Agent Systems. Advanced Separation of Concerns Workshop at ICSE'2001, May 2001 Dorigo M., V. Maniezzo & A. Colorni (1996). The Ant System: Optimization by a Colony of Cooperating Agents. IEEE Transactions on Systems, Man, and Cybernetics-Part B, 26(1):29-41 Eric Bonabeau, Marco Dorigo, Guy Theraulaz. Swarm Intelligence: From Natural to Artificial Systems. Santa Fe Institute Studies in the Sciences of Complexity, Oxford University Press, 1999, ISBN 0-19-513159-2 Harel, D. Statecharts: a Visual Formalism for Complex Systems. Science of Computer Programming 8, 3 (June 1987), 231--274. Rao, A. S., & Georgeff, M. BDI Agents: from theory to practice. In Proceedings of the First International Conference on Multi-Agent Systems (ICMAS-95), pp. 312–319 San Francisco, CA. Valckenaers, P., Van Brussel, H., Kollingbaum, M., Bochmann, O. (2001). Multi-agent coordination and control using stigmergy applied to manufacturing control, Lecture notes in Artificial Intelligence, 2086, 317-334, Springer-Verlag. Dorigo M., G. Di Caro and L. M. Gambardella. Ant Algorithms for Discrete Optimization. Artificial Life, 5,2, pp. 137-172 M. Fowler,.Dealing with roles. Proccedings of the 4 th Annual Conference on the Patterns Languages of Programs, Monticello, Illinois, USA,. (September 1997) 2-5. M. Wooldridge, P. Ciancarini. Agent-Oriented Software Engineering: the State of the Art. In Proc. of the First International Workshop on Agent-Oriented Software Engineering, Limerick, Ireland, June, 2000. LNCS 1957, pp.1-28. M. Wooldridge and N. R. Jennings. Intelligent agents: Theory and practice. The Knowledge Engineering Review, 10(2), pp. 115-152, 1995. F. Zambonelli, N. R. Jennings, and M. Wooldridge (2000) "Organisational Abstractions for the Analysis and Design of Multi-Agent Systems" Proc. 1st Int. Workshop on AgentOriented Software Engineering, Limerick, Ireland, 127-141. R. Depke, R. Heckel, and J. M. Küster. Improving the agent-oriented modeling process with roles. In Proc. Fifth Int. Conference on Autonomous Agents (AGENTS-2001), Montreal, Canada, 2001. R. Depke, G. Engels, J.M. Küster. On the Integration of Roles in the UML. Technical report 214, Univ. PAderborn, August 2000. G. Kiczales, E. Hilsdale, J. Hugunin, M. Kersten, J. Palm, W.G. Griswold. An Overview of AspectJ. J. Lindskov Knudsen (Ed.): ECOOP 2001, LNCS 2072, pp. 327-353. R.E. Filman, D.P. Friedman. Aspect-Oriented Programming is Quantification and Oblivousness. ECOOP 2000 Workshop on Aspects and Dimensions of Concerns.
