Towards agent-based modeling and verification of ...

International Journal of Cooperative Information Systems  World Scientific Publishing Company

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 rolebased 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 welldefined (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 1

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 designtime 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.

4

M. Stuit & N.B. Szirbik

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 wellfunctioning 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 transportrelated 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

Towards agent-based modeling and verification of collaborative business processes

5

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

6

M. Stuit & N.B. Szirbik

(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 interagent 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. Processwide 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

Towards agent-based modeling and verification of collaborative business processes

7

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.

8

M. Stuit & N.B. Szirbik

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-

Towards agent-based modeling and verification of collaborative business processes

9

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.

10

M. Stuit & N.B. Szirbik

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.

Towards agent-based modeling and verification of collaborative business processes

11

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

12

M. Stuit & N.B. Szirbik

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

Towards agent-based modeling and verification of collaborative business processes

13

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

14

M. Stuit & N.B. Szirbik

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,