MD Day 2010

Like every year, the french modeling community has met during the MD Day last week in Paris.

It was the fourth edition, with a format which makes the success of this event: each partner (11 this year) must come with one of its customers who presents a real-life project where model-driven engineering has been used. Once again, despite optimistic forecasts, we still ran out of place, and we have been forced to close the registrations three weeks before the event ! Finally there have been 275 attendees (234 last year).

This year, the conference started with Steve Cook's keynote "UML: Past, Present and Future". 

Stevecook uml mdday2010

I already knew the past: I've worked a while with Booch notation in the 90' (remember these little clouds...) ;-) 

What I found really interesting was the part about the UML dilemnas:

• What is the real value proposition of UML ? There is often a misandurstanding about why to create UML models.
• Should DSLs be based on UML ? UML should be more reusable.
• Is UML appropriate to describe non software domains ? It was not the initial intention of this metamodel.
• Can UML be a pivot to model semantics ? New versions of OO languages integrate concepts which are not supported by UML.

Regarding the future of UML, Steve presented the main initiatives:

• UML is too complex: it is going to be simplified, in order to facilitate its modularization and isolate the parts which are really used.
• MOF is going to disapear: UML will be defined by itself, in order to facilitate the manipulation of metamodels with any UML compliant tool.
• UML Diagrams are going to be formally defined: a Diagram Definition initiative has started

These problems are real, but as Eclipse Modeling Project already proposes solutions to solve this kind of problems, I hope that UML team is not going to reinvent the wheel.

After the keynote, the conference continued in two tracks, with partners and users talks.

At Mia-Software we had invited Olivier Corbel, the IS manager of BritAir, an airline company, who presented  its model-driven development process.

Britair mdday2010

BritAir uses MagicDraw to create very simple UML class diagrams which represent the domain model of each new application (entities and relations).

This UML model is used to fully generate RCP applications which allow to manipulate the data (CRUD). The generation rules are defined and executed with Mia-Studio.

When some business logic is required, it is defined with a textual DSL (business rules in french) and then automatically translated into Java.

This approach and the corresponding tools are now used each time BritAir has to develop a specific application. The code is 100% generated. For now, six applications have been developped (small maintenance of aircrafts, management of aircraft events, cost accounting, financial forecasts, management of passengers, preparation of flights). Olivier Corbel said that the development managers have evaluated to 10 the productivity ratio on these projects!

After this presentation, I had decided to talk (in french again) about Model-Driven Development and how to reconcile developers with Model-Driven engineering.

Mia-Software at MD Day 2010

In the first part of my presentation I constated that, in 2010, Model-Driven Engineering adoption continues to increase:

• A lot of successful projects have already proven the benefit of Model-Driven Development. In many domains (bank, insurance, defence, aeronautics, transportation, etc) and for various technologies (Java, C#, Flex, Smalltalk, Ada, C, Cobol, etc).
• Model-Driven Engineering is not only dedicated to the development of new applications. It is also used to maintain the existing ones and facilitate their modernization. The MoDisco project is an example of such initiative.
• The offer is very rich! Just have a look at the Eclipse Modeling Project: during the last nine months, there have been 14M lines of code committed on 45 active projects, by 113 committers of 20 different companies ! In addition, standards such as UML2 (even if the specification could be simplified) is now supported by a lot of mature tools.
• The MD Day reflects this adoption with a continuous augmentation (since 2007) of both partners and attendees.

Despite this fact, we must also admit that Model-Driven Engineering still faces strong resistance. 

It is easy to challenge the most current arguments:

• Complexity of UML? UML is complex (even OMG admitted it by launching the UML Specification Simplification RFP), but 20% of UML (class diagram) is sufficient for 80% of needs. Do you really think that a class diagram is more complex than all the web technologies (WSDL/SOAP, Hibernate, Spring, etc) that most developers are familiar with ? And if it's still too complex, you can use a DSL with only your vocabulary: Model-Driven Engineering is not only UML!
• Too much abstractness? MDD implies that the model should be more abstract than the code to develop (this is what makes the model more sustainable than only the source code). But the level of abstraction is free: it's up to you to define the good level of abstraction depending on the maturity of the team.
• Complicated Process? MDD implies two new activities (the production of the model and the generation). But these activities can be integrated to any kind of process (from agile to waterfall). And modeling usually corresponds to the design of the application. For those who still think that design is not compatible with agility, just read principle #9 of Agile Manifesto: "Continuous attention to technical excellence and good design enhances agility".

Nevertheless, one argument againts MDD is a real one: the difficulty to keep in sync the model and the code. If you loose the synchronization, you loose the benefit of MDD. But if you put all the energy of your team in maintaining this synchronization, you loose in agility.

Hopefully there are solutions to avoid this pitfall: 

• Model at runtime: the model is not transformed into code, it is directlty deployed and interpreted by a runtime engine. This approach is similar to declarative languages based on XML, for example to describe GUIs (XUL, XAML, etc). The drawback is that you need to implement a runtime engine.
• Model compilation: the model is transformed into a complete source code, where no additional coding is required (this is the solution adopted by BritAir). This approach is similar to the compilation of a 3GL language (Java, C++, C#, etc) into C or byte code. The drawback is that you need to create comprehensive models and develop complex generators where all the cases must be supported.

But in most cases, you can't describe all your system with a model. Then the generated code has to be completed manually. In this situation, to avoid the desynchronization between the model and the code, a solution consists in applying the Agile principles to modeling and code generation (we can call this approach Agile MDD).

Agile Modeling consists in:

• Useful modeling: only model what is really helpful for the understanding of the system, and what will be exploited by the generator. Avoid modeling any information which is redundant with the code (it would rapidely be out of sync).
• Simple modeling: if the system is complex, the model can be complex, but it should always be more simple than the code.
• Viewpoints modeling: decompose the model into submodels describing viewpoints on the system
• Incremental modeling: the model should be continuously challenged by other people on the project and/or by the generator.

Scott Ambler has defined several other core principles that you can read on http://www.agilemodeling.com/principles.htm

To produce code, these principles should be combined with other Agile principles related to generation. The objective of these Agile Generation is to reduce the gap between the model and the code:

• Targeted generation: you must be able to select only what you need to (re)generate, depending on what has changed (in the model, or in the generator). If each re-generation is global and takes too much time, you may want to delay the modification in the model and directly modify the code.
• Incremental generation: if the generated code has to be completed manually, these modifications must be protected by the next generations (now, all the generators have this functionality with protected areas).
• Traceability: the generator should keep the trace between the model and the code to allow to easily navigate from a file to the corresponding model element.
• Impact analysis: each time you click on the "generate" button, you must be informed of what exactly happened. Which are the new generated files ? Which parts of the existing files have been modified ?
• Assisted coding: after a generation, you should have a direct access to the parts of the code which have to be manually completed.
• Adaptability: the generated code reflects architectural and coding choices which can evolve during the project. Templates engine already allow to easily modify the generator. But to facilitate the modification of the right template, traceability mechanisms should give a direct access from the generated code to the corresponding template definition.

Of course, these Agile MDD principles are not exclusive: they should be combined, when it is possible, with Model at Runtime and Model Compilation approaches.

To illustrate Agile MDD, I ended my talk with a presentation of the Mia-Studio tool suite which supports these Agile Generation principles. 

Then Tony Rostren shown a short demonstration of the tool:

• Modeling of the cinematic of an application in UML with MagicDraw
• Generation of an executable application based on Struts
• Edition of the generated code in Eclipse
• Navigation from Java source code editor to corresponding element in MagicDraw
• Modification of the model and regeneration of the corresponding code
• Access to a template from a selected fragment of generated code

The full demonstration is available here:

http://www.mia-software.com/html/miaStudio/download/demo/mdday2010.htm

I spent the rest of the conference talking with customers and partners and demonstrating our tools. I could only attend one other presentation. It was the Sodius one, with Yann Lebeaupin talking with EADS about tools interoperability to support system engineering. 

You can find all the other presentations on slideshare: http://www.slideshare.net/MDDAY/presentations