Allow abstract superclass to be non-public

[Matthias Schoettle]

It should be possible to have a non-public abstract class with public operations. Right now, when the user attempts to change the visibility back to concern an error message appears.

At the same time, when the abstract class is concern visible and a public operation is added, the class visibility is automatically changed to public as well.

[Nirmal Kanagasabai]

References #480

Removed the checks made for a classifier to be a super class as per the comments received. Also, included the check if a non-public operation's visibility is made public.

→ <<cset a9a99dbd55e3>>

[Arthur Le Saint]

Resolve #480: Abstract class can be non-public with public operations

• An operation visibility does not have any effect on an Abstract class
• OCL rules have been change accordingly

A question remains if the Abstract class should change from concern to public when a public operation is added (unclear)

→ <<cset db95acc3edab>>

[Matthias Schoettle]

A question remains if the Abstract class should change from concern to public when a public operation is added (unclear)

In my opinion it should not. At least in Java you can have a non-public abstract class with public methods. Because the sub-classes will have these public methods in their interface, it works.

We just have to make sure that these public methods can be called.

Would you also be able to add test case(s) for the class controller to cover this?

[Arthur Le Saint]

We just have to make sure that these public methods can be called.

See img to follow the example

I tried to call "getOperationByName(Bclass, sell)" but it didn't work (even when A was public).

I have no idea how to test if it's possible to call an operation or not (even less when it's from a super class). Basically I have not idea how to test anything related to visibility and access..

The closest I got was to access the operations from the super class and check if it's public or not. But that's of little use... This code pass the tests.

public void testConcernAbstractPublicOperationInheritanceUse() {
        Classifier classifier = MessageViewTestUtil.getClassifierByName(aspect, "B");
        Classifier parentClassifier = classifier.getSuperTypes().get(0);

        Operation operationSell = MessageViewTestUtil.getOperationByName(parentClassifier, "sell");
        assertTrue(operationSell.getVisibility().equals(COREVisibilityType.PUBLIC));

        Operation operationBuy = MessageViewTestUtil.getOperationByName(parentClassifier, "buy");
        assertTrue(operationBuy.getVisibility().equals(COREVisibilityType.CONCERN));
    }

Would you have a hint on how to test it? Thanks :)

[Matthias Schoettle]

Sorry, what I meant with testing is what you are fixing in this issue. I.e., the fact that the class visibility is not changed if it is abstract and so on ...

Does that make sense?

For the problem with getOperationByName: That's odd, it should find it. Have you tried debugging the call?

[Arthur Le Saint]

Oh, all right. Awkward, but I get it now.

I'll test if the class visibility is changed as it should now from public to concern (I'll test the others while I'm at it)

I'll try again for getOperationByName, maybe I wasn't doing it well. I didn't try debugging here since it wasn't my main issue.

EDIT: confirmed, class B inherits from superClass A but it's list of operation is null (but the field superTypes matches class A)

[Arthur Le Saint]

Merged in Issues/480-try-nb-2-Allow-abstract-superclass-to-be-non-public (pull request #129)

Resolve #480: Abstract class can be non-public with public operations

→ <<cset d1d6b74e333a>>