\documentclass[a4paper,10pt]{article}
\usepackage{graphicx}
\usepackage{hyperref}

%opening
\title{}
\author{}

\begin{document}

\maketitle

\begin{abstract}

\end{abstract}

\section{Reverse engineering behavior specification of components from Java}

Reverse engineering general Java application into component application
consists of two tasks. First, extraction of an architectural view
(identification of components, their interconnections, etc.); second, extraction
of a dynamic behavior specification of the components identified during the
first task. Constituting an interface between the two tasks, the architectural
information is to be stored in a form of Java annotation in the actual Java
sources of the application being reverse engineered.

This section presents goals, means and organization of the second task in the
scope of the ECONET project, and thus summarizing the results of the Prague
2007 Workshop working sessions.


\subsection{Goals}

Each group participating in the project has developed its own formalism for
behavior specification. Therefore, the idea is to make the reverse engineering
as general as possible in order to allow extraction of behavior in any
formalism.

To be more specific, the formalisms considered are:
\begin{itemize}
 \item \emph{Enhanced behavior protocols} (EBP) developed by DSRG
 \item \emph{eLTS} developed by COLOSS
 \item \emph{STS} developed by OBASCO
\end{itemize}


The individual behavior specification formalisms differ a lot. This
makes creation of a general tool very difficult. However, steps common to
extraction of any behavior specifications (in particular Behavior protocols and
LTS-based formalisms eLTS and STS) might be identified. Thus, the general
approach is to divide all necessary steps of behavior extraction into two
parts: i) steps common to all formalisms, and ii) steps specific to a
particular formalism.

The first part will be implemented in a General analysis tool, while the second
part will be performed by back-ends specific to a particular formalism.

To prevent reinvention of the wheel, the analysis tool is to be implemented
using existing libraries/tools/platforms (for parsing Java sources and
annotation extraction, etc.).

To sum it up, the goals of reverse engineering behavior specification are as
follows:

\begin{enumerate}
 \item Find a suitable libraries/tools/platforms for analysis of Java sources
 \item Create a generic Java analysis tool which produces an intermediate
representation of behavior suitable for subsequent creation of
concrete behavior specifications in a chosen formalism
 \item Create formalism-specific back-ends for extraction of behavior
specification from the intermediate specification
\end{enumerate}



\subsection{Annotations}

Reflecting the goals stated in the previous section, the process of reverse
engineering behavior specification starts, where the first process (reverse
engineering component architecture) ends---i.e. by extracting and using
architectural information provided in a form of Java annotations directly in the
Java sources and, of course, the Java sources themselves.

The necessary architectural information consists of:

\begin{enumerate}
  \item assignment of Java classes to individual components,
  \item identification of provided interfaces and their methods,
  \item identification of required interfaces (as class attributes), and
  \item demarkation of the components' initialization code.
\end{enumerate}

Moreover, in order to help extraction of behavior specification, it might be
helpful to have explicitly annotated \emph{ValueType} classes. By a ValueType,
we mean a class used for storing and passing data rather than providing a
specific functionality.

As the ValueTypes have to be reflected in the behavior specification, hints
about the abstraction may be necessary. By abstraction we mean replacement
of the actual ValueType by a simpler abstract type ( for example integer type by enumeration). 
Although the abstract type has less states, it captures all information necessary
for the component behavior. For example if the behavior of the component
depends on the sign of the integer parameter, all information we need can be stored
in the single bit of information. Thus, the boolan type suffices for the parameter.

The information about ValueType abstraction could be specific to
the target formalism and even more added manually by a human user. More
detailed description of the proposed set of annotations follows.


\subsubsection{Component}

One or more Java classes can be assigned to a single component. Such
an assignment is specified by the following annotation of a Java class:
\begin{verbatim}
@inComponent(annotation_src, component_name)
\end{verbatim} 
As in the rest of this section, the \verb|annotation_src| specifies the origin
of the annotation---i.e. a name of a tool which inserted the annotation in the
code or whether the annotation has been inserted manually.


\subsubsection{Interfaces}

Methods of Java classes may be assigned to component's \emph{provided
interfaces} in two different ways. First, as an annotation of a Java class:
\begin{verbatim}
@provided(annotation_src, model_iface_name, java_iface_name)
\end{verbatim}
This way, all methods of the specified Java interface (which the annotated
class has to implement) are marked as a part of the provided interface of the
component. The second possibility is to mark individual methods of a Java class
by the annotation:
\begin{verbatim}
@provided(annotation_src, model_iface_name)
\end{verbatim}
This is necessary in a case the component's provided interfaces do not
correspond with the Java interfaces.

In Java sources, a required interface is present in a form of a class attribute.
The attribute stores a reference to another component, whose provided interface
is bound to this required interfaces. Therefore, the target of the annotation
for required interface is an attribute of a Java class:
\begin{verbatim}
@required(annotation_src, model_iface_name)
\end{verbatim}


\subsubsection{Component's initialization}

In order to be able to derive the behavior specification correctly, knowledge
about a component initialization is crucial. By initialization, we mean
instantiation of classes, assigning references to the required interfaces (i.e.
to the class attributes), starting threads of active components, etc.

Typically, there are two ways of initialization. First, the initialization is
performed by a class. This class is the first instantiated and is responsible (its constructor)
for the instantiation and initialization of the component's content. To identify
such a class, the following annotation is used:
\begin{verbatim}
@initclass(annotation_src, component_name)
\end{verbatim}


The second possibility is that the component content is instantiated and
initialized by a static method (an equivalent of the \emph{main} method).
\begin{verbatim}
@initmethod(annotation_src, name_of_the_component)
\end{verbatim}


\subsubsection{Data and method parameters abstraction}

Some of the internal component data and method parameters might be of
crucial importance for correct extraction of the behavior specification. Those
should be also explicitly annotated, in order that the behavior specification
extractor could take them into account and provide a necessary abstraction.

However, it is hard to predict the needs of behavior extraction in advance and
thus these annotations are yet to be further elaborated. The initial proposal is
to identify ValueTypes classes and interfaces, and therefore mark all their
instances as important for the component behavior.
\begin{verbatim}
@businessparametertype(annotation_src)
\end{verbatim}

As some types might be important only in a specific context (e.g. String),
there is also possibility to mark particular method parameters and Java class
attributes as important for business logic.
\begin{verbatim}
@businessattribute(annotation_src)
@businessparameter(annotation_src, parameter_name)
\end{verbatim}

For the actual behavior specification extraction, hints on how to perform a data
abstraction from the concrete values of these types have to be added by a human
user. A particular format of these hints will be further analyzed.


\subsubsection{External dependencies}

Some architecture information cannot be introduced into the code as
annotations. Mostly, these are the external dependencies on the class libraries
used by the component code. Classes from the libraries can be also important
for the behavior extraction but in general, they cannot be directly annotated.
Therefore, these dependencies are listed in an extra file. The complete code of
the component is thus a set of classes annotated by both the
\verb|InComponent| annotations and also the content of the dependencies file.


\subsection{Tools for Java source analysis}

Having the Java sources properly annotated, the question of how to extract the
annotations and analyze the sources comes up. There is quite a choice of tools
to be used for this purpose. 

Possible options are:
\begin{itemize}
 \item JavaC \cite{JavaC}---standard Java compiler from
Sun---is a natural first option as it is standard part of the Java development
kit (JDK) and features a reasonable interfaces for either annotation
processing alone or to obtain the complete abstract syntax trees.
 \item JavaCC (Java Compiler Compiler) \cite{JavaCC} is a generator of
parsers. To create a parser, it uses a LL(n) grammar.
 \item ANTLR \cite{ANTLR} is another parser generator which also uses LL(n)
grammars.
 \item Java CUP \cite{JavaCUP} is also a parser generator, but in comparison to
the previous ones it uses LALR(1) grammars. It is quit similar to the
standard YACC and Bison tools. In contrast, it is written in Java.
 \item SableCC \cite{SableCC} is another LALR(1) parser generator.
\end{itemize}

In a case, the chosen parser generator does not provide a lexical analyser, a
usage of tools like JLex and JFlex has to be considered.

Choosing the suitable tool will require deeper exploration and in-depth
analysis of all features provided by the tools. The preferred option is to
use JavaC, as it allways guarantees to parse the current (and also older)
version of the Java languages and also it does not introduce any
third-party tool dependencies.

\subsection{Generic analysis tool (GAT)}

Behavior specification extraction is divided into two steps. First step is to
preprocess the annotated Java sources and propagate information about
architecture to the actual Java code, so that Java statements can be
categorized as either externaly visible events (method calls on required
interfaces), visible actions (change of business attributes), changes in
control flow (if and cycle statements), or internal invisible actions (work
with local variables). The result of the process is an abstract syntax tree
with nodes ``colored'' by the architecture information (obtained from the
annotations).


In the second step, the produced cAST (colored AST) is used to create a control
flow graph (CFG) representing the code. Again, nodes of the graph are
``colored'' by the architecture information (cCFG). Both cAST and cCFG is
available by the defined API (all details about the API have to be analyzed yet)
and/or in a serialized textual form.

A specific formalism back-end can choose whether cAST is sufficient for it or
whether the usage of cCFG is necessary.

Based on the preliminary analysis, for the EBP back-end cAST is
sufficient while the LTS-based formalism (eLTS and STS ) requires an existence
of cCFG. 

The whole process is illustrated on Figure \ref{fig:generic_analysis_tool}.

\begin{figure}
 \begin{center}
  \includegraphics{fig/general_analysis_tool.eps}
  % general_analysis_tool.eps: 0x19 pixel, 300dpi, 0.00x0.16 cm, bb=0 0 651 326
  \caption{The two step process of reverse engineering behavior specification}
  \label{fig:generic_analysis_tool}
 \end{center}
\end{figure}

There is a bigger set of transformations which can be performed among AST, cAST, cCFG.
Some of them, like coloring, are necessary part of the proposed
process. Other transformations, like ommiting actions on non-ValueType data, can be used 
by some back-ends or even the single one.
These transformations should be available to the authors of the back-ends in order to
prevent duplicit work.

\subsection{Reverse engineering back-ends}

Depending on the choice of the target behavior specification formalism (BP,
EBP, STS, eLTS, ...) a specific back-end of GAT is used to extract the
behavior specification. For example, the back-end for extraction of behavior
protocols abstracts from everything except externaly visible events and
control flow (replacing \verb|if| statements by alternative and cycles by
repetition).

\subsection{Organization}

This task is led by the DSRG group; the OBASCO and COLOSS groups also
participate. The first version of the set of annotations was created by all
groups during the Prague 2007 Workshop. However, the initial version is
expected to be further enhanced in order to allow automated (or at least
semi-automated) abstraction of ValueTypes.

More specifically, DSRG is responsible for creation of the general analysis
tool. For this tool, each participating group (DSRG, OBASCO, COLOSS) is going to
implement their own back-ends specific to the behavior specification formalisms
they use.

First results on the generic analysis tool are expected by the time of the
second workshop (Nantes 2008). Results on extraction back-ends are expected till
the third workshop (Cluj 2008).


\begin{thebibliography}{99}
 \bibitem{JavaCC}JavaCC, \url{https://javacc.dev.java.net/}
 \bibitem{JavaC}Java Development Kit, \url{http://java.sun.com/}
 \bibitem{ANTLR}ANTLR, \url{http://www.antlr.org/}
 \bibitem{JavaCUP}Java CUP, \url{http://www2.cs.tum.edu/projects/cup/}
 \bibitem{SableCC}SableCC, \url{http://sablecc.org/}
\end{thebibliography}

\end{document}
