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
> 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.