Once the project grammar has been determined, we can focus on the automatic generation of components that are language parameterized such as frameworks for generic analysis, transformation, and pretty printing [13]. Since we are working in a first-order setting, we cannot use higher-order analysis and transformation functions. Instead, we generate from the grammar specific analysis and transformation functions which perform a default operation for each language construct. This default behaviour can be overruled by writing conditional equations that define the desired behaviour for specific language constructs.
This immediately raises the question, who should write these equations: a formal specification expert or a programmer knowledgeable in the legacy languages of the project? It is clearly necessary to be able to describe certain patterns in the code to facilitate analysis and automatic change. The approach we take is to automatically generate a pattern language [47] from the project grammar that resembles the language defined by the project grammar as much as possible. Thanks to the tight integration between abstract and concrete syntax in ASF+SDF, we can express patterns over the abstract syntax tree using the concrete syntax of the language being reengineered. In this way, a programmer knowledgeable in that language can specify search and replacement patterns in conditional equations without needing to know all the formal machinery that is used in the factory as a whole.
It is important to have complete control over what steps are taken during a (automated) renovation process and over how their intermediate results are handled. We automatically generate support for a form of ``scaffolding'' which is similar to the inclusion of pseudo-code or assertions in comments during traditional code development. In our case, we see a scaffolding as an extension to the project grammar that allows the representation of intermediate results of analysis or transformation as annotations of the program code.