Enterprise Modeling - Model Persistence

Quite some discussions regarding the persistence of models took place at the Eclipse Summit Europe 2010. It seemed to me that there are two main camps. One side prefers files while the other looks for a scalable repository. Three questions are related to this:

How are model elements identified?

• Each model element has a unique identifier
• Selected model elements have a unique name

How are models edited?

• With a text editor which means that there are transient states where a model is syntactically invalid   
• With a specialized model editor which does not allow the user to create  syntactically inconsistent states
• With a projecting editor combining the two approaches

How are models stored?

• Textual modeling languages are naturally file based to be able to handle the transient states and will use the element names for identification as required by the implemented language. Other model elements have no identifier.
• The ‘traditional’ modeling approach is more flexible as the elements have an implicit or explicit id. It and can use both files and repositories for persistence and always has a form of model element identity.

There are some differences which become important to select the appropriate approach when looking at a specific use case.

The first essential difference is the guarantee of traceability over the life cycle of model elements.

• The identity based approach is more robust – traceability is only lost if an element is deleted and then re-created again (which results in a new element). 
• The name based approach is more brittle. A name change breaks the traceability (unless there is some magic done behind the scenes)

The level of traceability is important when dealing with model evolution. The conventional approach enables tracking of every change in the model whereas the textual makes only those states visible, when the model representation is syntactically correct.

The next difference is directly influenced by the storage mechanism and becomes relevant for large models.

• Repository based approaches scale better as model elements can be retrieved using the identifier when required
• The file based approach requires partitioning of large models. The partitioning may by straightforward in certain use case but it can also be artificial when the model has no natural partitioning. It is also problematic when different views on the same model are possible as they often do not have the same natural partitioning needs.

What does this mean? The selection of the persistency mechanism depends on the actual use case – it will be influenced by the required level of traceability and by the natural structure of the domain being modeled. The user of the modeling environment should have the flexibility to choose one or the other approach or even combine them. The modeling platform must allow the user to make the choice. And as we learned in the key note by Jeff Norris – we should have the freedom to stay uncommitted and make the decision late. Sounds like a standard interface to me where the best suited storage provider can be injected.

Eclipse Summit Europe 2010 - Modeling Platform Focus Day

Here is a view on the Eclipse Modeling Platform in the light of the key note by Jeff Norris he held at ESE this Wednesday. He made the point that innovation requires having a vision, being willing to take risks and to stay uncommitted as long as possible in order to keep agility high.

Vision – the Eclipse Modeling Platform has an agreed vision “The Eclipse Modeling Platform (EMP) is an industrial quality integrated software platform designed to enable a complete tool chain of model-centric tools. It will be based on existing Eclipse modeling technologies but focus on better integration, quality, scalability and usability for use in the enterprise“.

Risks –the group is certainly willing to take risks but it is also important to mitigate known risks. So far the group has not worked out a risk list. A solid risk management will be needed as part of the wider initiative going forward. One of the risks is that the projects do not pick up the envisioned interfaces and that the fragmentation stays as it is.

Commitment – stay uncommitted as long as possible but when the point comes make the required decision. An iterative approach tackling the right things at the right time in the right way is hence imperative.

The key point is to get the architecture sound and stable so that technology suppliers, tool providers and consumers can hook into the platform.

This means that for all technology providers know what they have to respect in order to contribute to the platform. The overall initiative must have a snowball effect with the architecture and the standard interfaces as its core.

There is an iterative plan which follows the priorities defined by the workgroup participants. The important point is that the initiative delivers iteratively interfaces and implemented reference services and consumers which can be used by all modeling projects and provides them a benefit. The plan complementing the gap analysis shows the following milestones:

·         The 1^st milestone’s focus is on establishing a sound architecture and on closing some of the obvious gaps in individual technologies.

·         The 2^nd milestone mainly provides a revised version of UML support which can work on the repository as well as merging functionality.

·         The 3^rd milestone mainly adds traceability, security and more support of versioning and evolution of models or parts thereof. 

·         The 4^th milestone adds multi user and distributed team support as well as first functionality for model management.

An industry working group is envisioned to implement realize the vision. For me the key point is that interfaces are defined which get a wide acceptance so that the integration of the individual technologies becomes as smooth as possible. The difficult point is that we talk here about interfaces which may (or even should) be implemented and also used by many projects.

If you or your company is interested to join the initiative, then please contact Ian Skerrett.