Tag Archives: Model Driven Architecture

SiTra and Eclipse 3.3 or Java 1.6

Posted on by | Leave a reply

I recently installed eclipse 3.3 and Java 1.6. Today I tried to use SiTra (Simple Transformations in Java) but when I tried to compile it Java started complaining on the following methods of the SimpleTransformerImpl.java:

public Object transform(Object object) {
return transform(Rule.class, object);
}
public List<? extends Object> transformAll(List<? extends Object> sourceObjects) {
return transformAll(Rule.class, sourceObjects);
}

The error was something about java inconvertible types. I don’t know if it is the new version of eclipse or Java 1.6. Looks like for some reason the compiler doesn’t recognise that Rule.class is of type Class<? extends Rule<S, T>>, so as to call the public <S, T> T transform(Class<? extends Rule<S, T>> ruleType, S source)

A simple solution is to ct the Rule.class expression to Class (it sounds weird but it worked).

So the transform and transformAll methods become:

public Object transform(Object object) {
Class r = Rule.class;
return transform(r, object);
}
public List<? extends Object> transformAll(List<? extends Object> sourceObjects){
Class r = Rule.class;
return transformAll(r, sourceObjects);
}

Making UML2Alloy compatible with Alloy v4.0

Posted on by | Leave a reply

Alloy Analyzer v4.0 has been out for quite a while. Alloy v4.0 is an extension of the Alloy v 3.0 language (http://alloy.mit.edu/alloy4/quickguide/a4.html). More specifically parts of the concrete syntax of the language has changed (i.e. when invoking a predicate from within another predicate we now have to use brackets “pred1 [param1,param2,..]” instead of parentheses “pred 1(param1, param2,..)“. Also some of the properties of the language have changed (in MDA terms constraints on the metamodel, or well-formedness rules have changed). For example in Alloy 4 you are able to overload predicates, functions and fields. These are relatively small changes and it should be easy to accommodate them in UML2Alloy.

However, Alloy v4.0 has been developed from scratch and it is based on the kodkod model finder. The AST implementation has changed substantially and the convenience methods provided on the AST model elements are fine tuned for the Alloy compiler. For example Signature constructors are private and I couldn’t find a way to update the properties of Signatures (i.e. the Multiplicity of the Signature) after a Signature has been created.

Of course this is perfect if you have an Alloy model and you just want to parse, but not very convenient if you use an MDA approach to instantiate Alloy AST objects. For example in UML2Alloy you can change the Multiplicity of a Signature (i.e. change from set to some to enforce that some Signature instances will exist in the model). If you don’t have access to the Multiplicity attribute of the Signature class, after the object has been created, complicates the situation.

Moreover the AST class elements have been defined as final so there is no way you can override the Alloy v4.0 AST classes.

So, I spent almost 1 day evaluating the situation and trying to find a solution. One solution would be to create my own implementation of Alloy’s AST. Another would be to create wrapper classes of Alloy’s AST that will have pointers to the actual Alloy implementation.

Then I stepped back and thought about the siltation. Well, I already have a rather stable implementation that uses Alloy v3.0 AST. In Alloy v4.0 the AST has NOT changed. Just the concrete syntax. So the solution is easy.

Currently in UML2Alloy after the Alloy AST objects have been generated by SiTra, a visitor is used to create a text file that contains the Alloy model. So, all I have to do is use another visitor and override the methods that create the part of the model for which the concrete syntax has changed.