Wuhan University dournal of Natural Sciences Vol. 3 No. 3 1998,288~292

tP

The Inher i tance of P N - C O O P N

Zhang Qian Computer Science ~ Technology Ins t i tu t ion ,Wuhan Univers i ty ,Wuhan 430072, China

A b s t r a c t An appropriate combination of COOP and Petri nets is required in order to profit from the strength of both methods. This paper gives an overview of our ongoing research on P N - C O O P N , which is a

paradigm and development environment for concurrent object-oriented programming based on Petri nets. We

describe the object model and programming notation and emphasis the Inheritance part for PN-COOPN.

K e y w o r d s inheritance, synchronizat ion, Petri net , object net , Inheritance anomaly

0 Introduction

In the domain of concurrent object-oriented programming (COOP) there is a strong need for a formalism to describe concurrency. Using a formal technique offers several advantages: it enables for- mal reasoning about the system being modeled in terms of behavior, properties, equivalence notions between system models, and so on.

We have chosen Petri nets as the formalism for modeling concurrency. Petri nets are widely used for modeling complex concurrent systems. Having been the subjects of intensive research for many years, it has well-developed theoretical foun- dation. One major drawback of Petri nets is the lack of thorough modularization techniques for coping with models for large systems. So, an ap- propriate combination of COOP and Petri nets can profit from the strength of both methods.

Recently, several systems and languages have been proposed for combining object-orientation with Petri nets. Here is a short overview.

POT systems have been introduced as a mod- eling technique for object-based systems. One POT is used to model an entire application. The state of objects is represented by a number of places in the POT. Objects are considered sequen- tial entities. The lack of an object model and a class concept prohibits the integration within ob- ject-orientation.

CO-OPN [l'z] is a formal specification language for specifying data structures and communication between algebraic data types. Since not based on state nets, intra-eoncurrency is allowed. Howev- er, inheritance is not considered.

LOOPN Ea? is a textual language for object-ori- ented Petri nets. LOOPN supports two class hier- archies, one for tokens and one for subnets. Inher- itance, overriding and polymorphism are allowed on both hierarchies. But still, one net is the over- all control structure of the application, and tokens are passive data item.

In this paper we present PN-COOPN (Petri Net for Concurrent Object-Oriented Programming Notation), a paradigm and development environ-

ment for concurrent object-oriented programming based on Petri nets. We describe the object model and programming notation and emphasis the inher- itance part. When designing the object model, we consider the inheritance of concurrency sufficient- ly, so we can see this object model can decrease the harmful effect of the inheritance anomaly E4~.

1 The object net model

The global idea for developing a PN-COOPN application is to use object-oriented techniques for modeling the application domain and identifying concurrently active, autonomous objects. In this model, objects are provided with a net describing

* Supported by the Foundation of National 863 Project. Received Jan. 7,1908. Zhang Qian,born in 19730 Ph. D

No. 3 Zhang Qian..The Inheritance of PN-COOPN 289

their concurrency behavior. 1.1 Petri net object

In order to describe the concurrency in PN- COOPN, we provide objects with a net, which called object net. The object nets model the con- current behavior that is inherent to the objects, that is, their "intra-object concurrent behavior". Each object net is encapsulated within an object, which then called a Petri net object. Each Petri net object has an interface, the other objects cart only assess it through the interface, those methods not belong to the interface can not be invoked by other objects. We provide each object with an object manager, whose responsibility is to synchronize each method with other methods in this object. To achieve this goal, we attach each method a syn- chronization policy and a synchronization condi- tion. Only the method that synchronization policy and condition have satisfied can be executed.

In order to enhance the expressive ability, we introduce two additional notations for the Petri nets. The first one is introduced to present that when leaving from one place, there are two choic- es, either choice (the following transition) can be reasonable. (See Fig. 1 (a)). The second one is in-

troduced to present that there exists two choices (places), either place can lead the occurrence of the following transition. (See Fig. l (b ) ) .

(a) (b)

Fig. 1 Two addi t ional no ta t i ons for the Petr i nets

Let us clarify the object net model through an example (See Fig. 2). In Fig. 2, we present the Petri net object----BoundedBuffer, this object have two operations, which are put and get respec- tively. Only when the buffer is not empty does the get method can execute, and only when the buffer is not full does the put method can execute. Only through these two methods can the other objects access this object. So in the interface part, we can only see get and put. (The construction of each object is in the interface by default)

The encapsulation of the object net has several advantages. First, it is a kind of information hid- ing. The internal activities of the Petri net object

I I n t e r f a c e , I n t e r n a l Obj . ec t N e t

n e w . . . . ~- . . . . . . . . . . - P O ~ . ~ l �9 , I * '~ . . . . . . . . . . . . . . . . . . . . --I

put - - - t - - - - ~ _ . _ _ ] T l l ' , T I2 _......2-.I,J-~P~j i [,,._,~T21 I ~ ; . _ _ _ + ~ _ ' ~ ' I 7~

. 4 . . . . . . . . . . . . .

get ---i PIIC) i ~ " - -"f22~ i OP2I ; C ) P I2 P 2 2 C ) :

I , 2_ 2', I i L _ ] TI3 T23 I . :

i

P3~,~ C ) P4

P0: Buffer is empty; TI I: Propose put query; T I 2 : Check the synchronisation policy:

P i !: W nit for the admission for put; P 12: Pass the synchronisation policy check;

T I3 : Check the synchronisation condition; P I3 : Pass thesynchronisa t ion condition check;

"I"!4: Execute put; T21: Propose get query; T22: Check the synchronisation policy;

P2: Wait for the admission for get; P22: Pass the synchronisation policy check:

1'23: Check thesynchronisa t ion condition; P23: Pass the synchronisation condition check;

"1'24: Execute put; P3: Buffer is partial; P4: Buffer is full; Pob j :Ob jec t manger

Fig. 2 The Petr i net objec t B o u n d e d B u f f e r

290 Wuhan University Journal of Natural Sciences Vol. 3

are irrelevant for some views of the application. Moreover, the internal concurrency behavior may be modified without effecting other objects that use the object's service operations.

Another advantage is the multi-model princi- ple. Several sorts of net models exist: from basic Condition/Event nets, over Place/Transition nets to high-level ne t s , such as Colored Petri nets and Predicate/Transition nets. Tom Holvoet has stated that each of these models has its domain where it may prefer over others rS]. Since object nets are en- capsulated within the Petri net object, objects from different classes may have object nets of different net models. This enables flexibility in designing an application, which is a necessity for developing large and complex systems. 1.2 Programming notations for object

Now, assume that we want one interface oper- ation for BoundedBuffer objects:put. After calling the put operation through the interface, the system checks whether T l l could be activate. If the buffer is empty or partial, the transition T l l could acti- vate. On one hand the system enters the place P l l , waiting for the admission to execute the put method. On the other hand, the object manager of this object checks the synchronization policy and the synchronization condition of put method. If there is no other put or get method active, and the buffer is not empty, then the transition T14 can activate, the system executes the put methods. Depending on the current size of the buffer, sys- tem can enter the place P3 or P4, which presents the buffer is partial or full respectively.

In order to express the above process, we pro- vide the programming notations for the object. Now we will explain the function of the following notations. One can use Class to define a new class, Inheritance to define the inheritance relationship, DataPrivate to define the internal data that can not be accessed by the other objects, DataPublie to de- fine the data that can be accessed by the other ob- jects, Method to define the internal method that can not be accessed by the other objects, Interface to define the method that can be accessed by the other objects, Sync-Policy to define the synchro- nization policy for each method, Sync-Cond to de- fine the synchronization condition for each method.

Using the programming notations explained

above, we can write the BoundedBuffer as Fig. 3.

Class BoundedBuffer { Inheritance NULl.; //Inheritance relationship

/ /no internal variable DataPrivate DataPublic int size; int MaxSize; / /no internal method Method Interface BoundedBuffer (int n) {MaxSize =

In;}

Interface void put(elm int) { {Sync-Policy (Mutex put get)} //control the synchronisation policy {Sync-Cond (size<Maxsize) } //control the synchronisation condition . . . s i z e + + ; . . . } //definition body Interface int get(void) { {Sync-Policy (Mutex get put) } //control the synchronisation policy {Sync-Cond (size~>0) } //control the synchronisation condition . . . s i z e - - ; . . . } //definition body

Fig. 3 The programming notation for the Bounded- Buffer class

2 I n h e r i t a n c e o f P N - C O O P N

The inheritance is an essential part of the inte- gration of Petri nets within object-orientation. The inheritance mechanism in object-oriented languages can help for the extensibility and reusability of the system [63. However, most concurrent object-ori- ented languages fail in combining their synchro- nization mechanisms with inheritance structure. This is called the inheritance anomaly.

It is our view that much of the problem stems from the way those method definitions in tradition- al programming languages tend to lump together the synchronization code with the internal state transformation. 2. 1 Separation of the functional code and syn- chronization code

Suppose another class BoundedBuffer2, it is inherited from class BoundedBuffer and do the fol- lowing changes: Introduce a new operation, get2, that removes two items from the buffer. The base class divided the state of the buffer into three parts: empty, full and partial. By introducing the method get2, the concept of a partiatly full buffer will need to be sub-divided into: (i) a buffer con-

No. 3 Zhang Qian..The Inheritance of PN-COOPN 291

taining one item, and (ii) a buffer containing two or more items. The get2 operation cannot execute in the former state but can in the latter. Now the get2 method will be invoked mutex with the put and get method. Therefore, the synchronization code at the existing operations put and get will have to change in order to take into account the new method get2.

We will have to rewrite the methods put and get anew, if the object model does not support the separation of the functional code and synchroniza- tion code. Thus we see that introducing a new op- eration might make it impossible to reuse any of the inherited sequential operations.

But the functional operations of the get and put method do not change at all. So in our model, by using the notations Sync-Policy and Sync-Cond, we divided the method into two parts, one present the synchronization code and the other present the definition body. We can write the definition of BoundedBuffer2 as Fig. 4. In the definition we use Inheritance to depict the inheritance relationship between two classes. When overriding the get and put methods, the only thing we need to do is rewriting the synchronization code of these two methods, the definition body can be inherited.

Class BoundedBuffer2 { Inheritance BoundedBuffer;

//Inheritance relationship Interface void put(elm int) { {Sync-Policy (Mutex put get get2)} / /other parts need no modify Interface int get (void) { {Sync-Poliey (Mutex get put get2)} / /other parts need no modify Interface int c2~ get2(void) { {Sync-Policy (Mutex get2 get put)} //control the synchronisation policy {Sync-eond (size> 1) } //control the synchronisation conditiol . . . s ize=s ize-2 ; . . . }

Fig. 4 The programming notation of the Bounded- Buffer2

2.2 Compositionality After analyzing the synchronization con-

straints of a method, we can see that each method has two kinds of constraints, which are synchro- nization policy constraints and synchronization co.n- dition constraints respectively. For example, in the BoundedBuffer2, only when there is no other get, get2 or put method is active, and the buffer is not empty, can get method be invoked.

In PN-COOPN, we can illustrate the Bound- edBuffer2 as Fig. 5. To formalize the relationship in BoundedBuffer2, we only need to add several new places, such as PS,P51 ,P52,P53, and several new transitions, such as T51, T52, T53, T54. These new places and transitions are used to pre- sent the new method get2. In order to synchroniza- tion with this new method, the synchronization code of the existed methods put and get has to change. Since the synchronization condition of these two methods does not change, so it can be inherited. The only thing we need to do is overrid- ing the synchronization policy of those methods. So in PN-COOPN, we only need to override the transitions T12 and T22.

In the concurrent environment, there are some synchronization policies that can be used frequent- ly, these include. ReadersWriter policy, Shortest Job First Sever policy, Mutex policy and so on. These policies are used frequently in concurrent programming, so making these policies into a syn- chronization policy library (SPL) would improve the reusability of code. In this object model, we use the concept of synchronization policies library (SPL) as a means of reducing the inheritance anomaly.

292 Wuhan University Journal of Natural Sciences Vol. 3

. . l i ter(ace " . . . . . . . . . . . . . . . . . . . . . . . . . . . I.nte..rn.al. Ob.j.ec.t. Net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

new . . . . . . . . . . . . . . . . . . . . .

,u, . . . .

g e t - - - - I : . l l P l l U ! ~, T22 ,

,'-Hk . . . . . . . . --c

ill ' ~ 6 P I 3 P 2 3 (

T51 : Propose get2 query;

! +2 ,

P2

.I __. __'

P52 I

3 T53[

. . . . . . ~ ~ L

0 P5 P3 l ~ f .9 P4

T52: Check the synchronisation policy;

P51: Wait for the admission for get2; P52: Pass the synchronisation policy check;

T53: Check the synchronisat ion condition; P53: Pass the synchronisation condition check;

"1"54: Execute get2; P5: Buffer has only one element.

Fig. 5 The Petrl net object . . . . BoundedBuffer2

References

1 Biberstein O,Buchs D. Concurrency and object-orienta- tion with structured algebraic nets. 1S-CORE work- shop, Evry: September 1995. 73-75

2 Biberstein O,Buehs D. An Object Oriented Specification Language based on Hierarchical Algebraic Petri Nets. In : Agha G, Cindio F eds. Proc. o f workshop on Object- Oriented Programming and Models o f concurrency. Italy: 1995. 131-145

3 Lakos C. The Object Orientation of Object Petri Nets. In : Agha G, Cindio F eds. Proceedings of Workshop on Object-Orientation and Models o f Concurrency, lnt'l Conference on Application and Theory of Petri nets,

Italy: June, 1995 4 Matsuoka S, Wakita K, Yonezawa A. Inheritance

Anomaly in Object-Oriented Concurrent Programming Languages. In: Agha G, Wegner P,Yonezawa A eds. Research Directions in Concurrent Object-Oriented Pro- grarnming. Cambridge MA:MIT Press, 1993

5 Holvoet T,Verbaeten P. PN-TOX:a Paradigm and De- velopment Environment for Object Concurrency Specifi- cations. In: Agha G, Cindio F eds. Proceedings of Workshop on Object-Orientation and Models of Concur- rency, lnt'l Conference on Application and Theory of Petri Nets. Italy: June, 1995

6 Aksit M, Dijkstra J W, Tripathi A. Atomic Delegation: Object-oriented Transactions. 1EEE Software, 1991,8 (2) .. 331-345