1. Aspect-oriented Code Generation Approaches Abid Mehmood & Dayang N. A. Jawawi Department of Software Engineering Faculty of Computer Science and Information System Universiti Teknologi Malaysia INSPIRING CREATIVE AND INNOVATIVE MINDS

2. Overview 1.Introduction 2.Aspect-Oriented Model to Code Approaches 3.Comparison Approach 4.Comparison Results and Discussion 5.Conclusion and future work

3. Introduction Model-driven Engineering (MDE) - automated model-driven code generation offers many :  an instrument to enhance the produced software.  Advantages: rapid development of high quality code, reduced number of accidental programming errors, enhanced consistency between design and code to name a few & etc. Aspect-Oriented Programming (AOP)  paradigm deals with requirements (concerns) that cut across the primary modularization of a software system  Aspect-Oriented Software Development (AOSD) environment - these crosscutting are modeled and implemented independent from the main functional concerns of the system.

4. Introduction  different efforts to combine MDE & AOP to generating AO code by automatically transforming models  They use a source model (e.g. UML) as input and generate the target AO (use transformation definition).  Different featuresof AO model-driven code generation  Objective : A comparative review of these approaches  to facilitate the future researchers to automate the process of reliable AO code generation.

5. AO Model to Code 1.Aspect-oriented model-driven skeleton code generation [5]  a graph-based transformation approach 2.A Meta-Level Specification and Profile for AspectJ in UML [8]  from a specification of the AspectJ meta-model 3. Aspect-oriented Code Generation [11]  use the Theme/UML (composition pattern to integrate classes) to map from model to code 4.Generating Aspect Code from UML [12]  uses extended UML model as input &generates AspectJ code stubs

6. AO Model to Code 5.Mapping Aspect-Oriented Models to Aspect- Oriented Code [13]  using Reusable Aspect Models (RAM) into Java and AspectJ code 6.Mapping Design to Implementation [14]  Theme/UML approach to generate AspectJ code  maps the symmetric AO design to asymmetric implementation

7. Comparison Approach Important features considered : 1.Transformation approach 2.Source notation 3.Target notation 4.Models covered 5.Extent of code generation 6.Implementation knowledge requirement 7.Tool support 8.Adaptability 9.Validation

8. Comparison Approach NoApp.Transf.Source Notation Target Notation Models covered Extent of code gen. Req of Impl Knowl. Tool support 1[5][5]GBTFDAFAspectJCDSkeletonNoYes 2[8][8]XSLT (TB) AspectJ MMAspectJCDSkeletonYes 3[10]10XSLT (TB) Theme/UMLAspectJCDSkeletonYes 4[12]12DMUMLEAspectJCDSkeletonNoYes 5[13]13DMRAMAspectJCD, SD, SC N/ANo 6[14]14TUATheme/UMLAspectJCDN/ANoYes GBT – Graph-based transformation FDAF – Formal Design Analysis Framework TUA – Theme/UML mapping approach RAM – Reusable Aspect Models UMLE – UML extended using standard mechanisms MM – Meta-model CD – Class diagram SD – Sequence diagram SC – Statecharts TB – Template- based DM – Direct mapping

9. Results & Discussion Transformation approach PerspectiveNo.Question[5][5][8][8][10]10[12]12[13]13[14]14 Transforma tion approach Q1Are advantages of transformation approach clearly identified comparative to other approaches? YesNo TSEYes Q2Does the approach clearly provide support for static view of system? Yes Q3Does the approach clearly provide support for dynamic view of system? No YesTSE Q4Are advantages of the code generation approach clearly identified comparative to other approaches? YesNo TSENo Q5Does it generate full code? i.e. both base as well as aspects.No YesNoYes Q6Are interaction mechanisms (between base class elements and aspects) other than pointcuts supported? TSENo TSEYesNo Q7Are format and syntax decisions supported?YesNo Q8Are ADTs, Collections and Arrays supported?TSENo YesNo Q9Does the approach explicitly address the algorithm correctness and performance? TSENoTSENo TSE All approaches support transformation of structural models only Correctness and performance of transf. approach not explored by any work

10. Results & Discussion Source notation, Target notation & Models covered all approaches use standard visual models developed in some AO extension of UML as input none of the approaches propose any solution for code generation from behavioral diagrams such as UML sequence, activity and statechart diagrams PerspectiveNo.Question[5][5][8][8][10]10[12]12[13]13[14]14 Source notation Q1Is it a standard, visual modeling language?TSEYes Q2Are standard UML extension mechanisms used to model AO elements? TSEYes TSEYes Target notation Q1Are languages other than AspectJ discussed as target notations? No Yes Q2Are different standards of target language supported? No Models covered Q1Is code generation from class diagrams addressed?Yes NoYes Q2Is code generation from behavior diagrams addressed? No

11. Results & Discussion Extent of code generation None of the approaches generate full code for classes in the class diagram. Could not find any proposal that discusses generation of even the skeleton code from behavioral diagrams. Perspecti ve No.Question[5][5][8][8][10]10[12]12[13]13[14]14 Extent of code generatio n Q1Is full code generation supported for class diagrams?No Q2Is skeleton code generation fully implemented?YesNoYes NoYes Q3Is full code generation supported for behavior diagrams? No Q4Is code generation for both base as well as aspect model elements addressed? No YesNoYes Q5Does the approach provide clear path towards implementation of behavior diagrams, thus full code generation? No YesNo Q6Is the trade-off between amount of code generated and extent of implementation details at design level considered? YesNo

12. Results & Discussion Implementation knowledge & Tool support has provided sufficient tool support and have considered the reliability of tools to a greater extent. need professional tool support to validate some approaches PerspectiveNo.Question[5][5][8][8][10]10[12]12[13]13[14]14 Implementation knowledge Q1Is modeler required to have implementation knowledge in order to use the approach effectively? NoYes No Tool supportQ1Is sufficient tool support provided to apply and validate the approach? YesTSE NoYes Q2Are the tools considerably reliable (not prototypes) to be used to the purpose? YesNo TSE Q3Are the tools developed using standard development frameworks? Yes TSEYesNoYes Q4Are the tools extendable and allow integration with some IDE/ other tools? TSENo YesNoYes Q5Are the tools capable of generating both base and aspect model code? No YesNoYes Q6Are different types of pointcuts supported by tools? No Q7Is the inheritance between aspects supported by tools? No

13. Results & Discussion Adaptability & Validation Most works do not address adaptability at all, neither for input nor for output Works [5] and [14] consider the two attributes at certain level. PerspectiveNo.Question[5][5][8][8][10]10[12]12[13]13[14]14 AdaptabilityQ1Is the approach adaptable to changing standards of input notation e.g. a new standard of UML? TSEYes TSE Q2Is the approach adaptable to other AO languages?No TSE Yes Q3Is it adaptable to other versions/ implementations of the selected target language? TSENo TSE ValidationQ1Is the validation done using a reliable, mature technique taken from literature (opposite to a self-defined, proof-of- concept mechanism)? TSENo TSE Q2Are standard inputs applied?YesNo Yes Q3Are the outputs determined to be standard?YesNo Yes Q4Are the results compared using standard and open mechanism? YesNo Yes

14. Conclusion and Future Work Advancement in AO MD code generation may play a significant role for more maintainable, extensible and reusable software systems. The study reveals that most approaches: –Are limited to structure diagrams only –Generate skeleton code only –Do not address full code generation at all –Do not address correctness of algorithm –Do not provide sufficient tool support Future Work: –Code generation from behavioral diagrams –Enhancement of interaction mechanisms between base and aspect models –Validation, correctness and performance of the transformation algorithm

15. INSPIRING CREATIVE AND INNOVATIVE MINDS Q A &