osate / osate-ge

Old Graphical editor for OSATE repository, kept for reference
6 stars 3 forks source link

Rendering features in a feature group #157

Closed jjhudak closed 6 years ago

jjhudak commented 8 years ago

A set of features contained in a feature group that contains 'inverse of' another FG are not shown graphically. I don't know if this is a bug, or functions as intended. My expectation is that the features of the FG defined as 'inverse of' should be rendered.
I have kept the default setting/behavior of the Classifier_Match rule. Below are two test cases.

For case #1, showing the graphical view of ControllerDataOut displays the two out data ports. The graphical view of the ControllerDataIn (which is is the 'inverse of' ControllerDataOut, results in an empty rectangular box.

Test case #2 ControllerDataIn2 does, with the ports explicitly defined and the directions defined, does show the ports in the graphical view. -------- Code follows ------------- package test public -- Case #1 ---- feature group ControllerDataOut features MyData1: out data port; MyData2: out data port; end ControllerDataOut;

feature group ControllerDataIn inverse of ControllerDataOut end ControllerDataIn;

---- Case #2 ------------ feature group ControllerDataOut2 features MyData1: out data port; MyData2: out data port; end ControllerDataOut2;

feature group ControllerDataIn2 features MyData1: in data port; MyData2: in data port;
inverse of ControllerDataOut2 end ControllerDataIn2;
end test;

philip-alldredge commented 8 years ago

This is functioning as intended. I'll mark this as a feature request to be considered when implementing future enhancements. The change would be to calculate the inverse of the features and display them whenever inverse of is used and the feature group type does not contain any explicitly defined features.

Is the use case for this for visualization purposes or is there another use case? I'm afraid it would likely be considered a nice-to-have feature but would likely be prioritized behind others currently in the works.

jjhudak commented 8 years ago

Hi Phil: Thanks for the reply. I can understand that there are other more important issues to address, but I am not sure this is a ‘nice to have.’(I don’t think I’d put it at the bottom of the list in any case)….I think that if the semantics of ‘inverse of’ is a short hand way of including the content of the reference object, then one’s expectation upon visualizing the object would be to see the contents. It does display properly when the FG is attached to a system/device, so the need to have it ‘fixed’ as submitted is not that important. Thank you for clarifying that it is working as intended – that sets my expectation. Best regards,

John

From: philip-alldredge [mailto:notifications@github.com] Sent: Thursday, May 19, 2016 5:14 PM To: osate/osate-ge osate-ge@noreply.github.com Cc: John Hudak jhudak@sei.cmu.edu; Author author@noreply.github.com Subject: Re: [osate/osate-ge] Rendering features in a feature group (#157)

This is functioning as intended. I'll mark this as a feature request to be considered when implementing future enhancements. The change would be to calculate the inverse of the features and display them whenever inverse of is used and the feature group type does not contain any explicitly defined features.

Is the use case for this for visualization purposes or is there another use case? I'm afraid it would likely be considered a nice-to-have feature but would likely be prioritized behind others currently in the works.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHubhttps://github.com/osate/osate-ge/issues/157#issuecomment-220448652

philip-alldredge commented 8 years ago

John, Thanks for the feedback. Perhaps nice-to-have was a poor choice of words. I'm including some additional explanation and notes below for you but also as a reference when/if the feature is implemented.

Except for when it is necessary for graphical editing capabilities, the editor usually avoids adding graphical elements for things that aren't part of the declarative model. Additionally, explicitly defining the inverse features graphically is problematic because they need to be in the same order in the AADL specification.

The implementation would need to indicate that the features being displayed aren't actually part of the feature group type declaration. That would be important because adding a feature would result in the implicit features disappearing since the user is specifying the features explicitly.

On this same topic, I believe it would be helpful to indicate to the user that the feature group type has an inverse of clause. This is currently not represented graphically.

philip-alldredge commented 6 years ago

Closing. Won't fix for now.