Flow and Mode Highlighting Improvements

[philip-alldredge]

highlight flow implementations when there are multiple flow implementations of the same flow specification.

The flow and mode highlighting mechanism needs to be reworked.

Deficiencies:

• The implementation was not designed for multiple implementations of the same flow specification.
• Incomplete support for Flow implementations which implement the same flow spec have the same name. They are currently duplicated in the flow selection list, and highlight different flow implementations. However, it is felt that flow specifications should appear once and selecting a flow spec should highlight all flow implementations with that name.
• Doesn't scale well when many classifiers may be included. Selecting a flow could highlight it in multiple classifiers whether that is desired or not.
• Only supports single mode and single flows.
• Does not have a legend. This is important for user understand-ability and exporting diagrams.
• User interface takes significant screen real-estate and does not integrate well with plans for the UI.
• The highlighted flow is driven by the UI and not part of the diagram. This will cause difficulties when exporting diagrams.

[philip-alldredge]

An earlier implementation plan is described below. This no longer reflects the current thinking but is left here for discussion and consideration.

Description

The plan is to add a tab in the properties view which will allow selecting modes and flows for individual model elements. The tool would process these selections and assign colors and generate a legend. Selected flows and modes will be stored in the diagram so that the diagram could be exported with highlighting intact. The capability would be important for any sort of Javadoc like capability that wanted to export diagrams.

Implementation Thoughts

Need new system for flow impl and ETEF. Store in diagram. Automatically assigned colors for combinations of highlighters. Generate legend. Are these diagram elements? If so, they are different from any other. What is the bare minimum a diagram element must have? May not be appropriate for the "All" filter. Modes are already in the diagram. Difference between highlighting things in mode and the modes themselves. Could be a diagram element internally but treated differently in the UI? When highlighting a flow impl and etef, need to highlight references flow implementations, ETEF... What if they are selected too? Combination?

• Create unique names for flow implementations that have identical names. Add suffix? test_flow, test_flow#2, test_flow#3?

[philip-alldredge]

Plan

Below is a list of capabilities. This is equivalent to the previous plan. However the following list has been prioritized based on what is felt to be the most important capabilities. The current resource allocation only considers the need for supporting multiple flow implementations of the same flow specification and there may not be resources to implement all desired capabilities. The implementation should be one such that is can be implemented incrementally.

Desired Capabilities

• Support for multiple flow implementations of the same flow implementation.
• Legend support. Under the following cases:
  • While viewing the diagram in the editor.
  • After export to bitmap or vector formats. Important for exporting as part of a javadoc like capability.
  • When printing.
• Selecting multiple mode, flow implementations, and end to end flow specifications for highlighting. This would be done by moving the highlighting options into a property tab which is poulated by two property sections:
  • A property section for when a classifier is selected.
  • A property section when a mode is selected.
• When multiple items are selected, the user should be able distinguish the combinations that are being used.

[philip-alldredge]

Implementation Thoughts

• Update the existing flow and mode highlighting UI to support selecting specific flow implementations.
  • Allow selecting specific flow specification, end to end flow specification, mode, and mode transition from any specific classifier or sub-component.
  • This selection should be a combination of the containing diagram element and the selected mode/flow.
  • Selecting a flow specification will highlight all flow implementations for that flow specification/diagram element combination.
  • Only flow specifications which have an implementation should appear in the list.
  • Flow specification highlighting should include referenced features.
  • The implementations of flow specifications referenced in flow implementations should also be highlighted.
  • Modes and flows for a diagram element should not be in the lists unless the diagram element contains at least one applicable element. For this purpose would be modal elements for modes and elements that can be part of a flow for flows.
  • Show an asertisk in the flow item list for flows which have segments which are not in the diagram.
  • Derived modes should be supported.
  • Implementation Note: Relative references may be useful for comparing model elements.
• Implement the capability for plugins to override the styles of graphical elements. The exact design of this implementation is TBD. Should the plugin be called for every diagram element or simply be called to refresh things for the entire diagram? At this point is is considered that a diagram wide approach would be preferable. This would avoid lots of dependency injection calls and allows for more flexible implementations on the plugin side.
  • The appearance property section should indicate that aspect of the style is currently being overriden programatically. Need to indicate which ones.
  • Optional/Later: Consider implementing current capability of styling elements which are not owned by the graphical container differently using this system. In this case the system should support specifying when to override. User styles should override that sort of default styling.
  • Migrate the existing mode and flow highlighting using the style override system.
  • Migrate any tool classes to use the new system as appropriate. For simplicity on the tool implementation side, the tools may need to use something like the current coloring service instead of using the capability directly. Remove unused code.
• Implement a property system that allow plugins to add arbitrary data to the diagram nodes. The exact implementation is TBD, but some thoughts are included below.
  • A way of marking it as a relative reference will be needed. Canonical references may be needed as well? Such references should be updated automatically during the refactoring. They will need to be indexed.
  • Should properties form a tree structure? NO? It complicates the implementation. Ownership could be denoted by a property group or by a prefix. If properties are stored in a hash map, then performance should be acceptable either way and a tree structure would likely be more overhead.
  • There will likely be a need for native lists at some point. Plugins encoding the information for a list is not acceptable because lists of references will need to processed by the diagram service for refactoring. List capability could be added later as long as the serialization to file is done in such a way to allow forward compatibility.
  • The flow and mode highlighting system will need to be updated to use properties to persist information.
• Implement Legending Support
  • Style system should have a way of reporting what colors mean. Gradients may be appropriate for things where the shade of the color has meaning.
  • While in editor. This could be a toggleable window that shows the colors.
  • Printed
  • Bitmap and SVG Export
• Implement Support for Selecting Multiple Modes/Flows/Mode Transitions
  • Consider whether migration to GEF5 will be done soon. If that is the case, it might be advisable to switch to repeating gradients to avoid needing to using unique colors for combinations.
  • Update UI to add property section to allow selecting elements for highlight.
  • Update properties in a backwards compatible way.

The proposed implementation has the benefits of being modular and allowing use by other plugins. It does not require persisting data but supports it for plugins where that is desired. It should be feasible to implement incrementally as resources allow.

[philip-alldredge]

Mode Highlighting Behavior

• Non Modal Children of the mode container will be highlighted.
• Modal children of the mode container will be highlighted if they are in the same mode.
• If a highlighted child does not have required modes, then highlight all children irrespective of their in modes clauses. The reasoning is that since the child is in the mode, all of it's children are in the mode even though they may be optionally available due to their children's independent modes. This should be recursive.
• If a highlighted child has requires modes, then highlight its children with rules above. Substituting the parent mode with the child mode for highlighting purposes. In accordance with the AADL standard, mode bindings are implicit if the names match. This should be recursive.

[philip-alldredge]

88adeb7 implements support for improved handling for modes and flows. The commit introduces handling of the case where there are multiple flow implementations of the same specification. Highlighting is limited to a specific context which prevents unintended flows or modes from being highlighted. The behavior of flows when there are multiple flow implementations is to highlight all flows for the selected specifications.

Part of the desired capability was not implemented. These capabilities will be tracked in #251.