[FEAT] CasePathResolver: categorize the elements returned in the inferred path

[tbouffard]

DISCLAIMER: this issue describes path computation for a single instance/case only. So the implementation will go to the CasePathResolver class as it differs from PathResolver which is a generic implementation that both deals with single instance or all instances of a process.

We have several use cases where we want to categorize the elements in the computed path

• [FEAT] CasePathResolver: handle "forward lonely edge" from an exclusive gateway targeting a merge exclusive gateway #10, [FEAT] CasePathResolver: detect start/end event in "lonely edge" branch #13, [FEAT] CasePathResolver: handle "backward lonely edge" with exclusive gateways #14: candidate but not part of the path. We could have an option to decide whether we want such elements to be part of the returned path
• provided
  • completed ([FEAT] CasePathResolver: add a method that returns the "full path" i.e compute both Shapes and Edges #22)
  • pending ([FEAT] CasePathResolver: distinguish completed and pending elements passed as input parameters to infer more flows/edges in the path #16)
• inferred/computed:
  • [FEAT] CasePathResolver: distinguish completed and pending elements passed as input parameters to infer more flows/edges in the path #16
  • [FEAT] CasePathResolver: add a method that returns the "full path" i.e compute both Shapes and Edges #22
• candidate: when there is no way to know. Returning such elements could be enabled by setting an option
  • [FEAT] CasePathResolver: handle "forward lonely edge" from an exclusive gateway targeting a merge exclusive gateway #10
  • [FEAT] CasePathResolver: detect start/end event in "lonely edge" branch #13
  • [FEAT] CasePathResolver: handle "backward lonely edge" with exclusive gateways #14

Note: Validate the types of the input parameter and the returned value. The initial proposal is available in #142. If something changes, please describe it here. See also #16.