The Execution Model

Figure 9-1 shows the structure of an Executable UML model. However, a language is not meaningful unless there is a well-defined execution semantics. Executable UML has unambiguous rules regarding dynamic behavior how the language executes at runtime stated in terms of a set of communicating state machines, which are the only active elements in an Executable UML "program."

Each object and class (potentially) has a state machine that captures, over time, the behavior of that object or class, and associated actions reachable through procedures defined on that object or class. Every state machine is in exactly one state at a time, and all state machines execute concurrently with respect to one another.

Coding Versus Actions

Why use an action language rather than just write code?

The semantics of actions are defined so that data structures can be changed at translation time without affecting the definition of the computation a critical requirement for translatability (see the next section, Translating Models). Therefore, action models and languages allow you to specify behavior without relying on knowledge of the implementation. For example, a common approach to finding the total amount of the last ten transactions is to loop through the data structure creating a sum as we go. This inextricably links the computation to the data structure, but what if that structure changes? The action semantics casts this example problem instead as two actions: Get the last ten transaction amounts, then sum them. The consequence of this small change in view is that it is possible to change the storage scheme without affecting the algorithm that sums values.

Note that you can use Java or C++ syntax as an action language, so long as it conforms to the underlying action model.

The result is an executable UML model that can be translated to any target.

When a transition fires, a procedure comprising a set of actions is executed. The actions in each procedure execute concurrently unless otherwise constrained by data or control flow; these actions may access data of other objects. It's the proper task of the modeler to specify the correct sequencing and to ensure object data consistency. A state machine synchronizes its behavior with another by sending a signal that's interpreted by the receiver's state machine as an event. On receipt of a signal, a state machine fires a transition and executes a procedure, which is a set of actions that must run to completion before the next event is processed.

State machines communicate only by signals, and signal order is preserved between sender/receiver instance pairs. The rule simply states the desired sequence of activities. When the event causes a transition in the receiver, the procedure in the destination state of the receiver executes after the action that sent the signal. This captures desired cause and effect in the system's behavior. It is a wholly separate problem to guarantee that signals do not get out of order, that failed links can be handled, and so forth, just as it's a separate problem to ensure sequential execution of instructions in a parallel machine.

An arbitrary model, therefore, contains the details necessary to support its execution, verification, and validation, independent of implementation. No design details or code need be developed or added for model execution, so formal test cases can be executed against the model to verify that requirements have been properly addressed. This form of verification can be carried out on each executable model, independent of the other models.

Them's the rules, but what's really going on is that Executable UML is a concurrent specification language. Rules about synchronization and object data consistency are simply rules for that language, just as in C++ we execute one statement after another and data is accessed one statement at a time. We specify in such a concurrent language so that we may translate it onto concurrent, distributed platforms, as well as fully synchronous, single-tasking environments.