HOONets: Hierarchical Object-Oriented Petri Nets for System Modeling and Analysis Jang Eui Hong and Doo-Hwan Bae
CS/TR-98-132 November 17, 1998
KAIST Department of Computer Science
1
HOONets: Hierarchical Object-Oriented Petri Nets for System Modeling and Analysis Jang Eui Hong and Doo-Hwan Bae Department of Computer Science Korea Advanced Institute of Science and Technology 373-1, Kusong-dong, Yusong-gu, Taejon 305-701, Korea fjehong,
[email protected]
Abstract
Petri nets is a very useful language to analyze and model system formally. Recently, many Petri nets mania devote their e orts to enhance and/or extend the expressive power of Petri nets. One of these e orts is to extend Petri nets with object-oriented concepts. Object-oriented paradigm provides very excellent concepts to model real-world problems. Object-oriented concepts can make us to build software system easily, intuitively, and naturaly. Several high-level Petri nets with the concepts of objects were suggested. These nets do not fully support the object-oriented concept, thus can not be called object-oriented Petri nets. Through our research, we propose a hierarchical object-oriented Petri nets, called HOONets (Hierarchical Object-Oriented Petri Nets). The formal syntax and semantics of HOONets are explained in detail. HOONets support wide range of object-oriented features including abstract, encapsulated and modularized object, object interaction by message passing, and inheritance and ploymorphism. HOONets also support a variety of analysis mechanisms such as decomposal, re ned and incremental approach to evolve system, unfolding the nets to lower level Petri nets, and incremental reachability analysis for HOONet models. In addition, we demonstrate the usefulness of HOONets with applying it to model and analyze with an example, and mention on the some areas which can gain the bene cial results by adoption of HOONets. Keywords: object-oriented Petri nets, software modeling, incremental analysis
1 Introduction The development of software systems starts with two main activities, requirements analysis and system modeling. The purposes of the requirements analysis in the development activities are to understand the problem throughly and reduce potential errors caused from ambiguous requirements, and the purpose of the system modeling is to depict the overall structure of a system by decomposing system into its logical components. Many researchers have focused their interests on the development of techniques to support the two activities[Thayer97]. There are two ways to achieve the purposes of those two activities. One is to specify and analyze systems formally, and the other is to describe and model systems naturally. When specifying, modeling, and analyzing the behavior of a critical and complex system, we choose a language which can formally depict the properties of the system. Formal languages support us to describe system properties clearly, exactly and in detail. Specially, Petri net is widely used than others in various application domains because of its simplicity, exibility to depict the dynamic system behaviors, and strong expressive and analytic power of system behaviors. Despite these powerful capability of formal methods, designer is still likely to recognize the shortage of formal methods when analyzing and modeling systems of various domains. Thus many Petri net researchers have devoted their e orts to enhance/extend the theory and the techniques on Petri nets [Baumgarten88, Brauer90, Brown92, Cardoso91, Fehling93, Vautherin87] including high-level Petri nets such as CPN(Colored Petri Nets) [Huber91, Jensen92, Pinci90]. 1
The concepts of object-oriented paradigm such as encapsulation, inheritance, and etc, have been widely used in the system modeling because they let us describe system easily, intuitively, and naturally [Eliens95, Eriksson98, Jacobson92, Rumbaugh91]. The designers who have formal appliance, became to understand the usefulness of the object concepts. Along with this trend, object-oriented formal methods also became one of interesting research issues for last several years, and many experts had suggested object-oriented formal methods such as OPN(Object Petri Nets), VDM++, Object-Z, etc[Bastide95, Harel96, Moldt95, Schuman97, Valk95]. Among them, the researches on the OPN methods have been actively studied to extend the Petri nets formalism to the object Petri nets such as OBJSA, LOOPN+, COOPN/2 [Battiston88, Lakos95, Biberstein94]. Although the results of such study have shown promising, these nets do not support fully all the major concepts of object-oriented paradigm. Detail comparisons are described in the next section. In this paper, we formally de ne HOONet(Hierarchical Object-Oriented Petri Net), which is a high-level Petri net supporting object-oriented concepts. The modeling features supported in HOONets are information hiding through the optimized interface, abstraction through abstract places, transitions and tokens, polymorphism through dynamic binding of abstract tokens, inheritance through properties sharing among classes, and interaction through message passing. We also propose two analysis methods of HOONet models - incremental reachability analysis for behavioral analysis, and unfolding of HOONets to lower-level Petri nets for structural analysis. We apply HOONets modeling and analysis methods to an example system in order to demonstrate its e ectiveness. The contributions of our work can be summarized in two: One is integration of object-oriented concepts into Petri net more rigorously than other such existing approaches, and the other is provision of incremental reachability analysis methods for HOONet models. This paper is organized as follows: In section 2, we brie y review some of the earlier proposals made for OPN and identify their shortcomings. In section 3, we justify a need for de ning HOONet by explaining the integration of Petri net formalism and object-oriented concepts which is required to accomplish our goal. We provide an informal and intuitive introduction to HOONet as well as formal de nitions and behavioral semantics. Section 4 describes a systematic procedure for modeling a system with HOONets, and explains the procedure through modeling an example system, car rental service system. In section 5, analysis techniques for ensuring the correctness of structural and behavioral properties in HOONet models are discussed. We provide the algorithms to generate a reachability graph of HOONets, and demonstrate the e ectiveness of them. Section 6 concludes our paper and suggests further research issues.
2 Related Work Attempting to incorporate Petri net formalisms into concepts of object-orientation, and vice versa, came into views as the OBJSA/CLOWN[Battiston88, Battiston93], LOOPN++[Lakos94, Lakos95], COOPN/2[Biberstein94, Biberstein96] and so on[Giese98, Lee93, Maier97, Perkusich97]. Although these nets have shown promising, they do not support fully all the major concepts of object-oriented paradigm. In this section, we consider and compare the characteristics of several high-level Perti nets in aspect of supporting object-oriented concepts.
2.1 OBJSA and CLOWN
OBJSA nets suggested by Battiston, are motivated to model together the data and control structure by adequately supporting abstraction in system modeling. This research is the rst attempt representing tokens by algebraic speci cation. OBJSA nets correspond to the semantics model described by algebraic notations, and CLOWN(CLass Orientation With Nets) is syntactic notations. The algebraic speci cation of objects in CLOWN consists of several phrases such that \attributes" and \methods" phrase written by algebraic notations, \partner" phrase representing the required external methods, \net" phrase depicting the control structure by Petri nets, and \inherit from" phrase describing which class is the superclass. These are shown in 1 with an example. 2
Class Printer inherit from Resource attributes type : TRADEMARK speed : REAL parter P has use methods get_printer :: get, releasr_printer :: release, print with P.use net create
leave available
unborn
dead release_printer
get_printer print reserved
used
Figure 1: Modeling example of \printer" in CLOWN Nets To depict the control structure for system behavior, CLOWN copies the net model of the superclass and adds it to the net model of its subclass for local behavior. However, such copying does not keep the concepts of object-orientation such as encapsulation and inheritance. Furthermore, it does not allow to rede ne the attributes and methods inherited from the superclass. Another problem is that it only uses the transition fusion to compose small nets into lager nets[Lakos97], and more severe de ciency is that the CLOWN does not support the notion of abstraction.
2.2 COOPN/2
Biberstein[Biberstein94, Biberstein96] suggests the speci cation language, called COOPN/2 (Concurrent Object-Oriented Petri Nets/2) which is designed to specify and model the large scale concurrent systems. The class de nition in COOPN/2 consists of two parts: \Signature" part is to describe the interface with other classes, and \Body" part is to describe the internal behaviors and operations of a class. The speci cation method of COOPN/2 is similar with that of CLOWN, but the di erences are that COOPN/2 supports abstracted data type in order to reuse its type de ned in other classes, and the method declared in \Signature" part is used as interface transition. Figure 2 is an example of COOPN/2 for counting of clock. Class Clock; Signature tick Use Time; Type clock; Methods gettime _: time; tick; true Body Use Bool; succ(t) true Places currenttime: {time}; tickcount: {bool}; t Transaction incr; tickcount incr Axioms gettime(t):: currenttime{t} -> currenttime{t}; create(n) tick:: -> tickcount{true}; incr:: tickcount{true}, currenttime{t} -> currenttime(succ(t)}; create:: -> currenttime{zero}; Where t: time; End Clock;
gettime(t) t t currenttime
n
Figure 2: An example of COOPN/2 for clock-count When each subnet of COOPN/2 is integrated, interface methods(transitions) play a role of links for the integration, and each link is associated with a label representing for synchronous mechanisms 3
such as concurrent, sequential, and conditional. However, Biberstein did not provide the unfolding mechanism of the link parts, so the analysis and simulation method of COOPN/2 is not clear. In spite of supporting inheritance and rede nition among classes, COOPN/2 does not support the abstraction notion.
2.3 LOOPN++
Lakos[Lakos94, Lakos95, Lakos97] proposes a class of object-oriented Petri nets, called LOOPN++(Language for Object-Oriented Petri Nets). LOOPN++ uses the text-based grammar to specify systems. In the speci cation of LOOPN++, the class de nition consists of three parts: \Fields" to de ne data, \Functions" to describe expression with parameters and operation, and \Actions" to represent the behaviors of a system. The \Fields" part is a declaration of a token in Petri nets, and is used to represent the states of places. The \Functions" and \Actions" part together represent the transitions of Petri nets. Figure 3, we show an example of LOOPN++ for increment of a number. The \Export" phrase in Figure 3 is to de ne the externally accessible objects. C’
Class C’ Export numbers; integer size()=count x where, V ar(t) is a set of variables appeared in the guard function G(t) and incoming arc expression of t, and Type(v) is a type of variable v. By the above de nition, a binding element is de ned as a pair (t; b), where t 2 T and b is a binding for t, and a set of all binding elements is denoted by BE. While, a token element is de ned as a pair(p; tt), where p 2 P and tt 2 TYPE(p), and the set of all token elements is denoted by TE. The meaning of TYPE(p) is a mapping of each place p to a set of token types (described in DD). To go forward the token movement, it must be decided which elements are selected in BE. This decision depends on step semantics. We adopt the nondeterministic step semantics. This semantics means that the bindings which rstly satis ed the condition to re t are selected, and other bindings are discarded. The token movement means the changes of the states of the system. That is to say, the change of the system states is to transfer the tokens from places to other places. The positioning of speci c tokens into places is called marking. For 8(p; tt) 2 TE , it is possible to give markings to p. Markings can be represented as functions de ned on P , and is notated as M (p). The M0 is an initial marking. The initial marking in HOONets is restricted to OIP and static places only because the internal behaviors of a class start from OIP. The static places such as data store should also have M0 because it is a place which should keep the tokens permanently, not consumed. Now we consider the formal de nition of enabling. The expression evaluation E (p; t) < b > yields the multi set of token values, which are removed from p when t occurs with the binding b. By taking the sum over all binding elements (t; b) included in step(denoted by Y ), we get all tokens that are removed from p when Y occurs. Intuitively, a transition t is said to be enabled when each input place p of t is marked with at least the same number of tokens de ned on the arc expression, and a set of tokens to be removed from each input place p, is obtained. De nition 3.6 A step Y is enabled in a marking M i the following property is satis ed: 8p 2 P : ( )2 E (p; t) < b > M (p) When a step is enabled and it may occur, this means that the tokens in the input places are removed and added to the output places of the ring transition. The number and types of those removed and added tokens are determined by the arc expressions and evaluated by the occurring of the bindings. De nition 3.7 The ring of a transition t means that the marking M1 in place p is changed to the marking M2 . This has the requirements as below: 8p 2 P : M2 (p) = (M1 (p) ? ( )2 E (p; t) < b >) + ( )2 E (t; p) < b > The rst sum, in the above de nition, is for removed tokens, while the second is for added tokens by the ring transition. The completion of a transition ring means the changes state of a system. The binding, step, enabling, and ring are invisible and indivisible events. Besides the above behavioral semantics, another behavioral constraint is caused by the changes of ag variables appeared in the de nitions of HOONet components. These behavioral properties are de ned and explained in the next section. As an additional de nition, x is the input to x, x is the output from x. This is formally de ned as x = fy 2 P [ T j(y; x) 2 Ag and x = fy 2 P [ T j(x; y) 2 Ag. t;b
t;b
Y
Y
t;b
3.3 Object-Oriented Representation with HOONets
Y
In this section, we formally de ne and explain to represent object-oriented concepts with HOONets, and these representations and concepts are useful in the modeling of object-oriented software systems. 10
3.3.1 Modularization and encapsulation
One design goal is to treat classes as \block boxes," whose external interface is public but whose internal details are hidden. Hiding internal information permits design(also including implementation) of a class to be changed without modifying its clients. Furthermore, additions and changes to the class are surrounded by " re walls" that limit the e ect of any changes so that changes can be understood clearly [Rumbaugh91, Eliens95]. A class is represented as a HOONet, and a HOONet consists of an OIP, a DD and an ION. DD is a declaration for attributes in a class, and ION depicts the internal behaviors of the class. These DD and ION are semantically encapsulated with an OIP. An OIP is a place having unique name for other all classes, and plays the role of public interface to external classes. The behavioral properties which can be occurred at OIP is de ned as follows:
De nition 3.8 The behavioral property at OIP: depending on the values of ag variables de ned as the constituent of OIPs, the behaviors of nets are controlled as follows: if state = \pre," 8t 2 OIP and 8v 2 V ar(t) : B (t). if state = \post," M (X ) for X such that X = OIP:pid:return; OIP:pid return; An example model of HOONets is shown in Figure 6. This example models the high-level behaviors of a server to perform the test(simple test or complex test) for psychological and physical status depending on patient's age and to display the grade(A, B, or C) as the result of the test.
Figure 6: An example for Client/Server using HOONets This example shows two HOONet models at level 1. The ABP \Csta" is an abstraction representing the psychological and physical status of patient. The COT \Sver" is to call the class \Sver" to perform the test. The \Csta", \simple" and \complex" are will be re ned in the modeling process of level 2. At the COT \Sver", the behavior of system is switched to the class \Sver", and the transition which satis es the guard condition between transitions of OIP is red. After the execution of a test, the test results will be returned to the COT \Sver". The places \cp3," \cp4" and \cp5" mean the states to represent the grades A, B and C of test results, respectively. Like shown in Figure 6, the functional behaviors of each class(HOONet) is modularized and encapsulated by an OIP.
11
3.3.2 Abstraction
Abstraction consists of focusing on the essential, inherent aspects of an entity and ignoring its accidental properties. In system design, this means focusing on what an object is and does, before deciding how it could be re ned into detail aspects. Use of abstraction gives the freedom to make decisions as late as possible by avoiding premature commitments to details [Rumbaugh91, Brauer90]. In HOONet models, the concept of abstraction is re ected into places, transitions, and tokens. The abstraction of these components is needed, as mentioned in Lakos's research[Lakos97], to maintain the symmetric structure and duality of nets. Conceptually, the ABP, ABT, and ATN(Abstract ToKen) are to represent the abstractions of object states, method behaviors, and token types, respectively. The property of abstraction and its re nement can be de ned with the morphism between nets. The morphism shows that the constraints of an abstraction are preserved in its re ned nets(RN ) [Desel90, Lakos97]. In HOONet models, the a sine qua non conditions of the morphism are sucient to show that the observable behaviors are equivalent between the abstract component and its re ned net. They can also show that the token types in abstraction is fully contained into the DD of RN. The Figure 7 shows the simple representation of the ABP, ABT and their re nements. Csta
sp1
simple
ss01 [gc1]
1’c
C
simple
[gc]
Csta Internal structures
1’c+1’s
Internal structures
1’(c,g)
sp3 [gc31]
Sver
(a) ABP "Csta" and its Refinment
[gc2]
[gc32]
(b) ABT "simple" and its Refinement
Figure 7: The representation of abstraction and its re nements When an ABP was re ned, the constraints which should be preserved in the re ned net are the token types, arc expressions of incoming and outgoing edges a ; a of the ABP. In case of ABT, the token types of input and output places, a ; a , and guard expressions are the constraints. The de nition on observable morphism in HOONet models is given as follows. De nition 3.9 The observable morphism, 8H 2 fABT; ABP; ATN g; H v RN should satisfy the requirements below (A v B means B is a re nement of A): for token of types ABP and ABT, p 2 ABP; TY PE (p) TT ; and t 2 ABT , fTY PE (t) [ TY PE (t)g TT , where TT is the set of all token types de ned in DD of RN. for all Sa ; a of ABP, all a of ABT, and all a of ABT , i o V ar(expr) V ar(OIP ) V , where V is the set of all variables de ned in DD of RN. for guard expressions of ABT, t 2 ABT; G(t) S8 i 2( RN ) G(t ). Abstraction and its re nement may us possible to model the system by incremental and hierarchical approach, and this is useful mechanism to reduce complexity in the process of analysis and design. The precise formal de nition on abstraction was given in [Lakos97]. It is not dicult to adapt the notion of the semantics to our HOONets. The behavioral properties of abstract components are constrained by the ag variable refine state. The properties are de ned as follows: De nition 3.10 The behavioral properties of ABP, ABT: Let R(action) be a function to perform the static reaction. The behaviors of abstract components controlled by the ag variable refine state are followings. i
i
o
o
RN
RN
RN
i
o
i
o
RN
a ;a
RN
RN
t
12
OI P
i
for all ABPs,
if refine state = true, M (OIP ) such that ABP:pn = OIP:oip. else, fR(action); 8t 2 ABP : B (t)g. for all ABTs, if refine state = true, M (OIP ) such that ABT:tn = OIP:oip. else, fR(action); +M (ABT ) ^ -M (ABT )g. The term, +M (ABT )^ -M (ABT ) means the addition of tokens to output place and deletion of tokens from input places by the ring of the ABT.
3.3.3 Inheritance
Inheritance is the sharing of attributes and operations among classes based on a hierarchical relationship. A class can be de ned broadly and then re ned into successively ner subclasses. Each subclass incorporates, or inherits, all of the properties of its superclass and adds its own unique properties. The properties of the superclass need not be repeatedly de ned in each subclass [Rumbaugh91, Eliens95]. The notation of inheritance in HOONets is shown in Figure 8. Figure 8 represents the inherited subclass from the class \Sver" in Figure 6. The symbol to express inheritance is : is also extended. An issue in inheritance mechanism is to override the properties of superclass with modi cation. The overriding features of subclass re ne and replace the overridden features of superclass. The reasons to override the features(methods) of superclass are to specify behavior that depends on the subclass, and to tighten the speci cation of a method. It should be determined which method is supposed to be binded between the overridden method and the overriding method because override rede nes a method with the same name and it does not permit to override the signature1, or form of a feature. This decision is achieved by scoping rule of the dynamic binding. The rule searches up the inheritance hierarchy to bind the method that implements a speci c operation in the object of subclass. De nition 3.11 An inheritance of properties from superclass satis s the following requirements. Let I, S, and N be an inherited subclass, a superclass, and the newly de ned and overriding methods, respectively. 1
signature in object-oriented concepts means the number and types of arguments, and the type of result value.
13
TT = TT [ TT , the set of enabled transitions, ET = ft j8t ; E (OIP ; t) < b >g [ ft j8t ; E (OIP ; t) < b >g, and for t 2 T ^ t 2 T , 9t ; t 2 ET 7! ((t ; b) 2 Y ^ (t ; b) 62 Y ). I
S
i
N
I
i
N
j
N
I
S
i
j
j
I
S
i
S
j
Modeling multiple inheritance with above de nition is also straight forward.
3.3.4 Dynamic binding
In terms of operation, dynamic binding may be regarded as a dispatching mechanism that acts like a case statement to dynamically select the appropriate behaviors in response to a value of token. In HOONet models, dynamic binding can occur when the variable refine state of ABP or ABT is true, or a COT calls the OIP of external class. A dynamic binding in abstract components is processed with two steps: at rst, the complex token type is decomposed into several detailed token types of OIP in re ned net, and then the token values in OIP are de ned with speci c values depending on the one of complex type. For example, in Figure 6, let the ABP \Csta" be a place to represent whether the psychological or physical status of a patient is normal or abnormal(i.e., TT CS = complex with normal j abnormal;). When the token value of CS is normal of patient's psychological status, the token type CS is decomposed into TT CS = record IntQ = EmoQ = Speh =
f
with [0..110] [111..130] [131..150]; [0..3] [4..7] [8..10]; trouble common fluent;
j
j
j
j
j
j
g
and the token value of each type are assigned to f(IntQ,[111..130]), (EmoQ,[4..7]), (Spek,common)g in the re ned net of the \Csta". But, in the case of the normal physical status of patient, the token type CS is decomposed into TT CS = record Weight BloodP PulseF
f
with = light average heavy; = low middle high; = low center high;
j j
j
j j
j
g
and, the token value are assigned to f(Weight,average), (BloodP,middle), (PulseF,center)g in the re ned net. Like this, a token type can be binded with di erent subtypes according to the value(at here, psychological or physical) of parametric variable. But we will recommend to avoid the use of this polymorphism for understandability of models.
3.3.5 Message passing
Message passing occurs when a class calls a method for object interaction. A method call causes the transferring of tokens from COT to OIP of the called class. There are two considering issues to support message passing mechanism.
synchronous or asynchronous method calls: The COT must receive the results from the execution of called methods in synchronous mechanism. So, the places of COT is not marked until
the result is returned. In this situation, the value of target is \yes". In asynchronous call, even though the token is transferred from COT to the OIP, the places of the COT should have markings. The asynchronous COT de ned passes the token to the OIP and COT both. The results of execution of the called method are stored in the global variable to be used by later operations. Nesting of method calls: It is possible to call the methods of other objects or of itself on the way of a method execution. We use the variable pid to nest method calls. When a COT calls a method, the variable pid is set with the process identi er indicating the instance of object 14
created by the method call, and return address. The size of the variable pid is proportionally increased whenever occurring the sequential calls. De nition 3.12 The behavioral properties of COT: the behaviors of COT depending on the values of ag variables are de ned as follows. for target = \true," if comm type = \SYNC" then fM (OIP ) such that COT:tn = OIP:oip; OIP:pid return; -M (COT )g. else fM (OIP ) such that COT:tn = OIP:oip; +M (COT ) ^ -M (COT )g.
for target = \false,"
if comm type = \SYNC" then fR(action); +M (COT ) ^ -M (COT )g. else +M (COT ) ^ -M (COT ). For more explanation in detail, the procedures to modeling an example system, are presented in the next section.
4 Modeling a System using HOONets 4.1 Steps of modeling and analysis
The overall process for the modeling and analysis of software systems using HOONets, is shown in Figure 9. These steps are based on the concepts of abstraction and decomposition(or re nements), and can be performed in an iterative and incremental way. User’s requirements
Decomposing user requirements HOONets
Analyzing the models
Complete models
No
Yes
Refining the models
Specifying and modeling the system
HOONet Models with abstractions
HOONet Models with refinements
System Design
Figure 9: The design process of system using HOONets To design a system using HOONets, at rst, we brie y decompose the requirements of the system, and specify the requirements by formal methods. In the early process of system modeling, we do not know exactly the detail information of the system. Thus, the rst speci cation of requirements will be described with HOONets including only the high-level and available information of the system. In the next step, the speci cation grows up to models of the system, and system models are re ned with the information gained from the previous works and the further analysis of requirements. There exists some feedbacks and adoptions of the design information between steps. After the completion of the system modeling, we analyze the correctness of the models and the behaviors of the system. Additionally, we note the fact that HOONet models can be analyzed and simulated modeling, not after the completion of modeling. The steps will be explained in detail in the following with an example. 15
4.2 Modeling with an example system
As an example, the simplied version of a car rental service(CRS) system is modeled.
4.2.1 Requirements of a CRS system
The initial requirements for a CRS system, are as follows: CRS system supports basic rental services, such as rental of cars, receiving the rented cars. To rent a car, customer should take out an insurance policy, and a rental agency checks the customer's credit is in good standing to rent a car. The mental and physical status of a customer(driver) must be normal one. The information on a customer consists of a name(identi er), the number of driving license, the number of a credit card, etc, and information on car includes an identi er, the type of a car, the states of a car, insurance fee, etc. When an accident occurs after the rental, the customer contacts the rental agency, not the insurance agency. When a car is returned by an accident, the rental agency sends the car to the insurance agency. When the car is returned from the insurance agency, it is assumed that the state of the car is fully recovered. Even though the rental period of a car is not expired, the customer involved in an accident should return the car, and should pay the designed fee by agreements. Other requirements comply with explanatory remarks.
4.2.2 Decomposing the requirements
Before formally writing the requirement speci cations, it is necessary to rearrange the information which take by the functional decomposition of requirements. The CRS system has representative entities such as \customer(CUST)," \rental agency(REAG)," and \insurance agency(INAG)". There are some interactions among them such as \rent a car," \take out an insurance," and so on. The table 2 shows the abstracted data and functions for each entity. Table 2: The high-level information of CRS system Entity Abstracted data CUST customer info. REAG car info., rental info. INAG insurance info.
Abstracted functions Request car, Operate car, Notice accident, Return car Lend car, Take insurance, Manage car, Receive car, Request repair Support insurance
The abstracted data and functions of each entity can be translated into the states and their changes of each entity. It is to represent a system with state-based Petri nets. For example, the function \Request car" is one of the customer's behaviors, and the previous and subsequent states of the behavior is determined by a set of the values of variables of which the abstracted data \customer info." is consisted. 1. Customer The state of a customer is divided into (1) Before rental, (2) Under rental, and (3) After return, and the state \Under rental" is also divided into (2.1) Normal operation and (2.2) Under accident, more precisely. 16
The change of states can be de ned with a tuple, < previous state; actions;
sequent state >. That is, the subsequent state is de ned by the action in which a speci c state.
No Previous state Actions Sequent state 1 Before rental request car Under rental 2 Under rental operate car Normal operation 3 Normal operation occurs accident Under accident 4 Normal operation normally return car After return 5 Under accident return car with accident After return
2. Rental Agency The high-level states of REAG are (1) Car lending and (2)Car receiving. The state (1) is divided into three states such as (1.1) Ready lend, (1.2) Lent car, and (1.3) Not lendable(impossible lending). Recursively, the state Lent car is divided into (1.2.1) Deliver car and (1.2.2) Take insurance. The state (2) divided into (2.1) Normal receiving and (2.2) Accident receiving, and for the state (2.2), it did into (2.2.1) Accept accident, (2.2.2) Before repair, and (2.2.3) After repair. The actions causing the state changes of a rental agency are \process the lend," \take out insurance," \process the return," and \process the accident". 3. Insurance Agency The INAG has the three states such as (1) Ready insurance, (2) Accept insurance, and (3) Expire insurance, and its actions are \grant insurance," \process insurance," and \perform repair".
4.2.3 Specify and model the system
1. High-level speci cation and modeling The requirements of the CRS system can be modeled in HOONets, as shown in Figure 10. At the level 0, the HOONet model contains three ABPs \CUST," \REAG," and \INAG," and an ABT \RENT AFFAIR". \CUST" is the re nement of the ABP "CUST" as shown in the right side of Figure 10. CRS
CUST 1’C
1’C 1’R
init
C1_t1
REAG
1’C
R
1’C
ReqCar 1’C C
1’R 1’C C
RENT_ AFFAIR
CUST 1’C
1’C
OpeCar C 1’I
1’C
1’C complete [gc]
1’I
1’C
INAG C1_t2
1’C
RENT_CP
1’C
I
AftRet C
1’C
level 0
level 1
Figure 10: The models of CRS system and the re ned "CUST" The re ned HOONet \CUST" has an ABP \OpeCar" which can be decomposed into the states of \normal operation", and \under accident". An ABT "RENT CP" can also be re ned 17
into the two abstracted behaviors, \request car" and \return car" in the customer's perspective. However, at the level 1, \RENT CP" can be replaced with two ABTs \RENT" and \RETURN" according to the intention of the designer. 2. Data dictionary Data dictionary(DD) is to declare the token types, variables, and functions. Additionally, it can also contain the internal actions of ABPs, ABTs and COTs, which are to de ne the static reaction. DD is a variant of CPN ML(or SML) in terms of its syntax and semantics[U-Aarhus96, Ullman98]. We have some types to declare as components of the net, that is a set of types = fprimitive, complicated, user de nedg. The primitive types are boolean, string, alphanumerics, integer, real, array, and so on, and the complicated types are a record type and a complex type. The record type means that several primitive types can be declared as a bundle type, and it can has record types to de ne the nested token structure. The complex type means having the undecided several types, therefore, the type is re ned into several types through dynamic binding. The symbol \+" in a type means the globally referenced type. The DDs of the HOONet \CRS" and \CUST" are as follows.
Level 0: Data Dictionary of "CRS" TT C = complex; TT R = complex; TT I = complex;
Level 1: Data Dictionary of "CUST" Var +CX = Boolean; /* rent or not */ TT C = record with CI = complex; CR = complex ; ABT(RENT CP) = Fun(CX == F): CX = T Fun(CX == T): CX = F ;
f
f
g
^ M (OpeCar; C ); ^ M (AftRet; C );
g
In DD, the token types in "CRS" were de ned with complex types. The token types of the ABP \CUST" were decomposed into re ned token types in the DD at level 1. The global variable \CX" means whether the customer rent a car or not. The internal `static reaction' of the ABT is to change the value of CX to true(T) and to mark the place OpeCar when the value of CX is false(F). 3. Detailed speci cation and modeling At level 1, the models for REAG and INAG can be also generated from the re nement of the model "CRS". The main activities of REAG are lending car and receiving car. The HOONet model for REAG is shown in the Figure 11. The DD of class REAG is similar with that of class CUST. The global variable \CX" is also used in this class. In the REAG class, the method starting from the transition R1 t10 is to represent the behavior of lending car to customer, and the method lead by the transition R1 t20 is for the receiving of car from the customer. The method for receiving a car can be also decomposed into the major two behaviors: normal receiving and receiving with accident. The re nement of this part is omitted. Here, the place \NotLen" represent the status in which the customer cannot rent a car at any reasons.
18
REAG 1’R
1’R R1_t10 1’R
[CX==F]
R1_t20
[CX==T]
1’R R
R BefLen
R
ReagDB
RecCar 1’R
1’R LENDING
RECEIVING
1’R 1’R
AftPro 1’R
R1_t12
CarRec R
R1_t13
R
1’R R
NotLen
[CX==F]
AftLen
1’R R1_t14
R1_t22
1’R [CX==F]
R1_t15
[CX==T]
level 1
Figure 11: The "REAG" model at level 1 The abstract places and transitions are re ned into more detail nets at level 2. We consider two re ned HOONets: the ABT \RENT CP" in the CUST and the ABT \LEADING" in REAG. The ABT \RENT CP" is an abstraction which consists of the behaviors such as rent[CX: F ! T] and return[CX: T ! F] car. As an additional note, among the customer's behaviors, \operate car" and \occurs accident" can be included into the ABP "OpeCar". The model of RENT CP is shown in Figure 12. The DD of this net is as follows.
Level 2: Data Dictionary of "RENT CP" Var +CA = Boolean; /* accident or not */ TT C = record with TT CI = record with c name = string; license = alphanumeric; credit = string ; TT CR = record with car type = alphanumeric; rent period = date ;
f
f
f
g
g
COT(REAG) = Fun( Fun( ;
g
g
f
sync == ``syn''): wait(CX == T); target == ``no''): display(\static reactions !!");
The class \LENDING" which is representing for car lending, is shown in Figure 13. The reasons for the customer cannot rent, are in the two cases: low credit of customer[GC = "Bad"] and unavailable car[(RI.car type == RV.Types) ^ (return date 6= null)]. The DD of this class is as follows. The Type RL is for the customer list of the rental agency, and RV is for the list of cars being held by the agency. The variables RI and RC are declared with the types used in the DD of the class CUST. 19
RENT _CP 1’C
1’C
c2_t10
[CX==F]
[CX==T]
c2_t20
C TryRet PreRen
1’C
1’C
[CA==F]
1’C
[CA==T]
c2_t21 1’C
REAG
c2_t22 1’C
1’C RetNor
RetAcc
PstRen
1’C 1’C
1’C REAG
REAG
[CX==T]
c2_t12 C
1’C
EndSer 1’C
[CX==F]
c2_t25 1’C level 2
Figure 12: The detail HOONet model of the ABT, \RENT CP"
Level 2: Data Dictionary of "LENDING" f
TT R = record with RI = CR; RL = complex; RV = complex ;
g
Var n = integer with 1..1000; /* number of customers */ Var m = integer with 1..100; /* number of cars */ TT RL = record array[1..n] with RC = CI; GC = with "Best"|"Good"|"Bad"| null ; /* grades of credits */ TT RV = record array[1..m] with types = alphanumeric; rent fee = integer; return date = date; car states = SC ;
f
f
g
g
In Figure 13, the place "ReagDB" is a static place containing the information on customer's credits[RL] and on the rental car[RV]. This place also can be represented to an ABP because it can contain the some actions such as retrieval, update, and delete the data. The OIP(LENDING) and ReagDB places are initially marked when the LENDING is instantiated. The other models for CRS system, remains not yet drawn. The class INAG for the insurance service agency at level 1, and the class for checking the current states of car at level 3, can be modeled by re nement. However, we omit these models since we believe that enough has been explained application of HOONets. When modeling a system with HOONets, we need not consider all together the complex and large information about the system because the steps are based on the re nement and incremental development. Also, the reachability analysis of models can be achieved by incremental way. This approach can help us to handle the complex and large software system, and to modify the models easily. 20
LEND -ING 1’R R2_t1
[CX==F]
R ReaLen
1’RL
if GC== Bad, 1’R
R2_t2 if GC== Best|Good, 1’R
GooCre
1’RL
1’R
if return_date =/= null, 1’R
ReagDB R
1’RV
R2_t3
1’RV
if return_date == null, 1’R
TakIns
RenTab
1’R
1’R R2_t4
INAG
[CX==T]
level 2
Figure 13: The detail HOONets models of Rent process
5 Analysis of the HOONet Models We suggest two schemes to analyze the HOONet models. One is static analysis which checks the structural properties of HOONet models by unfolding of nets. Such unfolding make it possible to clearly represent the global system structure[Perkusich97]. The other is dynamic analysis of behavioral properties depicted in HOONet models, which is achieved by performing reachability analysis for the dynamic properties of a system such as deadlock, liveness, and so on [Jensen92, Murata89, Peterson81].
5.1 Static analysis
The static analysis is performed by checking the structural properties of HOONet models without executing the model. To analyze of structural properties of HOONet models, the unfolding of HOONet components is required. The components which need to be unfolded are OIP, ABP, ABT, COT and ATN.
5.1.1 Unfolding of HOONet models Unfolding OIP OIP is a place with the role of class identi er and the entrance and exit of a class. The unfolding of a net which is encapsulated with OIP and its body frame of a class, is to prepare the separate door for the entrance and exit of nets. It can be easily achieved with duplicating the OIP as the exit after the removal of the body frame of HOONets, as shown in Figure 14.
Unfolding of ABP and ABT ABP and ABT are to represent the abstraction of nets corre-
sponding to high-level information of a system. The unfolding of ABP and ABT substitutes the abstraction components with re ned nets. To substitute the former with the latter, the unfolding for OIP of re ned nets should be preceded. The representation for unfoldings of ABP and ABT are shown in Figure 15 and 16. One issue in the unfolding of ABT is, as shown in Figure 16, splitting the abstract transition into two internal sub-transitions. The transition i AT 1 of the two acts as the invocation of the re ned net, and the transition o AT 1 is ending of the invocation. Therefore, the substitution ABT with re ned nets is the insertion of re ned nets between i AT 1 and o AT 1. 21
OIP
OIP
[g1]
[g1]
[g2]
p1
p2
p3
p4
[g2]
p1
p2
p3
p4
duplicated OIP
Figure 14: Unfolding OIP of HOONets
O1
T1
T1
AP1
AP1
AP1
AP1 pp11
pp12
T2
p2
1’a T3
pp11
1’b
pp12
AP1 T4 T2
HOONets with abstraction
Refined net of AP1
Unfolding of the ABP, AP1
Figure 15: Unfolding the HOONets with ABP
REAG
p1 p1
sp1
sp1
i_AT1
AT1
AT1 AT1
p2 rp1
rp1 p1
rp2
rp2
rp3
sp1
AT1
i_AT1 o_AT1
rp3
o_AT1
p2 HOONet "REAG" with abstraction
p2 Refined net of "AT1"
Unfolding of the ABT, AT1
Figure 16: Unfolding the HOONets with ABT 22
Unfolding of COT COT is a feature to provide a communicative method between classes. A
COT can call an OIP to execute a method, and after its execution the result is returned to the COT from the OIP. The communication mechanisms are classi ed into two categories, synchronous and asynchronous call. The unfolding of the synchronous COT starts with splitting the COT into o COT and i COT , and an arc is inserted from o COT to OIP of the called class, and from duplicated OIP to i COT , respectively. The Figure 17 shows the unfolding of COT. In Figure 17, the COT O1 is split to o O1 and i O1. O1 Unfolding of Synchronous COT
p1
[g2] [g1]
o_O1 i_O1
Internal Structure of HOONets
O1 [g2]
p2
[g1]
O1
p1
O1
Internal Structure of HOONets
O1 p1
p2
[g2] [g1]
o_O1 i_O1
Internal Structure of HOONets
p2
Unfolding of Asynchronous COT
O1
Figure 17: Unfolding the COT which represents the interaction Unfolding mechanism of asynchronous COT is a little di erent with that of synchronous COT. After bisecting the COT, an arc is inserted from o COT to the called OIP. The result from the execution of the called method, is preserved to use in the execution of later operation. This is shown in the below of right side in Figure 17.
Unfolding of ATN An abstract token can be represent by the values connoted with an abstract
states of the system. The unfolding of abstract token ATN is accomplished together with the re nement of ABP or ABT. We explained how to decompose the token of a complex type into its several subtypes in the section, 3.3.4. This decomposition is a just similar concept with unfolding of abstract tokens. For example, let \acc type" be a type to represent the extent of car accident. At the high-level models, the declaration of the type \acc type" will be de ned as follows: TT acc type = with waste | critical | smolder | trauma;
If a car consists of six components such as engine, shaft, gear, radiator, wheel, and hood, the token types to represent a fault of each component, in the low-level models, will be declared as follows: TT TT TT TT TT TT
Engine = with disable | damage | unimpact; Shaft = with broken | curved | abrasion | upright; Gear = with collapse | defect | operate; Radiator = with disrupt | fumes | normal; Wheel = with crook | flat tire | optimal; Hood = with bend | scratch | slick;
23
Here, we should consider the mechanism to unfold the abstract token value in high-level models into the token value in low-level models. Therefore, the unfolding function of ATN should be declared in DD of the low-level model as follows: ATN(waste) = record with
fengine
= TT Engine with disable; shaft = TT Shaft with broken | curved; gear = TT Gear with collapse; radiator = TT Radiator; wheel = TT Wheel; hood = TT Hood; ;
g
ATN(trauma) = record with
fengine
= TT Engine with unimpact; shaft = TT Shaft with upright; gear = TT Gear with operate; radiator = TT Radiator with normal; wheel = TT Wheel with flat tire | optimal; hood = TT Hood; ;
g
As described in the above example, the abstract tokens are de ned with all variables which are declared in the lower model. The decomposed values of the abstract token can have the partially overlapped values of the variables, but the value of each token is unique. Also, it can be represented the abstract token type with the disjoint range of value - e.g., the degree of temperature, pressure, and so on.
5.1.2 Analysis of structural properties
After these unfolding of nets, the syntactic errors of HOONets will be checked. The syntactic checks are performed by investigating connectivity of places and transitions. If each place(transition) does not have input and output transition(place), the place or transition can be considered as and syntactic error - except initiator and terminator. Since the primitive components of HOONets did keep the syntax and semantics of CPN without variation, the analysis techniques of CPN are used in our analysis method.
5.2 Dynamic analysis
Dynamic analysis is performed by executing the system model for checking anomalies related with system behaviors. In the HOONet models, this analysis can be performed using reachability graph which involves essentially the enumeration of all reachable marking, and this enumeration is appeared to reachability graph(or tree).
5.2.1 Incremental generation of reachability graph
In our method, we suggest the incremental reachability analysis to alleviate this problem. The suggested method is very simple and natural because after the accomplishment of properties analysis for the reachability graph of each class, each graph is composed into a global graph. This means that we can analysis the models with the information which does not described in the requirements of the system, and/or does not yet fully analyzed. This analysis is possible since the interface of each class(or net) is limited to OIP only, that is, each model has one entry and one exit to interact with others. For example, if the ABT \RENT CP" was re ned after generating the reachability graph of the class \CUST" in Figure 10, the global reachability graph is expanded to analyze for all given models 24
10000 00000
c2_t10
c2_t20
01000 00000
00100 00000 c2_t21
o_COT(1) 00010 00000
c2_t22
00001 00000
i_COT(1)
00000 10000
00000 01000
10000
o_COT(3)
o_COT(2) 00000 00100
c1_t1
00000 00010
01000
i_COT(3)
i_COT(2)
i_ABT(1) 00000 00001
c2_t12 10000 00000
00100
c2_t25
i_ABT(2) o_ABT(1)
c2_t10
Reachability graph of the RENT_CP
10000 00000
c2_t20
00001 01000 00000
c1_t2 10000
10000
c1_t1
00100 00000 c2_t21
o_COT(1) 00010 00000
01000
i_COT(1)
i_ABT(1)
c2_t22
00001 00000
o_COT(3)
o_COT(2)
00000 01000
00100
00000 00100
i_ABT(2) o_ABT(1)
00001
00000 00001
c2_t12
o_ABT(2) o_ABT(2)
c1_t2
00000 00010 i_COT(3)
i_COT(2)
00010
00000 10000
10000 00000
c2_t25
10000 Reachability graph of the CUST with the refined RECT_CP
Reachability graph of the CUST
Figure 18: Composition of reachability graph including the re ned net. In Figure 18, it is shown that the reachability graph of the \RENT CP" was generated and analyzed, and the graph is composed into the global graph. Our HOONets has some di erent features with other high-level nets. The algorithm to generate a reachability graph, should re ect the characteristics of these features, and described in Algorithm 5.1. To help understand the algorithm, some de nitions are preceded;
Waiting is a set of nodes, which contains those nodes for which we have not yet found the
successors. Node(M) is a procedure that creates a new node M, and adds M to the set of Waiting. If M is already a node, the procedure has no e ect. Next(M1) is to denote a set of all possible "next moves" from a marking M1 . i.e., Next(M1 ) = f(b; M2) 2 BE MjM1 [b > M2 g. Arc(M1 ; b; M2) creates a new arc with the source M1 and the destination M2 . GenNode(M1; M2 ) is a procedure that create a node and connect the node to reachability graph. begin Node(M2 ); Arc(M1; b; M2 ); Waiting := Waiting - fM2 g; end.
AllGen(M1; M2 ) is a procedure that performs the following. 25
begin for all (b, M2 ) 2 Next(M1 ) do GenNode(M1 ; M2 ); end. As an additional note, if the source of a node is an element among ABP, ABT and COT, the node should be considered as two nodes because they are having the two states which are the initial state and the post state of the primitive actions of the elements.
Algorithm 5.1 Reachability Graph(Nets, Graph) ?
Waiting := ; Node( 0 ); repeat select a node Waiting; 1 Case 1 on OIP: if ( == "pre") AllGen( 1 2 ); break ; else if ( == "self") End of Algorithm; else 2 := OIP.pid.return; OIP.pid return; GenNode( 1 2 ); break ; PIP: AllGen( 1 2 ); break ; ABP or ABT: if (not yet refined) AllGen( 1 2 ); break ; else OIP.pid return; 2 := refined OIP; GenNode( 1 2 ); break ; COT: if (not yet refined) do(static reactions) or wait(user's response); AllGen( 1 2 ); break ; else if (synchronous call) OIP.pid return; 2 := refined OIP; GenNode( 1 2 ); break ; else AllGen( 1 2) 2 := refined OIP; GenNode( 1 2 ); break ; ; until Waiting = ; End of Algorithm.
M
M 2
M
f
status pid fM
f
M ;M
g
M ;M
f
g
f
M
g
M ;M
g
M ;M
M ;M
g
f
g
M
g
f
M ;M
f
M ;M
M ;M
k fM
g
g ?
M ;M
The reachability graph for HOONet models is incrementally generated depending on the type of places and transitions. As explanatory notes about the algorithm 5.1, if the class called from COT, was not modeled, the prede ned static reactions at the COT is executed, or the progress of analysis is halt to accept user's response. In the case of asynchronous COT, the path in the graph branch o by performing parallel operations. One of key issues in our analysis methods, is consolidation of two reachability graphs into one. Let \SetABC" be a set of all ABPs, ABTs and COTs in the models, and M be the preceding state of an element abc in the given reachability graph. The consolidation steps are shown below in Algorithm 5.2. Algorithm 5.2 Consolidation of two reachability graphs. 1. select an component abc 2 SetABC . 2. using the algorithm 5.1, generate the reachability graph corresppnding to the re ned model of the abc . 3. inserts the reachability graph at the next location of the M . i
i
i
i
i
26
5.2.2 Analysis of behavioral properties
Our incremental method is very useful in the design and analysis of complex and large scale systems because it is possible to generate the reachability graph for the only interesting models. For instance, it is possible to analyze the models without considering the insurance service in our example system \CRS". And we can analyze several dynamic properties such as deadlock freeness, liveness, fairness and so on using reachability graph[Jensen92, Murata89].
Deadlock check In the reachability graph, deadlock can be checked by dead marking which has
no enabled transitions. The ring sequence from the initial marking to dead marking represents that a behavior of system reached to the deadlock status.
Liveness check Since every transition should be red at least once, every transition in the
HOONet models should appear in their reachability graph. Trnasitions not appeared in the graph can not be red. A system model should not have these dead transition.
Fairness check Two trnasitions are said to be fair relation if the maximum number of times that either one can re while other is not ring is bounded. This means that the system model does not have the in nite loop of a behavior. Thus, all generated reachability graph are fair. Nondeterminism check Nondeterminism between transitions can be checked using the reachability graph and the structural analysis. When transitions being in con ict, where they have same input place, are enabled at a reachable marking, a nondeterministic choice occurs. Nondeterminism check is performed by searching two enabled transitions being in con ict for all reachable marking in the reachability graph.
References [Ajroud98] H.B. Ajroud and A. Jaoua \Abstraction of objects by conceptual clustering," International Journal of Information Sciences, Vol. 109, 1998, pp.79-94 [Alberti95] M.A. Alberti, P. Evi, and D. Marini, "Modeling Geometric Objects with OBJSA Nets," Proceeding of the Int'l Workshop on Object-Oriented Programming and Models of Concurrency, Turin, Italy, June, 1995 http://wrcm.dsi.unimi.it/PetriLab/ws95/home.html [Bachatene95] H. Bachatene and M. Coriat, "PAM: a Petri net-based Abstract Machine to the Speci cation of Concurrent System," Proceeding of the Int'l Workshop on Object-Oriented Programming and Models of Concurrency, Turin, Italy, June, 1995 http://wrcm.dsi.unimi.it/PetriLab/ws95/home.html [Bastide95] R. Bastide, "Approaches in unifying Petri Nets and the Object-Oriented approach," Proceeding of the Int'l Workshop on Object-Oriented Programming and Models of Concurrency, Turin, Italy, June, 1995 http://wrcm.dsi.unimi.it/PetriLab/ws95/home.html [Battiston88] E. Basttistone, F.D.Cindio, and G. Mauri, "OBJSA Nets: a class of high-level nets having objects as domains," APN'88, and also LNCS 340, 1988, pp.20-43 [Battiston93] E. Battiston and F.D. Cindio, "Class Orientation and Inheritance in Modular Algebraic Nets," Proceedings of IEEE Conference on System, Man, and Cybernetics, Vol.2, pp.712-723, October, 1993 [Baumgarten88] B. Baumgarten, "On Internal and External Characterisations of PT-Net Building Block Behavior," APN88, and also LNCS 340, 1988, pp.44-61 27
[Beringer97] D. Beringer, "Modeling Global Behavior with Scenarios in Object-Oriented Analysis," Ph.D Thesis, Ecole Polytechnique Federal de Lausanne, Department dInformatique, Switzerland, May 1997. [Biberstein94] O. Biberstein and D. Buchs, "An Object-Oriented Speci cation Language based on Hierarchical Algebraic Petri Nets," Proceedings of the IS-CORE Workshop, Amsterdam, September, 1994 and TR: EPFL-DI 94-76, 1994 [Biberstein96] O. Biberstein, D. Buchs, and N. Guel , "Modeling of Cooperative Editors Using COOPN/2," Proceeding of the Int'l Workshop on Object-Oriented Programming and Models of Concurrency, Osaka, Japan, June, 1996 [Brauer90] W. Brauer, R. Gold, and W. Vogler, "A Survey of Behaviour and Equivalence Preserving Re nement of Petri Nets," APN'90, and also in LNCS 483, pp.1-46 [Brown92] C. Brown and D. Gurr, "Re nement and Simulation of Nets: a categorical characterisation," ATPN'92, and also LNCS 616, 1992, pp.76-92 [Buchs93] D, Buchs, F. Mourlin and L. Safavi, "COOPN for specifying a distributed termination detection system," Software Engineering for Parallel System, Vol. 3, Sept., 1993 [Cardoso91] J. Cardoso, R. Valette, and D. Dubios, "Petri Nets with Uncertain Markings," APN'90, and also LNCS 483, 1991, pp.64-78 [Desel90] J. Desel and A. Merceron, "Vicinity Respecting Net Morphism," APN'90, and also LNCS 483, 1991 [Eliens95] A. Eliens, Principles of Object-Oriented Software Development, Addison-Wesley, 1995 [Eriksson98] H. Eriksson and M. Penker, UML Toolkit, Wiley Computer Publishing, 1998 [Fehling93] R. Fehling, "A Concept of Hierarchical Petri Nets with Building Blocks," APN'93, and also LNCS 674, 1993, pp.148-168 [Giese98] H. Giese, J. Graf and G. Wirtz, "Modeling Distributed Software Systems with Object Coordination Nets," Proceedings for the Int'l Symposium on Software Engineering for Parallel and Distributed Systems, Japan, April, 1998, pp.39-49 [Harel96] D. Harel and E. Gery, "Executable Object Modeling with Statechart," Proceedings of the 18th Int'l Conference on Software Engineering, Germany, March, 1996, pp.246-257 [Hinchey95] M.G. Hinchey and J.P. Bowen, Applictions of Formal Methods, Prentice-Hall Inc., 1995 [Holvoet95a] T. Holvoet and P. Verbaeten, "PN-TOX: a Paradigm and Development Environment for Object Concurrency Speci cation," Proceeding of the Int'l Workshop on Object-Oriented Programming and Models of Concurrency, Turin, Italy, June, 1995 http://wrcm.dsi.unimi.it/PetriLab/ws95/home.html [Holvoet95b] T. Holvoet and P. Verbaeten, "Petri Charts: an Alternative Technique for Hierarchical Net Construction," Proceedings of IEEE Conference on System, Man, and Cybernetics, October, 1995 [Huber91] P. Huber, K. Jensen, and R.M. Shapiro, "Hierarchies in Coloured Petri nets," APN'90, and also LNCS 483, 1991, pp.313-341 [Jacobson92] I. Jacobson, et al., Object-Oriented Software Engineering: A Use Case Driven Approach Addison-Wesley Publishing Company, 1992 [Jensen92] K. Jensen, Coloured Petri Nets: Basic concepts, Analysis methods, and Practical use, Vol 1. 2., Springer-Verlag, 1992 28
[Lakos94] C. Lakos and C. Keen, "LOOPN++: A New Language for Object-Oriented Perti Nets," Technical Report R94-4, Networking Research Group, Univesity of Tasmania, Australia, April, 1994 [Lakos95] C. Lakos, "The Object Orientation of Object Petri Nets," Proceeding of the Int'l workshop on Object-Oriented and Models of Concurrency, Turin, Italy, June, 1995. (within the 16th Int'l conference on ATPN 95) [Lakos97] C. Lakos, "On the Abstraction of Coloured Petri Nets," Proceedings of Petri Net Conference 97, Touloure, France, 1997 [Lee93] Y.K Lee and S.J. Park, \OPNets: An Object-Oriented High-Level Petri Net Model for Real-Time System Modeling", Journal of Systems Software, Vol(20), 1993. pp.69-86 [Lee98] N.H. Lee, J.E. Hong, S.D. Cha, and D.H. Bae, "Towards Reusable Colored Petri Nets", Proceedings of Int'l Symposium on Software Engineering for Parallel and Distributed Systems, Kyoto, Japan, April, 1998. pp.223-229 [Maier97] C. Maier and D. Moldt, "Object Colored Petri Nets- a Formal Technique for Object Oriented Modeling," Proceedings for the Workshop on the Petri nets in System Engineering, Modeling, Veri cation and Validation, Germany, Sept., 1997 [Moldt95] D. Moldt, "OOA and Petri Nets for System Speci cation," Proceeding of the Int'l Workshop on Object-Oriented Programming and Models of Concurrency, Turin, Italy, June, 1995 http://wrcm.dsi.unimi.it/PetriLab/ws95/home.html [Murata89] T, Murata, "Petri Nets: Properties, Analysis and Applications," Proceddings of the IEEE, Vol.77, No.4, April 1989. pp.541-580 [Perkusich97] A. Perkusich and J.C.A. Figueiredo, "G-Nets: a Petri Net Based Approach for Logical and Timing Analysis of Complex Software Systems," Journal of Systems and Software, Vol(39), 1997, pp.39-59 [Peterson81] J. Peterson, Petri Net Theory and the Modeling of Systems Prentice-Hall Inc., 1981 [Pinci90] V. Pinci and R. Shapiro, "An Integrated software development methodology based on hierarchical colored Petri nets," Proceeding of the 11th Int'l Conference on ATPN, Paris, June 1990 [Regnell96] B. Regnell, et al, "A Hierarchical Use Case Model with Graphical Representation," Proceedings of the Int'l Symposium and Workshop of ECBS96, Germany, March 1996, pp.270277 [Reisig85] W. Reisig, PETRI NETS: An Introdunction, Springer-Verlag, 1985. [Rumbaugh91] J. Rumbaugh, et al, Object-Oriented Modeling and Design, Prentice Hall, 1991. [Schuman97] S.A. Schuman, Formal Object-Oriented Development, Springer-Verlag, 1997 [Some96] S. Some and R. Dssouli, "An Enhancement of Timed Automata Generation from Timed Scenarios using Grouped States," Technical Report 1029, University of Montreal, Canada, April 1996. [Thayer97] R.H. Thayer and M. Dortman, Software Requirement Engineering, IEEE Computer Society Press, 1997 [U-Aarhus96] Design/CPN, Overview of CPN ML Syntax, version 3.0, University of Aarhus, Denmark, 1996 [Ullman98] J.D. Ullman, Elements of ML Programming, Prentice-Hall Inc., 1998 29
[Valk95] R. Valk, "Petri Nets as Dynamical Objects," Proceeding of the Int'l Workshop on Object-Oriented Programming and Models of Concurrency, Turin, Italy, June, 1995 http://wrcm.dsi.unimi.it/PetriLab/ws95/home.html [Vautherin87] J. Vautherin, "Parallel Systems Speci cations with Coloured Petri Nets and Algebraic Speci cations," APN'87, and also LNCS 266, 1987, pp.293-308
30
