This educational site was launched in May of 2017. Expect it to be a bit messy as it evolves into a broader collection of Executable UML educational and technology resources. For now, it is being written mostly by Leon Starr. In the future, it will be opened up to more community participation.
Executable UML is a modeling language designed to express requirements clearly and unambiguously. The notation is a subset of the Object Management Group's (OMG) Unified Modeling language (UML). But the underlying semantics (the meanings of the notational elements) is quite different than any UML you have probably heard about or experienced. So get ready for something completely different.
What's special about Executable UML?
The models you build are fully executable. Like a programming language, Executable UML is complete, so you can run and test the models without writing any code. You don't insert Java or C++ or any programming langauge to get the models to do their thing.
The models you build are platform independent. So let's say that you build a model of aircraft landing and handoff procedures in an air traffic control application. Or let's say you model the time and response patterns of the cardiac muscle in a pacing application. The models that you build are completely about the subject matter and say nothing about how it will be implemented. So your model, and the intellectual property it captures, remains useful across a wide variety of implementation technologies and platforms. You never have to change a model just because the platform technology changes or evolves.
The modeling language is lean and mean. You want the language to be as simple as possible, with as few notational elements as necessary. This way, when you look at a model, you see your application rules and policies clearly with a minimum of modeling language artifact.
Concurrency is fully supported. In most programming languages you start with the assumption that everything runs in sequence unless you specify otherwise with mechanisms such as threads, go routines, forked processes and so forth. In xUML, the default assumption is that everything happens at once unless it is explicitly sequenced. Furthermore, there is no specification of any particular concurrency technology. You are free to map the model behavior to whatever concurrency elements are available on your target platform. This includes none at all. At least one existing xUML model compiler runs entirely within a single threaded loop.