EPC and BPMN modelling rules

Hi, 

A1: yes. EPC's can have multiple start and end events (they need to have at least one).

A2: yes, BPMN models can have multiple start and end events (they need to have at least one).

A3: yes, in BPMN, similar to EPC, a function can only have one incoming and one outgoing connection. 

A4; in case of multiple start events, first a gateway is needed to consolidate these events into one connection that connects to the first function (because of A3).

A5: BPMN does have a complex gateway. I am not sure if this is also available in EPC, I think the closest to this is the RULE gateway, where you can specify the rule for going either one way or the other.

regards, Caspar

A3: By the Spec in BPMN a task may have multiple incoming connections. The semantic is different from joining paths at a gateway. Example: You split the path with a parallel gateway and the two paths eventually join on the task. Then there is no synchronisation done by the task. The task is instantiated twice whenever a process token arrives at it from any path.

A4: The path from a second start event doesn't need to be joined before the "first" function. It may be a start event that skips the first steps and joins the path later with a XOR gateway or with the technique I described in A3 - if you want to allow that.

A5: EPC does offer some more exotic Rule symbols but I have never seen them in use. I would recommend to stick with AND and XOR, maybe also OR. Consider your audience's capabilities if you want to employ more. In EPC the expressiveness of the Rule object lies in the events that follow it.

Thanks for the additions/corrections M. Zschuckelt. I guess my A3 answer (and therefore also A4 answer) are more from a best practice perspective ;-) 

Yes, I totally agree. I just wanted to add it for completeness, since we don't know anything about the context where the question came from.

In fact, my scenario in A3 does not do any harm, if the paths are split with a XOR gateway or the second path comes in from a path originating at a second start event. In these cases there is no second process token. Nonetheless for readability I would always prefer the join on a gateway and obeying strict 1-in-1-out on tasks.

When there is more than one process token (created by parallel or OR gateway) there is no way to re-synchronize the two process branches after they meet asynchronously at the task. One process has effectively become 2 processes.

you're absolutely right. In the end it all depends on the use case for the BPMN process model. The more detailed (and closer to execution) the model becomes, the more need for stricter control of modeling convention I would say. I've learned something again today. Thanks!