Contents

Introducing Executable UML

What Makes Executable UML Unique

The Notation

UML Action Semantics

Synonyms

xUML

Related Subjects

The Shlaer-Mellor Method

OOA to Code using Translation By Archetype

The UML Action Semantics Group

The Notation

It is anticipated that there may be many subsets of UML notation used to describe an Executable UML model. To this end, the documentation talks about profiles of UML, where a profile describes the subset of UML notation and any required UML stereotypes, together with the assumptions governing how classes are grouped, and how classes (and their object instances) communicate. These last two points are of particular importance.

To be able to execute a model (i.e. simulate the requirements), you need to know in what order messages between objects will be handled. You also need to know what priority those events will have between groups of objects. So, what priority does an external event at the edge of your model have? Are you assuming a single thead of control through your model, or does each object instance truly run in parallel? Do you intend to group classes into a client/server configuration? If so do events between groups of classes have the same priority as between object instances within each group? This means you:

Define a virtual machine/architecture on which your model will execute.

If you think about it, this is not so unusual: if you are drawing UML sequence diagrams and UML collaboration diagrams, you are already making assumptions about your virtual machine (you even number the messages in the order they occur on the collaboration diagram). This also happens in other environments e.g. (1) Java is not just a programming language but a defined virtual machine that specifies everything down to the gauranteed storage size of data type, e.g. (2) The language ADA also defines many thing about its runtime environment, e.g. (3) UCSD Pascal compile to byte code to execute on a virtual machine, e.g. (4) PolyForth compiles to byte code and executes on a virtual machine. What links all of these examples is that their virtual machines were designed to keep the programs as independent of platform and hardware considerations as possible.

When you finally implement your executable model on the target hardware and operating system, it is this specific virtual machine you must emulate. If you don't emulate the same machine, you cannot be sure that your logic testing will be correct.

If your final target platform is multi-processor or a distributed system, you need to think carefully about your choice of virtual machine; some machines will be much more efficient to realize than others. All will work, at least from the logic viewpoint, if not from the timing viewpoint, but a machine that assumes a single thread of control with synchronous messages may peform badly if the implementation is very distributed and has only asynchronous communications available.

It is also important that your virtual machine is stable. Change the machine and you may invalidate tens (or more likely hundreds) of sequence diagrams, plus all of your collaboration diagrams.

Proposed Profiles

Currently only one profile of UML is under development. To quote Steven Mellor, one of the people driving executable UML:

[It is] based on state charts and asynchronous, distributed behavior. Each object has a state machine that executes independently of all others. It is in just one state at a time, possibly executing many actions. It can invoke data access methods (that do not change state) synchronously, and it can send asynchronous signal events to communicate and synchronize with other independently executing state charts. Both these elements and the interactions between them have a precise definition at run-time-sufficiently well-defined, in fact, to be executable, and translatable into multiple possible implementations

UML Action Semantics

One of the problems UML has suffered for some time is a lack of defined action semantics to describe the sequential behaviour of classes. You see this in every UML CASE tool on the market where the action semantics vary on a vendor-by-vendor basis, and often you are provided with no better facility that a shell in which to write programming code. Thre a re sume manufacturers who provide proper action semantics to keep your model source-code independent, but they are manufacturer specific.

Without precise action semantics Executable UML is not possible (how would you describe the actions that occur on state transitions?). The solution being abdopted within UML is an abstract action semantics specification. This does not supply a language to describe actions as such, but says what behaviour any action language must have. This means, in theory at least, that in the future the action language supported by any one CASE tool vendor should be directly translatable into any other dialect. This can either be viewed as a subtle and elegant piece of meta-specification, or as a political fix because the CASE tool vendors can't agree amongst themselves (and figure heavily on the steering groups for UML).