There seems to be some confusion about the relationship between these three concepts: executable models, code-generation and model interpretation.
An executable model is a model complete enough to be executable. I´m fully aware that this definition is kind of useless but the executability of a model depends more on the execution tool we use than on the model itself (e.g. some tools may require a more complete and precise model specification while others may be able to “fill the gaps” and execute more incomplete models).
The most well-known family of executable models are the Executable UML methods ( most classic book on this topic). Executable UML models make extensive use of an Action language (kind of imperative pseudocode, see for instance the Alf action language ) to precisely define the behaviour of all class methods. The OMG itself is now in the process of standardizing this notion of Executable UML models, more specifically, the Semantics of a Foundational Subset for Executable UML Models (FUML) . Surprisingly enough the current version of this standard does not include either a definition of what an Executable Model is.
Code-generation and model interpretation are then two different alternative strategies to “implement” execution tools.
The code-generation strategy involves using a model compiler (many times defined as a model-to-text transformation) to generate a lower-level representation of the model using existing programming languages and platforms (e.g. Java). Instead, the model interpretation strategy relies on the existence of a virtual machine able to direclty read and run the model ( example of a proposal for a UML virtual machine).
If in the beginning most MDD approaches opted for the code-generation strategy we are now witnessing more and more tools going for the model interpretation strategy (e.g. see Mendix or AlphaSimple ). I´m not going to describe now the benefits and drawbacks of each approach since Johan den Haan already did this job for me.
However I don´t see the two approaches are completely opposite. For instance, I could imagine a virtual machine implemented using an internal on the fly code generation approach (i.e. even if the user is not aware of that in fact the virtual machine would be using code-generation techniques to implement the model in an existing programming language before executing it). Not sure about the benefits of this mixed strategy but who knows?