Modelling organisational emergent behaviour using compositional role-based interactions in an agent-oriented language

(1)

Master Thesis

Modelling organisational emergent

behaviour using compositional

role-based interactions in an

agent-oriented language

by

Marco Stuit

University of Groningen, The Netherlands

Faculty of Management and Organization

Faculty of Economics

(2)

Modelling organisational emergent

behaviour using compositional

role-based interactions in an

agent-oriented language

Master Thesis Master of Science Business Administration Specialization: Business & ICT

Faculty of Management and Organization & Faculty of Economics University of Groningen, the Netherlands

February 2005 – July 2005

Student: Marco Stuit, M.Stuit@rug.nl

Student Number: 1153498

Supervisors: Dr. Nick Szirbik, N.B.Szirbik@rug.nl Dr. H. Balsters, H.Balsters@rug.nl

Research group: The Agent Laboratory

(3)

Master Thesis MSc BA Business & ICT 3

Preface

After completing a Bachelor in Information and Communication Technology at the Hanzehogeschool Groningen, including the 30 ECTS-graduate intake programme I started the MSc Business Administration, Specialization Business & ICT in September 2005. At the same time, I started working as a student-assistant on the third-year specialization course Business & ICT (taught by Prof. Wortmann, Dr. Szirbik and Drs. Elsenga). During this period, I was acquainted with The Agent Laboratory (TAL), part of the Faculty of Management and Organization, University of Groningen, of which Dr. Szirbik is one of the founding members. I enjoyed the master courses very much and on February 8th 2006, it was just natural to start my graduate project at TAL.

This Master Thesis is the result of my research at TAL that ended near July 28th 2006. To me it seems the time has gone very fast which is certainly a good sign. The process not only resulted in this thesis but also three papers have been written. The first has been accepted for the student session of The Eight European Agent Systems Summer School

2006 (EASSS 2006) in Annecy, France, 17 – 21 July 2006. The second is an extension of

the first and has been submitted to the Seventh International Workshop Engineering

Societies in the Agents World (ESAW 2006), 6 – 8 September 2006, Dublin, Ireland. The

third has been submitted to The 2006 IEEE/WIC/ACM International Conference on

Intelligent Agents, 18 – 22 December 2006, Hong Kong. All papers can be found in the

Appendices section. In addition, I applied for a PhD position at the SOM research school during this period. I have been accepted as a PhD and I am very proud of that. Therefore, I can only conclude the entire period was very successful.

Even though my interest in agent-based research has been short, I find the research field very promising and interesting. This thesis mainly discusses an agent-oriented modelling language and I am convinced that agents provide new insights and flexibility into business process modelling. I will certainly pursuit this research in the future.

(4)

he is second author. Overall, the lab has certainly been more then just a workplace. The dart games, the lunches and the beers have been very nice. I would also like to thank Cees de Snoo for his comments and his help with the PhD proposal. Finally, I thank Herman Balsters, my second supervisor, for his feedback on my thesis.

Marco Stuit

Groningen, July 11, 2006

Some guidelines for the reader

As stated above, this thesis is mainly about an agent-oriented modelling language. Although this thesis introduces, defines, and clarifies most of the terms used, readers should have some understanding of the basics of object-orientation (classes, objects, inheritance etc.) and the Unified Modelling Language (UML).

(5)

Master Thesis MSc BA Business & ICT 5 Science is a human subject, developed by

people who step on each other’s toes at least as often as they stand on each other’s shoulders.

(6)

Summary

In The Agent Laboratory (TAL) an agent-oriented modelling language named The Agent Laboratory Language (TALL) has been developed. The three main concepts in TALL are agents, roles, and interactions. In organizational contexts, agents play roles and because these agents have to communicate, the roles are attached to explicit representations of interactions. We focus on complex interaction processes that are hard to define in advance. In these processes, each agent has its own local view of the process. The local views of the agents are represented by Interaction Beliefs that consist of the intended behaviour of the agent and the expected behaviour of other agents involved in the interaction.

We do not take a centralistic standpoint and do not try to model the entire process in advance by using a central process definition (like in traditional workflow management) from which agents’ behaviours are instantiated. The advantage of not using a central process definition is that there is more flexibility within the organization (or network of organisations) where the process takes place. Moreover, the agents will have full control over their part of the entire process. In an agent approach, a central process definition would make no real sense, because the central view has to be stored within every agent. Instead, we model the local views of the agents that are playing the roles in the interactions.

(7)

Master Thesis MSc BA Business & ICT 7 defined properly. Both agents and roles were depicted as instances. In addition, there was no way to show agent classes. This thesis critically reviewed and redefined both diagrams, and reviewed the role concept and the agents appearing in the diagrams. This resulted in a new diagram called the Agent-Role-Interaction (ARI) diagram that can be created at two levels of abstraction: the generic ARI diagram and the instance level ARI diagram. In the generic ARI diagram agent groups (i.e. agent classes) are assigned to the roles that are linked to an interaction. This denotes a constraint, showing that only agent members of that group are authorized to play that role in that interaction. Besides, the generic ARI diagram shows multiplicity between agents and roles. The instance level ARI diagram depicts an interaction instance and shows agent members (i.e. agent instances) that are assigned dynamically to play the roles. In addition, this diagram shows the IBs of the agents participating in the interaction. The IBs are represented in the instance level diagram by a chevron symbol that is attached to the association end of the agent-role connector. The execution of an interaction is the coordinated execution of (local) IBs provided by the participating agents. In the generic as well as the instance level diagram roles are never depicted as instances. We see roles only as placeholders that are filled by agents. The roles are not instantiated but recruit their instances from the agents filling the roles.

(8)

semantics of an interaction decomposition, showing how interactions can be triggered and chained in top-down and bottom-up fashion. 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.

Key words: agent-oriented modelling, business process support, interaction, roles,

interaction decomposition

Supervisors: Dr. Nick Szirbik

Dr. H. Balsters

Title: Modelling organisational emergent behaviour using compositional role-based interactions in an agent-oriented language

(9)

1 Theoretical Background

This chapter will provide the reader with the basic knowledge needed to read and understand this thesis. The Agent Lab Language (TALL) has been developed in The Agent Laboratory (TAL) and a preliminary version was initially described by De Snoo (2005) in his Master Thesis ‘Modelling planning processes with TALMOD’. Paragraph 1.1 will discuss the most important concept from his thesis. Next, paragraph 1.2 will define and clarify some concepts that will be used throughout this thesis to act as a guide for the reader.

1.1 The Agent Lab Language

In September 2004 The Agent Laboratory (TAL) was founded by several scientists from the University of Groningen, The Netherlands. The basic motivation for the foundation of The Agent Lab is the conviction that multi-agent architectures have great potential in the support and automation of business processes. A framework (AGE – i.e. Agent growing Environment, see Roest & Szirbik 2006) has been developed, which uses TALL for multiple functions:

• the description, analysis and conceptual modelling of complex, distributed business processes;

• the description of organizational structures;

• development (design and implementation) of agent-based software systems; • interactive simulation/gaming and dynamic visualisation of agent-based software

systems;

(12)

prescriptive models are also possible. The agent approach enables the modelling and support of a process that is not entirely known, allowing conflicting process views.

Decomposition is sought to capture complex actor interactions where all participating

active entities are agents. TALL can model static as well as dynamic aspects of complex (interaction) processes. The static structure diagram represents the environment where a process takes place and the dynamic aspects allow processes to be modelled while explicitly paying attention to the local views on the processes of each agent. Therefore, TALL can be used for business process modelling and analysis as well as information systems development and software engineering.

Well-functioning interaction processes are of great importance for a business because humans are more and more dependent on each other. Process models should be a tool to share and understand better the structure and dynamics of this process. For the sake of process visualisation, four types of diagrams in TALL have been initially introduced (De Snoo 2005):

• Agent-role diagram: displays what actors and entities play what roles in the modelled scenario. This diagram describes a very specific scenario, in which the agent instances and role instances are specified. Therefore, it is a model at the instance level. This thesis presents a revision of this diagram type – extending the kind of entities used, by allowing multiple levels of abstraction (type and instance). The new version of the diagramming technique will be discussed and depicted in Chapter 3. • Role-interaction diagram: identifies the roles in a business process, the multiplicities

of the roles and the local processes that realize the process from the perspective of a role. This diagram does not provide a detailed description of how a role is implemented, but rather serves to identify roles and role responsibilities. The role-interaction diagram is a type-level diagram, identifying types instead of instances. The main revision was to include this technique in the previous one – having only an “agent-role-interaction” diagram (abbreviated ARI diagram). A major revision is that roles cannot be instances. The diagram will be discussed and depicted in chapter 3. • Static structure diagram: is basically the UML static structure diagram to which roles

(13)

not be discussed any further in this thesis. For more information on this diagram type, the reader is referred to De Snoo (2005).

• Process diagram (from a local perspective): describes in detail the activities that an agent executes in an interaction. This diagram type is always made from the perspective of one role in the process; the role that an agent plays in the process. Previously, the diagram was using the concept of a sNICKer (due to the lack of a better name). The same concept is now named now an interaction belief (IB). Subsequently, the diagramming produces IB diagrams. This diagram type is explained in more detail in paragraph 1.2.5.

1.2 Defining and Clarifying Key Terms

In this paragraph, some key terms of TALL will be discussed: agents, agent groups and their members, protocols, modelling of interactions, and IB diagrams. It is possible that in the near future, new names will be used. Due to the experimental nature of our research, we do not consider names as an important issue, we focus on concepts and names come second1.

1.2.1 Agents

Many definitions for agents exist and it seems that the only thing all scientists agree on is the notion of autonomy as a main characteristic of agents. Koning and Romero-Hernandez (2002) also agree that most authors see autonomy or independence as a key factor in defining an agent.

Ekdahl (2001) enforces this argument by stating that there seems to be a common opinion that autonomy is a decisive property of agents. However, there has been no real attempt to give ‘autonomy’ a precise definition, which should be the first step in a definition of agent. Autonomy usually means that an agent has the ability to make its own decisions without being influenced by anyone else. Without question, autonomy is of paramount importance for software agents, and the whole idea of agent relies upon the belief that computers can act autonomously. The author distinguishes between two types

1

(14)

of anticipatory systems, the description based and the model-based. The formers’ behaviour is completely decidable because it is programmed to have a limited number of choices. The supposed autonomy of such systems is a consequence of a decision procedure and cannot exhibit pure autonomy in the sense of non-algorithmic behaviour. Such systems have no freedom of action and are not able, if the environment changes, to perform behaviour that is not part of the algorithmic behaviour. This means we cannot say that such systems are autonomous and can make decisions by itself. The latter are pure autonomous since the behaviour of those systems is not a result of a simple algorithm but based on a model. Such autonomy is impossible to represent in a formal system since if pure autonomy were algorithmically describable an unpredictable environment could be defined in advance. In this case, we would only have description-based anticipatory systems. In short, software agents that are claimed to be autonomous are no more autonomous than algorithms in arithmetic (Ekdahl 2001).

In this thesis, we are using the basic working definition of an agent described by Odell (2000, p.15): ‘an agent is an autonomous entity that can interact with its environment’. This means an agent can be a software system, a machine, a human, or even a department or an organization. This definition also conforms to the definition of Wooldridge (1999, p. 22): ‘a system that is situated in some environment and that is capable of flexible, autonomous action in that environment in order to meet its objectives. An agent can be an encapsulated computer system but also a human being, organization or department’. On the modelling level, the distinction between software and human agents is not relevant. Hence, the different agent types will not be discussed any further in this thesis.

1.2.2 Agent Groups and Agent Members

(15)

Master Thesis MSc BA Business & ICT 15 specialisation (sub-sets) can be used. The agent groups can be used to define an authorisation scheme in the organisation.

1.2.3 Protocols

The concept of protocol will be used numerous times in this thesis. Protocols are defined and agreed by the organization being modelled or analyzed. Protocols are illustrated as a process definition that is available centrally (in the form of a pool of interactions) to the agents that are involved in a particular interaction. Therefore, protocols are always attached to interactions (processes), and agents that are supposed to play a role in an interaction, regulated by a protocol, should be able to understand the protocol description and if possible, obey it. Because protocols are only available to the agents involved in the interaction they are more like local process definitions then generic process definitions (like in traditional workflow management). A protocol (for a particular interaction) includes the messages being exchanged between the agents, the number of activities for each agent, the sequence of these activities, and the relationships between them. To summarize, a protocol is a regulation for the behaviour of agents participating in a particular interaction. This is the basic definition of a protocol. Additional characteristics of protocols will be discussed in the upcoming chapters.

1.2.4 Modelling Agents, Roles, and Interactions in TALL

The central concept in TALL is the interaction between agents that are playing roles. Obviously, the agent concept has to be explicit in any universe of discourse and/or language that are pragmatically used in domains where the agent paradigm is employed. We see roles only as placeholders for the behaviours of the agents (more about this discussion can be found in Chapter 3).

(16)

We denote that an agent plays a role like in figure 1-1. 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 populate the role, but also at an instance level, denoting what agent members are currently playing that role. Moreover, the interpretation of such a diagram is temporally dependent. 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”).

Figure 1-1 Example of an agent member playing a role.

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. This is the main reason for the interaction construct. Agents that play “connected” roles interact. We depict the fact that agents interact as in figure 1-2 (here at a generic level). The syntactic term used for interaction is depicted as a suggestive symbol used also in MESSAGE (FIPA 2003): a flattened hexagon, as in figure 1-2. The 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 interaction concept and the different levels of abstraction at which ARI diagrams can be created will be discussed in more depth in chapter 3.

(17)

1.2.5 IB Diagrams

As mentioned before an IB represents the local view of an agent playing a role in an interaction. An IB is 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. The execution of an interaction is the coordinated execution of (local) IBs provided by the participating agents.

The activities that are part of the IB are depicted in the TALL IB diagram (also known as the process diagram). This diagram shows the (local) behaviour, of the agent for which the diagram is created, as a fully-detailed swimlane that shows all activities, the sequence of activities, the relationships between them, messages being exchanged with other agents, time issues etc. The behaviour of other roles is shown in separate swim lanes but these are depicted at a very high-level of abstraction by using clouds. Examples of IB diagrams can be found in figures 6-4 and 6-5 in chapter 6.

(18)

2 Introduction and Research Plan

In this chapter, the research will be introduced. First, paragraph 2.1 will present the research problems in a context. After that, the relevance and connection of my research to the field of Management and Organization will be justified in paragraph 2.2. Next, the problem definition including the research questions will be described in paragraph 2.3. Finally, paragraph 2.4 will present the research structure.

2.1 Research Context

In this paragraph, the reasons and motives to start my study and the practical and theoretical relevance of the research will be discussed. A subparagraph is devoted to each research problem and together these define the scope of this thesis.

2.1.1 Abstraction Level

One of the main differences between workflows and workflow modelling on the one hand, and agent-oriented modelling (e.g. TALL) on the other hand, is that the former deals with predefined business processes that are executed regularly, that have few exceptions and that can be easily modelled as a fixed order of activities. The latter can deal with non-predefined business processes, unpredictable interactions and completely independent and/or autonomous participants (agents) each having their own local views and behaviours concerning the process. Process goals will be reached by interaction between the behaviours of the agents. Workflow modelling lacks a clear presentation of agents and roles involved in the process. In addition, it assumes full understanding of the activities, the sequence of them, the division of tasks over actors and/or roles, the interaction protocols, etc (De Snoo 2005).

(19)

Master Thesis MSc BA Business & ICT 19 act and perform their activities but the agent has some ideas/beliefs about the behaviour or behavioural intentions of these other agents.

Currently, the IB is defined as a prototypical instance because activities are not totally specified or knowable in advance. In other words, IBs are an intention to perform a role in a certain way but because of the dynamics of the context and the environment, the executed behaviour may be different. We consider it important to define the exact level of abstraction for IBs because if it is not defined clearly which leads to ambiguity in discussions and publications.

In TALL, the agent-role diagram and the role-interaction diagram have been used to model agents, roles, and the (dynamic) interactions between them. However, the choice to draw the agent-role diagram at the instance level and to draw the role-interaction diagram at the type level is not scientifically grounded. Therefore, the level of abstraction must also be defined for these diagrams. In addition, the role concept that appears in these diagrams must be clarified because it is not clear what the abstraction level of a role is and how roles should be depicted in the two diagrams.

2.1.2 Interaction Decomposition

TALL is interaction centred and agent-oriented, which means that communication, negotiation, collaboration, cooperation and coordination between agents, either human or artificial, have the focus. As discussed in chapter 1 each local view of the agents involved in interactions is presented as IBs. For each IB a separate IB diagram shows the process view of a specific agent (who plays a specific role).

(20)

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 we want to be able to show a coupling between the interactions. 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. In short, it is important to make some ontological commitments concerning the interaction concept, and research how it can be decomposed into possible sub-interactions.

2.2 Research Justification

It is a common notice that most existing processes in companies are not as efficient as they could be and that new technologies can be used to design processes that are more efficient. A business process redesign or improvement effort usually starts with the analysis of an existing business processes after which the process is improved, (re)designed or automated. Finally, the changed business process is implemented. A

business process change cycle is shown in figure 2-1, which is a general description of

(21)

Figure 2-1 The business process change cycle. Source: Modified after Harmon (2003, p. 11).

Process improvement refers to minor, specific changes that one makes in an existing business processes. Process design or redesign refers to a major effort that is undertaken to significantly improve an existing process or to create a new business process; it considers every aspect of a process and often results in changes in the sequence in which the process is done, in employee jobs, and in the introduction of automation. Process automation refers to the use of computers and software applications to assist employees or to replace employees in order to improve the performance of a business process. Today, many companies are thinking about how to improve their business processes. It is clear that business process change is a growing concern of business managers and will continue to be throughout this decade. The agent-oriented modelling language TALL can be positioned in the rectangle of figure 2-1 so it really represents an essential tool in the analysis and the eventual change of business processes (Harmon 2003).

(22)

representation the models described in this thesis are analysis models that say nothing about how much of the model is implemented or supported by software. Therefore, they are conceptual models that describe a situation of interest in the world (Daniels 2002). This situation is usually an organizational context. TALL is a modelling language that can help organizations in analyzing their current business situation. As such, this analysis, using various kinds of diagramming techniques, helps to graphically depict business processes in a manner that management, user groups, and other stakeholders can understand. Nevertheless, TALL is more then just a diagramming technique. Whereas diagramming techniques end with a pictorial representation, a modelling language like TALL enables the production of software artefacts from these representations. Fowler (1999) reports that a model is something that matters to a customer. Customers want software that works, not pictures, however pretty or standard. The value of a model is that it gives the user a greater understanding. This can be a greater understanding of the software itself or of the domain/environment the software supports.

In The Agent Lab, we are using the agent paradigm to improve, (re)design, or automate complex interaction processes so the technology being used is multi-agent systems. The multi-agent system is a way to automate processes or activities. Software agents can be used to support and/or automate business processes, and human agents can gain experience in executing processes and hereby improve or (re)design business processes. My research mainly focuses on improving TALL that mainly benefits the analysis of existing business processes with the goal to eventually automate a business process. We view business processes as interactions between different participants in which each participant has its own local view of the process, but still participants are working together in a collective activity (i.e. an interaction) towards a common goal. These parties can be part of the same organization or can span multiple organizations.

(23)

Master Thesis MSc BA Business & ICT 23 ability to quickly analyze processes can possibly understand the organizations they are asked to manage, or figure out how to effectively improve them. TALL provides managers and/or modellers with this ability. The models help to visualize the processes and the domain that the multi-agent system will support. Using TALL, the understanding of (interaction) processes to the modeller is increased and through the models this understanding can be communicated to others. Of course, with TALL a single solution is not advocated and organizations should use the practices best suited to specific problems as they occur.

2.3 Problem Definition

This paragraph will first introduce the research motives including the objectives of the research and the relevance of this objective. Second, the problem statement will lead the way to the research questions. Finally, the research methods used to answer the research questions will be explained.

2.3.1 Research Motives

(24)

of the language. Finally, the modelling language will serve as the basis for an agent-based software engineering framework that is one of the main goals of The Agent Laboratory. The Department of Information and Technology, Faculty of Technology and

Management, Eindhoven University of Technology has been prominent in research into

the modelling and analysis of operational business processes. Although their research has also recognized the need for more dynamic and adaptive workflows they have not embraced the use of agents in business process modelling. Integration of workflow and agent technology has attracted a lot of attention from other researchers in the agent as well as the workflow community. The use of IBs and agent interactions in TALL provide new insights, flexibility into business process modelling, especially distributed, and complex (interaction) processes that are hard to define in advance. The ontological commitments made regarding these modelling constructs will benefit the modelling of less well-defined problem domains like Energy and Healthcare. These domains usually involve processes that are hard to define a priori because they are greatly influenced by new market demands, new regulations etc. In such a case a more flexible approach is needed that can be offered by an agent-oriented approach like TALL.

2.3.2 Problem Statement

The research context shows that the scope of this thesis is defined in two problem domains. First, the level of abstraction for the IBs, the agent-role diagram, and the role-interaction diagram must be defined more clearly. This leads to the following research questions:

1. How can the level of abstraction for the Agent-Role and Role-Interaction diagram be defined? Sub questions, logically derived from this question are:

• How should a role be represented and integrated as a modelling construct in these diagrams?

2. Can an IB (formerly Local Behaviour) be defined as a process instance?

(25)

Master Thesis MSc BA Business & ICT 25 lead to a more precise definition of the interaction concept. This leads to the following research question:

3. How can the decomposition of an interaction be done in a consistent way? Sub questions, logically derived from this question are:

• What are the characteristics of the interaction concept?

• In what kind of diagram can such a decomposition be depicted? • How do the agents execute the interaction decomposition?

2.3.3 Research Methods

(26)

2.4 Research Structure

(27)

3 Abstraction Levels in the Agent-Role and Role-Interaction

Diagrams

In this chapter, the agent-role diagram and role-interaction diagram will be discussed. First, paragraph 3.1 will introduce both diagrams. Next, paragraph 3.2 will present a revision of both diagrams and the reasons to integrate them into a single (ARI) diagram. After that, a comparison to the representation of roles in UML is made in paragraph 3.3. Next, the role concept in TALL will be clarified in paragraph 3.4. Finally, paragraph 3.5 will present a conclusion to this chapter.

3.1 Introduction

Initially, TALL used the agent-role diagram and the role-interaction diagram, as discussed in the theoretical background, to model agents, roles, and interactions.

(28)

Second, the role-interaction diagram (shown in the bottom part of figure 3-1) identifies which roles are involved in a business process but it does not show multiplicity. In addition, this diagram does not show which and how many agents are playing the roles involved in the process. For this information, the agent-role diagram must be consulted. Because the role concept as well as the agent-role diagram will be critically reviewed and redefined, it is also wise to review the role-interaction diagram. Overall, it can be concluded that the role concept, and the level of abstraction and use of these two diagrams should have been investigated more thoroughly.

Figure 3-1 The agent-role diagram (above) and the role-interaction diagram (below). Source: De Snoo (2005, pp. 22-23).

3.2 Revision of the Agent-Role and Role-Interaction Diagram

(29)

3.2.1 The Generic ARI Diagram

(30)

Figure 3-2 Example of a generic interaction with a protocol attached to it.

The generic ARI diagram shows which roles are involved in the interaction and it relates the agent groups to the roles their members can play. Any agent, no matter what group it is a member of can fill a role as long as the agent conforms to what is required by the role (Steimann 2001). The relationship between the agent groups and the roles is named

populates. Steimann (2000b, p. 8) mentions that it is convenient to speak of a class as populating a role and of an instance as playing a role. We have adopted this and therefore

we see agent groups as populating roles and agent members as playing roles. An example of a generic ARI diagram is shown in figure 3-3. It depicts the agent groups ICT

employee, Manager and Business Employee. These agent groups are sets of agents with

the same skills or behaviours. For instance, the members of the Manager group all have managerial skills. The agent groups are connected to the roles with the ‘populates’-relationship which means for instance that all members of the ICT employee group are authorized to play the role of either Systems analyst or Infrastructure analyst. The diagram also shows multiplicity between agents and roles. The multiplicity in the diagram shows that each role should be played by at least one agent so this interaction can only be successful if all roles are being played. Besides, a maximum of one Project

Manager can be involved in this interaction. The diagram could be used as a generic

(31)

Figure 3-3 Example of a generic ARI diagram.

3.2.2 The Instance Level ARI Diagram

ARI diagrams can also be expressed at instance level. A generic example is shown in figure 3-4. 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 (this choice is explained in paragraph 3.4).

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

(32)

The local views of the agents participating in the interactions are represented by the so-called Interaction Beliefs (IBs). The IB defines the behaviour of an agent playing a role. At the modelling level, an IB is an abstraction of a business process as it is seen from a local agent perspective. IBs in TALL have three types. First, they can represent a plan or as we call it an intended behaviour. Second, they become active when they are actually executed by the agents (we call this adapted intended behaviour). The agent adapts the intended behaviour where necessary either on the fly or by the “Deus Ex Machina”. The Deus Ex Machina is the entity that helps the agent when it goes into escape mode. Escape mode is the state an agent enters when it fails to grasp a problem and needs intervention from something outside its system (Roest & Szirbik 2006). Finally, an IB can be a log when the adapted intended behaviour is logged to a pool of already executed interactions and possibly made available to other agents. In this way, a learning experience is created that can be used in future interactions. An agent can also have a belief or acquaintance model about the expected behaviour of other agents participating in the interaction. This part of the IB is called expected behaviour. The entire life cycle of the IB is shown in figure 3-5.

Figure 3-5 Life cycle of the IB concept in TALL. Source: Meyer (2006).

(33)

symbol. The chevron as a protocol is attached to an interaction and the chevron as an IB appears at the association end of the agent-role connector. The agent-role connector, an arrow with a hollow triangular head, with an interrupted line as shaft, defines an “[agent]

playing [role]” – relationship, at the instance level. For each agent member playing a

role, a chevron may be depicted. If an agent does not have a behaviour, it has to learn one from another agent (could be the Deus ex Machina) or it can use a protocol if one is attached to the interaction.

The Project Planning example is shown at the instance level in figure 3-6. This diagram shows which and how many agent members are playing the roles. The chevrons in the diagram represent the IBs from the viewpoint of the particular agents. For example George, who is a member of the ICT Employee group, is playing the role of Systems

Analyst in figure 3-6. In the accompanying generic diagram (figure 3-3), we can see that

George is allowed to play this role because his group populates the role he is playing. The interpretation of the ARI instance level diagram is temporally dependent. 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”).

Figure 3-6 The (new) agent-role-interaction diagram at the instance level.

(34)

3.3 Comparison with UML

In UML, roles appear as role names in associations. In UML class diagrams, role names represent the perspective of a class in a relationship and it is indicated at the end of an association. An example is shown in figure 3-7 in which a Person is an Employee in the association with the University and in which a Person is either a participant or lecturer in the association with a Course. According to Depke, Engels and Küster (2000) role names primarily serve the navigation in class diagrams and for intuitively defining a role. In implementations, especially for relational databases and/or object-oriented languages, role names can qualify method invocations and various queries that otherwise have to make the des-ambiguisation via “invented” labels with limited denotational semantics.

Figure 3-7 Class diagram with role names at the association ends. Source: Modified after Depke et al. (2000, p. 3).

(35)

Figure 3-8 A generic interaction reduced to metalevel UML.

An interaction instance can be reduced to UML in a similar way. In figure 3-9, a Sales

interaction is shown with four roles involved. In the bottom part of the figure, this

interaction is reduced to UML in which the roles are not explicitly modelled anymore but transformed into role names attached to the association ends. In The Agent Lab, we want to be able to explicitly model the roles involved in an interaction but it is possible to always reduce the interaction view to UML. Representing roles explicitly allows you to model attributes specific to a role and allows you to model dependencies between roles that represent a hierarchical scheme or organizational structure (describing also reporting, authorisation and appraisal relations between roles). Using roles to model the organizational structure of a company is a direction for future research in The Agent Lab. In the next paragraph, the role concept will be explained in more detail.

(36)

Figure 3-9 An interaction instance reduced to UML.

3.4 The Role Concept in TALL

In this paragraph, the difference between agents and roles will be explained first. After that, role properties will be discussed. Finally, the role of the role concept will be clarified.

3.4.1 Difference between Agents and Roles

(37)

Master Thesis MSc BA Business & ICT 37 are a placeholder for a human skill or an information system service required to perform a particular task. 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 circumstances and all times. An agent can never drop its natural type without losing its identity. In TALL, we see all agents belonging to the natural type Agent that cannot be dropped without the agent loosing its agent identity. 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. In other words, agents have meaning on their own but a role has no meaning outside its context. Roles are intermediaries or bridges between relationships and the natural types populating their places. In TALL, roles have meaning only when they are involved in a relationship (i.e. an interaction). For instance, the role of Student has no meaning on its own because to be a Student enrolment in a university is required. When George (an agent) plays the role of Student and finishes its studies the role loses its meaning but George will not loose its (agent) identity.

Steimann (2001) who states that roles, unlike classes, have “something” dynamic about them describes another difference between agents and roles. An instance of class Person (a natural type) for example can take on several roles during its lifetime like Student,

Programmer, Tester etc. Besides, unlike with classes, playing several roles

simultaneously is not unusual for the instances of certain classes (i.e. a person can be a customer, supplier, and stakeholder at the same time).

3.4.2 Role Properties

(38)

Steimann (2000a, p. 98) discusses several properties of the role concept. The following properties are important for defining the role concept in TALL:

1. A role may come with its own properties and behaviour but roles are sort of types that cannot be instantiated. For example, the role of Employee will always have the property of salary (an absolute property). The absolute properties of a role are inherited to the agent groups filling them and will become the properties of the instances playing them. For instance, when a Person plays the role of Employee at two different universities getting two different salaries one might expect that two role instances will be created and each corresponds to the same role type. In our view, the

salary attribute is inherited to the agent playing the role. Therefore, an agent’s

behaviour is modified as a result of playing a role.

2. Roles depend on relationships: roles occupy the places of relationships, which means a role is only meaningful in the context of a relationship. As stated above, in TALL a role only has meaning when it is involved in an interaction. A role that does not interact with other roles is of no interest (Genilloud & Wegmann 2000). However, in a static diagram in TALL (not the subject here) roles can be represented without being involved in an interaction because roles can be used to depict an organizational structure or authorization scheme.

3. An object may play different roles simultaneously: an agent member can play multiple roles as long as the agent group populates the specific roles – defining an authorisation scheme;

4. An object may play the same role several times simultaneously: an agent can play the same role in different interactions;

5. An object may acquire and abandon roles dynamically: agent members can directly be assigned to and removed from the extent of a role-defining class so the taking up of roles is always an explicit act and not a consequence of an instance participating in a relationship. This is also a good argument for the statement that roles cannot be instantiated;

(39)

Master Thesis MSc BA Business & ICT 39 that particular group; for example, a human agent can be supported (even substituted on-the-fly) in an interaction by a software agent;

7. Roles can play roles: in TALL, this is not possible, since roles have no instances of their own.

8. A role can be transferred from one object to another: during run-time, a software agent may go into escape mode because it encounters a situation that it cannot handle with its (programmed) behaviour. In this case, its role can be taken over by an (software or human) agent higher in the hierarchy;

9. Features and the state of an object can be role-specific: different roles may have the same attributes and behaviour (see property 1) but agents will realize them differently according to their own behaviour. Each agent has its own local view and each role played by an agent member should be viewed as a separate instance.

10. An object and its roles share identity: an agent and a role are the same. In other words, a role is a mask that an agent can wear. An agent and its role form an aggregate that appears indivisible from the outside. On the inside roles usually have permissions whereas agents have abilities. An agent needs to have certain abilities or skills in order to play a role.

11. We view roles as organizational artefacts that can be used in a static diagram to show an authorization scheme or organizational structure. During execution of agent behaviours, the roles only act as placeholders for the agents playing the roles. Miles, Joy, and Luck (2000) explain that roles provide a way to describe a multi-agent system as analogous to an organisation without placing heavy restrictions on the behaviour of concrete agents at runtime. In our view, behaviours primarily belong to the agents playing the roles. This means the behaviours that are occurring in an interaction through the agents can never be defined through its roles (because they are only placeholders).

3.4.3 Roles as Interfaces

(40)

class (role property 1), they neither add nor refine attributes and methods. Instead, a role recruits its instances from those agent groups that are declared compatible with the role, that is, that comply with the partial specification that makes the role. In other words, the agent groups serve as providers of instances (which roles do not have) and as takers of the responsibility for the realization of whatever the roles of a model promise (Steimann 2000b).

The idea behind roles as partial specifications of agent classes is similar to the interface specification in object-oriented programming. Usually, classes that utilize other classes do not need all of the other classes’ functionality. The features that are actually required are declared as interfaces. Steimann (2001 cites Firesmith & Henderson-Sellers 1998) mentions that interfaces are only partial specifications of classes, specifications that highlight one particular aspect or usage of a class in a specific interaction, and that roles are the appropriate conceptual abstraction for this. Roles can be played by multiple agents, even agents of other types (i.e. groups), which means roles are more then the populating agent classes. This makes roles super types instead of subtypes (Steimann 2001, p. 10).

3.5 Conclusion

(41)

4 Interaction Beliefs and Workflows

In this chapter, the behaviour of agents will be defined more precisely by researching if the IB of an agent can be called a process instance. The IB has already been introduced in the previous chapters. Paragraph 4.1 will provide an overview of traditional workflow. After that, paragraph 4.2 will discuss ad-hoc workflow. Paragraph 4.3 will discuss some concepts in object-oriented design. Next, paragraph 4.4 will position the TALL IB concept in these three areas (traditional workflow, ad-hoc workflow, object-oriented design). Enactment of IBs will be described in paragraph 4.5. Finally, paragraph 4.6 will present a conclusion.

4.1 Traditional Workflow

Traditional workflow includes a generic process description that defines the routing of all activities and the possible routing deviations. When this generic process description is instantiated, a process instance is created. The generic process definition and the instances that are enacted from them will be described more carefully.

4.1.1 Generic Process Definition

(42)

relationships, criteria to indicate the start and termination of the process, and information about the individual activities, such as participants, associated IT applications and data. Process definitions are initially defined prior to workflow enactment, and may be modified at a later date, or modified during run time. A process definition can include attributes like a deadline for a certain activity, pre-conditions for activities, post-conditions for activities or transition post-conditions (WfMC 1999).

Verbeek (2004) explains that a process definition specifies which tasks need to be executed in what order. Tasks are ordered by specifying for each task the conditions that need to be fulfilled before it may be executed. In addition, it is specified which conditions are fulfilled be executing a specific task.

4.1.2 Workflow Instances

(43)

Figure 4-1 Relationships between basic workflow terminologies. Source: WfMC (1999, p. 7).

A synonym for a workflow instance is a case. Verbeek (2004) 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. 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. Besides, the goal is to handle large numbers of similar cases in an efficient and effective way, which means for example that handling one requisition request usually does not differ much from handling another requisition request. When a process is running, multiple cases may correspond to the process definition and multiple work items may correspond with the case depending on the state of the case (Van der Aalst 2000b; Verbeek 2004).

(44)

(45)

Master Thesis MSc BA Business & ICT 45 A case can be represented by one or more tokens; this number can fluctuate during execution of the case. The number of tokens that belong to a specific case corresponds with the number of conditions that are currently fulfilled. Tokens that belong to different cases can be depicted in two ways. First, a separate process instance can be made for each case so they do not influence each other. Second, tokens can be assigned values by using coloured Petri nets from which can be concluded to which case a token belongs. To make sure that tokens of different cases are not mixed every transition can be assigned a precondition in order to only consume tokens of the same case simultaneously. A task (definition) is not directed at a specific case. A task that needs to be executed for a specific case is called a work item – can be seen as a task instance; if the task is seen as a type. When a work item is executed by a specific resource, it is called an activity. In Petri nets tasks are represented by transitions, a work item corresponds to a transition that is ‘enabled’, and an activity corresponds to the firing of a transition. For the firing of a transition more is needed then just an appropriate state. Certain transitions only become activities when they are triggered. There are three forms of triggers: resource triggers, external triggers, and time triggers (Van der Aalst and Hee 2004).

4.2 Ad-Hoc Workflows

(46)

New techniques, new laws and new market demands may require structural modification of the workflow process definition. In addition, ad-hoc modifications may be necessary because of exceptions. Traditional production workflows (as described in the previous paragraph) have difficulty coping with such changes. Adaptive or ad-hoc workflow offers process support just like traditional production workflows but these systems can deal with process changes. There can be two types of changes:

• Individual (ad-hoc) changes: these ad-hoc changes to the workflow process influence a specific case (or limited number of cases). These changes can be entry-time changes (changes that occur before the case enters the system) and on-the-fly changes (the process definition for the case changes while the case is in the system);

• Structural (evolutionary) changes: this is the evolution of a workflow process that affects all cases. For instance, the redesign of the entire workflow because of a Business Process Redesign (BPR) project.

A workflow can be changed in three ways. First, the process definition can be expanded like adding new tasks. Second, tasks can be replaced by other tasks like refining a task to a sub process. Finally, tasks can be rearranged like placing two sequential tasks in a parallel route. Dealing with changes to running cases (i.e. instances) is only relevant for structural changes because individual changes are always exceptions and will be dealt with by the one who explicitly started the change. Structural changes can be dealt with in three ways. First, the running instances can be rolled back and restarted at the beginning. Second, multiple versions of the process can be maintained and in this way the changes have no influence on the running instances. Finally, a case can be moved to a new process. The basis of an ad-hoc workflow system is that the actors are able to change the

process definition for specific cases (Van der Aalst & Hee 2004).

(47)

Master Thesis MSc BA Business & ICT 47 executed. Van der Aalst & Hee (2004, pp. 171-172) discuss a WfMS called InConcert that supports flexible or ad-hoc workflows. They explain four ways a new instance can be created:

1. Start an existing workflow process definition: a copy is made of the process definition and the first task is enabled without changing the workflow (this is similar to a traditional production workflow);

2. Start a changed process definition of the existing workflow process definition: a copy is made of the process definition and is changed to allow for an ad-hoc sequence; 3. Start an ad-hoc workflow by specifying a sequence of activities and actors;

4. Start a so-called ‘free routing process’, i.e. an empty ad-hoc workflow process: there is no explicit workflow process definition and this definition is created during execution.

These four ways to create instances will be discussed further and applied to TALL in paragraph 4.5

4.3 Workflows and Agents

(48)

defined a priori and this does not limit application to well-defined problem domains or rigidly structured business process such as order processing. Yan et al. (2001) do mention that one of the problems of agent technology is the lack of a coordination mechanism, which could make systems unstable and unreliable. Another problem they mention is that due to the lack of an explicit definition business process optimization is difficult to achieve. We do not advocate a pure agent approach – where agents have only “rational beliefs”, tuned to increase the local utility of each agent (so called “selfish agent architectures”). We position our approach in the middle, between the workflow approach and the (pure) agent approach. This allows us to acquire the ‘best of both two worlds’2. By using the protocols, we introduce a coordination mechanism for agents but we remain flexible because agents can always supplant the protocol with their own behaviour. In our view, agents are capable of such action because they can react to changing circumstances and have the ability to generate alternative execution paths. This ability normally involves agent’s adaptive features, such as learning (Yan et al. 2001). Because we are in the middle, the process logic is not completely embedded centrally in the system but it also not completely embedded in every agent. The latter to avoid redundant data storage by letting each agent carry a process definition. In our approach, standardized interactions are available centrally in the form of protocols but only to agents that are involved in the particular interaction.

4.4 Object-Oriented Design

Inheritance is one of the cornerstones of oriented programming and object-oriented design. The basic idea of inheritance is to provide mechanisms, which allow for constructing subclasses that inherit certain properties of a given super class. A class

2

(49)

corresponds to a workflow process definition (i.e. routing diagram) and objects (i.e. instances of the class) correspond to cases (Van der Aalst 2003).

In UML, interaction diagrams are offered at two levels: the specification (or classifier) and the instance level. However, interactions (and collaborations) always take place between actual objects, not their roles or classes, and it seems that the specification level is needed only insofar as interactions require or impose additional structure, structure that, because of its generality, should indeed be expressed on the classifier level. The specification of interaction itself however must be able to distinguish different objects even if they play the same role and, more importantly, must be able to express that the same objects play different roles in one interaction. Such is not possible on the classifier level, and it would appear that the instance level is the natural domain for interaction specification. The definition of collaborations with generic interaction patterns on the classifier level tends to blur this distinction, and is rather difficult to communicate (Steimann 2000b).

Although the UML interaction diagram cannot be completely compared to the combination of IBs of TALL it is true that in interactions between agents it should always be possible to distinguish between agent members (i.e. instances) playing a certain role. As this distinction is not possible at the type level this provides additional arguments for defining IBs at the instance level even when a process class is absent.

4.5 Positioning TALL

TALL cannot be compared to a production workflow in which all the procedural rules are defined in advance because in The Agent Lab we decided not to have a predefined central process definition. There is no global definition of the entire business process that includes all exceptions3. In traditional workflow modelling, there is a distinction between the process definition phase (build-time) and the process execution phase (run-time) (Reijers et al. 2003). When processes are created dynamically, like in TALL, this distinction becomes irrelevant (WfMC 1999). This means in TALL the activities and the

3

(50)

sequence of activities is unknown, except when a protocol exists. An IB can be seen as a workflow, capturing the way an agent interacts with other agents, but from a local

perspective. Roest & Szirbik (2006) report that the agent who owns the behaviour

“knows” what it will do in an interaction, and “expects” what the other will do – or in other terms, it has an “acquaintance” model about the behaviours of the other agents. Roles serve as placeholders for the behaviours of the agents. As described above a process instance as described by the traditional workflow community is instantiated from a central process definition, which would lead me to conclude that an IB is not a process instance. However, this conclusion is too hasty because TALL does include some form of process definition in the form of protocols. In other words, TALL is not a ‘pure’ agent approach. According to Roest & Szirbik (2006) in a ‘pure’ agent approach there is no central point of control or global representation of the process structure in which agents perform their own activities and pass the control and flow items to other agents. Furthermore, even without a generic process a workflow can still be an instance, which will be explained in the next paragraph.

TALL is in the middle of centralized and decentralized process structures. In TALL, there is no full view on the entire process like the process definition of a traditional WfMS. A traditional WfMS is usually called a production workflow and only supports routes through the process that are modelled explicitly at build time (Reijers et al. 2003). This would be very inefficient for our approach because this process definition will have to be stored decentralized within every agent. Roest & Szirbik (2006) explain that by using roles, agent-role static assignments, and role-to-role interaction specifications, we are capturing centrally a view of the organization, without cluttering the agents’ beliefs with this information. The role names are global knowledge because they are linked to an organizational structure.

(51)

Master Thesis MSc BA Business & ICT 51 also prescribe the process steps to be undertaken. This was already made clear in the definition of a protocol in paragraph 1.2.3. In other words, protocols regulate the behaviour of agents just like traditional process definitions with a big difference because they are less global (they cover only the scope of a specific interaction) and can always be supplanted by the agents’ own behaviour. They are bound to specific interactions and known only to the agents participating in these interactions. In a way, they are in the middle of an axis between centralized and decentralized process definitions. Adams et al. (2003 cites Bardram 1997) note that realizing an activity in a contingent environment is aided considerably by having a repertoire of actions and operations to choose from. Protocols then become standardized generic interactions that can be reused and can be applied to various kinds of interactions between agents. They could even become domain-independent and be made available to organizations in other domains. Moreover, if humans are leaving the organisation and protocols have been built on their experience and behaviour, the organisation may keep (using the appropriate infrastructure) their experience in terms of “deposited” protocols.

(52)

‘resources for action’ rather than strict blueprints of work practices which may also be a better word for the TALL protocol. By giving IBs over-rule ability over protocols we have a more dynamic, flexible system that can cope with complex situations in which processes do not have to be completely defined in advance. This allows interactions, roles, protocols and behaviours to be discovered dynamically as is happening in real-life situations.

4.6 IB Instance Creation

In the workflow community, process instances are formed in a central, top-down manner; they are instantiated from the generic process definition. According to the definition of an instance of the WfMC an instance is also the representation of a single enactment of an activity within a process. In TALL, an instance is not created from a process definition but a workflow participant (i.e. an agent) still performs activities for a specific interaction. Activities in the IB Diagrams are executed for a specific interaction by processing a work item. Moreover, each task needs a work item, trigger and/or resource to be executed. This means we do have activity instances that are created during execution. Because of the lack of a generic process definition and the resulting dynamics and flexibility of the IBs there are no multiple cases that correspond to the same generic process definition. However, it is possible to have IBs that correspond to the same protocol. The activities are formed during execution, which corresponds to an ad-hoc workflow as discussed in paragraph 4.2. The first two ways to create an instance as discussed in paragraph 4.2 do not apply to TALL because of the lack of a generic process definition. In our approach, IB instances can be formed in two ways which corresponds to the third and fourth way to create instances as discussed in paragraph 4.2. Both ways will be discussed now.

(53)

Master Thesis MSc BA Business & ICT 53 picks a protocol from the pool of interactions and an IB instance is created. This is similar to the top-down instance creation (instantiating from a generic process definition) of an ad-hoc workflow because the workflow can change on the fly according to the autonomous behaviour of the agents executing the process. Therefore, this type of instance creation is similar to the third type of instance creation as discussed in paragraph 4.2 because the sequence and number of activities is specified in the protocol (in advance). After creation, the IB instance is an ad-hoc workflow that implies that it can always be supplanted by the actual behaviour of the agent executing the workflow.

Second, IB instances can be created during execution. In this case, the IB instance is formed at the moment the agent that owns that IB receives a trigger to begin execution. This trigger can be an agent that picks up a task (a resource trigger) or can be an external trigger like a message or a time trigger. This implies that we can have two types of messages. We can have messages that start a workflow (create an IB instance) or messages that are sent to a running IB instance that is waiting for a message. Finally, an IB instance can be created because a certain time constraint is met; this corresponds to a time trigger. IB instances that are created when execution starts can be called bottom-up instances. Bottom-up IB instances are formed from tasks that are not predefined but discovered dynamically. In a sense, they are like ‘one-of-a-kind’ processes in which for each case a separate process is defined. During run-time, the task is assigned a work item and a resource and transforms into an activity. Now, it can be called an activity instance. Multiple activity instances will be created during execution and together they form an IB instance. The IB instance has a start and an end. The IB instance ends when the agent finishes its local part of the interaction so the IB instance is discrete. The enactment of bottom-up IB instances is less rigid and formalized then traditional process enactment (i.e. top-down enactment).

Modelling organisational emergent behaviour using compositional role-based interactions in an agent-oriented language

Master Thesis

Modelling organisational emergent

behaviour using compositional

role-based interactions in an

agent-oriented language

by

Marco Stuit

University of Groningen, The Netherlands

Faculty of Management and Organization

Faculty of Economics

Modelling organisational emergent

behaviour using compositional

role-based interactions in an

agent-oriented language

Preface

Summary

Table of Contents

1 Theoretical Background

2 Introduction and Research Plan

3 Abstraction Levels in the Agent-Role and Role-Interaction

Diagrams

4 Interaction Beliefs and Workflows