Expert in conflicts

Expert Systems with Applications 36 (2009) 5630–5642

Contents lists available at ScienceDirect

Expert Systems with Applications

journal homepage: www.elsevier .com/locate /eswa

Expert in conflicts

Sandra I. Casas a,*, J. Baltasar Garcı́a Perez-Schofield b, Claudia A. Marcos c

a Unidad Académica Rı́o Gallegos, Universidad Nacional de la Patagonia Austral, Lis de la Torre 1060, Sta Cruz, Rı́o Gallegos 9400, Argentinab Departamento de Informática, Universidad de Vigo, Orense 32004, Spainc Instituto de Sistemas de Tandil, Universidad Nacional del Centro, Tandil 7000, Argentina

a r t i c l e i n f o

Keywords:
Expert systemsAspect-oriented programmingAspects conflictsAspect weavingAspectJ
0957-4174/$ - see front matter � 2008 Elsevier Ltd. Adoi:10.1016/j.eswa.2008.06.094

* Corresponding author.E-mail addresses: [email protected] (S.I. Casas),

Garcı́a Perez-Schofield), [email protected] (

a b s t r a c t

Aspect-oriented programming (AOP) is an emergent technology for the modularization of crosscuttingconcerns. The most used approach to support the AOP paradigm is based on the aspect notion, as thebasic unit that contains the crosscutting concern logic and a method (pointcuts, advice, and join-points) that relates it to the functional components. This mechanism, popularized by tools likeAspectJ, restricts and limits the handling of conflicts among aspects. In this work, a flexible, wideand powerful approach is presented. This strategy is based on two main mechanisms: definition ofassociations and symbolic rules. An expert embedded system detects and solves conflicts automati-cally. The approach presented is implemented in a prototype denominated MEDIATOR.

� 2008 Elsevier Ltd. All rights reserved.

1. Introduction

Aspect-oriented programming (Kiczales et al., 1997) providesimplementation support for separation of concerns (SoC) (Dijk-stra, 1976; Hursch & Lopes, 1995). The crosscutting concernsare encapsulated in isolated and separate units of code denomi-nated aspects. After aspects codification, a weaving process inte-grates the aspects with the components of basic functionality,generating the final application (Piveta & Zancanella, 2003). Anaspect is a unit of code and it is composed of different construc-tions such as methods, attributes, introductions, declarations,pointcuts, advice. The pointcuts give sense to the aspects, sincethey declare the link among aspects and components of basicfunctionality. Most of the AOP tools are extensions of conven-tional languages. These extensions incorporate mechanisms toimplement the aspects and add constructs that describe thesemantics and the behaviour of aspects. Although the devicecharacteristic varies among these tools, their purpose is essen-tially the same. This model has been imposed by AspectJ (Kicz-ales et al., 2001), the most diffused, popular and used AOPtool. The AspectJ model has also been replicated by many otherAOP tools (Hirschfeld, 2001; phpAspect, 2007; AspectC, 2007;AspectJ, 2007).

In aspect-oriented applications, the same component can beassociated to more than one aspect. It is possible that two ormore aspects can cause a conflict, during the weaving process.This would be the case, for example, if an object is associated

ll rights reserved.

[email protected] (J. BaltasarC.A. Marcos).

to an aspect that updates a log system and also to an aspect thatdefines a specific function for the database administrator. Whena message is sent to this object and a method that stores data inthe database is invoked, the two associated aspects will be acti-vated. These situations arise questions such as the possibility ofbeing able to predict the resulting behaviour when both aspectsare invoked without any control. For example, a given order inwhich aspects are invoked could result in undefined behaviour,while other order could result in correct behaviour without fur-ther need of control. It may even be the case that the aspect re-lated to the database administrator should be specializedaccording to the actual database being updated at that particularmoment; that is, the behaviour is dependent on the context. Inthese and other cases, it would be desirable for the developerto specify the type of conflict among competing aspects, andto describe the actions to be carried out, determining the prior-ities and activation policy of the conflicting aspects. Then, Con-flicts may occur if two or more aspects compete for activation(Pryor, Diaz Pace, & Campo, 2002), this phenomenon is alsoknown as interaction (Duoence, Fradet, & Südholt, 2002) orinterference (ROOTS, 2007). There may be different types of hid-den dependencies or conflicts among aspects, and each one willrequire a different solution in order to avoid undesired or unpre-dictable behaviour. However, the handling of aspects conflicts ishard and complex with the current aspects tools, because of tworeasons: first of all, the identification process of conflicts is amanual task, and secondly the possibilities of resolution of con-flicts are very restricted.

In this work, an approach to conflict solving among aspectsis presented. The providing solution involves detection andresolution of these conflicts, while based on two mechanisms:

mailto:[email protected]



http://www.sciencedirect.com/science/journal/09574174

http://www.elsevier.com/locate/eswa

aspect A { pointcut A1(): call (void CX.met()); pointcut A2(): call (* CX.*(..)); before(): A1()

{ ........ } before (): A2 ()

{ ........ } }

Fig. 2. Two different declare precedence statement for aspects A and B.

aspect Logging { public static loogedOperations(..) { // send operation information to file or console } }

Fig. 3. Aspect logging.

S.I. Casas et al. / Expert Systems with Applications 36 (2009) 5630–5642 5631

the definition of associations and symbolic rules. An expert embed-ded system manages the conflicts among aspects. These strategieshave been implemented in a prototype denominated MEDIATOR,making this approach very flexible, effective and powerful. Thiswork arises to complement and overcome the explicit rules (Casas,García Perez-Schofield, & Marcos, 2007). The disadvantage of thisprevious approach emerges in very complex scenarios in whichlots of conflicts can be activated and they require similar solutions.The explicit rules definition can be a tedious, repetitive and a taskprone to errors. In these cases, the best strategy will be to use sym-bolic rules. In this way, each symbolic rule can solve subsets ofconflicts.

This work is structured as the following: Section 2 is dedicatedto the analysis of handling of conflicts in conventional AOP model;in Sections 3–5, the proposed solutions are deeply discussed; Sec-tion 6 presents a case of study; Section 7 exposes a performancestudy; Section 8 exposes related works; and Section 9 presentsthe final conclusions.

2. Restrictions of the AOP model

One of the reasons why the handling of conflicts is complex isdue to the underlying AOP model of the language. The conven-tional AOP model confers too many responsibilities to aspects.The supposition is that if an aspect is responsible for: (i) toencapsulate the logic and behaviour of the crosscutting concerns(advice); (ii) to establish the link with components of basic func-tionality explicitly (pointcuts); and (iii) to establish the execu-tion order (declares precedence), probably some of theseresponsibilities will not be fulfilled very well. In consequence,more flexible possibilities are restricted or limited. The mainexponent of this AOP model is AspectJ (<http://aspectj.org>. Ac-cessed December 2007; Kiczales et al., 2001). In this tool, aspectsare programming units that crosscut the modularity of the basicfunctional classes of the application in predetermined way. First,analyzing the devices that AspectJ provides to the handling con-flicts it is observed that, AspectJ lacks mechanisms to detect pos-sible conflicts among aspects. The weaver–compiler ‘‘ajc” doesnot inform the possible conflicting situations automatically andit always proceeds in the same way, no matter whether the con-flicts exist or not. Second, the mechanism for resolution, pro-vided by AspectJ consists in a very restricted precedence-basedscheme (also known as order or priority). In order to execute as-pects code in a certain order, it is necessary to specify it with astatement of precedence declaration: declare precedence: A, B;.The semantics states that if an aspect A precedes aspect B, thenthe advice of aspect A have priority and they are executed beforethe advice of aspect B.

The declare precedence statement presents limitations in thefollowing scenarios:

(a) The aspects outline more than one conflict (Fig. 1). Each con-flict requires different order policies. In this case, it is neces-sary that the advice associated to the pointcut A1 of aspect Abe executed before that the advice associated to the pointcut

aspect A { pointcut A1(): call(void CX.met());

pointcut A2(): execution(void CY.met()); before(): A1()

{ ........ } after(): A2()

{ ........ } }

Fig. 1. Two different conflicts

B1 of aspect B. Once the declaration ‘‘declare precedence: A,B” is added to the source code, it is impossible for the adviceassociated to pointcut B2 of aspect B to be executed beforethe advice associated to pointcut A2 of aspect A.This situa-tion is not possible to solve through a mechanism of prece-dence declarations, because it is related to the aspects andnot to the advice or pointcuts.

(b) The conflict is outlined by different pointcuts of the sameaspect (Fig. 2). The precedence declaration does not haveeffects for advice of the same aspect, the execution orderof advice in conflict is indefinite.The precedence declarationscannot be bound to different pointcuts or advice of the sameaspect.

(c) Two or more aspects outline a conflict that is solved in a par-ticular order in a certain application. If these same aspectsare used in another application in which should be executedin a different order, the previous declare precedence state-ment is not valid. In this situation, the aspect that containsthe declaration of precedence statement, cannot be reusedand they should be modified.

(d) In a developed application the whole code source of theaspects should be examined to determine the executionorder. This is due to a declaration of precedence thatinvolves several aspects that can be part of any of theseaspects source code. For example, if the aspects A, B and Care in conflict, the precedence declaration can be definedin the aspect A or B or C.

The problems indicated in the first two scenarios force to re-de-sign and to re-implement the aspects in a different way, the lasttwo problems impact negatively in the software reuse and mainte-nance. We propose an alternative approach, denominated Model ofAssociations. This model preserves the SoC, improves the aspectsreusability and mainly the handling of conflicts, which is moreflexible, and overcomes the drawbacks indicated.

aspect B { pointcut B1(): call(void CX.met()); pointcut B2(): execution(void CY.met()); before(): B1()

{ ........ } after(): B2()

{ ........ } }

among aspects A and B.

http://aspectj.org

Fig. 5. Symbolic rule to identify all conflicts.

12345

association LogAcc { call void Logging.loogedOperations();after void Account.setBalance(float amount);priority = 10; }

Fig. 4. Association among Logging aspect and Account class.

1 The facts in the expert system are such us tuples. A fact is structured in slotselds). Each slot represents an individual and atomic value. The working memory hasset of the same facts but with different slot value.

5632 S.I. Casas et al. / Expert Systems with Applications 36 (2009) 5630–5642

3. AOP model of associations

To solve the drawbacks discussed in the previous section, a dif-ferent model is adopted for crosscutting concerns implementation.This approach is aimed to assign the responsibilities in differententities. The entities are: aspects, associations and symbolic rules.

Aspects are independent units composed by methods and attri-butes and encapsulate specific crosscutting concern logic. Forexample, the Logging aspect (Fig. 3) is formed by the loogedOpera-tions(..) method.

Associations are entities defined in a separate way, instead ofbeing tied to aspects, they link aspects with classes. That is tosay, an association describes a relationship between an aspectand a class. For example, in Fig. 4 the LogAcc association is defined,relating the Logging aspect with the Account class. It establishesthat every time that the setBalance(float amount) method of Ac-count class is invoked, the loogedOperations() method of Logging as-pect is executed immediately afterwards.

The join-point and primitive cut are defined in line 3 and the as-pect and advice in line 2. In line 4 it has been defined a numericpriority for the association (not for the aspect). This priority willbe used later on for the handling of the conflicts. Looging.loogedO-perations() can be related to other functional components with an-other priority. The join-point Account.setBalance() can be related toother aspects. Then, other associations will be defined whenneeded. An association is always a one-to-one relationship. How-ever, the wildcards are allowed to denoted a set of join-points.An additional mechanism transforms this n-to-one relationshipin n associations.

This approach allows the aspects to be independent of the sys-tems in which they are used and they can be more reusable. Butmore important is the fact that this approach will facilitate thehandling of associations in an isolated particular way. Within thismechanism, a conflict does only happen when two or more associ-ations define for the same relationship type for the same functionalcomponent. The handling of conflicts should be applied toassociations.

4. Symbolic rules to handle conflicts

The strategy to manage conflicts is based on a set of symbolicrules and an expert embedded system (Giarratano & Riley, 2004)in the AOP tool. This proposal has been implemented in a denom-inated prototype MEDIATOR. The expert embedded system inMEDIATOR has been implemented with JESS (Friedman-Hill, 2003).

Through an expert system of rules, the following expression willallow to determine the existence of a certain conflict, and also toapply a method to solve it.

IF hconflict X exists iTHEN hto apply resolution Yi

where the expression hconflict X existsi is an expression thatinvolves a set of conditions (general or specific). And where theexpression hto apply resolution Yi is a function that applies a reso-lution category which implies some modification in the aspectsweaving.

Initially the goals of expert system are: (i) to detect the conflictsautomatically; (ii) to solve conflicts starting from symbolic rules;(iii) to identify non-resolved conflicts and; (iv) to identify firedrules and not fired. In the next subsections it is described the mainaspects of the expert system (for simplicity, the rules are describedin JESS pseudo-code, in Appendix some of these rules are imple-mented in JESS).

4.1. Working memory

The working memory is composed by the initial facts1 and thefacts that arise when rules are fired. Initially, two types of facts con-form the working memory, the associations and the system configu-ration. The associations are automatically converted (mapping) asasoc facts. For example, the fact (asoc (as_id LogAcc) (asp_id Looging)(asp_ma loogedOperations) (rel_cut call-after) (cl_id Account) (cl_masetBalance) (as_pr 10)) corresponding to the LogAcc association (Fig.4).

At the beginning, other facts which are part of the workingmemory, are those that refer to the configuration of the expert sys-tem. (The templates of all the facts enunciated next are detailed inAppendix A.)

4.2. Detection conflict rule

The detection of conflicts generates a set of facts that denote theexistence of conflicts. The fact conf represents a conflict betweentwo associations. A priori, the conformation of the conflicts is ig-nored. These could be formed for more than two associations. Bydefinition, a conflict consists, of at least, two associations. If a con-flict is formed by three associations, then three facts conf will exist.The conflictDetection rule (Fig. 5) identifies all the existent conflictsin the working memory (The assert function adds a fact in theworking memory).

4.3. Resolution conflicts rules

The resolution of conflicts is a process formed by a set of rules.When these rules are fired, they generate a set of resolution facts(resc). A resolution fact represents a resolution category to beapplied to the associations in conflict. This resolution fact willindicate a certain action to execute for the aspects weaving.

A resolution rule generate more than a fact: (i) the fact thatrepresents the resolution (category and associations) and (ii) afact that represents the conflict is solved (confS). The facts resc

(fia

Fig. 7. Resolution rules and OF subcategory.

Fig. 8. Resolution rules and excluded subcategory.

Fig. 9. Resolution rules and annulled category.


represent a resolution category applied to a certain conflict. In thisway three resolution categories can be applied:

Order: It determines an order of weaving-execution processes ofthe associations in conflicts. The subcategories are: order bypriority (OBP), inverse order by priority (IOBP), first order (OF)and last order (OL).

Exclusion: It excludes of weaving-execution processes of one ormore associations in conflicts. The subcategories are: to excludeone association (ETA), to exclude all associations except one(EAA), to exclude association with less priority (ELP) and to excludeassociation with great priority (EGP).

Nullity: It annuls all the associations in conflict of the weaving-execution processes.

In Fig. 6, the OBP subcategory is applied in a different ways. Therule R01 orders all the associations in conflict according to theirpriority.

The rules R02, R03 and R04 are more particular, since they canbe applied to subsets of conflicts. R02 solves alone the conflicts thatoutline about on the Account class; in R03 solves the conflicts thatoutline about on the debit method of Account class. And R04 solvesthe conflicts, if any of their associations involves to the Logging as-pect. The subcategory IOBP can be applied in a similar way.

The OF and OL subcategories order the associations in conflictwithout considering the priority of associations. The rule Rof1(Fig. 7), makes that if the Authentification aspect is part of someof the associations in conflict, it must be weaved first.

The exclusion subcategories eliminate one or more associationsin conflict, but not all. That is to say, after some of these subcate-gories are applied one or more associations will be eliminatedout of the weaving. ETA excludes an association, EAA excludes allassociations except one, EGP and ELP exclude respectively fromthe weaving the association of greater and smallest priority. Forexample in Fig. 8, the rule RE1 excludes the association of biggestpriority of the conflict.

The Nullity category annuls all the associations in conflict. Thismeans that all the associations will not be weaved. In Fig. 9, therule RA1, annuls all the associations in conflict. The rules RA2 andRA3 are more specific. RA2 eliminates the associations in conflictif this is about the Account class. RA3 eliminates the associationsin conflict if this is about debit method of Account class.

4.4. Depuration rules

The described rules are enough when the conflicts are formedby two associations. When the conflicts are formed by more oftwo associations they can be generated resolution facts unneces-sary and redundant. The goal of depuration rules is to solve these

Fig. 6. Resolution rules a

situations. For example, if the associations asoc1, asoc2 and asoc3are in conflict and they have priorities 5, 10 and 15, respectively,the rule R01 is fired three times and it generates the following res-olution facts: (resc (sent OBP) (a1 asoc3) (a2 asoc1)), (resc (sent OBP)(a1 asoc3) (a2 asoc2)), (resc (sent OBP) (a1 asoc2) (a2 asoc1)). Thefirst and third facts are ambiguous since it is not clear if the

nd OBP subcategory.

Fig. 12. Rule to identify non-solved conflicts.Fig. 10. Depuration Rule depOBP.


association asoc1 will be weaved after asoc3 or asoc2. The first factis not necessary. The depuration rule depOBP solves this problem(Fig. 10). This rule is fired only if the conflict is formed by morethan two associations. Therefore, the resolution fact (resc (sentOBP) (a1 asoc3) (a2 asoc1)) is eliminated of the working memory(the retract function remove a fact from de working memory).The same situation happens with resolution facts of subcategoriesIOBP, OF, OL, EGP and ELP. The depuration rules in these cases aresimilar to the depOBP rule. The resolution facts of resolution sub-categories ETA, EAA and Nullity do not require depuration rulessince the semantics of the resolution category do not generate factsthat may present ambiguity for the weaving aspects.

4.5. Interference rules

When the developer specifies more one symbolic resolutionrules, it can exits interferences among the generated resolutionfacts. Interference happens when two or more different resolutionfacts exist for the same conflict. This can happen for two reasons:(i) it has been defined a general resolution rule and a particularrule and both match to the same conflict; (ii) it has been definedcontradictory resolution rules that match to the same conflict. Inboth situations the expert system should save these drawbacks.Before the expert system execution, the developer has to configurethe system. The configuration of the expert system will solve auto-matic way interferences among the resolution facts. The developerhas to assign a priority for each category of resolution which ismapped such as pr_rule fact. For each category of resolution apr_rule fact assigns a priority. For example, the fact assigns thepriority 1 to OBP category of resolution. The interference rule Ri1(Fig. 11) eliminates from the working memory the resolution factswith different categories in which the first argument refers to thesame association. The condition to eliminate one or another factis the priority of the category of resolution.

The interference rule Ri2 eliminates from working memory theresolution facts with different categories in which the first and thesecond argument refer to the same association. Once more, thecondition to eliminate one or another fact is the assigned priorityto the category of resolution.

4.6. Non-solved conflicts

Starting from the conflict facts (conf) and solved conflict facts(confS), it is simple to determine which conflicts have not beensolved. The rule confN (Fig. 12) generates the confP facts. The confP

Fig. 11. Interfer

facts represent a non-solved conflict. Basically the rule confNchecks whether for each conflict fact exists a solved conflict fact(confS) or not. The goal of this rule is to determine the conflict factsthat do not match any of the solved conflict fact.

4.7. Output expert system

The information of expert execution system is available withJESS API. The facts conf, confS, confP and resc in Working Memorycan be retrieved. The fired and non-fired resolution rules can alsobe recovered. Therefore, the output expert system can be used bythe developer or the aspect weaver.

5. MEDIATOR weaving process

The weaving process integrates the aspects with the classes tobuild the final application (Piveta & Zancanella, 2003). The objec-tive is to maintain the associations and the logic of resolution ofconflicts as separated and isolated as possible from classes and as-pects. This is the objective to which the design of the weavingstrategy was aimed to.

The proposed strategy requires classes, associations and of ob-jects of resolution facts objects to participate in the weaving pro-cess, apart from aspects, which are explicitly not involved in thisprocess. The weaving process proceeds in two stages.

First, the compilation process performs three operations: (i)unify explicit and symbolic rules, (ii) generate the linking classand (iii) generate the class files.

As it was said at the beginning, MEDIATOR includes the use ofexplicit rules (Casas et al., 2007) to solve a conflict. The main differ-ences with symbolic rules, are that an explicit rule only can solve aconflict and that the resolution categories are wider. These catego-ries can be simple (order, optional, exclusion and nullity) or a com-bination (using several simple resolution categories). When asymbolic resolution rule is fired, are generated some resolutionsentences. All the resolution sentences are converted in explicitrules. In Table 1, the form in which a resolution sentence is con-verted in explicit rule is showed.

After this transformation, the system checks if a conflict issolved by more than one explicit rule. This ambiguity generatesan error and the process stops. If none of the errors happens, thelinking class is generated automatically next. The methods of thisclass are denominated linking methods. These methods will relatefunctional components to the aspects obtaining the information

ences rules.

Fig. 13. Linking method generated from association LoggAcc.

Fig. 14. Conflict between LoggAcc and StatisAcc associations, resolution fact andexplicit rule.

Fig. 15. Linking method of associations in conflicts.

Table 1Mapping resolution sentences in explicit rule

Resolution sentences Explicit rule

(OBP (asoc2) (asoc1)) Condition: {asoc2,asoc1}Action: order(asoc2,asoc1)

(IOBP(asoc1) (asoc2)) Condition: {asoc1,asoc2}Action: order (asoc1,asoc2)

(OL (asoc2) (asoc1)) Condition: {asoc2,asoc1}Action: order(asoc2,asoc1)

(OF (asoc2) (asoc1)) Condition: {asoc2,asoc1}Action: order(asoc2,asoc1)

(ETA (asoc1)) Condition: {asoc1}Action: excluded (asoc1)

(EAA (asoc1)(asoc2)) Condition: {asoc1,asoc2}Action: excluded (asoc1,asoc2)

(ELP (asoc1)) Condition: {asoc1}Action: excluded (asoc1)

(EGP (asoc1)) Condition: {asoc1}Action: excluded (asoc1)

(ANULLED (asoc1)(asoc2)) Condition: {asoc1,asoc2}Action: anulled (asoc1,asoc2)


from their corresponding associations. In Fig. 13 the link_Met1()linking method is shown, generated from the LoggAcc association.

The link_Met1() method invokes the execution of the Log-ging.loogedOperations() aspect method, defined in the LoggAccassociation.

The previous example is validated for associations free of con-flicts. When the associations to weave are in conflict, the processis carried out in a similar way. In the first phase the explicit ruleis required besides the associations. The linking method concen-trates the logic of resolution of conflict.

For example, in Fig. 14 the LoggAcc and StatisAcc associationshave been defined. The LoogAcc and StatisAcc associations are inconflict. The rule R01 (Fig. 6) has been defined to solve all conflictsapplying to OBP subcategory. The resolution fact (resc (OBP Log-gAcc, StatisAcc)) is created when R01 is fired. Then, in the compila-tion process this fact is converted in explicit rule with the actionorder (LoggAcc, StatisticAcc). This final sentence is employed tothe weaving.

Besides, both associations are merged into a unique linkingmethod. The method encapsulates the logic of resolution of theconflict. This logic comes from the category resolution of conflictin the defined explicit rule. In Fig. 15, the link_Met2() linking meth-od has been automatically generated starting from the rule R01.

At the same time the linking class is being generated, the dy-namic table of linking methods is created with the necessary infor-

mation for the next weaving phase. Each input in this tablerepresents the functional component to crosscut, the relationshiptype (before or after) and the linking method. Following the pre-sented previous examples, the table dtlm = {(Account,extract,after,-link_Met1), (Account,debit,after, link_Met2)} is created.

The second phase proceeds during the execution of the applica-tion. In load-time, those classes affected by the associations arelinked to the linking methods, according to the relationship type(before or after). This operation is simple due to a customizeclass-loader employs the dynamic table of linking method. Thisprocess has been implemented by means of the Javassist API (Chi-va, 1998).

In summary, in the functional components affected by someassociations are inserted a call to a linking method, according tothe type of relationship of the association. The linking method in-vokes of the aspect method directly, or it can include a group ofsentences that apply a category of resolution of conflict. Therefore,the following advantages are obtained: (i) classes do not have anyknowledge about what aspect cuts them; (ii) aspects preserve theiroriginal state and they can be associated to any other functionalcomponent (iii) conflict resolutions are hidden in the linking class,being specific for a certain application, and finally, (iv) if a newassociation or rule is defined it is only necessary to generate thelinking class, it is not necessary to compilate the other units (clas-ses and aspects). It has been presented the weaving strategy in Ca-sas et al. (2007).

6. Experimental validation

In order to verify the practical applicability of the presented ap-proach, a case of study was developed with MEDIATOR. The case ofstudy is a simple banking application. The basic functionality isrepresented by Account, AccountManager and BankingApplic classes.The AccountManager class manages the Account objects and Bankin-gApplic class has the main method. The crosscutting concerns arerepresented by three aspects: Logging, Profile and Statistic. The Log-ging aspect sends a message to the console that identifies the classand method executed. The Statistic aspect calculates the average ofdebits and credits. The Profile aspect computes the average time ofexecution of adding or removing an account (Fig. 16).

AccountManager

addAccount removeAccount doDebit doCredit

<<aspect>> Logging

consoleOperation

<<aspect>> Statistic

statDeb statCred printStatistic

<<aspect>> Profile

start ends printProfile

Account

Account getId debit credit

BankingApplic

main

ba1 ba2 ba3 ba4

ba12

ba8 ba9

ba10ba11

ba5ba6

ba7

Fig. 16. Banking application diagram.

Table 2Structures of associations

Association Advice Class Member

ba1 After AccountManager addAccouba2 After AccountManager removeAba3 After AccountManager doDebitba4 After AccountManager doCreditba5 After AccountManager doDebitba6 After AccountManager doCreditba7 After BankingApplic mainba8 Before AccountManager addAccouba9 Before AccountManager removeAba10 After AccountManager addAccouba11 After AccountManager removeAba12 After BankingApplic main

Fig. 17. Specification of

Fig. 18. Outputs of


Twelve associations set up the aspectual relationships. Table 2samples the structure of each association. For example, the associ-ation ba1 declares an aspectual relationship between the Account-Manager class and the Logging aspect. Every time that the methodaddAccount is executed the consoleOperation method is executedafterwards. The priority of ba1 is 3.

Next, two different scenarios of resolution of conflicts arepresented.

Scenario 1. To order according to the priority of the association.In this scenario, it is outlined the solution of all the conflicts

according to the priority of the association. Then it is necessaryto define a symbolic rule. This task is very easy to carry out dueto MEDIATOR provides special form to fill in. The system convertsthe form in the Jess format rule. The definition of rule RS1 (Fig. 17)requires only the OBP resolution subcategory, it is not necessary tocomplete any condition. It is due to the specification indicates allthe conflicts.

The following step is to order the execution of the embeddedexpert system. Automatically the twelve associations are mapped

Aspect Property Priority

nt Logging consoleOperation 3ccount Logging consoleOperation 3

Logging consoleOperation 4Logging consoleOperation 7Statistic statDeb 5Statistic statCred 6Statistic printStatistic 7

nt Profile start 10ccount Profile start 10nt Profile ends 10

ccount Profile ends 10Profile printProfile 10

symbolic rule RS1.

expert system.

Fig. 19. Linking class.


such as asoc facts in the working memory and the RS1 rule is addedto the engine rules. Fig. 18 shows the report of the outputs. In thefirst screen, the system informs: (i) the detection of five conflicts,(ba12, ba7), (ba2, ba11), (ba10, ba1), (ba6,ba4) and (ba3,ba5). Thismeans that the ConflictDetection rule was fired five times; (ii) thesolved conflicts, in this case all of them (information obtained fromconfS facts); (iii) non-solved conflicts, in this case none of them.That is to say, if there are not any confP facts in the working mem-ory, that is why the ConfN rule was not fired. In the followingscreen, it is informed the five resolutions which were generatedby the expert system of rules, coming from the rule RS1. The firstresolution indicates that ba12 association will be ordered before

Fig. 20. Symbolic rul

than ba7 association, because of the ba12 priority is greater thanba7 priority, and so on and so for. At the bottom of the screen,the system informs, the non-fired resolution rules (in this casenone).

During the compilation phase, the resolution sentences gener-ated by the expert system of rules are transformed into explicitrules. The associations and unified explicit rules are used for gen-erating the linking class in an automatic way.

In Fig. 19, the linking class has been edited. The linking class hasseven linking methods. The link_met1 method corresponds to theba8 association, while the link_met3 method corresponds to theba12 and ba7 associations. That is to say to a conflict.

es RS1 and RS2.

Fig. 21. Configuration of the rules system.


Scenario 2. To weave Logging first and to exclude Statistic.In this scenario, it is outlined the necessity of test the execution

of the application under certain restrictions: to eliminate from theweaving the Statistic aspect when it is in conflict, and to be alwaysexecuted first the Logging aspect. These premises only set up tomake a series of traces but not in a permanent way. In the caseof being permanent modifications some associations would beredefined.

A symbolic rule must be defined to apply the OF resolution sub-category just for the conflicts that Logging aspect is involved. Andanother symbolic rule which applies the ETA resolution subcatego-ry for the conflicts in those that it participates the Statistic aspect(the adopted approach is not the association priority). In Fig. 20,the symbolic rules RS1 and RS2 are shown that express theseconditions.

The symbolic rule RS1 specifies the application of the ETA sub-category on the conflicts which Statistic aspect participates. Andthe symbolic rule RS2 specifies that the OF subcategory is appliedon the conflicts that it participates the Logging aspect.

Also, it is necessary to configure the rules system, since in thissituation will exist interferences among some resolution facts(resc). The conflicts (ba6,ba4) and (ba3,ba5) are matched with bothrules (RS1 and RS2) and they will have more than a resolution facteach one. Fig. 21 shows the form to configure the rules system.Each resolution subcategory has a numeric priority. The configura-tion is mapped such as pr_rule facts. For this case, ETA subcategoryhas greater priority than OF subcategory. These facts and the rescfacts in interference will fire the interference rule Ri2 (Fig. 11). Thisrule solves the inconsistency, removing the resc facts with OFsubcategory.

Fig. 22 presents the resolution sentences generated by the ex-pert system of rules. Three resolution sentences apply the ETA sub-

Fig. 22. Resolutions sentences.

category on ba5, ba6 and ba7 associations which use the Statisticaspect. Besides it has been generated two OF resolution sentencesindicating that ba1 and ba2 associations are woven first which useLogging aspect.

The linking class generated by compilation process is thefollowing:

class Linking_Class {
Profile.ends(); public static void link_met1() // ba8 } { public static void
link_met5() // ba1,ba10

Profile.start();
{ }Logging.consoleOperation(”AccountManager”,
public static void link_met2() // ba9
‘‘addAccount”); { Profile.ends(); Profile.start(); }
}
public static voidlink_met6() // ba4
public static void link_met3() // ba12
{ {Logging.consoleOperation(”AccountManager”,
‘‘doCredit”);Profile.printProfile();
}
}
public static voidlink_met7() // ba3
public static void link_met4() // (ba11, ba2)
{ {Logging.consoleOperation(”AccountManager”,
‘‘doDebit”);Logging.consoleOperation(”AccountManager”,
} ‘‘removeAccount”); }
As it can be observed, there is no linking method that invokesany property of the Statistic aspect and the invocations of the Log-ging aspect are always carried out before (link_met4 and link_met5methods).

Conclusions: The presented case has demonstrated clearly thatthe expert system of rules has detected all the conflicts automati-cally; it has applied different symbolic rules of resolution of con-flicts and it has solved possible interferences among theresolution rules. Besides, it provides enough information to thedeveloper. Other very important consideration to highlight is thatin none of the different scenarios implied the modification of theoriginal code of the application. In other words, it was not neces-sary to modify neither a single line of the code of the classes, northe aspects and the associations.

0

500

1000

1500

2000

2500

Test 1 Test 2 Test 3

ns/in

voca

tion

MEDIATOR ASPECTJ

Fig. 23. Time average time of execution of conflicts with AspectJ and MEDIATOR.


7. Performance study

To validate the MEDIATOR a performance study was carried out.The experiment had the purpose of evaluating the performance ofthe invocation of the aspects in conflicts using the linking class ofMEDIATOR vs. the performance of invocation of aspects in conflictof AspectJ. While, AspectJ weaver inserts direct hooks in base codeto the aspects. The base of the experiment was taken from AOPBenchmark (2007) with some adaptations.

The application which was used for the experiment, was theapplication defined in the previous section. The Account andAccountManager classes and the Logging and Statistic aspect wereonly applied to the credit operation. In MEDIATOR the conflictwas solved with a symbolic rule that applied OBP subcategory. InAspectJ the conflict was solved with declare precedence statement.The environment of execution of the experiment was thefollowing:

–Machine:Intel Centrino RAM 1 GB–Operative System: Microsoft Windows XP Professional–JVM: Java 1.5.0_9 (J2SE 5.0)–AspectJ: 1.5–Javassist: 3.2

The experiment consisted of three tests, which are described inTable 3.

Each test was executed 2.000.000 of iterations on the methodthat was intercepted. In each invocation it was registered the timethat required the execution of the method and their interceptions.The time was accumulated in the 2.000.000 iterations to be, finally,calculated the time average. In this experiment, the time was takenin nanoseconds with the System.nanoTime() method of Java.

The results of the experiment are exposed in the graph of Fig.23.

In the three tests MEDIATOR is a bit more efficient that AspectJ.The differences in favor of MEDIATOR are really minima, oscillatingbetween 14 and 16 ns. This means that the particular invocation ofaspects in conflicts using the linking class does not generate anoverload in the execution of the application. These results are con-sistent with other experiment, which have been carried out (Casaset al., 2007).

8. Related works

Several works have been developed in order to detect and solveconflicting situations among aspects.

The first directly related work with the detection and resolutionof conflicts has seems to be (Duoence et al., 2002). The authors holdthat the treatment of the conflicts among aspects should be carriedout in a separated way from the aspects definition. A model ofthree-phases has been proposed for the programming of multipleaspects: (i) Programming; (ii) Analysis of conflicts; (iii) Resolutionof conflicts. The programmer solves the interactions by using adedicated composition language. The result of this phase can beagain checked in phase (ii). The solution is based on a genericframework for AOP that is characterized by a very expressive lan-

Table 3Interceptions and invocations used in the experiment

Test AspectJ/MEDIATOR

(1) Before The AccountManager.doCredit() metho(2) Before + after The AccountManager.doCredit() metho(3) Before + this + args The AccountManager.doCredit() metho

guage of crosscutting cuts, static conflicts analysis and a linguisticsupport for the resolution of conflicts.

An approach to detect and to analyze the conflicts caused by thecapacities of AspectJ is presented in Storzer and Krinkle (2003).This approach provides mechanisms to modify the hierarchicalstructure of the classes (declaration declares parents) and to intro-duce new members to the classes (methods and attributes). Thiswork is based on traditional techniques of programs analysis andit is only led to the detection of a class of conflicts.

An analysis model to detect conflicts among crosscutting con-cerns is presented in Tessier, Badri, and Badri (2004). The purposeof the authors is to identify the interactions among aspects duringthe modeling, and to provide a formal method that allows develop-ers to detect the conflicts by means of successive refinements. Themain objective is to achieve the detection of conflicts as soon aspossible (early detection of conflicts) and to offer certain level ofprediction of the generated impact by the insert of new aspects.This work is restricted to the detection of the conflict, in spite ofearly stages of the development.

A precedence model of AspectJ (sequential), used to establishthe execution order of advice, when they are associated to thesame join-point is improved and optimized in Yu and Kienzle(2004). The representation of the model in a precedence graph,leads to a model of concurrent precedence. This work tries to im-prove the mechanism of resolution conflict especially for AspectJ.

LogicAJ (ROOTS, 2007) provides interferences aspect–aspectanalysis for AspectJ that includes capacities for: (a) identifying awell defined interferences class, (b) determining the execution or-der free of interference (c) determining the weave algorithm moreconvenient for a group of given aspects. The analysis of interfer-ences is independent from the base programs to those that the as-pects are referred to (only the aspects are necessary for theanalysis) and independent from the additional annotations of theaspect analyzer.

d is intercepted by two before advice/associationsd is intercepted by two before advice/associations and two after advice/associationd is intercepted by two before advice/associations passing all the context

Table 4Comparing AspectJ model & MEDIATOR model

AspectJ MEDIATOR

Does not have solution when the aspects outline more than oneconflict, and each conflict requires different order policies

Has a solution. The conflicts resolution is not applied to aspects. The conflicts resolution is appliedto associations. Then two o more aspects can outline more than one conflict. Each conflict can besolved independently

Does not have solution when the conflict is outlined by differentpointcuts in the same aspect.

Has solution. The associations are such as pointcuts, but they are entities with 1–1 relationship.Then if two or more associations involve the same aspect and they are in conflict, a symbolic rulecan solve them

If the same conflict requires different resolution in differentapplications, it should modify the aspect source code

It is not necessary to modify the aspects source code. The developer only has to modify theresolution symbolic rule

In a developed application the whole aspect source code should beexamined to determine the execution order

It is not necessary to examine the whole aspects source code. The expert system generate thefollowing outputs: solved and non-solved conflicts, resolution facts, fired a non-fired resolutionrules. This information is enough for this task


Programme Slicing is a technique that aims to the extraction ofprogram elements related to a computation in particular. This ap-proach is proposed to analyze the interactions among aspects,since it can reduce the code parts that are needed to analyze in or-der to understand the effects of each aspect (Monga, Beltagui, &Blair, 2003).

A very interesting work is Reflex (Tanter & Noye, 2005), a toolthat facilitates the implementation and composition of differentaspect-oriented languages. This work proposes a model which pro-vides a high level of abstraction to implement the new aspect lan-guage and to support the detection and resolution of conflicts.Reflex consists basically of a kernel with 3 layers architecture:(1) a layer of transformation in charge of the basic weave with sup-port for the structural modification and of behaviour of base pro-grams; (2) a composition layer for the detection and resolutionof interactions and (3) a language layer, for the definition of the as-pect language modulation. The detection of interactions followsthe outline proposed for Charfi, Riveill, Blay-Fornarino, and Pin-na-Dery (2006) and it is a static approach. The interactions arenot detected at execution time. There are two ways of solving aninteraction: (1) to choose of the interactions the aspect that willbe applied in the execution (2) to order and to nest the aspectsfor the execution. This work advances that an AOP tool shouldmanage conflicts and consequently it provides a specific layer ofthe kernel for this purpose.

A way to validate the order of precedence formally, between as-pects that share join-points, is presented in Pawlak, Duchien, andSeinturier (2005). This work introduces a small language, CompAr,in which the user expresses the effect of the advice that is impor-tant for aspect interaction, and properties that should be true afterthe execution of the advice. The CompAr compiler checks a givenadvice order does not invalidate a property of an advice.

An interactions analysis based on Composition Filters is pro-posed in Durr, Staijen, Bergmans, and Aksit (2005). In this work,it is detected when one aspect prevents the execution of another,and can check that a specified trace property is ensured by anaspect.

The use of rules as strategy or mechanism for handling of con-flicts has been proposed in several recent works. (Kessler & Tanter,2006) presents a logic-based initial exploration where facts andrules are defined for the detection of interactions in Reflex. In Nagy,Bergmans, and Aksit (2006), it is proposed a constraint-baseddeclarative approach to specify the composition of aspects whichshare join-points. The implementation of this model requires theextension of AOP Language in several aspects: join-point con-structs, advice constructs, declaration statements, etc. The restric-tions of AOP Languages, such as the limitations of precedencestatement (Section 2) are not overcome, because of the resolutionsare applied in the body of the aspects.

The model of interactions (Charfi et al., 2006) is similar to themodel of associations. The authors proposed to represent the

aspects such as components and the aspectual relationships in‘‘Interaction” units. The Interactions are a mixture of associationsand explicit rules. An interaction specification language (ILS) isprovided. This language provides a set of operators, which defineweaving rules (‘‘merging”). The operators apply different resolu-tions to the conflicts: conditional execution, mutual exclusionand order, and the sequential or concurrent composition. All theinteractions on the shared join-points are mixed in an only interac-tion (it unifies advice after and before). The interactions are definedin singular form, after an automatic mixture process generates thefinal interaction.

Another similar approach is Aspect-Markup Language (AML)(Lopes et al., 2004). In AML, an aspect-oriented program consistsof three elements: core modules, aspectual modules and aspectbindings. Core and aspectual modules are developed in the baselanguage; these entities are similar to classes and aspects in MEDI-ATOR. The aspect bindings are specified in AML, and are similar to aset of associations. All aspectual relationship (pointcuts, advice,etc.) related with an aspectual module are encapsulated in an as-pect binding. Aspect binding is XML-based binding specification.It is provided binding instructions that determine how core andaspectual modules are unambiguously composed to produce the fi-nal behaviour. In general, an aspect binding file contains a mixtureof predefined XML elements called core elements and user-definedXML elements called custom elements. The authors do not high-light specific syntactic and semantic mechanisms for handling ofconflict.

Apart from AOP, various techniques that would enable the mod-ularization of crosscutting concerns have been proposed. The mostrelevant and widespread approaches are: Composition filters (Ak-sit, Bergmans, & Vural, 1992), adaptive programming (Lieberherr,1996) and multi-dimensional separation of concerns using hyper-spaces (Tarr, Ossher, Harrison, & Sutton, 1999). In composition fil-ters model, the order of filters permits the handling of certainconflicts when there is more than one crosscutting concerns. Inadaptive programming and hyperspaces approaches, the handlingof conflict is limited, within composition rules.

9. Conclusions

In this article, a novel approach to detect and to solve conflictsamong aspects has been presented. The main strategies appliedare: (i) implementation separated from the crosscutting concernsin aspects and associations. These mechanisms allow us to isolateand to individualize the resolution of conflicts; (ii) the precedencescheme is overcome by the definition of symbolic rules. The possi-bility to apply the resolution of several categories is a unique solu-tion in AOP context; (iii) the weaving strategy makes the aspectsremain intact. They are contaminated neither by the associationsnor by any of the conflict resolutions applied.

Rules

(defrule conflictDetection(asoc(as_id ?x)(rel_cut ?rel) (cl_id ?cl_id) (cl_ma ?cl_ma))(asoc(as_id ?y)(rel_cut ?rel) (cl_id ?cl_id) (cl_ma ?cl_ma))(not (conf (a1 ?y)(a2 ?x)))(test (neq ?x ?y))

=>(assert (conf (a1 ?x)(a2 ?y))))

(defrule R01(conf (a1 ?x) (a2 ?y))(asoc (as_id ?x) (as_pr ?prx))(asoc (as_id ?y) (as_pr ?pry))

=>(if (> ?prx ?pry)then (assert (resc(sent OBP)(a1 ?x)(a2 ?y)))else (assert (resc(sent OBP)(a1 ?y)(a2 ?x))))(assert (confS (a11 ?x) (a22 ?y))))

defrule R02(conf (a1 ?x) (a2 ?y))


In Section 2, it was stated several scenarios in which the AspectJmodel present serious difficulties. In Table 4, we compare both ap-proaches in these situations.

These characteristics make this approach very flexible, effectiveand powerful in order to handle conflicts and the SoC principle alsoremains. Additional benefits are achieved such as reusability due toaspects that avoid storing some information about the functionalcomponents that they crosscut.

The described strategies in Sections 3–5 have been imple-mented in a prototype denominated MEDIATOR. This tool allowsimplementation of AOP application in Java. MEDIATOR is simpleand easy. It extends Java with two new units: associations andsymbolic rules. The expert embedded system in MEDIATOR isimplemented in JESS. In Section 4, we defined four goals of the ex-pert system, they were satisfied. The expert system includes sym-bolic rules for the detection and resolution of conflicts, depurationrules and interference rules. The resolution rules apply a resolutioncategory to one or more conflicts. The symbolic resolution rulescan be general or particular, being adjusted by the developer. Thedepuration rules solve ambiguous resolution facts. The interfer-ence rules remove contradictory resolution facts. The detection ofconflicts, depuration and interference rules are automatic. Thedeveloper must specify the resolution rules only. This task is easy

Appendix A

TemplatesAssociation template

(deftemplate asoc(slot as_id) // association identifier(slot asp_id) // aspect identifier(slot asp_mf) // aspect method/ attribute identifier(slot rel_cut) // cut-relation

(slot cl_id) // class identifier(slot cl_ma) // class method attribute identifier(slot as_pr) // association priority

Configuration template

(deftemplate pr_rule(slot sent) // resolution category(slot pr) // resolution category priority

Conflict template

(deftemplate conf(slot a1) // association in conflict(slot a2) // association in conflict

Solved conflict template

(deftemplate confS(slot a11) // association of solved conflict(slot a22) // association of solved conflict

Pending conflict template

(deftemplate confP(slot a1) // association of pending conflict(slot a2) // association of pending conflicts

Resolution template

(deftemplate resc(slot sent) // resolution category(slot a1) // conflict association(slot a2) // conflict association

(asoc (as_id ?x)(cl_id Account) (as_pr ?prx))(asoc (as_id ?y) (pr ?pry))

=>(if (> ?prx ?pry)then (assert (resc(sent OBP)(a1 ?x)(a2 ?y)))else(assert (resc(sent OBP)(a1 ?y)(a2 ?x))))(assert (confS (a11 ?x) (a22 ?y)))

(defrule R04(conf (a1 ?x) (a2 ?y))(asoc (as_id ?x) (asp_id ?ax) (as_pr ?prx))(asoc (as_id ?y) (asp_id ?ay) (as_pr ?pry))(test (or (eq Logging ?ax) (eq Logging ?ay)))

=>(if (> ?prx ?pry)then (assert (resc(sent OBP)(a1 ?x)(a2 ?y)))else(assert (resc(sent OBP)(a1 ?y)(a2 ?x))))(assert (confS (a11 ?x) (a22 ?y))))

(defrule Rof1(conf (a1 ?x) (a2 ?y))(asoc (as_id ?x) (asp_id ?anx))(asoc (as_id ?y) (asp_id ?any))(test (or (eq ?anx Authentification) (eq ?any Authentification)))

=>(if (eq ?anx Authentification)then (assert (resc (sent OF) (a1 ?x)(a2 ?y)))else (assert (resc (sent OF) (a1 ?y)(a2 ?x))))(assert (confS (a11 ?x) (a22 ?y))))

(defrule RE1(conf (a1 ?x) (a2 ?y))(asoc (as_id ?x) (as_pr ?prx))(asoc (as_id ?y) (as_pr ?pry))

=>(if (> ?prx ?pry)then (assert (resc (sent EGP)(a1 ?x)))else (assert (resc (sent EGP)(a1 ?y)))(assert (confS (a11 ?x) (a22 ?y))))

(defrule RA1(conf (a1 ?x) (a2 ?y))

Appendix A (Continued)

=>(assert (resc (sent anulled) (a1 ?x)(a2 ?y)))(assert (confS (a11 ?x) (a22 ?y))))

(defrule RA3(conf (a1 ?x) (a2 ?y))(asoc (as_id ?x) (cl_id Account) (cl_ma setBalance))

=>(assert (resc (sent anulled) (a1 ?x) (a2 ?y)))(assert (confS (a11 ?x) (a22 ?y))))

(defrule depOBP(and (resc (sent ?s) (a1 ?x1) (a2 ?x2))(resc (sent ?s) (a1 ?x1) (a2 ?x3))(asoc (as_id ?x2) (as_pr ?px2))(asoc (as_id ?x3) (as_pr ?px3)))(test (eq ?s OBP))(test (neq ?x1 ?x3))(test (> ?px2 ?px3))?f <-(resc (sent ?s) (a1 ?x1) (a2 ?x3))

=>(retract ?f))

(defrule Ri1?f <-(resc (sent ?s1) (a1 ?x1))?g <-(resc (sent ?s2) (a1 ?x1))(pr_rule (sent ?s1) (pr ?pr1))(pr_rule (sent ?s2) (pr ?pr2))(test (neq ?s1 ?s2))

=>(if (> ?pr1 ?pr2)then (retract ?g)else (retract ?f)))

(defrule ConfN(declare (salience -10))(conf (a1 ?x) (a2 ?y))(not (confS(a11 ?x) (a22 ?y)))(not (confS(a11 ?y) (a22 ?x)))

=>(assert (confP (a1 ?x) (a2 ?y))))


with MEDIATOR, a friendly interface allows that the developerdoes not require JESS knowledge.

The main restriction of MEDIATOR does not support aspects in-stances but it is a limitation of the implementation. And it is not alimitation of the model of associations.

Acknowledgement

This work was partially supported by the Universidad Nacionalde la Patagonia Austral, Santa Cruz, Argentina.

References

Aksit, M., Bergmans, L., & Vural, S. (1992). An object-oriented language-databaseintegration model: The composition filters approach. In Proceedings of Europeanconference on object-oriented programming (ECOOP). The Netherlands.

AOP Benchmark. AspectWerkz – Confluence <http://docs.codehaus.org/display/AW/AOP+Benchmark> Accessed December 2007.

AspectC (2007). http://www.cs.ubc.ca/labs/spl/projects/aspectc.html, accessedDecember 2007.

AspectJ (2007). http://aspectj.org, accessed December 2007.Casas, S., Garcı́a Perez-Schofield, B., & Marcos, C. (2007). Associations in conflict.

INFOCOMP – Journal of Computer Science – Federal University of Lavras, 6(2),27–36. ISSN:1807-454.

Charfi, A., Riveill, M., Blay-Fornarino, M., & Pinna-Dery, A. (2006). Transparent anddynamic aspect composition. In Workshop on software engineering properties oflanguages and aspects technologies, VII AOSD, Germany.

Chiva, S. (1998). Javassist – A reflection-based programming wizard for Java. InProceeding of the ACM – OOSPLA. Workshop on reflective programming in C++ andJava. Canada.

Dijkstra, E. W. (1976). A discipline of programming. Prentice-Hall.Duoence, R., Fradet, P., & Südholt, M. (2002). Detection and resolution of aspect

interactions. TR No. 4435, INRIA, France. ISSN:0249-6399.Durr, P., Staijen, T., Bergmans, L. & Aksit, M. (2005). Reasoning about semantic

conflicts between aspects. In K. Gybels, M. D’Hondt, I. Nagy, R. Douence (Eds.),Second European interactive workshop on aspects in software.

Friedman-Hill, E. (2003). Jess in action. Manning Publications. ISBN:1-930110-89-8.Giarratano J. & Riley G. (2004). Expert systems: Principles and programming (4th ed.).

Course Technology. ISBN:978-0534384470.Hirschfeld, R. (2001). AspectS – AOP with squeak. In Proceedings of OOPSLA.

Workshop on advanced separation of concerns in object-oriented system. USA.Hursch, W., & Lopes, C. (1995). Separation of concern. Northeastern University. TR.

NU-CCS-95-03.Kessler B., & Tanter E. (2006). Analyzing interactions of structural aspects. In

Workshop AID in 20th European conference on object-oriented Programming(ECOOP).

Kiczales, G., Lamping, J., Mendhekar, A., Maeda, C., Lopes, C., & Loingtier, J. (1997).Aspect-oriented programming. In Proceedings of the 11th European conference onobject-oriented programming (ECOOP). Finland.

Kiczales, G., Hilsdale, E., Hugunin, J., Kersten, M., Palm, J., & Griswold, W. (2001). Anoverview of AspectJ. In J. L. Knudsen (Ed.), Proceedings of the 15th Europeanconference on object-oriented programming (ECOOP). LNCS (Vol. 2072,pp. 327–353). Hungary: Springer-Verlag.

Lieberherr, K. (1996). Adaptive object-oriented software: The Demeter method withpropagation patterns. PWS Publishing Company.

Lopes, C., & Ngo, T. (2004). The aspect oriented markup language and its support ofaspect pluggings, technical report # UCI-ISR-04-08. Institute for SoftwareResearch – University of California.

Monga, M., Beltagui, F., & Blair, L. (2003). Investigating feature interactions byexploiting aspect oriented programming. TR N comp-002. Lancaster University,England.

Nagy, I., Bergmans, L., & Aksit, M. (2006). Composing aspects at shared join point. InWorkshop AID in 20th European conference on object-oriented programming(ECOOP).

Pawlak, R., Duchien, L., & Seinturier, L. (2005). CompAr: Ensuring safe around advicecomposition. In FMOODS 2005, LNCS (Vol. 3535, pp. 163–178).

phpAspect (2007). http://phpaspect.org/wiki/doku.php, accessed December 2007.Piveta, E., & Zancanella, L. (2003). Aspect weaving strategies. Journal of Universal

Computer Science, 9(8).Pryor, J., Diaz Pace, A., & Campo, M. (2002). Reflection on separation of concerns.

RITA, 9(1).ROOTS ‘‘LogicAJ–A Uniformly Generic and Interference-Aware Aspect Language”.

<http://roots.iai.uni-bonn.de/researh/logicaj/> Accessed December 2007.Storzer, M., Krinkle, J. (2003). Interference analysis for AspectJ. FOAL: Foundations

of Aspect-Oriented Languages.Tanter, E., Noye, J. (2005). A versatile kernel for multi-language AOP. In Proceedings

of the fourth ACM SIGPLAN/SIGSOFT conference on generative programming andcomponent engineering, LNCS (Vol. 3676, pp. 173–188). Estonia: Springer-Verlag.

Tarr, P., Ossher, H., Harrison, W., & Sutton, S. M., Jr. (1999). N-degrees of separation:Multi-dimensional separation of concerns. Proceedings of 21st ICSE.

Tessier, F., Badri, M., & Badri, L. (2004). A model-based detection of conflictsbetween crosscutting concern: Towards a formal approach. In: Internationalworkshop on aspect-oriented software development.

Yu, Y., & Kienzle, J. (2004). Towards an efficient aspect precedence model. In:Proceeding of the dynamic aspects workshop (pp 156–167).

http://docs.codehaus.org/display/AW/AOP+Benchmark

http://docs.codehaus.org/display/AW/AOP+Benchmark

http://www.cs.ubc.ca/labs/spl/projects/aspectc.html

http://aspectj.org

http://phpaspect.org/wiki/doku.php

http://roots.iai.uni-bonn.de

Expert in conflicts

Documents

Transcript of Expert in conflicts