Logic Model Transformation

The architecture of implementing the transformation in logic model is shown as Figure 4-4; it includes two components developing by JavaCC and JDOM [11], which both are the available techniques written in Java. These two components will read the original programming codes, indicates “Program logical codes (server)” at the top left of the figure, run on the ART server and the API mapping rules, indicates “API mapping rules” at the top right, written in IM²L; after read these two files, “Code Generator”, marked in the middle, will use the “Transformer” to compare the statements with the mapping rules and to transform

the matched statements into the target statements. Finally, we will get the “Program logical codes (client)” which composed by the target statements and it can be executed on the client side.

Figure 4 – 4 architecture of code generator in logic model

The two available techniques, JavaCC and JDOM, we used in the logic model shall be examining how we exploited them to fulfill our requirement in the continuing paragraph.

We use JavaCC to generate a Java parser which can help us checking the programming blocks and the APIs’ name using in the applications. The Java parser contains many Java language grammars written in regular expressions. We can make use of it to build a parsing tree and note down the interested information into a temporary file. Such as the statements in the programming block and the APIs’ name and parameters used in the original application programming codes are inscribed in the temporary file. Then, the main component doing the compared and transformed task can easily get the marshaled information and have the better performance.

JDOM is a new API which can let programmers handle the XML documents as Java objects. It also improves the performance in accordance with Java. So, JDOM can handle a XML document as we with just like DOM and have the well performance as SAX. We use JDOM to trace out the mapping rules recorded in the API mapping rules written in IM²L. By using the mapping rules, we can find the corresponding APIs within the target developing platform and forward the information to the Code Generator which is responsible to the comparison.

L

IM² in the aspect of using in logic model is mainly in describing how the APIs, which is run in the application on the ART server, should be transformed into the APIs which can be run upon the runtime environments on the client side. As we mentioned in the section 3.3, the mobile applications run on the client side and the server side are both written in Java, so we do not need to modify the syntaxes and the semantics of the statements during transformations.

What we should do to port the program logical codes into different platforms is tracing out the APIs among the statements and transforming these to the target platforms according to the mapping rules written in IM²L. Figure 4-5 is an example for describing the API mapping rules written in IM²L using in the logic model. The explanations of what the elements do are as follows:

z InterfaceMapping

The element defines a set of API mapping rules within various developing platforms. The detailed mapping rules are illustrated in this section enclosed by the InterfaceMapping element.

z class

It records what class the API belongs to. In the Object-Oriented programming language, it is a common usage to specify the references of the APIs.

z method

The value of this element specifies the method’s name of the API. We will use the value of method and params, which will be talked later, to construct the mapping rules.

z progBlock

progBlock is abbreviate from the programming block. The value of this element can be “startApp”, “stopApp”, “listener” and “all” which is the default value. The functionality of using it is to promote the performance of the API transformations. The reason is that some APIs can just be used in some programming block or just be called during the life state of the applications in MIDP, so we do not have to compare these APIs in other programming blocks. This mechanism of adopting this element can make the performance well.

z params

params is an element of a nest shape. It can have lots of argument settings marked by parameters within. And it represents the argument that the API needs to set in itself.

z platform

This element is used in recording the API transformation rules corresponding to different developing platforms. There are two sets of platform elements in Figure 4-5 and it means that we support the API transformations between these two developing platforms. The first one in the name attribute of the platform is j2se and it records the usage of the specified API run on the j2se platform in its element value. Second is j2me and it also records the usage of the corresponding API in the j2me developing platform. By adding element of platform directly, we can easily extend our API transformations to a new developing platform, such as PJava [15].

<InterfaceMapping>

Figure 4 – 5 example of mapping rules in logic model

In the transformation of logical programming codes, we had defined the mapping rules from the APIs provided in ART to the APIs provided in MIDP completely. The mapping rule shown in Figure 4-5 describes the API usage of displaying a window on the ART platform can be transformed to the API of setting a window to the displayable object in the MIDP. Because we can only display a window on the monitor of handheld devices, we should select a suitable API to attain the same purpose on the client side. Here, we choose the API named setCurrent in MIDP and pick up a Displayable object as the parameter. In other mapping rules, we can also ensure that they will work well after transformed to the APIs run on the client side.