JEE, Flex and MDSD in Tunis

Last week I was in Tunis.

The weather was not as sunny as expected, but it was not the reason of my travel. I was there to setup a MDSD (Model-Driven Software Development) process for a tunisian bank.

This bank has planned to redevelop its Core Banking System with new technologies (JEE and Flex). In order to facilitate the development and provide both flexibility and quality to the future system, they have decided to adopt a Model-Driven approach.

My mission consists in helping the IT team to put this approach in place.

Developing a generator for a customer is an activity which I usually decompose in four steps:

Development of a reference application

In every industrialization process, the first step consists in identifying the scope of what can be beindustrialized. In a MDSD process, the better way to define this scope is to manually develop a reference application: a subset of the future application which contains examples of each coding patterns.

During a first stay, few weeks ago, we had specified and started to develop a reference application based on a cash withdrawal scenario. Behind this scenario, we had defined several services to invoke, the corresponding business objects (BO) and data transfer objects (DTO), and the existing Oracle tables and stored procedures which have to be reused. Based on the languages and frameworks selected by the customer (Flex with the CairnGorm framework, JEE with the Spring and Hibernate frameworks), we had designed the reference application and defined the coding patterns to use.

This week, when I began my second stay, the customer had finished the development of the reference application, and it was running.

Identification of the Generation Scope

Once a reference application exists, the second step consists in analysing its source code to identify the variability factor of each line of code:

• What is the minimal information required to be able to produce this line of code?
• Is this information specific to the reference application or generic ?
• Can we produce other lines of code with the same information?
• What is the ratio between the effort to declare this information and the effort to manually produce all the corresponding code?

The answers to these questions, coupled with a discussion with the customer, help defining the generation scope:

• which code can be produced automatically?
• which code needs to be developped manually?

Definition of Modeling Rules

Once the generation scope is identified, then we need to define how the information required to generate the code can be defined within a model. There are three possibilities:

1. Defining a Profile in a UML Modeler
2. Developing a Domain-Specific Modeler
3. Developing a Domain-Specific Concrete Syntax

For my customer in Tunis, I have proposed the first option and defined a UML profile containing a first set of about 20 stereotypes (application, service, bo, vo, dao, table, ...). With this profile I used MagicDraw (which provides very powerful extensibility and customization mechanisms) integrated in Eclipse to create a model of the reference application.

Development of Generation Templates

The fourth step is the easiest: templates can be developped from the reference application by copy/pasting fragments of code. The fragments parts which are generic remain in the templates, while variable parts are replaced by calls to the model (using EMF APIs).

Last week, it tooks me one day to develop the Mia-Studio templates for the presentation layer. From the EMF model of the reference application, the templates have regenerated 6 MXML files and 19 ActionScript files (Commands, Events, Service Delegates, Front Controller, and Value Objects). The MXML files contain the graphical definition of the GUI: they will be generated only once, just to provide a first application which can be executed. Then they will be edited and maintained with a WYSIWYG designer.

The templates for the two other layers (Business and Data) will be developed with a colleague during a third stay in Tunis.

Then our role in the project will be to assist the team in modeling and developing the first application and adapt the MDSD process to integrate the unforseen cases.

Eclipse & OMG Symposium

After Ottawa in 2008, the 2nd biannual symposium on Eclipse & OMG will held in June at Minneapolis. This symposium will be introduced by Kenn Hussey, the leader of the Eclipse MDT project which provides implementations and tools for standard metamodels. It is the opportunity to discuss about how OMG standards can be implemented on Eclipse, and how Eclipse can influence the definition of new standards.

With Hugo Bruneliere and Jordi Cabot of INRIA/AtlanMod team, I will present the Eclipse implementation of SMM (Structured Metrics Metamodel), one of the OMG standards supported by the MoDisco project. We will explain how this metamodel can be used to represent metrics computed from Java source code. And how it can help while developing Eclipse components, by measuring their compliance to Eclipse development best practices.

You can read three of my posts on this topic :

• Emf and SMM to export Code Metrics to Sonar and Squale
• How to create an EMF model from a Java application
• Reverse-Engineering of JUnit Tests

Talks on other standards will be given by people from University of Madrid, NASA (JPL), IBM, CEA, Model Driven Solutions, Ericsson, Intalio, RedHat, Obeo and Thales.

Back from EclipseCon 2010

I came back to home today, after one week at Santa-Clara, near San-Francisco, attending my second EclipseCon.

Last year, I only presented a poster. But this year I gave a talk about MoDisco and I participated to the Modeling Project runway organized by Kenn Hussey. Gabriel Barbier, my colleague from Mia-Software, had also a talk with Henrik Lindberg about B3 and the possibility to use MoDisco to extract build information from source code .



Once again, I really enjoyed the conference and its organization: lots of interesting talks, very good keynotes (Steve Harris show was THE event of the week), but most of all it is the best way to share ideas, to meet people and to show what we working on.

This year, we spent a lot of time explaining a project we propose to create. The EMF Facet project will provide mechanisms to dynamically extend ECore models: adding properties, references, operations without changing the initial ECore model. These mechanisms have already been developped as part of the MoDisco project. We propose to externalize them to make them more reusable by other projects. We received very good feedback on this project from all the Modeling Project members to whom we presented our ideas and the existing components. We will first submit the proposal to the Modeling PMC next week.

Reverse-engineering of JUnit tests

Tuesday I presented MoDisco during two EclipseCon sessions at Santa-Clara:

• the Eclipse Modeling Project Runway, a five minutes commented screencast with nine other modeling project committers
• the talk How to Deal With Your IT Legacy with Hugo Brunelière of INRIA-AtlanMod.

We decided this year to illustrate MoDisco with a example based on JUnit :

• reverse-engineering of source code containing JUnit tests (we took draw2d as a sample)
• creation of a fine-grained EMF model describing the source code
• definition of an extension (Facet) to find the JUnit Test suites, Test cases and Tests contained within the code

• colorization (UICustom) of the packages, classes and methods to be tested, depending on how many tests are defined for them

• transformation of the EMF model and regeneration of the source code to migrate from JUnit3 to JUnit4

The slides are available here.

I will blog soon to give more details about this JUnit use-case.

MoDisco 0.8M5 available for download

Version 0.8M5 of MoDisco, has been released yesterday : http://www.eclipse.org/gmt/modisco/downloads/

It already embeds the components which will be available in the final 0.8 version running with Helios.

Today I would like to focus on two new components (Query Manager and Facet Manager) and how they are used by the new version of the Model Browser to allow defining custom (and dynamic) viewpoints on your EMF models.

These mechanisms have been developped to support understanding of complex models automatically created from legacy source code. But you can also use it on "classic" EMF models created manually with graphical tool such as Papyrus.

Query Manager (new)

This is a new component providing a facade to evaluate queries against an EMF model independently from the query mechanism. Implementations are provided to call queries written in Java, EMFQuery, OCL and XPath.

A QuerySet containing OCL and Java queries

See : http://wiki.eclipse.org/MoDisco/Components/QueryManager

Facet Manager (new)

This new component provides a mechanism to dynamically extend EMF model elements by adding "virtual" attributes and relations computed by queries.

See : http://wiki.eclipse.org/MoDisco/Components/FacetManager

ModelBrowser

The look & feel has been reviewed to be more compliant with Eclipse UI checklist.

With the new version it is possible to dynamically customize how the EMF model elements are displayed. Any customizable feature (label, color, icon, police, ...) can be set statically, or dynamically using a Query executed on each element to display.

Wizard to customize the Browser for a given metamodel

You can also execute a Query against a model element directly from the browser

Selection of a model element from the Browser

Selection of Query to execute on the selected element

Result of the Query displayed in a table

If you want the Query to be always executed on each element of the same type, you can define a Facet to see the Query as a virtual type, attribute or relation in the browser.

The Query "subClassifiers" visible as a "virtual" relation on Class

See : http://wiki.eclipse.org/MoDisco/Components/ModelBrowser

How to create an EMF model from a Java application ?

Is it possible to reuse EMF-based tools with Java source code ? Yes if you have your Java source code translated into an EMF model.

This is the aim of the Java component provided by MoDisco. This component is composed of a ECore definition of a java application and a discoverer which creates EMF models from an EClipse project containing Java source code.

The ECore definition declares all the concepts of the Java language : Package, ClassDeclaration, MethodDeclaration, Parameters, VariableDeclaration, IfStatement, Assignment, CastExpression, LineComment, ...

To create an EMF model using this metamodel, select your project and right-click on the menu "MoDisco>Discover Java model from Java project...". A wizard appears to select the analysis options :

• You can extend the analysis to dependencies (the JAR used by the project).
• You can use an incremental mode if you need to optimize the memory usage
• You can limit the analysis to declaration members if you don't need a model of the instructions contained within the methods
• You can use a filter to exclude Java classes during the analysis

The result is an EMF model which can be opened with the EMF reflexive editor or with the MoDisco generic browser. This browser allows accessing directly to instances of a specific class (for example all the MethodDeclarations) and navigating through all the references (composed or not).

This model can be used with other EMF-based tools to check architectural or coding norms, to generate other models (UML or Domain-Specific) or to regenerate an other application (if you modify the Java model, MoDisco provides templates to regenerate Java source code).

EMF and SMM to export code metrics to Sonar and Squale

How to facilitate the integration between code quality measurement tools and code quality reporting tools ?


This is the problem we are faced with at Mia-Software: to address modernization projects, we have developped a lot of parsers creating models of code from which we can compute quality metrics (from COBOL, Natural or VB6 to Smalltalk, C# or Java). But as our customers are interested in getting these metrics in the quality report tool of their choice, we don't want to multiply the development of adhoc bridges (one for each couple "metrics calculator" <-> "report tool")

To reduce the cost of bridging the tools, we chose SMM (Structured Metrics Metamodel) as a pivot. SMM is the OMG/ADM standard for defining metrics related to software and for representing their measurement on existing systems. Its reference EMF implementation can be found in MoDisco, the Eclipse Modeling project focused on discovering models from software assets.

The main classes defined by SMM are quite simple :
- Measure : the definition of an indicator (nb lines of code, cyclomatic complexity, …)
- Scope : the kind of elements on which the indicator can be measured
- Measurand : an element on which an indicator has been measured
- Measurement : the measured value of an indicator
- Observation : who ? how ? when ?
Then, for each measurement tool that we need to integrate with a report tool, we just have to create a SMM model describing the kind of metrics to exchange (instances of Measure and Scope) and a connector to translate the specific export format of the measurement tool to a SMM model containing the measured values (instances of Measurement, Measurand and Scope).

In parallel, we create one generator for each report tool to integrate with. This generator takes the SMM model defining the measures and generates :

• the files declaring the metrics within the report tool
• the files configuring the report tool to integrate the new kind of metrics
• the source code of the component which will import SMM models containing the measurements
At this time we have experimented this approach to import COBOL and VB6 metrics (calculated by Mia-Insight) into the quality report tools Sonar and Squale.

Screenshots : COBOL -> Sonar







Screenshots : COBOL -> Squale







Our conclusion is that SMM fits the need of integration between these kind of tools.

The next step will be the integration of XRadar (suggestions of other report tools are welcome ;-) ).

We also have to solve the problem of metrics aggregation. There are three possibilities :
- aggregation at measurement time
- aggregation in SMM model
- aggregation in report tool
We have already identified pros and cons for each alternative. Depending on the kind of aggregation to perform, experimentation will probabely give an answer !