In this Appendix, the paper that has been accepted for the Student Session of the Eight European Agent Systems Summer School (EASSS 2006) can be found. It is titled:

(1)

Appendices

All papers written during my graduation project are included in the following sequence:

Appendix A Paper EASSS 2006

In this Appendix, the paper that has been accepted for the Student Session of the Eight European Agent Systems Summer School (EASSS 2006) can be found. It is titled:

“Decomposing Role-Based Interactions between Agents”.

Appendix B Paper ESAW 2006

In this Appendix, the paper that has been submitted to the Annual International Workshop "Engineering Societies in the Agent World (ESAW06)” can be found. It is titled: “Embodied Interactions: a Way to Model and Execute Complex and Changing Business Processes with Agents”.

Appendix C Paper IAT 2006

In this Appendix, the paper that has been submitted to the 2006 IEEE/WIC/ACM

International Conference on Intelligent Agent Technology (IAT 2006) can be found. It is

titled: “Interaction Beliefs: a Way to Understand Emergent Organisational Behaviour”.

(2)

Decomposing Role-Based Interactions between Agents

Marco Stuit

Master Student at The Agent Laboratory, Faculty of Management and Organization, University of Groningen, Nijenborgh 4, 9747 AG Groningen, the Netherlands.

m.stuit@student.rug.nl Abstract

This paper presents the basis for an interaction decomposition in an agent-oriented modelling language with interactions, agents, and roles as central modelling concepts. Because of the complexity of the processes being modelled interactions can become quite complex involving many roles. Therefore, decomposing interactions into ‘smaller’ interactions makes the interactions easier to understand, model and execute.

1 Introduction

Each modelling approach has a specific focus. It could be the “entity” concept, or the “activity”, or “location”.

Our research is centred on developing an Agent Modelling Language (as an extension of UML and Petri Nets).

We have called this language The Agent Lab Language (TALL) – due to the name of our lab (TAL, see [1, 2]).

In TALL, the most important is the concept of interaction. This concept allows for the modelling of complex and distributed business processes (BPs). Classic BP modelling takes a centralistic standpoint, which means an external observer sees the entire process model as a monolithic whole.

In our approach, due to the agent-orientation each participant has to have its own local view of the process. On a high level of abstraction, TALL allows an entire process to be described as a single over-encompassing interaction. Interactions are executed by agents that play the roles attached to an interaction. From a modelling perspective, such a representation is very simple but at the same time, its simplicity reduces the expressiveness and richness of the model. From the perspective of the agents performing the roles such a conceptual interaction is very complex and undesirable. To be useful, it is necessary to decompose a high-level interaction into

‘smaller’ interactions in a top-down analysis fashion. Alternatively, it is possible to have a set of interactions where all interactions are elementary interactions (i.e. these cannot be decomposed further). Such a set of interactions is not very useful either, because the triggering of an interaction may occur at a higher level of abstraction. There is clearly a need to define interactions that are “in between” the overall BP-describing interaction and the elementary interactions. In our view, interactions are compositional; they can be grouped and divided. This leads to the following research questions: “How can the de- and re-composition of an interaction be done in a consistent way?

Motivation and Relevance

Interactions that are enacted on local models of interaction of the agents usually lead to inconsistencies or failure of the BP. In [3] it is explained that it is not sufficient to concentrate on the local behaviour of agents, as the interaction execution is often the most difficult part due to synchronization problems between agents.

Wagner [4] introduces the “interaction diagrams” but there is no coordination between these, leaving the enactment of the BP to the agents alone. The increasing relevance of interactions in agent-oriented frameworks has been described in several publications [5, 6]. For example, in the MESSAGE framework [7] such an interaction view is used. The agent approach enables the modelling and support of a distributed, heterogeneous, and not well “known” process. The humans who are carrying out the process do not have a precise view either.

In addition, the agent paradigm allows for conflicting process views.

This paper is organised as follows. Section 2 will present the syntax and semantics of the interaction decomposition. Next, section 3 will discuss the modelling and execution of the decomposition. Finally, a conclusion will be presented in section 4.

2 Interaction modelling in TALL

Interactions are modelled as standalone entities. An interaction has to be linked with roles, which can be played by agents. So-called Interaction Beliefs (IBs) represent the local views of the agents participating in the interactions. Such and IB is a swimlane workflow-like description (based on Petri-nets) of the activities, states,

(3)

and messaging channels as seen by an agent instance in a specific interaction. Basically, the execution of an interaction is the coordinated execution of (local) IBs provided by the participating agents.

TALL is a graphical language. The syntactic term used for interaction is depicted as a suggestive symbol used also in MESSAGE: a flattened hexagon, as in fig. 1. The TALL Agent-Role-Interaction (ARI) diagram shows the dynamic relationships between agents who are playing the roles; roles are connected to the lines outgoing from the interaction symbol. The IBs of the agents are represented in a “condensed” symbol by chevrons that appear at the association end of the agent-role connector at the agent side. This connector, an arrow with a hollow triangular head, with an interrupted line as shaft, defines an “[agent] playing [role]” - relationship.

According to [8] it is convenient to speak of a class as populating a role and of an instance as playing a role. A generic example of such a diagram is shown in fig. 1.

Figure 1 Example of an interaction with two roles attached in which each agent has its own local view of the interaction.

Such a diagram, at a type level, can indicate what types of agents can (or in an organisational sense, should) populate the roles. At an instance level, an agent will have to play a role in an interaction; this interaction will be instantiated and other agent instances will fill the remainder of the roles. We see roles only as placeholders that are filled by agents; they are never instantiated but recruit their instances from the agent classes filling the role (more about this debate can be found in Chapter 3 of [2]).

3 Interaction decomposition

To incorporate the decomposition of interactions into TALL as a modelling view a new diagram type called the Interaction Decomposition diagram has been created. Interactions depicted in the diagram show only the roles without the agents attached. This is only an initial modelling view, showing prescriptively how a process can be structured as a graph of interactions. At this moment, it is not necessary to know which agents are playing the roles in the (sub) interactions. For that, an instance level of the ARI diagram is used. More information about this diagram can also be found in [2].

Fig. 2 shows an example of a Sales interaction that is decomposed into sub-interactions. These are linked to the higher-level interaction by the TALL FlowSet (FS) symbol. This symbol has been created to depict that sub- interactions together form a set of ‘flowing’ interactions that are executed in a certain order (allowing parallel execution also). Completing a FS of sub-interactions implies that their parent interaction is completed. Hence, each sub-interaction completes a part of the higher-level interaction. However, it is not always necessary that all sub-interactions are to be executed, in order to complete a parent interaction. In addition, the order in which the interactions are completed is determined at run-time (in the coordinated execution of the IBs).

In UML, there are two forms of the aggregation relationship. First, there is the strong form of aggregation called composition. ‘Composite aggregation is a strong form of aggregation that requires a part instance be included in at most one composite at a time. If a composite is deleted, all of its parts are normally deleted with it [9, p. 38]’. For the interaction decomposition, it is not desirable to make the higher-level interactions responsible for the creation and destruction of the lower-level interactions. Interactions are executed at the lowest level (this is explained in Section 4) so they are not the responsibility of the higher-level interactions. Lower-level

interactions should be, in our view, able to exist on their own. This is not possible when using the strong composite relationship. When the higher-level interaction is deleted, it should be possible to retain the interactions that have been part of this interaction. Finally, we do not want such a rigid relationship for our decomposition where each sub-interaction is only owned by the interaction of which it is a part and cannot be part of another higher-level interaction. It should be possible that the interaction graph is reconstructed in another way, which means sub-interactions could become part of other interactions as well.

Second, there is the weak form of aggregation also known as shared aggregation that is nothing more then a special form of association that specifies a whole-part relationship between the aggregate (whole) and a component part. In this case, the part may be included in several aggregates and the owner of the part can

(4)

change over time. In addition, it does not imply the deletion of the parts when an aggregate referencing is deleted [9]. It can be argued that that the explicit FlowSet symbol in the decomposition is similar and therefore redundant. In a decomposition graph, it could be enough to show only ordinary association relationships between the interactions. Nevertheless, because we want to explicitly depict that sub-interactions are part of higher-level interactions we have adopted the use of an aggregation-like symbol that has some new

characteristics over the UML aggregation symbols.

We believe that both these forms of UML aggregation are bound to a static view. The TALL interaction decomposition diagrams should show also an (implicit) order between the interactions in the interaction decomposition. According to [10] UML class diagramming is a non-temporal conceptual modelling technique.

For the interaction decomposition, we want to express a dynamic phenomenon.

Figure 2 Example of an interaction decomposition of a Sales interaction.

The interaction decomposition can be used to describe a prescriptive model of a process. It focuses on understanding the specific problem domain by analyzing primarily the role-based interactions between agents, and depicts a possible way of enacting the interactions to achieve the purposes of a BP. From an organisational perspective (where roles have usually precedence over interactions, depending on the kind of organisation that is investigated), it shows a division of labour. Other approaches [11] emphasise that a certain (process) plan or organisational (or individual) behaviour is generated because of a goal. The difference with a goal decomposition is that goal-orientation focus on “what” should be done, whereas interactions specify also “how”

it should be done. Another difference is that a goal describes motivation (internal behaviour) whereas an interaction describes a (collective) activity (external behaviour). However, the goal concept is still an open issue in TALL. For newer versions, we would like to make the goal concept more explicit, both from an individual- agent perspective, as well as from an organisational perspective. Truly, we do see that goals are very important to agents and their interactions, and should be part of any agent-oriented framework.

4 Modelling and executing the decomposition

It is up to the modeller to decide how the BPs of an organization are modelled using the interaction

decomposition. This means the decomposition can be either modelled top-down or bottom-up. In the first case, the modeller identifies the root interaction and then decomposes it into ‘smaller’ interactions to create the decomposition. In the second case, the modeller starts identifying ‘smaller’ interactions that occur between people and/or computer systems at a low level. The lower-level interactions are then assembled into more generic interactions to create the decomposition. Of course, practical modelling exercises show that a mixed method (top-down and bottom-up combined) is the best. The result is a set of potential prescriptive models for different versions of the internal processes and a pool of labelled generic interactions (at various levels of composition), reflecting the collaborative work within the organisation.

At run time, the initiation of the interactions in the decomposition occurs ad-hoc. It starts when a specific trigger “activates” an agent (instance). This means that the agent has to do something with others in order to fulfil the purpose meant by the trigger. The agent has to know what interaction(s) is(are) necessary for this fulfilment and also what role(s) it is required to play. The interaction is instantiated and other agents are “called”

to play the remainder of the roles. This mechanism produces a cascade of interactions that are part of the decomposition. Because of the run-time context, it is possible to have interactions in the decomposition that are not executed. Some interactions are only executed in certain execution contexts. If these contexts are not set

(5)

when the interaction is to be executed, these interactions become inoperative. In addition, it is possible to have multiple interaction threads on the implementation level that are started independently by different agents. The running interactions are finally completing parent interactions in the decomposition model, and these can be considered as finished process instances.

The real execution of these interactions occurs actually only at the lowest of the graph (the “elementary”

interaction, level, that have no “children”). Higher-level interactions are split in elementary interactions. The elementary interactions are bi-polar interactions because they only involve two roles. The parent interactions are

“executed” by executing the child interactions. The bi-polar interactions are not decomposed any further. Fig. 3 shows the link between the interaction decomposition on the upper side and the process diagrams that depict the IBs of agents on the bottom side. It shows a high-level (conceptual) interaction involving seven roles that is decomposed into smaller interactions. If the organisation has a single process and all the process instances look the same, the decomposition will be a single tree (like in a traditional workflow based system). The content of the entire interaction decomposition is not shown but it does show that at the lowest level all interactions comprise two roles. The tree shows a prescriptive plan for execution. One of the bi-polar interactions has started to execute; agent instances are playing the roles by executing their IBs.

Figure 3 The link between the interaction decomposition and the Interaction Beliefs of agents.

Executing IBs for the completion of the elementary interactions and assembling them bottom-up to form the parent interaction enables us to incorporate change much easier. In [6] it is explained that one obvious use of the flexibility of agent-based systems is to ease the incorporation of changes. The authors stress that at execution time multi-agent systems have an advantage over most other forms of system in adapting to change. The individual IBs of the agents executing the bi-polar interaction can be targeted individually and change is implemented bottom-up. Overall, the bottom-up assembly of child interactions to form the parent interactions at run-time may cause the decomposition tree to be reconstructed in another (improved) way then it was modelled as a prescriptive model for the BP (either top-down or bottom-up).

5 Conclusion

This paper presented a way to decompose interactions occurring between agents playing defined roles. The basics of the syntax and semantics of an interaction decomposition have been described and a new TALL diagram type has been created for this purpose. A consistent decomposition can be created by modelling via a high-level overview and then drill down to lower levels. Alternatively, one can start with a view on elementary interactions and then assemble them to form parent interactions, or preferably, use a mix of the two.

(6)

The Sales interaction example is only a small part of a sales organization. If we would try to model such a BP with for example a Workflow Management System (WfMS) it would be very hard to identify a single case that flows through the process. For the sales example, potential cases would be order, product, request for

information etc. Verbeek [12] mentions that the fundamental property of a workflow process is that it is case- based which means every piece of work is executed for a specific case. Usually, the same task is executed for many cases and this means that a generic process, like putting a tire on a wheel, is not a workflow process because it is independent of a specific bicycle. The goal is to handle many similar cases in an efficient and effective way. Interactions are more like ‘one of a kind’ processes that are hard to capture a priori (in a central process definition) by an external observer that sees the entire process because of their complex, distributed, and emergent nature. Therefore, they are hard to model with workflows. By decomposing interactions, we are able to model loosely coupled, ad-hoc, and emergent BPs.

The new Interaction Decomposition (diagram) allows users to make an analysis of the interactions needed to achieve the goals of the organization under consideration. Given a very complex interaction, it is not very useful for analysis to create a single interaction representing and involving all roles. Parent interactions in the

decomposition are actually only conceptual processes instead of actual interactions between all roles. By using the interaction decomposition, presented in this paper, interactions can be divided into sub-interactions that are easier to understand, model, and execute. The interaction decomposition is an analysis model with a focus on the external behaviour of agents. At a generic level, all interactions in the decomposition are in fact “types” of interactions. Agents are involved at runtime when the generic interactions become interaction instances. Using the TALL FlowSet symbol as the decomposition symbol, we stress that interactions are executed in a certain topological order. Therefore, the interaction decomposition can also show a dynamic view. We have stressed that the generic interaction graph only shows a prescriptive structure of the interactions. The actual process routing of the interactions is determined at run-time by the agents and their IBs. By not using the decomposition as a rigid execution scheme the flexibility of the overall system (organisation) and the autonomy of the agents is maintained.

References

1. Snoo, C. De., 2005. Modelling planning processes with TALMOD. Master Thesis. University of Groningen.

2. Stuit, M., 2006. Instantiation of Local Agent Behaviours from Agent Interactions: A Decentralized Enactment Architecture. Master Thesis. University of Groningen. To Appear.

3. Klügl, F., Oechslein, C., Puppe, F., and Dornhaus, A., 2002. Multi-agent Modelling in comparison to Standard Modelling. In: F.J. Barros and N. Giambiasi, eds. AIS 2002: Artificial Intelligence, Simulation and Planning in High Autonomy Systems. SCS Publishing House, 105-110.

4. Wagner, G., 2003. The Agent-Object-Relationship metamodel: towards a unified view of state and behavior.

Information Systems, 28 (5), 475-504.

5. Koning, J., and Romero-Hernandez, I., 2002. Thoughts on an Agent Oriented Language Centered on Interaction Modeling. In: Proceedings International Symposium and School on Advance Distributed Systems (ISSADS 2002), 11- 15 November 2002 Holland. Springer-Verlag, 2002.

6. Miles S., Joy, M., and Luck, M., 2000. Designing Agent-Oriented systems by Analysing Agent Interactions. In: P.

Ciancarini, and M. J. Wooldridge, eds. Proceedings of the First International Workshop on Agent-Oriented Software Engineering (AOSE-2000), Limerick, Ireland, 171-184.

7. Foundation for Intelligent Physcial Agents (FIPA), 2003. Modeling Notation Source - MESSAGE. Document author:

Radovan Cervenka.

8. Steimann, F. 2001. Role = Interface: A merger of concepts. Journal of Object-Oriented Programming, 14 (4), 23-32.

9. Object Management Group (OMG), 2004. UML 2.0 Superstructure Specification. Version 2.0 (OMG, 2004-08-10).

10. Cabot, J., Olive, A., and Teniente, E., 2003. Representing Temporal Information in UML. In: P. Stevens, J. Whittle, and G. Booch, eds. The Unified Modeling Language: Model Languages and Applications, proceedings of 6^th International Conference, October 2003 San Fransisco. Springer Verlag, LNCS (2863), 44-59.

11. Simon, G., Mermet, B., and Fournier, D., 2006. Goal Decomposition Tree: An Agent Model to Generate a Validated Agent Behaviour. In: M. Baldoni, U. Endriss, A. Omicini, and P. Torrini, eds. Proceedings Declarative Agent Languages and Technologies III: Third International Workshop, 25 July 2005 Utrecht, The Netherlands. Springer Verlag, LNAI (3904), 124-140.

12. Verbeek, H.M.W., 2004. Verification of WF-nets. Thesis (PhD). Technische Universiteit Eindhoven.

(7)

Embodied Interactions: a Way to Model and Execute Complex and Changing Business Processes with Agents

Marco Stuit¹, Nick B. Szirbik¹

1 The Agent Laboratory, Faculty of Management and Organization, University of Groningen, Nijenborgh 4, NL-9747 AG Groningen, The Netherlands, +31 (0)50 363 8497

{M.Stuit@rug.nl, N.B.Szirbik@rug.nl}

Abstract. Interaction refers to an abstract and intangible concept. In modelling, intangible concepts can be embodied and made explicit. This allows to manipulate the abstractions and to build predictable designs. Business processes in or- ganisations are in fact reducible to interactions, especially when agent-oriented modelling methods are employed. Business processes represented as interaction structures can appear at different levels of abstraction. There is a compositional coupling between these levels, and this necessitates a method that allows dynamic de/re-composition of hierarchically organised interactions. We introduce the novel concepts that allow interaction-based diagramming and explain the syntax and semantics of these constructs. Finally, we argue that a business process decomposition with interactions allows more organisational flexibility and agent autonomy, providing a better approach in complex and ever-changing situations than current solutions.

1 Introduction

Each modelling approach has a specific focus. It could be the “entity” concept, or the

“activity”, or “location”. In our approach, the most important is the concept of inter- action that allows for an easier modelling of complex and distributed business proc- esses (BPs). Classic BP modelling takes a centralistic standpoint; an external observer sees the entire process model as a monolithic whole. In our approach, due to the agent-orientation, each participant has its own local view of the process. These local views, known as interaction beliefs (IBs), are linked to explicit depictions of named interactions. These beliefs are used by agents that play the roles that are attached to an interaction. Interactions are compositional; they can be grouped and divided. A method for decomposition of interactions is used to identify ‘smaller’ interactions in a top-down analysis, or the ‘smaller’ interactions can be grouped in more complex ones in a bottom-up approach (or a mix of these two). An agent-oriented modeller, an agent-based organisation simulation tool, or a multi-agent system that supports the organisational processes can use a pool of interactions, in which all interactions are explicitly and globally named. The beliefs of the agents will reflect the information from this pool.

(8)

This paper is organised as follows. Section 2 introduces and justifies the use of the interaction concept by analysing it from both a philosophical and pragmatic perspective. The relation with similar approaches is discussed. In section 3 we explain the syntax and semantics of our interaction diagrams. Section 4 presents the de/re- composition of interactions. Patterns to model the de/re-composition are discussed, a de/re-composition symbol is introduced and compared to UML, and the usage and execution of the de/re-composition is explained. Finally, we present a discussion, conclusion and some directions for future work in the last section.

2 Agents, roles, and the embodiment of the interaction concept

The application of our research in multi-agent systems is in the area of BPs. We analyse and model organisations that we view as multi-agent systems, and use the conceptual models to build designs for agent systems that support the BPs within these organisations. We are developing a framework (AGE – i.e. Agent Growing Environ- ment, see [11]), which uses a language (TALL – i.e. the Agent Lab Language, see [14, 17]) for multiple functions: analysis, specification, conceptual modelling, interac- tive simulation/gaming and dynamic visualisation, design, implementation, and test- ing.

2.1 Using agents and roles for business process modelling

There are three main concepts in the TALL language: agent, role, and interaction.

Obviously, the agent concept has to be explicit in any universe of discourse and/or language that is pragmatically used in domains where the agent paradigm is employed. Many formal languages tend to associate the role played by an agent in an organisation with the agent itself (as a property) or define specialised types of agents.

However, we adhere to the ontological distinction made by Steimann [16], who considers that roles should be defined separately from agents. He states that in software development roles should be a sort of interfaces; in organisational modelling they should be dynamic placeholders for the actor/agent participants. The main reason is that a role itself has no meaning outside its context and has to be filled with persons, things or places to have a meaning.

These persons, things or places are named natural types. In general, an agent in TALL belongs to a natural type (i.e. is an instance of the natural type), under all cir- cumstances and all times. An agent can never drop its natural type without losing its identity. For example in TALL all agents belong to the natural type Agent which can- not be dropped without loosing their identity as an agent. Roles are filled with agents and these agents can leave their roles without losing their identity. For example the human agent George can leave the role of Business Manager without loosing its agent identity. In business environments, roles make sense only in the (organizational) context in which they are defined.

Another difference between agents and roles according to Steimann [16] is that roles, unlike classes, have “something dynamic” about them. An agent for example can take on several roles during its lifetime like Student, Programmer, and Tester etc.

(9)

Unlike entity types, playing several roles simultaneously is not unusual for the instances of certain natural types. For example a person can be a customer, supplier, and stakeholder at the same time.

In an organizational context, agents belong to agent groups (i.e. they are members of a certain group) that are generic sets of agents with similar skills – not necessarily based on the function assigned formally to the agent in the organisation. Agents can belong to more than one group, thus, these sets can overlap; also specialisation (sub- sets) can be used. The agent groups can be used to define an authorisation scheme in the organisation.

In TALL, roles are types with a dynamic nature, which cannot be instantiated.

They can add properties to the agents that play the role, and also may regulate the behaviour of these agents. We denote that an agent plays a role like in Fig. 1a. A role has a name and may have properties that have to be “implemented” by an agent. This diagramming method can be at a generic level, denoting what agent groups can play the role, but also at an instance level, denoting what agent members are currently assigned to that role. Moreover, the interpretation of such a diagram is temporally de- pendent. It can illustrate a plan (“these are the agents who will play the role”), or a snapshot (“currently, these are the agents playing the role”), or a trace (“these have been the agents that played the role”).

Fig. 1a & 1b. Example of an agent member playing a role (top) and an interaction representing the dynamic connection between two roles (bottom).

Within any organisation, by playing the roles, agents execute certain activities and always communicate with other agents – they cannot exist in isolation. That introduces the necessity to relate the roles. And this is the main reason for the interaction construct. Agents that play “connected” roles interact. We depict the fact that agents interact as in Fig. 1b (here at a generic level). The dynamic connection is illustrated between roles, and not the agents. To explain this choice in our language, we need to discuss the interaction concept in more depth.

2.2 Philosophical background

Interaction is defined as: “mutual or reciprocal action or influence” by the Merria Webster dictionary. This explains only the “what” aspect of this concept. To answer the “who” and “how” questions, a new definition can be: “Interaction is an observable action that happens when two or more entities have an effect upon one another”. From an organisational and social perspective, the entities are usually humans (or groups of humans). When viewed via the agent paradigm, the interaction can occur between two artefacts (like software agents, or simulated humans/organisations).

(10)

The concept of interaction is an intangible one. However, for pragmatic reasons, a symbol can be introduced to capture the presence of an interaction. Physics has various ways to model the interaction between objects; even these interactions are intangible (but yet observable and predictable). Thus, at an abstract level, the modeller will have a tangible way to deal with them. In the same way, a modeller of multi-agent systems could employ artefacts that make agent interaction tangible. Following this argument, we are supporting the statement that “an interaction can be seen as a standalone entity”. An entity that represents an abstraction of an intangible concept. The way to define such a class of entities is to identify its properties.

Sowa (see [15] pp. 60-62) discusses Peirce basic categories that comprises the triad of Firstness, Secondness, and Thirdness. Firstness is the conception of being or existing independent of anything else. It can be described by a monadic predicate P(x), which describes an entity x by its inherent qualities, independent of anything external to x. Secondness is the conception of being relative to, the conception of reaction with, something else. It requires a dyadic relation R(x,y) which describes some reaction between an entity x and an independent entity. Thirdness is the conception of mediation, whereby a first and a second are brought into relation. Thirdness requires an irreducible triadic relation M(x,y,z) which describes how an entity x mediates two entities y and z. Thirdness focuses on the intangible framework of activities that brings the first and second into relation. For example the legal system gives rise to the roles of Attorney and Client. Marriage relates the Wife and the Husband. Aviation relates the Pilot to the Airplane. The Business Enterprise relates the Employee to the Employer.

We argue that an interaction should be represented by a triadic relation. Interac- tions are conceptualised as the mediating Thirdness. We see the agents in a multi- agent system (artefactual or human/organizational agents) as natural types who corre- spond to the Firstness category. An agent exists independent of any external relationship. Roles played by the agents are Secondness because roles depend on an external relationship to agents. Interactions “bring” the roles and the agents into mediation.

The three main concepts that we use in our universe of discourse: agents, roles, and interactions together form a triad. In the next section we explain how this is integrated in a pragmatic framework for multi-agent systems.

2.3 Embodiment of the interaction concept for agent modelling

In a model in TALL, or during an agent simulation in AGE, interactions are explicit and “exist”. The modeller or the experimenter can create and manipulate the interactions, as reflections of observed interactions in a real BP. One can relate it to “embodiment”, meaning to make concrete and perceptible. In a formal context, embodiment of an abstraction raises the need for identity. Thus each interaction has to get a name (label). Naming can be achieved, according to the object oriented approach, in a two level scheme: generic name (or interaction class identity) and specific name (or interaction instance identity). The first level is useful for the beliefs of the agents, who should “know” what interactions are possible within the organisation, and the second is useful for simulation and BP monitoring purposes. “Name/identity” is the first property of an interaction.

(11)

An interaction can be seen as a “piece” of a BP. An interaction is performed to achieve something, and this leads to other properties. A simple solution is to define pre-conditions and post-conditions. Some agent-oriented methods propose to define

“external goals” [13]. There is a generic precondition for all interactions. There should be at least two roles involved. The roles can be linked to an interaction stati- cally or dynamically. In a static framework, an interaction will have always the same pre-defined roles. For more flexibility, it is better to have the possibility to change dynamically the number of roles involved in an interaction, even to link new roles that did not exist (in the specific universe of discourse) before the interaction started.

Roles linked to interactions can be considered as implicit properties here. Of course, roles are more than that; they help describe the organisation’s structure and nature.

Current BP support approaches put the description of the process outside the ac- tors/agents that execute that process. In a typical agent-oriented approach, the description appears as beliefs of the agents, and it is inherently distributed. That gives no

“power” to the organisation to enforce behaviour. For a modeller of BPs, a process description that resides solely in the beliefs of the agents is not really making sense, unless an agent has the “authority” to enforce behaviour over other agents. We believe that a simpler way to enforce behaviour is to attach an interaction description to the interaction entity. In the organisational paradigm, this description is called a protocol. These protocols can be also considered as properties of the interaction. We discuss protocols in more detail in section 3. Other operational properties can be useful in an agent-simulation environment. Interactions can have time attributes, like start- time, end-time, run-time variables, etc.

Interactions are triads of (interaction – roles – agents) names. A modelling envi- ronment can use these triads as a pool of interactions, which captures what happens in an organisation. Being “pieces” of BPs, they serve the purpose to build a description of a BP. This induces also a temporal dependency. The overall process description can be a plan, a runtime snapshot or a log of a past process. The agents in the organisation should have beliefs about this pool of potential interactions, in order to initiate them. We explain later how various triggers induce the agents to initiate interactions.

2.4 Related work

Other works [5, 7] pointed out the importance of agent interaction and devised ways to capture the patterns and execution procedures for interaction. In [4] it is explained that it is not sufficient to concentrate on the local behaviour of agents as the interaction execution is often the most difficult part due to synchronization problems between agents. To illustrate the interaction execution a special diagram can be used. In UML for example, sequence, collaboration and activity diagrams are showing how messages flow between participants. AUML (agent UML, see [10]) uses the same diagramming techniques. Wagner [18] introduces the interaction pattern diagrams and interaction sequence diagrams. In the former, the nature of the interaction is explained (showing what kind of information flows can occur), and in the latter, the particular sequence of messages is indicated, like in UML behaviour diagrams. Still, these techniques take all a centralistic point of view. Except for the interaction pattern diagram

(12)

of Wagner, all indicate a priori the execution procedure for the interaction, as it is en- forced on the participants.

MESSAGE (see [3]) introduces the interaction view. A special symbol is used to denote interaction. Roles, represented by special symbols, are linked to the interaction. The technique also shows the flows of information using UML notation. The execution description is separated, by using an Interaction Protocol description, cor- responding to a UML sequence diagram. The collection of Interaction Protocols defines how agents are performing their overall activities. It adopts still a centralistic approach. The main step forward in MESSAGE is the decoupling between generic interactions and the way they are performed. Flexibility can be achieved by having more – alternative - interaction protocols for each kind of interaction. It is not explicitly stated, but also in Wagner’s approach, it is possible to have more than one Inter- action Sequence Diagram for one Interaction Pattern.

None of these approaches considers that an agent can have explicit beliefs about the interaction. Moreover, they consider that all agents behave according to the pre- defined protocols (sequences). This implies that the agent design is going through the

“external-to-internal route” or, as Wagner calls it, the internalisation process [18].

First, the modeller will have to understand from a central point of view what is hap- pening, and design the internal behaviour of the agent accordingly. We argue that it is easier to understand first what an agent beliefs about the interaction and build an internal model, and only after try to achieve coherence, not necessarily by aligning a- priori all these “local behaviours” of the agents. Some BPs are difficult to understand from a single perspective. In these cases the analysis can start from a local point of view, and global understanding of the process is not even necessary a priori. The agent approach enables the modelling and support of a distributed, heterogeneous, constantly evolving and not “well known” process; the humans who are carrying out the process do not have a precise overall view either. In addition, the agent paradigm allows for conflicting process views. Most human organisations function because the participants know partially what to do, and nobody has necessarily a global view.

Even the high level managers have a limited view, because they see the process from the “highest point”, but they do not have to understand the details. They delegate this to lower level managers. Especially in flat organisations, delegation and decisional autonomy restrict the view of one participant. Complex organisations tend to be any- way incomprehensible for humans, and efforts to model “everything” are usually fu- tile attempts [12].

Another shortcoming of these methodologies refers to the choice used for the pro- cedural description. All these are sequence diagrams and these do not allow for “internal” routing constructs that enable the modeller to illustrate parallelism and choice that can appear in the local behaviours of the agents.

BPs are often supported by WfM (workflow management) systems and/or BPM (business process management) systems. Petri nets and various extensions are used here to model the BPs. Such a model represents a purely centralistic view lacking the flexibility and changeability necessary to capture the ever-changing nature of processes in dynamic organizations. Probably this was the reason why agent behaviour modelling with Petri nets was not a favourite technique. In TALL and in AGE the behaviour of agents is explicitly modelled with an extension of Petri nets: Behaviour Nets [6]. In our approach, the interaction is performed after the local behaviours

(13)

(known as Interaction Beliefs) are aligned. There is no centralistic view and in advance a lack of consistency between beliefs is allowed.

3 Modelling embodied interactions in TALL

For the modeller interactions are initially just labels that capture the nature of the specific activities done in a “bounded” area of activities between agents. As previously stated, roles and interactions are linked; at least two roles are needed to show the con- text where the interaction takes place. At a conceptual level, even if we depict an in- teraction as a single symbol, one assumes implicitly (given his mentally enacted background) that roles are involved.

3.1 Organisational modelling with TALL

The modeller has the choice either to identify first what kinds of interactions are observable, either to enact a role scheme (usually a hierarchy) and “embody” the interactions that are observable between roles. In the first approach, roles are to be defined (or identified) in the second step. This choice between “roles-first” or “interaction labels first” depends on the kind of organisation that it is being modelled. Bureaucracies for example allow the modeller to easily identify first the roles, and an eventual hier- archical tree of these. On the other side of the organisational spectrum, in the so- called “ad-hocracies” [8], which are flat organisations, the analysis should start first with the identification of interactions and only after roles can be “discovered”. Real organisations are somewhat in between these two extremes, and the modeller gener- ally identifies interactions and role names in parallel. We call this analysis result “the organisation’s pool of interactions”.

The agents that are forming the organisation can be represented as a pool of agent members. This pool can be structured in groups (as discussed in paragraph 2.1). Cur- rently, these agent groups are rigidly associated to roles in the organisational hierarchy. For example, an agent with secretarial skills is assigned to the secretary role. Un- fortunately, such a static association will assign an agent group to all the interactions where that role appears.

In TALL, we adopt a more flexible structure. It is possible to assign agent groups (depicted like generic agents) to the roles that are linked to an interaction (as in Fig.

1b). This denotes a constraint, showing that only agents of that group are authorised to play that role in that interaction. This enhances considerably the flexibility of the authorisation scheme, allowing the same role to have different authorisation schemes, depending on the interactions linked to this role. Finally, the pool of interactions is composed by triads, or in modelling terms, agent-role-interaction diagrams (ARI generic diagrams). As we have stated already, even if the agent groups are not illustrated there, the “universal agent” (the set encompassing the whole agent pool) is always assigned to any role. Fig. 1b is an example of an ARI generic diagram, showing that the agent members of those agent groups are authorised to play the depicted roles in that particular interaction called X.

(14)

Fig. 2. Example of an ARI diagram (at instance level) with two roles attached that are being played by agents according to their own local view.

ARI diagrams can be expressed at instance level also, as in Fig. 2. The ARI instance level diagram depicts an interaction instance and shows agent members which are assigned dynamically to play the roles. In the diagram roles are never depicted as instances. The local views of the agents participating in the interactions are represented by the so-called Interaction Beliefs (IBs). This concept is not thoroughly presented in this paper, more about its meaning and content can be found in [6]. Basically, the execution of an interaction is the coordinated execution of (local) IBs provided by the participating agents, as is depicted in Fig. 4. The IBs are represented in ARI diagrams by a chevron symbol that appears at the agent side of the association end of the agent- role connector. The connector, an arrow with a hollow triangular head, with an interrupted line as shaft, defines an “[agent] playing [role]” – relationship, at the instance level. It is convenient to speak of an agent group as “populating” a role (by using the same arrow symbol) and of a member as “playing” a role [16]. The generic level ARI diagram can also show multiplicity between agents and roles. In an organisation, an agent that wants/needs to play a role must be authorized to play that role.

This authorization is determined at run time by checking (by consulting the generic level ARI diagram) if the agent group has the relation “populates” with that specific role.

3.2 Interaction Beliefs and Protocols

The TALL Interaction Belief (IB) defines both the (intended) behaviour of an agent playing a role using a swimlane workflow-like description (based on Petri nets) of the activities, states, and messaging channels as seen by an agent member in a specific interaction (see figure 4). At the modelling level, an IB is a representation of that

“piece” of the BP that is performed as an interaction in the way it is seen from a local agent perspective. An agent has an intended behaviour (do not confuse this with the IB itself), but also a belief or acquaintance model about the behaviour of other agents participating in the interaction. This part of the IB is called expected behaviour. If all agents are linking their intended behaviours together, a process view about how the interaction should be performed is enacted. Of course, if these behaviours are not matching, the interaction will fail. One of the main features of the AGE framework is that it allows these behaviours to be “aligned”. Alignment refers here to the soundness of the resulting Petri Net [1]. It is possible that processes deadlock, due to different reasons. In AGE, the Petri Net that results from the combination of IBs can be checked and modified in a way that will ensure the soundness and termination of the

(15)

interaction seen as a sub-process description [6]. This alignment can be realised auto- matically or manually, depending on the level of severity of the deadlock situation.

Some simple deadlocks can be identified and formalised, allowing for automatic alignment, but other will necessitate human intervention.

Fig. 3. Example of an interaction with a protocol attached to it.

In TALL, the chevron symbol is used for two denotational purposes. The first has been described above and depicted in Fig. 2. The other one is that it can also graphi- cally represent a protocol. In this case, only the place of the symbol is different, as shown in Fig. 3. It shows a generic interaction X that is regulated by a protocol. The description of a protocol is also a Petri Net with swimlanes, where for each role, certain activities and routings are imposed. The meaning of this concept is centralistic, like the interaction protocols in MESSAGE [3] and interaction diagrams in AORml [18]. If agents perform an interaction that has a protocol (or more) attached to it, the AGE framework will try first to make the agents obey the protocol. They have to try to adopt the behaviour that is described in the associated swimlane to the role they are playing. However, we allow in our framework that the agents have the power to overrule the protocol, especially if it is not possible to apply it in an unexpected context.

Also, they can change the content of the protocol, if this is considered at that moment necessary.

In an extreme case, protocols can be attached to all the interactions from the pool.

Actually, this is exactly what MESSAGE and AORml propose. This is also very similar to a workflow enactment machine with agents (but allowing less flexibility). In AGE, even when all interactions from the pool have associated protocols, the agents can still overrule them. On the other extreme, none of the interactions is regulated by protocols. Here, agents have to rely only on their own IBs. In real organisations, some protocols can be useful, by regulating those interactions that are routine and predictable, enabling “newcomer” agents to interact even if they do not posses yet the necessary abilities (i.e. IBs).

4 Interaction De/Re-composition

Interactions, occurring between agents playing roles, can be identified at different levels of abstraction. On a high level of abstraction, a BP can be conceptualized as a single, over-encompassing interaction (see Fig. 4, the top interaction). This should not be confused with an operational description of a BP, as a workflow. It just shows that a BP has a number of roles involved, and together with the ARI diagrams indicates

(16)

what agents can be involved. From a modelling perspective, such a representation is very simple but at the same time its simplicity reduces the expressiveness and richness of the model. From the perspective of the agents performing the roles, such a conceptual interaction is very complex and undesirable.

Fig. 4. The link between the interaction decomposition and the Interaction Beliefs of agents.

4.1 Patterns to de/re-compose interactions

To be useful, it is necessary to decompose a high level interaction into ‘smaller’ interactions in a top-down analysis fashion. Alternatively, it is possible to have a pool of interactions where all interactions are “elementary”. Such a set of interactions is not very useful either, because the triggering of an interaction may occur at a higher level of abstraction. There is clearly a need to define interactions that are “in between” the overall BP-describing interaction and the elementary interactions; these are structured on different levels of abstraction in the interaction pool.

One can define a priori a complete compositional scheme between the interactions that appear on successive levels of abstraction, looking as a tree structure, where elementary interactions are grouped in more complex interactions until the root interaction is reached. However, this will reduce drastically the flexibility of the execution of

(17)

the BP as a set of on-the-fly executed interactions. Such a tree becomes just another way to illustrate the structure for a workflow execution, conditioning rigidly the way the BP is executed. Our approach aims at defining various “partial recipes” of compo- sitionality, covering local areas of the interaction pool and insuring the existence of different possible interaction compositions. In this way, we build a supplementary pool of diagrams that show potential ways of how some of the interactions can be de- constructed or reconstructed on different levels. We call this pool the patterns pool.

The modelling of a prescriptive IDR can proceed either top-down or bottom-up. In the first case, the modeller identifies the root interaction (which can represent the whole BP) and then decomposes it into ‘smaller’ interactions to create the decomposition. In the second case, the modeller starts identifying ‘smaller’ interactions that occur between people and/or computer systems at a low level. The lower-level interactions are then assembled into more generic interactions to create the re-composition.

Of course, practical modelling exercises show that a mixed method (top-down and bottom-up combined) is the best.

4.2 The FlowSet symbol

For the pattern pool, a new diagram type called the Interaction De/Re-composition Diagram has been introduced in TALL. This IDR diagram shows prescriptively how a higher level interaction can be structured as a graph of lower level interactions.

Fig. 5. Example of an interaction decomposition of a Sales interaction.

Fig. 5 shows an example of a Sales interaction that is “formed” by sub-interactions.

These are linked to the higher level interaction by a symbol that we call TALL FlowSet (FS). This has been created to depict that sub-interactions together form a set of ‘flowing’ interactions that are executed in a certain topological order. Parallel execution of the child interactions is allowed. The order of execution is determined during the coordinated execution of the IBs. The diagram is “weakly” prescriptive; it is not always necessary that all child interactions are executed, in order to complete a parent interaction. There can be more than one prescriptive IDR diagram for a high level interaction, allowing more recipes for the execution of a complex interaction.

The whole set of prescriptive IDR diagrams will form the pattern pool.

(18)

4.3 Comparison with UML

The FS symbol is comparable with the UML aggregation symbol. In UML, there are two forms of the aggregation relationship. The first is the strong form of aggregation called composition. In [9, p.38] it is stated that: “Composite aggregation is a strong form of aggregation that requires a part instance be included in at most one composite at a time. If a composite is deleted, all of its parts are normally deleted with it“. The second level of aggregation proposed in UML corresponds to a weak form of aggregation or shared aggregation. This is a special form of association that specifies a whole-part relationship between the aggregate and a component part. Thus, the part may be included in several aggregates and the owner of the part can change over time.

In addition, it does not imply the deletion of the parts when an aggregate referencing is deleted [9].

Lower-level interactions should be, in our view, able to exist on their own. This is not possible when using the strong composite relationship. When the higher-level interaction is deleted it should be possible to retain the interactions that have been part of this interaction. Also, it is not desirable that a low level interaction is only owned by a single high level interaction. It should be possible that during run-time the interaction graph is reconstructed in another way which means sub-interactions could become part of other interactions as well.

It can be argued that that the explicit FlowSet symbol in the decomposition is simi- lar to the weak form of UML aggregation and therefore redundant. The main difference with our approach is that both these forms of UML aggregation are bound to a static view. The TALL IDR diagrams show also an (implicit) order between the interactions in the interaction decomposition. According to [2] UML class diagramming is a non-temporal conceptual modelling technique. For the interaction decomposition we want to express a dynamic phenomenon.

4.3 Different ways to use IDRs

From an organisational perspective where roles have usually precedence over interactions, depending on the kind of organisation that is investigated, the IDR diagram shows a division of labour. Other approaches [13] emphasise that a certain plan or or- ganisational or individual behaviour exists because of a goal. The difference between the IDR diagram and a goal decomposition is that goals focus on “what” should be done, whereas interactions specify also the structure, possibly the order, and the potential participants. The main difference is that a goal describes motivation (internal behaviour) whereas an interaction describes a (collective) activity (external behaviour).

For another purpose, the IDR diagrams can be used to track a running process. The AGE framework allows simulations of BPs that are enacted as dynamic sets of interactions. The active (instantiated) interactions can be illustrated in a sort of “cockpit- view” diagram. Each new interaction that is triggered by an agent can appear dynamically in the picture, and also the agents that are playing the roles can be shown. Inter- actions can be connected dynamically to a higher level interaction, or they can be decomposed into “smaller” interactions. The way the de/re-composition is done can be

(19)

based on a prescriptive IDR diagram from the pattern pool, or can be determined on the fly. When the process simulation has ended, the IDR diagrams can be used for a

“post-mortem” of a BP simulation. This “trace” of IDRs shows what interactions have occurred and who played the roles in these interactions. We assume that each interaction instance is different from another, thus allowing a high degree of flexibility.

However, certain (partial) patterns occur, and these can be “mined” from a repository of traces and can be added to the pool of patterns – which will become in time a repository of prescriptive de/re-compositions. However, the information about “how”

these should be executed resides as beliefs of the agents – with the reserve that some protocols can be added to the ARI diagrams and also emphasised in IDR diagrams from the pattern pool.

4.4 Executing the process as a dynamic set of interactions

At run time, the initiation of an interaction that may belong to an IDR from the pattern pool occurs ad-hoc. It starts when a specific trigger “activates” an agent (member).

The agent has to know what interaction(s) is(are) necessary at this moment and also what role(s) it is required to play. The interaction is instantiated and other agents are

“called” to play the remainder of the roles. This mechanism produces a cascade of interactions that could be described in a prescriptive IDR. Because of the run-time context it is possible to have interactions present in the IDR that are not executed. In addition, it is possible to have multiple threads (of the same interaction from the interaction pool) that are started independently by different agents.

Fig. 4 shows the link between the interaction decomposition on the upper side and the diagrams that depict the execution of the IBs of agents on the bottom side. If Fig.

4 would depict a single prescriptive IDR (except for the bottom left side interaction that has started to execute) this would mean that the organisation has a single BP and all the process instances are similar. In this case the decomposition will be a single tree and the execution is similar to a traditional workflow-based system.

At the bottom left side of Fig. 4, we show how a cockpit view IDR looks like. For example, the agent Ag_1 is triggered to start an elementary interaction. It will instan- tiate an interaction and it will select the appropriate role for itself. The AGE environment will act as an “interaction mediator” and it will find an agent to play the other role (in this case agent Ag_2). Both agents will provide an IB that will perform the interaction by executing their intended behaviours.

An agent can trigger an interaction that is not elementary. In this case, this interaction has to be decomposed (guided by a prescriptive IDR or ad-hoc) into component interactions until the elementary level is reached. Agents that trigger an interaction, at any level, have the necessary IBs for this complex interaction. It could be that in a specific organisation there is an agent that “understands” the whole BP. That means that this agent has a complete IB that can be applied to the top level interaction in Fig.

4, and this interaction can be triggered directly by this “omniscient” agent. In this situation, the execution will be performed top-down, and it will be equivalent to a workflow execution. In flat organisations, which are our target domain, interactions are typically triggered at the middle and lower levels of the IDR diagrams.

(20)

If an organisation adopts a software solution based on agents supporting its BPs we believe that it is best used when executing the “low level” interactions. These tend to be more stable and simple, and/or can be regulated by protocols, making their automatic execution easier. Typically, higher level interactions are triggered by humans, and at the lower levels of decomposition, software agents will be delegated to take over the routine interactions. This will still allow for flexibility on the higher levels of the de/re-composition, but also will ensure stability on the lower levels – especially if the organisational learning process has enacted various protocols at this level.

5 Discussion, future work and conclusions

We have argued that the interaction concept can be useful to analyse, model, and simulate organisations in BP-oriented and agent-oriented ways. Also, semantics for the execution of these interactions can form the basics for implementing agent-based software support systems for BPs. Interaction, as an abstract and intangible concept, can be explicitly represented (embodied) as an agent-role-interaction triad. We also argue that the modelled organisation should build a pool of interactions, in the form of ARI diagrams. Also, based on patterns that emerge with experience, a pool of prescriptive recipes that prescribe how to dynamically structure these interactions (IDR diagrams) can be built. The syntax and semantics of an interaction decomposition has been described, showing how interactions can be triggered and chained in top-down and bottom-up fashion.

Given a very complex interaction, it is not very useful for analysis to create a single interaction representing and involving all roles. Also, it is very complex for the agents to maintain huge interaction beliefs (IBs) that help them perform such a complex interaction. By using the interaction decomposition, interactions can be divided into sub-interactions that are easier to understand, model, and execute. Alternatively, a bottom-up approach can group elementary interactions into higher-level ones. The interaction de/re-composition is basically an analysis model with a focus on the external behaviour of agents.

The next step in our research will be to formalise the de/re-composition process, in order to have a precise operational semantics, allowing the agents in the AGE environment to make use of the patterns pool. This is necessary also for the visualisation purposes; to have clear semantics for what is exactly shown in the cockpit view during simulations. Another interesting future direction is towards building IDR based representations for the post-mortem analysis. This will allow the analysts to investi- gate past simulations and infer new IDRs that can be added to the patterns pool.

Currently, we have no explicit representation of goals in our framework. We consider that there is a strong conceptual link between business processes, interactions and goals, and we intend to explore the nature and applicability of this link. A more elaborated mechanism for authorisations and explicit representations of responsibility is also necessary. Finally, a methodology to apply the models in a consistent way is needed.

Business processes can be represented as static structures, like Petri Nets, and workflow representations. This ensures discipline, stability and repeatability in an or-

(21)

ganisation. However, it produces rigidity, centralistic views, and obsolescence. We argued that a novel way to enact complex, distributed and ever-changing BPs, based on de/re-composition of interactions, ensures more organisational flexibility and also more autonomy for the participants. We believe that the first step to achieve this is by adopting an agent-role-interaction based worldview.

References

1. Aalst, W.M.P. Van Der., 2000. Loosely coupled interorganizational workflows: modeling and analyzing workflows crossing organizational boundaries. Information & Management, 37 (2), 67-75. Available from: http://is.tm.tue.nl/staff/wvdaalst/publications/p99.pdf 2. Cabot, J., Olive, A., and Teniente, E., 2003. Representing Temporal Information in UML.

In: P. Stevens, J. Whittle, and G. Booch, eds. The Unified Modeling Language: Model Languages and Applications, proceedings of 6^th International Conference, October 2003 San Fransisco. Springer Verlag, LNCS (2863), 44-59. Available from:

http://www.lsi.upc.es/~jcabot/papers/UML03.pdf

3. Foundation for Intelligent Physcial Agents (FIPA), 2003. Modeling Notation Source - MESSAGE. Document author: Radovan Cervenka. Available from:

www.auml.org/auml/documents/MESSAGE.doc

4. Klügl, F., Oechslein, C., Puppe, F., and Dornhaus, A., 2002. Multi-agent Modelling in comparison to Standard Modelling. In: F.J. Barros and N. Giambiasi, eds. AIS 2002: Arti- ficial Intelligence, Simulation and Planning in High Autonomy Systems. SCS Publishing House, 105-110. Available from:

http://ki.informatik.uni-wuerzburg.de/~kluegl/pubs/2002/kluegl_etal_ais02.pdf 5. Koning, J., and Romero-Hernandez, I., 2002. Thoughts on an Agent Oriented Language

Centered on Interaction Modeling. In: Proceedings International Symposium and School on Advance Distributed Systems (ISSADS 2002), 11-15 November 2002 Holland.

Springer-Verlag, 2002. Available from:

http://www.esisar.inpg.fr/lcis/cosy/Ivan.Romero/issads02.pdf

6. Meyer, G.G., and Szirbik, N.B., 2006. Behaviour Alignment as a Mechanism for Anticipa- tory Agent Interaction. Submitted to The Third Workshop on Anticipatory Behaviour in Adaptive Learning Systems (ABiALS 2006). Available from:

http://tbk15.fwn.rug.nl/gerben/publications/p4.pdf

7. Miles S., Joy, M., and Luck, M., 2000. Designing Agent-Oriented systems by Analysing Agent Interactions. In: P. Ciancarini, and M. J. Wooldridge, eds. Proceedings of the First International Workshop on Agent-Oriented Software Engineering (AOSE-2000), Limerick, Ireland, 171-184. Available from: http://www.ecs.soton.ac.uk/~mml/papers/aose00.pdf 8. Mintzberg, H., 1983. Structure in fives: designing effective organizations. Englewood

Cliffs, New Jersey, Prentice Hall.

9. Object Management Group (OMG), 2004. UML 2.0 Superstructure Specification. Version 2.0 (OMG, 2004-08-10). Available from:

http://www.omg.org/cgi-bin/apps/doc?formal/05-07-04.pdf

10. Odell, J., Dyke Parunak, H. van and Bauer, B., 2000. Extending UML for Agents. In: G.

Wagner, Y. Lesperance and E. Yu, eds. Proceedings of the Agent-Oriented Information Systems Workshop at the 17th National conference on Artificial Intelligence, Austin, 3-17.

Available from: http://www.jamesodell.com/ExtendingUML.pdf

11. Roest, G.B., and Szirbik, N.B., 2006. Intervention and Escape Mode: Involving Stake- holders in the Agent Development Process. In: L. Pagdam and F. Zambonelli, eds. Pro- ceedings of the 7^th International Workshop on Agent-Oriented Software Engineering

(22)

(AOSE), May 2006, Hakodate, Japan, 109-120. Available from:

http://tbk15.fwn.rug.nl/tal/downloadfile.php?id=31

12. Simon, H.A., 1982. Models of bounded rationality. Cambridge, MA [etc.], MIT Press.

13. Simon, G., Mermet, B., and Fournier, D., 2006. Goal Decomposition Tree: An Agent Model to Generate a Validated Agent Behaviour. In: M. Baldoni, U. Endriss, A. Omicini, and P. Torrini, eds. Proceedings Declarative Agent Languages and Technologies III:

Third International Workshop, 25 July 2005 Utrecht, The Netherlands. Springer Verlag, LNAI (3904), 124-140.

14. Snoo, C. De., 2005. Modelling planning processes with TALMOD. Master Thesis. Univer- sity of Groningen. Available from: http://tbk15.fwn.rug.nl/tal/downloadfile.php?id=28 15. Sowa, J.F., 2000. Knowledge Representation: logical, philosophical, and computational

foundations. Pacific Grove, CA: Brooks/Cole.

16. Steimann, F. 2001. Role = Interface: A merger of concepts. Journal of Object-Oriented Programming, 14 (4), 23-32. Available from:

http://www.kbs.uni-hannover.de/~steimann/published/JOOP-14-4.pdf

17. Stuit, M., 2006. Instantiation of Local Agent Behaviours from Agent Interactions: A De- centralized Enactment Architecture. Master Thesis. University of Groningen. Draft Ver- sion Available from: http://tbk15.fwn.rug.nl/tal/downloadfile.php?id=44

18. Wagner, G., 2003. The Agent-Object-Relationship metamodel: towards a unified view of state and behavior. Information Systems, 28 (5), 475-504. Available from:

http://www.informatik.tu-cottbus.de/~gwagner/AORML/AOR.pdf