This Site

This educational site was officially launched on July 1, 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 may be opened up to community participation. For now, your suggestions and requests for content are most welcome in the discussion section, or via email below.

Next up: I'm hoping to post a few xUML mini-tutorials up in the coming weeks.

Why xUML?

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.

So, what's special about Executable UML?

PI thumb.png

Platform Independent Requirements Modeling

Conventional UML models, sooner or later, devolve into a mix of application requirements and code design. xUML is designed specifically to express the logic and data essential to your requirements without EVER biasing the implementation toward any particular code solution.

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 shifts or evolves.

Code or other implementation artifacts are never mixed into the models. Instead, the model elements are mapped over to corresponding code patterns through a translation process. This process can be partially or fully automated depending on the target platform. The translation process is directed by platform specific translation rules. These rules can be further refined by marking up the models with various performance directives. Still, these platform specific "markings" are kept out of the models similar to the way any markup language is isolated from the source it modifies.


Executable Modeling

The models you build are fully executable. xUML is complete, like a programming language, in the sense that all data (class model), control (state models) and processing (actions) are specified so you can run and test the models without writing any code. You don't need to insert Java or C++ or any other implementation language to get the models to do their thing.

Concurrency thumbnail.png

Concurrency fully supported

In the real world, things happen simultaneously. Software implementations, for a variety of reasons, lean toward sequential behavior. For example, in most programming languages you start with the assumption that everything runs in sequence unless you specify otherwise employing mechanisms such as threads, go routines, forked processes and so forth. Since xUML models express real world behavior, and not any particular implementation, it stands to reason that these models should readily express parallelism. In fact, the default assumption in xUML is that everything happens at once unless there is a real world constraint that dictates sequencing (a cabin's doors must be closed before that cabin can move).

You are then free to map the modeled behavior to whatever degree of concurrency or parallelism is available on your target platform. This includes none at all. At least one existing xUML model compiler, for example, runs all the modeled logic within a single threaded loop.

lean from web.jpg

Lean Modeling

A core principle in the design of xUML is the ability to express requirements unambiguously and precisely using as few symbols and rules as possible. Since the goal is to expose complexity, unusual cases, hidden subtleties and, most importantly, erroneous logic in the requirements subject matter, it is necessary to reduce language clutter to the bare minimum. This way, when you look at a model, your application rules and policies stand out clearly against the modeling language artifact.

This is in direct contrast with many traditional applications of UML where model developers revel in its expansive symbology and intricate rules.

Mathematical Foundations

Most UML is built on object oriented programming semantics. These foundations are unnecessarily complex (for requirements analysis modeling) and leak implementation assumptions into the modeling language.

xUML relies instead on more fundamental mathematical definitions. The class model is based on relational theory which itself is an extension of set theory, functions and predicate logic. State model execution and event communication are based on distributed networking theory. Actions are based on data flow analysis.

For example, if you ask a conventional UML modeler to define what is meant by a modeled class, they may describe the usual object oriented programming ideas such as encapsulation and leave you with, it as "kind of like a Java class" or "kind of like a C++ class" depending on their favorite oo programming language.

If you ask an xUML modeler, they will say that a class is a named set definition modeled to identify a collection of things such that each thing follows the same rules, shares the same behavior and has the same characteristics (without exception). No object oriented programming language element comparisons are necessary.

There are numerous benefits to building on strong mathematical foundations. The modeler benefits from a simpler and more expressive modeling language. The implementor benefits by having less complex and more orthogonal elements to map to code. Since math is platform neutral, it is easier to generate code for a wide variety of target technologies.