Ella Roubtsova's Page

Downloaded...At first sigth it sounds very well...

Thanks so much, Ella. I haven´t seen you message until now, late night. Just for read this weekend.
Thanks again
Jorge

Ella, repeating what I said to Mr Mc Neile:
Finally, opted for open a discussion repeating my arguments to you and Ashley. I have thought initially to add your comments, but later I judge that I have no right to do it, given that you and Ashley are the owners of your concepts. Why reduce or alter them, when you are here?
Hope you agree with the description of the subject, at less for initiate this.
Kindly
Jorge Ubeda

Ella,
I´m not using MDA, but another way to create applications from models. However, I have followed with entusiasm OMG and other efforts to develop a standard for modeling to generate applications. I agree strongly with the idea of model design at abstract level, separating for platform design. I have seen, passing years of different approaches, how UML have become a constraint for OMG standards. Here, repeatedly, the discussion falls on a critical separation: model transformations arriving to a static representation of the application, which requires code intervention. I have discussed this issue before, regarding colleagues working with Rose or AndroMda: the automation gets a limit, which requires code. Descriptions of EMF shows a similar process: at end of modeling, you need to add java code.
It seems to me an issue, an obstacle that must be faced. Mr Varnica mentions today two issues which relate to model integrity: how to assure that an object have a unique representation into the model (Vlad says "I mean that changing one element in one diagram would immediately update my other 1,000 diagrams which include this element"); and how to get traceability of the use of an object into the model ("know in which diagram my element is used"). Add this "frustration" to the fact that the behavior of the model is declared in java code. What propagation of changes could be made this way? What traceability? How if manual code introduces errors in mapping from model object to code?
I belive this is a critical issue for Model abstraction, and must be solved. Behavior of the model must be represented in its proper terms, and it must be generated from abstract definition, which maps strictly to model definition. It is the only way to support maintainbility, and not to fall in an early definition, which finally differs from the "live" application, which resides into the code.
In sum, it is my interest in your point of view, be it mature or immature. I belive that "behavioral modeling" sounds great.
Regarding participation on the workshop, I like it, but I´m more able to hear than to talk...I will be very interested in know its results, indeed.
Regarding what to do here, I like to invite you to talk here, opening some discussion. Surely, most of us would ask and participate.
With kind regards
Jorge