[FEAT] CasePathResolver: detect start/end event

[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.

Is your feature request related to a problem? Please describe.

There are several situations where the start/end event are modeled in the BPMN diagram and related execution data aren't available at runtime.
This is something which is typical with Process Discovery.

Describe the solution you'd like

Be able to infer the start/end event in the path in "simple" cases i.e. when the list of provided reference elements contains an element right before/after the event.
Such detection should be enabled by passing an option and should be disabled by default. Possible names of for the new option (non exhaustive list, feel free to add new proposals. To be discussed and the final decision should be explicitly mentioned here along with all proposals considered, in particular the usage of singular or plural as part of #23):

• inferStartAndEndEvents
• inferTerminalEvents

More complex use cases will be handled through a dedicated issue. See #13.

Single start/end events

flowchart LR
    A((start 1)) --> task1 --> 
    task2-->  x((end))

Loading

Several start events with BPMN elements in the same branch

flowchart LR
    A((start 1)) --> task1 --> gateway{X}
    X((start 2))  --> task2--> gateway
    gateway --> task(task) --> x((end))

Loading

Several end events with BPMN elements in the same branch

flowchart LR
    A((start 1)) --> task --> 
    gateway{X} --> task2(task2) --> end1((end 1))
    gateway  -->task3(task3) -->  end2((end 2))

Loading

Possible implementations

• retrieve all start and end events from the model
• ignore those which are already executed
• to detect an executed start event: check if one of its following elements have been executed, if so, consider it as executed
• for end event, do the same by considering the previous elements

Interactions with #145

Notes: the following use cases require dedicated tests. If this issue is implemented prior to #145, create a dedicated issue to manage this specific use case. Otherwise, implement it as part of this issue.

Find start and end events that can be deduced from pending/completed elements.

• For start events, they can have incoming message flows. We should probably not consider them, as we are only considering following elements in [FEAT] CasePathResolver: Allow to infer pending elements #145, not predecessors.
• For end events, they can have outgoing message flows. The can target a start even, an activity, an intermediate catch event or a participant/pool.

For inferred pending participant/pool, we should decide if we return then or not. We could have an option to infer such an element.