Meng Tian mt5e09@ecs.soton.ac.uk

1. Extension in Domain Specific Code Generation with Ontology Based Aspect Weaving Meng Tian mt5e09@ecs.soton.ac.uk Supervisor: Julian Rathke jr2@ecs.soton.ac.uk

2. Domain Specific Code Generation Domain Specific Code Generation (DSCG) • Model Driven Engineering (MDE) • Raised abstraction level, highly automated • Increased productivity and reliability

3. Domain Specific Code Generation Domain Specific Code Generation (DSCG) • Model Driven Engineering (MDE) • Raised abstraction level, highly automated • Increased productivity and reliability

4. Domain Specific Code Generation Domain Specific Code Generation (DSCG) • Model Driven Engineering (MDE) • Raised abstraction level, highly automated • Increased productivity and reliability However, in practice…

5. Extensions Required e.g. to add logging facilities in the generated code.

6. Extensions Required e.g. to add logging facilities in the generated code. MDE orthodoxy “model change -> code re-generation”

7. Extensions Required e.g. to add logging facilities in the generated code. MDE orthodoxy “model change -> code re-generation” Round-trip engineering “code change -> model reverse generation”

8. Extensions Required e.g. to add logging facilities in the generated code. MDE orthodoxy “model change -> code re-generation” Round-trip engineering “code change -> model reverse generation” What if change not expressible?

9. Extensions Required e.g. to add logging facilities in the generated code. MDE orthodoxy “model change -> code re-generation” Round-trip engineering “code change -> model reverse generation” What if change not expressible? Or even worse, meta-model change is required

10. Evolving model-based software Is meta-model change a good thing? Yes. Now my modelling language is more expressive and powerful. • Is that still abstraction? • Is that cost effective? • Compatible problems?

11. Evolving model-based software Is meta-model change a good thing? Yes. Now my modelling language is more expressive and powerful. • Is that still abstraction? • Is that cost effective? • Compatible problems?

12. Extensions Required e.g. to add logging facilities in the generated code. MDE orthodoxy “model change -> code re-generation” Round-trip engineering “code change -> model reverse generation” What if M’=M

13. Where is the problem? Modification CANNOT be reflected in the model.

14. Where is the problem? Modification CANNOT be reflected in the model. Causes: • Model and code are both maintained explicitly as core products. • Forceful synchronization of artefacts of two different abstraction level is unnecessary and may break abstraction levels.

15. Where is the problem? Modification CANNOT be reflected in the model. Causes: • Model and code are both maintained explicitly as core products. • Forceful synchronization of artefacts of two different abstraction level is unnecessary and may break abstraction levels.

16. What makes the magic mapping? The code generator!

17. What makes the magic mapping? The code generator!

18. What makes the magic mapping? The code generator!

19. Our approach • No “model-code” synchronization. • An intermediate layer – aspect, between model and code, in which modification can be expressed flexibly. • As the aspect languages are built based on the domain ontology, we call them Ontology Based Aspect languages (OBALs)

20. Our approach

21. Test with ANTLR Parser Generator Production rule in ANTLR grammar Extension for program synthesis functionalities in ANTLR grammar can be difficult, sometimes even impractical.

22. Test with ANTLR Parser Generator Production rule in ANTLR grammar Extension for program synthesis functionalities in ANTLR grammar can be difficult, sometimes even impractical.

23. Test with ANTLR Parser Generator Production rule in ANTLR grammar Extension for program synthesis functionalities in ANTLR grammar can be difficult, sometimes even impractical.

24. Test with ANTLR Parser Generator

25. Test with ANTLR Parser Generator Count how many if-only statements in a Java program, and how many equality check involved.

27. 3 “if” statements without “else”.

28. Test with ANTLR Parser Generator Begin_Parse_Rule_statement_Alternative_1(); End_Parse_Rule_statement_Alternative_1(); Begin_Match_Token_ELSE(); End_Match_Token_ELSE();

29. Test with ANTLR Parser Generator Begin_Parse_Rule_statement_Alternative_1(); End_Parse_Rule_statement_Alternative_1(); Begin_Match_Token_ELSE(); End_Match_Token_ELSE();

30. Test with ANTLR Parser Generator Begin_Parse_Rule_statement_Alternative_1(); End_Parse_Rule_statement_Alternative_1(); Begin_Match_Token_ELSE(); End_Match_Token_ELSE();

31. Test with ANTLR Parser Generator

32. Evaluation Benefits • It solves the “model non-reflectable” extension problem. • It makes the generator extensible, instead of simply extending it. • There is no model compatible problem. • It allows modification to be described in a flexible way. • The aspect based extension process can be fully automated. Limitations • Knowledge of the code generator is required. • Maintenance of ontology tracing information

33. Conclusions • We introduced a new approach for extending the generated code in model-based software development, i.e. via ontology-based aspect. • Under certain assumptions, our approach can generate the aspect language over the ontology model, and produce the corresponding weaver provided ontology tracing information.

34. Future Work • Standardize the ontology definition schema, i.e. meta meta model. • Supporting restrictions in domain ontology. E.g., access control, conflict prevention. E.g., OCL based solution.

35. Any Question?