BPGEN - Uno strumento per la generazione di diagrammi BPMN

(1)

DIPARTIMENTO DI INFORMATICA

Corso di Laurea Magistrale in Data Science and Business Informatics

TESI DI LAUREA

BPGEN - UNO STRUMENTO PER LA GENERAZIONE DI

DIAGRAMMI BPMN

Relatore:

Prof. Roberto Bruni

Candidato:

Andrea Lamanna

(2)

Nel corso degli anni, in ambito aziendale, hanno assunto sempre maggiore impor-tanza la denizione ed il controllo dei processi di business. Per modellare questi processi, viene utilizzata la notazione BPMN, diventata lo standard de facto. Que-sta notazione graca, semplice ed intuitiva, permette di specicare in modo chiaro tutte le attività che portano allo svolgimento di un processo aziendale, rendendolo facilmente comprensibile a tutti gli attori coinvolti. I processi di business permet-tono di descrivere sia processi intra-aziendali che extra-aziendali, utilizzando una notazione graca chiaramente denita da speciche standard.

Il nostro studio si è concentrato sulla realizzazione di uno strumento multipiat-taforma, BPGen, che permetta la generazione automatica di processi di business e collaborazioni, espressi nel dialetto dello standard XML per l'interscambio di diagrammi BPMN. In questo modo, i diagrammi generati a partire da semplici espressioni algebriche sono utilizzabili su qualsiasi tool che permetta una notazione graca per denire tutte le speciche di un processo di business.

(3)

Indice

1 INTRODUZIONE 5

1.1 Esempio di processo . . . 7

1.2 Struttura del documento . . . 13

2 BPMN 14 2.1 Modelli di business rappresentabili con BPMN . . . 15

2.2 Gli elementi della notazione BPMN . . . 18

2.2.1 Flow Object . . . 19 2.2.2 Connecting object . . . 28 2.2.3 Swimlanes . . . 29 2.3 Notazione XML . . . 31 2.3.1 Modello . . . 31 2.3.2 Diagramma . . . 34

2.4 Strumenti di supporto alla progettazione BPMN . . . 36

2.5 Riepilogo . . . 38

3 PROGETTAZIONE 39 3.1 Denizione del linguaggio . . . 40

(4)

3.1.1 Sottomodelli . . . 41

3.1.2 Espressioni . . . 42

3.2 Modalità di analisi dell'espressione . . . 52

3.3 Regole e best practice di scrittura . . . 52

3.4 Riepilogo . . . 53

4 REALIZZAZIONE 55 4.1 Strumenti per lo sviluppo . . . 56

4.2 Diagramma delle classi . . . 57

4.2.1 Motore . . . 59

4.2.2 Elementi . . . 60

4.2.3 Errori . . . 61

4.2.4 Utility . . . 61

4.2.5 Launcher . . . 61

4.3 Costruzione dell'albero di oggetti . . . 62

4.3.1 Costruzione Interna . . . 75

4.4 Creazione XML . . . 79

4.4.1 Modello . . . 80

4.4.2 Diagramma . . . 99

4.4.3 Costruzione dell' XML completo . . . 111

4.5 XML per Collaboration . . . 111

4.6 Problemi riscontrati e principali scelte di implementazione . . . 117

4.7 Riepilogo . . . 120

5 TEST E COSTRUZIONE DI CASI D'USO 122 5.1 Test su casi ttizi . . . 123

(5)

5.2 Casi d'uso reali . . . 142

5.2.1 Symmetric Model 2 . . . 142

5.2.2 Shipment Process . . . 144

5.2.3 Selection and recruitment . . . 146

5.2.4 Patient and Doctor . . . 149

5.2.5 Logistic . . . 150

6 CONCLUSIONI 155 6.1 Sviluppi Futuri . . . 157

(6)

Capitolo 1

INTRODUZIONE

La pratica del Business Process Modeling, BPM, nasce fra la ne degli anni '80 e l'inizio degli anni '90, con l'intento di supportare i processi di business uti-lizzando metodologie, tecniche e software per progettare, rilasciare, controllare e analizzare i processi aziendali. Lo scopo principale dell'utilizzo di questa notazione è la rappresentazione, tramite un modello, dei processi produttivi e organizzativi di un'azienda, in modo da poterne analizzare il funzionamento e migliorarne le performance. Le persone principalmente interessate sono:

gli analisti (o business analysts), che hanno il compito di studiare il funzio-namento dell'azienda e dei suoi processi produttivi e organizzativi, crearne il modello ed eseguire su di esso le operazioni di simulazione, raccolta dati e aggiornamento;

i manager, che devono compiere scelte di politica aziendale, in base ai dati forniti loro dagli analisti, per migliorare il modello esistente.

(7)

A partire dagli anni `90, un consorzio di aziende del settore informatico deno-minato Object Management Group (OMG) diede vita alla UML Activity Diagram notation, con l'obiettivo di stabilire gli standard di modellizzazione che vengono utilizzati nella rappresentazione dei sistemi software e dei processi. All'interno del principale linguaggio di modellizzazione software, l' UML (Unied Modeling Lan-guage), l' OMG ha denito l'Activity Diagram quale diagramma avente lo scopo di descrivere il usso di attività che devono essere svolte durante la realizzazione di uno specico processo di business. Nel 2004 l'organizzazione Business Process Management Initiative (BPMI), formata dai maggiori fornitori di software per la modellizzazione dei processi di business, creò una nuova notazione chiamata Busi-ness Process Modeling Notation (BPMN). Inne, nel 2005 avvenne la fusione tra le due organizzazioni, rendendo la nuova struttura responsabile sia dello sviluppo della notazione BPMN, sia del UML Activity Diagram.

Entrambe le notazioni dispongono di un'ampia varietà di simboli, i quali danno la possibilità di rappresentare processi anche molto complessi in maniera talmen-te precisa che i diagrammi possono essere utilizzati per la generazione di codice software (ad esempio in linguaggio BPEL).

La modellizzazione dei processi aziendali viene realizzata allo scopo di renderne chiara e comprensibile le modalità di funzionamento agli utenti di business. L'uti-lizzo di notazioni complesse può rappresentare un problema, non permettendo la totale condivisione aziendale. E' importante che ciò avvenga perché gli stessi dia-grammi di processo devono poter essere utilizzati da dierenti persone ed essere di supporto a numerose attività. L'insieme dei principali elementi che costituiscono la notazione BPMN rappresenta il miglior compromesso attualmente disponibile per l'applicazione di uno standard condiviso nell'analisi dei processi aziendali,

(8)

renden-do la notazione come lo standard de facto utilizzato per rappresentare i processi aziendali.

I processi di business sono generalmente espressi, tramite la notazione BPMN, 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 condivisione 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 de-nizione 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 il binding graco per la costruzione del diagramma.

Il lavoro svolto parte 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.

1.1 Esempio di processo

Si propone, a scopo introduttivo ai prossimi argomenti, un esempio completo di espressione, con conseguenti xml e diagramma generati.

(9)

Costruiamo il processo partendo da un ipotetico servizio di controlli di sicurezza in aeroporto a cui sottoporsi. Le attività da svolgere sono:

raggiungere il punto di controllo;

parallelamente sottoporsi e sottoporre la valigia ai controlli di sicurezza dirigersi verso le partenze

Si noti che sia valigia che passeggero devono aver completato i controlli di sicurezza altrimenti non si può procedere. Per costruire il processo è necessario creare una struttura specica che identichi il nome del processo e tutti gli elementi in esso contenuti.

All'interno del processo dovremo costruire alcuni task che identichino le attività svolte.

Inne avremo bisogno di uno strumento, il gateway, per garantire il parallelismo nelle attività.

Provando a descrivere l'espressione, otteniamo: P< name : ControlliSicurezza > :=

t< name : RaggiungiStanzaDiControllo , type :user > ;

( t< name : RiceviControlliSicurezzaPersonali , type : generic > + t< name : RiceviControlliSicurezzaValigia , type : generic > ) ;

t< name : LasciaControllo , type : generic > .

Come si può notare, abbiamo implementato il parallelismo delle due soluzione con un gateway e usato i caratteri speciali come "+" per garantire i punti contatto. Lanciando il parsing sul motore, otteniamo l'xml corrispondente al seguente diagramma.

(10)

L'xml completo dell'analisi è:

<!-- P< name : ControlliSicurezza >:=t< name : RaggiungiStanzaDiControllo , type :user >;(t< name : RiceviControlliSicurezzaPersonali , type : generic >+t< name :

RiceviControlliSicurezzaValigia , type : generic >);t< name : LasciaControllo , type : generic >. -->

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

< definitions xmlns =" http :// www . omg . org / spec / BPMN /20100524/ MODEL " xmlns : bpmndi =" http :// www . omg . org / spec / BPMN /20100524/ DI" xmlns : omgdc =" http :// www . omg . org / spec /DD /20100524/ DC" xmlns : omgdi =" http :// www . omg . org / spec /DD /20100524/ DI" xmlns : xsi =" http :// www .w3. org /2001/ XMLSchema - instance " targetNamespace ="" xsi :

schemaLocation =" http :// www . omg . org / spec / BPMN /20100524/ MODEL http :// www . omg . org / spec / BPMN /2.0/20100501/ BPMN20 . xsd ">

< startEvent id=" ControlliSicurezza_1 " name =" start "> <outgoing > ControlliSicurezza_2 </ outgoing >

</ startEvent >

< sequenceFlow id=" ControlliSicurezza_2 " sourceRef =" ControlliSicurezza_1 " targetRef =" ControlliSicurezza_3 " />

< userTask id=" ControlliSicurezza_3 " name =" RaggiungiStanzaDiControllo "> <incoming > ControlliSicurezza_2 </ incoming >

<outgoing > ControlliSicurezza_4 </ outgoing > </ userTask >

< parallelGateway gatewayDirection =" Diverging " id=" ControlliSicurezza_5 " > <incoming > ControlliSicurezza_4 </ incoming >

<outgoing > ControlliSicurezza_6 </ outgoing > <outgoing > ControlliSicurezza_9 </ outgoing > </ parallelGateway >

<task id=" ControlliSicurezza_7 " name =" RiceviControlliSicurezzaPersonali "> <incoming > ControlliSicurezza_6 </ incoming >

<outgoing > ControlliSicurezza_8 </ outgoing > </task >

(11)

=" ControlliSicurezza_12 " />

<task id=" ControlliSicurezza_10 " name =" RiceviControlliSicurezzaValigia "> <incoming > ControlliSicurezza_9 </ incoming >

<outgoing > ControlliSicurezza_11 </ outgoing > </task >

< sequenceFlow id=" ControlliSicurezza_11 " sourceRef =" ControlliSicurezza_10 "

targetRef =" ControlliSicurezza_12 " />

< parallelGateway gatewayDirection =" Converging " id=" ControlliSicurezza_12 " > <incoming > ControlliSicurezza_8 </ incoming >

<incoming > ControlliSicurezza_11 </ incoming > <outgoing > ControlliSicurezza_13 </ outgoing > </ parallelGateway >

<task id=" ControlliSicurezza_14 " name =" LasciaControllo "> <incoming > ControlliSicurezza_13 </ incoming > <outgoing > ControlliSicurezza_15 </ outgoing > </task >

< endEvent id=" ControlliSicurezza_16 " name =" end "> <incoming > ControlliSicurezza_15 </ incoming > </ endEvent >

</ process >

</ bpmndi : BPMNShape >

(12)

(13)

Figura 1.1: Output le

</ bpmndi : BPMNShape > </ bpmndi : BPMNPlane > </ bpmndi : BPMNDiagram > </ definitions >

Mostriamo inne il rendering graco del processo (g. 1.1).

Come è possibile constatare, l'idea portante del nostro studio risiede nella possi-bilità di costruire un'unica espressione, che rappresenti come nell'esempio appena visto un singolo processo o, in alternativa, una collaborazione fra più processi, che sintetizzi notevolmente le righe di codice, garantendo contemporaneamente semplicità, immediatezza e precisione.

(14)

1.2 Struttura del documento

Nel capitolo 2 sarà presentata la notazione BPMN, sia per quanto riguarda la notazione graca, che per quanto riguarda l'xml. Dopo una breve panoramica, ogni elemento sarà analizzato nel dettaglio, indicandone il simbolo graco, i tag xml e il signicato.

Il capitolo 3 conterrà tutte le speciche riguardanti le scelte di progettazione di BPGen.

Nel capitolo 4 illustreremo il class diagram del parser e discuteremo le scelte implementative e gli eventuali problemi conseguenti, inserendo le porzioni di codice più importanti.

Il capitolo 5 includerà alcuni dei casi di test più signicativi che abbiamo rea-lizzato, con link di rimando alla documentazione di riferimento, e i casi d'uso standard creati utilizzando lo strumento e riutilizzabili in realizzazioni di processi più complessi.

Nel capitolo 6, inne, saranno inserite le conclusioni e gli eventuali sviluppi futuri proposti per lo strumento BPGen.

(15)

Capitolo 2

BPMN

Lo scopo principale dello standard BPMN è di fornire una notazione che sia facilmente comprensibile a tutti gli utenti di business:

da parte degli analisti, che hanno il compito di realizzare i diagrammi relativi ai processi;

da parte degli sviluppatori, che devono gestire e mettere a punto la parte tecnologica per la realizzazione di tali processi;

da parte dei responsabili dei processi che, ognuno per il suo processo, avrà il compito di gestirlo, controllarne il funzionamento e migliorarlo se possibile.

BPMN è lo standard dei modelli di rappresentazione dei processi di business, accorpa le migliori idee dalle notazioni già esistenti al momento della sua de-nizione, tra le quali il diagramma delle attività UML. L'utilizzo della notazione BPMN rende possibile, a partire dai diagrammi, la generazione di codice soft-ware eseguibile (ad esempio BPEL4WS - Web Services Business Process

(16)

tion Language), permettendo un rapido passaggio dal disegno del processo alla sua implementazione.

I processi di business sono rappresentati attraverso la realizzazione di diagram-mi di processo denodiagram-minati Business Process Diagram (BPD) e basati sull'utilizzo della notazione BPMN. Grazie all'utilizzo nel BPD degli elementi graci della notazione, è possibile rappresentare in maniera semplice e chiara il usso delle at-tività che vengono eseguite durante il funzionamento di un processo. La notazione BPMN è stata sviluppata con lo scopo di fornire uno strumento semplice per la modellizzazione dei processi business, riuscendo contemporaneamente a gestirne la complessità. Per soddisfare entrambe le necessità, gli elementi graci della no-tazione sono stati organizzati in categorie speciche, in modo da poter leggere e comprendere un processo attraverso l'utilizzo di un numero limitato di tipologie di simboli. Allo stesso tempo, all'interno delle basilari categorie di elementi, è pos-sibile aggiungere diverse variazioni e informazioni allo scopo di rappresentare la complessità associata al processo, non intaccando però la chiarezza del diagramma.

2.1 Modelli di business rappresentabili con BPMN

Con la notazione BPMN è possibile rappresentare 3 tipi di sottomodelli, costi-tuenti elementi di business in ambito aziendale:

Processi, divisibili in aziendali privati e pubblici. Coreograe.

(17)

Figura 2.1: Processo Privato [1]

I processi aziendali privati (g 2.1) generalmente prendono il nome di work-ow, o processi BPM. Un altro termine utilizzato per indicarli è quello di Orchestrazione dei servizi. Un processo aziendale è un processo privato che è stato modellato allo scopo di documentare un comportamento dell'azienda. Un processo di business privato sarà contenuto all'interno di un unico elemento detto Pool, di cui non potrà attraversarne i conni salvo che nel caso in cui esistano delle interazioni tra più processi aziendali. Eventuali ussi di messaggi possono attraversare i conni del pool o dell'unità organizzativa.

I processi pubblici (g 2.2) deniscono le interazioni tra un processo privato e un altro processo o partecipante, riportando le attività che permettono di comu-nicare al di fuori del processo privato e i meccanismi mirati a controllare i ussi di processo. Il processo pubblico mostra quindi i ussi e l'ordine dei messaggi ritenuti necessari per l'interazione con un altro processo processo.

La collaborazione (g 2.3) denisce le interazioni tra più entità aziendali. Ge-neralmente contiene due o più pool, ognuno dei quali rappresenta i partecipanti della collaborazione. Lo scambio d'informazioni è realizzato mediante un usso di messaggi che collega i due pool. La collaborazione può essere considerata come l'unione di due o più processi pubblici comunicanti tra loro. In un processo pub-blico, le attività per la collaborazione tra i partecipanti possono essere considerate

(18)

Figura 2.2: Processo Pubblico [1]

Figura 2.3: Collaboration [1] "punti di contatto" tra i partecipanti.

Una coreograa (g. 2.4) (senza pool o processi aziendali) è una denizione del comportamento atteso tra più partecipanti che interagiscono. Mentre un normale processo esiste all'interno di un pool, una coreograa esiste tra i pool (o partecipan-ti). La coreograa è simile a un processo aziendale privato poiché è costituita da una rete di attività, eventi, e gateway. Le attività, nelle coreograe, rappresentano un insieme di scambi di messaggi, che coinvolgono due o più partecipanti.

Lo strumento da noi realizzato, per scelta, tratterà solamente i processi e le collaborazioni, non permettendo la generazione di coreograe.

(19)

Figura 2.4: Coreograa [1]

2.2 Gli elementi della notazione BPMN

Uno degli obiettivi principali della notazione BPMN è di creare un semplice e comprensibile meccanismo per realizzare modelli di processi aziendali, gestendo allo stesso tempo la complessità intrinseca dei processi aziendali. L'approccio adottato per gestire queste due esigenze contrastanti è stato quello di organizzare gli aspetti graci della notazione in categorie speciche. Questo fornisce un insieme di categorie, in modo che il lettore di un diagramma BPMN possa facilmente riconoscere gli elementi di base e capire il diagramma. Le cinque categorie degli elementi base sono:

Flow Objects (Forme), che rappresentano i principali elementi graci per denire il comportamento dei processi aziendali;

Data Objects, che rappresentano i dati;

Connecting Objects (Connettori), che permettono di connettere i Flow Ob-jects;

(20)

Artifacts (Elementi accessori), utilizzati per fornire ulteriori informazioni sul processo.

2.2.1 Flow Object

Esistono tre tipi di Flow Objects: Events.

Activities. Gateways.

Di seguito descriveremo ognuno di essi, riassumendone le caratteristiche e illustrandone il simbolo della notazione graca.

Events

Rappresentano qualcosa che "accade" nell'ambito di un processo o di una co-reograa. Impattano sul usso del modello e solitamente hanno una causa (trigger) o un impatto (risultato). Il simbolo che rappresenta gli eventi è un cerchio. Esi-stono tre tipi di eventi che si dierenziano in base a quando si manifestano nel usso del processo: Inizio, Intermedio e Fine.

Eventi Iniziali Gli eventi Inizio (g. 2.5) hanno dei triggers (inneschi) che ne determinano le caratteristiche: questi eventi indicano dove e come un processo inizierà la sua esecuzione. Gli eventi iniziali danno il via al usso del processo e quindi, per denizione, non possono essere preceduti da una sequenza entrante a monte. Si riassumono di seguito le caratteristiche principali dell'evento iniziale.

(21)

Figura 2.5: Notazione graca eventi [1]

in ogni processo deve essere presente almeno un evento iniziale;

per ogni evento di tipo ne deve esistere almeno un evento di tipo inizio; se il processo è complesso e/o le condizioni di partenza non sono evidenti,

allora è raccomandato l'utilizzo dell'evento inizio;

l'evento inizio è l'unico elemento del usso che non ammette la presenza di un usso di sequenza a monte;

possono esistere più eventi iniziali indipendenti per un dato processo paral-lelo.

L'attivazione di un evento iniziale può essere di vario tipo ed è indicata gra-camente dall'icona dentro il simbolo dell'evento. Si utilizzano diversi simboli per denotare questi eventi nel BPMN (g. 2.6), di cui forniamo breve descrizione per gli eventi accettati nel nostro motore.

(22)

Nessun simbolo: il modellatore non mostra il tipo di evento; è usato anche all'inizio di un sotto-processo;

Message: un partecipante fa partire un messaggio che dà il via al processo; Timer: il processo ha origine in un particolare momento;

Signal: l'inizio avviene a fronte della ricezione di un segnale (a dierenza di un messaggio, è pubblico).

Eventi Finali Gli eventi di tipo nale (g. 2.5) indicano la terminazione di un processo: questi tipi di eventi non possono avere un ulteriore usso in uscita poiché concludono il usso del processo. Gli eventi nali sono rappresentati da un cerchio dal bordo nero spesso. Le principali caratteristiche dell'evento nale sono:

un processo può avere più eventi nali;

deve esistere almeno un elemento nale nel diagramma; per ogni evento iniziale deve esserci almeno un evento nale;

da un evento di tipo ne non può scaturire alcun usso di sequenza in uscita. I simboli utilizzati per denotare il tipo di evento nale, limitatamente a quanto trattato nel nostro lavoro (g. 2.6), sono i seguenti.

Nessun simbolo: il modellatore non mostra il tipo di evento e indica la ne del processo.

Message: questo tipo di evento nale indica l'invio di un messaggio da parte di un partecipante nel momento in cui si conclude il processo.

(23)

Signal: alla ne del processo viene lanciato un segnale che deve essere cat-turato.

Terminate: indica la terminazione immediata del processo, interrompendo tutti i task ancora in esecuzione.

Eventi Intermedi Gli eventi di tipo intermedio (g. 2.5) hanno luogo tra un evento iniziale e uno nale. Hanno la stessa forma di base dell'evento iniziale e nale, un cerchio con un centro aperto e con i bordi formati da una doppia linea sottile, con eventuali simboli interni che indicano il tipo di evento. Gli eventi intermedi possono essere utilizzati per mostrare in che punto del processo si aspetta la ricezione o si attua l'invio dei messaggi. Gli eventi intermedi possono reagire a (catch) o creare (throw) un trigger.

I simboli utilizzati per denotare gli eventi intermedi nel BPMN, da noi utilizzati all'interno del motore (g. 2.6), sono i seguenti:

Nessun simbolo: questo tipo di evento non viene mostrato dal modellatore e può essere usato solo nel usso principale del processo, per indicare alcuni cambiamenti nello stato del processo.

Message: questo tipo di evento reagisce all'arrivo di un messaggio. Il par-tecipante (pool) invia un messaggio al processo originando l'evento. Nel momento in cui arriva il messaggio, il processo prosegue il suo corso oppure devia le transazioni verso la parte del usso che gestisce gli eventi eccezio-nali. Nel usso normale gli eventi di messaggio intermedi possono essere utilizzati per inviare messaggi a un partecipante.

(24)

Timer: questo tipo di evento può innescare una transazione nel processo in un determinato istante. Se viene utilizzato nel usso principale può rimandare l'esecuzione del processo ad un determinato istante o allo scadere del time-out.

Signal: questo tipo di evento ritarda l'esecuzione del processo no all'arrivo di un segnale.

Si riporta di seguito, a solo scopo documentativo, la lista degli altri tipi di attivazione disponibili.

Escalation, valido per tutti i tipi di eventi Compensation, valido per tutti i tipi di eventi Conditional, valido per eventi iniziali e intermedi Multiple, valido per tutti i tipi di eventi

Parallel, valido sia per eventi iniziali che per eventi intermedi Cancel: valida per eventi intermedi e nali

Link: valida per eventi intermedi. Activity

Le attività, utilizzate sia nei processi standard sia nelle coreograe, possono essere atomiche o composte (non atomiche), a seconda che possano o meno essere ulteriormente scomposte in passi più semplici: le operazioni composte prendono il nome di Sub-Process (sotto-processi), mentre quando sono atomiche prendono il nome di Task.

(25)

(26)

Figura 2.7: Task[1]

Task Un task è un'attività atomica inclusa all'interno del processo. Viene uti-lizzato quando un'attività, all'interno del processo, non deve essere dettagliata ulteriormente. Il task può essere l'origine di un usso di sequenza e può avere più ussi in uscita, creando un percorso parallelo separato per ogni usso. Se il task non possiede dei ussi di sequenza in uscita e se manca l'evento nale, allora è compito del task stesso indicare il termine di uno o più percorsi nel processo. Il task viene rappresentato gracamente con un rettangolo con gli angoli arrotondati tracciato con una linea sottile. Nel nostro studio è attualmente l'unico tipo di attività presa in considerazione.

Gateway

Utilizzati per controllare la divergenza e la convergenza della sequenza di un processo e di una coreograa, permettendo di generare ramicazioni, biforcazioni, fusioni o giunzioni di percorsi. Vengono inoltre utilizzati per cicli e "salti". La rappresentazione graca prevede la forma romboidale, nella mappatura tradizio-nale impiegata per rappresentare le decisioni. Nel BPMN, quando presenti simboli interni al gateway, si intende utilizzare particolari comportamenti di controllo che determino il modo e il numero di strade disponibili per proseguire il usso,in base a quanti ussi di sequenza usciranno dal gateway.

(27)

join) e divergente (o split). Le principali operazioni logiche perseguibili con i gateway, che determinano poi il comportamento del usso, sono: AND, XOR, OR, complesse.

XOR: decisione e unione esclusive, sia basate sui dati che sugli eventi. OR: decisione e unione inclusive.

AND: biforcazioni e unioni; ogni tipo di controllo ha eetto sia con i ussi in entrata sia con quelli in uscita.

Complesso: condizioni e situazioni complesse.

XOR I Controlli esclusivi (g 2.8) rappresentano punti del processo aziendale in cui il usso di sequenza ha a disposizione due o più possibili percorsi, ma può intraprendere soltanto uno. Una decisione, dal punto di vista dei processi azien-dali, non è un'attività ma è un tipo di controllo che gestisce il usso di sequenza all'interno delle attività. La decisione può essere intesa come una domanda posta in un punto del processo, avente un insieme denito di risposte alternative (porte). Ogni risposta è associata a un usso di uscita e, quando si sceglie una porta du-rante l'esecuzione del processo, viene scelto di conseguenza anche il corrispondente usso uscente.

Esistono due tipi di decisioni esclusive:

Basate sui dati: sono i tipi di controllo che vengono usati più frequentemente. Queste espressioni usano i valori dei dati del processo per determinare quale percorso scegliere;

(28)

Figura 2.8: Exclusive[1]

Figura 2.9: Inclusive[1]

Basate sugli eventi: rappresentano dei punti di ramicazione nel processo in cui le decisioni sono basate sugli eventi che avvengono in quel punto piutto-sto che sulla valutazione di espressioni. Un evento specico, solitamente la ricezione di un messaggio, determina quale percorso prendere.

OR I controlli inclusivi (g. 2.9) sono punti di ramicazione in cui le diverse alternative sono basate su espressioni condizionali contenute all'interno del usso di sequenza uscente. In questi controlli la valutazione di un'espressione che risulti vera non esclude la valutazione di altre espressioni: tutti i ussi di sequenza con-siderati veri saranno eseguiti. Essendo ogni percorso indipendente, possono essere intraprese tutte o nessuna delle combinazioni di strade. Tuttavia si presume che venga seguito almeno un percorso.

AND I controlli paralleli possono essere utilizzati sia per dividere i ussi, ga-rantendo che tutti i sequence ow in uscita vengono attivati simultaneamente, sia per riunire più ussi, attendendo che tutti i ussi precedentemente innescati siano arrivati. In fase di creazione dei percorsi non è obbligatorio ricorrere ai controlli,

(29)

Figura 2.10: Parallel[1]

Figura 2.11: Sequence Flow[1]

ma è tuttavia importante utilizzarli per chiarire il comportamento dei ussi in caso di situazioni complesse.

2.2.2 Connecting object

Esistono varie tipologie di connettori: Sequence Flows.

Message Flows. Associations Sequence Flow

Rappresentano il usso del processo, per mostrare l'ordine in cui le attività saranno eseguite (g 2.11). Ogni connettore ha un punto di origine e un punto di arrivo, agganciati a uno dei seguenti oggetti: eventi, attività o controlli.

(30)

Figura 2.12: Message Flow[1] Message Flow

Rappresentano il usso informativo del processo: sono utilizzati per mostrare il usso di messaggi tra due partecipanti, inseriti in due pool dierenti, che devono inviare e ricevere messaggi (g 2.12). Questi tipi di connettore devono collegare gli oggetti che fanno parte del usso, ma non può connettere due oggetti dello stesso pool.

2.2.3 Swimlanes

Le Swimlanes sono di 2 tipi: Pools.

Lanes. Pool

Rappresentano gracamente un partecipante (g. 2.12). Si comporta come un contenitore del usso di sequenza tra le attività. Nei diagrammi BPMN il usso sico non può oltrepassare i conni di un pool, viceversa il usso informativo, denito tramite Message Flow, può oltrepassare tali conni, in quanto indica lo scambio di informazioni esistente tra due partecipanti o entità. Un altro aspetto dei pool riguarda la presenza o meno di attività dettagliate al loro interno: un determinato pool può apparire come una scatola bianca, o come una scatola

(31)

Figura 2.13: Pool[1]

nera, con i dettagli nascosti. Le scatole nere non possono essere associate ai ussi di sequenza, ma i ussi di messaggio possono collegarsi ai loro bordi. Nelle scatole bianche, le attività all'interno sono organizzate in ussi di sequenza. Altri simboli della notazione

Per completezza di informazione e al solo scopo documentativo, riportiamo di seguito una lista di elementi e notazioni volutamente esclusi dal nostro studio, per i quali si rimanda, per approfondimenti specici, alla documentazione uciale [1].

Gateway Event Based.

Gateway Parallel Event Based. Gateway Complex.

Sub Process - Collapsed Sub Process - Expanded Data Objects.

Data Inputs. Data Outputs.

(32)

Data Stores. Data Message.

Connecting Object Association. Swimlanes Lane

Artifact Group Artifact Annotation

2.3 Notazione XML

Come precedentemente accennato, tutti gli elementi graci appena illustrati possono essere rappresentati mediante linguaggio XML. Ciò permette la portabilità fra varie piattaforme, sistemi e tool di realizzazione graca dei processi diversi, favorendo il lavoro di progettazione. La denizione del documento XML si divide in due componenti principali:

denizione del modello

denizione del diagramma del processo

2.3.1 Modello

Si denisce inizialmente, con una struttura rigida e formale, esplicitata in op-portuni fogli XSD, il modello contenente tutti gli elementi che costituiscono il processo. Ogni elemento sarà contraddistinto a un proprio tag, un id e un nome. Altri attributi possono essere specici per il singolo componente. Si riporta di

(33)

seguito la struttura di alcuni dei componenti principali, considerando il limitato scostamento dagli altri elementi.

Il modello inizia sempre con la denizione di una Collaborazione, eventual-mente contenente un solo processo (nel caso di rappresentazione di singoli processi aziendali).

< collaboration id="0">

< participant id="1" name =" Customer " processRef =" ... " /> </ collaboration >

La denizione di un processo richiede l'utilizzo di due tag di apertura e chiusura, all'interno dei quali deniremo tutti gli oggetti del processo.

<process id="1" name =" ... "> ....

</ process >

Tutti i ow objects contenuti all'interno del processo dovranno essere collegati mediante connettori. I collegamenti saranno deniti mediante un tag indicante il tipo di connettore e la parola Flow, come segue:

< sequenceFlow id="2" name =" ... " sourceRef ="1" targetRef ="2" />

Gli attributi sourceRef e targetRef indicheranno rispettivamente l'identicativo assegnato all'elemento di provenienza e a quello di destinazione.

Tutti i connettori saranno indicati anche tra i tag di apertura e di chiusura degli oggetti ad essi collegati, mediante utilizzo di tag in cui specicare l'identicativo dell'oggetto di riferimento:

Gli eventi hanno una notazione che prevede il tipo di evento, seguito dalla paro-la Event. Gli eventi di Start ed End, di cui si riportano di seguito i tag di apertura e chiusura, saranno casi particolari in cui, come già accennato nella denizione

(34)

della notazione BPMN, saranno presenti rispettivamente solo connettori di uscita e connettori di ingresso.

< startEvent id="2" name =" Start "> <outgoing >... </ outgoing > </ startEvent >

I task possono essere esplicitati con un tag <task...> , per un'attività generica, o con il tipo specico del task che si vuole creare, come ad esempio <sendTask..>.

I componenti Gateway richiedono una maggiore accortezza. Nel tag sarà infatti possibile specicare il tipo di Gateway che si sta creando, ma sarà anche opportuno specicare la direzione (convergente o divergente) degli archi entranti/uscenti.

< exclusiveGateway id="5" gatewayDirection =" Converging "> <incoming >4 </ incoming >

In questo caso indichiamo la presenza di un gateway esclusivo che presenta due archi in ingresso e due in uscita.

Per una trattazione più approfondita sul modello XML si rimanda ai prossimi capitoli, in cui aronteremo nel dettaglio il processo di creazione e testing dello strumento BPGen e all'appendice B in cui sono presenti gli xsd uciali [2].

(35)

2.3.2 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 docu-mento XML necessità di una parte di rappresentazione graca di tutti gli elementi deniti nel modello.

La denizione del diagramma è inclusa nei tag: <bpmndi : BPMNDiagram id=" ... ">

....

</ bpmndi : BPMNDiagram >

Per la rappresentazione graca si utilizzano tag specici che non richiamano direttamente il tipo di elemento utilizzato, si occupano piuttosto di denire forme (nel caso dei ow object) o bordi (nel caso dei connettori), indicando le coordinate in cui posizionare ogni elemento e la sua dimensione, con gli attributi x, y, width ed height. Nel caso dei connettori, le coordinate sono rappresentate da più punti, dovendo seguire una direzione fra più elementi.

Si riporta di seguito, a titolo di esempio, la rappresentazione graca degli eventi start ed end, di un gateway e di un connettore.

Start:

</ bpmndi : BPMNShape > End:

(36)

</ bpmndi : BPMNShape > Gateway:

</ bpmndi : BPMNShape > Sequence Flow:

</ bpmndi : BPMNEdge >

All'interno dei tag di denizione di ogni oggetto, come è possibile vedere nell'e-sempio, è possibile specicare una label contenente la parte informativa del compo-nente, che ne fornisce un'identicazione rapida riguardo al suo utilizzo nell'ambito del processo di business.

Per una trattazione più approfondita sul modello XML si rimanda ai prossimi capitoli, in cui aronteremo nel dettaglio il processo di creazione e testing dello strumento BPGen e all'appendice B in cui sono presenti gli xsd uciali.

(37)

2.4 Strumenti di supporto alla progettazione BPMN

In ambito aziendale, per progettare i processi di business, si ricorre spesso ad ambienti di sviluppo graci che permettano rapidamente di aggiungere elementi al diagramma, creando gli opportuni collegamenti. E' inoltre possibile marcare tutti gli elementi con opportune etichette che identichino il comportamento dei vari oggetti e la valenza che essi hanno all'interno de diagramma.

Gli strumenti che vengono utilizzati permettono la creazione del tracciato xml contestualmente alla realizzazione della parte graca, aggiornandolo ad ogni mo-dica. E' quindi possibile utilizzare uno di questi strumenti per costruire processi in formato xml, da confrontare successivamente con quanto prodotto dal motore BPGen.

Per il nostro lavoro abbiamo utilizzato principalmente due tool: Yaoqiang [3]

Camunda [4]

Yaoqiang Si tratta di un editor graco che rispetta le speciche BPMN 2.0. Il prodotto è open source, non richiede installazioni ed è interamente realizzato in java ed eseguibile come una normale applicazione jar. La versione del run time enviroment consigliata per la sua esecuzione è la JRE 8. Per problemi di compatibilità non è attualmente possibile eseguirlo sull'ultima versione di Java (JRE11). La versione di Yaoqiang da noi utilizzata è la 5.3.12.

Fra le caratteristiche principali da citare ci sono: validazione in tempo reale della sintassi

(38)

generazione automatica del tracciato XML repository interno per il controllo delle versioni motore BPMN2.0 integrato

possibilità di importare ed esportare le in diversi formati (PNG, JPG, HTML, ODT, ecc) per integrazione semplicata con altri software.

Camunda Si tratta di uno strumento costruito su più moduli, dei quali quelli di nostro interesse sono due: il modeler, per creare processi di business e testare gli xml generati con il nostro motore, e il BPMN Workow Engine, per eseguire eventualmente il processo o tramite chiamate a servizi rest, o tramite integrazione nel codice java.

Fra le caratteristiche principali abbiamo:

possibilità di creare i processi tramite tool locale semplicato generazione automatica del tracciato XML

possibilità di testare il processo realizzato in locale

possibilità di testare il processo da remoto, con chiamata a servizi REST da esporre su un server centrale

possibilità di integrare i processi nelle proprie applicazioni con API Java. Entrambi gli strumenti sono stati utilizzati per la generazione di casi d'esempio e per la validazione dell'output del motore, oltre che per garantire la completa interoperabilità fra tool di realizzazione di processi diversi.

(39)

2.5 Riepilogo

In questo capitolo abbiamo approfondito la notazione BPMN, indicandone le caratteristiche principali e l'utilità. Dopo aver presentato la notazione graca, abbiamo illustrato la struttura xml dei processi di business, base da cui partire per garantire l'interoperabilità fra più sistemi. Abbiamo inne spostato il focus sugli strumenti di realizzazione graca e XML utilizzati nel nostro lavoro.

Nel prossimo capitolo ci concentreremo sulla parte di progettazione, indicando le valutazioni e le scelte fatte per quanto riguarda la sintassi e la costruzione del motore.

(40)

Capitolo 3

PROGETTAZIONE

La struttura xml utilizzata per rappresentare un progetto di business risulta complessa e strutturata, dicile da scrivere senza un eventuale supporto. Per questo motivo, spesso, si tende a realizzare il progetto graco, lasciando che sia il tool di sviluppo ad occuparsi dell'eventuale generazione automatica del le xml. L'idea di base del nostro lavoro è quella di inventare una sintassi testuale semplice ed immediata che, mediante espressioni algebriche e simboli che conuiscono in un nuovo linguaggio, permetta di generare in maniera automatica processi di business e collaborazioni in formato XML.

I principali beneci attesi nella denizione del nuovo linguaggio sono:

immediatezza nella creazione di un processo, utilizzando un linguaggio con sintassi ridotta a pochi termini ed operazioni

compattezza nelle espressioni che permettono di denire processi complessi anche in una sola riga articolata

(41)

possibilità di generare automaticamente il tracciato XML che rappresenta il processo di business

possibilità di scambiare in maniera immediata i dati con altri utilizzatori condividendo una semplice riga testuale

possibilità di riuso di sottoprocessi e di workow predeniti multipiattaforma e multisistema

La successiva fase di realizzazione partirà da questi punti e dalla denizione del nuovo linguaggio per produrre uno strumento che sia facilmente portabile e consultabile sia via web che da riga di comando.

3.1 Denizione del linguaggio

La sintassi denita per l'espressione del processo di business deve rispondere ad esigenze speciche dettate dalle modalità di input previste dal sistema. Uno degli obiettivi è infatti quello di non complicare in maniera eccessiva la descrizione di un processo, per rispondere ad una delle caratteristiche della notazione BPMN. Presenteremo ora i simboli utilizzati per modellare il processo sul nostro strumento, costruendo progressivamente il diagramma corrispondente.

Tutte le espressioni sono costituite da una forma: sottomodello := espressione

(42)

3.1.1 Sottomodelli

Per scelta di progettazione abbiamo preso in considerazione i processi e le collaborazioni fra processi, escludendo le coreograe che mal si sposerebbero con la denizione sintattica oerta dal nostro linguaggio.

Processi

Identicati con la lettera P, i processi sono costituiti dai ow object e dai con-nettori deniti nell' espressione successiva ai caratteri := e sono salvati in output sul tracciato xml nale per poter essere eventualmente recuperati con interrogazio-ni successive. Il carattere di terminazione di oginterrogazio-ni processo, obbligatorio, è il . Per ogni processo è necessario specicare un nome, con l'attributo name:ProjectName P< name : DemoProject > :=

Collaborazioni

Identicate con la lettere C, richiedono la specica dell'attributo nome na-me:ProjectName come per i processi. Dopo i caratteri ":=" è necessario inseri-re la corinseri-relazione fra più processi con il caratteinseri-re &. I processi devono esseinseri-re precedentemente deniti, e specicati nella forma:

C< name : Collaboration1 > :=

P< name : Pcoll1 , type : start , message : sendMailP1_receiveMailP2 > &

P< name : Pcoll2 , message : sendMailP2_receiveMailP1 >

Si noti che, per scelte progettuali, i processi che partecipano alla collaborazio-ne devono essere stati analizzati e salvati precedentemente. Per il salvataggio è

(43)

necessario che il nome del le corrisponda al nome del processo, funzionalità che comunque è stata automatizzata nel sistema. Inoltre è obbligatorio specicare:

il processo principale, unico ad avere gli eventi start ed end, tramite l'attri-buto type:start;

il usso di messaggi, direzionando sempre dal nodo sorgente al nodo desti-nazione.

Nel caso dell'esempio precedente, ad esempio, abbiamo rispettivamente un evento di send message e uno di receive message nel primo processo, un evento di receive message e uno di send message nel secondo processo. Nella denizione della collaboration, oltre ad indicare i processi partecipanti, dovremo quindi indi-care, per ognuno, tutti i messaggi in uscita con relativi nodi di ingresso degli altri processi. Nella denizione del message, i processi di invio e ricezione sono separati dal carattere "_" e, nel caso ci sia uno scambio di più messaggi, essi possono es-sere indicati sequenzialmente con carattere di congiunzione "-". L'espressione per l'invio messaggi sarà quindi:

message : send1P1_receive1P2 send2P1_receive2P2

-Si riporta, in gura 3.1, il diagramma corrispondente all'espressione appena denita.

3.1.2 Espressioni

Identicano eettivamente tutti gli elementi che costituiscono il processo di bu-siness, con una sintassi specica e una serie di operazioni permesse. Per vincolare il

(44)

(45)

corretto inserimento dell'espressione, sono stati implementati dei controlli che per-mettono di segnalare esplicitamente eventuali errori di inserimento e la posizione esatta del punto di errore.

Si indica di seguito la sintassi scelta per il linguaggio. Sequence Flow ;

Il carattere ";" viene utilizzato per identicare un connettore fra due elementi, quello che precede il simbolo e quello che lo segue. Per non aumentare il livello di complessità dell'espressione, si è scelto di non permettere altri tipi di connettori. Nella parte nale del capitolo riporteremo alcune regole per l'utilizzo dei sequence ow.

Dopo aver approfondito i prossimi elementi, utilizzeremo i sequence ow all'in-terno di alcuni esempi.

Eventi e(<name><type[-EventDenition]>)

Denizione di un evento con un nome specico. Il nome e il tipo sono da-ti obbligatori e quest'ulda-timo, in parda-ticolare, è uda-tilizzato per denire il successivo tag xml dell'evento. Se scrivessimo un tipo non esistente, di fatto, genereremmo un tag non interpretabile dai tool di realizzazione dei processi di business. La scelta, seppur apparentemente non coerente con il resto dei controlli imposti, è stata fatta per non vincolarsi alla sintassi di una singola piattaforma ma permet-tere l'utilizzo di tipi evento disponibili su vari sistemi, preoccupandosi ovviamente di non utilizzare l'xml creato su strumenti che non possano supportarlo. Esiste inoltre, per l'attributo type, la possibilità di specicare un'espressione opzionale, nella forma -EventDenition. Tramite questa denizione, se passata in fase di

(46)

creazione, andremo a denire la decorazione dell'evento, per denirne l'eettivo comportamento. In caso no nsia presente il parametro, l'evento intermedio sarà di tipo generico.

E' possibile costruire 3 tipi di eventi:

start, costruiti automaticamente dopo i caratteri := ; intermediate, che possono essere di tipo throw o catch; end, costruiti quando inseriamo il carattere ..

Gli eventi intermedi, sia throw che catch, come discusso nel capitolo 2, possono avere un'ulteriore denizione nelle seguenti categorie:

message; timer; signal;

Nel caso in cui non si indichi alcuna denizione ulteriore, l'evento sarà generico. Come precedentemente detto, per scelta, il motore non vincola alcun tipo di evento lasciando all'utilizzatore la possibilità di denire quanto necessario per il suo processo.

Tratteremo nel prossimo capitolo nel dettagli la costruzione dell'xml a fronte del tipo di un evento.

Per imporre il vincolo di un solo evento Start e un solo evento End, si è deciso di non permettere la creazione di questo tipo di eventi che saranno aggiunti auto-maticamente alla struttura xml. Il motore aggiungere quindi lo Start dopo aver

(47)

Figura 3.2: P<name:DemoProject>

lavorato i caratteri ":=" mentre 'evento End sarà aggiunto quando si troverà il "." nale, carattere di ne denizione.

A scopo d'esempio creiamo un processo con solo evento iniziale e nale total-mente scollegati, generati dall'espressione:

P< name : DemoProject := .

Task t(<name><type>)

Per permettere una gestione semplicata della sintassi di input senza aumentare la complessità, abbiamo scelto di utilizzare solo i Task come tipi di attività. Nella denizione del task sarà obbligatorio inserire il nome mentre il tipo, che risponde alle stesse caratteristiche elencate per l'evento in termini di generazione dell'xml, può non essere presente permettendo la creazione di un task generico.

I task possono essere di 4 tipi fondamentali:

generico, con possibilità di omettere l'attributo di tipo generic; message, di tipo send per invio messaggi;

message, di tipo receive per ricezione messaggi; user, per attività che svolge l'utente.

Come già detto per i processi, anche in questo caso il motore lascia libertà di valorizzare l'attributo type con un valore accettato dalla notazione xml. Sarà onere

(48)

dell'utilizzatore vericare la giusta tipologia di task da creare per il suo processo e la relativa sintassi.

Arricchendo il processo precedente otteniamo: P< name : DemoProject :=

t< name : UserTask , type : user > .

Gateway (...+...x...|...)

I gateway sono identicati dai caratteri di parentesi tonde "( )". Tutto quello che viene inserito nelle parentesi seguirà uno dei rami dei gateway. La direzione del gateway è "divergente" nel caso di parentesi aperta e "convergente" nel caso di parentesi chiusa. All'interno delle parentesi è obbligatorio ci sia un simbolo che identichi il tipo di operazione logica svolta. In particolare per scelte progettuali si è scelto di implementare solo le operazioni XOR, rispondente al simbolo x , AND, rispondente al simbolo + ed OR, rispondente al simbolo |. In caso di errore nell'inserimento del simbolo dell'operazione o della sintassi di apertura e chiusura delle parentesi, è previsto la segnalazione di eccezione che identichi esattamente il problema.

I gateway possono essere innestati, costruendo un'espressione che mantenga il usso logico di apertura-chiusura parentesi che permetta di rispettare il usso del

(49)

processo. Nella parte nale del capitolo riporteremo alcune indicazioni che sarebbe opportuno prendere in considerazione nella costruzione.

Continuando l'utilizzo del processo precedente avremo (g. 3.4): P< name : DemoProject :=

t< name : UserTask , type : user >; (

t< name : Parallel1 , type :send > +

t< name : Parallel2 , type :send > ) ;

t< name : FinalTask , type : generic > .

Cicli

I cicli sono blocchi di espressioni complesse, sintetizzate con pochi caratteri di inizio e ne. Possono contenere singoli oggetti o scelte multiple e altri cicli. Per scelte progettuali sono stati implementati due tipi di ciclo:

(50)

Ciclo 0..n

Si raccomanda di seguire le regole indicate a ne capitolo per non aumentare eccessivamente il livello di complessità dell'espressione, con conseguenti errori di parsing o problemi nella visualizzazione del diagramma corretto.

Ciclo 1..n *[...]*

L'espressione racchiusa tra i simboli citati permette di realizzare cicli che ese-guono alcuni rami da una a n volte. I gateway esclusivi utilizzati per il ciclo sono aggiunti implicitamente senza controllo dell'utente.

Dall'esempio precedente avremo (g 3.5): P< name : DemoProject :=

t< name : UserTask , type :user > ; *[

(

]*;

t< name : FinalTask , type : generic >.

Ciclo 0..n @[...]@

L'espressione racchiusa tra i simboli citati permette di realizzare cicli che ese-guono alcuni rami da zero ad n volte. I gateway esclusivi utilizzati per il ciclo sono aggiunti implicitamente senza controllo dell'utente.

Dal processo precedente otterremo (g 3.6): P <name : DemoProject :=

(51)

(52)

Figura 3.6: P<name:DemoProject> @[

(

]@ ;

t< name : FinalTask , type : generic > .

Si noti che la rappresentazione graca del ciclo (0..n) può riportare alcune pic-cole sovrapposizioni di elementi. Il problema è però facilmente superabile spo-stando manualmente, nel diagramma, gli elementi sovrapposti, per evitare gli accavallamenti.

(53)

3.2 Modalità di analisi dell'espressione

Per il tipo di operazioni da svolgere in fase di parsing, il motore sarà realizzato come un parser sintattico ricorsivo. Ad ogni ricorsione sarà passata in input la stringa del processo privata dei caratteri già analizzati, procedendo da sinistra a destra. In questo modo, ad esempio, si elimineranno prima i simboli "P :=" poi il primo task "t", ecc.

Al termine dell'operazione di parsing la stringa sarà stata completamente ana-lizzata e tradotta in un modello xml, dal quale il motore partirà per la generazione dei tag di diagramma graco.

3.3 Regole e best practice di scrittura

Il linguaggio costruito per la formalizzazione dei processi è volutamente limitato a pochi simboli e ad una struttura abbastanza rigida. E' perciò consigliato seguire alcune regole speciche che semplicano la stesura del processo.

Non inserire nomi troppo lunghi negli oggetti che complicherebbero eccessi-vamente la visibilità complessiva dell'espressione.

Non utilizzare nomi di processi con carattere "_".

Non terminare i gateway con il carattere ";" prima della chiusura della parentesi ma inserirlo subito dopo.

Non concatenare direttamente due gateway fra di loro ma inserire sempre un task intermedio.

(54)

Non utilizzare più di tre livelli innestati rispetto a quello principale, per evitare complicazioni eccessive nella scrittura dell'espressione e nel successivo rendering graco.

Vericare sempre la correttezza formale di apertura e chiusura parentesi nel rispetto del usso logico del processo. In tal senso, si consiglia sempre di inserire una parentesi chiusa subito dopo una aperta e partire a scrivere l'espressione all'interno.

Vericare sempre la presenza di operazioni logiche (x + |) nei gateway e che tutte siano coerenti fra loro.

Inserire il carattere ";" anche al termine dei cicli e dei gateway, prima della chiusura delle parentesi.

Chiudere sempre un ciclo con ";" dopo i caratteri "*" e "@" tranne nel caso di gateway di chiusura processo, per il quale basta il "." al posto del ";" . non utilizzare parole e simboli riservati all'interno dei nomi, x + | * @ [ ] (

) ; , . = .

3.4 Riepilogo

In questo capitolo abbiamo descritto l'alfabeto utilizzato per costruire l'e-spressione che denisce il processo di business. Dopo la descrizione di tutti i caratteri e simboli utilizzati, descrivendo anche le scelte progettuali, abbiamo il-lustrato con alcuni esempi l'equivalenza fra un'espressione e il diagramma che

(55)

rappresenta. Abbiamo indicato il funzionamento del motore di parsing, conclu-dendo con l'indicazione di alcune regole e best practice per la scrittura corretta dell'espressione.

Nel prossimo capitolo ci concentreremo sulla parte di realizzazione eettiva, indicando i tool utilizzati e le scelte di implementazione nella realizzazione sica del motore.

(56)

Capitolo 4

REALIZZAZIONE

Nel capitolo precedente abbiamo illustrato le scelte progettuali e i vincoli impo-sti per rendere la struttura del linguaggio fruibile e semplice ma allo stesso tempo robusta.

Come già indicato, il motore si occupa, in fase di lavorazione principale, di eseguire l'analisi ricorsiva di una stringa di input opportunamente privata, ad ogni ricorsione, dei caratteri già analizzati.

In questo capitolo discuteremo inizialmente degli strumenti utilizzati per la realizzazione del motore. Successivamente illustreremo il diagramma delle classi, spiegando la struttura del modello realizzato. Inne analizzeremo tutte le princi-pali operazioni, le scelte implementative fatte per realizzarle ed eventuali problemi che abbiano portato ad una revisione dell'approccio di realizzazione.

(57)

4.1 Strumenti per lo sviluppo

Per permettere la portabilità del codice sorgente del motore e garantire la pos-sibilità di revisioni e sviluppi futuri, abbiamo deciso di puntare su una piattaforma di sviluppo largamente diusa nel mondo dello sviluppo software e che garantisca paradigmi di programmazione moderni. Abbiamo scelto di utilizzare quindi il lin-guaggio java, di cui si discutono brevemente i pro e i contro, dando per assodata la conoscenza almeno ad alto livello del linguaggio.

E' indipendente dalla piattaforma: una volta compilati i sorgenti, basta avere una Java Runtime Enviroment (JVM) installata su un computer perché il codice sia eseguibile.

Supporta la programmazione orientata agli oggetti, indispensabile per la struttura progettale scelta.

Ha una buona gestione delle eccezioni, che possono essere personalizzate e create.

E' abbastanza sicuro non permettendo accessi indesiderati ad aree di memo-ria che potrebbero portare problemi all'esecuzione dell'intero sistema. Mette a disposizione una piattaforma orientata alla realtà enterprise, con cui

poter aprire il motore anche per l'accesso su web.

Il principale aspetto negativo di Java è l'alto consumo di memoria, legato pro-prio alla sua struttura che non permette accessi immediati per la deallocazione di oggetti, non più utilizzati, in fase di lavorazione. Nel nostro caso il problema incide

(58)

in maniera marginale perché, a causa della complessità rappresentativa che assu-merebbe un processo altamente innestato o pieno di elementi, lavoreremo sempre con carichi di memoria leggeri.

La versione di Java utilizzata è la più recente, versione 11.0.1 del Java Deve-lopment Kit (JDK). Non si è fatto uso di altri strumenti per la programmazione, salvo che per alcune librerie, utilizzate per motivi di approfondimento, che verranno trattate nei prossimi paragra.

Per lo sviluppo abbiamo utilizzato l'IDE Eclipse 2018-09 installato su sistema MacOS. Per l'esecuzione di yaoqiang è stato necessario congurare una versione precedente di java per problemi di compatibilità.

4.2 Diagramma delle classi

Nella realizzazione del parser, anche a seguito delle considerazioni precedenti sull'occupazione di risorse e la bassa complessità dei processi realizzati, abbiamo deciso di costruire una struttura ad oggetti, mantenuta in memoria, che permetta di rimappare i singoli elementi inseriti. Partendo da questi elementi è possibile costruire sia il modello, sia la componente graca, mediante tag xml, generati a runtime. Si noti che la persistenza è garantita da salvataggio su disco dei pro-cessi tradotti in xml, per permettere agli utenti di costruire anche casistiche più complesse partendo da processi già memorizzati.

Per illustrare il modello implementativo, partiamo dal Class Diagram (g. 4.1) che permette di mappare le classi come entità, ognuna con delle proprietà e delle relazioni con altre entità.

(59)

(60)

Analizziamo singolarmente ognuna delle classi, prima di procedere ad illustrare i metodi per la creazione dell'xml.

4.2.1 Motore

La classe Engine è il cuore dell'applicazione, il motore vero e proprio, che si occupa di eettuare l'analisi dell'input in maniera ricorsiva, immagazzinando i componenti in una struttura ad oggetti e creare l'xml corrispondente agli oggetti costruiti.

Può essere invocato per quattro operazioni principali:

Mostrare una breve guida per l'utilizzo da terminale dell'applicazione Caricare un le di input contenente un processo o una collaboration

Costruire il modello xml corrispondente a una stringa del nostro linguaggio Caricare un le, restituendo un xml a video

Alcune funzionalità sono pensate in ottica di riuso futuro, specie se richiamato da applicazioni web.

Il motore è realizzato con pattern singleton, per garantirne la creazione di un'unica istanza, con costruttore protetto da metodo statico di accesso all'istanza corrente, In questo modo non potremo creare più oggetti di tipo motore, avendo di fatto un'unica istanza in memoria.

All'interno del motore ci occuperemo anche di creare la struttura ad albero contenente gli oggetti che rappresentano il nostro processo.

(61)

4.2.2 Elementi

Tutti gli oggetti che costituiscono l'albero del processo di business hanno carat-teristiche in comune. Si è scelto quindi di uniformarne il comportamento, denen-do un'interfaccia che utilizzeremo nella gestione di tutti i tipi di ritorno in fase di elaborazione. Abbiamo creato poi una classe astratta che, implementando l'inter-faccia per acquisirne il "comportamento", contiene al suo interno la denizione di metodi concreti, comuni a tutti gli oggetti. Avremo quindi un costruttore, metodi getter e setter, e l'implementazione di una versione di toString(), per la stampa di nome e tipo oggetto. Altri metodi, astratti, dovranno invece essere implemen-tati concretamente dai gli, perché ognuno ha specicità legate alla tipologia del componente.

Gli elementi che implementano l'interfaccia IElement ed estendono la classe astratta Element sono:

Collaboration Event Gateway Link Process Section Task

Vedremo i metodi principali di queste classi più nel dettaglio nei prossimi capitoli.

(62)

4.2.3 Errori

La classe ParseErrorException serve per catturare tutti gli errori riscontrati in fase di parsing, generalmente per formato dell'input sbagliato. Quando viene sol-levata un'eccezione, si fornisce all'utente un messaggio che permetta di identicare l'errore, e la posizione esatta in cui l'errore sia avvenuto.

Tipici esempi di errori di questo tipo sono:

errori nell'operazione di assegnazione a una collaboration; errori sintattici nell'inserimento dei simboli;

errori per omissione di attributi obbligatori.

4.2.4 Utility

Le classi di Utility sono classi statiche utilizzate per spostare parti di gene-razione dei tag o dell'xml che, altrimenti, occuperebbero spazio nei componenti principali, rendendo la gestione del codice più caotica.

4.2.5 Launcher

La classe MainClass permette di lanciare da riga di comando il parser per eseguire le operazioni precedentemente descritte. Accetta un parametro seguito dal nome del le di input e, se desiderato, dal nome del le di output. Il le di input dovrà avere formato testuale, con estensione txt, mentre il le di output è un le .bpmn, direttamente apribile sui tool graci come camunda e yaoqiang.