"Welcome to the network, Jezz. Indeed your contribution would be of great interest both in terms of Software Factories as for Model Driven development in general. Having passed a couple of years since Microsoft focus on Software Factories, would be…"
"Thanks for your reply, Maria del Carme
Do you agree if we talk on english? It is preferable in order to help other people here...
Your interest is a personal project or a collaborative work? Is the University working on it? It is related to the…"
"Hola Jorge, si, soy de la universidad de tandil. Me he adherido la foro pero todavia no habia empezado a hacer uso de el. Con todo gusto podemos comenzar a conversar, siempre estoy en el tema de modelos de requisitos y sus transformaciones a modelo…"
Hola Jorge, si, soy de la universidad de tandil. Me he adherido la foro pero todavia no habia empezado a hacer uso de el. Con todo gusto podemos comenzar a conversar, siempre estoy en el tema de modelos de requisitos y sus transformaciones a modelo OO.
Thanks for your reply and your interest. I think it would be great idea to open a discussion thread -- but I am not quite sure what the topic should be. Do you have thoughts on this?
Perhaps I should explain the relevance of my comments to your question about the issue of: "How to assure that an object has a unique representation into the model".
I think that, if you have a single, common, semantic basis you can derive different views using different notations and know that they are compatible.
This is rather like the plan, side and front elevation of a building -- you know thet are compatible if the three views are projected from a single definition of the underlying building.
If, on the other hand, you have three draftsmen working separately on the plan, side and front elevations of a building, without a single defintion of the buildling, they will produce three diagrams that are (in general) incompatible and could not all represent any single building. It would be hard (and, I think, rather silly) to attempt to define "rules" that could be used to detect and correct the incompatibilities between the three views.
UML, in my view, tends to be used in a manner that corresponds to the second of these two approaches; and the problem you mention is akin to the problem of trying to reconcile the separately drawn pictures of a building. What I am suggesting is that we should try to move to the first approach.
Ella has provided some links to papers that she and I have written.
I think my views are:
1. The way that software behaviour is modelled is key to realizing the vision of model driven development (MDD).
2. UML developed as a collection of notations, and OMG have tried (not very successfully) to bolt semantics on afterwards. But the notations were not, in the first place, intended to be a basis for execution or code generation and are not really very suitable for this purpose.
3. The right way to proceed is to start with behavioural semantics and define notations afterwards, as ways of expressing the semantics. But it is the semantics that are important, and these should be defined in a way that is notation independent.
4. The best source of ideas on software behavioural semantics is the work that has been done on process algebras (such as CSP, CCS and pi-calculus). However these, while very strong on behavioural semantics, were not intended for and are not suitable as modelling techniques. If you try and model "real software" in process algebras you get enormous models.
Our work has been to try and define techniques for modelling using ideas on behavioural semantics taken from process algebras. We have been working on a technique called "Protocol Modelling" that does this. This technique does not give the enormous models that using pure process algebra requires.
There are several things that come from this:
1. You get the ablility to reason about the behaviour of models, with much greater ease and power than the UML notations provide.
2. You can use the parallel composition ideas of process algebras to enable complex behaviour to be defined as a composition of partial descriptions. (The semantics that have been bolted onto the UML notations do not allow the composition techniques of process algebra to be used on UML models.)
The models that PM creates are executable, so provide a suitable basis for MDD. However, the semantics are very different from UML.
You are right about code intervention and model abstractions.
I think that the only way to solve the problems is to make models truly executable, so that they can have one to one translation to a code of abstract level and make the models truly compostable, so that any middleware extension can be composed with the model of the abstract level without changing it. We work on this topic with Ashley McNeile and we have presented our ideas about this in a paper that I would like to send you. If you do not mind then I invite Ashley to the discussion. We would be happy to discuss it with you and with the community.
You can find the paper using this link
Thank you for you reaction on the topic of the workshop. I also think that behavioural models with suitable semantics will get an impulse to MDA.
I would like to kindly invite to the workshop, if you have time. Please, send your ideas or experience in a position paper, or just come without any paper.
Before we start a discussion, I would like to know about your interests.
What kind of problems have you experienced with behavioural modelling?
What are your favorite behavioral semantics or notation?
My best regards