Classifier information view should show subtype hierarchy

[lwrage]

Summary

The classifier view should also show component types and implementations that extend the classifier that is currently in focus.

Expected and Current Behavior

Currently the view only shows types and implementations that are extended by the classifier in focus, i.e., the supertype hierarchy. Subtypes should also be displayed.

Compare the Java type hierarchy view, which has type hierarchy, supertye hierarchy, and subtype hierarchy.

Environment

• OSATE Version: 2.8.0
• Operating System: all

[AaronGreenhouse]

Constructing the subtype hiearchy rooted at the selected classifier is harder than getting the ancestors: Need to search the workspace for all references to the classifier and then see if the reference is in an extends or implementation clause. Need to identify the following:

• type extension: i.e., system A extends B — type A extends type B — this is a TypeExtension node

• type implementation: i.e., system implementation A.i — implementation A.i implements type A — this is a Realization node

• implementation extension: i.e, system implementation A.i extends C.k — implementation A.i extends C.k (and also implements type A) — this is a ImplementationExtension node

Need to use the class org.osate.search.AadlFinder. See FindUnusedClassifiersAnalysis for example of usage.

[AaronGreenhouse]

At first I thought that this was going to affect the changes made for Issue #2435 (updating when the file is changed). But this is not true. I must always watch the ancestors of the selected classifier for changes to update the RHS of the view. Even when the supertypes are not being shown I still need to watch them.

Not sure how important it is to live update the subtype hierarchy. The Java type hierarchy view does it. But I don't know now to do it efficiently. I'll have to experiment with this later. . . . So I should still branch this from 2435.

[AaronGreenhouse]

I don't need to search the whole workspace. I only need to search the projects that recursively depend on the project in which the root classifier is located. I'm not sure if this really helps or not.

[AaronGreenhouse]

It's probably a bad idea that the AncestorTree nodes hold on to Classifier nodes. Also MemberNode elements hold on to Element and Classifier nodes.

[AaronGreenhouse]

As usual I nearly forgot about feature groups. We also have

• feature group extension: i.e., feature group A extends B — feature group A extends feature group B — this is a GroupExtension node

• feature group inverse: i.e., inverse of B appears in feature group A — feature group A is an inverse of feature group B — this is a direct reference in the FeatureGroupType for A.

[AaronGreenhouse]

N.B. Need to refresh the descendants tree whenever a file in the project dependency tree changes.

[AaronGreenhouse]

Fixed the AncestorTree and the MemberTree to not hold onto EObject nodes.

[AaronGreenhouse]

Still need to update the resource change handling to work correctly with the descendant tree.

I current have 3 panes: ancestor, descendant, member. Lutz said he would prefer to switch between the ancestor and descendant trees, so I ahve to fix that.

[AaronGreenhouse]

The three-pane classifier information view: Gets kinda cramped on small screens.