1 Scope
· Specifications for structuring the FIPA Interaction Protocol Library (IPL) including a status of a FIPA Interaction Protocols (IPs), maintenance of the library and inclusion criteria for new IPs.
· A description of how to understand and express IPs using AUML (Agent Unified Modeling Language).
· The FIPA IP registry list.
This specification is primarily concerned with defining the structure of the FIPA IPL and the requirements for an IP to be included in the library.
2 Overview
This specification focuses on the organization, structure and status of the FIPA IPL and discusses the main requirements that an IP must satisfy in order to be FIPA-compliant. The objectives of standardising and defining a library of FIPA compliant IPs are:
· To provide tested patterns of agent interaction that may be of use in various aspects of agent-based systems,
· To facilitate the reuse of standard agent IPs, and,
· To express IPs in a standard agent unified modelling language (AUML).
In the following, we present the basic principles of the FIPA IPL which help to guarantee that the IPL is stable, that there are public rules for the inclusion and maintenance of the IPL, and that developers seeking a public IPs can use the IPL.
2.1 Interaction Protocols
Ongoing conversations between agents often fall into typical patterns. In such cases, certain message sequences are expected, and, at any point in the conversation, other messages are expected to follow. These typical patterns of message exchange are called interaction protocols. A designer of agent systems has the choice to make the agents sufficiently aware of the meanings of the messages and the goals, beliefs and other mental attitudes the agent possesses, and that the agent’s planning process causes such IPs to arise spontaneously from the agents’ choices. This, however, places a heavy burden of capability and complexity on the agent implementation, though it is not an uncommon choice in the agent community at large. An alternative, and very pragmatic, view is to pre-specify the IPs, so that a simpler agent implementation can nevertheless engage in meaningful conversation with other agents, simply by carefully following the known IP.
This section of the specification details a number of such IPs, in order to facilitate the effective inter-operation of simple and complex agents. No claim is made that this is an exhaustive list of useful IPs, nor that they are necessary for any given application. The IPs are given pre-defined names and the requirement for adhering to the specification is:
A FIPA ACL-compliant agent need not implement any of the standard IPs, nor is it restricted from using other IP names. However, if one of the standard IP names is used, the agent must behave consistently with the IP specification given here.
These IPs are not intended to cover every desirable interaction type. Individual IPs do not address a number of common real-world issues in agent interaction, such as exception handling, messages arriving out of sequence, dropped messages, timeouts, cancellation, etc. Rather, the IPs defined in this specification set should be viewed as interaction patterns, to be elaborated according to the context of the individual application. This strategy means that adhering to the stated IPs does not necessarily ensure interoperability; further agreement between agents about the issues above is required to ensure interoperability in all cases.
Note that, by their nature, agents can engage in multiple dialogues, perhaps with different agents, simultaneously. The term conversation is used to denote any particular instance of such a dialogue. Thus, the agent may be concurrently engaged in multiple conversations, with different agents, within different IPs. The remarks in this section, which refer to the receipt of messages under the control of a given IP, refer only to a particular conversation.
2.2 Status of a FIPA-Compliant Interaction Protocol
The definition of an IP belonging to the FIPA IPL is normative, that is, if a given agent advertises that it employs an IP in the FIPA Content Language Library (see [FIPA00007]), then it must implement the IP as it is defined in the FIPA IPL. However, FIPA-compliant agents are not required to implement any of the FIPA IPL IPs themselves, except those required for Agent Management (see [FIPA00023]).
By collecting IP definitions in a single, publicly accessible registry, the FIPA IPL facilitates the use of standardized IPs by agents developed in different contexts. It also provides a greater incentive to developers to make their IPs generally applicable.
FIPA is responsible for maintaining a consistent list of IP names and for making them publicly available. In addition to the list of encoding schemes, each IP in the FIPA IPL may specify additional information, such as stability information, versioning, contact information, different support levels, etc.
2.3 FIPA Interaction Protocol Library Maintenance
The most effective way of maintaining the FIPA IPL is through the use of the IPs themselves by different agent developers. This is the most direct way of discovering possible bugs, errors, inconsistencies, weaknesses, possible improvements, as well as capabilities, strengths, efficiency, etc.
In order to collect feedback on the IPs in the library and to promote further research, FIPA encourages coordination among designers, agent developers and FIPA members.
2.4 Inclusion Criteria
To populate the FIPA IPL, setting fundamental guidelines for the selection of specific IPs is necessary. The minimal criteria that must be satisfied for an IP to be FIPA compliant are:
· A clear and accurate representation of the IP is provided using AUML protocol diagram,
· Substantial and clear documentation must be provided, and,
· The usefulness of a new IP should be made clear.
FIPA does not enforce the use of any particular IP.
3 AUML Sequence Diagrams for Interaction Protocol Specification
3.1 Introduction
During the 1970s, structured programming was the dominant approach to software development. Along with it, software engineering technologies were developed in order to ease and formalize the system development lifecycle: from planning, through analysis and design and finally to system construction, transition, and maintenance. In the 1980s, object-oriented languages experienced a rise in popularity, bringing with it new concepts such as data encapsulation, inheritance, messaging, and polymorphism. By the end of the 1980s and beginning of the 1990s, a jungle of modelling approaches grew to support the object-oriented marketplace. To make sense of and unify these various approaches, an Analysis and Design Task Force was established on 29 June 1995 within the Object Management Group (OMG). And by November 1997, a de jure standard was adopted by the OMG members called the Unified Modelling Language (UML - see [OMGuml]).
UML unifies and formalizes the methods of many object-oriented approaches, including analysis and design [Booch94 and Booch95], modelling [Rumbaugh91] and software engineering [Jacobson94]. It supports the following kinds of models:
· Static models
Such as class and package diagrams describe the static semantics of data and messages. Within system development, class diagrams are used in two different ways, for two different purposes. First, they can model a problem domain conceptually and since they are conceptual in nature, they can be presented to the customers. Second, class diagrams can model the implementation of classes which guides developers. At a general level, the term class refers to the encapsulated unit and at the conceptual level, models types and their associations; the implementation level models implementation classes. While both can be more generally thought of as classes, their usage as concepts and implementation notions is important both in purpose and semantics. Package diagrams group classes in conceptual packages for presentation and consideration. (Physical aggregations of classes are called components that are in the implementation model family, mentioned below.)
· Dynamic models
These include interaction diagrams (that is, sequence and collaboration diagrams), state charts and activity diagrams.
· Use cases
The specification of actions that a system or class can perform by interacting with outside actors. They are commonly used to describe how a customer communicates with a software product.
· Implementation models
These describe the component distribution on different platforms, such as component models and deployment diagrams
· Object Constraint Language (OCL)
This is a simple formal language to express more semantics within an UML specification. It can be used to define constraints on the model, invariant, pre- and post-conditions of operations and navigation paths within an object net.
For modelling agents and agent-based systems, UML is insufficient. Compared to objects, agents are active because they act for reasons that emerge from themselves. The activity of agents is based on their internal states, which include goals and conditions that guide the execution of defined tasks. While objects need control from outside to execute their methods, agents know the conditions and intended effects of their actions and hence take responsibility for their needs. Furthermore, agents do not only act solely but together with other agents. Multi-agent systems can often resemble a social community of interdependent members that act individually.
However, no sufficient specification formalism exists yet for agent-based system development. To employ agent-based programming, a specification technique must support the whole software engineering process—from planning, through analysis and design, and finally to system construction, transition, and maintenance.
A proposal for a full life-cycle specification of agent-based system development is beyond the scope of this specification. Here, we suggest a subset of an agent-based extension to the standard UML, called AUML, for the specification of agent interaction protocols (AIPs).
It has to be distinguished between generic (or parameterised) protocols (and their instantiations) and domain-specific protocols.
3.2 Extending UML by Protocol Diagrams
In the following, we provide sequence diagrams for AUML [Odell2000], an extension to UML. We refer to these sequence diagrams as protocol diagrams (PDs) which show well-defined interactions among agents. Note that we do not define formal semantics for the communicative acts for AUML, but instead use the UML meta-model.
3.2.1 Protocol Diagrams
Adapted from [OMGuml], section 3.59.
3.2.1.1 Semantics
A PD represents an interaction, which is a set of messages exchanged among different agent roles within a collaboration to effect a desired behaviour of other AgentRoles or agent instances.
3.2.1.2 Notation
A PD has two dimensions: the vertical dimension represents time, the horizontal dimension represents different AgentRoles. Normally the time proceeds down the page and usually only time sequences are important, but in real-time applications the time axis could be an actual metric. There is no significance to the horizontal ordering of the AgentRoles.
3.2.1.3 Presentation Options
The axes can be interchanged, so that time proceeds horizontally to the right and different AgentRoles are shown as horizontal lines.
Various labels (such as timing marks, generated goals depending on the received message, etc.) can be shown either in the margin or near the lifelines or messages that they label.
3.2.1.4 Example
3.2.1.5 Mapping
The mapping is analogous defined as for sequence diagrams (see [OMGuml]).
A PD maps like a sequence diagram into an Interaction and an underlying Collaboration. An Interaction specifies a sequence of communications; it contains a collection of partially ordered Messages, each specifying a communication between a sender role and a receiver role. Collections of agent roles that conform to the ClassifierRoles in the Collaboration owning the Interaction, communicate by dispatching Stimuli that conform to the Messages in the Interaction. An AgentRole maps into a ClassifierRole. A PD presents one collection of AgentRoles and arrows mapping to AgentRole and Stimuli that conform to the ClassifierRoles and Messages in the Interaction and its Collaboration.
In a PD, each AgentRole box with its lifeline maps into an agent role that conforms to a ClassifierRole in the Collaboration. The name fields maps into the name of the agent, the role name into the Classifier's name and the class field maps into the names of the Classifier (in this case AgentClasses being Classes) being the base Classifiers of the ClassifierRole. The splitting of lifelines has a concurrency Association defining either AND/OR parallelism or decision Association denoting threads (<<thread>>). The associations among roles are not shown on the sequence diagram since they must be obtained in the model from a complementary collaboration diagram or other means. A message arrow maps into a Stimulus connected to two AgentRoles. the sender and receiver AgentRole. The Stimulus conforms to a Message between the ClassifierRoles corresponding to the two AgentRoles' lifelines that the arrow connects. The Link is used for the communication of the Stimulus and plays the role specified by the AssociationRole connected to the Message. Unless the correct Link can be determined from a complementary collaboration diagram or other means, the Stimulus is either not attached to a Link (not a complete model), or it is attached to an arbitrary Link or to a dummy Link between the Instances conforming to the AssociationRole implied by the two ClassifierRoles due to the lack of complete information. The name of the communicative act is mapped onto the behaviour associated by the action performing, requested information, information passing, negotiation or error handling connected to the Message. Different alternatives exist for showing the arguments of the Stimulus. If references to the actual Instances being passed as arguments are shown, these are mapped onto the arguments of the Stimulus. If the argument expressions are shown instead, these are mapped onto the Arguments of the action performing, requested information, information passing, negotiation or error handling connected to the dispatching communicative act. Finally, if the types of the arguments are shown together with the name of the communicative act, these are mapped onto the parameter types of the communicative act. A timing label placed on the level of an arrow endpoint maps into the name of the corresponding Message. A constraint or guard placed on the diagrams maps into a Constraint on the entire Interaction. The cardinality label restricts the number of sending and receiving instances of agent roles accordingly to the numbers denoted at the beginning (sender) and end (receiver) of the message.
An arrow with the arrowhead pointing to an AgentRole symbol within the frame of the diagram maps into a Stimulus dispatched by a CreateAction, that is, the Stimulus conforms to a Message in the Interaction which is connected to the CreateAction. The interpretation is that the AgentRole instance (not an arbitrary agent role, nor a set of AgentRole instances) is created by dispatching the Stimulus, and the AgentRole instance conforms to the receiver role specified in the Message. After the creation of the AgentRole instance, it may immediately start interacting with other AgentRoles. This implies that the creation of the AgentRole dispatches these Stimuli. If an AgentRole instance termination symbol ("X") is the target of the of an arrow, the arrow maps into a Stimulus which will cause the receiving agent role instance to be removed. The Stimulus conforms to a Message in the Interaction with a DestroyAction attached to the Message or the agent instance terminates itself.
The order of the arrows in the diagram map onto a pair of associations between the Messages that correspond to the Stimuli the arrows maps onto. A predecessor association is established between Messages corresponding to successive arrow ends in the vertical sequence. In case of concurrent arrows preceding an arrow, the corresponding Message has a collection of predecessors. In case of exclusive-or and inclusive-or arrows preceding an arrow the corresponding message has one and at least one out of the collection of possible predecessors, respectively. Moreover, each Message has an activator (thread of interaction) association to the Message corresponding to the incoming arrow of the activation or pro-active sending of a message.
A nested protocol maps into a PD. The name compartment of a nested protocol maps into the name of the Collaboration. The guard and constraint compartment maps into a constraint on the complete Interaction.
A complex nested protocol maps into a PD. The order of the messages within the protocol is defined according to the combination of the complex nested protocol. The ordering of the messages in the nested protocol is the ordering of these protocols. Depending on the combination the messages are sent in AND/OR parallelism or decision ordering.
3.2.2 AgentRoles
In the framework of agent oriented programming an agent satisfying a distinguished role behaves in a special way. In contrast to this semantics role in UML is an instance focused term. Moreover the term multi-object does not fit to describe AgentRoles but it is used to show operations that address the entire set, rather than a single object in it. However, there is a communication with one instance of this multi-object. By AgentRole a set of agents satisfying distinguished properties, interfaces or having a distinguished behaviour are meant.
UML distinguishes between:
· multiple classifications where a retailer agent can act as well as a buyer as well as a seller agent, for example, and,
· dynamic classification where an agent can change its classification during its existence.
Agents can perform various roles within one IP. Using a contract-net protocol, for example, between a buyer and a seller of a product, the initiator of the protocol has the role of a buyer and the participant has the role of a seller. But the seller can as well be a retailer agent, which acts as a seller in one case and as a buyer in another case, i.e. agents satisfying a distinguished role can support multiple classification and dynamic classification. Another example can be found in [FIPA00023] which defines the functionality of the Directory Facilitator (DF) and the Agent Management System (AMS). These functionalities can be implemented by different agents, but the functionality of the DF and AMS can also be integrated into one agent.
An AgentRole can be seen as a set of agents satisfying a distinguished interface, service description or behaviour. Therefore the implementation of an agent can satisfy different roles.
Note that within FIPA the notion of role is not used, but in the framework of specifying agent-based systems this notion is appropriate.
3.2.2.1 Semantics
An AgentRole describes two different variations that can apply within a protocol definition. A protocol can be defined between different concrete agent instances or a set of agents satisfying a distinguished role and/or class. An agent satisfying a distinguished AgentRole and class is called agent of a given AgentRole and class, respectively.
3.2.2.2 Notation
An AgentRole is shown as a rectangle that is filled with some string of one of the following forms:
· role
This denotes arbitrary agents satisfying the distinguished AgentRole.
· instance / role-1 ... role-n
This denotes a distinguished agent instance that satisfies the AgentRoles 1-n where n³ 0.
· instance / role-1 ... role-n : class
This denotes a distinguished agent instance that satisfied the AgentRoles 1-n where n³ 0 and class it belongs to.
3.2.2.3 Presentation Options
The second case can be abbreviated as instance if n equals zero, that is, a concrete agent is meant independent of the role(s) it satisfies and class it belongs to.
3.2.2.4 Example
3.2.2.5 Mapping
See Section 3.2.1.5, Mapping.
3.2.3 Agent Lifeline
The agent lifeline defines the time period when an agent exists. For example a user agent is created when a user logs on to the system and the user agent is destroyed when the user logs off. Another example is when an agent migrates from one machine to another.
3.2.3.1 Semantics
A PD defines the pattern of communication, that is, the steps in which the communicative acts are sent between agents of different AgentRoles. The agent lifeline describes the time period in which an agent of a given AgentRole exists. Only during this time period an agent can participate on a protocol.
The lifeline starts when the agent of a given AgentRole is created and ends when it is destroyed. The lifeline can be split in order to describe AND/OR parallelism and decisions and may merge together at some subsequent point.
3.2.3.2 Notation
An agent lifeline is shown as a vertical dashed line. The lifeline represents the existence of an agent of a given AgentRole at a particular time. If the agent is created or destroyed during the period of time shown on the PD, then its lifeline starts or stops at the appropriate point; otherwise it goes from the top of the diagram to the bottom. An AgentRole is drawn at the head of the lifeline. If an agent of a given AgentRole is created during the PD, then the message that creates it is drawn with its arrowhead on the AgentRole. Note, that the AgentRole (see Section 3.2.3.4, Example) that receives the message is responsible for the creation of the agent instance, that is, the arrowhead ends at the dashed line of the AgentRole receiving the message and the AgentRole is fixed at the left-hand or right-hand side of the lifeline or the thread of interaction. If an agent instance is destroyed during the PD, then its destruction is marked by a large "X", either at the message that causes the destruction or (in the case of self destruction) at the final action of the AgentRole. The termination is restricted to concrete instances of an agent role.
AgentRoles that exist when a protocol starts is shown at the top of the diagram (above the first message arrow). An AgentRole that exists when the protocol finishes has its lifeline continued beyond the final arrow of the diagram.
The lifeline may split into two or more lifelines to show AND/OR parallelism and decisions. Each separate track corresponds to a branch in the message flow. The lifelines may merge together at some subsequent point. The splitting of the lifeline for:
· AND parallelism starts at a horizontal heavy bar,
· OR parallelism (inclusive-or) starts at a horizontal heavy bar with a non-filled diamond, and,
· decision (exclusive-or) starts at a horizontal heavy bar with a non-filled diamond with "x" inside the diamond and is continued with a set of parallel vertical lifelines connected to the heavy bar.
The merging is done the analogous way, that is, the parallel vertical lifelines stop at some of the horizontal heavy bars and one lifeline is continued from at the heavy bar.
3.2.3.3 Presentation Options
None.
3.2.3.4 Example
See also Section 3.2.1.4,
Example.
3.2.3.5 Mapping
See Section 3.2.1.5, Mapping.
3.2.4 Threads of Interaction
The sending of messages can be done either in parallel or as a decision between different communicative acts. Receiving different communicative acts usually results in different behaviour and different answers, that is, the behaviour of an AgentRole depends on the received message.
Adapted from [OMGuml], section 7.4.
3.2.4.1 Semantics
Since the behaviour of an AgentRole depends on the incoming message and different communicative acts are allowed as an answer to a communicative act, the thread of interaction, that is, the processing of incoming messages, has to be split up into different threads of interaction. The lifeline of an AgentRole is split and the thread of interaction defines the reaction to received messages.
The thread of interaction shows the period during which an AgentRole is performing some task as a reaction to an incoming message. It represents only the duration of the action in time, but not the control relationship between the sender of the message and the receiver. A thread of interaction is always associated with the lifeline of an AgentRole.
Note we do not mean a physical thread in this context. The specification is independent of the implementation using threads or other mechanisms.
3.2.4.2 Notation
A thread of interaction is shown as a tall thin rectangle whose top is aligned with its initiation time and whose bottom is aligned with its completion time. It is drawn over the lifeline of an AgentRole. The task being performed may be labelled as text next to the thread of interaction or in the left margin, depending on the style; alternately the incoming message may indicate the task, in which case it may be omitted on the thread of interaction itself.
If the distinction between the reaction to different incoming communicative acts can be neglected, the entire lifeline may be shown as one thread of interaction.
3.2.4.3 Presentation Options
· Variation
A thread of interaction may can take only a short period of time. To simplify diagrams, for compactification reasons of the diagram the parallelism and the decisions can be abbreviated by omitting the splitting/merging and putting the different threads of interaction one after another on the lifeline.
· Variation
A break of the rectangle describes a change in the thread of interaction.
3.2.4.4 Example
can be abbreviated as 
3.2.4.5 Mapping
See Section 3.2.1.5, Mapping.
3.2.5 Messages
The main issue of protocols is the definition of communicative patterns, especially the sending of messages from one AgentRole to another. This sending can be done in different ways, for example, with different cardinalities, depending on some constraints or using AND/OR parallelism and decisions.
Adapted from [OMGuml], section 7.5 and section 8.9.
3.2.5.1 Semantics
A message or sending of a communicative act is a communication from one AgentRole to another that conveys information with the expectation that the receiving AgentRole would react according to the semantics of the communicative act. The specification of the protocol says nothing about the implementation of the processing of the communicative act.
3.2.5.2 Notation
A message sending is shown as a horizontal solid arrow from a thread of interaction of an AgentRole to another thread of interaction of another AgentRole. In case of a message is sent from an AgentRole to itself (note that there might be many individual agents in an AgentRole), the arrow may start and end on the same lifeline or thread of interaction. Such a nested thread of interaction is denoted by a thread of interaction that is shifted a little bit to the right side in the actual thread of interaction.
Nested protocols are represented by a separate thread of interaction, along with an arrow initiating the nested protocol and one or more arrows terminating the nested protocol. The initiating arrow is drawn starting with a small solid filled circle, and a terminating arrow ends with a circle surrounding a small solid filled circle.
Each arrow is labelled with a message label that has the following syntax:
predecessor guard-condition sequence-expression communicative-act argument-list
Where:
· predecessor
This consists of at most one natural number followed by a slash (/) defining the sequencing of a parallel construct or the number of the input and output parameter in the context of Section 3.2.9, Threads of Interaction and Messages Inside and Outside Nested Protocols, xxxx. The clause is omitted if the list is empty.
· guard-condition
This is a usual UML guard condition, with the semantics, that the message is sent iff the guard is true. The guard conditions must be defined on the behavioural semantics of the agents, that is, the internal state of the agent must not be used in the definition of the guard.
· sequence-expression
This is a constraint, especially with n..m which denotes that the message is sent n up to m times with nÎ N, mÎ NÈ {*}[1]. The keyword broadcast denotes the broadcast sending of a message; the keyword deadline denotes a string that is encoded according to [ISO8601] and represents the deadline by which a message is useful.
· communicative-act
This is either the name, that is, a string representation with an underlined name, of a concrete communicative act instance, the name of a concrete communicative act instance and its associated communicative act, written as name:communicative-act or only the name of the communicative act, for example, inform.
· argument-list
This is a comma-separated list of arguments enclosed in parentheses. The parentheses can be omitted if the list is empty. Each argument is an expression in pseudo-code or an appropriate programming language or an OCL expression.
3.2.5.3 Presentation Options
· Variation: Cardinality
The cardinality of a message (for example, n senders and m receivers of a message) is shown by writing natural numbers at the beginning and at the end of the arrow. This variation is only allowed if the sender and/or receiver is not an instance of an agent.
· Variation: Asynchronous Message Passing
An asynchronous message is drawn with a stick arrowhead (
).
It shows the sending of the message without yielding control.
· Variation: Synchronous Message Passing
A synchronous message is drawn with a filled solid arrowhead (
).
It shows the yielding of the thread of control (wait semantics), that is, the
AgentRole waits until an answer message is received and nothing else can be
processed.
· Variation: Time intensive Message Passing
Normally message arrows are drawn horizontally. This indicates the
duration required to send the message is atomic, that is, it is brief compared
to the granularity of the interaction and that nothing else can take place
during the message transmission. That is the correct assumption within many
computers. If the messages requires some time to arrive for mobile
communication, for example, during which something else can occur then the
message arrow may be slanted downward so that the arrowhead is below the arrow
tail (
).
· Variation: Repetition
The repetition of parts of a PD is represented by an arrow or one of its variations usually marked by some guards or constraints ending at a thread of interaction which is according to the time axis before or after the actual time point. Note, that in this case the time ordering on the PDs is violated.
3.2.5.4 Example
3.2.5.5 Mapping
See Section 3.2.1.5, Mapping.
3.2.6 Complex Messages
Besides the already presented kinds of messages, more complex messages can be used.
3.2.6.1 Semantics
A complex message may be the parallel sending of messages or exclusively sending of exactly one message out of a set of different messages.
3.2.6.2 Notation
Three kinds of complex messages are distinguished. All three complex messages substitute an arrow from one thread of interaction to another thread of interaction by an arrow starting at one thread of interaction ending either:
· at a heavy bar (for AND parallelism),
· at a heavy bar with a non-filled diamond (for OR parallelism; inclusive-or), or,
· at a heavy bar with a non-filled diamond (for decisions; exclusive-or) with an "x" inside the diamond.
From these different kinds of heavy bars new arrows start in a right angle at the bar and end at possibly different threads of interaction, which are possibly combined in a parallel or decisional way.
The merging of different messages is done in the analogous way, that is, the parallel horizontal message arrows stop at one vertical bar and one message arrow is continued from the heavy bar.
3.2.6.3 Presentation Options
None.
3.2.6.4 Example
(a) (b)[2] (c)
3.2.6.5 Mapping
See Section 3.2.1.5, Mapping.
3.2.7 Nested Protocols
Nested protocols are applied to specify complex systems in a modular way. Moreover the reuse of parts of a specification increases the readability of them.
A nested protocol can be defined and applied, if it is used several times within the same specification. In contrast to a parameterised protocol it is only an abbreviation for a fixed (part of a) protocol. Additionally nested protocols are used for the definition of repetition of a nested protocol according to guards and constraints.
Interleaved protocols show that between different agents a protocol is performed and more over in order to finish/proceed the protocol an agent has to perform another protocol with other agents.
3.2.7.1 Semantics
If the nested protocol is marked with some guard then the semantics of the nested protocol is the semantics of the protocol under the assumption that the guard evaluates to true, otherwise the semantics is the semantics of an empty protocol, that is, nothing is specified.
If the nested protocol is marked with some constraints the nested protocol is repeated as long as the constraints evaluate to true.
3.2.7.2 Notation
A nested protocol is shown as a rectangle with rounded corners. It may have one or more compartments. The compartments are optional. They are as follows:
· Name compartment
This holds the (optional) name of the nested protocol as a string. Nested protocols without names are anonymous. It is undesirable to show the same named nested protocol twice in the same diagram except when they define the same nested protocol. The compartment is written in the upper left-hand corner of the rectangle.
· Guard compartment
This holds the (optional) guard of the nested protocol in the usual guard notation as [guard-condition]. Nested protocols without guards are equivalent with nested protocols with guard [true]. The guard compartment is written together with the constraint compartment in the lower left-hand corner of the rectangle.
· Constraint compartment
This holds the (optional) constraint of the nested protocol in the usual constraint notation as {constraint-condition}. Nested protocols without constraints are equivalent with nested protocols with constraint {1}. The constraint compartment is written together with the guard compartment in the lower left-hand corner of the rectangle. In addition to the constraint condition used in UML the constraint n..m denotes that the nested protocol is repeated n up to m times with nÎ N, mÎ N È {*}.
Another nested protocol can completely be drawn within the actual nested protocol denoting that the inner one is part of the outer one.
3.2.7.3 Presentation Options
The abbreviations n and * can be applied to denote n..n and 0..*, respectively. Beyond the above usage of nested protocols for simple protocols, nested protocols can also be used applying parameterised protocols or instantiated parameterised protocols.
Another presentation option is the definition of interleaved protocols. For a nested protocol being part of another protocol the rectangle representing it has to be completely drawn within the other one. If interleaved protocols are defined, that is, during performing one IP another IP has to be processed, the rectangles are not drawn within each other.
3.2.7.4 Example
Nested Protocol Interleaved Protocols
3.2.8 Complex Nested Protocols
Beyond the already presented nested and interleaved protocols, other kinds of complex nested protocols can also be defined.
3.2.8.1 Semantics
A complex nested protocol defines the parallel or decisional combination of nested protocols. It has to take into consideration the thread of interaction at the beginning and at the end of the complex nested protocol. Furthermore the starting and ending point within the nested protocols have to be considered.
3.2.8.2 Notation
Three kinds of complex nested protocols are distinguished. All three complex nested protocols are drawn over the lifeline and threads of interaction within a PD. Each individual nested protocol in a complex nested protocol is introduced by a line that is terminated by the rectangle of a nested protocol. These lines are connected either by:
· a heavy bar defining AND parallelism,
· a heavy bar with a non-filled diamond defining OR parallelism (inclusive-or), or,
· a heavy bar with a non-filled diamond defining decisions (exclusive-or) with an "x" inside the diamond.
The threads of interaction which are continued in the different nested protocols are drawn as usual.
3.2.8.3 Presentation Options
None.
3.2.8.4 Example
3.2.8.5 Mapping
See Section 3.2.1.5, Mapping.
3.2.9 Threads of Interaction and Messages Inside and Outside Nested Protocols
Usually, nested protocols have input and output parameters, namely threads of interaction and messages.
3.2.9.1 Semantics
Nested protocols are defined in detail either within a PD where it is used or outside another PD. Threads of interaction and messages inside and outside nested protocols define the input and output parameter for nested protocols.
The input parameters are the threads of interaction, which are carried on in the nested protocol, and the messages which are received from other IPs.
The output parameters are on the one side the threads of interaction which are started within the nested protocol and are carried on outside the nested protocol and the messages which are sent from inside the nested protocol to AgentRoles not involved in the actual nested protocol. A message or thread of interaction ending at an input or starting at an output parameter of a nested protocol describes the connection of a whole PD with the embedded nested protocol.
3.2.9.2 Notation
The input and output parameters for the threads of interaction of a nested protocol are shown as a tall thin rectangle (like a thread of interaction) which is drawn beyond the bounds of over the top line and bottom line of the nested protocol rectangle, respectively.
The input and output message parameters are shown by arrows starting with a small solid filled circle, and arrows ending at a circle surrounding a small solid filled circle (a bull's eye), respectively.
3.2.9.3 Presentation Options
The message arrows can be marked like usual messages. In this context, the predecessor denotes the number of the input/output parameter. The input/output thread of interaction can be marked with natural numbers to define the exact number of the parameter.
3.2.9.4 Example
3.2.9.5 Mapping
See Section 3.2.1.5, Mapping.
3.2.10 Parameterised Protocols
Adapted from [OMGuml], section 5.11.
3.2.10.1 Semantics
A parameterised protocol is the description for an IP with one or more unbound formal parameters. It therefore defines a family of protocols, each protocol specified by binding the parameters to actual values. Typically the parameters represent agent roles, constraints, instances of communicative acts and nested protocols. The parameters used within the parameterised protocol are defined in terms of the formal parameters so they are become bound when the parameterised protocol itself is bound to the actual values.
A parameterised protocol is not a directly-usable protocol because it has unbound parameters. Its parameters must be bound to actual values to create a bound form that is a protocol.
3.2.10.2 Notation
A small dashed rectangle is superimposed on the upper right-hand corner of the rectangle with rounded corners as when defining a nested protocol. The dashed rectangle contains a parameter list of formal parameters for the protocol. The list must not be empty, although it might be suppressed in the presentation. The name of the parameterised protocol is written as a string in the upper left-hand corner.
The parameter list is a comma-separated list of arguments (formal parameters) defined by identifiers, like names for AgentRoles, constraint expressions, communicative acts or nested protocol names.
3.2.10.3 Presentation Options
The input/output parameters like messages and threads of interactions can be used and defined as for nested protocols.
Communicative act can be marked with an asterisk in the parameter specification, denoting different kinds of messages that can alternatively be sent in this context.
3.2.10.4 Example
3.2.10.5 Mapping
See Section 3.2.1.5, Mapping.
3.2.10.6 Comment
Note the difference between interleaved, nested and parameterised protocols. An interleaved protocol is used to show that during the execution of one protocol another one is started/performed. Nested protocols are used to show repetitions of sub-protocols, identifying fixed sub-protocols, reference to a fixed sub-protocol, like asking the DF for some information, or guarding a sub-protocol. Parameterised protocols are used to prepare patterns which can be instantiated in different contexts and applications, for example, the FIPA Contract Net Protocol for appointment scheduling and negotiation about some good which should be sold.
3.2.11 Bound Elements
Adapted from [OMGuml], section 5.12.
3.2.11.1 Semantics
A parameterised PD cannot be used directly in an ordinary interaction description, because it has free parameters that are not meaningful outside of a scope that declares the parameter. To be used, a formal parameter of a parameterised protocol must be bound to actual values. The actual value for each parameter is an expression defined within the scope of use. If the referencing scope is itself a parameterised protocol, then the parameters of the referencing parameterised protocol can be used as actual values in binding the referenced parameterised protocol, but the parameter names in the two templates cannot be assumed to correspond, because they have no scope outside of their respective templates. We can assume without loss of generality that the parameter names of the different parameterised protocols are different.
3.2.11.2 Notation
A bound element is indicated in the name string of an element, as follows:
parameterised-protocol-name < role-list, constraint-expression-list, value-list >
Where:
· parameterised-protocol-name
This is identical to the name of the parameterised protocol.
· role-list
This is a comma-delimited list of role labels. constraint-expression-list is a comma-delimited list of constraint terms.
· value-list
This is a comma-delimited non-empty list of pairs, separated by a colon consisting of a value expression and a communicative act. The communicative act is optional.
The number and types of the values must match the number and types of the parameterised protocol formal parameters for the parameterised protocol of the given name. The bound element name may be used anywhere that protocol of the parameterised kind could be used.
3.2.11.3 Presentation Options
None.
3.2.11.4 Example
FIPA-ContractNet-Protocol
<
Buyer, Seller
20000807
cfp-seller : cfp,
refuse-1 : refuse,
refuse-2 : refuse, not-understood, propose, reject-proposal, accept-proposal,
cancel, inform, failure
>
3.2.11.5 Mapping
The use of the bound element syntax for the name of a symbol maps into a Binding dependency between the dependent ModelElement corresponding to the bound element symbol and the provider ModelElement whose name matches the name part of the bound element without the arguments. If the name does not match a parameterised protocol or if the number of arguments in the bound element does not match the number of formal parameters in the parameterised protocol, then the model is ill-formed. Each argument in the bound element maps into a ModelElement bearing a templateArgument association to the Namespace of the bound element. The Binding relationship bears the list of actual argument values.
4 References
[Booch94] Booch, G., Object-Oriented Analysis and Design with Applications. Benjamin/Cummings, 1994.
[Booch95] Booch, G., Object Solutions: Managing the Object-Oriented Project. Addison-Wesley, 1995.
[FIPA00007] FIPA Content Language Library Specification. Foundation for Intelligent Physical Agents, 2000. http://www.fipa.org/specs/fipa00007/
[FIPA00023] FIPA Agent Management Specification. Foundation for Intelligent Physical Agents, 2000. http://www.fipa.org/specs/fipa00023/
[ISO8601] Date Elements and Interchange Formats, Information Interchange – Representation of Dates and Times, ISO 8601:1988(E), 1988.
[Odell2000] Odell, J., Parunak, H. van Dyke and Bauer, B., Extending UML for Agents. In: AOIS Worshop at AAAI, 2000.
[OMGuml] OMG Unified Modelling Language Version
1.1, Object Management Group, 1999.
http://www.omg.org/uml/
[Rumbaugh91] Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F. and Lorenzen, W., Object-Oriented Modeling and Design. Prentice Hall, 1991.