WIDE workflow model: modello dei processi

WIDE workflow model: modello dei processi

Processi in WIDE

Il modello per la rappresentazione dei processi proposto nel progetto EU-ESPRIT WIDE (Workflows on an Intelligent and Distributed database Environment) si colloca nel filone dei modelli che consentono di descrivere processi come insiemi di attività  tra loro collegate da vincoli di precedenza e punti di sincronizzazione. Caratteristiche particolare del modello WIDE (WIDE workflow model) sono la possibilità di descrivere processi in modo flessibile, in particolare per quanto riguarda il trattamento delle eccezioni, e la definizione di un modello transazionale associato ai processi.

Il modello dei processi di WIDE è associato a altri due modelli che completano la descrizione dei processi con la descrizione delle informazioni a essi associate e degli agenti che svolgono attività nei processi. Pertanto il modello WIDE descrive i processi e le loro caratteristiche tramite tre modelli tra loro collegati:

  • il modello dei processi, che definisce le attività che fanno parte del processo e l’ordine in cui tali attività devono essere eseguite;
  • il modello delle informazioni, che consente di descrivere i dati e i documenti necessari all’esecuzione di un processo, in particolare in vista di un supporto informatizzato tramite workflow;
  • il modello dell’organizzazione, che consente di descrivere la struttura dell’organizzazione e gli agenti che ne fanno parte, indipendentemente dalla descrizione dei singoli processi.

Il modello dei processi

La descrizione del flusso delle attività in WIDE è basata sulla descrizione formale del flusso di controllo delle attività nel processo.

Un workflow in WIDE è specificato essenzialmente da un insieme di attività (task) e da connettori che specificano l’ordine in cui i task devono essere eseguiti. Oltre a task e connettori, la specifica di un workflow può includere altri due tipi di elementi:

  • unità di modularizzazione, distribuzione e transazionali: consentono di descrivere i processi a diversi livelli di dettaglio, isolandone alcune parti che debbono essere ritenute unitarie dal punto di vista della distribuzione del lavoro o dal punto di vista transazionale
  • eccezioni: consentono di descrivere in modo compatto alcune situazioni di tipo anomalo che si possono verificare durante l’esecuzione del processo e richiedono un particolare trattamento, quale l’esecuzione di specifiche attività o l’aggiornamento di alcuni dati del processo o l’alterazione del normale flusso di esecuzione.

Un esempio di workflow che descrive un processo di prenotazione viaggi è presentato nella figura seguente.

Specifica WIDE di un processo per la prenotazione di un viaggio
Specifica WIDE di un processo per la prenotazione di un viaggio

Nella figura, i task sono rappresentati da rettangoli, mentre gli altri simb oli sono connettori, e definiscono la struttura del processo. Una istanza di un workflow (chiamata case nella terminologia WIDE) è un’esecuzione del processo. Varie istanze dello stesso processo possono essere in esecuzione nello stesso momento (ad esempio, molti istanze del processo di prenotazione viaggi possono essere contemporaneamente attivi).

Nel seguito della sezione presenteremo nel dettaglio i diversi costrutti del modello WIDE e descriveremo poi la semantica del workflow mostrato nella figura precedente.

Task

I task sono le attività elementari che compongono un processo. Un task è caratterizzato da:

  • un nome, unico all’interno del processo;
  • una descrizione, in linguaggio naturale, che descrive lo scopo del task;
  • un insieme di ruoli, che indica le capacità necessarie per eseguire il task. L’esecutore del task deve essere scelto fra quelli che ricoprono almeno uno dei ruoli specificati. I ruoli sono l’anello di collegamento tra il modello di processo e quello dell’organizzazione, come meglio descritto in seguito;
  • un insieme di dati associati al task, necessari per la sua esecuzione. I dati possono essere sia strutturati e di un tipo noto al sistema (ad esempio interi, reali, stringhe) che non strutturati (documenti prodotti con un programma di videoscrittura);
  • un insieme di azioni predefinite che è possibile effettuare sul task; ad esempio, è possibile sospendere e poi riprendere l’esecuzione di un task, terminare un task o delegarlo per l’esecuzione ad un altro

Uno stesso task può essere attivato (istanziato) più volte nello stesso case. Differenti istanze di task sono caratterizzate da un diverso (e progressivo) numero di attivazione1.

Connettori

I connettori modellano l’interazione fra i task e definiscono la struttura di un workflow. Un task può avere una sola connessione in uscita ed una in ingresso. Due task A e B possono essere connessi direttamente (tramite una freccia, nel linguaggio grafico), con la semantica che non appena A termina, B viene mandato in esecuzione. In tutti gli altri casi, le connessioni fra task sono mediate da connettori. I connettori possono iniziare l’esecuzione parallela di task (connettori fork), o sincronizzare al termine di esecuzioni parallele (connettori join).

Connettori fork

I connettori di tipo fork sono preceduti da un task, chiamato predecessore, e seguiti da due o più task, chiamati successori. I connettori di tipo fork sono classificati come segue:

  • totale: al temine del predecessore il sistema attiva tutti i successori.
  • condizionale: ad ogni successore è associata una condizione: al termine del predecessore, il sistema attiverà tutti i successori la cui condizione è vera.

Connettori join

I connettori di tipo join sono preceduti da due o più task, chiamati predecessori, e seguiti da un task, chiamato successore. I connettori di tipo join sono classificati come segue:

  • totale: il successore viene attivato solo al termine di tutti i predecessori;
  • parziale: al connettore join è associato un valore k : il successore viene attivato non appena k predecessori con lo stesso numero di attivazione sono terminati. La terminazione di ulteriori predecessori non ha nessun effetto. k può essere una costante o una variabile del Per default, il join parziale ha k=1.
  • ciclico: un’istanza del successore viene attivata tutte le volte che un predecessore

La rappresentazione grafica di task e connettori è mostrata nella figura seguente.

Simboli del modello WIDE
Simboli del modello WIDE

Simboli di inizio e fine processo

Ogni workflow ha un simbolo di inizio e uno o più simboli di fine processo. Il simbolo   di inizio ha uno o più successori (nel caso di più di un successore, il simbolo di inizio deve essere seguito da un connettore fork), e analogamente il simbolo di fine ha uno o più task predecessori (nel caso di più successori, il simbolo di fine deve essere preceduto da un connettore join).

Quando un workflow viene istanziato, il sistema attiva il successore (o i successori) del simbolo di inizio. L’istanza terminerà al termine di un predecessore del simbolo di fine workflow. Quando l’istanza termina, alcuni task possono essere ancora attivi: questi task vengono cancellati, e i rispettivi agenti vengono informati della cancellazione.

Wait task

Il wait task è un particolare tipo di task che non compie azioni e che non deve essere assegnato ed eseguito da un agente. Il suo compito è di attendere che una certa condizione si verifichi. La condizione associata alla definizione del wait task può essere definita come un predicato sui dati del workflow, sul tempo, o sull’occorrenza di eventi esterni. Non appena la condizione è verificata, il task termina, attivando così il task successivo.

Multitask

Un multitask definisce un insieme di task che eseguono la stessa funzione in parallelo. L’attivazione del multitask corrisponde all’attivazione contemporanea di più istanze dello stesso task, assegnate ad agenti differenti. Tutte le istanze hanno lo stesso numero di attivazione, che coincide con quello del multitask (differenti attivazioni del multitask hanno comunque numeri di attivazione differenti e progressivi). Il multitask ha un duplice scopo: consente di specificare in modo compatto un insieme di task che  compiono la stessa funzione e consente di definire a tempo di esecuzione il numero delle istanze che devono essere attivate, che può dipendere dal valore di una variabile del workflow.

Ad esempio, nel workflow di prenotazione viaggi, revisione di un documento, il numero dei revisori che controllano una fattura può essere definito in funzione dell’importo della fattura. Un multitask termina quando termina un numero k di istanze di task. k è quorum del multitask, e può essere una costante o può identificare una variabile di processo il cui valore viene verificato ogni volta che una istanza del multitask termina. Ad esempio, è possibile specificare che il multitask di controllo fattura termini non appena la maggioranza dei revisori ha dato un parere concorde (favorevole o contrario), senza dover necessariamente attendere il giudizio di tutti i revisori.

Sottoprocessi, supertask, e business transactions

Sottoprocessi, supertask e business transaction sono costrutti che raggruppano insiemi di task, consentendo di modularizzare la specifica di un workflow e di definire proprietà transazionali. Nessuno di questi costrutti può essere direttamente eseguito (istanziato): essi devono essere definiti all’interno di un workflow, e sono istanziati quando vengono raggiunti dal flusso di controllo, come per i task ordinari.

I sottoprocessi sono del tutto analoghi a workflow, salvo per il fatto che non possono essere direttamente istanziati. Essi hanno un insieme di dati in ingresso e in uscita,  passati (per copia/risultato) al sottoprocesso e ritornati al processo padre al termine del sottoprocesso. Il sottoprocesso è una “scatola nera” per il processo padre, ed è la base per la definizione di specifiche riusabili: infatti, un sottoprocesso può essere riutilizzato (invocato) nel contesto di diversi workflow.

Come i sottoprocessi, anche i supertask sono composti da un insieme di task, collegati tramite connettori. Il supertask non ha però parametri di ingresso o di uscita, e vede le stesse variabili del processo nel quale è definito. Inoltre, il supertask può essere definito ed istanziato solo nel contesto di un workflow, e non può quindi essere riusato per altri workflow.

La business transaction è l’elemento di base del modello transazionale di WIDE. Il concetto di business transaction ha lo scopo di consentire la specifica, a livello di workflow, di proprietà transazionali caratteristiche delle operazioni su basi di dati. Un workflow ha però caratteristiche molto diverse da una classica transazione eseguita su di una base di dati. Infatti, l’esecuzione di un workflow comporta azioni che hanno effetto nel mondo reale, quali l’invio di documenti per posta o la vendita di un prodotto. Tali operazioni non possono essere annullate, come lo possono invece essere le operazioni di manipolazione dati. Inoltre, è praticamente impossibile eseguire un intero case in modo isolato, dato che un case può durare parecchi giorni, o anche mesi, ed altre applicazioni hanno tipicamente la necessità di accedere agli stessi dati in quel lasso di tempo. Il concetto di business transaction e il modello transazionale di WIDE hanno quindi lo scopo di fornire determinate proprietà transazionali ai workflow, tenendo conto delle caratteristiche sopra citate.

Una business transaction raggruppa task che formano un’unità transazionale, ovvero che devono essere eseguiti in modo atomico e isolato rispetto agli altri task dello stesso o di altri case. In WIDE, ogni task deve fare parte di una business transaction o deve essere esso stesso una business transaction. Pertanto, un workflow può essere visto come un insieme di business transaction. All’interno di una business transaction i vincoli di isolamento possono essere definiti in modo flessibile: è possibile specificare se i risultati di un task devono essere resi visibili o meno agli altri task della business transaction.

Nel caso che l’esecuzione di una istanza debba essere annullata, il sistema garantisce l’atomicità dell’esecuzione come segue: le business transaction attive vengono abortite; questo è possibile, dato che le business transaction hanno le classiche proprietà “acide” delle transazioni. Le business transaction completate vengono invece compensate, dal punto di vista semantico, eseguendo un task di compensazione associato ad  ogni business transaction. Ad esempio, se una business transaction ha il compito di inviare un documento ad un cliente, il task di compensazione potrebbe comportare una telefonata o un’altra lettera al cliente che lo informa che il contenuto della precedente lettera non deve essere considerato valido. La compensazione avviene in ordine inverso rispetto all’esecuzione delle business transaction, e procede fino a che il case è stato compensato.

Il workflow Prenotazione Viaggi

In questo paragrafo si descrive brevemente la semantica del workflow Prenotazione Viaggi mostrato nella relativa figura. Una nuova istanza del processo viene attivata da un agente alla richiesta della prenotazione di un viaggio da parte di un cliente. L’impiegato propone al cliente un viaggio (business transaction Selezione viaggio), verifica la disponibilità del mezzo di trasporto e della sistemazione alberghiera e calcola il costo del viaggio. Il cliente può decidere se accettare o meno il viaggio proposto dall’agente (l’agente assegna alla variabile Approvato il valore true o il valore false a seconda della decisione del cliente), e in caso di rifiuto può decidere di provare con un’altra proposta (alla variabile Cambia viene assegnato il valore true) o cancellare la sua richiesta.

In caso di approvazione, il processo continua con la preparazione e l’invio della fattura al cliente (business transaction Conferma viaggio) e con la preparazione dei documenti di viaggio (business transaction Preparazione documenti). In parallelo alla preparazione dei documenti viene attivato il sottoprocesso Richiesta pagamento, composto dalle business transaction Invio fattura e Gestione pagamento. Si noti, all’interno di Invio fattura, il multitask Controllo fattura , descritto in precedenza, la cui molteplicità è definita dalla variabile del case NumRev, ed il cui quorum è definito dalla variabile di case RevQuorum. Queste variabili sono opportunamente impostate dal task Preparazione fattura. Da ultimo, quando il viaggio è stata pagato e i documenti sono stati preparati (si noti il join totale che attende il termine del task Prepara documenti e del sottoprocesso Richiesta pagamento), il processo prevede, come ultimo task, l’invio dei documenti al cliente.

Nel caso che invece il cliente non accetti i viaggi proposti dall’agente, la richiesta viene cancellata (business transaction Cancellazione viaggio), ed il case termina subito dopo.

Assegnamento di un task

L’assegnazione di un task ad un agente può avvenire in due modi: il  sistema  può scegliere l’agente, nel rispetto dei vincoli definiti dal progettista del workflow, e assegnare direttamente il task ad un agente (modalità push), oppure può inserire il task nella lista delle attività pendenti di tutti gli agenti autorizzati ad eseguire il task. Quando un agente autorizzato seleziona il task per eseguirlo, il task viene rimosso dalla lista delle attività degli altri agenti (modalità pull). La maggior parte dei sistemi commerciali adotta la modalità pull, sia perché è più flessibile (non impone l’esecuzione ad un agente specifico ma la propone a molti), sia perché la modalità push è a volte considerata “fastidiosa” dall’impiegato, che si vede assegnato il lavoro da svolgere dal sistema.

Quando un agente ha terminato l’esecuzione del task, notifica al sistema che il task è completato ed il sistema determina il prossimo task da attivare nel case. Un task assegnato può anche essere delegato ad un altro agente (il sostituto), se l’operazione è fra quelle consentite per quel task.

Agenti particolari in un sistema di gestione di workflow

In un sistema di workflow vi sono alcuni agenti che svolgono funzioni  specifiche rispetto alla gestione e all’esecuzione dei workflow:

  • l’esecutore del task è l’agente incaricato di eseguire una specifica istanza di task in un certo case;
  • il responsabile del case è l’agente che supervisiona il case, e al quale vengono notificati i problemi e le situazioni eccezionali relative a quel case;
  • l’esecutore del case è l’agente che ha attivato il case. Come per i task, anche per i workflow è possibile specificare il ruolo che deve ricoprire l’agente autorizzato ad istanziare un workflow, ovvero a creare un nuovo case;
  • il progettista di un workflow è l’agente che ha specificato il workflow;
  • l’amministratore del sistema è l’agente (o l’insieme di agenti) che gestisce il sistema di workflow, e che ha i diritti di installare nuove definizioni di workflow o di modificare la struttura dell’organizzazione.

Action Workflow

Nell’approccio proposto negli Action Workflow il flusso di lavoro (ed il processo correlato) non è fatto soltanto di azioni ed attività finalizzate alla trasformazione di informazioni, ma è fatto soprattutto di interazioni tra persone, che  comportano reciproche richieste, promesse e assunzioni di impegni. L’enfasi viene quindi posta sull’interazione tra fornitori e clienti di servizi nell’esecuzione del processo.

Gli elementi principali del modello Action Workflow sono i seguenti:

  • Attività – Ogni compito lavorativo svolto dalle persone
  • Azione – Ciò che le persone fanno quando chiedono o prendono reciprocamente impegni le une con le altre con l’obiettivo di ottenere una condizione di soddisfazione
  • Impegno – Modalità di interazione tra cliente e fornitore
  • Processo – Insieme di attività scatenati da azioni, sotto la responsabilità di un operatore, e che avvengono in un determinato spazio o tempo

Un processo è dunque definibile come una rete di transazioni tra persone (clienti ed esecutori) che produce azioni coordinate ai fini della soddisfazione del cliente.

Precedente Data Flow Diagram (DFD): rappresentazione dei processi Successivo Diagramma delle attività in UML

Lascia un commento

*