With the advent of the UML action model, it is now possible to build executable models. These models are complete in that they have everything required to produce the desired functionality of a single problem domain. An executable model of a bank, for example, would be able to transfer money from your account to mine (we'll implement the other way later), but it would not have a user interface in a meaningful sense of the word, nor would it have a way of verifying who you are, or even of storing data properly.
Executable models are neither sketches nor blueprints; as their name suggests, models run. This allows us to deliver a running system in small increments in direct communication with customers. In this sense, executable models act just like code, though they also provide the ability to interact directly with the customer's subject matter, expressed in the customer's language, which is something code doesn't do well.
Executable models for domains are not exactly the same as code (though they are something like aspect-oriented code) because they need to be woven together with other models to produce a system. These other models would include, of course, a meaningful user interface, a way of verifying who you are, and a way to store data properly. However, as each model is complete in itself, once the weaving is done, the system is complete.