What is miUML?

The miUML (pronounced my-UML) project is centered around two key goals.  First and foremost is to provide an open executable UML metamodel and API hub around which a combination of free and proprietary development tools may be contributed.  So nothing prevents miUML from becoming your-UML.  Second is to create a metamodel that supports high performance code generation while preserving platform independence and the high level of abstraction necessary to support complex requirements analysis. miUML realizes the execution semantics originally defined by Sally Shlaer and Steve Mellor and supports the Object Mangement Group's standard UML as well as alternate graphical notations.  In fact, the metamodel itself is entirely notation neutral.

Why open source?

It’s easy to get developers and requirements analysts excited about all the powerful things you can do with executable UML.  But then you get the following question:  ‘How can I start playing around with it?’  Answer:  ‘Get hired on a project using it (good luck!) or shell out some serious cash for the tools.’  Result:  Another java programmer is born. 

The key word here is 'play'.  That’s how we learn to use tools with which we eventually do ‘work’.  You cannot skip the ‘play’ step.  Inherent in the concept of ‘play’ is ‘free’.  Many of us are willing to pay when it comes time to do real work on a funded project.  But you can’t skip that first step in the sandbox where interest, skill, experimentation and enthusiasm spring forth.  And a 30 day evaluation followed up with sales pressure, while appropriate for a funded project, throws a stinky wet blanket on the engineering playground.

We want to make the powerful and proven technology of executable UML available to as many students, developers, individual analysis, product visionaries as possible.  An ever expanding cadre of application analyst and software architects have had the experience of building complex systems directly from models rather than source code.  But to do this, we need tools and expertise that rarely coalesce into the critical mass required to carry a project through to completion.  There just isn’t enough platform independent talent out there right now.  miUML is an effort to make executable UML accessible to a wider audience so that the pool of talent, projects and tools becomes the rule rather than the exception.

That said, the ultimate success of any technology lies in the ability to profit from it.  miUML is an attempt to reconcile these two driving factors.  The LPGL3 license treats the miUML metamodels and API as a library that may be freely distributed, modified and used in conjunction with both free and proprietary tools.

Which Executable UML?

We want the best of both worlds for the application (business/science) logic and the software design.  The models should be articulate and detailed representations of platform independent requirements without prescribing any particular implementation.  The developers and/or model compiler should be free to choose the best platform specific technology and implementation.  The models shouldn’t make programming decisions, and the developers shouldn’t be sticking their noses in the application logic.

Even though miUML models may be used to generate Java or C++ code, those very same models may target other languages such as Go, Python, plpgsql, C, assembler or even hardware circuitry.  So the model elements of miUML do not necessarily mirror those of Java or any other particular programming language.  Instead, miUML provides a level of abstraction better suited to expressing application logic without specifying implementation. So don’t go looking for implementation features like private method or static class in miUML, because you won’t find them.

We do not fancy ourselves language innovators.  Rather, miUML is an effort to realize the execution semantics, language elements and development philosophies already described in the following resources as a set of metamodels and an API:

• Executable UML: A Foundation for Model Driven Architecture by Steve Mellor and Marc Balcer
• OOA 96: A paper written by Sally Shlaer and Neil Lang back in, you guessed it, 1996.
• Databases, Types and the Relational Model by C.J. Date and Hugh Darwen

Why miUML?

There are several existing UML and Executable UML metamodels.  So why, oh why, do we need another one?

There are several motivations driving miUML:

1) Fix problems and inadequacies in existing Executable UML metamodels and tools such as:

• Incorrect or non-existent formalization of referential attributes and the rules for using them.
• Unconstrained generalization and incorrect use of referential attributes therein. 
• Poor and non-existent metamodel documentation. 
• Lack of explicit constraints.
• No explicit support for constrained loops. 
• Incorrect identifier construction. 
• Tool-hack variations from Shaler-Mellor and Mellor-Balcer (class based statecharts, for example)

2) Provide a better and more transparent fit between miUML and the underlying relational theory

Executable UML is derived from Shlaer-Mellor which was based firmly on the relational model which is grounded in set theory and mathematics.  In the rush to appease the object-oriented community and adhere to UML, many great benefits of referential attributes were dropped.  We’re bringing them back.  OCL has been put forward as a mechanism for expressing constraints, but in many cases, referential attributes solve the problem more concisely and directly in the model structure thus helping ensure that they are carried forward into any implementation.

3) Create a metamodel that better enforces the modeling rules.  Existing executable UML metamodels permit nonsensical constructs such as one-legged generalizations.

4) Incorporate features that were lost in the adaptation of UML notation onto Shlaer-Mellor, such as symmetric reflexive associations.

5) Remove various hacks that have been introduced as shortcuts by vendor tools and subsequently abused by modelers.

6) Make it open source to encourage larger scale participation in development of tools, publication of techniques, and usage.  If you don’t have to worry about onerous licenses and innovation stifling attorneys, you can feel more comfortable about getting down to business and realizing your dreams!

7) Provide a hub for both proprietary and open source tools.

8) Raise the bar for model documentation. 

Every aspect of the miUML metamodel is documented.  Every class, attribute, identifier, association multiplicity, association conditionality, association meaning, loop constraint, data type is described and illustrated.  An emphasis is placed on explaining the rational behind all abstractions.  We truly want to open this metamodel up for others to use and extend.  We also hope that he standards used for these descriptions will be adopted by other analyst/modelers.  One can always hope.

What can I do with miUML metamodel?

You can use the metamodel as the foundation for designing model editors, model level debuggers, model to code compilers, import/export tools and any other MDA utilities.

If you want to build or adapt a tool, such as a graphical model editor, it can be either open source or proprietary as long as the metamodel library (models and API) source, along with any of your modifications, remains freely available to everyone.

The metamodel is also the ultimate reference to the executable modeling rules.

The models may also serve as a learning resource.  Advanced modeling practices such as merged referential attributes, stable generalization partitions, constrained loops, carefully named association perspectives, use of domain specific types, strategic use of specification classes, and strong documentation are few topics you can explore when you curl up with your metamodel descriptions at bedtime.