A Meta-Level Specification and Profile for AspectJ in UML Joerg Evermann School of Information Management Victoria University of Wellington

Yet Another AspectJ Profile? Previous work based on UML 1.x –UML 2.x extensions very different –Integrated meta-level extensions –Meta-models are profiles Full coverage of AspectJ Full code generation capabilities No textual specification or special code words –Rigorous meta-level based modeling –Supported by all MOF compliant tools

Meta-Level Specification CrossCuttingConcern –Not in AspectJ –But important for modularization –Extend Package meta- class –Related to Aspect through the meta-model level Aspect –Static features Pointcuts –Dynamic features Advice –Generalizable –Similar to meta-model element Class Extension Relationships

Aspects isPrivileged declareParents –Specifies meta-level Generalizations declareImplements –Specifies meta-level InterfaceRealizations Precedence –Total ordering Instantiation –PointCut

Advice Advices are dynamic –BehavioralFeature –Expressible as state charts, collaborations, or opaque behaviour, i.e. methods Related to Aspect via meta-model Signatures by virtue of Operation –Subclass of BehaviouralFeature –Requires behavior specification by method –Determines when advice is applied (after throwing or after returning value)

Static Crosscutting Features Owned by / modelled with the aspect –For better separation of concerns and encapsulation –Requires specification of type for introduced features Alternative possible –“Cleaner” meta-model –But less rigorous separation

PointCuts Explicit composition –UML has no built-in regular expressions Refer explicitly to specific model elements they cut

OCL Constraints Advice stereotype only on behavioral features of classes that are stereotyped Aspect context Advice inv: allInstances.featuredClassifier.oclIsKindOf(Asp ect) StaticCrossCuttingFeature stereotype only for features of classes that are stereotyped Aspect context StaticCrossCuttingFeature inv: allInstances.featuredClassifier.oclIsKindOf(Asp ect) PointCut stereotype only for behavioural features of classes that are stereotyped Aspect context PointCut inv: allInstances.featuredClassifier.oclIsKindOf(Asp ect)

OCL Constraints (2) Aspects are either instantiated perPointCut or perType context Aspect inv: perType->size() > 0 or perPointCut->size() > 0 Aspect stereotype only on classes packaged in packages that are stereotyped as CrossCuttingConcern context Aspect inv: package.oclIsKindOf(CrossCuttingConcern)

Code Generation AspectJ from XMI XSLT –approx 600 lines of code, 9 templates Proof of concept –Lacking sufficient error handling No support for templated and stereotyped classes (i.e. Java Generics and Annotiations) yet. Modeller must ensure advice signature matches context exposed in PointCuts –Not all boolean combinations allowed in AspectJ

Code Generation (2) Advice signature (return parameter or raised exception) determines after … returning or after … throwing advice context Advice inv: if (adviceExecution = AfterAdvice) then ownedParameter(p | p.direction=return)->size() > 0 or raisedException->size() > 0 Different interpretation of return parameter in advice signature –Ignored for before-Advice –Type of returned value for around-Advice –PointCut context for after-Advice

Discussion Rigorous Meta-model specification Lightweight extensions –Cross-tool support (in theory) Lack of pattern based textual specification –Requires awareness of base model –Safer –Easier model verification –No tool support required

Where to from here? Two main directions –Breadth: Other AOP languages –Depth: Generic Aspect Profile –Model Transformations for MDA Other improvements –Code generation for templated and stereotyped elements (i.e. Java 5 generics and annotations) –Validity constraints with OCL –Usability and practical application studies

Thank You