miUML – an open source Executable UML project

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.

If you enjoyed this post you can subscribe to this Software Modeling blog , to the portal’s mailing list , follow me on twitter and/or participate in the forums . And if you really liked it help me pass it on to others by sharing the post using the links below. Don’t forget to check our consulting and code-generation services either!

5 Responses to miUML – an open source Executable UML project

  1. Lee, one suggestion I have is to keep PostgreSQL as an implementation detail. I find worrisome to tightly couple an entire modeling platform API on one specific DB implementation. APIs are meant to give you freedom, and your picture seems to be wasting that opportunity.

    I suggest addressing that by designing a very slim OO layer on top of it (mapping 1:1 to the PostgreSQL schema relations and stored procedures) that would be implemented on all target languages. That could probably be auto-generated from the miUML metamodel (ie. DB schema).

    • I meant Leon, sorry…

    • Leon Starr says:

      All good points, Rafael. Here’s where I think we agree:
      1) The metamodels (class models) themselves are the platform independent component
      2) the PostgreSQL implementation of the API is just that, one particular implementation of command driven model editor

      That said, I think you might not be appreciating the full power of the API and what it represents. And I haven’t done a great job of explaining it, (it was hard enough to code it!) so that’s on my list of things to do. Also, the thin layer solution won’t work.

      Before explaining why, I need to make this point clear:

      There is no requirement at all to use the API. Developers are free to access the class models directly and create their own access layer in whatever language suits them. Furthermore, developers are welcome to create their own schemas from the class models in whatever database they like (SQLlite, Oracle, MySQL, or even NoSQL – good luck with that!)

      HOWEVER, I don’t recommend it in most cases. Why?

      Any complete Executable UML domain, such as a model editor (what I’ve been calling the possibly misnamed API), must specify data/control/processing and thus a complete set of class model, state models and action language would be required. But we only have class models! Where’s the control/processing component? In theory, we should eliminate the ‘API’ and replace it with platform independent state charts and action language.

      Well, I’ll tell you why ;)

      The metamodel editor is light on state behavior and we don’t have an action language specified yet. SO, being pragmatic, we have a set of class models (data) and the database stored procedures (control/processing) to complete the editor. In other words the ‘API’ is really just an implementation of the missing statecharts/action language.

      If you use the class model only, you lose ALL the behavior that enforces the constraints described by the class models. It’s a lot of work to replicate properly and I strongly encourage use of the API. It just seems silly to me to redo all that work in another implementation language without a REALLY good reason. Once we have a proper miUML action language, we’ll be in a position to respecify the SQL completely in miUML. And maybe throw in a few statecharts as necessary. I think that this approach is what you are trying to get to in the last sentence of your comment.

      And I don’t think the metamodels would be of much value to anyone without the behavioral component (API/editor).

      That said, anyone can build their own editor instead. Andrew Mangogna has, for example, started work on a TclRAL database and D language style relational algebra API using the metamodels. He is also coupling that with SQLlite for persistence (TclRAL is in-memory only). Personally, I would prefer a D interface to ugly SQL, but the current implementation comes nowhere close to the functionality available in the Postgres API, not to mention Postgres itself.

      The nice thing about the stored procedures, is that they HIDE the ugly SQL from the developer. You can code the front end of a GUI or whatever language you like without having to know PLPGSQL. Most every programming language can access the API.

      As for a ‘slim OO layer’, believe it or not, the stored procedures in the API are exactly that. Anything slimmer would not enforce the constraints laid out in the class models.

      By the way, in choosing Postgres, I was looking for 1) open source 2) a robust stored procedure language 3) strong enforcement of referential, identity and type constraints. As far as I can see, Oracle is the only other option that comes close, but it is not open source.

      - Leon

  2. As for a ‘slim OO layer’, believe it or not, the stored procedures in the API are exactly that. Anything slimmer would not enforce the constraints laid out in the class models.

    I think you misunderstood what I was proposing. I am totally fine with the fact you deem PostgreSQL is a good technology for *implementing* miUML. I was not suggesting replacing anything you have in your picture. My suggestion was just to have an OO API that wrapped (not replaced) the calls to the database (and did nothing else) – the actual work would still be done by the database. Everything you currently have would still remain (including any contraints). The benefit is that people developing tools (which I suspect are often implemented using OO) wouldn’t need to deal wit the “database concern” in their code, and their code would survive changes to the API implementation (if one day it transitioned to another DB, or a non-DB based implementation).

    As a tool developer, I don’t want to have to care if the mechanism you use to store and maintain the models happens to be a database – I just want a (database-free) OO API I know I can rely on even if 15 years from now there is desire to reimplement the miUML API on top of a different technology.

    Makes more sense now?

    • Leon Starr says:

      Ah. I’ve got no problem at all with that. In fact, that is exactly the sort of thing I would invite somebody to contribute! And I’m happy to coordinate with anyone who is interested in putting that together. Seems to me that the OO layer should live on the open source (library) side with regard to LGPL3.

      - Leon

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Powered by WordPress
More in tools, UML
Featuring your MDE tool in this portal
logo_moskitt_home
From UML models to AJAX Java EE code in OpenXava with MOSKitt

ER
The only thing I miss from the ER language

Close