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.
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.