AADL Classifier View

[AaronGreenhouse]

Need a view that shows all the members of a classifier (type/impl/feature group). This is like a flattened view of the classifier, showing which ancestor a member is inherited from, whether it is refined, etc. Also shows the complete ancestor hierarchy of the classifier.

EMF has the EClass Information view that does something similar. Not sure if it is necessary to steal code from this view, but it's good for inspiration.

child of #1371

[AaronGreenhouse]

Lutz wondered if the following was (1) legal and (2) actually worked in OSATE:

package MyPackage
public
	system C	
	end C;
	
	system D extends C
	end D;
	
	system implementation C.i
	end C.i;
	
	system implementation D.i extends C.i
	end D.i;
end MyPackage;

The answer is (1) yes, and (2) yes.

The ComponentImplementation object for D.i has

• A reference to D as the value for the attribute type
• A reference to C.i as the value for the attribute extended

This is as expected.

This example came up in a discussion about wither AADL has a the "diamond problem" of multiple inheritance. It does not seem too. Really there are two extension hierarchies for a component implementation, one for the type and one for the implementation. They can be displayed separately within the proposed view.

[AaronGreenhouse]

Created WIKI page for this: internal wiki page

[AaronGreenhouse]

Created simple a placeholder view in org.osate.ui.views.ClassifierInfoView . Added the view to the AADL perspective.

[AaronGreenhouse]

Got the hierarchy portion finished. Deferring to the UiUtil.getModelElementLabelProvider() label provider to get icons and element labels.

Been testing with the package

package Types
public
	abstract A
	end A;
	
	abstract B extends A
	end B;
	
	system C extends B
	end C;
	
	system D extends C
	end D;
	
	process P extends B
	end P;
	
	process Q extends P
	end Q;
	
	system implementation C.i1
	end C.i1;
	
	system implementation C.i2 extends C.i1
	end C.i2;
	
	system implementation D.i1 extends C.i2
	end D.i1;
	
	feature group FG1
	end FG1;
	
	feature group FG2 extends FG1
	end FG2;
	
	feature group FG3 extends FG2
	end FG3;
	
	feature group FG4 extends FG2
	end FG4;
end Types;

Here is the hierarchy for the component implementation D.i1:

and the feature group FG3

[AaronGreenhouse]

Lutz suggested seeing what things look like without the "implements" and "extends" prefixs, and changing the extended system implementation to come before the type. I think it looks like a confusing mess:

[AaronGreenhouse]

the classiifer members section of the view now works for the features and prototype declared in a component type. The code needs to made more generic so that I can eaisly add the other member sections and expand to classifier impementations and feature groups.

Also, I need to figure out how to unparse things to get better labels for the members. Lutz says that Xtext calls the unparser a serializer.

[AaronGreenhouse]

QUICK NOTE: Flesh this out later on the wiki page... Double-clicking on htings in the view should open editors, etc.

[AaronGreenhouse]

Added flows to the component type display. Need to generalize the source code now.

Started playing with the serializer, but I don't know how to turn of indenting and the unparsing of comments.

[AaronGreenhouse]

Wanted to use the Serializer to unparse the member declarations for the labels, but that isn't going to work. It includes indenting and comments. Don't really want to unparse myself, but the label provider I am using right now doesn't give as much information as I would like.

[AaronGreenhouse]

Component types are done. The rest should be easy now. Still not happy with the labels.

[AaronGreenhouse]

Started working on Component Implementations.

I had to fix a problem with ComponenentImplementationImpl.getAllPrototypes(): when a prototype from a component type is refined in a later component implementation, the refined declaration was not removed from the list. This occurred because the prototypes from the component type hierarchy were processed after those of the component implementation hierarchy. I swapped the order in which types and implementations are processed.

[AaronGreenhouse]

Current status summary:

• Ancestor view is complete
• Component Type is done
• Component Implementation needs end to end flows and call sequenences
• Feature Group Type is not done at all
  • Tricky part (?) showing the inferred features for inverse feature groups

To do

• link with the editor
• need better labels. Want to use the unparser/serializer for this, but its not good for that

Maybe

• add multiple views panes: see the Properties view.

[AaronGreenhouse]

How should the members be sorted?

[AaronGreenhouse]

Member groups should be sorted by syntactic order (already done), and alphabetically within each group.

[AaronGreenhouse]

Should have a "Link to Editor" option, where just selecting an item jumps the editor.

[AaronGreenhouse]

Don't forget HELP text

[AaronGreenhouse]

Updated UiUtil to have the new methods openDeclarativeModelElement() and openDeclarativeModelElementAsJob() to replace gotoDeclarativeModelElement() which doesn't work very well. It should probably be made @deprecated and replaced.

Still to do:

• double-click to open in the member tree
• add "link to editor"
• fix the members in the feature group types, getting duplicated, and not sure where the problem lies.
• help docs

[AaronGreenhouse]

Added double-click to the member tree

[AaronGreenhouse]

Looking at PropertySheetPage for guidance on link-to-editor

[AaronGreenhouse]

Synchronize with editor functionality added. Toolbar action in place. Stole icons from eclipse.

Need to figure out now why there are duplicate features in the feature group types.

[AaronGreenhouse]

Alphabetical sorting of members is the wrong thing to do for feature group types because order matters. Furthermore, refined features must be put in the right position as well.

[AaronGreenhouse]

Fixed FeatureGroupTypeImpl.getAllFeatures() to only add features from each type once, and to replace refined features in place in the list so that the order of features is maintained.

Changed the view to not sort the features of the feature group.

Need to fix the insertion of the "inverse of" label, which may be difficult.

[AaronGreenhouse]

Fixed the "inverse of" label.