UNIVERSITÀ DEGLI STUDI DI BARI
      FACOLTÀ DI SCIENZE MATEMATICHE FISICHE E NATURALI
      CORSO DI LAUREA IN INFORMATIC...
2
3




Indice

 Indice delle figure .......................................................................... 6
 Capitolo ...
4

   4.2 Organizzazione ....................................................................................... 39
   4.3...
5

            8. Request Access ............................................................................................
6




Indice delle figure

 Figura 1: Logo della piattaforma openwork® .....................................10
 Figura 2: ...
7
8




“ A te nonna …”
9
10




Capitolo 1:
Introduzione

   Questa tesi è il prodotto finale, di uno stage durato sei mesi
nell’area “Ricerca & Sv...
11

delineando un approccio del tutto originale ed innovativo, non
soltanto per il mercato italiano.
   La mission azienda...
12

    L’assenza di standard ha agevolato per anni, il proliferarsi di
numerose soluzioni software di BPM tutte proprieta...
13

1.2 Struttura della tesi

    Il documento si articola nei capitoli di seguito descritti.
    Nel capitolo intitolato ...
14




Capitolo 2:
I processi

    Un processo è un insieme di attività eseguite da persone e/o
sistemi che, scatenate da ...
15

strutturato. Un processo può essere costituito da diversi
sottoprocessi o può avviare altri processi indipendenti. Un
...
16

    Un workflow è una rappresentazione di una sequenza di
operazioni, dichiarate come lavoro di una persona, lavoro di...
17

all'azienda (cliente). Il processo è teso al raggiungimento di un
obiettivo aziendale, determinato in sede di pianific...
18

     i processi primari, che hanno come clienti soggetti esterni
       all'azienda;
     i processi di supporto, ch...
19

   Esistono software proprietari di modellazione dei processi che
garantiscono un'interoperabilità fra loro e con gli ...
20

attraverso uno sviluppo di tipo incrementale; possiamo infatti
identificare alcune fasi che, eseguite in maniera seque...
21

   Tali operazioni sono talora svolte da software differenti che
comunicano tra loro, da programmi che misurano i dati...
22

es. invoca servizio, ricevi risposta, assegna valore ad una variabile,
termina processo, etc…), mentre quelle struttur...
23

.bpel da un database proprietario all'altro senza perdere il contenuto
della rappresentazione.
    La “receive" di un ...
24

    Il primo obiettivo del BPMN è quello di consentire una notazione
standard che sia immediatamente comprensibile ad ...
25

2.2.3 XPDL

   Il XML Process Definition Language (XPDL) è un formato
standardizzato dal Workflow Management Coalition...
26

XML tutti i concetti presenti in BPMN. Questa terza revisione è nota
come XPDL 2.0 e fu ratificata dal WfMC nell'Ottob...
27




Capitolo 3:
Openwork®

   Openwork® è una piattaforma di Business Process Management
web-based, che permette la mod...
28

Management, ponendo inizialmente particolare attenzione alla
componente documentale, in quanto l'efficienza del motore...
29

    Il Repository Documentale è un file-system che può risiedere su
qualsiasi piattaforma; l'Application Server vi acc...
30

    La creazione di un documento (come una Richiesta di Acquisto)
può scatenare l'avvio di un processo: secondo il par...
31

javascript, garantisce l'apertura dell’applicazione e agevola
l’estensione delle sue funzionalità.
    Integrabile: Le...
32

   Tutti i moduli possono essere configurati in differenti modalità a
seconda dell'architettura prescelta e dei requis...
33

    L'utilizzo del BPM Tools® favorisce la costruzione di applicazioni
che fanno riferimento al “linguaggio” ed ai con...
34

3.3.1.1 Organization Designer

    L'organizzazione è l'insieme di operatori, ruoli, unità
organizzative che concorron...
35

stabilendo chi può fare cosa, come, con quali documenti,
autorizzazioni, etc.
   Il Business Flow Designer integra un ...
36

  Nel momento in cui si effettuano delle modifiche nella form e
queste vengono salvate, il percorso è il seguente:
  ...
37




Capitolo 4:
Analisi del problema

                                               “Un’idea, un concetto, un’idea
   ...
38

   L’utente modellatore, utilizzando una apposita palette di
strumenti, disegna graficamente un modello di processo
ar...
39

4.2 Organizzazione

   openwork® consente di definire il concetto di partecipante in
molteplici modi. In particolare e...
40

Egli potrebbe non essere in grado di cogliere la giusta differenza tra i
diversi tipi di entit{ organizzative da coinv...
41

espressione, egli potr{ farlo utilizzando l’apposita interfaccia guidata
di creazione di una nuova espressione.
    L’...
42

processo per la sua pubblicazione devono essere disponibili; pena: la
mancata pubblicazione dello stesso.
   Nel caso ...
43

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


4.4...
44

blocco unico, ma ciò non è richiesto. Spring .NET non è una
soluzione “tutto-o-niente”. Lo sviluppatore può usare le f...
45

specificatamente, la collezione di partecipanti (potenziali o reali)
deve essere risolta all’atto dell’esecuzione di u...
46

   Malgrado si vada ad appesantire il carico computazione, questa
risulta essere l’unica soluzione ragionevole per gar...
47

 La definizione di taluni gruppi dinamici diverrebbe
  sintatticamente errata (negli attributi o negli operatori),
  ...
48




Capitolo 5:
Analisi dei requisiti

   Dopo aver analizzato a fondo la problematica in maniera astratta
con uno stud...
49

5.1 Requisiti
   Di seguito si espongono i diversi requisiti che la futura
applicazione software deve osservare.
   Co...
50

                pubblicazione di un processo) provvederà ad eliminare i gruppi
                dinamici inutilizzati.
...
51

Interfaccia [IFC]

               Gruppi Dinamici
OWK-IFC-0001   L’interfaccia per la gestione dei Gruppi Dinamici dev...
52

               Eredità della localizzazione
OWK-INT-0001   Si deve essere in grado di adattare la lingua utilizzando l...
53




Capitolo 6:
Specifiche dei requisiti

6.1 Classi

   In questa sezione si illustreranno i requisiti funzionali
prec...
54

 FUN-   Il server, allo scatenarsi di un particolare evento
 0002   (ad es. la pubblicazione di un processo)
        p...
55

Classi definitive




                          Figura 8: Classi definitive


   La classe Activity pur essendo stata ...
56

6.2 Casi d’uso

6.2.1 Diagrammi

   A partire dai requisiti funzionali si estraggono i casi d’uso.
   Si ispezionano i...
57

       modificare i         gruppi   dinamici
       precedentemente inseriti. L’utente
       potrà modificare nome, ...
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 de...
60

2. Delete Unused Dynamic Groups

   L’Application Server, allo scatenarsi di uno specifico evento, deve
provvedere aut...
Orchestrazione delle risorse umane nel BPM
Orchestrazione delle risorse umane nel BPM
Orchestrazione delle risorse umane nel BPM
Orchestrazione delle risorse umane nel BPM
Orchestrazione delle risorse umane nel BPM
Orchestrazione delle risorse umane nel BPM
Orchestrazione delle risorse umane nel BPM
Orchestrazione delle risorse umane nel BPM
Orchestrazione delle risorse umane nel BPM
Orchestrazione delle risorse umane nel BPM
Orchestrazione delle risorse umane nel BPM
Orchestrazione delle risorse umane nel BPM
Orchestrazione delle risorse umane nel BPM
Orchestrazione delle risorse umane nel BPM
Orchestrazione delle risorse umane nel BPM
Orchestrazione delle risorse umane nel BPM
Orchestrazione delle risorse umane nel BPM
Orchestrazione delle risorse umane nel BPM
Orchestrazione delle risorse umane nel BPM
Orchestrazione delle risorse umane nel BPM
Orchestrazione delle risorse umane nel BPM
Orchestrazione delle risorse umane nel BPM
Orchestrazione delle risorse umane nel BPM
Upcoming SlideShare
Loading in …5
×

Orchestrazione delle risorse umane nel BPM

2,267 views
2,183 views

Published on

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,267
On SlideShare
0
From Embeds
0
Number of Embeds
9
Actions
Shares
0
Downloads
80
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Orchestrazione delle risorse umane nel BPM

  1. 1. 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. 2. 2
  3. 3. 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. 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. 5. 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. 6. 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. 7. 7
  8. 8. 8 “ A te nonna …”
  9. 9. 9
  10. 10. 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. 11. 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. 12. 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. 13. 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. 14. 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. 15. 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. 16. 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. 17. 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. 18. 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 Re- engineering, possono riguardare tecnologia e/o organizzazione.
  19. 19. 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. 20. 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. 21. 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. 22. 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. 23. 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. 24. 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. 25. 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 meta- modello 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. 26. 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. 27. 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, Human- To-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. 28. 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. 29. 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. 30. 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. 31. 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. 32. 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. 33. 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. 34. 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. 35. 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. 36. 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. 37. 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. 38. 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. 39. 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. 40. 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. 41. 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. 42. 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. 43. 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. 44. 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. 45. 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. 46. 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. 47. 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. 48. 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. 49. 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] Creare Gruppi Dinamici L’utente (utilizzatore di BPM Tools®) avrà la possibilità di creare nuovi gruppi detti “gruppi dinamici” specificando nome, OWK-FUN-0001 descrizione ed un insieme di condizioni (attributo-operatore- valore). Le condizioni devono essere composte con operatori logici AND e OR. Il set di attributi utilizzabili può cambiare nel tempo. Eliminare Gruppo Dinamico OWK-FUN-0002 Il server, allo scatenarsi di un particolare evento (ad es. la
  50. 50. 50 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 OWK-FUN-0003 associare ad un gruppo dinamico precedentemente creato un’attivit{. Visualizzare Elenco Gruppi Dinamici OWK-FUN-0004 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 OWK-FUN-0005 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 OWK-FUN-0006 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 OWK-FUN-0007 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] Gruppo Dinamico È la rappresentazione di tutte le informazioni che caratterizzano il gruppo dinamico. OWK-INF-0001 STRUTTURA: - identificativo, nome, descrizione, espressione; RELAZIONI: - Attività(1 .. 1) Attività È l’insieme delle informazioni che caratterizzano una singola attività. OWK-INF-0002 STRUTTURA: - identificativo, … RELAZIONI: - Attività (1 .. )
  51. 51. 51 Interfaccia [IFC] Gruppi Dinamici OWK-IFC-0001 L’interfaccia per la gestione dei Gruppi Dinamici deve essere integrata nel Business Flow Designer. HCI Guidelines OWK-IFC-0002 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 OWK-IFC-0003 di persone dovrà essere integrata a quella già esistente per non disorientare l’utente. Manutenzione [MAN] Nessuno Prestazioni [PER] Nessuno Piattaforma [PLF] Modello di gruppo dinamico OWK-PLF-0001 È necessario scindere la definizione di un gruppo dinamico nelle tre versioni del modello di processo: Model, Instance, Executable. Sicurezza [SEC] Nessuno Integrazione [INT]
  52. 52. 52 Eredità della localizzazione OWK-INT-0001 Si deve essere in grado di adattare la lingua utilizzando le relative componenti di localizzazione già realizzate. Accesso alle entità organizzative OWK-INT-0002 Si deve essere in grado di accedere alle entità organizzative definite in BPM Tools®. Visibilità della verifica di correttezza formale OWK-INT-0003 Si dovrà esporre la funzionalità di verifica di correttezza formale all’esterno. Estensione del modulo di controllo È necessario estendere il modulo di “ispezione errori” pre- OWK-INT-0004 pubblicazione nel Business Flow Designer anche al controllo dei gruppi dinamici. Estensione del Business Flow Designer OWK-INT-0005 È necessario estendere il Business Flow Designer anche all’associazione di un’attivit{ al Gruppo Dinamico. Tecnici [TEC] Framework di sviluppo OWK-TEC-0001 Il sistema dovrà essere realizzato utilizzando Microsoft Framework 2.0 Lista degli attributi OWK-TEC-0002 La lista degli attributi sarà contenuta in un file XML con relativo schema.
  53. 53. 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 Classi candidate Creare Gruppi Dinamici - Gruppo Dinamico L’utente (utilizzatore di BPM Tools®) avr{ la - Attributo possibilità di creare nuovi gruppi detti “gruppi OWK- dinamici” specificando nome, descrizione ed un FUN- insieme di condizioni (attributo-operatore- 0001 valore). Le condizioni devono essere composte con operatori logici AND e OR. Il set di attributi utilizzabili può cambiare nel tempo. OWK- Eliminare Gruppo Dinamico - Gruppo Dinamico
  54. 54. 54 FUN- Il server, allo scatenarsi di un particolare evento 0002 (ad es. la pubblicazione di un processo) provvederà ad eliminare i gruppi dinamici inutilizzati. Associare Gruppo ad un’Attività - Gruppo Dinamico OWK- L’utente (utilizzatore di BPM Tools®) avr{ la - Attività FUN- possibilità di associare ad un gruppo dinamico 0003 precedentemente creato un’attivit{. Visualizzare Elenco Gruppi Dinamici - Gruppo Dinamico OWK- L’utente (utilizzatore di BPM Tools®) avrà la FUN- possibilit{ di visualizzare l’elenco di tutti i gruppi 0004 dinamici definiti. Modificare Gruppo Dinamico - Gruppo Dinamico L’utente (utilizzatore di BPM Tools®) avr{ la - Condizione possibilità di modificare i gruppi dinamici - Espressione OWK- precedentemente inseriti. L’utente potrà FUN- modificare nome, descrizione ed espressione. Per 0005 “modifica dell’espressione” si intende la cancellazione, e la modifica di ogni singola condizione e l’inserimento di nuove condizioni. Controllo formale di correttezza - Gruppo Dinamico Prima della pubblicazione, il Server deve essere in - Attributo grado di controllare la correttezza della definizione di un gruppo dinamico. Un gruppo OWK- dinamico si dirà corretto quando gli operatori FUN- logici saranno ben bilanciati e quando tutti gli 0006 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 - Gruppo Dinamico coinvolgono l’utente nei gruppi dinamici - Attività OWK- L’utente (utilizzatore dell’interfaccia Web Client) FUN- all’atto della richiesta di accesso al sistema, dovr{ 0007 poter conoscere quali sono le attività in carico (da svolgere) che lo coinvolgono in un gruppo dinamico. 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. 55. 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. 56. 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 Attore Caso d’uso Creare Gruppi Dinamici Business Flow Creare un gruppo L’utente (utilizzatore di BPM Modeler dinamico Tools®) avrà la possibilità di creare nuovi gruppi detti “gruppi dinamici” OWK- specificando nome, descrizione ed un FUN- insieme di condizioni (attributo- 0001 operatore-valore). Le condizioni devono essere composte con operatori logici AND e OR. Il set di attributi utilizzabili può cambiare nel tempo. Eliminare Gruppo Dinamico Application Eliminare gruppi Il server, allo scatenarsi di un Server dinamici inutilizzati OWK- particolare evento (ad es. la FUN- pubblicazione di un processo) 0002 provvederà ad eliminare i gruppi dinamici inutilizzati. Associare Gruppo ad un’Attività Business Flow Associare gruppo ad OWK- L’utente (utilizzatore di BPM Modeler un’attivit{ FUN- Tools®) avrà la possibilità di 0003 associare ad un gruppo dinamico precedentemente creato un’attivit{. Visualizzare Elenco Gruppi Business Flow Visualizzare gruppi Dinamici Modeler dinamici OWK- L’utente (utilizzatore di BPM FUN- Tools®) avrà la possibilità di 0004 visualizzare l’elenco di tutti i gruppi dinamici definiti. OWK- Modificare Gruppo Dinamico Business Flow Modificare gruppo FUN- L’utente (utilizzatore di BPM Modeler dinamico 0005 Tools®) avrà la possibilità di
  57. 57. 57 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 Application Controllare la Prima della pubblicazione, il Server Server, correttezza formale, deve essere in grado di controllare la Business Flow Pubblicazione del correttezza della definizione di un Modeler processo gruppo dinamico. Un gruppo OWK- dinamico si dirà corretto quando gli FUN- operatori logici saranno ben 0006 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 Business Flow Verifica attività che coinvolgono l’utente Modeler l’appartenenza ad nei gruppi dinamici un gruppo OWK- L’utente (utilizzatore dell’interfaccia dinamico, Utenti che FUN- Web Client) all’atto della richiesta di appartengono ad un 0007 accesso al sistema, dovrà poter gruppo dinamico conoscere quali sono le attività in carico (da svolgere) che lo coinvolgono in un gruppo dinamico.
  58. 58. 58 Diagramma dei casi d’uso Figura 9: Diagramma dei casi d'uso
  59. 59. 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 Relation Direction Link Dynamic Group to Activity Extend From SCENARIO Scenario di base 1. 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. 60. 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

×