Saving an aspect should also save the concern

[Matthias Schoettle]

Saving an aspect and not the concern can lead to inconsistencies, e.g., reuses added or removed (see #216). Even though the user gets asked before closing, the user might not realize that it is necessary to save.

When saving the aspect, the related concern should also be saved (this requires a reference from COREModel to COREConcern [opposite of the existing one for models], which needs to be added).

As discussed in the meeting on 05.03.2015, the following needs to be done:

• rename the "Save" button to "Save Concern" to make it clear to the user what will happen
• add an opposite reference (to models) from COREModel to COREConcern
• add the setting of this reference when "new aspect" is performed (both from the feature and from the side menu in the feature model)
• when performing "Save Concern" the current aspect and the concern both need to be saved
• performing "Save Concern" will save the aspect (like the concern, without the request to provide a file name); unless the aspect has not been saved yet, then a file name needs to be request or the aspect name is used and saved into the concern directory
• it would be good to have a "Save As" when tap-and-holding on the save button that allows to save the aspect somewhere else (without saving the concern I think)

[Matthias Schoettle]

References #271: Updates the generated model and edit code to reflect the change made in the CORE metamodel that adds the opposite reference from COREModel to COREConcern.

→ <<cset 92ea78a7a114>>

[Matthias Schoettle]

References #271: Updated all existing models to have the models and concern references set. Only the current concerns (not the reused copied ones) are updated, because this leads to problems with references to the woven models in message and state views.

→ <<cset 1acded4218dc>>

[Omar Alam]

Setting the opposite reference (to models) from COREModel to COREConcern doesn't always work. For example, if you are inside a concern and generate the woven model it won't belong to any concern.

[Matthias Schoettle]

Yes, the question is if that matters. Is it part of the concern or not? Maybe the backlink should be 0..1. And then whenever we need to get the concern, we must make sure it "exists" (is there).

[Matthias Schoettle]

As stated in a comment in #275, when an action triggers modifications in the concern and another model, the decision of not saving one (the model mainly) can lead to inconsistencies.

For example: Reusing a concern creates a model reuse in the aspect and a reuse in the concern. When the aspect is now closed (and not saved) the concern still contains the reuse but the aspect does not reuse the concern.

Perhaps, when closing an aspect (or any COREModel) and choosing not to save, all changes since the last save should be undone in order to revert to a previous correct state.

This would also allow to not unload an aspect when going back to the concern, which would resolve the following issue: Associate an existing feature with an existing aspect, open the aspect, go back (this unloads the aspect). Now the aspect does not realize the feature anymore, since the resource was unloaded. This leads to an inconsistency (unless the concern is not saved). Unloading could then take place when closing the concern (i.e., unload all models), once #215 is resolved.

[Matthias Schoettle]

Merged into master in pull request #42.

When going back without saving, all changes are discarded, i.e., everything on the command stack is undone until the last time the model was saved. Also, saving an aspect also saves the concern at the same time to keep consistency.