Hi Lee

The "if they work at all" comment referred to the fact that some
so-called MDA tools can only generate skeletons and/or only generate
CRUD behaviour (so cannot handle more complex transactional updates).

The "restricted to specific application areas" refers to the fact that
some MDA techniques, because of the forms of behavioural modelling
semantics they use, have less than universal applicability.

I think the latter is true of Executable UML, which seems to have no
profile outside of the embedded systems area (apart from text book
examples). Please correct me if I am wrong about this.

There was no intent to insult anyone, except perhaps those who believe
that the MDA vision has actually been realised, in a consistent way,
across the spectrum domains that it professes to address.

Perhaps you would like to submit a paper? You would be welcome!

I hope you decided to laugh rather than cry.

Rgds
Ashley



Lee Riemenschneider wrote:
>
> I wasn't sure whether I should laugh or cry when reading the text of
> this posting. This really makes one realize why Pascal and Date felt
> compelled to create the Database Debunkings web site.
>
> > Call for Papers
> >
> > *The First Workshop on Behavioural Modelling in Model-Driven
> > Architecture (BM-MDA) http://www.ou.nl/bm-mda <http://www.ou.nl/bm-mda>
> > University of Twente, Enschede, The Netherlands. 23 June 2009*
> >
>
> Consider the following:
>
> > To date, the fully automatic generation of the code from models is
> still
> > a dream and, if it works at all, restricted to specific application
> > areas. One of the main obstacles is the lack of adequate models for the
> > behaviour of the software and of mechanisms to integrate behaviour
> > models with structural models and with other behaviour models.
>
> This is an insult to practitioners of Executable UML. We've had
> application area independent "fully automatic generation of the code
> from models" for well over a decade. The Executable UML method clearly
> defines integration of behavioral and structural models.
>
> > There are different approaches for modelling behaviour in the UML:
> >
> > * Use UML Behavioural State Machines ("Executable UML"), which have
> > semantics that borrow largely from work in real-time systems.
> [SNIP]
> > Although there are many different approaches for modelling
> behaviour, none of them enjoys the same universality as the UML class
> diagrams do for the structural parts of the software.
> >
>
> I find this to be a contradiction per my statements above. The only
> way it isn't is if the reference, "("Executable UML")", actually
> refers to "executable UML". I like to make the E vs. e distinction
> rather than using the phrase, "Executable and Translatable UML",
> because I failed to find any usage of the term, "Executable UML",
> before the Shlaer-Mellor people started using it. IIRC, the Mellor and
> Balcer book also preceded any alternative usage of the term.
>
> > Further evidence of confusion about PIM level behavioural modelling
>
> It's not hard to find evidence of confusion on almost any subject
> pertaining to software development. Pretty much all of it can be
> traced to ignorance, and a lot of the ignorance is due to
> unwillingness to learn. This isn't endemic to software developers, and
> seems to be a societal issue.
>
>