Add graphical editing support for prototypes

[lwrage]

[philip-alldredge]

@lwrage by graphical editing support, is it intended to provide a diagram notation for editing prototypes or just display prototypes on the diagram,potentially textually, and provide a GUI such as a property section for editing it?

[philip-alldredge]

Support: should include the ability to edit prototypes and prototype bindings via the properties view. The graphical view should reflect the affect of prototype bindings.

• Support editing prototype and prototype refinements in component types, component implementations, and feature group types via the properties view.
  • component
  • feature group
  • feature
• Support prototype bindings for the following cases via the properties view/dialogs:
  • classifiers
  • subcomponent and subcomponent refinements. Should be supported as part of selecting classifier?
  • prototype actuals. Should be supported as part of selecting classifier?
• Support referencing prototypes via the properties view/selection dialogs.
  • Abstract prototype feature
  • Feature classifier
  • Subcomponents
  • Called subprogram
• Graphical views should reflect the prototypes. Partial support is already available. Need to review and ensure all cases for which editing is supported work properly. That is if a feature or subcomponent references a prototype, it should be represented as referencing the bound type.
• Update user guide

Prototype bindings will not be supported in array element implementation lists. In general, Array element implementation lists are not supported in OSATE or the OSATE graphical editor.

[philip-alldredge]

@lwrage is the above implementation in line with your original intent? This proposed initial implementation focuses on being able to edit and work with prototypes but not really representing the bindings in the diagrams. It seems to me that representing the bindings in the diagrams would clutter the diagram. However, the diagrams will adapt based on the prototype bindings.

[lwrage]

Looks good to me.

[philip-alldredge]

I went down the rabbit hole of protoype resolution. I was heading down resolving prototypes up the hierarchy. However, upon further consideration, this seems needless and a bit counter productive. The graphical editor should only apply prototype bindings to the extent that the text editor supports them. It should not be equivalent to the instance model. Such application of bindings would result in ports that couldn't actually be referenced in the instance model.

In other words, when working with the declarative model, the graphical editor should only apply model elements necessary for full editing functionality. It should not show model elements that could not be legally referenced in connections, etc.

[philip-alldredge]

@lwrage should the square bracket/component classifier list prototypes be supported? I believe they are called arrays in the metamodel. From reading the standard it seems related to subcomponents arrays with elements with different types of classifiers which isn't supported in instantiation.

Component prototypes declared with square brackets specify that they expect a list of component classifiers. These prototypes can only be referenced in subcomponent array declarations. The component classifier list supplies the classifiers for each of the elements in the component array.

[lwrage]

@philip-alldredge There's no need to support array prototypes at this time.