Wednesday, March 24, 2010

Eclipse Con 2010 and Acceleo community feedbacks

Eclipse Con seems to be a great success this year, like every year ;-)

I have particularly liked the Jeff Norris keynote this morning. What a standing ovation! Thank you Jeff for the road trip on mars...

Thanks also to you Kenn for the nice Eclipse Modeling Runaway 2010. It was a pleasure to talk a little bit about Acceleo. For those of you who are interested, here is the fash demo I have shown during this session : Acceleo at Eclipse Modeling Runaway 2010.

Here are the slides of my 25 minutes session Acceleo Code Generation - Let's start with an Android example. I hope that you liked it... Let's me know if you have learned something. I had 3 goals when I made this quick tutorial :

  • Acceleo beginners could see a simple but concrete case-study
  • Acceleo addicts could discover some new "killing" features, for the Obeo guys also ;-)
  • Android experts could learn enough of the basics to be able to create advanced code generator in a few days

I'm not an Android expert but I like this technology and I have liked to make a quick example on how to use Android and Acceleo together. To be continued...

Monday, March 8, 2010

Just a little bit about "Simple OCL"

I just come back from Cambodia, and it has been a wonderful time to think about how to simplify modeling technologies ;-) ;-) I have focused on the language we use everytime to make automation tools with modeling technologies : OCL

The OCL OMG specification has been released several times in the last 5 years. We use OCL at Obeo to make automation tools with Acceleo and ATL, and we think that OCL queries should be as short as possible to improve the template readability... We have defined several common OCL queries that are always used in our tools. We would like to have these queries in the standard library because we must define them each time we have to make a new tool with Eclipse modeling technologies.

Here are some ways to simplify OCL I have discussed a couple of days ago with OCL experts. It isn't really easy to think about how to improve OCL because there were a lot of work on it and we can't change everything for compatibility reason. But, it is really possible to improve the language with little thing without breaking the compatibility.

The first way for me to improve OCL is to add in the library the common stuff we define every time in our code generation and model transformation projects. When we navigate on models, the main things we do is to navigate around the current node, up and down : to get the children, the children of the children, the parent, and the siblings... OCL should propose shortcuts to go in these directions... Do we need a new function in the library or a new syntax element like in XPath? I don't know, but both will be better than what we have today. We often need to filter the types of the objects we would like to keep during this navigation. We spend a lot of time to explain how to get some specific children of the current node. As an example, here is the expression we have to write in OCL to get the descendant list of an object where we only want to keep the named elements :
myCollection->select(oclIsKindOf(NamedElement))-> collect(oclAsType(NamedElement))

It would be strictly equivalent to eAllContents(NamedElement) if the query eAllContents(OclType) was defined. Of course, we can define this query in one common library for all the projects of my company. I'd prefer to have such a useful service in the OCL standard library to prevent naming ambiguities. Today, everybody gives its prefered name to this query and it isn't possible to understand easily the work of someone else.

For the same reason, we would like to simplify the syntax used to make filters on collections. myCollection->select(name <> ' ') could be replaced by myCollection[name <> 0]. The "select" function is used everywhere in OCL queries. This new shorter syntax could really improve readability. To be extreme, [...] should be the way to filter every kind of thing, for example if I want to filter the types of the objects in the current collection, I would write something like that :

myCollection[Class or Interface].name

In the second example, "name" could compile because there is a common attribute called "name" both in "Class" and "Interface". The goal is to replace the oclAsType() function as often as possible.

Another way to improve the readability of the OCL expressions is to add operators like '+' or '-' between collections :
(property + method)->size()
(list - element)->size()
list + element

Some researchers think that we can already do that with operator overloading, but to go further, we would probably need generics in OCL.

The opinions of the OMG guys would be interesting ;-)