It's fundamental to the idea of ColdFrame that you don't need to build a design model by decorating your clean, beautiful analysis model with all sorts of support clutter (lists, queues etc). The software architect decides how analysis models are to be translated into code, and a mechanical process (applied either by a programmer or by a program) applies the rules.
That isn't to say that you can be slapdash about your models. Often people will treat the modelling phase as if it were a sketchy whiteboard activity; you can't do that if the model is going to be translated directly into code (not that that was ever a good idea!)
An example of a commercial product which takes this approach is artisanStudio.
It's important that the tool lets the architect adopt different strategies depending on circumstances. For example, the way that ColdFrame generates code for a class is changed markedly if you apply the stereotype «singleton».
This need makes it very advantageous to have a complete programming environment available while scripting the output. Predetermined substitution variables aren't likely to fill the bill. Pattern matching facilities will help.