Generating Assertion Code from OCL: A Transformational Approach Based on Similarities of Implementation Languages
0 likes18,575 views
This document presents an approach for generating assertion code from the Object Constraint Language (OCL) using model transformations. The approach constructs a hierarchy of programming languages based on their structural similarities. This allows rules for translating OCL to be reused across multiple implementation languages, saving approximately 50% of the effort compared to creating individual translators. An evaluation implemented the approach in Maude and demonstrated its ability to generate code for Java, Python, Haskell and O'Haskell from a single OCL specification.
Generating Assertion Code from OCL: A Transformational Approach Based on Similarities of Implementation Languages
- 1. 2009. 10. 9 TOKYO INSTITUTE OF TECHNOLOGY DEPARTMENT OF COMPUTER SCIENCE MODELS 2009 Generating Assertion Code from OCL: A Transformational Approach Based on Similarities of Implementation Languages Rodion Moiseev Shinpei Hayashi Motoshi Saeki Department of Computer Science Tokyo Institute of Technology Japan
- 2. Abstract Generation Assertion Code from OCL − Transformational Approach: Regarding OCL-to-code as model transformation − Similarities of Implementation Languages: Constructing a language hierarchy for effective developing of transformation rules Results − A translation framework has been developed − Showed ~50% of effort to construct translation rules saved 2
- 3. Background Model-centric approaches are becoming important in academia and industry OCL is often the language of choice for stipulating constraints on models Successful application depends on mature tool support: − Support for multiple programming languages − Customizable assertion code/test case generation 3
- 4. Motivating Example Application design: UML with OCL <<interface>> OCL MyApplication doQuery(q : Query) : Integer context MyApplication::doQuery( q: Query): Integer pre: not q = null post: result >= 0 4
- 5. Motivating Example A need to check OCL for multiple languages MyApplication Client 1 Perl Java Server <<interface>> Client 2 MyApplication Haskell doQuery(q : Query) : Integer context MyApplication::doQuery( q: Query): Integer pre: not q = null post: result >= 0 5
- 6. Pinpointing the Problem Interface (UML+OCL) Generate <<write code>> Skeleton OCL Code Code OCL Skeleton Assertion Code Generate assertion code 6
- 7. Problems Troublesome to make individual OCL translators − Many languages exist • Most of existing tools are tailor-made for a specific language − Creating a translator requires efforts • Specifying OCL translation rules for each individual OCL concept, operator, etc. Our solution: Usage of language similarities 7
- 8. Language Similarities E.g., for-loop iterating over a collection For Each apple In apples Do: If apple.color == “red” Then … Next Imperative Pseudo-language for (Iterator it = apples.iterator(); it.hasNext(); ) { Apple apple = (Apple) it.next(); if (apple.color == “red”) { for apple in apples: … if apple.color == “red”: Java … Python 8
- 9. The Approach Hierarchy of programming languages based on their structural similarities OCL Imperative Functional DbC Java, C# like Python Lisp Haskell JML Step-by-step <<described in terms of>> Java C# Translation Pseudo-languages Concrete languages MultiJava High concreteness 9
- 10. Advantages Provide a single framework for creating OCL translators for any language − Reuse translator implementations Bridges semantic gap − Effort of understanding OCL is alleviated − Manual effort of creating OCL translators is reduced OCL OCL Semantic gap Imperative Python Python 10
- 11. Generation Process Environment containing type information Parser + type checker OCL AST ENV AST→Imperative DL AST ENV OCL OCL Imperative DL Input Imper. DL→Python DL Imper. DL ENV UML + OCL rewriting rules Python DL Python Code Python DL→Python Code Python DL ENV printing rules DL = Definition Language (Structural representation of pseudo/implementation languages) 11
- 12. Comparison with MDE DL Definition and MDE Terms Rewriting System Metalanguage Rewriting Language written in Transformation Language written in written in Imperative DL Imper. DL→Python DL Python DL PIM Transformation PSM Rules Rewriting engine 12
- 13. Transformation Example All employees in the company earn more than 10,000 employees->forAll( e : Employee | e.salary > 10000) OCL AST: iteratorExp (assocEndCallExp simpleName("self") . simpleName("employees")) -> simpleName("forAll") ( varDecl(simpleName("e"), pathName("Employee")) | operCallExp( attrCallExp simpleName("e") . simpleName("salary"), simpleName(">"), intLitExp("10000") Company 1 .. * employees Employee ) salary : Int ) 13
- 14. Rewriting Rules iteratorExp OE -> simpleName(“forAll”) `( varDecl(SN, TYPE) | OE’’ `) impMethodExtract( { impForLoop( OE, impVarDecl(TYPE, SN), { impIf( impNot(OE''), OCL AST→Imperative DL { impReturn( boolLitFalse ) }) }) ; impReturn( boolLitTrue ) }, pathName("Boolean")) . 14
- 15. Imperative DL impMethodExtract( {emptyCtx | impForLoop( assocEndCallExp simpleName("self"). simpleName("employees"), impVarDecl(pathName("Employee"),simpleName("e")), { "ctx:iter" = simpleName("it_e") | impIf( impNot(operCallExp( attrCallExp simpleName("e"). simpleName("salary"), simpleName(">"), intLitExp(“10000"))), {emptyCtx | impReturn(boolLitFalse) }) }) }; {emptyCtx | impReturn(boolLitTrue) },pathName("Boolean")) 15
- 16. Generation Result class Employee: From UML def __init__(self, name, salary): self.name = name self.salary = salary class Company: def __init__(self, employees): self.employees = employees def callExtMethod_A(self): From OCL for e in self.employees: if (not (e.salary > 10000)): return False return True def inv(self): return self.callExtMethod_A() 16
- 17. Approach Evaluation Implemented a tool in the Maude System (*) To show the ability to implement several OCL translators with significant effort savings Target languages − Imperative • Java OCL Predefined • Python Imperative Functional − Functional • Haskell Java Python Haskell • O’Haskell O’Haskell * http://maude.cs.uiuc.edu/ 17
- 18. Approach Evaluation Compare effort in our approach vs. direct approach: − # rewriting rules + # structures + # printing rules OCL AST OCL AST Imperative DL Imper. DL→Java DL Compare OCL AST →Java Java DL Java DL→Java Java Code Java Code Direct Approach Proposed Approach 18
- 19. Evaluation Results Imperative languages rewriting rules structures printing rules Java Python 85 58% 99 40% effort effort 59 saved saved Effort Effort 36 Direct Our Direct Our approach approach 19
- 20. Evaluation Results Functional languages rewriting rules structures printing rules Haskell O’Haskell 32% 99% 76 76 effort effort 52 saved saved Effort Effort 1 Direct Our Direct Our approach approach 20
- 21. Evaluation Results Direct Proposed Approach Approach Java 85 36 Python 99 59 Haskell 76 52 O’Haskell 76 1 Total 316 148 ~50% effort could be saved on average 21
- 22. Conclusion Proposed a novel technique to generate assertion code from OCL constraints Used structural similarities of programming languages to enable reusing in OCL translators for multiple languages − Saving manual effort Run an experiment to show the claimed effort savings by using our approach 22
- 23. Future Work Uncovered functionalities of OCL − History expressions (@pre) − OCL messages − allInstances, etc. Hierarchy Limitations − Difficult to extend hierarchy from the middle − Does not allow multiple parent nodes (e.g. useful for implementing an imperative/functional hybrid) Real case study 23