On Thu, 17 Feb 2005 02:04:51 +0900, Markus Pilzecker
<markus.pilzecker / io-software.com> wrote:
> Austin Ziegler wrote:
> | Actually, Ilias, it is 100% accurate. There is no system in
> | existence -- no CASE tool in existence -- which will allow you
> | to:
> Would you subsume an MDA-based model transformer and generator
> framework under your understanding of ``CASE tool''?

A "generic" model transformer and generator, yes. A framework,
maybe. It depends on the capabilities. However, properly stated,
code generation is a toolbox, not a tool.

> | 1) generate any random application in the world that can use an
> | embedded database or an external database and perform well in
> | any use case; and
> I think, this is a point, where a generator indeed helps. It helps
> a lot to keep domain knowledge in the model [of the domain -- you
> see, it's about to become a tautology] and to concentrate the
> diverse aspects of technology projections into the transformation
> engine.

Yes, but a generator isn't necessarily the same as what was being
talked about. All of the generators that I've ever used have been
domain and application specific. Additionally, proper generation
techniques indicate that you should know how to implement at least
one of the items you're generating (e.g., if you're developing a
generated GUI, you should develop at least one screen by hand; the
same applies to web interfaces, etc.)

> | 2) program against platform-agnostic GUI to run on systems from Sun
> |    to Linux to Windows to MacOS X to PalmOS or even something
> |    embedded in your toaster, OR run as a web application at whim.
> |
> | That's basically what you're wanting. There's no such commercial
> | application and there's no such open source application. Why?
> Only, if you exclude transformer|generator frameworks from the
> understanding of CASE tool.

Not at all. Code generation is a technique -- a toolbox -- and not a
silver bullet. It's a very valuable technique, and various tools can
help with the technique, but there's still *no such (singular) tool*
to generate an application and make it run everywhere in every way
that makes it feel right for those platforms. It's a non-soluble
problem, especially when you get to user interaction and platform
look-and-feel.

To take a simple example, there's a development tool for mobile
development called "AppForge". This plugs into a Visual Basic
development environment and allows you to generate mobile apps for
the PocketPC, PalmOS, Symbian, Windows Mobile, Windows SmartPhone,
and a few other targets, I think. The application thus generated
requires a massive runtime (300Kb on PalmOS systems) and doesn't
look like native applications. Similarly, Java's Swing doesn't look
or act like any other application on a platform.

If a developer for the platforms in question can't do it, what makes
you think that a transformer/generator will be able to do it?

>| Because such a tool would SUCK. As every single CASE tool in
>| existence has ever done. CASE tools generally require that you
>| run a very large runtime, program *their* way, often in *their*
>| language (which isn't related to anyone else's), and then tend to
>| fall behind both operating system releases and the technology
>| curve.
> Transformer|generator frameworks concentrate the knowledge of the
> target technology in the transformation engine. At least for
> simpler scenarios, this does not at all imply generation or use of
> a runtime system:  e.g., if you have modelled your system in
> ArcStyler and use its Java2-cartridge to generate code of it,
> there is nothing near to a runtime system, which comes into the
> game. And the result is [at least beyond javac] as slim as what
> you could code by hand.

Maybe. I'm very skeptical of claims in this direction. Indeed, what
the OP wanted was something that could be run on an embedded device,
a workstation, or a cluster of servers. I'm sorry, but I stand by my
original statement: there's no such tool -- not even ArcStyler --
which can do that. (And I'm unsurprised that UML is being pushed
this way. UML is good for very few things, and the most important
part of making an n-tier database applications is one of the things
that UML is worst at: data modeling. It's too based on OO
technologies to even remotely come close to properly modeling data
relationships other than hierarchical.)

[major snippage]

> Present experience shows, that all structural decisions[, e.g., which
> patterns you apply, what a deployment descriptor is or the syntax of a
> make file, ...] get materialised in the transformation engine and
> can be kept separate from the domain world to quite a high degree.
> Just to say it a bit more explicit: programming diverts into two
> activities: programming the transformer and programming the domain
> dynamics.

Again, maybe. ArcStyler and other OMG-driven insanities won't help.
Being able to state requirements clearly will.

-austin
-- 
Austin Ziegler * halostatue / gmail.com
               * Alternate: austin / halostatue.ca