Next Gen Expander Control

Runtime Executors in the Hinge

The hinge nsx-prime serves as an interface to the outside world for expansion, harvesting, and code import. In essence, invoking those interfaces will let nsx-prime:

  • retrieve both the analysis model and the various technology settings from the Prime Radiant or XML

  • submit the model and settings for expansion/harvesting/importing to the Expanders

Currently, nsx-prime invokes the expanders at the level of components and application for expansion and harvesting, e.g. ApplicationSkeletonExpander and FullComponentExpander, and at the level of individual elements for the code import. For the Next Gen control, it is preferred to

  • expose the API at the level of the full application, e.g. FullApplicationExpander, and to provide partial expansion through options (the existing FullComponentExpander could be supported through a thin wrapper selecting the option of expanding a single component)

  • pass the entire model and settings though a composite class spanning the entire graph, containing both the model, e.g. ApplicationComposite, and the technology settings, e.g. ApplicationExpansionContext.

Hierarchical Expanders for Sequencing

Hierarchical or non-leaf expanders, such as a FullComponentExpander or TotalTaskElementExpander, are responsible to sequence or invoke expanders at the hierarchical level below. Besides the fact that they should be named consistently, i.e. Full vs. Total, the following tasks need to be specified.

  • The retrieval of the list of - hierarchical or leaf - expanders they need to invoke. This should be specified in a declarative way, e.g. in YAML or preferably XML files.

    • A selector class should filter the list by matching the declarative list, containing the technology of the various expanders, with the technology settings of the ApplicationExpansionContext.
  • The actual invocation of the various expanders of the list.

    • An appropriate <Node>ExpansionContext should be passed to the expanders below, consisting of the <Node>Composite class representing the model, and the ApplicationExpansionContext

Individual Expanders Writing Artifacts

Individual or leaf expanders, such as TaskElementAgentExpander, expand or write an artifact or file. Besides the corresponding string template and/or subtemplates, the following tasks need to be specified.

  • The mapping of the various relevant values of the <Node>ExpansionContext graph to the individual properties used by the string template. As described, this should be performed in a declarative way, by a <Element><Artifact>Mapping XML file.

  • The construction of the full pathname of the artifact. A path assembler class should construct this pathname based on the properties of the artifact and of the settings in the <Node>ExpansionContext.

All expanders should implement one or more common interfaces. As every expander should be able to perform harvesting or code importing, it seems that a single interface could be sufficient. Moreover, we currently see no reason to make a difference between expanders belonging to the different elements, such as DataElementExpanders or TaskElementExpanders. Therefore, all expanders could implement a NormalizedExpander interface, providing:

  • expand : to expand the artifact
  • harvest : to harvest the custom code
  • inject : to inject the custom code
  • assess : to assess the artifact code (retrieve pathname and size of expanded and custom code)