Earlier versions of UML were not executable; they provided for an extremely limited set of actions (sending a signal, creating an object, destroying an object, as well as our personal favorite, "uninterpreted string"). In late 2001, the UML was extended by a semantics for actions. The action semantics provides a complete set of actions at a high level of abstraction. For example, actions are defined for manipulating collections of objects directly, thus avoiding the need for explicit programming of loops and iterators. Executable UML relies on these new actions to be complete.
For UML to be executable, we must have rules that define the dynamic semantics of the specification. Dynamically, each object is thought of as executing concurrently, asynchronously with respect to all others. Each object may be executing a procedure or waiting for something to happen to cause it to execute. Sequence is defined for each object separately; there is no global time and any required synchronization between objects must be modeled explicitly. The existence of a defined dynamic semantics makes the three models computationally complete. A specification can therefore be executed, verified, and translated into implementation. Executable UML is designed to produce a comprehensive and comprehensible model of a solution without making decisions about the organization of the software implementation. It is a highly abstract thinking tool to aid in the formalization of knowledge, a way of thinking about and describing the concepts that make up an abstract solution to a client problem. Executable UML helps us work out how we want to think about a solution: the terms we need to define, the assumptions we make in selecting those terms, and the consistency of our definitions and assumptions. In addition, executable UML models are separate from any implementation, yet can readily be executed to test for completeness and correctness. Most important of all, together with a model compiler, they are executable. |