Practical Application of a Translation Tool from UML/OCL

to Java Skeleton with JML Annotation

Kentaro Hanada, Kozo Okano, Shinji Kusumoto and Kiyoyuki Miyazawa

Graduate School of Information Science and Technology, Osaka University, Osaka, Japan

Keywords:

Model-driven Architecture, OCL, JML, Design by Contract.

Abstract:

In recent years, MDA techniques have been strongly developed. Thus, translation techniques such as UML

to some program languages have gained a lot of attention. Translation techniques such as OCL to JML have

been also researched. OCL is a language to describe detail properties of UML and standardized by OMG,

while, JML is a language to specify properties of Java program. Both OCL and JML are based on DbC and

able to provide properties of classes or methods. There are, however, not many researches on translating

automatically OCL into JML and past researches often pay little attention to collection features, especially

iteration. Our research group has proposed a concrete method which translates UML class diagram with

OCL into Java skeleton with JML. This paper presents an implementation tool based on the technique. To

evaluate the quality of the tool, we applied the tool to two real examples, a warehouse management program

and a syllabus management system. As a result, we found that every OCL constraint described manually was

translated successfully into JML. Also, we found some defects existed in the design of a syllabus management

system.

1 INTRODUCTION

In recent years, MDA (Model Driven Architecture)

(Kleppe et al., 2003) techniques have been strongly

developed. Thus, translation techniques such as UML

to some program languages have gained a lot of atten-

tion.

Translation techniques such as OCL (Object Man-

agement Group, 2006) to JML (Leavens et al., 1999)

have been also studied. OCL is a language to de-

scribe detailed properties of UML and standardized

by OMG (Object Management Group), while, JML

is a language to specify properties of a Java program.

JML aims for describing more detail properties than

OCL does. Both OCL and JML are based on DbC

(Design by Contract) (Meyer, 1992) and able to pro-

vide properties of classes or methods. There are not,

however, many researches on translating automati-

cally OCL into JML, and past researches often pay

little attention to collection features, especially itera-

tion. The problem should be solved because the iter-

ation feature is necessary and widely used.

We have already proposed a concrete method

which translates a UML class diagram with OCL into

a Java skeleton with JML (Owashi et al., 2010). This

paper presents a tool implementing the method.

The tool is applied to two real examples, a ware-

house management program and a syllabus manage-

ment system, which consist of seven classes and 60

classes, respectively. As a result, we found that ev-

ery OCL constraint described manually was trans-

lated successfully into JML. In addition, 86% of them

are translated into the same form of JML described

manually and independently. The translation time is

less than seven seconds for the syllabus management

system. Consequently we can conclude that our tool

can practically translate OCL statements.

The contributions to the ﬁeld are the following

three items. The ﬁrst one is implementation of the

translation tool as an Eclipse plug-in. The tool sup-

ports iteration feature that is not supported by a lot

of existing research of translation from OCL to JML.

The second one is that the proposal method utilizes

external libraries (including Java standard libraries

and third party’s libraries) to improve the utility of

the translation tool. The last one is an evaluation of

the translation tool. We carried out evaluation experi-

ment onto real projects.

The organization of the rest of the paper is as fol-

lows. Sec.2 describes the background of this research

and related work. Sec.3 presents overviewof our tool.

Sec.4 and Sec.5 will give experimental results and

389

Hanada K., Okano K., Kusumoto S. and Miyazawa K..

Practical Application of a Translation Tool from UML/OCL to Java Skeleton with JML Annotation.

DOI: 10.5220/0004151403890394

In Proceedings of the 14th International Conference on Enterprise Information Systems (MDDIS-2012), pages 389-394

ISBN: 978-989-8565-11-2

 2012 SCITEPRESS (Science and Technology Publications, Lda.)

discussions, respectively. Finally, Sec.6 concludes the

paper.

2 BACKGROUND

In this section, we present background of our research

such as some techniques and related works.

2.1 OCL and JML

OCL details properties of UML models. It is stan-

dardized by OMG. UML diagram alone cannot ex-

press rich semantics of and all relevant information

about the target design. OCL allows describing pre-

cisely the additional constraints on the objects and en-

tities in a UML model.

JML is a language to detail constraints of Java

methods or objects (Leavens et al., 1999). The con-

straints are based on DbC. It is easy for novices to de-

scribe properties in JML because the syntax of JML

is similar to that of Java.

2.2 Related Work

Hamie (Hamie, 2004) proposed a method which

translates from OCL into JML based on syntax con-

version techniques. Rodion and Alessandra (Ro-

dion and Alessandra, 2006) enhanced the technique

of Hamie (Hamie, 2004). They proposed translation

techniques of Tuple type operations and a part of Col-

lection type operations. Moreover, they implemented

these techniques. Speciﬁcally, OCL operations that

do not correspond operations of JML or Java directly

such as setOfSets−> flatten() were solved by deﬁn-

ing generalized libraries like expression (1)

JMLTools.ﬂatten(setOfSets) (1)

Avila et al. (Avila et al., 2008) proposed a method

which reduces differences of collection operations

among OCL and JML. They also provide a Java class

library which interprets some of OCL statements.

These methods, however, do not enough support an

iterate feature that is the most basic operation among

collection loop operations. An iterate feature is an

operation which applies an expression given as its ar-

gument to each element of a collection which is also

given as its another argument.

Set{1,2,3}−> iterate(i: Integer;

sum : Interger = 0 | sum+ i) (2)

Expression (2) deﬁnes an operation that returns a

value which represents a sum of all elements in Set.

private T1 mPrivateUseForJML01(){

µ(init);

for (T2 e: µ(c1))

res = µ(body)

return res;

}

Figure 1: General Java Template of the Method for Iterate

Feature

In expression (2), the ﬁrst argument (i : Integer) de-

ﬁnes an iterator variable. The second argument (sum :

Integer = 0) deﬁnes a variable which is used to store

the return value and its initialization. The third argu-

ment (sum + i) stands for an expression that is exe-

cuted iteratively in the loop.

Our research group proposed a technique to re-

solve this problem by inserting a Java method that is

semantically equal to each OCL loop feature (Owashi

et al., 2010). It is worthful that the algorithm deals

with the iterate feature because an iterate feature is

widely used.

Expression (3) showsthe general format of an iter-

ate feature. The variables e, init, body and c mean an

iterator variable, a declaration of the return value and

its initialization, an expression executed in the loop,

and a Collection type variable respectively.

c−> iterate(e; init | body) (3)

Figure 1 shows a general format of our newly created

method. The keywords µ(), T

, T

and the variable res

mean a function which translates an OCL expression

into a Java expression, a variable declared in init, a

variable e, and the name of a variable declared in init

respectively.

3 IMPLEMENTATION

In this section, we will present the implementation of

our translation tool. Figure 2 shows a brief overview

of our translation tool. We have implemented the tool

as an Eclipse plug-in. In this section, ﬁrstly, we show

the detailed explanation about the implementation of

the parser of OCL. Secondly, we explain in detail

about how to support the external type information.

Finally, we list parts of translation rules from OCL

statements to JML statements.

3.1 Translation from UML to Java

We utilize an existing resource to translate from UML

to Java. Papyrus UML (Eclipse Foundation, 2012a) is

used as roles of drawing UML and translation from

ICEIS2012-14thInternationalConferenceonEnterpriseInformationSystems

390

Figure 2: Brief overview of our translation tool.

UML to Java. Papyrus UML is an open-source UML

CASE tool. It is developed as one of Model Develop-

ment Tools (MDT) projects in Eclipse Foundation. It

is available as an Eclipse plug-in. Its input and output

ﬁles are compliant with XMI, the standard UML ﬁle

format by OMG.

3.2 Implementation of OCL Parser

Firstly, we describe the parser generator. We

use ANTLR (Parr, 2007) for the parser generator.

ANTLR automatically generates a parser using LL(k)

parsing. ANTLR supports Java as an output language.

It generates not only a parser but also its associate

lexical analyzer. Paper (Object Management Group,

2006) deﬁnes EBNF of OCL. It contains some mod-

iﬁcation in EBNF. Therefore, we modify the EBNF.

As a result, the grammar of OCL statements is con-

structed by EBNF with the size of 50 non-terminal

symbols and 100 generation rules.

Secondly, we describe a method to support for

external libraries. We designed the OCL parser to

parse only two kinds of types. One is a deﬁned type

by a user. The other is a standard type in OCL.

It is, however, difﬁcult to design without using the

standard library of Java and external packages devel-

oped by third parties. For this reason, the translation

tool needs to use information on types of external li-

braries and the standard library. There are several ap-

proaches. One approach is that the translation tool is

applied to UML class diagrams with extra diagrams

that have enough information on standard library and

third parties libraries. These extra diagrams are pre-

pared by a user in advance. The other approach is

that the OCL parser accepts directly information on

such extra types. There are, however, vast amounts of

classes in the standard library. Also, ﬂexible accep-

tance of external libraries seems difﬁcult. For these

reasons, we choose the ﬁrst approach. In order to ob-

tain UML class diagrams with extra diagrams, we use

Java2UML (Atos Origin TOPCASED Team, 2006).

The input is a Java project or a package folder. The

output is UML diagrams corresponding to the Java

ﬁles in the input directory. We improved Java2UML,

so that it can read a single Java ﬁle speciﬁed in the

input. It also obtains super classes of the input class.

From the information, a user can specify a subset of

super classes that are needed for further analysis.

Finally, we describe translation rules of OCL

statement to JML statement. The set of the transla-

tion rules is deﬁned in Owashi (Owashi et al., 2010).

We, however, deﬁned new translation rules due to the

set of the translation rules are not sufﬁcient. Table 1

is a set of new translation rules. The number of whole

rules is about 150.

A translation function of an OCL statement to a

JML statement is expressed by µ in the same manner

as (Hamie, 2004). Any Integer, Real and Boolean are

expressed by a

. Any Collection is expressed by c

4 EXPERIMENTS

This section will explain experiments in detail. We

conducted two experiments. The ﬁrst experiment uses

a small project (Experiment 1). The second experi-

ment (Experiment 2) is larger than Experiment 1.

4.1 Preparation of Experiment

We need OCL statements and ideal JML statements

for reference. OCL statements are used to generate

JML statements by our translation tool. Ideal JML

statements are used to compare and analyze generated

JML statements by our translation tool as references.

The project of Experiment 1, however, does not have

OCL statements. In order to perform Experiment 1,

we described OCL statements. The OCL statements

Table 1: New µ translation.

.oclIsKindOf(a

) = µ(a

).class.isAssignableFrom

(µ(a

).getClass())

.oclIsTypeOf(a

) = µ(a

).getClass().equals(µ(a

))

a.oclIsUndeﬁned() = µ(a) == null

PracticalApplicationofaTranslationToolfromUML/OCLtoJavaSkeletonwithJMLAnnotation

391

are syntactically identical and logically equivalent to

ideal JML statements.

The project used in Experiment 2 does not have

not only OCL statements but also JML statements.

We, however, need both data in order to perform an

Experiment 2. Therefore, ﬁrstly, we described JML

statements on the basis of the speciﬁcation which is

read from the codes and comments of javadoc. Sec-

ondly, we checked the correctness of the JML state-

ments by running test cases with a runtime assertion

checker, JMLrac. Finally, we described OCL state-

ments that are syntactically identical and logically

equivalent to ideal JML statements.

In order to evaluate the quality of JML statements

generated by the translation tool, we measured three

items, coverage, recall ratio, and execution time of the

runtime assertion checker.

Here, ﬁrstly we provide a metric for the coverage.

We deﬁne the coverage by Expression (4), where C

all

and C

translatable

are the number of pre-conditions and

post-conditions, and the number of statements trans-

lated by the translation tool, respectively.

Coverage = C

translatable

all

(4)

Secondly, we provide the recall ratio. We de-

ﬁne the recall ratio by Expression (5), where C

equal

the number of statements which are translated by the

translation tool and are identical to the corresponding

ideal JML statement. Here, “corresponding” stands

for syntactical and logical equivalence.

recallratio = C

equal

translatable

(5)

Finally, we compare execution times of runtime

assertion checker, JMLrac by applying source codes

with JML statements generated by the translation tool

and that with ideal JML statements. We use JML4c

(Sarcar and Cheon, 2010) and JML4rt (Sarcar and

Cheon, 2010) as a JML compiler and a runtime asser-

tion checker, respectively. As far as we know, JML4c

is the only compiler that supports enhanced for-loop

and generics. Also for a given executable ﬁle gener-

ated by JML4c, JML4rt checks consistency between

runtime values of variables and the constraints given

by the JML statements. When some of constraints of

JML statements violate to the runtime values of vari-

ables, JML4rt outputs the location of violated point

and the values of variables at the location.

4.2 Environment of Experiments

Evaluations have been performed on an Intel(R)

Core(TM)2 Duo E7300 2.66GHz 2.67GHz HP Com-

paq dx7500 Microtower with 4GB RAM running

Windows Vista 64bit.

4.3 Experiment 1

In Experiment 1, we evaluated the quality of the trans-

lation using the warehouse management program. It

consists of seven classes. Table 2 shows components

of the warehouse management program in details. It

(Owashi et al., 2008) has correct JML statements by

the past research. In Experiment 1, we add OCL state-

ments for 20 methods.

In Experiment1, as we described, JML statements

have already been fully annotated. We selected three

core classes and annotated OCL statements. For the

three classes, we can translate every OCL statements

into correct JML statements. Consequently, Cover-

age and recall ratio are both 100 %, which indicates

the power of the tool. Also, we observed execution

times of both cases. The results show that there is no

distinguishing execution time of manual JML state-

ments from that of JML statements by the translation

tool.

Execution time of translation from OCL state-

ments to JML statement is 20ms. Also, execution

time of translation from abstract tree of OCL to ab-

stract tree of JML is 1ms. Therefore, if we describe

OCL statements to all attributesand all methods of the

program, perhaps execution time of translation from

these OCL statements (about one hundred statements)

to JML statement will be about 2 sec.

4.4 Experiment 2

In Experiment 2, we evaluated the quality of transla-

tion tool by data of educational material of IT-Spiral

(Ministry of Education, Culture, Sports, Science and

Technology, 2010). The project is a syllabus manage-

ment system of Wakayama University. The system

consists of 200 classes, and we choose core 60 classes

and annotate 400 methods in the chosen classes. Ta-

ble 3 shows parts of OCL statements and JML state-

ments.

Table 4 shows the result of translation from OCL

statements of the syllabus management system to

Table 2: Components of warehouse management program.

Class Name # of methods # of lines

ContainerItem 12 224

Customer 10 156

Item 7 110

ReceptionDesk 8 162

Request 16 245

StockState 0 9

Storage 10 258

TOTAL 63 1164

ICEIS2012-14thInternationalConferenceonEnterpriseInformationSystems

392

/*@ requires this.getDAO(UserDAO.class)

!= null;@*/

public void save(final User user)

throws ServiceException{

getDAO(UserDAO.class).save(user);

}

Figure 3: Save method of UserServiceImpl class.

JML statements. It shows that the coverage and the

recall ratio are 89.9% and 86.0%, respectively. All

OCL statements are translated to JML statements.

The JML statement that is not identical to ideal JML

statement is constraints with iteration feature.

Half of JML statements are not translated due to

following two cases.

1. JML statements including class literal

2. JML statements including an array expression

For example, JML statement includes class literal

shown in Figure 3. We could not describe the state-

ment as OCL statements. We described “requires

this.getDAO(UserDAO.class) != null;” as JML in the

save method because the method must check that

DAO is not null as pre-condition. UserDAO class is,

however, the class literal; we could not describe the

corresponding OCL statements.

Figure 4 shows the example statements includ-

ing arrays. The post-condition checks that values in

this.kyoukasho have the same values in the array of

parameter. OCL, however, uses Sequence instead of

the array; we cannot describe the corresponding OCL

statements. We will explain the details in Section 5.

5 DISCUSSIONS

5.1 Some Observations on the Results

The translation tool can translate 90 percent out of all

OCL statements in 60 classes into JML statements.

We, however, could not translate the following JML

Table 3: The number of classes and methods which are an-

notated in OCL.

Class # of classes # of methods

ServiceImpl 13 74

DAO 11 64

Util 6 29

DTO 2 25

Entity 30 216

TOTAL 62 408

/*@

ensures kyoukasho != null ?

(\forall int i4; i4>=0

&& i4<this.kyoukasho.length;

kyoukasho[i4] == null ||

this.kyoukasho[i4].equals(kyoukasho[i4]))

&& this.kyoukasho.length == kyoukasho.length

: this.kyoukasho == null;

@*/

public void setKyoukasho

(final JugyouShousaiKyoukasho[] kyoukasho){

this.kyoukasho = kyoukasho;

}

Figure 4: JML statements of the method which contains

arrays.

statements to OCL statements: assignable keyword,

class literal, and arrays.

There is not a keyword corresponding to

“assignable” in OCL. Also, there is not concept of

class literal in OCL because class literal is a proper

concept in Java language. OCL does not deﬁne ar-

rays, but Sequence type is provided to represent a list

structure. Sequence is an indexed bag (multi-element

set). It supports insertAt() and prepend() features,

thus Sequence can be translated into List in Java. Our

tool also translates in the above manner. On the other

hand, there are few demands to translate sequence

feature into an array. It is, however, arguable that it

supports translation from sequences to multi dimen-

sion arrays for some reasons such as efﬁciency.

5.2 Threats to Validity

Here, we simply summarize threats to validity. As

external threats to validity, we can say the number

of experiments is not enough. Therefore, we cannot

generalize the results and discussion. We, however,

choose real examples; the tendency can be inferred.

Of course, to obtain more precise data, we have to

apply the tool to more applications.

As internal threats to validity, we can enumerate

(1) that we have constructed OCL statements man-

ually from JML statements and (2) that we do not

Table 4: The result of Experiment 2 to the syllabus manage-

ment system.

The number of JML statements by hand(C

all

) 602

The number of OCL statements 541

The number of translated JML statements

by the tool(C

translatable

) 541

The number of match of translated JML

statements and ideal JML statements(C

equal

) 465

The number of match by inserting methods 57

PracticalApplicationofaTranslationToolfromUML/OCLtoJavaSkeletonwithJMLAnnotation

393

translate all OCL statement of all class in both Ex-

periments.

As for (1), if OCL statements are described by a

person who knows about the detail of translation al-

gorithm of out tool, it may be said that the OCL state-

ments include a problem in our experiments. OCL

statements, however, are described manually by a per-

son who does not know about the detail of our transla-

tion tool. We think this shows the validity of the OCL

statements in our experiments.

As for (2), we choose core classes of both cases.

For example, Experiment 2 uses core classes that are

used to access its database. We analyzed syntactically

all patterns that are covered in the description. Also,

the main objective of the experiments is how many

OCL statements are translated into JML statements.

We think it is not serious problem that we cannot an-

notate to every class.

6 CONCLUSIONS

This paper presents a tool which translates OCL in-

cluding iteration features into JML. On implementa-

tion of the tool, we enhance our tool to be able to deal

with external libraries that are not included in design

projects such as Java standard library. We applied our

tool to two real examples, a warehouse management

program and a syllabus management system. As a re-

sult, we found that 90% of necessary constraints were

well translated, and 86% of constraints were trans-

lated into suitable expressions. The translation time

in which about 600 OCL expressions are translated is

less than seven seconds. Consequently we can con-

clude that our tool can translate in practical time.

Future work includes reverse translation from

JML to OCL. Implementing mutual transformation

between OCL and JML by use of Xtext (Eclipse

Foundation, 2012b) is considerable as future work.

ACKNOWLEDGEMENTS

This work is being conducted as Grant-in-Aid for Sci-

entiﬁc Research C (21500036).

REFERENCES

Atos Origin TOPCASED Team (2006). Java to UML.

http://gforge.enseeiht.fr/projects/java2uml/.

Avila, C., Flores, Jr., G., and Cheon, Y. (2008). A Library-

Based Approach to Translating OCL Constraints to

JML Assersions for Runtime Checking. In Interna-

tional Conference on Softw. Eng. Research and Prac-

tice, pages 403–408.

Eclipse Foundation (2012a). Papyrus UML.

http://www.eclipse.org/modeling/mdt/papyrus/.

Eclipse Foundation (2012b). Xtext - Language Develop-

ment Framework. http://www.eclipse.org/Xtext/.

Hamie, A. (2004). Translating the Object Constraint Lan-

guage into the Modeling Language. In In Proc. of the

2004 ACM symposium on Applied computing, pages

1531–1535.

Kleppe, A., Warmer, J., and Bast, W. (2003). MDA ex-

plained: the model driven architecture: practice and

promise. Addison-Wesley Longman Publishing Co.,

Inc. Boston, MA, USA.

Leavens, G., Baker, A., and Ruby, C. (1999). JML: A No-

tation for Detailed Design. Behavioral Speciﬁcations

of Businesses and Systems, pages 175–188.

Meyer, B. (1992). Eiffel: the language. Prentice-Hall, Inc.,

Upper Saddle River, NJ.

Ministry of Education, Culture, Sports, Science and Tech-

nology (2010). IT Spiral. http://it-spiral.ist.osaka-

u.ac.jp/.

Object Management Group (2006). Ocl 2.0 speciﬁcation.

http://www.omg.org/cgi-bin/apps/doc?formal/06-05-

01.pdf.

Owashi, M., Okano, K., and Kusumoto, S. (2008). De-

sign of Warehouse Management Program in JML

and Its Veriﬁcation with Esc/Java2 (in Japanese).

The IEICE Transaction on Information and Systems,

91(11):2719–2720.

Owashi, M., Okano, K., and Kusumoto, S. (2010). A Trans-

lation Method from OCL into JML by Translating the

Iterate Feature into Java Methods (in Japanese). Com-

puter Software, 27:106–111.

Parr, T. (2007). The Deﬁnitive ANTLR Reference: Building

Domain-Speciﬁc Language. Pragmatic Bookshelf.

Rodion, M. and Alessandra, R. (2006). Implementing an

OCL to JML translation tool. In In IEICE Technical

Report, volume 106, pages 13–17.

Sarcar, A. and Cheon, Y. (2010). A new Eclipse-based JML

compiler built using AST merging. Department of

Computer Science, The University of Texas at El Paso,

Tech. Rep.

ICEIS2012-14thInternationalConferenceonEnterpriseInformationSystems

394