Automatic model modifications and handling of constraints when mapping elements

Issue #320 new
Cécile Camillieri created an issue

Right now some specific things we do in the model automatically update other elements to ensure that the resulting model is valid. For example, if we make an operation abstract, the containing class will automatically be made abstract if it's not. And we will not be able to switch the class to non-abstract while one of its operations is abstract (a popup is displayed to inform the user).

Unfortunately for now this doesn't take in account the fact that we can map other classes :

  • Create an Aspect A1, containing the abstract class C1.
  • Add an abstract operation to C1.
  • Create an Aspect A2, extend A1.
  • In A2, create a class C2 and map it to C1.

If C2 is not abstract, the woven result will be a non abstract class containing an abstract operations.

We have the exact same problem with public operations. For now when adding a public operation to a non-public class, the class visibility is switched to public. But we can map a non-public class to a public one the same way. So we lose the fact that we want public operations only in public classes.

There are several possibilities to handle this (not exhaustive) :

  • Not allowing the user to map non-abstract class to an abstract class (not sure we want to do this)
  • Automatically update the mapped class abstract. This should be avoided because the user may not want this. Plus he may not see the change and even if he does, he will probably not know why this happened.
  • Add constraints to the validator to inform the user his model is inconsistent. This would allow more consistency in the application.
  • The weaver could also make sure it does make classes abstract if needed.

I think we should try to find a consistent way to handle these kind of things in the app. Making automatic changes is fine as long as it's only in one model but as soon as we can extend and map models, we can't really update automatically anymore because the user won't know what happens. Constraints may solve the problem but in this case if we want to be consistent we probably will have to remove the automatic updates like the ones mentioned above.

Comments (1)

  1. Cécile Camillieri reporter

    updated behavior when trying to change visibility of class. Now checks if any operations are public. This is not good though (see issue #320)

    → <<cset b58d7bfff8de>>

  2. Log in to comment