How to track changes made in an SCA model?

This document explains how the STP-IM may track changes in an SCA model.
This solution could be used in other use cases related to model transformations and changes tracking.

As a prerequisite, it is assumed you know what is an SCA signature.

Tracking changes in SCA models with the STP-IM builder

The STP-IM use case

The STP-IM aims at bridging STP tools thanks to a central meta-model defining SOA concepts and their relations. Each STP tool can then map the concepts it works on with the concepts represented in the intermediate model. One of the features the IM component provides is a builder to synchronize the different views within the tooling. As an example, we could imagine two BPMN and SCA models being linked through an IM instance. In this situation, some BPMN elements would be associated with certain SCA elements, and vice-versa. The association would be made through an STP-IM instance.

The IM builder aims at reporting modifications made in one model (e.g. the BPMN one) in the associated models (e.g. the SCA model in this example). The issue is that it is not possible to intrinsically associate SCA elements with STP-IM elements. With BPMN, it is possible. The BPMN specification defines the graphical representation, not the way this representation is written. In the STP BPMN modeler, BPMN elements are associated a unique ID (UUID) by the modeler. This ID will never change as long as the element exists. Therefore, it is possible to associate this element with an IM element.

With SCA, this is not possible.
The specification defines the XML schemas (and also the graphical representation). Add an ID attribute, like in the BPMN modeler, would not be a clean solution. XML and EMF parsers would be able to deal with that. But only the editor which defines this ID would understand its meaning. Within SCA Tools, there are four editors, relying on 3 different model representations. Such an attribute would have to be strongly required in order to be correctly handled by all the editors. With BPMN, there is only one editor. That's the reason why it is difficult to imagine the IM builder remain synchronized with SCA resources.

Using SCA signatures

SCA signatures bring a basis of a solution to this issue. An incomplete solution, but better than nothing.
SCA signatures are computed SCA IDs. They can be stored as string objects by the IM builder. To determine what has changed in an SCA model, the IM builder could proceed the following way:

• For very element of the first SCA model...
  • Compute and store the SCA signature of the element.
• For every element of the second SCA model...
  • Compute the SCA signature of the element. Search this signature in the first model signatures.
  • If it is found, compare all the properties / attributes to determine what has changed.
  • Otherwise, it may be a new element (store it).
• Process orphan the elements from both models (i.e. which were not found in the other SCA model).
  • These elements may have been removed.
  • Or their identifiers may have changed (e.g. if the name of a component has changed, then its signature has changed).

In any case, the STP-IM builder would have to find a solution to deal with this last situation (it must be possible to compute the proximity between two signatures and/or provide a merge view). If we see the IM component as a helping tool, one nice approach could be to simply add markers on unresolved resources and let the user deal with that (rather than wanting the perfect matching in any situation and provide a wrong mapping).