UNIVERSITA’ DEGLI STUDI DI PISA
Scuola di Ingegneria
CORSO DI LAUREA IN INGEGNERIA INFORMATICA PER
LA GESTIONE D’AZIENDA
TESI DI LAUREA
ANALISI, PROGETTAZIONE E DEFINIZIONE DI
UNO STANDARD D’INTERFACCIAMENTO PER
SIMULATORI DI PROCESSO AZIENDALE
BASATI SU LINGUAGGIO BPMN
Candidato:
Massimo Puccetti
Relatori
Ing. Mario Giovanni C. A. Cimino
Prof. Franco Failli
Ringraziamenti
Il mio primo ringraziamento va al Prof. Mario Cimino per avermi seguito durante lo svolgimento della tesi con consigli utili e per la continua disponibilità e prontezza neichiarimenti e suggerimenti.
Ringrazio mia madre per la tenacia che mi ha trasmesso fin da ragazzo. Ringrazio il Prof Franco Failli secondo relatore.
Ringrazio i miei compagni di studio in particolare Pierluigi Dell’arciprete, DanielePagano, Stefano Atzeni, Vanessa Scarna, per avermi, nonostante la differenza di età,fatto sentire un loro coetaneo.
Un ringraziamento speciale va alla mia compagna di vita Prof.ssa Maria LuciaMozzi per avermi incoraggiato ad andare avanti nei momenti più significativi del percorso di studio.
Il ringraziamento più grande che ha permesso tutto ciò va per un cristiano come me a “NOSTRO SIGNORE” credo che senza di Lui non sarebbe stato possibile arrivare fin qui.
“Il vinicitore e’ colui che non ha mai smesso di sognare” Nelson Mandela
1
1. Riassunto
La modellazione dei processi aziendali, per analizzarne e migliorarne le performance, ha riportato un crescente successo sin dalla sua introduzione negli anni ’80.
A oggi, il più affermato standard grafico di modellazione dei processi è Business Process Model and Notation (BPMN); la versione 2.0 è stata rilasciata all’inizio del 2011, dopo un lungo periodo di messa a punto e di attesa da parte degli addetti ai lavori.
In questa tesi s'intende fare un’analisi della situazione riguardante il panorama delle implementazioni software di BPMN 2.0 disponibili sul mercato; saranno fatte prove di simulazione dei vari tools per evidenziare le differenze di performance.
Tale analisi comparativa sarà il punto di partenza per definire una specifica strutturale e funzionale delle caratteristiche disponibili nei simulatori, che costituiscono un’estensione del linguaggio BPMN. Il BPMN è nato come notazione standard, ma sta progressivamente diventando una metodologia di modellazione e di esecuzione. È proprio sugli aspetti di esecuzione che i vendor aggiungono proprietà dinamiche ai vari costrutti per soddisfare specifiche esigenze. In questa tesi si cercherà di definire le proprietà rilevanti attraverso un'interfaccia indipendente dalla piattaforma con lo scopo di favorire il riuso di tali proprietà su più implementazioni. A tal fine sarà adoperato il linguaggio XML. Infine, si fornirà un modello logico e architetturale di base per implementare quest’approccio.
2
2. Sommario
1 Riassunto____________________________________________ 1 2 Sommario___________________________________________ 2 3 Indice figure_________________________________________ 4 4 Indice tabelle________________________________________ 7 5 5.1 5.2 5.3 5.4 5.5 Introduzione_________________________________________ BPM Business Process Modeling_________________________ Il ciclo di vita di un processo_____________________________ Una notazione standard per la modellazione dei processi_____ BPMN 1.x___________________________________________ BPMN 2.0___________________________________________ 8 8 9 14 16 16 6 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 Linguaggio BPMN_____________________________________ Introduzione al linguaggio BPMN_________________________ I diagrammi BPMN____________________________________ Tipi di processi in un modello BPMN______________________ I livelli di un processo__________________________________ Gli elementi del BPMN_________________________________ Forme______________________________________________ Connettori___________________________________________ Reparti______________________________________________ Elementi accessori____________________________________ Conclusioni BPMN____________________________________ 19 19 20 21 22 23 23 43 45 46 49 7 7.1 7.2 7.2.1 7.2.1.1 7.3 7.3.1 7.4 La Simulazione_______________________________________ La simulazione di processo e l’ottimizzazione_______________ La performance di processo_____________________________ Esempio con logizian__________________________________ Modellazione dei flussi di attività e determinazione degli scenari in un Hospital Emergency Center __________________ Parametri affetti da incertezza e ottimizzazione_____________ Un esempio_________________________________________ I parametri statistici___________________________________ 50 51 51 52 53 71 72 74 8 8.1 8.2 8.3 8.4 .8.5 8.6 8.7 8.8Analisi dei Tools di Simulazione basati su BPMN_____________ Software BPMN_______________________________________ Abacus______________________________________________ AccuProcess Modeler__________________________________ Adonis______________________________________________ Aris________________________________________________ Bizagi BPM Suite______________________________________ Bonita BPM__________________________________________ Enterprise Architect___________________________________ 76 76 78 79 80 81 81 84 84
3 8.9 8.10 8.11 8.12 8.13 8.14 8.15 8.16 8.17 8.18 8.19
IBM Business Process Manager__________________________ IGraf_______________________________________________ Innovator For Business Analysts__________________________ Inubit_______________________________________________ Iyopro______________________________________________ Logizian_____________________________________________ Mega Simulation______________________________________ Oracle BPM Suite_____________________________________ Savvion_____________________________________________ Signavio Process Editor_________________________________ Tibco Business Studio__________________________________
85 85 87 88 89 90 92 93 93 94 96 9 9.1 9.2 9.3 9.4 9.5 9.6 9.7 9.8 9.9 9.10 9.11
Selezione e analisi di alcuni Tool _________________________ Logizian_____________________________________________ Accuprocess Modeler__________________________________ BIMP (online simulator) ________________________________ Bizagi bmp Suite______________________________________ Enterprise Architect (Sparx System)_______________________ Abacus______________________________________________ Innovator For Business Analysts__________________________ Iyopro (online modeler and simulator) ____________________ Signavio Online_______________________________________ Dizionario delle caratteristiche___________________________ Approfondimenti su aspetti particolari delle features dei tools_
101 101 103 105 107 109 110 112 114 116 119 139 10 10.1 10.2 10.2.1 10.3 10.4 Progettazione Interfaccia_______________________________ Introduzione al design di Descrizione XML_________________ Design di Descrizione XML______________________________ Spiegazione dello schema_______________________________ Descrizione del Simulation Parameters____________________ Funzionamento Decisore_______________________________ 161 161 162 165 166 176 11 Conclusioni _________________________________________ 177 Bibliografia__________________________________________ 179
4
3. Indice delle figure
Figura 1 Ciclo di vita di un processo secondo BPM_______________ 9 Figura 2 La vita di un processo in un sistema BPMN_____________ 12 Figura 3 Simbolo di evento iniziale___________________________ 24 Figura 4 Nessun simbolo – evento iniziale_____________________ 25 Figura 5 Simbolo di evento messaggio________________________ 25 Figura 6 Simbolo di evento timer____________________________ 25 Figura 7 Simbolo di evento regola___________________________ 25 Figura 8 Simbolo di evento collegamento_____________________ 25 Figura 9 Simbolo di evento multiplo_________________________ 26 Figura 10 Simbolo di evento finale___________________________ 26 Figura 11 Nessun simbolo – evento finale______________________ 27 Figura 12 Simbolo di evento finale messaggio___________________ 27 Figura 13 Simbolo di evento finale errore_______________________ 27 Figura 14 Simbolo di evento finale cancellazione_________________ 27 Figura 15 Simbolo di evento finale compensazione_______________ 28 Figura 16 Simbolo di evento finale collegamento_________________ 28 Figura 17 Simbolo di evento finale terminazione_________________ 28 Figura 18 Simbolo di evento finale multiplo_____________________ 28 Figura 19 Simbolo di evento intermedio________________________ 29 Figura 20 Simbolo di evento intermedio – nessun simbolo_________ 30 Figura 21 Simbolo di evento intermedio messaggio_______________ 30 Figura 22 Simbolo di evento intermedio temporale_______________ 30 Figura 23 Simbolo di evento intermedio errore__________________ 31 Figura 24 Simbolo di evento intermedio cancellazione____________ 31 Figura 25 Simbolo di evento intermedio compensazione__________ 31 Figura 26 Simbolo di evento intermedio regola__________________ 32 Figura 27 Simbolo di evento intermedio collegamento____________ 32 Figura 28 Simbolo di evento intermedio multiplo________________ 32 Figura 29 Simbolo di attività_________________________________ 34 Figura 30 Simbolo di sottoprocesso___________________________ 34 Figura 31 Sottoprocesso che richiama se stesso__________________ 35 Figura 32 Sottoprocesso con più istanze________________________ 35 Figura 33 Sottoprocesso Ad Hoc______________________________ 35 Figura 34 Sottoprocesso di compensazione_____________________ 36 Figura 35 Simbolo di controllo basato sui dati___________________ 40 Figura 36 Simbolo di controllo basato sugli eventi________________ 40 Figura 37 Simbolo di controllo inclusivo________________________ 41 Figura 38 Simbolo di controllo parallelo (AND)___________________ 41 Figura 39 Simbolo di controllo complesso______________________ 42 Figura 40 Simbolo flusso di sequenza__________________________ 43 Figura 41 Simbolo flusso di sequenza, espressione condizionale_____ 44 Figura 42 Simbolo flusso di sequenza, espressione di default_______ 44 Figura 43 Simbolo di flusso di messaggio_______________________ 44
5 Figura 44 Simbolo di Associazioni_____________________________ 45
Figura 45 Un pool con due lane______________________________ 45 Figura 46 Oggetto di tipo dati________________________________ 47 Figura 47 Gruppi__________________________________________ 48 Figura 48 Annotazioni di testo_______________________________ 48 Figura 49 Diagramma BPMN Logizian__________________________ 56 Figura 50 Report della simulazione____________________________ 58 Figura 51 Scenari di simulazione______________________________ 59 Figura 52 Risultati in forma grafica simulazione__________________ 60 Figura 53 Completamento token______________________________ 61 Figura 54 Utilizzo risosrse___________________________________ 61 Figura 55 Code di attesa____________________________________ 62 Figura 56 Coda attesa più bilanciata___________________________ 62 Figura 57 Esempio di progettazione del layout__________________ 63 Figura 58 Modello di emulazione_____________________________ 63 Figura 59 Test case con gateway paralleli_______________________ 64 Figura 60 Scenario________________________________________ 64 Figura 61 Ulteriore scenario Logizian__________________________ 65 Figura 62 Modello di emulazione_____________________________ 66 Figura 63 Inserimento risorse________________________________ 66 Figura 64 Report di simulazione______________________________ 68 Figura 65 Token completati__________________________________ 68 Figura 66 Token completato_________________________________ 70 Figura 67 Simulazione con Abacus____________________________ 78 Figura 68 Avvio simulazione, pulsante start cerchiato in rosso______ 80 Figura 69 Scelte percentuali sul gateway_______________________ 82 Figura 70 Visione grafica della simulazione_____________________ 83 Figura 71 Risultati della prova di simulazione___________________ 86 Figura 72 Simulazione con Inubit_____________________________ 88 Figura 73 Simulazione con Logizian___________________________ 91 Figura 74 Grafici di simulazione Logizian_______________________ 92 Figura 75 Simulazione con Savvion___________________________ 94 Figura 76 Ambiente di simulazione di Signavio per il caso One Case__ 96 Figura 77 Aggiunta di partecipanti all’attività____________________ 99 Figura 78 Risultati della simulazione con il Software Tibico Business
Studio___________________________________________
99 Figura 79 Simulazione di Logizan_____________________________ 103 Figura 80 Simulazione di Accuprocess Modeler__________________ 105 Figura 81 Simulazione di BIMP (online simulator)________________ 107 Figura 82 Simulazione di Bizagi bpm Suite______________________ 108 Figura 83 Simulazione di Enterprise Architect (Sparx System)_______ 110 Figura 84 Simulazione di Abacus______________________________ 112 Figura 85 Simulazione d’Innovator For Business Analysts___________ 113 Figura 86 Simulazione di Iyopro (online modeller and simulator)____ 116 Figura 87 Simulazione di Signavio Online_______________________ 118 Figura 88 Le tre matrici ottenute con matlab____________________ 139
6 Figura 89 Simulazione AND e OR su Accuprocess_________________ 140
Figura 90 Validazione diagramma BPMN su Bizagi________________ 140 Figura 91 Simulazione parallelismo con un And su BIZAGI__________ 141 Figura 92 Parallelismo con due And Accuprocess_________________ 141 Figura 93 Parallelismo con un And Accuprocess__________________ 142 Figura 94 Simulazione parallelismo su Bizagi con due And_________ 142 Figura 95 Simulazione parallelismo Bizagi con un And e un Or______ 143 Figura 96 Simulazione su Logizian_____________________________ 144 Figura 97 Test case Iyopro___________________________________ 145 Figura 98 Parallelismo su Accuprocess_________________________ 146 Figura 99 Alert su Signavio__________________________________ 147 Figura 100 Diagramma con errore validazione BPMN______________ 148 Figura 101 Diagramma per test su BIMP_________________________ 148 Figura 102 Diagramma su Iyopro______________________________ 150 Figura 103 Test priorità su Iyopro______________________________ 150 Figura 104 Settaggio della priorità su Accuprocess________________ 152 Figura 105 Prova su Accuprocess______________________________ 153 Figura 106 Settaggio proprietà risorse Accuprocess________________ 153 Figura 107 Report priorità su Accuprocess_______________________ 154 Figura 108 Funzioni di distribuzione su Accuprocess_______________ 155 Figura 109 Impostazione tempo interarrivo su BIMP_______________ 155 Figura 110 Distribuzioni statistiche_____________________________ 156 Figura 111 Impostazione calendario custom su Accuprocess_________ 157 Figura 112 Impostazione calendario custom_____________________ 158 Figura 113 Architect Enterprise________________________________ 159 Figura 114 Testcase testato su Enterprise Architect________________ 160 Figura 115 Diagramma UML da trasformare in file XML____________ 162 Figura 116 Codice in XML che descrive le classi di fig. 115__________ 163 Figura 117 Schema per validare l’istanza creata___________________ 164 Figura 118 Schema logico dell’applicazione______________________ 165 Figura 119 Oggetti che l’interfaccia utilizza per la simulazione_______ 166 Figura 120 File XML schema dell’interfaccia______________________ 166/172
7
4. Indice delle tabelle
Tabella 1 Riepilogo dei parametri e dei vincoli________________ 55/56 Tabella 2 Tempo medio d’impiego_________________________ 56 Tabella 3 Configurazioni_________________________________ 57 Tabella 4 Attività relative alle risorse_______________________ 58 Tabella 5 Forma tabellare informazioni______________________ 59 Tabella 6 Ulteriori informazioni estratte_____________________ 60 Tabella 7 Report tabellare________________________________ 67 Tabella 8 Report tabellare________________________________ 69 Tabella 9 Distribuzione di alcuni parametri___________________ 74 Tabella 10 Tabella dei Software_____________________________ 77 Tabella 11 Disponibilità Software Tibico Business Studio_________ 100 Tabella 12 Quadro riassuntivo delle simulazioni effettuate secondo
l’ordine di analisi _______________________________
127/129 Tabella 13 Tabella 12 trasformata con matlab_________________ 129 Tabella 14 Quadro riassuntivo delle simulazioni effettuate secondo
l’ordine di freature______________________________
130/133 Tabella 15 Tabella 14 trasformata con matlab_________________ 134 Tabella 16 Caratteristiche comuni dei quattro tool_____________ 135/137 Tabella 17 Tabella 16 trasformata con matlab_________________ 138
8
5. Introduzione
5.1 BPM - Business Process Modeling
In questo capitolo si presenterà il concetto di Business Process Modeling, ripercorrendone brevemente la storia per indicarne gli scopi e introducendo alcuni esempi dei paradigmi software e delle notazioni utilizzate per implementarlo. In particolare, si vedrà come una di queste notazioni, BPMN, abbia ottenuto il favore delle diverse figure professionali cui la disciplina BPM si rivolge, arrivando a imporsi come standard de facto.
La pratica del BPM nasce a cavallo fra la fine degli anni ’80 e l’inizio del 1990 con l’intento di “supportare i processi di business utilizzando metodi, tecniche e software per progettare, mettere in atto, controllare e analizzare i processi operativi che coinvolgono risorse umane, organizzazioni, applicazioni, documenti e altre fonti d’informazione” . Si vogliono rappresentare con un modello i processi produttivi e organizzativi di un’azienda in modo da poterne analizzare il funzionamento e migliorare le performance.
Le persone interessate sono principalmente gli analisti (o business analysts), il cui compito è studiare il funzionamento dell’azienda e dei suoi processi produttivi, organizzativi, crearne il modello ed eseguire su di esso le operazioni di simulazione, raccolta dati e aggiornamento, e i manager, che devono compiere scelte di politica aziendale, in base ai dati forniti loro dagli analisti, per migliorare il modello esistente.
9
5.2 Il ciclo di vita di un processo
Il concetto di BPM è rappresentato come un ciclo di miglioramenti successivi. Partendo da un design di modello, si esegue su di esso una simulazione e se ne analizzano i risultati; si procede a un’ottimizzazione che porti verso i risultati desiderati e da questa si ricava un nuovo modello migliorato (figura 1).
La creazione del modello parte da una fase di analisi della catena produttiva da svolgere all’interno dell’azienda, durante la quale si compie un lavoro di discernimento dei processi interni; questo lavoro inizia, tipicamente, con lo svolgere una serie d’interviste al personale impiegato ai diversi livelli dell’azienda stessa, dall’operaio al personale amministrativo fino ai dirigenti. È necessario che tali interviste vadano a coprire tutti i punti di vista di chi lavora nei vari ruoli della catena produttiva, per poterle poi raccogliere, interpretare e integrare in una descrizione dei processi che sia quanto più possibile completa e dettagliata.
Questa parte del lavoro di modellazione va a costruire le fondamenta dei cicli successivi, ed è quindi necessario che sia eseguita in maniera sistematica e accurata.
10 Il modello ottenuto da questo lavoro di modellazione rappresenta lo stato corrente della catena di processi all’interno dell’azienda sotto osservazione e viene perciò definito modello as is, cioè “così come stanno le cose”. Una volta formulato tale modello iniziale, segue una fase di analisi dei dati concernenti i processi individuati, come, ad esempio, il costo di un prodotto finito oppure il tempo necessario per portare a termine una lavorazione. Tali dati possono essere già disponibili in quantità sufficiente, magari grazie all’esistenza di un sistema di tracciabilità interno, oppure possono essere generati in modo verosimile e in quantità sufficiente con un’operazione di simulazione del funzionamento del processo modellato. Raccolta una sufficiente mole di dati concernenti il modello as is, si procede a una fase di analisi delle performance, studiando i risultati ottenuti e confrontandoli con gli obiettivi di business prefissati; correggendo i difetti più evidenti del modello si arriva alla formulazione di un nuovo modello ottimizzato, che è detto to be, cioè “così come dovrà diventare”.
Lo scopo ultimo della disciplina del Business Process Modeling è quindi proprio quello di poter ottimizzare i processi aziendali allo scopo di aumentarne le performance. A causa di un bacino di clientela e di una concorrenza sempre più globalizzati, il mercato odierno propone sfide sempre più pressanti ai manager aziendali, che si trovano a dover compiere scelte di business complesse per far fronte, fra l’altro, a:
- commesse da smaltire rapidamente;
- diversificazione delle commesse per quantità richieste e deadlines da rispettare;
- una sempre più vasta competizione nazionale e internazionale;
11 Nei primissimi anni ’90 la pratica del BPM era ancora lontana dall’essere affiancata dal supporto della tecnologia informatica dell’epoca: i dati delle interviste e quelli concernenti le analisi prestazionali, ad esempio, dovevano essere raccolti a mano tramite registrazioni o moduli prestampati, senza avere nessun software a disposizione che potesse aiutare gli analisti nella loro archiviazione e soprattutto elaborazione. Negli anni successivi la necessità di informatizzare questo settore in rapida diffusione si fece via più urgente; questo fatto contribuì alla proliferazione di diverse soluzioni metodologiche, ognuna delle quali era in competizione con le altre per imporsi come standard . Tale rapida crescita ha però portato con sé numerosi svantaggi:
- confusione fra differenti metodologie e terminologie;
- funzionalità replicate fra soluzioni diverse, oppure completamente assenti da tutte le soluzioni a disposizione;
- mancanza di formalismi ben definiti, e assenze ancora più gravi dal punto di vista delle validazioni, spesso non eseguite o non superate.
Nella fase iniziale dello sviluppo di un nuovo settore, di tale importanza e complessità, riuscire a trovare un paradigma che fosse universalmente accettato come standard di riferimento doveva essere la necessità principale. Da qui si sarebbe potuto trovare un punto d’incontro per quanto riguardasse la metodologia, la notazione e la terminologia utilizzate, per poi definire per tale standard un’implementazione software che seguisse tali riferimenti.
12
Figura 2: La vita di un processo in un sistema BPMS
BPM è riuscito a imporsi come standard de facto sugli altri paradigmi di modellazione dei processi (come ad esempio Workflow Management, WfM) proprio grazie all’inclusione di una fase di analisi delle performance da cui ricavare un giudizio o una diagnosi numerica sulla bontà del modello correntemente implementato, per individuarne i problemi esistenti come ad esempio i colli di bottiglia. Una volta che tutti i maggiori operatori del settore si sono trovati d’accordo sull’adozione di BPM come disciplina da portare avanti come standard, si è riproposto il problema della frammentazione, dovuta a implementazioni software diverse. Dal 2003, con la nascita dei cosiddetti sistemi Business Process Management System (BPMS), pacchetti software integrati che permettono di modellare i processi, renderli eseguibili, raccoglierne i dati, archiviarli e analizzarli, è stata creata una piattaforma tecnologica che supporti l’intero ciclo di vita di un processo definito da BPM. Com’era già successo durante il processo di affermazione del paradigma BPM, attorno a questa categoria di software, si è manifestato grande interesse sia da parte degli analisti, che avrebbero potuto trarre molti vantaggi nell’utilizzo dei BPMS come ausilio alla modellazione e all’analisi, che da parte degli
13 sviluppatori, che hanno immediatamente visto in queste nuove soluzioni una grande opportunità di ritorno economico.
Si è sviluppato così, in modo molto rapido, un enorme giro di affari e i pacchetti software BPMS sono andati a formare un mercato a sé; si è quindi assistito a una nuova, rapida proliferazione della varietà di linguaggi utilizzati, di proposte di standard e notazioni, spesso discordanti o contrastanti e, soprattutto, di un enorme parco di soluzioni software. In diversi casi, pur di uscire sul mercato e concorrere per una fetta della torta, alcuni sviluppatori non implementavano ancora tutto il ciclo di vita dei processi nei propri programmi. Il caso più frequente era che i pacchetti BPMS non avevano funzioni di Business Activity Monitoring (BAM) dedicate alla valutazione delle metriche e delle performance di processo, e gli utenti si dovevano appoggiare a software esterni dedicati pereseguire operazioni di analisi e diagnostica dei processi modellati, incappando in nuovi costi e aumentando la complessità di utilizzo.
Subito dopo la nascita dei primi bpms, la frammentazione è stata resa ancora più efficace dall’arrivo delle soluzioni basate sul paradigma architetturale Service Oriented Applications (SOA), in altre parole sistemi software distribuiti basati sul web, che permettono di avere un’evoluzione più rapida e agile del software stesso. Tramite il modello SOA un programma complesso può essere scomposto in servizi modulari più semplici, che possono essere sviluppati e mantenuti separatamente gli uni dagli altri; ciò che interessa è l’interfaccia che il singolo servizio rende disponibile verso l’esterno (in questo caso, tale interfaccia viene “annunciata” sul web e il servizio reso pubblico) e non la sua implementazione interna.
A metà degli anni 2000 c'è stata una solida affermazione di BPM come “disciplina standard”, ma all’atto pratico ne esistevano svariate implementazioni, spesso in contrasto fra loro per
14 terminologia o metodo di realizzazione, oppure dedicate a una sola delle fasi del ciclo di vita di un processo, come la modellazione oppure l’analisi delle performance. Una breve lista potrebbe comprendere:
- Business Process Modeling Notation (BPMN), una notazione per la rappresentazione grafica dei modelli di business;
- Business Process Execution Language (BPEL), un linguaggio basato su estensibile Markup Language (XML) (quindi con modellazione dei processi basata sulla scrittura di codice e non grafica) dedicato all’implementazione dei processi;
- XML Process Definition Language (XPDL) e Yet Another Workflow Language (YAWL), ancora basati su XML ma comprendenti sia strumenti di design (anche visuali) che soluzioni per l’implementazione. YAWL, in particolare, essendo basato su una semantica formale, ha permesso la nascita di alcuni strumenti per l’analisi dei processi modellati su di esso.
5.3 Una notazione standard per la modellazione dei processi
Dovrebbe essere ormai chiaro come la necessità primaria fosse quella di trovare un punto d’incontro per quanto riguardava:
- uno standard visuale di progettazione del modello di business;
- uno standard d’implementazione software del processo;
- uno standard per la misurazione delle performance di business e per l’analisi dei risultati;
15 La preferenza era ovviamente verso uno standard che permettesse di modellare i processi in maniera visuale, rendendoli molto più human-readable e fruibili anche da parte di lettori privi di una preparazione tecnica specifica.
5.4 BPMN 1.x
Tramite BPMN, i processi di business sono rappresentati come diagrammi di flusso denominati Business Process Diagrams o BPD. Un diagramma BPD rappresenta un processo complesso scomponibile in una serie di attività atomiche collegate da connettori e controlli di flusso che descrivono i rapporti sequenziali fra le attività stesse e il loro ordine di esecuzione (non sempre sequenziale, alla presenza di punti decisionali). La simbologia, ad alto livello, di un diagramma BPD è simile a quella di UML e altre notazioni grafiche, ma presenta una semantica molto più precisa. In questo modo i diagrammi possono essere compresi in modo pressoché immediato da tutti i loro possibili diversi utilizzatori, partendo dagli analisti che devono creare la rappresentazione iniziale dei processi di business, passando per gli sviluppatori che devono implementarli e renderli eseguibili, fino ad arrivare agli utenti finali, cioè gli operatori dell’azienda che ne utilizzeranno l’implementazione, e ai manager, che dovranno analizzare i dati così raccolti, capirne il significato e trarne considerazioni, risultati e decisioni di management aziendale.
Il principale vantaggio di BPMN rispetto ad altre notazioni è quindi la sua intuitività verso differenti tipologie di utenza (accessibilità e human readability). La notazione si propone inoltre di fornire un ponte fra la rappresentazione grafica di un processo mediante uno o più diagrammi di flusso e una sua implementazione in termini di codice eseguibile, sia esso un software tradizionale o basato su una piattaforma distribuita come le SOA. Il modello interno di
16 BPMN 1.x avrebbe dovuto soddisfare questo requisito (machine readability) permettendo una facile esportazione di un diagramma in un linguaggio serializzato basato su XML e dedicato all’esecuzione dei processi come BPEL o BPEL4WS (Business Process Execution Language For Web Services).
Nella sua prima versione, BPMN non riusciva a mantenere appieno queste promesse, avendo in particolare due gravi mancanze: BPMN 1.x, infatti, non prevedeva la definizione di un formato d’interscambio serializzato, ben strutturato e non garantiva la completa corrispondenza con il linguaggio BPEL; non sempre un processo modellato in BPMN poteva essere mappato sul linguaggio BPEL con una corrispondenza 1:1, ma occorreva fare delle modifiche per adattarlo prima della conversione. Il principale problema derivante dalla prima di queste due mancanze era la scarsissima compatibilità fra i vari strumenti di modellazione BPMN. Spesso e volentieri la necessità di migrare i propri diagrammi esistenti verso un nuovo tool aveva come unica soluzione quella di ridisegnarli da capo. Lo standard prevedeva, infatti, la definizione del significato di ciascuna forma o shape, ma non quella di uno schema XML standard.
5.5 BPMN 2.0
Queste due mancanze, insieme a molti altri miglioramenti dell‘espressività e dell’implementazione, sono state risolte con la seconda major release della notazione, che il consorzio BPMI, nel frattempo assorbito dall’Object Management Group (OMG) ha rilasciato nella versione 2.0 definitiva nel mese di Gennaio 2011. Nella stessa occasione, per rilevare l’importanza delle modifiche apportate allo standard, è stato deciso di modificare il significato dell’acronimo BPMN, che dalla versione 2.0 si traduce con Business Process Model and Notation. In questo modo è stato evidenziato come, all’interno della stessa specifica, si vogliano
17 mantenere indipendenti fra loro la notazione grafica utilizzata per la descrizione visuale dei processi di business e il modello che sta alla base. Così si tende a preferire la portabilità dei processi modellati fra strumenti BPMN-compliant prodotti da diversi sviluppatori e a garantire che le definizioni di tali processi restino valide nel caso ci sia il bisogno di trasportarle verso una diversa specifica basata sulla disciplina BPM, che condivida il modello di BPMN ma eventualmente non la sua notazione.
Si è parlato in precedenza di come, in passato, il campo dello studio dei processi di business era frammentato in una miriade di diverse notazioni, ciascuna con i propri strumenti di modellazione, spesso incompatibili fra loro per significato della terminologia, oppure senza un legame reale con un linguaggio eseguibile. Le diverse figure coinvolte nella modellazione dei processi erano così limitate nello scambio d’informazioni, e l’interoperabilità (non solo dei software, ma anche a livello umano) fra diverse società che adottavano notazioni differenti era molto difficile, se non impossibile. Il lavoro richiesto al settore IT, per implementare il modello finito, era spesso complicato, esposto a errori, le procedure di sviluppo software finivano con il diventare incomprensibile sia per gli analisti sia per i manager. BPMN, proponendosi come standard, ha cercato di risolvere tutti questi problemi, garantendo una semplice collaborazione fra realtà diverse e la trasparenza delle operazioni effettuate in tutte le fasi dello studio del processo sotto esame. Con la versione 2.0 della specifica si è cercato di venire incontro agli analisti e a chi si occupa di modellare i processi aziendali introducendo un meccanismo di estensibilità della notazione. In questo modo, chi ne avesse bisogno, per descrivere casi particolari, può estendere gli attributi di un elemento di BPMN, mantenendone valide le proprietà di base. La specifica pone dei vincoli a questa possibilità imponendo che tali estensioni non alterino in nessun modo la semantica o l’aspetto degli elementi predefiniti della
18 notazione, in particolare gli elementi “primitivi” come eventi, attività e gateway, la cui descrizione sarà fatta in seguito. BPMN 2.0 definisce nuovi modelli di diagramma, passando dal generico Business Process Diagram della versione 1.x alla coppia Process e Collaboration Diagrams (il primo dettaglia i processi privati di un partecipante, mentre il secondo riguarda l’interazione fra partecipanti diversi); è aggiunto un Choreography Diagram per rappresentare in modo diverso il flusso di messaggi e un Conversation Diagram per accorpare tale flusso in maniera sintetica. Ciascuno di questi modelli è rivolto a un diverso target di utilizzatori, per rappresentare processi complessi in maniera intuitiva.
BPMN 2.0 si propone di “fornire una notazione e un modello” per i processi di business, uniti a un formato d’interscambio che può essere usato per scambiare le definizioni di processi BPMN. I principali elementi di novità di questa major release si possono quindi riassumere con:
- una formalizzazione ben definita delle semantiche di esecuzione di tutti gli elementi della notazione;
- la definizione di un meccanismo di estensibilità della notazione, sia per il modello sia per gli elementi grafici;
- l’introduzione di nuovi modelli di diagramma, volti a descrivere diversi aspetti dei processi aziendali;
- l’aggiunta di nuovi elementi grafici per raffinare alcune costruzioni semantiche ed eliminare possibili equivoci nell’interpretazione dei diagrammi.
19
6. Linguaggio BPMN
6.1 Introduzione al linguaggio BPMN
Il BPMN fornisce un meccanismo di visualizzazione standard per i processi aziendali definito tramite un linguaggio d’esecuzione specializzato nei processi aziendali. Il BPMN fornirà alle aziende la capacità di comprendere le loro procedure interne in una notazione grafica e darà all’organizzazione l’abilità di comunicare tali procedure in maniera standard. Correntemente esistono numerosi strumenti e metodologie per modellare i processi. Dato che le persone si spostano da un’azienda all’altra e che queste hanno continuamente rapporti tra loro, è verosimile che agli analisti aziendali sia richiesto di comprendere più rappresentazioni dei processi aziendali e potenzialmente differenti rappresentazioni dello stesso processo per tutto il suo ciclo di vita, sviluppo, implementazione, esecuzione, monitoraggio e analisi. Una rappresentazione standard facilita la comprensione delle attività collaborative e delle transazioni aziendali all’interno e tra le aziende. Questo consente alle aziende di incrementare la loro comprensione e le loro parti per adeguarsi velocemente alle situazioni sia interne sia di Business to Business. Il BPMN è adatto a supportare la modellazione dei processi aziendali. Ciò significa che altre tipologie di modellazione realizzate per scopi aziendali saranno fuori portata per il BPMN. Per esempio, non sarà compito del BPMN modellare le strutture organizzative e le risorse, i guasti funzionali, i modelli di dati e le informazioni, le strategie, e le regole d’impresa.
20
6.2 I diagrammi BPMN
L’acronimo BPMN sta per Business Process Modeling Notation: notazione per la modellazione di processi aziendali. Si tratta di una notazione standard di mappatura dei processi aziendali. Tramite il BPMN sarà possibile ricreare il sistema azienda tramite un modello software che ne simuli il funzionamento. Si ha la possibilità di avere reparti mobili, cioè non contigui, e di rappresentare non solo sequenze di attività, ma anche “insiemi di attività”, non necessariamente consecutivi.
I reparti, anche suddivisi in corsie o swimlanes, sono popolati con forme e architettati secondo certe regole: i cerchi rappresentano gli eventi, i rettangoli emulano le operazioni e i rombi raffigurano il controllo sui flussi; inoltre si possono inserire elementi accessori ovvero alcune forme grafiche che hanno lo scopo di facilitare la comprensione della sequenza.
Un’altra novità è la distinzione grafica tra i connettori di flusso: a linea continua, preposti a rappresentare il flusso fisico tra le attività lungo il processo, e a linea tratteggiata, che indicano flussi di messaggi; questi ultimi danno indicazione del flusso informativo connesso al processo. Il BPMN consente anche di implementare processi ad hoc in cui non è indispensabile conoscere la sequenza delle operazioni, o comunque essa non è nota.
Le quattro categorie base di elementi del BPMN sono: Forme (Flow objects), Connettori (Connecting objects), Reparti (Swimlanes) ed Elementi accessori (Artifacts).
Lo sviluppo della notazione in BPMN ha come scopo quello di ridurre la frammentazione esistente nella miriade di strumenti di notazioni e di modellazione dei processi. Si è cercato di trarre le migliori idee dalle notazioni più affermate già esistenti, tra le quali l’UML, l’IDEF, il workflow tradizionale e altri, in parte noti. Queste frammentazioni e disparità hanno spesso
21 impedito l’adozione generalizzata di un sistema standard di modellazione dei processi interaziendali.
Un altro importante scopo è creare un raccordo tra la notazione di modellazione dei processi aziendali e i linguaggi d’esecuzione, in modo da garantire l’implementazione dei processi in un sistema di gestione.
6.3 Tipi di processi in un modello BPMN
La modellazione dei processi aziendali è usata per comunicare un’ampia gamma d’informazioni a svariati destinatari. Il BPMN deve considerare diversi tipi di modellazione per permettere la creazione di modelli d’interi processi aziendali.
I tre tipi base di sotto-modelli all’interno di un modello BPMN sono i seguenti:
processi aziendali privati (interni);
processi astratti (pubblici);
processi collaborativi (globali).
La terminologia usata per descrivere i differenti tipi di processi non è standardizzata e le definizioni dei termini sono in continua evoluzione.
I processi aziendali privati si focalizzano in genere sul punto di vista di una singola azienda. I processi interni definiscono per lo più le attività non generalmente visibili al pubblico, anche se spesso mostrano interazioni con partecipanti esterni. Nella normativa del BPMN, i flussi fisici di processo sono contenuti all’interno di un singolo pool e non possono attraversarne i confini. I flussi informativi, invece, possono transitare tra un pool e l’altro.
22 I processi astratti rappresentano le interazioni fra un processo privato e un altro partecipante. Sono comprese nel processo pubblico solamente quelle attività atte a comunicare al di fuori del processo privato e i meccanismi mirati a controllare i flussi di processo. Di fatto, il processo privato esprime la sequenza dei messaggi che servono per l’interazione con il processo pubblico. I processi astratti sono contenuti all’interno di un pool e possono essere modellati separatamente oppure all’interno di un diagramma più ampio; lo scopo è di mostrare i flussi di messaggio fra le attività del processo pubblico e le altre entità.
I processi collaborativi descrivono le interazioni tra due o più entità aziendali in un contesto B2B (Business to Business). I diagrammi di questi tipi di processo sono in genere costruiti da un punto di vista globale. Essi quindi non prendono in esame il punto di vista di uno specifico partecipante, ma mostrano le interazioni tra i partecipanti, descritte tramite lo scambio di messaggi e informazioni tra le sequenze di attività. I processi di collaborazione possono essere visti come due o più processi pubblici tra loro comunicanti.
6.4 I livelli di un processo
Il BPMN definisce il termine “processo” in maniera univoca e descrive i processi aziendali in modo generale come “un insieme di attività eseguite da un’azienda tra più aziende”.
Nel BPMN, un processo è raffigurato come un grafico contenente oggetti di flusso, che rappresentano una sequenza di attività e controlli. Il concetto di processo è intrinsecamente gerarchico e può quindi essere definito su più livelli.
La modellazione dei processi aziendali parte spesso dalla definizione delle attività ad alto livello per poi aumentare il dettaglio in diagrammi separati. Il BPMN non impone regole precise sui
23 livelli di un processo e quindi la scelta sul numero di livelli di diagrammi che si possono avere dipende dalle preferenze espresse dai modellatori.
6.5 Gli elementi del BPMN
Come già detto in precedenza, le quattro categorie base di elementi del BPMN sono:
Forme (Flow objects)
Connettori (Connecting objects) oReparti (Swimlanes)
Reparti(Swinlane)
Elementi accessori (Artifacts).6.6 Forme
Un diagramma BPMN, chiamato nel seguito BPD, Business Process Diagram, può presentare al suo interno tre tipi fondamentali di forme:
Eventi
Attività
Controlli.
Un Evento è rappresentato da un cerchio e simboleggia qualcosa che accade durante il corso di un processo aziendale. Questi eventi influiscono nel flusso di processo e usualmente hanno una causa scatenante e un impatto sul processo. Gli eventi sono cerchi con i centri vuoti per permettere, tramite differenti icone al loro interno, di identificare differenti cause o risultati. Si possono distinguere tre tipi di eventi, in base al momento nel quale essi influiscono sul flusso: Inizio, Intermedio e Fine.
24 Gli eventi di tipo iniziale hanno triggers, vale a dire cause o inneschi, che ne determinano le caratteristiche. Questi tipi di eventi indicano dove e come un processo avrà origine. Per quanto riguarda la sequenza di flusso, gli eventi iniziali danno il via al flusso del processo e quindi, per definizione, non possono essere preceduti da una sequenza entrante a monte. Le principali caratteristiche dell’evento iniziale sono:
un evento iniziale può non essere presente all’interno del processo;
per ogni evento di tipo fine deve esistere almeno un evento di tipo inizio;
se il processo è complesso e/o le condizioni di partenza non sono evidenti, allora l’uso dell’evento inizio è raccomandato;
l’evento inizio è l’unico elemento del flusso che non ammette la presenza di un flusso di sequenza a monte;
• possono esistere più eventi iniziali indipendenti per un dato processo parallelo
Esistono differenti modi attraverso i quali un processo aziendale può essere attivato. L’attivazione di un evento iniziale può essere di vario tipo, ed è indicata graficamente dall’icona dentro il simbolo dell’evento.
Figura 3: Simbolo di evento iniziale
Le sei simbologie per denotare questi eventi nel BPMN con le relative icone sono le seguenti:
Nessun simbolo: il modellatore non mostra il tipo di evento ed è usato anche all’inizio di un sottoprocesso;
25
Figura 4: Nessun simbolo - evento iniziale
Messaggio: un partecipante fa partire un messaggio che dà il via alprocesso;
Figura 5: Simbolo di evento messaggio
Timer: il processo ha origine in un particolare momento;
Figura 6: Simbolo di evento timer
Regola: il processo ha inizio nel momento in cui avvengono determinate condizioni;
Figura 7: Simbolo di evento regola
Collegamento: meccanismo per connettere la fine di un processo con l’inizio di un altro. Tipicamente ci sono due sottoprocessi dentro lo stesso processo genitore;
Figura 8: Simbolo di evento collegamento
26 richiesto solo uno. L’evento iniziale definirà quali dei vari tipi d’innesco attivare.
Figura 9: Simbolo di evento multiplo
Gli eventi di tipo finale indicano come e dove termina un processo. In termini di flusso di sequenza, questi tipi di eventi terminano il flusso del processo e quindi non possono avere un altro flusso in uscita. Gli eventi finali sono rappresentati da un cerchio dal bordo nero spesso:
Figura 10: Simbolo di evento finale
Le principali caratteristiche dell’evento finale sono:
un processo può avere più eventi finali
l’evento finale può non essere presente nel diagramma;
per ogni evento iniziale deve esserci almeno un evento finale;
da un evento di tipo fine non può scaturire alcun flusso di sequenza in uscita.
Se non si ricorre all’evento finale, tutte le forme, senza successivi flussi in uscita, sono marcate in modo da indicare la fine del processo.
Le otto simbologie per denotare questi eventi finali nel BPMN con le relative icone sono le seguenti:
Nessun simbolo: il modellatore non mostra il tipo di evento; viene anche usato per mostrare la fine di un sottoprocesso, quando le transazioni del sottoprocesso sono
27 restituite al processo principale;
Figura 11: Nessun simbolo - evento finale
Messaggio: questo tipo di evento finale indica l’invio di un messaggio da parte di un partecipante nel momento in cui si finisce il processo;
Figura 12: Simbolo di evento finale messaggio
Errore: questo tipo di evento indica che dovrebbe essere generato unerrore;
Figura 13: Simbolo di evento finale errore
Cancellazione: questo tipo di evento è usato all’interno di un sottoprocesso. Indica l’annullamento della transazione e genera un evento intermedio di tipo cancellazione che indica l’invio di un messaggio a tutte le entità coinvolte nel processo;
Figura 14: Simbolo di evento finale cancellazione
Compensazione: questo tipo di evento finale indica il ricorso a una compensazione che diventa un’attivazione per un evento intermedio nel momento in cui il processo torna indietro;
28
Figura 15: Simbolo di evento finale compensazione
Collegamento: è un meccanismo per connettere la fine di un processo con l’inizio di un altro. Generalmente vi sono due sottoprocessi dentro lo stesso processo genitore, e un token che arriva a un evento finale di tipo collegamento salta al corrispondente evento iniziale o intermedio al quale fa riferimento.
Figura 16: Simbolo di evento finale collegamento
Terminazione: questo tipo di evento indica che devono terminare tutte le attività di processo all'istante;
Figura 17: Simbolo di evento finale terminazione
Multiplo: indica che si possono avere molti modi nei quali il processo può terminare e l’evento finale definirà quale risultato applicare;
Figura 18: Simbolo di evento finale multiplo
Gli eventi di tipo intermedio hanno luogo tra un evento iniziale ed uno finale, cioè dopo l’istanza di un processo. Condividono la stessa forma di base dell’evento iniziale e finale ossia un cerchio con un centro aperto, in modo da poter collocare eventuali icone.
29 Gli eventi di tipo intermedio sono rappresentati da un cerchio con i bordi formati da una doppia linea sottile:
Figura 19: Simbolo di evento intermedio
Gli eventi intermedi possono essere usati per mostrare in che punto del processo si aspetta la ricezione o si attua l’invio dei messaggi e per mostrare i ritardi attesi all’interno del processo e il lavoro extra necessario per le attività di compensazione.
Questi tipi di eventi vengono anche usati per interrompere il normale flusso attraverso la rappresentazione delle eccezioni o la gestione delle compensazioni.
Gli eventi intermedi possono essere collegati in qualsiasi punto del bordo dell’attività e il flusso che ne origina può scorrere in ogni direzione. Le nove simbologie per denotare gli eventi intermedi nel BPMN con le relative icone sono le seguenti:
Nessun simbolo: questo tipo di evento non è mostrato dal modellatore e può essere usato solo
nel flusso principale del processo. Esso è impiegato per indicare alcuni cambiamenti nello stato del processo;
30 Messaggio: il partecipante (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 flusso che gestisce gli eventi eccezionali.
Nel flusso “normale” gli eventi di messaggio intermedi possono essere usati per inviare messaggi a un partecipante. Se usato nella gestione delle eccezioni, questo modificherà il flusso da normale a eccezionale;
Figura 21: Simbolo di evento intermedio messaggio
Temporale: questo tipo di evento può innescare una transazione nel processo in un
determinato istante. Se è usato nel flusso principale, può anche dare origine a un ritardo altrimenti, se è utilizzato per gestire le eccezioni, può trasformare il flusso normale in flusso eccezionale;
Figura 22: Simbolo di evento intermedio temporale
Errore: questo tipo di evento è usato sia per stabilire la probabilità di errore sia per fissare le
relative norme di reazione; l’evento imposta un errore se questo rientra nel flusso del processo e reagisce all’errore quando è innestato nel bordo di un’attività;
31
Figura 23: Simbolo di evento intermedio errore
Cancellazione: questo tipo di evento intermedio è usato all’interno dei sottoprocessi e deve
innestarsi nel bordo. L’evento si attiva nel momento in cui avviene la ricezione di un messaggio di tipo cancellazione durante l’esecuzione del sottoprocesso;
Figura 24: Simbolo di evento intermedio cancellazione
Compensazione: questo evento è impiegato per porre rimedio o tarare una situazione esistente.
Si parla di “Compensazione” se l’evento è situato lungo il flusso normale del processo, mentre si tratta di “Richiesta di compensazione” se l’evento è collegato al bordo di un’attività;
Figura 25: Simbolo di evento intermedio compensazione
Regola: questo metodo è impiegato solo per la gestione delle eccezioni e si origina al verificarsi
32
Figura 26: Simbolo di evento intermedio regola
Collegamento: è un meccanismo per connettere un evento finale (risultato) di un processo con
un evento intermedio (attivazione) in un altro processo. Eventi intermedi appaiati possono anche essere usati come oggetti del tipo “Vai a” dentro un processo;
Figura 27: Simbolo di evento intermedio collegamento
Multiplo: questo metodo consente di allocare più attivazioni di un evento; si applica solo uno
dei modi possibili, in funzione degli attributi dell’evento intermedio.
Figura 28: Simbolo di evento intermedio multiplo
Un’Attività rappresenta una delle generiche fasi elementari nelle quali può essere scomposto un processo. Le attività possono essere a loro volta atomiche o non, ossia composte, a seconda che possano o non essere ulteriormente scomposte in passi più semplici. Nel primo caso sono dette Compiti (Task), nel secondo caso Sottoprocessi (Sub-Process).
Un task è un’attività atomica inclusa all’interno del processo. Si fa ricorso al task quando l’attività all’interno del processo non deve essere dettagliata ulteriormente.
Un task può rappresentare la meta di un flusso di sequenza e può avere flussi di entrata multipli, paralleli o esclusivi; se si hanno più flussi in entrata, questi sono considerati
33 incontrollati. Ciò significa che, quando un token arriva da uno dei percorsi, s’istanzierà il task senza attendere l’arrivo dei token provenienti dagli altri percorsi. All’arrivo di un altro token (dallo stesso o da un altro processo), sarà creata un’altra richiesta separata del task. Se il flusso deve essere controllato, va convogliato in una forma di controllo antecedente il task. Se il task non possiede dei flussi di sequenza in entrata e manca l’evento iniziale del processo, allora il task deve essere inizializzato insieme al processo.
Il task può essere l’origine di un flusso di sequenza e può avere più flussi in uscita; questo implica che si sta creando un percorso parallelo separato per ogni flusso.
Se il task non possiede dei flussi di sequenza in uscita e se manca l’evento finale, allora è compito del task stesso indicare il termine di uno o più percorsi nel processo.
Tutti i flussi di messaggio devono collegarsi al bordo di due pool separati o agli oggetti di flusso all’interno dei pool: non possono tuttavia collegare due oggetti all’interno dello stesso pool. Un task può fungere da meta per un flusso di messaggio e può essere l’origine di uno o più flussi di messaggio uscenti.
Il task è rappresentato graficamente mediante un rettangolo con gli angoli arrotondati tracciato con una linea sottile.
Figura 29: Simbolo di attività
Un sottoprocesso è un’attività inclusa nel processo, é composta e può essere suddivisa in altre sottoattività di maggior dettaglio.
34 Un sottoprocesso condivide la stessa forma del task e quindi è rappresentato graficamente da un rettangolo con gli angoli arrotondati tracciato con una linea sottile, ma si differenzia dall’attività perché all’interno del rettangolo é contenuto un segno “più” (+) nella parte centrale bassa della forma.
Figura 30: Simbolo di sottoprocesso
Il BPMN specifica cinque tipi di marcatori standard per un sottoprocesso. Il marcatore di un sottoprocesso inglobato può essere combinato con altri quattro marcatori: marcatore di loop, parallelo, di compensazione e Ad Hoc. Un sottoprocesso inglobato può avere solo tre di questi altri marcatori tra loro combinati, ad eccezione dell’indicatore di loop e di multi-istanza che non possono essere visualizzati assieme:
• Il marcatore di un sottoprocesso che richiama se stesso può essere utilizzato con ogni altro marcatore tranne quello della multi-istanza.
Figura 31: Sottoprocesso che richiama se stesso
• il marcatore di un sottoprocesso con più richieste può essere combinato con ogni altro marcatore tranne quello del loop;
35
Figura 32: Sottoprocesso con più istanze
• il marcatore di un sottoprocesso Ad Hoc può essere combinato con ogni altro marcatore;
Figura 33: Sottoprocesso Ad Hoc
• il marcatore di un sottoprocesso di compensazione può essere combinato con qualsiasi altro marcatore.
Figura 34: Sottoprocesso di compensazione
I sottoprocessi possono essere annidati o indipendenti. Un sottoprocesso annidato (embedded) è un’attività che contiene, a sua volta altre attività. Poiché gli oggetti al suo interno dipendono dal livello superiore, non possiedono tutte le caratteristiche di un BPD completo, come pool e lane; pertanto, un sottoprocesso annidato dovrebbe contenere solo oggetti di flusso, connessioni ed elementi accessori.
36 Un sottoprocesso indipendente è un’attività che richiama un altro sottoprocesso del medesimo BPD. Il sottoprocesso indipendente sarà istanziato da altri oggetti simili o da un flusso di messaggio proveniente da una fonte esterna; questi sottoprocessi possono trasferire dati da e verso il processo di partenza, localizzato in un diagramma separato.
I tre modi per uscire da una transazione sono elencati qui di seguito:
Successo: sarà visualizzato come un normale flusso di sequenza che fuoriesce dal sottoprocesso;
Fallimento (Annulla): quando si annulla una transazione, le attività al suo interno saranno soggette all’azione di annullamento che potrebbe includere il “riavvolgimento” del processo e specifiche azioni di compensazione.
I due metodi per segnalare l’annullamento della transazione sono: il raggiungimento di un evento finale di annullamento oppure la ricezione di un messaggio di annullamento;
Hazard (Termina): significa che qualcosa è andato molto male, e non consente una riuscita o un annullamento normale del processo. Gli eventi di tipo errore sono usati per visualizzare gli hazard (“pericoli”). Nel momento in cui avviene l’hazard, l’attività s’interrompe senza compensazione e il flusso devia verso l’evento intermedio di errore. Il comportamento al termine di un sottoprocesso concluso correttamente è leggermente diverso da quello di un sottoprocesso normale.
Quando ogni percorso della transazione raggiunge un evento finale di qualunque tipo, purché non di annullamento, il flusso non torna immediatamente al livello superiore, come in un sottoprocesso normale. Per prima cosa si controlla che tutti i partecipanti abbiano completato con successo la transazione: il più delle volte questo sarà vero e il flusso retrocederà
37 effettivamente al livello superiore. È tuttavia possibile che uno dei partecipanti possa incappare in un problema che causa l’annullamento o l’hazard, nel cui caso il flusso si sposterà lungo l’evento intermedio appropriato, anche se in apparenza sembrerà terminare il sottoprocesso con successo. Un sottoprocesso può essere la destinazione di un flusso di sequenza e può avere più flussi in entrata, che possono provenire sia da percorsi paralleli sia consecutivi. Da notare che, se un sottoprocesso ha più flussi in entrata, questo è considerato come flusso incontrollato, ciò significa che quando un token arriva da uno dei percorsi, il sottoprocesso sarà istanziato e non attenderà l’arrivo di successivi segnali dagli altri percorsi. Nel caso dovessero arrivare degli altri token, saranno generate altre richieste separate del sottoprocesso. Per porre una regola al flusso, bisognerebbe farlo transitare in un controllo posto innanzi al sottoprocesso.
Un Controllo è indicato dalla familiare forma romboidale che nella mappatura tradizionale è impiegata per rappresentare le decisioni. Nel BPMN ha un impiego più articolato, perché serve per controllare la divergenza e la convergenza della sequenza del flusso. Anche qui icone differenti all’interno del rombo specificano il tipo di azione che i Controlli hanno sul flusso.
I controlli sono elementi di modellazione usati per regolare il flusso di sequenza nelle convergenze e divergenze all’interno del processo. Il termine “controllo” implica la presenza di un meccanismo di regolazione che consente o nega il passaggio lungo la forma; ciò significa che i token in arrivo al controllo possono essere uniti e/o divisi secondo la regola indicata nel controllo stesso.
Esistono diversi tipi di controlli, come descritto in seguito, e il loro comportamento determina quante porte sono disponibili per proseguire il flusso: ci saranno tante porte quanti i flussi di
38 sequenza in uscita dal controllo. I controlli possono definire tutti i tipi di comportamento dei flussi di sequenza dei processi aziendali.
I diversi tipi di controllo sono i seguenti:
XOR: decisione e unione esclusive basate sui dati e sugli eventi;
OR: decisione e unione inclusive;
AND: biforcazioni e unioni; ogni tipo di controllo ha effetto sia con i flussi in entrata sia
con quelli in uscita;
Complesso: condizioni e situazioni complesse (es: valori da 3 a 5).
Il controllo gestisce il flusso sia nelle convergenze sia nelle divergenze; ciò significa che una particolare forma potrebbe avere più flussi di sequenza in entrata e/o in uscita. Un controllo può essere la meta di zero o più flussi di sequenza, sia alternativi sia paralleli. Se manca il flusso entrante e l’evento iniziale non è presente, allora il comportamento divergente sarà eseguito durante la richiesta del processo.
Esaminiamo ora in maniera più approfondita i quattro tipi di controllo sopra elencati:
Controlli esclusivi (XOR): I controlli esclusivi (decisioni) sono punti del processo aziendale in cui
il flusso di sequenza può prendere due o più vie alternative; per il processo si tratta di un “incrocio lungo la strada”, in cui una data richiesta del processo può intraprendere solo un percorso tra quelli disponibili. Una decisione, dal punto di vista dei processi aziendali, non è un’attività ma è piuttosto un tipo di controllo che gestisce il flusso di sequenza all’interno delle attività; può essere inteso come una domanda posta in quel punto del processo avente un insieme definito di risposte alternative (porte). Ogni risposta è associata a un flusso di sequenza in uscita, quando si sceglie una porta durante l’esecuzione del processo, è scelto di
39 conseguenza anche il corrispondente flusso di sequenza uscente. Quando un token arriva alla decisione, questo è deviato lungo il percorso appropriato, secondo la porta scelta. Una decisione esclusiva ha due o più percorsi in uscita, ma sarà preso solo uno di questi durante l’esecuzione.
In pratica, la decisione esclusiva definisce un insieme di percorsi alternativi per il flusso dei token. Esistono due tipi di decisioni esclusive:
Basate sui dati: sono i tipi di controllo che sono usati più frequentemente. L’insieme delle porte è basato in questo caso su espressioni booleane costruite sugli attributi del flusso di sequenza uscente. Queste espressioni usano i valori dei dati del processo per determinare quale percorso prendere, da cui il nome “controllo basato sui dati”.
Figura 35:Simbolo di controllo basato sui dati
Basate sugli eventi: rappresentano dei punti di ramificazione nel processo in cui le decisioni sono basate sugli eventi che avvengono in quel punto. Piuttosto che sulla valutazione di espressioni. Un evento specifico, solitamente la ricezione di un messaggio, determina quale percorso prendere.
40
Controlli inclusivi (OR): I controlli inclusivi sono punti di ramificazione in cui le diverse scelte
sono basate su espressioni condizionali contenute all’interno del flusso di sequenza uscente. In questi tipi di controlli la valutazione di un’espressione che risulti vera non esclude la valutazione di altre espressioni. Tutti i flussi di sequenza considerati veri saranno attraversati da un token. Poiché ogni percorso è indipendente, possono essere prese tutte le combinazioni di strade, da nessuna a tutte; tuttavia, dovrebbe essere impostato che sia preso almeno un percorso. Se nessuna porta è valutata vera, il modello è considerato non valido. I due meccanismi per modellare questo tipo di decisione sono:
Non usare i controlli inclusivi ma ricorrere piuttosto a un insieme di flussi di sequenza condizionali, che si riferiscono a espressioni booleane basate sulle informazioni interne al processo. Questi flussi di sequenza sono rappresentati graficamente da un mini-rombo all’inizio della linea del flusso.
Usare i controlli inclusivi che presentano un controllo OR, a volte in combinazione con altri controlli.
Figura 37: Simbolo di controllo inclusivo
I due metodi hanno un comportamento equivalente: il compito del modellatore sarà di assicurare che almeno una condizione sia vera durante l’esecuzione del processo.
Controlli paralleli (AND): forniscono un meccanismo per sincronizzare e creare flussi paralleli.
In fase di creazione dei percorsi non è obbligatorio ricorrere ai controlli, ma essi possono essere usati per chiarire il comportamento dei flussi in caso di situazioni complesse. Se esistono più
41 flussi di sequenza in entrata, questi saranno tutti utilizzati per continuare e sincronizzare il flusso del processo, che quindi proseguirà solo all’arrivo di tutti i token del flusso di sequenza. Se si hanno, invece, più flussi divergenti, questi saranno tutti selezionati durante l’esecuzione del processo.
Figura 38: Simbolo di controllo parallelo (AND)
Controlli complessi: questi tipi di controlli sono introdotti dal BPMN per gestire quelle
situazioni non facilmente controllabili attraverso altri metodi di controllo. I controlli complessi possono essere usati anche per raggruppare un insieme di controlli semplici in una situazione unica più compatta. I modellatori possono inserire espressioni complesse che determinano l’unione o la divisione all’interno del controllo stesso.
Se il controllo è usato come decisione, il flusso uscente sarà determinato dall’espressione riguardante ciascun percorso. Le espressioni possono essere riferite sia ai dati del processo sia allo stato del flusso di sequenza entrante. Se invece è utilizzato come unione, ci sarà un’espressione che determinerà quale dei flussi di sequenza entrante sarà richiesto per proseguire il processo.
Se esistono più flussi di sequenza in entrata, saranno utilizzati uno o più di questi per proseguire il processo. L’esatta combinazione dei flussi entranti sarà determinata dall’espressione posta sul controllo entrante. Il flusso del processo deve proseguire quando, dalla sequenza in entrata, giunge il giusto numero di token; possono giungere anche i segnali
42 provenienti dagli altri flussi di sequenza, ma, questi, non devono essere usati per continuare il processo.
Per quanto riguarda il comportamento divergente, durante l’esecuzione del processo saranno scelte una o più porte, secondo l’espressione posta nel controllo uscente.
Figura 39: Simbolo di controllo complesso
6.7 Connettori
Le forme sono collegate insieme in un grafico per creare la struttura di base di un diagramma di processo. Si possono distinguere tre tipi di connettori in base alla funzione da essi esplicata. Questi connettori sono:
Sequenza
Messaggio
Associazione
Una freccia di tipo Sequenza, flusso fisico del processo, è usata per mostrare l’ordine con cui le attività sono eseguite nel processo. Ogni connettore ha un solo punto di origine e un solo punto di arrivo. L’origine e l’arrivo devono arrivare da uno dei seguenti oggetti: eventi (iniziale, finale e intermedio), attività (task, sottoprocessi) e controlli.
Durante la simulazione del processo, un token parte sempre da un oggetto di origine, passa attraverso una sequenza e termina nell’oggetto di arrivo.
