The objective of the process B 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 Process A). The model is also an instance of the metamodel (see the detailed description in meta_model) that will control its consistency.

A general view of the process B is given in the figure below; 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:

• Input
  • 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 extended annotation.
  • UML models are not accepted as direct inputs but are read by the user.
• Output
  • Only flat component models are targetted.
  • Process B is not directly responsible of the consistency between a model and the corresponding Java annotated code.
  • The conformance of the produced component model is checked at the metamodel level.

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… 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.

The idea is to combine primitive transformations and develop a customised (or human driven) process B. Here are some of these primitive transformations:

• Annotate a Java program from user information.
• Build a component model from an annotated Java source.
• Build a component model from a plain Java source.
• Analyse a distributed program to detect components (deployment).
• Extract cluster using graph tools (grouping class into components, or grouping components into composite).
• Process model transformations such as fusion, selection… on the couple (code, model).
• …

Important remarks:

1. Note that combining transformation 1 and 2 provides a first result of process B which can be reusable in process A.
2. Note also that input and outputs need format filters (reader, writer) which are common to all subprojects.
3. Note also that some of these transformations ought to be used in the other subprojects.

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

• Annotate a Java program from user information. This program needs input/output functions for annotating Java sources. Some tools are

  • Java parsers, analysers…
  • JDK 5.0 Java Annotation Processing Tool.
  • A program that lead the interactions.
  • XML reader/writer.

  1. 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).
  2. 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.

  1. 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 ?).
  2. Extract clusters (grouping class into components, or grouping components into composite). We need graph tools to analyse component architectures.
  3. 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.
  4. Consistency checker. In collaboration with the team working on the metamodel we have to develop tools that check the consistency between models and their corresponding annotated Java programs.
  5. 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, …).
  6. Scheduler. This program will chain the transformation in order to build interactive B processes.

  \end{enumerate}

A first implementation using CMM (meta_model CCMM section - item 2).

The code and documentation are available on the Econet SVN repository (ProcessB directory).