Agent-oriented Software Construction with UML

Agent-oriented Software Construction with UML Federico Bergenti and Agostino Poggi Dipartimento di Ingegneria dell’Informazione, Università degli Studi di Parma Parco Area delle Scienze 181A, 43100, Parma, Italy E-mail {bergenti,poggi}@ce.unipr.it

Abstract In the last years, an increasing number of computing systems are being realized taking advantage of autonomous agents. Traditional software engineering methodologies are insufficient to be used in the development of such systems because of the particular characteristics of autonomous agents. Therefore, a lot of work has been done to extend traditional software engineering methodologies for agent systems and its result has been the definition of new methodologies of agent-oriented software engineering. This chapter introduces the basic concepts of agent-oriented software engineering showing the new artefacts that we introduced to analyse, design and implement multi-agent systems. In particular, we present a set of agent-oriented diagrams that support the modelling of: (i) the architecture of the multi-agent system, (ii) the ontology followed by agents and (iii) the interaction protocols used to coordinate agents. These artefacts are described exploiting an UML-based notation that exploits stereotypes to provide agent-oriented semantics to class and collaboration diagrams.

Keywords Software agents, Agent-oriented software engineering, UML.

1.

Introduction

The ever-increasing importance of the Web in everyday life is driving the need of software capable of coping with open and dynamic environments. More than other technologies, software agents seem to have the necessary characteristics to support the development of open and flexible software systems [22,32,44]. This is the reason why the research on agents and multi-agent systems has come to a new life in the recent years, leaving artificial intelligence laboratories to reach the realm of real-world software development. The creation of FIPA, the decision of OMG to raise the status of the Agent Working Group to special interest group and the agent-oriented software engineering workshop (AOSE) at ICSE are only indications of the importance that this technology is gaining. In particular, the creation of FIPA – the Foundation for Intelligent Physical Agents – in 1996 seems to be one of the major causes for the interest that nowadays industry is having for agent technologies. FIPA’s mission is to promote “technologies and interoperability specifications that facilitate the end-to-end inter-working of intelligent agent systems in modern commercial and industrial settings” and its goal is “to overcome the destructive competition between incoherent concurrent proprietary technologies in the marketplace”. Surprisingly, the community of agent technologies has not yet adopted an accepted definition for the word agent and many, and somehow opposite, definitions are available. In this paper we do not take this debate into account and we restrict the agent abstraction only to express the characteristics that make agents ideal for the development of open and flexible software systems. This chapter introduces the fundamental concepts of agent-oriented software engineering taking the pragmatic approach of showing the new artefacts that the architect can exploit to model a system at the agent level of abstraction. The next section introduces softwarec agents. Section three presents the main works on agent-oriented software engineering. Section four describes

2

how UML diagrams can be used as basis for agent-oriented software engineering. Finally, section five presents some conclusions.

2.

Software Agents

We introduce our informal characterisation of software agents emphasising the features that we will exploit in the definition of the artefacts described in the following sections. The definition presented here is adapted from [44]: an agent is a software system that is (i) situated in some environment, (ii) capable of autonomous actions in order to meet its objectives and (iii) capable of communicating with other agents. This definition raises several points that should be discussed to show that agents can be naturally used in software engineering as a first-class abstraction. Such a discussion involves the unresolved debate on the differences between objects and agents, as it should be clear that they are somehow similar abstractions. Agents are situated systems and the environment provides to agents the essential information to work. This emphasises that agents are intended to work with non-agentized entities and the importance of reification is weaken with respect of the object-oriented approach. In the object-oriented picture, everything must be reified, as objects are not intended to interact with the environment. Agents naturally interact with their environment and take advantage of this possibility to bring about their objectives. The most important characteristic that we associate with agents is the ability to act in complete autonomy, i.e., agents have their own objectives and they are capable of acting to bring about them without any external coercion. This is sometimes summarised with the phrase: “agents can say go” [29], to emphasise that they are not requested to wait for an external command to act, but they can decide to act because they have an explicit goal to achieve. As a direct consequence of this characteristic, agents are allowed to refuse acting if

3

they believe that the outcome of an action may prohibit them to achieve their goals, and we say that “agents can say no” [29]. Autonomy is probably the most important difference between agents and concurrent or active objects. An object is not explicitly associated with a goal and its role in the system is implicitly defined by when and how the other objects send messages to it. An agent is explicitly associated with a goal and its interaction with the environment and with the other agents are mainly directed to achieve this goal. Another characteristic that we associate with agents is the so-called social ability, i.e., the possibility that agents have to communicate with other agents. Various communication models are available, but all these models mainly derive from speech act theory [39]. KQML (Knowledge Query Manipulation Language) is the probably the most known agent communication language [12,13]. KQML is a protocol for exchanging information and knowledge whose main feature is that all the information for understanding the content of the message is included in the communication itself. FIPA ACL - Agent Communication Language - is a language for the communication between agents that is proposed by FIPA consortium [14]. The syntax of the FIPA ACL is very close to the syntax of KQML. However, despite syntactic similarity, there are fundamental differences between KQML and FIPA ACL, the most evident being the existence of a formal semantics

for FIPA ACL which should eliminate any ambiguity and confusion from the

usage of the language. Each FIPA ACL message is structured in two parts: a communication part and a content part. The communication part carries content-independent information such as the identification of the sender and the receiver. On the contrary, the content part bares the meaning of the message and it is structured as a performative and a domain content. The performative is a domain-independent verb that specifies the meaning that the sender of the message wanted to

4

associate with the domain content. FIPA specifies a set of performatives, such as inform, request and query, that agents can use to communicate. The domain content of the message is a sentence expressed in some language and following some ontology that actually bares the meaning of the message. FIPA does not prescribe any language for expressing domain contents and when an agent receives a message, it comes to know the language and the ontology used in the domain content exploiting the communication part of the message. The structure of a FIPA ACL message introduces some overhead because the data sent may be redundant in some cases, however, the advantage is that message processing is simpler and may be easily used for the interaction of heterogeneous agents. FIPA communication model is not limited to isolated messages exchanged by agents, but it also allows messages to be grouped into interaction protocols. Interaction protocols are domain-independent courses of messages that can be instantiated in concrete conversations between agents. They are intended to abstract a common path of performatives from the set of possible conversations to ease the realisation of agents. FIPA provides a set of generalpurpose interaction protocols and it also provides guidelines for the realisation of applicationspecific interaction protocols [14]. FIPA guarantees interoperability because the syntax and the semantic of FIPA ACL are standardized and communicating agents are supposed to share a common ontology and a common language for expressing domain contents. At the moment, only a few systems [3, 37] support the semantic of FIPA ACL, while many other support only the syntax of it [1, 2, 27, 33]. The latter systems rely on the common syntax of ACL and on the set of general-purpose interaction protocols to support interoperability. This kind of interoperability is not sufficient to support the realisation of open and flexible systems and FIPA decided to address this problem explicitly devoting resources to provide a more feasible means to support service-level interoperability.

5

The characteristic autonomy and FIPA service-level interoperability justify the interest for agents in the realisation of complex and dynamic applications capable, for example, of managing the resources available on the Web. Autonomy is necessary when dealing with dynamic environments to allow software systems adapting to unpredictable situations. We cannot delegate to the developer the prediction of all possible courses of events that may occur in the Web. Inter-operability is a necessary condition for the implementation of open systems [16, 17, 31]. Every second new information and new services become available on the Web and users cannot wait for developers evolving their products to take advantage of these new resources.

3.

Agent-oriented Software Engineering

The research on agent-oriented software engineering is based on the possibility to model a software system at the agent level of abstraction [4,7,20,21, 26, 42, 47,46]. This level of abstraction considers agents as atomic entities that communicate to implement the functionality of the system. Various initiatives [26, 47] are devoted to establish a methodology for an agent-oriented development process and this work shows a brief overview of the common ideas behind such methodologies to demonstrate how the introduction of the agent level of abstraction can change the software development cycle. In the following of the section, some of most interesting agent-oriented methodologies to develop multi-agent systems are described. The AAII methodology for agent-oriented analysis and development [24] is based on objectoriented methodologies enhanced with some agent-based concepts. This methodology derives from a long experience in realizing multi-agent systems through the belief-desire-intention technology [34]. A multi-agent system is represented through both internal and external models. The external models mainly described the interactions between agents while the 6

internal models is entirely dedicated to the description of the internal of the different agents in term of their beliefs, desires and intentions. Cassiopeia methodology [9] is based on a bottom up development process. In particular, the methodology proposes three steps. The first step identifies the elementary behavious that are implied by the overall system task. The second step identifies the relationships between elementary behaviours. Finally, the third step identifies the “organizational behaviours” of the system representing the way in which agents form themselves into groups. MAS-CommonKADS methodology [19] extends the models defined in CommonKADS [38] adding technology from object-oriented methodologies and from protocol engineering for describing the agent protocols [36]. This methodology starts with a conceptualisation phase from which defines a first description of the system from the user point of view. Then it uses a set of models for the analysis and design of the system through a risk-driven life cycle. The models used are: the agent model, describing the main features of agents, the task model, describing the tasks carried out by agents, the expertise model, describing the knowledge that agents need to carry out their tasks, the coordination model, describing interactions between agents, the organisation model, describing the organization of the agent society, the communication model, describing the interaction between humans and agents, and, finally, the design model, that collects the previous models. The Gaia methodology [47] tries to build a multi agent system through a process of organisational design. This methodology borrows some terminology and notation from object-oriented analysis and design and, in particular, from FUSION [8]. The objective of the analysis stage is to capture the system organization as a collection of roles that stand in certain relationships to one another and that take part in a set of systematic interactions with other roles. There are not a mapping one-to-one between roles and individuals (agents), but often an individual can take on many roles. A role is defined by four attributes:

7

responsibilities, permissions, activities and protocols. Responsibilities determine functionality and are the key role attributes. Permissions are the “right” associated with a role. Activities are computations associated with a role that an agent can take without interacting with other agents. Finally, protocols define the way that a role interact with other roles.

4.

Using UML for Developing Agent Systems

Even if the agent level is the natural level of abstraction for describing a multi-agent system, the lack of accepted diagrammatic notations and design tools might prevent architects from exploiting its benefits. The research community of agent-oriented software engineering is currently addressing this problem investigating the possibility of extending UML [5] to support the basic agent-oriented concepts such as agent, ontology and interaction protocol. This research trend has led to various extensions of UML [10, 15, 28, 29], but such notations are not completely accepted because they are not yet supported by CASE tools. It is worth noting that one of the main goals of the AUML initiative [29] is to encourage CASE-tools vendors to support an agent-oriented notation in their products. In the remaining of this section we introduce the basic concepts of agent-oriented software engineering taking the pragmatic approach of showing the new artefacts that the architect can realize and introducing an UML-based notation to describe such artefacts. Our UML-based notation does not require extensions to the usual UML diagrams and any off-the-shelf CASE tool can support it. This approach has the advantage of allowing architects using our notation without either the need for agent-enabled CASE tools or, when the CASE tool support UML extensions (e.g., Rational Rose Case tool) the need for extending the CASE tool with new diagrams and for learning to use such kinds of diagrams.

8

4.1

Agent-oriented Analysis

The analysis phase is intended to examine the domain of the problem to specify what the software system is intended to do. In general, this phase should be reasonably independent from the technology used to develop the system and the system itself should be seen as a black box interacting with its environment. This is the reason why talking about agentoriented analysis may seem an oxymoron. Nevertheless, some kinds of agents, such as personal assistants or information agents, are directly in contact with the user and they provide pieces of functionality that must be considered during the analysis. Therefore, we introduce agent-oriented use cases to allow the architect specifying the interactions that some kinds of agent have with the user, with the environment and with the rest of the system. Even if they are modelled out of the black box bounding the system, such agents are part of the system under construction and they are analysed separately only to take their special role in providing functionality into account. In order to represent agent-oriented use case diagrams, we introduce the stereotype agent, easing the implementation of tools managing such diagrams, and we treat agents as common actors. Figure 1 shows a simple agent-oriented use case diagram describing a system implementing a personal assistant capable of buying CDs on behalf of its user. We will discuss this example in more detail in the rest of this section, as we will use it to introduce other agent-oriented diagrams. Another reason for introducing agent-oriented analysis is the importance of data modelling in the realisation of multi-agent systems. Agents use ontologies to associate a meaning to messages and the most important ontology-description languages, such as Ontolingua [13], allow describing the domain of the problem in terms of entities and relations between entities. The kinds of artefacts produced during the modelling of an ontology are similar to the ones produced during the usual data-modelling phase. This is due to the fact that ontologies are not engineered, to avoid constraining how agents can be realised, and therefore they are simply a

9

description of the domain data. The similarity between data modelling and ontology modelling suggests using similar notations. We propose to use a variant of conceptual diagrams [25], that we call ontology diagrams, to model ontologies. An ontology diagram is a class diagram where classes model classes of entities defined in the ontology. We tag the classes in ontology diagrams, i.e., entity classes, with the stereotype entity. Entities are structured using public attributes. Ontology diagrams allow defining relations between classes and we use such relations to model the predicates provided by the ontology. Figure 2 shows the ontology of the CD shop example. This diagram comprises three classes of entities: CDs, prices and payment conditions. CDs are characterized by a title and by an author; prices are characterized by an integer value, while payment conditions comprise only a credit card number. The diagram shows also four predicates: two has predicates and two price predicates defined over different entity classes.

4.2

Agent-oriented Design

Designing a multi-agent system at the agent level requires modelling the architecture of the multi-agent system and the interactions between agents. Such elements can be modelled using some UML class diagrams, we call architecture diagrams that identify the roles [23] that agents play in the system. Each role is associated with a class, that we call agent class, and we introduce the stereotype agent to tag such classes because they equals the ones used in agent-oriented use case diagrams. Associations between agent classes describe possible associations between agents playing different roles. Such associations are basically used to express acquaintance because it is common to promote flexibility in the multi-agent system avoiding the use of associations to spread responsibilities across agents. An agent class can be used to associate a set of actions with a role. Actions are represented as public methods of the class. Such methods must be declared void because no concept of return value is defined for actions performed by agents. Moreover, the parameters of such 10

actions must belong to entity classes defined in ontology diagrams. The list of actions associated with an agent class does not include the performatives of the agent communication language because we suppose to use FIPA ACL and its performatives. Object protocols, the object-oriented counterpart of interaction protocols, are not included in UML because our approach allows modelling only known protocols and the developer is implicitly requested to use only the set of FIPA general-purpose interaction protocols, so the possible ways agents interact are “predefined”. This is the reason why we have no means to annotate agent classes with the list of supported interaction protocols except for using comments. The motivation of this choice is simply to preserve interoperability. In fact, introducing application-specific interaction protocols may lead to the following problems. Even if we provide agents with a run-time description of a protocol, it is extremely difficult to implement an agent capable of taking such a description and learning how to use the protocol without any explicit help from the developer. Therefore, agents using applicationspecific protocols may not be able to run in open systems where third-party agents join and leave the system dynamically. Moreover, the semantics of the paths of a protocol must be coherent with the semantics of the employed performatives. This coherence is very difficult to achieve and only well-studied and accepted protocols can guarantee this property. If an application-specific interaction cannot be expressed as a combination of general-purpose protocols, we can use the notation introduced by Odell et al. [28, 29] to create new interaction protocols from scratch. Figure 3 shows the architecture diagram for the CD shop example. It shows two classes of agents: personal assistants and CD shop agents. Agents belonging to such classes support the FIPA contract net protocol [14, 41] the FIPA request protocol [14]. Moreover, CD shop agents can be requested to perform an action called sell. Such an action requires the

11

identification of the personal assistant buying the CD, the description of the CD it wants to buy and its payment conditions.

4.3

Agent-oriented Implementation

The need of an agent-oriented support to develop software was felt long before the introduction of agent-oriented software engineering with the definition of agent-oriented programming languages such as Agent0 [40] and Telescript [43]. Nowadays, the approach of agent-oriented languages is no longer adopted and the greater majority of agents are developed in Java taking advantage of one of the available agent platforms. Agent platforms are run-time environments that manage the lifecycle of agents and provide the necessary communication resources: means for sending and receiving messages, white and yellow pages services. Such communications reach either agents within the same platform or agents on different platforms transparently to the developer. This is a fundamental characteristic of agent platforms as it allows supporting open systems where agents join and leave dynamically. In addition, an agent platform can be physically distributed across a set of network nodes. The distribution and cooperation of agents residing on different platforms implies the conformance to a standard. At the moment, only FIPA is producing specifications for agent platforms and these specifications are the basis for the Java Specification Request JSR-000085 – Java Agent Services. Agent platforms, such as Jade [1] and Fipa-Os [33], provide only a transport layer and some basic services, but they do not provide any support for autonomy. Moreover, they lack support for service-level interoperability because they do not take into account the semantics of the agent communication language. Therefore, another kind of development tool, called agent-development toolkit, was introduced to provide the developer with high-level abstraction from the BDI agent architecture [44]. These tools, such as dMars [11], Jack [6], AgentBuilder [35], Jam [18] and Zeus [27], provide a way for rapidly prototyping agents but 12

they do not seem to produce sufficiently robust and efficient agents for their adoption in industrial-strength projects mainly because of their immaturity. Recently,

we

implemented

an

agent-development

toolkit

called

ParADE

(Parma

Development Environment) [3] to support autonomy and inter-operability over existing FIPA-compliant platforms. Even if ParADE could have been implemented over any existing agent platform, its current implementation works on top of Jade [1] to take advantage of its services. The goal driving the work on ParADE is providing the agent developer with a hybrid agent architecture capable of promoting interoperability and supporting autonomy exploiting the semantics of FIPA ACL. Such an architecture is basically goal-oriented but it also integrates reactive behaviours. This approach is chosen because goal-orientation is a fundamental key in supporting the semantics of FIPA ACL and we think that reactive agents are easier to design and to implement. Goal-oriented agents are inherently autonomous because they act to achieve their goals without requiring the developer to foresee all possible flows of events. ParADE is composed of a set of development tools supporting the developer at the agent level and at the object level. The agent level allows describing agents in terms of their BDIlike characteristics such as beliefs, goals and social organization. At this level of abstraction, the developer can produce UML models as described in this paper to generate code for agents. This code relies on ParADE development library and on the services provided by the underlying agent platform. It is worth noting that ParADE does not integrate any CASE tool because the code generator works with XMI [30] files that any off-the-shelf CASE tool should be able to produce. The code generated from agent-level models is only a skeleton and the developer is requested to complete it at the object level integrating application-specific behaviours. Such behaviours are implemented by using the ParADE development library to access ParADE components such as the knowledge base and the planning engine. This two-

13

level approach has the advantage of supporting the production of code from UML models at the agent level without taking implementation details into account. Moreover, it allows integrating legacy code and supporting application-specific optimisations at the object level.

5.

Conclusions

Software engineering is founded on the possibility to model a system at different levels of abstraction. Agent-oriented software engineering introduces a new level, called agent level, to allow the software architect describing a system in terms of interacting agents. At this level of abstraction, an agent is considered as an atomic entity that communicates with other agents to implement the functionality of the system. This work introduces the basis of agent-oriented software engineering exploiting the pragmatic point of view of showing the new artefacts provided to the architect to model systems at the agent level. Such artefacts can be produced using an UML-based notation supported by any off-the-shelf CASE tool to allow architects adopting it without the need for agent-enabled CASE tools. Three agent-oriented diagrams are introduced to model the basic elements characterising the agent level of abstraction: the interactions between agents and the environment, the architecture of the multi-agent system and the ontology followed by agents. Agent-oriented use case diagrams are simple extensions of usual use case diagrams that allow introducing agents and modelling their interactions with the user, with the environment and with the rest of the system. Architecture diagrams allow modelling the architecture of the multi-agent system in terms of a set of agent classes connected through relations. Each class is characterised by the actions that an agent belonging to it can be requested to perform. The relations between classes may be used to express the network of acquaintance that an agent can build at runtime. Ontology diagrams allow defining a model of the environment composed of entities and relations. These relations can be used to specify the predicates that

14

agents can use to communicate and therefore ontology diagrams can be used to model the domain-content of messages.

Acknowledgements This work is partially supported by CSELT and by the European Commission through the contracts IST-1999-12217, CoMMA – Corporate Memory Management through Agents – and IST-1999-10211, LEAP – Lightweight Extensible Agent Platform.

References 1. F. Bellifemine, A. Poggi and G. Rimassa, Developing Multi-agent Systems with JADE, Proceedings Seventh International Workshop on Agent Theories, Architectures, and Languages (ATAL 2000), (2000) 85-99. 2. F. Bergenti and A. Poggi, A Development Environment for the Realization of Open and Scalable Multi-Agent Systems, Proceedings Ninth European Workshop on Multi-Agent Systems (MAAMAW 99), (1999) 52-62. 3. F. Bergenti and A. Poggi A Development Toolkit to Realise Autonomous and Interoperable Agents, Proceedings Fifth International Conference on Autonomous Agents (Agents 2001), (2001), 632-639. 4. F. Bergenti and A. Poggi Exploiting UML in the Design of Multi-Agent Systems, Proceedings ECOOP Workshop on Engineering Societies in the Agents' World 2000 (ESAW'00), (2000) 96-103. 5. G. Booch, J. Rumbaugh and I. Jacobson, “Unified Modelling Language User's Guide”, Addison-Wesley, 1999. 6. P. Busetta, R. Rönnquist, A. Hodgson and A. Lucas, JACK Intelligent Agents – Components for Intelligent Agents in Java, AgentLink News Letter (January 1999). 7. P. Ciancarini and M.J. Wooldridge, Agent-Oriented Software Engineering, Lecture Notes in Computer Science, 1957, Springer-Verlag, 2001. 8. D. Coleman, P. Arnold, S. Bodoff, C. Dollin, H. Gilchrist, F. Hayes and P. Jeremaes, Object-Oriented Development: The FUSION Method, Prentice Hall, 1994. 9. A. Collinot, A. Drogoul, P. Benhamou, Agent oriented design of a soccer robot team, Proceedings ICMAS-96, (1996) 41-47. 10. S. Cranefield and M. Purvis, UML as an Ontology Modelling Language, Proceedings of the Workshop on Intelligent Information Integration, 16th International Joint Conference on Artificial Intelligence (IJCAI-99), 1999. 11. M. d'Inverno, D. Kinny, M. Luck and M. Wooldridge, A Formal Specification of dMARS. (M.P. Singh, A.S. Rao and M. Wooldridge Eds) Intelligent Agents IV, pp. 155-176, Springer-Verlag LNAI, vol. 1365, 1998.

15

12. T. Finin, J. Weber, G. Wiederhold, M. Genesereth, R. Fritzson, D. McKay, J. McGuire, P. Pelavin, S. Shapiro and C. Beck Specification of the KQML Agent-Communication Language, Enterprise Integration Technologies, EIT TR 92-04, Palo Alto, CA, 1992. 13. T. Finin, Y. Labrou and J. Mayfield, KQML as an Agent Communication Language, (M.J. Bradshaw Ed.) Software Agents, MIT Press, 1997. 14. FIPA, FIPA ’99 Specification Part 2: Agent Communication Language, available at http://www.fipa.org. 15. FIPA Technical Committee C, Extending UML for the Specification of Agent Interaction Protocols, response to the OMG Analysis and Design Task Force UML RTF 2.0 Request for Information, 1999. 16. M. R. Genesereth and R. E. Fikes, Knowledge Interchange Format - Version 3 Reference Manual, technical report Logic-92-1, Stanford University, 1992. 17. M. R. Genesereth, N. Singh and M. Syed, A Distributed and Anonymous Knowledge Sharing Approach to Software Interoperation, International Journal of Cooperative Information Systems 4(4), 1995, 339-367. 18. M. J. Huber, JAM: A BDI-theoretic Mobile Agent Architecture, Proceedings Proceedings Third International Conference on Autonomous Agents (Agents 1999), (1999) 236-243. 19. C. A. Iglesias, M. Garijo and J. C. A. González, J.R. Velasco. Analysis and design of multiagent systems using MAS-CommonKADS, Proceedings International Workshop on Agent Theories, Architectures, and Languages (ATAL’97), (1997) 313-327. 20. C. A. Iglesias, M. Garijo and J. C. A. González, Survey of Agent-Oriented Methodologies, Proceedin Proceedings International Workshop on Agent Theories, Architectures, and Languages (ATAL’98), (1998) 317-330. 21. N.R. Jennings, On agent-based software engineering, Artificial Intelligence 117, 2000, 277-296. 22. N.R. Jennings and M. Wooldridge, Agent oriented software engineering, (M.J. Bradshaw Ed) Handbook of Agent Technology, MIT Press, 2000. 23. E. A. Kendall, Agent Roles and Role Models: New Abstractions for Multiagent System Analysis and Design, Proceedings International Workshop on Intelligent Agents in Information and Process Management, 1998. 24. D. Kinny, A.S. Rao and M. P. Georgeff, A methodology and modeling technique for systems of BDI agents, (W. Van de Velde and J.W. Perram Eds), Agent Breaking Away: Proceedings Seventh European Workshop on Modelling Autonomous Agents in a MultiAgent World, 56-71, Springer-Verlag LNAI, vol. 1038, 1996. 25. C. Larman, Applying UML and Patterns, Prentice Hall, 1997. 26. MESSAGE Consortium, Deliverable 1: Initial Methodology, deliverable of the EURESCOM Project P907-GI, 2000. 27. H. S. Nwana, D. T. Ndumu and L. C. Lee, ZEUS: An advanced Toolkit for Engineering Distributed Multi-Agent Systems, Proceedings of PAAM’98, 1998 (377-391). 28. J. Odell and C. Bock, Suggested UML Extensions for Agents, response to the OMG Analysis and Design Task Force UML RTF 2.0 Request for Information, 1999. 29. J. Odell, V. Parunak and B. Bauer, Representing Agent Interaction Protocols in UML, Proceedings of Agents 2000, 2000. 30. OMG, XML Metadata Interchange – Version 1.1, available at http://www.omg.org.

16

31. P. F. Patel-Schneider and B. Swartout, Description-Logic Knowledge Representation System Specification, DARPA KSE technical report, 1993. 32. R.S. Patil, R.E. Fikes, P.F. Patel-Scheneider, D. McKay, T. Finin, T. Gruber and R. Neches, The DARPA knowledge sharing effort: progress report, Proceedings Third Conf. on Principles of Knowledge Representation and Reasoning, (1992) 103-114. 33. S. Poslad, P. Buckle, R. Hadingham, The FIPA-OS Agent Platform: Open Source for Open Standards, available at http://fipa-os.sourceforge.net. 34. A.S. Rao, M. P. Georgeff, BDI agents: from theory to practice, Proceedings First Int. Conf. On Multi-Agent Systems, (1995) 312-319. 35. Reticular Systems, AgentBuilder - An Integrated Toolkit for Constructing Intelligence Software Agents, available at http://www.agentbuilder.com. 36. E. Rudolph, J. Grabowski, P. Graubmann, Tutorial on message sequence charts (MSC), Proceedings of FORTE/PSTV’96 Conference, 1996. 37. M. D. Sadek, Dialogue acts are rational plans, Proceedings ESCA/ETRW Workshop on the Structure of Multimodal Dialogue, (1991) 1-29. 38. A.T. Schreiber, B.J. Wielinga, J.M. Akkermans, W. Van de Velde, CommonKADS: A comprehensive methodology for KBS development, Deliverable DM1.2a KADSII/M1/RR/UvA/70/1.1, University of Amsterdam, 1994. 39. J.R. Searle, Speech Acts: An Essay in the Philosophy of Language, Cambridge University Press, Cambridge, 1969. 40. Y. Shoham, An Overview of Agent-oriented Programming, (J.M. Bradshow Ed) Software Agents, AAAI Press, 1997. 41. R. Smith, The Contract Net Protocol: High-Level Communications and Control in a Distributed Problems Solver IEEE Transactions on Computers, vol. 29, no. 12, 1980, 1104-1113. 42. J. Treur, Methodologies and Software Engineering for Agent Systems, available at http://www.cs.vu.nl/~treur. 43. J. White, Mobile Agents, (J.M. Bradshow Ed) Software Agents, AAAI Press, 1997. 44. M. Wooldridge, Agent-based software engineering, IEE Proceedings on Software Engineering, 144(1), 1997, 26-37. 45. M. Wooldridge, Intelligent Agents, (G. Weiss Ed) Multiagent Systems: A Modern Approach to Distributed Artificial Intelligence, MIT Press, 1999. 46. M. Wooldridge, N. Jennings, Software Engineering with Agents: Pitfalls and Pratfalls, IEEE Internet Computing, 3(3), 1999, 20-27. 47. M. Wooldridge, N. R. Jennings and D. Kinny, The Gaia Methodology for Agent-Oriented Analysis and Design, Journal of Autonomous Agents and Multi-Agent Systems, 3(3), 2000, 285-312.

17

Figure 1. Agent-oriented use case diagram of the CD shop example.

User

Buy a new CD

Assistant

18

Figure 2. Ontology diagram of the CD shop example.

CD Shop

has

Assistant

Condition cardNumber : long

has price

CD title : String author : String

price

19

Price value : int

Figure 3. Architecture diagram of the CD shop example.

protocol: FIPA Contract Net FIPA Request

Assistant

CD Shop sell (cd : CD, assistant : Assistant, condition : Condition) : void

20