The Second Workshop on Behavioural Modelling - Foundations and Application ( BM-FA 2010)
http://www.ou.nl/eCache/DEF/2/17/059.html
15 June 2010, University of Pierre & Marie Curie, Paris, France
Proceedings will be published as a volume of the ACM D…
I am interested in success of Model Driven Software Development which is impossible without behavioral modelling, without taxonomy of behavioral models and without proper support of behavioral modelling both at the Platform Independent and Platform Specific levels of modelling.
My experience of Model Driven Software Development:
I teach courses on Model Driven Software development during 6 years and the interest of my students and their questions stimulate my interest. I have applied the ideas of MDSD in two research projects and I would be happy to take part in an industrial or a research project that involves any application of Model Driven Software Development.
Dear Jorge,
I was just busy with this workshop. Even in papers of this workshop you can see that there are different understanding what behaviour is and what is the behaviour composition.
First paper treat behaviour as function and the behaviour composition is as composition of functions.
The third paper and some other paper see behaviour as a set of traces.
The third notion of behaviour is something that is specified by a contract.
I am going o discuss the difference with the authors of the first paper, because they have problems with behaviour adaptation an the adaptation is their current project.
Dear Jorge,
You may be interested in preliminary proceedings of the BM MDA workshop
http://www.open.ou.nl/elr/173740-L-bw-CTIT%28no%20keynote%29.pdf
My best regards
Ella
Hi Jorge,
It would be difficult to discuss behavioural models in general.
Do you have in mind a particular class (domain) of beavioural models where you see some modelling problems?
You write that you do not use MDA but use another approach for executable modelling.
What kind of approach is it? Can we look at it or read about it or see the examples of its application? May be you can describe it in this discussion.
My regards
Ella
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
Dear Ella,
As pointed to Mark, behavioral modeling is a very interesting matter to me. Maybe you would open a brief discussion on it. It seems to me that "behavioral" sound like a solution to the opened discussion on "mdd death".
With kind regards
Jorge Ubeda
Comment Wall (8 comments)
You need to be a member of The Model Driven Software Network to add comments!
Join The Model Driven Software Network
I was just busy with this workshop. Even in papers of this workshop you can see that there are different understanding what behaviour is and what is the behaviour composition.
First paper treat behaviour as function and the behaviour composition is as composition of functions.
The third paper and some other paper see behaviour as a set of traces.
The third notion of behaviour is something that is specified by a contract.
I am going o discuss the difference with the authors of the first paper, because they have problems with behaviour adaptation an the adaptation is their current project.
Let me know your opinion.
My regards
Ella
Thanks again
Jorge
You may be interested in preliminary proceedings of the BM MDA workshop
http://www.open.ou.nl/elr/173740-L-bw-CTIT%28no%20keynote%29.pdf
My best regards
Ella
It would be difficult to discuss behavioural models in general.
Do you have in mind a particular class (domain) of beavioural models where you see some modelling problems?
You write that you do not use MDA but use another approach for executable modelling.
What kind of approach is it? Can we look at it or read about it or see the examples of its application? May be you can describe it in this discussion.
My regards
Ella
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
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
As pointed to Mark, behavioral modeling is a very interesting matter to me. Maybe you would open a brief discussion on it. It seems to me that "behavioral" sound like a solution to the opened discussion on "mdd death".
With kind regards
Jorge Ubeda