Re: chooses not to generate code at all

Responding to JXStern...

Note that only the MDA tools supporting translation provide full code generation. The MDA round-trip tools, currently the most common MDA tools, that support traditional elaboration usually only generate static structure declarations.


Does structure-only really deserve the label MDA???

Probably. Just because the static view is the only one transformed doesn't negate the value of the transformation. One could also argue that MDA enables plug & play so that the drawing tools can be substituted with the source version control tools rather than requiring a monolithic round-trip environment.

OTOH, the round-trip tools are starting to do more code generation (e.g., state machine infrastructure generation is now fairly common) so they will eventually evolve into full translation tools.


In database, I suppose one can say the architecture is driven by the
data model in any particular application, but sadly, this
formalization does not extend to the guts of stored procedures, etc.
There is debate about how much business logic even belongs in the
database, and most people think some or ALL of it belongs outside.
Otherwise we'd have to call SQLServer an MDA system, and that doesn't
seem right to me.  How about you?

I belong to the camp that thinks nothing should be in stored procedures except rules related to data integrity that have the stability of Keplar's or Maxwell's Laws.

FWIW, I think SQL is an implementation of MDA principles because it enables a generic transformation from one model representation (application data) to another (RDB storage). In the end MDA is simply:

[Input Model]       [Transformation Model]
     |                      |
     |                      |
     V                      |
{Transformation} <----------+
     |
     |
     V
[Output Model]

If we have an Input Model of objects, C structs, FORTRAN arrays, or whatever for a specific application and we need to turn it into an RDB representation (schemas, tables, tuples), then SQL is one Transformation Model that formalizes that conversion. The actual Transformation can be done manually by the developer in the 3GL de jour or it can be automated by a full code generator.

Also note that for translation-based MDA there is no maintenance of generated code. If one needs to make a change it is done to the model and the code is regenerated. (I know of one vendor who deliberately makes the generated code difficult to read to prevent anyone from mucking with it directly.) One of the main reasons that the translation tools generate 3GL code at all is to reuse the optimization provided by 3GL compilers.


And other details of installation and binary formatting.

The early translation tools (and some engines for R-T/E environments today) went directly to Assembly or machine language. But that requires another level of optimization that the 3GL already compilers provide.

You are right that the 3GLs also abstract a number of convenient, reusable services like streaming devices and file systems. That makes life easier for the transformation engine. One could argue that sort of abstraction/composition/encapsulation for managing complexity that is ubiquitous in the computing space is what is incrementally leading to the inevitable automation of the computing space.

Finally, as McKinnon points out, I think the definition of "code" for codeless is bit picky. It seems to me that scripts are code in exactly the same sense as C or COBOL source code. [I could also point out that scripting and markup languages were widely used in the '50s and '60s and there is a reason why they were largely abandoned by the '70s. But let's not go there. B-)] 


Well, but if you have a model, it must be scriptable, or at least
persistable, right?  But I guess part of the *idea* of an MDA is that
you use the tool to get some advantage over any possible script, is
that what you're saying?

In a way. However abstract the model is, there must be some unambiguous implementation path to get to a useful model at a lower level of abstraction. One can encode that transformation manually or use a tool to automate it.

In this context my objection is that I see no substantive difference between writing scripts and writing "code"; it's all still 3GL implementation. Whether one automates the writing is an orthogonal issue.

[BTW, PathMATE is template based. The transformation engine semantics is really 'template processor' rather than 'code generator'. So if one swaps the template set one can do things like writing MS Word documentation from the same model without touching the transformation engine itself. (In MDA terms our templates are the relevant Transformation Model above.) We can and do produce things like CGI scripts. So from my perspective the OP's distinction of scripts vs. code is really irrelevant in an MDA translation context.]


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH



.

Relevant Pages

  • Re: Confusion with MDA / DSL
    ... MDA is basically about enabling unambiguous transformations from one representation to another. ... Each meta-model abstractly defines the semantics of the particular representation. ... The vertical arrows represent instantiations of a particular meta-model as a concrete model. ... Transformation provides mappings between the meta-models so that one can map the basic semantics from one meta-model to another. ...
    (comp.object)
  • Re: Lets put this to rest
    ... MDA is simply platform independant (I assume you are ... An OOA model is a solution model for functional requirements that is expressed solely in customer terms. ... As such it maps directly into an MDA Platform Independent Model because it does not depend on computing space mechanisms. ... The second is the conceptual framework for transformation where a Transformation Model provides tailoring via rules for a specific transformation. ...
    (comp.object)
  • Re: chooses not to generate code at all
    ... representation, then SQL is one Transformation ... Well, to start with, SQL is not the model, but relational algebra is, ... meta-model that provides the specific mappings necessary for the ... even constitute a "model" in MDA terms? ...
    (comp.object)
  • Re: Any MDA tools that have a transformation for Smalltalk?
    ... > They have C and C++ archetypes available, but a Smalltalk ... > I was always under the impression that MDA meant full ... then run a transformation (to be specified by ... on the modeling language and generators provided by the vendor. ...
    (comp.lang.smalltalk)
  • Re: chooses not to generate code at all
    ... "Where other MDA tools are generating programmingcode, ... >> Codeless chooses not to generate code at all". ... It seems to me that scripts are code in exactly ...
    (comp.object)