Previous article

Next article


A Meta-Level Specification and Profile for AspectJ in UML

Joerg Evermann, School of Information Management, Victoria University of Wellington, Wellington, New Zealand


space REFEREED
ARTICLE


PDF Icon
PDF Version

Abstract

Aspect-oriented programming (AOP) has become a mature technology. Increasingly, calls for support of AOP on the software model level are being voiced. This paper addresses these calls by offering a meta-model of AspectJ in UML. Using the UML extension mechanisms, the resulting meta-model is also a UML profile for supporting AspectJ modelling in UML. In contrast to previous work, this profile offers complete meta-level integration of all AspectJ concepts. Moreover, the use of standard XMI based modelling allows the use of the profile in commercially available CASE tools and supports easy code generation.


1 INTRODUCTION

The identification and separation of cross-cutting concerns in software design has led to the the widespread use of aspect-oriented programming (AOP) techniques. While AOP has matured and gained widespread industry support, there is little support for separation of cross-cutting concerns on the software model level. Aspect-oriented modelling (AOM) techniques are intended to fill this gap.

Aspect-Oriented Modelling and Positioning of This Work

AOM approaches can be distinguished along two orthogonal dimensions: the level of weaving and the symmetry of the approach (Fig. 1). The first dimension, the level of weaving, indicates that level of abstraction where separation of cross-cutting concerns is given up and weaving of concerns (aspects) occurs. In the case of modellevel weaving, cross-cutting concerns are separately modelled, then woven together to yield a non-aspect-oriented model, which is then transformed to non-aspect-oriented code (Fig. 2a). In the case of code-level weaving, the separation of concerns is maintained to the level of code. Aspect-oriented models are transformed to aspectoriented code, and the weaving is done by an aspect compiler on the code (Fig. 2b). Finally, recent developments have led to the idea of executable-level (runtime) weaving, where the separation of concerns is maintained on the executable (e.g. JVM or CLR bytecode) level and weaving occurs only at run-time (Fig. 2c).

Along the symmetry dimension, AOM approaches may be categorized as symmetric or asymmetric. For asymmetric AOM approaches, there is a designated base model into which cross-cutting concerns (aspects) are woven. In the symmetric case, there is no such designated base system and the ’base system’ is just one concern among many that is woven together.

Figure 1: Dimensions of Aspect-Oriented Modeling

(a) Model-level weaving      (b) Code-level weaving      (c) Executable-level weaving

Figure 2: Levels of weaving

Using these dimensions, the work presented here is positioned in the highlighted sector of Figure 1 and highlighted in Figure 2b: We present a technique to create aspect-oriented models that are converted to aspect-oriented code, which can be woven by an aspect-oriented compiler. We also make a clear distinction between the base-system and the cross-cutting concerns.

The focus on code-level weaving instead of model-level weaving is useful for software development projects where the system behaviour is not specified in UML behavioural diagrams. Many software development projects use only UML class diagrams [10], thereby ruling out model-level weaving of behaviour. For example, agile methods such as XP (eXtreme Programming) [6] reject elaborate model construction and eschew the use of MDA (model-driven-architecture).

Motivation and Goal

While aspect-oriented programming (AOP) is rapidly maturing and industrial-strength tools such as AspectJ [21] are quickly becoming widely applied de-facto standards, there is no standards-based approach to AOM that is supported by commercial modelling tools. UML [25], the de-facto standard software design language upon which many modelling tools are based, does not offer specific constructs for aspects and their associated concepts. However, UML does provide standardized extension mechanisms that can be used to provide aspect-oriented modelling facilities. In UML 2.0, these extension mechanisms allow the definition of UML profiles by means of meta-models.

In this paper, we present a meta-model of the AspectJ language [21]. Using the powerful extension mechanisms in UML 2.0, this meta-level model is a UML profile.

In the context of Model-Driven-Architecture (MDA), our proposal is situated as shown in Figure 3. Our profile allows the specification of a platform-specific model (PSM), namely one that is specific to the Java and AspectJ platform. We also offer a translation to code, as indicated by the circled elements in Figure 3.

The presented profile is not a generic aspect-oriented modelling extension. The conceptual differences between different aspect implementations, e.g. AspectC++, Aspect# and AspectJ are substantial and cannot readily be captured in a single meta-model. We have focused on providing a UML extension to support AspectJ because of the maturity of the development of AspectJ and its wide-spread industrial use [21].

Generic aspect-oriented profiles may be used for specification of a platformindependent model (PIM), which in MDA forms the basis of the platform-specific model (PSM) (Fig. 3). A generic aspect profile and platform specific aspect profiles for languages other than AspectJ are beyond the scope of this paper.

Our approach as outlined here offers the following advantages over previous proposals (discussed in detail in Section 2). First, it is supported by UML 2.0 compliant modelling tools. The extension requires no special software support and allows aspect modelling to be used within existing, mature software tools.

Figure 3: Use of profile within MDA-based development

For example, the work described in this paper was developed using the commercially available tool MagicDraw, version 11.5. This contrasts with earlier proposals, which are not all based on profiles and extend UML either by introducing new meta-model classes, or new notation elements, or both [13, 31]. Those proposals cannot be used with available modelling tools and require specific tool support.

Second, because the proposed technique is supported by UML XMI model interchange facilities, the model extension, as well as any models it is applied to, can be exchanged between different MOF (Meta-Object-Facility) compliant UML modeling tools.

Third, the proposal allows all aspect-related concepts to be specified in metamodel terms. Hence, no textual specification of special keywords is necessary. This means the models can be easily manipulated or verified, without requiring the parsing of keywords or other textual specifications by special tools.

Fourth, the proposal maintains strict separation of base-model and cross-cutting concerns in the models it is applied to, the primary motivation behind AOP.

The remainder of this paper is structured as follows. Section 2 presents related work. Section 3 represents the main contribution of this work and discusses the proposed AspectJ meta-model. This is followed by a brief example of the use of this profile in Section 4. We describe the code-generation capabilities that have been developed for this profile (Sec. 5) before concluding the paper with an outlook to future research (Sec. 6).

2 RELATED WORK

An overview of some of the prior work for modelling aspects in UML is presented in [27]. The early work presented at the AOM 2002 workshop is based on the extension mechanisms in UML 1.x versions. Because these mechanisms are not fully integrated with the meta-model, the specification of advices and pointcuts often remains in textual form. The connection between aspects and base-model is made as part of the model, instead of an aspect extension to the model, thereby foregoing the clear separation of base-model and cross-cutting concerns that is central to AOP.

Initial work presented in [1] proposed the specification of aspects as stereotypes on classes and was later extended to include advice and pointcut specification [2]. It models cross-cutting associations to show which aspect features relate to which base-model elements. It is a generic profile that captures only few of the AspectJ extensions.

The proposal in [26] is not defined in meta-model terms and uses special keywords in a textual specification of roles to define pointcuts. It is limited to advice on method calls and field accesses. An aspect stereotype for UML collaborations was developed in [18], however without being fully defined in UML meta-model terms. Aspects as well as pointcuts are stereotypes on UML classes. Pointcuts can be associated with UML classes by means of stereotyped ”binding” associations.

An earlier profile for AspectJ [28] proposes that messages in collaborations are join points. This profile represents advices and pointcuts as stereotyped operations, introduction of fields or methods is modelled as templated collaborations, and the connection to the base features is made via dependencies in the model. Similarly, the proposal in [5] uses textual specification of pointcuts, rather than being based on (meta-)model elements. Later extensions to this in [11] are similar to our proposal in that aspects are stereotyped classes. However, because no meta-model based profile is developed, the connection between aspects and base-model is made as part of the model, rather than an aspect extension to it. An inital proposal for aspect modelling using UML 2.0 was presented in [4], however without fully defining an extension profile, as we do here.

Other prior work is based on defining new UML meta-classes, instead of defining stereotypes for existing meta-classes, which requires specialized tool support for the new meta-classes. Instead of using the extends relationship type in UML, these proposals use the generalization relationship type to define the new aspect concepts. The research in [13] introduces new UML meta-classes and therefore requires specialized tools for their support. A meta-model for generic AOP is offered in [7], but with no apparent mapping to AspectJ and without describing an implementation. A full meta-model based approach, similar to this proposal, is found in [31]. However, rather than employing the standard lightweight extensions of UML, this approach also introduces new meta-classes, thus requiring specialized tools.

Other work on aspect modelling in UML proposes join point annotations for UML [16]. A translation of aspect UML to object-oriented Petri-nets is described in [23] but is limited to pointcuts around method calls. Weaving on the model level is presented in [17] as part of work on design-by-contract. Code generation from aspect-extended UML models is presented in [12], who opt against the XMI based method proposed in this paper and instead use custom tool extensions.

In summary, much of the existing work on AOM profiles for UML is either based on older UML versions, not well integrated on the meta-model level, incomplete with respect to AspectJ, or requires specific tool support. The present proposal addresses these gaps in the prior work.

3 ASPECT UML EXTENSION

The main point of distinction of the present work to previous proposals is the focus on developing a complete and comprehensive meta-model of AspectJ. It also resolutely employs a meta-model based specification. For example, the operations selected by a call join point are specified as operation model elements, not as a textual specification, as previous work has done.

This allows the integration of aspect features with base-model features on the meta-model level, rather than as part of the model, as previous work was forced to do, and thereby maintains strict separation of base and cross-cutting concerns. For example, the application of an aspect to a classifier is not shown by any kind of relationship in the model. Instead, analogous to the pecification in AspectJ, pointcuts of an aspect select specific operation elements or attribute elements of the model (Sec. 4 and Figs. 13, 14).

This section presents a meta-model of the AspectJ concepts. It is modelled on the UML meta-level, so that it is usable as a profile. Rather than specializing UML meta-classes, as previous work has done, we extend the existing meta-classes. A UML stereotype is a meta-class which enters into extends relationships with existing meta-classes [25]. Visually, this is shown with the extended class in square brackets. Attributes that are modelled on stereotype meta-classes will translate to tags when the profile is applied [25]. Similarly, values of stereotype attributes will become values of tags when the profile is applied [25]. This extension mechanism in UML 2.0 is therefore a powerful way in which any meta-level model immediately becomes usable as a profile. The following paragraphs present the UML meta-model for each AspectJ construct. We show the complete model in Figure 11 below.

Figure 4: Cross cutting concern as package extension

CrossCuttingConcern We introduce the meta-class CrossCuttingConcern as a way of grouping related aspects. While cross-cutting concerns are not directly specifiable in AspectJ, being able to package related aspects is important for modularization and reuse [8, 9, 3]. CrossCuttingConcern extends the UML meta-class Package, because a cross-cutting concern contains aspects in the same way as packages contain classes (Fig. 4). Providing a stereotyped package to contain aspects also allows the packaging of supporting classes and supporting interfaces for aspects in these packages to enhance modularization. For example, an aspect A may depend on classes C1 and C2 and the CrossCuttingConcern allows these to be packaged together. Because the UML meta-model already specifies that packages own classes, the CrossCuttingConcern meta-class does not need to be associated with the Aspect meta-class.

Aspect An aspect contains both static features (that do not specify behaviour), such as pointcuts, and dynamic features (that specify behaviour), such as advices. Furthermore, aspects can be specialized, and can realize interfaces. These characteristics are sufficiently close to the features of a UML class, so that we model aspects using a meta-class Aspect, which extends the meta-class Class (Fig. 5). This makes the Aspect meta-class a stereotype on the UML Class construct.

Recall that this proposal is positioned in asymmetric AOM (Fig 1). Hence, elements of the cross-cutting concern model or models must remain separated from base-model elements. The following constraint ensures this by requring that classes that are stereotyped «Aspect» are only packaged in packages that are stereotyped as «CrossCuttingConcern».

Aspects have some properties that are not already offered by classes. These are modelled as attributes of the meta-class, which will become tags when the profile is applied to a model. A boolean attribute isPrivileged indicates whether the aspect is privileged, i.e. whether its advices can access private or protected members of the class they advise.

Figure 5: Aspect as class extension

A multi-valued attribute declaredParents allows the declaration of generalizations by the aspect (”declare parents: I extends J” in AspectJ). Because the aspects are a meta-level model element, the data type for this attribute is the meta-class Generalization in UML. In other words, the values of this sterotype tag pick out generalization model elements when this extension is applied. For exposition purposes, Figure 5 explicitly shows the meta-level connections modelled as associations. Figure 11 uses atttributes with appropriate datatypes for reasons of brevity.

Similarly, declaredImplements allows the declaration of interface realizations (”declare parents: I implements J” in AspectJ). The data type of this attribute is the UML meta-class InterfaceRealization. The values of this stereotype tag pick out interface realization model elements when this extension is applied.

Because aspects may be instantiated per pointcut, the attributes perType and perPointCut are used to specify the type of aspect instantiation and associated pointcut, if any. The data type of perPointCut is the PointCut meta-class (i.e. the stereotype) in this extension and the values for perType are provided by the enumeration AspectInstantiationType. We add the following constraint to ensure that aspect instantiation is indicated either per type or per pointcut, but not for both:

Aspect precedence is modelled as a recursive relationship between aspects. Because the precedence ordering in AspectJ is total, each aspect has at most one directly preceding and following aspect.

The AspectJ specification states that aspects may extend classes or other aspects and implement interfaces, but that classes may not extend aspects. Consequently, we add the following constraint that ensures for all generalizations that the specific class of a general class that is an aspect is also an aspect:

Because aspects are extensions of the meta-class Class, dependencies between aspects can easily be defined. Moreover, visibility declarations and interfaces can be used to establish which parts of an aspect are visibile to or hidden from other aspects. This enables modellers to use aspect-composition frameworks, such as the one proposed in [19].

Advice With Aspect being a meta-class that extends Class, the dynamic features of aspects, i.e. advices, play the role of class behavior: The meta-class Advice is an extension of the meta-class BehavioralFeature (Fig. 6).

In UML, the meta-class BehavioralFeature with subclasses such as Operation or Reception (of a signal) is associated with the Behavior meta-class, which is the superclass of OpaqueBehavior, Activity, Interaction and StateMachine, and specifies the actual behavior of a behavioral feature. Opaque behaviour denotes methods whose body is specified in a UML-external language (and thus is opaque as far as UML tools are concerned). This means that advice behavior can be specified either as a method, an activity, an interaction or a state machine. This mirrors a previous proposal in [1, 2].

Because behavioral features are owned by classes in the UML meta-model, Aspect does not have to be associated with Advice. We add the constraint that the «Advice» stereotype can only be applied to behavioral features of classes that are stereotyped «Aspect». In other words, for all instances of an advice, the classifier of the advice feature must be an aspect:

The UML meta-model already associates operations with signatures. Hence, our extension does not need to model signatures for advices when the advice stereotype is applied to operations, a subclass of behavioral features. When applying the «Advice» stereotype to an operation, we get parameters, return values, and raised exceptions automatically.

Advice code can be executed before, after, or instead of (around) a pointcut.

Figure 6: Advice as behavioral feature extension

We model adviceExecution as an attribute of the Advice meta-class. The values are provided by the enumeration AdviceExecutionType. Because each advice has a signature by virtue of being an operation, the signature determines whether an”after” advice is ”after returning” or ”after throwing” by examining whether the signature of an operation that is stereotyped «Advice» contains a return parameter or a raised exception, respectively.

Static Crosscutting Features Aspects may introduce new features to existing classes and types. Because such cross-cutting features can be static or dynamic, the meta-class StaticCrossCuttingFeature extends the UML meta-class Feature, which is the superclass of both Property and Operation (Fig. 7). Because the crosscutting features are owned by the aspect (by virtue of the ownership of attributes and operations by classes), there is no need to associate StaticCrossCuttingFeature with Aspect. We add the constraint that the «StaticCrossCuttingFeature» stereotype can only be applied to features of classes that are stereotyped «Advice». In other words, for all instances of an introduced cross cutting feature, the classifier of that instance must be an advice.

To specify on which types the cross-cutting feature is to be introduced, the StaticCrossCuttingFeature meta-class possesses a multi-valued attribute onType whose data type is the UML meta-class Type. For exposition purposes, Figure 7 explicitly shows the meta-level connections modelled as an association. Figure 11 uses an atttribute with the appropriate datatype for reasons of brevity.

We have chosen to model cross-cutting features as owned by the aspect, rather than by the classifier they are introduced on. While this requires the extra metamodel attribute onType, it enforces the separation of base-model and cross-cutting concerns that is fundamental to AOP. In the alternative model, the meta-class Aspect would be associated with the meta-class Feature so that the aspect can pick out any feature owned by any classifier in the model (Fig. 8).

Figure 7: Static cross-cutting feature as feature extension

Figure 8: Alternate model for Static Crosscutting Features

The application of this alternate meta-model in Figure 9 shows that in this case the static cross-cutting features are visually modelled as part of the base-model element rather than the aspect, thereby giving up the clear separation of concerns into the aspects, at least visually.

PointCut A pointcut does not specify dynamic behaviour. Hence, the meta-class PointCut extends the UML meta-class StructuralFeature. We add the constraint that the «PointCut» stereotype can only be applied to features of classes that are stereotyped «Aspect».

PointCut is an abstract meta-class: This stereotype cannot be applied to the attributes of an aspect; only its non-abstract sub-classes, such as CallPointCut or

Figure 9: Alternate application of Static Crosscutting Features

Figure 10: Pointcut meta-model excerpt

ExecutionPointCut can. Rather than specifying the type and AspectJ textual declaration of pointcuts as attributes on PointCut, we subclass the PointCut meta-class to allow different attributes to be modelled for different pointcuts. Figure 10 shows the meta-model excerpt for pointcuts and one subclass of pointcut, the property pointcut. Other subclasses of pointcuts are modelled analogously (Fig. 11).

OperationPointCut is a superclass to describe pointcuts that select operationrelated join points. Hence, this meta-class has a multi-valued attribute operation for this purpose, whose data type is the UML meta-class Operation. The subclasses of this pointcut directly reflect AspectJ pointcut types and the reader is referred to the AspectJ specification or [21] for the precise semantics. Because UML does not distinguish between operations and constructors, both InitializationPointCut and PreInitializationPointCut are subclasses of OperationPointCut and inherit
the operation attribute.

TypePointCut is a superclass to describe pointcuts that select type-related join points. Therefore, it contains an ordered, multi-valued attribute Type, whose data type is the UML meta-class Type. The subclasses of TypePointCut again directly reflect AspectJ pointcut types and the reader is again referred to the AspectJ specification or [21] for the precise semantics.

AdviceExecutionPointCut describes a pointcut that selects all advice execution.

PointCutPointCut is a superclass for those types of pointcuts that select another pointcut. Hence, it is associated with the meta-class PointCut to specify the selected pointcuts.

PropertyPointCut is a superclass of those types of pointcuts that select fields. Therefore, it possesses a multi-valued attribute with data type Property.

ContextExposingPointCut is an abstract superclass of those types of pointcuts that can expose context in an advice. It contains an ordered, multi-valued attribute argNames that holds the names of the exposed arguments. This collection is ordered, so that the corresponding type can be discerned from the ordered collection type specified for the TypePointCut meta-class.

In AspectJ, pointcuts can be composed of primitive pointcuts. We therefore introduce three kinds of pointcut composition meta-classes: PointCutConjunction, PointCutDisjunction and PointCutNegation. These are modelled as separate sub-classes because the negation operation accepts only a single operand, while conjunction and disjunction require at least two. No ordering of the operands for conjunction or disjunction is necessary because these operations are associative and commutative. Figure 10 shows an excerpt including the PointCutConjunction meta-class. Disjunction and negation are modelled analogously (Fig. 11).

We have chosen to make all references to join points that are selected by pointcuts multi-valued (the operation, field, and type attributes on OperationPointCut, PropertyPointcut and TypePointCut, respectively) to reduce the complexity of the resulting model. The alternative would force the modeller to use pointcut composition using pointcut disjunction. When multiple features are specified for pointcuts, e.g. multiple values of the operation attribute of a ExeuctionPointCut instance, the assumption during code generation (Sect. 5) is that they are composed using logical disjunction.

Finally, because pointcuts are used by advices, the meta-class PointCut is associated with the meta-class Advice.

Figure 11 shows the complete profile developed in this section. In this representation the meta-classes that are extended are not shown explicitly but are shown in the class symbols in square brackets. In the above discussion we have shown associations to existing meta-classes for purposes of exposition and clarity. In the final representation, these associations have been modelled instead as attributes of classes with the appropriate datatypes.

4 PROFILE APPLICATION

We show an application of the proposed profile as proof of concept (Fig. 12) and to identify benefits and shortcomings of the proposed UML extension. Rather than using a complex case study, we show a simple example to demonstrate the use of the profile’s during modelling and to show the visual appearance of the model.

Figure 11: AspectJ profile for UML

Recall that in UML, meta-classes that extend existing meta-classes become stereotypes, and attributes of extending meta-classes become tags.

Crosscutting concerns become packages that are stereotyped «CrossCuttingConcern» and the aspects of this cross-cutting concern are classes that are stereotyped «Aspect», contained in the package. The isPrivileged attribute of the meta-class Aspect becomes the tag isPrivileged of the stereotype «Aspect». In this example, the aspect declares a generalization and an interface realization relationship. Because of the meta-model integration, the values of the declaredParents and declaredImplements tags are the relationships elements specified in the model.
The UML generalization meta-class is not a subclass of the NamedElement metaclass, so that no name is shown for the value of the declaredParents tag, but the interface realization dependency between FigureElement and Drawable is named. This name appears as the value of the declaredImplements tag of the aspect. As Figs. 13 and 14 show, these are not textual specifications but refer to actual model elements. This means that XMI based tools can be used to manage and modify these features without requiring specialized parser extensions.

Pointcuts are stereotyped attributes of the aspect, because they are defined as meta-class extensions of the StaticFeature meta-class. For example, the setXYPointCut attribute is stereotyped as a «SetPointCut». Its meta-class attribute field becomes a tag that provides a list of fields selected by this pointcut. The values of the fields are the attribute elements in the model (the CASE tool does not show the fully qualified name). Because of the meta-model integration, the CASE tool allows selection of the appropriate model elements as values, shown in
Figure 13. The figure shows the fully qualified names of the model elements that are the values of the tag field. Figure 14 shows that the values of the tags can be picked out from the actual model elements. An example of a pointcut that exposes context variables is given with the TwoIntArgsPC example, selecting all operations taking two arguments of type int.

Static cross-cutting features can be either atttributes or operations. Examples of both are shown as stereotyped «StaticCrossCuttingFeature». The meta-level attribute onType of the meta-class StaticCrossCuttingFeature becomes, on the model level, a tag with (multiple) values referencing the classes of the model. For example, the aspect introduces a public operation addObserver (myObserver) : int on the types Line and Point.

Advices are operations that are stereotyped «Advice». The Advice meta-class is associated with the Pointcut meta-class. Therefore, each advice in the aspect advises a pointcut, specified as the value of the tag pointCut.

(a) Base-model and cross-cutting concern


(b) Generated AspectJ code

Figure 12: Application of AspectJ profile

Figure 13: Tag values referring to model elements

Figure 14: Selecting model elements as tag values

5 CODE GENERATION

Because the model is compliant with standard UML XMI format and is fully specified in terms of the meta-model, code can easily be generated. As a proof-of-concept, an XSLT has been implemented that generates valid AspectJ code (Fig. 12). Existing CASE tools already support code generation for the non-aspect-oriented parts of the model, so that the XSLT only generates code for classes stereotyped as «Aspect» within packages that are stereotyped «CrossCuttingConcern». The XSLT will generate method bodies for advice behavior that has been specified as a method body (opaque behavior) in the model. If advice behavior has been specified as an activity, interaction, or state machine, the XSLT will create only a method stub. The translation of those types of behavioral specifications to Java method bodies is clearly beyond the scope of this research.

While there is not enough space here to present the complete XSLT, to give an indication of the complexity of the transformation, code generation is implemented in approx. 580 lines of XSLT code. Most of the complexity in the transformation stems from ensuring robustness. The XSLT is freely available from the author.

The code generation currently relies on the modeller to develop models that are valid representations of AspectJ. For examples, the modeller must ensure that the signature of an Advice matches the context exposed on any referenced ContextExposingPointCut. Another example of this onus on the modeller is the choice between a return parameter and a thrown exception on an advice. The XSLT will generate after ... returning when a return parameter is included in the advice signature, and will generate after ... throwing when a raised exception is modelled for the advice. However, it is valid in UML to model both. To at least partially address this issue, we include the following constraint:

While TargetPointCut and ThisPointCut have, in the interest of a simple metamodel, been modelled as subclasses of TypePointCut, they, in contrast to the other subclasses of TypePointCut, should only refer to a single type. When generating code, additional type references in the model are ignored. This can be addressed using OCL constraints:

Combining context-exposing primitive pointcuts using multiple boolean operations can lead to very complex structures with no easily discernible signature. In the current implementation, the pointcut signature is generated from the signatures of the primitive ContextExposingPointCuts in a CompositePointCut using simple union. It is up to the modeller to ensure that this transforms to valid AspectJ code.

When an advice signature contains a return parameter, the XSLT will interpret this parameter depending on the value of the adviceExecution tag. For a BeforeAdvice, the return parameter type is ignored, for an AroundAdvice it is interpreted as the type of the value returned by the advice (generating ”type around(...):”), while for an AfterAdvice it is interpreted as the type of the value returned by the operation (generating ”after(...) returning (type):”).

These examples of potential pitfalls when generating code highlight the need for OCL-based constraint specifications as part of the profile. Such constraints, if enforced, can significantly reduce the complexity of the code generation. However, while this profile includes OCL constraints, most current commercial UML modelling tools lack the ability to enforce them.

6 DISCUSSION

We have shown an AspectJ profile for UML which, in contrast to previous work, is based entirely on the existing UML meta-model, employing standard UML extension mechanism. This section discusses strengths and weaknesses of the proposal. From a theoretical perspective, the strength of this proposal is a complete specification of AspectJ in UML. The model completely specifies AspectJ in terms of the UML meta-model and does not rely on textual descriptions or annotations that must be parsed for model application or verification. To our knowledge, this is the first complete proposal.

From a practitioner’s perspective, using the lightweight, meta-model based extension mechanisms of UML 2.0 makes the theoretically important AspectJ meta-model practically useful as a profile. The profile can be used with existing, commercially available UML CASE tools1. Aspects can be exchanged using UML XMI model interchange mechanism and applied to both new and existing UML models. The modular way in which UML 2.0 and the MOF allow profiles to be exchanged and applied means that AspectJ model extensions can be applied to existing UML models, just as AspectJ extensions can be woven into existing Java software.

However, some words of caution are in order. The lack of pattern based, textual specification implies that each AO-feature refers to a specific model element that must be explicitly specified by the modeller (Figs. 13, 14). This is in contrast to the AspectJ language where patterns are used to select join points for pointcuts. The power of pattern specifications is not available in UML. Having to explicitly specify each pointcut requires that the modeller be aware of the complete base-system model. This also is in contrast to AspectJ where AO-features can be specified using
pattern expressions without full knowledge of the specific join points or types selected by a pattern. However, this type of pattern-based specification, while convenient, also opens the door to inadvertent selection of unintended join points. This problem is known as the fragile pointcut problem [14, 20] and is especially problematic when refactoring [22] the base system code, because pattern-based pointcut specifications depend strongly on the specific design of the base system. In this respect, the explicit specification required by the presented profile is safer and the
meta-model integration allows easier model checking and verification. Moreover, if patterns were to be specified using textual attributes in the UML model, special tools would be required to resolve such specifications on the model level, e.g. as part of model-level weaving. This would preclude the use of commercially available CASE tools for AspectJ modelling. A future extension to this work may investigate whether the use of JPDD (joint point description diagrams) [29, 30, 15] can address this issue. JPDDs are used for describing joint point selection in pointcuts. Because JPDDs are a type of UML diagram, an integration with this proposal may be possible.

While one may argue that explicit specification of all AO-features creates a model almost as complex as if the cross-cutting functionality had been included using non-aspect methods, the use of the proposed profile retains the main advantage of AO-modelling, namely that of modularization and encapsulation of cross-cutting concerns.

The present work can be extended in multiple directions in future work. First, it does not yet fully take into account generics and annotations in Java 5 and 6. UML has the TemplateableElement concept and is therefore able to express Java generics. Java annotations may be modelled as stereotypes in UML. While the proposed profile can be applied to stereotyped and templated model elements, the code-generating XSLT transformation needs to be extended to develop corresponding Java 5 code.

Second, in the context of the model driven architecture (MDA) process [24] (Fig. 3), two extensions can be developed. UML profiles can be developed for other aspect-oriented languages, such as Aspect#, to allow the development of platform specific models (”PSM”in MDA terminology). The aspect-oriented features can also be abstracted into a language-agnostic UML profile for generic AOM, to be used for platform independent models (”PIM” in MDA terminology). Transformations can then be developed to transform the language-agnostic aspect-oriented models (”PIMs”) into language specific aspect-oriented models (”PSMs”) and from there to code.

Third, while some OCL constraints are presented, others can be developed to further ensure the validity of the models. For example, the signature of Advices needs to match the context exposed by ContextExposingPointCuts, so that valid AspectJ code is ensured.

Fourth, while the present work describes the use of this profile for code-level weaving (refer to Figure 1 in Sect. 1 for the positioning of this work), it is also conceivable that a code-generating XSLT can be be developed for model-level weaving. From a woven UML model, the regular code-generation capabilities of commercial UML tools can then be used to create ordinary Java code. However, while feasible, it would require essentially duplicating the existing AspectJ weaver on the UML model level.

Finally, usability studies need to be conducted. In this context, it is also possible to explore the impact of various design decisions for this profile, e.g. textual specification of join points versus the present meta-model based specification, or the modelling of static cross-cutting features with the aspect as presented here, or with the base model element.

FOOTNOTES

1 It has been implemented in the MagicDraw tool from NoMagic, Inc.


REFERENCES

[1] O. Aldawud, T. Elrad, and A. Bader. A UML profile for aspect oriented modeling. In Proceedings of OOPSLA 2001, 2001.

[2] O. Aldawud, T. Elrad, and A. Bader. UML profile for aspect-oriented software development. In Proceedings of the AOM workshop at AOSD, 2003, 2003.

[3] E. Baniassad and S. Clarke. Theme: An approach for aspect-oriented analysis and design. In Proceedings of the International Conference on Software Engineering, 2004., 2004.

[4] E. Barra, G. Genova, and J. Llorens. An approach to aspect modelling with UML 2.0. In Proceedings of the AOM workshop at AOSD, 2004, 2004.

[5] M. Basch and A. Sanchez. Incorporating aspects into the UML. In Proceedings of the AOM workshop at AOSD, 2003, 2003.

[6] K. Beck. Extreme programming explained: embrace change. Addison-Wesley, Reading, MA, 2000.

[7] C. Chavez and C. Lucena. A metamodel for aspect-oriented modeling. In Proceedings of the AOM with UML workshop at AOSD, 2002, 2002.

[8] S. Clarke and R. J. Walker. Composition patterns: an approach to designing reusable aspects. In ICSE ’01: Proceedings of the 23rd International Conference on Software Engineering, pages 5–14, Washington, DC, USA, 2001. IEEE Computer Society.

[9] S. Clarke and R. J. Walker. Towards a standard design language for AOSD. In AOSD ’02: Proceedings of the 1st international conference on Aspect-oriented software development, pages 113–119, New York, NY, USA, 2002. ACM Press.

[10] B. Dobing and J. Parsons. How the UML is used. Communications of the ACM, 49(5), 2006.

[11] L. Fuentes and P. Sanchez. Elaborating UML 2.0 profiles for AO design. In Proceedings of the AOM workshop at AOSD, 2006, 2006.

[12] I. Groher and S. Schulze. Generating aspect code from UML models. In Proceedings of the AOM workshop at AOSD, 2003, 2003.

[13] J. Grundy and R. Patel. Developing software components with the UML, Enterprise Java Beans and aspects. In Proceedings of ASWEC 2001, Canberra, Australia, 2001.

[14] K. Gybels and J. Brichau. Arranging language features for more robust patternbased crosscuts. In Proceedings of the 2nd international conference on Aspect-Oriented Software Development (AOSD), pages 60–69, 2003.

[15] S. Hanenberg, D. Stein, and R. Unland. From aspect-oriented design to aspectoriented programs: Tool-supported translation of JPDDs into code. In Proceedings of the 6th International Conference on Aspect-Oriented Software Development AOSD, Vancouver, Canada, pages 49–62, 2007.

[16] W. Harrison, P. Tarr, and H. Ossher. A position on considerations in UML design of aspects. In Proceedings of the AOM with UML workshop at AOSD, 2002, 2002.

[17] J.-M. Jezequel, N. Plouzeau, T. Weis, and K. Geihs. From contracts to aspects in UML design.

[18] M. Kande, J. Kienzle, and A. Strohmeier. From AOP to UML - a bottom-up approach. In Proceedings of the AOM with UML workshop at AOSD, 2002, 2002.

[19] M. Katara and S. Katz. A concern architecture view for aspect-oriented software design. Software and Systems Modeling, 2007.

[20] A. Kellens, K. Mens, J. Brichau, and K. Gybels. Managing the evolution of aspect-oriented software with model-based pointcuts. In Proceedings of the European Conference on Object-Oriented Programming (ECOOP), pages 501–525, 2006.

[21] R. Laddad. AspectJ in Action: Practical Aspect-Oriented Programming. Manning Publications, Greenwich, UK, 2003.

[22] T. Mens and T. Tourwe. A survey of software refactoring. IEEE Transactions on Software Engineering, 30(2):126–139, Feb. 2004.

[23] F. Mostefaoui and J. Vachon. Formalization of an aspect-oriented modeling approach. In Proceedings of Formal Methods 2006, Hamilton, ON, 2006.

[24] Object Management Group. MDA Guide, June 2003. Document omg/2003-06-01.

[25] Object Management Group. Unified Modeling Language: Superstructure, Aug. 2005. Document formal/05-07-04.

[26] R. Pawlak, L. Duchien, G. Florin, F. Legond-Aubry, L. Seinturier, and L. Martelli. A UML notation for aspect-oriented software design. In Proceedings of the AOM with UML workshop at AOSD, 2002, 2002.

[27] A. Reina, J. Torres, and M. Toro. Towards developing generic solutions with aspects. In Proceedings of the AOM workshop at AOSD, 2004, 2004.

[28] D. Stein, S. Hanenberg, and R. Unland. Designing aspect-oriented crosscutting in UML. In Proceedings of the AOM with UML workshop at AOSD, 2002, 2002.

[29] D. Stein, S. Hanenberg, and R. Unland. Query models. In Proceedings of UML’04, Lisbon, Portugal, pages 98–112, 2004.

[30] D. Stein, S. Hanenberg, and R. Unland. Expressing different conceptual models of joint point selections in aspect-oriented design. In Proceedings of the 5th International Conference on Aspect-Oriented Software Development AOSD, Bonn, Germany, pages 15–26, 2006.

[31] H. Yan, G. Kniesel, and A. Cremers. A meta model and modeling notation for AspectJ. In Proceedings of the AOM workshop at AOSD, 2004, 2004.

About the author





Joerg Evermann is a faculty member with the School of Information Management at Victoria University of Wellington. He received his PhD in MIS from the University of British Columbia. His research interests include requirements engineering and conceptual modeling, modeling issues in system analysis and software design, and the evaluation and improvement of modeling languages.

 


Cite this article as follows: Joerg Evermann: "A Meta-Level Specification and Profile for AspectJ in UML", in Journal of Object Technology, vol. 6, no. 7, Special Issue: Aspect-Oriented Modeling, August 2007, pages 27-49, http://www.jot.fm/issues/issue_2007_08/article2

 


Previous article

Next article