Leon Starr presents us today his new tool miUML.

miUML (pronounced my-UML) is an open source Executable UML project that has just launched at miuml.org. Our goal is to provide a hub where the Executable UML community can plug in a variety of both open and proprietary model editors, code generators, simulators, import/export and related tools.

There are two parts to the hub: 1) a set of metamodels that describe and constrain the modeling language and 2) a fully implemented API that makes it possible to create, edit and, eventually, execute an Executable UML model.  Both components are licensed as a library under the Lesser Gnu Public License (LGPL3) which explicitly keeps the metamodel and API open while making it accessible to proprietary tools.

What is Executable UML exactly?

Executable UML is a hybrid of standard UML (graphical notation) and platform/language independent execution semantics designed to support both embedded and enterprise system specification, simulation and code generation. 

What can you do with Executable UML?

With Executable UML you can the model platform independent logic, behavior, synchronization and algorithms in an application and run it without having to mix in any platform specific code such as C++ or Java.

This makes it possible to develop and test immediately, in great detail, without having to wait for issues in the implementation technology (target language, operating system, distribution architecture, hardware, etc) to sort itself out.  By definition, platform independent models can be ported, without modification, to a variety of platforms.  When the platform specific details are factored out, it is possible to make faster and higher quality progress on the application (business/science) logic and to expose the nuanced logic for verification by the relevant subject matter experts.

By contrast, traditional development mixes application and platform details from the get-go.  This is bad because 1) application requirements are often compromised, oversimplified or misinterpreted in the effort to achieve high performance 2)  or vice versa, misunderstanding of a subtle application feature may prevent the implementers from capitalizing on it to enhance performance  3) tangling application and implementation logic complicates both increasing the likelihood of bugs and slowing progress 4)  after delivering a working system, porting to a new or varied platform necessitates the untangling and re-tangling of the application and design logic, typically resulting in new (worse yet, old) bugs being introduced into the application logic.  5) progress on the application  stalls when serious issues or changes develop in the target platform 6) with all the subject matters perpetually entangled, it is difficult to benefit from engineer specialization – everyone has to know a little bit about everything to get anywhere 7) if you don’t know why 6 is bad, spend some more time in the software industry.

Right, but what about the platform?

Nothing we deploy, by definition, is platform independent.  Platform dependent technology in all its detail and complexity must be fully understood and exploited to yield an effective implementation.  This is particularly true in embedded system development.  Platform independent modeling cannot be achieved by pretending that we can focus on ‘high level’ details while we defer ‘low level’ details.

The misleading notions of ‘high level’ and ‘low level’ details do not exist in the Executable UML world.  Application details and platform details are equally important.  It’s just that the platform details are relevant only to a particular platform and the application logic details are exclusive to the application.  We don’t trivialize or omit important details, we just factor them into separate but bridgeable domains.  For the most part, these domains can be developed in parallel with specialized engineers working in each domain (see item 6 above).

Compiling a modeled application onto a platform

To make a long story short, here’s what you need to implement a set of Executable UML models:  1) An architecture that will execute the models which runs on the platform.  2) A set of marking models that
tag various model elements and color them for specific platform features (supported by 1) and 3) a code generator that takes the marking models and Executable UML models as input and outputs a combination of model generated code and hooks into model execution architecture run time libraries.  It’s not trivial to get these 3 items working for you on a project, but it’s not magic either as this has all been done on numerous projects.  The problem is that the technology is largely proprietary and not exactly shrink wrap. And there are only a few handfuls of engineers out there who know how to put all the pieces together.  All the more reason for an open source movement to make the technology more accessible to those outside the elite world of Executable UML.

miUML offers a new metamodel of Executable UML

To create platform independent models you need a lot more than a graphical notation such as UML.  You need the equivalent of a full development language.  Executable UML models run on a set of math/set theory/distributed synchronization principles that provide a kind of platform independent machinery.  For example, every platform independent object runs concurrently, with its own local Einsteinian clock, and there is no assumed sequence unless explicitly specified. (The exact opposite of most programming languages).  Any given implementation may introduce further sequencing as necessary, by running everything in a big loop, for example.  The model execution architecture is not a virtual machine in the Java sense (though you can build one) but a well defined set of rules and execution semantics that are typically compiled and used in conjunction with run time libraries.  This rule set is the ‘executable’ in Executable UML.

miUML models Executable UML as described in this book by Stephen Mellor and Marc Balcer as well as some earlier white papers by Sally Shlaer.  While the book does an excellent job of describing the language informally, a metamodel is required to support the development of compatible editors, model compilers and model execution environments.  Several Executable UML metamodels already exist, but are typically 1) proprietary to varying sometimes uncertain degrees 2) poorly documented 3) peppered with tool specific features  4) unconstrained (permitting non-sensical and illegal model structures to be created) 5) blissfully ignorant of systematic identity and referential constraints, especially when loops of relationships are involved.  The miUML project seeks to remedy these problems.  miUML also fully embraces relational theory as the class model underpinning and a compatible type system as described by C.J. Date and Hugh Darwen.

The miUML roadmap

The miUML hub is not yet complete.  But enough does exist to begin designing compatible tools, participate in discussions and coordinating effort.  So far, we have the class metamodel subsystem and a fully implemented API ready for your perusal.  The subsystems are:  Classes and Attributes, Relationship Structure, Identity/Uniqueness Constraints, Relationship Formalization (Referential Attributes), Domains and Subsystems and a first stab at Data Types.  The API provides commands such as new_class( … ), new_binary_association( … ), rename_attribute( … ), delete_relationship( … ), that sort of thing.

A lot of work remains.  Next up is behavior modeling (statecharts), followed by action language.  Though they aren’t yet published, the first draft statecharts are in decent shape, so we should have a release up on the site by the end of the year.  A primitive action language will be released followed by improvements over the course of 2012.  The API will be extended as we go.  And, in case you were wondering, all the elements will be resolved to OMG standards, such as fUML, in time.  That said, our philosophy is that the integrity, simplicity and usefulness of the design comes first, standards second.

On the platform specific side, a model execution architecture is being built on an ARM processor platform by Andrew Mangogna.  He also has the beginnings of an action language (raloo) built on top of an in-memory relational algebra implementation (tclral).

Clearly we’ve got a long road ahead of us, but it’s not too early to get involved, or at least learn more about the technology and its capabilities.  Keep an eye on us throughout 2012 and feel free to contribute to the discussion group.