Originally coined for the ShlaerMellorMethod, RecursiveDesign is the
approach to translative software construction where the translator
is part of the source code of the project, and the translator is
also developed using this translative approach.
This contrasts with the approach of many OOD CASE tools which attempt to
deliver OneSizeFitsAll code generators. This approach gives code generation
a bad name, because the impression is given that code generation is only suitable for situations where performance is unimportant.
The generic approach to code generation works well for translating a low
level language (such as C) to machine code. It is usable for higher level
languages, but there is an increasing disconnect between the source code
and the target machine. The translation of the higher level descriptions
require tradeoffs to be made in the translation. Once these tradeoffs
go beyond basic speed/size tradeoffs then project specific translators
become a sensible approach for optimisation.
The ShlaerMellorMethod provides a simple formalism that allows you
to build models that are easy to write translators for. The simplicity
of this formalism leaves it open to criticisms (some valid, IMHO) that
it is too simple. Any comparison of Shlaer Mellor against traditional,
full-featured, formalisms tend to show SM in an unfavourable light.
But the SM approach truely allows you to draw diagrams that are
the source code. SM originally came with its own notation, but is
has been shown that you can use a subset of the UML is you prefer.
As soon as you have a diagram, you can use a generic
code generator to run simple tests (and to gain insight into the
behaviour of the code/diagram). SM CASE tools will usually provide
simulators: these either interpret the models or generate highly
instrucmented code for the model. An orthogonal activity is to
construct (and maintain) a code generator that produces code that
meets the performance/interface requirements of the system.
See AspectOrientedProgramming, MetaRefactoring.