The latest on Modelio.

icon contribute

What do you call "professional" or "serious" modeling tool? I can give a set of criteria (mine). I do not pretend being exhaustive, but these are important criteria, that I have. Most of them are sadly never seen in tool evaluation criteria.


This one is a frequent request. This means that all features defined in the supported modeling language standards (UML2, BPMN2) are properly supported by the tool. Even those that are ill defined by the standard? (well, it happens: I will come back later on this point). And these that are of a very minor interest, or of interest for a very tiny community?

Modelio provides a good coverage of UML2 and BPMN2, but does not pretend to be religiously exhaustive. I give here a first indication: UML Action semantics is very poorly covered by Modelio. We are in the "tiny community" case here: The use case for Action Semantics is that it provides a metamodel (and thus a storage model in the modeling database) that could be used by some language (additional to UML) on top of it, such as a syntactical language.

I have never encountered end users asking for it (I mean a real one, not the fake one just playying R&D). But, should this happen frequently, let's do an additional Modelio project to cover that.

There are, however, respectable communities working on Action Semantics tooling.


This features the ease to create the model you are looking for with a modeling tool: can you easily manage large models, can you easily refer to an existing model element, can you change and restructure easily an existing model, ... ? This criteria is hard to grasp, due to the numerous ergonomic related aspects that it covers. To summarize: how easily and smoothly can you create, update and handle your models? Counter examples are tools having a GUI closely mapped to the underneath metamodel: if for example you need to handle "AssociationEnd" elements to create an association, or if in order to create a lifeline in a sequence diagram representing a Class you need to do elementary actions creating the intermediary elements and links, then practicability is out of reach.

Modelio does a fair job in this area, but this is a permanent ongoing effort. For example, dragging a class and dropping it will provoke smart actions depending on the target context: creating lifelines in sequence diagram, parts in internal structure, data objects under a BPMN process diagram. Referencing other model elements, such as typically the type of an element (attribute, parameter, ...) is a frequent action while modeling. If you just enter a string to define a type, ditch your tool! Modelio provides direct referencing or drag & drop or text completion.

Model element identification

Very often, the most important things are details that we do not discover at the first sight.

"Model element identification" is one of them. How to properly manage elements, if they are not identified? That is impossible! Many tool identify model elements, such as Classes, by their names. This leads to disasters: A Class named "Client" by someone could be renamed "Customer" by someone else. These tools will consider that "Customer" is a class different from "Client". What will they do? Discard "Client" and create "Customer"? Have both the "Client" Class and the "Customer" Class? These two wrong options will apply depending on the exact use case. Let's guess what happens in teamwork situations...

Now, let's imagine a large model on which a UML profile applies. Now the profile has a new release, where some stereotypes have changed with different names and properties, some are discarded and some new stereotype are created. We need to update the profile by applying the new one to our existing model, and we certainly do not want to check everywhere which stereotype has been applied, and which new one should replace it. Model element identification allows to just apply the new version of profile to the existing model, in order to update the model.

As a last implication example, let's think about code/model roundtrip. The code contains "strings" in which are the names of model elements. Having identifiers, the tool can adorn the main program element (class, operation, ...) in the code with their modeling identifier, allowing thus a better correspondence management.

Modelio implements a unique identification mechanism for each model element that allows keeping track of the element and any transformation or generation that has applied to it.

Ownership management

I have encountered an unpleasant experience with several modeling tools : after creating a class diagram under a package, I have reorganized the classes into several other packages. Where are the associations between classes now? Still in the original package, specifically the non navigable ones.

That's silly: the original package has no relation with the other packages, the classes and associations, except an historical one. This leads quickly to a mess when we need to deliver separately the packages or to work in a teamwork configuration.

These tools are not wrong according to UML: they are just unpractical at the few places where UML has been vague in its ownership definition.

Modelio has rules and heuristics, where associations ownership is always related to the connected classes.

Managing very large models

I will come back to that one. As a model is a complex graph, models tend to be entirely loaded in memory by modeling tools after doing some modeling activities. Under Windows, this leads to unacceptable performances with large models. The footprint and efficiency of the tool obviously matters, but more important is the capacity to organize models into different working spaces, and to handle communication between these spaces. "Model Component" is the key mechanism that Modelio provides for this purpose.

^ Back to Top