TOWARDS AGENT-BASED MODELING AND VERIFICATION OF...

International Journal of Cooperative Information Systems World Scientific Publishing Company

1

TOWARDS AGENT-BASED MODELING AND VERIFICATION OF COLLABORATIVE BUSINESS PROCESSES: AN APPROACH CENTERED ON

INTERACTIONS AND BEHAVIORS

MARCO STUIT and NICK B. SZIRBIK

Department of Business & ICT, Faculty of Economics & Business, University of Groningen, P.O. Box 800, 9700 AV Groningen, The Netherlands

{m.stuit, n.b.szirbik}@rug.nl

This paper presents the process-oriented aspects of a formal and visual agent-based business process modeling language. The language is of use for (networks of) organizations that elect or envisage multi-agent systems for the support of collaborative business processes. The paper argues that the design of a collaborative business process should start with a proper understanding of the work practice of the agents in the business domain under consideration. The language introduces a novel diagram to represent the wide range of (cross-enterprise) business interactions as a hierarchy of role-based interactions (including their ordering relations) in a tree structure. The behaviors owned by the agents playing the roles in the tree are specified in separate process diagrams. A collaborative business process studied in the context of a case study at a Dutch gas transport company is used to exemplify the modeling approach. Explicit (agent-based) process models can and should be verified using formal methods. In the business process community, design-time verification of a process design is considered vital in order to ensure the correctness and termination of a collaborative business process. The proposed modeling approach is enhanced with a design-time verification method. The direction taken in this research is to combine the interaction tree and the associated agent behaviors into a verifiable hierarchical colored Petri net in order to take advantage of its well-defined (execution) semantics and proven (computerized) verification techniques. The verification method presented in this paper consists of three steps: (1) the translation of the agent-based process design to a hierarchical colored Petri net, (2) the identification of process design errors, and (3) the correction and rollback of process design errors to the agent-based model. The translation technique has been implemented in a software tool that outputs the hierarchical colored Petri net in a format that can be loaded in the widely used CPN Tools software package. Verification results are discussed for the case study model.

Keywords: agent interaction structuring, agent behaviors, collaborative business processes, business process modeling, process verification, hierarchical colored Petri nets.

1. Introduction

Traditional process modeling languages like BPMN1, UML2, EPCs3, IDEF04, and Petri nets5 create structured well-defined process models. In these languages, the collection of tasks or activities in the business process is ordered in a strict pre-defined execution sequence that is performed in an imperative way.6 Such languages are able to model business processes that display complex flows, but are less appropriate for modeling business processes that involve the co-operation of several entities.7-10

Nowadays, systems that support business processes across different autonomous organizations and/or organizational units are becoming popular in order to foster horizontal collaboration and information sharing. In such collaborative business

2 M. Stuit & N.B. Szirbik

processes (CBPs), collaboration instead of task sequence determines the nature of the working activity. According to Ref. 11, collaborative activity simply does not match in any way the underlying “parallel flowchart” paradigm of current mainstream process notations and languages.

An increasing number of research efforts12-17 apply agents to the business process domain by creating agent-oriented Workflow Management (WfM) and Business Process Management (BPM) systems. These approaches offer more process flexibility, which is important for the application of business process support and automation in less structured application domains. There seems to be an opportunity for IT support by building software agents for support of (human) collaborative work practice.18 Ref. 19 adds that the agent paradigm promotes autonomous action and decision-making, which makes it relevant for modeling and implementing business processes involving different enterprises. However, most agent-oriented WfM or BPM approaches are directed at the use of agents as part of the architecture and/or infrastructure associated with the system. Thus, the focus is on the use of agents as a technology rather than a (business process) modeling framework.

Well-known agent-oriented software engineering (AOSE) methodologies like MaSE20, Prometheus21-22, Tropos23, Gaia24, and MESSAGE25-26 support the agent system development process from analysis and design to implementation. Dedicated agent-based modeling languages are core components of these methodologies. Other agent-based modeling languages include (amongst others) AUML27-28, AORML29, and AML30-32. All these agent-based languages are information systems modeling techniques and are not fully and easy applicable to business process design and analysis. In general, they are focused on system specification instead of business process specification.

As process-centric systems grow in scale and complexity (i.e. multi-agent systems), business process modeling will become crucial. Therefore, this paper stresses that organizations that elect or envisage agent technology for CBP support should start with a proper understanding of the work practice of the agents in the business domain under consideration.

This paper consists of two main parts. The first part presents TALL33 (The Agent Lab Language), a visual and formal agent-based business modeling language. The development of the language is motivated by the need for new methods and languages to model (agent-driven) CBPs. The main contribution TALL makes as a modeling language is that it presents a process-oriented approach, based on agent-oriented concepts and notations, which is more suited for business (process) modeling in comparison to existing agent-based languages. In the language, CBPs are addressed in two ways. On a high level, an interaction diagram is used to visualize inter-agent interactions in a tree layout. In the interaction diagram, the CBP is conceived as a structure of role-based interactions through which agents cooperate and coordinate their work. Individual agent behaviors are specified in process models, which are owned by the agents that are assigned to play the roles in the interaction diagram.

Towards agent-based modeling and verification of collaborative business processes 3

The logical step after a CBP has been defined in a process model is to implement it in an agent-based execution environment. However, fundamental flaws in the agent behaviors should be identified before the CBP model is put into use. Design-time verification is concerned with determining whether a process model exhibits certain desirable behaviors before it is used for execution.34 Verification is essential in collaborative business settings8-9 where the design and run-time complexity of the process increases because agents autonomously perform their local behaviors when engaged in interactions.

The second part of the paper is devoted to an execution-platform-independent design-time verification method that is focused on the structural compatibility of the agent behaviors that perform the interactions in the CBPa. The direction taken in this research is to translate the TALL CBP (TCBP) model (i.e. the combined interaction and behavior diagrams) into a Hierarchical Colored Petri (HCP) net in order to take advantage of its well-defined (execution) semantics and proven (computerized) verification techniques. The verification method is able to verify the structural composition of individual agent behaviors into the interactions that form a CBP. The user can experiment with a specific set-up of agent behaviors and can check if the agent behaviors contain no design errors and inconsistencies, and send each other the required messages to complete the interactions. After correction, this results in a coordinated set-up of the agents that avoids deadlock and livelock situationsb, which is a necessary and desirable property of agent systems.35 The verification method enhances the reliability of the TCBP model and the (future) system that supports the CBP. After verification, the agent behaviors can be subject to further design and/or implementation.

The language and verification method presented in this paper are useful in the field of requirements engineering for agent-based systemsc. This paper is not concerned with the question how TALL’s semantics can be implemented by an (existing) agent platform. Each system may attach its own semantics to an input process specification or may not even have formal execution semantics to run process models. A TALL-focused evaluation of agent platforms is beyond the scope of this paper. This implies that specific agent (system) implementation and operation details are not detailed in this paper. The focus of this paper is to present and exemplify a language and verification method. Based on this focus, this paper does not aim to discuss managerial insights from the perspective of the case study company or present any experiments that provide (statistical) proof of the success rate of the language for practitioners. Finally, this paper assumes that any

a A CBP model is correct if there exists, for each interaction in the CBP, at least one (collaborative) scenario that can successfully end through a specific set-up of agent behaviors. Section 4 discusses the verification method in more detail. b Deadlock refers to a state of affairs in which further action between two or more agents is impossible; on the contrary, livelock refers to a scenario where agents continuously act (e.g. exchange tasks), but no progress is made.35 c A single superior solution is not advocated with TALL. Existing agent-oriented languages and development paradigms can be used to describe different aspects of an agent-based system in more detail or to finally build the software agents.


agent, role, or interaction name that is local to the agents is based on a shared ontology of the business domain under consideration.

The remainder of the paper is structured as follows. Section 2 introduces a case study of a real-life CBP that is used throughout the paper to exemplify the approach. Next, Section 3 motivates and presents TALL. After, Section 4 introduces the proposed verification method. Section 5 describes the set of translation functions (from now on: the translation technique) that translate the TCBP model to a HCP net (from now on: the produced HCP net). Formal verification of the produced HCP net and correction of the TCBP model based on the verification results is described in Section 6. Section 7 reflects on the verification method and TALL. Related work is discussed in Section 8. Finally, Section 9 contains conclusions, and gives directions for future work.

2. Case Study

A case study of a real-life CBP at Gas Transport Services Inc. (GTS) is used to exemplify the modeling approach and the verification method. Earlier projects established good relationships at GTS and revealed the existence of an interesting CBP: the Provision of Gas Transport Services process (from now on: the GTS process). GTS agreed to participate in a case study where the authors received access to company documentation and received permission to meet with process experts and participants. Thus, the primary form of data collection was inspection of company documentation and interviewsd with process experts and participants.

The liberalization of the gas market in The Netherlands on July 1, 2005 implied a strict separation between the trade and transport of natural gas. The national Dutch gas infrastructure company NV Nederlandse Gasunie was split into two autonomous companies, a gas transport company named Gasunie and a purchasing and sales company for natural gas named GasTerra. The main activity of Gasunie is to manage, maintain, and adjust the gas transport system. The division GTS of Gasunie is responsible for the management, operation, and development of the national gas transport grid on an economic basis. GTS provides gas transport services in order to promote a well-functioning liberalized gas market. Transport services are mainly requested by shippers, the largest customer group of GTS. A shipper is a company that uses the grid to transport gas. As soon as a shipper concludes a transport contract with GTS, it is regarded a supplier of gas to end-users (i.e. the actual users of the gas like residential consumers, business, or industries). The GTS process provides shippers with several gas transport-related servicese. Service provisioning has become increasingly electronic in recent years and GTS uses a web-enabled ERP system to offer services to shippers. However, several services have to be requested manually by fax or e-mail through an application form that is downloaded at the website of GTS. These services are called ‘offline’ services and are

d The interviews had the form of informal iterative consultations. Therefore, this paper does not present a detailed interview framework. e For a description of all the transport services that can be booked by shippers, the website of GTS can be consulted: http://www.gastransportservices.com


handled manually. Moreover, certain online services require considerable manual effort. Most service requests are the result of a weakly structured collaboration between the shipper and GTS, and between the (technical, legal, financial etc.) employees within GTS. The complexity of the service request, the vast amount of data that needs to be verified, the specific requirements of certain shippers, and the multiple departments involved requires continuous human involvement.

The GTS process has been simplified in order to take into account a non-disclosure agreement but also for the purpose of explanation and illustration. Nevertheless, the key aspects of the process are still present. This paper focuses on a fragment of the GTS process that is concerned with a selection of transport services: • Booking of Entry/Exit Capacity: GTS uses an entry-exit system for the national gas

transmission grid, in which the gas enters the grid at entry points and leaves the grid at exit points. Shippers can book both entry- and exit transport capacity;

• Reduction of Contracted Capacity: A shipper can reduce the contracted capacity by 20% free of charge;

• Shift of Capacity: A shift of capacity allows capacity that was booked for a particular exit point to be transferred to another exit point for a specified period.

As part of the booking process for entry/exit capacity, GTS performs an availability check and a technical capacity check. Most of the capacity checks can be executed by the ERP system since the requested capacity is simply compared with the available capacity. However, in certain areas of the transport grid, network points are clustered and influence each other. The complexity of the capacity check for such network points requires an employee of the back office (i.e. the capacity planner) to perform a manual capacity check. The same human-based scenario can apply to the financial check that checks the creditworthiness of shippers. The financial position of a shipper is dependent on the bookings already made by the shipper. With complex bookings, like the one above, the financial check needs to be performed manually by an accountant.

3. The TALL Agent-based Modeling Language

This section introduces TALL. Section 3.1 motivates the need for the language. Next, Section 3.2 introduces the graphical syntax and semantics of the interaction and behavior diagrams. After, Section 3.3 presents the formal definition to support the introduced concepts. Finally, Section 3.4 highlights the modeling method and discusses tool support.

3.1. Motivation

Contemporary organizations are complex collaborative networks.36 The business processes of such organizations involve more people that collaborate both within and across organizations. TALL is inspired by the agent paradigm to model CBPs, and is based on the premise that human collaborative work is not about carrying out steps in a pre-defined sequence but instead requires a higher-level notion of process. TALL is a business modeling language that can help business analysts/architects that elect or envisage a multi-agent system (MAS) for the support of CBPs, to help understand the


(collaborative) work practice of the agents in the business domain under consideration. The language can be adopted outside a system development or implementation context. In this paper, the focus is on the process-oriented aspects of the language. In this regard, TALL offers a process-oriented approach that is centered on agent-oriented concepts (i.e. agents, roles, behaviors, and interactions).

The language has been designed with a strong conceptual separation between inter-agent interaction specification and local agent behavior specification. The Interaction Structure (IS) diagram introduces a higher-level notion of process that establishes the role-based interaction structure of the CBP in which the agents behave. A set of Agent Behavior (AB) diagrams specify the individual local behaviors of the agents that are assigned to the roles in the IS diagram. The agent paradigm increases process flexibility because control is distributed among the agents that execute parts of the collaborative workflow autonomously. Still, the agents need to coordinate their work in order to reach the goals of the overall CBP. The IS diagram separates the definition of process-wide behavior (i.e. MAS behavior) from the possible ways to perform that behavior. Process-wide behavior can be partially defined at design time and used at execution time independently of the autonomous behaviors of the agents.

Agent behavior specification is done from a local viewpoint using explicit process models in the form of the AB diagrams. The use of explicit process models is in line with a process-based approach. On the one hand, the process-orientation departs from existing agent-oriented languages that have been used mostly for software modeling. On the other hand, traditional process modeling languages do not use agent-oriented concepts and notations during initial process design and analysis, and, as mentioned in the introduction, do not address properly collaboration and interaction. In these languages, the concept of locality does not exist. Local process variation is lost at the whim of the business analyst who creates a centralistic model of the process in order to increase process standardization. Such a model does not adequately reflect the local process knowledge of the agents and a lack of consistency between the activities of the agents is not allowed. TALL models the operational flow of the process from the local perspectives or beliefs of the agents.37 Other approaches do not consider that an agent can have explicit beliefs about an interaction. This is especially important in collaborative business settings where autonomous parties have different perspectives on a process. Taking into account the local views of the agents has the potential to minimize the gap between the actual process and the modeled process by capturing real-world nuances, variations, and views. Section 8 contrasts TALL with related work.

In this paper, a CBP is defined as a collaboration process that consists of multiple local (distributed) business processes. Each local business process is owned and executed by a single business entity or agent (e.g. humans, departments, teams, IT systems etc.), but it may interact with the business process(es) performed by other agents. The interactions between the agents can be both inter- or intra-organizational depending on the involved agents. A CBP instance is a representation of a single enactment of a CBP, which is managed according to an IS diagram. Although multiple local IS diagrams may


exist, this definition assumes that the agents have agreed upon or build a single global IS diagram. A CBP instance is created when the IS diagram is initiated by an agent that is triggeredf. Although a global IS diagram can be used to manage a majority of CBP instances, each CBP instance is independently controlled and has its own process state and identity.

3.2. Diagrams, graphical syntax, and semantics

The main modeling constructs of TALL are agents, roles, interactions, and behaviors. Fig. 1 shows how these constructs are graphically visualized and connected. Interactions are depicted as double hollow arrows with their names as labels. Roles are depicted as ellipses, have their names as labels, and are attached to the lines outgoing the interaction. Agents are depicted as rectangles with rounded corners, have their names as labels, and are assigned to play roles. In the IS diagram, behaviors are depicted as chevrons (i.e. arrow rectangles), carry an agent-role label, are owned by the adjacent agent, and are detailed in an AB diagram.

Fig. 1. Abstract example of TALL’s main modeling constructs. Agents that play ‘connected’ roles interact by performing their local behaviors.

3.2.1. Agents and roles

From a modeling perspective, all the interaction participants in a CBP are viewed as agents whose nature can be individual (human or software agent) or collective (synthetic agent). Human agents represent the people that make up an organization. Software agents are software applications that run on computer platforms and autonomously carry out certain activities within the business process on behalf of a human or synthetic agent. Other IT systems like (legacy) enterprise information systems can also be modeled as software agents and can be exposed as agents by transduction or wrapping.39 In addition, a software agent can be assigned to a passive object, like a chair (physical entity) or an order (information entity). Synthetic agents40 are composite agents that consist of zero or more internal (human, software, or synthetic) agents and typically represent organizations or organizational units. Synthetic agents have their own (organizational level) behaviors,

f According to Ref. 38, a trigger is the recognition of some predefined set of circumstances associated with the operation of the entire system, which causes a particular action to be taken. In an agent context, triggers can be seen as events that are perceived by the agents and cause them to initiate certain actions. Either an external trigger (i.e. a communicative event like receiving a message) or an internal trigger (i.e. a non-communicative event like perceiving or sensing the status of an object) may activate an agent. Of course, event processing involves much more detail, that is, some form of internal agent processing is required in order for the agent to know how to react when facing a specific trigger.


that is, their behavior is not simply the behavioral aggregate of their constituents. This is useful when it is hard or impossible to identify the behaviors of the constituent agents in detail or when the internal agents are not known at design time. The former is especially true with complex human behaviors. An example in which the synthetic agent concept is useful is when a project team (a synthetic agent) is assigned to a role in an interaction with a client. In this case, the abstract behavior of the project team can be studied and modeled as a single entity, and a software agent can be created to directly support some of the teams’ activities. It is not necessary to study the detailed behaviors of the (possibly unknown) project members. The structural composition of synthetic agents is shown in the TALL Agent Structure (AS) diagram. This diagram is not specified formally in this paper but is discussed shortly since it is relevant for the modeling method presented in Section 3.4.2. Fig. 2 shows a possible composition of the high-level synthetic agent that represents GTS. A line between two agents indicates software agent ownership. Graphically, icons that appear in the top-left corner of the agent symbol are used to distinguish between the three agent types: circles represent human agents, squares represent existing software agents, and triangles represent synthetic agents.

Fig. 2. The composition of the synthetic agent GTS.

In TALL, an interaction does not exist without at least two roles being bound to it. Several authors share this view. According to Ref. 41, a role that does not interact with other roles is of no interest. Ref. 42 mentions that agent-to-agent interactions are well identified and localized in the definition of the role; it is the role that requires a given form of interaction behavior. Ref. 43 specifies valid interactions only between roles. Ref. 44 indicates that roles provide the building blocks for agent social systems and the requirements by which agents interact. In TALL, roles are placeholders for the agents. They serve as bridges or intermediaries between interactions and the agents playing them. This view of roles is based on the work in Refs. 45-47. The roles in the IS diagram are determined and named at design time.

In the IS diagram, the depicted agents are agent instances. Other diagrams in TALL can represent agents at a more generic level. The meta-concept of the language is agent group, which is similar to an extent to agent type.33 An agent group can be statically related to a role in various ways. In the AS diagram (e.g. Fig. 2), a special kind of instance (the prototypical instance agent, like anAccountant) can be used. When a computational environment (typically a MAS kernel) processes the IS diagram for real-


life process support, it is likely that the roles are filled dynamically by the agents at execution time. However, at design time, agents (i.e. instances or prototypical instances) may be assigned to play the roles in order to show a prescriptive IS diagram (i.e. these are the agents that can or must play the roles). In the context of this paper, the inclusion of agents at design time and the explicit representation of their behaviors in AB diagrams enables formal verification of the agent behaviors at design time (see Section 4).

3.2.2. Agent interaction modeling

The IS diagram of the GTS process is shown in Fig. 3. The IS diagram represents an interaction tree, that is, a hierarchical set of role-based (parent and child) interactions and their ordering relations. Interactions are related to other interactions through composition (one interaction being part of another) and dependency (one interaction must be completed before the other can start).

Each interaction in the IS diagram appears at a certain level in the tree, starting at level zero, the root level. Parent interactions are interactions that have sub-interactions (i.e. child interactions) in the tree. A collection of child interactions constitutes a parent interaction according to certain ordering constraints. The supported routing types in the IS diagram are SEQ (sequential execution of the children), PAR (parallel execution of the children), and XOR (selective execution of the children). The three routing types can be specified with or without decision rules. With decision rules, the execution of the child interactions is based on the fulfillment of certain (data) conditions. Graphically, routing types appear below parent interactions like in Fig. 3.

The formal definition of the IS diagram in Section 3.3 discusses the supported routing types and the decision rules in more detail. Fig. 3 shows that the root interaction consists of the three main interactions described in Section 2: Booking of Entry/Exit Capacity, Reduction of Contracted Capacity, and Shift of Capacity. Each of these interactions has its own child interactions. When the capacity or the financial check yields a negative result, the Cancel Booking Request interaction is performed. In this case, the Complete Booking Request interaction (and its children) is not executed. During enactment of the global IS diagram by a computational environment (e.g. a MAS), this decision is made by the agent that evaluates the decision rule attached to the XORd routing type defined on the Evaluate Booking Request interaction. The leafs of the tree are named elementary interactions and are executed by agents that perform their behaviors. Completion of a set of elementary interactions with the same parent implies completion of the parent interaction according to the specified routing. This bottom-up process continues until the root interaction completes.

The Perform Automatic Capacity Check interaction mainly consists of activities that are executed by the GTS ERP system without any user involvement. The ERP system is actually working on the processing of the booking request. Thus, its work is modeled as an interaction with two roles: Transaction System and Booking Request. During execution, the GTS ERP system plays both roles. Most organizations do not have an empty IT landscape, i.e., agents are deployed in an environments with legacy systems.


The inclusion of legacy systems in the modeling exercise as software agents allows the modeler to capture the current IT landscape and helps to mark applications that are affected by (i.e. that have to be transduced or wrapped to enable agent communication) the introduction of the future MAS. Moreover, coarse-grained modeling of legacy systems’ activities in AB diagrams exposes their generic functionalities and interaction touch points.

Fig. 3. The Interaction Structure diagram of the GTS process.


In Fig. 3, certain roles have been grouped on higher levels in the tree. This grouping is based on the TALL Role Structure diagram48 (see Fig. 4). This diagram can be used by the modeler to depict an organizational or reporting structure in the business domain under consideration. Grouping of roles in the IS diagram is a modeling convenience that enables the modeler to avoid role clutter as parent interactions collect the roles of their children.

Fig. 4. The composition of roles at GTS.

3.2.3. Agent behavior modeling

Fig. 5 shows a segment of the IS diagram of Fig. 3 that focuses on the Register Booking Request interaction. The human agent Shipper X and the software agent GTS ERP System are assigned to the roles Customer and Transaction System. Both agents own a behavior that is used to perform the interaction.

Fig. 5. A fragment of the IS diagram of the GTS process in which two agents provide a behavior to perform the Register Booking Request interaction.

In the IS diagram, the behaviors of the agents, which are playing the roles attached to the elementary interactions, are indicated by chevron symbols. Chevron symbols represent the explicit local views or behaviors of the agents on an abstract level and appear adjacent to their owner agent. As mentioned before, chevrons have agent-role labels as


their names. The agent-role label is a concatenation of the agent name (the owner), a colon, and the role name. The interaction to which the behavior is applied is apparent from the position of the chevron symbol. Each chevron symbol is a compact representation of an AB diagram that details the behavior of the owner agent. Fig. 6 shows the two AB diagrams that detail the chevron symbols in Fig. 5. The two agents use these behaviors to perform the Register Booking Request interaction.

Fig. 6. The AB diagrams of the agents that are playing the roles attached to the Register Booking Request interaction in Fig. 5.

AB diagrams are based on the Behavior net formalism49 and capture the intended behaviors of their owners. The Behavior net formalism is an extension of the CP net formalism with the message place type. Message places enable the flow of tokens between the different agent behaviors in an interaction. The AB diagram is a swimlane that depicts the internal states of the agent and the events or activities that cause it to change states. The messages send and received by the agent are modeled explicitly as


message places (see Fig. 6). The labels of message places act as their type names. These type names are useful in order to determine on which message place an incoming message is placed (e.g. the Booking overview message that is received by Shipper X). Message exchange is peer-to-peer, which means if a message is send to two agents, the message place is modeled twice in the AB diagram. Based on the presumed ontological alignment, agents use similar type declarations for matched message places and assign the same semantic meaning to these type names. Each swimlane is marked with the (agent-role) label of the corresponding chevron.

An agent can own multiple AB diagrams for each interaction it knows about. The associated chevron symbols may be drawn inside the owner agent. This means each agent can have a knowledge base of applicable behaviors in the form of AB diagrams. In the IS diagram, only the AB diagram that is selected for usage in an interaction is depicted (as is in Fig. 5). During enactment of the IS diagram by a computational environment, agents can make contextual run-time choices from their knowledge base of AB diagrams. The agents need to be implemented with a selection mechanism in order to identify and select an AB diagram for a specific interaction. Based on the individual behavior of an agent, there is no certainty that the behavior(s) of the other agent(s) are matching the behavior of the agent. If the behaviors are matching, the agent behaviors are said to be aligned. In aligned agent behaviors, the message places are exactly matched by number and type name (as in Fig. 6).

AB diagrams are created by a modeler that adopts the viewpoint of specific agents. For simple (intra-organizational) interactions with relatively simple agent behaviors or only two agents involved, the modeler can manually ensure alignment by making sure each sending message place has a corresponding receiving message place of the same type in an AB diagram of another agent that is party in the interaction. However, for more complex interactions with many inter-agent interdependencies or in modeling exercises where multiple modelers (from different organizations or organizational units) are involved, manual alignment is not possible. Moreover, in this case mistakes are more likely to be made. Section 3.4 describes in more detail how one or multiple modelers build a TCBP model by presenting the TALL modeling activities as a method. Using the proposed verification method (see Section 4), the combined agent behaviors that result from the integration of the AB diagrams owned by agents involved in a particular (elementary) interaction can be verified for alignment and correctness. This implies that after any corrections and/or modifications, the execution of a specific (elementary) interaction is the coordinated execution of all the aligned intended agent behaviors involved.

Although human and synthetic agents do not correspond to executing objects, they are interaction participants that can be expected to exhibit certain behaviors. Simplified behaviors can be suggested for the human and synthetic agents in the form of guidelines. These guidelines can be modeled in AB diagrams and become formal behaviors. Most other modeling languages do not model human or organizational behavior since it is not under the control of the (future) system. The guidelines are either extracted from


company behavioral procedures, protocols or norms, or directly extracted from the human owners through interviews. The formalization of these behaviors makes the assumptions about these behaviors explicit and visible, and allows the structural compatibility of these behaviors to be verified against other behaviors. If all the agent behaviors are formalized, a complete executable CBP model is obtained. Moreover, the (human and synthetic) guidelines can be used to identify activities suited for software agent support (not the subject of this paper).

AB diagrams can also include beliefs about the expected behaviors of other agents. This allows an expected interaction to be modeled from the viewpoint of one agent. In this case, the AB diagram is represented as a multi-swimlaned Behavior net including message exchange points. Such AB diagrams are named interaction beliefs in TALL. More about the interaction belief concept can be found in Ref. 37. The next section presents the formal definition that supports the introduced IS and AB diagrams.

3.3. Formal definition

The formal definition of the IS and AB diagrams is presented here. Explanations of the individual parts are given immediately below the definition. Definition 1 (IS and AB diagrams). The TCBP model is a tuple (I, LI, <I, RT, R, LR, RI, A, LA, AR, AT, DR, AV, LAV, O): (a) I is the non-empty set of interactions and (b) L I: I → LabelsI is the interaction labeling function that assigns a label to each

interaction and (c) <I ⊆ I × I is a relation such that:

• <I is a partial ordering of I; • for any i∈ I the set {s∈ I | s <I i} is well-ordered; • L0 = {i 0} with L x = {i ∈ I | ht(i) = x} and ht(i) = |{s∈ I | s <I i}|.

(d) RT: I → {SEQ, SEQd, PAR, PARd, XOR, XORd} is the routing type function that assigns a routing type to each interaction.

(e) R is the non-empty set of roles and (f) LR: R→ LabelsR is the role labeling function that assign a label to each role and (g) RI: R→ I is the role-interaction function that connects roles to interactions. (h) A is the set of agents and (i) LA: A → LabelsA is the agent labeling function that assign a label to each agent and (j) AR: A → R is the agent-role function that assigns agents to roles and (k) AT: A → {H, S, Y} is the agent type function that maps each agent to a generic

agent type: Human, Software, or sYnthetic. (l) DR: ID → RS is the decision rule function that assigns a decision rule set RS to each

interaction that applies a decision rule with: • ID = {i ∈ I | RT(i)∈ {XORd, SEQd, PARd}.

(m) AV is the set of agent behaviors and (n) LAV: AV → LabelsAV is the agent behavior labeling function that assigns a label to

each agent behavior and (o) O: AV → A is the ownership function that assigns agents (read: owners) to each

agent behavior.


(a&b&c) The IS diagram is a graphical representation of an interaction tree. The interactions in the set I are the nodes in the tree that form the CBP under consideration. The set I is required to be non-empty because the root interaction is always defined for any CBP. Interactions in the IS diagram are denoted by interaction labels. Each interaction in the tree is unique. In distributed business settings, interactions can appear in one or more local IS diagrams owned by different business entities. The construction of a global IS diagram in these settings (possibly automatically by using an algorithm, see Section 7.2) can lead to similar interactions appearing at different levels in the global IS diagram. Thus, although interactions are unique they are allowed to have identical labels which are assigned by the labeling function LI. Identically labeled interactions are different by their position and are completely unrelated when executed.

The partial ordering relation < I connects parents and their children, that is, it is a set of ordered pairs (i, s) where the first element is a parent interaction i∈ I and the second element is a child interaction s∈ I. The nodes in the tree immediately greater than (or succeeding) a node are called its children. The node immediately less than (or preceding) a node is called its parent (if it exists). Any node lesser than a node is an ancestor and any node greater than a node is a descendant. The partial ordering < I represents distance from the root and the well-ordering requirement ensures that each node has at most one parent, and therefore at most one grandparent, and so on. Nodes with no ancestors are roots: {i ∈ I |¬∃ s∈ I: s <I i}. Elementary interactions are nodes with no descendants: EI = {i∈ I |¬∃ s∈ I: i <I s}. For any node, its set of ancestors is well-ordered. Hence, an ordinal that denotes height can be associated to any node: ht(i) = |{s∈ I | s <I i}|. In this way, the x-th level of the tree is defined to be the set: Lx = {i ∈ I | ht(i) = x}. Consequently, L0 denotes the root level in the tree. The set L0 is required to be a singleton set in order to make sure there exists only one root interaction i0. Whenever a << I b in I (i.e. interaction a is an immediate predecessor of interaction b), interaction a is placed higher then b in the IS diagram and there is a line drawn from interaction a to b (called an edge). In this way, movement downwards indicates succession. Graphically, the lines between each parent and its direct children converge in the routing type symbol that graphically appears below each parent.

Two auxiliary functions are defined to navigate the IS diagram. The function Children(i) returns the set of direct children (i.e. immediate successors) of interaction i: Children(i) = {s∈ I | i <<I s}. Logically, the set Children(i) is empty for an elementary interaction. The function parent(i) is used to denote the parent of interaction i: ∀ i∈ I: [parent(i) = {s∈ I | s <<I i}]. (d) Formally, each routing type is defined on the parent interaction. In the IS diagram, six routing types are supported (see Fig. 7). Type SEQ indicates that all children of the parent interaction execute in sequence, PAR that all children execute in parallel, and XOR that a non-deterministic choice is made to execute only one of the children at a time. In most cases, routing is determined based on the fulfillment of certain data conditions. The types SEQd, XORd, and PARd apply decision rules, which enables condition-based execution of a set of direct child interactions. Type XORd uses a decision rule to make a deterministic


choice for only one of the direct children. Ref. 50 introduces the multi-choice routing pattern that can choose multiple alternatives from a given set of alternatives. This construct corresponds to an OR-split in which one or more of the child interactions is executed at a time (i.e. an inclusive choice is made). However, when two or three are executed it is not clear if these children are executed sequentially or in parallel. The types SEQd and PARd deal with this issue. Based on the evaluation of the decision rule, an inclusive choice is made for one or more of the children.

Fig. 7. The routing types supported in the IS diagram.

The function rank IS→ ℕ (based on Ref. 51) is used to indicate the (sequential) order of two or more children of parents with type SEQ or SEQd: IS = {s∈Children(i) | RT(i)∈ {SEQ, SEQd} ∧ |Children(i)| > 1}. Graphically, the sequential order is determined by the relative horizontal positions of the child interactions, starting at rank zero and increasing with one unit from left to right.

In addition to these six routing types, iterative routing can be accomplished by attaching a single child to a parent interaction with routing type SEQd. The decision rule contains the iteration and enforces the repeated execution of the single child (and its children, sub children, and so on). An example is the Plan Booking Request interaction in Fig. 3. Based on the evaluation of the decision rule, the Plan Booking Request interaction is executed at least once and continues until a certain condition holds (like the java “do-while” construct) or executes the child a certain number of times through a counting loop (like the java “for” loop). In the GTS process, when a booking request is being planned, the networkpoint for which the booking request is made and the requesting shipper is blocked. Another booking request on the same networkpoint or by the same shipper is put in a queue. Planning attempts are made until the booking has been successfully planned.

Ref. 52 mentions that in most WfM systems the degree of parallelism is fixed in the process definition. It is not possible to concurrently execute selected parts of the workflow process a variable number of times. Although iteration can be used to execute parts a variable number of times, according to the authors this results in the sequential execution of inherently parallel tasks. The PARd routing type with a single child enables the parallel execution of a predefined number of maximum occurrences of the single child. Again, the child must be executed at least once.


(e&f&g) The set R contains all the roles that are relevant to the set of interactions I. Each interaction i ∈ I is required to have at least two roles attached: I = {i ∈ I |∃ 2≥ r∈R: (r, i) ∈RI}. Since the root interaction is always defined, the set R is required to be non-empty. The function RI connects roles to interactions such that each role r ∈R belongs to an unique ordered pair (r, i) in RI. Whenever (r, i) ∈RI, there is a line drawn between r and i in the IS diagram. When multiple agents play the same role in a certain interaction, they are assigned to a single occurrence of that role. (h&i&j&k) The set of agents A is built by identification of the agents in the business domain under consideration. Each agent is a human, software, or synthetic agent. Agents are denoted by agent labels. The function AR connects agents to roles such that each agent a∈A belongs to an unique ordered pair (a, r) in AR. Whenever (a, r)∈AR, there is a directed line drawn between a and r in the IS diagram. This line always carries the annotation plays.

(l) The set ID contains all interactions with a routing type that needs to dynamically apply a decision rule (XORd, SEQd, and PARd). This decision can be generically expressed as a “rule”, called here decision rule. The function DR assigns a decision rule set (RS) to each interaction i ∈ ID, and this set manages the control flow of the direct child interactions of i at runtime. An RS can be viewed as a pseudo-workflow that is built upon implicit, explicit, and eventual formal business rules.53 In the abstract formal definition of the IS diagram, it is not necessary to specify the concrete syntax in which the rules are specified internally to the agents. The exact syntax depends on the formal (rule-based) framework that is used to build the (agent-based) execution environment.

The business domain under consideration can adopt a collaborative IT platform based on agent technology as an execution environment for distributed CBP execution that enacts the IS diagram, the associated (agreed upon) business rules, and coordinates the distributed agent behaviors. Based on the decoupling between the interaction structure and the individual behaviors of the agents (IS diagram vs. AB diagrams), all the rule sets should be separated from the agents. Moreover, they should be explicitly represented, as well as (possibly) dynamically inspectable and modifiable.54 In this way, each RS can be considered the formal expression of the business logic available and known to all agents involved in the provision of a certain CBP.

(m&n&o) The set AV contains all agent behaviors in the business domain under consideration. Graphically, the elements (read: agent behaviors) in this set appear in a compact form (as chevron symbols) in the IS diagram and as detailed agent behaviors (read: Behavior nets) in the AB diagrams. Although agents can own multiple AB diagrams for the same interaction, the formal definition focuses on the behaviors used by the agents to perform the interactions. These are also the relevant behaviors for design-time process verification. Agent behavior labels are agent-role labels that mark the chevron symbols in the IS diagram and the swimlanes in the AB diagrams. Ownership of agent behaviors is set by the function O that assigns agent behaviors to agents such that each agent behavior belongs to an unique ordered pair (av, a) in O. Agents that play a role, select and use one agent behavior to perform the interaction. The composition


RI�AR of the functions AR and RI is a function from the set of agents A to the set of interactions I: RI �AR: A → I. A pair (a, i) is only a member of the composition if there exists a role r ∈R and an agent a∈A that is connected to that role, and if the role is connected to the interaction i∈ I: {(a, i)∈A × I | ∃ r∈R: (a, r)∈AR ∧ (r, i)∈RI}. Whenever (a, i)∈RI�AR, the selected agent behavior (i.e. chevron symbol) is drawn at the agent side of the agent-role line with its arrowhead connected to the line (as in Fig. 5). The auxiliary function ReturnAV(i) returns the subset of agent behaviors that are owned and selected by the role-playing agents involved in the elementary interaction i ∈EI: ReturnAV(i) = {av∈AV | ∀ a∈A: (av, a)∈O∧ (a, i)∈RI �AR ∧ i∈EI}. Logically, ReturnAV(i)⊆ AV.

3.4. Tool support and modeling method

3.4.1. Toolset

A software toolset has been developed to support TALL. The toolset consists of a graphical editor suite and a database that allows for model management. The graphical editor suite consists of two graphical editorsg. The interaction editor is used by the modeler to build and manipulate IS diagrams. Fig. 8 shows the IS diagram of the GTS process in the interaction editor without the roles.

Fig. 8. Screenshot of the interaction editor that shows the IS diagram of the GTS process.

g The TALL graphical editor suite can be downloaded from the software section on http://www.agentlab.nl/


The interaction editor stores the TALL diagrams and its modeling elements (including the relationships between elements) in an associated database. Fig. 9 shows the interface to manage this database (i.e. the Table view window).

Fig. 9. Screenshot of the interaction editor showing the drawing window, the database interface used by the modeler to manipulate the drawing window, and the main window of the translation tool.

To add and remove modeling elements (i.e. agents, roles, interaction, behaviors, and the relations between them) or to change the properties of elements, the database interface can be directly manipulated. Newly created elements appear automatically in the drawing window and additional appearances of existing elements can be added upon user request. In the drawing window, any element can be directly selected and moved. The lower right window shows the interface of the translation tool that implements the translation technique (see Section 5.2).

The agent behavior editor supports the creation and manipulation of Behavior nets in order to create AB diagrams. The behavior editor can be started from the database interface in order to detail specific chevron symbols using AB diagrams. On save, the AB diagram is stored in an XML-format in the database and linked to the specific chevron symbol. The behavior editor is described in more detail in Ref. 55.

3.4.2. Modeling method

The TALL modeling method is based on the following activities.


Define the collaborative business domain and acquire the necessary knowledge The interaction and behavior models are developed for a specific collaborative business domain by one or more modeler(s)h. The input to the modeling method is company and business process documentation, analysis of the business domain and business processes, and any other knowledge acquisition methods. During analysis, the domain experts and process participants play an important role because they are knowledgeable about the interactions and behaviors performed by them as well the interrelationships with interactions and behaviors performed by others. Thus, the modeling exercise is most advantageous when the business domain under consideration allows domain experts and process participants to be actively involved. The modeler has the task to collect the (local) process information from the humans and capture it as a business process model. The output is a global IS diagram and several AB diagrams that specify the agent behaviors. All diagrams under design can be validated together with process experts to check if the model reflects reality and user expectations. Identify and understand the high-level synthetic agents The highest-level synthetic agent is the agent that contains the high-level partners, which form the team operating the CBP. The partners make up the first level of synthetic agents and form the starting point for the development of the TCBP model in the following steps. The current activity creates an AS diagram for each first-level synthetic agent. In this regard, the synthetic agent concept guides thinking at the initial scoping stage when the existing agents in the business domain are identified. This activity includes an analysis of the current IT landscape to identify any applications that may need to communicate with a future MAS. These applications are modeled as software agents, or as synthetic agents that consist of subsystems or modules modeled as software agents. The latter is useful when certain system functionalities are suited to be integrated into a (future) software agent. Build the global IS diagram This activity tries to understand how the different agents interact with each other. Interactions are identified and named in parallel with the roles since interactions occur between agents/roles. During this step, the single modeler implicitly builds a common shared ontology of interactions and roles based on the views and beliefs of the agents. In a multi-modeler situation, it is assumed that the interaction and role names are based on a shared ontology in the business domain. The global diagram is built using a top-down or bottom-up approach:

hThe modelling activities can be executed by a single modeller that captures the entire business domain. However, in inter-organizational settings, it cannot be assumed that organizations are willing to share the inner details of their business processes. In this case, each organization can elects its own modeller and only share their local IS diagrams to facilitate coordination of the overall CBP. Section 7.2 discusses public and private processes in more detail.


• Top-down approach: Start with the overall root interaction of the CBP and decompose it by identifying and naming interactions and their routing types. Continue the decomposition process as long as subtrees can be created.

• Bottom-up approach: Identify and name interactions (and their routing types) and compose these into a global IS diagram. Alternatively, interactions can be identified and named separately for each first-level synthetic agent and composed into different local IS diagrams. These local IS diagrams can then be merged automatically using an algorithm (see Section 7.2).

In practical modeling exercises, a combination of these approaches is typically used. Assign agents to the roles and build the AB diagrams For verification and execution purposes, it is sufficient to assign agents to the elementary interactions. However, for descriptive purposes agents can be assigned to any interaction in the IS diagram. If any new agents are identified, the initial AS diagram is updated. In general, identification of agents and roles is important because these concepts form the basis for interaction design and agent programming.56 During this activity, the viewpoint of specific agents is adopted and their behaviors are detailed in AB diagrams. As mentioned before, simplified behaviors that act as guidelines can be set for the behaviors of human or synthetic agents that are too complex to model. Moreover, AB diagrams can be created for software agents that represent legacy systems in order to expose their generic functionality in the form of activities and message exchange points. From a simulation or verification perspective, all the AB diagrams are executable specifications. Translate the TALL CBP model into a verifiable HCP net The proposed verification method relies on using existing formal methods and associated computer tools to determine the structural correctness of the TCBP model. The entire TCBP model (i.e. the combined interaction and behavior diagrams) is translated to a HCP net for verification purposes (see Section 4). Use CPN Tools to verify the produced HCP net This research adopts CPN Tools57 to execute formal verification of the produced HCP net. The translation technique has been implemented in a software tool that is part of the TALL graphical editor suite (see Section 5.2). This translation tool produces a HCP net format that can be directly loaded in CPN Tools.

4. Verification of the TALL CBP model

Sections 4 to 6 of this paper are devoted to the explanation of the verification method for the TCBP model. This section defines the verification method (Section 4.1) and motivates the need for verification (Section 4.2).


4.1. A verification method for agent-driven CBPs

The verification method consists of three sequential phases: (1) the translation of the TCBP model to a HCP net, (2) the identification of process design errors, and (3) the correction and rollback of process design errors to the TALL models. The first phase is detailed in Section 5, the second and third phase are detailed in Section 6.

For the first phase, the TCBP model is translated to a HCP net so that the analysis power of CP nets can be leveraged and existing computer tools that implement proven verification techniques can be used. A single HCP net that combines the IS and AB diagrams is produced by the translation. In this way, all participants and their behaviors are represented and a single executable CBP model is obtained that can be checked for proper termination and completion. The execution of an elementary interaction is the coordinated execution of the agent behaviors involved. After translation, the verification method checks the structural compatibility of the combined agent behaviors that have to complete a certain elementary interaction. Structural compatibility is ensured when the combined agent behaviors are structurally correct.

There are different ways to define structural correctness. The notion of sound workflow nets58-59, a special subclass of Petri nets, expresses correctness criteria any workflow process should satisfy. These criteria are relevant to any executable business process model. A workflow is named sound if and only if it satisfies the following requirements: • Option to complete: for each token put in the start place, one (and only one) token

eventually appears in the end place; • Proper completion: when a token appears in the end place, all the other places are

empty; • No dead transitions: for each transition, it is possible to move from the initial state to

a state in which the transition is enabled. The proposed verification method uses the soundness notion to check the structural correctness/compatibility of the agent behaviors. The verification method is execution-platform-independent and is concerned with design-time verification. The latter means that the method verifies the model before full data and control features are added. At execution time, agents deal with a wide range of parameters and environmental factors. This may cause run-time errors and prevent proper CBP completion. Design-time verification ensures that there exists a scenario that can successfully end through a specific set-up of agent behaviors for a certain interaction. Ref. 8 makes an analogy with a labyrinth. At design time, it is verified whether there is a path that leads to the exit. At execution time, the interacting agents should try not to engage in a death-end path. This research is concerned with the former only. By performing model-based verification at design time, potential problems can be identified and resolved before the model is put into use.34

The identification of process design errors occurs in the produced HCP net in the second phase. In the third phase, any errors in the agent behaviors that are pinpointed in the second phase are rolled back to the TCBP model. After correction, the sound agent


behaviors can be subject to further design and/or implementation. Section 7 discusses this in more detail.

4.2. The necessity of the verification method

A CBP consists of many interacting agents that use their local behaviors to execute parts of the process autonomously. The design complexity of CBPs and the many execution interdependencies between the agents spurs the need for formal verification at design time. A coherent and coordinated set-up of the agents is required, a setup in which the agent behaviors contain no design errors and inconsistencies, and send each other the required messages to complete their behaviors, the desired interactions, and finally the CBP instance.

A MAS is a complex system with high investment and critical requirements. A coherent set-up of the agents enhances the reliability of the process design and the (future) MAS that supports the CBP. In this regard, design-time verification can minimize conflicting and redundant efforts among the agents. Corrections made at process execution time can be very costly. Not only the flawed agent behaviors may need to be corrected and/or modified, but also certain parts of running CBP instances may need to be redone, or even the whole CBP instance may need to start over, sometimes by applying costly rollback procedures. In the case of several CBP instances being active simultaneously – or if performing certain activities is costly or is required to be timely – correcting agent behaviors at execution time is detrimental. Moreover, it may displease partners or customers, especially in distributed settings where malfunctioning affects several organizations or organizational units.

5. Translation of the TALL CBP Model to a Hierarchical Colored Petri net

The direction taken in this research is to translate the TCBP model to a HCP net for verification purposes. For an elaborate introduction into (H)CP nets, the reader is referred to the work of Jensen.60-61 Section 5.1 formally describes the translation as a set of translation functionsi. After, Section 5.2 presents a software tool that implements the translation technique.

5.1. Translation: Formal definition

The formal definition consists of eleven translation functions that map the global IS diagram and the associated AB diagrams into a single HCP net. The functions use the following notations from the formal definition of (H)CP nets60-61: (a) ∑ is the finite set of non-empty types also called color sets, P is the finite set of

places, T is the finite set of transitions, A is the finite set of arcs, S if the finite set of subnets or pages, SN⊆ T is the set of substitution nodes, and PN⊆ P is the set of

i The formal definition of the TCBP model is defined directly on its syntax and is the starting point for the translation to a HCP net. Alternatively, the syntax of TALL could be translated to the syntax of HCP nets that already has a formal semantics. This is unwanted since HCP nets is not an agent-based language.


port nodes. Places and transitions are both referred to as nodes in a (H)CP net. In a HCP net, the substitution node or transition is the most important hierarchy construct (drawn as a double-bordered transition). A substitution transition acts as the parent transition of a subpage that contains the detailed behavior of the activity represented by the substitution transition;

(b) C is the color function that is defined from P into∑ . C maps each place to a color set;

(c) SA is the page assignment function that is defined from SN into S. SA relates substitution transitions to their subpages such that no page is a subpage of itself;

(d) PA is the port assignment function. PA is defined from SN into binary relations that relate socket places with port places. The port assignment relates socket places on the super page (the places that surround the substitution transition) to port places on the subpage;

(e) PT is the port type function that is defined from PN into {in, out, i/o, general}; (f) ST is the socket type function that maps from pairs of socket places and substitution

transitions into {in, out, i/o}. Related socket and port places must have matching port and socket types and conceptually represent the same place (i.e. they always have identical markings);

(g) N is the node function that is defined from A into P× T∪ T× P. N maps each arc into a pair where the first element is the source node and the second the destination node;

(h) In(x) returns the set of input nodes for a node x: In(x) = {x’ ∈X |∃ a: N(a) = (x’, x)} and Out(x) returns the set of output nodes for a node x: Out(x) = {x’∈X |∃ a: N(a) = (x, x’)}.

In addition, the following notations are introduced: • LF is the HCP net Labeling Function. LF: X → V where X = P∪ T∪ A and V is a set

of labels; • Net elements are augmented with a page index in order to refer to the elements on a

specific page in the produced HCP net. For example, Ps is used to denote the places and Ts is used to denote the transitions on page s. The page index is omitted when referring to the elements of the entire produced HCP net;

• There exists a one-to-one correspondence between the set SN of the produced HCP net and the set of interactions I in the global IS diagram. Based on this, two bijective functions are defined: map1: I→ SN and map2: SN→ I. The former returns the corresponding substitution transition t∈SN of interaction i ∈ I while the latter returns the corresponding interaction i ∈ I of substitution transition t∈SN.

The translation functions are augmented with figures for clarification (Fig. 11 to Fig. 14). In these figures, the socket type of a place is written in a small rectangle that appears below the place at the right or left side, which indicates the transition on which the socket type is defined. The port type of a place is written in a small circle that appears below the place. Place labels are written inside the circles and (substitution) transition labels are written inside the squares.

As explained in Section 4, the verification method abstracts away from data and control aspects. This impacts on the routing types XORd, SEQd, and PARd that make deterministic choices based on an evaluation of the data conditions in the decision rules.


Therefore, the translation technique represents these deterministic choices as non-deterministic choices (see Fig. 10).

Fig. 10. Unfolding transitions to produce non-deterministic choices.

Definition 2 (Translation). The translation is formally defined by a set of eleven translation functions. Translation Function 1 (RTF): Root Interaction Suppose: i∈ I ∧ i ∈L0. Then interaction i is the root interaction i0. The Root Translation Function RTF maps i0 into a page s*∈S (called the prime page) that contains substitution transition t1∈SNs with adjacent input and output places such that:

xn∈Ps∧ In(t1) = x1 ∧ Out(t1) = x2 ∧ ST(x1, t1) = in∧ ST(x2, t1) = out∧ LF(xn) = pn ∧ LF(t1)

= map2(t1).

The prime page s* serves as the start page of the entire produced HCP net. All the other pages are subpages of s*. Fig. 11 shows three examples of the translation of a root interaction A using the function RTF.

In the IS diagram, routing applies to sets of direct child interactions that are completed according to the routing type of their parent interaction i. The function Children(i) returns a set of direct child interactions of an interaction i. The subsequent translation functions 2 to 8 translate, for each routing type, the set of direct child interactions into a page that manages the corresponding control flow. Translation Function 2 (STF): Sequential Routing Suppose: i∈ I ∧ RT(i)∈ {SEQ}. The Sequential Translation Function STF maps Children(i) into a subpage s∈S that contains a finite non-empty sequence of substitution transitions t1, t2, …, tm∈SNs with adjacent input and output places such that:

∀ k∈ {1, .., |Children(i)|}:

[xn∈Ps∧ In(tk) = xk ∧ Out(tk) = xk+1 ∧ ST(xk, tk) = in∧ ST(xk+1, tk) = out∧ x1,

xm+1∈PNs ∧ PT(x1) = in∧ PT(xm+1) = out∧ LF(xn) = pn ∧ LF(tk) = map2(tk)].

Fig. 11a illustrates the translation of a set of sequential child interactions using the function STF. In the specific example of Fig. 11a, Children(i) contains three interactions. Translation Function 3 (SCF): Sequential Conditional Routing Suppose: i∈ I ∧ RT(i)∈ {SEQd} ∧ |Children(i)| > 1. The Sequential Conditional translation Function SCF maps Children(i) into a subpage s∈S that contains a finite non-


empty sequence of substitution transitions t1, t2, …, tm∈SNs with adjacent input and output places, and artificial control flow tasks for inclusive conditional sequential splitting- and joining-behavior such thatj:

∀ k∈ {1, .., |Children(i)|}:

[xn∈Ps∧ yn∈Ts\SNs ∧ In(tk) = xk*2 ∧ In(xk*2) = yk ∧ In(yk) = x(k*2)-1 ∧ Out(x(k*2)-1) =

yk*2 ∧ (Out(tk), Out(yk*2) = x(k*2)+1) ∧ ST(xk*2, tk) = in∧ ST(x(k*2)+1, tk) = out∧ x1,

x(m*2)+1∈PNs∧ PT(x1) = in∧ PT(x(m*2)+1) = out∧ LF(xn) = pn ∧ LF(yn) = tn ∧ LF(tk) =

map2(tk)].

Fig. 11b illustrates the translation of a set of conditional sequential child interactions using the function SCF. As explained, the SEQd routing type is an OR-split in which one or more interactions are executed at a time. When two or more interactions are enabled, they are executed in a sequence. On the subpage A#1, a non-deterministic choice is made either to execute the substitution transition tk or to bypass it.

Fig. 11. Examples of the translation of a set of three sequential (top), three conditional sequential (middle), and a single child that is iterated sequentially (bottom).

Translation Function 4 (SIF): Sequential Iterative Routing Suppose: i∈ I ∧ RT(i)∈ {SEQd} ∧ |Children(i)| = 1. Then Children(i) is a singleton set {z}. The Sequential Iterative translation Function SIF maps Children(i) into a subpage

j In the translation functions, the * sign is the multiplication operator.


s∈S that contains substitution transition t1∈SNs with adjacent input and output places, and artificial control flow tasks for looping behavior such that:

xn∈Ps∧ yn∈Ts\SNs ∧ In(t1) = x1 ∧ Out(t1) = x2 ∧ Out(x2) = y1, y2 ∧ Out(y1) = x1 ∧ Out(y2)

= x3 ∧ ST(x1, t1) = in∧ ST(x2, t1) = out∧ (x1, x3∈PNs) ∧ PT(x1) = in∧ PT(x3) =

out∧ LF(xn) = pn ∧ LF(yn) = tn ∧ LF(t1) = map2(t1).

Fig. 11c illustrates the translation of a single child interaction B using the function SIF. At place x2, a choice is made either to repeat or not repeat t1. Because the choice to repeat transition t1 is non-deterministic, t1 can potentially be repeated infinitely and cause the entire HCP net (read: the CBP instance) to get locked in an endless loop. The definition of soundness assumes a notion of fairness, which means that it is assumed that iteration does not violate the soundness requirements by postponing transition t2 indefinitely. The fairness assumption is reasonable since in collaborative domains all choices are made (implicitly or explicitly) by agents that share and pursue a common (business) goal. Translation Function 5 (PTF): Parallel Routing Suppose: i∈ I ∧ RT(i)∈ {PAR}. The Parallel Translation Function PTF maps Children(i) into a subpage s∈S that contains a finite non-empty sequence of substitution transitions t1, t2, …, tm∈SNs with adjacent input and output places, and artificial control flow tasks for parallel splitting- and joining-behavior such that:

∀ k∈ {1, .., |Children(i)|}:

[xn∈Ps∧ yn∈Ts\SNs ∧ In(tk) = xk+1 ∧ Out(tk) = xk+m+1∧ In(xk+1) = y1 ∧ In(y1) =

x1 ∧ Out(xk+m+1) = y2 ∧ Out(y2) = x(m*2)+2 ∧ ST(xk+1, tk) = in∧ ST(xk+m+1, tk) = out∧ (x1,

x(m*2)+2∈PNs) ∧ PT(x1) = in∧ PT(x(m*2)+2) = out∧ LF(xn) = pn ∧ LF(yn) = tn ∧ LF(tk) =

map2(tk)].

Fig. 12a illustrates the translation of a set of parallel child interactions using the function PTF. The transition y1 is used to produce tokens for all of the input nodes of the parallel substitution transitions tk. Similarly, the transition y2 is used to synchronize the parallel paths. Translation Function 6 (CPF): Conditional Parallel Routing Suppose: i∈ I ∧ RT(i)∈ {PARd} ∧ |Children(i)| > 1. The Conditional Parallel translation Function CPF maps Children(i) into a subpage s∈S that contains a finite non-empty sequence of substitution transitions t1, t2, …, tm∈SNs with adjacent input and output places, and artificial control flow tasks for inclusive conditional parallel splitting- and joining-behavior such that:

∀ k∈ {1, .., |Children(i)|}:

[xn∈Ps∧ yn∈Ts\SNs ∧ In(tk) = xk+4 ∧ Out(tk) = xk+m+4∧ In(xk+4) = yk*2 ∧ In(yk*2) =

xk+1 ∧ In(xk+1) = y1 ∧ In(y1) = x1 ∧ Out(xk+1) = y(k*2)+1 ∧ Out(y(k*2)+1) = xk+7 ∧ Out(xk+7) =


y(m*2)+2 ∧ Out(y(m*2)+2) = x(m*3)+2 ∧ ST(xk+4, tk) = in∧ ST(xk+m+4, tk) = out∧ (x1,

x(m*3)+2∈PNs∧ PT(r1) = in∧ PT(x(m*3)+2) = out∧ LF(xn) = pn ∧ LF(yn) = tn ∧ LF(tk) =

map2(tk)].

Fig. 12b illustrates the translation of a set of inclusive conditional parallel child interactions using the function CPF. The behavior of the PARd routing type is related to the SEQd routing type since it also an OR-split that makes a choice between one or more children. However, when two or more interactions are enabled they are executed in parallel. The subpage A#1 first uses the transition y1 to enable parallel execution of all the children. Next, a non-deterministic choice is made either to execute the substitution transition tk or to bypass it. When the substitution transitions tk are not executed, the bypass route makes sure that the flow can continue by producing the needed tokens for the synchronizing transition y8.

D

PARd

A

CB

CPF

RTFp2p1

Root#0

in out

x1 x2t1

p1 t1

p2

x1

y1x1

in

t2 p5

x5y2

in

out

p8

t1

x8

t8

out

p11

A#1

y8 x11

A

p1 t1

p2

p3 p6

p7

p5

t2 p8

p4

p2p1

Root#0

in out

A#1

x1 x2

x2

x3

x4

x5

x7

x6 y2 x8

in out

in out

in out

in outt3

t2

t1

t1

D

PAR

A

CB

PTF

RTF

B

x1 y1

t3

p3

x2

t4 p6

x6y1

in

out

p9

t2

x9

t5

p4

x3

t6 p7

x7y6

in

out

p10

t3

x10

t7

y3

y5

y7

PARd

A

B

RTF

PIF

p2p1

Root#0

in out

x1 x2t1

p1 t1

p2

p3 p8

p9

p7

t2 p12p4

x2

x3

x4

x7

x9

x8

y2 r2y1x1

in out

in out

in outin out

t3

t2

t1

p10p5

in out

p11p6

in out

x5

x6 t5

t4 x10

x11

A#1

C

C

D

A

B

A

B

C

D

A

B

B

B

B

B

Fig. 12. Example of the translation of a set of three parallel (top), three conditional parallel (middle), and a single child that is performed a certain pre-defined number (5 in this example) of times in parallel (bottom).

Translation Function 7 (PIF): Parallel Iterative Routing


Suppose: i∈ I ∧ RT(i)∈ {PARd} ∧ |Children(i)| = 1. Then Children(i) is a singleton set {z}. The integer n is a counter that indicates how many times the single child should be performed in parallel. The Parallel Iterative translation Function PIF maps Children(i) into a subpage s∈S that contains a finite non-empty sequence of substitution transitions t1, t2, …, tm∈SNs with adjacent input and output places, and artificial control flow tasks for parallel splitting- and joining-behavior such that:

∀ k∈ {1,.., n}:

[xn∈Ps∧ yn∈Ts\SNs ∧ In(tk+1) = xk+1 ∧ Out(tk) = yk+m+1∧ In(xk+1) = y1 ∧ In(y1) =

x1 ∧ Out(xk+m+1) = y2 ∧ Out(y2) = x(m*2)+2 ∧ ST(xk+1, tk) = in∧ ST(xk+m+1, tk) = out∧ (x1,

x(m*2)+2∈PNs) ∧ PT(x1) = in∧ PT(x(m*2)+2) = out∧ LF(xn) = pn ∧ LF(yn) = tn ∧ LF(tk) =

map2(tk)].

Fig. 12c illustrates the translation of a single child interaction B using the function PIF. This translation is identical to the PAR routing type except that the number of parallel paths depends on the value of the counter. Interaction B needs to be performed at least once. In the translation tool (Section 5.2), the number of the counter is fixed arbitrarily at five and can be changed by the user in the interaction editor. Translation Function 8 (ECF): Exclusive Conditional Routing Suppose: i∈ I ∧ RT(i)∈ {XOR, XORd}. The Exclusive Conditional translation Function ECF maps Children(i) into a subpage s∈S that contains a finite non-empty sequence of substitution transitions t1, t2, …, tm∈SNs with adjacent input and output places, and artificial control flow tasks for non-deterministic exclusive selective splitting- and joining-behavior such that:

∀ k∈ {1, .., |Children(i)|}:

[xn∈Ps∧ yn∈Ts\SNs ∧ In(tk) = xk+1 ∧ Out(tk) = xm+2∧ In(xk+1) = yk ∧ In(yk) = x1 ∧ ST(xk+1,

tk) = in∧ ST(xm+2, tk) = out∧ (x1, xm+2∈PNs) ∧ PT(r1) = in∧ PT(r2) = out∧ LF(xn) =

pn ∧ LF(yn) = tn ∧ LF(tk) = map2(tk)].

Fig. 13 illustrates the translation of a set of exclusive conditional child interactions using the function ECF. The translation of the XORd routing type is the same.

Fig. 13. Example of the translation of a set of three non-deterministic exclusive conditional child interactions.


Translation Function 9 (ABF): Agent Behavior Translation This translation function uses the following notations: • s is the start place and f is the final place of the Behavior net av∈AV that represents

the intended behavior of an agent such that: s, f∈Pav and In(s), Out(f) = ∅ ; • The output of ABF is the (sub)page s∈S. The page s is a union of the Behavior nets

av∈ReturnAV(i). Hence, the net elements of s consist of all the combined elements of these Behavior netsk:

Ts = ( )av ReturnAV i∈

∪ Tav , Ps = ( )av ReturnAV i∈

∪ Pav , MPs = ( )av ReturnAV i∈

∪ MPav , and As =

( )av ReturnAV i∈∪ FIav∪ FOav;

• MPS is the set of message places for sending messages and MPR is the set of message places for receiving messages: MPSs = {mp∈MPs | Out(mp) =∅ }, MPRs = {mp∈MPs | In(mp) =∅ } and MPSs∩ MPRs = ∅ ;

• MPM is the Message Place Matching function. It is defined from MPSs into MPSs× MPRs. MPM relates message places for sending to message places for receiving such that: • Related message places appear in two agent behaviors involved in the same

interaction:∀ (mps,mpr)∈MPM(mps):[∃ i∈EI ∧ ∃ av1,av2∈ReturnAV(i)∧ mps∈av1 ∧ mpr∈av2;

• Related message places have identical data types:∀ (mps, mpr)∈MPM(mps): [C(mps) = C(mpr)].

Suppose: i∈EI ∧ ReturnAV(i)≠ ∅ . Then interaction i is an elementary interaction with associated AB diagrams. The AB diagrams are returned by the function ReturnAV(i). The Agent Behavior translation Function ABF maps ReturnAV(i) into a single “behavioral” subpage s∈S that details the behavior of the substitution transition corresponding to the elementary interaction i. This page contains the combined Behavior nets and artificial control flow tasks (and adjacent input and output places) for parallel splitting and joining of the Behavior nets such that:

∀ k∈ {1, .., |ReturnAV(i)|}:

[xn∈Ps∧ yn, zn∈Ts∧ In(sk) = y1 ∧ In(y1) = x1 ∧ Out(fk) = y2 ∧ Out(y2) = x2 ∧ (x1,

x2∈PNs) ∧ PT(x1) = in∧ PT(x2) = out∧ ∀ (p, p’)∈MPM(p): [(p, p’)∈Ps ∧ Out(p) =

zn ∧ In(p’) = zn] ∧ ∀ p∈ (Ps∪ MPs)\xn: LF(p) = LF(pav) ∧ ∀ t∈Ts\{y n, zn}: LF(t) =

LF(tav) ∧ LF(x1) = S∧ LF(x2) = F∧ LF(y1) = t1 ∧ LF(y2) = t2 ∧ LF(zn) = dn.

Fig. 14 illustrates the translation of an IS diagram where three agents bring behaviors to perform the elementary interaction C. The function ABF translates the AB diagrams into a single page C#2 that contains the three combined agent behaviors. Fig. 14 shows that ABF connects pairs of matching message places to a shared transition that acts as a k Ts is the finite set of transitions, Ps is the finite set of places, MPs is the finite set of message places, FIs is the finite set of incoming arcs that connect (message) places and transitions, and FOs is the finite set of outgoing arcs that connect transitions and (message) places.


synchronization point between the agent behaviors. Message places are matched based on a simple rule. Each sending message place of an agent is matched with a receiving message place of another agent that has the same message type. If there are two agents with such a receiving place, only one pair is created since communication is considered to be peer-to-peer. Message places that do not have a matching message place are not attached to a shared transition. If such message places exist, then the behaviors are not aligned. This can be resolved during the verification process when the behaviors can be corrected or modified (see Section 6.2). In the (simple) example of Fig. 14, all message places are exactly matched by type name and number, which results in four pairs.

Fig. 14. Example of the translation of an elementary interaction C and the associated AB diagrams.

Translation Function 10 (EIF): Pruning of Elementary Interactions The previous translation functions translate the interactions in the global IS diagram into substitution transitions. However, if elementary interactions have no associated AB diagrams, the corresponding substitution transitions have no subpages. IA is the set of elementary interactions that have no associated agent behaviors: IA = {i∈ I | i∈EI ∧ ReturnAV(i) = ∅ }. The Elementary Interaction pruning Function EIF turns all substitution transitions that correspond to interactions in the set IA into “normal” transitions such that:


∀ i∈ IA: [map1(i)∈T ∧ SN\map1(i)∧ ∀ p∈P: ST(p, map1(i)) =∅ ].

Translation Function 11 (PLF): Page Labeling The function PLF is the Page Labeling Function. It is defined from S into a set of page labels Z such that: • s = s*→PLF(s*) = Root#0. The prime page receives Root#0 as its page name. • s≠ s* →PLF(s) = LF(t)^#^ht(map2(t))+1 with t∈SN and SA(t) = s. The operator ^ is the concatenation operator for text strings. Each page that is not the prime page is assigned a page label, which is a string concatenation of the label of the substitution transition on the super page of s, the # sign, and the interaction level or height on which interaction i appears (increased with 1). The requirement SA(t) = s makes sure that the label of the correct substitution transition is used, that is, the substitution transition that has page s as its subpage.

Fig. 15 shows the GTS HCP net that results from the application of the described translation technique to the global IS diagram of the GTS process. All sets of direct child interactions are translated into subpages (from now on: interaction pages). The lowest-level “behavioral” subpages that contain the combined agent behaviors have not been included because of space limitations.

Fig. 15. The HCPN-form of the global IS diagram of the GTS process.


5.2. TALL2HCPN: From the TALL CBP model to a HCP net

This research uses CPN Toolsl as an execution engine to enable formal verification of the produced HCP net. The proposed translation technique has been implemented in a tool named TALL2HCPN. This translation tool is started from the Tools menu in the interaction editor. The user interface of TALL2HCPN is shown in Fig. 9. The tool takes its input from the currently active database. The user can select a specific IS diagram to be translated, and start the translation. During execution, TALL2HCPN queries the database to extract the elements of the selected diagram and automatically creates an XML-file that can be directly loaded in CPN Tools. The XML file created by the translation tool contains the HCP net (its pages and page structure), the port assignment that links the pages, and the net elements for each page (including basic layout and proper positioning). Since CPN Tools requires all places to be typed and all arcs to carry an arc expression that evaluates to the type of the adjacent place, TALL2HCPN assigns the empty color set E to all places and the variable e to all arcs in the produced HCP net. Tokens of type E are considered uncolored or black tokens that carry no data.61 Fig. 16 shows the (partial) output of TALL2HCPN in CPN Tools for the TCBP model shown in Fig. 8 and Fig. 9.

Fig. 16. Screenshot of CPN Tools in which the GTS HCP net produced by TALL2HCPN is loaded.

l CPN Tools can be downloaded from http://wiki.daimi.au.dk/cpntools/_home.wiki


6. The Verification Activity

This section is concerned with the execution of the verification activity. Section 6.1 is concerned with the identification of design errors in the agent behaviors. Next, Section 6.2 explains how errors are rolled back to the TCBP model.

6.1. Verification analysis

CPN Tools is equipped with verification techniques. The state space analysis feature of CPN Tools is used to verify the soundness of the combined agent behaviors in the HCP net (i.e. the behavioral pages) produced by TALL2HCPN.

The state space report that results from the application of the state space tool to the GTS HCP net identified several design errors in the agent behaviors, that is, some of the behavioral pages are unsound. This implies that the agent behaviors on such a page are structurally incompatible. The method to check the three soundness requirements by using the state space report is demonstrated for the Reduction of Contracted Capacity#2 behavioral page. The method is inspired by the soundness analysis procedure using CPN Tools described in Ref. 62. To test the first soundness requirement Option to complete, the list of dead markings is checked. The state space report with the relevant results for the specific page shows that there are three dead markings with node numbers 46, 406, and 479 (see Fig. 17). These node numbers correspond to nodes in the generated state space graph. The corresponding marking in the HCP net can be shown, in CPN Tools, by expanding the node descriptor for a node.

Fig. 17. State space report for the GTS HCP net focused on the Reduction of Contracted Capacity#2 behavioral page (excerpt).


A CBP instance completes when a token appears on the output socket place on the root page in the produced HCP net (this is the end state). In this case, all the underlying (interaction and behavioral) pages have successfully completed. Inspection of the node descriptor for node 46 revealed a token to be present on the end place p2 on the root page and on place p11 on the page Provision of Transport Services#1 (these two places have identical markings because of the port assignment). This dead marking is expected since it corresponds to the end state of the CBP instance. However, the node descriptors for nodes 406 and 479 revealed non-empty (read: dead) markings on the behavioral page Reduction of Contracted Capacity#2. Clearly, these tokens are not in the end state of the CBP instance.

The State Space to Sim tool in CPN Tools is used to transfer the nodes that contain dead markings to the net simulator. Here, the design errors can be identified and the problem area(s) pinpointed as part of a certain agent behavior. Transfer of nodes 406 and 479 to the simulator and analysis of the net structure revealed several flaws on the page Reduction of Contracted Capacity#2: (a) The first error is related to the scenario in which the capacity planner disapproves the

request for reduction. In this case, the capacity planner simply ends the interaction without sending any message to the other agents. However, the behaviors of the other agents were activated by transition t1. Thus, these agents wait endlessly for messages that are never received;

(b) The second error is related to the scenario in which the capacity planner approves the request for reduction. When the customer receives the final contract and letter, it can either accept and sign both documents, or decide to reject them. The latter decision cancels the request for reduction. In this case, the behavior of the customer needs to end by placing a token in its end place. In the current net structure, there is no separate path that properly ends the customer’s behavior;

(c) The third error occurs because the secretary agent does not have a separate path to handle the rejection, which means its behavior is not ended properly. Therefore, the secretary’s behavior deadlocks in the case of a rejection since it also waits for the signed acceptance letter and contract that never arrives.

Correction of these errors is required to complete the Reduction of Contracted Capacity interaction. After correction (see Section 6.2), the state space graph can be generated again to (re-)check for soundness. If the state space report contains only the dead marking that corresponds to the end state of the CBP instance then the first soundness requirement is satisfied for the produced HCP net. In general, when a token is encountered in a dead marking and the token is not in the end state of the HCP net, then the CBP model is unsound and the non-empty (dead) markings should be inspected. The second soundness requirement Proper completion is tested with the help of the root page in the produced HCP net. The output socket place on the root page acts like a termination place that enforces Proper completion. It will only contain a token if all the underlying pages successfully complete. If this place contains no token when the CBP instance indicates completion, this means tokens reside in a state other than the end state, which is detected by the test for the first soundness requirement. The third soundness requirement No dead


transitions is satisfied when there are no dead transition instances in the state space report (see Fig. 17).

The net elements of the interaction pages of a produced HCP contain the same fixed (and sound) elements produced by the translation functions. The point is that it is sufficient to perform soundness checking on the behavioral pages. If all the behavioral pages are sound (and safe) then all their superpages (i.e. interaction pages) are also sound (and safe). This statement is based on the following theorem in Ref. 63: “If we have two sound and safe workflow nets V and W and we have a task t in V which has precisely one input and one output place, then we may replace task t in V by W and then the resulting workflow net is sound and safe again”. In the produced HCP net, all the substitution transitions contain precisely one input and output place. Therefore, each substitution transition can be replaced by the net on its subpage without invalidating soundness.

6.2. Verification reporting and correction

CPN Tools is used to identify any design errors. For the moment, the correction of errors (i.e. agent behavior re-design) is manual. The modeler identifies the soundness related errors in CPN tools and, due to the ownership relation that is kept during translationm, he/she can identify those behaviors that contain the errors. The modeler then has two choices in terms of how the correction of the agent behaviors (i.e. the AB diagrams) is done.

The first option is to correct the error(s) in CPN Tools, calculate the state space graph again, check if the errors have been resolved, adjust the initial AB diagram(s) in the TALL graphical editor that led to the error(s), and send it back to the source agent. The second option is to pinpoint, after verification, the problem area, identify the agent(s) that is(are) responsible for one or more errors, and communicate it to the respective agents using the analysis report produced by CPN tools as a feedback mechanism. These agents then have to send back a new version of their AB diagrams, and the modeler can then check if the new models lead to a sound overall HCP net by running the translation again. This is a typical distributed problem-solving situation. A middle solution is to send back to the agents a potential solution for correction (in the form of a structurally correct behavior) in order to help them find better behaviors. The first reporting scheme takes away from the autonomy of the agents, but it is fast and effective. The second can be slow due to repetition of trial-and-error cycles of local redesign and central verification, but the agents have the autonomy to change their behaviors as they see fit.

The flaws on the page Reduction of Contracted Capacity#2 have been identified and corrected using the first option. The corrected behaviors in CPN Tools have been used to correct the AB diagrams of the involved agents. In this specific case, the verification activity led to changes in the net structure of the customer, secretary, and capacity planner agents. After correction, the agent behaviors that perform the Reduction of

m The individual agent behaviors are marked in the behavioral pages by an agent-role label that appears above the behaviors.


Contracted Capacity interaction are structurally compatible. The errors in the agent behaviors described in Section 6.1 demonstrate the importance of design-time verification. For example, in the case when the agent playing the role of back office employee does not inform the other agents, the other agents have no way of knowing that the request for reduction was disapproved. In the real-life distributed business settings that operate CBPs such deadlock situations occur easily since each agent uses its own local behavior to execute its part in the process autonomously. The next section reflects on the proposed verification method.

7. Reflection

This section reflects on the verification method in Section 7.1 and the TALL language in Section 7.2.

7.1. Reflection on the verification method

One of the disadvantages of using the state space method for verification is that it is not possible to obtain a full state space for very large and complex nets.57 In the proposed verification method, the number of tokens on the places in the HCP net is bounded to one because each CBP instance is independently controlled. Thus, the HCP net is safe. Model checking is decidable for bounded models.64 Moreover, the separation between interaction and behavior models allows the formal verification to be restricted to the most important aspects of the TCBP model, that is, the agent behaviors that perform the elementary interactions.

The proposed verification method is effective only if there is an existing IS diagram and all the roles of the elementary interactions that appear in the diagram are assigned an agent that brings an explicit local behavior in the form of an AB diagram. This means that the agents who will execute the CBP have to be known before verification. The identification of agents is part of the modeling method as presented in Section 3.4.

It is assumed that different instances of a CBP are executed differently. The degree of differentiation is given by the instance’s context, the particular group of agents that will execute the instance, and finally, the behaviors that are exhibited by these agents. A global IS diagram may in certain cases be mappable to a majority of CBP instances. In this case, the behaviors of the agents will not change drastically between different instances. Such an IS diagram and the associated agent behaviors can be verified before an agent-based execution environment is implemented. For these CBP instance scenarios, the verification can be used as a tool by a business modeler, whose role is either to design new interaction-centric business processes, either to identify and correct flaws in existing processes. The goal of this kind of design-time verification is to ensure as early as possible (i.e. before system development starts) the existence of a successful scenario for the interactions that form a CBP. In this way, the agents are able to solve a certain family of process instances. Overall, the verification method presented in this paper gives modelers or designers a handle to construct sound (i.e. compatible) agent behaviors.


Related research9,65-66 presents transformations from existing modeling languages (e.g. (A)UML, EPCs, BPMN) to Petri nets in order to exploit their strong analytical methods and computer tools. The reader is referred to Refs. 8 and 9 for a detailed discussion of several such transformations. Ref. 8 mentions that in most approaches to verify a collaborative business process, a translation to a modeling language that supports formal analysis is used. In an agent-based system or model, the main difficulty is to decide what to verify and to what extent. The translation presented in this paper is different from other transformations in that it includes the multiple local views or behaviors of the agents involved in a CBP. Just computing global behavior without mechanisms for tracing back potential difficulties to individual (local) business processes is not sufficient in practice.8 The proposed verification method is focused on the structural compatibility of the agent behaviors that perform the interactions. This focus allows the combined behaviors of the agents involved in a certain interaction to be verified without loosing the ability to trace back design errors to the local agent behaviors.

The business domain under consideration can adopt a collaborative IT platform based on agent technology that serves as an execution environment for CBP operation. With TALL, this execution environment is to be driven by the IS diagram that facilitates controlled inter- and intra-organizational interactions by coordinating the distributed agent behaviors. Ongoing research is concerned with the use of business process gaming to identify new software agents and their behaviors. For this purpose, a series of tools form an integrated process gaming environment called AGE (the Agent Growing Environment67). The TALL models drive the simulation, development, and deployment of agents in AGE where gaming sessions (i.e. interactive simulations of the business process) are played with human experts or stakeholders from the business domain under consideration. Software agents are developed during the gaming sessions where the human agents act as “instructors”. The behavior of the software agents is enriched (i.e. grown) with the logged behavior of the humans. Implementation of the proposed verification method as a “verification service” is the subject of further research in AGE. In this way, the behavior of the software agents can be checked for structural compatibility for different business scenarios. Successful scenarios can be discovered for one or more interactions, that is, the verification service cannot only be invoked for full CBP instances but also partial IS diagrams or individual interactions can be verified. In AGE, the verification method becomes more of an implementation service than a design-time service.

Currently, the verification reporting and correction is a manual step. One of the main requirements to make the gaming sessions effective in enacting a successful scenario using the collaboration of the human instructors is to automate the identification of the agents that invalidate soundness, and to automate the manual procedures of rollback to the TALL models.


7.2. Reflection on the TALL language

A single superior general-purpose language is not advocated with TALL. Existing agent-oriented languages and development paradigms can be used to describe different aspects of an agent-based system in more detail or to finally build the software agents. Examples are the use of rule-based engines, agent development platforms and associated programming languages, agent communication architectures etc. The TALL-based set of descriptions should be considered as complementary to these, not as alternatives. Even if the application of TALL is not followed by the implementation of an agent-based system, the agent-oriented modeling exercise can facilitate a better understanding of the business domain and help to describe the complexities or intricacies of collaboration. Empirical evaluation of TALL is part of ongoing research.

The ability the check the soundness of the TCBP model is considered a desirable feature. To enable verification, the language builds on the strong formalism and analysis capabilities of (H)CP nets. This paper demonstrates how the language and verification method helps to build sound process models for an envisioned MAS that supports CBPs. Thus, the formalization of agent behaviors in process models enables computerized verification, after applying the translation technique, before diving into (agent) system design and implementation. The verified agent behaviors can be used as sound standard specifications that can be subject to further design, simulation, and/or implementation. Related to this, current research is directed towards the implementation of the “grown” software agents in a MAS. The discovered successful scenarios (in terms of interaction and behavior models) can be used as a first draft for the development of a MAS that supports the CBP.

The internal processing component of the software agents in terms of process structure and execution code can be based on the AB diagrams that have already been verified. The use of explicit process models for the agents should not invalidate completely the autonomy of the agents. The majority of CBP instances will require on the fly modification of behaviors because of the dynamic nature of the business context and its participants. Associated research49 explains how agents are implemented with alignment policies that enable the agents to dynamically modify their behavior without invalidating (local) soundness. These alignment policies can be used both on the fly and at design-time. Behavioral updates or even new behaviors can be introduced by modification of existing sound behavior specifications. Changes to agent behaviors do not have ripple effects on the IS diagram because of the clear separation between interactions and behaviors in TALL.

The use of the Behavior net formalism for the internal processing component of the software agents does not restrict the applicability of the TALL models to AGE. Several agent platforms require the communication architecture of the MAS to be based on accepted standards (i.e. FIPA ACL), in order to ensure interoperability, but allow freedom in the formalism used for the individual processing component (i.e. the application-dependent behavior) of the agents. The agent platform JADE for instance


imposes standards only for the external behavior of the system components but leaves open the implementation details and the internal architectures.68

A line of research related to the IS diagram is concerned with the alignment of interaction-based process views. From a single modeler’s perspective, the IS diagram is a global view of a CBP. However, in a multi-modeler or multi-organizational setting, an IS diagram is a situated view of the same CBP and multiple local IS diagrams owned by different agents can coexist. To tackle this multiplicity of local IS diagrams in an automatic manner, an algorithm has been developed that can automatically construct a global IS diagram from a set of local IS diagrams. The algorithm can deal with different compositions of (overlapping) local IS diagrams. An explanation and illustration of its use is presented in Ref. 69. It is important to note that by using the algorithm, it is possible to build a new global IS diagram for each CBP instance. Thus, the algorithm allows to build agreement in the form of a global IS diagram that can coordinate the agents, which operate the CBP. Agents influence the construction of a global IS diagram (and its contents) by sharing their local IS diagrams that are input to the algorithm. Change of a local IS diagram means running the algorithm again. The structural modification of the global IS tree, using the algorithm, without the need to stop or re-start, during real-time execution of the process is part of future research (see Section 9.2). Using the algorithm and the alignment policies respectively, both the IS diagrams and AB diagrams have the potential to be modified during real-time process execution. This builds flexibility into the TALL process models.

In a distributed business setting that provides an inter-organizational CBP, one of the issues is in which degree each party (with its own legal and business boundaries) is willing to share the inner details of their business processes with their partners. In TALL, a separation between public and private process views can be made on the same lines as the separation between the interaction and behaviour specification.69 Effectively, this means that agents have the option to share only their local IS diagrams after which a global IS diagram is built using the algorithm. In this scenario, the distributed agent behaviors (i.e. the AB diagrams) remain private knowledge and are coordinated by the global IS diagram. The verification method can still be used by each organization to check the structural compatibility of intra-organizational interactions and behaviors that are part of the overall CBP. As for inter-organizational interactions, the agents can share minimal representations of their private agent behaviors. Such a minimal representation would only include the behavorial touch points (i.e. the messages send and received), their sequence, and possibly some coarse-grained activities. Such a disclosure allows the structural compatibility of the agent behaviors to be checked using the verification method. However, this level of disclosure does not reveal the exact activities in the private agent behaviors. Related work that is concerned with public and private views is discussed in Ref. 69.


8. Related Work

This section discusses related work. Section 8.1 evaluates TALL against several agent-based modeling languages for system design. After, Section 8.2 discusses several agent-based workflow approaches and approaches that apply several types of Petri nets for representation of agent’s interactions and/or behaviors. An explicit comparison with several traditional business process modeling languages can be found in Ref. 33n.

8.1. Agent-based languages for system design

The most well known AOSE methodologies have been mentioned in the introduction. Modeling languages are core components of each of these methodologies and many of them incorporate the same basic constructs as TALL (i.e. agent, role, behavior, and interaction). The most closely related modeling languages in terms of purpose or modeling constructs are the TROPOS language23 and MESSAGE25-26. In addition, other agent-based languages include AUML27-28, AORML29, and AML30-32. All these agent-based languages are UML-driven languages that include interaction models (usually interaction protocols that specify the structured message exchange between agents and some constraints on the content of messages) and activity models that specify the private plans or actions/tasks of an agent.

The agent interaction protocol70 (AIP) allows hierarchical ordering using the UML package notation. This implies that an AIP can contain other AIPs, which allows for nesting. This nesting has similarities with TALL since a structure of nested protocols can be seen as a tree. Within an AIP, a sequence diagram describes the inter-agent transactions that are needed to implement the protocol, in terms of sequencing and eventual message branching. The lifeline of a receiving agent of a multiple branched message has to follow the same logical expression. This is done (probably) to avoid deadlocks, but it is very rigid. When nested, the lower level of detail can use activity diagrams, state diagrams, sequence diagrams, or collaboration diagrams. This makes the tree very diverse in terms of representations. This notation is clearly semi-formal and cannot be used for design-time verification. The AIP is a software-engineering concept and its high degree of variety can confuse a business modeler and its stakeholders. Another similarity to TALL is that at the lowest level of detail, an activity diagram can represent the behavior of an agent. The AIPs, which include the message exchange between agents, are fixed at design time, and the behaviors are selected at runtime. In TALL, the specification of the message exchange structure is done, from a local perspective, in the AB diagrams. A fixed pattern of message exchange is not imposed on the interaction level. In addition, the IS diagrams are local knowledge which are used to construct a global model only when necessary by applying the algorithm. This feature is

n Many business process modeling languages exist. It is almost impossible to make an explicit comparison with all of them. However, the strengths of TALL that have been discussed in Section 3.1 can be considered an implicit comparison. Naturally, other modeling languages may also share some of these strengths and may have strengths not found in TALL.


not offered for AIPs or sequence diagrams. The IS diagram relates interactions through both dependency (one interaction must be completed before the other can start) and composition (one interaction being part of another). The UML sequence diagram does not reveal how an interaction is related to other interactions as part of a business process. Consequently, the IS diagram provides a better base for process analysis, coordination, or improvement.

A step forward in MESSAGE is the decoupling between generic interactions and the way they are performed and structured, and the explicit guidelines provided to support the modeling exercise. However, the interaction view does not present a global process-oriented view. In addition, MESSAGE provides no explicit support for process verification. Ref. 71 describes an enhanced version of the OPM modeling framework called OPM/MAS that is specifically suited for agent systems. Although a good alternative for the UML-driven languages, OPM/MAS is a system modeling framework that addresses a number of essential software engineering issues (like accessibility and expressiveness aspects) and is useful primarily for system architects and developers. Ref. 72 presents the PIM4Agents metamodel for agent systems that abstracts from the specific requirements of existing AOSE methodologies, programming languages, and platforms. PIM4Agents is focused on the specification of software services and interfaces required by certain agent platforms. Thus, it deals with system and implementation details instead of business process concepts. All of the languages and frameworks discussed in this section focus on software development activities for agent systems. They provide a set of behavioral, functional, and structural views on the architectural design of the system and its components (i.e. agents). From the start, the goal is to derive system functionalities instead of describing business processes.

8.2. Agent-driven workflow and the use of Petri nets

JBees14,73 is an agent-based WfM system that uses CP nets as its process definition formalism. JBees implements a distributed network of autonomous agents each responsible for certain work associated with the running workflow process. A top-level CP net is separated in subnets, which are managed and executed by different agents. ADEPT15,74 provides an infrastructure for the (conceptual) design and implementation of agent-based BPM systems. The different components of a business process are each represented by an autonomous agent. Automated negotiation is used for coordination and management of agent dependencies. Both in JBees and ADEPT, agents must adhere to a pre-defined negotiation protocol, which suffers from the same limitations as the AIPs discussed in Section 8.1. Moreover, there is no explicit support for design-time process verification.

Brahms75 is a modeling and simulation environment for analyzing and supporting human work practice in organizations with intelligent software agents. The core of the Brahms model is the activity model that is dependent on internal reasoning, interaction with other agents, and interaction with the environment. WADE76 is a software platform (built on top of JADE) that facilitates the development of distributed agent applications.


WADE agents are embedded with lightweight workflow engines to execute tasks defined as workflows. Both Brahms and WADE are implementation frameworks that lack graphical representations to which business modelers can relate. These frameworks are of no use for business analysts or architects that want to design or analyze CBPs before software development starts.

Ref. 77 presents a goal-oriented approach towards business processes that consists of a process modeling language, named GO-BPMN, and a BPM system, named LS/ABPM. The approach is targeted, like TALL, at processes not following a strict predefined execution sequence. A strength of GO-BPMN is the clear orientation towards business people. In GO-BPMN, a clean separation is made between goals and the plans that achieve them. At first, processes are described as goal hierarchies. Every leaf goal is then linked to one or more plans that achieve the goal by execution of functional tasks. Likewise, the elementary (or leaf) interactions in the IS diagram are performed by two or more agent behaviors. The GO-BPMN models are directly executable in the run-time environment of the LS/ABPM suite. This allows the user to test the model. However, an option to verify either the goal hierarchy or the plans is not offered which is especially important for CBPs as argued in Section 4.2. Testing shows the presence of errors but not their absence.64 TALL introduces the IS diagram, which allows the interactions between participants to be made explicit in a process context (in terms of structure, order, and participants). GO-BPMN does not provide an interaction diagram and does not provide the option to construct process models using the local process knowledge of the agents. The main difference is that a goal describes motivation (internal behavior) whereas an interaction describes a (collective) activity (external behavior)o. Finally, the agent-orientation of the entire approach resides mainly in the architecture of the system (and not in the modeling language) in which each process instance is interpreted and run by a software agent.

Several researchers13,16-17,52,78-87 present or argue in favor of agent-oriented workflow approaches or systems. A (compact) overview is provided by Ref. 88. In essence, most of these approaches focus on the use of agents as part of the architecture and/or infrastructure associated with the WfM system, or focus on internal agent (implementation) details. Some of these works13,78-79 allow for a (graphical) representation of agent behaviors using Petri nets. The advantage of these approaches is their use of Petri nets, which enables validation and verification. However, their graphical representations are limited to the specification of agent behaviors using traditional process models of which the limitations have been discussed in Section 3.1. In these languages, it is not possible to capture local process views or to model inter-agent interactions separately from the agent behaviors. Moreover, these approaches present no useful (agent-centric) modeling guidelines.

Other related research is concerned with the application of different types of Petri nets to the agent domain. This research includes:

o The representation of goals in TALL is part of future research (see Section 9.2).


• the use of CP nets and CPN Tools to model and/or analyze agent interaction protocols, and agent negotiation processes;89-91

• the use of (H)CP nets (and other Petri net variants) to study and analyze MAS plans;92-93

• the use of CP nets to study agent social systems or social aspects;94-95 • the use of CP nets (and other Petri net variants) to specify and analyze (1) agent

behaviors and interactions or (2) the structure of distributed software systems.96-102 These Petri net-based approaches are not process-oriented since the focus is not on business processes modeling and analysis. Their emphasis is on system interaction and behavior, and (agent) implementation details.

9. Conclusions and Outlook

9.1. Conclusions

This research arguments that the development of agent systems for the support of collaborative business processes (CBPs) via software agents should start with a proper (agent-oriented) understanding of the work practice of the agents in the business domain under consideration. On the one hand, existing agent development approaches are software engineering approaches that focus on (agent) implementation details and not on business process specification. Hence, they are not easy applicable outside a system implementation context. On the other hand, existing business process modeling languages do not provide notations that suit the characteristics of the agent and CBP domains.

The first part of this paper presents a visual and formal agent-based modeling language for CBPs named TALL. The main modeling constructs of the language are agents, roles, behaviors, and interactions. The language starts from a business (process) point of view. TALL imposes a clear separation between the CBP’s interaction structure and the local agent behaviors that perform the interactions. The former is depicted in the Interaction Structure (IS) diagram and allows for hierarchical descriptions of role-based interactions and their ordering relations in a tree layout. The IS diagram scopes the interaction context in which the agents behave. Moreover, it can be used to enforce process-wide behavior separately from the autonomous behaviors of the agents when enacted by a MAS. The agent behaviors are captured in Agent Behavior (AB) diagrams, which are process diagrams that capture the local views or behaviors of the agents. The novelty of the language is that it is in line with a process-oriented approach (in which business processes are explicitly described) but at the same time agent-based. A software toolset has been developed to create IS and AB diagrams. Throughout the paper, a CBP studied in the context of a case study at a Dutch gas transport company is used to exemplify the modeling approach.

Explicit process models can be verified using formal methods. This is the subject of the second part of the paper in which a verification method to verify the structural compatibility/correctness of the combined agent behaviors for the CBP’s interactions is presented. The autonomous behaviors of the agents and their situated nature may give


rise to structural incompatibilities that can prevent proper completion of a CBP instance. Thus, verification, before system development or process enactment starts (i.e. design-time verification), is considered necessary since it can ensure the existence of a successful scenario. Design-time verification enhances the reliability of the CBP model and the (future) MAS.

The proposed verification method uses a translation to a Hierarchical Colored Petri (HCP) net, which enables the application of existing analytical methods and computer tools. Process design errors are identified in the agent behaviors, using the CPN Tools package, and then rolled back to the TALL models. This results in a sound set of compatible agent behaviors that can be used for further design, simulation, and/or implementation. An implemented software tool converts the TALL models into the HCP net format specific to CPN Tools. The verification method is applied to some of the agent behaviors from the case study and the results are discussed.

9.2. Future research

There are limitations to the modeling language as it currently stands. Further work remains to be done to apply and test TALL both in theory and in practice. Feasibility of the language is to be demonstrated by an evaluation of TALL against a generic set of (interaction) patterns.50,103

TALL is not a general-purpose modeling language but is to be used in conjunction with other languages and (agent-oriented) development frameworks. In this regard, TALL can be the starting point for many possible research directions and applications. For instance, TALL can be directly mapped to the concepts used in agent development platforms like JADE or JACK. This enables model-driven agent development similar to the approach described in Ref. 72. Ongoing work is directed towards the integration of TALL, the verification method, business gaming, and software agent development in the context of AGE. Particular attention is to be given to the rollback of design errors in an automated way and the implementation of the verification method as a service that can be invoked both at design and implementation time.

In the near future, several other research directions are to be explored. First, currently the IS diagram includes composition and dependency relationships between the interactions. Several other dependencies are to be investigated, in particular, resource and data dependencies. Related to resource dependencies, the nature of roles and agent groups is to be investigated in more detail as a way to make sure that the role-playing agents are authorized and skilled to do so. This requires a more elaborated mechanism for authorizations and an explicit representation of (role) responsibilities. Second, an explicit representation of goals is missing in the language. There is a strong conceptual link between business processes, interactions, agents, and goals. Future work intends to explore the nature and applicability of this link. Third, the TALL modeling method is to be extended with more advanced procedures that assist the modeler in the identification of agents, roles, and interactions. Fourth, future research is dedicated to enable agents to initiate dynamic interactions at run-time (i.e. interactions not part of the global IS


diagram). This can improve the flexibility and applicability of the approach in highly dynamic contexts. In this regard, future research will investigate the role of the algorithm as a runtime service that allows for on the fly structural modification of the IS diagram. Finally, a mathematical evaluation of the translation in terms of formally specified properties like termination, correctness, complexity etc. is planned for the future.

References

1. S. A. White, Introduction to BPMN, BPTrends White Papers & Technical Briefs (2004), http://www.bptrends.com/publicationfiles/07-04%20WP%20Intro%20to%20BPMN%20-%20White.pdf.

2. M. Dumas and A. H. M. ter Hofstede, UML activity diagrams as a workflow specification language, in «UML» 2001 — The Unified Modeling Language. Modeling Languages, Concepts, and Tools, eds. M. Gogolla and C. Kobryn (Springer, Berlin, 2001) 76-90.

3. W. Scheer, O. Thomas and O. Adam, Process modeling using event-driven process chains, in Process-Aware Information Systems: Bridging People and Software through Process Technology, eds. M. Dumas, W. M. P. van der Aalst and A. H. M. ter Hofstede (John Wiley & Sons, Hoboken, New Jersey, 2005) 119-145.

4. R. J. Mayer, M. K. Painter and P. S. deWitte, IDEF family of methods for concurrent engineering and business reengineering applications, Technical Report (Knowledge Based Systems, Inc., 1992), http://www.idef.com/pdf/IDEFFAMI.pdf.

5. J. Desel, Process modeling using petri nets, in Process-Aware Information Systems: Bridging People and Software through Process Technology, eds. M. Dumas, W. M. P. van der Aalst and A. H. M. ter Hofstede (John Wiley & Sons, Hoboken, New Jersey, 2005) 147-177.

6. M. Pesic and W. M. P. van der Aalst, A declarative approach for flexible business processes management, in Business Process Management Workshops, eds. J. Eder and S. Dustdar (Springer, Berlin, 2006) 169-180.

7. N. Melao and M. Pidd, A conceptual framework for understanding business processes and business process modeling, Information Systems J. 10(2) (2000) 105-129.

8. M. De Backer, M. Snoeck, G. Monsieur, W. Lemahieu and G. Dedene, A scenario-based verification technique to assess the compatibility of collaborative business processes, Data & Knowledge Engineering 68(6) (2009) 531-551.

9. K. Ryu and E. Yücesan, CPM: A collaborative process modelling for cooperative manufacturers, Advanced Engineering Informatics 21(2) (2007) 231-239.

10. B. J. Hommes, The evaluation of business process modeling techniques, PhD Thesis (Delft University of Technology, 2004), http://repository.tudelft.nl/file/82937/044821.

11. K. Harrison-Broninski, Human interactions: The heart and soul of business process management (Meghan-Kiffer Press, Tampa, Florida, USA, 2005).

12. W. Binder, I. Constantinescu, B. Faltings, K. Haller and C. Türker, A multiagent system for the reliable execution of automatically composed ad-hoc processes, Autonomous Agents and Multi-Agent Systems 12(2) (2006) 219-237.

13. P. A. Buhler and J. M. Vidal, Towards adaptive workflow enactment using multi-agent systems, Information Technology and Management 6(1) (2005) 61-87.

14. L. Ehrler, M. Fleurke, M. Purvis and B. T. R. Savarimuthu, Agent-based workflow management systems (WfMSs): JBees – a distributed and adaptive WfMS with monitoring and controlling capabilities, J. of Information Systems and E-Business Management 4(1) (2006) 5-23.

15. N. R. Jennings, P. Faratin, T. J. Norman, P. O’Brien and B. Odgers, Autonomous agents for business process management, Int. J. of Applied AI 14(2) (2000) 145-189.

Towards agent-based modeling and verification of collaborative business processes 47 16. Y. Verginadis and G. Mentzas, Agents and workflow engines for inter-organizational

workflows in e-government cases, Business Process Management J. 14(2) (2008) 188-203. 17. Y. Yan, Z. Maamar and W. Shen, Integration of workflow and agent technology for business

process management, in Proc. of The Sixth Int. Conf. on Computer Supported Cooperative Work in Design (IEEE Computer Society Press, Los Alamitos, 2001) 420-426.

18. I. Partsakoulakis and G. Vouros, Agent-enhanced collaborative activity in organized settings, Int. J. of Cooperative Information Systems 15(1) (2006) 119-154.

19. K. Taveter and G. Wagner, A multi-perspective methodology for modelling inter-enterprise business processes, in Conceptual Modeling for New Information Systems Technologies, eds. H. Arisawa and Y. Kambayashi (Springer, Berlin, 2002) 403-416.

20. S. A. DeLoach, M. F. Wood and C. H. Sparkman, Multiagent systems engineering, The Int. J. of Software Engineering and Knowledge Engineering 11(3) (2001) 231-258.

21. C. Cheong and M. Winikoff, Improving flexibility and robustness in agent interactions: Extending Prometheus with Hermes, in Software Engineering for Multi-Agent Systems IV, eds. A. Garcia, R. Choren, C. Lucena, P. Giorgini, T. Holvoet and A. Romanovsky (Springer, Berlin, 2006) 189-206.

22. L. Padgham and M. Winikoff, Prometheus: A methodology for developing intelligent agents, in Agent-Oriented Software Engineering III, eds. F. Giunchiglia, J. Odell and G. Weiss (Springer, Berlin, 2003) 174-185.

23. P. Bresciani, A. Perini, P. Giorgini, F. Giunchiglia and L. Mylopoulos, Tropos: An agent-oriented software development methodology, Autonomous Agents and Multi-Agent Systems 8(3) (2004) 203-236.

24. M. J. Wooldridge, N. R. Jennings and D. Kinny, The GAIA Methodology for agent-oriented analysis and design, Autonomous Agents and Multi-Agent Systems 3(3) (2000) 285-312.

25. G. Caire, W. Coulier, F. Garijo, J. Gomez, G. J. Pavon, F. Leal, P. Chainho, P. Kearney, J. Stark, R. Evans and P. Massonet, Agent oriented analysis using Message/UML, in Agent-Oriented Software Engineering II, eds. M. J. Wooldridge, G. Weiss and P. Ciancarini (Springer, Berlin, 2002) 119-135.

26. G. Caire, F. Leal, P. Chainho, R. Evans, F. G. Jorge, G. J. Pavon, P. Kearney, J. Stark and P. Massonet, MESSAGE: Methodology for agent-oriented software engineering, Technical Report (EURESCOM, 2001), http://www.eurescom.de/~pub-deliverables/P900-series/P907/TI1/p907ti1.pdf.

27. B. Bauer, J. P. Müller and J. Odell, Agent UML: A formalism for specifying multiagent software systems, The Int. J. of Software Engineering and Knowledge Engineering 11(3) (2001) 207-230.

28. J. Odell, H. Van Dyke Parunak and B. Bauer, Extending UML for agents, in Proc. of the Agent-Oriented Information Systems Workshop at the 17th National Conf. on Artificial Intelligence (AAAI Press, Austin, Texas, 2000) 3-17.

29. G. Wagner, The agent-object-relationship metamodel: Towards a unified view of state and behavior, Information Systems 28(5) (2003) 475-504.

30. R. Cervenka, I. Trenanský and M. Calisti, Modeling social aspects of multi-agent systems: The AML approach, in Agent-Oriented Software Engineering VI, eds. J. P. Müller and F. Zambonelli (Springer, Berlin, 2006) 28-39.

31. R. Cervenka, I. Trenanský, M. Calisti and D. Greenwood, AML: Agent modeling language toward industry-grade agent-based modeling, in Agent-Oriented Software Engineering V, eds. J. Odell, P. Giorgini and J. P. Müller (Springer, Berlin, 2005) 31-46.

32. I. Trencansky and R. Cervenka, Agent Modeling Language (AML): A comprehensive approach to modeling MAS, Informatica 29(4) (2005) 391-400.


33. M. Stuit and N. B. Szirbik, Modelling and executing complex and dynamic business processes

by reification of agent interactions, in Engineering Societies in the Agents World VII, eds. G. O’Hare, A. Ricci, M. O’Grady and O. Dikenelli (Springer, Berlin, 2007) 106-125.

34. M. T. Wynn, H. M. W. Verbeek, W. M. P. van der Aalst, A. H. M. ter Hofstede and D. Edmond, Business Process Verification – Finally a Reality!, Business Process Management J. 15(1) (2009) 74-92.

35. H. S. Nwana, L. Lee and N. R. Jennings, Co-ordination in software agent systems, British Telecom Technology J. 14(4) (1996) 79-88.

36. L. M. Camarinha-Matos and H. Afsarmanesh, Collaborative networks: A new scientific discipline, J. of Intelligent Manufacturing 16(4/5) (2005) 439-452.

37. M. Stuit, N. B. Szirbik and C. de Snoo, Interaction beliefs: A way to understand emergent organizational behaviour, in Proc. of the Ninth Int. Conf. on Enterprise Information Systems (INSTICC, Funchal, Madeira, Portugal, 2007) 241-248.

38. Workflow Management Coalition, Workflow Management Coalition: Terminology & Glossary, Technical Report (WfMC, 1999), http://www.wfmc.org/standards/docs/TC-1011_term_glossary_v3.pdf.

39. M. R, Genesereth and S. P. Ketchpel, Software agents, Communications of the ACM 37(7) (1994) 48-53.

40. K. M. Carley, Computational organization science: A new frontier, Proc. of the National Academy of Sciences 99(3) (2002) 7257-7262.

41. G. Genilloud and A. Wegmann, A foundation for the concept of role in object modeling, in Proc. of the Fourth Int. Conf. on Enterprise Distributed Object Computing Conf. (IEEE Computer Society, Los Alamitos, 2000) 76-85.

42. F. Zambonelli, N. R. Jennings and M. J. Wooldridge, Organizational abstractions for the analysis and design of multi-agent systems, in Agent-Oriented Software Engineering, eds. P. Ciancarini and M. J. Wooldridge (Springer, Berlin, 2001) 407-422.

43. J. Ferber and O. Gutknecht, A meta-model for the analysis and design of organizations in multi-agent systems, in Proc. of the 3rd Int. Conf. on Multi Agent Systems (IEEE Computer Society Press, Los Alamitos, 1998) 128-135.

44. J. Odell, H. Van Dyke Parunak and M. Fleischer, Modeling agent organizations using roles, Software and Systems Modeling 2(2) (2003) 76-81.

45. F. Steimann, Role = interface: A merger of concepts, J. of Object-Oriented Programming 14(4) (2001) 23-32.

46. F. Steimann, A radical revision of UML’s role concept, in «UML» 2000 — The Unified Modeling Language, eds. A. Evans, S. Kent and B. Selic (Springer, Berlin, 2000) 194-209.

47. F. Steimann, On the representation of roles in object-oriented and conceptual modeling, Data & Knowledge Engineering 35(1) (2000) 83-106.

48. M. Stuit, N. B. Szirbik and J. C. Wortmann, Building agent-based simulations using structural and process mental models, in Proc. of the Ninth Int. Symposium on Symbolic and Numeric Algorithms for Scientific Computing (IEEE Computer Society, Los Alamitos, CA, USA, 2007) 267-274.

49. G. G. Meyer and N. B. Szirbik, Anticipatory alignment mechanisms for behavioral learning in multi agent systems, in Anticipatory Behavior in Adaptive Learning Systems, eds. M. V. Butz, O. Sigaud, G. Pezzulo and G. Baldassarre (Springer, Berlin, 2007) 325-344.

50. W. M. P. van der Aalst, A. H. M. ter Hofstede, B. Kiepuszewski and A. P. Barros, Workflow patterns, Distributed and Parallel Databases 14(1) (2003) 5-51.

51. R. Eshuis and P. Grefen, Constructing customized process views, Data & Knowledge Engineering 64(2) (2008) 419-438.

52. M. Adams, A. H. M. ter Hofstede, D. Edmond and W. M. P. van der Aalst, Worklets: A service-oriented implementation of dynamic flexibility in workflows, in On the Move to


Meaningful Internet Systems 2006: CoopIS, DOA, GADA, and ODBASE, eds. R. Meersman and Z. Tari (Springer, Berlin, 2006) 291-308.

53. Business Rules Group, Defining business rules - What are they really?, Technical Report (Business Rules Group, 1995), http://www.businessrulesgroup.org/first_paper/BRG-whatisBR_3ed.pdf.

54. A. Ricci, A. Omicini and E. Denti, Virtual enterprises and workflow management as agent coordination issues, Int. J. of Cooperative Information Systems 11(3/4) (2002) 355-379.

55. G. G. Meyer and N. B. Szirbik, Agent behavior alignment: A mechanism to overcome problems in agent interactions during runtime, in Cooperative Information Agents XI, eds. M. Klusch, K. Hindriks, M. P. Papazoglou and L. Sterling (Springer, Berlin, 2007) 270-284.

56. S. Bussmann, N. R. Jennings and M. J. Wooldridge, On the identification of agents in the design of production control systems, in Agent-Oriented Software Engineering, eds. P. Ciancarini and M. J. Wooldridge (Springer, Berlin, 2001) 423-441.

57. K. Jensen, L. M. Kristensen and L. Wells, Coloured Petri nets and CPN Tools for modelling and validation of concurrent systems, Int. J. on Software Tools for Technology Transfer 9(3) (2007) 213-254.

58. W. M. P. van der Aalst, Workflow verification: Finding control-flow errors using Petri-net-based techniques, in Business Process Management, eds. W. M. P. van der Aalst, J. Desel and A. Oberweis (Springer, Berlin, 2000) 161-183.

59. W. M. P. van der Aalst, Verification of workflow nets, in Application and Theory of Petri Nets 1997, eds. P. Azema and G. Balbo (Springer, Berlin, 1997) 407-426.

60. K. Jensen, Hierarchical coloured Petri nets, in Coloured Petri nets: basic concepts, analysis methods and practical use vol. 1 (Springer, Berlin, 1997) 89-119.

61. K. Jensen, An introduction to the theoretical aspects of coloured Petri nets, in A Decade of Concurrency Reflections and Perspectives, eds. J. W. de Bakker, W. P. de Roever and G. Rozenberg (Springer, Berlin, 1994) 230-272.

62. F. Gottschalk, W. M. P. van der Aalst, M. H. Jansen-Vullers and H. M. W. Verbeek, Protos2CPN: Using colored Petri nets for configuring and testing business processes, in Proc. of the Seventh Workshop on the Practical Use of Coloured Petri Nets and CPN Tools (University of Aarhus, Aarhus, 2006) 137-156.

63. W. M. P. van der Aalst and K. Van Hee, Workflow management: Models, methods and systems (The MIT Press, Cambridge MA/London England, 2002).

64. R. Eshuis, Semantics and verification of UML activity diagrams for workflow modeling, PhD Thesis (University of Twente, 2002), http://www.ctit.utwente.nl/library/phd/eshuis.pdf.

65. L. Cabac and D. Moldt, Formal semantics for AUML agent interaction protocol diagrams, in Agent-Oriented Software Engineering V, eds. J. Odell, P. Giorgini and J. P. Müller (Springer, Berlin, 2005) 47-61.

66. R. M. Dijkman, M. Dumas and C. Ouyang, Semantics and analysis of business processes in BPMN, Information and Software Technology 50(12) (2008) 1281-1294.

67. G. B. Roest and N. B. Szirbik, Escape and intervention in multi-agent systems, AI & Society 24(1) (2009) 25-34.

68. F. Bellifemine, G. Caire, A. Poggi and G. Rimassa, JADE: A white paper, EXP Magazine, Telecom Italia 3(3) (2003) 6-19, http://jade.tilab.com/papers/2003/WhitePaperJADEEXP.pdf.

69. M. Stuit and G. G. Meyer, Agent interaction modeling based on product-centric data: A formal method to improve enterprise interoperability, in Agent-Based Technologies and Applications for Enterprise Interoperability, eds. K. Fischer, J. P. Müller, J. Odell and A. J. Berre (Springer, Berlin, 2009) 197-219.

70. J. Odell, H. Van Dyke Parunak and B. Bauer, Representing agent interaction protocols in UML, in Agent-Oriented Software Engineering, eds. P. Ciancarini and M. J. Wooldridge (Springer, Berlin, 2001) 201-218.


71. A. Sturm, D. Dori and O. Shehory, Single-model method for specifying multi-agent systems, in

Proc. of the second int. joint conference on Autonomous agents and multiagent systems (ACM, New York, 2003) 121-128.

72. C. Hahn, C. Madrigal-Mora and K. A. Fischer, A platform-independent metamodel for multiagent systems, Autonomous Agents and Multi-Agent Systems 18(2) (2008) 239-266.

73. B. T. R. Savarithmu, M. Purvis and M. Purvis, Different perspectives on modeling workflows in an agent based workflow management system, in Knowledge-Based Intelligent Information and Engineering Systems, eds. R. Khosla, R. J. Howlett and L. C. Jain (Springer, Berlin, 2005) 208-214.

74. N. R. Jennings, P. Faratin, T. J. Norman, P. O’Brien, B. Odgers and J. L. Olty, Implementing a business process management system using ADEPT: A real-world case study, Int. J. of Applied AI 14(5) (2000) 421-465.

75. M. Sierhuis, W. J. Clancey and R. J. J. van Hoof, Brahms: A multiagent modelling environment for simulating work processes and practices, Int. J. of Simulation and Process Modelling 3(3) (2007) 134-152.

76. Workflow and Agents Development Environment, WADE User Guide (Telecom Italia, 2008), http://jade.tilab.com/wade/doc/WADE-User-Guide.pdf.

77. M. Calisti and D. Greenwood, Goal-oriented autonomic process modelling and execution for next generation networks, in Modelling Autonomic Communications Environments, eds. S. van der Meer, M. Burgess and S. Denazis (Springer, Berlin, 2008) 38-49.

78. G. Joeris, Decentralized and flexible workflow enactment based on task coordination agents, in Proc. of the 2nd Int. Bi-Conference Workshop on Agent-Oriented Information Systems (iCue Publishing, Berlin, 2000) 41-62.

79. K. Palacz and D. C. Marinescu, An agent-based workflow management system, in Proc. of the AAAI Spring Symposium 2000 (AAAI Press, Menlo Park, California, 2000) 119-126.

80. W. M. P. van der Aalst, P. Barthelmess, C. A. Ellis and J. Wainer, Proclets: A framework for lightweight interacting workflow processes, Int. J. of Cooperative Information Systems 10(4) (2001) 443-482.

81. J. W. Chang and C. T. Scott, Agent-based workflow: TRP support environment (TSE), Computer Networks and ISDN Systems 28(7) 1996 1501-1511.

82. X. Chen and P. Chung, Cross-organisational workflow enactment via progressive linking by run-time agents, in Advances in Applied Artificial Intelligence, eds. M. Ali and R. Dapoigny (Springer, Berlin, 2006) 54-59.

83. I. Hawryszkiewycz and J. Debenham, A workflow system based on agents, in Proc. of the 9th Int. Conf. on Database and Expert Systems Applications (Springer, Berlin, 1998) 135-144.

84. C. J. Huang, A. J. C. Trappey and Y. H. Yao, Developing an agent-based workflow management system for collaborative product design, Industrial Management & Data Systems 106(5) (2006) 680-699.

85. M. P. Singh and M. H. Huhns, Multiagent systems for workflow, Int. J. of Intelligent Systems in Accounting, Finance and Management 8 (1999) 105-117.

86. H. Tarumi, K. Kida, Y. Ishiguro, K. Yoshifu and T. Asakura, WorkWeb system – Multi-Workflow management with a multi-agent system, in Proc. of the int. ACM SIGGROUP conf. on Supporting group work: the integration challenge (ACM, New York, 1997) 299-308.

87. M. Wang and H. Wang, Intelligent agent supported business process management, in Proc. of the 38th Annual Hawaii Int. Conf. on System Sciences (IEEE Computer Society Press, Los Alamitos, 2005) 71b-71b.

88. R. Thimm and T. Will, AMIRA – A state of the art analysis of workflow modelling and agent-based information systems, Technical Report (University of Trier, 2004), http://www.wi2.uni-trier.de/publications/2004_TechnicalReport_thimmWill.pdf.

Towards agent-based modeling and verification of collaborative business processes 51 89. E. Bacarin, W. M. P. van der Aalst, E. Madeira and C. B. Medeiros, Towards modelling and

simulating a multi-party negotiation protocol with coloured Petri nets, in Proc. of the 8th Workshop and Tutorial on Practical Use of Coloured Petri Nets and the CPN Tools (University of Aarhus, Aarhus, 2007) 29-48.

90. J. Billington and K. G. Gupta, Effectiveness of coloured Petri nets for modelling and analysing the contract net protocol, in Proc. of the 8th Workshop and Tutorial on Practical Use of Coloured Petri Nets and the CPN Tools (University of Aarhus, Aarhus, 2007) 49-65.

91. C. Hanachi and C. Sibertin-Blanc, Protocol moderators as active middle-agents in multi-agent systems, Autonomous Agents and Multi-Agent Systems 8(2) (2004) 131-164.

92. H. Oliveira de Almeida, L. Dias da Silva, A. Perkusich and E. de Barris Costa, A formal approach for the modelling and verification of multiagent plans based on model checking and Petri nets, in Software Engineering for Multi-Agent Systems III, eds. R. Choren, A. Garcia, C. Lucena and A. Romanovsky (Springer, Berlin, 2005) 162-179.

93. D. Xu, R. Volz, T. Loerger and J. Yen, Modeling and verifying multi-agent behaviors using predicate/transition nets, in Proc. of the 14th int. conf. on Software engineering and knowledge engineering (ACM, New York, 2002) 193-200.

94. M. V. Costa Miranda and A. Perkusich, Modeling and analysis of a multi-agent system using colored Petri nets. in Proc. of the Workshop on Applications of Petri Nets to Intelligent System Development (Williamsburg, Virginia, USA) 59-70.

95. D. Weyns and T. Holvoet, A colored Petri net for a multi-agent application, in Proc. of the Second Workshop on Modelling of Objects, Components and Agents (Aarhus, Denmark, 2002) 121-141.

96. F. Camargo-Santacruz, J. F. Frausto-Solís and F. Ramos-Quintana, Modeling multiple interactions using colored Petri nets: A case study, in Advanced Distributed Systems, eds. F. F. Ramos, V. Lrios Rosillo and H. Unger (Springer, Berlin, 2005) 182-193.

97. G. Decker and M. Weske, Local enforceability in interaction Petri nets, in Business Process Management, eds. G. Alonso, P. Dadam and M. Rosemann (Springer, Berlin, 2007) 305-319.

98. M. Köhler, D. Moldt and H. Rölke, Modelling the structure and behaviour of Petri net agents, in Applications and Theory of Petri Nets 2001, eds. J. M. Colom and M. Koutny (Springer, Berlin, 2001) 224-241.

99. J. Lian and S. M. Schatz, A modeling methodology for conflict control in multi-agent systems, Int. J. of Software Engineering and Knowledge Engineering 18(3) (2008) 263-303.

100. F. Lin and D. H. Norrie, Schema-based conversation modeling for agent-oriented manufacturing systems, Computers in Industry 46(3) (2001) 259-274.

101. T. Miyamoto, M. Sakamoto and S. Kumagai, On reachability analysis of multi agent nets, IEICE Transactions on Fundamentals of Electronics, Communications and Computer Sciences E90-A(10) (2007) 2257-2260.

102. D. Moldt and F. Wienberg, Multi-agent systems based on coloured Petri nets, in Application and Theory of Petri Nets 1997, eds. P. Azema and G. Balbo (Springer, Berlin, 1997) 82-101.

103. A. P. Barros, M. Dumas and A. H. M. ter Hofstede, Service interaction patterns: Towards a reference framework for service-based business process interconnection, Technical Report (Queensland University of Technology, 2005), http://www.workflowpatterns.com/documentation/documents/ServiceInteractionPatterns.pdf.

Date post:	28-Aug-2020
Category:	Documents
Upload:	others
View:	2 times
Download:	0 times

TOWARDS AGENT-BASED MODELING AND VERIFICATION OF...

Documents