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].name 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 + elementSome 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 ;-)
