Show hierarchy of implementation classes

[Matthias Schoettle]

When importing an implementation class, which a) has a superclass or b) is a superclass of an existing implementation class, no hierarchy is shown.

It is important to have this information, because both might have different operations that need to be called. I am not sure, though, how this interferes with the fact that right now importing operations allows to import operations from superclasses as well.

For example: Importing java.util.Set and then java.util.HashSet (or vice versa) does not show that the latter is implementing the former.

Since it is difficult to obtain subclasses through the Java Reflection API and the usage of the Reflections framework would be quite expensive, I suggest to only consider the existing classes in the structural view:

• For each implementation class, it needs to be checked whether the to-be-imported class is a superclass
• For the to-be-imported class, it needs to be checked whether any existing implementation class is a superclass

Also, the GUI right now does not display inheritance between implementation classes. This is due to the metamodel having the superTypes reference only for classes (not Classifier).

[Matthias Schoettle]

References #279: Updates the metamodel to move the superTypes reference up to Classifier in order to support inheritance between ImplementationClasses.

→ <<cset 62ab233411c8>>

[Matthias Schoettle]

References #279: Adds proper filtering for the Classifier's superType property descriptor.

Specifically:

• ImplementationClasses can only have a super type of the same type
• a Classifier can not have itself as a superType
• the super type must be contained in the same StructuralView/Aspect

→ <<cset 27fe1fa86819>>

[Matthias Schoettle]

References #279: Fixes compile errors due to metamodel change and adds the ability to visualize inheritance between implementation classes. Contrary to a class that has a super type, inheritance between two implementation classes has no handler set to avoid removal of it.

→ <<cset 24b4c8fd088f>>

[Matthias Schoettle]

References #279: Improves and unifies the handling of adding and removal of Class and ImplementationClass.

• Removal of any Classifier is performed by the same operation
• Adding of a Classifier is unified and therefore handles super types in any case
• When a Classifier is deleted, in addition to the superType references from other Classifiers, the deleted Classifier's own superTypes are removed first (this was done by the view previously)

→ <<cset 557798ee9114>>

[Matthias Schoettle]

References #279: Adds the ability to retrieve super classes (extended and implemented) of Java classes. On import of a class, if a super type was already imported (i.e., an implementation class exists), the hierarchy will be set accordingly.

Right now, this is not done if the class has generics, because we need to ensure that, for example, ArrayList<X> can only implement List<X>. Therefore, in the case of generics, the hierarchy needs to be set once the type parameter is chosen by the user.

Furthermore, subtypes are missing.

→ <<cset a13025331ab7>>

[Matthias Schoettle]

References #279: Adds the ability to find existing (in the structural view) subtypes of a given class name. If that is the case for an implementation class to be created, the superType reference is set accordingly. See parent commit for more information.

→ <<cset c04236efe6be>>

[Matthias Schoettle]

References #279: Adds the ability that once a type parameter is set, all existing implementation classes that are a sub or super type are checked. If the type parameters match, an inheritance link is added accordingly.

→ <<cset 33c3b208f992>>

[Matthias Schoettle]

Merged current state into master in pull request #48. The remaining issue is the proper handling of generics, see https://bitbucket.org/mcgillram/touchram/pull-request/48/general-and-message-view-enhancements/diff#comment-8358120.