The fundamental notion behind model-driven engineering is that completely automated transformation of models to code should be possible. To achieve this, you have to be able to construct graphical models whose semantics are well-defined. You also need a way of adding information to graphical models about the ways in which the operations defined in the model are implemented. This is possible using a subset of UML 2, called Executable UML or xUML (Mellor and Balcer, 2002). I don’t have space to describe the details of xUML, so I will simply present a short overview of its main features.
UML was designed as a language for supporting and documenting software design, not as a programming language. The designers of UML were not concerned with semantic details of the language, but rather with its expressiveness. They introduced useful notions such as use case diagrams that help with the design process but which are too informal to support execution.
To create an executable subset of UML, the number of model types has therefore been dramatically reduced to these 3 key types:
- Domain models that identify the principal concerns in a system. They are defined using UML class diagrams and include objects, attributes and associations.
- Class models in which classes are defined, along with their attributes and operations.
- State models in which a state diagram is associated with each class and is used to describe the life cycle of the class.
The dynamic behavior of the system may be specified declaratively using the object constraint language (OCL), or may be expressed using UML’s action language. The action language is like a very high-level programming language where you can refer to objects and their attributes and specify actions to be carried out.
Mellor, S. J. and Balcer, M. J. (2002). Executable UML. Boston: Addison-Wesley.