Integrating Software Engineering Methods and Petri Nets for the Speci cation and Prototyping of Complex Information Systems ? Yi Deng1 , S.K. Chang2, Jorge C.A. de Figueired2 and Angelo Perkusich2 School of Computer Science Florida International University { Miami, FL 33199 { USA 2 Department of Computer Science University of Pittsburgh { Pittsburgh, PA 15260 { USA 1
Abstract. We present a Petri net based framework called G-Net for the modular design of complex information systems. The motivation of this framework is to integrate Petri net theory with a modular, objectoriented approach for the speci cation and prototyping of complex software systems. We use the client/server example to illustrate the G-Net speci cation of distributed systems, and how such a speci cation can be translated into a Predicate/Transition net for formal analysis. The di erences between G-Net and hierarchical Petri net, as well as some limitations of the transformation technique, are then discussed.
1 Introduction First introduced by C.A. Petri in the early sixties, Petri nets have been actively studied and applied to many areas of computer science. Di erent variations or extensions of Petri nets have been proposed. The early Condition/Event (CE) nets and their extension, Place/Transition nets, serve as the basis for other higher level or more specialized Petri net models. However, when modeling systems that consist of many interrelated identical components, these basic Petri net models exhibit great redundancy, since the only way to di erentiate two identical elements is to specify an identical subnet for each one. An important development in Petri net theory is the introduction of individual tokens, that is, to allow individual objects as tokens. With this extension, we can model the common component only once and assign one distinguishable token to each identical component. This development leads to a class of Petri-Nets called highlevel Petri-Nets, including Predicate/Transition nets (PrT-nets) [10, 9] Colored Petri-Nets (CP-Nets) [12] Relation Nets (Rel-Nets) [17], and Petri Nets with Individual Tokens [18]. However, even with high level Petri nets, system modeling ?
Also with Departamento de Engenharia Eletrica, Universidade Federal da Paraba, 58100, Campina Grande, PB { Brazil. The authors would like to acknowledge the nancial support of CNPq/Brazil in the form of scholarship 201463/91-1 and 201462/91-5. Application and Theory of Petri Nets 1993, Lecture Notes in Computer Science, LNCS-691, pages 206-223, June, 1993, Chicago, USA, Springer-Verlag.
can still be dicult because no mechanisms or notations are provided in these models to specify the structure of a system. For example, there is no concept of hierarchy. To remedy the problem, another extension has been proposed to introduce the concept of hierarchy to high-level Petri nets. The resulting Petri net models are called hierarchical Petri nets, including Hierarchical CP-Nets [11, 12] and Hierarchical PrT-nets [15]. As indicated in [11] although the hierarchical constructs introduced do not extend the modeling power of CP-Nets, they do provide structuring tools to construct large system models in practice. In this paper, we present a Petri net based framework called G-Net for the modular design and speci cation of distributed information systems. The framework [4, 5, 6] is an integration of Petri net theory with the software engineering approach for system design. The motivation of this integration is to bridge the gap between the formal treatment of Petri nets and a modular, object-oriented approach for the speci cation and prototyping of complex software systems. The G-Net notation incorporates the notions of module and system structure into Petri nets; and promotes abstraction, encapsulation and loose coupling among the modules. The former feature makes G-Net a more suitable tool for specifying complex software systems. The latter feature supports incremental modi cation of the speci cation of a complex system. A speci cation based on G-Nets (called a G-Net speci cation) consists of a set of independent and loosely-coupled modules (G-Nets) organized in terms of various system structures. Recursive structures or functions can be easily and naturally speci ed by G-Nets. A G-Net is encapsulated in such a way that a module can only access another module through a well de ned mechanism called G-Net abstraction, and no G-Net can directly a ect the internal structure of another module. As indicated by Booch [1] we can hardly make a complex design right at the rst try, thus complex software design is an evolutionary process, where repeated changes are necessary. Also, as argued by Luqi [13], the potential bene ts of prototyping depend critically on the ability to modify the prototype's behavior with substantially less e ort than required to modify the production software. The modular features of G-Nets provide the necessary support for incremental design and successive modi cation. A G-Net speci cation can be directly executed in a distributed environment, where a G-Net is a natural unit for distribution and execution [3]. The execution mechanism allows multiple instances of invocation on the same G-Net to be executed simultaneously. The execution of a G-Net handled by multiple distributed computation agents enables the execution to be conducted in a parallel fashion. The paper is organized as follows. In Section 2 we introduce the basic notations and concepts. The unique modularization features of the G-Nets and their impact on incremental design and continuous modi cation are discussed. We also show that recursive structures can be easily and naturally speci ed using G-Nets. A prototype G-Net system has been implemented on SUN workstations connected by a LAN. Some examples are used to show the execution of the system. The modeling of a client/server interaction using G-Nets is presented in Section 3. A formal transformation technique has been developed, which is
capable of translating a G-Net speci cation to a semantically equivalent Predicate/Transition nets (PrT-nets). With this transformation, the formal analysis techniques for PrT-nets can then be applied to G-Net speci cations. We will present the transformation procedure in Section 4. Finally, the conclusion of this paper is given in Section 5, where the di erences between G-Net and hierarchical Petri net are also discussed.
2 G-Net Abstraction and Instantiation A widely accepted software engineering principle of design is that a system should be composed of a set of independent modules, where each module in the system hides the internal details of its processing activities and modules communicate through well-de ned interfaces [7]. The G-Net notations provide a strong support to this principle. As mentioned earlier, a system modeled in terms of a G-Net speci cation is composed of a set of self-contained modules called G-Nets. A G-Net, G, is composed of two parts: a special place called Generic Switch Place (GSP) and an Internal Structure (IS). The GSP provides the abstraction of the module, and serves as the only interface between the G-Net and other modules. The IS, a modi ed Petri Net, represents the detailed internal realization of the modeled application. An example is shown in Figure 1. The GSP of a G-Net, G, (denoted by G:GSP in the ellipse of Figure 1) uniquely identi es the module. The GSP contains one or more executable methods (denoted by G.MS in the round-cornered rectangle in Figure 1) specifying the functions, operations or services de ned by the net, and a set of attributes (denoted by G.AS) specifying the passive properties of the module (if any). The detailed structures and information ows of each method in G:MS are de ned by a piece of Petri net in G:IS . More speci cally, a method mtd 2 G:MS de nes the input parameters, the initial marking of the corresponding internal Petri net (the initial state of the execution), a set of special places called Goal Places (denoted by double circle in Figure 1) represents the nal state of the execution, and the results (if any) to be returned. The collection of the methods and the attributes (if any) provides the abstraction or the external view of the module. In G:IS , Petri Net places represent primitives; and transitions, together with arcs, represent connections or relations among the primitives. These primitives may be actions, predicates, data entities, and Instantiated Switch Place (ISP). A primitive is said to be enabled if it receives a token, and an enabled primitive can be executed. A transition, together with arcs, de nes the synchronization and coordinates the information transfer between its input and output places (primitives). More speci cally, an input arc between a transition t and an input place p may carry an inscription denoted by I (p; t). I (p; t) is composed of a set of items, each of which is either a variable or a logical expression of variables. I (p; t), p 2 I (t), de nes the conditions when t is enabled and de nes the values to be exported by the primitive p. We assume that the inscriptions on the input arcs of t do not share variables to avoid ambiguity. An output arc may also have an inscription, which is a list of variables de ning the content of the input token
to each output place. GSP(G2)
GSP(G1)
mG2={r}
mG1={a}
P1 P1 t1 t2
t1
P4
P2 isp(G2)
P3
P2
P3
t2
t3
P5
Fig. 1. Two G-Nets connected through an isp Given a G-Net G, an ISP of G is a tuple (G:Nid, mtd) which is denoted by isp(G:Nid; mtd) (or simply isp(G) if no ambiguity occurs), where G:Nid is the unique identi cation of G, and mtd 2 G:MS . Each isp(G:Nid; mtd) denotes an instantiation of the G-Net G, i.e. an instance of invocation of G based on the method mtd 2 G:MS . Therefore, executing the ISP primitive implies invoking G (by sending a token to G) based on the speci ed method using the content of
the token (received at the ISP) as input (if any). On the other hand, using an ISP of one G-Net (say isp(G:Nid; mtd)) as a building block (primitive) in the Internal Structure of another G-Net, G0 :IS , speci es a connection between the two G-Nets. Since the ISP is treated as a primitive of G0 :IS , the precise meaning of the connection between G0 and G is de ned by the connections between the primitives of G0 :IS . From the view point of G0 , invoking G from its internal structure is just like executing another primitive. The ISP notation serves as the primary mechanism for specifying the connections or relationships between di erent G-Nets (modules). Embedding an ISP of a lower level G-Net into the IS of a higher G-Net speci es a hierarchical con guration. Embedding an ISP of a G-Net into its own IS speci es a recursive con guration. Furthermore, embedding an ISP of a G-Net specifying a server into a G-Net specifying a client results in a client-server relation. Figure 1 shows an example of two G-Nets connected by an isp, where an isp of G2 is used as a primitive of G1 . For net G1 it is de ned one method, mG1 , that receives an integer a, and for net G2 it is de ned one method, mG2 , that receives a integer r. Figure 2 shows a G-Net specifying the recursive function f (n) = 2f (n?1) ; f (0) = 1, where n 2 IN. The G-Net has one method, m1 , with input n and initial
marking P1. If n > 0, transition t1 becomes enabled and res. Primitive P2 decreases the value of n by 1. Primitive P3 is an ISP which recursively invokes the G-Net to compute f (n ? 1). Primitive P5 calculates f (n ? 1) 2. If input n = 0, transition t4 res, and primitive P4 returns 1 as the result. GSP(G) mG={n}
P1
t1
t4
P2 P4 t2
P3 isp(G)
P5
t3
Fig. 2. G-Net speci cation of a recursive function The G-Nets in a G-Net system are loosely coupled because they don't share variables, and they interact with each other only through their GSPs (by the means of token passing). The internal structure of a G-Net is transparent to the others. Therefore, any change made to the internal structure, IS , of a G-Net is unlikely to a ect the structures of the other G-Nets as long as the interface de ned by its GSP remains unchanged. Furthermore, the entire G-Net speci cation can be built incrementally in a G-Net by G-Net basis, and a G-Net can be referenced by the other G-Nets even before the design of its internal structure, because the interface of the net is solely determined by its GSP. An interesting feature of the G-Net framework is that it allows more than one invocation of a G-Net to be executed simultaneously. This feature is due to the unique token structure in the G-Net framework. A token, tkn, is de ned as a triple, i.e. tkn = (seq; sc; msg), where tkn:seq is called propagation sequence, tkn:sc is called the status color, and tkn:msg is called the message of the token. Tkn:seq is a sequence of hNid; isp; Pidi, where Nid is the identi er of a G-Net, isp is the name of an ISP and Pid is a process identi cation. The propagation sequence of a token is only changed in ISP and GSP . When a GNet, G, is invoked from an ISP , ispi , in another G-Net, G0 , (when ispi receives a token), a triple hG0 ; ispi; PidG i, where PidG is the identi er of the process executing G0 , is appended to the propagation sequence of the token before it is sent to G-Net G. This triple indicates that when the execution of G is over, the 0
0
resulting token should be returned to the place identi ed by ispi in G-Net G0 . The process identi er is needed to distinguish which instance of the execution on G0 the returning token belongs to. When the input token received at the GSP G, a triple h0; 0; PidGi is appended to the end of its propagation sequence indicating that the agent responsible for executing the invocation is identi ed by PidG . Because PidG is unique, the propagation sequence is also unique. The token structure in the G-Net framework thus not only guarantees that all tokens belong to an instance of a G-Net execution have the same and unique propagation sequence, but also contains the complete propagation history of the tokens, which governs the interactions between the processes executing a G-Net speci cation. The status color of a token has two possible values, either before or after. A token is said to be available if its sc = after, otherwise, it is said to be unavailable. When a new token is received at a place, its status color is set to be before, and after the primitive action at the place is taken, the status color of the token is set to be after, indicating that the token is ready to be used in subsequent transition ring. The message eld of a token is a list of application speci c values. The G-Net transition ring mechanism is de ned by the following transition ( ring) rules: 1. A transition t is said enabled i : (a) every place p 2 I (t) holds at least one token and its content satis es the condition de ned by I (p; t); (b) all the tokens stated in (a) have the same propagation sequence; (c) all the tokens stated in (a) and (b) have their sc = after; and (d) the number of tokens in O(t) is smaller than the capacities of the places. 2. An enabled transition t may re. When ring t: (a) a token which satis es I (p; t) is removed from every p 2 I (t); and (b) a token whose propagation sequence is the same as the one in tokens removed from I (t), whose sc = before, and whose message part is determined by O(t; p) is deposited to every place p 2 O(t). An invocation of a G-Net, G, based on a method mtd 2 G:MS is carried out in the following way: 1. Determine the initial marking of G based on the de nition of mtd (the content of the tokens depends on the content of the input token); 2. Fire enabled transitions, if any; 3. Invoke enabled primitives, if any; 4. Repeat (2)-(3) until a Goal Place is reached; 5. Send the result of the execution (if de ned by mtd) to the invoker. The execution of a G-Net speci cation is carried out by a set of concurrent processes called agents. A G-Net can be associated with one of the two execution modes, namely, instantiation mode or server mode. In the instantiation mode, the function of an agent is solely to execute one instance of a G-Net invocation based on a speci ed method. A new agent is created for every instantiation of the G-Net; and the agent is terminated when the instance of the G-Net execution
User
SCHEDULER input/output server Remote
Name Server
MSG-IN
Machines MSG-OUT
COORDINATOR
G-Net Editor AGENTS
User
G-Net Base G-Net Dictionary
Fig. 3. Block diagram of the G-Net simulator is done. In the server mode, only one agent is associated with a G-Net specifying a server. The agent is called a server agent which handles all client request sent to the server. The agents communicate to each other through token passing as described above. The G-Net framework maximize the concurrency among the agents because (1) the agents are independent in the sense that no agent has direct control over another; and (2) while an agent is waiting for the result of an invocation of another G-Net, it can still execute other primitives which do not depend on the result of the communication. Such concurrency among the primitives is explicitly speci ed by Petri net notations. For instance, in Figure 1, while the agent executing G1 is waiting for the reply from G2 (at P2), it can still execute P3 and P4. Thus the execution of the both G-Nets are conducted in parallel. A prototype of a simulator for G-Net systems has been implemented on SUN workstations connected by a LAN. The structure of the system and the details of the implementation can be found in [3, 4]. In Figure 3 the block diagram of the simulator is shown. A copy of the simulator resides in each machine of a distributed system executing a G-Net speci cation. The SCHEDULER has four basic modules. The SHELL module implements the interface between the user and the module COORD, named coordinator. The module COORD is the main part of the SCHEDULER, its main functions are: creation of computation agents to execute a G-Net speci cation; and provision of an interface between the agents and the message server. The message server, named MSG SERVER, handles inter-process comunication for local and remote agents. The module
Fig. 4. The execution of the G-Nets of Figure 1 NAME-SERVER provides a mapping from a given logical G-Net identi er to a phisycal address for the system network. As shown in Figure 3, there is also an o -line user inteface. The main modules are the G-Net Editor and the G-Net Dictionary. The G-Net Editor is a prompt-driven editor that allows the user to input or change a G-Net speci cation. The G-Net Dictionary is a set of prede ned high level G-Net constructs. Finally, the G-Net Base contains the text les specifying each G-Net alocated to a machine. The execution of the G-Nets of Figure 1 is shown in Figure 4, where the GNet G1 is allocated in a machine called "gumby", and G-Net G2 is allocated in a machine called "elvis". Two middle windows in the gure are for the SCHEDULER subsystem in the two machines respectively. These subsystems run on every involved machines to control the execution and to coordinate the communications between the computation agents executing the G-Nets. The two bottom windows show the traces of the execution of the two G-Nets G1 and G2 , respectively. The execution of the recursive G-Net G of Figure 2 is shown in Figure 5, where the G-Net G is invoked with input n = 2. The three windows on the top of the gure are associated with three recursive instantiations of the net with input n being 2, 1 and 0, respectively.
Fig. 5. The execution of the recursive G-Net of Figure 2
3 Client-Server Example In this section we present the modeling of a client/server interaction using GNets. The server may attend requests from clients and it is provided a bu er for pending requests. The client may issue various requests to the server, depending on the service that is to be executed. After a successful request, the client sends the data to the server to trigger the execution of the pending request. When the server receives a request it checks if it can either accept the request in case there is space in the bu er, or reject the request otherwise. If the pending requests bu er is not full it puts the requested information, in this case the service needed, in a bu er, to be processed when the data arrives. The availability of bu er space is modeled by an attribute, BS, associated with the server. Upon starting the execution of request the server updates the attribute related to the bu er and starts the execution of the service. After executing a request the server sends a positive acknowledge to the client. The client/sever interaction as described above is modeled for the i-th client by G-Net G(C ), presented in Figure 6, and for the server by G-Net G(S ) modeling the client and presented in Figure 7. The process starts when the client has a request to send to the server. In this case, a token is deposited in place
GSP(C)
CR CR: client pending requests GC: client request executed
isp(S.mc) E
sa
es
es: enquire server sa: server available
sb ce isp(S.ms)
ce: correct execution sb: server busy
S GC
Fig. 6. G-Net modeling the Client
CR in the G-Net G(C ). The transition es res and a token is put in place isp(S.ms), with the service identi cation, service id, associated to it. Then, the G-Net G(S ) is invoked with method ms to verify if the server is available. A token is deposited in place SV in the G-Net G(S ). The availability of bu er space will determine which transition will re, i.e., bn or ba. If no space is available in the bu er, transition bn res and a token is deposited in place GD and the invocation resumes. In this case, after the invocation, the transition sb in G-Net G(C ) res, a token is deposited in place CR and the process is repeated until the pending request is executed. If space is available in the bu er, the transition ba in G(S ) res and tokens are deposited in places PR and GR. The bu er capacity attribute is decremented by one and the invocation resumes. In this case, transition sa res, and the data inforamation is obtained from place CR, a token is deposited in place isp(S.mc) that invokes the G-Net G(S ) with method mc. Then, a token is put in place TR in G-Net G(S ) and transition ex res and the pending request is processed, and the bu er capacity attribute, BS, is incremented by one. After processing the request (token in place ER), transition ac res, an acknowledgment is sent to the client and the invocation resumes. Transition ce in G-net G(C ) res, a token is deposited in goal place GC and the interaction nishes.
4 A Formal Transformation Technique A formal transformation technique has been proposed in [4]. The technique translates a G-Net speci cation to a set of PrT-nets, where each PrT-net corresponds to a method in the G-Net speci cation, and has the equivalent semantics as the latter. By this transformation, the formal analysis techniques developed for PrT-nets can be used to analyze G-Net speci cations. There are some limitations associated with this formal transformation technique. The transformation is, at this time, restricted to G-Nets without net-wide
GSP(S)
SV
BS={0,1,..,n} ms={service_id} me={data} PR
SR
SV: status verification GR: return status PR: pending service request
bn
ba
ex
ER: executing request SA: send acknowledge ER
SR: start execution a request bn: buffer not available ba: buffer available
GR
ac
ex: execute pending request ac: acknowledge client SA
Fig. 7. G-Net modeling the Server attribute set. A more serious weakness is that the technique does not take advantage of the abstraction and modularization features of G-Nets. Therefore, when it is applied to analyze complex G-Net speci cations, we are likely to face the so-called state explosion problem, which is considered to be a major weakness of Petri nets [14]. Nevertheless, this formal transformation does provide a theoretical foundation for the G-Net framework. In this section, we use the G-Nets in Figure 1 as an example for illustrate the transformation procedure. A more formal presentation of the technique and associated proofs can be found in [4]. The transformation algorithm accepts a G-Net speci cation de ned by GS = G1 ; G2 ; ; Gk and a method mtd 2 G:MS , G 2 GS , as inputs. It produces a semantically equivalent PrT-Net corresponding to the method as output. The key of this transformation is the treatment of GSPs and ISPs. The basic idea of the algorithm can be described as follows: For each regular place (primitive action) and each transition, we create an equivalent segment in PrT-net notation. As the result of the translation of an ISP, isp(G0 ), the PrT-net representation of G0 :IS is also created, recursively. Because multiple ISPs corresponding to G0 may be used in the G-Net speci cation, we must be careful that G0 :IS is only translated once. The de nition of the method mtd will determine the initial marking and nal marking of the PrT-net, these markings become the interfaces to other part of the speci cation. Another issue is that, since the concept of propagation sequence is not de ned in PrT-nets, we have to use regular attributes to mimic of the e ect of G-Net token propagation sequence. We start with elementary transformations. The transformation of regular places and transitions is quite intuitive. A regular place in G-Net can be viewed as a mapping, denoted by A(p), between a set of input parameters, I (p) =
P
Pf
Pl
Fig. 8. The transformation of a primitive hseq; x ; x ; : : : ; xq i, (carried by the input token, an input token is one whose sc = before), and a set of output parameters, O(p) = hseq; y ; y ; : : : ; yr i, which 1
2
1
2
constitute the content of the output token from the place. Such a place can be easily transformed to PrT-net representation shown in Figure 8. Notice that the propagation sequence of the token remains unchanged. A transition, t, in a G-Net can also be easily transformed to PrT-net notation as shown in Figure 9. P1
P3
P1l
P3f
O(P1)
t P2
t’ P4
P2l
O(P2)
I(P,t), P
P4f I(t)
Fig. 9. The transformation of a transition and its surrounding arcs Recall that an ISP denotes a G-Net instantiation. Every time the ISP receives an input token, the G-Net corresponding to the ISP is invoked. More speci cally, the semantics of an ISP, Isp(G0 :Nid; mtd0 ), is de ned in the following procedure, where Step 1 and 4 are to update the propagation sequence of the token. 1. action before : tkn:seq tkn:seq + hNid; NAME (p); Pidi; 2. Invoking G-Net G0 based on method mtd0 using tkn as input (by sending the token to G0 ); 3. Waiting for the result of step (2) 4. action after : tkn:seq tkn:seq ? LAST (tkn:seq); tkn:sc after, There are two basic issues need to be addressed in the transformation of an ISP. The rst is how to interface the G-Net, G, which contains the ISP, and the G-Net G0 . The second is how to simulate the semantics of the G-Net token propagation sequence, so as to maintain the uniqueness of the tokens in a GNet invocation. This is important because in the resulting PrT-net we must be able to distinguish the tokens belonging to one invocation of a G-Net from the tokens belonging to other invocations. Such an ability will ensure that the ring
of a transition only involves tokens of the same invocation, thus maintaining the semantics of a G-Net execution. The transformation procedure of an ISP, isp(G0 ; mtd0 ), is illustrate in Figure 10. isp(G’)
Pf(M 0(G’,m’))
Pf
t1
Ps
P2
t2
G’.IS
t3
P3
t4
Pl
Pl(M f (G’,m’))
Fig. 10. The transformation of an ISP The rst function of an ISP, isp(G0 ; mtd0 ), is to update the propagation sequence of the input token. Since the multi-agent concept is not de ned in PrTnet, we mimic the role of action before using Pf, Ps, t1, P2 and the connections between them as shown in Figure 10. The integer value generated by the marking of Ps, which is increased by one each time t1 res, is used to mimic the unique process identi cations in G-Nets. The value is then combined with the propagation sequence of the input token of the ISP serving as the propagation sequence of the tokens involved in the execution of G0 . In the transformation shown in Figure 10, transition t2 serves as the connection point of G and G0 . The output places of t2 are the places de ned in the initial marking of mtd0 in G0 . The inscriptions on the arcs between t2 and its output places can also be determined from mtd de nition. Therefore, t2 serves as a gate in the resulting PrT-net, and the ring of t2 moves tokens from one G-Net to another. The part of PrT-net corresponding to G0 is produced by recursively calling the G-Net transformation procedure, which guarantees that each G-Net is only transformed at most once. Similarly, transition t3 serves as another connection point between G and G0 in the resulting PrT-net. The input place of t3 is the goal place in G0 de ned by mtd. The ring of t3 indicates the end of execution of G0 . Finally, transition t4 represent event (de ned by action after) which recovers the propagation sequence of the tokens back from G0 to the original one in G. A nal note is that the status color of tokens is not used in the transformation, because the structure of the transformation sequence has re ected the order of processing, thus status color is no longer necessary.
In summary, the following description provides the framework of the transformation algorithm, where GS = G1 ; G2 ; : : : Gk is a G-Net speci cation, G 2 GS , and mtd 2 G:MS . 1. IF G 62 GS THEN return the initial marking and the goal place of mtd of G; exit; 2. GS GS ? G 3. FOR every place p 2 G DO If p is an regular place THEN Place Transformation (p); ELSE ISP Transformation (p, GS); 4. FOR every transition t in G DO T transformation (t); 5. return the initial marking and the goal place of mtd of G; exit;
GSP(S)
SV
bn
n
BS
ba
ms={service_id} me={data}
SR
PR
ex
ER
GR
ac
SA
BS: place modeling the status of the buffer, n={0,1,2,...,m}
Fig. 11. G-Net modeling the Server with a place modeling the bu er state It has been shown that the time complexity of the transformation algorithm and the size of the resulting PrT-net are both linear to the size of the G-Net speci cation GS . As an example, the transformation of the client/server interaction speci ed as in Section 3 will be shown. Before applying the transformation to the G-Nets specifying the client/server interaction, the G-Nets are redrawn with annotations about the inscriptions on arcs. In Figure 11 the revised G-Net for the server is
CRf
PEf
PE2
< ω ,i>
sb r=nak
PI2
< ω ,i=i+1>
PIs
< ω ,i>
< ω ,i=i+1>
sa r=ack PEs
PEl
ERf
TRf
ce
GCf
ex
BS
< ω ,1>
bn
GRf
EXf
GCf
SVl
ba
< ω ,1>
SAl
ERl
TRl
SVf
BA
EXl
PI3
< ω ,n>
PIl
PIf
es
CRl
PE3
SAf
GRl
Fig. 12. The PrT-net corresponding to the G-Nets specifying the client/server shown. Also, before applying the transformation the attribute representing the status of the bu er is embedded into the net, as shown in Figure 11. It is also necessary to eliminate the inhibitor arc from place BS to transition bn. This elimination is very simple once BS is bounded. The resulting net is not presented. But on the resultant PrT-net, shown in Figure 12, place BA plus the arcs connecting it to transition ex, ba, and bn are resultant from this elimination. Notice that the ! in the resulting PrT-net, as for example used in connecting place BS and transition ba, is a universal propagation sequence, which can match with any other propagation sequence in transition ring. This concept is designed speci cally for specifying shared resources. In Figure 11 hpi, hri and h1i are the service indenti er, returning token and an anonymous token, respectively.
5 Discussion and Conclusion In the preceding sections, we presented a modular, object-oriented approach for the speci cation and prototyping of complex software systems. The client/server example was used to illustrate the G-net speci cation of distributed systems, and how such a speci cation can be translated into a PrT net for formal analysis. G-Nets di er from hierarchical Petri nets in both technical and paradigmatic aspects. These di erences will now be discussed. System modeling based on hierarchical Petri nets follows the stepwise re nement approach, in which high-level speci cations will be eventually replaced by
more detailed lower level speci cations. This is clearly shown by the rationale behind the substitution of transitions and places [11]. On the other hand, GNets are a multi-level modeling and speci cation tool, in which each higher level G-Net imposes constraints and requirements on lower level ones so that all levels remain part of the nal speci cation [8]. The fundamental concepts behind G-Nets, namely Logical Entity Abstraction and Instantiation (LEAI) [4] are independent of, and have no counterpart in the Petri net theory. These concepts are the cornerstones of the G-Net framework. The notion of G-Net is fundamentally di erent from the notion of a subnet. A subnet in hierarchical Petri nets is a speci cation of some functional unit with single entry and exit. In addition, conventional Petri nets emphasize control information and provide little opportunity for representing data [19]. In contrast, G-Net is a uni ed notion for specifying not only functional modules but also objects and data. In hierarchical Petri nets, subnets are tightly coupled, where socket places (transitions) must match exactly to the corresponding port places (transitions), because socket places or transitions are the interface of a higher-level net to a lower-level net whose interface to the high-level net is in turn represented by the corresponding port places or transitions [11]. In a G-Net speci cation, each G-Net is a self-contained and independent module. The G-Net abstraction separates the external properties of the module from its realization or internal structure. No G-Net can directly access the internal structure of another G-Net. Under the concept of G-Net instantiation, the G-Nets in a system speci cation are loosely coupled through a well de ned and encapsulated mechanism, named G-Net abstraction. Any change made to the internal structure of a G-Net are transparent to other G-Nets. The self-contained nature of G-Nets also provides the means to allocate a system speci cation in a distributed environment and to concurrently execute the speci cation. In the development of the theory of G-Nets the most powerful way to analyze a G-Net speci cation is through simulation. Since a G-Net system is an executable speci cation and a simulator has already been implemented, analysis by simulation is feasible. This gives the designer a powerful tool to validate a speci cation. Currently the transformation procedure presented in Section 4 can only handle functional or control modules and restricted types of attributes, e.g. nite integers. Another limitation of the technique is that it does not take advantage of the abstraction and modularization features of the G-Nets. Therefore, when it is applied to the analysis of complex G-Net speci cations, we are likely to face the so-called state explosion problem, a major problem of Petri nets [14]. A more desirable approach would be to develop a localized analysis technique, which allows us to analyze each G-Net individually, and to express and verify the properties of a G-Net speci cation by composing the results of analysis of the individual G-Nets. Since the size of each G-Net can be kept small with proper design, the state explosion problem can be signi cantly reduced. This localized analysis technique is currently under investigation. Also, the timing analysis of
G-Net has been addressed. An extension to G-Net is being investigated in order to permit the speci cation of timing requirements and the performance analysis of systems. In [16] these two aspects together with an approach to embed fault-tolerant properties in the design of complex software systems are described. We are currently investigating two problems based on the G-Net framework. First, we are using G-Net as a speci cation and simulation tool for the design of distributed multimedia systems [20]. Second, we are cooperating with an industrial partner to apply the G-Net system tool for the fault-tolerant design and performance analysis of real time control systems [2].
References 1. G. Booch. Object Oriented Design with Applications. The Benjamin/Cummings Publishing Company Inc., Redwood City, CA, 1991. 2. S.K. Chang, A. Perkusich, J.C.A. de Figueiredo, B. Yu, and M.J. Ehrenberger. The design of real-time distributed information systems with object-oriented and fault-tolerant characteristics. In Proc. of The Fifth International Conference on Software Engineering and Knowledge Engineering, San Francisco, California, June 1993. 3. T.C. Chen, Y. Deng, and S.K. Chang. A simulator for distributed systems using g-nets. In Proceedings of 1992 Pittsburgh Simulation Conference, Pittsburgh, PA, USA, May 1992. 4. Y. Deng. A Uni ed Framework for the Modeling, Prototyping and Design of Distributed Information Systems. PhD thesis, Department of Computer Science, University of Pittsburgh, 1992. 5. Y. Deng and S.K. Chang. A framework for the modeling and prototyping of distributed information systems. International Journal of Software Engineering and Knowledge Engineering, 2(3):203{226, September 1991. 6. Y. Deng and S.K. Chang. Unifying multi-paradigms in software system design. In Proc. of the 4th Int. Conf. on Software Engineering and Knowledge Engineering, Capri, Italy, June 1992. 7. R. Fairley. Software Engineering Concepts. MacGraw-Hill, New York, NJ, 1985. 8. A. Gabrielian and M.K. Franklin. Multilevel speci cation of real time systems. Com. of ACM, 34(5):50{60, May 1991. 9. H.J. Genrich. Predicate/Transition nets. In W. Brauer, W. Reisig, and G. Rozemberg, editors, Petri Nets: Central Models and Their Properties, volume 254 of Lecture Notes in Computer Science, pages 207{247. Springer-Verlag, 1987. 10. H.J. Genrich and K. Lautenbach. System modeling with high level-petri nets. Theoretical Computer Science, 13:109{136, 1981. 11. P. Huber, K. Jensen, and R.M. Shapiro. Hierarchies in coloured petri nets. In Jensen. K. and G. Rozenberg, editors, High-Level Petri Nets: Theory and Application, pages 313{341. Springer-Verlag, 1991. 12. K. Jensen. Coloured petri nets: A high level language for system design and analysis. In Advances in Petri Nets 1990, volume 483 of Lecture Notes in Computer Science. Springer-Verlag, 1990. 13. Luqi. Software Evolution Through Rapid Prototyping. IEEE Transactions on Computers, pages 13{25, May 1989.
14. T. Murata. Petri nets: Properties, analysis and applications. Proc. of the IEEE, 77(4):541{580, April 1989. 15. H. Oswald, R. Esser, and R. Mattmann. An environment for specifying and executing hierarchical petri nets. In Proceedings of the 12th International Conference on Software Engineering, pages 164{172, 1990. 16. A. Perkusich, J.C.A. de Figueiredo, and S.K Chang. Embedding fault-tolerant properties in the design of complex systems. Journal of Systems and Software, 2(25):23{37, 1994. 17. W. Reisig. Petri Nets: An Introduction. Springer-Verlag, 1985. 18. W Reisig. Petri nets with individual tokens. Theoretical Computer Science, 41:185{213, 1985. 19. P Zave. An insider's evaluation of PAISLey. IEEE Transactions on Software Engineering, 17(3):212{225, March 1991. 20. T. Znati, Y. Deng, B. Field, and S.K. Chang. Multi-level speci cation and protocol design for distributed multimedia communication. In Procceedings of Conference on Organizational Computing Systems, pages 255{268, Atlanta, GA, USA, November 1991.
