search

vitruv-tools / Vitruv

View-based Development and Model Consistency Framework
http://vitruv.tools
Eclipse Public License 1.0
14 stars 19 forks source link

Should Correspondences Be Monitored for Changes? #405

Closed jGleitz closed 3 years ago

jGleitz commented 3 years ago

We currently register the CorrespondenceModel in the monitored resource set of the VSUM, meaning that all correspondences get UUIDs and are monitored for changes. This obviously was a conscious design decision, but I wonder why.

  1. I can’t imagine a consistency relation that would require reacting to correspondences being created, removed, or changed. I would consider it bad practice to react on those events.
  2. Monitoring correspondences and assigning UUIDs for them takes time.
  3. Correspondences take up a significant portion of the UUID repository (up to 50%), so they additionally slow down lookups for proper model elements.

In a quick test, I loaded the CorrespondenceModel in a separate resource set, so that no changes were monitored for it and no UUIDs were assigned. I did not notice anything breaking.

So unless there is a strong conceptual argument for monitoring correspondences, I’d propose to stop doing it.

jGleitz commented 3 years ago

Note also that ChangePropagatorImpl has a method for filtering out correspondence changes. This might be another indication that we generally don’t want to have changes for correspondences.

HeikoKlare commented 3 years ago

I agree to all presented arguments and I am not sure why we started to record changes of correspondences. More important than whether the consistency mechanisms want to react to correspondence changes or not (and I absolutely agree that they should not do that) is, from my point of view, the question whether correspondence changes have to be monitored to reproduce a state of the models by just executing the monitored changes. And in that regard I would assume the original changes plus the given user interaction decisions to be sufficient for reproducing any state by applying changes and executing transformations again, which then creates the correspondences (as well as the consequential changes). Thus, also from that point of view, monitoring correspondence changes should not be necessary.

Just as a guess: The correspondence model stored EObjects rather than (UU|TU)IDs some years ago. Therefore, it had to be placed in the same resource set as the EObjects in the monitored resource linked by the correspondences. We could have started monitoring only for non-correspondence resources, but the monitor worked differently as well and that may have led us to the current solution. Please note that I don't want to justify any aspect of the implemenation. I just try to recap how we came to the current implementation to, in the best case, conclude that the correspondence model was only monitored by accident or because of technical limitations but not by conceptual intent.

jGleitz commented 3 years ago

Your theory sounds quite plausible. It also supported by the fact that nothing broke when I moved the correspondence model to another ResourceSet. There wasn’t even a small, dumb thing I had to change. Everything just continued working.