Even though the evolution system was shown to be useful for real world scenarios, there are a few drawbacks that limit the applicability of the system. For example, the presented evolu- tions were designed to target merely a single solution space model at a time. This suffices for most practical applications but may cause problems if there are models in the same space that reference one another. For example, a UML model may be accompanied by a UML diagram model, which contains the information to visualize the original model in the graphical UML rep- resentation. Evolutions such as Duplicate Class currently only affect the UML model but not the diagram representation. In consequence, the duplicated class is not shown in the diagram representation even if the original class is present. In a concrete case, this problem can be solved by implementing the additional steps of modification for the dependent model in the respective evolutions.
Another limitation exists with the use of the object remapping specification. When adapting a modification specified by Refactory for the use in a software product line, the expressiveness of the ORSpec may not be sufficient to perform an adequate remapping. The problem stems from the fact that only objects that play a particular role in Refactory can be targeted but not their descendants. For instance, if an element is deleted, its mapping should be removed along
with it. Specifying that the mapping of its descendants should be deleted as well is not possible as Refactory only provides the objects playing at least one of the specified roles. An equivalent situation may appear if a particular element is duplicated and its mapping should be copied to the clone including the respective descendants. However, this type of problem currently is of no practical consequence as Refactory allows to only delete elements that do not have descendants and it does not provide a copy operator.
The most severe limitation of the evolution system arises with models that identify elements of the model by their position in the containment hierarchy. For example, in DocBooklet a particular section might be targeted as the third section of the second chapter. All EMFText languages use this mechanism as their textual syntax does not necessarily allow to specify explicit IDs. Furthermore, other types of models may be affected as well. When performing a modification that alteres the order of elements on one such model, the IDs have to be adapted to the changes. This may happen when adding or removing but also when reordering elements as with the Move Up Chapter evolution for DocBooklet. As the position of an element in the containment hierarchy was changed, it has a different ID after the modification and all references using this ID have to be updated.
For a single memory instance of a model, EMF adapts references to IDs according to the performed modifications automatically. However, if there are multiple instances of the same model, IDs and references may become inconsistent. Unfortunately, the evolution system is required to deal with two separate instances of the same solution space model. The first instance of the solution space model is held by FeatureMapper, which uses it as target of the mapping. The second instance of the very same model belongs to the specific solution space editor (e.g., UML editor). When the evolution is triggered from the editor, the modifications are performed on the respective instance of the model held by the editor. The instance of FeatureMapper is updated after the model was saved by unloading and then reloading the resource of the model.
During this process, the mapping targets of the solution space model are converted to proxy objects holding the URI of their targeted elements, which (in part) consists of an element’s ID. After the solution space model was reloaded, the proxies are resolved to objects using the stored URIs, which have not been altered in accordance to the performed changes. In consequence, targets of the mapping model may be invalid as they point to the wrong or a no longer existing element. For example, the Remove Section evolution might delete the aforementioned third section in the second chapter of a DocBooklet model. As part of the evolution, the mapping of the deleted section will be removed as well. However, mappings to the rest of the document may cause problems. For example, if there were a fourth and fifth section in the second chapter, they would now be the third and fourth section respectively. Thus, mappings to the old fourth section would now target the old fifth section and mappings to the old fifth section would now be invalid as no new fifth section exists. The latter harms the mapping model and prevents FeatureMapper from saving, which informs the user of the problem. However, in the first case, an unintended mapping is introduced to the mapping model by mistake, which is particularly dangerous as it can easily go unnoticed.
A solution to the problem would be to refrain from using the position of an element for identification. Unfortunately, not all solution space models permit using unique IDs (e.g., the textual languages of EMF Text). One possibility to overcome this issue would be to obtain IDs
from an external provider that has knowledge of the targeted type of model and thus can use other characteristics for identification than the position of an element. For the described case of DocBooklet, it might be possible to use a combination of the title and content of a section as ID. Until a solution to the described problem has been conceived and implemented, special caution has to be applied when evolving models that use the position of elements for identification.