Keep track of where things came from

[Jörg Kienzle]

It would be great to keep track of where model elements came from in "woven" models.

This could be done in the model by changing a "reuse" to a "was reused", and potentially linking each model element with a "was reused".

In the GUI it would be then possible to display a list of models that "were reused", and tapping on a "was reused" could highlight all the model elements that were introduced/affected by the reuse.

[Matthias Schoettle]

Issue #154 was marked as a duplicate of this issue.

[Matthias Schoettle]

This information needs to be persisted, because a woven model can be saved and later be opened again. Specifically, when reusing a concern the woven model is persisted.

We don't want to store a direct link to the aspects that were woven in order to not get into problems when moving the woven model on the file system.

[Matthias Schoettle]

We still need to figure out how we identify tracable elements in the model. Whether it is an abstract super type or the mapping is done for any model element (e.g., EObject).

It is only possible to use EObject as a type of a reference if the Ecore metamodel is loaded as a resource. I am not sure what the implications of this would be and if it is a good idea.

[Wisam Al Abed]

After our meeting on Aug 5, 2014, we have decided to extend the metamodel to add support for tracing. The general gist of the solution is to create two new entities in the metamodel: Traceable and Weaving. Traceable will be an abstract class. All elements from our metamodel that we wish to tag as traceable will inherit from Traceable so for example if we want operations to be traceable then the Operation entity will inherit from Traceable. Weaving is the entity that will have a reference to the external aspect when weaving. Furthermore, the weaving entity will also store the name of the aspect as a string hence it is also named i.e. inherits from NamedElement. Every aspect contains zero to many Weavings depending on how many aspects are woven into it. All traceable elements in an aspect will be added to a weaving every time an actual weaving is performed.

The general flow of the algorithm is as follows:

1. When a weaving between two aspect A and B is requested, the weaver will creating a Weaving entity(W) in the woven aspect AB.
2. Each time the weaver performs a weaving between two traceable elements class C1 from A and class C2 from B with C2 -> C1, it will set the Weaving of C1 to be W i.e C1 will come from the weaving W.

[Thomas Di Meco]

Is it not the Weaving class that should be Named?

[Jörg Kienzle]

Perfect

• J

[Wisam Al Abed]

Yes you are correct thanks very much i updated the comment

[Wisam Al Abed]

References#129:Added preliminary support for tracing currently only classifiers, attributes, and operations are traceable

→ <<cset 0125b4915db1>>

[Wisam Al Abed]

References#129:Fixed error with regards to references between aspect and wovenAspect mistakenly made the two references opposites. Also changed names of role name to be clearer

→ <<cset 74265b75fc00>>

[Matthias Schoettle]

References issue #129: Reverted change to RamPackageImpl that replaced namespace URI of CORE.

→ <<cset 3d1870695170>>

[Wisam Al Abed]

Currently basic support for tracing in the metamodel works. Currently requires further testing before closing the issue.

[Matthias Schoettle]

Maybe we want to add information of what element the element came from, i.e., if a class was merged from multiple classes, it could be nice to see which ones (same for other elements).

This would require the Traceable class to have a self-reference (maybe transient). Or we don't put it into the model, but into a separate one that has this mapping.