Jorge Ubeda's Page

We only have some "elective subjects" that cover some aspects of MDD, but in generall few students take them.

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.

Jorge:

thank you for your note. Looking forward to contribute.

JJ-

Hi Jorge

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.

Regards
Ashley

Hi Jorge

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.

I hope you find the papers of interest.

Rgds
Ashley

http://www.open.ou.nl/elr/Simulation.pdf

Dear Jorge,
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
http://www.open.ou.nl/elr/aom4s-roubtsova.pdf
My Regards
Ella