% Project: ECONET 
% Document: Prague07 Workshop Report
% Last writer: Andre Pascal 
% creation: 14/09/07 
% modification PA 17/09/07 
% *********************************** 
%\chapter{Project Architecture}
%\section{Structural Abstraction Subproject}
%\label{structural}
\textit{Writer: Pascal André, Gilles Ardourel}\\

This is currently a draft version.

\subsection{Objectives and Goals}

The objective of the process B (Fig. \ref{archiEcoTask}) is to build a structural component model and a corresponding annotated java code.
These two elements are inputs of the process A (see the detailed process in section \ref{behavioural}).
The model is also an instance of the metamodel (see the detailed description in section \ref{metamodel}) that will control its consistency.

A general view of the process B is given in figure \ref{processB};
from plain Java code and user interaction, process B should produce an annotated Java code and a corresponding component model (both results must be consistent).
Some restrictions apply to the first program release:
\begin{itemize}
    \item Input
\begin{itemize}
    \item Annotations are those related to the common Component Meta  Model (CCMM) but do not include other component models yet (Fractal, Sofa, ...).
The latter will be called \textbf{extended annotation}.
    \item UML models are not accepted as direct inputs but are read by the user.
\end{itemize}
    \item Output 
\begin{itemize}
    \item Only flat component model are targetted.
    \item Process B is not directly responsible of the consistency between a model and the corresponding Java annotated code. 
    \item The conformance of the produced component model is checked at the metamodel level.
\end{itemize}
\end{itemize}

\begin{figure}[ht]
\centerline{\epsfig{figure=\repFIGURES/processB.eps,width=14cm}}
\caption{A general view of the process B}
\label{processB}
\end{figure}

The process B is in fact iterative because its source is variable (in the sense that it may include many informations from different nature) and target different goals.
For instance one goal  is to abstract structural elements of a component model from a plain Java code and user informations.
Another is to read and interpret existing annotations.
Another is to check the compatibility between one component model and an annoted Java code...
%The result is an instance of the structure metamodel and an annoted Java code.
On each iteration, the process accepts a java program (with or without annotation) and a component model (possibly empty).
It computes some information, sometimes using external tools and human interaction.
This information modifies the a java program and the component model.

\begin{figure}[ht]
\centerline{\epsfig{figure=\repFIGURES/processBiter.eps,width=11cm}}
\caption{An iterative view of the process B}
\label{processBiter}
\end{figure}

The idea is to combine primitive transformations and develop a customised (or human driven) process B.
Here are some a these primitive transformations:
\begin{enumerate}
    \item Annotate a Java program from user information.
    \item Build a component model from an annotated Java source.
    \item Build a component model from a plain Java source.
    \item Analyse a distributed program to detect components (deployment).
    \item Extract cluster using graph tools (grouping class into components, or grouping components into composite).
    \item Process model transformations such as fusion, selection... on the couple (code, model).
    \item ...
\end{enumerate}

Important remarks:
\begin{enumerate}
    \item Note that combining transformation 1 and 2 provides a first result of process B which can be reusable in process A.
    \item  Note also that input and outputs need format filters (reader, writer) which are common to all subprojects.
    \item Note also that some of these transformations ought to be used is the other subprojects.
\end{enumerate}

Consequently, process B is rather a tool box or a sequence of subprocess applications.

\begin{figure}[ht]
\centerline{\epsfig{figure=\repFIGURES/processBbox.eps,width=15cm}}
\caption{A architectural view of the process B}
\label{processBbox}
\end{figure}

\subsection{B transformations and tools}
%\subsection{Module organisation}

\begin{enumerate}
    \item Annotate a Java program from user information.\\
This program needs input/output functions for annotating Java sources.\\
Some tools are 
\begin{itemize}
    \item Java parsers, analysers... see section \ref{java:tools} on page \pageref{java:tools}.
    \item JDK 5.0 Java Annotation Processing Tool \texttt{APT}\footnote{\url{java.sun.com/j2se/1.5.0/docs/guide/apt/}}.
    \item A program that lead the interactions.
    \item 
\end{itemize}
    \item Build a component model from an annotated Java source.\\
Having an annotated Java program, one can build the corresponding model providing we have the good filters and formats (see the adapted transformations).
    \item Build a component model from a plain Java source.\\
This can be obtained by combining other transformations.
Since the input model is empty, the human must provide many informations and can be helped by the cluster tool. 
    \item Analyse a distributed program to detect components (deployment).\\
One way to find components is to analyse the distribution framework.
Components in this case are linked to deployment nodes.
We can use RMI analysis for example (or corba ?).
    \item Extract clusters  (grouping class into components, or grouping components into composite).\\
We need graph tools to analyse component architectures.
    \item Process model transformations such as fusion, selection... on the couple (code, model).\\
In collaboration with the team working on the metamodel we have to develop transformations on models and their pending java annotation transformations. 
    \item Consistency checker.\\
In collaboration with the team working on the metamodel we have to develop tools that check teh consistency between models and their corresponding annotated java programs. 
    \item Filters.\\
In collaboration with the other teams we have to define the formats and to develop utilitary programs to read and write on the adopted format (XMI, MOF-XMI, Ecore, Java Model API, ...).
    \item Scheduler.\\
This program will chain the transformation in order to build interactive B processes.
\end{enumerate}



%\subsection{Means}

\subsection{Interface}
\label{processB:interfaces}

The annotation language and component metal model have been discussed but the full definition of interface need an interoperable format.

\begin{enumerate}
    \item Metamodel format (XMI, ECore, MOF, model API...)
    \item Model format (XMI, ECore, MOF, model API...)
    \item ...
\end{enumerate}

\textcolor{BrickRed}{This work has to be done.}

\subsection{Organisation}
%\subsection{Tasks and Schedule}
%\subsection{Participants}

This task is led by the COLOSS group; the OBASCO group also
contribute significantly to the toolbox; the LCI team will bring its experience on reverse-engineering tools.

The program is designed as a set of tools which can be developped independently provide the interface are well defined (see section \ref{processB:interfaces}).
The list of tools is open and will be extended each time we need another tool.

We have to distribute the transformations on the participants and
to define which transformations are to include in each delivery.
\textcolor{BrickRed}{This work has to be done.}

First results on the structural 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).

\endinput

