UNIVERSITÀ DEGLI STUDI DI BARI

FACOLTÀ DI SCIENZE MATEMATICHE FISICHE E NATURALI

CORSO DI LAUREA IN INFORMATICA E TECNOLOGIE PER LA
PRODUZIONE DEL SOFTWARE

Tesi di laurea in
Gestione della conoscenza di impresa

ORCHESTRAZIONE DI RISORSE UMANE NEL BPM

Gestione dinamica feature-based delle organizzazioni nella
piattaforma openwork®

Relatore:
Prof. Giovanni Semeraro

Correlatore:
Dott. Gianpiero Bongallino
Candidato:
Michele Filannino

Anno accademico 2007-2008

2
 3

Indice

Indice delle figure .......................................................................... 6

Capitolo 1: Introduzione ...........................................................10
1.1 Scopo della tesi....................................................................................... 11
1.2 Struttura della tesi ................................................................................ 13
Capitolo 2: I processi ..................................................................14
2.1 Storia dei processi ................................................................................ 15
2.1.1 Workflow ........................................................................................ 15
2.1.2 Business Process ......................................................................... 16
2.1.3 BPM ................................................................................................... 19
2.2 Standard .................................................................................................... 21
2.2.1 BPEL .................................................................................................. 21
2.2.2 BPMN ................................................................................................ 23
2.2.3 XPDL .................................................................................................. 25
Capitolo 3: Openwork® .............................................................27
3.1 Document Management ..................................................................... 28
3.2 Workflow Management...................................................................... 29
3.3 Architettura ............................................................................................. 30
3.3.1 BPM Tools® .................................................................................. 32
3.3.1.1 Organization Designer ............................................................................................ 34
3.3.1.2 Form Designer ............................................................................................................ 34
3.3.1.3 Business Flow Designer ......................................................................................... 34
3.3.2 Web Client ...................................................................................... 35
Capitolo 4: Analisi del problema ............................................37
4.1 Modello di processo ............................................................................. 37
 4

4.2 Organizzazione ....................................................................................... 39

4.3 Cos’è un gruppo dinamico ................................................................ 40
Gruppo dinamico in un Process Model ........................................ 42
Gruppo dinamico in un Executable Model ................................. 42
Gruppo dinamico in una Process Instance ................................. 42
4.4 Espressioni ............................................................................................... 43
Spring.NET Framework ...................................................................... 43
4.5 Riflessioni ................................................................................................. 44
Valutazione dell’espressione ............................................................ 44
Eliminazione di un gruppo dinamico .......................................... 46
Gruppo dinamico privo di elementi .............................................. 46
Cambiamento del set di attributi utilizzabili ............................ 46
Capitolo 5: Analisi dei requisiti ..............................................48
5.1 Requisiti ..................................................................................................... 49
Funzionali [FUN] .................................................................................... 49
Informativi [INF] .................................................................................... 50
Interfaccia [IFC] ...................................................................................... 51
Manutenzione [MAN] ........................................................................... 51
Prestazioni [PER] ................................................................................... 51
Piattaforma [PLF]................................................................................... 51
Sicurezza [SEC] ........................................................................................ 51
Integrazione [INT] ................................................................................. 51
Tecnici [TEC] ............................................................................................ 52
Capitolo 6: Specifiche dei requisiti ........................................53
6.1 Classi ........................................................................................................... 53
6.1.1 Diagrammi...................................................................................... 53
Mapping ........................................................................................................................................ 53
Raffinamento .............................................................................................................................. 54
Classi definitive ......................................................................................................................... 55
6.2 Casi d’uso .................................................................................................. 56
6.2.1 Diagrammi...................................................................................... 56
Mapping ........................................................................................................................................ 56
Diagramma dei casi d’uso..................................................................................................... 58
6.2.2 Dettaglio casi d’uso .................................................................... 59
1. Show Dynamic Groups ...................................................................................................... 59
2. Delete Unused Dynamic Groups................................................................................... 60
3. Create Dynamic Group ...................................................................................................... 61
4. Update Dynamic Group .................................................................................................... 62
5. Link Dynamic Group to Activity ................................................................................... 63
6. Formal Control of Accuracy ............................................................................................ 64
7. Publish Model........................................................................................................................ 65
 5

8. Request Access ..................................................................................................................... 66

9. Verify affiliations of dynamic group ........................................................................... 67
10. Affiliated Users of a Dynamic Group ....................................................................... 68

Capitolo 7: Conclusioni ..............................................................69

7.1 Possibili sviluppi futuri ...................................................................... 69
7.1.1 Uso trasversale delle espressioni........................................ 70
7.1.2 Information Retrieval ............................................................... 70
Appendice .......................................................................................71
A UML ...............................................................................................72
A.1 Storia........................................................................................................... 73
A.2 Caratteristiche speciali ...................................................................... 74
A.3 Applicazioni ............................................................................................. 75
B XML ................................................................................................76
B.1 Strumenti aggiuntivi per XML ........................................................ 77
Glossario ed Acronimi ................................................................79
Bibliografia.....................................................................................81
 6

Indice delle figure

Figura 1: Logo della piattaforma openwork® .....................................10

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

“ A te nonna …”
9
 10

Capitolo 1:
Introduzione

Questa tesi è il prodotto finale, di uno stage durato sei mesi

nell’area “Ricerca & Sviluppo” presso l’azienda Net Sistemi srl di
Modugno (BA).
Net Sistemi srl è una Indipendent Software Vendor che sviluppa
un solo prodotto software: openwork®.

Figura 1: Logo della piattaforma openwork®

openwork® nasce dall’intuizione, negli anni novanta, con largo

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

delineando un approccio del tutto originale ed innovativo, non

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

1.1 Scopo della tesi

Il lavoro di ricerca profuso in questi sei mesi per la Net Sistemi

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

L’assenza di standard ha agevolato per anni, il proliferarsi di

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

1.2 Struttura della tesi

Il documento si articola nei capitoli di seguito descritti.

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

Capitolo 2:
I processi

Un processo è un insieme di attività eseguite da persone e/o

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

strutturato. Un processo può essere costituito da diversi

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

2.1 Storia dei processi

Il concetto di processo ha cominciato ad emergere nelle realtà

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

2.1.1 Workflow
 16

Un workflow è una rappresentazione di una sequenza di

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

2.1.2 Business Process

Il processo aziendale (o business process) è un insieme di attività

interrelate, svolte all'interno dell'azienda, che creano valore
trasformando delle risorse (input del processo) in un prodotto
(output del processo) destinato ad un soggetto interno o esterno
 17

all'azienda (cliente). Il processo è teso al raggiungimento di un

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

 i processi primari, che hanno come clienti soggetti esterni

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

Esistono software proprietari di modellazione dei processi che

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

2.1.3 BPM

Il Business process management è l'insieme di attività necessarie

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

attraverso uno sviluppo di tipo incrementale; possiamo infatti

identificare alcune fasi che, eseguite in maniera sequenziale,
modellano e consentono la gestione delle attività rispetto a
particolari esigenze.

Figura 2: Ciclo di vita del BPM

Si distinguono le seguenti fasi:

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

Tali operazioni sono talora svolte da software differenti che

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

2.2 Standard

Nell'ambito della definizione, modellazione, esecuzione e

scambio di modelli di processo, esistono diversi standard.
In questa sezione si illustreranno solo gli standard più importanti,
unitamente a quelli essenziali per la comprensione del lavoro di
ricerca condotto.

2.2.1 BPEL

BPEL (Business Process Execution Language) è un linguaggio

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

es. invoca servizio, ricevi risposta, assegna valore ad una variabile,

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

.bpel da un database proprietario all'altro senza perdere il contenuto

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

Figura 3: Esempio di un processo disegnato in BPEL

2.2.2 BPMN

Il Business Process Modeling Notation (BPMN) è una notazione

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

Il primo obiettivo del BPMN è quello di consentire una notazione

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

Figura 4: Esempio di un processo disegnato con BPMN

 25

2.2.3 XPDL

Il XML Process Definition Language (XPDL) è un formato

standardizzato dal Workflow Management Coalition (WfMC) per lo
scambio della definizione di Business Process tra diversi prodotti di
workflow, come strumenti di modellazione e motori di workflow.
XPDL viene definito come uno schema XML per la specifica della
parte dichiarativa di un workflow (6).
XPDL è progettato per lo scambio del disegno di processo, la
grafica e la semantica di workflow di un processo di business. XPDL
contiene elementi che rappresentano le coordinate X,Y dei nodi di
un'attività così come le coordinate dei punti lungo le linee che
collegano i nodi. Questo differenzia XPDL da BPEL che è solo un
formato di definizione del processo che si focalizza prevalentemente
sugli aspetti di esecuzione del processo. BPEL non contiene elementi
che rappresentano l'aspetto grafico di un diagramma di processo.
La prima revisione di XPDL fu chiamata Workflow Process
Definition Language (WPDL) e fu pubblicata nel 1998. Questo 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

XML tutti i concetti presenti in BPMN. Questa terza revisione è nota

come XPDL 2.0 e fu ratificata dal WfMC nell'Ottobre del 2005.
 27

Capitolo 3:
Openwork®

Openwork® è una piattaforma di Business Process Management

web-based, che permette la modellazione, l'esecuzione ed il
monitoraggio di processi organizzativi durante i quali documenti,
informazioni e compiti vengono scambiati tra applicazioni e/o
persone in una sequenza di operazioni stabilite, attraverso un
insieme di regole procedurali.
In generale un processo può essere definito come un insieme
ordinato di attività che, secondo regole prestabilite, coinvolgendo
più funzioni aziendali ed impiegando risorse di tipo diverso,
risolvono un problema di business chiaramente identificato.
Secondo una diffusa definizione, le piattaforme di BPM
dovrebbero consentire l'orchestrazione di sistemi (anche definite
System To System o S2S), ovvero lo scambio di dati secondo regole
ben strutturate. Openwork® rientra in una più recente e ampia
definizione di BPM che prevede l'integrazione non solo di persone,
Human-To-Human o H2H, ma anche di persone e sistemi, 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

Management, ponendo inizialmente particolare attenzione alla

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

3.1 Document Management

Un sistema di Document Management è composto

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

Il Repository Documentale è un file-system che può risiedere su

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

3.2 Workflow Management

All'interno di un processo possono essere creati e archiviati

documenti e valorizzati i loro indici, secondo delle regole specifiche
della applicazione di business che si vuole gestire. Queste regole
vengono modellate graficamente in un modello di processo.
 30

La creazione di un documento (come una Richiesta di Acquisto)

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

3.3 Architettura

L' architettura si basa su alcuni paradigmi illustrati di seguito:

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

javascript, garantisce l'apertura dell’applicazione e agevola

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

Figura 5: Architettura del framework openwork®

Le openwork® business components, l'openwork® manager e

openwork® job engine formano il core della piattaforma
denominata: openwork® engine.
 32

Tutti i moduli possono essere configurati in differenti modalità a

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

3.3.1 BPM Tools®

Una delle principali componenti del framework openwork® è il

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

L'utilizzo del BPM Tools® favorisce la costruzione di applicazioni

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

Figura 6: Architettura del BPM Tools®

 34

3.3.1.1 Organization Designer

L'organizzazione è l'insieme di operatori, ruoli, unità

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

3.3.1.2 Form Designer

Con il Form Designer è possibile disegnare form per la

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

3.3.1.3 Business Flow Designer

Il Business Flow Designer fornisce strumenti grafici con i quali è

possibile definire la sequenza logica e temporale di attività,
 35

stabilendo chi può fare cosa, come, con quali documenti,

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

3.3.2 Web Client

L’applicazione Web è costituita da una applicazione lato server e

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

Nel momento in cui si effettuano delle modifiche nella form e

queste vengono salvate, il percorso è il seguente:
 Il client invia al Web Server un messaggio SOAP contenente i
dati modificati unitamente ad eventuali allegati in formato
DIME da salvare nel repository documentale.
 Il Web Server provvede a instradarli, tramite ws-addressing e
ws-referral, al Web Service.
 I dati indicizzati (contenuti nei vari campi della form) vengono
memorizzati nel database, gli eventuali allegati vengono
memorizzati nel repository.

Quando il client richiede la stampa di una form o di un elenco,

viene invece eseguita una trasformazione lato server con l' utilizzo di
Formatting Objects per la produzione di documenti in formato PDF
secondo regole definite con openwork® BPM Tools®. Tramite il
meccanismo delle trasformazioni è possibile convertire i documenti
di openwork® in diversi altri formati come Microsoft Word® o
Microsoft Excel® (cfr. openwork® Export).
L’applicazione web lato server è attualmente realizzata in
tecnologia Microsoft .NET per server Microsoft IIS versione 5 o
successiva. È inoltre possibile, con estrema facilità, estendere i
moduli Java Script lato client con codice custom ed anche modificare,
attraverso fogli di stile, il layout grafico dell'applicazione. La
disposizione delle directory sul Web Server è studiata in modo da
separare i moduli proprietari da eventuali personalizzazioni (CSS,
codice Java Script, etc.) per semplificare le operazioni di
manutenzione dell’applicazione. Il protocollo utilizzato nelle
comunicazioni può essere HTTP o HTTPS.
Possono essere installati diversi Web Server sulla stessa
Application che espongono anche politiche di autenticazione diverse;
i web server comunicano con i web service tramite HTTP o HTTPS e
possono essere impostati meccanismi di Load Balancing come NLB.
È possibile quindi multi-istanziare sia l' interfaccia applicativa (Web
Services), sia il motore (in modalità separazione di carico).
 37

Capitolo 4:
Analisi del problema

“Un’idea, un concetto, un’idea

finché resta un’idea è soltanto un’astrazione”
Giorgio Gaber

Si introduce, con questo capitolo, il problema aziendale oggetto di

questa tesi. Quello che segue è un documento che presenta diversi
scenari e soluzioni assieme ad una discussione delle scelte adoperate
considerando i diversi fattori critici: costo, tempo, benefici, numero
di risorse impiegate.

4.1 Modello di processo

La piattaforma openwork® adotta, come standard per il disegno

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

L’utente modellatore, utilizzando una apposita palette di

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

4.2 Organizzazione

openwork® consente di definire il concetto di partecipante in

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

Egli potrebbe non essere in grado di cogliere la giusta differenza tra i

diversi tipi di entit{ organizzative da coinvolgere per l’esecuzione di
un’attivit{.

4.3 Cos’è un gruppo dinamico

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

espressione, egli potr{ farlo utilizzando l’apposita interfaccia guidata

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

processo per la sua pubblicazione devono essere disponibili; pena: la

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

Gruppo dinamico in un Process Model

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

Gruppo dinamico in un Executable Model

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

Gruppo dinamico in una Process Instance

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

sbagliato. Ereditando l’informazione direttamente dall’Executable

Model, si garantisce l’aggiornamento continuo.

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

Spring.NET Framework

Spring.NET fornisce un support infrastrutturale per lo sviluppo di

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

blocco unico, ma ciò non è richiesto. Spring .NET non è una

soluzione “tutto-o-niente”. Lo sviluppatore può usare le funzionalità
nei suoi moduli independentemente.
Spring.NET consiste dei seguenti moduli:
 Spring.Core;
 Spring.Aop;
 Spring.Data;
 Spring.Data.NHibernate;
 Spring.Web;
 Spring.Web.Extensions;
 Spring.Services;
 Spring.Testing.NUnit;

Il modulo Spring.Core include ulteriori funzionalità aggiuntive:

 Expression Language – fornisce uno strumento di
interrogazione e manipolazione di grafi di oggetti efficiente
ed a run-time;
 Validation Framework – una robusto framework per la
creazione di complesse regole di validazione per oggetti di
business sia programmaticamente che dichiarativamente;
 Data binding Framework – un frameworka per portare a
termine il legame tra dati.
 Dynamic Reflection – fornisce delle API estremamente
performanti per la reflection.
 Threading - fornisce astrazioni concorrenti addizionali
come Latch, Semaphore e Thread Local Storage.
 Resource abstraction – fornisce una interfaccia commune
per il trattamento di InputStream da un file e da un URL in
maniera polimorfica ed indipendente da protocollo.

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

specificatamente, la collezione di partecipanti (potenziali o reali)

deve essere risolta all’atto dell’esecuzione di una attività e
modificabile all’intervento dell’Amministratore.

Figura 7: Eventi per un'attività openwork®

Nella Fig. 7 sono indicati gli eventi di un’attivit{ nei quali è

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

Malgrado si vada ad appesantire il carico computazione, questa

risulta essere l’unica soluzione ragionevole per garantire che la
coerenza di ogni singolo gruppo dinamico.

Eliminazione di un gruppo dinamico

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

Gruppo dinamico privo di elementi

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

Cambiamento del set di attributi utilizzabili

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

 La definizione di taluni gruppi dinamici diverrebbe

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

Capitolo 5:
Analisi dei requisiti

Dopo aver analizzato a fondo la problematica in maniera astratta

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

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

Funzionali [FUN]

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

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

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

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

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

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

Classi definitive

Figura 8: Classi definitive

La classe Activity pur essendo stata inserita all’interno

dell’insieme delle classi definitive, è già presente nella piattaforma
openwork®.
 56

6.2 Casi d’uso

6.2.1 Diagrammi

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

Si ispezionano i requisiti funzionali al fine di far emergere le
funzionalità del sistema in relazione ad ogni singolo attore.

Mapping

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

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

Diagramma dei casi d’uso

Figura 9: Diagramma dei casi d'uso

 59

6.2.2 Dettaglio casi d’uso

1. Show Dynamic Groups

L’utente deve avere la possibilit{ di consultare l’elenco dei Gruppi

Dinamici inseriti nella piattaforma.

ACTORS

Business Flow Modeler.

USE CASE INTERACTION

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

2. Delete Unused Dynamic Groups

L’Application Server, allo scatenarsi di uno specifico evento, deve

provvedere automaticamente a cancellare i gruppi dinamici
dichiarati nel modello di processo, ma non utilizzati da quest’ultimo.

ACTORS

Application Server.

USE CASE INTERACTION

Use Case Relation Direction

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

PERCORSI ALTERNATIVI

None

REQUISITI TRACCIATI

OWK-FUN-0002
 61

3. Create Dynamic Group

L’utente deve avere la possibilità di inserire un Gruppo Dinamico

nella piattaforma.

ACTORS

Business Flow Modeler.

USE CASE INTERACTION

Use Case Relation Direction
Link Dynamic Group to Activity Extend To
Formal Control of Accuracy Include To

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

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

REQUISITI TRACCIATI

OWK-FUN-0001
 62

4. Update Dynamic Group

L’utente deve avere la possibilit{ di modificare un Gruppo

Dinamico inserito nella piattaforma.

ACTORS

Business Flow Modeler.

USE CASE INTERACTION

Use Case Relation Direction
Show Dynamic Groups Extend To
Formal Control of Accuracy Include To

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

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

REQUISITI TRACCIATI

OWK-FUN-0005
 63

5. Link Dynamic Group to Activity

L’utente deve avere la possibilità di associare un Gruppo

Dinamico inserito nella piattaforma ad un’attivit{ nel Business Flow
Designer.

ACTORS

Business Flow Modeler.

USE CASE INTERACTION

Use Case Relation Direction
Show Dynamic Groups Extend From
Update Dynamic Group Extend From
Create Dynamic Group Extend From

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

PERCORSI ALTERNATIVI

None

REQUISITI TRACCIATI

OWK-FUN-0003
 64

6. Formal Control of Accuracy

L’Application Server deve controllare la correttezza formale della

definizione di un Gruppo Dinamico. Un Gruppo Dinamico è
formalmente corretto quando gli operatori logici presenti nelle
condizioni sono ben bilanciati e quando le condizioni coinvolgono
attributi che sono utilizzabili sulla piattaforma. Ogni piattaforma può
utilizzare un set diverso di attributi. E’ necessario pertanto
controllare che la espressione del gruppo dinamico faccia
riferimento solo ad attributi che possono essere interpretati dalla
piattaforma.

ACTORS

Application Server.

USE CASE INTERACTION

Use Case Relation Direction
Create Dynamic Group Include From
Update Dynamic Group Include From
Publish Process Model Include From

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

PERCORSI ALTERNATIVI

None

REQUISITI TRACCIATI

OWK-FUN-0006
 65

7. Publish Model

Questo caso d’uso non è oggetto di questo documento. Per questa

ragione non verrà descritto.

ACTORS

Business Flow Modeler.

USE CASE INTERACTION

Use Case Relation Direction
Formal Control of Accuracy Include From

SCENARIO

None

PERCORSI ALTERNATIVI

None

REQUISITI TRACCIATI

None
 66

8. Request Access

Questo caso d’uso non è oggetto di questo documento. Per questa

ragione non verrà descritto.

ACTORS

Web Client User.

USE CASE INTERACTION

Use Case Relation Direction
Verify affiliations of dynamic group Include To

SCENARIO

None

PERCORSI ALTERNATIVI

None

REQUISITI TRACCIATI

None
 67

9. Verify affiliations of dynamic group

L’utente che utilizza il Web Client richiede l’accesso al sistema.

All’atto della richiesta dell’accesso al sistema, tra le tante
funzionalità che il sistema gli espone c’è quella di proporre la lista
delle attivit{ in carico. Questo particolare caso d’uso riguarda
l’insieme di quelle attivit{ proposte, che coinvolgono l’utente poiché
questi è parte di un gruppo dinamico associato ad un’attivit{ in
esecuzione. In particolare questo caso d’uso sta ad indicare la
funzionalit{ di verifica dell’appartenenza ad un gruppo dinamico.
Iterando questo procedimento per tutti i gruppi dinamici presenti, è
facile ottenere l’elenco di tutti i gruppi dinamici ai quali l’utente
appartiene.

ACTORS

Application Server.

USE CASE INTERACTION

Use Case Relation Direction
Request Access Include From

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

PERCORSI ALTERNATIVI

None

REQUISITI TRACCIATI

OWK-FUN-0007
 68

10. Affiliated Users of a Dynamic Group

L’Application Server è in grado di valutare l’espressione di un

determinato gruppo dinamico ed estrarre una lista di partecipanti
attivi: tutti e soli quelli che soddisfano le condizioni del gruppo.
Questa attività è estremamente onerosa in termini di risorse
consumate e per questa ragione ha un limitatissimo campo di
applicabilità.
In generale questa funzionalità verrà utilizzata solo per
particolari tipi di attività che non costituiscono la maggior parte di
quelli in esecuzione.

ACTORS

Application Server.

USE CASE INTERACTION

Use Case Relation Direction

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

PERCORSI ALTERNATIVI

None

REQUISITI TRACCIATI

OWK-FUN-0007
 69

Capitolo 7:
Conclusioni

Dopo aver studiato la fattibilità e dopo aver analizzato

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

7.1 Possibili sviluppi futuri

Lo stage nella Net Sistemi srl è durato giusto il tempo necessario

per comprendere la logica dell’intera piattaforma, approfondire il
dominio applicativo (a me totalmente sconosciuto prima di allora) e
redigere un documento di analisi dei requisiti completo.
Per questa ragione, il naturale sviluppo di questa tesi consisterà
nel procedere con le restanti fasi del ciclo di sviluppo del software:
progettazione, codifica e test.
 70

7.1.1 Uso trasversale delle espressioni

Un interessante sviluppo della soluzione precedentemente

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

7.1.2 Information Retrieval

I gruppi dinamici, per come sono stati analizzati sono un fattore

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

Appendice
 72

A UML

In ingegneria del software, UML (Unified Modeling Language,

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

A.1 Storia

I linguaggi per la modellazione object-oriented iniziarono a

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

indipendentemente all’OMG da un gruppo composto da IBM,

ObjectTime, Ptech e altre.

A.2 Caratteristiche speciali

La notazione UML è semi-grafica e semi-formale; un modello UML

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

A.3 Applicazioni

Di per sé, UML è solo un linguaggio di modellazione, e non

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

B XML

L’XML, acronimo di eXtensible Markup Language, ovvero

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

nodo radice che contiene tutti gli altri. Se il documento è well-formed

e in più rispetta i requisiti strutturali definiti nel DTD o nell’XML
Schema si dice Valid.

B.1 Strumenti aggiuntivi per XML

L’XML non si esaurisce qui: esistono diversi strumenti legati

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

• XQuery: è un linguaggio di query concepito per essere

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

Glossario ed Acronimi

.NET Tecnologia di programmazione ad oggetti versatile

di Microsoft.
API Application Programming Interface
BPEL Business Process Execution Language
BPM Business Process Management
BPMN Business Process Management Notation
COM+ Component Object Model; Piattaforma Microsoft
per componenti software
CSS Cascading Style Sheets
DCOM Distributed Component Object Model; Piattaforma
Microsoft per le component software distribuite
DOM Document Object Model
Failover È un sistema di salvataggio nel quale le funzioni di
una componente di un sistema (come ad esempio
un processore, un server, una rete un database e
altri) vengono inviate ad una seconda componente
quando la prima ha un problema. Viene utilizzato
per rendere i sistemi più resistenti ai problemi di
errori
FTP File Transfer Protocol
HCI Human-Computer Interaction
HTML Hyper Text Markup Language
HTTP Hyper Text Transfer Protocol
HTTPS Hyper Text Transfer Protocol Secure
 80

ISO International Organization for Standardization

KPI Key Performance Indicator
MDA Model Driven Architecture
MEGA MEGA International azienda leader nell’area del
BPM
OMG Object Management Group
OMT Object Modeling Technique
OWK Openwork abbreviazione utilizza nello standard
aziendale di documentazione
PDF Portable Document Format
SAX Simple API for XML
SOA Service Oriented Architecture
SOAP Simple Object Access Protocol
SVG Scalable Vector Graphics
UML Unified Modeling Language
Undo Funzione mediante la quale è possibile annullare le
ultime modifiche eseguite
UNI Ente Nazionale Italiano di Unificazione
VTD-XML Virtual Token Descriptor for eXtensible Markup
Language
W3C World Wide Web Consortium
WS Web Service
WSDL Web Services Description Language
XML eXtensible Markup Language
XPDL eXtensible Process Description Language
XSD XML Schema
XSL eXtensible Stylesheet Language
XSL-FO XSL Formatting Objects
XSLT XSL Transformations
 81

Bibliografia

1. The Workflow Management Coalition. 2007 BPM & Workflow

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

[Online] Gennaio 16, 2003. http://xml.coverpages.org/OMG-03-01-

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