IOW: your concern is that code gen is not "agile" enough?
q.
No, I'm saying that UML is not adequate enough to provide a basis for the ultimate in code generation. If it was, then the fundamental precepts would provide enough in the definition of "use cases" such that the system could be "mechanically" devised.
Geert says
"Yes, you CAN still hand-code assembler, but it is only done by a few weird specialists, and only if REALLY needed. All normal people let the compiler create the assembler stuff." Beware, my friend, beware! Looking into my somewhat cracked crystal ball I can see a time when
"Yes, you CAN still hand-draw class structures, but it is only done by a few "weird specialists", and only if you really need to HUMOR THEM. All normal people let the the modeling tool create the conceptual system structure."But, and I mean BUT!, there is a dimension to the whole modeling ethos that is being ignored/sidestepped in this discussion. If it were possible to construct a "system-to-generate-systems" then it must start at the first and fundamental concepts. That is, in the case of UML, the use case. Obliquely, I was trying to say that it is a case of "physician, heal thyself!" The sheer idea of humankind's ability to devise a universally coherent "round-trip" code generator, when we can't even devise a coherent definition of what the "damn code is supposed to achieve in the first place" is somewhat like trying to design a brick that could build the Winchester Cathedral, by itself so to speak, so we didn't have to help, or "work" so to speak.
Or, in other words, there are more substantial problems within UML and therefore by extension, EA, that need to be solved before the answer to "how come when I click on generate and then on import and then on generate and then on ...". So to get back to Geert, yes there will always be a need for assembler coders, just as there will always be a need for UML expert practitioners, if not then Dog help us! We'll all be out of a job.
Well Paolo, you did warn them
!
