No. This rendition views each object as potentially having a state machine that can execute asynchronously and concurrently. We view this approach as necessary for today's distributed computing environments. However, one could define an executable UML that relies on synchronous method calls between objects to produce a completely synchronous model of the subject matter. Similarly, our particular use of the statechart diagram is not the only possible one.

Yes and No. The notational elements you see in this book conform to UML, and so qualify as a profile of that standard. In addition, the execution semantics defined here conform to UML, though we do both subset UML and impose certain rules to link the elements together. What is not yet a standard is the exact content of what can and should be interchanged so that we can guarantee that any and all model compilers, irrespective of vendor, can compile any arbitrary executable UML model.

Throughout this book, we use standards as much as they are established. In some areas, the book is intended to provide a basis for discussion of what should ultimately become a standard.

Yes, we hope so. Work has begun informally to define a standard and we will encourage and support it. We expect the standard to define an underlying semantics quite similar to that outlined here, and to layer increasingly rich syntax on top.

Not at all. This technology is taking off, and the basic elements are already established. Get ahead of the learning curve.

We assume you have an intuitive understanding of the goals behind UML, but nothing more. We will show you all the elements you need to build an executable UML model.

If you want to garner the benefits of Executable UML, then you'll have to learn the elements that make it up. Focus on the definitions we use and the chapters that show how to build and execute models. Skip the notational stuff. Be prepared to unlearn some UML and habits of mind required to model software structure, but not required to specify an executable model.

We don't need them for Executable UML. UML enables you to model software structure, but that's not our purpose here, so those adornments, and many others, are not in our proWle.

Shlaer-Mellor focused on execution and speciWcation of an abstract solution, not on specifying software structure. UML can be used for both the expression of software structure and the abstract model. Executable UML brings Shlaer-Mellor and UML together by using UML notation and incorporating concepts of execution. We hope this will make execution accessible to a broader community.

A lot can happen in this industry in ten weeks, let alone the ten years since the publication of Object Lifecycles. First of all, of course, we all now use UML notation and vocabulary. (Resistance was futile.) Executable UML takes a more object-oriented perspective, no longer requiring identifiers or referential attributes, or other traces of Shlaer-Mellor's relational roots.

The addition of an action semantics to the UML is a major step forward. We hope the action semantics, and the very concept of an executable and translatable UML may one day be seen as a significant contribution of the Shlaer-Mellor community.

Progress in tools has also made certain conventions, such as event numbering, less critical to model understanding, though they are still helpful in keeping our minds clear.

Because UML defines only the semantics of actions, it does not define a language.

We use an action semantics-conforming language that is executable today. We show several other action languages to illustrate that syntax is unimportant.

Yes. We chose a more IT-oriented case study to increase the reach of the approach. You can Wnd a completely worked out real-time case study in Leon Starr's book Executable UML: The Elevator Case Study.

All of the examples in this book were developed using Project Technology's tool, BridgePoint. A copy of BridgePoint can be downloaded from Project Technology .

There are two main differences. First, compiling models produces the whole system, not just interfaces or frameworks. Second, there are many different model compilers available to buy, and even more that can be built, to meet exacting software architecture needs.

Executable UML has been used to generate systems as large as two million lines of C++, and as small as handheld drug delivery devices. Executable UML has also been used in lease-origination, web-enabled executive reporting, and intermodal transportation logistics systems.

Because we had nothing better to do? No: There are lots of books out there that tell you about UML notation, but few of them focus on the subset you need for executability. Many books use UML to describe software structure. We explicitly spurn this usage.

Because it describes completely everything you need to know about executable UML: It's the Executable UML handbook.