[ Back To Entry Executable UML ]

What it Is

Executable UML is a subset of the UML notation which specifically aims to model requirements not solutions, and to do so in sufficient detail that the model of the requirements may itself be executed independently of any design. ¹

Where It Comes From

The definition of Executable UML comes out of a debate on how you get from an OOA view of the world to executing program (or hardware). One side of the argument is that you may enhance and elaborate from the OOA model to incoroprate architectures, implementation, and code structure. The other side of the argument says that if you describe your OOA model precisely, you can translate it directly to code using archetypes (which is a fancy way of saying rule-based mappings e.g. "A UML class maps to a C++ class, and UML attributes become instance-based attributes of that C++ class"). On the elaboration side were the likes of Grady Booch, and on the translation side were the likes of Steven Mellor.

One of the advantages of the translation approach is that it produces precise executable models independent of architecture and implementation details. For "executable model" read "program that doesn't know what operating system or hardware it is running on, or for that matter if it has been implemented directly in hardware". It also produces those executable models much earlier, than if you have to wait for implementation work to complete before you can test whether your requrements capture was correct.

When you look carefully at these executable models, it is clear that however you choose to to generate your program from the OOA model, both strategies, of elaboration and of translation, can actually start from that executable model. What it does to the elaboration process is that it provides a much more precise starting point (but with the result that the elaboration process starts later and takes less time).

And so Executable UML was born. The driving force behind Executable UML remains those methodologists who prefer translation by archetype (because it fits directly into their existing development lifecyles), but even those who prefer an elaborative approach to development are beginning to take an interest, especially those with a string interest in requirements capture by use-case and sequnce diagram as Executable UML gives them the opportunity to test their model against the requirements cature (as opposed to implementation) sequence diagrams.

Executable UML is however still very much "bleeding edge" notation (and the work is currently much more on the notation side). But executable models are not: the Shlaer-Mellor method, which is based on the translation approach, has been around since the mid 1980s.

Why Choose To Use It

There are many reasons for choosing to produce executable UML models. Some are to do with re-use, others are to do with handling complexity, and yet more centre around project risk reduction and cost control.

Re-Use

Examples of when you may want to separate requirements from solutions are:

• A word processor system that you will implement on say Microsoft Windows, an Apple Mac, and Linux.
• A computer game to run on Playstation, Dreamcast and X-BOX.
• A set of web-pages to run on multiple browser/operating system combinations.
• A range of telephone exchange products, where you need to apply the same essential functionality across a range of products that have different hardware platforms depending on the number of subscribers it supports.

In each case the exact behaviour that you need in terms of what your programs must do is the same, but how you implement that behaviour will depend on your programming language, hardware and operating system choices.

Complexity

Some systems that are modelled in UML notation involve relatively complex interactions between instances of classes, and between the system you are modelling and the outside world. Even without considering the architecture on which the model will be implemented, describing the interactions between the classes and the lifecycles of the individual classes is a major exercise in itself.

If, in expressing system behaviour, you also have to consider an instance-to-processor allocation model, and possible variations depending on hardware platform, the model can become unmaintanable and on occasion unreadable.

The advantages of first modelling what a system must do and not how it may implement a solution are clear to see, and have formed the basis of systems analysis for a considerable number of years; these advantages are also independent of whether you choose to implement truly executable models or simply use such requirements models as the basis for further elaboration.

What makes Executable UML stand out, and why it helps in particluar with complexity is twofold:

• The precision of the model
• The testability of the model

With Executable UML you have a precise description of all the information content, the lifecycle of that information, and its interactions and dependencies. You also have precise descriptions in an action language that describes the sequential behaviour of a class instance when it changes state. Since we are only describing what the system must do, we (should) produce the smallest, and simlpest expression of the requirments. All of the additional complexity of dealing with implementation issues is removed.

Whilst Executable UML is precise description of system behaviour, the classes and their lifecycles are only a specification of the system. Implementations of the Executable UML may structure/map those classes and lifecycles quite differently in order to support he underlying architecture. When you draw an Executable UML class, you are not specifying a C++ or Java class, you are only describing an element in a system, the mapping of that element to code happens later.

Because an Executable UML model is a complete description of system (not implementation) behaviour, it is testable: you can choose use-cases, draw sequence diagrams and then execute the model to test that for each external stimulus in the sequence diagram, you get the expected outputs from the model. This means you can test your understanding of the system behaviour without having to consider implementation issues. It also means that when you have failing tests, you know the problem is either with your test itself or with your understanding of the system requirements, and not something deep inside your implementation.

Risk And Cost Control