Separate change propagation from VirtualModel

[HeikoKlare]

This PR separates the change propagation concepts of the framework from the VirtualModel. As a result, ChangePropagationSpecifications do only depend on the specifications of EChange and VitruviusChange as well as the user interaction definitions, but not on VitruvDomains as a VirtualModel-specific concept. In addition, the ChangePropagator that is currently integrated into the VirtualModel concepts is made independent to be used without a VirtualModel.

This involves:

• ChangePropagationSpecification accepts namespace URIs of the metamodels rather than VitruvDomains
• Introduction of ChangeInPropagation that decoples the information about whether a change shall be propagated transitively from accessing the VitruvDomains that are currently the only source for deciding on transitive propagation.
• ChangePropagator:
  • Operates on namespaces, depending on a lean ChangeRecordingModelRepository, which is implemented by the ModelRepository of the VirtualModel, rather than on VitruvDomains.
  • Knowledge about transitive change propagation has been transferred from access to VitruvDomains to an explicit specification in a ChangeInProgress delivered by the ChangeRecordingModelRepository, which makes the decision for transitive propagation.

With this PR, the tools.vitruv.framework.propagation bundle together with the change representation specifications can be used independent from the virtual model, domains and applications to implement change propagation. A subsequent PR (#502) will adapt the DSLs (Reactions, Mappings, Commonalities) to also depend on metamodel rather than domains, such that these DSLs can be used only depending on the change representation but not on the complete Vitruv framework.

In a future PR, we may also add a default implementation for the ChangeRecordingModelRepository to have ready-to-use implementations for all change propagation artifacts to be used without a VirtualModel, such that the DSLs can be easily used as standalone transformation languages.

[JanWittler]

I made pretty picky comments as these code parts will probably not be touched for a while.

In general I like the proposed changes, I am just questioning myself whether the approach to work directly on the nsURIs is the best. It makes the accessor names pretty long and we lose some type safety. The alternative would be to introduce some lightweight interface like ChangeDomain or similar that encapsulates the nsURIs. However, having an interface to only encapsulate one property can be considered as unnecessary overhead.
What were your decisive arguments to throw away the domain concept in the change context?

[HeikoKlare]

Thanks for the review. The reason why we want to get rid of the domain is that they are a concept that is only used in the VirtualModel in particular for reasons of persistence (save/load options etc.). To use the consistency preservation DSLs, the metamodels to be defined on have to specified in present VitruvDomains, which have to be provided in the registry provided via Eclipse extension mechanis. However, the only property consistency preservation needs to use are the metamodels. And in EMF, metamodels are accessed by their nsURI, which is why I used them to refer to the metamodels. An alternative would be EPackages, but they are only an implementation artifact of the metamodels and may even not be represented as a dedicated class we can statically refer to but as an instance of EPackage. Wrapping an nsURI within some "domain" class will not solve the problem of missing type safety, as you can enter whatever nsURI you want into that domain as well. And finally it is again an object to wrap around the EMF metamodel reference, the nsURI, like the VitruvDomains before, only in a more lightweight fashion.
These are the general reasons for using nsURIs to refer to metamodels

[JanWittler]

Wrapping an nsURI within some "domain" class will not solve the problem of missing type safety, as you can enter whatever nsURI you want into that domain as well. And finally it is again an object to wrap around the EMF metamodel reference, the nsURI, like the VitruvDomains before, only in a more lightweight fashion.

I totally agree with your arguments. The benefit I see with an interface - besides shorter attribute names - was the possibility to have a centralized documentation (like how to retrieve nsURIs or what they represent). If using a data class, we could even implement some validation to the URIs. However, these are not the strongest arguments to motivate a refactoring. Additionally, as I'm coming from the Swift language domain where interfaces are far more lightweight, maybe I am a bit biased on the overhead of such an additional interface.
Therefore, I am fine with sticking to the current solution.

[HeikoKlare]

Regarding the namespace URIs: I agree that encapsulating the URIs makes sense. I've proposed a Metamodel class in 261b0ef that encapsulates the namespace URIs of a metamodel. Is this like you have expected? Maybe we can have a better name than the generic Metamodel, but I think that encapsulating a namespace URI is not specific to a "change" and the word "domain" is quite overloaded in Vitruv, which is why I did not use the term ChangeDomain, but we can of course discuss that.

[JanWittler]

Yes, the encapsulating is as I would have expected it.
Regarding the naming: I also think that metamodel is suboptimal, as the class itself does not model anything or contain model elements.
I was thinking about what we really want to express with the class. The nsURIs are the location of the metamodel of the domain. The class itself has no actual functionality but serves as a wrapper. Regarding overloading of the "domain" word, are there other concepts than the VitruvDomain?

I was thinking of DomainDescriptor / DomainDescription or similar? And if we want to be precise we could name the uri attribute then metamodelNsUris.

[HeikoKlare]

There are no other concepts except for the VitruvDomain, but the main purpose for calling it a domain was that it contains (a) metamodel(s) and, in particular, additional information around it. In this case, however, the class does only describe a metamodel and does nor provide addition domain information.
Calling it a "descriptor" or "description" makes sense. Why not call it something like MetamodelDescriptor?

[JanWittler]

Looks good!
I only added some minor comments regarding documentation.