Why Executable Models?

Java, Smalltalk, and C++ are at a higher level of abstraction than assembler, but they still call for consideration of a number of concepts of no interest to a customer. In conversing with customers, it's preferable to use a highly abstract modeling language that focuses on a single subject matter the subject matter of interest to the customer and yet is specific and concrete enough to be executed. In other words, we need an executable model.

Executable models allow developers to model the underlying semantics of a subject matter without having to worry about, for example, the number of processors, the data-structure organization, or the number of threads. In other words, 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. Code bodies are inherently dependent on the structure of the target for which the code is intended. For example, any code written for the target metamodel that assumes remote procedure calls (RPCs) can only be used in an environment that uses RPCs, even if the subject matter captured by the model is banking. The result of this approach is that models are not universal, but instead form silos that mix the modeling language (the metamodel) and the subject matter at hand. This is a form of architectural mismatch (Garlan 1994), which executable models seek to avoid.

Moreover, software platform independence abstracts away glue code required to connect two components implemented using different technologies, such as .NET and J2EE. Executable models therefore enable collaboration between different platforms, as well as projection to arbitrary platforms, which benefits projects supporting multiple iterations, releases, and configurations.

Executable models also provide for early verification. Because the model is executed, it can be shown to be correct (or not) as soon as it's conceived, without waiting for a design or an implementation. We take up this topic in more detail in Chapter 10.