Scribd
Upload
78 views23 pages

Generating Assertion Code From OCL:: A Transformational Approach Based On Similarities of Implementation Languages

This document presents a transformational approach to generate assertion code from the Object Constraint Language (OCL) by leveraging similarities between programming language implementations. The approach develops a hierarchy of languages based on their structural similarities. Transformation rules are defined to rewrite an OCL abstract syntax tree into an imperative definition language, and then into concrete target languages. An evaluation showed the approach saved an average of 50% effort over direct one-to-one translations. Future work includes supporting more OCL features and refining the language hierarchy.

Uploaded by

THOMASB_19747048
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
78 views23 pages

Generating Assertion Code From OCL:: A Transformational Approach Based On Similarities of Implementation Languages

This document presents a transformational approach to generate assertion code from the Object Constraint Language (OCL) by leveraging similarities between programming language implementations. The approach develops a hierarchy of languages based on their structural similarities. Transformation rules are defined to rewrite an OCL abstract syntax tree into an imperative definition language, and then into concrete target languages. An evaluation showed the approach saved an average of 50% effort over direct one-to-one translations. Future work includes supporting more OCL features and refining the language hierarchy.

Uploaded by

THOMASB_19747048
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 23

2009. 10.

9 MODELS 2009

TOKYO INSTITUTE OF TECHNOLOGY DEPARTMENT OF COMPUTER SCIENCE

A Transformational Approach Based on Similarities of Implementation Languages


Rodion Moiseev Shinpei Hayashi Motoshi Saeki Department of Computer Science Tokyo Institute of Technology Japan

Generating Assertion Code from OCL:

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

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

Motivating Example

Application design: UML with OCL


MyApplication
<<interface>>

OCL

doQuery(q : Query) : Integer

context MyApplication::doQuery( q: Query): Integer pre: not q = null post: result >= 0
4

Motivating Example

A need to check OCL for multiple languages


MyApplication
Perl Server

Client 1
Java

MyApplication
doQuery(q : Query) : Integer

<<interface>>

Client 2
Haskell

context MyApplication::doQuery( q: Query): Integer pre: not q = null post: result >= 0

Pinpointing the Problem


Interface (UML+OCL)
OCL

Generate Skeleton Code Skeleton

<<write code>>

OCL

Code Assertion Code


6

Generate assertion code

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

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

The Approach

Hierarchy of programming languages based on their structural similarities


OCL Imperative Functional DbC

Java, C# like

Python

Lisp

Haskell

JML
<<described in terms of>>

Java MultiJava

C#

Step-by-step Translation

Pseudo-languages Concrete languages

High concreteness

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 Semantic gap Python OCL Imperative Python

10

Generation Process
Parser + type checker
ASTImperative DL OCL AST

Environment containing type information

ENV
ENV

AST

OCL OCL

Imperative DL Imper. DLPython DL


Imper. DL ENV

Input UML + OCL

rewriting rules

Python DL
ENV

Python Code

Python DLPython Code Python DL

printing rules

(Structural representation of pseudo/implementation languages) 11

DL = Definition Language

Comparison with MDE


DL Definition and Rewriting System Metalanguage Rewriting Language Transformation Language
written in MDE Terms

written in

written in

Imperative DL PIM

Imper. DLPython DL

Transformation Rules Rewriting engine

Python DL PSM

12

Transformation Example
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

All employees in the company earn more than 10,000

Rewriting Rules
iteratorExp OE -> simpleName(forAll) `( varDecl(SN, TYPE) | OE `) impMethodExtract( { impForLoop( OE, impVarDecl(TYPE, SN), { impIf( impNot(OE''), { impReturn( boolLitFalse ) }) }) ; impReturn( boolLitTrue ) }, pathName("Boolean")) .

OCL AST Imperative DL

14

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

Generation Result
class Employee: def __init__(self, name, salary): self.name = name self.salary = salary

From UML

class Company: def __init__(self, employees): self.employees = employees def callExtMethod_A(self): for e in self.employees: if (not (e.salary > 10000)): return False return True def inv(self): return self.callExtMethod_A()

From OCL

16

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 Python
Imperative Java Python OCL

Predefined
Functional Haskell OHaskell

Functional
Haskell OHaskell

* http://maude.cs.uiuc.edu/

17

Approach Evaluation

Compare effort in our approach vs. direct approach:


# rewriting rules + # structures + # printing rules
OCL AST OCL AST Imperative DL Imper. DLJava DL Java DL Java DLJava

OCL AST Java

Compare

Java Code
Direct Approach

Java Code
Proposed Approach
18

Evaluation Results

Imperative languages
Java
85

rewriting rules structures printing rules Python

Effort

36

Direct

Our approach

Effort

58% effort saved

99 59

40% effort saved

Direct

Our approach
19

Evaluation Results

Functional languages
Haskell
76 Effort 52

rewriting rules structures printing rules OHaskell

Effort

32% effort saved

76

99% effort saved

1 Direct Our approach Direct Our approach


20

Evaluation Results
Direct Approach Proposed Approach

~50% effort could be saved on average


21

Java Python Haskell OHaskell Total

85 99 76 76 316

36 59 52 1 148

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

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

You might also like