Closed AaronGreenhouse closed 5 years ago
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
D
as the value for the attribute type
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.
Created WIKI page for this: internal wiki page
Created simple a placeholder view in org.osate.ui.views.ClassifierInfoView
. Added the view to the AADL perspective.
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
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:
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.
QUICK NOTE: Flesh this out later on the wiki page... Double-clicking on htings in the view should open editors, etc.
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.
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.
Component types are done. The rest should be easy now. Still not happy with the labels.
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.
Current status summary:
To do
Maybe
How should the members be sorted?
Member groups should be sorted by syntactic order (already done), and alphabetically within each group.
Should have a "Link to Editor" option, where just selecting an item jumps the editor.
Don't forget HELP text
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:
Added double-click to the member tree
Looking at PropertySheetPage
for guidance on link-to-editor
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.
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.
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.
Fixed the "inverse of" label.
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