Orchestrazione Di Risorse Umane Nel Bpm

UNIVERSITÀ DEGLI STUDI DI BARI FACOLTÀ DI SCIENZE MATEMATICHE FISICHE E NATURALI CORSO DI LAUREA IN INFORMATICA E TECNOLOGIE PER LA PRODUZIONE DEL SOFTWARE

Tesi di laurea in Gestione della conoscenza di impresa

ORCHESTRAZIONE DI RISORSE UMANE NEL BPM Gestione dinamica feature-based delle organizzazioni nella piattaforma openwork®

Relatore: Prof. Giovanni Semeraro Correlatore: Dott. Gianpiero Bongallino Candidato: Michele Filannino

Anno accademico 2007-2008

2

3

Indice Indice delle figure .......................................................................... 6 Capitolo 1: Introduzione ...........................................................10 1.1 Scopo della tesi....................................................................................... 11 1.2 Struttura della tesi ................................................................................ 13

Capitolo 2: I processi ..................................................................14 2.1 Storia dei processi ................................................................................ 15 2.1.1 Workflow ........................................................................................ 15 2.1.2 Business Process ......................................................................... 16 2.1.3 BPM ................................................................................................... 19 2.2 Standard .................................................................................................... 21 2.2.1 BPEL .................................................................................................. 21 2.2.2 BPMN ................................................................................................ 23 2.2.3 XPDL .................................................................................................. 25

Capitolo 3: Openwork® .............................................................27 3.1 Document Management ..................................................................... 28 3.2 Workflow Management...................................................................... 29 3.3 Architettura ............................................................................................. 30 3.3.1 BPM Tools® .................................................................................. 32 3.3.1.1 Organization Designer ............................................................................................ 34 3.3.1.2 Form Designer ............................................................................................................ 34 3.3.1.3 Business Flow Designer ......................................................................................... 34

3.3.2 Web Client ...................................................................................... 35

Capitolo 4: Analisi del problema ............................................37 4.1 Modello di processo ............................................................................. 37

4 4.2 Organizzazione ....................................................................................... 39 4.3 Cos’è un gruppo dinamico ................................................................ 40 Gruppo dinamico in un Process Model ........................................ 42 Gruppo dinamico in un Executable Model ................................. 42 Gruppo dinamico in una Process Instance ................................. 42 4.4 Espressioni ............................................................................................... 43 Spring.NET Framework ...................................................................... 43 4.5 Riflessioni ................................................................................................. 44 Valutazione dell’espressione ............................................................ 44 Eliminazione di un gruppo dinamico .......................................... 46 Gruppo dinamico privo di elementi .............................................. 46 Cambiamento del set di attributi utilizzabili ............................ 46

Capitolo 5: Analisi dei requisiti ..............................................48 5.1 Requisiti ..................................................................................................... 49 Funzionali [FUN] .................................................................................... 49 Informativi [INF] .................................................................................... 50 Interfaccia [IFC] ...................................................................................... 51 Manutenzione [MAN] ........................................................................... 51 Prestazioni [PER] ................................................................................... 51 Piattaforma [PLF]................................................................................... 51 Sicurezza [SEC] ........................................................................................ 51 Integrazione [INT] ................................................................................. 51 Tecnici [TEC] ............................................................................................ 52

Capitolo 6: Specifiche dei requisiti ........................................53 6.1 Classi ........................................................................................................... 53 6.1.1 Diagrammi...................................................................................... 53 Mapping ........................................................................................................................................ 53 Raffinamento .............................................................................................................................. 54 Classi definitive ......................................................................................................................... 55

6.2 Casi d’uso .................................................................................................. 56 6.2.1 Diagrammi...................................................................................... 56 Mapping ........................................................................................................................................ 56 Diagramma dei casi d’uso..................................................................................................... 58

6.2.2 Dettaglio casi d’uso .................................................................... 59 1. Show Dynamic Groups ...................................................................................................... 59 2. Delete Unused Dynamic Groups................................................................................... 60 3. Create Dynamic Group ...................................................................................................... 61 4. Update Dynamic Group .................................................................................................... 62 5. Link Dynamic Group to Activity ................................................................................... 63 6. Formal Control of Accuracy ............................................................................................ 64 7. Publish Model........................................................................................................................ 65

5 8. Request Access ..................................................................................................................... 66 9. Verify affiliations of dynamic group ........................................................................... 67 10. Affiliated Users of a Dynamic Group ....................................................................... 68

Capitolo 7: Conclusioni ..............................................................69 7.1 Possibili sviluppi futuri ...................................................................... 69 7.1.1 Uso trasversale delle espressioni........................................ 70 7.1.2 Information Retrieval ............................................................... 70

Appendice .......................................................................................71 A UML ...............................................................................................72 A.1 Storia........................................................................................................... 73 A.2 Caratteristiche speciali ...................................................................... 74 A.3 Applicazioni ............................................................................................. 75

B XML ................................................................................................76 B.1 Strumenti aggiuntivi per XML ........................................................ 77

Glossario ed Acronimi ................................................................79 Bibliografia.....................................................................................81

6

Indice delle figure Figura 1: Logo della piattaforma openwork® .....................................10 Figura 2: Ciclo di vita del BPM.............................................................20 Figura 3: Esempio di un processo disegnato in BPEL .........................23 Figura 4: Esempio di un processo disegnato con BPMN ....................24 Figura 5: Architettura del framework openwork® .............................31 Figura 6: Architettura del BPM Tools®................................................33 Figura 7: Eventi per un'attività openwork® ........................................45 Figura 8: Classi definitive.....................................................................55 Figura 9: Diagramma dei casi d'uso ....................................................58

7

8

“ A te nonna …”

9

10

Capitolo 1: Introduzione Questa tesi è il prodotto finale, di uno stage durato sei mesi nell’area “Ricerca & Sviluppo” presso l’azienda Net Sistemi srl di Modugno (BA). Net Sistemi srl è una Indipendent Software Vendor che sviluppa un solo prodotto software: openwork®.

Figura 1: Logo della piattaforma openwork®

openwork® nasce dall’intuizione, negli anni novanta, con largo anticipo rispetto al mercato, del bisogno di soluzioni software con logiche di WorkFlow e Document Management che avessero un approccio e strumenti più vicini alle esigenze degli utilizzatori non esperti di tecnologia. Nell'ottica più ampia e completa del Business Process Management, l’ambito di intervento di openwork® si è andato quindi ampliando nel corso degli anni, con un'evoluzione costante che continua ancora oggi. Questo è il risultato di lunghi anni di lavoro progettuale e investimenti in ricerca e sviluppo, realizzati interamente in Italia,

11 delineando un approccio del tutto originale ed innovativo, non soltanto per il mercato italiano. La mission aziendale è quella di fornire strumenti per il governo delle organizzazioni definendo metodologie e producendo una suite software per disegnare, analizzare e condividere processi, con la possibilità di creare e manutenere, in modo sostenibile, applicazioni su misura sempre allineate al business che cambia. Il portfolio clienti dell’azienda annovera grandi realtà economiche quali:  Enel SpA;  Bosch SpA;  Natuzzi SpA;  ACEA-Electrabel;  Comune di Bari;  Comune di Lecce;  Regione Basilicata;  Comune di Salerno;  Politecnico di Torino;  Findomestic Banca SpA;  TNT Global Express SpA;  Banca Popolare di Garanzia SCpA;  Konica Minolta Business Solutions Italia SpA.

1.1 Scopo della tesi Il lavoro di ricerca profuso in questi sei mesi per la Net Sistemi srl ha avuto come obiettivo l’analisi del concetto di organizzazione all’interno di una piattaforma software di BPM; con particolare riferimento alla piattaforma openwork®. Il BPM è una disciplina che si occupa delle metodologie e degli strumenti per la modellazione, esecuzione, miglioramento in termini di efficienze ed efficacia dei processi di business di qualsiasi organizzazione. Sotto questa denominazione sono stati classificati negli anni tool software completamente diversi tra loro ed in particolare quelli di EAI (Enterprise Application Integration) e i sistemi di Workflow.

12 L’assenza di standard ha agevolato per anni, il proliferarsi di numerose soluzioni software di BPM tutte proprietarie, ciascuna con la propria logica, i propri vincoli ma soprattutto la propria interpretazione del dominio applicativo. Sicché, pur esistendo tanti software diversi, ognuno di essi contemplava una definizione di Processo, o di Attività, il più delle volte profondamente diversa. Il principale difetto di questo approccio è stato quello della non interoperabilità tra i diversi software: un processo formalizzato nel software A non era assolutamente leggibile dal software B. Da qualche anno, grazie al sempre maggior successo che queste applicazioni riscuotono, il settore dei BPM sta vivendo un periodo di standardizzazione. Hanno iniziato timidamente a fare il loro ingresso sul mercato i primi standard di interoperabilità ufficiali. Gli organi ratificatori più autorevoli e prestigiosi in questo settore sono il Workflow Management Coalition (che ha elaborato lo standard di interoperabilità XPDL e della quale la Net Sistemi srl è rappresentante a livello nazionale), Oasis (che ha elaborato lo standard di esecuzione di processi SOA di nome BPEL), BPMI.org che ha elaborato lo standard di modellazione BPMN. La piattaforma openwork® fu realizzata dieci anni fa, quando ancora non esistevano standard o direttive che chiarissero il dominio applicativo di un software di BPM. In più, openwork® non si limita ai concetti strettamente correlati al Workflow ma va oltre, consentendo di gestire altri due domini affini: documenti ed organizzazioni. La piattaforma in questi mesi ha iniziato a vivere un periodo di profonda reingegnerizzazione e di apertura verso gli standard. Tuttavia, gli standard garantiscono l’interoperabilit{ solo di una parte del dominio applicativo di openwork®: non esiste ancora nessuno standard circa l’interoperabilit{ di documenti e/o delle organizzazioni. Da questa carenza è nata l’esigenza di riflettere, in largo anticipo sui concorrenti, sul concetto di organizzazione (1). L’oggetto della riflessione è stato prevalentemente quello di:  Formalizzare il concetto di gestione dinamica delle organizzazioni;  Integrare la gestione dinamica delle organizzazioni all’interno della generazione futura della piattaforma.

13

1.2 Struttura della tesi Il documento si articola nei capitoli di seguito descritti. Nel capitolo intitolato “I processi” si analizza l’evoluzione del concetto di processo partendo dal taylorismo e concludendo con il Business Process Management. Si illustreranno anche i principali standard correlati. Nel capitolo “Openwork®” si introdurrà il framework con una panoramica generale introduttiva e con degli approfondimenti circa le componenti astratte di interesse per questo lavoro di ricerca. Il capitolo “Analisi del problema” introduce il problema concreto inquadrandolo nell’ottica aziendale e della piattaforma illustrando delle possibili soluzioni. Il capitolo “Analisi dei requisiti” è il nodo centrale di questa tesi poiché contiene tutta la documentazione relativa alla formalizzazione dei diversi requisiti richiesti per la costruzione del prodotto software. Il capitolo “Specifiche dei requisiti” contiene principalmente la descrizione formale dei casi d’uso prodotti per formalizzare efficacemente il problema. Per finire, in “Conclusioni” si chiuder{ la tesi illustrando i risultati finali ed esponendo dei possibili sviluppi futuri.

14

Capitolo 2: I processi Un processo è un insieme di attività eseguite da persone e/o sistemi che, scatenate da un evento, producono un risultato di output. Un processo può essere costituito solo da attività eseguite da sistemi (processo System-To-System o S2S) o solo da attività eseguite da persone (processo Human-To-Human o H2H) o entrambi (processo Human-To-System-To-Human o H2S2H). Le attivit{ possono essere coordinate secondo regole predefinite (processo strutturato) o secondo regole che vengono definite in itinere dai partecipanti al processo (processo destrutturato). I processi strutturati si caratterizzano per un’elevata rigorosit{ della struttura, sono ben definiti, ripetitivi e guidati da schemi prefissati; tutti gli elementi necessari alla realizzazione del processo sono forniti all’operatore in forma automatizzata. Il flusso informativo è paragonabile ad una catena di montaggio. I processi destrutturati sono legati prevalentemente alla capacità di intervento dei singoli operatori che collaborano attivamente all’esecuzione del processo, decidendo di volta in volta la scelta più opportuna alla prosecuzione del normale flusso operativo. Gli elementi necessari alla realizzazione del processo possono variare e gli stessi operatori si procurano le informazioni ritenute utili allo svolgimento della propria attivit{. Il flusso informativo è paragonabile ad una invenzione. In genere un processo in cui partecipano persone è un processo parzialmente strutturato o semi-

15 strutturato. Un processo può essere costituito da diversi sottoprocessi o può avviare altri processi indipendenti. Un sottoprocesso è un processo a se stante che può essere avviato solo da un processo padre.

2.1 Storia dei processi Il concetto di processo ha cominciato ad emergere nelle realtà organizzative a partire dagli inizi degli anni 20, in linea con quanto aveva teorizzato Taylor (1), secondo il quale, il lavoro all'interno delle aziende, poteva essere ottimizzato attraverso la suddivisione delle attività di produzione, in task più elementari. Il principio alla base della suddivisone dei compiti, è ancora tuttora dominante nelle aziende, anche se la visione del processo ha assunto un ruolo più idoneo attraverso la definizione di linee guida che mirano al raggiungimento degli obiettivi di business in modo efficiente. Oggigiorno, il processo non viene più visto come una componente non automatizzabile e scindibile dall’esperienza aziendale, ma piuttosto come uno strumento attraverso il quale è possibile automatizzare il flusso delle attività in tempi nettamente inferiori, consentendo di tenere traccia della conoscenza insita nel processo stesso. Man mano che l'esigenza di gestire il flusso delle attività è prevalsa in ambito aziendale, si sono affermate nel contempo tecniche, metodologie e strumenti in grado di coordinare al meglio le attività di sviluppo di un processo. Infatti le soluzioni di Business Process Management (BPM vedi 2.1.3) stanno diventando sempre di più la chiave strategica che le organizzazioni adottano con maggiore frequenza per incrementare l'efficienza dei loro processi di business.

2.1.1 Workflow

16 Un workflow è una rappresentazione di una sequenza di operazioni, dichiarate come lavoro di una persona, lavoro di un meccanismo semplice o complesso, lavoro di un gruppo di persone (2), lavoro di uno staff organizzativo. Un workflow può essere visto come l'astrazione di un lavoro reale, un lavoro condiviso, un lavoro frazionato o lavoro con qualunque altro tipo di ordinamento. Per esaminare lo scopo, un workflow può essere la visione di un lavoro reale sotto un determinato aspetto (3), così da diventare la rappresentazione astratta di un lavoro concreto. Il workflow è un modello che rappresenta un lavoro reale per ulteriori assestamenti: per descrivere una sequenza di operazioni ripetibili in maniera affidabile. Più filosoficamente, un workflow è un modello di attività abilitato da un'organizzazione sistematica delle risorse, definisce ruoli e massa, flussi di energia e di informazione, in un processo di lavoro che può essere documentato ed appreso[3]. I workflow sono progettati per realizzare intenti processabili di qualsiasi tipo, come trasformazioni fisiche, fornitura di servizi, od elaborazione di informazione. I concetti relativi al workflow sono strettamente correlati ad altri concetti usati per descrivere la struttura organizzativa, come funzioni, squadre, progetti, politiche e gerarchie. I workflow possono essere visti come primitivi blocchi di costruzione di organizzazioni. Il termine workflow è usato nell'informatica per catturare e sviluppare l'interazione tra l'uomo e le macchine. I software di workflow puntano a fornire gli strumenti affinché l'utente finale sia in grado di orchestrare o descrivere complessi processi di dati in una forma visuale, come diagrammi di flusso, senza tuttavia richiedere all'utente competenze tecniche quali la conoscenza di linguaggi di programmazione specifici.

2.1.2 Business Process Il processo aziendale (o business process) è un insieme di attività interrelate, svolte all'interno dell'azienda, che creano valore trasformando delle risorse (input del processo) in un prodotto (output del processo) destinato ad un soggetto interno o esterno

17 all'azienda (cliente). Il processo è teso al raggiungimento di un obiettivo aziendale, determinato in sede di pianificazione. Tanto le risorse quanto il prodotto possono essere beni, servizi o informazioni oppure una combinazione di questi elementi. La trasformazione dell'input in output può essere eseguita con l'impiego di lavoro umano, di macchine o di entrambi. Un'attività è una parte di un processo che non include decisioni e che quindi non è utile scomporre ulteriormente (sebbene la scomposizione sia di per sé possibile). Le attività, quindi, possono sostanziarsi in operazioni su oggetti fisici o informativi oppure in una decisione assunta da un attore coinvolto nel processo. Un sotto-processo è una parte del processo che comprende più attività e ha propri attributi in termini di obiettivo, input e output, contribuendo però nel contempo al raggiungimento dell'obiettivo più generale del processo. Un progetto può essere visto come un particolare tipo di processo aziendale, volto al conseguimento di un obiettivo specifico in un determinato tempo e con determinate risorse, che non è la sostanziale ripetizione di processi già svolti. In un processo sono normalmente coinvolti più organi aziendali e il loro apporto è coordinato attraverso un flusso di informazioni (workflow). Il coordinamento può essere perseguito in vari modi:  formalizzando in procedure i compiti e le responsabilità degli organi aziendali che intervengono nel processo; spesso, infatti, è proprio nel punto di passaggio da una funzione aziendale ad un'altra che si verificano i maggiori punti di attrito nei processi;  attribuendo la necessaria autorità funzionale ad un'apposita figura manageriale (process manager), che ha il compito di coordinare tutto il processo nella sua interezza;  raggruppando in un'unica unità organizzativa tutti gli organi coinvolti nel processo. Questa soluzione comporta l'abbandono dei tradizionali criteri di raggruppamento basati sull'input o sull'output e, sebbene caldeggiata dalla più recente letteratura in materia di management, non ha fino ad ora riscosso molto successo nella realtà aziendale. Come si è visto, sono considerati clienti tutti coloro ai quali è destinato l'output di un processo, anche se interni all'azienda. Da questo punto di vista si distinguono:

18  i processi primari, che hanno come clienti soggetti esterni all'azienda;  i processi di supporto, che hanno come clienti soggetti interni all'azienda e che, quindi, supportano i processi primari. Un'altra classificazione dei processi è la tripartizione (4), tra:  processi direzionali (o strategici), che concorrono alla pianificazione di medio-lungo termine dell'organizzazione;  processi gestionali, che concorrono alla traduzione degli obiettivi di medio-lungo termine nella programmazione di breve termine e controllano il raggiungimento degli obiettivi;  processi operativi, che concorrono al raggiungimento degli obiettivi. I processi direzionali sono tipicamente caratterizzati da decisioni non strutturate, assunte cioè in assenza di regole predeterminate per decidere. Nei processi gestionali sono invece prevalenti le decisioni semi-strutturate, assunte in base a regole solo in parte predeterminate. Nei processi operativi, infine, la grande maggioranza delle decisioni sono strutturate, ossia assunte in base a regole completamente predeterminate. I tre tipi di processi, inoltre, sono svolti a livelli diversi della struttura aziendale: ai livelli più alti i processi direzionali, che coinvolgono prevalentemente il senior management, ai livelli intermedi quelli gestionali, che coinvolgono prevalentemente il middle management, e ai livelli più bassi quelli operativi. Nelle aziende dotate di un sistema di gestione della qualità, in accordo alla norma ISO 9001, i processi aziendali devono essere misurabili e monitorabili nel tempo mediante l'utilizzo di indicatori di prestazione chiave. Il Business Process Modeling è l'attività di rappresentazione dei processi aziendali nella situazione “as-is” e “to-be”. La mappatura dei processi reali (“as-is”) e di quelli a tendere (“to-be”) sono due attività nettamente distinte, in cui l'analisi dell'“as-is” serve a definire i miglioramenti dei processi formalizzati nel “to-be”. Manager ed analisti tendono a migliorare efficienza ed efficacia dei processi, ovvero a ridurre i costi e accrescere la qualità intesa come soddisfazione del cliente. Gli interventi nel “to-be” possono essere di tipo incrementale ed essere inclusi nell'ambito del BPM, o di tipo radicale aprendo la tematica del Business Process Reengineering, possono riguardare tecnologia e/o organizzazione.

19 Esistono software proprietari di modellazione dei processi che garantiscono un'interoperabilità fra loro e con gli standard aperti di modellazione, in modo da evitare una costosa perdita di informazione nella migrazione dei dati da un linguaggio all'altro. Tali software implementano una metodologia proprietaria, fatta di particolari oggetti e regole, che è “emebedded” nel prodotto. L'utilizzo della metodologia è legato all'acquisto di licenze del relativo prodotto. I linguaggi possono essere uno strumento di rappresentazione dei processi e supporto decisionale ai manager, ed un potente tool di “programmazione”. In questo caso, mentre il processo viene “pensato” e disegnato per via grafica, il tool genera parti del codice necessario all'automazione di processi esistenti (nell'ambito del Workflow e del Work Force Automation) o all'esecuzione del nuovo processo. Concentreremo la nostra attenzione sui principali linguaggi: Business Process for Execution Language (BPEL vedi 2.2.1), Business Process Modeling Notation (BPMN vedi 2.2.2) ed il recente XML Process Definition Language (XPDL vedi 2.2.3). Per completezza, in appendice trovate una breve descrizione di Unified Modeling Language (UML vedi A) ed eXtensible Markup Language (XML vedi B).

2.1.3 BPM Il Business process management è l'insieme di attività necessarie per definire, ottimizzare, monitorare e integrare i processi aziendali, al fine di creare un processo orientato a rendere efficiente ed efficace il business dell'azienda. Il BPM è una via intermedia fra la gestione d'impresa e l'Information Tecnology, ed è riferito a processi operativi, che interessano variabili quantitative e sono ripetuti su grandi volumi quotidianamente. Un processo del genere è adatto all'automazione, mentre i processi di carattere strategico-decisionale utilizzano la tecnologia come un supporto che difficilmente può sostituire l'attività umana. Il Business Process Management rappresenta l'insieme delle attività necessarie per gestire il ciclo di vita di un processo,

20 attraverso uno sviluppo di tipo incrementale; possiamo infatti identificare alcune fasi che, eseguite in maniera sequenziale, modellano e consentono la gestione delle attività rispetto a particolari esigenze.

Figura 2: Ciclo di vita del BPM

Si distinguono le seguenti fasi:  Progettazione: fase nella quale si da vita ad un primo modello formale di processo;  Modellazione: in cui la visione di business viene definita formalmente in processi concreti, attraverso l'analisi accurata delle attività svolte in ambito aziendale;  Esecuzione: dove i processi vengono effettivamente applicati mediante la definizione di precise regole di business in grado di garantire l'orchestrazione delle attività;  Monitoraggio: attività indispensabile per lo studio del modello prodotto e per eventuali valutazioni di diversa natura;  Ottimizzazione: fase nella quale si identificano e si implementano i miglioramenti. Il BPM differisce dal BPR (Business Process Reengineering), che toccò la sua massima diffusione negli anni 90, perché mira ad un miglioramento incrementale dei processi, mentre il secondo ad un miglioramento radicale. I software di BPM dovrebbero velocizzare e semplificare la gestione e il miglioramento dei processi aziendali. Per ottenere questi obiettivi, un software di BPM deve monitorare l'esecuzione dei processi, consentire ai manager di fare analisi e cambiare tecnologia e organizzazione sulla base di dati concreti, piuttosto che in base ad opinioni soggettive.

21 Tali operazioni sono talora svolte da software differenti che comunicano tra loro, da programmi che misurano i dati e altri che contengono la descrizione dei processi “aggiornabile" con i dati dell'operatività. I programmi che si occupano della rilevazione degli indicatori di prestazione chiave (KPI) forniscono dei resoconti sintetici sull'operatività dei processi, e consentono un dettaglio dell'indicatore che può arrivare dal globale della società al singolo operatore/macchina.

2.2 Standard Nell'ambito della definizione, modellazione, esecuzione e scambio di modelli di processo, esistono diversi standard. In questa sezione si illustreranno solo gli standard più importanti, unitamente a quelli essenziali per la comprensione del lavoro di ricerca condotto.

2.2.1 BPEL BPEL (Business Process Execution Language) è un linguaggio basato sull'XML costruito per descrivere formalmente ed eseguire l’orchestrazione tra servizi applicativi. Un'applicazione BPEL viene invocata come Web service ed interagisce con il mondo esterno esclusivamente invocando altri Web services. L'ambiente run-time all'interno del quale viene eseguito il generico processo è detto motore BPEL. Lo standard che definisce l'uso di BPEL nelle interazioni tra Web services è chiamato BPEL4WS o WS-BPEL. BPEL è nato come integrazione delle ricerche svolte da IBM e Microsoft su WSFL e XLANG, entrambi superati da BPEL. Nell'aprile del 2003 BPEL è stato sottoposto ad OASIS che lo ha standardizzato attraverso Web Services BPEL Technical Committente. Il linguaggio BPEL permette di descrivere un processo business mediante un insieme di attività, che possono essere semplici o strutturate. Le attività semplici esprimono una generica azione (ad

22 es. invoca servizio, ricevi risposta, assegna valore ad una variabile, termina processo, etc…), mentre quelle strutturate sono normalmente utilizzate per raggruppare attività semplici allo scopo di esprimere cicli, operazioni condizionali, esecuzione sequenziale, esecuzione concorrente, etc… L'intero processo è descritto mediante un'unica attività strutturata (top-level activity), generalmente di tipo sequenziale. Un tag scope racchiude l'insieme di attività che compone una transazione atomica, ovvero un processo che può terminare con un commit o un abort, senza stati intermedi, nel quale l'arresto del processo su un'attività comporta l'interruzione del processo e la cancellazione delle modifiche in scrittura al database durante le attività precedenti (undo delle attività). Questo è necessario ad esempio in una transazione bancaria/finanziaria nella quale ad ogni addebito deve corrispondere un accredito di somme. Un diagramma di workflow contiene tipicamente operazioni, messaggi, attori (umani o applicativi), applicazioni che definiscono il web-service, condizioni logiche (IF), parallelismi, cicli e task di sincronizzazione fra operazioni. BPEL è in particolare adatto a modellare workflow completamente automatizzati, per la composizione di web service, l'integrazione di servizi (e applicazioni che li eseguono) eterogenei per hardware che li esegue, architetture di rete e linguaggio del relativo codice. BPEL mette altresì a disposizione dei costrutti per esprimere le cosiddette transazioni di lungo periodo (long running transactions, LRT), che rappresentano un'estensione delle transazioni ACID al caso di processi di lunga durata mediante la nozione di compensazione delle attività eseguite. Ancora, il meccanismo della correlazione è utilizzato per tener traccia di una certa conversazione a livello business, identificando così una sorta di sessione tra più partecipanti ad una stessa istanza di processo. BPEL consente di descrivere un workflow esistente oppure un processo astratto non eseguibile, trasformando in codice di programmazione una modellazione grafica che contiene la semantica descrivibile con i costrutti di UML. Questo è particolarmente utile per far comunicare software proprietari per la modellazione dei processi, che utilizzano terminologie e icone differenti per rappresentare quanto può essere descritto con una notazione UML. BPEL permette di esportare e importare questi diagrammi in un file

23 .bpel da un database proprietario all'altro senza perdere il contenuto della rappresentazione. La “receive" di un messaggio crea un'istanza del processo; istanze del processo differenti variano per il contenuto del messaggi scambiati. Perciò, un campo del messaggio identifica univocamente l'istanza di appartenenza in modo da inviare i corretti dati a ogni istanza di processo. I messaggi sono delle “Input/Output variable” per le quali BPEL crea in automatico il tipo appropriato (stringa, testo, numero), ossia ciò che serve alla persistenza dell'informazione durante l'esecuzione del workflow; messaggi con identico contenuto informativo vengono rappresentati con un'istruzione di assegnazione che permette di associare ad una variabile il contenuto di un'altra.

Figura 3: Esempio di un processo disegnato in BPEL

2.2.2 BPMN Il Business Process Modeling Notation (BPMN) è una notazione grafica standard per il disegno di processi di business in un workflow. BPMN fu sviluppato dal Business Process Management Initiative (BPMI), ed è ora promosso dal Object Management Group. La versione corrente è la 1.1, ma vi è già una versione draft della 2.0.

24 Il primo obiettivo del BPMN è quello di consentire una notazione standard che sia immediatamente comprensibile ad ogni stakeholder. Gli stakeholder includono i business analyst che creano e migliorano i processi, i tecnici sviluppatori responsabili dell'implementazione del processo, ed i manager che monitorano e gestiscono i processi. Conseguentemente BPMN ha lo scopo di diventare il linguaggio in grado di colmare quel gap che spesso si crea tra il manager e lo sviluppatore. Attraverso l'utilizzo di BPMN ogni stakeholder può leggere il processo senza alcun tipo di perdita di informazioni. Oggigiorno, ci sono diversi linguaggi per la definizione di processi, strumenti e metodologie. L'adozione di BPMN aiuterà ad unificare l'espressione dei concetti base di un business process così come la modellazione avanzata dei concetti correlati. BPMN è vincolato ad essere un linguaggio capace di esprimere solo i concetti applicabili ai business process. Questo significa che altri tipi di concetti esulano dalle competenze di questo linguaggio, pur essendo in qualche modo legati ad essi. Per esempio, la modellazione dei seguenti concetti non fa parte del BPMN: Strutture organizzative, Guasti funzionali, Modelli di dati. Inoltre, nonostante BPMN mostri il flusso dei dati (messaggi), e le associazioni tra artefatti e attività, esso non è un data flow diagram.

Figura 4: Esempio di un processo disegnato con BPMN

25

2.2.3 XPDL Il XML Process Definition Language (XPDL) è un formato standardizzato dal Workflow Management Coalition (WfMC) per lo scambio della definizione di Business Process tra diversi prodotti di workflow, come strumenti di modellazione e motori di workflow. XPDL viene definito come uno schema XML per la specifica della parte dichiarativa di un workflow (6). XPDL è progettato per lo scambio del disegno di processo, la grafica e la semantica di workflow di un processo di business. XPDL contiene elementi che rappresentano le coordinate X,Y dei nodi di un'attività così come le coordinate dei punti lungo le linee che collegano i nodi. Questo differenzia XPDL da BPEL che è solo un formato di definizione del processo che si focalizza prevalentemente sugli aspetti di esecuzione del processo. BPEL non contiene elementi che rappresentano l'aspetto grafico di un diagramma di processo. La prima revisione di XPDL fu chiamata Workflow Process Definition Language (WPDL) e fu pubblicata nel 1998. Questo metamodello di processo conteneva tutti i concetti chiave richiesti per supportare l'automazione di un workflow espressa usando la codifica URL. Le dimostrazioni sull'interoperabilità furono effettuate per confermare la facilità di utilizzo di questo linguaggio. Dal 1998, i primi standard basati su XML cominciarono a nascere. Il Workflow Management Coalition Working Group produsse un linguaggio per la definizione del processo chiamato XML Process Definition Language (XPDL). Questa seconda revisione era un linguaggio di scambio basato su XML che conteneva molti dei concetti di WPDL, con alcuni miglioramenti. XPDL 1.0 fu ratificato dal WfMC nel 2002, e fu successivamente implementato da diversi prodotti BPM per lo scambio della definizione di processi. Ci fu un gran numero di ricerche e studi universitari sulle reali capacità di XPDL, che era essenzialmente l'unico vero linguaggio per lo scambio di disegni di processi. Il WfMC continuò ad aggiornare e migliorare il XPDL. Nel 2004 il WfMC introdusse il BPMN, un formalismo grafico per la standardizzazione del modo con cui i processi venivano visualizzati. XPDL fu esteso specificatamente con l'obiettivo di rappresentare in

26 XML tutti i concetti presenti in BPMN. Questa terza revisione è nota come XPDL 2.0 e fu ratificata dal WfMC nell'Ottobre del 2005.

27

Capitolo 3: Openwork® Openwork® è una piattaforma di Business Process Management web-based, che permette la modellazione, l'esecuzione ed il monitoraggio di processi organizzativi durante i quali documenti, informazioni e compiti vengono scambiati tra applicazioni e/o persone in una sequenza di operazioni stabilite, attraverso un insieme di regole procedurali. In generale un processo può essere definito come un insieme ordinato di attività che, secondo regole prestabilite, coinvolgendo più funzioni aziendali ed impiegando risorse di tipo diverso, risolvono un problema di business chiaramente identificato. Secondo una diffusa definizione, le piattaforme di BPM dovrebbero consentire l'orchestrazione di sistemi (anche definite System To System o S2S), ovvero lo scambio di dati secondo regole ben strutturate. Openwork® rientra in una più recente e ampia definizione di BPM che prevede l'integrazione non solo di persone, Human-To-Human o H2H, ma anche di persone e sistemi, HumanTo-System-To-Human o H2S2H. Infatti la piattaforma integra strumenti di Document Management e Workflow Management, e consente anche la gestione di processi destrutturati, legati prevalentemente alla capacità di intervento dei singoli operatori che collaborano all'esecuzione del processo. Considereremo, sia la componete di gestione documentale, Document Management, che la componente di Workflow

28 Management, ponendo inizialmente particolare attenzione alla componente documentale, in quanto l'efficienza del motore documentale è un aspetto propedeutico alla gestione e all'avanzamento dei processi stessi, in contesti ove la mole di documenti gestiti è notevole. Descriviamo brevemente il ciclo di sviluppo di una applicazione utilizzando openwork:  Si definisce l'organigramma della struttura attraverso l'Organization Designer, un tool grafico che consente di definire le aree organizzative, i ruoli e gli operatori;  Si modella il processo definendo le attività, i partecipanti alle attività e i legami logici e temporali tra le diverse attività, utilizzando lo strumento di Workflow Designer;  Si definiscono le form che “trasporteranno" dati strutturati e destrutturati tra i partecipanti al processo attraverso il Form Editor. L'aspetto innovativo della piattaforma sta nel fatto che il disegno del processo è l'applicazione software, ovvero senza effettuare altre operazioni di programmazione, gli operatori potranno creare una form di richiesta RDA e partecipare al processo secondo le regole stabilite attraverso una to-do list all’interno del browser.

3.1 Document Management Un sistema di Document Management è composto fondamentalmente da una repository di documenti o file e da un database per la memorizzazione di metadati. Esso è in grado di gestire sia dati strutturati (gli indici) che dati destrutturati; in particolare bisogna specificare che i file e gli indici sono associati tra di loro. I file possono essere classificati, ovvero caratterizzati in base alla loro tipologia (una fattura, una RDA, un reclamo, etc. . . ). In openwork® gli indici vengono renderizzati in HTML all'interno del browser, in una form, e modificati tramite funzioni javascript invocate dall’interfaccia utente secondo delle regole dipendenti dalla tipologia del metadato e dalla tipologia di documento. L'insieme di tali regole costituisce un modello.

29 Il Repository Documentale è un file-system che può risiedere su qualsiasi piattaforma; l'Application Server vi accede tramite FTP o NETBIOS, ma potrebbe anche essere costituito da un sistema dedicato di Document Management esterno ad openwork. Il database è di tipo RDBMS gestito dal motore Microsoft SQL Server oppure Oracle. Il repository si distingue da un documentale classico per l'associazione uno a molti tra file e dati di indicizzazione; infatti ad uno stesso record possono essere associati più file opportunamente indicizzati. La logica applicativa è distribuita tra client e web service, per cui possiamo considerare l'architettura web di tipo thick client:  Il codice di rendering e d'interazione utente con i dati è all'interno di template XSL e di codice Javascript sul client che vengono scaricati automaticamente dal browser;  Le logiche di gestione del ciclo di vita e di accesso ai documenti risiedono sull'application server che espone una interfaccia di tipo web service. Il web server esegue solo il caching dei modelli di documento, e gestisce la sessione utente, che per definizione, non è gestita dai web service. L'application server è realizzato su piattaforma .NET, il Web Server in .NET o Apache. Quando viene inoltrata una richiesta (ovvero dei dati di indicizzazione di un file) di una form dal client al server, esso interpreta questa richiesta e lo inoltra ai Web Services ottenendo in risposta una struttura XML che viene rinviata al client con l'indicazione della trasformazione XSL da utilizzare per renderizzare in HTML i dati. Si verifica, pertanto, una opportuna trasformazione dell’XSL in Formatting Object (FO) lato server, e il documento FO ottenuto viene avviato a un FO processor che lo trasformerà in PDF. Il documento in formato PDF verrà inviato al client come stream di dati.

3.2 Workflow Management All'interno di un processo possono essere creati e archiviati documenti e valorizzati i loro indici, secondo delle regole specifiche della applicazione di business che si vuole gestire. Queste regole vengono modellate graficamente in un modello di processo.

30 La creazione di un documento (come una Richiesta di Acquisto) può scatenare l'avvio di un processo: secondo il paradigma di openwork, dal modello di processo ne viene creata un'istanza (ovvero la medesima rappresentazione grafica); questa istanza viene interpretata dal Workflow Engine che è in grado di risolvere le regole logiche e temporali con cui distribuire ai vari partecipanti le attività. Il Workflow Engine, in sintesi, garantisce che, a fronte delle molteplici procedure esistenti, le attività vengano assegnate agli operatori in maniera opportuna ed al momento giusto. Oltre a garantire l'esatta distribuzione delle attività attraverso l’avanzamento del processo in base agli eventi generati, openwork® garantisce la capacità di verificare la correttezza del processo, il suo monitoraggio, la gestione delle eccezioni e la gestione delle modifiche.

3.3 Architettura L' architettura si basa su alcuni paradigmi illustrati di seguito: Component-based: openwork® permette di modellare e gestire i processi, combinando gli oggetti secondo la logica della realtà quotidiana delle organizzazioni. Il disegno e l' implementazione delle componenti che costituiscono e partecipano all'attività (processi, sottoprocessi, documenti, operatori, ruoli, eventi, etc.) permette alla piattaforma di "vestirsi" sull'organizzazione e soprattutto di implementare le attuali procedure. Service Oriented: L’architettura di tipo SOA e l’utilizzo dei Web Services garantisce alla piattaforma grande scalabilità, robustezza e affidabilità; è difatti possibile interfacciare l'applicazione via HTTP per mezzo di chiamate ai servizi esposti, che possono avvenire da sistemi prodotti e/o che utilizzano linguaggi differenti. Multi-tier: La suddivisione dell’applicazione in 4 livelli permette di adattare facilmente l’architettura dell’applicazione all’architettura fisica e garantisce una facile gestione dei carichi di lavoro e delle situazioni di failover. Compliant con i più diffusi standard: L’ utilizzo di tecnologie quali HTML, SOAP, WSDL, XML, XPATH, XSL, XSD, XSL-FO, CSS,

31 javascript, garantisce l'apertura dell’applicazione e agevola l’estensione delle sue funzionalità. Integrabile: Le interfacce standard, come Web Services e DCOM, e la presenza di entry point cui agganciare codice custom sia lato client, sia lato server, rendono possibile l’ integrazione, per mezzo di logiche di workflow, di altre applicazioni già presenti nell’organizzazione. Stepwise implementation: La presenza di strumenti di modellazione evoluti permette l’implementazione graduale di soluzioni all’ interno di un’ organizzazione, in modo da minimizzare i rischi e facilitare sensibilmente il change-management. Scalabile: La piattaforma è costituita da diverse componenti e permette la scalabilità e la distribuzione delle stesse su diversi sistemi: openwork® business components, openwork® manager, openwork® job engine, applicazioni web, database, repository documentale, componenti aggiuntive e Business Process Management Tools (BPM Tools®).

Figura 5: Architettura del framework openwork®

Le openwork® business components, l'openwork® manager e openwork® job engine formano il core della piattaforma denominata: openwork® engine.

32 Tutti i moduli possono essere configurati in differenti modalità a seconda dell'architettura prescelta e dei requisiti di performance, ridondanza e sicurezza richiesti al sistema. Ogni singolo modulo può essere installato su un solo server o scalato su più server e presenta caratteristiche di scalabilità derivanti dalla particolare tecnologia software utilizzata: i componenti possono essere installati su un array di server, vi possono essere più web server che utilizzano gli stessi componenti, etc. Poiché il sistema nel suo complesso (configurazione e dati) è costituito da uno o più database relazionali e da un insieme di file, esso è compatibile con le più diffuse soluzioni di backup, protezione dati e monitoraggio disponibili sul mercato. È possibile configurare i diversi moduli in modo da gestire con un unico engine, database diversi e repository diversi ovvero organizzazioni diverse. Tale configurazione prende il nome di modalità ASP. Non si pretende in questo documento di coprire tutti gli aspetti del framework, per questa ragione di seguito si approfondiranno esclusivamente gli aspetti coinvolti nel lavoro di ricerca.

3.3.1 BPM Tools®

Una delle principali componenti del framework openwork® è il BPM Tools®. È un’applicazione proprietaria Windows che mette a disposizione degli utilizzatori di openwork® un insieme di strumenti grafici attraverso i quali costruire applicazioni di BPM web-based. I principali strumenti dell'openwork® Business Process Management Tools sono:  Organization Designer per la gestione dell’organigramma / funzionigramma;  Form Editor per il disegno del layout delle form;  Business Flow Designer per la modellazione dei processi che si intendono gestire.

33 L'utilizzo del BPM Tools® favorisce la costruzione di applicazioni che fanno riferimento al “linguaggio” ed ai contenuti dell’organizzazione aziendale, in modo da rendere il più naturale possibile la traduzione delle operazioni in una forma processabile a livello informatico. Gli strumenti di classificazione e numerazione documentale sono strutturati sulla base di archivi totalmente associabili agli archivi cartacei usuali e si conformano anche alle normative che regolano il protocollo informatico. I processi vengono configurati mediante appositi diagrammi di flusso in cui è possibile rappresentare un’ampia gamma di attivit{ (semilavorati) che richiamano le usuali mansioni di gestione documentale ed operativa. L'organigramma degli operatori di sistema è composto da aree organizzative, gruppi di lavoro e ruoli che in generale rispecchiano la reale organizzazione aziendale, in altri casi invece è necessario adattare l'organigramma alle esigenze del processo. Un’interfaccia grafica particolarmente intuitiva e user-friendly consente di velocizzare i tempi del design-time: inoltre, conformemente alla flessibilità che contraddistingue la piattaforma, le mutue relazioni tra documentazione, flusso operativo ed organico delle risorse vengono gestite autonomamente in maniera dinamica e coerente. Questo rende openwork® BPM Tools® non solo il principale strumento per configurare il sistema, ma anche un valido supporto per l’analisi ed il re-engineering organizzativo.

Figura 6: Architettura del BPM Tools®

34

3.3.1.1 Organization Designer L'organizzazione è l'insieme di operatori, ruoli, unità organizzative che concorrono alla gestione delle informazioni e all'avanzamento dei processi. Attraverso l’Organization Designer è possibile definire relazioni gerarchiche tra i vari elementi dell'organizzazione, ovvero definire l'organigramma. E' possibile raggruppare i diversi elementi dell'organizzazione in base a competenze, abilità, autorizzazioni specifiche, ovvero definire gruppi o insiemi di operatori, ruoli e unità organizzative. Combinando elementi dell’organigramma e gruppi è possibile definire regole organizzative (formule) che dipendono da come un operatore è posizionato nella gerarchia (ruolo) e/o dalla sua appartenenza a un determinato gruppo (regole a matrice). I risultati delle formule possono essere utilizzati da altre applicazioni per la risoluzione di autorizzazioni oppure per stabilire l’accesso alle informazioni e assegnare le attivit{ all’interno della piattaforma openwork®. Un operatore è identificato da un individuo (o risorsa) interno all'organizzazione aziendale e definito nell'anagrafica degli operatori; ad ogni operatore possono essere assegnati uno o più ruoli.

3.3.1.2 Form Designer Con il Form Designer è possibile disegnare form per la rappresentazione dei dati utilizzando, oltre ad oggetti standard web (controlli standard HTML) anche una collezione completa di controlli openwork® che permettono di creare facilmente interfacce evolute per la gestione dei dati nell’ambito dei processi di un’organizzazione.

3.3.1.3 Business Flow Designer Il Business Flow Designer fornisce strumenti grafici con i quali è possibile definire la sequenza logica e temporale di attività,

35 stabilendo chi può fare cosa, come, con quali documenti, autorizzazioni, etc. Il Business Flow Designer integra un ambiente di programmazione in linguaggio VB Script con il quale è possibile far eseguire, dal motore di workflow, codice custom (lato server) al verificarsi di determinati eventi (avvio, esecuzione o completamento di un’attivit{, etc.) o condizionare il completamento di un’attivit{ al verificarsi di determinate condizioni. Questa funzionalità, unitamente alle API di openwork®, permette di interagire con applicazioni esterne, realizzando un'unica infrastruttura di workflow.

3.3.2 Web Client L’applicazione Web è costituita da una applicazione lato server e da librerie lato client in XSL, Java Script e CSS (thick client). L’applicazione Web lato server è una delle possibili applicazioni client basate sui Web Services di openwork®. L' architettura segue rigorosamente il principio della separazione tra dati e presentazione; il flusso di seguito descritto semplifica quello che normalmente accade quando il client inoltra una richiesta al Web Server:  Il client richiede al Web Server l’apertura di una form;  Il Web Server chiede ad un opportuno Web Service i dati con cui la form deve essere riempita per mezzo di una chiamata SOAP;  Il Web Service restituisce i dati al Web Server;  Nei dati è presente il riferimento a un foglio di stile in cui sono codificate le regole per la rappresentazione dei dati richiesti (tali regole vengono definite tramite openwork® BPM Tools® durante la modellazione del processo e delle form in esso coinvolte); il Web Server verifica se il foglio di stile è presente nella directory dell’applicazione e, qualora non lo fosse, lo richiede tramite chiamata ad altro Web Service;  Il Web Server invia al client i dati e il foglio di stile, che vengono presentati sotto-forma di pagina web nel browser.

36 Nel momento in cui si effettuano delle modifiche nella form e queste vengono salvate, il percorso è il seguente:  Il client invia al Web Server un messaggio SOAP contenente i dati modificati unitamente ad eventuali allegati in formato DIME da salvare nel repository documentale.  Il Web Server provvede a instradarli, tramite ws-addressing e ws-referral, al Web Service.  I dati indicizzati (contenuti nei vari campi della form) vengono memorizzati nel database, gli eventuali allegati vengono memorizzati nel repository. Quando il client richiede la stampa di una form o di un elenco, viene invece eseguita una trasformazione lato server con l' utilizzo di Formatting Objects per la produzione di documenti in formato PDF secondo regole definite con openwork® BPM Tools®. Tramite il meccanismo delle trasformazioni è possibile convertire i documenti di openwork® in diversi altri formati come Microsoft Word® o Microsoft Excel® (cfr. openwork® Export). L’applicazione web lato server è attualmente realizzata in tecnologia Microsoft .NET per server Microsoft IIS versione 5 o successiva. È inoltre possibile, con estrema facilità, estendere i moduli Java Script lato client con codice custom ed anche modificare, attraverso fogli di stile, il layout grafico dell'applicazione. La disposizione delle directory sul Web Server è studiata in modo da separare i moduli proprietari da eventuali personalizzazioni (CSS, codice Java Script, etc.) per semplificare le operazioni di manutenzione dell’applicazione. Il protocollo utilizzato nelle comunicazioni può essere HTTP o HTTPS. Possono essere installati diversi Web Server sulla stessa Application che espongono anche politiche di autenticazione diverse; i web server comunicano con i web service tramite HTTP o HTTPS e possono essere impostati meccanismi di Load Balancing come NLB. È possibile quindi multi-istanziare sia l' interfaccia applicativa (Web Services), sia il motore (in modalità separazione di carico).

37

Capitolo 4: Analisi del problema “Un’idea, un concetto, un’idea finché resta un’idea è soltanto un’astrazione” Giorgio Gaber Si introduce, con questo capitolo, il problema aziendale oggetto di questa tesi. Quello che segue è un documento che presenta diversi scenari e soluzioni assieme ad una discussione delle scelte adoperate considerando i diversi fattori critici: costo, tempo, benefici, numero di risorse impiegate.

4.1 Modello di processo La piattaforma openwork® adotta, come standard per il disegno di modelli di processo, il BPMN (7). Per questa ragione, un modello di processo altro non è che l’insieme di oggetti di flusso (flow objects), oggetti di connessione (connecting objects), artefatti (artifacts) e corsie (swimlanes). Per disegnare un nuovo modello di processo, la piattaforma openwork®, mette a disposizione lo strumento Business Flow Designer.

38 L’utente modellatore, utilizzando una apposita palette di strumenti, disegna graficamente un modello di processo arricchendolo delle opportune informazioni correlate (alle attività assocer{ gli opportuni partecipanti) e salvandolo. Quello che l’utente salva è l’insieme di tutte le informazioni necessarie a mantenere consistente il modello di processo: quando l’utente decide di caricare un modello di processo precedentemente salvato, la piattaforma deve essere in grado di visualizzarlo così come era sto costruito dall’utente modellatore. Nella nuova generazione di openwork® viene enfatizzata la dicotomia esistente tra le tipologie di informazioni, quali: 1 Informazioni che servono e sono inserite a design-time (es. posizione di un nodo grafico). 2 Informazioni inserite a design-time che servono a run-time (es. URL di un servizio web da consumare). 3 Informazioni inserite a design-time che possono essere modificate a run-time (es. descrizione di un’attivit{). 4 Informazioni di istanza (es. stato di una attività). Dalla diversa natura di tali informazioni si definiscono le seguenti entità:  Process Model: modello di processo contenente tutte quelle informazioni inserite a design-time, dalle proprietà di un nodo grafico ad informazioni di esecuzione.  Executable Model: modello di processo eseguibile. Contiene tutte quelle informazioni necessarie all’esecuzione di un modello di processo (per esempio le informazioni di disegno non sono necessarie alla esecuzione e quindi non saranno contenute). Tale modello sarà istanziato per essere eseguito. Un Executable Model è infatti una sorta di modello di processo compilato.  Process Instance: modello eseguibile istanziato. Ai parametri formali caratterizzanti il modello di processo vengono sostituiti quelli attuali. La suddetta divisione ha come fine ultimo il miglioramento delle performance relative all’esecuzione dei processi. Il modello descritto imita quello dei linguaggi di programmazione object-oriented e sarà parte integrante della nuova generazione di openwork®.

39

4.2 Organizzazione openwork® consente di definire il concetto di partecipante in molteplici modi. In particolare esso introduce una lista di tipologie di elementi dell’organizzazione ognuno con una semantica ben precisa. La piattaforma, nella sua versione attuale, mette a disposizione dell’utente responsabile della gestione dell’organigramma i seguenti elementi:  Unità Organizzativa: Questa componente corrisponde ad un’area o divisione aziendale (es. Area Marketing). Essa può contenere a sua volta delle altre Aree Organizzative o dei Ruoli oppure entrambe le cose;  Ruolo: Rappresenta la figura professionale e può essere inserita solo in un’Area Organizzativa (es. responsabile, direttore, sviluppatore, operaio). Ogni Ruolo può contenere a sua volta solo elementi di tipo Operatore;  Operatore: Questa componente indica la persona fisica (es. Mario Rossi) che ricopre un Ruolo in una Unità Organizzativa;  Gruppo: È un contenitore di tutti i precedenti elementi descritti. Il problema fondamentale di questa suddivisione è la natura statica di ogni entità organizzativa. L’organizzazione viene rappresentata da un albero n-ario avente per radice un nodo fittizio: l’azienda. L’utilizzo di questo tipo di struttura conferisce un indubbio beneficio in termini di lettura della organizzazione, a scapito, tuttavia, della flessibilità della struttura stessa. In una organizzazione estremamente dinamica, sovente capita che un operatore (persona fisica) rivesta più ruoli anche in differenti unità organizzative. Con la struttura ad albero per adempiere a questa incombenza è necessario introdurre ridondanza informativa. In definitiva, la struttura ad albero rivela tutta la sua rigidità in contesti aziendali dinamici come le Banche, le Holding etc… Il problema della rigidità si riflette direttamente nel disegno di un modello di processo, poiché nell’associare le singole attivit{ ad un entit{ organizzativa, l’utente modellatore potr{ incorrere più facilmente in errore a causa dell’eccessiva ridondanza informativa.

40 Egli potrebbe non essere in grado di cogliere la giusta differenza tra i diversi tipi di entit{ organizzative da coinvolgere per l’esecuzione di un’attivit{.

4.3 Cos’è un gruppo dinamico Prima di introdurre la definizione di Gruppo Dinamico è doveroso illustrare l’assunto teorico di partenza. Nella realizzazione di questo sistema si è assunto che l’atto di assegnazione di una qualsivoglia attività ad una persona (o un gruppo di persone) avviene sulla base delle capacità e competenze di quella persona (o gruppo di persone). Quando un manager assegna l’attivit{ X all’operatore Y, implicitamente sta analizzando le capacità di Y per capire se è in grado di eseguire l’attivit{ X. Se l’assegnazione viene effettuata significa che il manager ritiene l’operatore Y capace di eseguire l’attivit{ X. Un gruppo dinamico è un particolare contenitore di entità organizzative eterogenee. Esso corrisponde ad una regola formale. Tutte le entit{ organizzative che sono contenute all’interno di un particolare gruppo dinamico devono soddisfare la regola formale. Una regola formale è una espressione che utilizza gli operatori logici, aritmetici e di confronto per la concatenazione di condizioni, espresse sulle caratteristiche informative di ciascun entità organizzativa (gli operandi). All’utente (che utilizza il Business Flow Designer) deve essere data la possibilit{ di associare ad un’attivit{ di un modello di processo, un gruppo dinamico. In particolare, l’utente potr{ esprimere la volont{ di assegnare una particolare attivit{ ad “un partecipante che soddisfi determinate caratteristiche”; vale a dire “un partecipante che osservi una precisa regola”; in altri termini “un gruppo dinamico”. Quando l’utente disegner{, utilizzando il Business Flow Designer, un’attivit{ (in un modello di processo) potr{ scegliere di associare ad essa una delle formule già inserite, oppure definirne una nuova ad hoc. A questo scopo, sar{ messo a disposizione dell’utente modellatore, un repository di formule. Il repository conterrà tutte le formule in precedenza inserite in tutti i modelli di processo. Nel caso in cui l’utente modellatore abbia la necessit{ di esprimere una nuova

41 espressione, egli potr{ farlo utilizzando l’apposita interfaccia guidata di creazione di una nuova espressione. L’utente (che utilizza il Business Flow Designer) potrà modificare la definizione di un gruppo dinamico. In questo caso all’utente verr{ chiesto se sovrascrivere le modifiche sullo stesso modello di processo oppure creare un nuovo modello di processo. Questa scelta trova il suo fondamento, nel fatto che “cambiare i partecipanti assegnati ad un’attivit{”, concettualmente significa stravolgere la semantica del modello di processo. Il modello di processo, su qualsiasi piattaforma venga disegnato, conterrà la definizione dei gruppi dinamici coinvolti. Ogni piattaforma mette a disposizione una serie di informazioni che possono essere utilizzate (sulle entità organizzative) nella definizione di una espressione di gruppo dinamico. A tal proposito non è detto che la definizione di un gruppo dinamico in un modello di processo importato (da qualsivoglia piattaforma) possa essere valido nella piattaforma ospite. All’atto dell’importazione il modello di processo viene importato senza alcun controllo sulla correttezza del gruppo dinamico. Questo perché l’importazione di un modello di processo ha come fine ultimo la visualizzazione del processo e non la sua esecuzione. La volontà di eseguire un processo (modello di) si palesa nel momento in cui l’utente decide di pubblicarlo. Prima della pubblicazione effettiva, il sistema controllerà la correttezza formale dell’espressione che rappresenta il gruppo dinamico e potranno presentarsi i seguenti scenari:  Il sistema (Application Server) controlla l’espressione e restituisce esito positivo. Il sistema pubblica il processo correttamente.  Il sistema (Application Server) controlla l’espressione e restituisce esito negativo poiché essa contiene degli errori. Il sistema comunica la sospensione della pubblicazione imputandola ad un errore nella espressione e non pubblicando il processo. Condizione necessaria e sufficiente, affinché un modello di processo (che coinvolge un gruppo dinamico) possa essere pubblicato regolarmente, è che il modello di processo sia consistente. Tutte le informazioni che servono al modello di

42 processo per la sua pubblicazione devono essere disponibili; pena: la mancata pubblicazione dello stesso. Nel caso in cui sia rilevato un errore, l’utente dovr{ essere guidato nell’associazione dei partecipanti alle attivit{, attraverso un wizard che permetta di reimpostare i punti errati di definizione, in base alle entità organizzative ed alla lista di informazioni utilizzabili su ciascun entità organizzativa presente sulla piattaforma di destinazione. A discrezione dell’utente, le regole di associazione devono essere disponibili anche nell’importazione dei successivi processi. Dovrà essere possibile salvare le scelte intraprese per una singola importazione ed applicarle ad una successiva importazione. Altri esempi di definizione dei gruppi basati sulle caratteristiche dei partecipanti sono specificati nel documento (8) in cui un partecipante associato ad un’attivit{ è concepito come risorsa.

Gruppo dinamico in un Process Model Il Process Model dovrà contenere tutte le informazioni necessarie per eseguire ma anche manipolare un gruppo dinamico. In particolare è necessario che un Process Model contenga il nome del gruppo, una descrizione testuale e l’espressione che lo definisce (formalizzata in XML).

Gruppo dinamico in un Executable Model L’Executable Model conterrà le stesse informazioni del Process Model, tuttavia l’espressione contenuta in questo modello non sar{ formalizzata in XML ma convertita nel formalismo utilizzato dal processore di espressioni della generazione futura di openwork®.

Gruppo dinamico in una Process Instance L’unica informazione circa il gruppo dinamico che deve essere disponibile in una Process Instance è l’espressione che definisce il gruppo. Tuttavia questa informazione deve poter essere ereditata dall’Executable Model. Se così non fosse mentre la definizione del gruppo cambia, tutti le attività che hanno come partecipante quel gruppo, continuerebbero ad essere assegnate ad un gruppo

43 sbagliato. Ereditando l’informazione direttamente dall’Executable Model, si garantisce l’aggiornamento continuo.

4.4 Espressioni Il cuore di un gruppo dinamico è la regola formale che esprime le qualità che ogni singola entità organizzativa deve avere per poter far parte del gruppo. L’espressione è una componente estremamente complessa e per questa ragione risulterebbe estremamente oneroso in termini di costo e tempo, costruire un expression engine appositamente per questo scopo. L’azienda si riserva la possibilit{ di “trattare” le espressioni utilizzando un framework apposito di terzi. La sua scelta è stata un punto cruciale di questo lavoro di tesi. Molte erano le alternative che si profilavano. Nello scegliere il framework migliore si è tenuto conto dei costi di acquisto, di integrazione, del supporto tecnico, della generalità e soprattutto delle potenzialità future. Alla fine la scelta è ricaduta su Spring.NET Framework.

Spring.NET Framework Spring.NET fornisce un support infrastrutturale per lo sviluppo di applicazioni enterprise .NET. Esso consente di eliminare la complessità tipica nell’utilizzo delle librerie di classi base di un linguaggio, fornendo delle regole di buon utilizzo, come lo sviluppo guidato dal test. Spring.NET è stato creato, supportato e sostenuto da SpringSource. Il modello di Spring.NET è basato sulla versione Java di Spring Framework, che ha dimostrato reali benefici ed è utilizzato in centinaia di applicazioni di impresa in tutto il mondo. Spring .NET non è un semplice port dalla versione Java, ma più uno 'spiritual port' (come lo definiscono gli autori stessi) basato su comprovati pattern architetturali e progettuali che non sono legati a nessuna piattaforma particolare. Il cuore delle funzionalità in Spring .NET abbravvia diversi livelli applicativi che consentono allo sviluppatore di trattarlo come un

44 blocco unico, ma ciò non è richiesto. Spring .NET non è una soluzione “tutto-o-niente”. Lo sviluppatore può usare le funzionalità nei suoi moduli independentemente. Spring.NET consiste dei seguenti moduli:  Spring.Core;  Spring.Aop;  Spring.Data;  Spring.Data.NHibernate;  Spring.Web;  Spring.Web.Extensions;  Spring.Services;  Spring.Testing.NUnit; Il modulo Spring.Core include ulteriori funzionalità aggiuntive:  Expression Language – fornisce uno strumento di interrogazione e manipolazione di grafi di oggetti efficiente ed a run-time;  Validation Framework – una robusto framework per la creazione di complesse regole di validazione per oggetti di business sia programmaticamente che dichiarativamente;  Data binding Framework – un frameworka per portare a termine il legame tra dati.  Dynamic Reflection – fornisce delle API estremamente performanti per la reflection.  Threading - fornisce astrazioni concorrenti addizionali come Latch, Semaphore e Thread Local Storage.  Resource abstraction – fornisce una interfaccia commune per il trattamento di InputStream da un file e da un URL in maniera polimorfica ed indipendente da protocollo.

4.5 Riflessioni Valutazione dell’espressione In generale la valutazione dell’espressione di un gruppo dinamico va fatta in late binding (il più tardi possibile) per evitare che un’attivit{ venga assegnata ad un insieme di partecipanti attivi che non soddisfa più le condizioni del gruppo dinamico. Più

45 specificatamente, la collezione di partecipanti (potenziali o reali) deve essere risolta all’atto dell’esecuzione di una attività e modificabile all’intervento dell’Amministratore.

Figura 7: Eventi per un'attività openwork®

Nella Fig. 7 sono indicati gli eventi di un’attivit{ nei quali è possibile intervenire. L’evento ultimo nel quale poter intervenire utilmente al fine di valutare l’espressione di un gruppo dinamico è l’After Activate, poiché nella fase di After Booking è già stata assegnata l’attivit{ ad un insieme di partecipanti attivi. Il problema della scelta, tuttavia, non è risolvibile in questo modo. Un’attivit{ può rimanere in stato di prenotazione anche per tempi lunghi (a volte anche per mesi!). In questi casi il sistema prenoterebbe l’attivit{ ad una serie di partecipanti attivi che in quel momento soddisfano il gruppo dinamico. Dopodiché l’attivit{ rimane in prenotazione per N mesi. Dopo questo lungo periodo, un partecipante attivo prende in carico l’attivit{ e la esegue e successivamente la completa. Dopo N mesi non è detto che quel partecipante attivo che la prende in carico soddisfi ancora i requisiti del gruppo dinamico. Una possibile soluzione consiste nel valutare l’espressione del gruppo dinamico nel momento in cui il singolo partecipante attivo richiede la propria To-Do List al Web Server. In questo caso il sistema dovrà preoccuparsi di estrarre il sottoinsieme delle istanze di processo attive che coinvolgono gruppi dinamici. Di questi estrarre il sottoinsieme di quelle istanze di processo che hanno attività in fase di After Activate che coinvolgono gruppi dinamici. Valutare ogni gruppo dinamico e verificare che il partecipante attivo “richiedente” non sia coinvolto in una di quelle attività.

46 Malgrado si vada ad appesantire il carico computazione, questa risulta essere l’unica soluzione ragionevole per garantire che la coerenza di ogni singolo gruppo dinamico.

Eliminazione di un gruppo dinamico L’eliminazione di un gruppo dinamico non è consentita. L’unica eliminazione possibile è quella relativa all’associazione tra attivit{ e gruppo dinamico. L’utente modellatore ha la possibilit{ di disassociare un’attivit{ da un particolare gruppo dinamico ed associarlo con un altro o nessuno. Quantunque ciò avvenisse, tutte le attività modificate si aggiornerebbero in automatico senza alcun problema. In nessun modo l’utente modellatore ha facolt{ di cancellare un gruppo dinamico dal repository della piattaforma.

Gruppo dinamico privo di elementi Può succedere che la definizione di un gruppo dinamico non contenga effettivamente alcun’entità organizzativa. Questo accade, ad esempio, quando nessun’entit{ risponde alle caratteristiche descritte in fase di definizione del gruppo. In questo caso, essendo il gruppo “dinamico”, non ci sono problemi. L’attivit{ che ha come partecipante quel gruppo, non sarà eseguita da nessuno e rimarrà in attesa di un partecipante attivo in eterno a meno che durante l’attesa qualche entità organizzativa soddisfi i requisiti del gruppo dinamico o l’amministratore del processo modifichi l’istanza di processo. In questo caso, si nota subito, l’importanza che la definizione di gruppo dinamico venga risolta il più tardi possibile: in late-binding.

Cambiamento del set di attributi utilizzabili Cambiare l’insieme di attributi utilizzabili all’interno di una piattaforma openwork® significa aggiungere e/o rimuovere uno o più attributi dalla lista di quelli consentiti. Questo tipo di operazione impatta, inevitabilmente, sul meccanismo di valutazione dell’espressione dei gruppi dinamici. Se in un dato momento, cambiassimo il set di attributi, le ripercussioni potrebbero essere:

47  La definizione di taluni gruppi dinamici diverrebbe sintatticamente errata (negli attributi o negli operatori), generando errori. Si potrebbe rilanciare il controllo di correttezza formale per ogni gruppo dinamico, dopo la modifica del set di attributi.  La definizione di taluni gruppi dinamici rimarrebbe sintatticamente valida. Non verrebbero generati errori.

48

Capitolo 5: Analisi dei requisiti Dopo aver analizzato a fondo la problematica in maniera astratta con uno studio di fattibilit{, si passa ora all’analisi dei requisiti. Obiettivo di questo documento è quello di identificare e descrivere i requisiti, ossia le caratteristiche del sistema. In questo documento è opportuno cogliere le esigenze del committente senza ignorare quelle del progettista. Il documento deve essere facilmente comprensibile, preciso, completo coerente e non ambiguo inoltre facilmente modificabile. La caratteristica di questo documento è il suo duplice indirizzo. L’analisi dei requisiti di solito viene sottoposta all’approvazione del committente e successivamente consegnato al progettista per avviare la fase di progettazione software. Nel caso specifico, la problematica analizzata è talmente innovativa e priva di riferimenti esterni che è stato necessario rielaborare il documento più volte del previsto. Quello che trovate di seguito, è pertanto, il documento finale frutto di numerose iterazioni revisionali. Il modello documentale utilizzato per la redazione dell’analisi dei requisiti è il frutto di una fusione tra il modello accademico e gli standard interni della Net Sistemi srl. Tutti i codici presenti nel documento trovano una loro precisa semantica negli standard aziendali.

49

5.1 Requisiti Di seguito si espongono i diversi requisiti che la futura applicazione software deve osservare. Concordemente agli standard aziendali, i requisiti sono stati classificati in nove diverse categorie:  Requisiti Funzionali: Descrivono le funzionalità ed i servizi offerti dal prodotto software;  Requisiti Informativi: Descrivono le informazioni che il prodotto software deve essere in grado di gestire;  Requisiti di Interfaccia: Descrivono le caratteristiche richieste per la realizzazione delle interfacce utente;  Requisiti di Manutenzione: Descrivono eventuali vincoli di manutenzione da segnalare immediatamente in fase di analisi;  Requisiti di Prestazione: Descrivono alcuni vincoli sulla definizione del sistema software che impattano sulle prestazioni dello stesso;  Requisiti di Piattaforma: Descrivono eventuali accorgimenti, evidenziabili già in fase di analisi, derivanti dall’utilizzo di una particolare piattaforma;  Requisiti di Sicurezza: Descrivono i vincoli relativi alla sicurezza del futuro sistema software;  Requisiti di Integrazione: Descrivono i vincoli che dovrebbero poter essere imposti in fase di integrazione del prodotto software con un sistema software.  Requisiti Tecnici: Descrivono eventuali altri requisiti.

Funzionali [FUN]

OWK-FUN-0001

OWK-FUN-0002

Creare Gruppi Dinamici L’utente (utilizzatore di BPM Tools®) avrà la possibilità di creare nuovi gruppi detti “gruppi dinamici” specificando nome, descrizione ed un insieme di condizioni (attributo-operatorevalore). Le condizioni devono essere composte con operatori logici AND e OR. Il set di attributi utilizzabili può cambiare nel tempo. Eliminare Gruppo Dinamico Il server, allo scatenarsi di un particolare evento (ad es. la

50

OWK-FUN-0003

OWK-FUN-0004

OWK-FUN-0005

OWK-FUN-0006

OWK-FUN-0007

pubblicazione di un processo) provvederà ad eliminare i gruppi dinamici inutilizzati. Associare Gruppo ad un’Attività L’utente (utilizzatore di BPM Tools®) avrà la possibilità di associare ad un gruppo dinamico precedentemente creato un’attivit{. Visualizzare Elenco Gruppi Dinamici L’utente (utilizzatore di BPM Tools®) avrà la possibilità di visualizzare l’elenco di tutti i gruppi dinamici definiti. Modificare Gruppo Dinamico L’utente (utilizzatore di BPM Tools®) avrà la possibilità di modificare i gruppi dinamici precedentemente inseriti. L’utente potrà modificare nome, descrizione ed espressione. Per “modifica della espressione” si intende la cancellazione, e la modifica di ogni singola condizione e l’inserimento di nuove condizioni. Controllo formale di correttezza Prima della pubblicazione, il Server deve essere in grado di controllare la correttezza della definizione di un gruppo dinamico. Un gruppo dinamico si dirà corretto quando gli operatori logici saranno ben bilanciati e quando tutti gli attributi coinvolti saranno validi per la piattaforma in uso. Un attributo si dirà valido rispetto alla piattaforma, quando il suo uso è ammesso in quella piattaforma. Richiedere informazioni sulle attività che coinvolgono l’utente nei gruppi dinamici L’utente (utilizzatore dell’interfaccia Web Client) all’atto della richiesta di accesso al sistema, dovrà poter conoscere quali sono le attività in carico (da svolgere) che lo coinvolgono in un gruppo dinamico.

Informativi [INF]

OWK-INF-0001

OWK-INF-0002

Gruppo Dinamico È la rappresentazione di tutte le informazioni che caratterizzano il gruppo dinamico. STRUTTURA: - identificativo, nome, descrizione, espressione; RELAZIONI: - Attività(1 .. 1) Attività È l’insieme delle informazioni che caratterizzano una singola attività. STRUTTURA: - identificativo, … RELAZIONI: - Attività (1 .. )

51

Interfaccia [IFC] OWK-IFC-0001 OWK-IFC-0002

OWK-IFC-0003

Gruppi Dinamici L’interfaccia per la gestione dei Gruppi Dinamici deve essere integrata nel Business Flow Designer. HCI Guidelines L’interfaccia dovr{ essere compatibile con gli standard di HCI. Binding Attività-Gruppo Dinamico L’interfaccia utente per l’assegnazione di un’attivit{ ad un gruppo di persone dovrà essere integrata a quella già esistente per non disorientare l’utente.

Manutenzione [MAN] Nessuno

Prestazioni [PER] Nessuno

Piattaforma [PLF] OWK-PLF-0001

Modello di gruppo dinamico È necessario scindere la definizione di un gruppo dinamico nelle tre versioni del modello di processo: Model, Instance, Executable.

Sicurezza [SEC] Nessuno

Integrazione [INT]

52 OWK-INT-0001

OWK-INT-0002

OWK-INT-0003

OWK-INT-0004

OWK-INT-0005

Eredità della localizzazione Si deve essere in grado di adattare la lingua utilizzando le relative componenti di localizzazione già realizzate. Accesso alle entità organizzative Si deve essere in grado di accedere alle entità organizzative definite in BPM Tools®. Visibilità della verifica di correttezza formale Si dovrà esporre la funzionalità di verifica di correttezza formale all’esterno. Estensione del modulo di controllo È necessario estendere il modulo di “ispezione errori” prepubblicazione nel Business Flow Designer anche al controllo dei gruppi dinamici. Estensione del Business Flow Designer È necessario estendere il Business Flow Designer anche all’associazione di un’attivit{ al Gruppo Dinamico.

Tecnici [TEC] OWK-TEC-0001

OWK-TEC-0002

Framework di sviluppo Il sistema dovrà essere realizzato utilizzando Microsoft Framework 2.0 Lista degli attributi La lista degli attributi sarà contenuta in un file XML con relativo schema.

53

Capitolo 6: Specifiche dei requisiti 6.1 Classi In questa sezione si illustreranno i requisiti funzionali precedentemente individuati e da questi si estrarrà un elenco di classi candidate. Da queste si ricaverà un sotto-insieme proprio di classi definitive.

6.1.1 Diagrammi Mapping Requisiti Funzionali

OWKFUN0001

OWK-

Creare Gruppi Dinamici L’utente (utilizzatore di BPM Tools®) avr{ la possibilità di creare nuovi gruppi detti “gruppi dinamici” specificando nome, descrizione ed un insieme di condizioni (attributo-operatorevalore). Le condizioni devono essere composte con operatori logici AND e OR. Il set di attributi utilizzabili può cambiare nel tempo. Eliminare Gruppo Dinamico

Classi candidate - Gruppo Dinamico - Attributo

- Gruppo Dinamico

54 FUN0002

OWKFUN0003 OWKFUN0004

OWKFUN0005

OWKFUN0006

OWKFUN0007

Il server, allo scatenarsi di un particolare evento (ad es. la pubblicazione di un processo) provvederà ad eliminare i gruppi dinamici inutilizzati. Associare Gruppo ad un’Attività L’utente (utilizzatore di BPM Tools®) avr{ la possibilità di associare ad un gruppo dinamico precedentemente creato un’attivit{. Visualizzare Elenco Gruppi Dinamici L’utente (utilizzatore di BPM Tools®) avrà la possibilit{ di visualizzare l’elenco di tutti i gruppi dinamici definiti. Modificare Gruppo Dinamico L’utente (utilizzatore di BPM Tools®) avr{ la possibilità di modificare i gruppi dinamici precedentemente inseriti. L’utente potrà modificare nome, descrizione ed espressione. Per “modifica dell’espressione” si intende la cancellazione, e la modifica di ogni singola condizione e l’inserimento di nuove condizioni. Controllo formale di correttezza Prima della pubblicazione, il Server deve essere in grado di controllare la correttezza della definizione di un gruppo dinamico. Un gruppo dinamico si dirà corretto quando gli operatori logici saranno ben bilanciati e quando tutti gli attributi coinvolti saranno validi per la piattaforma in uso. Un attributo si dirà valido rispetto alla piattaforma, quando il suo uso è ammesso in quella piattaforma. Richiedere informazioni sulle attività che coinvolgono l’utente nei gruppi dinamici L’utente (utilizzatore dell’interfaccia Web Client) all’atto della richiesta di accesso al sistema, dovr{ poter conoscere quali sono le attività in carico (da svolgere) che lo coinvolgono in un gruppo dinamico.

- Gruppo Dinamico - Attività

- Gruppo Dinamico

- Gruppo Dinamico - Condizione - Espressione

- Gruppo Dinamico - Attributo

- Gruppo Dinamico - Attività

Raffinamento Delle classi candidate precedentemente individuate è necessario scartarne alcune per differenti motivi:  Condizione: non è propriamente una classe, ma semplicemente un attributo della classe “Espressione”.  Attributo: non è propriamente una classe.

55

Classi definitive

Figura 8: Classi definitive

La classe Activity pur essendo stata inserita all’interno dell’insieme delle classi definitive, è già presente nella piattaforma openwork®.

56

6.2 Casi d’uso 6.2.1 Diagrammi A partire dai requisiti funzionali si estraggono i casi d’uso. Si ispezionano i requisiti funzionali al fine di far emergere le funzionalità del sistema in relazione ad ogni singolo attore.

Mapping Requisiti Funzionali

OWKFUN0001

OWKFUN0002

OWKFUN0003

OWKFUN0004 OWKFUN0005

Creare Gruppi Dinamici L’utente (utilizzatore di BPM Tools®) avrà la possibilità di creare nuovi gruppi detti “gruppi dinamici” specificando nome, descrizione ed un insieme di condizioni (attributooperatore-valore). Le condizioni devono essere composte con operatori logici AND e OR. Il set di attributi utilizzabili può cambiare nel tempo. Eliminare Gruppo Dinamico Il server, allo scatenarsi di un particolare evento (ad es. la pubblicazione di un processo) provvederà ad eliminare i gruppi dinamici inutilizzati. Associare Gruppo ad un’Attività L’utente (utilizzatore di BPM Tools®) avrà la possibilità di associare ad un gruppo dinamico precedentemente creato un’attivit{. Visualizzare Elenco Gruppi Dinamici L’utente (utilizzatore di BPM Tools®) avrà la possibilità di visualizzare l’elenco di tutti i gruppi dinamici definiti. Modificare Gruppo Dinamico L’utente (utilizzatore di BPM Tools®) avrà la possibilità di

Attore

Caso d’uso

Business Flow Modeler

Creare un gruppo dinamico

Application Server

Eliminare gruppi dinamici inutilizzati

Business Flow Modeler

Associare gruppo ad un’attivit{

Business Flow Modeler

Visualizzare gruppi dinamici

Business Flow Modeler

Modificare gruppo dinamico

57

OWKFUN0006

OWKFUN0007

modificare i gruppi dinamici precedentemente inseriti. L’utente potrà modificare nome, descrizione e condizioni. Per “modifica dell’espressione” si intende la cancellazione, e la modifica di ogni singola condizione e l’inserimento di nuove condizioni. Controllo formale di correttezza Prima della pubblicazione, il Server deve essere in grado di controllare la correttezza della definizione di un gruppo dinamico. Un gruppo dinamico si dirà corretto quando gli operatori logici saranno ben bilanciati e quando tutti gli attributi coinvolti saranno validi per la piattaforma in uso. Un attributo si dirà valido rispetto alla piattaforma, quando il suo uso è ammesso in quella piattaforma. Richiedere informazioni sulle attività che coinvolgono l’utente nei gruppi dinamici L’utente (utilizzatore dell’interfaccia Web Client) all’atto della richiesta di accesso al sistema, dovrà poter conoscere quali sono le attività in carico (da svolgere) che lo coinvolgono in un gruppo dinamico.

Application Server, Business Flow Modeler

Controllare la correttezza formale, Pubblicazione del processo

Business Flow Modeler

Verifica l’appartenenza ad un gruppo dinamico, Utenti che appartengono ad un gruppo dinamico

58

Diagramma dei casi d’uso

Figura 9: Diagramma dei casi d'uso

59

6.2.2 Dettaglio casi d’uso 1. Show Dynamic Groups L’utente deve avere la possibilit{ di consultare l’elenco dei Gruppi Dinamici inseriti nella piattaforma. ACTORS Business Flow Modeler. USE CASE INTERACTION Use Case Link Dynamic Group to Activity

Relation Extend

Direction From

SCENARIO 1.

Scenario di base L’utente preme il pulsante relativo alla sezione dei Gruppi Dinamici, all’interno della finestra di assegnazione partecipanti nel Business Flow Designer;

PERCORSI ALTERNATIVI None REQUISITI TRACCIATI OWK-FUN-0004

60

2. Delete Unused Dynamic Groups L’Application Server, allo scatenarsi di uno specifico evento, deve provvedere automaticamente a cancellare i gruppi dinamici dichiarati nel modello di processo, ma non utilizzati da quest’ultimo. ACTORS Application Server. USE CASE INTERACTION Use Case

Relation

Direction

SCENARIO Scenario di base 1. L’Application Server controlla il verificarsi di un determinato evento; 2. Quando l’evento si scatena, l’Application Server elimina tutte le definizione dei gruppi dinamici superflui per il corrente modello di processo.

PERCORSI ALTERNATIVI None REQUISITI TRACCIATI OWK-FUN-0002

61

3. Create Dynamic Group L’utente deve avere la possibilità di inserire un Gruppo Dinamico nella piattaforma. ACTORS Business Flow Modeler. USE CASE INTERACTION Use Case Link Dynamic Group to Activity Formal Control of Accuracy

Relation Extend Include

Direction To To

SCENARIO Scenario di base 1. Il Business Flow Modeler preme il pulsante relativo al collegamento di un’attivit{ con i Gruppi Dinamici; 2. Il Business Flow Modeler preme il pulsante relativo all’inserimento di un nuovo Gruppo Dinamico; 3. Il Business Flow Modeler inserisce le informazioni richieste (lista di attributi e valori relativi); 4. Il Business Flow Modeler preme sul pulsante di conferma inserimento; 5. L’Application Server controlla la correttezza dei dati inseriti; 6. L’Application Server assegna il gruppo dinamico all’attività in esame.

PERCORSI ALTERNATIVI Scenario alternativo 5. L’Application Server controlla la correttezza dei dati inseriti e notifica gli errori; 6. Il Business Flow Modeler reinserisce i dati in modo corretto; 7. L’Application Server assegna il gruppo dinamico all’attivit{ in esame.

REQUISITI TRACCIATI OWK-FUN-0001

62

4. Update Dynamic Group L’utente deve avere la possibilit{ di modificare un Gruppo Dinamico inserito nella piattaforma. ACTORS Business Flow Modeler. USE CASE INTERACTION Use Case Show Dynamic Groups Formal Control of Accuracy

Relation Extend Include

Direction To To

SCENARIO Scenario di base 1. Il Business Flow Modeler preme il pulsante relativo alla visualizzazione dei Gruppi Dinamici; 2. Il Business Flow Modeler preme il pulsante relativo alla modifica di un Gruppo Dinamico visualizzato; 3. Il Business Flow Modeler modifica le informazioni opportune (nome e/o condizioni); 4. Il Business Flow Modeler preme sul pulsante di conferma modifiche; 5. L’Application Server controlla la correttezza dei dati inseriti; 6. L’Application Server assegna il gruppo dinamico all’attivit{ in esame.

PERCORSI ALTERNATIVI Scenario alternativo 5. L’Application Server controlla la correttezza dei dati inseriti e notifica gli errori; 6. Il Business Flow Modeler reinserisce i dati in modo corretto; 7. L’Application Server controlla la correttezza dei dati inseriti; 8. L’Application Server assegna il gruppo dinamico all’attivit{ in esame.

REQUISITI TRACCIATI OWK-FUN-0005

63

5. Link Dynamic Group to Activity L’utente deve avere la possibilità di associare un Gruppo Dinamico inserito nella piattaforma ad un’attivit{ nel Business Flow Designer. ACTORS Business Flow Modeler. USE CASE INTERACTION Use Case Show Dynamic Groups Update Dynamic Group Create Dynamic Group

Relation Extend Extend Extend

Direction From From From

SCENARIO Scenario di base 1. Il Business Flow Modeler accede al Business Flow Designer per gestire un modello di processo; 2. Il Business Flow Modeler seleziona l’attivit{ da sottoporre al gruppo dinamico; 3. Il Business Flow Modeler preme sul pulsante relativo all’indicazione dei partecipanti; 4. Il Business Flow Modeler selezione il gruppo dinamico desiderato; 5. L’Application Server associa l’attivit{ a quel gruppo dinamico.

PERCORSI ALTERNATIVI None REQUISITI TRACCIATI OWK-FUN-0003

64

6. Formal Control of Accuracy L’Application Server deve controllare la correttezza formale della definizione di un Gruppo Dinamico. Un Gruppo Dinamico è formalmente corretto quando gli operatori logici presenti nelle condizioni sono ben bilanciati e quando le condizioni coinvolgono attributi che sono utilizzabili sulla piattaforma. Ogni piattaforma può utilizzare un set diverso di attributi. E’ necessario pertanto controllare che la espressione del gruppo dinamico faccia riferimento solo ad attributi che possono essere interpretati dalla piattaforma. ACTORS Application Server. USE CASE INTERACTION Use Case Create Dynamic Group Update Dynamic Group Publish Process Model

Relation Include Include Include

Direction From From From

SCENARIO Scenario di base 1. L’Application Server controlla la correttezza formale del gruppo dinamico. 2. L’Application Server restituisce l’esito del controllo.

PERCORSI ALTERNATIVI None REQUISITI TRACCIATI OWK-FUN-0006

65

7. Publish Model Questo caso d’uso non è oggetto di questo documento. Per questa ragione non verrà descritto. ACTORS Business Flow Modeler. USE CASE INTERACTION Use Case Formal Control of Accuracy

SCENARIO None PERCORSI ALTERNATIVI None REQUISITI TRACCIATI None

Relation Include

Direction From

66

8. Request Access Questo caso d’uso non è oggetto di questo documento. Per questa ragione non verrà descritto. ACTORS Web Client User. USE CASE INTERACTION Use Case Verify affiliations of dynamic group

SCENARIO None PERCORSI ALTERNATIVI None REQUISITI TRACCIATI None

Relation Include

Direction To

67

9. Verify affiliations of dynamic group L’utente che utilizza il Web Client richiede l’accesso al sistema. All’atto della richiesta dell’accesso al sistema, tra le tante funzionalità che il sistema gli espone c’è quella di proporre la lista delle attivit{ in carico. Questo particolare caso d’uso riguarda l’insieme di quelle attivit{ proposte, che coinvolgono l’utente poiché questi è parte di un gruppo dinamico associato ad un’attivit{ in esecuzione. In particolare questo caso d’uso sta ad indicare la funzionalit{ di verifica dell’appartenenza ad un gruppo dinamico. Iterando questo procedimento per tutti i gruppi dinamici presenti, è facile ottenere l’elenco di tutti i gruppi dinamici ai quali l’utente appartiene. ACTORS Application Server. USE CASE INTERACTION Use Case Request Access

Relation Include

Direction From

SCENARIO Scenario di base 1. L’Application Server comunica all’esterno se l’utente richiedente fa o meno parte di un particolare gruppo dinamico.

PERCORSI ALTERNATIVI None REQUISITI TRACCIATI OWK-FUN-0007

68

10. Affiliated Users of a Dynamic Group L’Application Server è in grado di valutare l’espressione di un determinato gruppo dinamico ed estrarre una lista di partecipanti attivi: tutti e soli quelli che soddisfano le condizioni del gruppo. Questa attività è estremamente onerosa in termini di risorse consumate e per questa ragione ha un limitatissimo campo di applicabilità. In generale questa funzionalità verrà utilizzata solo per particolari tipi di attività che non costituiscono la maggior parte di quelli in esecuzione. ACTORS Application Server. USE CASE INTERACTION Use Case

Relation

Direction

SCENARIO Scenario di base L’Application Server percepisce l’identificativo del gruppo dinamico. L’Application Server valuta l’espressione contenuta nella definizione del Gruppo Dinamico. L’Application Server restituisce una lista di partecipanti che in quel preciso momento soddisfa le particolari condizioni presenti nell’espressione del Gruppo Dinamico.

PERCORSI ALTERNATIVI None REQUISITI TRACCIATI OWK-FUN-0007

69

Capitolo 7: Conclusioni Dopo aver studiato la fattibilità e dopo aver analizzato formalmente il concetto di Gruppo Dinamico, esso è diventerà uno dei punti cardine della prossima generazione di openwork®. In particolare, ci si è resi conto, dopo una lunga fase di studio che i Gruppi Dinamici sono stati definiti in maniera sufficientemente generale da poter inglobare nella loro definizione altre forme di organizzazioni oltre a quella gestita dall’attuale piattaforma. Ciò significa che anche le restanti entità organizzative potranno essere viste come un gruppo dinamico (espressione). Di fatto nella prossima generazione di openwork® tutta l’organizzazione sar{ gestita come gruppo dinamico.

7.1 Possibili sviluppi futuri Lo stage nella Net Sistemi srl è durato giusto il tempo necessario per comprendere la logica dell’intera piattaforma, approfondire il dominio applicativo (a me totalmente sconosciuto prima di allora) e redigere un documento di analisi dei requisiti completo. Per questa ragione, il naturale sviluppo di questa tesi consisterà nel procedere con le restanti fasi del ciclo di sviluppo del software: progettazione, codifica e test.

70

7.1.1 Uso trasversale delle espressioni Un interessante sviluppo della soluzione precedentemente illustrata è quello di estendere l’ambito di competenza delle espressioni dai soli gruppi dinamici a tutte le entità presenti nella piattaforma. Oltre che poter utilizzare come operandi le sole entità organizzative, in futuro potrebbe essere possibile utilizzare tutte le entità coinvolte: documento, processo, attività e naturalmente organizzazione. I costi di realizzazione di una soluzione del genere impongono di relegare l’idea nella sezione sviluppi futuri.

7.1.2 Information Retrieval I gruppi dinamici, per come sono stati analizzati sono un fattore chiave della futura generazione della piattaforma openwork® pur tuttavia rimanendo ad un livello di elaborazione dati sintattico. Un possibile sviluppo futuro, interessante e pioneristico, potrebbe essere quello di integrare un motore di ricerca semantico all’interno della piattaforma, che consentisse all’utente di scrivere una semplice descrizione testuale del gruppo che vuole creare e lasciare alla piattaforma il compito di trasformare quella descrizione testuale in una espressione come accade oggi. Si pensi all’utente che anziché destreggiarsi con espressioni booleane, tipi di dati e altro, si cimenti nella scrittura di una descrizione del gruppo in linguaggio naturale. La piattaforma, dotata di un sistema di information retrieval, interpreterà il testo come query e restituirà oggetti di dati strutturati che nel caso specifico saranno le entità organizzative.

71

Appendice

72

A UML In ingegneria del software, UML (Unified Modeling Language, linguaggio di modellazione unificato) è un linguaggio di modellazione e specifica basato sul paradigma object-oriented. Il nucleo del linguaggio fu definito nel 1996 da Grady Booch, Jim Rumbaugh e Ivar Jacobson (detti i tre amigos) sotto l’egida dello OMG, che tuttora gestisce lo standard di UML. Il linguaggio nacque con l’intento di unificare approcci precedenti (dovuti ai tre padri di UML e altri), raccogliendo le best practices nel settore e definendo così uno standard industriale unificato. UML svolge un’importantissima funzione di lingua franca nella comunità della progettazione e programmazione a oggetti. Gran parte della letteratura di settore usa UML per descrivere soluzioni analitiche e progettuali in modo sintetico e comprensibile a un vasto pubblico. L’ultima versione del linguaggio, la 2.0, è stata consolidata nel 2004 e ufficializzata da OMG nel 2005. UML 2.0 riorganizza molti degli elementi della versione precedente (1.5) in un quadro di riferimento ampliato e introduce molti nuovi strumenti, inclusi alcuni nuovi tipi di diagrammi. Sebbene OMG indichi UML 2.0 come la versione corrente del linguaggio, la transizione `e di fatto ancora in corso; le stesse specifiche pubblicate da OMG sono ancora non completamente aggiornate e il supporto dei tool a UML 2.0 `e, nella maggior parte dei casi, appena abbozzato.

73

A.1 Storia I linguaggi per la modellazione object-oriented iniziarono a svilupparsi in diversi contesti a partire dagli anni ’80. Si trattava di notazioni di varia natura, che consentivano di descrivere la struttura di un sistema software a oggetti (in termini di classi e relazioni fra classi) ed eventualmente il suo comportamento dinamico. La proliferazione di queste notazioni diede luogo a quelle che furono poi battezzate guerre dei metodi (method wars), con diversi progettisti, o organizzazioni, che adottavano e sostenevano una particolare notazione a scapito di altre adottate altrove. Intorno alla met{ degli anni ’90 diversi metodi e linguaggi iniziarono a fondersi, e si iniziò a delineare la possibilità di una integrazione dei principali formalismi in una notazione universalmente accettabile. Fra le metodologie e le notazioni più apprezzate e diffuse del periodo spiccavano OMT (Object Modeling Technique) di Jim Rumbaugh, e il cosiddetto metodo Booch di Grady Booch, entrambi ricercatori presso Rational Software. Il lavoro di unificazione iniziò con loro; in seguito si un`ı a questo sforzo Jacobson con la sua software house Objectory. Il primo risultato congiunto di questo team fu OOSE (Ob ject Oriented Software Engineering). Mentre i tre gringos operavano per unificare i propri approcci all’analisi e alla progettazione a oggetti, il progetto fu accolto sotto l’egida dell’OMG (Object Management Group), un consorzio fondato con l’obiettivo di creare e gestire standard nel contesto dello sviluppo del software a oggetti. Nel 1995, l’OMG raccolse tutti i principali metodologisti del settore in un incontro internazionale per discutere della notazione unificata. Nel 1996 l’OMG emise una RFP (Request for Proposal) per tale notazione. Nello stesso anno, Booch, Rumbaugh e Jacobson misero a punto le release 0.9 e 0.91 di UML. Il progetto fu ben accolto dalla comunità internazionale e innumerevoli grandi organizzazioni si unirono a Rational per proseguirlo (per esempio Digital, Hewlett-Packard, IBM, Microsoft, Oracle e Unisys). Questo gruppo esteso realizzò, nel 1997, UML 1.0, che fu sottoposto alla OMG come risposta alla RFP dell’anno precedente. La release 1.1 di UML contribuì a consolidare la semantica del linguaggio e incluse elementi tratti da una proposta avanzata

74 indipendentemente all’OMG da un gruppo composto da IBM, ObjectTime, Ptech e altre.

A.2 Caratteristiche speciali La notazione UML è semi-grafica e semi-formale; un modello UML è costituito da una collezione organizzata di diagrammi correlati, costruiti componendo elementi grafici (con significato formalmente definito), elementi testuali formali, ed elementi di testo libero. Ha una semantica molto precisa e un grande potere descrittivo. Il linguaggio è stato progettato con l’obiettivo esplicito di facilitare il supporto software alla costruzione di modelli e l’integrazione di questo supporto con gli ambienti integrati di sviluppo. OMG, in particolare, gestisce una famiglia di standard correlata a UML, detta Model Driven Architecture (MDA), che ha lo scopo di fornire le fondamenta concettuali e semantiche per lo sviluppo di ambienti evoluti di roundtrip engineering in cui la modellazione UML, in qualche misura, possa sostituire di fatto la programmazione tradizionale. Sebbene questo obiettivo sia ancora da raggiungere, molti IDE comprendono strumenti di modellazione in UML e forniscono meccanismi automatici di traduzione parziale dei diagrammi UML in codice e viceversa. Viceversa, molti ambienti software dedicati alla modellazione in UML consentono di generare codice in diversi linguaggi. UML è un linguaggio di modellazione general purpose, che fornisce concetti e strumenti applicabili in tutti i contesti. Poiché particolari domini applicativi o famiglie di applicazioni potrebbero aver bisogno di concetti ulteriori e specifici, UML fornisce un meccanismo standard che consente di estendere il linguaggio. Una estensione di UML per un particolare contesto viene detta un profilo UML.

75

A.3 Applicazioni Di per sé, UML è solo un linguaggio di modellazione, e non definisce alcuna specifica metodologia per la creazione di modelli (o alcun processo software). UML può quindi essere utilizzato nel contesto di diversi approcci metodologici. La OMG gestisce uno standard metodologico, correlato a UML ma proposto come specifica indipendente, detto RUP. UML consente di costruire modelli object-oriented per rappresentare domini di diverso genere. Nel contesto dell’ingegneria del software, viene usato soprattutto per descrivere il dominio applicativo di un sistema software e/o il comportamento e la struttura del sistema stesso. Il modello è strutturato secondo un insieme di viste che rappresentano diversi aspetti della cosa modellata (funzionamento, struttura, comportamento, e così via), sia a scopo di analisi che di progetto, mantenendo la tracciabilità dei concetti impiegati nelle diverse viste. Oltre che per la modellazione di sistemi software, UML viene non di rado impiegato per descrivere domini di altri tipi, come sistemi hardware, strutture organizzative aziendali, processi di business. Lo standard UML, gestito da OMG, definisce una sintassi e delle regole di interpretazione; non si tratta quindi di una metodologia di progettazione e per questo motivo può essere adottato con diverse metodologie o in ambiti diversi da quello informatico.

76

B XML L’XML, acronimo di eXtensible Markup Language, ovvero «Linguaggio di marcatura estensibile» è un metalinguaggio creato e gestito dal World Wide Web Consortium (W3C). È una semplificazione e adattamento dell’SGML, da cui è nato nel 1998, e permette di definire la grammatica di diversi linguaggi specifici derivati. Rispetto all’HTML, l’XML ha uno scopo ben diverso: mentre il primo è un linguaggio creato principalmente per la descrizione e la formattazione di pagine web e, più in generale, di ipertesti, il secondo è un meta linguaggio utilizzato per creare nuovi linguaggi, atti a descrivere documenti strutturati. Mentre l’HTML ha un insieme ben definito e ristretto di tag, con l’XML è invece possibile definirne di propri a seconda delle esigenze. L’XML è oggi molto utilizzato anche come mezzo per l’esportazione di dati tra diversi DBMS. Per poter essere correttamente interpretato da un browser, un documento XML deve essere ben formato, deve cioè possedere le seguenti caratteristiche: • Un Prologo, che è la prima istruzione che appare scritta nel documento. Nel nostro caso: • Un unico Elemento radice (ovvero il nodo principale) che contiene tutti gli altri nodi del documento. Nel nostro esempio: ; • All’interno del documento tutti i Tag devono essere bilanciati. Un documento XML viene considerato Well Formed se non contiene errori di sintassi, tutti tag sono bilanciati ed esiste un unico

77 nodo radice che contiene tutti gli altri. Se il documento è well-formed e in più rispetta i requisiti strutturali definiti nel DTD o nell’XML Schema si dice Valid.

B.1 Strumenti aggiuntivi per XML L’XML non si esaurisce qui: esistono diversi strumenti legati all’XML, ognuno con uno scopo differente: • DTD (acronimo di Document Type Definition): `e un documento attraverso cui si specificano le caratteristiche strutturali di un documento XML attraverso una serie di regole grammaticali. In particolare definisce l’insieme degli elementi del documento XML, le relazioni gerarchiche tra gli elementi, l’ordine di apparizione nel documento XML e quali elementi e quali attributi sono opzionali o meno. • XML Schema: come la DTD, serve a definire la struttura di un documento XML. Oggi il W3C consiglia di adottarlo al posto della DTD stessa, essendo una tecnica più nuova ed avanzata. La sua sigla è XSD, acronimo di XML Schema Definition; • XLink: serve a collegare in modo completo due documenti XML; al contrario dei classici collegamenti ipertestuali che conosciamo in HTML, XLink permette di creare link multidirezionali e semanticamente avanzati; • XSL (acronimo di eXtensible Stylesheet Language): è il linguaggio con cui si descrive il foglio di stile di un documento XML. La sua versione estesa è l’XSLT (dove la T sta per Trasformations); • XPath: è un linguaggio con cui è possibile individuare porzioni di un documento XML e sta alla base di altri strumenti per l’XML come XQuery. A supporto di questo scopo principale, fornisce anche elementari funzionalità per trattare stringhe, numeri e dati booleani. Il suo funzionamento si basa sulla creazione di un albero a partire dal documento e la sintassi succinta permette di indirizzare una specifica parte attraverso i nodi dell’albero con la semplice parola path; • XPointer: serve ad identificare univocamente precise porzioni di un documento XML; consente poi il loro accesso ad altri linguaggi o oggetti di interfaccia;

78 • XQuery: è un linguaggio di query concepito per essere applicabile a qualsiasi sorta di documento XML e si basa sull’utilizzo di XPath per la specificazione di percorsi all’interno di documenti. XQuery ha funzionalità che consentono di poter attingere da fonti di dati multiple per la ricerca, per filtrare i documenti o riunire i contenuti di interesse; • SAX (Simple API for XML): è un’interfaccia di programmazione, implementata in numerosi linguaggi, che permette di leggere e modificare i documenti XML. Attraverso SAX è possibile implementare dei parser XML specifici. SAX è event-base, al contrario di DOM, e reagisce agli eventi di parsing facendo rapporto all’applicazione. È compito del programmatore implementare i metodi per reagire agli eventi di parsing; • DOM: è un’interfaccia di programmazione, come SAX, implementata in una moltitudine di linguaggi di programmazione, per la manipolazione di file XML. DOM costruisce partendo dal file XML un albero dove ogni nodo dell’albero corrisponde ad un elemento del file; per questo motivo è detta tree based; • VTD-XML. DOM è più facile ed immediata da utilizzare rispetto a SAX ed è pertanto preferita solitamente dai programmatori per manipolare un file XML; purtroppo l’albero generato da DOM va mantenuto completamente nella memoria RAM e di conseguenza non è possibile utilizzare questa interfaccia per manipolare file che siano più grandi della memoria disponibile sul computer. • XForms: come il suo nome lascia intendere, è un linguaggio nato per creare moduli (forms) di tipo HTML all’interno di un documento XML; • RSS: è uno standard che serve a creare un documento con una struttura di tipo XML univoca, atta allo sviluppo di un semplice scambio dati tra pagine Web ed accessibile da qualsiasi linguaggio di scripting. In sostanza si tratta di un documento XML la cui struttura dei nodi ed i relativi tag hanno lo stesso nome; • SVG (Scalable Vector Graphics): è uno standard per la creazione di immagini vettoriali che sfrutta dei documenti formattati in XML. Serve inoltre a descrivere immagini bidimensionali, statiche e dinamiche. Leggendo le istruzioni contenute nel documento sorgente XML, l’interprete disegna le figure-base fino al completamento dell’immagine.

79

Glossario ed Acronimi .NET API BPEL BPM BPMN COM+ CSS DCOM DOM Failover

FTP HCI HTML HTTP HTTPS

Tecnologia di programmazione ad oggetti versatile di Microsoft. Application Programming Interface Business Process Execution Language Business Process Management Business Process Management Notation Component Object Model; Piattaforma Microsoft per componenti software Cascading Style Sheets Distributed Component Object Model; Piattaforma Microsoft per le component software distribuite Document Object Model È un sistema di salvataggio nel quale le funzioni di una componente di un sistema (come ad esempio un processore, un server, una rete un database e altri) vengono inviate ad una seconda componente quando la prima ha un problema. Viene utilizzato per rendere i sistemi più resistenti ai problemi di errori File Transfer Protocol Human-Computer Interaction Hyper Text Markup Language Hyper Text Transfer Protocol Hyper Text Transfer Protocol Secure

80 ISO KPI MDA MEGA OMG OMT OWK PDF SAX SOA SOAP SVG UML Undo UNI VTD-XML W3C WS WSDL XML XPDL XSD XSL XSL-FO XSLT

International Organization for Standardization Key Performance Indicator Model Driven Architecture MEGA International azienda leader nell’area del BPM Object Management Group Object Modeling Technique Openwork abbreviazione utilizza nello standard aziendale di documentazione Portable Document Format Simple API for XML Service Oriented Architecture Simple Object Access Protocol Scalable Vector Graphics Unified Modeling Language Funzione mediante la quale è possibile annullare le ultime modifiche eseguite Ente Nazionale Italiano di Unificazione Virtual Token Descriptor for eXtensible Markup Language World Wide Web Consortium Web Service Web Services Description Language eXtensible Markup Language eXtensible Process Description Language XML Schema eXtensible Stylesheet Language XSL Formatting Objects XSL Transformations

81

Bibliografia 1. The Workflow Management Coalition. 2007 BPM & Workflow Handbook Methods, Concepts, Case Studies and Standards in Business Process Management and Workflow. s.l. : Layna Fischer, 2007. pp. 145-152. 2. Taylor, C. Philosophical Papers: Philosophy and the Human Sciences. Cambridge Paperback Library. s.l. : Cambridge University Press, 1985. Vol. 2. 3. ISO. ISO 12052:2006. Health informatics -- Digital imaging and communication in medicine (DICOM) including workflow and data management. s.l. : ISO, 2006. 4. —. ISO/TR 16044:2004. Graphic technology - Database architecture model and control parameter coding for process control and work. s.l. : ISO, 2004. 5. Anthony, R.N. Essentials of Accounting. s.l. : Addison-Wesley Longman, Incorporated, 1977. 6. The Workflow Management Coalition. Process Definition Interface - XML Process Definition Language. Document Number WfMC TC-1025. [Online] 2.00, Ottobre 3, 2005. http://www.wfmc.org/standards/docs/TC-1025_xpdl_2_2005-1003.pdf. 7. Business Process Management Initiative. Business Process Modeling Notation 1.0. BPMI. [Online] Maggio 8, 2008. http://www.omg.org/docs/bei/05-08-07.pdf. 8. Object Management Group. Business Process Definition Metamodel Request For Proposal. Object Management Group.

82 [Online] Gennaio 16, 2003. http://xml.coverpages.org/OMG-03-0106.pdf. 9. Wikimedia Foundation. Wikipedia - Wikipedia, the free encyclopedia. Wikipedia.org. [Online] Wikimedia Foundation, Gennaio 2001, 2001. http://www.wikipedia.org/. 10. The Workflow Management Coalition. Terminology & Glossary. Document Number WfMC TC-1011. [Online] 1994-1999. http://www.wfmc.org/standards/docs/TC1011_term_glossary_v3.pdf. 11. —. WfMC.org Homepage. WfMC.org. [Online] Dicembre 19, 2007. http://www.wfmc.org. 12. —. Process Definition Interchange Organisational Model. Document Number WfMC TC-1016-O. [Online] 1994-1998. http://www.wfmc.org/standards/docs/if19807o.pdf.

83