-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Austin Ziegler wrote:
| On Wed, 16 Feb 2005 04:34:53 +0900, Ilias Lazaridis
| <ilias / lazaridis.com> 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''?


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


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


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

Of course, if one utilises external libraries[, which is usually the
case], your domain model has a surface against a model of these
libraries, or an abstraction thereof.  And then, you will link your
application against a runtime lib, when it comes to build it.

If, at some time in the future, javadoc is replaced by the model of
the world, represented by the lib, your transformer|generator were able
to _generate_ exactly this part of the lib, which is needed together
with your application.  You can regard this as on-the-fly generation of
the runtime system.  Seen from this perspective, a lib of nowadays is
nothing else than a cache of the generated products.  Consider e.g. a
state machine like it is used in lex or a table-based L2-engine as in
some LALR-parser: why shouldn't you want to ``cache'' it in a library?

A clear advantage of a generator is, that you can easily customise the
generated products.  And [e.g. with ArcStyler] it is already possible,
to use one and the same model and generate Java code from it or C# code
[or both] and the artefacts, you need to build, and, if you like, deploy
it to an application server.

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.

Certainly, you have the freedom to be unclever and interrelate model
and transformer tightly.  But this is less the fault of a methodology,
but an inherent property of any knowledge engineering process: you
have the freedom to be dumb.  The question is: does it help you to be
un-dumb?

So much,

~   Markus



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCE3uP0sM4x4ItYcQRAntfAJ9lwO/yi1JAcVxcr+AhdfScvMheOwCfcKJy
JrfvPMnG7XJJtWAFmhw83j0=
=ryQ0
-----END PGP SIGNATURE-----