"In its current form UML is designed to support a wide variety of different modelling techniques and formalisms. This is evident, for example, in the state machine formalism which allows both Moore and Mealy formalism with hierarchical states including concurrent sub-states and both synchronous and asynchronous calling semantics. The result of this is not only that almost any state modelling style can be supported but also that many combinations of elements have no defined execution semantics. It is now widely recognised within the UML community, however, that considerable benefit can be gained by forming subsets of the UML with well defined execution semantics. Such subsets can form an “executable UML” which would enable the simulation, execution, testing and ultimately translation of UML models into target code. As part of this movement, work is progressing under the auspices of the OMG towards the definition of “profiles” that define such subsets and towards the more detailed definition of the contents of “actions” including a more precise definition of the execution semantics of UML models."

“Executable UML is at the next higher layer of abstraction, abstracting away both specific programming languages and decisions about the organization of the software so that a specification built in Executable UML can be deployed in various software environments without change.”

“MDA per se is relaxed about exactly what models it transforms, so long as the modeling language in which the models are expressed can be defined.”

“Creating a modeling language that is also an executable language has long been a goal of the software community. Many years ago, in 1968 to be exact, while working with software components to successfully develop a telecommunications system, we created a modeling language that was the forerunner to UML. To model components we used sequence diagrams, collaboration diagrams, and state transition diagrams . Our modeling language then seamlessly translated the component models into code. Each code component was in its turn compiled into an executable component that was deployed in our computer system. The computer system was a component management system—thus we had "components all the way down.”

“Stephen J. Mellor at geekchic.com”

“In the bad old days before MDA, models served only to facilitate communication between customers and developers and act as blueprints for construction. Nowadays, MDA establishes the infrastructure for defining and executing transformations between models of various kinds.”

“What's the point of having metamodels, and why should you care? Because models must be stated in a way that yields a common understanding among all involved parties, we need a way to specify exactly what a model means. Metamodels allow you to do just that: They specify the concepts of the language you're using to specify a model.”