Metamodel Access Protocols for Extensible Aspect-Oriented Modeling

1. SEKE 2006Software Engineering and Knowledge Engineering Metamodel Access Protocolsfor ExtensibleAspect-Oriented Modeling Naoyasu Ubayashi (Kyushu Institute of Technology, Japan) Shinji Sano (Kyushu Institute of Technology, Japan) Yusaku Maeno (Kyushu Institute of Technology, Japan) Satoshi Murakami (Kyushu Institute of Technology, Japan) Tetsuo Tamai (University of Tokyo, Japan) 5 July 2006

2. Overview • Motivation • Metamodel Access Protocol MMAP • Implementation • Related work • Conclusion

3. 1. Motivation

4. What is Aspect Orientation ? • Aspect-oriented programming (AOP) can separate crosscutting concerns including logging, error handling, and transaction. • These concerns are modularized as aspects. logging

5. AO Mechanism--- JPM: Join Point Mechanism advice join point pointcut logging code program execution points including method calls and field access points extract a set of join points related to a specific crosscutting concern from all join points raise effects at the join points AspectJ aspect Logging { pointcut publiccall (): call (public * *(..)); before() : publiccall() {logging(); } }

6. Towards AO Modeling • Recently, aspect orientation has been proposed for coping with concerns at the early stages of the software development phases including requirements analysis, domain analysis, and architecture design phases. • We previously proposed a UML-based aspect-oriented modeling language called AspectM.

7. AspectM Extension of JPM (Join Point Mechanism) in AOP join point (class) pointcut advice classA classA || classB add new attributes add new operations attributes new attributes classA attributes operations new operations operations classB classB attributes join point (class) attributes new attributes operations operations new operations classC join point (class) attributes operations

8. AspectM JPM PA（pointcut & advice），CM（composition），NE（new element），OC（open class），RN（rename），RL（relation）

9. Example of AspectM descriptions pointcut classA || classB aspect advice << OC >> addAttributeX classA classA add new attributes new attributes classB classeAandB : class { pointcut-body=“cname(classA) || cname(classB)” } classC classB new attributes merge [classAandB] : add-attribute { advice-body=“attributeX” } <aspect name=“addAttributeX” type=“ordinary” jpm=“OC" > <pointcut name=“classeAandB” type=“class”> <pointcut-body> cname(classA) || cname(classB) </pointcut-body> </pointcut> <advice name=“add-attributeX” type=“add-attribute” ref-pointcut=“classAandB”> <advice-body> attributeX </advice-body> </advice> </aspect>

10. AspectM is nice, but … • Although AspectM provides major JPMs, there might be situations in which a modeler wants to define a JPM specific to an application. • For example, a modeler wants to capture a group of methods that are targets of an application-specific logging or transaction. • However, current aspect-oriented modeling languages including AspectM do not allow a modeler to extend JPMs.

11. We want to use application-specific rich vocabularies aspect class

12. Contribution • We introduce a mechanisms called metamodel access protocol (MMAP) that allows an application modeler to access and modify the AspectM metamodel, an extension of the UML metamodel. • MMAP enables a modeler to define a new JPM that includes application-specific join points, pointcut designators, and advice.

13. 2. Metamodel access protocol MMAP

14. Two approaches forextending model elements in UML Lightweight An approach using UML profiles Heavyweight An approach that extends the UML metamodel by using MOF (Meta Object Facility), a language for modeling a metamodel

15. UML profile approach • UML profiling mechanisms use stereotypes for introducing rich vocabularies. • While an application modeler can easily introduce some kinds of application-specific JPMs, there are situations in which stereotypes as a mere annotation mechanism are insufficient: the typing of tags is weak; and we cannot declare new associations among UML metamodel elements.

16. Problems in UML profiles aspect Stereotypes as annotations cannot describe relations among application-specific model elements including DCEntityContract, DCControllerContract, UniqueId, and DCLogger. class

17. MOF approach • MOF approach is very strong because all of the metamodel elements can be extended. • However, it is not easy for an application modeler to extend the UML metamodel by using the full power of the MOF.

18. Our approach -- MMAP • Our approach is a middle weight approach that restricts available extension by MOF. • MMAP (Metamodel Access Protocol) aims at introducing an application-specific JPM. An application modeler can access and modify the AspectM metamodel by using protocols exposed by MMAP. • The target of MMAP is not a tool developer that needs full access to the AspectM metamodel but an application modeler that wants to introduce rich vocabulary at small cost.

19. AspectM metamodel AspectM model Our concept meta level (MOF L2) reify modify the AspectM metamodel protocols extension point MMAP Editing-time reflection base level (MOF L1) reflect introduce a new kind of application-specific model element new model element model editor

20. MMAP AspectM metamodel Extension points • Class, Attribute, Operation • PA, CM, NE, OC, RN, RL Extension operations • define subclasses • add attributes to subclasses • create associations among subclasses Primitive predicates • predicates for navigating the AspectM metamodel

21. MMAP: Primitive predicates PredicateExplanation meta-class-of(mc, c) mcis a metaclass ofc member-of(m, c) mis a member of a classc value-of(v, a) vis value of an attributea super-class-of(c1, c2) c1is a superclass ofc2 related-to(c1, c2) c1is related toc2

22. Example DCEntityContract_UniqueId_isUserAssigned (c): meta-class-of ("DCEntityContract", c) && member-of (a, c) && meta-class-of ("UniqueId", a) && member-of ("isUserAssigned", "UniqueId") && value-of ("true", "isUserAssigned") member-of meta-class-of meta-class-of Meta model member-of Base model value-of

23. MMAP vs. MOP • The idea of MMAP originates in the mechanisms of extensible programming languages, such as metaobject protocol (MOP) and computational reflection. • MOP is useful at the modeling-level although the targets of MOP are different from those of MMAP: the former focuses on execution behavior, and the latter focuses on model structures.

24. 3. Implementation

25. Our Prototype AspectMTools Model Compiler Model Editor XMI (from UML diagrams) AspectM metamodel Prolog predicates XSLT: Model Tranformation (from Aspect diagrams) UML diagrams Aspect diagrams XMI (UML) • AspectM metamodel and application models are transformed to a set of Prolog predicates. • Model transformation accesses these model elements by MMAP predicates. Java code

26. 4. Related work

27. Related Work Extensible AOP language • Three-part modeling framework [ECOOP2003, H.Masuhara and G.Kiczales] • Parameterized AO interpreter [ASE2005, N.Ubayashi et al.] • XAspect [OOPSLA2003, M.Shonle, K.Lieberherr, and A.Shah] • Versatile kernel for multi-language AOP [GPCE2005, E.Tanter and J.Noye] In AspectM, application-specific AOP features can be introduced by using MMAP.

28. Related Work (Cont’d) Domain-specific aspect orientation • Domain-specific aspect-oriented modeling [GPCE2003, J.Gray] Reflective editor • Edit-time metaobject protocol ETMOP [ODAL2006, A.D.Eisenberg and G.Kiczales

29. 5. Conclusion

30. Conclusion • We proposed MMAP that enables a modeler to define a new JPM that represents application-specific crosscutting concerns. • Our approach is the first step towards extensible aspect-oriented modeling based on metamodel access protocols.