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

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.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
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
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

8. 8
“ A te nonna …”

9. 9

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
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
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
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
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
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
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
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
 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
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
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
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
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
.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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
 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
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
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
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
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
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
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
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
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
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
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
Diagramma dei casi d’uso
Figura 9: Diagramma dei casi d'uso

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
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