Logistic - Casi d'uso reali - BPGEN - Uno strumento per la generazione di diagrammi BPMN

5.2 Casi d'uso reali

5.2.5 Logistic

Concludiamo con un ultimo esempio di collaborazione, presente a pagina 318 della documentazione uciale [1], inerente la logistica. Nel diagramma avremo 4 attori, Supplier, Retailer, Shipper, Consignee. Il Supplier richiede delle variazioni, per ordini già pianicati, al Retailer. Il Retailer risponde con le possibili variazioni. Il Supplier dialoga quindi con Shipper e Consignee sulle possibili variazioni nella spedizione. Conseguentemente, il Retailer interagisce con Consignee e Supplier

per le conferme nali.

Deniamo le espressioni che rappresentano i processi di ognuno degli attori e l'espressione che rappresenta la collaborazione, considerando il processo Shipper come quello principale che da avvio alla collaborazione. In gura 5.8 riportiamo il diagramma di collaborazione completo.

P< name : Supplier > :=

t< name : SendPlannerOrderVariation , type : send > ; t< name : ReceiveOrderVariation , type : receive > ;

t< name : ReceiveDeliverCheckpointRequest , type : receive > ; (

t< name : SendShipmentPlanVariationS , type : send > ; t< name : ReceiveProposedPlanS , type : receive > +

t< name : SendDeliveryPlanVariationC , type : send > ; t< name : ReceiveProoposedPlanC , type : receive > ) ;

t< name : SendUpdatePO , type : send > ;

t< name : ReceivePOModification , type : receive > ; t< name : ReceivePOSchedule , type : receive > ; t< name : SendFinalizeSchedule , type : send > .

P< name : Retailer > :=

t< name : ReceivePlannerOrderVariation , type : receive > ; t< name : SendOrderVariation , type : send > ;

t< name : SendDeliverCheckpointRequest , type : Send > ; t< name : ReceiveUpdatePO , type : receive > ;

t< name : SendPOModification , type : send > ; t< name : SendConfirmationSchedule , type : send > ; t< name : ReceiveConfirmationReceived , type : Receive > ; t< name : SendPOSchedule , type : send > ;

t< name : ReceiveFinalizeSchedule , type : receive > .

t< name : ReceiveShipmentPlanVariationS , type : receive > ; t< name : SendProposedPlanS , type : send >

P< name : Consignee > :=

t< name : ReceiveDeliveryPlanVariationC , type : receive > ; t< name : SendProoposedPlanC , type : send > ;

t< name : ReceiveConfirmationSchedule , type : receive > ; t< name : SendConfirmationReceived , type : send >

C< name : Logistic > :=

P< name : Supplier , type : start , message :

SendPlannerOrderVariation_ReceivePlannerOrderVariation - SendShipmentPlanVariationS_ReceiveShipmentPlanVariationS - SendDeliveryPlanVariationC_ReceiveDeliveryPlanVariationC - SendUpdatePO_ReceiveUpdatePO - SendFinalizeSchedule_ReceiveFinalizeSchedule - > &

P< name : Retailer , message :

SendOrderVariation_ReceiveOrderVariation - SendDeliverCheckpointRequest_ReceiveDeliverCheckpointRequest - SendPOModification_ReceivePOModification - SendConfirmationSchedule_ReceiveConfirmationSchedule - SendPOSchedule_ReceivePOSchedule - > &

P< name : Shipper , message :

SendProposedPlanS_ReceiveProposedPlanS - >

P< name : Consignee , message :

SendProoposedPlanC_ReceiveProoposedPlanC -

SendConfirmationReceived_ReceiveConfirmationReceived - >

Nonostante la complessità della collaborazione, siamo riusciti a rappresentarla con la sintassi denita per il nostro motore, costruendo prima i diagrammi dei singoli processi.

Si noti che, per quanto precedentemente discusso nel capitolo 4, il diagramma della collaborazione risulta di più dicile consultazione a causa del posizionamento degli elementi. In questi casi è comunque possibile, su un tool di sviluppo graco, spo- stare i componenti per aumentarne le distanze, senza però perdere le connessioni costruite correttamente in fase di realizzazione del diagramma.

Capitolo 6

CONCLUSIONI

La modellazione mediante notazione BPMN viene realizzata allo scopo di ren- dere chiara e comprensibile la modalità di funzionamento dei processi aziendali all'interno di un'azienda. I processi di business sono generalmente espressi su tool graci che permettano di denire procedure e ussi con simboli chiari, ben deniti e di facile comprensione. In questo modo è possibile sia standardizzare la condivisio- ne di ussi e procedure intra-aziendali, sia permettere una migliore comunicazione degli scambi transazionali tra più aziende.

La notazione graca è accompagnata da un modello che ne permetta la denizione semantica: ogni elemento di uno schema graco è infatti rappresentato da attributi e relazioni con altri oggetti, che possono essere deniti mediante la notazione XML.

La denizione XML risulta di notevole importanza se consideriamo che un tool graco può essere specico per piattaforma mentre l'espressione di un processo mediante XML può garantire la totale portabilità fra sistemi totalmente diversi, denendo sia il modello, sia la costruzione del diagramma.

Il lavoro svolto partiva dalla complessità e dalla verbosità della sintassi XML per realizzare uno strumento che permetta di generare in maniera automatica, mediante espressioni algebriche e un linguaggio con sintassi semplicata, processi di business e collaborazioni, garantendone la portabilità su più piattaforme. La notazione XML, per denire un processo di business, richiede infatti di specicare due componenti fondamentali:

il modello; il diagramma.

La denizione del modello fornisce una rappresentazione semantica del processo di business, che risulta tuttavia poco utilizzabile in ambito di studio e condivisio- ne, oltre a violare alcuni dei punti su cui si basa BPMN, con la sua semplicità e immediatezza. Per poter essere visualizzato su un qualsiasi tool graco, il documento XML necessità di una parte di rappresentazione graca di tutti gli elementi deniti nel modello.

Analizzando nel dettaglio la struttura del modello e del diagramma, abbiamo realizzato uno strumento che, partendo da scelte ben denite, ci ha permesso con simboli e operazioni algebriche di denire processi completi e ben strutturati.

Abbiamo vericato come un processo denito da poche righe possa essere importato su diversi software di modellazione (Camunda, Yaoqiang) e diverse piattaforme.

Nello svolgimento del lavoro abbiamo riscontrato problemi legati alla costruzione dell'xml, che hanno reso necessaria la creazione di una struttura ad albero degli oggetti inseriti, per convertire un'espressione "piatta" in una struttura ad oggetti complessa.

Il software realizzato è stato testato su diversi processi completamente nuovi e su modelli preesistenti, creando anche una piccola sorgente dati in cui immagazzi- narli per successivo riutilizzo.

Si può quindi concludere l'ecacia del lavoro proposto per gli obiettivi inizial- mente pressati, a patto che si accettino alcuni compromessi circa gli elementi che è possibile creare e le linee guida per la stesura dell'espressione di rappresentazione del processo.

6.1 Sviluppi Futuri

Si propone di seguito una breve lista di possibili sviluppi futuri.

Aggiunta sottoprocessi, dichiarabili come fatto attualmente per un processo, con possibilità di recupero tramite un solo tag.

Aggiunta di pool e lane.

Esposizione, tramite servizi rest, dei comandi di interazione con il motore. Creazione di una web application per l'interazione con il motore via web. Integrazione del modello realizzato su una pagina web personale, utilizzan-

do strumenti come bpmn.io, per concludere la denizione e visualizzare il processo su un'unica interfaccia utente.

APPENDICE A

Poster BPMN2.0 [5]

Attività Conversazioni

Eventi

Gateways

Diagramma di conversazione

Non definiti: punti di inizio,

cambi di stato, o stati finali.

Messaggio: invio e ricezione

di messaggi

Timer: eventi a tempo.

Errore: attiva o si occupa di

un errore.

Cancel: reagisce a delle

transazioni cancellate o causa una cancellazione.

Compensazione: gestisce o

innesca la compensazione.

Condizionale: reagisce a

condizioni di business cambiate o integra regole di business.

Signal: comunica con più

processi. Lo stesso segnale può essere intercettato più volte.

Multiplo: intercetta uno tra

vari eventi. Gestisce tutti gli eventi definiti.

Link:

Due corrispondenti link events sono uguali ad un flusso sequenziale.

Terminate: causa la fine

immediata di un processo.

Escalation: passa ad un livello

più alto di responsabilità.

Parallelo Multiplo: intercetta

tutti gli eventi.

Inizio Intermedio Fine

C at ch in g T h ro w in g In te rr u zi on e d i so tt op ro ce ss i A lt o li ve ll o N on -i n te rr u zi on e d i so tt op ro ce ss i B ou n d ar y In te rr u p ti n g B ou n d ar y N on - In te rr u p ti n g Flusso sequenziale definisce l’ordine di esecuzione delle attività. Flusso condizionale ha una condizione assegnata che definisce se usare o meno il flusso. Flusso predefinito è il ramo predefinito da scegliere se tutte le altre condizioni vengono valutate come false. Task Transazione Sottoprocesso basato su eventi Call Activity Task di invio Task di ricezione Utente Task manuale Regole di business Service Script Sottoprocesso Loop Esecuzione in parallelo Esecuzione sequenziale ~Ad hoc Compensazione

Una comunicazione definisce un insieme di scambi di messaggi collegati logicamente. Se annotati con un simbolo indicano una comunicazione interna ad un’altra conversazione.

Un forked conversation link connette le comunicazioni e molteplici partecipanti.

Un conversation link connette le comunicazioni ed i partecipanti.

Inclusivo

In caso di splitting, uno o più rami sono attivati. Il flusso va avanti solamente quando l’esecuzione di tutti i rami è terminata.

Complesso

Gestioni di merging e

branching che non sono

gestite da altri gateways.

Esclusivo basato su eventi

All’attivazione di ogni evento successivo, viene avviata una nuova istanza di processo.

Parallelo basato su eventi

All’attivazione di tutti gli eventi successivi, viene avviata una nuova istanza di processo.

Pool

(compresso) Multi Instance Pool (compresso)

Comunicazione

Sub-Conversation

Pool (compresso)

Participant B

L’ ordine degli scambi

di messaggi può essere specificato associando il flusso di messaggi e il flusso sequenziale. Po ol Po ol Pools (Partecipanti) e Lanes(corsie) rappresentano le responsabilità per le attività in un processo. Esse possono essere un’organizzazione, un ruolo o un sistema. Le corsie suddividono le pools o altre corsie gerarchicamente. C or si a Task C or si a Task Po ol Flusso di messaggi rappresenta il flusso di informazioni. Un flusso di messagi può essere unito a pools, attività, o eventi di messaggi. Data Task Input Out- put Data Store

Un Data Object rappresenta le informazioni che attraversano l’intero processo, come ad esempio documenti di business, e-mails, o lettere.

Un Data Store è un luogo dove il processo può leggere oppure scrivere dati, ad esempio un database. Esso si mantiene oltre la durata dell’istanza del processo.

Un Data Input è un input esterno usato all’interno del processo. Può essere letto da un’attività.

Un Data Output è una variabile disponibile come risultato di un intero processo.

Un messaggio è usato per rappresentare i contenuti di una comunicazione tra due partecipanti.

Un Collection Data Object rappresenta una collezione di informazioni, come ad esempio una lista di elementi ordinati.

Pool (compresso) Collaboration Diagram P oo l (e sp an so ) C or si a C or si a Coreografie Diagramma di coreografia Un Task di coreografia rappresenta un’interazione(scambio di messaggi) tra due partecipanti. Task di coreografia Partecipante A Partecipante B Un Processo di

coreografia contiene una

coreografia rifinita con molte interazioni. Il simbolo Multiple

Participants denota un

insieme di partecipanti della stessa tipologia. Swimlanes Collection Sottoprocesso ad hoc Task Task ~ Evento iniziale di messaggio Messaggio di flusso Data Object Sottoprocesso compresso Gateway Escalation Evento finale Evento a tempo intermedio Task di ricezione Allegato Evento a tempo intermedio Link Evento Intermedio Task manuale Evento finale Data Store Evento intermedio Link Evento intermedio Parallelo Multiplo Annotazioni di testo Gruppo Multi Instance Task (Parallel) Evento finale di messaggio Task di invio Gateway parallelo Gateway esclusivo Evento intermedio di errore allegato Evento Finale di segnala zione Call Activity Sottoprocesso Sottoprocesso basato su eventi

Evento iniziale Condizionale Evento finaledi errore

Evento iniziale Evento finale Looped Sub-Process condizione Partecipante A Partecipante C Partecipante B Task di coreografia Partecipante A Partecipante B Task di coreografia Partecipante A Partecipante C Messagio iniziale Messaggio di risposta Task di coreografia Partecipante B Partecipante A

In caso di splitting, il flusso sequenziale viene diretto esattamente verso uno dei rami in uscita. In caso di

merging, il flusso aspetta che un ramo in entrata

arrivi a termine prima di andare avanti.

Esclusivo(xor)

Questo simbolo è sempre seguito da intercettazioni di eventi o tasks di ricezione. Il flusso sequenziale prosegue verso il sucessivo task/evento che accade per primo.

Basato su eventi

Quando viene usato per dividere il flusso sequenziale, tutti i rami in uscita sono attivati simultaneamente. Invece quando viene usato per unire rami paralleli, il flusso aspetta il completamento di tutti i rami in entrata prima di andare avanti.

Parallelo Sottoprocesso di coreografia Partecipante A Partecipante C Partecipante B Un task è un unità di lavoro, cioè il lavoro da

svolgere. Quando si annota con il simbolo indica un sottoprocesso, cioè un’attività che può essere perfezionata.

Una transazione è un insieme di attività che si legano logicamente; essa potrebbe seguire uno specifico protocollo.

Un sottoprocesso basato su eventi si trova all'interno di un processo o sottoprocesso. Si avvia quando il suo evento di inizio viene attivato e può interrompere il processo di livello superiore oppure eseguire in parallelo (senza interruzioni) in base all'evento di inizio.

Una call activity è un contenitore di un sottoprocesso definito globalmente o un task che può essere riusato nel processo attuale.

Simboli per attività

I seguenti simboli indicano il comportamento di esecuzione delle attività:

Tipologie di tasks

Le tipologie specificano la natura dell’azione da eseguire

APPENDICE B

Di seguito gli XSD disponibili sulla pagina di documentazione uciale [2] <? xml version =" 1.0 " encoding ="UTF -8"?>

<xsd : schema elementFormDefault =" qualified " attributeFormDefault =" unqualified "

xmlns =" http :// www . omg . org / spec / BPMN /20100524/ MODEL "

xmlns : xsd =" http :// www .w3. org /2001/ XMLSchema "

xmlns : bpmndi =" http :// www . omg . org / spec / BPMN /20100524/ DI"

targetNamespace =" http :// www . omg . org / spec / BPMN /20100524/ MODEL "> <xsd :import namespace =" http :// www . omg . org / spec / BPMN /20100524/ DI"

schemaLocation =" BPMNDI . xsd "/>

<xsd : element ref =" bpmndi : BPMNDiagram " minOccurs ="0"

maxOccurs =" unbounded "/>

</ xsd : sequence >

<xsd : attribute name =" namespace " type =" xsd : anyURI " use =" required "/> <xsd : attribute name =" location " type =" xsd : string " use =" required "/> <xsd : attribute name =" importType " type =" xsd : anyURI " use =" required "

/> </ xsd : complexType > </ xsd : schema >

<? xml version =" 1.0 " encoding ="UTF -8"?>

<xsd : schema xmlns : xsd =" http :// www .w3. org /2001/ XMLSchema " xmlns : bpmndi =" http :// www . omg . org / spec / BPMN /20100524/ DI" xmlns :dc=" http :// www . omg . org / spec /DD /20100524/ DC" xmlns :di=" http :// www . omg . org / spec /DD /20100524/ DI" targetNamespace =" http :// www . omg . org / spec / BPMN /20100524/ DI" elementFormDefault =" qualified "

attributeFormDefault =" unqualified ">

<xsd :import namespace =" http :// www . omg . org / spec /DD /20100524/ DC"

schemaLocation ="DC. xsd " />

<xsd :import namespace =" http :// www . omg . org / spec /DD /20100524/ DI"

schemaLocation ="DI. xsd " />

<xsd : element ref =" bpmndi : BPMNPlane " /> <xsd : element ref =" bpmndi : BPMNLabelStyle "

maxOccurs =" unbounded " minOccurs ="0" /> </ xsd : sequence >

</ xsd : extension > </ xsd : complexContent > </ xsd : complexType >

<xsd : attribute name =" bpmnElement " type =" xsd : QName "

/> </ xsd : extension > </ xsd : complexContent > </ xsd : complexType >

<xsd : element ref =" bpmndi : BPMNLabel "

minOccurs ="0" /> </ xsd : sequence >

<xsd : attribute name =" bpmnElement " type =" xsd : QName "

</ xsd : extension > </ xsd : complexContent > </ xsd : complexType >

<xsd : element ref =" bpmndi : BPMNLabel "

minOccurs ="0" /> </ xsd : sequence >

<xsd : attribute name =" bpmnElement " type =" xsd : QName "

</ xsd : extension > </ xsd : complexContent > </ xsd : complexType >

<xsd : attribute name =" labelStyle " type =" xsd : QName "

/> </ xsd : extension > </ xsd : complexContent > </ xsd : complexType >

</ xsd : extension > </ xsd : complexContent > </ xsd : complexType >

</ xsd : simpleType >

</ xsd : simpleType > </ xsd : schema >

<? xml version =" 1.0 " encoding ="UTF -8"?>

Nel documento BPGEN - Uno strumento per la generazione di diagrammi BPMN (pagine 151-171)