2013 20th Asia-Pacific Software Engineering Conference

Bidirectional Translation between OCL and JML for Round-trip Engineering
Hiroaki Shimba ,Kentrao Hanada ,Kozo Okano and Shinji Kusumoto
Graduate School of Information Science and Technology
Osaka University, Japan{h-shimba,k-hanada,okano,kusumoto} @ist.osaka-u.ac.jp
It enables a user to detect the location of software
defects by the concept of design by contract.
• For JML, there are several tools to check whether
inconsistency exists between implemented code and thespeciﬁcation in JML.
In our previous work, two directions of translation among
OCL and JML are performed independently without considering uniﬁed and iterative translations. For an OCL statement
and another OCL statement which is obtained from a JML
statement which was translated from the original OCL, ourprevious framework preserves only the meaning of the twostatements, however the forms of the OCL statements maychange. This paper proposes a translation technique between
OCL and JML with maintaining OCL code by describing
their original forms in the comment area of the target
languages.
Our contributions are summarized as follows.
• A bidirectional translation technique helps uniﬁcationof design and implementation by some devices suchas describing OCL statements in the comment area of
JML such that forms of code are maintained.
• Our implemented tool enables a user to maintain consistency of speciﬁcation between design and implementation.
• The experimental results highlight the beneﬁts of ourtranslation approach between OCL and JML.
The organization of the remainder of this paper is asfollows. Section 2 describes the background of this research.
Sections 3, 4, and 5 describe our approach, the implementation of our tool and the experimental results respectively.
Finally, Section 6 concludes the paper.
•

Abstract—In recent years, Model-driven development(MDD) based techniques have emerged, and thus translation
techniques such as translation from Object Constraint Language (OCL) to Java Modeling Language (JML) have gainedmuch attention. We have been studying not only translation
techniques from OCL to JML but also from JML to OCL
in order to support Round-trip Engineering (RTE). Two
directions of translation among OCL and JML are performed
independently without considering uniﬁed and iterative translations in our previous work. For an OCL statement and another
OCL statement which is obtained from a JML statement which
was translated from the original OCL, our previous frameworkpreserves only the meaning of the two statements; however, theforms of the OCL statements may change. It prevents us fromRTE-based development. This paper proposes a translation
technique between OCL and JML maintaining OCL codeby describing their original forms in the comment area ofthe target languages. Our implementation has been evaluatedon two projects used in our previous work and also sevenadditional open source projects.
Keywords-Model-Driven Development,Bidirectional Translation,OCL,JML,

I. I NTRODUCTION
Agile software development has come to be used recently
and has been important in industry. Round-trip Engineering(RTE) is one of agile software development. In RTE, developers generate code from models using MDD techniques andmodify the models or the generated code. In general changes
in the models or the code are reﬂected to the corresponding
code or the models. Such a developer reﬁnes the models
and the code using a framework which supports RTE. This
framework maintains consistency between the models andthe code automatically translating the models to the code andthe code to the models. Several approaches to support RTE
have been proposed. For example, Tanaka et al. proposed abidirectional translation technique between Service Oriented
Architecture and Process Oriented Architecture [1]. However
any bidirectional translation techniques which focus onannotation language such as OCL [2] and JML [3] havenot been proposed.
We have been studying not only translation techniquesfrom OCL to JML but also from JML to OCL [4]. The
advantage of using the annotation languages such as OCL
and JML is described as follows.
• It is possible to describe speciﬁcation precisely than anatural language.
1530-1362/13 $31.00 © 2013 IEEE
DOI 10.1109/APSEC.2013.111

II. BACKGROUND
A. Design by Contract
Design by Contract [5] is known as contract programming. It is one of the concepts of object-oriented designing.
It regards speciﬁcation as a contract between a supplier ofthe method (callee) and client of the method (caller) for the
purpose of improving software quality and reliability.
B. OCL and JML
OCL is an annotation language for the Uniﬁed Modeling Language (UML). It can describe speciﬁcation more49

precisely than natural languages. The speciﬁcation is represented by describing pre-condition, post-condition andinvariant condition to model elements of UML. OCL does
not change state of models because OCL statements haveno side effect.
JML is an annotation language for Java code. It can
describe speciﬁcation of Java methods or objects in the same
way as OCL. It is easy to describe the speciﬁcation in JML
because its syntax is similar to that of Java. JML statements
are described in the comment area of Java. There are tools
to verify Java code annotated with JML. JML Run Time
Assertion Checker [6] dynamically detects inconsistency
between runtime values and speciﬁcation in JML. ESCJava2[7] checks correctness of the implementation of Java codefor speciﬁcation with JML.

Cheon et al. [13] manually translated OCL into four
languages such as Java code, assertion, JML and AspectJ.
They compared results of veriﬁcation using translated speciﬁcation. As a result, they found that Java code and assertiosn
are useful from the viewpoint of CPU usage and memory
usage. JML and AspectJ are useful in terms of ease oftranslation and debug.
A translation technique from UML class diagram annotated with OCL to Alloy was proposed by Anastasakis
et al [14]. It enables designers of software to verify the
UML class diagram. Moreover they proposed a translation
technique from the results of veriﬁcation by Alloy to UML
object diagram [15]. Designers can understand the results ofthe veriﬁcation without knowledge of Alloy by combining
these translations.
It takes a signiﬁcant amount of time and resources toperform model translation on large and complex models.
Razavi et al. [16] proposed an approach for deriving incremental model transformations by partial evaluation of theoriginal model transformation programs. The experimental
results indicate that their approach signiﬁcantly improves theperformance of repetitive applications of model transformations.
It is important and difﬁcult to maintain traceability between models and code in MDD. It will be lost when a userof MDD modiﬁes the models or the generated template code.
Yu et al. [17] proposed their framework which maintaintraceability between the modiﬁed models and the modiﬁed
template code.

C. Model Translation
Model translation in general translates a model in accordance with a certain metamodel into another model inaccordance with yet another metamodel. Model translation
falls into two types. One translates from a model to anothermodel (M2M), while the other translates from a model tocode (M2T). QVT and ATL are typical M2M model translation languages. UML2Java [8] supports M2T translation.
D. Round-trip Engineering
RTE is a software development method performed byrepeating forward engineering and reverse engineering. In
forward engineering, program code is generated from models such as class diagram and sequence diagram. In reverse
engineering, program code is translated into corresponding
models. Developers iterate modeling phase and coding phasein RTE. In general, when code or models are modiﬁed,changes must be automatically reﬂected to the corresponding
models or the code by using tools which support RTE.

III. A PPROACH
A. Translation from OCL to JMLFirst, we describe the overview of our proposed translationfrom OCL to JML. The translation on basic operations is
deﬁned in our previous work. The translation rules deﬁne
one-to-one relation in target elements. The translation oncollection loop is performed using the translation rules described at related work [11]. In the bidirectional translation,
it is desirable that statements which are not modiﬁed by auser are maintained in the same form. Our tool maintains
OCL code by inserting their original forms in the commentarea in the front of the generated JML statements. Moreover,a hash code for each of the generated JML statements isinserted in the same comment area. It is used to check
whether the generated JML statements are modiﬁed by auser.
Collection loop operations are replaced with an iterate
operation and translated into semantically equivalent Javamethods in our previous work. However there are somecases that the translation fail. For example, translation on
the statement (1) fails. The keyword “result” means returned
value of a method in OCL. In this case, the type of the“result” value is collection. In our previous work, collection

E. Xtext
Xtext [9] is a framework which supports deﬁning syntax
of models and translation rules based on M2T. It automatically generates an editor from models. This editor supports
code completion and detection of syntax error. If models aredescribed on the editor, they are automatically translated intoa target language by using user-deﬁned translation rules.
F. Related WorkAn existing method [10] does not adequately support theiterator feature, which is the most basic operation amongcollection loop operations. Our research group proposed atechnique to translate the iterator feature by generating aJava method that is semantically equal to each OCL loop
feature [11].
There is a research which generates OCL constraints froma natural language speciﬁcation[12]. In this research, thenatural language which conforms SBVR is translated into
OCL. It is useful to study OCL.

50

of OCL statements in translation from JML to OCL. In
translation from OCL to JML, these inserted JML statements
as comment are directly outputted into JML. Figure 4
describes such situation. The ﬁrst statement represents JML
statement which cannot be essentially translated into an OCL
statement. The second statement represents statement which
can be translated into JML. The area enclosed by “\*”and “*\” is comment in OCL. This approach prevent us
from losing information about statements which cannot beessentially translated from JML to OCL.

/*@ensures translatedIteration1(\result)>= 100; @*/private Collection sample(){}private Integer translatedIteration1(Collection param_Collection){
Integer res = 0;
for (String e : param_Collection){
res = (res + e);}
return res;
Figure 1.

B. Translation from JML to OCL

translation on iterate operation

Here, we describe the overview of the translation from
JML to OCL ﬁrstly. Translation rules on basic operations
are deﬁned with one-to-one relation between target elements.
However it is necessary to deal with collection loop statements in order to perform translation correctly. Moreover
when generated JML statements are not modiﬁed by a user,
OCL statements which are inserted in the comment areaof corresponding JML statements have to be outputted asa result of translation in translation from JML to OCL.
There are several JML statements which are impossible totranslate into OCL. We need to consider dealing with thesestatements.
In JML, loop operations such as “exist” and “forall”
operation are similar to “for” operations in Java. Thus
these operations can handle various variables. However these
operations can handle only collection variables in OCL.
We assume that the loop operations deal with collection
variables in JML. Thus we deﬁned translation rules under
this assumption.
In translation from OCL to JML, collection loop operations are translated generating semantically equivalentJava methods. These methods are invoked by statements in
JML. We need to analyze the generated methods in order toperform reverse translation.

which is the target of the iterate operation is translated in
the generated methods.
result−> iterate(e : Integer; res : Integer = 0| res + e) >= 100(1)

The keyword “result” in OCL is translated into “\result”
in JML. However “\result” is available only in JML statements. The keyword “\result ʡ is not available in Javamethods. Thus we perform translation correctly by passing
collection (the “\result” value) as argument to the generated
methods. The statement (1) is translated successfully into
Figure 1.
In our new approach, we maintain OCL statements asoriginal forms in bidirectional translation if generated JML
statements are not modiﬁed by a user. First, we insert theoriginal OCL statements and its hash code in the commentarea in the front of the corresponding JML statements intranslation from OCL to JML. Then in reverse translation
we calculate the hash code of the target JML statements
and compare it with the inserted hash code in order tocheck whether the generated JML statements are modiﬁedby a user. If the target JML statements are not modiﬁed,
we output the OCL statements in the comment area of the
JML statements as a result of translation instead of adapting
translation rules on the target JML statements. If the target
JML statements are modiﬁed, we adapt translation rules.
The advantage of this approach is that forms of statements
don’t become complex by repeated bidirectional translation.
Moreover it enables us to translate JML statements which
are impossible to translate into OCL unless a user modiﬁes generated code. Figure 2 and 3 describe examples ofsuch translations. Note that the inserted OCL statements ascomment in the generated JML statements will be directly
outputted in reverse translation.
Basically, OCL statements which are translated from JML
statements are translated into JML by using translation
rules deﬁned in our previous work. However JML statements which cannot be essentially translated to OCL are
maintained original forms inserted in the comment area

pre : c−>iterate(e :Integer; res : Integer = 0| res + e) >= 10
requires translatedIteration1() >= 10

(2)
(3)

pre : translatedIteration1() >= 10(4)For example, the OCL statement (2) is translated into the
JML statement (3) generating a sementically equivalent Javamethod. The translatedIteration1 method is semanticallyequal to the statement ʠ c− >iterate(e : Integer; res :Integer = 0 | res + e) ʡ . It is invoked by the generated
JML statement (3) . Then the statement (3) is translated
into the OCL statement (4). As a result, information about
implementation of translatedIteration1 in OCL has beenlost. Thus we analyze only the generated Java methods
semantically equivalent to the original OCL in translationfrom JML to OCL. Basically modifying these methods
are prohibited except for modiﬁcation in accordance with51

op getAmount(name : String) : Integer{
pre : not name.oclIsUndefined() and name <> ’’post : itemList->exists(i : Item |i.getTotalAmount() = result) or result = 0}
Figure 2.

An example of translation between OCL and JML (OCL)//Original_OCL={pre: not name.oclIsUndefined() and name <> ’’},JML_HashCode={378505836};/*@ requires !(name == null) && !(name.equals("")); @*///Original_OCL={post: itemlist->exists(i:Item |i.getAmount() = result) or result = 0}
,JML_HashCode={2016817273};/*@ ensures translatedIteration3(itemlist, name, \result)|| \result==0; @*/public Integer getAmount(String name) {}Figure 3.

An example of translation between OCL and JML (JML)op sampleMethod(str:String) : void{/*@require (¥forall int i; 0<=i && i<=str.length();str.itemAt(i) instanceof JMLChar);@*/
pre : not str.oclIsUndefined();}Figure 4.

/*@require (¥forall int i; 0<=i && i<=str.length();str.itemAt(i) instanceof JMLChar);@*//*@require str != null;@*/public void sapleMethod(String str){}

Translation on inserted JML as comment in OCL

method template. An modiﬁer can change particular part ofthe methods.
In translation from OCL to JML, the OCL statements andthe hash code of the generated JML statements are inserted
in the comment area of the JML statements. In translationfrom JML to OCL we use these information as mentioned
in section III-A.
There are JML statements which are impossible to translate into OCL because JML has complex operations thanthat of OCL. The ﬁrst statement of Figure 4 is impossible totranslate. It is desirable that information on these statements
is preserved in bidirectional translation. Thus we insert
these JML statements in the comment area of the OCL
in translation from JML to OCL, which is reused whentranslation from OCL to JML is performed.

UML annotated with OCL and Java skeleton code annotatedwith JML. The syntax of the models is deﬁned by EBNF.
Next, we deﬁne translation rules on elements of the models.
Translations from OCL to JML and JML to OCL are
implemented in the same way. The advantage of using Xtext
is described as follows.
• Deﬁned syntax of models is reusable for other translation because syntax of the models and translation rules
are deﬁned independently.
• An editor which supports code completion and syntax
checking is automatically generated from the deﬁned
syntax.

IV. I MPEMENTATION
We implemented a translation tool between OCL andJML using Xtext. First, we deﬁne syntax of models such as

We have conducted experiments on nine Java projects
annotated with JML statements. Two of the nine projects
are developed by our research group in a past research while

V. E VALUATION
A. Targets and Metrics

52

Table I

Table IIIDETAIL OF THE PROJECTSTRANSLATION FROM GENERATED OCL TO JML

Project
warehouse management
educational affairs
PokerTop
101JMLSpeciﬁcations
consultorOrtograﬁcoZinaraLenguajes III
P2-master
extweka
TOTAL

Class
7
200
9
3
6
28
16
5
10
77

JML
142
468
113
30
124
126
65
56
233
747

Project

Statements

Warehouse Management
educational affairs
PokerTop
101JMLSpeciﬁcations
consultorOrtograﬁcoZinaraLenguajes III
P2-master
extweka
TOTAL

142
444
113
30
84
106
65
56
230
1270

Semantically
Num
Ratio
142
100%
444
100%
103
91.2%
26
86.7%
82
97.6%
96
90.6%
65
100%
30
53.6%
200
87.0%
1188 93.5%

Syntactically
Num
Ratio
62
43.7%
214
48.2%
74
65.5%
9
30%
63
75%
36
34.0%
0
0%
18
32.1%
115
50%
591
46.5%

Table II
TRANSLATION FROM JML TO OCL

Project
Warehouse Management
educational affairs
PokerTop
101JMLSpeciﬁcations
consultorOrtograﬁcoZinaraLenguajes III
P2-master
extweka
TOTAL

JML
142
468
113
30
124
128
65
56
233
1359

Success
142
444
113
30
84
106
65
56
230
1270

We measured the ratio of the statements which cannot
be translated from JML to OCL.
We have conducted the experiments in the following way.
1) We applied the implemented tool to the Java projects
annotated with JML statements. It generated UML
diagrams annotated with OCL statements.
2) We measured the Rsucc and the Rcannot.
3) We applied the tool to the generated UML dagrams
annotated with OCL statements. It generated Java code
annotated with JML statements.
4) We measured the Rsyntac and the Rseman.

Ratio
100%
94.5%
100%
100%
67.7%
82.8%
100%
100%
98.7%
93.5%

B. Results of Experiments

the other seven projects are open source projects obtained
from Github. The two projects are a warehouse management
system and an educational affairs system. The warehousemanagement system has correct JML statements as describedin the past research. Table I shows the number of the classes
and the JML statements each project has.
We measured the following items in the experiments.
• Ratio of the statements which are successfully translated from JML to OCL (Rsucc)
We measured the successfully translated OCL statements from the view of meaning of the statements at
translating from JML.
• Ratio of the semantically corresponding statements
in reverse translation (Rseman)
We measured the ratio of the generated JML statements
which are semantically equal to the original JML statements. Note that forms of the statements may change.
• Ratio of the syntactically corresponding statements
in reverse translation (Rsyntac)
We measured the ratio of the generated JML statements
which are syntactically equal to the original JML
statements. Note that there is no difference except for
white space, tab, parentheses and line separators. The
ratio of the semantically corresponding statements isgreater than the ratio of the syntactically corresponding
statements.
• Ratio of the statements which cannot be translated(Rcannot)Table II represents the results of the translation from JML
to OCL. The Rsucc is 93.5 percent. Most of the remaining
statements contain loop operations on an array variables.
The array variables in JML are translated into “Sequence”
in OCL. Therefore, we deﬁne translation rules for statements
refering variables with array type. We, however, don’t deﬁnesuch rules for statements with loop operations for arrays. In
order to deal with such a statement, one possible solution
would be to deﬁne rules for a subset of such statements,
which can be naturally translated into OCL. The solution still
has problem on a trade-off between possibility of translationand degrees of freedom of description.
Table III represents the results of the translation fromgenerated OCL to JML. The Rseman is 93.5 percent. There
are typos of JML statements in the open source projects.
Our tool cannot detect these errors unless the statements
conform the syntax of the deﬁned models. If semanticalinconsistency between original statements and generated
statements occurs, our tool either cannot detect such anerror. It is one of the problems we have to deal within the future. The Rsyntac is 46.5 percent. More thanhalf of the statements change their forms by applicationof the bidirectional translations which starts from JML.
The Rsyntac of Lenguajes III is zero percent because allstatements contain “!=” operator. For example, “name !=null” becomes “(name==null)==false” after application of
our bidirectional translation. If a bidirectional translation

53

starts from OCL using our approach, the Rsyntac will be
100 percent unless generated code is modiﬁed by a user.
If the generated code are modiﬁed by a user, our tooltranslate normally using translation rules deﬁned by ourprevious work and the statements which cannot be translated“essentially” from JML to OCL are inserted in the commentarea of the OCL.
The Rcannot is 6.5 percent. The ratio of the statements
which cannot be translated “essentially” in these 6.5 percent
statements is 9.86 percent. Thus, the ratio of the statements
which cannot be translated “essentially” in all statements isless than one percent. We think it is practical to perform
translation between OCL and JML.

[6] A. Sarcar and Y. Cheon, “A new Eclipse-based JML compiler
built using AST merging,” Department of Computer Science,
The University of Texas at El Paso, Tech. Rep, pp. 10–08,
2010.
[7] J. Kiniry and D. Cok, “ESC/Java2: Uniting ESC/Java and
JML,” Construction and Analysis of Safe, Secure and Interoperable Smart devices (CASSIS’2004), vol. 3362, pp. 108–128,
2005.
[8] W. Harrison, C. Barton, and M. Raghavachari, “Mapping
UML designs to Java,” in Proc. of the 15th ACM SIGPLAN
conference on Object-oriented programming, systems, languages, and applications, 2000, pp. 178–187.
[9] Eclipse Foundation, “Xtext - Language Development Framework,” http://www.eclipse.org/Xtext/.

VI. C ONCLUSION[10] A. Hamie, “Translating the object constraint language into
the java modelling language,” in Proc. of the 2004 ACM
symposium on Applied computing, 2004, pp. 1531–1535.

This paper proposes a translation technique between OCL
and JML maintaining OCL code by describing their original forms in the comment area of the target languages.
We applied our implemented tool to two projects used in
our previous work and also seven additional open source
projects. From the results of experiment, we found that ourtool performs translation from OCL to JML and from JML to
OCL efﬁciently. However syntactically corresponding ratio
is not high. We found that the ratio of JML statements whichis essentially impossible to translate is less than one percent.
In the future, we want to reﬁne the translation rules
in order to improve correspondence ratio because formsof half the number of statements are different from theoriginal statements after applying our several bidirectionaltranslations. We also want to handle other JML features suchas pure, model and ghost modiﬁers.

[11] K. Miyazawa, K. Hanada, K. Okano, and S. Kusumoto,“Class enhancement of our ocl to jml translation tool and its
application to a curriculum management system,” In IEICE
Technical Report, vol. 110, no. 458, pp. 115–120, 2011.
[12] M. G. L. I. S. Bajwa, B. Bordbar, “OCL Constraints Generation from Natural Language Speciﬁcation,” in 14th IEEE
The Enterprise Computing Conference (EDOC 2010), 2010,
pp. 204–213.
[13] Y. Cheon, C. Avila, S. Roach, and C. Munoz, “Checking
design constraints at run-time using OCL and AspectJ,”International Journal of Software Engineering, vol. 3, no. 1,
pp. 5–28, 2009.
[14] K. Anastasakis, B. Bordbar, G. Georg, and I. Ray,
“UML2Alloy: A Challenging Model Transformation,”
ACM/IEEE 10th International Conference on Model Driven
Engineering Languages and Systems (MoDELS 2007), vol.
4735, pp. 436–450, 2007.

ACKNOWLEDGMENTS
This work is being conducted as a part of Grant-in-Aid
for Scientiﬁc Research C(21500036) and S(25220003).

[15] S. Shah, K.Anastasakis, and B. Bordbar, “From uml to alloy
and back,” in 6th Workshop on Model Design, Veriﬁcation andValidation (MODEVVA 09) published in ACM International
Conference Proceeding Series, vol. 413, 2009, pp. 1–10.

R EFERENCES[1] A. Tanaka and O. Takahashi, “Experimental transformations
between business process and soa models,” International
Workshop on Informatics 2011, pp. 104–112, 9 2011.

[16] A. Razavi and K. Kontogiannis, “Partial evaluation of modeltransformations,” in Proc. of the 2012 International Conference on Software Engineering, ser. ICSE 2012, 2012, pp.
562–572.

[2] Object Management Group, “Ocl 2.0 speciﬁcation,” 2006,
http://www.omg.org/spec/OCL/2.0.

[17] Y. Yu, Y. Lin, Z. Hu, S. Hidaka, H. Kato, and L. Montrieux, “Maintaining invariant traceability through bidirectional transformations,” in Proc. of the 2012 International
Conference on Software Engineering, ser. ICSE 2012, 2012,
pp. 540–550.

[3] G. Leavens, A. Baker, and C. Ruby, “Jml: A notation for
detailed design,” Behavioral Speciﬁcations of Businesses andSystems, pp. 175–188, 1999.
[4] K. Hanada, H. Shinba, K. Okano, and S. Kusumoto, “Implementation of a prototype bi-directinal translation tool between
ocl and jml,” International Workshop on Informatics 2012
(IWIN2012), pp. 121–127, 9 2012.
[5] B. Meyer, Eiffel: the language.
Prentice-Hall, Inc., 1992.

Upper Saddle River, NJ:

54