DI INGEGNERIA. Laurea specialistica in Ingegneria Informatica ANALISI E SIMULAZIONE AD AGENTI ASINCRONI DI WORKFLOW INTER-ORGANIZZATIVI

Transcript

1 UNIVERSITÀ DEGLI STUDI DI ROMA TOR VERGATA FACOLTÀ DI INGEGNERIA Laurea specialistica in Ingegneria Informatica ANALISI E SIMULAZIONE AD AGENTI ASINCRONI DI WORKFLOW INTER-ORGANIZZATIVI RELATORE Prof. Salvatore Tucci CANDIDATA Silvia Agatello CORRELATORE Ing. Emiliano Casalicchio Anno accademico

2 Indice Introduzione 1 1 Business process re-engineering e Qualità del servizio Business Process Re-engineering (BRP) Introduzione alla re-ingegnerizzazione dei processi amministrativi Le principali cause di insuccesso degli interventi di BPR Il concetto di processo L approccio per simulazione di processi Qualità del servizio (QoS) Workflow e WfMS Workflow Management Systems e Workflow Business Process Workflow Management Coalition Workflow Management Systems Terminologia del Workflow Business Process Classificazione dei WfMS Workflow di Produzione Workflow Amministrativi Workflow Collaborativi Workflow Ad Hoc Componenti dei workflow Interfaccia 1: Definizione del Processo Interfacce 2 e 3: API dei Workflow Interfaccia 4: Interoperabilità tra vari WF INDICE I

3 INDICE Interfaccia 5: Amministrazione e controllo Gestione delle risorse: i workflow inter-organizzativi Introduzione al SABS Motivazioni Beni e servizi Utenti e permessi Workflow Sottomissione di una richiesta da parte di un utente Assegnazione di una richiesta Splitting e generazione di sottorichieste in fase iniziale Evasione della richiesta e presa in carico Chiusura della richiesta ed esito Generazione di sottorichieste per richieste parzialmente soddisfatte Negoziazione e modifica della richiesta Negoziazione e chiusura della richiesta Rimozione della richiesta Analisi di strumenti e modelli di simulazione dei workflow Fasi di uno studio di simulazione Strumenti per la simulazione di workflow Analisi SABS con Simul Visio Analisi SABS con Swarm Analisi SABS con jes I formalismi Che cosa fare (WD) Chi fa che cosa (DW) Creazione del modello SABS virtuale in jes Analisi SABS con RePast INDICE II

4 INDICE 5 Reti di Petri e reti WF-net (workflow-net) Reti di Petri Notazioni e definizione Proprietà Estensioni delle reti di Petri Reti WF-net Notazioni e definizione Proprietà Trigger Routing Split e Join Modellazione di workflow tramite reti di Petri e reti WF-net Modellazione dei workflow SABS Individuazione e analisi dei workflow reali Rappresentazione dei workflow SABS reali mediante reti di Petri e WF-net Verifica delle proprietà dei workflow rappresentati con reti di Petri e WF-net Classificazione Correttezza (soundness) e Vitalità Modellazione delle risorse Identificazione delle caratteristiche di impianto Identificazione dei parametri di impianto Raccolta dei dati dell impianto Raccolta dei dati dal sistema SABS semplificato (con approssimazione) Raccolta dei dati dal sistema SABS reale (senza approssimazione) WFsimulator: implementazione del modello di simulazione Pseudo-simulazione tramite Token-Game e vettore di marcatura Implementazione in Java di un simulatore di workflow reti di Petri ad agenti Obiettivi e peculiarità Parametri di sistema Librerie API utilizzate INDICE III

5 INDICE Diagrammi UML del Package e delle Classi Struttura del programma Altre caratteristiche Esempio della logica di processo del workflow in WFsimulator Esempio di simulazione con WFsimulator Manuale d uso di WFsimulator Raccolta delle misure e risultati Parametri delle simulazioni Risultati delle simulazioni Misurazioni con N tick = 30 e N maxt ask = Misurazioni con N tick = 30 e N maxt ask = Misurazioni con N tick = 60 e N maxt ask = Misurazioni con N tick = 60 e N maxt ask = Conclusioni e sviluppi futuri Sommario del lavoro svolto Possibili estensioni di WFsimulator A Scripts per la creazione di ricette SABS in jes 173 B JavaDocs di WFsimulator 176 B.1 Classe Container B.1.1 Dichiarazione B.1.2 Campi B.1.3 Costruttori B.1.4 Metodi B.2 Classe MoverAgent B.2.1 Dichiarazione B.2.2 Costruttori B.2.3 Metodi B.2.4 Metodi ereditati dalla classe wfsimulator.systemagent B.2.5 Metodi ereditati dalla classe DefaultDrawableNode INDICE IV

6 INDICE B.3 Classe SystemAgent B.3.1 Dichiarazione B.3.2 Costruttori B.3.3 Metodi B.3.4 Metodi ereditati dalla classe DefaultDrawableNode B.4 Classe Task B.4.1 Dichiarazione B.4.2 Costruttori B.4.3 Metodi B.5 Classe UserAgent B.5.1 Dichiarazione B.5.2 Campi B.5.3 Costruttori B.5.4 Metodi B.5.5 Metodi ereditati dalla classe AsynchAgent B.6 Classe WFsimulator B.6.1 Dichiarazione B.6.2 Campi B.6.3 Costruttori B.6.4 Metodi B.6.5 Metodi ereditati dalla classe SimpleModel B.7 Classe Workflow B.7.1 Dichiarazione B.7.2 Costruttori B.7.3 Metodi B.8 Classe WorkflowDefinition B.8.1 Dichiarazione B.8.2 Campi B.8.3 Costruttori B.8.4 Metodi INDICE V

7 INDICE Elenco delle figure 218 Elenco delle tabelle 226 Bibliografia 228 INDICE VI

8 Introduzione I sistemi di Workflow possono essere definiti come automazioni di processi di business, complete o parziali, durante le quali i documenti, le informazioni o le attività sono trasferiti da un partecipante (uomo o macchina) ad un altro per effettuare l azione più appropriata, in accordo ad un insieme di regole procedurali. Negli anni recenti l information technology ha fatto grandi passi avanti in questo settore, arrivando a formulare una nuova concezione dell organizzazione dei processi di business. In questo ambito, particolare rilevanza riveste lo sviluppo di sistemi software generici per la gestione dei processi di business, i cosiddetti workflow management systems (WFMS). Applicazioni di rilievo nella Pubblica Amministrazione e negli Enti privati utilizzano i WFMS, fra l altro, come strumenti per rendere automatico il processo di scambi documentali e tenere traccia della dinamica degli scambi stessi, dal momento della ideazione, o apertura di un fascicolo fino alla chiusura o completamento. Nel contesto dei sistemi di workflow della P.A. riveste un ruolo consolidato il sistema SABS (Sistema per l Acquisizione di Beni e Servizi on line) introdotto presso la Presidenza del Consiglio dei Ministri tramite il quale il Dipartimento per le risorse umane ed i servizi informatici raccoglie le richieste di beni e servizi provenienti da tutti coloro che prestano la loro opera presso la Presidenza del Consiglio dei Ministri e quindi provvede ad instradare la richiesta verso l Ufficio o Servizio deputato al suo soddisfacimento. Per poter sostenere idoneamente le richieste e seguirle durante l iter di soddisfacimento, all interno del sistema opera un workflow che rappresenta da un lato l organizzazione e dall altro per ciascun specifico processo la dinamica delle azioni che vengono compiute. Il sistema consente di sottomettere delle richieste in modo strutturato, di gestirle in modo automatico ed in breve tempo consegnare l ordine ad eseguire a chi poi fornirà la prestazione o le prestazioni finali così come richiesto. Introduzione 1

9 Introduzione Il processo di automazione, oltre che semplificare il modo di richiedere una prestazione, permette di controllare l evoluzione dell intervento nei vari stadi previsti attraverso un identificativo unico (trouble ticket). La possibilità di tracciare una richiesta nello spazio e nel tempo fornisce molti dati utili per: controllare l avanzamento dello stato delle richieste; tracciare l evoluzione delle richieste; determinare i colli di bottiglia; verificare la validità del sistema organizzativo; valutare prestazioni e costi. Partendo dalla disponibilità di una notevole mole di dati producibili è possibile introdurre un importante obiettivo: definire la qualità del servizio (QoS) per questo sistema. L impatto dello sviluppo dell information technology nel campo dei processi di business ha prodotto una serie di studi riguardanti i criteri per valutarne e incrementarne l efficienza, tramite il metodo del business process re-engineering (BPR). Tramite BPR, quindi, è possibile valutare la qualità del servizio di un sistema di workflow management. Questo lavoro di tesi si colloca nel contesto della definizione di strumenti per valutare la QoS dei sistemi di workflow, applicando i risultati al sistema SABS. Vi è l esigenza di costruire un modello rappresentativo del sistema sul quale implementare politiche di gestione, schemi organizzativi, varie architetture operative che permettano di fare confronti tra le scelte possibili e il comportamento reale del sistema. L obiettivo del lavoro è sperimentare le possibili soluzioni fino a costruire una sorta di laboratorio sperimentale di simulazione mediante il quale sarà possibile individuare le scelte migliori per raggiungere obiettivi prefissati di prestazione e di affidabilità. La delicatezza della valutazione risiede nel fatto che il modello deve contemplare, oltre che dinamiche proprie dei sistemi, quella degli operatori umani: anche se negli anni è stato fatto molto per informatizzare la gestione dei processi di business utilizzando i sistemi informativi, non va dimenticato che oggi, e per il prossimo futuro, alcune attività possono essere svolte solamente dalle persone. È per questo che la tipologia di workflow da modellare è denominata di tipo inter-organizzativo: una componente fondamentale è la buona riuscita della modellazione dell organizzazione e delle risorse. Introduzione 2

10 Introduzione L attività di ricerca svolta nell ambito di questa tesi si articolerà nelle fasi seguenti: individuazione e analisi dei workflow reali; rappresentazione dei workflow reali mediante reti di Petri; verifica delle proprietà dei workflow reali rappresentati con reti di Petri; identificazione dei vari parametri e delle caratteristiche di impianto; individuazione e analisi di possibili sperimentazioni simulative; costruzione dei modelli di simulazione per la generazione sintetica del workload; raccolta delle misure e convalida del modello. La tesi è strutturata come segue: nel capitolo 1 viene mostrata l importanza di pianificare e attuare interventi di re-ingegnerizzazione dei processi, il che si rende indispensabile per sistemi critici come alcuni fra quelli della pubblica amministrazione, e discusso il concetto di qualità del servizio. In particolare, il processo che ci si propone di migliorare è il SABS adottato dalla Presidenza del Consiglio dei Ministri, un sistema basato su workflow. Il capitolo 2 approfondisce le caratteristiche generali dei workflow e dei sistemi di gestione di workflow, facendo riferimento al framework descritto dall organizzazione WfMC ; alcune definizioni saranno introdotte e utilizzate nei capitoli successivi. Il capitolo 3 fornisce una panoramica del sistema SABS: viene posto l accento sulle caratteristiche funzionali e architetturali necessarie allo studio dei relativi workflow reali. Il capitolo 4 riporta le attività di analisi e sperimentazione svolte sui sistemi software utilizzati per la costruzione di modelli simulativi. Al fine di modellare i workflow, nel capitolo 5 è presente una spiegazione teorica delle reti di Petri, con le relative proprietà ed estensioni. In particolare, vengono discusse le reti WF-net (workflow-net) che sono un sottoinsieme delle reti di Petri da cui ne ereditano le proprietà. Le reti di Petri sono state utilizzate sia nella modellazione dei workflow reali del SABS, sia nella costruzione del simulatore di workflow. Nel capitolo 6, infatti, vengono individuati e formalizzati, tramite reti di Petri e WF-net, i workflow del SABS. Viene inoltre verificato il soddisfacimento delle proprietà di base delle reti WF-net, tramite appositi strumenti. Nel capitolo 7 successivo, dopo un esempio di Token-game sul workflow del SABS, vengono descritte nel dettaglio le caratteristiche del software di simulazione implementato Introduzione 3

11 Introduzione per questa tesi, WFsimulator, basato sul tool di simulazione ad agenti RePast e sulle reti di Petri. Tramite il software WFsimulator è possibile simulare un mondo ad agenti asincroni, con risorse che si interfacciano ad un sistema simulato di workflow contenente, ad esempio, il modello di rete di Petri del SABS ricavato nel capitolo 6. Per mezzo della simulazione è possibile ricavare risultati relativi al sistema reale e, attraverso eventuali modifiche alle ipotesi di lavoro e di architettura, il comportamento predittivo del sistema permette di operare le scelte più opportune ai fini di migliorare la qualità del servizio oggetto della modellazione. Nel capitolo 8 vengono discussi i risultati ottenuti. Introduzione 4

12 Capitolo 1 Business process re-engineering e Qualità del servizio Nel capitolo viene mostrata l importanza di pianificare e attuare interventi di re-ingegnerizzazione dei processi e discusso il concetto di qualità del servizio. 1.1 Business Process Re-engineering (BRP) Introduzione alla re-ingegnerizzazione dei processi amministrativi Il BPR è stato originariamente formulato da M. Hammer (MIT), sia nel suo articolo [Ham90] che nel libro scritto con J. Champy [Cha93]. In sintesi, il BPR consiste in una procedura di rielaborazione dei processi di business, senza necessariamente effettuare approfondite analisi riguardanti lo stato dell arte dei processi già attivi. Nel BPR, il tema centrale è il potere dell information technology: i sistemi IT vengono proposti come strumenti in grado di ridefinire radicalmente il business. Davenport & Short [Sho90] definiscono il BPR come the analysis and design of workflows and processes within and between organizations; mentre Teng et al. [Ten95] definiscono il BPR come the critical analysis and radical redesign of existing business processes to achieve breakthrough improvements in performance measures. Cap. 1 Business process re-engineering e Qualità del servizio 5

13 1.1 Business Process Re-engineering (BRP) Le principali cause di insuccesso degli interventi di BPR Nonostante il BPR sia oggi uno dei principali approcci manageriali per la corretta gestione e l incremento del business, ancora circa dal 50 al 70 per cento dei progetti di BPR fallisce nello scopo di raggiungere i risultati stabiliti. Tale fallimento è generalmente dovuto ad una scarsa attenzione nella definizione del processo di business o ad una scorretta implementazione degli appropriati sistemi IT in grado di supportarlo. È comunemente accettata l idea che un corretto sviluppo dei sistemi informativi di una organizzazione dipenda fortemente da una buona conoscenza e comprensione dei bisogni degli utenti e dalla qualità delle analisi dei requisiti dei sistemi. Se un sistema non incontra i bisogni degli utenti, infatti, essi potranno fallire nell utilizzo degli stessi, usarli poco o per nulla, o, infine, avere spesso bisogno di richiedere assistenza, ostacolando il raggiungimento degli scopi previsti. Altri motivi che conducono al fallimento dei progetti di BPR riguardano la resistenza ai cambiamenti o le aspettative piuttosto ampie rispetto al possibile campo di applicazione. Anche per il BPR, pertanto, l analisi dei requisiti costituisce una fase di fondamentale importanza, così come per ogni nuovo progetto. In tale ambito è necessario che l analisi non sia focalizzata solo nello sviluppo dei sistemi software, ma anche dell ambiente che interagisce con esso, che include l integrazione fra le risorse umane e gli agenti automatici Il concetto di processo I già citati Davenport & Short [Sho90] definiscono il business process a set of logically related tasks performed to achieve a defined business outcome. Un processo è [Dav93] a structured, measured set of activities designed to produce a specified output for a particular customer or market. It implies a strong emphasis on how work is done within an organization. Nella loro visione, i processi hanno due importati caratteristiche: comprendono gli utenti - clienti (interni o esterni); Cap. 1 Business process re-engineering e Qualità del servizio 6

14 1.2 Qualità del servizio (QoS) attraversano i confini organizzativi, ad esempio possono occorrere tra sotto-unità organizzative. I processi sono generalmente identificati dai punti di inizio e di fine, e dalle unità organizzative coinvolte, in particolare gli utenti - clienti e gli utenti - serventi. I processi possono essere definiti sulla base di tre criteri [Sho90]: 1. Entità: processi che hanno luogo fra entità organizzative. 2. Oggetti: durante i processi, vi è manipolazione di oggetti. Tali oggetti possono essere fisici o, genericamente, sistemi informativi. 3. Attività: i processi possono includere due tipi di attività: manageriali e operazionali L approccio per simulazione di processi Al fine di migliorare la qualità del servizio di complessi processi amministrativi, è possibile procedere alla loro re-ingegnerizzazione attraverso diversi criteri. L approccio scelto in questo lavoro è definibile Simulazione per processi : i business processes vengono astratti e circoscritti, modellati e infine analizzati tramite il metodo simulativo. Le risorse che interagiscono con i processi (siano esse risorse umane, sistemi, trigger, allarmi, altri sistemi esterni) sono parte integrante della ristrutturazione e devono essere anch esse modellate opportunamente, perché costituiscono l ambiente (enviroment) del sistema software e influiscono fortemente sui relativi processi amministrativi. La simulazione includerà strumenti per la modellazione delle situazioni del mondo reale. Quando ci si occupa della modellazione del mondo reale, è necessario considerare l incertezza associata all occorrenza delle azioni. Per questo motivo, si assumerà che nessuna metodologia è in grado di fornire una soluzione completa e quindi sarà necessario ragionare principalmente sulle metodologie per la modellazione del mondo reale e su possibili modifiche proposte grazie ai risultati del metodo simulativo, piuttosto che sull architettura hardware e software pre-esistente del sistema da re-ingegnerizzare. 1.2 Qualità del servizio (QoS) I sistemi che si sta cercando di re-ingegnerizzare sono dei workflow (cf. cap. 2), pertanto è necessario sottolineare quale sia, in questo ambito, l utilità del metodo simulativo, i cui Cap. 1 Business process re-engineering e Qualità del servizio 7

15 1.2 Qualità del servizio (QoS) risultati potranno essere utilizzati per prevedere quali possibili modifiche siano in grado di migliorare la qualità del servizio, sia del sistema in senso assoluto che quella soggettiva percepita dagli utenti. Obiettivo del lavoro è simulare il processo in modo da proporre eventuali modifiche al flusso, quali ad esempio l aggiunta, la sostituzione, l eliminazione di un task, la modifica, l aggiunta, la cancellazione di un percorso di routing, la modifica all organizzazione, costituita da utenti, ruoli e gruppi, la modifica dei sistemi esterni coinvolti nel sistema (allarmi, messaggi, trigger o altri sistemi), oppure una combinazione dei vari elementi. Prerequisito di questo lavoro è che i sistemi di workflow da re-ingegnerizzare siano di tipo adattativo, ossia in grado di adattarsi alle modifiche richieste. Se in tali sistemi non fosse possibile, ad esempio, aggiungere un flusso o modificare un task, gli interventi da effettuare sarebbero piuttosto complessi, tali da impattare fortemente, per esempio, sul codice sorgente o sull architettura logico-fisica del sistema. Attraverso la simulazione con WfMS adattativi sarà possibile controllare l efficacia dei cambiamenti, ossia valutare il sistema con la metodologia What IF. Tale efficacia potrà essere quantificata, attraverso lo studio della qualità del servizio (QoS) del nuovo sistema. Al fine di procedere alla valutazione della QoS, sarà necessario introdurre un modello di costo [Car02]; se il modello di costo non è formalmente presente nel sistema software, dovrà comunque essere implicitamente utilizzato nella fase di valutazione della QoS. Ad esempio, il modello di costo del sistema oggetto dello studio può essere formalizzato come segue: ogni attività (task) ha una corrispondenza nel modello di costo. Si consideri l esecuzione del task τ che comincia al tempo t 1 e termina al tempo t 2. Tale esecuzione preleverà dei dati di ingresso (input), produrrà dei dati in uscita (output) e modificherà lo stato del task. La qualità globale sarà decomposta in tre dimensioni (metriche di qualità): (i) tempo = t 2 - t 1 (ii) costo = f c (τ, output) (iii) qualità = f q (τ, output) Attraverso lo studio del modello di costo del sistema, l efficacia delle modifiche da apportare potrà pertanto essere quantificata in un ottica predittiva, fornendo la possibilità Cap. 1 Business process re-engineering e Qualità del servizio 8

16 1.2 Qualità del servizio (QoS) di valutare l impatto che avrebbero potenziali modifiche del sistema, soprattutto qualora fossero rischiose o applicate a sistemi in produzione. Cap. 1 Business process re-engineering e Qualità del servizio 9

17 Capitolo 2 Workflow e WfMS Il capitolo illustra le caratteristiche generali dei workflow e dei sistemi di gestione di workflow, ponendo l accento sul framework di riferimento descritto dall organizzazione WfMC. 2.1 Workflow Management Systems e Workflow Business Process Workflow Management Coalition La Workflow Management Coalition (WfMC) è stata fondata nell agosto del missione dell organizzazione prevede la promozione e lo sviluppo dell utilizzo dei workflow attraverso la specifica di precisi standard per la terminologia dei software, l interoperabilità e la connessione fra diversi prodotti di workflow. Nel 1996, la WfMC ha pubblicato un glossario (versione aggiornata in [Coa99] ) contenente tutta la terminologia relativa ai workflow, definiti come [WfM06]: The automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules. Nel sito è presente un documento di Rob Allen, Chair, WfMC External Relations Committee, intitolato Workflow: An Introduction [All01] in cui viene descritto che ogni workflow è composto di un certo numero di processi, in pratica procedure da seguire per ottenere un certo risultato da determinate condizioni di partenza. Nei primi tempi di sviluppo di questi sistemi, il lavoro veniva passato da un partecipante (o lavoratore) ad un La Cap. 2 Workflow e WfMS 10

18 2.1 Workflow Management Systems e Workflow Business Process altro, senza che elementi incompleti potessero procedere nel flusso di lavoro: ciò garantiva una consistenza nello svolgimento della singola attività, che veniva pertanto automatizzata. La tecnologia dei workflow è poi maturata con gli anni, ed ora è l intero processo di lavoro ad essere automatizzato. Una attività viene creata ed elaborata, e può poi modificarsi nel tempo per raggiungere lo scopo prefissato. Attualmente, i motori di workflow riescono a gestire anche serie di processi piuttosto complessi, poiché qualunque tipo di condizione che possa essere espressa matematicamente può anche essere gestita attraverso un sistema di workflow [vumzmmr97]. L automazione dei flussi di lavoro può portare ad un consistente incremento dell efficienza dell azienda e, inoltre, fornisce un valido strumento per la creazione della cosiddetta Organizzazione Virtuale (cf. par. 2.4) Workflow Management Systems Secondo la WfMC, un Workflow Management System (WfMS) è a system that defines, creates and manages the execution of workflows through the use of software, running on one or more workflow engines, which is able to interpret the process definition, interact with workflow participants and, where required, invoke the use of IT tools and applications. In pratica, un WfMS gestisce un workflow, in particolare è un sistema in grado di interpretare la definizione del workflow (workflow definition o process definition) e di gestire i trigger, gli allarmi e l interoperabilità con altri sistemi esterni Terminologia del Workflow Business Process Tutti i sistemi di workflow sono orientati al processo. Una definizione di processo è una rappresentazione di cosa dovrebbe accadere, suddivisa, eventualmente, in sotto-processi. Ogni processo e sotto-processo comprende alcune attività (activities), ossia dei singoli passi logici nel processo. Ogni processo è quindi descritto dall insieme di attività e dalla sequenza con cui esse sono svolte. Un attività descrive un singolo passo del processo da eseguire. Il processo ha sempre una sola attività d inizio, in cui entrano gli oggetti che devono essere elaborati, ed un attività di fine da cui escono i prodotti del processo. La Cap. 2 Workflow e WfMS 11

19 2 - BASIC CONCEPTS This section identifies basic concepts and terminology associated with workflow as a general topic. nology 2.1 Workflow Management Systems e Workflow Business Process Business Process (es: cosa dovrebbe succedere) è definito in un è gestito da un Sub-Processes Process Definition (una rappresentazione di cosa dovrebbe succedere) composto da Workflow Management System (controlla gli aspetti automatici usato per creare del business process) & gestire tramite Activities che possono essere o Process Instances (una rappresentazione di cosa accade in un preciso momento) include una o più Manual Activities Automated Activities Activity Instances (che non sono gestite come una durante l'esecuzione che parte del Workflow System) sono rappresentati da includono e/o Invoked Work Items Applications (attività allocate a un (computer tools/applicazioni participante al workflow) usate per supportare un'attività) Figure 1 - Relationships between basic terminology Figura 2.1: Terminologia del Workflow Business Process sequenza di passi di un processo può comprendere ramificazioni e ricongiungimenti, a rappresentare attività che devono essere svolte in parallelo o attività che devono essere svolte in alternativa le une alle altre. Non tutte le attività di un singolo processo necessitano di essere automatizzate, pertanto le possibili tipologie di attività sono di tipo manuale oppure automatico. La fase di produzione del Workflow Definition deve essere svolta approfonditamente dai professionisti IT, impiegandovi tutto il tempo necessario. Più accurata sarà questa Workflow Management Coalition Page 7 of 65 fase, maggiore sarà la probabilità di non dover effettuare interventi successivi. Una volta prodotto, il Workflow Definition deve essere caricato nel sistema WfMS e sottoposto a test per valutarne la congruità. Ogni processo è un entità statica, comprendente la definizione di procedure e iter da intraprendere. Al termine dei test, il Workflow Definition potrà essere introdotto in fase di produzione, permettendo la creazione, da parte delle unità lavorative del sistema, siano esse risorse umane, gruppi di lavoro o sistemi computerizzati, di istanze del flusso di processo. Ogni processo può avere più istanze, anche contemporanee. Le istanze sono le entità Cap. 2 Workflow e WfMS 12

20 2.2 Classificazione dei WfMS dinamiche del processo e associate ad esse sono sempre presenti alcuni attributi di stato (orario di inizio attività, orario di fine attività e dati relativi allo svolgimento dei passi e delle attività). 2.2 Classificazione dei WfMS Il tipo di sistema di gestione di workflow da utilizzare dipende dagli scopi che si desidera raggiungere e la classificazione che segue è la più comune nella letteratura Workflow di Produzione L obiettivo dei sistemi di workflow di produzione è di gestire un ampio numero di attività simili e di ottimizzare la produzione. A tale scopo, vengono automatizzate la maggior parte delle attività e l intervento umano è previsto solo in casi eccezionali, per un periodo di tempo comunque breve e con minima complessità di lavoro. Tali sistemi di gestione di workflow possono essere visti come entità in grado di svolgere task ripetitivi in modalità batch. Inoltre, sono in grado di gestire processi complessi e possono essere facilmente integrati con sistemi esistenti (legacy). Il concetto di integrazione introduce una ulteriore suddivisione: Motori di workflow autonomi Un sistema di workflow autonomo è completamente funzionante senza alcuna applicazione software addizionale, ad eccezione del sistema database e del middleware relativo alla coda di messaggi. Ogni eventuale applicazione esterna al sistema di workflow viene invocata a runtime e i dati rilevanti del workflow vengono passati fra i partecipanti. Pertanto, normalmente tali sistemi possiedono una propria interfaccia utente e consistono di una parte di software separato che offre le funzionalità di workflow. Workflow incorporati (embedded) Un sistema di workflow embedded è funzionante solo se incorporato all interno di un altro sistema. Le funzionalità del workflow vengono presentate all esterno dal sistema principale. I componenti del sistema di workflow vengono usati per controllare la sequenza delle funzioni delle applicazioni e per gestire le code e l elaborazione delle eccezioni. Cap. 2 Workflow e WfMS 13

21 2.3 Componenti dei workflow In tali sistemi di workflow, il throughput è una misura fondamentale Workflow Amministrativi I sistemi di workflow amministrativi sono caratterizzati dalla semplicità durante la fase di definizione del processo. Le definizioni sono spesso create utilizzando delle form predefinite. In tali sistemi, la flessibilità è più importante della produttività Workflow Collaborativi I sistemi collaborativi sono incentrati sul concetto di gruppo di lavoro e forniscono solitamente un ambiente di lavoro per supportare e permettere la collaborazione di persone con interessi o obiettivi in comune. Solitamente tali sistemi sono anche chiamati Groupware. In tali sistemi, la definizione del processo non è rigida e il throughput non è una misura fondamentale Workflow Ad Hoc I sistemi di workflow ad-hoc sono sistemi che permettono di creare e modificare velocemente le definizioni del processo, anche qualora vi sia la necessità di effettuare dei cambiamenti in corso d opera. Pertanto, è virtualmente possibile avere tante definizioni di processo quante sono le istanze di workflow. In tali sistemi, la flessibilità è la caratteristica fondamentale, mentre il throughput e la sicurezza vengono messi in secondo piano. 2.3 Componenti dei workflow Nel 1995 il Dipartimento della Difesa USA ha sponsorizzato gli studi iniziali della Workflow Management Coalition, il cui primo risultato fu la produzione del Workflow Reference Model [Coa95], che descrive cinque interfacce, come riportato in figura Interfaccia 1: Definizione del Processo L interfaccia 1 descrive le modalità con cui al workflow abilitato viene passata la definizione di processo proveniente da sistemi esterni. Al fine di descrivere i criteri per l inizio, l esecuzione e il termine dei processi, la WfMC ha pubblicato un nuovo linguaggio, il PDL (Process Definition Language). Recentemente, con l avvento e la diffusione di XML, tale interfaccia Cap. 2 Workflow e WfMS 14

22 The Workflow Reference model has been developed from the generic workflow application structure by identifying the interfaces within this structure which enable products to interoperate at a variety of levels. All workflow systems contain a number of generic components which interact in a defined set of ways; different products will typic ally exhibit different levels of capability within each of these generic components. To 2.3 Componenti dei workflow Strumenti per Definizione Processo Interfaccia 1 Strumenti di Amministrazione e Monitoraggio Interfaccia 5 API del Workflow e formati di interscambio Servizio per la promulgazione Motore/i di Workflow Interfaccia 4 Altri servizi per la promulgazione dei Workflow Motore/i Workflow Interfaccia 2 Applicazioni Client Workflow Applicazioni Invocate Interfaccia 3 Figura 2.2: Framework del Workflow Reference Model della WfMC. è stata riscritta per utilizzare Wf-XML. Il linguaggio attuale è denominato XPDL (XML Process Definition Language) [Coa05]. Copyright 1993, 1994, 1995 Workflow Management Coalition Page 20 of Interfacce 2 e 3: API dei Workflow Le interfacce 2 e 3 sono state combinate a formare il WAPI (Workflow API ) [Coa98b]. Tramite queste interfacce è possibile implementare applicazioni in grado di accedere alle funzionalità dei motori di workflow. Le chiamate WAPI possono essere implementate in vari tipi di linguaggi. Le definizioni della versione 1 sono state scritte in linguaggio C, le più recenti in Java Interfaccia 4: Interoperabilità tra vari WF L interfaccia 4 descrive le modalità per implementare l interoperabilità fra più workflow [Coa98c], ad esempio fare in modo di effettuare delle richieste ad un secondo workflow, utilizzare la relativa definizione di processo e i relativi dati del contesto e ricevere indietro delle informazioni di stato. L interoperabilità attualmente avviene grazie al linguaggio Wf- XML 2.0 [Coa04]. Cap. 2 Workflow e WfMS 15

23 2.4 Gestione delle risorse: i workflow inter-organizzativi Interfaccia 5: Amministrazione e controllo Le funzionalità di auditing sono descritte nell interfaccia 5 e permettono di gestire il controllo dei dati attraverso vari prodotti workflow di tipo eterogeneo [Coa98a]. Attraverso questo controllo, l utente può monitorare e tenere traccia delle attività accorse durante l esecuzione delle istanze di workflow. 2.4 Gestione delle risorse: i workflow inter-organizzativi Nei primi tempi dello sviluppo di sistemi di workflow, gli utenti erano generalmente in numero basso e spesso i processi erano automatizzati. I sistemi moderni, invece, contemplano spesso anche più di un milione di utenti. Per questi motivi, è divenuto fondamentale gestire attentamente le risorse che partecipano al workflow, siano esse risorse umane che sistemi di vario genere [Say61]. In questo ambito, particolare valore assume una corretta gestione dei workflow che necessitano, oltre che della gestione delle risorse, anche della gestione dell organizzazione di cui essi fanno parte. Solitamente, una risorsa umana facente parte di un workflow inter-organizzativo ha uno o più ruoli e fa parte di uno o più gruppi di risorse [Ret95]. La differenza fra un workflow normale e un workflow inter-organizzativo consiste nel fatto che, mentre nel primo le attività (i singoli task) del workflow possono essere svolte da una delle quattro entità risorsa umana, trigger, allarmi, messaggi, nel secondo è necessario anche specificare quali ruoli e quali gruppi fra quelli relativi alle risorse umane sono autorizzati ad eseguire la particolare attività. Nel workflow di tipo inter-organizzativo è pertanto possibile specificare dettagliate e complesse ACL (access control list), con descrizione di risorse, ruoli e gruppi, ossia dell organizzazione in cui tali risorse sono contenute. Cap. 2 Workflow e WfMS 16

24 Capitolo 3 Introduzione al SABS Il capitolo fornisce una panoramica del sistema SABS adottato dalla Presidenza del Consiglio dei Ministri: viene posto l accento sulle caratteristiche funzionali e architetturali necessarie allo studio dei relativi workflow reali. 3.1 Motivazioni Il Dipartimento per le risorse umane e i servizi informatici (DRUS) si occupa dell informatizzazione e della gestione delle infrastrutture tecnologiche e d approvvigionamento utili al lavoro interno alla Presidenza del Consiglio (PCM) e agli uffici-ministeri ad essa collegati. Nasce quindi l esigenza di costruire il portale intranet: uno strumento utile ad aggregare i molteplici flussi informativi che devono essere gestiti centralmente secondo particolari esigenze. Vista la disposizione topologica degli uffici di riferimento, esso consente le interazioni dinamiche sia all interno sia all esterno della PCM, richiede una registrazione ed autenticazione degli attori nel sistema, ha la capacità di fornire informazioni personalizzate per le diverse tipologie d utenza. I riferimenti, da cui sono state estrapolate alcune delle informazioni che seguono, si trovano nella documentazione di progetto [PdCdM03a] e [PdCdM03b], fornita dal DRUS (ex DRS). Altre informazioni sono state recepite dai primi contatti con l azienda produttrice del sistema e a seguito della collaborazione di alcuni funzionari della PCM. All interno del portale intranet si colloca il progetto SABS: Sistema di Acquisizione Beni e Servizi on-line. Attraverso l uso di un sistema web based, che implica connettività totale all interno dell amministrazione oltre che permessi d accesso graduati e caratteristiche di Cap. 3 Introduzione al SABS 17

25 3.2 Beni e servizi flessibilità e d evoluzione, si è cercato di rispondere all esigenza di molteplici obiettivi, quali ad esempio offrire supporto alle procedure svolte dal Dipartimento per le risorse umane ed i servizi informatici nello svolgimento della propria missione, integrare i sistemi informativi e le procedure esistenti per incrementare il grado d affidabilità ed efficienza degli attori coinvolti, incrementare la qualità e la sicurezza delle modalità d evasione delle richieste, fornire una valutazione oggettiva dei livelli di servizio offerti dal Dipartimento, generare un ciclo di revisione e verifica che consenta economie di gestione e controllo dei costi, garantendo la soddisfazione degli utenti. 3.2 Beni e servizi Da indagini effettuate dal DRUS risulta un insieme di beni e servizi richiesti al DRUS molto variegato e complesso; è stato deciso di classificarli in: tipologie di beni; tipologie di servizi. Inoltre s identificano diverse tipologie di processo di servizio classificabili in: processo elementare; processo composito. Per processo elementare s intende una richiesta di bene o servizio che segue un percorso lineare ovvero è trasmessa dal SABS ad un solo destinatario che la esegue e la chiude. Invece un processo composito è una richiesta di beni o servizi per soddisfare i quali occorre un concorso di più attori individuabili in più servizi o anche più Uffici del DRUS. Il SABS tende a semplificare e rendere essenziale il modus operandi delle persone coinvolte nel processo di soddisfacimento di una richiesta che è formalizzato in fasi: 1. Presentazione delle richieste nell ambito del proprio profilo o livello d autorizzazione. 2. Assegnazione della richiesta da parte del responsabile all incaricato per l evasione della stessa. 3. Svolgimento da parte dell incaricato delle attività necessarie per il completamento della richiesta. Cap. 3 Introduzione al SABS 18

26 3.3 Utenti e permessi 4. Avviso sollecito della conclusione nei confronti del richiedente. 5. Supervisione da parte di un Call Center del flusso operativo per il completamento della richiesta e supporto agli utenti. 3.3 Utenti e permessi Ogni utente che agisce all interno del sistema SABS fa parte di un insieme d utenti con precise caratteristiche di autorizzazione. Per questo motivo ogni utente può svolgere determinate richieste di beni o servizi e attività che cambiano lo stato delle richieste. Considerando che ad ogni bene o servizio è associato uno o più livelli d autorizzazione e che ciascun utente possiede un suo livello d autorizzazione, le attività disponibili (che verranno in seguito dettagliate) sono riportate nella matrice di tabella 3.1 che comprende i livelli d autorizzazione per: 1. Utente Generico 2. Coordinatore Servizio 3. Coordinatore Ufficio 4. Capo Ufficio / Capo Dipartimento 5. Segretario Generale 6. Autorità Politica 7. Dirigente 8. Call Center e le seguenti operazioni: C = Creazione A = Assegnazione E = Evasione S = Splitting Cap. 3 Introduzione al SABS 19

27 3.4 Workflow Ruolo / Operazioni C A E S N Ch M R Utente generico PCM Sì No No No No No No No Call Center Sì Sì No Sì Sì No Sì Sì Capo Ufficio/Dipartimento Sì Sì No Sì No No No No Amministratore Sì No No No No No No No Capo Servizio Sì Sì No Sì No No No No Utente Servente Sì No Sì No No Sì No No Responsabile Servente Sì Sì Sì Sì No Sì No No Tabella 3.1: Matrice Capability List del SABS. N = Notifica Ch = Chiusura M = Modifica R = Rimozione 3.4 Workflow All interno del SABS ogni richiesta (sia di bene sia di servizio) segue un percorso che cambia secondo le azioni degli utenti e gli stati intermedi della richiesta ne costituiscono il suo stato. Ad esempio, quando una richiesta è inizialmente sottomessa da un utente al sistema, essa potrà essere assegnata ad un servente oppure potrà essere suddivisa splitting in più sotto-richieste. Il workflow degli eventi del sistema SABS, ricavato dalla documentazione di progetto, è riassunto graficamente nel diagramma di stato della figura 3.1 (cf. [PdCdM03b]) Sottomissione di una richiesta da parte di un utente Attori: Tutti gli utenti del SABS. All immissione di una richiesta all interno del sistema SABS, la richiesta si troverà nello stato di sottomessa. L immissione di una richiesta di un bene o servizio specifico, può avvenire da parte di un qualunque utente del SABS (purché avente il livello d autorizzazione necessario alla richiesta di quel bene o servizio) indipendentemente dal suo ruolo. Ruoli che hanno il privilegio di sottomettere una richiesta: Cap. 3 Introduzione al SABS 20

28 3.4 Workflow Tutti i ruoli Assegnazione di una richiesta Attori: Call Center, Capo Ufficio/Capo Dipartimento, Capo Servizio. Dopo che una richiesta è stata immessa, questa può essere assegnata o suddivisa in più sottorichieste. La richiesta giunge nello stato di assegnata quando un utente, con specifici privilegi, assegna la richiesta ad un servente. Questa azione è denominata assegnazione della richiesta. In figura 3.1 è indicata con il numero 1. Ruoli che hanno il privilegio di assegnare una richiesta: Call Center Capo Ufficio / Dipartimento Capo Servizio Splitting e generazione di sottorichieste in fase iniziale Attori: Call Center, Capo Ufficio/Capo Dipartimento, Capo Servizio. Una richiesta immessa può in certi casi necessitare d altri beni e servizi che contribuiscono al suo soddisfacimento. In questo caso anziché assegnare direttamente la richiesta ad un servente, l utente può creare tutte le sottorichieste (richieste figlia) di cui la richiesta originaria (richiesta madre) ha bisogno per essere soddisfatta. Lo stato della richiesta passa da sottomessa a diventata madre. Questa azione è denominata splitting della richiesta. Nella figura è indicata con il numero 8. Ruoli che hanno il privilegio di generare sottorichieste: Call Center Capo Ufficio / Dipartimento Capo Servizio Evasione della richiesta e presa in carico Attori: Responsabile Servente, Servente. Quando le richieste sono assegnate ad un ufficio o dipartimento la richiesta si trova nello Cap. 3 Introduzione al SABS 21

29 3.4 Workflow stato di assegnata. Lo stato successivo è quello di presa in carico, in cui un servente ha preso in carico la richiesta per chiuderla. L azione che porta lo stato della richiesta da assegnata a presa in carico è denominata evasione della richiesta. Nella figura è indicata con il numero 2. Ruoli che hanno il privilegio di evadere le richieste: Responsabile Servente Utente Servente Figura 3.1: Diagramma di stato del SABS. Cap. 3 Introduzione al SABS 22

30 3.4 Workflow Chiusura della richiesta ed esito Attori: Responsabile Servente, Servente. Dopo aver preso in carico una richiesta, l utente espleterà l ultima attività che è quella della chiusura. La chiusura di una richiesta può avere diversi esiti. Il primo esito è quello positivo di richiesta soddisfatta. In questo caso la richiesta passa dallo stato di presa in carico a quello di soddisfatta. Nella figura è indicata con il numero 3. Ruoli che hanno il privilegio di chiudere le richieste con stato finale soddisfatta : Responsabile Servente Utente Servente Un altro esito della chiusura della richiesta è quello di richiesta rifiutata. La richiesta si troverà in questo stato quando il servente non potrà servirla. Nella figura è indicata con il numero 4. Ruoli che hanno il privilegio di chiudere le richieste con stato finale rifiutata : Responsabile Servente Utente Servente Una situazione diversa si presenta quando la richiesta necessita di sottorichieste per poter essere evasa. In questo caso abbiamo due possibili esiti secondo il ruolo del servente. Nel caso in cui il servente abbia anche il ruolo di Responsabile Servente, sarà possibile passare ad una fase di splitting della richiesta che la porta dallo stato di presa in carico a quello di madre. Questa azione è indicata in figura con il numero 5. Ruoli che hanno il privilegio di chiudere le richieste con un azione di splitting: Responsabile Servente Nel caso in cui il servente abbia solo il ruolo d Utente Servente la richiesta potrà solo passare dallo stato di presa in carico a quello di parzialmente soddisfatta. Questa azione è indicata in figura con il numero 6. Ruoli che hanno il privilegio di chiudere le richieste con stato finale parzialmente soddisfatta : Cap. 3 Introduzione al SABS 23

31 3.4 Workflow Responsabile Servente Utente Servente Generazione di sottorichieste per richieste parzialmente soddisfatte Attori: Call Center. Quando una richiesta si trova nello stato di parzialmente soddisfatta, questa si troverà in una particolare sezione dell agenda del Responsabile Servente che provvederà alla generazione di tutte le sottorichieste necessarie al suo completamento. Questa azione è denominata splitting della richiesta parzialmente soddisfatta e fa passare lo stato della richiesta da parzialmente soddisfatta a madre. Nella figura è indicata con il numero 7. Ruoli che hanno il privilegio di chiudere le richieste con un azione di splitting: Call Center Negoziazione e modifica della richiesta Attori: Call Center. Una richiesta rifiutata può essere rinegoziata con l utente, in modo da ridefinirne i parametri, eliminando gli impedimenti che non ne hanno reso possibile il soddisfacimento. Questa azione è denominata modifica e porta la richiesta da uno stato di rifiutata a quello di modificata. Nella figura è indicata con il numero 12. Ruoli che hanno il privilegio di chiudere le richieste con un azione di modifica: Call Center Negoziazione e chiusura della richiesta Attori: Call Center. Una richiesta può non essere rinegoziata con l utente perché i parametri della stessa non sono negoziabili. In questo caso la richiesta sarà chiusa con esito negativo. Questa azione è denominata chiusura e porta la richiesta da uno stato di rifiutata a quello di notificata. Nella figura è indicata con il numero 11. Ruoli che hanno il privilegio di chiudere le richieste con un azione di chiusura non negoziabile con successivo stato di notificata : Call Center Cap. 3 Introduzione al SABS 24

32 3.4 Workflow Rimozione della richiesta Attori: Call Center, Capo Ufficio/Capo Dipartimento, Capo Servizio. Una richiesta che giunge nello stato di sottomessa può essere direttamente rimossa dal processo d avanzamento. Questa azione è denominata rimozione e porta la richiesta da uno stato di sottomessa a quello di rimossa. Nella figura è indicata con il numero 14. Ruoli che hanno il privilegio di rimuovere le richieste con successivo stato di rimossa : Call Center Capo Ufficio / Dipartimento Capo Servizio Riassumendo, la richiesta può avere 10 stati (sottomessa, assegnata, presa in carico, soddisfatta, rifiutata, parzialmente soddisfatta, madre, modificata, notificata, rimossa), che a loro volta comprendono 8 operazioni (assegnazione, evasione, chiusura, modifica, splitting, rimozione, automatica, creazione). Cap. 3 Introduzione al SABS 25

33 Capitolo 4 Analisi di strumenti e modelli di simulazione dei workflow Il capitolo riporta le attività di sperimentazione svolte sui sistemi utilizzati per la costruzione di modelli simulativi. 4.1 Fasi di uno studio di simulazione Nello studio di sistemi ad eventi discreti non di rado la complessità del sistema reale che si vuole studiare è tale da rendere impossibile o dispendiosa la valutazione delle prestazioni attraverso l utilizzo di metodi matematici analitici o ibridi, da trattare utilizzando la teoria della probabilità, metodi algebrici o altre tecniche di calcolo. In questi casi al metodo analitico è preferibile il metodo simulativo: mediante un programma di simulazione è possibile riprodurre il funzionamento di un sistema reale in un ambiente controllato. Ciò consente non solo di valutare numericamente il modello del sistema e stimare le grandezze d interesse, ma anche di analizzare il comportamento del sistema rispetto alle possibili condizioni, ad esempio le variazioni rispetto ai parametri di ingresso e di uscita. Un passo del processo consiste nello sviluppo di un modello, che sarà di tipo simulativo e non analitico. Le fasi da svolgere durante uno studio di simulazione, in figura 4.1, sono riconducibili a: 1. Formulazione del problema. Il problema da affrontare deve essere enunciato in relazione agli obiettivi da raggiungere. 2. Creazione (astrazione) del modello. Durante questa fase si cerca di astrarre gli aspetti Cap. 4 Analisi di strumenti e modelli di simulazione dei workflow 26

34 4.1 Fasi di uno studio di simulazione 1 - Formulazione del problema Definizione degli obiettivi 2 - Astrazione del modello 3 - Raccolta dei dati 4 - Codifica del modello NO NO 5 - Verifica NO 6 - Validazione 7 - Progetto degli esperimenti di simulazione 8 - Esecuzione e analisi dei dati Accuratezza? NO 9 - Documentazione e presentazione dei dati Figura 4.1: Fasi di uno studio di simulazione. Cap. 4 Analisi di strumenti e modelli di simulazione dei workflow 27

35 4.1 Fasi di uno studio di simulazione fondamentali di un problema, a partire dalla creazione di un modello semplice da complicare successivamente. 3. Raccolta dei dati. I dati del sistema reale devono essere raccolti in modo da fornirli come input al modello precedentemente creato. Tali dati serviranno nelle fasi successive di convalida del modello. 4. Traduzione (codifica) del modello. Una volta deciso qualche sarà il modello, esso andrà tradotto in codice adatto all interpretazione per mezzo di elaboratori elettronici, solitamente usando un linguaggio di simulazione, oppure scrivendo il proprio simulatore in un linguaggio di programmazione (C, C++, Java, ecc.). 5. Verifica. Il modello software sviluppato deve funzionare correttamente sia nella logica che nelle interfaccia di input e output e per questo deve essere sottoposto a verifica. 6. Convalida (validazione). Durante la fase di validazione è necessario controllare che il modello rappresenta correttamente il sistema reale e, eventualmente, ricalibrare il modello al fine di avvicinarsi quanto più possibile al funzionamento reale. La validazione, solitamente, mira a verificare che i valori di uscita del modello siano i medesimi dei dati raccolti in precedenza. 7. Progetto degli esperimenti. Durante il progetto degli esperimenti devono essere stabilite le alternative da simulare. Per ogni alternativa bisogna stabilire il periodo di inizializzazione, la durata del periodo che si vuole simulare e il numero di repliche da effettuare per ogni prova. 8. Analisi dei risultati. Tramite l analisi dei risultati si stabilisce se sono necessarie altre prove di simulazione. 9. Documentazione. La fase di documentazione serve a integrare il modello delle informazioni utili alla comprensione dello studio, alle alternative degli esperimenti e alle scelte fatte. Cap. 4 Analisi di strumenti e modelli di simulazione dei workflow 28

36 4.2 Strumenti per la simulazione di workflow 4.2 Strumenti per la simulazione di workflow Al fine di automatizzare, in modalità batch, la generazione del carico su sistemi di workflow, si è proceduto ad un analisi di alcuni strumenti utili a comporre un laboratorio di simulazione. Il primo approccio, tramite reti di code, si è rivelato piuttosto limitante data la particolare natura del sistema da simulare in cui deve essere posto l accento nella modellazione dell organizzazione delle risorse (utenti, gruppi e ruoli). Tramite i meccanismi tipici delle reti di code, infatti, sarebbe stato innaturale modellare le informazioni relative alle attività che le risorse (utenti, sistema, trigger esterni) devono svolgere durante un processo di workflow. La scelta più naturale [vda96b], quindi, è stata quella di adottare le strutture delle reti di Petri che meglio si adattano a modellare, tramite il sistema dei Token, un workflow ([vda94] e [vda95]). Dal punto di vista dei framework di simulazione, è stato scelto un approccio ABM (agentbased modeling) ritenuto il più soddisfacente per modellare l interazione umana [Bon02] e integrabile con i processi di workflow [Lam97] e [Jer06]. Nella modellazione ABM, infatti, un sistema è modellato come una collezione di entità autonome e decisionali chiamate agenti. Ogni agente è in grado di conoscere e tenere traccia della propria situazione, in modo da prendere delle decisioni sulla base di un insieme di regole. Gli agenti possono assumere i comportamenti appropriati a seconda del sistema che essi rappresentano. Una caratteristica fondamentale della modellazione ad agenti riguarda le interazioni ripetitive e competitive fra essi, tramite cui è possibile procedere a calcoli matematici tramite elaboratori elettronici. A livello elementare, un modello ad agenti consiste di un sistema di agenti e delle relazioni fra essi. Anche un modello semplice, però, può emulare comportamenti complessi e fornire informazioni e dati utili circa la dinamica del mondo reale che si sta simulando. Oltre ciò, gli agenti sono capaci di evolversi, permettendo l emergere di comportamenti non pianificati. I benefìci della modellazione basata su Agenti, rispetto ad altre tecniche di modellazione, possono riassumersi in tre grandi aree: 1. cattura di fenomeni emergenti o non pianificati; Cap. 4 Analisi di strumenti e modelli di simulazione dei workflow 29

37 4.3 Analisi SABS con Simul8 2. descrizione naturale di un sistema; 3. flessibilità (basti pensare a quanto sia semplice aggiungere nuovi agenti nel sistema). Nei paragrafi seguenti si riportano le attività svolte tramite reti di code (Simul8 ) e tramite framework ad agenti (Swarm, jes, RePast). 4.3 Analisi SABS con Simul8 Il software Simul8, potente ambiente di simulazione grafico (fig. 4.2), è stato utilizzato durante il presente lavoro allo scopo di dare una prima rappresentazione grafica del workflow e tentare una simulazione dello stesso. La prima attività è stata svolta senza problemi e ha posto le basi per la modellazione tramite reti di Petri. La simulazione non è invece stata agevole, né alla fine possibile completamente, per il fatto che il software in questione è un prodotto chiuso e proprietario. Non è stato possibile infatti intervenire in maniera adeguata anche solo tramite sistemi di connessione esterna (ad esempio API ) per programmare le necessarie attività [Cor02] volte alla modellazione di sistemi di workflow tramite reti di Petri e, soprattutto, all introduzione del concetto di agenti. In Simul8 la simulazione basata su agenti pensanti non è possibile. Si ritiene comunque interessante introdurre il pacchetto software e riportare alcuni dettagli delle sperimentazioni fatte. Simul8 [Tse03] è un applicazione industriale per lo studio dei processi di business, un ambiente integrato per lo sviluppo di modelli. È fornito di un numero di estensioni per animazioni grafiche e statistiche e si interfaccia a programmi esterni in ambiente Windows come Excel e Visio. È disegnato per rappresentare vari problemi di business, fra cui la gestione delle catene di provvigione, il disegno di sistemi di produzione e attività relative alla pianificazione delle capacità. Simul8, tramite il sistema integrato di statistiche, produce informazioni relative ai costi o stime dei tempi di attesa degli utenti. Simul8 è un simulatore di eventi discreti, in cui i processi coinvolgono elementi da lavorare, stazioni di lavoro, code, routing. In figura 4.3 sono riportati gli elementi di base di una simulazione con Simul8. Nelle figure 4.4 e 4.5 sono riportate le rappresentazioni dei workflow reali SABS modellate con Simul8. Ogni oggetto ha specifiche proprietà, ad esempio ogni task ha una lista di risorse che sono abilitate ad eseguirlo. Nella seconda figura è possibile notare che la simulazione di un mese, terminata, ha fornito risultati in linea con le statistiche prelevate dal database Cap. 4 Analisi di strumenti e modelli di simulazione dei workflow 30

38 4.3 Analisi SABS con Simul8 Figura 4.2: Simul8. Figura 4.3: Elementi di base di Simul8. Cap. 4 Analisi di strumenti e modelli di simulazione dei workflow 31

39 4.3 Analisi SABS con Simul8 Figura 4.4: Il workflow SABS rappresentato con Simul8 (stati). Cap. 4 Analisi di strumenti e modelli di simulazione dei workflow 32

40 4.3 Analisi SABS con Simul8 Figura 4.5: Il workflow SABS rappresentato con Simul8 (operazioni). Cap. 4 Analisi di strumenti e modelli di simulazione dei workflow 33

41 4.4 Analisi SABS con Swarm SABS in termini di numero di attività completate. Ovviamente, si tratta di una simulazione del tutto generica e non può essere considerata un modello Visio Per completezza, si riporta una rappresentazione del flusso SABS (figura 4.6) creata utilizzando il software MS Visio. 4.4 Analisi SABS con Swarm Il progetto Swarm 1, nato dal lavoro di un gruppo di ricercatori dell Istituto degli Studi sulla Complessità di Santa Fe (New Mexico), ha come obiettivo la facilitazione della ricerca sulla simulazione e sui modelli ad agenti attraverso l utilizzo di strumenti informatici complessi. La biblioteca di funzioni Swarm è diventata uno degli strumenti di riferimento per la modellazione basata su agenti (agent based) di fenomeni fisici, chimici, economici. Swarm supporta l utente nella scrittura del codice Java, inoltre predispone l interfaccia grafica e la gestione della temporizzazione. Swarm consiste in una libreria di funzioni, scritte in Objective-c, un linguaggio orientato agli oggetti. Gli agenti, che costituiscono lo sciame - swarm, sono costruiti all interno di oggetti, le popolazioni di agenti sono riprodotte da classi, un particolare agente è rappresentato da una istanza di classe. La tipologia di agenti è relativa al sistema che si deve simulare, esempi classici sono le unità produttive di un azienda, agenti di borsa, insetti, ambulanze. I singoli agenti potrebbero rappresentare a loro volta degli sciami, permettendo in questo modo una simulazione a più livelli. Al fine di elaborare tutte le attività correlate alle fasi della simulazione elencate a pagina 26, il tool di sviluppo Swarm che è stato analizzato in questo lavoro è jes, Java Enterprise Simulator, realizzato e implementato in linguaggio Java. 4.5 Analisi SABS con jes jes (abbreviazione di Java Enterprise Simulator) è un programma di simulazione d impresa nato nel 2000 dal Dipartimento di scienze economiche e finanziare dell università di Torino. 1 Cap. 4 Analisi di strumenti e modelli di simulazione dei workflow 34

42 4.5 Analisi SABS con jes MODIFICA CHIUSURA (??) CON SOTTOR. SODDISF ATTA RIMOZIONE SPLITTING (??) ASSEGNAZIONE (??) CHIUSURA NOTIFICA PARZ. SODD. CHIUSURA CHIUSURA CREAZIONE MODIFICA ASSEGNAZIONE RIASSEGNAZIONE EVASIONE NOTIFICA SOSPENSIONE SOTTOME SSA ASSEGNA TA ACQUISIT A IDLE SOSPESA EVASA RIMOZIONE CHIUSURA CHIUSURA RIPRESA CHIUSURA MODIFICA STATI SABS VISIO Chart RIFIUTAT A Figura 4.6: Il workflow SABS rappresentato con Visio. Cap. 4 Analisi di strumenti e modelli di simulazione dei workflow 35

43 4.5 Analisi SABS con jes È un modello che poggia sulla libreria di funzioni di Swarm e che permette di riprodurre le realtà delle imprese attraverso l uso di un linguaggio di programmazione [Ter04]. Gli scopi per l utilizzo di jes sono ricostruire un impresa o un organizzazione esistente per simularne il comportamento e studiarne eventuali modifiche organizzative, oppure costruire un impresa virtuale [Ter03] I formalismi Per descrivere il mondo in cui l impresa opera, jes adotta due distinti formalismi: Cosa fare (What to Do, WD) Chi fa che cosa (Which is Doing What, DW) Il primo formalismo permette di effettuare un analisi del Cosa fare in modo che l azienda (o l organizzazione) possa descrivere i passi che conducono agli obiettivi. Il secondo formalismo è legato al Chi fa che cosa con cui possono essere descritte le risorse (beni, servizi, macchine) che l impresa ha a disposizione. La modellazione jes introduce tre concetti di base: ordine, ricetta e unità produttiva. L ordine è la rappresentazione di un elemento da costruire o di una attività da portare avanti. La ricetta è un elenco dei passi da svolgere per l esecuzione di un ordine. L unità produttiva può essere un macchinario o un sistema che esegue alcuni dei passi necessari per l esecuzione dell ordine. Nella simulazione d impresa, vi sono ordini da prendere in carico e da portare a compimento tramite le unità produttive. Esiste anche un terzo formalismo che descrive il Quando fare cosa (When Doing What, WDW) ossia la temporizzazione degli eventi, attraverso l utilizzo delle opportune unità di tempo per tick di simulazione. Per avviare gli ordini all inizio della simulazione si possono seguire tre strade: generare delle ricette in modo casuale; utilizzare le ricette preparate dall utente e avviarle in sequenza; Cap. 4 Analisi di strumenti e modelli di simulazione dei workflow 36

44 4.5 Analisi SABS con jes 7 s 30 4 m 3 42 h 3... Tabella 4.1: Formalismo di una generica ricetta jes. utilizzare le ricette preparate dall utente e avviarle in modo casuale. Nel seguito, si danno cenni sui due formalismi WD e DW Che cosa fare (WD) Il formalismo delle ricette viene utilizzato per raccogliere gli ordini da svolgere attraverso i passi produttivi. Le ricette, di cui l esempio più semplice è riportato in tabella 4.1, sono scritte attraverso una convenzione numerica, in cui i passi sono identificati univocamente e ad essi è affiancata la codifica temporale del tempo necessario allo svolgimento. Riferendosi all esempio citato, sono presenti tre passi produttivi identificati dal codice 7, 4, 42. Il primo verrà svolto in 30 secondi, il secondo in 3 minuti, il terzo in 3 ore. Esistono codifiche apposite per passi produttivi particolari, che permettono il parallelismo, la lavorazione a lotti, l approvvigionamento, fare riferimento a [Ter04] per approfondimenti Chi fa che cosa (DW) Il secondo formalismo rappresenta le unità produttive che producono i beni o servizi quando sono richiamate dalle ricette. Vi sono tre tipi di unità produttive: unità produttive semplici; unità produttive complesse; endunit. Unità semplici Le unità semplici possono svolgere un unica tipologia di attività e questa proprietà è inserita nel file che descrive le unità (unitbasicdata.txt). Le informazioni contenute all interno di questo file sono: il codice dell unità: ogni unità si distingue tramite un identificatore unico; Cap. 4 Analisi di strumenti e modelli di simulazione dei workflow 37

45 4.5 Analisi SABS con jes fase di produzione: indica la tipologia di passo produttivo che l unità semplice può svolgere; utilizzo dei magazzini: indica se all unità è associato un magazzino; costi fissi: i costi fissi che l impresa deve registrare con l utilizzo di questa unità; costi variabili: i costi variabili. Unità complesse Le unità complesse sono in grado di fare più tipologie di operazioni, il cui dettaglio è inserito in un secondo file (units.xls) Creazione del modello SABS virtuale in jes Operazioni preliminari: installazione e studio del database In seguito a contatti con funzionari della Presidenza del Consiglio dei Ministri, è stato fornito un database contenente tutti i dati relativi alle richiesta di acquisizione beni e servizi effettuate online attraverso il sistema SABS. Il database in formato PostgreSQL 8.0.x. si è rivelato, come prevedibile, di una certa complessità ma, grazie alla collaborazione iniziale con il personale della ditta fornitrice e con funzionari della PCM, si è potuto procedere all installazione del database in locale su un server di sviluppo e all analisi autonoma per la comprensione della natura dei relativi elementi logici (tabelle, viste, procedure, ecc). In questa versione del modello si è scelto di circoscrivere le informazioni all anno 2004 poiché all atto dell inizio della modellazione erano le uniche complete. Sono state prodotte alcune statistiche di massima contenenti il numero delle richieste di beni e servizi distinguendole per versione e stati interni (figure 4.7, 4.8, 4.9). Creazione di un foglio spreadsheet di appoggio La prima fase dello studio individuale della banca dati, in particolare, è servita ad individuare fra la vastità delle tabelle e delle altre strutture del DB, quali fossero quelle da considerare per costruire il modello. Si è quindi proceduto ad una scrematura e a un restringimento delle tabelle e procedure SQL da cui ricavare le informazioni. Cap. 4 Analisi di strumenti e modelli di simulazione dei workflow 38

46 4.5 Analisi SABS con jes Idle Sottomessa Assegnata Acquisita Parz. soddisfatta Soddisfatta Rifiutata Evasa Definitivamente Rifiutata Modificata Sospesa Con sottorichieste Figura 4.7: Quantità degli stati delle richieste SABS nell anno 2004 (tutte le versioni sono comprese, non solo lo stato finale) Idle Sottomessa Assegnata Acquisita Parz. soddisfatta Soddisfatta Rifiutata Evasa Definitivamente Rifiutata Modificata Sospesa Con sottorichieste Figura 4.8: Quantità degli stati delle richieste SABS nell anno 2004 (tutte le versioni sono comprese, non solo lo stato finale), ma solo per le richieste che hanno la ultima versione a Soddisfatta oppure Evasa Idle Sottomessa Assegnata Acquisita Parz. soddisfatta Soddisfatta Rifiutata Evasa Definitivamente Rifiutata Modificata Sospesa Con sottorichieste Figura 4.9: finale). Quantità degli stati delle richieste SABS nell anno 2004 (comprende solo lo stato Cap. 4 Analisi di strumenti e modelli di simulazione dei workflow 39

47 4.5 Analisi SABS con jes Attraverso query mirate al database, è stato costruito un foglio spreadsheet di studio chiamato SABS worksheet. I paragrafi seguenti riportano alcune delle attività svolte e riportate nel file. Unità, ordini e ricette in SABS Una unità produttiva è una struttura produttiva, ad esempio un macchinario o una persona che compiono singole azioni, oppure una unità strutturata più complessa, presente all interno del mondo (all interno o all esterno di un impresa), in grado di svolgere alcuni passi necessari per portare a compimento un ordine. Un ordine rappresenta un oggetto che deve essere costruito (prodotti o semilavorati), o un attività che deve essere intrapresa (servizi o atti organizzativi). Le ricette, infine, descrivono i passi che devono essere eseguiti in una certa sequenza per ottenere l esecuzione di un ordine generico. Questi concetti in SABS hanno una traduzione ben precisa. Le unità produttive sono le entità che svolgono le azioni all interno del SABS per portare a compimento un ordine, ossia tutti gli operatori che interagiscono con il sistema: operatori del call center, segretario generale, capi dipartimento, capi ufficio, capi servizio, responsabili dei serventi, utenti serventi e utenti generici. Tutti gli operatori possono richiedere online, attraverso il sito web del SABS, un ordine di beni o servizi, il cui flusso di lavoro è informatizzato e gestibile tramite il sito web. Il flusso costituisce la ricetta per l esecuzione dell ordine e tutti i passi relativi al compimento della richiesta sono memorizzati nel database, compresi i time-stamp che attestano l orario di esecuzione e che sono fondamentali per il calcolo della durata di ogni singola fase di lavoro. Ruoli, privilegi e passi produttivi Per ogni ruolo degli utenti del database sono state estrapolate le relative operazioni possibili, in seguito identificate come fasi o passi produttivi, come indicato in tabella 4.2 e 4.3. Realizzazione delle Unità secondo il formalismo jes Chi fa che cosa (DW) Considerando che in questo modello il livello di dettaglio è piuttosto basso, per ogni utente è stato estrapolato l attributo di ruolo, quindi i relativi passi produttivi per costruire i file Cap. 4 Analisi di strumenti e modelli di simulazione dei workflow 40

48 4.5 Analisi SABS con jes ruolo id ruolo passi produttivi Capo Servizio Utente generico PCM 6 8 Call Center Capo Ufficio Utente servente Responsabile Gruppo Serventi Capo Dipartimento 17 8 Segretario Generale 18 8 Tabella 4.2: Ruoli SABS e relativi passi produttivi in jes. id operazione 1 Assegnazione 2 Evasione 3 Splitting 4 Notifica 5 Chiusura 6 Modifica 7 Rimozione 8 Creazione 13 Riassegnazione 15 Evasione da ConSottorichieste 16 Riattivazione 17 Rifiuto da con Sottorichieste 18 Sospensione 19 Assegnata da Sospesa Tabella 4.3: Codifica dei passi produttivi SABS. di simulazione relativi al formalismo DW di cui segue un estratto in cui i nomi del personale della PCM sono stati mascherati. Nel modello sono presenti n. 357 unità produttive riportate nel file unitdata/legenda Unita fasi.txt. 171 Utente generico PCM abianchi Utente generico PCM bneri Utente generico PCM cverdi 8 3 Call Center dbianchi Call Center eneri Cap. 4 Analisi di strumenti e modelli di simulazione dei workflow 41

49 4.5 Analisi SABS con jes 284 Call Center fverdi Capo Ufficio gbianchi Capo Ufficio hneri Capo Ufficio iverdi Capo Ufficio lbianchi Utente servente mneri Utente servente nverdi Utente servente obianchi Utente servente pneri Di queste, 245 unità sono semplici, le altre 112 complesse. Le unità semplici sono quelle che hanno ruoli Utente generico PCM, Capo Dipartimento oppure Segretario Generale, e sempre fase produttiva pari ad 8. Le unità semplici vengono immediatamente tradotte nel file unitdata/unitbasicdata.txt con un valore diverso da 0 nella terza colonna chiamata prod.phase. unit_# usewarehouse prod.phase_# fixed_costs variable_costs Per le unità complesse è stato creato il foglio spreadsheet unitdata/units.xls contenente un foglio per ogni unità complessa, secondo lo schema in figura 4.10, dove in basso sono presenti i numeri delle singole unità e aprendo il relativo foglio sono presenti i relativi passi produttivi. Il file units.xls è stato realizzato attraverso query al database, l uso del file SABS worksheet precedentemente creato e la macro di excel riportata nel listato A.2 in appendice A. Cap. 4 Analisi di strumenti e modelli di simulazione dei workflow 42

50 4.5 Analisi SABS con jes Figura 4.10: File di jes unitdata/units.xls che contiene le unità complesse SABS. Realizzazione delle Ricette secondo il formalismo jes Cosa fare (WD) Le ricette descrivono il modo in cui gli ordini arrivano a compimento. Per ogni richiesta SABS presente nel database sono state estrapolate le informazioni relative ai tipi di unità produttive che hanno svolto ogni stadio intermedio della richiesta (identificato dal record req ver nel database) ed è stato inserito il tempo di esecuzione di ogni singolo stadio. Allo scopo è stato scritto un programma in PHP, riportato in appendice A. Lo script PHP per le ricette crea un file CSV separato da punto e virgola pronto per Excel, collegandosi al database PostgreSQL locale. Si sottolinea che in prima istanza non è stata effettuata alcuna normalizzazione dei tempi di esecuzione, se non l arrotondamento dei decimali ad un numero intero. Estratto dei risultati dello script PHP per le ricette: "0";"richiesta_SABS_276";"276";"8";"s";"5";"8";"s";"425282";"13";"s"; "674282";"2";"s";"1292";"5";"s";"4";";" "1";"richiesta_SABS_280";"280";"8";"s";"5";"8";"s";"3437";"13";"s"; " ";"2";"s";"72";"5";"s";"1";";" "2";"richiesta_SABS_281";"281";"8";"s";"6";"8";"s";"26294";"13";"s"; "672779";"2";"s";"98754";"5";"s";"5";";" Cap. 4 Analisi di strumenti e modelli di simulazione dei workflow 43

51 4.5 Analisi SABS con jes richiesta SABS s 5 8 s s s s 4 ; A B C D E C D E C D E C D E C D E F Tabella 4.4: Riga della ricetta SABS compilata. Le informazioni estratte sono state riportate nel file recipedata/recipes.xls secondo il formalismo WD dove ogni riga è costituita similmente al modo in tabella 4.4, dove: A = descrizione della richiesta; B = numero identificativo della richiesta; C = per ogni stadio n: unità produttiva del singolo stadio; D = per ogni stadio n: unità di misura del tempo (s=secondi); E = per ogni stadio n: tempo di esecuzione; F = punto e virgola di chiusura riga. Le richieste SABS per questo modello -anno ammontano a un totale di 6919, pertanto il file delle ricette (figura 4.11) contiene 6919 righe non commentate. Esecuzione della simulazione Nella figura 4.12 è riportata una schermata di lancio del simulatore jes, con i parametri pre-impostati tramite il file di configurazione. L esecuzione in jes della simulazione del modello di SABS come sopra descritto (unità, fasi produttive, ordini, ricette) è nella figura I valori calcolati ad ogni tick di orologio per il grafico Ratio in alto a sinistra si trovano nel file data.ratio, di cui si riportano le ultime righe a titolo di esempio e e e+00 Cap. 4 Analisi di strumenti e modelli di simulazione dei workflow 44

52 4.5 Analisi SABS con jes Figura 4.11: File di jes recipedata/recipes.xls che contiene le ricette SABS. Figura 4.12: Schermata del lancio di jes. Cap. 4 Analisi di strumenti e modelli di simulazione dei workflow 45

53 4.5 Analisi SABS con jes Figura 4.13: Schermata dell esecuzione in jes del modello SABS e e e e e e e e+00 Dal grafico in alto a sinistra della figura 4.13 si desume che il ratio stabilizzarsi attorno al valore total time total lenghts sembra Inoltre, dal grafico al centro si nota che è presente una unità produttiva che ha 2 elementi in coda già qualche secondo dopo il lancio della simulazione, ciò comporta un immediato accodamento delle attività dell unità produttiva che cresce con il passare del tempo. Tale unità produttiva si configura come un possibile collo di bottiglia inaspettatamente già dalle prime fasi della simulazione. Cap. 4 Analisi di strumenti e modelli di simulazione dei workflow 46

54 4.6 Analisi SABS con RePast 4.6 Analisi SABS con RePast RePast (Recursive Porous Agent Simulation Toolkit) 2 è una libreria open-source per la modellazione e la simulazione basata su agenti, creata dall Università di Chicago. Anche RePast, come jes, prende in prestito alcuni concetti dello Swarm agent-based modeling toolkit (paragrafo 4.4), in particolare riguardanti la simulazione sociale. RePast differisce da Swarm principalmente perché è implementato in modo nativo in molteplici linguaggi di programmazione e ha caratteristiche incluse quali gli algoritmi genetici e la regressione. In generale, come accennato nell introduzione di questo capitolo, gli strumenti di modellazione basata su agenti supportano lo sviluppo di modelli flessibili del comportamento degli agenti stessi, inclusa la disponibilità di sofisticati scheduler, meccanismi di comunicazione tra agenti, topologie di interazione flessibili, e strumenti per la memorizzazione e la visualizzazione degli stati dell agente. Tipicamente, gli sviluppatori utilizzano le specifiche concettuali di modellazione ad agenti di RePast e costruiscono le simulazioni incorporando i componenti della libreria all interno dei propri programmi Java o utilizzando un ambiente di sviluppo visuale. RePast 3 ha una serie di peculiarità fra cui: include vari template di agenti ed esempi. Il toolkit offre agli utenti una flessibilità completa su come specificare le proprietà e il comportamento degli agenti; è completamente orientato agli oggetti; include uno scheduler di eventi discreti e concorrenti. Tale scheduler supporta operazioni sia di tipo sequenziale che parallelo su eventi discreti; offre strumenti incorporati per il log dei risultati della simulazione e per la relativa visualizzazione grafica; ha un framework automatizzato per la simulazione Monte Carlo; offre un vasto insieme di ambienti e visualizzazioni a due dimensioni degli agenti; permette agli utenti di accedere e modificare dinamicamente le proprietà degli agenti e del modello durante l esecuzione della simulazione; 2 Cap. 4 Analisi di strumenti e modelli di simulazione dei workflow 47

55 4.6 Analisi SABS con RePast include librerie per algoritmi genetici, reti neurali, generazione di numeri casuali, matematica specialistica; include la modellazione di sistemi dinamici; comprende strumenti per la modellazione e il supporto di reti sociali; ha integrato il supporto per i sistemi informativi geografici (GIS); è implementato in vari linguaggi inclusi Java e C#; i modelli per RePast possono essere sviluppati in svariati linguaggi, fra cui Java, C#, C++, Visual Basic.Net, Lisp, Prolog e Python; è disponibile per varie piattaforme, fra cui Windows, Mac OS e Linux. Il supporto delle piattaforme include sia personal computer che cluster per la computazione scientifica su larga scala. Il framework RePast, proprio per le caratteristiche sopra evidenziate, è stato utilizzato nel presente lavoro per implementare il simulatore di workflow descritto nel capitolo 7, ove è possibile verificare i dettagli implementativi di tale soluzione, che permette la modellazione del sistema SABS tramite tale strumento. Cap. 4 Analisi di strumenti e modelli di simulazione dei workflow 48

56 Capitolo 5 Reti di Petri e reti WF-net (workflow-net) Al fine di modellare i workflow, nel capitolo viene fornita una spiegazione teorica di base delle reti di Petri, con le relative proprietà ed estensioni. In particolare, vengono discusse le reti WF-net, che sono un sottoinsieme delle reti di Petri da cui ne ereditano le proprietà. Le reti di Petri vengono introdotte formalmente in questo capitolo, in modo da fornire una chiara ed univoca notazione e analizzare le principali proprietà di interesse, visto l articolato linguaggio scientifico presente al riguardo in letteratura. Si farà riferimento ad una estensione delle reti di Petri, che assumono la denominazione di reti WF-net. Tali reti sono state recentemente introdotte in ambito scientifico al fine di modellare i processi di business sottostanti ai sistemi di Workflow Management Systems. Con le reti WF-net è possibile pertanto formalizzare alcune delle proprietà tipiche dei workflow [WVDA04]. Le reti di Petri, che storicamente hanno origine dal lavoro di Carl Adam Petri ([Pet62]), costituiscono uno strumento espressivo che ben si presta alla modellazione e all analisi di workflow, a causa di vari fattori: le reti di Petri sono un formalismo matematico e grafico allo stesso tempo. Attraverso di esse è possibile applicare al modello il rigore formale necessario sia per eliminare ogni fonte d ambiguità nella rappresentazione, sia per effettuare analisi e verifiche sul comportamento del sistema, utilizzando una vasta gamma di tecniche di analisi (ad esempio basate sull algebra lineare). In seconda istanza, le reti di Petri possono essere Cap. 5 Reti di Petri e reti WF-net (workflow-net) 49

57 5.1 Reti di Petri rappresentate graficamente senza eccessiva difficoltà, sono di facile comprensione e possono essere usate come strumento di aiuto visuale in fase di progetto e di specifica; permettono di decomporre il sistema e rappresentarlo modularmente. Un sistema composto da più sottosistemi che interagiscono fra loro può essere decomposto e poi aggregato attraverso l uso di sottoreti e tramite operatori di rete; consentono la modellazione di sistemi complessi in modo compatto, poiché non c è bisogno di rappresentare tutto lo spazio di stato, ma solo le regole che ne definiscono l evoluzione; consentono di modellare la concorrenza, ossia lo svolgimento di attività parallelamente svolte. 5.1 Reti di Petri Notazioni e definizione Una rete di Petri classica [Mur89] è un grafico diretto bipartito con due tipologie di nodi: i posti, che definiscono lo stato del sistema, e le transizioni, che modificano lo stato. I nodi sono collegati tramite archi diretti e le connessioni fra due nodi dello stesso tipo non sono permesse. Graficamente i posti sono rappresentati da cerchi e le transizioni da rettangoli (o quadrati o barre). Ad ogni instante un posto contiene zero o più token, disegnati come punti di colore nero. Un esempio grafico di rete di Petri è riportato in figura 5.1 in cui sono presenti: Posti (stati parziali della rete, condizioni); Transizioni (eventi, che determinano la modifica di alcuni stati); Flussi (indicanti le transizioni possibili ed in quali stati esse portano); Token (indicanti gli oggetti del sistema: risorse, persone o beni). Lo stato di un sistema è dato dall unione di più stati parziali e indipendenti. Le singole transizioni generalmente non fanno variare lo stato globale del sistema, ma solo una parte, quindi qualora si verifichino due eventi indipendenti in contemporanea essi vengono rappresentati da due distinte transizioni contemporanee. Cap. 5 Reti di Petri e reti WF-net (workflow-net) 50

58 5.1 Reti di Petri Transizione Posto Token Figura 5.1: Una semplice rete di Petri. Definizione (Rete di Petri). Una rete di Petri è una tripla (P, T, F ): - P è un insieme finito di posti, - T è un insieme finito di transizioni (P T = ), - F (P T ) (T P ) è un insieme di archi (relazione di flusso). Un posto p è detto un posto di input di una transizione t se e solo se esiste un arco diretto da p a t. Si utilizza la notazione t per denotare un insieme di posti di input per la transizione t. Le notazioni t, p e p hanno significati simili, ad esempio p è l insieme delle transizioni che condividono p come posto di input. Si sottolinea che gli archi sopra descritti hanno peso pari a 1. Come evidenziato da [vda98], nell ambito delle procedure di workflow non ha senso avere pesi diversi da 1, poiché i posti corrispondono alle condizioni del sistema. Nel seguito ci si baserà sulla notazione formale e le definizioni proposte da [vda98] per le reti di Petri. Lo stato, chiamato anche marcatura, è la distribuzione dei token all interno dei posti, M P N. Gli stati vengono rappresentati come segue: 1p 1 + 2p 2 + 1p 3 + 0p 4 è lo stato con 1 token nel posto p 1, due token in p 2, un token in p 3 e nessun token in p 4. È possibile anche rappresentare questo stato nel modo seguente: p 1 + 2p 2 + p 3. Per comparare gli stati si definisce un ordine parziale. Per ogni coppia di stati M 1 e M 2, M 1 M 2 se e solo se per ogni p : M 1 (p) M 2 (p). Il numero di token può cambiare durante l esecuzione della rete. Le transizioni sono il componente attivo in una rete di Petri: esse modificano lo stato della rete in accordo alla seguente regola di scatto: (i) Una transizione t è detta abilitata se e solo se ogni posto di input p di t contiene al minimo un token. Cap. 5 Reti di Petri e reti WF-net (workflow-net) 51

59 5.1 Reti di Petri (ii) Una transizione abilitata può scattare. Se la transizione t scatta, allora t consuma un token da ogni posto di input p di t e produce un token in ogni posto di output p di t. Data una rete di Petri (P, T, F ) e uno stato M 1, si hanno le seguenti notazioni: - M 1 t M 2 : la transizione t è abilitata nello stato M 1 ; fare scattare t in M 1 porta allo stato M 2. - M 1 M 2 : esiste una transizione t tale che M 1 t M 2. - M 1 σ Mn : la sequenza di scatto σ = t 1 t 2 t 3 t n 1 porta dallo stato M 1 allo stato t M n, ad esempio M 1 t 1 M2 2 t n 1 M n. Uno stato M n è detto raggiungibile da M 1 (notazione M 1 Mn ) se e solo se esiste una sequenza di scatto σ = t 1 t 2 t 3 t n 1 tale che M 1 σ Mn. Da notare che è permessa anche la sequenza di scatto vuota M 1 M1. Si utilizza (P N, M) per denotare una rete di Petri P N con uno stato iniziale M. Uno stato M è uno stato raggiungibile di (P N, M) se e solo se M M Proprietà Le reti di Petri soddisfano le seguenti proprietà. Definizione (Vitalità). Una rete di Petri (P N, M) è viva se e solo se per ogni stato raggiungibile M e per ogni transizione t, esiste uno stato M raggiungibile da M che abiliti t. Una rete di Petri è strutturalmente viva se esiste uno stato iniziale per cui la rete è viva. Definizione (Limitatezza e binarietà). Una rete di Petri (P N, M) è limitata se e solo se per ogni posto p esiste un numero naturale n tale che per ogni stato raggiungibile il numero dei token in p è minore di n. La rete è binaria se e solo se per ogni posto il numero massimo di token non eccede 1. Una rete di Petri è strutturalmente limitata se la rete è limitata per ogni stato iniziale. Definizione (Rete ben formata). Una rete di Petri (P N, M) è ben formata se e solo se esiste uno stato M tale che (P N, M) è viva e limitata. Cap. 5 Reti di Petri e reti WF-net (workflow-net) 52

60 5.1 Reti di Petri I percorsi connettono i nodi tramite sequenze di archi. Definizione (Percorso, elementarietà, assenza di conflitti, alfabeto). Sia P N una rete di Petri. Un percorso C da un nodo n 1 a un nodo n k è una sequenza n 1, n 2,..., n k tale che n i, n i+1 F per 1 i k 1. C è elementare se e solo se, per ogni coppia di nodi n i e n j in C, i j n i n j. C è senza conflitti se e solo se, per ogni posto n j in C e ogni transizione n i in C, j i 1 n j / n j. Per convenienza, si introduce l operatore alfabetico α sui percorsi. Se C = n 1, n 2,..., n k, allora α (C) = {n 1, n 2,..., n k }. Definizione (Rete strettamente connessa). Una rete di Petri è strettamente connessa se e solo se, per ogni coppia di nodi (ad es. posti e transizioni) x ed y, esiste un percorso che porti da x ad y Estensioni delle reti di Petri La modellazione con le reti di Petri classiche può essere limitante qualora i processi reali tendano ad essere particolarmente complessi o di notevoli dimensioni. Per risolvere questi problemi sono state proposte varie estensioni([jen96], [vda94], [vh94]), fra cui le tre più conosciute: (1) l estensione con i colori per modellare i dati, (2) l estensione che tiene conto del tempo, e (3) l estensione che permette di modellare sistemi con strutture gerarchiche. Una rete di Petri estesa con colori, tempo o gerarchie è chiamata ad alto livello (High-level PN). Estensione con i colori Le reti di Petri colorate hanno lo scopo di rappresentare gli attributi degli oggetti che, nel sistema, sono rappresentati dai token (risorse, persone, beni). In queste reti ogni token ha un valore, a cui ci si riferisce come colore. Le transizioni determinano i valori dei token prodotti, sulla base dei valori dei token consumati. Estensione con la temporizzazione Il tempo può essere associato con token, posti e/o transizioni. Vi sono molti modi di introdurre il tempo nelle reti di Petri, volto a descrivere le caratteristiche temporali del sistema fra cui, ad esempio, le durate e le attese nel modello. Cap. 5 Reti di Petri e reti WF-net (workflow-net) 53

61 5.2 Reti WF-net Estensione con le gerarchie Per gestire i sistemi complessi è stata introdotta l estensione delle sottoreti, ossia un insieme di posti, transizioni e sottosistemi. Attraverso le gerarchie è possibile modellare il processo più semplicemente e, inoltre, è vantaggioso poter specificare un maggior numero di dettagli. 5.2 Reti WF-net Notazioni e definizione Le reti per modellare i workflow, chiamate WF-net e inizialmente proposte da W. van der Aalst (TU Eindhoven), costituiscono una ulteriore estensione delle reti di Petri da cui ne ereditano le proprietà. Le reti WF-net aggiungono ulteriori proprietà specifiche per la modellazione dei workflow, in particolare: ogni processo di workflow (ossia la rete) deve avere un unico posto iniziale. Quest ultimo deve avere almeno un arco in uscita verso una transizione. Può avere un arco in entrata proveniente da una transizione che intende ricominciare il processo; ogni processo di worflow deve avere un unico posto finale. Quest ultimo deve avere almeno un arco in entrata proveniente da una transizione (possono essere più di uno), ma non può avere alcun arco in uscita verso transizioni; viene introdotto il concetto di trigger ossia di modo con cui è possibile che una transizione abilitata possa scattare; vengono introdotti i concetti di routing tramite split e join. Definizione (WF-net). Una rete di Petri (P, T, F ) è una rete WF-net (Workflow net) se e solo se: - Esiste un solo posto iniziale i P tale che i = 0. - Esiste un solo posto finale o P tale che o = 0. - Ogni nodo x P T si trova in un percorso che va da i a o. Cap. 5 Reti di Petri e reti WF-net (workflow-net) 54

62 5.2 Reti WF-net Una rete WF-net ha un solo posto di inizio (i) e un solo posto di uscita (o) perché ogni flusso gestito dalla procedura rappresentata da una WF-net è creato quando esso entra nel sistema di WfMS ed è cancellato solo quando esso è stato completamente gestito dal WfMS. Il terzo requisito nella Definizione è stato introdotto per evitare task e/o condizioni pendenti, ad esempio task e condizioni che non contribuiscono all avanzamento del flusso Proprietà Proposizione (Proprietà delle reti WF-net). Sia P N = (P, T, F ) una rete di Petri. - Se P N è una WF-net con posto di inizio i, allora per ogni posto p P : p 0 oppure p = i, ad esempio, i è l unico posto d inizio. - Se P N è una WF-net con posto di uscita o, allora per ogni posto p P : p 0 oppure p = o, ad esempio, o è l unico posto d uscita. - Se P N è una WF-net, aggiungendo una transizione t a P N che connette il posto di uscita o con il posto di inizio i (ad esempio, t = {o} e t = {i}), allora la rete di Petri risultante è strettamente connessa. - Se P N ha un posto di inizio i e un posto di uscita o e aggiungere una transizione t che connette il posto di uscita o con il posto di inizio i produce una rete strettamente connessa, allora ogni nodo x P T si trova su un percorso che va da i a o in P N e la rete P N è una rete WF-net. Per le reti WF-net, un ulteriore importante proprietà deve essere verificata: per ogni flusso, la procedura (ad es. il case del workflow) alla fine deve necessariamente terminare e il momento in cui la procedura termina, nel posto o deve esserci un solo token e gli altri posti devono risultare vuoti. Questi requisiti addizionali corrispondono alla cosiddetta proprietà di correttezza o validità (soundness). Definizione (Correttezza, soundness). Una procedura modellata da una rete WF-net P N = (P, T, F ) è corretta se e solo se: Cap. 5 Reti di Petri e reti WF-net (workflow-net) 55

63 5.2 Reti WF-net Figura 5.2: Routing sequenziale WF-net. (i) Per ogni stato M raggiungibile dallo stato i, esiste una sequenza di scatto che porta lo stato M allo stato o. Formalmente: ) ( ) M (i M M o (ii) Lo stato o è l unico stato raggiungibile dallo stato i con almeno un token nel posto o. Formalmente: ) M (i M M o (M = o) (iii) Non esistono transizioni pendenti in (P N, i). Formalmente: t T M,M i M t M Trigger Il momento in cui una transizione è abilitata e quello in cui essa scatta sono differenti, come si deduce dalla regola di scatto descritta a pagina 51. Un trigger è la causa che determina lo scatto di una transizione abilitata. Nelle reti WF-net vi sono quattro tipologie di trigger (compresa quella automatica tipica delle reti di Petri) descritte in tabella Routing Il routing che permette lo spostamento dal posto iniziale al posto finale all interno di un processo di workflow può essere di diversi tipi: sequenziale in fig. 5.2, parallelo in fig. 5.3, condizionale in fig. 5.4, iterativo in fig Split e Join I costrutti di split e join nelle tabelle 5.2 e 5.3 servono ad implementare le politiche di routing. Cap. 5 Reti di Petri e reti WF-net (workflow-net) 56

64 5.2 Reti WF-net Automatico Utente Tempo Messaggio Una attività viene fatta cominciare nel momento in cui la transizione diventa abilitata. Essa non viene messa in coda. Una attività viene fatta cominciare da un partecipante umano, ad esempio un utente che seleziona una istanza di un attività per eseguirla. In un workflow management system ogni utente ha a disposizione un contenitore virtuale di istanze di attività di tipo abilitato, che possono essere eseguite dall utente. Quando l utente seleziona e completa l attività, la corrispondente istanza scatta nel workflow e quest ultimo avanza al prossimo passo del processo. Una attività abilitata viene fatta cominciare da un timer ad un orario predefinito o dopo un numero predefinito di ore, in modalità batch (ad esempio tramite Crontab Unix). Questa dovrebbe essere una delle opzioni in un OR split implicito (cf. pag. 59). Un evento esterno, ad esempio un messaggio, fa scattare una attività abilitata. Esempi di messaggi sono , telefonate, fax. Tabella 5.1: Tipologie di trigger WF-net. Figura 5.3: Routing parallelo WF-net. Figura 5.4: Routing condizionale WF-net. Cap. 5 Reti di Petri e reti WF-net (workflow-net) 57

65 5.2 Reti WF-net Figura 5.5: Routing iterativo WF-net. AND split Un esempio di routing parallelo in cui varie attività sono svolte in parallelo o senza un ordine particolare. È modellato da una transizione con un posto di input e due o più posti di output. Quando scatta, la transizione crea i token in tutti i posti di output. AND join Una transizione con due o più posti di input e un unico posto di output. Viene abilitata quando c è almeno un token in tutti i posti di input, ossia quando tutti i percorsi paralleli dell esecuzione terminano. OR split esplicito Un esempio di routing condizionale dove la decisione viene presa il più presto possibile. È modellato unendo delle condizioni chiamate guard all arco che esce dalla transizione. Un guard è un espressione associata ad un arco, tra parentesi, che può essere vera o falsa. I token possono attraversare gli archi solo quando le espressioni sono vere. Tabella 5.2: Tipologie di split e join WF-net (1). Cap. 5 Reti di Petri e reti WF-net (workflow-net) 58

66 5.2 Reti WF-net OR split implicito Un esempio di routing condizionale dove la decisione viene presa il più tardi possibile. È modellato come due archi che provengono da uno stesso posto ma vanno verso transizioni differenti. In questo modo, la transizione che per prima scatta (ciò dipende dai suoi trigger) riceverà il token. Una volta che il token va avanti, gli altri non sono più abilitati e quindi non possono essere soggetti allo scatto. Una delle transizioni, quindi, deve avere un trigger di tempo (un timer) per avere la speranza di poter fare lo scatto, in modo da farlo se l altra transizione non è ancora attivata prima della scadenza del tempo previsto. OR join (explicito e implicito) Si tratta semplicemente di un posto che riceve due o più transizioni in entrata. In questo modo, la successiva transizione a seguito dell OR join viene abilitata se tutti i processi in entrata sono conclusi. Tabella 5.3: Tipologie di split e join WF-net (2). Cap. 5 Reti di Petri e reti WF-net (workflow-net) 59

67 5.3 Modellazione di workflow tramite reti di Petri e reti WF-net 5.3 Modellazione di workflow tramite reti di Petri e reti WFnet Per meglio comprendere come modellare i workflow [Wri01], viene mostrato un generico esempio di processo di workflow che utilizza reti di Petri e WF-net [RADT06], illustrato in figura 5.6 a pagina 61. Quando il workflow comincia, un token viene inserito nel posto di inizio (A nell esempio) e la transizione automatica Inizio processo si abilita e scatta. Un nuovo token viene inserito nel posto successivo (B) e la transizione automatica Transazione Carta di Credito si abilita. La transizione scatta con un successo o un errore, che sono le etichette (guard) della transizione. Le etichette che risultano essere vere vengono percorse (routing condizionale). Se con successo, la transizione produce un token nel posto E, altrimenti nel posto C. La transizione Transazione Carta di Credito agisce come un OR-split esplicito, poiché è necessario scegliere solo uno dei due percorsi. È presente un altra forma di routing condizionale, che però equivale a un OR-split implicito, nel momento in cui si deve scegliere tra Aggiornare dati Pagamento e Cancellare Ordine. Infatti, poiché c è un unico token nel posto D, solo una delle due transizioni potrà riceverlo. Ma, contrariamente all OR-split esplicito in cui la decisione è esplicitamente fatta appena termina la Transazione Carta di Credito, la scelta fra Aggiornare dati Pagamento e Cancellare Ordine è fatta il più tardi possibile. Entrambe le transizioni saranno abilitate quando sarà presente un token nel posto D (ad esempio quando la comunicazione di avvertimento al cliente è stata spedita). Se l utente aggiorna i propri dati di pagamento prima che la transizione temporizzata Cancellare Ordine si abiliti ad un determinato orario, Cancellare Ordine non scatterà mai. Viceversa, se l ordine viene cancellato, allora l utente non potrà aggiornare le informazioni di pagamento e dovrà inserire un nuovo ordine. Per questo motivo, la scelta è fatta implicitamente, sulla base del tempo. Cap. 5 Reti di Petri e reti WF-net (workflow-net) 60

68 5.3 Modellazione di workflow tramite reti di Petri e reti WF-net [completo] A Inizio processo B Transazione Carta di Credito [successo] E Fare pacco H Spedire [errore] [incompleto] C F Avvertire l'acquirente Ordinare D G [aggiornare] Aggiornare dati di Pagamento Cancellare Ordine Ricevere I Fine processo J [cancellare] Figura 5.6: Esempio di workflow (gestione ordini) rappresentato con WF-net. Cap. 5 Reti di Petri e reti WF-net (workflow-net) 61

69 Capitolo 6 Modellazione dei workflow SABS Nel capitolo i workflow del SABS sono determinati e formalizzati tramite reti di Petri e WF-net. Vengono inoltre identificate le caratteristiche e i parametri del sistema e, infine, raccolti i relativi dati dall impianto reale. 6.1 Individuazione e analisi dei workflow reali Sulla base delle caratteristiche del sistema SABS descritte nel capitolo 3, in particolare nella sezione 3.4, si è proceduto ad analizzare la documentazione fornita e i contenuti del database al fine di individuare un workflow quanto più aderente alla realtà. Il reale flusso di lavoro è rappresentato nella figura 6.1. In figura 6.2 è mostrato il risultato finale dell estrapolazione dell automa a stati implicitamente presente nel sistema. Per quanto riguarda le operazioni, è stata compilata la matrice in figura 6.3. L analisi del workflow ha evidenziato da subito alcuni macro-problemi, in particolare: 1. Lo stadio n.4 parzialmente soddisfatta è un dead-step, ossia uno stadio che inserisce l istanza del flusso in esecuzione in una sorta di limbo. 2. La transazione dallo stadio n.0 sottomessa allo stadio n.4 notifica non ha senso logico, poiché il lavoro richiesto viene evaso direttamente senza passare per gli altri stadi (soprattutto se, come sembrerebbe essere, si interpreta l evasione come conseguenza del soddisfacimento del lavoro). 3. Lo stadio finale n.7 evasa implica il concetto di evasione e soddisfacimento della richiesta, con soluzione del problema posto (ad esempio, la fornitura di un bene). Cap. 6 Modellazione dei workflow SABS 62

70 6.1 Individuazione e analisi dei workflow reali IDLE RIMOZIONE CREAZIONE (*) MODIFICA (*) CHIUSURA SOTTOMESSA RIMOZIONE MODIFICA CON SOTTOR. MODIFICA CHIUSURA ASSEGNAZIONE (*) CHIUSURA ASSEGNATA RIASSEGNAZIONE EVASIONE CHIUSURA ACQUISITA CHIUSURA SODDISFATTA RIPRESA SOSPENSIONE CHIUSURA RIFIUTATA. SOSPESA PARZ. SODD. EVASA NOTIFICA NOTIFICA (*) Figura 6.1: Flusso di lavoro del SABS. Figura 6.2: Automa a stati SABS identificato. Cap. 6 Modellazione dei workflow SABS 63

71 6.2 Rappresentazione dei workflow SABS reali mediante reti di Petri e WF-net Figura 6.3: Matrice operazioni - operazioni del SABS. È però impossibile modellare una rete WF-net con uno stadio finale di questo tipo: l uscita deve permettere il soddisfacimento del flusso anche se la soluzione del problema posto non è intervenuta, altrimenti il flusso rimane inesorabilmente inconcluso. 6.2 Rappresentazione dei workflow SABS reali mediante reti di Petri e WF-net Utilizzando un astrazione delle notazioni di base delle reti di Petri [Nut93], sulla base dei ragionamenti presenti in [vda02], si è formulata la bozza di workflow reale rappresentata in figura 6.4 a pagina 65. La rete così modellata non soddisfa però le proprietà di correttezza (soundness) e vitalità descritte nel capitolo 5. Dato che il workflow SABS è stato nel frattempo modificato nei sistemi in produzione, vale la pena effettuare le verifiche delle proprietà su un modello semplificato (suddiviso nelle due fig. 6.5 e fig. 6.6 alle pagine 66 e 67) che, seppur non comprendendo tutte le caratteristiche funzionali del flusso del SABS, soddisfa appieno le proprietà specifiche delle reti WF-net e permette di valutarne le caratteristiche nel complesso. Cap. 6 Modellazione dei workflow SABS 64

72 6.2 Rappresentazione dei workflow SABS reali mediante reti di Petri e WF-net Figura 6.4: Modellazione del workflow SABS tramite reti di Petri. Cap. 6 Modellazione dei workflow SABS 65

73 6.2 Rappresentazione dei workflow SABS reali mediante reti di Petri e WF-net Figura 6.5: Modellazione semplificata del workflow SABS tramite reti di Petri WF-net; soddisfa le proprietà WF-net (1). Cap. 6 Modellazione dei workflow SABS 66

74 6.2 Rappresentazione dei workflow SABS reali mediante reti di Petri e WF-net Figura 6.6: Modellazione semplificata del workflow SABS tramite reti di Petri WF-net; soddisfa le proprietà WF-net (2). Cap. 6 Modellazione dei workflow SABS 67

75 6.3 Verifica delle proprietà dei workflow rappresentati con reti di Petri e WF-net State Machine Marked Graph Free Choice Net Extended Free Choice Net Simple Net Extended Simple Net Sì No Sì Sì Sì Sì Tabella 6.1: Classificazione del modello SABS semplificato. Figura 6.7: Strumento diagnostico Woflan per la verifica delle proprietà del modello SABS. 6.3 Verifica delle proprietà dei workflow rappresentati con reti di Petri e WF-net Classificazione Rispetto alle caratteristiche di base delle reti di Petri, il modello semplificato così individuato è classificabile [vda97] come in tabella Correttezza (soundness) e Vitalità Il modello semplificato soddisfa le proprietà di rete ben formata [vda96a] e vitalità previste per le reti di Petri (cf. sezione 5.1.2). Tramite lo strumento diagnostico Woflan 1 [vdadhhv97a] e [vdadhhv97b], in figura 6.7, si è verificato che: il workflow così modellato soddisfa i principi del workflow process definition (definizio- 1 Cap. 6 Modellazione dei workflow SABS 68

76 6.4 Modellazione delle risorse ne del processo che identifica le varie attività di processo, le regole procedurali e i dati di controllo associati utilizzati per gestire il workflow durante la fase di abilitazione del processo stesso); tutti i percorsi condizionali sono salvaguardati; il workflow è vitale; il workflow è corretto (soundness) (cf. par ). 6.4 Modellazione delle risorse Il SABS è un workflow inter-organizzativo perché al suo interno, oltre al processo, è presente anche una rappresentazione dell organizzazione (in questo caso degli uffici della Presidenza del Consiglio dei Ministri). La rappresentazione dell organizzazione nei workflow interorganizzativi è basata sulla definizione di precisi ruoli e gruppi, di cui fanno parte le risorse. Ogni risorsa solitamente fa parte sia di un ruolo che di un gruppo. Per modellare il SABS si è stabilito che le risorse vengono mappate con gli utenti del sistema SABS, ossia il personale della PCM, e che i ruoli sono univocamente assegnati ad essi sulla base dei valori riportati nella tabella 6.2. Più utenti possono far parte di uno stesso ruolo. ruolo id ruolo Capo Servizio 4 Utente generico PCM 6 Call Center 7 Capo Ufficio 8 Utente servente 9 Responsabile Gruppo Serventi 10 Capo Dipartimento 17 Segretario Generale 18 Tabella 6.2: Il concetto di ruolo nel SABS. L organizzazione, ossia l appartenenza ad un determinato Dipartimento, Ufficio o Servizio, è stata modellata come segue: per ogni utente è stato creato un vettore contenente gli identificativi logici univoci delle entità dipartimento, ufficio e servizio. Questi valori sono Cap. 6 Modellazione dei workflow SABS 69

77 6.5 Identificazione delle caratteristiche di impianto stati accorpati, separandoli da un segno trattino, in modo da costituire un quarto identificatore unico, denominato id organizzazione. L id organizzazione così prodotto svolge a tutti gli effetti funzione di gruppo e più utenti possono far parte di uno stesso gruppo. Nella tabella 6.3 è riportato un estratto (con nominativi mascherati) della modellazione di risorse, ruoli e gruppi. Si noti che i primi tre utenti fanno parte della stessa area organizzativa e probabilmente il primo e il terzo, ricoprendo anche lo stesso ruolo, lavorano insieme. Il quarto, un capo ufficio, ha il terzo valore in id organizzazione pari a zero (il Servizio). nome id risorsa id ruolo id organizzazione abianchi brossi cverdi dviola eneri Tabella 6.3: Risorse, ruoli e gruppi: esempio per il workflow inter-organizzativo SABS. Per un esempio di come sia possibile associare i valori di risorse, ruoli e organizzazioni alla rete SABS WF-net semplificata definita nei paragrafi precedenti, nelle figure 6.8 e 6.9 sono presenti la rete SABS, modellata con l aggiunta delle risorse, e l area di gestione dell organizzazione sopra discussa. 6.5 Identificazione delle caratteristiche di impianto L impianto da simulare è caratterizzato dalla rete di Petri discussa nei paragrafi precedenti. Tale impianto rispetta le ulteriori specifiche e definizioni che seguono. La definizione astratta di un workflow è chiamata Case Type. Ad esempio, nel workflow di gestione ordini descritto nel paragrafo 5.3 a pagina 60, il Case Type è il processo che definisce come le ordinazioni vengono svolte. I Case Type sono composti da task connessi tramite costrutti di routing. Per esempio, sempre in riferimento alla gestione ordini, Transazione con carta di credito è un task del Case Type Gestione Ordini. Dopo che il task viene svolto, altri task saranno abilitati in base al risultato del task Transazione con carta di credito e tali task sono connessi attraverso percorsi di routing. Un Case Type definisce tutte le possibili esecuzioni, o istanze, di un processo. Una Cap. 6 Modellazione dei workflow SABS 70

78 6.5 Identificazione delle caratteristiche di impianto Figura 6.8: Esempio di gestione dell organizzazione. Figura 6.9: Applicazione dell organizzazione alla rete SABS. Cap. 6 Modellazione dei workflow SABS 71

79 6.6 Identificazione dei parametri di impianto istanza specifica di un CaseType è chiamata Case. Per esempio, l ordine di un notebook è un Case del Case Type Gestione Ordini. In un Case, i task di un Case Type hanno due stati differenti: un task abilitato (pronto per lo scatto) è chiamato Work Item, mentre un task in esecuzione è chiamato una Activity. Per esempio, se un token si presenta nel posto che precede il task Transazione con carta di credito esso diventa un Work Item e può essere svolto da qualche utente del sistema. Se un utente svolge il Work Item, il task diventa una Activity (in progresso) fino a che viene completato. L utente, in pratica, si impossessa del Work Item (check-out) e svolge l attività in esso descritta. Sulla base delle caratteristiche delle reti di Petri descritte nel capitolo 5, i posti e le transizioni rappresentano l aspetto statico di una rete di Petri e i token rappresentano l aspetto dinamico. Nelle reti di Patri classiche, quando una transizione scatta essa consuma esattamente un token per ogni input e produce esattamente un token per ogni output. Allo scopo di costruire un simulatore che sia il più generale possibile, ossia in grado di riprodurre costrutti di routing più sofisticati, verranno utilizzate le reti di Petri colorate, ove ogni token ha un colore (che rappresenta il suo valore), e lo scatto di una transizione consuma e produce un numero di token in funzione del colore del token. Per rappresentare quanti token vengono consumati e prodotti da una transizione, nel simulatore saranno utilizzati archi pesati, in cui il peso è un espressione di tipo intero. In questo modo, una transizione che scatta produce un numero di token pari al peso dell arco per ogni input e consuma un numero di token pari al peso dell arco per ogni output. La rappresentazione del workflow tramite Petri mette in corrispondenza i posti ai possibili stati di esecuzione di un Case, le transizioni ai task, i token allo stato corrente del Case. In figura 6.10 è rappresentato il Case Type Gestione Ordini di pagina 60 con dei Case in esecuzione e un Case di esempio (è possibile notarne i token), nel rispetto delle caratteristiche appena evidenziate. 6.6 Identificazione dei parametri di impianto Il modello SABS è stato scelto come caso di studio per il modello di simulazione di workflow. A questo scopo, sono stati prima identificati i parametri dell impianto e poi si è proceduto alla raccolta dei dati del sistema SABS reale. Cap. 6 Modellazione dei workflow SABS 72

80 6.6 Identificazione dei parametri di impianto Figura 6.10: Case Type Gestione Ordini con la descrizione dell impianto. I parametri da raccogliere dal sistema reale SABS (input) sono i seguenti: Numero di utenti. Elenco degli utenti. Dettagli relativi all organizzazione, ossia elenco dei ruoli e mappatura ruoli-utenti. Dettagli relativi alla rete, secondo Petri, ossia elenco di posti e di transizioni. Per ogni transizione è necessario raccogliere: tempo medio per svolgere la transizione (tempo di servizio richiesto dai task (job)); archi di input dai posti alla transizione, con relativi pesi o condizioni; archi di output dalla transizione ai posti, con relativi pesi o condizioni; tipologia di scatto (automatico, a tempo, tramite risorsa, tramite messaggio); se la tipologia di scatto è tramite risorsa, elenco dei ruoli (risorse) che possono svolgere la transizione. Numero di task che entrano nel sistema nell unità di tempo (frequenza di arrivo). Numero di task assegnati agli utenti nell unità di tempo. Cap. 6 Modellazione dei workflow SABS 73

81 6.7 Raccolta dei dati dell impianto Numero massimo di task che un utente può contemporaneamente svolgere. I parametri da calcolare tramite la simulazione (output) sono i seguenti: Periodo di tempo di occupazione dell utente rispetto al periodo totale (fattore di utilizzazione delle risorse). Numero massimo, medio, minimo di task assegnati in generale per unità di tempo. Numero medio di task assegnati a ogni singolo utente per unità di tempo. Numero di task che escono dal sistema per unità di tempo (throughput globale medio). Tempo medio di percorrenza di un token dall inizio alla fine del percorso. Numero di transazioni completate (percorrenza di un token dall inizio alla fine del percorso) per unità di tempo. Numero di casi chiusi (totale). Numero di task eseguiti (totale). Numero di casi rifiutati perché gli utenti erano oberati (totale). Per ogni singolo utente del sistema, per unità di tempo: Numero di task assegnati. Numero di flussi chiusi. Numero di task eseguiti. Numero di task rifiutati. 6.7 Raccolta dei dati dell impianto I dati del sistema reale SABS sono stati raccolti in modo da fornirli come input al modello precedentemente creato. In prima approssimazione sono stati raccolti i dati per il SABS semplificato. In seguito, si è proceduto alla raccolta dei dati del SABS reale. Cap. 6 Modellazione dei workflow SABS 74

82 6.7 Raccolta dei dati dell impianto Figura 6.11: Denominazione di posti e transizioni del sistema SABS semplificato. Cap. 6 Modellazione dei workflow SABS 75

83 6.7 Raccolta dei dati dell impianto Raccolta dei dati dal sistema SABS semplificato (con approssimazione) 1. Numero di utenti: N utenti = Elenco degli utenti. L elenco è stato estrapolato dal sistema e reso disponibile per il modello. Fare riferimento al codice sorgente del simulatore, file WorkflowDefinition.java, CaseType SabsSemplCaseType. 3. Dettagli relativi all organizzazione, ossia elenco dei ruoli e mappatura ruoli-utenti. L elenco dei ruoli è presente in tabella 6.2 e la corrispondenza fra utenti e ruoli è stata estrapolata dal sistema e resa disponibile per il modello. Fare riferimento al codice sorgente del simulatore, file WorkflowDefinition.java, CaseType SabsSemplCaseType. N ruoli = Dettagli relativi alla rete, secondo Petri, ossia elenco di posti e di transizioni. La denominazione di posti e transizioni segue la rete riportata in figura I posti sono stati classificati con una lettera maiuscola dell alfabeto italiano da A a R comprese. Il totale dei posti del modello SABS semplificato è: N posti = 16. Le transizioni sono state classificate con una lettera minuscola dell alfabeto italiano da a a u comprese. Il totale delle transizioni del modello SABS semplificato è: N transizioni = 19. Il totale degli archi del modello SABS semplificato è: N archi = 38. Per quanto riguarda le transizioni, sono stati raccolti i dati in tabella 6.4. Cap. 6 Modellazione dei workflow SABS 76

84 6.7 Raccolta dei dati dell impianto t T servizio p input p output scatto risorse a 0 A, 1 B, 1 iniz. da risorse SabsTutti - SabsCallCenter b 0 B, 1 C, 1 automatico c 0.14 g C, 1 D, 1 da risorse SabsCapoServizio + SabsCallCenter + SabsCapoUfficio - utente che ha svolto $a d 0 D, 1 G, 1 automatico e 0 B, 1 E, 1 automatico f 0 E, 1 F, 1 automatico g 0 F, 1 G, 1 automatico h 1.33 g G, 1 H, 1 da risorse SabsCapoServizio + SabsCapoUfficio + SabsUtenteServente + SabsRespServenti - utente che ha svolto $a i 1.90 g H, 1 I, 1 da risorse utente che ha svolto $h + SabsCapoServizio + SabsCapoUfficio + SabsRespServenti - utente che ha svolto $a l g I, 1 L, 1 da risorse utente che ha svolto $h m 0 L, 1 Q, 1 automatico n g I, 1 M, 1 da risorse utente che ha svolto $h o 0 M, 1 P, 1 automatico p 1.90 g H, 1 N, 1 da risorse utente che ha svolto $h + SabsCapoServizio + SabsCapoUfficio + SabsRespServenti - utente che ha svolto $a q 0 N, 1 P, 1 automatico r 1.33 g G, 1 O, 1 da risorse SabsCapoServizio + SabsCapoUfficio + SabsUtenteServente + SabsRespServenti - utente che ha svolto $a s 0 O, 1 P, 1 automatico Cap. 6 Modellazione dei workflow SABS 77

85 6.7 Raccolta dei dati dell impianto t 0 P, 1 Q, 1 automatico u 0 Q, 1 R, 1 automatico Tabella 6.4: Parametri di impianto raccolti relativi alle transizioni di Petri del modello SABS semplificato. Calcolo delle matrici di incidenza per il sistema semplificato SABS. a o s q m t u e b c f g d h r p i l n A B N L M P Q R C E D F G H O I Tabella 6.5: Matrice di Incidenza in avanti I+ (modello semplificato). Cap. 6 Modellazione dei workflow SABS 78

86 6.7 Raccolta dei dati dell impianto a o s q m t u e b c f g d h r p i l n A B N L M P Q R C E D F G H O I Tabella 6.6: Matrice di Incidenza indietro I (modello semplificato). a o s q m t u e b c f g d h r p i l n A B N L M P Q R C E D F G H O I Tabella 6.7: Matrice di Incidenza combinata I (modello semplificato). Cap. 6 Modellazione dei workflow SABS 79

87 6.7 Raccolta dei dati dell impianto Calcolo dei tempi di lavoro dal sistema semplificato SABS. Transizione c. Tramite la query SQL seguente al database sottostante l applicazione SABS, è stata estrapolata la media, in secondi, per l esecuzione dell operazione di Assegnazione manuale (transizione c ) - stato della richiesta: Sottomessa. Vengono eliminate le assegnazioni automatiche tramite la condizione tempo > 5 secondi. select AVG(tempo) from storico.tempi_lavoro where id_stato=0 AND tempo > 5; Risultato: Poiché vale la conversione secondi = giorni (tre ore e mezzo), tale valore approssimato a 0.14 sarà il tempo di lavoro della transizione c. Transizioni h e r. Tramite la query SQL seguente, è stata estrapolata la media, in secondi, per l esecuzione delle operazioni successive a quella di Assegnazione - stato della richiesta: Assegnata. select AVG(tempo) from storico.tempi_lavoro where id_stato=1; Risultato: Poiché vale la conversione secondi = giorni, tale valore approssimato a 1.33 sarà il tempo di lavoro delle transizioni h e r. Transizioni i e p. Tramite le query SQL seguenti, è stata estrapolata la media, in secondi, per l esecuzione delle operazioni successive alla h - stato della richiesta: Assegnata. select AVG(tempo) from storico.tempi_lavoro where id_stato=1 AND req_ver>1; Risultato: Poiché vale la conversione secondi = giorni, tale valore approssimato a 1.90 sarà il tempo di lavoro delle transizioni i e p. Cap. 6 Modellazione dei workflow SABS 80

88 6.7 Raccolta dei dati dell impianto Transizioni l e n. Tramite la query SQL seguente, è stata estrapolata la media, in secondi, per l esecuzione dell operazione di evasione (transizione l ) e parziale evasione (transizione n ) - stato della richiesta: Acquisita. select AVG(tempo) from storico.tempi_lavoro where id_stato=3; Risultato: Poiché vale la conversione secondi = giorni, tale valore approssimato a sarà il tempo di lavoro delle transizioni l e n Raccolta dei dati dal sistema SABS reale (senza approssimazione) 1. Numero di utenti: N utenti = Elenco degli utenti. L elenco è stato estrapolato dal sistema e reso disponibile per il modello. Fare riferimento al codice sorgente del simulatore, file WorkflowDefinition.java, CaseType SabsCaseType. 3. Dettagli relativi all organizzazione, ossia elenco dei ruoli e mappatura ruoli-utenti. L elenco dei ruoli è presente in tabella 6.2 e la corrispondenza fra utenti e ruoli è stata estrapolata dal sistema e resa disponibile per il modello. Fare riferimento al codice sorgente del simulatore, file WorkflowDefinition.java, CaseType SabsCaseType. N ruoli = Dettagli relativi alla rete, secondo Petri, ossia elenco di posti e di transizioni. La denominazione d posti e transizioni segue la rete riportata in figura I posti sono stati classificati con una lettera maiuscola dell alfabeto inglese da A a K comprese. Il totale dei posti del modello SABS reale è: N posti = 11. Le transizioni sono state classificate con una lettera minuscola dell alfabeto inglese da a a n comprese. Il totale delle transizioni del modello SABS reale è: Cap. 6 Modellazione dei workflow SABS 81

89 6.7 Raccolta dei dati dell impianto Figura 6.12: Denominazione di posti e transizioni del sistema SABS reale. Cap. 6 Modellazione dei workflow SABS 82

90 6.7 Raccolta dei dati dell impianto N transizioni = 14. Il totale degli archi del modello SABS reale è: N archi = 38. Per quanto riguarda le transizioni, sono stati raccolti i dati in tabella 6.8. t T servizio p input p output scatto risorse a 0.82 g A B iniz. da risorse SabsTutti - SabsCallCenter b 1.57 g B C da risorse SabsCapoServizio + SabsCapoUfficio + SabsCallCenter - utente che ha svolto $a c 0.39 g C, H B da risorse SabsCallCenter d g C E da risorse SabsCapoServizio + SabsCapoUfficio + SabsUtenteServente + SabsRespServenti - utente che ha svolto $a e g C, E D da risorse SabsCapoServizio + SabsCapoUfficio + SabsUtenteServente + SabsRespServenti - utente che ha svolto $a f 0.01 g C, E, F H, I, F da risorse SabsCapoServizio + SabsCapoUfficio + SabsUtenteServente + SabsRespServenti - utente che ha svolto $a g g C, G J da risorse SabsCallCenter h 2.05 g C C da risorse SabsCapoServizio + SabsCapoUfficio + SabsUtenteServente + SabsRespServenti - utente che ha svolto $a i 4.31 g C, G G da risorse SabsCapoServizio + SabsCapoUfficio + SabsCallCenter - utente che ha svolto $a j 0 g G I da risorse SabsCapoServizio + SabsCapoUfficio + SabsCallCenter - utente che ha svolto $a k 0 g D C da risorse SabsCapoServizio + SabsCapoUfficio + SabsUtenteServente + SabsRespServenti - utente che ha svolto $a Cap. 6 Modellazione dei workflow SABS 83

91 6.7 Raccolta dei dati dell impianto l 0.96 g D E da risorse SabsCapoServizio + SabsCapoUfficio + SabsUtenteServente + SabsRespServenti - utente che ha svolto $a m 0 g G H da risorse SabsCapoServizio + SabsCapoUfficio + SabsCallCenter - utente che ha svolto $a n g I, F, J K automatico Tabella 6.8: Parametri di impianto raccolti relativi alle transizioni di Petri del modello SABS reale. 5. Numero di task che entrano nel sistema nell unità di tempo (tasso di arrivo): λ = 55 task g. 6. Numero di task assegnati agli utenti nell unità di tempo (tasso di assegnazione) 2 : µ = 209 task g. 7. Numero massimo di task che un utente può contemporaneamente svolgere (occupazione massima) 3 : N maxt ask = Si intende il numero di operazioni da distribuire agli agenti, non il tipo (creazione, assegnazione, acquisizione, etc). La parola assegnazione, quindi, in questo contesto non fa riferimento all operazione SABS di assegnazione (id 1). 3 Tale valore non è presente nel SABS, ove non è previsto un numero massimo di attività per utente. È però un parametro utile ai fini della valutazione del comportamento predittivo del sistema. Se pari a un valore più alto di quello mai raggiunto durante la simulazione, simula una infinite activity, riproducendo esattamente il comportamento del sistema reale. Cap. 6 Modellazione dei workflow SABS 84

92 6.7 Raccolta dei dati dell impianto Calcolo delle matrici di incidenza per il sistema reale SABS. a f g j m h d e k l b i n c A H C D E J B F G I K Tabella 6.9: Matrice di Incidenza in avanti I+ (modello reale). a f g j m h d e k l b i n c A H C D E J B F G I K Tabella 6.10: Matrice di Incidenza indietro I (modello reale). Cap. 6 Modellazione dei workflow SABS 85

93 6.7 Raccolta dei dati dell impianto a f g j m h d e k l b i n c A H C D E J B F G I K Tabella 6.11: Matrice di Incidenza combinata I (modello reale). Calcolo dei tempi di lavoro dal sistema reale SABS. Tramite la query SQL seguente, opportunamente adattata nell ultima riga inserendo volta per volta l identificativo delle singole operazioni al posto delle X, così come contrassegnate nel database SABS reale, sono state estrapolata le medie, in secondi, per l esecuzione delle rispettive operazioni. SELECT AVG ( date_part( epoch ::text, t2.data_ultima_modifica - t1.data_ultima_modifica)) AS tempo_lavoro FROM ( SELECT richieste.req_id, richieste.req_ver, richieste.id_stato, richieste.data_ultima_modifica, richieste.id_operazione FROM storico.richieste) t1 JOIN ( SELECT richieste.req_id, richieste.req_ver, richieste.id_stato, richieste.data_ultima_modifica, richieste.id_operazione FROM storico.richieste) t2 ON t1.req_id = t2.req_id AND (t1.req_ver + 1) = t2.req_ver JOIN stati ON stati.id = t1.id_stato WHERE t1.id_operazione = XXX Transizione a = creazione (id 8). Per questa transizione di tipo iniziale la condizione Cap. 6 Modellazione dei workflow SABS 86

94 6.7 Raccolta dei dati dell impianto WHERE della query è stata adattata come segue per comprendere lo stato 1 (e non 0) dell automa: t1.id_operazione = 8 and t1.id_stato = 1 --creazione Risultato: Poiché vale la conversione secondi = giorni, tale valore approssimato a 0.82 sarà il tempo di lavoro della transizione. Transizione b = assegnazione (id 1). Risultato: Poiché vale la conversione secondi = giorni, tale valore approssimato a 1.57 sarà il tempo di lavoro della transizione. Transizione c = modifica (id 6). Risultato: Poiché vale la conversione secondi = giorni, tale valore approssimato a 0.39 sarà il tempo di lavoro della transizione. Transizione d = evasione (id 2). Risultato: Poiché vale la conversione secondi = giorni, tale valore approssimato a sarà il tempo di lavoro della transizione. Transizione e = sospensione (id 18). Risultato: Poiché vale la conversione secondi = giorni, tale valore approssimato a sarà il tempo di lavoro della transizione. Transizione f = chiusura (id 5). Risultato: Poiché vale la conversione secondi = giorni, tale valore approssimato a 0.01 sarà il tempo di lavoro della transizione. Transizione g = rimozione (id 7). Risultato: Poiché vale la conversione secondi = giorni, tale valore approssimato a sarà il tempo di lavoro della transizione. Transizione h = riassegnazione (id 13). Risultato: Poiché vale la conversione secondi = giorni, tale valore approssimato a 2.05 sarà il tempo di lavoro della transizione. Cap. 6 Modellazione dei workflow SABS 87

95 6.7 Raccolta dei dati dell impianto Transizione i = splitting (id 3). Risultato: Poiché vale la conversione secondi = giorni, tale valore approssimato a 4.31 sarà il tempo di lavoro della transizione. Transizione j = evasione con sottorichieste (id 15). Risultato: 0.44 Poiché vale la conversione 0.44 secondi = giorni, tale valore approssimato a 0 sarà il tempo di lavoro della transizione. Transizione k = riattivazione da sospesa (id 19). Non sono stati trovati elementi con questa operazione. Il valore 0 sarà il tempo di lavoro della transizione. Transizione l = riattivazione (id 16). Risultato: Poiché vale la conversione secondi = giorni, tale valore approssimato a 0.96 sarà il tempo di lavoro della transizione. Transizione m = rifiuto con sottorichieste (id 17). Non sono stati trovati elementi con questa operazione. Il valore 0 sarà il tempo di lavoro della transizione. Transizione n = notifica (id 4). Risultato: Poiché vale la conversione secondi = giorni, tale valore approssimato a sarà il tempo di lavoro della transizione. Calcolo del tasso di arrivo. Per calcolare il tasso di arrivo del sistema, ossia il numero di nuove richieste SABS nell unità di tempo, sono state svolte le seguenti considerazioni. Si è provveduto a trovare il valore del numero di richieste totali nuove (con stato pari a 0) totali. Si è poi calcolato il numero di giorni totali oggetto della valutazione e in questo modo si è potuto calcolare la media degli arrivi nell unità di tempo pari a un giorno. -- Trova il Numero di richieste totali arrivate nel sistema SELECT count(*) FROM storico.richieste WHERE richieste.id_stato = 0 Cap. 6 Modellazione dei workflow SABS 88

96 6.7 Raccolta dei dati dell impianto Risultato: Trova la data iniziale delle richieste presenti SELECT min(data_creazione) FROM storico.richieste WHERE richieste.id_stato = 0 Risultato: " " -- Trova la data finale delle richieste presenti SELECT max(data_creazione) FROM storico.richieste WHERE richieste.id_stato = 0 Risultato: " " A partire da e includendo lunedì 10 novembre 2003, fino a e includendo lunedì 29 agosto 2005, il sistema copre un periodo totale di 659 giorni (1 anno, 9 mesi e 20 giorni includendo la data finale). Pertanto, in media, si hanno: λ = N arrivi totali medi N unita di tempo totali = N richieste totali arrivate nel sistema N giorni totali = Calcolo del tasso di assegnazione. task g = 55 task g. Per calcolare il tasso di assegnazione del sistema, ossia il numero di task distribuiti nell unità di tempo, si è provveduto a trovare il valore totale del numero di task distribuiti agli utenti e lo si è diviso per il numero di giorni totali, calcolato nel paragrafo precedente. Cap. 6 Modellazione dei workflow SABS 89

97 6.7 Raccolta dei dati dell impianto -- Trova il Numero di task totali distribuiti agli utenti SELECT count(*) FROM storico.richieste WHERE richieste.id_stato!= 0 Risultato: Pertanto, in media, si hanno: λ = N task totali distribuiti agli utenti N giorni totali = task g = 209 task g. Cap. 6 Modellazione dei workflow SABS 90

98 Capitolo 7 WFsimulator: implementazione del modello di simulazione Il capitolo, dopo un esempio di Token-game sul workflow del SABS, descrive come si è proceduto alla costruzione di un software, chiamato WFsimulator e basato sul tool RePast, che permette la simulazione ad agenti asincroni di risorse che si interfacciano ad un sistema di workflow contenente il modello di rete del SABS ricavato nel capitolo Pseudo-simulazione tramite Token-Game e vettore di marcatura Il meccanismo denominato token game, in generale, permette all utente di interagire con appositi tool per abilitare le transizioni nelle reti di Petri e visualizzare il percorso dei token, tramite un animazione guidata a step. Il token game serve a comprendere il funzionamento della marcatura (marking) della rete: tale concetto sarà utilizzato nell implementazione pratica di un simulatore di workflow. Il vettore di marcatura rappresenta lo spazio degli stati del sistema. Lo spazio degli stati è descritto da un vettore del tipo: {D=0, I=0, K=0, A=1, F=0, H=0, C=0, J=0, B=0, G=0, E=0} dove gli elementi nel vettore indicano il posto della rete di Petri e il relativo numero di token, quando il sistema si trova in un particolare stato. Ad esempio, nella figura 7.1 l utente ha interagito fino ad arrivare alla marcatura Cap. 7 WFsimulator: implementazione del modello di simulazione 91

99 7.1 Pseudo-simulazione tramite Token-Game e vettore di marcatura {A=8, B=0, C=2, D=2, E=2, F=4, G=0, H=0, I=0, L=0, M=0, N=0, O=2, P=4, Q=4, R=2} Figura 7.1: Esempio di token game e token marking Cap. 7 WFsimulator: implementazione del modello di simulazione 92

100 7.2 Implementazione in Java di un simulatore di workflow reti di Petri ad agenti A B N L M P Q R C E D F G H O I ove le seguenti transizioni sono abilitate: a o s q m t u e b c f g d h r p i l n sì no sì no no sì sì no no sì sì sì sì no no no no no no 7.2 Implementazione in Java di un simulatore di workflow reti di Petri ad agenti cd: Package Overview: wfsimulator WorkflowDefinition WFsimulator # containerspace - workflow Workflow - workflow # container # container SystemAgent - systemagent MoverAgent Container Task UserAgent Created with Poseidon for UML Community Edition. Not for Commercial Use. Figura 7.2: UML Package diagram del progetto WFsimulator Obiettivi e peculiarità L obiettivo pratico del presente lavoro è costituito dall implementazione, in linguaggio Java, di un simulatore di workflow inter-organizzativi basato su agenti, che possa essere utilizzato per raccogliere i dati di carico e di smaltimento del lavoro. Tale simulatore utilizza la teoria delle reti di Petri (tramite gli elementi posti, transizioni e token e le relative interazioni) e le proprietà della simulazione basata sugli agenti, ricreando un ambiente di gestione di Cap. 7 WFsimulator: implementazione del modello di simulazione 93

101 7.2 Implementazione in Java di un simulatore di workflow reti di Petri ad agenti workflow sottoposto a un carico di lavoro e, attraverso la simulazione, producendo dei dati utili ai fini della relativa analisi. WFsimulator offre un ambiente di simulazione di workflow reali tramite cui analizzare il carico di lavoro e i risultati del processo in un periodo di tempo a scelta dell utente. In WFsimulator la simulazione delle risorse che interagiscono con il workflow è basata su agenti pensanti, in grado di interagire ed essere consapevoli dell ambiente che li circonda. WFsimulator permette di emulare i workflow di tipo Inter- Organizzativo, tramite la definizione dei ruoli e delle possibili operazioni effettuabili da ogni risorsa, associando alle operazioni i tempi medi di svolgimento raccolti durante l analisi dei sistemi reali Parametri di sistema Per verificare la validità dei risultati prodotti dal simulatore è stato utilizzato il Case Type relativo al modello SABS. Nel capitolo 6 sono stati identificati i parametri dell impianto specifico SABS da simulare, in termini di parametri di input, i cui valori saranno inseriti come dati di input del simulatore, e parametri di output, i cui valori saranno raccolti durante la simulazione. Per quanto riguarda i parametri di input, dal modello SABS reale sono stati estrapolati i dati reali da inserire nel simulatore (paragrafo 6.7) Librerie API utilizzate L implementazione del simulatore è costituita da un package Java chiamato WFsimulator che utilizza le librerie API del tool di simulazione ad agenti RePast (pag. 47) e del workflow engine Bossa 1. Il workflow engine offre delle classi che forniscono una struttura di base di workflow al WFsimulator. Il simulatore ne estende le funzionalità, ad esempio trasformandone l idea di risorsa da oggetto statico a classe di agenti di varia tipologia, consapevoli dell ambiente che li circonda e in grado di conservare la memoria delle proprie attività e fornire interattivamente risposte aggiornate al sistema. La simulazione ad agenti è implementata attraverso le classi di RePast. Le librerie 1 Cap. 7 WFsimulator: implementazione del modello di simulazione 94

102 7.2 Implementazione in Java di un simulatore di workflow reti di Petri ad agenti WFsimulator -containerwidth: int = 600 -containerheight: int = 600 -containerdisplaysurface: DisplaySurface -numusers: int -numstep: int -stampadettaglioazioniwf: boolean -grafico_medie_todotasks: OpenSequenceGraph -grafico_medie_closecases: OpenSequenceGraph -grafico_medie_executedtasks: OpenSequenceGraph -grafico_medie_refusedtasks: OpenSequenceGraph -grafico_individuale_todotasks: OpenSequenceGraph -grafico_individuale_closecases: OpenSequenceGraph -grafico_individuale_executedtasks: OpenSequenceGraph -grafico_individuale_refusedtasks: OpenSequenceGraph -grafico_totale_todotasks: OpenSequenceGraph -grafico_totale_closecases: OpenSequenceGraph -grafico_totale_executedtasks: OpenSequenceGraph -grafico_totale_refusedtasks: OpenSequenceGraph -recorder: DataRecorder -numtaskassegnatitot: int = 0 -numcasichiusitot: int = 0 -numtaskeseguititot: int = 0 -numcasirifiutatiobertot: int = 0 +WFsimulator() +getinitparam(): String[] +begin(): void #buildgraphs(): void +setup(): void #step(): void +atend(): void +getname(): String +getuserscount(): int +setuserscount(numusers:int): void +setgraphproperties(graph:opensequencegraph): void +getstampadettaglioazioniwf(): boolean +setstampadettaglioazioniwf(val:boolean): void +getticksimulazione(): int +setticksimulazione(val:int): void +getmaxtasks(): int +setmaxtasks(val:int): void +gettasksassegnatipertick(): int +settasksassegnatipertick(val:int): void +gettasksarrivatipertick(): int +settasksarrivatipertick(val:int): void +getnumtaskassegnatitotali(): int +setnumtaskassegnatitotali(): void +getnumcasichiusitotali(): int +setnumcasichiusitotali(): void +getnumtaskeseguititotali(): int +setnumtaskeseguititotali(): void +getnumtaskrifiutatioberatototali(): int +setnumtaskrifiutatioberatototali(): void +getcasetype(): String +gettotaltime(): double +main(args:string[]): void containerspace AsynchAgent CustomProbeable SimpleModel container SystemAgent #tasksassegnatipertick: int #tasksarrivatipertick: int #containerspace: WFsimulator +SystemAgent(containerSpace:WFsimulator, container:container, x:double, y:double) +SystemAgent(containerSpace:WFsimulator, container:container) +distributetasks(): void +gettasksassegnatipertick(): int +settasksassegnatipertick(val:int): void +gettasksarrivatipertick(): int +settasksarrivatipertick(val:int): void +getcasetype(): String systemagent container UserAgent -maxtasks: int -userpicture: Image -baseidnumber: int -tasklist: ArrayList = new ArrayList() -id: int -servicetime: long -num_casi_chiusi: int = 0 -num_task_eseguiti: int = 0 -num_casi_rifiutati_oberato: int = 0 -modello: SimModel -colorindex: int = 0 -colors: Color = new +UserAgent(x:double, y:double, model:simmodel, id:int, username:string) +UserAgent(model:SimModel, id:int, username:string) +gettasklist(): ArrayList +draw(g:simgraphics): void +addtask(task:task): boolean +performtask(tasktoperform:task): void -getnextcolor(): Color +resetindices(): void -loaduserpicture(): void +getprobedproperties(): String[] +getid(): int +setid(id:int): void +setmodello(model:simmodel): void +getservicetime(wi:workitem): long +getcasetype(): String +getnumtaskassegnati(): int +getnumcasichiusi(): int +setnumcasichiusi(): void +getnumtaskeseguiti(): int +setnumtaskeseguiti(): void +getnumtaskrifiutatioberato(): int +setnumtaskrifiutatioberato(): void +getmaxtasks(): int +setmaxtasks(val:int): void useragent Container -tasksassegnatipertick: int = 10 -tasksarrivatipertick: int = 2 -ticksimulazione: int = 30 -maxtasks: int = 5 -users: ArrayList = new ArrayList() -systemagent: SystemAgent -useragent: UserAgent -width: int -height: int -username: String +Container() +Container(width:int, height:int) +fireallusers(): int +hireuseragents(numusers:int, model:simmodel, workflow:workflow): void +hireuseragent(useragent:useragent): void +hiresystemagent(containerspace:wfsimulator): void +getheight(): int +setheight(height:int): void +getwidth(): int +setwidth(width:int): void +getusers(): ArrayList +getsystemagent(): SystemAgent +getticksimulazione(): int +setticksimulazione(val:int): void +gettasksassegnatipertick(): int +settasksassegnatipertick(val:int): void +gettasksarrivatipertick(): int +settasksarrivatipertick(val:int): void +getmaxtasks(): int +setmaxtasks(val:int): void MoverAgent DefaultDrawableNode +MoverAgent(containerSpace:WFsimulator, container:container) +gradeusers(): void +screencoordstonormalizedcartesiancoords(x:double, y:double): double[] +normalizedcartesiancoordstoscreencoords(x:double, y:double): double[] -gettheta(useragent:useragent): double -getangle(inleftquads:boolean, angle:double): double -getlongesttasklistlength(): int WFsimulator -containerwidth: int = 600 -containerheight: int = 600 -containerdisplaysurface: DisplaySurface -numusers: int -numstep: int -stampadettaglioazioniwf: boolean -grafico_medie_todotasks: OpenSequenceGraph -grafico_medie_closecases: OpenSequenceGraph -grafico_medie_executedtasks: OpenSequenceGraph -grafico_medie_refusedtasks: OpenSequenceGraph -grafico_individuale_todotasks: OpenSequenceGraph -grafico_individuale_closecases: OpenSequenceGraph -grafico_individuale_executedtasks: OpenSequenceGraph -grafico_individuale_refusedtasks: OpenSequenceGraph -grafico_totale_todotasks: OpenSequenceGraph -grafico_totale_closecases: OpenSequenceGraph -grafico_totale_executedtasks: OpenSequenceGraph -grafico_totale_refusedtasks: OpenSequenceGraph Workflow -bossa: Bossa -casetypemanager: CaseTypeManager -resourcemanager: ResourceManager -workmanager: WorkManager -historian: Historian -cases: HashMap -lastcaselist: List -lastworkitemlist: List -lastactivitieslist: List -lastresourcelist: List -lastcasetyperesourcelist: List +Workflow() +refresh(id:string): void +getstatedir(): String +getcasetypemanager(): CaseTypeManager +getresourcemanager(): ResourceManager -retrieveresource(listid:int): Resource Figura 7.3: UML Class diagram del progetto WFsimulator (1). Cap. 7 WFsimulator: implementazione del modello di simulazione 95

103 #tasksassegnatipertick: int #tasksarrivatipertick: int #containerspace: WFsimulator containerspace SystemAgent +SystemAgent(containerSpace:WFsimulator, container:container, x:double, y:double) +SystemAgent(containerSpace:WFsimulator, container:container) +distributetasks(): void +gettasksassegnatipertick(): int +settasksassegnatipertick(val:int): void +gettasksarrivatipertick(): int +settasksarrivatipertick(val:int): void +getcasetype(): String systemagent container +hiresystemagent(containerspace:wfsimulator): void +getheight(): int +setheight(height:int): void +getwidth(): int +setwidth(width:int): void +getusers(): ArrayList +getsystemagent(): SystemAgent +getticksimulazione(): int +setticksimulazione(val:int): void +gettasksassegnatipertick(): int +settasksassegnatipertick(val:int): void 7.2 Implementazione in Java di un simulatore di workflow reti di Petri ad agenti +gettasksarrivatipertick(): int +settasksarrivatipertick(val:int): void +getmaxtasks(): int +setmaxtasks(val:int): void MoverAgent DefaultDrawableNode +MoverAgent(containerSpace:WFsimulator, container:container) +gradeusers(): void +screencoordstonormalizedcartesiancoords(x:double, y:double): double[] +normalizedcartesiancoordstoscreencoords(x:double, y:double): double[] -gettheta(useragent:useragent): double -getangle(inleftquads:boolean, angle:double): double -getlongesttasklistlength(): int WFsimulator -containerwidth: int = 600 -containerheight: int = 600 -containerdisplaysurface: DisplaySurface -numusers: int -numstep: int -stampadettaglioazioniwf: boolean -grafico_medie_todotasks: OpenSequenceGraph -grafico_medie_closecases: OpenSequenceGraph -grafico_medie_executedtasks: OpenSequenceGraph -grafico_medie_refusedtasks: OpenSequenceGraph -grafico_individuale_todotasks: OpenSequenceGraph -grafico_individuale_closecases: OpenSequenceGraph -grafico_individuale_executedtasks: OpenSequenceGraph -grafico_individuale_refusedtasks: OpenSequenceGraph -grafico_totale_todotasks: OpenSequenceGraph -grafico_totale_closecases: OpenSequenceGraph -grafico_totale_executedtasks: OpenSequenceGraph -grafico_totale_refusedtasks: OpenSequenceGraph -recorder: DataRecorder -numtaskassegnatitot: int = 0 -numcasichiusitot: int = 0 -numtaskeseguititot: int = 0 -numcasirifiutatiobertot: int = 0 +WFsimulator() +getinitparam(): String[] +begin(): void #buildgraphs(): void +setup(): void #step(): void +atend(): void +getname(): String +getuserscount(): int +setuserscount(numusers:int): void +setgraphproperties(graph:opensequencegraph): void +getstampadettaglioazioniwf(): boolean +setstampadettaglioazioniwf(val:boolean): void +getticksimulazione(): int +setticksimulazione(val:int): void +getmaxtasks(): int +setmaxtasks(val:int): void +gettasksassegnatipertick(): int +settasksassegnatipertick(val:int): void +gettasksarrivatipertick(): int +settasksarrivatipertick(val:int): void +getnumtaskassegnatitotali(): int +setnumtaskassegnatitotali(): void +getnumcasichiusitotali(): int +setnumcasichiusitotali(): void +getnumtaskeseguititotali(): int +setnumtaskeseguititotali(): void +getnumtaskrifiutatioberatototali(): int +setnumtaskrifiutatioberatototali(): void +getcasetype(): String +gettotaltime(): double +main(args:string[]): void Task -wi: WorkItem +Task(wi:WorkItem) +getwi(): WorkItem +setwi(wi:workitem): void workflow workflow WorkflowDefinition -workflow: Workflow -STATEDIR: String = "outputs/state" +CASETYPE: String = "SabsCaseType" +WorkflowDefinition() +getstatedir(): String +getcasetype(): String Workflow -bossa: Bossa -casetypemanager: CaseTypeManager -resourcemanager: ResourceManager -workmanager: WorkManager -historian: Historian -cases: HashMap -lastcaselist: List -lastworkitemlist: List -lastactivitieslist: List -lastresourcelist: List -lastcasetyperesourcelist: List +Workflow() +refresh(id:string): void +getstatedir(): String +getcasetypemanager(): CaseTypeManager +getresourcemanager(): ResourceManager -retrieveresource(listid:int): Resource -printhistory(l:list): void -printhistorylastcmd(l:list): String +s_takesnapshot(): void +l_listcasetypes(): void +g_registercasetype(file:string): void +r_removecasetype(id:string): void +c_listcasesofcasetype(id:string): void +w_listworkitemsofcasetype(id:string): void +w_listworkitemsnoinitialofcasetype(id:string): void +a_listactivitiesofcasetype(id:string): void +t_listresourcesofcasetype(id:string): void +y_listresourcesofcase(listid:int): void +m_changestateofcase(listid:int, placeid:string, value:int): void +lr_listallresources(): void +gr_registeraresource(id:string): void +rr_removearesource(listid:int): void +dr_detailaresource(listid:int): void +ir_includearesource(hostid:int, resid:int): void +er_excludearesource(hostid:int, resid:int): void +cr_cancelincludeorexclude(hostid:int, resid:int): void +ct_containsresourcequestion(hostid:int, resid:int): void +wr_listworkitemsofaresource(resid:int): void +ar_listactivitiesofaresource(resid:int): void +o_openaworkitem(listid:int, resid:int): void +cl_closeanactivity(listid:int): void +ca_cancelanactivity(listid:int): void +f_fireaworkitem(listid:int, resid:int): void +vs_declareacaseattribute(casetypeid:string, caseid:string, id:string, valuestr:string): void +vl_listcaseattributes(casetypeid:string, caseid:string): void +h_displayallhistory(): void +ht_displayacasetypehistory(id:string): void +htq_displaycasetypehistoryquartultima(id:string): String +htl_displaycasetypehistorylast(id:string): String +hc_displayacasehistory(listid:int): void +hr_displayaresourcehistory(listid:int): void +hx_exportandpurgeallhistory(): void +l_listcasetypes_quiet(): void +c_listcasesofcasetype_quiet(id:string): void +w_listworkitemsofcasetype_quiet(id:string): void +w_listworkitemsnoinitialofcasetype_quiet(id:string): void +a_listactivitiesofcasetype_quiet(id:string): void +t_listresourcesofcasetype_quiet(id:string): void +y_listresourcesofcase_quiet(listid:int): void +lr_listallresources_quiet(): void +wr_listworkitemsofaresource_quiet(resid:int): void +ar_listactivitiesofaresource_quiet(resid:int): void +vl_listcaseattributes_quiet(casetypeid:string, caseid:string): void f ( ) f Figura 7.4: UML Class diagram del progetto WFsimulator (2). Cap. 7 WFsimulator: implementazione del modello di simulazione 96

104 7.2 Implementazione in Java di un simulatore di workflow reti di Petri ad agenti di simulazione di RePast sono estese per richiamare le librerie del workflow engine che memorizza i dati su filesystem tramite un meccanismo di persistenza delle transazioni. I controlli interattivi forniti da RePast includono Initialize, Step, Run, e Pause per controllare l avanzare della simulazione. Le librerie del workflow sono quindi rese disponibili a RePast, includendo le capacità di memorizzazione e esportazione dei risultati delle simulazioni, oltre che di creazione di grafici statistici. L ambiente di simulazione ad agenti, unito al sistema di workflow, può così ricevere gli aggiornamenti alle sue funzionalità che sono eseguiti ad ogni tick (periodo di simulazione). La comunicazione tra il sistema di workflow e il simulatore RePast permette inoltre l aggiornamento dello stato dei singoli agenti, basandosi sulle interazioni fra agenti e sugli eventi esterni che influenzano gli agenti e il sistema. L implementazione tramite le API di RePast e del sistema di workflow è un programma interpretato, che non richiede compilazione o collegamenti che sono richiesti dai linguaggi di programmazione o dagli strumenti di modellazione ad agenti presi singolarmente. I due sistemi così collegati, inoltre, permettono l accesso a tutte le classi Java fornite da RePast e a quelle fornite dal workflow engine. Una delle caratteristiche del collegamento dei due sistemi è che fornisce naturalmente un sistema real-time, animato interattivamente per simulazioni basate su agenti, in modo che ogni estensione futura sia facilmente realizzabile Diagrammi UML del Package e delle Classi Nel diagramma di figura 7.2 a pagina 93 è riportata la struttura del package WFsimulator implementato in linguaggio Java. I package importati, oltre a quelli generici, comprendono uchicago.src.sim* per RePast toolkit simulator e com.bigbross.bossa* per il workflow engine. Nelle figure 7.3 e 7.4 sono riportate le classi del progetto. Nella sezione seguente è descritta la struttura di massima del programma, accompagnata graficamente dagli UML Activity e Sequence diagram più significativi Struttura del programma Il metodo di inizio main() del programma è presente alla fine della classe chiamata WFsimulator. Dai diagrammi UML activity diagram e sequence diagram, riportati rispettivamente in figura 7.5 e 7.6, si nota che come prima cosa viene richiamato il costruttore SimInit del Cap. 7 WFsimulator: implementazione del modello di simulazione 97

105 7.2 Implementazione in Java di un simulatore di workflow reti di Petri ad agenti WFsimulator::main (args: String[]): Void { } uchicago.src.sim.engine.siminit init = new uchicago.src.sim.engine.siminit(); WFsimulator model = new WFsimulator(); if (args.length > 0) init.loadmodel(model, args[0], false); else init.loadmodel(model, null, false); Figura 7.5: UML Activity diagram del metodo main() motore di simulazione RePast: l interfaccia grafica di RePast viene rappresentata a video all utente, comprendendo, fra l altro, i pulsanti di Run, Step, Pause, Stop, Initialize, Setup. La funzione di Setup (fig. 7.7, 7.8 e 7.9) viene richiamata automaticamente, secondo standard RePast, all inizio della simulazione. Tale metodo, oltre a reimpostare il modello per l esecuzione seguente, inizializza lo scheduler del simulatore. Il particolare tipo di scheduler utilizzato per gli agenti del mondo è uno Scheduler Asincrono, che permette lo scheduling automatico e personale degli agenti, inizializzato tramite il costruttore new AsynchSchedule(). In seguito, il WFsimulator viene inizializzato attraverso la chiamata al suo costruttore (fig. 7.10) e il modello viene caricato. All interno del costruttore sono svolte una serie di inizializzazioni per la preparazione dell ambiente ad agenti e per il caricamento dello specifico Case Type da utilizzare nel motore di workflow, in particolare quest ultima funzione viene svolta richiamando il costruttore new WorkflowDefinition() e lanciando (in modalità silenziosa) alcuni metodi di inizializzazione del workflow tramite cui vengono impostati il nome del CaseType e l elenco dei Case, delle risorse, dei Work Item e delle Activity presenti nel sistema. L utente può scegliere interattivamente il pulsante da premere e il programma reagirà lanciando le opportune funzioni per l esecuzione sequenziale oppure per step, la pausa e il termine della simulazione. È possibile reinizializzare il simulatore oppure lanciare manualmente la funzione di setup sopra descritta. Scegliendo uno dei pulsanti che lanciano la simulazione, il metodo begin() si occupa pri- Cap. 7 WFsimulator: implementazione del modello di simulazione 98

106 7.2 Implementazione in Java di un simulatore di workflow reti di Petri ad agenti object this : WFsimulator 1: main(args=) 2: init = new uchicago.src.sim.engine.siminit() 3: model = new WFsimulator() model : WFsimulator 4: [args.length>0] <<if>> 5: init.loadmodel(model,args[0],false) 6: [NOT(args.length>0)] <<else>> 7: init.loadmodel(model,null,false) Figura 7.6: UML Sequence diagram del metodo main() Cap. 7 WFsimulator: implementazione del modello di simulazione 99

107 7.2 Implementazione in Java di un simulatore di workflow reti di Petri ad agenti object this : WFsimulator 1: setup() 2: schedule = new AsynchSchedule() 3: container = new Container(containerWidth,containerHeight) container : Container 4: containerdisplaysurface = null 5: [grafico_medie_todotasks!=null] <<if>> 6: grafico_medie_todotasks.dispose() 7: grafico_medie_todotasks = null 8: [grafico_medie_closecases!=null] <<if>> 9: grafico_medie_closecases.dispose() 10: grafico_medie_closecases = null 11: [grafico_medie_executedtasks!=null] <<if>> 12: grafico_medie_executedtasks.dispose() 13: grafico_medie_executedtasks = null 14: [grafico_medie_refusedtasks!=null] <<if>> 15: grafico_medie_refusedtasks.dispose() 16: grafico_medie_refusedtasks = null Figura 7.7: UML Sequence diagram del metodo setup() (1) 17: [grafico_individuale_todotasks!=null] <<if>> 18: grafico_individuale_todotasks.dispose() Cap. 7 WFsimulator: implementazione del modello di simulazione : grafico_individuale_todotasks = null

108 13: grafico_medie_executedtasks = null 7.2 Implementazione in Java di un simulatore di workflow reti di Petri ad agenti 14: [grafico_medie_refusedtasks!=null] <<if>> 15: grafico_medie_refusedtasks.dispose() 16: grafico_medie_refusedtasks = null 17: [grafico_individuale_todotasks!=null] <<if>> 18: grafico_individuale_todotasks.dispose() 19: grafico_individuale_todotasks = null 20: [grafico_individuale_closecases!=null] <<if>> 21: grafico_individuale_closecases.dispose() 22: grafico_individuale_closecases = null 23: [grafico_individuale_executedtasks!=null] <<if>> 24: grafico_individuale_executedtasks.dispose() 25: grafico_individuale_executedtasks = null 26: [grafico_individuale_refusedtasks!=null] <<if>> 27: grafico_individuale_refusedtasks.dispose() 28: grafico_individuale_refusedtasks = null 29: [grafico_totale_todotasks!=null] <<if>> 30: grafico_totale_todotasks.dispose() Figura 7.8: UML Sequence diagram del metodo setup() (2) 31: grafico_totale_todotasks = null 32: [grafico_totale_closecases!=null] Cap. 7 WFsimulator: implementazione del modello di simulazione 101 <<if>> 33: grafico_totale_closecases.dispose()

109 26: [grafico_individuale_refusedtasks!=null] <<if>> 27: grafico_individuale_refusedtasks.dispose() 7.2 Implementazione in Java di un simulatore di workflow reti di Petri ad agenti 28: grafico_individuale_refusedtasks = null 29: [grafico_totale_todotasks!=null] <<if>> 30: grafico_totale_todotasks.dispose() 31: grafico_totale_todotasks = null 32: [grafico_totale_closecases!=null] <<if>> 33: grafico_totale_closecases.dispose() 34: grafico_totale_closecases = null 35: [grafico_totale_executedtasks!=null] <<if>> 36: grafico_totale_executedtasks.dispose() 37: grafico_totale_executedtasks = null 38: [grafico_totale_refusedtasks!=null] <<if>> 39: grafico_totale_refusedtasks.dispose() 40: grafico_totale_refusedtasks = null Figura 7.9: UML Sequence diagram del metodo setup() (3) Cap. 7 WFsimulator: implementazione del modello di simulazione 102

110 7.2 Implementazione in Java di un simulatore di workflow reti di Petri ad agenti object this : WFsimulator 1: WFsimulator() 2: Random.createUniform() 3: [super.agentlist==null] <<if>> 4: super.agentlist = new ArrayList() tmparraylist : ArrayList 5: <<try>> 6: new WorkflowDefinition() tmpworkflowdefinition : WorkflowDefinition 7: workflow = new Workflow () workflow : Workflow 8: tmpstring = getcasetype() 9: w orkflow.refresh(id=tmpstring) 10: 11: lastresourcelist = w orkflow.resourcemanager.getresources() 12: lastresourcelistsize = 0 13: tmpint = lastresourcelist.size() 14: *[i<tmpint]i = 0 <<for>> 15: tmpe = lastresourcelist.get(i=i) 16: r = (Resource)tmpE 17: [r.isgroup()==false] <<if>> 18: lastresourcelistsize++ 19: i++ 20: this.setuserscount(numusers=lastresourcelistsize) 21: [Exception ex] <<catch>> 22: SimUtilities.show Error("Error integrating the w orkflow ",ex) 23: super.stop() Figura 7.10: UML Sequence diagram del costruttore wfsimulator() Cap. 7 WFsimulator: implementazione del modello di simulazione 103

111 7.2 Implementazione in Java di un simulatore di workflow reti di Petri ad agenti object this : WFsimulator container : Container tmpsystemagent : SystemAgent 1: step() 2: tmpsystemagent = container.getsystemagent() 3: 4: tmpsystemagent.distributetasks() 5: 6: <<try>> 8: tmpstring = getcasetype() 7: workflow = new Workflow() workflow : Workflow 9: w orkflow.refresh(id=tmpstring) 10: 11: [Exception ex] <<catch>> 12: SimUtilities.show Error("Error integrating the w orkflow in step()",ex) 13: numstep++ 14: grafico_medie_todotasks.step() 15: grafico_medie_closecases.step() 16: grafico_medie_executedtasks.step() 17: grafico_medie_refusedtasks.step() 18: grafico_individuale_todotasks.step() 19: grafico_individuale_closecases.step() 20: grafico_individuale_executedtasks.step() 21: grafico_individuale_refusedtasks.step() 22: grafico_totale_todotasks.step() 23: grafico_totale_closecases.step() 24: grafico_totale_executedtasks.step() 25: grafico_totale_refusedtasks.step() Figura 7.11: UML Sequence diagram del metodo step() Cap. 7 WFsimulator: implementazione del modello di simulazione 104

112 7.2 Implementazione in Java di un simulatore di workflow reti di Petri ad agenti object this : UserAgent tasklist : ArrayList staticwfsimulator : WFsimulator task : Task 1: addtask(task=) 2: tmpint = tasklist.size() 3: 4: [tmpint>maxtasks] <<if>> 5: this.setnumtaskrifiutatioberato() 6: WFsimulator.setNumTaskRifiutatiOberatoTotali() 7: 8: false 9: <<try>> 11: tmpstring = getcasetype() 10: w orkflow = new Workflow () workflow : Workflow 12: w orkflow.refresh(id=tmpstring) 13: 14: w i_ok = 0 15: wi_id = 0 16: wi = task.getwi() 17: 18: tmpint1 = getid() 19: resource = (Resource)workflow.resourceManager.getResources().get(tmpint1) 20: lastworkitemlistres = workflow.workmanager.getworkitems(resource,true) 21: tmpint2 = lastworkitemlistres.size() 22: *[i<tmpint2]i = 0 <<for>> Figura 7.12: UML Sequence diagram del metodo UserAgent.addTask() (1) 23: tmpe = lastworkitemlistres.get(i=i) 24: wi2 = (WorkItem)tmpE Cap. 7 WFsimulator: implementazione del modello di simulazione : [(w i.getcase().getid()==w i2.getcase().getid())&&(w i.getid().equals(w i2.getid()))] <<if>> 26: wi_ok = 1

113 19: resource = (Resource)workflow.resourceManager.getResources().get(tmpint1) 20: lastworkitemlistres = workflow.workmanager.getworkitems(resource,true) 21: tmpint2 = lastworkitemlistres.size() 7.2 Implementazione in Java di un simulatore di workflow reti di Petri ad agenti 22: *[i<tmpint2]i = 0 <<for>> 23: tmpe = lastworkitemlistres.get(i=i) 24: wi2 = (WorkItem)tmpE 25: [(w i.getcase().getid()==w i2.getcase().getid())&&(w i.getid().equals(w i2.getid()))] <<if>> 26: wi_ok = 1 27: i++ 28: [w i_ok==0] 29: false <<if>> 30: tmpstring1 = getcasetype() 31: lastworkitemlist = workflow.casetypemanager.getcasetype(tmpstring1).getworkitems(true) 32: tmpint2 = lastworkitemlist.size() 33: *[i<tmpint2]i = 0 <<for>> 34: tmpe = lastworkitemlist.get(i=i) 35: wi_g = (WorkItem)tmpE 36: [(w i.getcase().getid()==w i_g.getcase().getid())&&(w i.getid().equals(w i_g.getid()))] <<if>> 37: wi_id = i 38: i++ 39: setdelayminimum(0.2) 40: tmplong = getservicetime(wi=wi) 41: setdelaymaximum(tmplong) Figura 7.13: UML Sequence diagram del metodo UserAgent.addTask() (2) 42: tmpint2 = getid() Cap. 7 WFsimulator: implementazione del modello di simulazione : w orkflow.o_openaworkitem(listid=w i_id, resid=tmpint2) 44:

114 <<if>> 37: wi_id = i 38: i Implementazione in Java di un simulatore di workflow reti di Petri ad agenti 39: setdelayminimum(0.2) 40: tmplong = getservicetime(wi=wi) 41: setdelaymaximum(tmplong) 42: tmpint2 = getid() 43: w orkflow.o_openaworkitem(listid=w i_id, resid=tmpint2) 44: 45: tmpstring2 = getcasetype() 46: command = workflow.htq_displaycasetypehistoryquartultima(id=tmpstring2) 47: 48: [command=="open_case"] <<if>> 49: w i.getcase().settickapertura(this.modello.gettickcount()) 50: [Exception ex] <<catch>> 51: SimUtilities.showError("Error integrating the workflow in addtask()",ex) 52: tasklist.add(e=task) 53: 54: WFsimulator.setNumTaskAssegnatiTotali() 55: 56: super.schedulewhenavailable("performtask",task) 57: true Figura 7.14: UML Sequence diagram del metodo UserAgent.addTask() (3) Cap. 7 WFsimulator: implementazione del modello di simulazione 107

115 7.2 Implementazione in Java di un simulatore di workflow reti di Petri ad agenti object this : UserAgent tasktoperform : Task System_out : PrintStream staticwfsimulator : WFsimulator tasklist : ArrayList 1: performtask(tasktoperform=) 2: <<try>> 4: tmpstring = getcasetype() 3: workflow = new Workflow () workflow : Workflow 5: w orkflow.refresh(id=tmpstring) 6: 7: w i_ok = 0 8: w i_id = 0 9: w i = tasktoperform.getw i() 10: 11: tmpstring1 = getcasetype() 12: w orkflow.lastworkitemlist = w orkflow.casetypemanager.getcasetype(tmpstring1).getworkitems(true) 13: tmpint = w orkflow.lastworkitemlist.size() 14: *[i<tmpint]i = 0 <<for>> 15: tmpe = w orkflow.lastworkitemlist.get(i=i) 16: w i2 = (WorkItem)tmpE 17: [(w i.getcase().getid()==w i2.getcase().getid())&&(w i.getid()==w i2.getid())] <<if>> 18: w i_ok = 1 19: w i_id = i 20: i++ 21: w orkflow.cl_closeanactivity(listid=w i_id) 22: 23: tmpstring2 = getcasetype() 24: command = w orkflow.htl_displaycasetypehistorylast(id=tmpstring2) Figura 7.15: UML Sequence diagram del metodo UserAgent.performTask() (1) 25: 26: [command=="close_case"] <<if>> 27: w i.getcase().settickchiusura(this.modello.gettickcount()) Cap. 7 WFsimulator: implementazione del modello di simulazione : [command=="close_case"] <<if>> 29: w i.getcase().settempototalecase() 30: System.out.println(string="Tempo totale Case "+w i.getcase().getid()+": "+w i.getcase().gettempototalecase())

116 17: [(w i.getcase().getid()==w i2.getcase().getid())&&(w i.getid()==w i2.getid())] <<if>> 18: w i_ok = 1 19: w i_id = i 20: i Implementazione in Java di un simulatore di workflow reti di Petri ad agenti 21: w orkflow.cl_closeanactivity(listid=w i_id) 22: 23: tmpstring2 = getcasetype() 24: command = w orkflow.htl_displaycasetypehistorylast(id=tmpstring2) 25: 26: [command=="close_case"] <<if>> 27: w i.getcase().settickchiusura(this.modello.gettickcount()) 28: [command=="close_case"] <<if>> 29: w i.getcase().settempototalecase() 30: System.out.println(string="Tempo totale Case "+w i.getcase().getid()+": "+w i.getcase().gettempototalecase()) 31: 32: [command=="close_case"] <<if>> 33: this.setnumcasichiusi() 34: WFsimulator.setNumCasiChiusiTotali() 35: 36: [command=="close_activity"] <<if>> 37: this.setnumtaskeseguiti() 38: WFsimulator.setNumTaskEseguitiTotali() 39: 40: [Exception ex] <<catch>> 41: SimUtilities.show Error("Error integrating the w orkflow in performtask()",ex) 42: tasklist.remove(object=tasktoperform) 43: Figura 7.16: UML Sequence diagram del metodo UserAgent.performTask() (2) Cap. 7 WFsimulator: implementazione del modello di simulazione 109

117 7.2 Implementazione in Java di un simulatore di workflow reti di Petri ad agenti object this : Workflow lastworkitemlist : List lastresourcelist : List 1: o_openaworkitem(listid=, resid=) 2: tmpe = lastworkitemlist.get(i=listid) 3: 4: w i = (WorkItem)tmpE 5: tmpe1 = lastresourcelist.get(i=resid) 6: 7: res = (Resource)tmpE1 8: a = w i.open(res) Figura 7.17: UML Sequence diagram del metodo Workflow.o OpenAWorkItem() Cap. 7 WFsimulator: implementazione del modello di simulazione 110

118 7.2 Implementazione in Java di un simulatore di workflow reti di Petri ad agenti object this : Workflow lastactivitieslist : List 1: cl_closeanactivity(listid=) 2: tmpe = lastactivitieslist.get(i=listid) 3: 4: a = (Activity)tmpE 5: attributes = (HashMap)cases.get(a.getCaseType().getId()+a.getCase().getId()) 6: result = a.close(attributes) 7: [result==true] <<if>> 8: resulttext = "successo." 9: [NOT(result==true)] <<else>> 10: resulttext = "errore." Figura 7.18: UML Sequence diagram del metodo Workflow.cl CloseAnActivity() Cap. 7 WFsimulator: implementazione del modello di simulazione 111

119 7.2 Implementazione in Java di un simulatore di workflow reti di Petri ad agenti ma di tutto di distribuire gli agenti nel mondo e poi attribuire agli agenti di tipo utente (UserAgent) alcuni task iniziali da svolgere, prelevati da quelli che vengono resi disponibili dal sistema di workflow; tale assegnazione avviene secondo alcune specifiche regole di assegnazione. Agli agenti viene attribuito un tempo di servizio relativo alla operazione da svolgere, prelevato dalla definizione di workflow. Il simulatore attenderà questo tempo, simulandolo, per completare il task durante l esecuzione. La funzione begin(), infine, predispone i grafici e il salvataggio dei dati su file, per questi ultimi ne imposta lo scheduling in modo da salvare i dati su file ad intervalli predefiniti (per esempio, ad ogni tick di simulazione, ogni 5 tick, etc.) e alla fine della simulazione. I grafici vengono aggiornati automaticamente a run-time tramite le funzionalità di RePast e offrono una visuale dell andamento rispetto al tempo dei vari parametri scelti. Nel codice sorgente è potenzialmente possibile inserire numerosi grafici: quelli che l utente sceglie di rendere non visibili durante la simulazione, non interferiranno con le prestazioni del simulatore, perché non saranno aggiornati dal sistema fino al momento in cui l utente sceglierà di renderli di nuovo visibili. Dopo le inizializzazioni, il simulatore entra nel ciclo di esecuzione simulativa vera e propria, lanciando il metodo step() (fig. 7.11) ad ogni passo della simulazione. Tale funzione può essere richiamata singolarmente scegliendo l apposita funzione di Step. Lo scopo principale del metodo è di distribuire i task, in attesa di essere eseguiti, agli utenti del workflow che sono in grado di svolgerli, richiamando l importante funzione container.getsystemagent().distributetasks(). È importante notare che durante un passo di simulazione il modello non controlla direttamente gli agenti/utenti. Essi svolgono i task solo quando ne hanno bisogno. In questo modo, il modello non necessita di preoccuparsi di loro: essi si auto-scheduleranno per svolgere i task che sono stati loro precedentemente assegnati. La regola di assegnazione di un task ad un agente prevede la coesistenza di queste due condizioni: (i) L agente non deve essere oberato di lavoro, ossia non deve aver raggiunto il numero massimo di task assegnabili. Tale numero massimo è predefinito (maxtasks) e può essere modificato. Cap. 7 WFsimulator: implementazione del modello di simulazione 112

120 7.2 Implementazione in Java di un simulatore di workflow reti di Petri ad agenti Workflow::o_OpenAWorkItem (listid: Integer, resid: Integer): Void { //System.out.println("##### start o_openaworkitem"); WorkItem wi = (WorkItem) lastworkitemlist.get(listid); Resource res = (Resource) lastresourcelist.get(resid); Activity a = wi.open(res); //System.out.println("Work Item aperto come activity n. " + a.getid() + "."); //System.out.println("----- end o_openaworkitem"); } Figura 7.19: UML Activity diagram del metodo Workflow.o OpenAWorkItem() (ii) L agente deve possedere l autorizzazione necessaria a svolgere il task. Per questo motivo viene verificato nella struttura dell organizzazione (utenti e ruoli) che tale utente possa effettivamente svolgere l operazione. La definizione delle operazioni che gli agenti possono svolgere è presente nella classe WorkflowDefinition. Gli agenti sono le risorse del workflow, che a loro volta possono essere unite in gruppi di risorse. Dal punto di vista delle reti di Petri, un task è un elemento transizione, pertanto nella definizione del workflow l assegnazione di risorse ad un task è effettuata nella specifica delle singole transizioni. Se l agente non può svolgere il task, quest ultimo rimane a disposizione degli altri utenti per lo svolgimento e il sistema provvederà ad assegnarlo. L automatismo che distribuisce i task è a sua volta un agente particolare, di sistema, (SystemAgent), il quale si occupa di interfacciarsi con il workflow e distribuire i task agli agenti utente, sulla base del numero di nuovi task per tick di simulazione, della tipologia di task, dello stato del task, dello stato degli agenti utente, etc. Inoltre, tale agente di sistema assegna agli agenti utenti, a seconda del tipo di task che viene assegnato, il periodo che serve a simulare il tempo che passa durante l esecuzione dell attività assegnata. Nella classe UserAgent sono presenti due metodi importanti: addtask() e performtask(). Il primo (fig. 7.12, 7.13 e 7.14) verifica che la regola di assegnazione sia superata con successo per l agente utente, nel qual caso: Il Work Item relativo al task viene aperto da questo agente (fig e 7.19). Aprire Cap. 7 WFsimulator: implementazione del modello di simulazione 113

121 7.2 Implementazione in Java di un simulatore di workflow reti di Petri ad agenti Workflow::cl_CloseAnActivity (listid: Integer): Void { //System.out.println("##### start cl_closeanactivity"); Activity a = (Activity) lastactivitieslist.get(listid); HashMap attributes = (HashMap) cases.get( a.getcasetype().getid() + a.getcase().getid()); boolean result = a.close(attributes); String resulttext; if (result == true) resulttext = "successo."; else resulttext = "errore."; //System.out.println("Activity n. " + a.getid() + " chiusa con " + resulttext); //System.out.println("----- end cl_closeanactivity"); } Figura 7.20: UML Activity diagram del metodo Workflow.cl CloseAnActivity() un Work Item implica il check-out dell oggetto ad uso esclusivo dell agente fino al rilascio. Un Work Item aperto (in progresso) è chiamato Activity. Nel workflow viene rimosso il token dal posto precedente la transizione = task (dalla rete di Petri). Lo scheduler viene programmato in modo da svolgere la funzione performtask() dopo il tempo di delay impostato per l agente e per il tipo di task, tramite la chiamata super.schedulewhenavailable(performtask, task). Il metodo performtask() (fig e 7.16) contiene la funzione da svolgere al termine dell emulazione del reale svolgimento dell attività da parte dell utente. Tale metodo rilascia la risorsa Activity e la chiude (fig e 7.20). Nel workflow viene inserito il token nel posto successivo alla transizione = task, permettendo di fatto l abilitazione della transizione successiva, il cui task verrà reso disponibile agli agenti tramite il workflow e potrà essere assegnato dall agente di sistema. Questo metodo, infine, effettua una serie di aggiornamenti dei parametri di impianto, ad esempio se necessario incrementa il numero di Case chiusi con successo, ossia con attraversamento completo della rete di Petri, dal simulatore. Infine, il metodo atend() della struttura RePast svolge alcune funzioni al momento del termine della simulazione, ad esempio stampa alcune informazioni riepilogative relative all istanza di workflow e salva su disco i grafici statistici. Cap. 7 WFsimulator: implementazione del modello di simulazione 114

122 7.2 Implementazione in Java di un simulatore di workflow reti di Petri ad agenti Altre caratteristiche Lo stato del workflow è salvato su file in modalità persistente all interno della directory STATEDIR (valore di default: outputs/state ). Ciò permette di riprendere lo stato di un workflow: se la directory contiene i dati di un motore di workflow eseguito, il sistema verrà reinizializzato utilizzando tali dati. Nella classe Workflow sono presenti svariate funzioni appositamente create per interagire con le API del workflow engine Bossa. Alcune di queste funzioni sono state utilizzate solo in fase di debug, ma restano utili ai fini di una possibile futura estensione. Alcune di queste funzioni sono presenti in modalità normale e silenziosa, in quest ultimo caso hanno un output di console nullo o limitato. La classe Task imposta il workitem assegnato ad un agente utente. Il simulatore è stato predisposto per la rappresentazione grafica degli agenti. I parametri della simulazione sono modificabili all inizio dell esecuzione, tramite l apposita interfaccia (cf. pag. 129). Il salvataggio dei dati è effettuato nel file di default outputs/results/outputdata.txt in formato testuale CSV. Tale file contiene alcune righe per la testata, una riga contenente i titoli delle colonne, una serie di righe con i valori elaborati relativamente ai tick che si è scelto di memorizzare tramite lo scheduling. OutputData.txt relativo al CaseType di Esempio (41 tick) - vedere paragrafi seguenti: File di output dati Timestamp: 2-ott "tick","numero di casi chiusi (totale)","numero di task eseguiti (totale)", "Numero di casi rifiutati perché gli utenti erano oberati (totale)", "Mario Bianchi(1) task assegnati","mario Bianchi(1) flussi chiusi", "Mario Bianchi(1) task eseguiti","mario Bianchi(1) task rifiutati", "Carlo Rossi(2) task assegnati","carlo Rossi(2) flussi chiusi", Cap. 7 WFsimulator: implementazione del modello di simulazione 115

123 7.2 Implementazione in Java di un simulatore di workflow reti di Petri ad agenti "Carlo Rossi(2) task eseguiti","carlo Rossi(2) task rifiutati", "Lucia Verdi(3) task assegnati","lucia Verdi(3) flussi chiusi", "Lucia Verdi(3) task eseguiti","lucia Verdi(3) task rifiutati" 1.0,0.0,3.0,2.0,6.0,0.0,1.0,0.0,5.0,0.0,1.0,0.0,6.0,0.0,1.0, ,1.0,5.0,3.0,6.0,0.0,2.0,1.0,6.0,0.0,2.0,0.0,5.0,1.0,1.0, ,3.0,6.0,4.0,7.0,0.0,3.0,1.0,7.0,1.0,2.0,1.0,7.0,2.0,1.0, ,4.0,11.0,4.0,5.0,1.0,4.0,1.0,7.0,1.0,4.0,1.0,7.0,2.0,3.0, ,6.0,12.0,5.0,4.0,2.0,4.0,1.0,7.0,1.0,5.0,2.0,6.0,3.0,3.0, ,6.0,15.0,7.0,3.0,2.0,5.0,1.0,6.0,1.0,6.0,2.0,7.0,3.0,4.0, ,6.0,22.0,7.0,1.0,2.0,7.0,1.0,4.0,1.0,8.0,2.0,4.0,3.0,7.0, ,6.0,28.0,7.0,0.0,2.0,9.0,1.0,2.0,1.0,10.0,2.0,3.0,3.0,9.0, ,7.0,30.0,7.0,0.0,3.0,9.0,1.0,2.0,1.0,11.0,2.0,3.0,3.0,10.0, ,8.0,32.0,7.0,0.0,3.0,9.0,1.0,5.0,2.0,11.0,2.0,2.0,3.0,12.0, ,8.0,35.0,7.0,0.0,3.0,9.0,1.0,3.0,2.0,13.0,2.0,1.0,3.0,13.0, ,10.0,36.0,7.0,0.0,3.0,10.0,1.0,5.0,3.0,13.0,2.0,3.0,4.0,13.0, ,11.0,39.0,7.0,1.0,3.0,10.0,1.0,5.0,3.0,15.0,2.0,1.0,5.0,14.0, ,12.0,42.0,7.0,0.0,3.0,11.0,1.0,3.0,4.0,16.0,2.0,0.0,5.0,15.0, ,13.0,45.0,7.0,0.0,3.0,12.0,1.0,2.0,5.0,17.0,2.0,3.0,5.0,16.0, ,14.0,47.0,7.0,0.0,3.0,12.0,1.0,0.0,5.0,19.0,2.0,2.0,6.0,16.0, ,15.0,49.0,7.0,0.0,3.0,12.0,1.0,0.0,5.0,20.0,2.0,3.0,7.0,17.0, ,16.0,52.0,7.0,0.0,3.0,13.0,1.0,0.0,6.0,20.0,2.0,1.0,7.0,19.0, ,16.0,54.0,7.0,0.0,3.0,13.0,1.0,1.0,6.0,21.0,2.0,3.0,7.0,20.0, ,17.0,55.0,7.0,0.0,3.0,13.0,1.0,0.0,6.0,22.0,2.0,2.0,8.0,20.0, ,19.0,57.0,7.0,1.0,3.0,14.0,1.0,0.0,7.0,22.0,2.0,1.0,9.0,21.0, ,20.0,59.0,7.0,2.0,4.0,14.0,1.0,3.0,7.0,23.0,2.0,0.0,9.0,22.0, ,21.0,61.0,7.0,1.0,5.0,14.0,1.0,1.0,7.0,25.0,2.0,0.0,9.0,22.0, ,22.0,64.0,7.0,1.0,5.0,15.0,1.0,3.0,8.0,27.0,2.0,0.0,9.0,22.0, ,23.0,65.0,7.0,1.0,6.0,15.0,1.0,3.0,8.0,28.0,2.0,1.0,9.0,22.0, ,24.0,67.0,7.0,0.0,6.0,16.0,1.0,2.0,9.0,28.0,2.0,0.0,9.0,23.0, ,24.0,70.0,7.0,2.0,6.0,16.0,1.0,0.0,9.0,30.0,2.0,1.0,9.0,24.0, ,24.0,73.0,7.0,0.0,6.0,18.0,1.0,1.0,9.0,30.0,2.0,1.0,9.0,25.0,4.0 Cap. 7 WFsimulator: implementazione del modello di simulazione 116

124 7.2 Implementazione in Java di un simulatore di workflow reti di Petri ad agenti 29.0,24.0,74.0,7.0,0.0,6.0,18.0,1.0,1.0,9.0,31.0,2.0,4.0,9.0,25.0, ,25.0,75.0,7.0,0.0,6.0,18.0,1.0,0.0,9.0,32.0,2.0,3.0,10.0,25.0, ,27.0,76.0,7.0,2.0,6.0,19.0,1.0,0.0,9.0,32.0,2.0,5.0,12.0,25.0, ,28.0,78.0,7.0,1.0,6.0,20.0,1.0,1.0,9.0,32.0,2.0,5.0,13.0,26.0, ,30.0,80.0,7.0,0.0,6.0,21.0,1.0,1.0,10.0,32.0,2.0,5.0,14.0,27.0, ,30.0,82.0,7.0,0.0,6.0,21.0,1.0,0.0,10.0,33.0,2.0,4.0,14.0,28.0, ,30.0,85.0,7.0,1.0,6.0,22.0,1.0,0.0,10.0,33.0,2.0,2.0,14.0,30.0, ,32.0,87.0,7.0,0.0,7.0,22.0,1.0,0.0,11.0,33.0,2.0,2.0,14.0,32.0, ,33.0,88.0,7.0,0.0,7.0,23.0,1.0,0.0,12.0,33.0,2.0,3.0,14.0,32.0, ,33.0,91.0,7.0,1.0,7.0,24.0,1.0,1.0,12.0,33.0,2.0,3.0,14.0,34.0, ,33.0,93.0,7.0,0.0,7.0,25.0,1.0,1.0,12.0,33.0,2.0,2.0,14.0,35.0, ,33.0,95.0,7.0,0.0,7.0,25.0,1.0,0.0,12.0,34.0,2.0,3.0,14.0,36.0, ,34.0,97.0,7.0,0.0,7.0,26.0,1.0,0.0,12.0,34.0,2.0,2.0,15.0,37.0, ,34.0,97.0,7.0,0.0,7.0,26.0,1.0,3.0,12.0,34.0,2.0,2.0,15.0,37.0, Esempio della logica di processo del workflow in WFsimulator Per meglio comprendere il funzionamento logico del workflow engine, basato sulle API di Bossa, è presentato un esempio di base. Il simulatore viene lanciato con il CaseType specificato nel seguente codice, consistente della rete di Petri più semplice possibile: tre posti e due transizioni, con routing sequenziale. La prima transizione può essere attraversata dalle risorse Richiedenti (tutte), la seconda solo dalle risorse Capi Ufficio, escludendo chi ha attraversato la prima transizione. // Definizione del CaseType: "CaseTypeEsempio" CaseType casetype = new CaseType(getCaseType()); Place A = casetype.registerplace("a", 1); Place B = casetype.registerplace("b"); Place C = casetype.registerplace("c"); Transition a = casetype.registertransition("a", "Richiedenti", 2L); Transition b = casetype.registertransition("b", "Capi-$a", 1L); Cap. 7 WFsimulator: implementazione del modello di simulazione 117

125 7.2 Implementazione in Java di un simulatore di workflow reti di Petri ad agenti a.input(a, "1"); a.output(b, "1"); b.input(b, "1"); b.output(c, "1"); HashMap attributes = new HashMap(); casetype.buildtemplate(attributes); // Registrazione del CaseType CaseTypeManager casetypemanager = workflow.getcasetypemanager(); casetypemanager.registercasetype(casetype); // Gestore Risorse ResourceManager resourcemanager = workflow.getresourcemanager(); // risorse di sistema Resource bianchi = resourcemanager.createresource("mario Bianchi"); Resource verdi = resourcemanager.createresource("lucia Verdi"); Resource rossi = resourcemanager.createresource("carlo Rossi"); Resource persone = resourcemanager.createresource("persone"); Resource capiufficio = resourcemanager.createresource("capi Ufficio"); persone.include(bianchi); persone.include(verdi); persone.include(rossi); capiufficio.include(verdi); capiufficio.include(rossi); // risorse del casetype (associate alle risorse di sistema) List caseresources = casetypemanager.getcasetype(getcasetype()).getresources(); for (int iter = 0; iter < caseresources.size(); iter++) { Resource resource = (Resource) caseresources.get(iter); Cap. 7 WFsimulator: implementazione del modello di simulazione 118

126 7.2 Implementazione in Java di un simulatore di workflow reti di Petri ad agenti if (resource.getid().equals("richiedenti")) { resource.include(persone); } else if (resource.getid().equals("capi")) { resource.include(capiufficio); } else if (resource.getid().equals("direttori")) { resource.include(rossi); } else { throw new BossaException("Casetype resource error."); } } Lo stato iniziale della rete di Petri è in figura 7.21: vi è un token all interno del posto A. Il flusso non è ancora iniziato, pertanto ancora non vi sono transizioni abilitate. Figura 7.21: Esempio della logica di processo in WFsimulator tramite rete di Petri (1) Al lancio del simulatore, appare l interfaccia di RePast con la barra dei pulsanti per la gestione della simulazione (fig. 7.22). Figura 7.22: Toolbar di RePast ad inizio simulazione. Il flusso comincia e la prima transizione a della rete di Petri viene abilitata perché è presente un token nel posto A che la precede (fig. 7.23). Utilizzando la funzionalità di Step è possibile svolgere il primo passo della simulazione in cui, a differenza dei successivi, verranno anche assegnati dei task pre-caricati agli agenti. L interfaccia mostra a video diversi diagrammi temporali che servono a tracciare a runtime l andamento dei parametri della simulazione. Cap. 7 WFsimulator: implementazione del modello di simulazione 119

127 7.2 Implementazione in Java di un simulatore di workflow reti di Petri ad agenti Figura 7.23: Esempio della logica di processo in WFsimulator tramite rete di Petri (2) Nella console vengono mostrate le informazioni sullo stato del simulatore e del workflow (se in fase di sviluppo non si sono scelti i metodi con output silenzioso). È interessante notare le seguenti caratteristiche. Le funzioni che elencano la lista delle risorse (lr ListAllResources e t ListResourcesOfCaseType) mostrano che il workflow engine ha elaborato correttamente le risorse, sia di sistema che di casetype, nel WorkflowDefinition: rid group? : Mario Bianchi no 1: Capi Ufficio yes 2: Persone yes 3: Carlo Rossi no 4: Lucia Verdi no rid group? : Capi yes 101: Richiedenti yes Il CaseType restituito (l ListCaseTypes) è: ctid CaseTypeEsempio Non sono presenti ancora Case nel workflow (c ListCasesOfCaseType): cid marking Cap. 7 WFsimulator: implementazione del modello di simulazione 120

128 7.2 Implementazione in Java di un simulatore di workflow reti di Petri ad agenti All interno del posto A è presente il token che abilita la transizione a (workitem). Nell elenco dei Work Item (w ListWorkItemsOfCaseType) è infatti presente il task a, non appartenente ad alcun Case perché si tratta di un workitem di tipo iniziale. Tale workitem sarà sempre presente: è sempre possibile iniziare il processo (con i requisiti utente adatti). ctid cid wiid : CaseTypeEsempio 0 a Visto che ancora nessun workitem è stato preso in carico diventando una activity, la lista di quest ultime è vuota (a ListActivitiesOfCaseType): ctid cid aid transition Durante la fase di assegnazione dei task pre-caricati, il sistema assegna all agente utente Bianchi il workitem a, dopo aver verificato che egli sia una risorsa in grado di svolgere tale compito. o_openaworkitem ok. Activity: 1 Tale workitem diventa in progress assumendo il nome di activity 1. È possibile pensare a questa fase come ad un check-out del task e visualizzarlo come in figura 7.24, in cui si nota che il token, prima presente nel posto A, è stato temporaneamente prelevato dalla rete: l agente Bianchi sta svolgendo il task sottinteso a tale transizione. Figura 7.24: Esempio della logica di processo in WFsimulator tramite rete di Petri (3) Il marking della rete di Petri del Case 1 assume la forma seguente, ossia temporaneamente non è più presente alcun token nel Case: Cap. 7 WFsimulator: implementazione del modello di simulazione 121

129 7.2 Implementazione in Java di un simulatore di workflow reti di Petri ad agenti cid marking : 1 {B=0, C=0, A=0} La lista dei workitem contiene come solito la transizione iniziale: ctid cid wiid : CaseTypeEsempio 0 a La lista delle activity ora contiene anche i dettagli dell activity 1 in corso di svolgimento: ctid cid aid transition : CaseTypeEsempio 1 1 a L assegnazione dei task pre-caricati prosegue, facendo iniziare nuovi Case (istanze di wokflow). Nel frattempo lo scheduler si accorge che Case 15 ha finito il tempo di servizio da emulare come svolgimento del task e pertanto decide di rilasciare la relativa activity. cl_closeanactivity ok. Success=true Nella rete di Petri il token che era stato temporaneamente tolto dal sistema per il Case 15 viene quindi inserito nel posto B (fig. 7.25), il quale abilita la nuova transizione b. Figura 7.25: Esempio della logica di processo in WFsimulator tramite rete di Petri (4) Lo scatto della transizione a per questo Case è completato. Il marking del Case 15 pertanto passa da valori pari tutti a zero al seguente: cid marking Cap. 7 WFsimulator: implementazione del modello di simulazione 122

130 7.2 Implementazione in Java di un simulatore di workflow reti di Petri ad agenti : 15 {B=1, C=0, A=0} È interessante notare come la lista dei Work Item ora contiene un nuovo Work Item a disposizione per la presa in carico: la transizione b del Case 15. ctid cid wiid : CaseTypeEsempio 0 a 1: CaseTypeEsempio 15 b Al termine dell assegnazione dei task pre-caricati la situazione sarà simile alla seguente, con vari workitem e activity presenti nel sistema: marking: cid marking : 15 {B=1, C=0, A=0} 1: 4 {B=1, C=0, A=0} 2: 19 {B=0, C=0, A=0} 3: 8 {B=0, C=0, A=0} 4: 11 {B=0, C=0, A=0} 5: 16 {B=0, C=0, A=0} 6: 18 {B=0, C=0, A=0} 7: 3 {B=0, C=0, A=0} 8: 7 {B=0, C=0, A=0} 9: 12 {B=0, C=0, A=0} 10: 17 {B=0, C=0, A=0} 11: 2 {B=0, C=0, A=0} 12: 13 {B=0, C=0, A=0} 13: 9 {B=0, C=0, A=0} 14: 6 {B=0, C=0, A=0} 15: 1 {B=0, C=0, A=0} 16: 20 {B=0, C=0, A=0} Cap. 7 WFsimulator: implementazione del modello di simulazione 123

131 7.2 Implementazione in Java di un simulatore di workflow reti di Petri ad agenti 17: 14 {B=0, C=0, A=0} 18: 10 {B=0, C=0, A=0} 19: 5 {B=0, C=0, A=0} workitem: ctid cid wiid : CaseTypeEsempio 0 a 1: CaseTypeEsempio 15 b 2: CaseTypeEsempio 4 b activity: ctid cid aid transition : CaseTypeEsempio 19 1 a 1: CaseTypeEsempio 8 1 a 2: CaseTypeEsempio 11 1 a 3: CaseTypeEsempio 16 1 a 4: CaseTypeEsempio 18 1 a 5: CaseTypeEsempio 3 1 a 6: CaseTypeEsempio 7 1 a 7: CaseTypeEsempio 12 1 a 8: CaseTypeEsempio 17 1 a 9: CaseTypeEsempio 2 1 a 10: CaseTypeEsempio 13 1 a 11: CaseTypeEsempio 9 1 a 12: CaseTypeEsempio 6 1 a 13: CaseTypeEsempio 1 1 a 14: CaseTypeEsempio 20 1 a 15: CaseTypeEsempio 14 1 a 16: CaseTypeEsempio 10 1 a 17: CaseTypeEsempio 5 1 a Ad ogni step di simulazione il workflow engine interattivamente permette l assegnazione Cap. 7 WFsimulator: implementazione del modello di simulazione 124

132 7.2 Implementazione in Java di un simulatore di workflow reti di Petri ad agenti dei task agli agenti utente tramite l agente di sistema. I singoli Case di questo CaseType si concludono con lo scatto dal posto B al posto C, attraverso lo svolgimento del task b (fig. 7.26). Figura 7.26: Esempio della logica di processo in WFsimulator tramite rete di Petri (5) Esempio di simulazione con WFsimulator In figura 7.27 è riportato lo screenshot effettuato al 41 tick di simulazione del Case Type descritto al paragrafo precedente. In alto a destra è presente la barra degli strumenti RePast, in basso la console di output. Sullo schermo vi sono i diagrammi dei valori dei parametri di impianto che si desidera raccogliere dalla simulazione. Cap. 7 WFsimulator: implementazione del modello di simulazione 125

133 7.2 Implementazione in Java di un simulatore di workflow reti di Petri ad agenti Figura 7.27: Screenshot del WFsimulator in RePast. Cap. 7 WFsimulator: implementazione del modello di simulazione 126

134 7.2 Implementazione in Java di un simulatore di workflow reti di Petri ad agenti Manuale d uso di WFsimulator Abstract Il simulatore utilizza RePast 3 per modellare un mondo ad agenti asincroni e Bossa per modellare un sistema di workflow management adattativo. Il CaseType del workflow è definibile nella classe WorkflowDefinition; quello di esempio è relativo al flusso SABS della Presidenza dei Consiglio dei Ministri. Per definire un workflow bisogna utilizzare la notazione delle reti di Petri, con posti e transizioni. Il workflow è del tipo inter-organizzativo poiché sono modellate anche le risorse del sistema, ossia utenti e ruoli. Gli agenti sono asincroni perché una volta che viene loro assegnato un task (fra quelli che possono effettivamente svolgere), autonomamente provvedono a schedularsi secondo le proprie caratteristiche, anche sulla base di particolari condizioni in corso del sistema. Struttura delle directory Per analizzare la struttura delle directory del progetto, fare riferimento alla tabella 7.1. Compilazione codice sorgente $WFSIM è il percorso della directory del simulatore WFsimulator. Includere nel classpath tutte le librerie JAR che si trovano nella cartella $WFSIM/lib, relative a bossa e repast. Per la ricompilazione è possibile utilizzare il MANIFEST file $WFSIM/.manifest e il CLASSPATH file $WFSIM/.classpath. I javadocs di WFsimulator si trovano in $WFSIM/doc/wfsimulator/javadocs (cf. appendice B). Codice sorgente delle librerie I sorgenti di bossa e repast si trovano rispettivamente in $WFSIM/doc/bossa/bossa-src.zip e $WFSIM/doc/repast/repast-src.zip, i cui javadocs sono rispettivamente in $WFSIM/doc/- bossa/javadocs e $WFSIM/doc/repast/javadocs. Due dei sorgenti delle librerie bossa sono stati ricompilati. Fare riferimento ai file bossa leggimi.txt e prevayler-leggimi.txt nella cartella $WFSIM/lib/bossa. Cap. 7 WFsimulator: implementazione del modello di simulazione 127

135 7.2 Implementazione in Java di un simulatore di workflow reti di Petri ad agenti Directory Descrizione + Contiene il JAR e file di startup + bin Contiene i file binari, ossia i file + wfsimulator.class dell applicazione + doc Contiene la documentazione + bossa - della libreria bossa + doc - descrizione + api api e + manifesto manifesto + javadocs - javadocs + pnk - editor pnk + repast - della libreria repast + how-to - tutorial + images e how-to + javadocs - javadocs + wfsimulator - del Simulatore + docs - documentazione + javadocs - javadocs + etc Contiene materiale aggiuntivo + bossa - della libreria bossa + pnk - editor pnk + test-data - file.pnml per editor + zip - zip pacchetto originale + wfsimulator - del Simulatore + casetype Purchase - rappr. grafica dei casetype + casetype SABS nella classe WorkflowDefinition + casetype Simple + lib Contiene le librerie per la compilazione + bossa - librerie bossa + repast - librerie repast + outputs Contiene i file di runtime e uscita + results - OutputData.txt con i dati + state - directory per le transazioni + src Contiene il codice sorgente + wfsimulator - package wfsimulator Tabella 7.1: Struttura delle directory del progetto WFsimulator. Cap. 7 WFsimulator: implementazione del modello di simulazione 128

136 7.2 Implementazione in Java di un simulatore di workflow reti di Petri ad agenti Figura 7.28: Modifica dei parametri di WFsimulator per la simulazione. Lancio della simulazione Le directory seguenti devono essere esistenti prima del lancio della simulazione. +---outputs +---results +---state Per far iniziare la simulazione è possibile lanciare a mano il file WFsimulator.jar o, meglio, utilizzare gli script, eventualmente adattati: $WFSIM/WFsimulator.sh in ambiente Unix-Linux $WFSIM/WFsimulator.bat in ambiente Windows Questi script effettuano una pulizia dello stato e della persistenza delle transazioni del workflow e poi provvedono al lancio del JAR del simulatore tramite il comando java -jar WFsimulator.jar. È possibile variare i parametri della simulazione tramite la finestra WFsimulator Parameters di RePast (cf. figura 7.28). Log e memorizzazione risultati I grafici saranno memorizzati nella directory radice del simulatore $WFSIM. I risultati (dati) saranno memorizzati nel file $WFSIM/output/results/OutputData.txt. Eventuali errori Cap. 7 WFsimulator: implementazione del modello di simulazione 129