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.