Swimlane, Pool e processi: errori comuni

Dopo le mie affermazioni sulla mancanza delle collaboration in BPMNComposer mi sono state fatte varie domande sulla reale importanza di una simile assenza, le quali mi hanno fatto ricordare come capiti spesso di vedere abusi ed errori nell'utilizzo delle swimlane e dei pool.



E' possibile utilizzare swimlane al posto di pool o viceversa? NO.
La domanda mi è arrivata in una mail e mi ha rammentato che un primo superficiale approcio a questi due artefatti possa far credere che l'uno sostituisca l'altro.
Invece no. Osserviamo il diagramma qui sotto:

All'interno dello stesso pool vi sono due processi , ma questo va contro le specifiche che l'OMG ha studiato e definito per la BPMN. Se si prova a validare con Bizagi (o altro tool con tale feature) il diagramma infatti si riceverà un errore.
Solo un processo e' consentito, perciò si deve modificare il diagramma come segue:

Se invece andiamo a osservare il diagramma qui sotto , possiamo vedere l'errore contrario: suddividere un unico processo all'interno di una collaboration composta da due pool. Ogni pool DEVE contenere un processo, con relativo start e end event, perciò anche in questo caso la validazione non andrà a buon fine.

Meglio quindi trasformare il diagramma come segue:

Grazie a questi due esempi, parte lo spunto anche per ricordare come tra due pool possano esservi solo delle connection di tipo message flow; ovviamente i message flow non possono essere usati all'interno dello stesso pool dove si devono utilizzare connection di tipo sequence flow. E già che ci siamo ricordiamo anche che un intermediate event non può essere l'inizio per un flusso: questo dovrebbe essere più ovvio visto che il termine intermediate e' esplicativo.