Aspect Composition in the Motorola
Aspect-Oriented Modeling Weaver
Jing Zhang, Thomas Cottenier, Aswin van den Berg, and Jeff Gray
|
 |
REFEREED
ARTICLE
PDF Version |
Abstract
One of the fundamental issues in Aspect-Oriented approaches is aspect-to-aspect
interference, which occurs when multiple aspects are deployed jointly such that different
composition orders may give rise to various inconsistency problems. This paper
describes how aspect precedence can be specified explicitly at the modeling level in
order to derive a correct composition order and therefore reduce the aspect interference
problem in Aspect-Oriented Modeling (AOM). The paper presents a modeling approach
to achieve aspect reuse by introducing three distinct categories of aspect composition
mechanisms. These composition concepts have been implemented in the Motorola WEAVR, which is an AOM weaver developed at Motorola as a plug-in component for
Telelogic TAU G2.
1 INTORDUCTION
Aspect-Oriented Modeling (AOM) [AOM] is an Aspect-Oriented Software Development
(AOSD) [AOSD] extension applied to earlier stages of the software lifecycle. AOM aims
at supporting separation of crosscutting concerns at the modeling level, with the purpose
of enhancing productivity, quality and reusability through the encapsulation of
requirements that cut across software components.
One of the fundamental issues in AOSD is the potential conflicts that may occur in
the presence of interactions among aspects (i.e., when multiple aspectual behaviors are
superimposed at the same joinpoint, different composition orders may reveal various
inconsistency problems). In such circumstances, the aspects interfere with each other in a
potentially undesired manner, either due to the side-effects caused by the aspects (e.g.,
several aspects change the state of the base program simultaneously) or due to the
requirements enforced by the system (e.g., the logging aspect may be applied only in the
presence of the encryption aspect because some particular systems require all logged data
to be encrypted). A number of aspect interference examples have been described in [Durr,
Kienzle06, Lagaisse, Nagy, Pawlak, Sihman].
Several techniques have been proposed and developed to resolve or reduce aspect
interference. For the most light-weight approach, the execution orders between aspects
are governed by declaring precedence relationships, such as in AspectJ [AspectJ] and
some aspect modeling approaches [Reddy]. Some other approaches extend the simple
precedence declaration and introduce more complex dependencies and ordering
relationships between aspects, such as [Kienzle03, Nagy]. Aspect interactions can be
identified through static analysis on the crosscutting concerns and the base module
[Douence02, Stoerzer06]. Advanced approaches require extra behavior specifications
from the user for each advice [Durr, Pawlak] or each aspect [Lagaisse, Sihman]. The
conflict between aspect semantics can then be detected automatically based on the
specified contracts.
The problem of aspect interference is intrinsic to every AOSD technique (i.e.,
interference is at the essence of aspects due to the focus of multiple concerns that may
crosscut at common locations). As an initial step towards resolving the interference issue
in AOM, we adopt a light-weight approach following and extending the AspectJ
[AspectJ] notation. This paper is not intended to analyze and detect the interference
between aspects, nor does it concentrate on reasoning about the correctness of the system
after composing multiple aspects simultaneously. Instead, we describe how aspect
precedence can be specified explicitly at the modeling level in order to reduce the
occurrences of aspect interference in AOM. Based on the precedence declarations, the
underlying composition mechanism will derive an appropriate weaving and execution
order automatically.
Furthermore, the paper presents a unique and powerful mechanism for pointcut
specification based on state machines. The paper also shows how to facilitate aspect reuse
to a larger extent by introducing three distinct categories of aspect composition
mechanisms (i.e., pointcut composition, advice composition, and aspect composition).
The approach has been implemented in the Motorola WEAVR, which is an AOM plug-in
for weaving aspects into executable UML state machine models in Telelogic TAU G2
[TAU]. The main benefit of this work is to improve the expressiveness and reusability of
crosscutting concerns by handling aspect interference and composition at a higher level
of abstraction.
The remainder of the paper is structured as follows. Section 2 gives a brief overview
of the Motorola WEAVR, including its basic language constructs and weaving procedure.
Section 3 further illustrates the aspect definition and pointcut designators by examples.
Section 4 presents the three categories of the composition mechanisms that have been
implemented in the current version of the WEAVR. Section 5 discusses the related work
about aspect interference and composition. The paper concludes in Section 6 by
summarizing contributions and ongoing work.
2 MOTOROLA WEAVR
The most essential feature of the Motorola WEAVR is to enable aspect-oriented weaving
for UML statecharts that include action semantics [OMG]. By weaving aspects into
executable UML models, the platform-specific models and the source code can be
generated in an automated manner. This section provides a background introduction to
the WEAVR in order to set the context for our contribution in aspect composition in
models.
Two fundamental language constructs are introduced in the WEAVR. First, we need
to specify the “where” (i.e., the locations, or joinpoints, in the models where the
crosscutting behavior emerges). Based on the UML concepts that actions are executed
during a transition from one state to another state, two distinct types of joinpoints are
supported in the WEAVR: action and transition joinpoints, referring to the actions and
transitions declared in the state machines, respectively. Examples of action joinpoints are
variable definition, assignment, new operation, signal output, timer set, and expression
method/constructor invocation. Transition joinpoints capture sequences of execution
paths (e.g., from one state to another state, or from the starting point to the return point of
a method execution) within a state machine.
A set of particular joinpoints are encapsulated in a pointcut, specially denoted by
one of two dinstinct UML stereotypes: <<ActionPointcut>> or <<TransitionPointcut>>. The notation used for both types of pointcuts is
identical: a pointcut is always represented as a transition from a set of source states to a
set of target states. A pointcut has an interface that can specify the particular parameters
exposed at the identified joinpoints. Further explanation of pointcut designators will be
provided in the next section.
Second, we need to specify the “what” (i.e., the behavior of the crosscutting
concern). In the WEAVR, this behavior is implemented using state machines and
encapsulated into a special kind of construct stereotyped by the name <<advice>>. An
advice is named, containing the proceed operation, reflective API calls, as well as several
parameters that are bound to the pointcut parameters.
Pointcuts and advice are encapsulated in an aspect, stereotyped by the name <<aspect>>. Aspects can own multiple pointcuts and advice. An aspect contains a
binding diagram that defines what advice are bound to which pointcuts. Those bindings
are stereotyped by the name <<binds>>. Aspects are applied to the base models
through a deployment diagram.
Two phases are involved in the weaving process: advice instantiation and advice
instance binding. During the first phase, advice are instantiated based on the pointcuts
they are bound to, with most of the calls to the reflective API resolved. The proceed operation is replaced by the original joinpoint action. Matched joinpoints are annotated
and linked to the corresponding advice. At this point, the base model has not been
modified, except for the joinpoint annotations.
During the second phase, the aspects are woven into the base models in one of the
following two ways: wrapping or inlining. In the wrapping mode, the original joinpoint
actions are replaced by an operation call to the corresponding advice instance. For the
inlining version, all advice instances are actually inlined in the base model. By allowing
specific behavioral aspects to be woven into the abstract models, the WEAVR makes the
use of executable UML more practical. For more details about the features of the
Motorola WEAVR, please refer to [Cottenier06, Cottenier07]. The WEAVR resources
and academic free license can be obtained at [WEAVR].
3 POINTCUT DESIGNATORS
The WEAVR offers a unique mechanism for pointcut designators, which enables
joinpoints to be strategically selected from state machine specifications. This section will
illustrate the aspect definition and two distinct types of pointcut designators through an
example based on a simplified authentication process model shown in Figure 1.
Figure 1. A simple authentication process model
This figure illustrates the process of an authentication request from a client to a
server. After the client initiates a request for access, it enters the state of
WaitingResponse, waiting for the reply from the server. Three kinds of responses
(i.e., challenge, accept, and reject) could be received, each of which carries a distinct type
of message. Depending on these different signals, the authentication process will trigger
specific actions that lead to different states. If the challenge signal is received, the client
will have to present an answer for the challenge question and request authentication
again. If the accept signal is received and the actions for handling the signal return
properly, the client will be authenticated. Otherwise, the whole process will terminate.
Figure 2 defines a tracing aspect applied to the authentication model. The aspect
contains one advice that is bound to two pointcuts. The advice tracing wraps the
original joinpoint action (denoted by proceed) by inserting print statements using
reflective API calls (e.g., thisJoinPoint). The actions before proceed are called
Figure 2. A tracing aspect definition with two pointcuts and an advice “before actions” and the actions after proceed are named “after actions.” The action
pointcut procAccessCall captures all the call actions to a method whose name starts
with procAccess (based on regular expression matching) and it may contain any
number of parameters of any type. The transition pointcut accessFailed-Transition matches a selection of execution paths that lead to the state of Stop (represented by the symbol X) after receiving a signal whose name starts with Access.
The joinpoints selected from these two pointcuts are shown in Figure 3. The red solid
bars denotate the “before” and “after” advice actions to be inserted by the matching of the
action pointcut procAccessCall. The green dashed bars delimit portions of execution
paths that match the transition pointcut accessFailedTransition. The marks that
occur first in the execution path correspond to the “before” actions whereas the second
marks refer to the “after” actions. The joinpoint selection mechanism performs static
control flow analysis to determine the earliest points that match the pointcut definition.
The “before” marks are placed at the first location in the execution paths for which the
only reachable next states match the target state of the pointcut designators (i.e., Stop state in this case), and the “after” marks are positioned right before the next state actions.
Figure 3. Selections of joinpoints that match the pointcut definitions in Figure 2 Due to the intrinsic difference of the definitions and the joinpoint selection
mechanisms, action pointcuts and transition pointcuts will never match to the same
joinpoint. (In Figure 3, the two “before” marks after the receiving signal AccessReject are essentially located at two different joinpoints.) Action pointcuts
and transition pointcuts are comparable to the call pointcuts and execution pointcuts in
AspectJ but with more powerful expressiveness.
Figure 4 illustrates a pointcut designator that can be interpreted as either an action
pointcut or a transition pointcut. It captures all the action joinpoints executed in the
context of a transition, as well as all the transition joinpoints that execute any actions in
their context. Therefore, this pointcut matches every single joinpoint in the whole state
machine model.
Figure 4. A pointcut designator to match every joinpoint in the
state machine model The context relationship between action and transition pointcuts also implies a cflow relationship – actions are executed within the control flow of transitions. Suppose in the
authentication example, the actions procAccessChal, procAccessAcc and procAccessRej will all invoke a common routine parse in their control flow, which
is used to analyze the authentication response information. One of the debugging
requirements is, “whenever the parse operation returns an error, print out the values of
the signal parameters that are associated by the signal received in the current context of
transition.” In this example, the authentication process prints chalMsg for AccessChallenge, accMsg for AccessAccept, and rejMsg for AccessReject.
This crosscutting concern can be captured easily by the AccessAspect shown in
Figure 5. The action pointcut ParseMsg matches all the joinpoints where the operation parse (with any number parameters and a Boolean type return value) is invoked in the cflow of the transitions from state WaitingResponse to any target states by a trigger
signal whose name starts with Access. The advice PrintMsg will call the parse routine and check whether the return value is “OK.” If not, the advice will print out the
signal name as well as its parameters for debugging purpose, through the use of thisJoinPoint reflective APIs. Cflow can also be used to compose two poincuts as
will be seen in the next section.
Figure 5. Access aspect definition with an action pointcut and
a print advice 4 COMPOSITIONS IN THE WEAVR
Based on the distinct definition of the aspect constructs introduced in the previous
sections, two kinds of interference problems may occur during the weaving process:
advice-to-advice and aspect-to-aspect. (Note: We do not consider pointcut-to-pointcut
interference in this paper because pointcuts do not own any behavior actions. Analysis on
the pointcut-to-pointcut interference is considered as part of future work.) This section
introduces precedence declarations on advice and aspects. The explicitly specified
precedence constraints reduce undesired interference at the shared joinpoint and will be
passed to the underlying model composition mechanism to compute a proper weaving
order.
Reusability in AOM can be defined as the ability to reuse pointcuts, advice and
aspects. To achieve reusability to the largest extent, we have implemented three distinct
categories of composition mechanisms in the WEAVR (i.e., pointcut composition, advice
composition and aspect composition). In the following sub-sections, each mechanism will
be illustrated in detail and compared to the corresponding AspectJ notation.
Pointcut Composition
In the WEAVR, the pointcut composition semantics strictly follow the AspectJ semantics.
Pointcuts can be composed with Boolean operators to build other pointcuts. The Boolean
expression is specified in a separate text box within the composite pointcut diagram.
(Note: Currently we adopt a primitive and intuitive way to represent the pointcut
compositions. However, the composition syntax can also be specified in a graphical
notation through the extensions of the pointcut metamodel definition.) The supported
Boolean operators are: AND (&&), OR (||) and NOT (!), indicating the intersection,
union and difference of the set of the joinpoint selections, respectively. Furthermore, the WEAVR also supports cflow, cflowbelow and within pointcut designators. As
illustrated in Figure 6, CompositePointcut is constructed by two sub-pointcuts – procAccessCall and accessFailedTransition (see pointcut definitions from
Figure 2), which means that CompositePointcut will pick out joinpoints matched
by procAccessCall that are not in the control flow of any joinpoint picked out by accessFailedTransition. After applying pointcut matching to the authentication
model in Figure 1, the resulting joinpoints will be two method call actions: procAccessChal and procAccessAcc.
One advantage of our approach over AspectJ is that a pointcut can be directly
referenced (e.g., through dragging and dropping in the model view) and reused in any
other aspect. AspectJ, however, only allows the abstract aspect to be reused by
inheritance. Concrete aspects extending an abstract aspect must provide concrete
definitions of abstract pointcuts. Reusing pointcuts among multiple aspects is not possible
in AspectJ.
Figure 6. Pointcut composition Advice Composition
Advice composition intends to bind and execute the advice instances that perform at the
same joinpoint in a certain appropriate order. In the WEAVR, advice are ordered based
on the precedence relationships that are specified by the aspect developers. Currently, we
have implemented the <<follows>> relationship between advice. As shown in Figure
7, Advice2 follows Advice1, which means that at a particular joinpoint (either an
action or a transition joinpoint), Advice1 has precedence over Advice2, and the
instances of Advice2 will be executed closer to the joinpoint than the instances of Advice1 (i.e., the “before” actions in Advice1 instances will always be executed prior
to the “before” actions in Advice2 instances while the “after” actions will be carried out
in the opposite order). In the absence of an ordering constraint, the execution order of the
corresponding advice instances is undefined and controlled by the underlying WEAVR compiler.
Ordering relationships specify a partial order upon the execution of a set of advice
instances. In order to obtain a composition and execution order, a topological sort is
performed on the advice. Circular dependencies among the advice are detected when their
corresponding pointcuts match to the same joinpoint. Under such circumstance, the WEAVR will abort with an error message, indicating the problematic advice involved in
the circularity.
When executing an advice instance, the call to proceed will be redirected to the
invocation of the advice instance with the next precedence, or the computation under the
joinpoint if there is no further advice instance. In the case of Figure 7, suppose Pointcut1 and Pointcut2 both match a single joinpoint (in the following, PCT replaces Pointcut and ADV replaces Advice). The advice instantiation order at this
joinpoint could be:
PCT1–ADV1, PCT2–ADV1, PCT1–ADV2, PCT2–ADV2
Figure 7. Advice composition
If both Advice1 and Advice2 contain a proceed action, the execution order of
the woven model at this joinpoint would be as follows:
- Before actions in the advice instance: PCT1–ADV1
- Before actions in the advice instance: PCT2–ADV1
- Before actions in the advice instance: PCT1–ADV2
- Before actions in the advice instance: PCT2–ADV2
- Original actions at the joinpoint
- After actions in the advice instance: PCT2–ADV2
- After actions in the advice instance: PCT1–ADV2
- After actions in the advice instance: PCT2–ADV1
- After actions in the advice instance: PCT1–ADV1
By comparing our advice composition mechanism with AspectJ, we believe that our
approach offers two advantages:
- In the WEAVR, the concepts of pointcuts and advice are loosely decoupled. An
advice is named, which allows it to be associated with not just one, but multiple
pointcuts as long as they share compatible interfaces. Therefore, an advice can be
directly referenced (e.g., through dragging and dropping in the model view) and
reused in different aspects in a compositional way. In AspectJ, advice is unnamed
and can only be bound to one particular pointcut. The tight coupling between
pointcuts and advice makes aspects difficult to reuse. The only way to reuse
advice in AspectJ is by means of inheritance, which is known to be more brittle
and less flexible than the composition-based solution [Gamma].
- In AspectJ, the precedence of advice relies completely on their textual locations in
an aspect file. The underlying interpretation rules, as stated in the AspectJ
Programmers Guide [AspectJ], declare that, “for two advice within a single
aspect, if either is after advice, then the one that appears later in the aspect has
precedence over the one that appears earlier; otherwise, the one that appears
earlier in the aspect has precedence over the one that appears later.” These rules
have limitations and cannot express all composition orders, as pointed out in
[Herrejon]. Our approach resolves the above problems because there is only one
advice type (i.e., around advice) in the WEAVR, which decreases the complexity
of handling three different types (i.e., before, after and around) of advice as in
AspectJ. Furthermore, by declaring the advice precedence explicitly, the
interference between the advice is reduced.
Aspect Composition
Aspect composition is achieved through a deployment diagram (Figure 8), which is used
to bind aspects to the base models, with the precedence relationships declared. Aspects
can be bound to multiple base models through the stereotype <<crosscuts>> (e.g., ExceptionAspect and TracingAspect are both applied to the base package Authentication). Aspects can also be deployed to other aspects or advice. In the absence of the <<crosscuts>> relationship, aspects will be applied to all the base
models in the current active project (e.g., LoggingAspect and EncryptionAspect). The precedence relationships between aspects can be <<follows>>, <<hidden_by>> and <<dependent_on>>. The remainder of this
section explains these three concepts in detail based on the example provided in Figure 8.
- TracingAspect follows ExceptionAspect: TracingAspect (as
defined previously in Section 3, Figure 2) is used to print out signatures and
parameter values of some particular action and transition joinpoints. ExceptionAspect captures all of the transitions that lead to the stop state
and sends out an exception notice right before the system terminates. There is no “before” advice in ExceptionAspect. The <<follows>> relationship
between these two aspects means that at a single joinpoint, ExceptionAspect
has higher precedence than TracingAspect. Therefore, all of the advice in the ExceptionAspect have higher precedence than the ones in the TracingAspect. In other words, the advice instances instantiated from TracingAspect will be executed closer to the joinpoint than the ones
instantiated from ExceptionAspect. The execution order of the woven model
at this shared joinpoint would be as follows:
- Before advice instance in TracingAspect
- Joinpoint action(s)
- After advice instance in TracingAspect
- After advice instance in ExceptionAspect
- Stop state entered
- LoggingAspect is hidden by TracingAspect: LoggingAspect stores the attributes and data of a particular interest into a database whenever they
are used or modified. However, the system may not always want to log
everything, such as those data that are being traced by TracingAspect. The <<hidden_by>> relationship inactivates LoggingAspect whenever it
matches the same joinpoint as TracingAspect. The correlation betweenTracingAspect and LoggingAspect can be described using the following
expression:
This notation means that the presence of TracingAspect implies the absence
of LoggingAspect. For each pointcut denoted as PointcutLoggingAspect in LoggingAspect, the actual corresponding pointcut exposed by this particular
deployment strategy is
Figure 8. Aspect Composition
- LoggingAspect is dependent on EncryptionAspect: The <<dependent_on>> relationship enforces the LoggingAspect to be
applied only in the presence of the EncryptionAspect. This is enforced
because some systems may require all logged data to be encrypted (i.e., LoggingAspect will only be applied at the joinpoints when EncryptionAspect and LoggingAspect both match. LoggingAspect will be disabled at the other joinpoints where it matches apart from EncryptionAspect). The relationship between LoggingAspect and EncryptionAspect is denoted as
This means that the presence of LoggingAspect implies that EncryptionAspect has to be present at the same joinpoint as well.
Therefore, under this particular condition, the actual pointcut exposed by LoggingAspect is
The resulting joinpoint selection set for LoggingAspect is indicated by the
striped area in Figure 9. In addition, as illustrated in Figure 8, EncryptionAspect also <<follows>> LoggingAspect, which forces
encryption actions to be executed closer to the joinpoint than logging procedures.
Figure 9. Joinpoint selection for LoggingAspect
by the deployment strategy in Figure 8 In order to detect and collect all of the joinpoints by traversing the whole model in
linear time, the base model is divided into several exclusive sets from the deployment
diagram. The derived aspect composition order for Figure 8 is:
Within the scope of package Authentication, ExceptionAspect will be
applied first, followed by TracingAspect, LoggingAspect (with the new
composite pointcut) and EncryptionAspect. For all of the other models that are not
within the scope of Authentication (denoted by subtracting Authentication from ALL with a minus sign “–”), only LoggingAspect and EncryptionAspect
will be applied. Circular and conflict relationships among the aspects will be detected and
reported when they are superimposed at the same joinpoint.
The advantages of our approach over AspectJ are:
- In the WEAVR, aspects are explicitly deployed by means of a deployment
diagram. Aspects can be bound to different fragments of the base models; in
AspectJ, aspects are applied everywhere. The only way to apply an aspect to a
certain scope is to restrict every pointcut specification by using the “within” keyword, which are bound lexically to method or class names; this makes
pointcuts and aspects less reusable.
- The semantics of the <<follows>> relationship in the WEAVR correspond to
the “declare precedence” form in AspectJ. In addition, the WEAVR is able to
handle two more dependency relationships between aspects (i.e., <<hidden_by>> and <<dependent_on>>), which further restrict
application of an aspect at the same joinpoint. In AspectJ, however, when a
pointcut matches a certain joinpoint, the corresponding aspect is always applied.
In this section, we introduced composition mechanisms implemented in the WEAVR in three distinct categories: pointcut, advice and aspect. From our experience, we have
found that by integrating compositions at different granularity levels, the aspect
expressiveness and reusability can be extended to a larger extent. By declaring
precedence relationships between crosscutting concerns, the aspect interference can be
reduced and controlled by the aspect developers. 5 RELATED WORK
Aspect interference is a well-known problem to every AOSD approach and has received
considerable attention in the research literature. The Aspects, Dependencies, and
Interactions (ADI) Workshop [ADI] is particularly dedicated to discussing this issue. An
exhaustive classification and documentation of aspect interactions has been investigated
by Sanen et al. [Sanen]. This section will give a brief overview on some of the existing
techniques that provide support for handling aspect interference.
As a light-weight approach, AspectJ [AspectJ] controls the aspect ordering by the“declare precedence” statement. As noted by Reddy et al. [Reddy], weaving order is
defined by two composition directives, i.e., “follows” and “precedes,” at the class design
modeling level. Theme/UML [Clarke] resolves aspect conflicts by indicating precedence
order using a “prec” tag. We extend these approaches by introducing two additional
precedence relationships between aspects. Furthermore, our approach allows precedence
to be specified explicitly between advice.
A number of advanced approaches have been proposed to manipulate aspect
interference at the programming level. Kienzle et al. [Kienzle03] defined an aspect based
on the services it provides, requires, and removes. They also established a set of
composition rules to solve inter-aspect dependencies. Similarly, aspect integration
contracts were introduced by Lagaisse et al. [Lagaisse] to manage semantic interference
between the aspects. Sihman and Katz [Sihman] united the theory of superimposition
with AOP, allowing interactions and relations to be expressed among generic aspects,
which can be used to define proof obligations for the correctness of superimpositions and
to check feasibility of combining superimpositions. Nagy et al. [Nagy] proposed
ordering, control and structural constraints to address the aspect interference issue.
Pawlak et al. [Pawlak] developed a language called “CompAr” to specify compositionrelevant
information on the advice, such as Boolean choices, action
executions/invocations and post-execution constraints, with the purpose of detecting and
solving aspect composition issues. As a similar approach, Durr et al. [Durr] defined the semantics of advice in terms of operations on an abstract resource model, in order to
reason about semantic conflicts between aspects. Douence et al. [Douence02] presented
static conflict analysis for aspect interactions and proposed some linguistic support for
conflict resolution. Later on, they extended their work by defining applicability
conditions for aspects, which made interaction analysis more precise [Douence04].
Stoerzer et al. [Stoerzer06] proposed an interference criterion by analyzing data flow and
control flow of the advice in order to detect aspect conflicts.
The primary benefit our approach compared to these other techniques is that aspect
interference is reduced even before proceeding to the implementation level, which
enhances the comprehensibility and reusability of the crosscutting concerns. Furthermore,
our unique pointcut designator provides more powerful expressiveness because it allows
joinpoints to be selected from the state machine specifications.
6 CONCLUSIONS
The paper introduces the aspect composition mechanisms in the Motorola WEAVR, an
industrial AOM tool that is currently being deployed in production in the Motorola
network infrastructure business unit [WEAVR]. A key point when dealing with aspects is
the notion of aspect interference. One of the primary contributions of this paper is an
approach that allows precedence relationships to be specified at the modeling level to
prevent undesirable interference. Model engineers make design decisions explicitly based
on the dependencies between aspectual behaviors. The underlying composition
mechanism in the Motorola WEAVR derives a composition order automatically.
Furthermore, the three distinct categories of aspect composition mechanisms
implemented in the WEAVR are introduced with the purpose of facilitating aspect
reusability and comprehensibility to a larger extent than the other existing AOSD
approaches. We are currently investigating the interference problem in a more systematic way in
order to explore and validate the precise needs for various aspect dependences and
constraints that can be introduced in the WEAVR. We are also working on integrating the
composition mechanism with the debugging and simulation feature, so that the model
engineers can simulate the model in different perspectives and verify the impacts that are
caused by each applied aspect.
As this research is still in the preliminary phases, there are some limitations. The
current version has not taken into account pointcut-to-pointcut interference. However, in
recent AOSD literature, the so-called “fragile pointcut” problem [Stoerzer04] has been
studied as an important aspect interference issue. The future work will include
investigation on the topic of pointcut interference. Also, the current research does not
take into account the correctness of the system after composing multiple aspects
simultaneously. The future work will exploit the reasoning mechanisms for weaving
correctness.
7 ACKNOWLEDGEMENTS
This work is partially supported by the National Science Foundation under CAREERCCF-0643725.
REFERENCES
[ADI] ADI, Aspects, Dependencies, and Interactions Workshop at European
Conference on Object-Oriented Programming (ECOOP), Nantes, France,
July 2006. http://www.aosd-europe.net/adi06/
[AOM] AOM Website: http://www.aspect-modeling.org/
[AOSD] AOSD Website: http://www.aosd.net/
[AspectJ] AspectJ Website: http://www.eclipse.org/aspectj/
[Clarke] Siobhàn Clarke and Elisa Baniassad, Aspect-Oriented Analysis and
Design: The Theme Approach, Addison Wesley, 2005.
[Cottenier06] Thomas Cottenier, Aswin Van Den Berg and Tzilla Elrad, “An Add-in for
Aspect-Oriented Modeling in Telelogic TAU G2,” Telelogic User Group
Conference (UGC), Denver, CO, October 2006.
[Cottenier07] Thomas Cottenier, Aswin van den Berg, and Tzilla Elrad, “Joinpoint
Inference from Behavioral Specification to Implementation,” In Proceedings of the 21st European Conerence on Object-Oriented
Programming (ECOOP), Berlin, Germany, July 2007.
[Douence02] Rémi Douence, Pascal Fradet and Mario Südholt, “A Framework for the
Detection and Resolution of Aspect Interactions,” In Proceedings of the
1st ACM SIGPLAN/SIGSOFT Conference on Generative Programming
and Component Engineering (GPCE), Pittsburgh, PA, October 2002, pp.
173-188.
[Douence04] Rémi Douence, Pascal Fradet and Mario Südholt, “Composition, Reuse
and Interaction Analysis of Stateful Aspects,” In Proceedings of the 3rd
International Conference on Aspect-Oriented Software Development
(AOSD), Lancaster, UK, March 2004, pp. 141-150.
[Durr] Pascal Durr, Tom Staijen, Lodewijk Bergmans, and Mehmet Aksit,“Reasoning About Semantic Conflicts Between Aspects,” 2nd European
Interactive Workshop on Aspects in Software (EIWAS), Brussels, Belgium,
September 2005.
[Gamma] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design
Patterns, Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995.
[Kienzle03] Jörg Kienzle, Yang Yu, Jie Xiong, “On Composition and Reuse of
Aspects,” In Proceedings of the 2nd Workshop on Foundations of Aspect-Oriented Languages (FOAL), Boston, MA, March 2003.
[Kienzle06] Jörg Kienzle and Samuel Gélineau, “AO Challenge - Implementing the
ACID Properties for Transactional Objects,” In Proceedings of the 5th
International Conference on Aspect-oriented Software Development
(AOSD), New York, NY, March 2006, pp. 202-213.
[Lagaisse] Bert Lagaisse, Wouter Joosen, and Bart De Win, “Managing Semantic
Interference with Aspect Integration Contracts,” International Workshop
on Software-Engineering Properties of Languages for Aspect
Technologies (SPLAT), Lancaster, UK, March 2004.
[Herrejon] Roberto Lopez-Herrejon, Don Batory, and Christian Lengauer, “A
Disciplined Approach to Aspect Composition,” In Proceedings of
Symposium on Partial Evaluation and Semantics-based Program
Manipulation (PEPM), Charleston, SC, January 2006, pp. 68-77.
[Nagy] Istvan Nagy, Lodewijk Bergmans and Mehmet Aksit, “Composing
Aspects at Shared Joinpoints,” In Proceedings of International Conference
NetObjectDays (NODe), Erfurt, Germany, September 2005, pp. 19-38.
[OMG] OMG. Semantics for a foundational subset for executable UML models -
request for proposal. Request for Proposal ad/2005-04-02, Object
Management Group, 2005.
[Pawlak] Renaud Pawlak, Laurence Duchien, and Lionel Seinturier, “CompAr:Ensuring Safe Around Advice Composition,” In Proceedings of 7th IFIP
International Conference on Formal Methods for Open Object-Based
Distributed Systems (FMOODS), Athens, Greece, June 2005, pp. 163-178.
[Reddy] Raghu Reddy, Sudipto Ghosh, Robert France, Greg Straw, James M.
Bieman, N. McEachen, Eunjee Song, and Geri Georg, “Directives for
Composing Aspect-Oriented Design Class Models,” Transactions on
Aspect-Oriented Software Development I, LNCS 3880, Springer-Verlag,
2006, pp. 75-105.
[Sanen] Frans Sanen, Eddy Truyen, Wouter Joosen, Andrew Jackson, Andronikos
Nedos, Siobhan Clarke, Neil Loughran, and Awais Rashid, “Classifying
and documenting aspect interactions,” The 5th AOSD Workshop on
Aspects, Components, and Patterns for Infrastructure Software (ACP4IS),
Bonn, Germany, March 20, 2006.
[Sihman] Marcelo Sihman and Shmuel Katz, “Superimpositions and Aspect-Oriented Programming,” The Computer Journal, 46(5), September 2003,
pp. 529-541. [Stoerzer04] Maximilian Stoerzer and Christian Koppen, “PCDiff: Attacking the
Fragile Pointcut Problem,” In Proceedings of the 1st European Interactive
Workshop on Aspects in Software (EIWAS), Berlin, Germany, July 2004.
[Stoerzer06] Maximilian Stoerzer, Robin Sterr and Florian Forster, “Detecting
Precedence-Related Advice Interference,” In Proceedings of the 21st
IEEE International Conference on Automated Software Engineering
(ASE), Tokyo, Japan, September 2006, pp. 317-322.
[TAU] Telelogic TAU G2 Website: http://www.telelogic.com/corp/products/tau/g2/index.cfm
[WEAVR] Motorola WEAVR Website: http://www.iit.edu/~concur/weavr/ About the authors
Cite this article as follows: Jing Zhang, Thomas Cottenier, Aswin van den Berg, and Jeff Gray: “Aspect Composition in the Motorola Aspect-Oriented Modeling Weaver”, in Journal of Object
Technology, vol. 6, no. 7,Special Issue. Aspect-Oreinted Modeling, August 2007, pp 89-108 http://www.jot.fm/issues/issue_2007_08/article4.
|
