Diagram Type Support and Diagram Configuration Improvements

[philip-alldredge]

predefined diagram types that determine the default contents of the diagram.

The ability to customize the model elements included in the diagram was recently added. The next iteration of this capability is to have pre-defined diagram types that will customize the default behavior of this capability. The current thought is that the tool should provide reasonable defaults for a particular diagram type but that the user should be able to customize however desired. The definition of these diagram types are TBD but it is anticipated that user feedback would be helpful. The goal is to look at SysML and UML diagram types and use that as a starting inspiration.

Tasks

• [x] Menu Rework
  • Simplify and organize context menu in graphical editor.
  • Remove commands extension point. Use standard eclipse commands and menus extension points.
• [x] Auto Content Filters
  • [x] Should be interface
    • Needs an id
    • Needs a name
    • Needs method for determining whether a child passes the filter.
    • Needs method to determine if the filter is applicable to a business object context.
  • [x] Diagram configuration dialog should allow selecting multiple filters.
  • [x] Each element should have a set of content filters.
  • [x] Add content filter extension point and provide list to configuration dialog.
  • [x] Add initial set of content filters.
  • [x] Add context menu to adjust contents of element.
    • Enable All Filters
    • Disable All Filters
    • Hide All Contents
    • Enable individual filters
    • Item to open config diagram. Go to the first selected element. Indicator for how many of the selected elements have manual children?
  • [x] Serialization
    • [x] Save content filters to diagram.
    • [x] Convert legacy auto content filters to a set of new filters.
      • Mode transition trigger connections, default annex library, and default annex subclauses will need to be specially handled since there isn't a filter for them. Mode transition triggers connections cause layout issues and annex subclauses and libraries are of limited usefulness.
      • Test opening older diagrams. Graphiti and OGE XML formats.
• [x] Design Document Types and Refine plans for Diagram Type Extension Point
• [x] Create Diagram Type Extension Point
  • [x] Allow defining via extension point.
  • [x] Should Provide:
    • ID
    • Name
    • The default filters for a diagram element
    • Return a set of default properties.
  • [x] Store Diagram Type as part of diagram configuration. All existing diagrams will be considered custom diagrams.
  • [x] Use diagram types to resolve default content filter.
  • [x] Show the Diagram Type in configuration dialog. Don't support changing diagram type.
  • [x] Show the Diagram Type in the select diagram dialog when opening
  • [x] Define Diagram Types based on earlier design. Add additional content filters as needed.
  • [x] If diagram type is not found, should be treated like a custom diagram. However, when saving, the original diagram type ID should be serialized.
• [x] Diagram Creation and Navigation
  • [x] Prompt user for type when creating a new diagram.
  • [x] Prompt user for name when creating a new diagram.
  • [x] Set default AADL properties based on diagram type.
  • [x] Don't prompt to configure diagram after creation. The default configuration combined with the new context menu results in a diagram that needs minimal configuration.
  • [x] Switch default to hiding connection labels. Retain backwards compatibility with existing diagrams.
  • [x] Need way to navigate to component implementation diagram
• [x] Make content filter extension point part of public API.
• [x] Optimization
• [x] Update Documentation
  • Context menu.
  • Configure Diagram Dialog
  • Diagram Types
  • Document that content filters must be immutable/stateless
  • Document behavior of enabling connections when endpoints aren't visible

[philip-alldredge]

Updated task list based on design refinements.

[philip-alldredge]

A previous version of this task described changes to how content filters are treated based on the manual flag. After further consideration, this change was discarded. Content filters need to be used independent of the manual flag. To do otherwise would likely result in cases where the user would manually need to disable the manual flag.

For example:

• Assume a top level component implementation.
• Enable Subcomponents filter
• Enable Modes in one of the subcomponents. This would require setting the manual flag for the subcomponent.
• Disable Subcomponents filter on top level.
• The subcomponent and modes would still be visible. This is not the desired behavior. The desired behavior is that an object is only manual if the user selects it as such. In the current application setting a content filter results in the node being manual and can result in unexpected behavior.

[philip-alldredge]

The planned diagram types are described below.

• All diagram types should represent mode transition triggers as labels. See #244.
• Diagram Types:
  • Custom Diagram.
    • Existing diagrams will be converted to custom diagrams.
    • Filters, except for mode transition trigger labels, are not enabled by default.
  • Package Diagram - Applicable to Packages
  • Classifiers
  • Generalizations
  • Stucture Diagram - Applicable to Classifiers
  • Classifier
  • Type Features
  • Implementation Features
  • Connections
  • Flow Specifications
  • Subcomponents - Only for classifiers/system instances the top level.
  • Mode Diagram - Applicable to Classifiers
  • Mode
  • Mode Transitions
  • NOTE: If such a diagram is made at the package level, the user will need to automatically show a classifier.
  • NOTE: The mode and mode transition filters should be enabled for both classifiers and subcomponents.
  • Processor Binding Diagram - Applicable to Classifiers
  • Actual_Processor_Binding Property.
  • Subcomponents: System, Processor, Virtual Processor, Device, Thread, Thread Group, Process
  • NOTE: This will require additional filters beyond those already created. Investigate whether there needs to be a way to declutter the UI.
  • NOTE: Only the actual_processor_binding property will be enabled by default. The user can customize to show the Allowed_Processor_Binding if desired.

[philip-alldredge]

Optimization is being deferred until later. While profiling, it appears that the most critical hotspots related to performance are not related to the business object providers or content filtering.