--- In executableuml@yahoogroups.com, "Lee Riemenschneider"
<lwriemen@...> wrote:
>
> --- In executableuml@yahoogroups.com, "Srinivas Nedunuri"
> <nedunuri@> wrote:
> >
> > A further comment. The biggest problem as I understand it is
> > generating production-quality optimized platform-specific code. Even
> > if there are some tools out there that do indeed do wide-spectrum MDA,
> > their techniques are buried inside proprietary code, which means they
> > are not open to examination and widespread understanding. From
> > academia's point of view (this is primarly an academia-driven
> > workshop) this is a no-no. For me a good sign will be when we see a
> > "Dragon book"-like Principles of MDA Compiler Design on the shelves.
> >
> I'm not sure what is an intended definition for "wide-spectrum MDA",
> but since is the Executable UML group, I'll restrict my remarks to
> Executable UML.
> The Executable UML semantics are pretty clearly defined. A number
> of people have built model compilers without needing access to
> proprietary tool code. It's my understanding that the "Dragon book" is
> as applicable to Executable UML model compilers as it is to 3GL model
> compilers.
>
By wide-spectrum, I was referring to MDA tools that aren't restricted
to specific domains, such as embedded or web services.

I'll give you that you could probably use many of the front-end
parsing and dataflow analysis ideas from the Dragon Book for
translating a UML+AS model, that is only a small (and shrinking) part
of what goes into a good compiler. The real value added is in the
platform specific code generation. Generating quality code for (say)
an app server is a more complex task than for an x86 instruction set.
You have to deal with transactions, bandwith limitations, server
capacity, memory capacity, communications delays, distribution and
clustering requirements, fault-tolerance, etc. In fact the problem
really becomes one of efficiently searching a large search space.
IMHO, an MDA dragon book would have to cover at least some of these
issues.

As I said before, I'm not denying that there's quality tools out there
that have solved some of these problems but (for obvious competitive
advantages) their solutions are not open to examination, and its
likely (though not certain) that at least some of the solutions are
ad-hoc, driven by the particular business requirments of the vendor.
Hence the need for academic conferences..

cheers