Hi Ed,
thanks for the clarifications and the links. Though I have
read/watched many of your writings/videos, I find now the two points
regarding mapping ecore classes to java interfaces and dealing with
multiple inheritance very helpful.
I did not mean my previous email to be provoking. I am very excited
from the idea of code generation and the EMF project. I was trying to
convey my point of view hoping that it could be of some help to the
project :-).
Thanks again and best wishes,
Firas.
Ed Merks wrote:
Firas,
I should mind my own business, but what the heck. Comments below.
Firas Swidan, PhD wrote:
Hi,
I am trying to use a simple UML -> Ecore -> java code transformation
to generate java code from a UML class diagram (on a side note, I
had to read material and view movies for 2-3 days to figure out how
to do the above basic operation.
You might have dispensed with UML and started directly with Ecore.
The Ecore Tools editor is awesome:
http://ed-merks.blogspot.com/2008/06/was-gany-good-to-you.html
Though I am totally new to MDA, it would have been nice to have a
faster kick start).
A tutorial analogous to this one would be handy:
Tutorial: Generating an EMF Model using XML Schema
<http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclipse.emf.doc/tutorials/xlibmod/xlibmod.html>
Mind you, all the same ideas apply, other than that it starts with a
*.xsd instead of a UML model.
I specify the visibility of an attribute in a UML2 class to private
(using UML2 tools graphical interface). However, the generated java
code declares the generated attribute as protected.
You should thing of the attributes as being equivalent to the
generated accessors in the API. I.e., if class Ahas attribute x, the
generated interface for A will have getX and and setX methods. In
the implementation (which you can hide in your plugin so that no one
outside your plugin can even see those classes) declares fields to
correspond to these. The default code generation patterns need to
access these fields in derived classes and hence make them protected.
Am I doing something wrong?
Nope.
I noticed that the intermediate ecore model lacks the equivalent of
visibility.
Yes. Ecore is focused on defining the public API of the model, i.e.,
primarily Java interfaces. Either something is in the interface or
it is not. Interfaces don't support protected and private. The
implementation classes are not intended to be accessed by clients at
all. You can even hide them so it's impossible for clients to access
them.
Is this the source of the problem?
Yes and no.
If so, is there a way to bypass the ecore model and generate the
java code directly from the UML
You can certainly write templates directly against UML but I think
it's a bit hard to map all of UML onto Java is a generally meaningful
way...
(my understanding is that ecore is a higher level of MOF abstraction
than UML.
Not sure which way your abstraction layers grow Ecore is effectively
equivalent to EMOF...
If so, it is weird that one needs to go up the MOF hierarchy before
going down again to the code level).
Probably you have some misconceptions. Keep in mind that while a
UML class diagram might use multiple inheritance, so if a UML class
just maps directly to a Java class and Java classes don't support
multiple inheritance then this simple mapping isn't fully general.
So from an Ecore point of view, a model (class) is defining an API
and APIs don't support this kind of protected and private visibility
(and via reflection, all data is visible, if if there isn't a method
in the API to access it).
Thanks for any tips and corrections.
Firas.