Page 159 -

142 Chapter 5 System modeling

5.5.2 Executable UML

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 here to
describe the details of xUML, so I 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 with its expressiveness. They introduced
useful notions such as use case diagrams that help with the design but which are too
informal to support execution. To create an executable sub-set of UML, the number
of model types has therefore been dramatically reduced to three key model types:

1. Domain models identify the principal concerns in the system. These are defined
using UML class diagrams that include objects, attributes, and associations.

2. Class models, in which classes are defined, along with their attributes and
operations.
3. State models, in which a state diagram is associated with each class and is used
to describe the lifecycle 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 lan-
guage. 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.

KEY POINTS

A model is an abstract view of a system that ignores some system details. Complementary system
models can be developed to show the system’s context, interactions, structure, and behavior.
Context models show how a system that is being modeled is positioned in an environment with
other systems and processes. They help define the boundaries of the system to be developed.
Use case diagrams and sequence diagrams are used to describe the interactions between user
the system being designed and users/other systems. Use cases describe interactions between a
system and external actors; sequence diagrams add more information to these by showing
interactions between system objects.