The next logical step is to executable models, which have everything required to produce the desired functionality of a single domain. These 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.
Executable models act just like code, in a sense, though they also provide the ability to interact directly with the customer's domain, which is something code doesn't do well. They're not exactly the same as code, though, because they need to be woven together with other models (for example, a meaningful user interface) to produce a system. This is generally done by a model compiler. As each model is complete in itself, though, once the weaving is done, the system is complete.
Just as programming languages conferred independence from the hardware platform, executable models confer independence from the software platform, which makes executable models portable across multiple development environments. Contrast this with adding code bodies to models. Such code bodies are inherently dependent on the structure of the platform for which the code is intended.
One way to express executable models involves the use of Executable UML, a profile of the UML that defines an execution semantics for a carefully selected, streamlined subset of the UML. The subset is computationally complete, so an executable UML model can be directly executed. Executable UML defines groupings of data and behavior ("classes"), the behavior over time of instances ("state charts"), and precise computational behavior ("actions") without prescribing implementation.
Chapter 9 offers details about executable models and Executable UML.