Sometimes, a user may need to transform only selected model elements instead of the entire model. There are (at least) three approaches to achieving this:
To simulate derived properties, EOL supports cached operations. A cached operation - parameter-less operation annotated with a @cached annotation - is only executed once: subsequent calls return the same result without executing its body again. An example that calculates the Fibonacci number of a given Integer follows:
15.fib();
@cached
operation Integer fib() : Integer {
if (self = 1 or self = 0) {
return 1;
}
else {
return (self-1).fib() + (self-2).fib();
}
}
As it is the case with all languages, model management languages have a particular scope of applicability. So, while a model-transformation language is expected to be efficient at navigating and modifying models, it is not really expected to be able e.g. to perform complex string comparison efficiently or to access an external system (e.g. a DBMS).
The concrete syntax of EOL (and thus all the languages that build atop it) has been influenced by OCL and Java. From Java it inherits things like if branches, while loops and return statements. On the other hand many things are influenced by OCL: the comparison operator is = (== in Java), the assignment operator is := (= in Java), type conformance is checked using x.isKindOf(Type) (x instanceof Type in Java) etc.
The initial rationale about this was that we wanted the languages to be more accessible to OCL-users than to Java-users. Nevertheless, we have found that Java-developers make the biggest part of our audience and to them this syntax seems a bit exotic. We are seriously thinking about providing an alternative, more Java-friendly concrete syntax in the future…
ECL is a task-specific language for comparing models of potentially different metamodels. The EMFT Compare component on the other hand supports pluggable comparison algorithms. A bridge between ECL and the Compare component that would allow specifying comparison algorithms in ECL (instead of Java) would be a very interesting experiment…
Compared to languages such as ATL, VIATRA, Kermeta, TEFKAT and frameworks such as openArchitectureWare and AndroMDA, Epsilon is a relatively young approach to MDD. This often raises the following (quite reasonable) questions:
The work that resulted to what today is Epsilon started sometime in October 2005. This entry provides a summary of the most important milestones…
The aim of this blog is to provide an informal discussion about the Epsilon Eclipse GMT component.
Epsilon @ GMT
