From: "H. S. Lahman" Date: 2004-02-26T05:59:49+09:00 Subject: Re: New paradigm of introspective OO development 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 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