Synchronization Speci cations for Agents with Net-based Behaviour Description Tom Holvoet and Pierre Verbaeten Dept. of Computer Science K.U.Leuven, Belgium e-mail:
[email protected]
Abstract Cooperative and multi-agent systems are (mostly
open) systems consisting of multiple agents that coordinate in order to achieve a common goal. Petri
nets are a highly expressive and visual formalism for specifying concurrent systems. Combining agents and nets means pursuing the speci cation of agents by nets and the speci cation of their interrelationships, in order to bene t from the obvious advantages of nets: they are a visual formalism with a substantial theoretical background. In this paper, we provide a formalism for the speci cation of multi-model nets, i.e. nets in which the class of composed subnets may di er. The idea is to model each agent as a separate net, while the inter-net speci cations describe the cooperation structure of the corresponding agents. We argue that most kinds of nets (such basic Condition/Event nets, over Place/Transition nets to highlevel nets) have their situations in which they are preferred over others for modelling concurrent behaviour. This suggests the need for multi-model net speci cations.
1 Introduction / Motivation Future software systems such as Computer Supported Cooperative Work (CSCW), Groupware and World Wide Web related applications, can be characterized by the following set of adverbs: they are open , exible , highly concurrent and complex . Open systems are systems that are recomposable, i.e. systems in which several components may join and/or leave the system during its execution. Components in such systems cannot rely on a priori knowledge of the availability of services of other Research Assistant of the Belgian Fund for Scienti c Research
components. Flexibility means that new components (modules, object, and so on) can be added to the system at run time. Each component in such an application is modelled as an autonomous and concurrent entity, whose physical location can even change during execution. Components can be related in numerous ways, going from a type relationship, over a simple use relation towards complex authorization and synchronization protocol. In this paper, we focus on the latter, i.e. dynamic dependencies. Objects and agents appear to provide suitable abstractions for modelling and realizing such systems. Developing such systems should be mainly concerned with two goals: describing components and their interrelationships, i.e. describing what components need/demand/expect from other components, rather than describing how components communicate; in particular, one often needs to model and realize a lot of questions in the sense of \which component may do what when "; deducing system properties, such as dead locks, starvation and so on. The global idea that is followed in this paper is the following. System components are modelled by objects or agents (autonomous active objects), whose behaviour is modelled by a Petri net. Petri nets are a very good formalism for modelling concurrent systems: they are visual (which eases the readability of a model) and highly expressive in terms of concurrency, causality, synchronization and non-determinism. The rability of transitions of such an object/agent speci cation either depend on the rability of transitions of other objects/agents, or not, in which case the corresponding action is called an autonomous action, since
no external state or stimuli can cause this action to occur. The dynamic interdependencies between agents and objects (i.e. synchronization, protocols, and so on), are described through interdependencies of their corresponding Petri nets. In this paper, we provide a means to abstract from the how of agent communication, emphasizing the what of agent interdependencies. Therefore, we introduce sychronization speci cations , a formal instrument for describing net composition for any kind of Petri net, in terms of the corresponding object/agent's type and/or state . In Section 2, we present a small example, which should give a rst clue on our view on how systems should be modelled. Then, Section 3 introduces the notion of generic nets, which are used to abstract from any concrete kind of Petri net model. A recursive de nition of synchronization speci cations is provided in Section 4. To show the usefulness and feasibility of this new approach, a small application is presented in Section 5.
2 An Introductory Example In order to o er the reader an intuitive idea of what is proposed in this paper, let us present a small, very simple and well-known example: the producer/consumer problem. It may seem that this problem is a bad example for a paper on applications like CSCW and Groupware. However, it allows to present the basics of the approach. The problem is described as follows. There are two kinds of entities in the system. Producers, which autonomously and consecutively produce items, and consumers, which consecutively operate on produced items. We call these entities agents because of their autonomous and encapsulated behaviour. First, the behaviour of the agents is modelled in isolation, meaning that at this point, inter-agent cooperation is not taken into account. This results in the simple C/E-nets, presented in Figure 1. Next, the agent cooperation is tackled. Their cooperation can be described as: every agent of type Producer should synchronize with an instance of type Consumer for exchanging the item. So actually, we need to de ne the type of agents which need to cooperate (Producers and Consumers), and the state in which both should be in order to perform the cooperation (the transitions deliver and get should re at the same time).
Producer
produce
Consumer
deliver
get
consume
Figure 1: The behaviour speci cation of producers and consumers. Producer
produce
Consumer
deliver
get
consume
Figure 2: A simple synchronization speci cation. This can be described by a simple synchronization speci cation , see Figure 2. Graphically, the
synchronization speci cation is visualized by a double line, interconnecting two transitions. Semantically, this means that the activity of the respective agents is now bound to the state of the peer agent. In particular, it denotes that the deliver transition of a producer can re i there is a consumer which can re its get transition. A deliver transition and a get transition either re both concurrently, or neither of them res. At this point, one might be interested in analyzing properties of the overall system. In our example, consider a con guration consisting of one producer and one consumer. Using the synchronization speci cation for de ning the appropriate transition merging operation1 for the several nets yields a composite net of the overall system. The resulting net (Figure 3) can now be analysed for deadlock, liveness, state reachability and so on. What synchronization speci cations are intended to specify is not how agents perform their cooperation, but what agents expect, demand or need from other agents in order to proceed in achieving their own goal. As such, synchronization speci cations should not be viewed as a means to statically interconnect the nets of di erent agents of the system. But synchronization speci cations are rather a means to formally denote the interdependency of 1 For an overview of this and other techniques for modular net construction, the reader is referred to [1].
produce
consume deliver/get
Figure 3: One net modelling the overall system of a speci c con guration. agent activity in terms of their types and state.
3 Generic Nets A large variety of Petri nets exist. Each sort probably has certain characteristics (e.g. the grain size of the speci cation, the expressive comfort, the available formal analysis instruments, available tools, and so on) such that they may be preferred over others for particular situations. In this section, we introduce generic nets. A generic net is an abstract version of a Petri net. It results from extracting commonalities between several classes of nets. In the next section, synchronization speci cations are de ned on generic nets. Since all sort of nets are special cases of these generic nets, synchronization speci cations are implicitly de ned for de ning synchronization between any kind of nets. A generic net is a directed bipartite graph, consisting of two kinds of nodes (places and transitions) and a ow relation (arrows). For each net element (i.e. place, transition and arrow), there is an annotation function, allowing inscriptions of any kind. For generic nets, these functions remain unspeci ed. Finally, there are tokens. Tokens have a type, and they can reside in places. The behaviour of such nets is described by a generic enabling rule : if a transition is enabled (a boolean operation in function of the transition's annotation, its pre-set and post-set and their annotations), it can re. A transition that res extracts appropriate tokens from its input places and shift appropriate tokens towards its output-places. It should be easy to understand how each concrete class of nets can be described as a special kind of generic net, enhanced with appropriate de nitions of:
annotation functions token type speci cations structural restrictions behavioural restrictions. As an example, consider the class of weighted Place/Transition nets with in nite capacities. The annotation functions are instantiated by: a constant function yielding in nity for the places; a constant function yielding an empty string for the transition; a weight function for arrows. The type of tokens is a constant for all tokens in the net. The type is Anonymous. There are no additional structural restrictions (there would be in the case of pure and simple Condition/Event nets). Additional behavioural restrictions should deal with the ring rule: the arrow weight should be respected during transition ring.
4 Synchronization Speci cations 4.1 Basic De nition In the environment we envisage (components/ agents), we do not intend to have components share parts of nets for modelling interaction. In stead, the nets of the respective agents remain encapsulated parts of the agent descriptions, and composition operators specify their interrelationship. Composition of nets in this paper is considered only as a relation between transitions. Flexible and dynamic synchronization speci cations are achieved by providing advanced transition composition operators. These operators interconnect transitions, denoting synchronization between these transitions, and hence, when these transitions belong to nets of di erent agents, between agents. Here, we de ne synchronization speci cations for generic nets. The de nition can easily be extrapolated to denote synchronization speci cations for any kind of net. Let us rst introduce two notions: synchronized transitions and synchronized blocks. A synchronized transition is a transition (of a generic net) that is subjected to a synchronization speci cation, either in a one-to-x relation or a n-tox relation. The notation used here are double lines starting from a transition (see Figure 4). A synchronized blocks is either: a synchronized transition (of a generic net);
...
... t1
t2 ...
...
...
... (a)
(b)
Figure 4: Synchronized transitions: (a) one-to-x (b) n-to-x ... t3 ... t4
*
...
...
Figure 5: A synchronized block: a conjunction of synchronized transitions or a conjunction of synchronized blocks (notation: meeting double lines, with a `*' indicator, see Figure 5); or a disjunction of synchronized blocks (notation: meeting double lines, with a `+' indicator). Based on these building blocks, we can now de ne synchronization speci cations. A synchronization speci cation is a pair of synchronized blocks. Notationally, a synchronization speci cation is an interconnection of a pair of double lines (one per synchronized block). Now, what can we achieve with these speci cations ? Semantically, a synchronized transition imposes a restriction on the transition ring rule: a synchronized transition cannot re unless it is synchronized with another transition or synchronized block (i.e. res at the same time). The meaning of a synchronization speci cation is best explained through an example. In the example in Figure 6, t5 and t6 can only re if either t7, t8 or t9 are enabled. And vice versa, t7, t8 or t9 can only re if both t5 and t6 are enabled. Hence, when some of these transition re, it will be t5 and t6, and one of t7, t8 and t9.
The (recursive) de nition of synchronized blocks allows a lot of expressiveness and exibility in specifying transition synchronization. Since synchronization speci cations have been de ned for generic nets, they allow to specify synchronization of transitions of nets of di erent classes. In that case, we talk about multi-model nets.
4.2 High-Level Extensions
The basic form of synchronization speci cation can now easily be extended in the same way as nets themselves have been extended over the years. Similar to weights in P/T-nets, annotating n-to-x synchronized transitions with a weight function can indicate that a number of instances of that transition must synchronize with the other end of the synchronization speci cation. Also, synchronized transitions can be ascribed preconditions (in function of the state of the corresponding agent and the state of the agent(s) it needs to synchronize with). In that case, the transitions in a synchronization speci cation can only re when they are enabled and when the appropriate preconditions are ful lled. This resembles preconditions as in Predicate/Transition nets and CPNs. Moreover, the precondition of a synchronized transition can be a function of the input tokens of the transition. These transition synchronizations allow dynamicity in that they do not constitute a purely static synchronization, but merely interconnect names of transitions. If one or several of these transitions is not available at that time, the transition might nd another transition or synchronized block to synchronize with (that is, when it should synchronize with a disjunctive synchronized block). Achieving exibility (i.e. being able to alter the synchronization speci cations at run time) calls for a more thorough approach for presenting synchronization speci cations. These need be viewed as rst-class objects, manipulatable during the execution. However, the limited space prohibits us in detailing this subject here. One of the advantages of synchronization speci cations is that they enable the composition of di erent kinds of nets. Evidently, this could yield some problems when one tries to construct an overall net of a system in order to deduce some overall system properties. However, an algorithm for constructing such an overall net can be described. The general
agent 3 t7 agent 1
...
t5
+
...
t8 ...
t6
+
*
t9
...
...
# agents 2
agent 4
Figure 6: A synchronization speci cation idea is to construct a high-level net, which allows to abstract from multiple instances of certain classes of agents, by representing agents as tokens in this net. The principles of the algorithm are similar to the ones used for constructing an overall net (called Synthesis net) for Cooperative Nets and Cooperative Objects ([5]). A correct outline of the algorithm and an investigation on the impact of the overall net on the analysis techniques (some analysis results will be lost compared to the analysis of the isolated nets) is the subject of current research. A rst practical experience proved that synchronization speci cations are a welcome instrument for describing permissions for performing particular actions. Permissions are mostly based on the performers type and the actions which it performed previously (its state).
5 A Small CSCW Example Consider the following, simple shared blackboard application. One blackboard is used, manipulated, viewed by (possibly) multiple users. The blackboard can contain objects, called blackboard objects here ( gures, text, and so on), which can be created by users and which may be changed by users after having selected them (e.g. by clicking on them with a pointing device). Objects must be released before other users can manipulate them. For gures, a redrawing functionality is assumed (e.g. for scaling a gure, to reshape polygons, and so on). A user must acquire both the pen and the blackboard object before (s)he may redraw a gure. The model of this simpli ed application consists of a number of objects: users, blackboard objects and pens. The internal behaviour of the objects
is depicted within the respective rectangles in Figure 7. The object cooperation is modelled by a set of synchronization speci cations. E.g. the gure shows that when a user releases a blackboard object, the blackboard object can either be switched to an un-selected state, or it can be removed. Similarly, a user may change a blackboard object either by changing its name or by changing its shape. The synchronization speci cations not merely describe which object is entitled to do what in which state, it also serves to describe the interaction protocol. E.g. the protocol for changing the shape of a gure is to acquire the pen and a blackboard object (this may be done concurrently); thereafter the user can reshape the blackboard object.
6 Conclusion Synchronization speci cations are a powerful tool for denoting component cooperation through specifying their synchronization. Being de ned for generic nets, they allow to specify synchronization between transitions of any kind of nets. The synchronization speci cations introduced in this paper are a logical description of component cooperation. We do believe that for systems in a classical, highly distributed multi-agent and/or groupware environment, these purely net-based composition speci cations do not suce. They merely serve the purpose of specifying highly synchronized components. Another, complementary way of specifying component cooperation and coordination is based on generative communication ([2]) as in Linda and Objective Linda ([4]). It extends this notion by having message objects being autonomous agents themselves. In the future, our research will concern a thor-
object
+
user
pen idle
free
release
select
click
free
active
selected remove
free
acquire pen
free
release pen
holding_pen
move change
chngename
move
change-shape
+
Figure 7: A simple CSCW application. ough investigation of both generative communication and synchronization speci cations in PNTOX([3]), a language and development environment for agent-based system development.
7 References [1] L. Bernardinello and F. De Cindio. A Survey of Basic Net Models and Modular Net Classes. In Advances in Petri Nets '92, pages 304{351, 1992. [2] D. Gelernter. Generative Communication in Linda. ACM Transactions on Programming Languages and Systems, 7(1):80{112, 1985. [3] T. Holvoet and P. Verbaeten. PN-TOX: a Paradigm and Development Environment for Object Concurrency Speci cations. In Proceedings of the Workshop on Object-Oriented Programming and Models of Concurrency, ICATPN'95, Turin, Italy, 1995. To appear. [4] T. Kielmann. Designing a Coordination Model for Open Systems. In Proceedings of COORDINATION'96, Cesena, Italy, April 1996. [5] C. Sibertin-Blanc. Cooperative Nets. In Proceedings of the 15th International Conference on Application and Theory of Petri Nets, Zaragoza, Spain, LNCS 815, 1994.
grab
release
acquired
