International Journal of Software Engineering and Its Applications Vol. 3, No.3, July, 2009
MEDIATOR: an AOP Tool to Support Conflicts among Aspects 1 1
Sandra I. Casas, 2J. Baltasar García Perez-Schofield, and 3Claudia A. Marcos
Unidad Académica Río Gallegos, Universidad Nacional de la Patagonia Austral Río Gallegos, Argentina, 9400 2 Departamento de Informática, Universidad de Vigo Orense, España, 32004 3 Instituto de Sistemas de Tandil, Universidad Nacional del Centro Tandil, Argentina, 7000
[email protected],
[email protected],
[email protected] Abstract
The issue of conflicts among aspects is not new, however the handling of conflicts is still an open problem. First, the detection of conflicts is a manual task in most of the AOP tools. Second, in general the resolution of conflicts is enclosed to order-schemes. The handling of conflicts can be problematical if the programming tool does not supply suitable structures and specific mechanisms. MEDIATOR is an environment programming that extends Java language to support AOP, with specific and flexible mechanisms to manage conflicts among aspects. The detection of conflicts is an automatic process and the resolution of them is implemented by explicit and symbolic rules. Keywords: Aspect-oriented programming,- aspect interactions, AspectJ
1. Introduction Aspect-Oriented Programming (AOP) [1] is a new programming approach that allows developers to partition their code based on the application concern. The AOP Languages provides means for proper modularization of crosscutting concerns. In general, an aspect is a unit of code equipped with specific mechanisms to encapsulate the crosscutting concerns, such as point cuts, join-points, advice, inter-types, etc. These constructs are used to weave aspects and components in order to generate the final executable code. A conflict among aspects occurs when two or more aspects compete for their activation [2]. The conflicts among aspects are also called interactions [3], interferences [4] or superimpositions [5]. The issue of conflicts among aspects is not new, however the handling of conflict is still an open problem. First, the detection of conflicts is a manual task in the most of the AOP tools. Second, the resolution of conflicts is enclosed to orderschemes. For example, AspectJ [6] does not detect the conflicts among aspects and the only possibility of resolution is based on declaring the aspects precedence in conflict. A similar approach is adopted by others tools such as Spring AOP Framework [7]. The handling of conflicts is far to be a trivial task if the programming tool does not supply suitable structures and specific mechanisms. Again, in AspectJ [6], the precedence declaration can be placed either in the aspect that defines the advice, or in other independent aspects; the circular relationships among aspects are detected only if they are superimposed on the same concrete join-point. The precedence is defined at the level of aspects, which implies that different pairs of advice of the same two aspects cannot have
33
International Journal of Software Engineering and Its Applications Vol. 3, No.3, July, 2009
different precedence. As in most of the other AOP languages, in AspectJ, conditional executions are not supported. These shortcomings present several drawbacks, such as the re-codification of the aspects, the difficulty in the maintenance and the lower reutilization of aspects [8]. In this work the environment programming tool MEDIATOR is presented. MEDIATOR extends Java to support AOP. But the main advantage of this tool is that provides a flexible, powerful and complete support to handling conflicts among aspects. This work is structured as it follows: in Section 2 MEDIATOR tool is presented, in section 3 the implemented weaving process is explained; in Section 4 the experimental validations are discussed; in Section 5 some related works are exposed; while in Section 6 the final conclusions are presented.
2. MEDIATOR MEDIATOR extends Java with three units: aspects, associations and rules. An aspect is an independent unit composed by a group of methods and fields and encapsulates specific crosscutting concern logic. Aspects are units of code, that they do not declare any crosscut information such us the join-points, pointcuts or advice. For example, Logging aspect represents a typical crosscutting concern. The consoleLogOperation and fileLogOperation methods register the execution of a system. Only the behaviour of Logging crosscutting concern is represented. aspect Logging { public void static consoleLogOperation(..) { // send message to the console } public void static fileLogOperation(..) { // save the message in a file } }
The associations are entities defined in a separated way, instead of being tied to aspects. They link aspects with classes. That is to say, an association describes a relationship between an aspect and a class. An association is always a one-to-one relationship. The wildcards are allowed to denote a set of join-points. An additional mechanism transforms this n-to-one relationship in n associations. association LogOperation { after public void Operation.setAmount(float); call public void Logging.consoleOperation(“Account”, “setAmount”); priority = 12; }
The LogOperation association relates the Operation class with Logging aspect. Each time Operation.setAmount() method is executed, the Logging.consoleOperation() method is executed afterwards. The priority of the association is a numerical value which is used to solve conflicts. Sometimes the aspects need dynamic information of the intercepted object, such as the arguments of the method or the objects. This mechanism is called “context passing”. In MEDIATOR it is defined in the associations, with the same syntax that Javassist [8].
34
International Journal of Software Engineering and Its Applications Vol. 3, No.3, July, 2009
A resolution rule is a mechanism to solve conflicts among aspects. In MEDIATOR, a conflict ocurrs if two or more associations define the same class member, the same relationship cut and the same relationship advice. A resolution rule is an entity that defines a resolution action for n (n ≥ 1) conflicts of a program, where each conflict is composed by m associations (m ≥ 2). A resolution rule has two parts: the antecedent (condition) and the consequent (action). The antecedent identifies the group of conflicts that the rule will solve. And the consequent part specifies a precise action of resolution of the associations in conflict. The action of resolutions will be used for the weaving. The rules can be explicit or symbolic. The explicit rules require that the condition is specified in a concrete way. That is to say, it must be indicated the associations in conflict. In the action part, these associations are specified such as part of the resolution action. ExplicitRule ER {
// antecedent => order (asoc3,asoc1,asoc2) // consequent }
For example, the explicit rule ER defines a solution for the conflict provoked by asoc1, asoc2 and asoc3 associations. The resolution action orders these associations in a particular way. The resolution actions that an explicit rule can apply are the following ones: -
Order: Defining an execution order for associations in conflict.
-
Inverse Order: Defining an execution reverse order for associations in conflict.
Optional: Defining an optional condition execution over associations in conflict. This condition can be a system or a context policy. -
Exclusion: Removing from the execution some associations in conflicts.
-
Nullity: Defining nullity execution (removing) over all associations in conflicts.
An explicit rule can be still more flexible owing to the fact that the resolution action can be combined in the consequent part. ExplicitRule ER_1 { => order (asoc3,asoc1); excluded (asoc2); }
ExplicitRule ER_2 { => if (cond) order (asoc3,asoc1); else excluded (asoc2); }
For example the ER_1 explicit rule applies a combination of order and excluded resolution actions. While ER_2 explicit rule applies a combination of optional, order, and excluded resolution actions. Therefore, an explicit rule solves only one conflict. Using this strategy the developer must specify for each existent conflict an explicit rule. In consequence, the process of detection of conflicts must be carried out previously. The symbolic rules apply a resolution action in order to solve subsets of conflicts. In the antecedent of the rule is specified a condition. The resolution action only will be applied to the conflicts which satisfied the condition imposed.
35
International Journal of Software Engineering and Its Applications Vol. 3, No.3, July, 2009
SymbolicRule SR_1 { < class = Account> => OBP }
SymbolicRule SR_2 { < all> => EGP }
For example the symbolic rule SR_1 defines OBP resolution action only for conflicts on Account class. While the symbolic rule SR_2 defines EGP resolution action for all conflicts. The symbolic rules can be absolutely general or partially general. As much as general is the antecedent of the rule, more conflicts will embrace the resolution action defined in the consequent part. If the antecedent is more specific, then less amount of conflicts will be affected by the consequent part of the rule. The specification of a symbolic rule does not require to know or to define the conflict. The conflicts will be known at the moment that the rule is applied. The resolution actions that a symbolic rule can apply are the following ones: OBP (order by priority): the associations in conflict are ordered downwardly by their priority. IOBP (inverse order by priority): the associations in conflict are ordered upwardly by their priority. -
OF (order First): one association of the conflict is ordered first.
-
OL (order Last): one association of the conflict is ordered last.
-
ETA (exclude this association): one association of the conflict is excluded.
EAA (exclude all associations): all associations except one of the conflict are excluded. ELP (exclude less priority): the association in conflict with less priority is excluded. EGP (excluded great priority): the association in conflict with great priority is excluded Nullity: it annuls all the associations in conflict of the weaving-execution processes. A specific symbolic rule can embrace more one conflict, and each of these conflicts can be outlined by different amount of associations. 2.1 Detection of conflicts and rules. Detection of conflicts is an automatic process in MEDIATOR. Besides, this process is independent of weaving, compilation and execution. The detection of conflicts operates such as is indicated in Figure 1. The associations defined are analyzed to generate a list of conflicts. If two or more associations have the same cut relationship, advice relationship and the same functional component (class and method), a conflict is created in the list. A conflict entity has all the information about the conflict. Afterwards, the developer can define the explicit rules using the list of conflict. On the other hand, the automatic process called “checking symbolic rules” verifies the list of conflict and symbolic rules to identify which is the conflict that satisfies the condition. It generates for each symbolic rule a set of validate resolution sentences. Then a symbolic rule can solve some conflicts.
36
International Journal of Software Engineering and Its Applications Vol. 3, No.3, July, 2009
associations
Detection of Conflicts
Checking Condition Symbolic rule
kkkkkk kkkkkkkkkk kkkkk oooooo
List of Conflicts
Explicit Rule Definition Explicit rule
Resolution Sentences
Figure 1. Detection of conflicts and rules.
2.2 Solving interferences between rules MEDIATOR incorporates other automatic processes in order to avoid ambiguity and interference situations in the weaving. First, two symbolic rules can generate different resolution actions for the same conflicts. The strategy to solve these interferences removes the generated resolution sentences by the more general symbolic rule. Second, in MEDIATOR the explicit rules and symbolic rules are complementary, that is to say, the developer can define both kinds of rules in the same application. Then an explicit rule can interfere with a symbolic rule, when both try to solve the same conflicts. In these cases, the generated resolution sentences by symbolic rules are removed. These strategies to solve interferences between rules are the default configuration of MEDIATOR. Another possibility is not to eliminate automatically any resolution sentences, and that the developer selects manually the resolution sentences or explicit rules to be removed.
3. Weaving Associations & Rules In MEDIATOR the weaving is a process that requires associations and rules and it is performed in two phases. The complete scheme is illustrated in Figure 2. The first weaving phase occurs in compilation time and the second phase occurs in load time. During the former phase, four operations take place: (i) unification of rules; (ii) transformation of the aspects in classes; (iii) linking class generation; (iv) class files generation. The unification of rules and linking class generations are the main functions. The CompilerManager component converts the resolution sentences (generated from symbolic rules) into explicit rules. The resolution sentences are is mapped into resolution actions of explicit rules and new explicit rules are created. In Table 1, it is shown how the resolution sentences are transformed in a condition and action of an explicit rule. This transformation is necessary because of the weaving requires explicit rules. Then these new explicit rules and the original explicit rules conform the set called “unificated explicit rules”. The AspectWeaver component generates automatically the linking class next. All the information for this task is in the associations and unificated explicit rules. The methods of this class are called linking methods. These methods relate functional components to the aspects. In Figure 3 the link_Met1() linking method is shown which is
37
International Journal of Software Engineering and Its Applications Vol. 3, No.3, July, 2009
generated from the LoggAcc association. The link_met1() method invokes the execution of the Logging.log() aspect method, defined in the LoggAcc association. Phase 2: Execution Time dtlm LoaderManager
aspects (.class) aaaaaaaaaaaa wwwwwwwwwww dddddddddddddd ssssssssss
kkkkkk kkkkkkkkkkkkkkk oooooo
aaaaaaaaaaaa wwwwwwwwwww dddddddddddddd ssssssssss
linking class
classes (.class)
associations AspectWeaver kkkkkk kkkkkkkkkkkkkkk oooooo
explicit rules CompilerManager resolution sentences
explicit rules unificated
Phase 1: Compilation Time
Figure 2. Weaving Proccess Table 1. Tranformation of resolution sentences into explicit rules Resolution sentences (OBP (asoc2) (asoc1)) (IOBP(asoc1) (asoc2)) (OL (asoc2) (asoc1)) (OF (asoc2) (asoc1)) (ETA (asoc1)) (EAA (asoc1)(asoc2) (ELP (asoc1)) (EGP(asoc1)) (ANULLED(asoc1)(asoc2))
38
Explicit Rules Condition: Action: order(asoc2,asoc1) Condition: {asoc1, asoc2} Action: order (asoc1, asoc2) Condition: {asoc2, asoc1} Action: order(asoc2,asoc1) Condition: {asoc2, asoc1} Action: order(asoc2,asoc1) Condition: {asoc1} Action: excluded (asoc1) Condition: {asoc1, asoc2} Action: excluded (asoc1,asoc2) Condition: {asoc1} Action: excluded (asoc1) Condition: {asoc1} Action: excluded (asoc1) Condition: {asoc1, asoc2} Action: anulled (asoc1, asoc2)
International Journal of Software Engineering and Its Applications Vol. 3, No.3, July, 2009
association LoggAcc { after public void Account.debit(); call public void Logging.log(); priority = 10; }
class Linking_Class { public static void link_met1() { Logging.log(); }
Figure 3. Linking Method of an association
The previous example is validated for associations free of conflicts. When the associations to weave are in conflict, the process is carried out in a similar way. In the first phase the explicit rule is required together with the associations. The linking method concentrates the logic of resolution of conflict. association LogAcc { association StatAcc { after public void Account.debit(); after public void Account.debit(); call public void Logging.log(); call public void Statistic.reg(); priority = 10; } priority = 10; } ExplicitRule rx {
=> order (StatAcc, LogAcc);} public static void link_metX() { Statistic.reg(); Logging.log; }
Figure 4. Linking Method of Explict Rule
For example, in Figure 4 the LoggAcc and StatisAcc associations have been defined. The LoogAcc and StatisAcc associations are in conflict. The rx explicit rule has been defined to solve this conflict. Then, in the compilation process, the action order (LoggAcc, StatisticAcc) is employed to the weaving. Besides, both associations are merged into a unique linking method. The method encapsulates the logic of resolution of the conflict. This logic comes from the category resolution of conflict in the defined explicit rule. At the same time the linking class is being generated, the dynamic table of linking methods is created with the necessary information for the next weaving phase. Each input in this table represents the functional component to crosscut, the relationship type (before or after) and the linking method. Following the previous examples, the table dtlm = {(Account, extract, after, link_Met1), (Account, debit, before, link_Met2) } is created. The latter phase proceeds during the execution of the application. In load-time those classes affected by the associations are linked to the linking methods, according to the relationship type (before or after). This operation is simple due to the fact that a customize class-loader (LoaderManager component) employs the dynamic table (dtlm) of linking methods. This process has been implemented by means of the Javassist API [8]. For example, in Figure 5, it is shown how the inputs of dtlm table are used to insert in Account class invocations to the linking class. The bytecode modification of Account class is “on the fly”. dtlm = {(Account, extract, after, link_Met1), (Account, debit, after, link_Met2) } class Account { public void extract (..) -----
{
39
International Journal of Software Engineering and Its Applications Vol. 3, No.3, July, 2009
Linking_class.link_met1(); } public void debit (..) { Linking_class.link_met2(); ----} }
Figure 5. Bytecode modification.
Another issue that the LoaderManager component has to consider is the context passing. If the associations declare any information of the object, then the inserted link must pass arguments or “this” reference. In summary, in the functional component affected by any association is inserted a call to a linking method, according to the type of relationship of the association. The linking method invokes the aspect method directly, or it can include a group of sentences that apply a category of resolution of conflict. Therefore, the following advantages are obtained: (i) the classes do not have any knowledge about what aspect cuts them; (ii) the aspects preserve their original state and they can be associated to any other functional component (iii) the conflict resolutions are hidden in the linking class, being specific for a certain application. Finally, if a new association or rule is defined it is only necessary to generate the linking class and it is not necessary to compilate the other units (classes and aspects).
4. Experimental Validation In this section a set of experiments to evaluate the performance of MEDIATOR are presented. The experiments are based on A class with met method, and two crosscutting concerns CC1 and CC2. Each test was performed in 3 versions: Java-Version, AspectJVersion and MEDIATOR-Version. The six tests carried out are described in Table 2. Table 2. Experimental Tests performed. Test 1: before 2: before+args 3: before+args+this 4: before+befote 5: after+after 6: before+before+after+after
Description The crosscutting concern cc1 is executed before the met method of C class. The crosscutting concern cc1 is executed before the met method of C class and it requires the arguments of met. The crosscutting concern cc1 is executed before the met method of C class and it requires the arguments of met and the C object (this). The crosscutting concerns cc1 and cc2 are executed before the met method of C class. The crosscutting concerns cc1 and cc2 are executed after the met method of C class. The crosscutting concerns cc1 and cc2 are executed before and after the met method of C class.
The tests 1, 2 and 3 allow evaluating and comparing a simple execution of invocation or interception of an aspect and how the context passing affects this operation. The tests 4, 5 and 6 allow evaluating and comparing the execution of conflicts among aspects. A loop of 1.000.000 of invocation of C.met() was executed to compute the average execution time for each version. Timing was taken using the standard System.currentTimeMillis() method, which has a resolution of 10ms or less, depending on the operating system. The environment of execution of the experiment was the following: -
40
Machine:Intel Centrino RAM 1GB Operative System: Microsoft Windows XP Professional
International Journal of Software Engineering and Its Applications Vol. 3, No.3, July, 2009
-
JVM: Java 1.5.0_9 (J2SE 5.0) AspectJ: 1.5 Javassist: 3.2
The results of the experiments are presented in graphs of Figures 6 and 7. First, in Figure 6 it is demonstrated that the passing context does not cause an overload in Java and MEDIATOR. In AspectJ the passing of “this” reference is slower in terms of the time of execution. MEDIATOR, in these tests, has the same performance than the Java Version. Java
AspectJ
MEDIATOR
50 45 40 35 30 25 20 15 10 5 0 1: before
2: before+args
3: before+args+this
Figure 6. Results of simple interception and passing context. Java
AspectJ
MEDIATOR
70 60 50 40 30 20 10 0 4: before+before
5: after+after
6: before+before+after+after
Figure 7. Results of execution of conflict among aspects.
In Figure 7, once again the MEDIATOR performance is similar to Java Version, and the AspectJ version is slower. The weaver of AspectJ inserts direct hooks in the classes to the aspects. This strategy seems to be more efficient than the linking class because it is more direct in the execution of the invocation of the aspect. But AspectJ provides a special reference variable “thisJoinPoint” that contains reflective information about the current join point for the advice to use. The creation of thisJoinPoint variable provokes the overload owing to it is a dynamic operation.
5. Related Works 41
International Journal of Software Engineering and Its Applications Vol. 3, No.3, July, 2009
AspectJ [6] is the most advanced and mature AOP environment currently available. The static weaver “ajc” does not detect when two or more pointcuts or advice intercept the same joint-point. The order of advice is defined with declaration of precedence statement. When multiple pieces of advice all want to run at the same join-point, Spring [7] AOP Framework follows the same precedence rules as AspectJ to determine the order of advice execution. When two pieces of advice defined in different aspects both need to run at the same join point, unless the developer specifies otherwise, the order of execution is undefined. The order of execution can be controlled by specifying precedence. This is done in the normal Spring way either by implementing the org.springframework.core.Ordered interface in the aspect class or by annotating it with the Order annotation. When two pieces of advice defined in the same aspect both need to run at the same join point, the ordering is undefined In Table 3, a summary of different AOP language and their capacity to handling conflicts is presented. Here the list of analyzed tools includes different weaving approach and base language. The conclusion is the handling of conflicts among aspects is still an open problem and MEDIATOR overcomes all of them in this issue. The Model of Interactions [17] is similar to MEDIATOR. The authors propose to represent the aspects such as components and the aspectual relationships in “Interaction” units. The Interactions are a mixture of associations and explicit rules. An Interaction Specification Language (ILS) is provided. This language provides a set of operators which defines weaving rules (“merging"). The operators apply different resolutions to the conflicts: conditional execution, mutual exclusion, order, and the sequential or concurrent composition. All the interactions on the shared join-points are mixed in an unique interaction (it unifies advice after and before). The interactions are defined in singular form, after an automatic mixture process generates the final interaction. Table 3. AOP Language Comparation AOP Language AspectC++ [9] AOP/ST [10] phpAspect [11] JAC [12] CAMEO [13] AspectR [14] µDyner [15] microDyner [16] MEDIATOR
Base Language C++ Smalltalk PHP Java C# Ruby C++ C++ Java
Static Dynamic Static Dynamic Static Static Dynamic Dynamic
weave Conflicts? YES YES YES YES YES YES NO NO
Automatic Detection NO NO NO NO NO NO -
Static
YES
YES
Weaver
Resolution Order Order None Order Order None Order Optional Exclusión Nullity
Another similar approach is Aspect-Markup Language (AML) [18]. In AML, an aspect-oriented program consists of three elements: core modules, aspectual modules and aspect bindings. Core and aspectual modules are developed in the base language; these entities are similar to classes and aspects in MEDIATOR. The aspect bindings are specified in AML, and are similar to a set of associations. All aspectual relationship (pointcuts, advice, etc.) related with an aspectual module are encapsulated in an aspect binding. Aspect binding is XML-based binding specification. It is provided binding
42
International Journal of Software Engineering and Its Applications Vol. 3, No.3, July, 2009
instructions that determine how core and aspectual modules are unambiguously composed to produce the final behaviour. In general, an aspect binding file contains a mixture of predefined XML elements called core elements and user-defined XML elements called custom elements. The authors do not highlight specific syntactic and semantic mechanisms for handling of conflicts.
6. Conclusions In this article a novel tool to develop aspect-oriented application has been presented. MEDIATOR is based on following premises: (i) the crosscutting concerns logic is implemented in aspect units; (ii) the mechanics (pointcuts, advise, join-point) to relate the aspects with functional components are defined in associations; (iii) the conflict resolutions are declared in rules. The rules can be explicit or symbolic. An explicit rule solves a conflict, while a symbolic rule solves a set of conflicts. The rules can apply a variety of the actions of resolution. In MEDIATOR, the detection of conflicts is an automatic process. Also, the interferences between rules are identified and solved in an automatic way in MEDIATOR. These strategies improve the handling of conflicts and the aspects reuse. The weaving strategy makes the code of aspects and classes (source and compiled) remains intact. Therefore, the aspects and classes are not contaminated either by the associations, or by the conflict resolutions applied. These features make this approach very flexible, effective and powerful in order to handle the conflicts.
References [1] Kiczales G., Lamping J., Mendhekar A., Maeda C., Lopes C., Loingtier J. and Irwin J. (1.997) “AspectOriented Programming”. In Proceedings of the 11th European Conference on Object-Oriented Programming (ECOOP), Finland. [2] Pryor J., Diaz Pace A. and Campo M. (2.002) Reflection on Separation of Concerns. RITA. Vol.9. Num.1 [3] Douence R., Fradet P. and Südholt M. (2.002) “Detection and Resolution of Aspect Interactions”. TR Nº4435, INRIA, ISSN 0249-6399, France. [4] Katz S., Rashid A. (2004). “From Aspectual Requirements to Proof Obligations for Aspect-Oriented Systems”. International Conference on Requirements Engineering (RE), Japon, IEEE Computer Society Press. Pp 48-57, 2.004. [5] Katz S., Gil J. (1999). “Aspects and superimpositions”. In ECOOP Workshops, pp 308–309, 1.999. [6] Kiczales G., Hilsdale E., Hugunin J., Kersten M., Palm J. and Griswold W. (2.001) “An Overview of AspectJ”. In J. L. Knudsen, editor, Proceedings of the 15th European Conference on Object-Oriented Programming (ECOOP), Num. 2072 in LNCS, pp 327–353, Springer-Verlag. Hungary. [7] Spring Framework – Chapter 6. http://www.springframework.org/docs/reference/aop.html (23/09/2007) [8] Chiva S. (1.998) “Javassist – A Reflection – based Programming Wizard for Java”. Proceeding of the ACM – OOSPLA. Workshop on Reflective Programming in C++ and Java. Canada. [9] Gal A., Schroder W., Spinczyk O. (2001). “AspectC++: Language Proposal and Prototype Implementation”. ACM International Conference Proceeding Series Proceedings of the Fortieth International Conference on Tools Pacific. Vol.10. Australia. 2.002. [10] Boellert, K. (1999). "On Weaving Aspects", Proc. of the AOP Workshop at ECOOP 1.999. [11] phpAspect WEB Site: http://phpaspect.org/wiki/doku.php [12] Pawlak P., Seinturier L., Duchien L. y Florin G. (2001). “JAC: A flexible solution for aspect-oriented programming in Java”. Proceedings of Reflection 2001, LNCS 2192, pp 1-21, Japon 2.001. [13] Prasad M., Chaudhary B. (2003). “AOP Support for C#”. 2nd Workshop on Aspect, Components and Patterns for Infrastructure Software – AOSD – USA, 2.003. [14] AspectR WEB site: http://aspectr.sourceforge.net/ [15] Chen Y. (2003). “Aspect – Oriented Programming (AOP): Dinamic Weaving for C++”. Master thesis, Vrije Universiteit Brussel and Ecole des Mines de Nantes, 2.003. [16] Segura-Devillechaise M., Meneaud J. (2003). “microDyner: efficient dynamic weaving of aspects in native running process”. Langages et Modeles a Objets, LMO 2.003, pp. 119-133, Francia, 2.003.
43
International Journal of Software Engineering and Its Applications Vol. 3, No.3, July, 2009
[17] Charfi A., Riveill M., Blay-Fornarino M., Pinna-Dery A. (2006) “Transparent and Dynamic Aspect Composition”, Workshop on Software Engineering Properties of Languages and Aspects Technologies, VII AOSD – Germany – 2.006 [18] Lopes C. and Ngo T. (2004) “The Aspect Oriented Markup Language and its Support of Aspect Plugings”, Technical Report # UCI-ISR-04-08, Institute for Software Research – University of California.
Authors
Sandra Casas is a Professor of Universidad Nacional de la Patagonia Austral (UNPA) since 1995. She has obtained the Master degree in Software Engineering in 1999 from Universidad de Deusto (Spain) and she received her PhD in computer science from the University of Vigo. (Spain). Since 2005 she is working in Aspect-Oriented Programming research area. J. Baltasar García Perez-Schofield is a lecturer in computer science at the University of Vigo. His research interests include persistence and object orientation, especially as related to virtual machines and dynamic languages. He received his PhD in computer science from the University of Vigo. Claudia Marcos has been a Professor in the School of Computer Science at Universidad Nacional del Centro de la Provincia de Buenos Aires (UNCPBA) since 1998. Her main research area is in aspect-oriented development, UML and agile development. Dr Marcos received her B. S. degree in Software Engineering from the UNCPBA State University in 1993. She obtained her PhD degree in Computer Science in 2001.
44
