A Petri net-based approach for supporting aspect-oriented modeling

(1)

RESEARCH ARTICLE

A Petri net-based approach for supporting aspect-oriented modeling

Lianwei GUAN (*), Xingyu LI, Hao HU, Jian LU

State Key Laboratory for Novel Software Technology, Nanjing University, Nanjing 210093, China Institute of Computer Software, Nanjing University, Nanjing 210093, China

E

Higher Education Press and Springer-Verlag 2008 Abstract The concept of aspect-orientation allows for modularizing crosscutting concerns as aspect modules.

Aspect-orientation originally emerged at the programming level, and has stretched over other development phases now. Among them aspect-oriented modeling (AOM) is a hot topic, and there are many approaches supporting it. Petri net is a good formalism which can provide the foundations for modeling software and simulating its execution, but fails to resolve the problem of crosscutting concerns to support AOM. So, this paper presents an approach which extends the Petri net so as to support the AOM. In this paper, the basic functions of the system are modeled as base net by Petri net, and the crosscutting concerns are modeled as aspect nets. In order to analyze the whole system, woven mechanism is proposed to compose the aspect nets and base net together. The problems about aspect- aspect conflict and conflict relations may exist among the aspect nets matching the shared join point, thus this paper propose solutions to resolve them. The Object Petri net which is an extension of traditional Petri net is also extended so as to support aspect-oriented modeling here.

Keywords Petri net, aspect oriented modeling, aspect- aspect conflict, shared join point, Object Petri net

1 Introduction

Aspect-oriented programming (AOP) [1] allows for modularizing crosscutting concerns as aspect modules. It is appealing to think these aspect modules as being independent or ‘‘orthogonal’’, but it is rarely the case in prac- tice [2,3]. When multiple aspect modules exist in the same system, problems such as mutual exclusions between

aspects, the importance of aspect ordering or conditional execution of an aspect by another aspect can occur [4].

The problems become more serious when many aspect modules match the shared join point (SJP) [5,6]. Among these aspect modules, there may exist conflict relations which might result from inaccuracies inherent in an aspect-oriented design. Resolving such inaccuracies at design time is cheaper, faster and more desirable than carrying out necessary code modifications later on-the- fly [7]. Aspect-oriented modeling (AOM) [8] is very important for aspect-oriented design, since the inaccuracies inherent in aspect-oriented design can be detected by the model, which can help the designers correct the software design, and modeling aspect-oriented software system at software design phase leading to a clear separa- tion of concerns and more maintainable, understandable and analyzable models.

However, most of the approaches supporting AOM are based on the Unified Modeling Language (UML), and lack of formal method based on Petri net. Petri net is a mathematically based technique for modeling and verifying software artifacts [9]. It provides clear and precise formal semantics, an intuitive graphical notation, and many techniques and tools for their analysis, simulation and execution. Petri net has been proposed for a wide variety of applications, such as modeling and analysis of distributed-software systems [10], software process [9,11]

and system behavior [12]. Unfortunately, Petri net fails to support aspect-oriented modeling. So, Xu et al. [13] incorporated the features of AOP into Petri net and extend Petri net to support AOM. However, the problems about the aspect nets composition at SJP and aspect-aspect conflict are not considered in their work. Thus, we propose a Petri net-based approach to support AOM and resolve the above problems.

In our approach, the aspect modules and the base modules are modeled by Petri nets as aspect nets and base net respectively. In order to fully understand or analyze a model with aspects, the aspect nets must be composed Received July 20, 2008; accepted October 14, 2008

E-mail: [email protected] DOI 10.1007/s11704-008-0041-8

(2)

with the base net, so we give a woven mechanism to compose aspect nets and base net into a woven net. During the process of weaving, there are order constraints and dependencies among the aspect nets that are imposed on the SJP. We give four composition mechanisms to represent the order constraints and dependencies, and compose these aspect nets equally as a new aspect net according to the composition mechanisms. The composition mechanisms are pretreatment methods to avoid the aspect-aspect conflict. When the aspect nets and base net are composed together, the new woven net can execute to simulate the execution of system. There may exist conflict relations among the aspects at SJP which results from the inaccuracies inherent in aspect-oriented design. The conflict relation can be detected by analyzing the structure of woven net, before moving on to implementation. Fig. 1 illustrates the idea of our approach which is implemented using the eXtensible Markup Language (XML) technology and Java programming.

Object Petri net (OPN) [14] is an extension of traditional Petri net, which can support Object-Oriented Modeling. They are composed of a System net and one or more Object nets which can be seen as token objects of the System net. The phenomenon of ‘‘crosscutting concern’’ exists among the Object nets of OPN. So we can model the crosscutting concerns of OPNs as aspect nets and extend OPN to support AOM. The idea is similar to the Petri net-based approach.

The rest of the paper is structured as follows: Section 2 first gives the basic definitions of Petri net, and then illustrates the Petri net using an example, lastly presents the Petri net-based approach for supporting aspect-oriented modeling. Section 3 first gives four composition mechanisms to model the order constraints and dependencies among these aspects that match the same join point, which are pretreatment methods to avoid the aspect- aspect conflict, finally presents a solution to find the conflict relation by detecting the structure of the woven net. A simple example is given to illustrate our approach in Section 4. The OPN-based approach to support aspect oriented modeling is introduced in Section 5. Section 6 gives the comparisons with related work. The paper finishes with conclusions and future works.

2 The Petri net-based approach

2.1 Introduction to Petri net

Petri net is firstly introduced by Carl Adam Petri in 1962 in his PhD, since then Petri net has developed into many dialects: such as Elementary nets, Place Transition nets, Predicate/Transition nets and Colored Petri nets. Our work is based on the Place Transition nets.

A Petri net consists of places, transitions, and arcs that connect them. In a graphical representation, places are drawn as circles, transitions as bars, and tokens as bullets.

The formal definition is as follows:

Definition 2.1 (Petri net) [9] A Petri net is a 3-tuple PN5 (P, T, F) where:

N

P is a finite set of places

N

T is a finite set of transitions, P> T 5 w

N

^F# (P 6 T) < (T 6 P) is a set of arcs (flow relation)

N

T h e p r e s e t o f a n o d e x[ P < T is defined as Nx 5 {y [ P < T|(y, x) [ F}

N

The postset of a node x[ P < T is defined as xN 5 {y [ P < T|(x, y) [ F}

Definition 2.2 (WF-net) [9] A Petri net PN5 (P, T, F) is a workflow net (WF-net) iff:

N

PN has two special places: i and o. Place i is a source place:Nx 5 1. Place o is a sink place: xN 5 1.

N

If we add a transition t* to PN so that Nt* 5 {o} and t*N 5 {i}, then the resulting Petri net is strongly con- nected.

In order to represent simply, we give a definition below:

Definition 2.3 (N.x) N.x means that x is an element of a set named N or a tuple named N.

For example, a Petri net named N, x[ P < T < F, here N.x means that x is a transition, place or arc of N.

2.2 An example of Petri net

In Ref. [15], Murata gave some typical interpretations of transitions and places. In this paper, a transition (an event) has a certain number of input and output places representing the pre-conditions and post-conditions of the event respectively. The presence of a token in a place is interpreted as holding the truth of the condition associated with the place. Based on above analysis, we can model a personnel management system by Petri net.

Some operations of the system are: the system manager first inputs the user name and password to login the system, then reads the salary of the personnel and increases someone’s salary, lastly the manager logouts. The system also consists of other operations which are omitted here.

Fig. 1 Process model for our approach

(3)

A sequence operations of the system are specified by the Petri net N1 in Fig. 2.

2.3 A Petri net-based approach for supporting aspect- oriented modeling

This Petri net-based approach is based on AOP [1] and Petri net. This approach also refers to the work of Xu [13].

AspectJ [16] adds to Java only a few new constructs:

pointcuts, advice, inter-type declarations and aspects.

Pointcuts and advice dynamically affect program flow, inter-type declarations statically affects a program’s class hierarchy, and aspects encapsulate pointcuts, advices, and inter-type declarations in a modular unit of crosscutting implementation.

A join point is a well-defined point in the program flow.

A pointcut picks out certain join points and values at those points. A piece of advice is code that is executed when a join point is reached. AspectJ has three kinds of advices: before advice, after advice and around advice.

Inter-type declarations are declarations that cut across classes and their hierarchies.

The entire aspect-oriented software at design level can be parted into two sections which are both modeled by Petri net. Our approach models the entire software as a base net and some aspect nets. Aspect net is an encapsu- lated entity of pointcuts, advice nets, inter-type declarations and models a separate crosscutting concern respect to the base net. In this model, join points are transitions of base net. A pointcut selects particular join points based on the defined criteria. For example, Pointcut tcut: BN.t13 in Fig. 3(b) defines a transition pointcut, which selects only one joint point named t13 of the base net BN in Fig. 3(a).

An advice for a pointcut specifies the operations to be applied to the join points that match the pointcut definition. An advice is represented by a section of a Petri net

called advice net. (BN.t13, BN.p13) defines that the property of the advice net is after type, which means where the advice net should be composed into base net is the place after the transition BN.t13, and (BN.p13, BN.t13) defines that the property of the advice net is before type. The important function of them is to define the accurate position where the advice net should be composed. They would be replaced by the advice net when using the woven mechanism. So, we call them position property.

If inter-type declarations declare members, which are used by advice, then we can treat the members as a part of advice net. If inter-type declarations change the inher- itance relationship between classes, then these declarations are not considered here, since it is difficult to model them by Petri net. Fig. 3(a) is the base net BN.

Fig. 3(b) illustrates the aspect net which defines a transition pointcut tcut, and an advice net VN is after type advice net for tcut. We can obtain a single woven net for the aspect-oriented model in Fig. 3 by composing the aspect net and the base net following the rules:

N

Compose the after type advice net of aspect net into the base net BN. This results in a new net WN.

N

We suppose that the number of arcs like (BN.t, BN.p) of position property definition is n, thus the advice net should be replicated n times. For each arc (BN.t, BN.p), operations should be done: the output arc of BN.t should point to the output place of tcut in advice net and the input arc(s) of pcut in advice net should point to BN.p.

N

Remove the first transition of the advice net and the transition’s output arc, and the last place of the advice net should be removed too.

Figure 4 shows the woven net for the Petri net-based model of Fig. 3. This example is also based on a personnel management system. Assume that a requirement in this scenario is to introduce a logging system for monitoring changes in salaries. This requirement is implemented by the aspect net MonitorSalary, which should be weaved into the base net. In the woven net WN, the transition t13 can be fired only after the transition t11 and t12 have already been fired, and the token must be in the place p12.

When the transition t13 is fired, the aspect net can be executed, which means the transition t21 can be fired.

Fig. 2 A Petri net for personnel management system

Fig. 3 Aspect-oriented Petri net-based model Fig. 4 Woven net

(4)

2.4 Formal definitions of Petri net-based approach In order to represent simply in this paper, the Petri net- based model is named as aspect-oriented Place Transition Net (AOPTN).

Definition 2.4 (AOPTN) An aspect-oriented Place Transition Net is a 2-tuple AOPTN5 (BN, ANs), where:

N

^BN5 (P, T, F) is a Petri net named as a base net.

N

^ANs^{5 (AN}¹^{, AN}²^{, …, AN}ⁿ⁾⁽ⁿ. 0), a finite set of aspect nets.

Definition 2.5 (aspect net) An aspect net is a 2-tuple AN5 (T cut, V Ns), where:

N

^{T cut}5 (N.t, …), N.t is a transition of base net N which is a join point here, and T cut is a pointcut including one or many join points.

N

^{V Ns}^{5 (V N}¹^{, V N}²^{), or V Ns}^{5 (V N}¹), a finite set of advice nets.

N

^{V N}^j5 (PT, pcut, Pj, Tj, Fj, arccut, tcut) or V Nj5 (TP, tcut, arccut, Pj, Tj, Fj, pcut)(j5 1, 2). The first one is before type advice net, and the other one is after type advice net. The number of one type advice net in V Ns can not exceed one. PT or TP named position property is a set of arcs. PT5 ((N.p, N.t), …) and TP 5 ((N.t, N.

p), …). N.t is a join point. N.p in PT is the input place of N.t and N.p in TP is the output place of N.t. Pj, Tjand Fj

are the notions of Petri net. pcut, arccut and tcut are symbols, whose functions are to define the type of advice net. arccut is the input arc of tcut in before type advice net, or the output arc of tcut in after type advice net.

Definition 2.6 (woven mechanism) The woven mechanism composes the base net and aspect nets into a woven net. AOPTN5 (BN, ANs), its woven net WN is a 3-tuple WN5 (P, T, F), whose initial values are: WN.P 5 BN.P, WN.T5 BN.T, WN.F 5 BN.F. In every aspect net ANi, for each advice net V Nj, and for each arc of the PT or TP of V Nj, the operations should be done following the rules:

N

^WN.P5 WN.P < ANs.ANi.V Nj.Pj

N

^WN.T5 WN.T < ANs.ANi.V Nj.Tj

N

^WN.F5 WN.F < ANs.ANi.V Nj.Fj

During the above operations, the elements that have identical names should be renamed. AOPTN is a medial production, and our analysis should be made on the woven net. Since woven net is a Petri net, some definitions [9] of Petri net also adapt to woven net.

Definition 2.7 (marking) The state (marking) of a Petri net is the distribution of tokens over places. Let M be a marking of net PN, p one of its places. M(p) is the number

of tokens in p at state M. Let p be a place and M a marking, M|p is such a marking that M|p(p)5 M(p) and M|p(q)5 0 for q ? p.

The behavior of many systems can be described in terms of system states and their changes. In order to simulate the dynamic behavior of a system, a state or marking in a Petri net is changed according to the following firing rules [9]:

Definition 2.8 (firing rule) [9]

N

A transition t is said to be enabled if each input place p of t contains at least one token.

N

An enabled transition may fire. If transition t fires, t consumes one token from each input place of t and produces one token for each out place p of t.

Given a Petri net PN5 (P, T, F) and a state M0, we get a Petri net system (PN, M0) (We also call (PN, M0) a Petri net for simplicity). We have the following definition:

Definition 2.9 (firing sequence) [9]

N

^M⁰^?^t ^M¹: transition t is enabled in state M0and firing t in M0results in state M1.

N

A firing sequence is described as s 5 t1t2…tn, if M₀?^t¹ M₁?^t² . . . ?^tⁿ M_n. A state Mnis called reachable from M0 (notion M0? Mn), if there exists a firing sequences 5 t1t2…tn, so that M0?^t¹ M1?^t² . . . ?^tⁿ Mn.

3 Modeling aspects composition at shared join point

3.1 Relations among aspects at shared joint point AOP gives the mechanism to weave the aspect modules to the base modules. Among the aspect modules and base modules, there may exist conflicts. Tessier [4] points out several different ways in which aspects and base modules can interfere with each other: crosscutting specifications, aspect-aspect conflicts, base-aspect conflicts, and concern-concern conflicts. The definition of aspect-aspect conflicts is: when multiple aspects exist in the same system, problems like mutual exclusions between aspects, the importance of aspect ordering or conditional execution of an aspect by another aspect can occur. So, when several aspect modules need to be superimposed on the same join point which is called shared join point [6], the execution order of the aspects and dependencies among them are more important.

In Ref. [6], Nagy listed three kinds of phenomenon at SJP.

1) Due to semantic interference, different execution orders among aspects at SJP may exhibit different behaviors.

(5)

N

No difference in the observable behavior. For example, consider two aspects where each does not refer to the effect of the other but solely main- tains its own state.

N

Different orders exhibit different behaviors.

2) The dependencies of aspects at SJP also should be considered, such as: the execution of an aspect depends on the outcome of other aspects. Only when the outcome of these aspects satisfies a certain criterion, the dependent aspect is allowed to execute.

3) There is another situation: the execution of one aspect may be skipped due to the result of the logical expression built up from the results of other condition.

Through the above analysis, we give four functions which can represent the relations between two aspects A and B at SJP: A||B, A||preB, A?^depB, A/orB.

A and B are aspects respectively. The first function means: it does not matter that which one should be executed first, they are equal; The second one means that B should be executed only after the execution of A, that is, B can never be executed until A has been executed. The third function means that the execution of B depends on the outcome of the execution of A, the execution of B may be canceled because the outcome of A does not fit the execution condition of B; The forth function means that one of them can be executed due to the logical expression built up from the results of other condition, that is to say that the execution of another aspect can be skipped.

Function A||B can be replaced by function A||preB or B||preA. Because aspect A and aspect B are independent, it does not matter which is executed first. During the execution of a system, the order of aspect A and aspect B should be made certain. So at design phase, we can make sure which aspect should be executed first. When encoun- tering the function A||B, we change their relation to A||_preB as a default. This conversion is propitious to analyze the structure of woven net and makes the structure of woven net simple.

Conclusion 3.1 (transitive) The relations ||preand?^depare both transitive. If two functions are presented here: A||preB and B||preC, so the function A||preC can be deduced. It is the same with the relation?^dep.

Proof. The function A||preB means that the aspect B should be executed after the the aspect A. It also means that the aspect B should use the outcome of aspect A, and there exists data dependency between the aspect A and B.

There are two functions presented here: A||preB and B||preC.

The outcome of aspect A is a set of data named Ao, which is the input of the aspect B. Aspect B performs some operations on the data Ao and outputs the set Bo. The relation between the input data and output data is: Bo5 F1(Ao).

The function F1 means the operations of aspect A. The

outcome of aspect B is the input of the aspect C. So, the relation can be described as: Co5 F2(Bo). From the functions Bo5 F1(Ao) and Co 5 F2(Bo), we can deduce that Co5 F2(F1(Ao)). So we can conclude that there exists data dependency between aspect A and C, which can be represented as A||preC. Thus, the relation ||preis transitive.

The proof process of relation ?^dep is similar with the proof process of relation ||pre.

Conclusion 3.2 (irreflexive) There exists no function similar to: A||preA or A?^depA. The relations ||pre and ?^dep are irreflexive.

Proof. The method of disproof is used here. Suppose that A||preA is right. When aspect A is executed at the first time, the input data set is Ai. The output is Ao, and Ao5 F (Ai), in which function F means the operations of aspect A. The output of aspect A is also the input of aspect A. So, Ai5 Ao. Then Ai 5 F(Ai). If the Ai 5 F(Ai) is right, then aspect A has no operation on the input data. This conclusion violates the precondition: F means the operations of aspect A. Thus, the relation ||preis irreflexive.

Conclusion 3.3 (anti-symmetric) The relation ||_preis anti- symmetric which means that the functions A||preB and B||preA cannot exist at the same time. It is the same with the relation?^dep.

Proof. The method of disproof is used here. Suppose that two functions A||preB and B||preA both exist at the same time. According to the Conclusion 3.1, we can deduce the function A||preA which violates the Conclusion 3.2. So the relation ||preis anti-symmetric.

Constraint 3.1 Given some aspects and their relation functions, each aspect should not appear on the left or on the right side among all the functions more than one time.

For example, given two relation functions A||preB and A?^depC, they do not obey the Constraint 3.1, because the aspect A appears twice on the left of the two relation functions. This constraint is to make the complexity of subsequent deduction under our control.

3.2 Compose aspect nets at SJP

In this paper, we model an aspect module as an aspect net.

When many aspect nets match the same transition join point, the transition is called shared join point. If there are many aspect nets at a shared join point, the aspect- aspect conflict may occur. So we give four composition mechanisms as a pretreatment method to avoid the conflict. The method is to compose these aspect nets as a new aspect net, then compose the new aspect net into the base net. The new aspect net should be semantically equal to

(6)

these aspect nets. Now the problem is how to compose these aspect nets as a new aspect net? Through our analysis, we found that the relation between two aspect nets can be converted to the structure of the Petri net, because the structures of Petri net contain parallel, sequence, choice and circulate which can model the four relations concerned above.

Now we give two aspect nets named AspectA and AspectB, which follows the definition in Fig. 5. BN.t13 is the shared join point. Composing aspect nets at the shared join point should follow the rules below:

1. Compose the aspect nets as one aspect net considering the execution order and the dependencies among the aspects following the composition mechanisms below.

2. Compose the new aspect net obtained from rule 1 into the base net resulting a new net following the rules in Section 2.3.

We present four composition mechanisms for composing two aspect nets at SJP as one aspect net.

1. AspectA and AspectB are equal, the order of the execution does not matter. The composition of AspectA and AspectB is shown in Fig. 6. The structure seems very complex, because it includes two new elements, null place and null transition. null does mean nothing, its function is only to make the structure of advice net according with the definition of Petri net.

2. The AspectA should be executed first, then the AspectB can be executed. In order to depict simply, we only display the advice net of the composed aspect nets in Fig. 7(a).

3. The execution of AspectB depends on the execution of AspectA. Here we only give out the advice net of the composed aspect nets in Fig. 7(b).

4. That only one of the two aspect nets can be executed depends on other conditions. The advice net for the composed aspect nets is illustrated in Fig. 7(c).

3.3 Detect the conflict relations

Given some aspects and their relations, the result function similar to A||preA or A?^depA may be deduced, which violates the Conclusion 3.2. Function A||preA or A?^depA means one aspect depends on itself through some aspect dependencies relations, so there must exist circular data dependency among the given aspects. Crosscutting concern is modularized as an aspect. Among the crosscutting concerns, there may exist data dependency. But the data dependency is in one direction. Circular data dependency means that these crosscutting concerns are so tightly coupled that they should be concerned as one crosscutting concern. This phenomenon can deemed as inaccuracies inherent in aspect-oriented design. The relations among the aspects at SJP are considered as conflict, and the definition of conflict relation is given here:

Definition 3.1 (conflict relation) Given some aspects and their relations, if the result function similar to A||preA or A?^depA can be deduced, thus these given relations are conflict.

Fig. 5 AspectA and AspectB nets

Fig. 6 One composed aspect net

Fig. 7 Three advice nets for composed aspect net

(7)

An example is given to interpret the conflict relation.

There are aspect A, B and C imposed on the same joint point. Their corresponding aspect nets are similar as Fig. 5. The relations among them are: A||preB, B||preC, and C||preA. According to the Conclusion 3.1, we can deduce that A?^depA, which violates the Conclusion 3.2.

So the dependencies relations are conflict.

According to the composition mechanisms, we can compose the three aspect nets A, B and C as a new aspect net in Fig. 8. The three aspect nets form a circular structure.

Circular structure in Petri net can describe the circular flow of data. So the circular data dependency among the aspects can be represented as a circular structure. If the circular structure exist in the woven net, but not in the base net, then the circular structure derives from the conflict relations among the aspects at SJP. So, we can detect the circular structure in the woven net to find the conflict relations.

The detective method to find the conflict relations in the woven net is:

1) Compute the firing sequence of the base nets0

2) Compute the firing sequence of the woven nets1

3) If there exists one sequencesi5 tt1…tit in thes1, but not in thes0, then we can conclude that there exist conflict relation.

4 One case for the conflict

This example is based on the personnel management system which has been used in Ref. [6]. The base program has been modeled by Petri net in Fig. 3(a).

Assume that the first requirement in this scenario is to introduce a logging system for monitoring changes in salaries. This requirement is implemented by the aspect MonitorSalary.

Assume that the second requirement in the scenario states that certain objects must store their state in a database. After each state change occurs in the corresponding objects, the database has to be updated as soon as possible. We consider persistence as a separate concern to be implemented as an aspect DBPersistence.

Assume that the next requirement in this scenario is to ensure that an employee’s salary cannot be higher than

his/her manager’s salary. Thus, a raise is not accepted if it violates this criterion. This is enforced by the aspect CheckRaise. Because the database needs to be updated as soon as possible after the state change occurs in the object, the advice of the aspect DBPersistence has to be executed before the advice of the aspect MonitorSalary.

Adding the aspect CheckRaise affects the composition; if this aspect fails, the DBPersistence aspect must not be executed because the employee’s data has not changed.

That is, the execution of the aspect DBPersistence depends on the outcome of the aspect CheckRaise.

According to the requirement, there are three aspect nets which all match the BN.t13 transition pointcut. BN.

t13 transition is the shared join point. The base net and MonitorSalary aspect are illustrated in Fig. 3. The CheckRaise aspect and DBPersistence aspect are illustrated respectively in Fig. 9. There are two relations among the three aspects, the first one is CheckRaise ?^dep DBPeresistence, and the other one is DBPersistence||pre

MonitorSalary. So, we firstly compose them into one aspect net, then compose the new aspect net into the base net. The new aspect net is shown in Fig. 10, and the new woven Petri net is shown in Fig. 11.

From the Fig. 11, we can obtain two firing sequences:

s15 t11t12t31t41t21t14 and s25 t11t12t31t941t21t14.

There are two transitions after place p41, and which transition can be fired depends on the outcome of t31. During Fig. 8 Circular structure formed by three aspect nets

Fig. 9 CheckRaise and DBPersistence nets

Fig. 10 Aspect net ComposedNet

(8)

the execution of the model, the token is first in the source place; when the execution is completed, the token will be in the sink place p14. There is no such a transition t that exists more than once in the firing sequence. So there is no conflict relation among the aspects, and the design of the aspects is right.

5 Application in Object Petri net

5.1 Introduction to Object Petri net

Object Petri net is an extension of traditional Petri net [14]. From the structure perspective, the Object Petri net includes two levels: System net and Object nets which are both Petri nets. There are interaction relation set between System net and Object net. The most important idea in the model of Object Petri net is ‘‘Petri nets as token objects’’, that is, viewing the tokens of System net as the references of Object nets [17]. There is a different definition of Object Petri net in Ref. [18], and in this paper we refer to Valk’s definition about the model of nets within nets [14]. The simplest paradigm of the model of nets within nets is Unary Elementary Object System (Unary EOS or UEOS). The idea of ‘‘nets within nets’’ can be expressed in the formal definition of EOS.

Definition 5.1 (EOS) [14] A unary elementary object system is a 3-tuple EOS5 (SN, ON, r):

N

^SN5 (P, T, W, M0) is an elementary net system with | M0|5 1, called System net of EOS.

N

^ON5 (B, E, F, m0) is an elementary net system, called Object net of EOS.

N

r # T 6 E is the interaction relation set between the transition sets of the two level nets. The interaction relation setr is used to describe synchronous relation between SN and ON.

The definition of EOS only contains one Object net, now we extend the definition of EOS to support one or more Object nets.

Definition 5.2 (OPN) An Object Petri net is a 3-tuple OPN5 (SN, ONs,r):

N

^SN5 (P, T, W) is WF-net, called System net of OPN. P is the set of places and T is the set of transitions.

W, (P 6 T) < (T 6 P), which is the set of arcs. There are two kinds of tokens. One kind token points to the Object nets, the other kind token is interpreted as holding the truth of the condition associated with one place.

N

^ON^s^{5 (ON}¹^{, ON}²^{, …,ON}ⁿ⁾⁽ⁿ. 1) is the finite set of Object nets. ONi5 (Bi, Ei, Fi) is a WF-net, called Object net of OPN. Fi, (Bi6 Ei)< Ei6 Bi).

N

r # T 6 E, E :5 < {Ei|1( i ( n}. r is the interaction relation set between the transition sets of the two level nets. The interaction relation setr is used to describe synchronous relation between SN and ONs.

In Fig. 12., there are two Object nets ON1and ON2at the bottom and a System net SN on the top. The interaction relationr is given by labels SinT at t and e if t_re(‘‘in’’

stands for interaction number n, which has no other meaning apart from specifying interacting transitions).

Now we give the definition of occurrence rules for OPN:

Definition 5.3 (Occurrence rules for OPN) The marking of Object Petri net OPN5 (SN, ONs,r) is a set(M, m1, …, mn), where M is the marking of the System net SN and mi

is a marking of the Object net ONi.

N

System-autonomous firing: A transition t[ T is activated in a marking (M, m1, …,mn) of OPN, ifr(t) 5 w and t is activated in M. Then the follower (M9, m91, …, m9n) is defined by M?^t M⁰ (w.r.t. SN) and m9i5 mi, written as

M, m1, . . . ,mn

ð Þ ?^½^t,^l M⁰, m⁰₁, . . . m⁰_n in the case.

N

Object-autonomous firing: ;i.1 ( i ( n, a transition ei[ Ei is activated in a marking (M, m1, …, mn) of OPN ifr(ei)5 w and ei is activated in mi. Then the Fig. 11 New woven Petri net

Fig. 12 An example of OPN

(9)

follower (M9, m91, m9n) is defined by m?^eⁱ m⁰ (w.r.t.

ONi), M5 M9, ;j ? i.1 ( j ( n, m9j5 mjwritten as M, m1, . . . , mn

ð Þ ?^½^l,eⁱ M⁰, m⁰₁, . . . , m⁰_n in this case.

N

Synchronous firing:mi.1 ( i ( n, a pair [t, ei][ T 6 Ei

is activated in a marking (M, m1, …, mn) of OPN if [t, ei][ r and t and e are activated in M and mi, respectively. Then the follower marking (M9, m91, …, m9n) is defined by M?^t M⁰ (w.r.t. SN), m_i?^eⁱ m⁰_i (w.r.t. ONi), and;j ? i.1 ( j ( n, m9j5 mjwritten as

M, m₁, . . . , mn

ð Þ ?^½^t,eⁱ M⁰, m⁰₁, . . . , m⁰_n in this case. Here, the l means empty occurrence sequence. The definition of r⁽t) and r(e): r(t) : 5 {e [ E|(t, e) [ r} and r(e) : 5 {t [ T|(t, e) [ r}.

According to definition of the occurrence rules, there is a firing sequence in Fig. 1 as an example: [t1,l], [t2, l], [t4, e11], [l, e21], [t5, e22], [l, e12], [l, e13], [l, e23].

In this definition for occurrence rule, the System-autonomous firing means the only actions of the System net, while the Object-autonomous firing means the only actions of the Object nets, which assigns the autonomous self-behaviors to the token objects. The Synchronous firing means the synchronous actions between the System net and the Object nets.

5.2 Extend Object Petri net to support aspect-oriented modeling

Object-oriented modeling means that software is designed as the interaction of discrete objects, incorporating both data structure and behavior [19].

OPN supports Object-oriented Modeling by Petri net [14]. They are composed of a System net and one or more Object nets which can be seen as token objects of the System net. Object and System-nets interact and syn- chronize via channels. The channels are denoted asr.

In the model of OPN, the discrete objects are modeled by the Object nets. The problem about ‘‘crosscutting concerns’’ exists in Object-orientation, thus it also exists in the formal approaches of Object-orientation modeling such as OPN.

The phenomenon of ‘‘crosscutting concern’’ is represented as a same section net contained by some Object nets. If a section net appears repeatedly in one Object net or some Object nets, we can take out the section net, and regard it as an aspect net, and the remained part as base net.

In Fig. 12, there are two Object nets. They both contain the transition called ‘‘log’’. The transition ‘‘log’’ can be regarded as the ‘‘crosscutting concern’’ in the OPN. We

can take out the section net containing the transition

‘‘log’’ as one aspect net in Fig. 13(b). The remained net is also an OPN called base net in Fig. 13(a).

The formal definition of aspect-oriented Object Petri net is as follows:

Definition 5.4 (AOOPN) An aspect-oriented Object Petri net is a 2-tuple AOOPN5 (BN, ANs), where:

N

^BN5 (SN, ONs, r) is an Object Petri net named as base net.

N

^ANs^{5 (AN}¹^{, AN}²^{, …, AN}ⁿ⁾⁽ⁿ. 0), it is a finite set of aspect nets.

The definitions of aspect net and woven mechanism are the same with the Petri net-based approach. The problems about aspect-aspect conflict and conflict relation also exist in the OPN-based approach, however, the solution remains unchanged.

6 Related works

Aspect-orientation has originally emerged at the programming level. Meanwhile, the application of the aspect-oriented paradigm is no longer restricted to the programming level but more and more stretches over phases prior to the implementation phase of the software development life cycle such as requirements engineering, analysis, and design [8]. In the context of this, aspect- oriented modeling languages attract more and more atten- tion. As a result, there has already been a number of AOM approaches proposed in literature.

Xu et al. [13] firstly incorporated the features of AOP into Petri net to support AOM and present a rigorous

Fig. 13 Aspect-oriented Object Petri net model

(10)

thread-driven approach for modeling and verifying secure software application using the Aspect-oriented Petri nets.

His work is based on Predicate/Transition nets (PrT nets).

However, the order constraints and dependencies among aspects at SJP aren’t considered in his work. Our work is based on Place Transition nets. In our paper, four composition mechanisms are given to model the order constraints and dependencies among the aspects at SJP, and an approach is given to detect the conflict relations.

Object Petri net is an extension of traditional Petri net [14],we also extend the Object Petri net to support aspect-oriented modeling.

Among the approaches for supporting AOM, most are based on UML. In Ref. [20], the design notation for AspectJ programs is presented based on the UML. It provides representations for all language constructs in AspectJ and specifies an UML implementation of AspectJ’s weaving mechanism. In Ref. [7], Lidia Fuentes et al. presented an aspect-oriented extension to the UML and its Action Semantics for the construction and execution of aspect-oriented models. Before executing such aspect-oriented models, they must be weaved. The idea of our approach looks like theirs, however their work didn’t consider the aspect-aspect conflict problem.

Aspect-aspect conflict is one hot topic in the aspect- oriented research areas. Douence et al. Ref. [2] propose a framework that allowed programmers to solve aspect inter- ferences by using a dedicated composition language. In Ref. [6], the authors propose a general and declarative model for defining constraints upon the possible composi- tions of aspects at a shared join point. In Ref. [5], a language-independent technique is presented to detect semantic conflicts among aspects that are superimposed on the same join point. The above approaches are all oper- ated at the programming phase. In this paper, aspect- aspect conflicts are considered at design phase and conflict relations among the aspects at SJP can be detected using the Petri net-based approach, which can avoid some aspect-aspect conflicts at programming phase in advance.

7 Conclusions

This paper presents a Petri net-based approach for supporting aspect-oriented modeling and the contributions of the work are:

1) A Petri net-based approach to support aspect- oriented modeling is given in this paper. In aspect- oriented software system, the whole system is modeled as aspect nets and base net by Petri net. In order to analyze the whole system, the woven mechanism is presented to compose the aspect nets and base net.

2) There are two kinds of conflicts considered in our paper. The first one is aspect-aspect conflict which

results from the competition of resource. When many aspect nets match the definition of the same SJP, the problems about the execution order and dependency become important. So, we give an avoid- ing method to pretreat the aspect-aspect conflict at SJP before using the woven mechanism.

3) The other conflict is conflict relation among the aspect nets at SJP, which results from the inaccuracies of the design. So we give a detective method to find the conflict in the structure of woven net after using the woven mechanism. Thus the inaccuracies inherent in aspect-oriented design can be detected using our approach, which can help the designers correct the software design.

4) Object Petri net is an extension of traditional Petri net, and we also extend the Object Petri net to support AOM.

There are some deficiencies in our work. This approach does not support the concept of aspect-oriented totally, for example: around type advice and static crosscutting are not considered in this paper. Liveness and safeness [9]

are important properties of Petri net, which are not used in our approach. The crosscutting concern is only considered in the level of model, not considered in the level of application areas. So much work will be done to extend and perfect the approach in future.

Acknowledgements This work was funded by the National Basic Research Program of China (973) (2002CB312002), the National High- T e c h R e s e a r c h a n d D e v e l o p m e n t P r o g r a m o f C h i n a ( 8 6 3 ) (2007AA01Z178, 2007AA01Z140 and 2006AA01Z159), Program for New Century Excellent Talents in University (NCET-07-0419), National Natural Science Foundation of China (Grant Nos.60403014, 60721002 and 60736015) and Jiangsu Natural Science Foundation (BK2006712).

References

1. Kiczales G, Lamping J, Mendhekar A et al. Aspect oriented programming. In: Proceedings of the European Conference on Object-Oriented Programming, Berlin: Springer, 1997, 220–

242

2. Douence R, Fradet P, Su¨dholt M. Composition, reuse and interaction analysis of stateful aspects. In: Proceedings of the 3rd International Conference on Aspect-Oriented Software Development, New York: ACM Press, 2004, 141–150 3. Havinga W, Nagy I, Bergmans L et al. A graph-based

approach to modeling and detecting composition conflicts related to introductions. In: Proceedings of the 6th International Conference on Aspect-Oriented Software Development, New York: ACM Press, 2007, 85–95

4. Tessier F, Badri L, Badri M. A model-based detection of conflicts between crosscutting concerns: towards a formal approach. In: Proceedings of the International Workshop on Aspect-Oriented Software Development, New York: ACM Press, 2004, 88–95

5. Durr P, Staijen T, Bergmans L et al. Reasoning about semantic conflicts between aspects. In: Proceedings of Workshop on

(11)

Aspects, Dependencies and Interactions (ADI), Berlin:

Springer, 2006, 10–18

6. Nagy I, Bergmans L, Aksit M. Composing aspects at shared join points. In: Proceedings of the International Conference NetObjectDays (NODe), Berlin: Springer, 2005, 19–38 7. Fuentes L, Sanchez P. Towards executable aspect-oriented

UML models. In: Proceedings of the 10th International Workshop on Aspect-Oriented Modeling. New York: ACM Press, 2007, 28–34

8. Schauerhuber A, Schwinger W, Kapsammer E et al. A survey on aspect-oriented modeling approaches. Technical Report, Vienna University of Technology, 2007

9. Wil M P van der Aalst. The application of Petri nets to workflow management. Journal of Circuits, Systems, and Computers, 1998, 8(1): 21–66

10. Azema P, Juanole G, Sanchis E et al. Specification and veri- fication of distributed systems using PROLOG interpreted Petri nets. In: Proceedings of the 7th International Conference on Software Engineering, Washington: IEEE Computer Society Press, 1984, 510–518

11. Huang L G, Boehm B, Hu H et al. Applying the value/Petri process to erp software development in China. In: Proceedings of the 28th International Conference on Software Engineering, Washington: IEEE Computer Society Press, 2006, 502–511 12. Balbo G, Bruell S C, Ghanta S. Combing queueing networks

and generalized stochastic Petri nets for the solution of complex models of system behavior. IEEE Transactions on Computers, 1988, 37(10): 1251–1268

13. Xu D X, Kendall E Nygard. Treat-driven modeling and veri- fication of secure software using aspect-oriented Petri nets.

IEEE Transactions on Software Engineering, 2006, 32(4):

265–278

14. Valk R. Petri nets as token objects: an introduction to elementary Object nets. In: Proceedings of the 19th International Conference on Application and Theory of Petri Nets (ICATPN), Berlin: Springer, 1998, 1–25

15. Murata T. Petri nets: properties, analysis and applications. In:

Proceedings of the IEEE, 1989, 77(4): 541–580

16. Colyer A, Clement A, Harley G et al. Eclipse aspectJ: aspect- oriented programming with aspectJ and the eclipse aspectJ development tools. USA: Addison Wesley, 2004, 110–221 17. Ge J D, Hu H Y, Lu P et al. Translation of nets within nets in

cross-organizational software process modeling. In:

Proceedings of the International Software Process Workshop (ISPW), USA: CSREA Press, 2005, 360–375

18. Lakos C. From coloured Petri nets to Object Petri nets. In:

Proceedings of the 16th International Conference on Application and Theory of Petri Nets (ICATPN), Lecture Notes in Computer Science, Vol 935, Berlin: Springer, 1995, 278–297

19. Rumbaugh J, Blaha M, Premerlani W et al. Object-oriented modeling and design. USA: Prentice-Hall, 1991, 1–500 20. Stein D, Hanenberg S, Unland R. A UML-based aspect-

oriented design notation for aspectJ. In: Proceedings of the 1st International Conference on Aspect-Oriented Software Development. New York: ACM Press, 2002, 106–112