Responding to Thirsk...

> ==  Introduction to DAF ==
> 
>   I am interested in the next generation of approaches to software
> development.  Over the last decades, there has been an obvious shift
> in how our most complex software is created.  We started off with
> punch cards (or so I am told -- I was born in 1981 so apologies if my
> history is off or my ideas are naive), punching in a stream of ones
> and zeros.  The code contained only 0 and 1 and everything else was
> abstracted in the mind of the programmer, even the machine-level
> instructions.  Then we moved to assembly language, where code more or
> less explicitly contains the machine-level instructions, while the
> meaning of variables, and the control structures were still largely
> abstract.  From there, with the advent of C, control structures and
> variable names are now in the code.  With C++, objects are in the
> code, while system-level architecture, design patterns, and object
> interoperability are still mostly abstracted.

FYI, paper tape preceded punched cards and plug boards preceded paper 
tape.  By the time punched cards arrived on the scene there had already 
been a lot of automation in the form of loaders, linkers, and Assembly 
compilers.  In the Plug Board Era software was quite literally an 
extension of the hardware.  One "wrote" a program by using a jumper to a 
power rail to selectively turn on/off the grid in triode tubes.

[Doing that and changing vacuum tubes was such a character building 
experience that I didn't do software again for a decade when 3GLs and 
solid state computers were commonplace (late '60s). B-)]

> 
>   The general trend is a move towards more intelligent code -- from
> 1's and 0's, to objects with explicit inheritance, interfaces, and
> data members.  Each time more abstractions are made explicit in the
> code, the code becomes easier to implement, test, and reuse.

True.  There has been a steady migration from right to left along the 
continuum:

Requirements -> Analysis -> Design -> 3GL code -> Assembly -> Executable

Today everything to the right of 3GL code is fully automated unless one 
is doing embedded systems or developing compilers.  But it took nearly 
three decades to get there.  Since the '70s things have migrated further 
in specialized niches like RAD IDEs for client/server applications.  (In 
at least once <rather narrow> arena, ATLAS (IEEE 716), a text 
requirements specification language is routinely compiled directly into 
an executable.)

However,...



> 
>   I am interested in exploring the next step (perhaps even determining
> the nature of or actualizing the final step), of moving more
> abstractions to code, making the code more intelligent, and easier to
> develop, as the developer needs to carry less abstraction in his/her
> own head.

In the late '80s the technology arrived to do exactly what you want to 
do.  It is called translation-based development.  Tools have existed for 
nearly two decades that will do 100% code generation from an OOA model. 
  Today all such tools employ UML as the notation and OMG's current MDA 
effort is providing much needed standardization.  You might want to 
check out the way MDA employs meta models to provide mapping between 
different model notations in the normal stages of software development.

In addition, you might want to check out these tool sites for examples 
of full code generators from OOA models:

ARTiSAN           www.artisansw.com
Bridgepoint       www.projtech.com
ObjectBench       www.ses.com
Rhapsody          www.i-logix.com
Rose/RT           www.rational.com
System Architect  www.popkin.com
xtUML             www.kc.com

In addition Pathfinder (www.pathfindermda.com) provides code generation 
rear ends for several UML drawing tools, including Rose.  These are just 
the vendors that have been around for a decade or so.  Since the MDA 
initiative was launched translation tool vendors are popping up like 
tulips.  The Bridgepoint, xtUML, and Pathfinder sites all have several 
white papers on translation available (albeit mostly at the Executive 
Summary level).

[Some are not pure translation vendors because they use an augmented 3GL 
as an behavior description language rather than an abstract action 
language (UML v1.5).  Also, some cater to both the translation and 
round-trip markets so some foraging of their web sites to find the 
translation stuff may be necessary.]

Your approach seems interesting based upon the summary.  Unforunately 
there wasn't enough in the summary to indicate how attractive it would 
be versus the existing technologies for translation.  My concern is that 
you may be reinventing a lot of work that has already been done.  That 
is, the "next step" has already been taken.


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

H. S. Lahman
hsl / pathfindermda.com
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
(888)-OOA-PATH