wkf applicazioni

POLITECNICO DI MILANO
V Facoltà di Ingegneria
Corso di Laurea in Ingegneria Informatica
Studio e realizzazione di primitive per la specifica di processi
sul Web
Relatore: Prof. Stefano Ceri
Correlatore: Prof. Marco Brambilla
Tesi di Laurea di:
Tiziano Furlan Matr. 651362
Giuseppe Giordano Matr. 653657
Anno Accademico 2003/2004
Indice
1 Introduzione ................................................................................. 1
1.1
Premessa .................................................................................................. 1
1.2
Obiettivi della tesi.................................................................................... 2
1.3
Struttura della tesi .................................................................................... 3
2 Il Modello WebML ...................................................................... 4
2.1
Cos’è WebML ......................................................................................... 5
2.2
Visione d’insieme sui modelli WebML .................................................. 6
2.3
Modello di struttura ................................................................................. 7
2.3.1
Tipi di dati .......................................................................................................... 9
2.3.2
Attributi .............................................................................................................. 9
2.3.3
Entità................................................................................................................... 9
2.3.4
Relazioni ............................................................................................................. 9
2.4
Modello di composizione ...................................................................... 10
2.4.1
Source entity e selector ..................................................................................... 11
2.4.2
Pagine ............................................................................................................... 12
2.5
Modello di navigazione ......................................................................... 13
2.5.1
Link................................................................................................................... 14
2.5.2
Non-contestual link .......................................................................................... 14
2.5.3
Automatic e Transport link ............................................................................... 14
3 Workflows................................................................................... 16
3.1
Cos’è un Workflow ............................................................................... 17
3.2
Workflow Management System ............................................................ 17
3.2.1
Il processo manuale .......................................................................................... 19
3.2.2
Il processo automatizzato ................................................................................. 19
3.2.3
Terminologia .................................................................................................... 20
3.2.4
Tipi di Workflow .............................................................................................. 21
3.2.4.1
Production Workflow.................................................................................... 21
I
Indice
3.2.4.2
Workflow Engine autonomi .......................................................................... 21
3.2.4.3
Embedded Workflow ..................................................................................... 22
3.2.4.4
Administrative Workflow .............................................................................. 22
3.2.4.5
Collaborative Workflow ............................................................................... 22
3.2.4.6
Ad hoc Workflow .......................................................................................... 23
3.2.5
Considerazioni .................................................................................................. 23
3.2.6
Workflow Reference Model ............................................................................. 24
3.3
Linguaggi e notazione per i workflow .................................................. 25
3.3.1
Orchestrazione e Coreografia ........................................................................... 25
3.3.2
BPML ............................................................................................................... 26
3.3.3
BPMN ............................................................................................................... 26
4 WebRatio Site Development Studio ......................................... 32
4.1
Introduzione a WebRatio....................................................................... 33
4.2
L’architettura di WebRatio .................................................................... 33
4.3
Progettazione di dati e ipertesto ............................................................ 34
4.4
Mapping dei dati .................................................................................... 36
4.5
Progettazione della presentazione ......................................................... 36
4.6
Generazione del codice.......................................................................... 38
4.7
Estensione attraverso unit personalizzate .............................................. 38
4.7.1
Cos’è una unit personalizzata ........................................................................... 38
4.7.2
La progettazione di unit personalizzate ............................................................ 39
5 Ipertesti guidati da Workflow in WebML .............................. 41
5.1
Requisiti di una applicazione Workflow-Driven Hypertext ................. 42
5.1.1
Modello di processo ......................................................................................... 43
5.1.2
Modello dei dati ................................................................................................ 44
5.1.3
Modello dell’ipertesto ...................................................................................... 44
5.2
Workflow: terminologia ........................................................................ 44
5.2.1
Processo ............................................................................................................ 44
5.2.2
Attività .............................................................................................................. 45
5.3
Definizione dei dati nei Workflow ........................................................ 46
5.3.1
5.3.1.1
Workflow data meta-model .............................................................................. 46
Entity Process ............................................................................................... 46
\
II
Indice
5.3.1.2
Entity Case.................................................................................................... 47
5.3.1.3
Entity Case Status ......................................................................................... 47
5.3.1.4
Entity Activity ............................................................................................... 47
5.3.1.5
Entity Activity Instance ................................................................................. 47
5.3.1.6
Entity Activity Instance Status ...................................................................... 47
5.3.2
5.4
Workflow data meta-model and application data model .................................. 48
Workflows nel modello di ipertesto ...................................................... 49
5.4.1
Inizio e fine di attività e case ............................................................................ 49
5.4.2
Start and end activities...................................................................................... 49
5.4.2.1
Input per la start activity unit ....................................................................... 50
5.4.2.2
Output della start activity unit ...................................................................... 50
5.4.2.3
Input della end activity unit .......................................................................... 50
5.4.2.4
Output della end activity unit ....................................................................... 50
5.4.3
Start e end cases................................................................................................ 51
5.4.4
Units per il Workflow driven navigation paths: if and switch ......................... 52
5.4.4.1
Switch unit .................................................................................................... 52
5.4.4.2
If unit ............................................................................................................ 52
5.4.5
Workflow-aware index unit .............................................................................. 53
5.4.6
Assign di oggetti alle activity instances ........................................................... 54
5.4.7
Controllo dello stato di una activity instance ................................................... 54
5.5
Progettazione di un Workflow-Driven Hypertext ................................. 55
5.5.1
Metodologie di implementazione ..................................................................... 56
5.6
Esempio ................................................................................................. 57
5.7
Controllo Implicito ................................................................................ 57
5.7.1
Utilizzo della politica pull ................................................................................ 57
5.7.2
Utilizzo della politica push .............................................................................. 60
5.8
Controllo esplicito ................................................................................. 62
5.8.1
Utilizzo della politica pull ................................................................................ 62
5.8.2
Utilizzo della politica push ............................................................................... 63
6 Progettazione e implementazione delle unit di Workflows .... 67
6.1
Il modello dei dati .................................................................................. 68
6.1.1.1
Le relazioni tra User e Activity Instance ...................................................... 69
6.1.1.2
La relazione tra Group e Activity Instance .................................................. 69
\
III
Indice
6.2
Progettazione e implementazione delle unit.......................................... 69
6.2.1
Start Activity Unit ............................................................................................ 70
6.2.2
End Activity Unit ............................................................................................. 72
6.2.3
Expression Parsing Unit – Test Unit ................................................................ 74
6.2.4
Workflow Index Unit ....................................................................................... 79
6.2.5
Assign Unit ....................................................................................................... 81
6.2.6
Get Activity Status Unit ................................................................................... 84
7 L’applicazione Web Online Publications ................................. 86
7.1
Descrizione dello scenario..................................................................... 88
7.2
Lista degli attori ..................................................................................... 89
7.2.1
Utente generico ................................................................................................. 89
7.2.2
Autore ............................................................................................................... 89
7.2.3
Direttore ............................................................................................................ 90
7.2.4
Impiegato .......................................................................................................... 90
7.2.5
Editore .............................................................................................................. 90
7.3
Activity List e Workflow ...................................................................... 91
7.3.1
7.4
Il workflow dell’applicazione........................................................................... 92
L’applicazione ....................................................................................... 92
7.4.1
Il modello entità–relazione ............................................................................... 92
7.4.1.1
Entità User.................................................................................................... 94
7.4.1.2
Entità Publication ......................................................................................... 94
7.4.1.3
Entità Photo .................................................................................................. 95
7.4.1.4
Entità Employee Comment ........................................................................... 95
7.4.1.5
Entità Author Comment ................................................................................ 95
7.4.1.6
Entità TextChunk .......................................................................................... 96
7.4.2
Struttura dell’applicazione................................................................................ 96
7.4.2.1
Public site-view ............................................................................................ 96
7.4.2.2
Author site-view ............................................................................................ 97
7.4.2.3
Director site-view ....................................................................................... 102
7.4.2.4
Employee site-view ..................................................................................... 103
7.4.2.5
Publisher site-view ..................................................................................... 104
8 Conclusioni ............................................................................... 106
8.1
Sviluppi futuri ...................................................................................... 106
\
IV
Indice
1
Sintassi .................................................................................................... 108
2
Grammatica ............................................................................................. 108
3
Tipi di variabili ....................................................................................... 109
4
Operatori ................................................................................................. 110
5
Funzioni predefinite ................................................................................ 111
5.1
6
Funzioni matematiche......................................................................................... 111
Altre funzioni .......................................................................................... 111
6.1
7
Funzioni SQL ..................................................................................................... 111
6.1.1
Sum ............................................................................................................. 111
6.1.2
Maximum .................................................................................................... 111
6.1.3
Minimum ..................................................................................................... 112
6.1.4
Average ....................................................................................................... 112
6.1.5
Count .......................................................................................................... 112
Funzioni operanti sulle date .................................................................... 112
7.1
Sum of dates ....................................................................................................... 112
7.2
Compare Dates ................................................................................................... 113
7.3
Today .................................................................................................................. 113
8
Esempi ..................................................................................................... 113
9
Il formato delle date ................................................................................ 114
9.1
Esempi ................................................................................................................ 115
\
V
1 Introduzione
1.1 Premessa
Questa tesina è stata sviluppata presso il dipartimento di Elettronica e Informazione del
Politecnico di Milano. Essa è stata svolta come lavoro finale del corso di Laurea di primo
livello in Ingegneria Informatica presso la V Facoltà di Ingegneria del Politecnico di Milano.
Diversi sono stati gli strumenti e i linguaggi utilizzati durante lo svolgimento di questa
tesi.
In primo luogo sono stati utilizzati il linguaggio di modellazione per applicazioni Web
WebML e il tool di sviluppo WebRatio. WebML è un linguaggio concettuale che permette di
progettare applicazioni Web basate sui dati attraverso l’utilizzo dei costrutti in esso definiti.
Essendo WebML un linguaggio di alto livello, che prescinde quindi dai dettagli
dell’architettura, si è fatto uso di WebRatio. Esso è uno strumento CASE (Computer Aided
Software Engineering) volto alla progettazione e allo sviluppo di siti Web centrati sui dati
(data-intensive), basato sul linguaggio di specifica WebML. L’intero processo di
progettazione è supportato dallo strumento CASE, esso è in grado di generare
automaticamente le pagine del sito partendo da specifiche di alto livello.
Oltre ai normali costrutti presenti in WebML, sono stati utilizzati dei costrutti facenti
parte di una delle estensioni del linguaggio. L’estensione presa in considerazione è quella
riguardante i Workflow; essa permette di definire ipertesti basati su di essi attraverso l’utilizzo
della notazione grafica tipica di WebML. Infatti, visto l’enorme successo dei sistemi di
gestione di Workflow e in particolare di quelli basati sul Web, si è deciso di concentrare il
lavoro sull’analisi di questa particolare estensione del linguaggio e della corrispettiva
estensione del tool WebRatio.
1
Introduzio
1.2 Obiettivi della tesi
Questo lavoro di tesi si è concentrato sull’analisi del modello per Workflow di WebML
con l’obiettivo di individuare le limitazioni e i problemi di questa particolare estensione . Una
volta individuati questi ultimi si è cercato di capire quali potessero essere gli eventuali
miglioramenti da apportare ai costrutti e alla struttura del modello dei dati.
A questo proposito è stato ideato un Workflow ad hoc con lo scopo di mettere in rilievo
i problemi ed imprecisioni dell’attuale estensione. Basandosi poi su di esso, è stato creato
grazie al tool di sviluppo un ipertesto. La progettazione di quest’ipertesto ha messo in risalto
tutti i problemi presenti nell’estensione per WebRatio che per mettere di definire ipertesti.
Una volta individuati i punti deboli delle unit, che rappresentano i costrutti WebML in
WebRatio, e della struttura del modello dei dati, si è passati alla ricerca delle necessarie
soluzioni. Durante questa parte del lavoro è stato quindi necessario modificare il codice
sorgente del tool allo scopo di salvaguardare la correlazione tra i costrutti WebML e le
relative unit di WebRatio.
Dopo aver modificato l’estensione del tool di sviluppo, l’ipertesto è stato riprogettato in
maniera coerente alle modifiche apportate. Come previsto durante la fase di studio delle
modifiche, le migliorie hanno permesso di semplificare notevolmente la struttura del sito
progettato con il linguaggio grafico, ma soprattutto è stato possibile realizzare delle parti
dell’ipertesto in modo molto più semplice ed intuitivo. Inoltre le modifiche al modello dei dati
hanno permesso di utilizzare con maggiore efficienza il database rendendolo più adatto non
solo all’utilizzo in questo particolare ipertesto, ma in qualsiasi altro ipertesto basato sui
Workflow che implementa processi aziendali.
Lo sviluppo dell’applicazione Web ha costituito una parte rilevante del lavoro. Essa ha
permesso di capire meglio cosa rappresentano i Workflow in teoria e in quali casi concreti
possano essere utilizzati. Attraverso la realizzazione dell’applicazione Web è stato possibile
capire quelli che sono ancora i limiti di questo tipo di sistemi.
Al termine del lavoro sopra descritto, grazie all’esperienza accumulata con il Workflow
da noi ideato e con l’ipertesto realizzato, abbiamo cercato di capire quali potessero essere gli
sviluppi futuri riguardanti i Workflow e la relativa estensione WebML.
2
Introduzio
1.3 Struttura della tesi
La tesi presenta il lavoro analizzando, nel capitolo 2, il modello WebML, utilizzato per
la specifica concettuale di ipertesti. In questo capitolo il linguaggio viene analizzato
abbastanza dettagliatamente in quelli che sono i suoi costrutti fondamentali in modo da fornire
una visione chiara del linguaggio e delle sue potenzialità ed utilizzi.
Nel capitolo 3, invece, vengono trattati i sistemi di gestione dei Workflow e come essi
possano essere utilizzati in casi concreti. Vengono quindi analizzati gli standard per la
rappresentazione concettuale dei Workflow e in particolare quello proposto dalla Workflow
Management Coalition.
Dopo aver presentato il linguaggio e i Workflow, nel capitolo 4, viene descritto il tool
di sviluppo utilizzato per la realizzazione dell’applicazione Web basata sui dati.
Il capitolo 5, uno dei più importanti della tesi, espone l’estensione per la realizzazione
dei Workflow in WebRatio. Nei sottoparagrafi vengono descritte le varie unit che permettono
di costruire il Workflow e vengono esposti i problemi riscontrati durante il loro utilizzo.
Nel capitolo 6 viene esposto tutto il lavoro svolto sul codice sorgente dell’estensione
del tool di sviluppo al fine di sopperire alle carenze riscontrate nelle unit durante lo sviluppo
dell’applicazione.
Nel capitolo 7 viene infine presentata in maniera dettagliata l’applicazione Web
sviluppata e i vantaggi che si sono ottenuti a seguito della modifica del programma WebRatio.
Infine nel capitolo 8 vengono esposte le conclusioni a cui siamo giunti alla fine del
lavoro svolto ed esposti i possibili sviluppi e miglioramenti auspicabili nel futuro.
3
2 Il Modello WebML
Gli odierni siti Web data-intensive [1] sono progettati con metodologie sottratte a
differenti settori, ma manca un modello guida di supporto allo sviluppo, con l’inevitabile
conseguenza che parte del codice è scritta manualmente. La necessità di aumentare il livello
d’astrazione appare dunque contingente, si vuole giungere ad avere tecniche di analisi dei dati
e di progetto di alto livello, invece di occuparsi della codifica manuale di pagine web. Inoltre,
in questo modo è possibile concentrarsi sull’ottimizzazione e sull’analisi delle prestazioni. Un
approccio alla modellazione più rigoroso consente di ridurre tempo e costi di sviluppo ed i
risultati finali potrebbero essere più utilizzabili e coerenti; inoltre la prototipazione potrebbe
essere immediata.
La specifica e il progetto dell’applicazione devono coprire una varietà di differenti
prospettive: l’organizzazione dei dati, la composizione delle pagine, la facilità di navigazione,
l’aspetto grafico del sito e l’interazione con servizi esterni.
Nell’area della progettazione di applicazioni web non è ancora emerso un linguaggio
standard per la modellazione, WebML mira a sopperire a questa mancanza ed a fornire un
approccio strutturato al progetto di siti Web data-intensive.
Figura 1 - Processo di sviluppo di una applicazione Web con WebML
4
Il Modello WebML
2.1 Cos’è WebML
WebML (Web Modelling Language) è un linguaggio concettuale per la specifica e la
progettazione di applicazioni data-intensive [2].
In particolare WebML definisce una notazione per la specifica e la progettazione di un
sito Web e per la pubblicazione automatica a partire dalle specifiche ad alto livello. Il
linguaggio fornisce una serie di costrutti, specificati formalmente mediante XML, per
descrivere la realtà d’interesse ad alto livello senza tenere conto dei dettagli architetturali.
WebML consente di specificare la struttura del contenuto di una applicazione web e di
descrivere l’organizzazione e la presentazione di ogni contenuto in un ipertesto.
Il modello UML (Unified Modelling Language) nell’ambito dei sistemi object-oriented
ed il modello Entità-Relazione in quello delle applicazioni orientate ai dati, devono il loro
successo alla presenza di una notazione grafica, più immediata di quella linguistica.
Il processo di progettazione e sviluppo WebML è supportato da un ambiente di lavoro
grafico in cui il connubio tra costrutti del linguaggio e notazione grafica consente una
rappresentazione intuitiva del sito da sviluppare.
I principali obiettivi del processo di progetto WebML sono:

Esprimere la struttura di un applicazione web con una descrizione ad alto
livello che possa essere utilizzata per il mantenimento e lo sviluppo del sito.

Fornire molteplici viste dello stesso contenuto.

Separare il contenuto d’informazione dalla propria composizione nelle pagine,
dalla navigazione e dalla presentazione, che possono essere definite e
sviluppate separatamente (logica a tre livelli).

Conservazione delle informazioni raccolte in fase di progetto in un repository,
che può essere utilizzato durante il ciclo di vita dell’applicazione per la
successiva generazione dinamica delle pagine web.

Modellare utenti e gruppi esplicitamente nel repository per consentire politiche
di personalizzazione.

Abilitare la specifica di operazioni di manipolazione dei dati per la modifica
del contenuto del sito o per l’interazione con arbitrari servizi esterni.
5
Il Modello WebML
2.2 Visione d’insieme sui modelli WebML
La realizzazione di un sito Web può essere schematizzata individuando diversi modelli
ortogonali, ciascuno dei quali permette di focalizzare l’attenzione del progettista su una
particolare dimensione, senza interferire con le altre [3].
Figura 2 - I modelli WebML
Questi modelli sono:

Modello strutturale: descrive l’organizzazione concettuale dei dati trattati, in
maniera compatibile con il diffuso modello Entità-Relazione e con diagrammi
UML.

Modello di derivazione: consente l’estensione del modello strutturale mediante
la definizione di dati ridondanti allo scopo di adattarlo ai differenti requisiti.

Modello dell’ipertesto: permette la descrizione di uno o più ipertesti pubblicati
nel sito e può essere ulteriormente suddiviso in:
o Modello di composizione: comprende le pagine di cui è composto un
ipertesto e la loro organizzazione interna in unità d’informazione
elementare (content unit).
o
Modello di navigazione: descrive i link tra le pagine e le content unit
allo scopo di creare un contesto informativo in cui l’utente durante la
navigazione viene facilitato nella ricerca delle informazioni.
Gli ipertesti definiti attraverso il modello di composizione e navigazione sono racchiusi
in costrutti di modularizzazione chiamati site-view. Ogni site-view rappresenta un differente
punto di vista dei dati dell’applicazione, al fine di soddisfare un insieme ben definito di
requisiti che coprono i differenti interessi dei gruppi di utenti.
6
Il Modello WebML

Modello di presentazione: descrive come appaiono graficamente le pagine web
indipendentemente dal linguaggio usato per la loro pubblicazione.

Modello utente: definisce gli utenti ed i gruppi di utenti che avranno accesso al
sito.

Modello di personalizzazione: permette di adattare i contenuti del sito ai
diversi tipi di soggetti che ne faranno accesso, mediante una combinazione di
utilizzo di dati derivati, modellizzazione degli utenti e regole di alto livello
(business rules).
I modelli visti sopra permettono la descrizione di siti in sola lettura ma possono essere
estesi per permettere la specifica di operazioni in scrittura e l’esecuzione di operazioni
generiche realizzate da programmi esterni.
Le operazioni di update vengono definite all’interno del modello dell’ipertesto e
costituiscono un’aggiunta ad esso. Vengono invocate come side-effect della navigazione,
percorrendo collegamenti appositamente progettati (activating link) e permettono di
specificare i comuni schemi di interazione come riempimento di maschere, gestione dei dati
personali e carrelli per il commercio elettronico.
L’idea fondamentale da cui si parte è la separazione tra i dati che un sito Web deve
visualizzare sia dall’ipertesto, che definisce come vengono esplorati i dati attraverso la
navigazione dell’utente, sia dalla presentazione grafica e multimediale dei dati. Questa
separazione viene poi raffinata, nella fase di progettazione, nel seguente modo:
Dati
Struttura + Derivazione
Ipertesto
Composizione + Navigazione
Presentazione
Presentazione
2.3 Modello di struttura
Il data design è una fondamentale attività di costruzione di applicazioni data–intensive
che consente al progettista di comprendere e formalizzare l’organizzazione dei dati utilizzati
dalle applicazioni. L’obiettivo del data-design è la rappresentazione degli oggetti essenziali
del dominio dell’applicazione, delle loro proprietà e delle relazioni tra essi [4]. Il risultato di
questa fase è uno schema di progetto che fornisce una rappresentazione facile e intuitiva della
conoscenza a disposizione circa i dati dell’applicazione.
Il modello di struttura è un adeguazione dei modelli concettuali per il data design, come
già in uso in altre discipline come, ad esempio, l’ingegneria del software.
7
Il Modello WebML
Il modello di struttura è compatibile con il modello dei dati Entità–Relazione e con i
diagramma delle classi UML. Gli elementi essenziali sono le entità, definite come contenitori
di dati, e le relazioni, definite come connessioni semantiche tra le entità.
Le entità hanno delle proprietà, chiamate attributi, che hanno associato un tipo di dato.
Le istanze sono univocamente indirizzabili per mezzo di un unique identifier (OID), noto
anche con il nome di chiave.
Le entità possono avere un’organizzazione gerarchica e le relazioni possono essere
ristrette per mezzo di limiti di cardinalità. Il WebML model consente al progettista di
esprimere sottoentità di un entità data mediante gerarchia is-a.
In Figura 3 è rappresentato un esempio di struttura dati di un sito in cui sono
visualizzate: le entità che rappresentano gli utenti ed i possibili gruppi, l’entità Product,
Combination, BigImage e TechRecord.
Ogni prodotto può avere:

“0” o “N” combinazioni

“0” o “N” BigImage

“0” o “1” Technical Record
Invece ogni technical Record e ogni BigImage sono legati ad uno specifico prodotto.
Figura 3- Rappresentazione Grafica della struttura dati di un sito
8
Il Modello WebML
2.3.1 Tipi di dati
I dati che rappresentano gli oggetti WebML sono sempre contraddistinti da un tipo, che
può assumere diversi valori: Oltre ai classici domini del mondo delle basi di dati (String,
Text, Integer, Float, Date, Boolean) sono presenti alcuni tipi specifici per le applicazioni
WebML: URL, Blob. WebML non prescrive rigidamente i tipi di dati da utilizzare, che
possono variare in differenti implementazioni.
2.3.2 Attributi
Gli attributi sono utilizzati nel modello WebML con l’obiettivo di rappresentare le
proprietà degli oggetti del mondo reale che sono gestiti nel sito. Questi corrispondono agli
attributi del modello Entità–Relazione e agli attributi di classe nel modello UML. Ogni
attributo ha un tipo.
2.3.3 Entità
Le entità sono i costrutti base del modello concettuale WebML; ogni entità è associata
ad un insieme di oggetti del mondo reale, le cui proprietà sono descritte dagli attributi.
2.3.4 Relazioni
Le relazioni rappresentano associazioni semantiche tra entità. La notazione WebML
supporta relazioni binarie senza attributi che connettono solo due entità. Comunque un
numero arbitrario di relazioni, con ID distinti, possono collegare due entità.
Le relazioni hanno i limiti di cardinalità minCard e maxCard: definiscono
rispettivamente la cardinalità minima e massima di una relazione, ovvero il numero di
esemplari dell’entità di destinazione a cui ciascuna istanza dell’entità sorgente può essere
legata. Se minCard assume il valore zero, la relazione è opzionale, altrimenti è obbligatoria. I
valori predefiniti di questi due attributi sono rispettivamente zero e “N”.
Inoltre WebML offre alcune convenzioni opzionali per assegnare nomi significativi alle
relazioni e alle coppie di relazioni diretta/inversa.
Relazioni N-arie e relazioni con attributi
WebML non fornisce notazioni ad hoc per esprimere relazioni che coinvolgono più di
due entità (chiamate relazioni N-arie), o per relazioni con attributi. In ogni caso questi
costrutti avanzati possono comunque essere rappresentati utilizzando una combinazione di
entità e di relazioni binarie.
9
Il Modello WebML
L’equivalenza delle relazioni N-arie e delle relazioni con attributi con gli stessi concetti
espressi utilizzando solo relazioni binarie è possibile attraverso l’utilizzo di un’entità
intermedia con i necessari attributi.
2.4 Modello di composizione
Lo scopo del modello di composizione è definire quali nodi compongono l’ipertesto
pubblicato in un sito Web [5]. In particolare il modello di composizione specifica :

Quali pagine compongono l’ipertesto.

Gli elementi atomici di informazione attualmente fornite all’utente, le units.

Site-view: una site-view è un modulo che definisce una modalità di accesso
ai dati. Tramite più site-view è possibile distinguere l’utente non registrato,
dall’amministratore del sito o da altri tipi di utente, fornendo una visione del
sito completamente diversa anche se basata sugli stessi dati. È inoltre
possibile usare le site-view per creare modalità di navigazione
specificatamente pensate per un client di navigazione, ad esempio per un
normale browser su PC, per un cellulare Wap, o per un browser a sintesi
vocale.
Le unit, possono stare all’interno delle pagine o all’esterno delle pagine. Le unit interne
aggiungono alla pagina dei contenuti visibili, tipicamente prelevati dalla struttura dati, ma è
anche possibile visualizzare dati che sono temporaneamente memorizzati in variabili
temporanee globali. Le unit fuori pagina eseguono operazioni di modifica, aggiornamento ed
eliminazione delle informazioni o altre operazioni legate alla navigazione dei siti (ad esempio
tutte le unit che consentono la gestione dei Workflow).
WebML supporta cinque tipi di unit [6] per comporre un ipertesto di sola lettura:

DataUnit: mostra le informazioni di un singolo oggetto; più precisamente,
permette di visualizzare l’istanza di un’entità.

MultiDataUnit: mostra le informazioni di un set di oggetti; permette di
visualizzare i dati relativi a più istanze di un’entità.

IndexUnit: permette di definire e visualizzare indici di accesso ai dati; mostra
una lista di proprietà descrittive di alcuni oggetti,senza presentare le
informazioni di dettaglio di ogni oggetto.

ScrollerUnit: visualizza i dati relativi a più istanze tramite una navigazione del
tipo “avanti/indietro - primo/ultimo”.
10
Il Modello WebML

EntryUnit: modella una entry form, i cui campi prelevano valori in input (non
necessariamente inseriti da un utente di tipo umano) necessari per effettuare
ricerche o per introdurre dati di modifica.
Le data unit sono usate per mostrare le informazioni di un singolo oggetto (istanza di
un’entità o componente), mentre le rimanenti rappresentano modi alternativi di sfogliare un
insieme di oggetti.
Le unità di informazione sono definite basandosi sul modello di struttura: il progettista
specifica l’entità, il componente o la relazione su cui ciascuna unità si basa.
Il tipico schema di una pagina WebML è un grafo di unità, in cui le data unit, mostranti
il contenuto di un oggetto, si alternano alle altre permettendo varie forme di interconnessione
tra oggetti correlati.
L’associazione tra entità e data unit è di tipo uno a molti; la stessa entità può essere
associata a diverse data unit, ciascuna mostrante un diverso insieme di attributi dell’entità.
Perciò, le data unit rappresentano diverse “viste virtuali” su concetti definiti nel modello di
struttura, adattabili a diversi requisiti.
Le entry unit servono per visualizzare o modificare informazioni ma soprattutto per
inserire nuovi dati attraverso maschere di inserimento.
Index, multidata e scroller unit sono tipicamente usate per specificare strutture di
accesso al contenuto del sito e per raggruppare in una pagina diversi frammenti correlati di
informazione. Questi tipi di unità possono essere definiti su una relazione 1:N, nel qual caso
permettono forme alternative di navigazione da un oggetto ad un insieme di oggetti ad esso
correlati. Queste unità possono anche essere definite su entità o componenti, permettendo di
selezionare un oggetto tra quelli contenuti. Come ultimo passo del progetto del modello di
composizione, tutte le pagine che definiscono una vista del sito Web (rispondenti cioè alle
esigenze di uno specifico gruppo di utenti) vengono raggruppate in un singolo elemento,
chiamato vista di sito (site-view).
2.4.1 Source entity e selector
Le unità di contenuto (content unit) sono collegate allo schema strutturale. WebML usa
due concetti per esprimere l’origine di una content unit: il concetto di entità sorgente (source
entity) e di selettore (selector).
L’entità sorgente indica il tipo di entità dello schema strutturale utilizzato e
rappresentata il nome dell’entità da cui è estratto il contenuto dell’unità. Le istanze di questa
entità verranno utilizzate per popolare il contenuto della unit.
11
Il Modello WebML
I selettori, invece, sono condizioni usate per determinare le istanze attuali della source
entity che contribuiscono a popolare la unit. Per esempio, la Figura 4 mostra un entità con
source entity (Album) e con selector costituito da una condizione booleana ([year=2000]).
Figura 4- Notazione grafica per la content unit
Il significato della Figura 4 è che la index unit deve contenere solo album che hanno
l’attributo Year uguale alla costante 2000.
2.4.2 Pagine
Sono gli effettivi elementi di interfaccia forniti all’utente che visualizza l’ipertesto
accedendo alle sue pagine secondo una sequenza non definita a priori.
Una pagina tipicamente consiste di diverse unità, unite insieme per raggiungere un ben
definito scopo comunicativo.
Una pagina è l’astrazione di una regione di schermo che viene trattata come un
elemento atomico di interfaccia con l’utente; può essere autonomamente trasmessa al browser
o ricaricata dall’utente. Un concreto esempio di realizzazione del concetto astratto di pagina
potrebbe essere un frame in HTML.
La relazione che lega unità e pagine è di contenimento. Nel caso più semplice, ogni
pagina contiene una sola unità, ma in molti casi una singola pagina contiene diverse unità, per
esempio la data unit di un artista e l’indice degli album che ha pubblicato, che necessitano di
essere visualizzate contemporaneamente per una migliore organizzazione dell’interfaccia. Le
unità in una pagina possono essere collegate tra loro, per permettere la corretta computazione
del loro contenuto.
Nell’esempio seguente Album Page è una pagina che contiene una index unit
AlbumIndex, che mostra una lista di Album e una data unit Album Info che visualizza i dati
di un album.
12
Il Modello WebML
Figura 5- Notazione grafica WebML per le pagine e relativa sua resa in HTML
Come in molte applicazioni, le pagine possono essere spezzate in sottopagine
indipendenti tra loro e trattate come elementi indipendenti per quanto riguarda la
presentazione. Una pagina può contenere unità oppure ricorsivamente altre pagine. Le pagine
innestate possono essere in forma congiuntiva (AND) oppure disgiuntiva (OR): nel primo
caso le sottopagine vengono mostrate contemporaneamente, mentre nel secondo la
visualizzazione di ciascuna sottopagina esclude quella delle altre. Le pagine in AND/OR
permettono di rappresentare molte strutture complesse. Il caso più semplice è quello in cui
una porzione di schermo viene tenuta fissa (ad es. il frame di sinistra in una pagina HTML) e
un’altra porzione mostra informazioni variabili in base ai comandi dell’utente)
Sebbene WebML sia un modello ad alto-livello, parliamo brevemente degli aspetti di
implementazione di unità e pagine:in una concreta messa in opera. In un sito web HTML,
dinamicamente costruito per mezzo di un linguaggio scripting come JSP o ASP, le unit
corrispondono a frammenti di script e le pagine a page templates. Tipicamente, ogni unità
corrisponde a una query su un database obiettivo; quando una pagina è richiesta
dinamicamente, le query corrispondenti alle sue unit sono eseguite ed il contenuto attuale
viene costruito e presentato all’utente.
2.5 Modello di navigazione
Le unità e le pagine non possono esistere da sole senza essere connesse a formare un
significativa struttura d’ipertesto. Gli ipertesti reali sono insiemi di pagine collegate con parti
interconnesse e con comandi che consentono all’utente di interagire con le applicazioni.
Lo scopo del modello di navigazione è quello di fornire il modo in cui le unità e le
pagine sono collegate per creare un determinato flusso informativo.
La principale nozione del modello di navigazione è quella di link (contestuale, non
contestuale, di trasporto).
13
Il Modello WebML
2.5.1 Link
Un link è una connessione diretta tra unità o tra pagine e può assolvere i seguenti
compiti:

Cambiare la pagina visualizzata.

Trasportare informazioni tra un’unità o pagina ad un’altra unità o pagina.

Produrre un side-effect.
L’informazione trasportata da un link è chiamata contesto di navigazione. I link che
trasportano un contesto si definiscono link contestuali, mentre quelli a cui non è associata
nessuna informazione prenderanno il nome di link non contestuali.
Le informazioni di contesto sono tipicamente necessarie per assicurare la computabilità
del contenuto di un’unità. Ad esempio, una data unit che mostra i dettagli di un artista può
essere collegata ad una index unit che mostri un indice di album pubblicati. Per calcolare la
lista di album pubblicati dall’artista mostrato dalla data unit, l’identificativo di tale artista
deve essere trasferito alla index unit.
2.5.2 Non-contestual link
La Figura 6 mostra un link non contestuale che connette due pagine. Il link connette
una pagina sorgente (PopArtistPage) contenente una multidata unit che mostra gli artisti pop,
con una pagina (JazzArtistPage) destinazione contenente una multidata unit che mostra gli
artisti jazz. Il contenuto della pagina PopArtistPage è indipendente dal contenuto della pagina
JazzArtistPage, quindi la navigazione non richiede che sia passato nessun parametro dalla
sorgente alla destinazione.
Figura 6 - Esempio di uso di link non contestuale
2.5.3 Automatic e Transport link
I link automatici sono link che non richiedono che l’utente definisca il link parameter
perché è il sistema che in grado di capire il tipo di parametro da passare. Tutti i link visti
14
Il Modello WebML
finora, infatti, richiedono, per poter essere utilizzati, che l’utente clicchi su di essi. Ci sono
casi in cui un link è usato semplicemente per trasportare informazione e non è dunque
utilizzato per la navigazione. Questo tipo di link è chiamato link di trasporto, per sottolineare
il fatto che il link serve solo per il passaggio dei parametri e non per la navigazione
dell’utente. La Figura 7 mostra un esempio di link di trasporto: la pagina CelineDionAlbums
contiene una data unit ArtistDetails, la quale contiene i dettagli dell’artista, e la index unit
PublishedAlbums che contiene la lista degli album che ha pubblicato.
CelineDionPage
CelineDionAlbums
ArtistDetails
PublishedAlbums
ARTIST
ALBUMS
FirstName: Celine
° All the way
° New day has come
LastName: Dion
Photo:
Artist
[FirstName="Celine"]
[LastName="Dion"]
Album
[ ArtistToAlbum ]
° Hits of ...
° Colour of ...
Figura 7 - Esempio di transport link e sua resa in pagine HTML
15
3 Workflows
Workflow è una preziosa tecnologia, ma è anche una disciplina, un modo di fare e un
concetto. Negli ultimi cinque anni il WfMC (Workflow Management Coalition) [7] ha
compiuto notevoli sforzi affinché nel mondo si affermasse una comune consapevolezza di che
cosa realmente è un workflow, e cosa invece non è. In questi cinque anni, la tecnologia e il suo
utilizzo pratico si sono sviluppati e maturati sostanzialmente.
Col passare del tempo, quindi, il concetto di workflow si è andato via via più
affermando e il suo utilizzo nei più svariati campi è sempre maggiore. In questo capitolo
quindi cercheremo di spiegare e descrivere qual è l’attuale concezione di workflow in maniera
SVC
Empl
Mgr
Cust
semplice e chiara.
Figura 8 - Un esempio di workflow
16
Workflows
3.1 Cos’è un Workflow
Il Workflow Management Coalition è l’organizzazione, costituita da più di 300
membri, che si occupa di promuovere i workflow e il loro sviluppo in tutto il mondo. Nel
1996 ha pubblicato un glossario contenente tutti i termini utili relativi ai workflow. Il WfMC
stesso dà la seguente definizione di workflow:
L’automazione di un processo, in ogni sua parte, durante il quale documenti,
informazioni, o compiti vengono passati da un attore ad un altro attraverso
azioni, coerentemente a delle regole procedurali.
Nei primi workflow, il lavoro veniva passato da un attore ad un altro. Il vantaggio
principale era che il lavoro svolto veniva consegnato agli altri attori, e ogni attore poteva
considerare il materiale a lui giunto pronto per essere elaborato da parte sua. Questo era
possibile in quanto il workflow system non consentiva ad un attore di consegnare materiale ad
un altro attore senza prima aver completato il proprio compito. Quindi la consegna era
automatizzata.
La maturazione della tecnologia dei workflow ha permesso di automatizzare il processo
in sé, ad esempio del materiale di lavoro o un insieme di documenti viene creato e viene
processato e modificato in determinati punti del processo con lo scopo di raggiungere
l’obiettivo prefissato. Attualmente esistono quindi numerosi workflow engine, essi possono
gestire serie molto complesse di processi, inoltre è possibile esprime una serie di condizioni
matematiche, che possono essere utilizzate e gestite dai workflow system presenti attualmente
sul mercato.
Un Workflow, normalmente, comprende un numero di operazioni, ognuna delle quali
viene chiamata activity. Una activity può comportare una interazione tra i vari attori del
workflow, oppure può essere eseguita automaticamente da determinate macchine. La
consegna del lavoro da svolgere a chi di competenza aumenta notevolmente l’efficienza del
processo, ma automatizzare il lavoro stesso porta ad un incremento ancora maggiore.
3.2 Workflow Management System
Nel Medioevo, i monaci seduti ad un tavolo copiavano minuziosamente le scritture. I
padri superiori assegnavano i compiti ai vari monaci preferendo il più abile per la prima
pagina di un capitolo o del libro. Negli ultimi secoli poco è cambiato, i supervisori continuano
ad assegnare i compiti ai propri sottostanti in base al loro allenamento, abilità ed esperienza.
17
Workflows
Le persone incaricate di svolgere i compiti con il passare del tempo hanno potuto usufruire di
strumenti sempre più potenti (basti pensare alla macchina da scrivere e poi al computer).
L’utilizzo di strumenti da parte delle persone ha permesso di aumentare l’efficienza del
processo, tuttavia il modo di controllare e supervisionare i vari lavoratori non ha subito
drastici cambiamenti nel corso del tempo.
Negli ultimi 15 anni però, sono stati sviluppati nuovi strumenti che permettono di
gestire il workflow in maniera più efficiente. Adesso quindi il processo può gestito da un
software che assegna i compiti, li assegna ai vari attori e tiene traccia dei progressi dei loro
progressi.
Possiamo dare quindi la seguente definizione di Workflow Management System [8]:
Un sistema che definisce, crea e gestisce l’esecuzione di un workflow attraverso
l’utilizzo di software e di uno o più workflow engine, che è abile di interpretare la
definizione di un processo, interagire con gli attori del workflow e , dove
richiesto, invocare l’uso di strumenti IT e applicazioni.
Può sembrare una eccessiva semplificazione dire che un WMS (Workflow Management
System) gestisce un workflow. Tuttavia, un WMS può avere diverse caratteristiche, che vanno
dalla comune interpretazione della definizione di un Workflow, alla gestione di trigger,
allarmi e interazioni con sistemi esterni. E’, inoltre, importante notare che mentre questa
definizione copre tutto lo spettro dei workflow system, esclude semplici sistemi di database
relazionali e meccanismi di posta elettronica con invio programmabile delle e-mail.
Se la migliore persona che svolge il più importante compito segue le procedure
corrette, l’organizzazione è condotta in maniera più efficiente, i costi diminuiscono e il
servizio al cliente generalmente migliora notevolmente. Se il lavoro è equamente distribuito e
si ha la sicurezza che si sta svolgendo un lavoro in maniera corretta, gli utenti sono più
soddisfatti. Per questi motivi un Workflow è un ottima soluzione dal punto di vista di molte
aziende, dei clienti e degli utenti.
Infatti con sistemi automatizzati di gestione dei processi:

Maggiore efficienza - l’automazione dei processi di business permette di
eliminare passaggi non necessari

Miglior controllo del processo – il miglioramento nella gestione dei processi di
business viene raggiunto attraverso la standardizzazione dei metodi di lavoro e
la continua verifica del lavoro svolto

Miglioramento del servizio offerto ai clienti – la coerenza e la consistenza dei
processi portano ad una maggiore prevedibilità nei livelli di risposta al cliente
18
Workflows

Flessibilità – l’utilizzo di software per il controllo dei processi permette la
riprogettazione in tempo reale secondo le necessità

Aumento della qualità del processo di business – l’attenzione sui processi di
business porta ad uno snellimento e una semplificazione degli stessi
Per capire meglio dove può agire un WMS diamo una rapida occhiata ad uno scenario
di un dipartimento aziendale che riceve richieste di prestiti, li classifica e controlla, e infine
decide se soddisfare la richiesta. Si noti che processi sono stati semplificati per dimostrare
l’impatto che i Workflow hanno su di essi. Analizziamo ora i due possibili casi
d’implementazione:

Manuale (ossia senza l’ausilio dei Workflow).

Automatico.
3.2.1 Il processo manuale
Una richiesta arriva per posta ed è classificata e distribuita ad uno dei molti impiegati
che ne verificano la correttezza. La richiesta può essere rispedita al mittente per avere
maggiori informazioni, rifiutata subito, oppure accettata. L’impiegato quindi potrà immettere i
dati della richiesta nel sistema informativo dell’azienda, per passarla all’impiegato successivo.
Il processo di accettazione di una richiesta di prestito può includere fino ad otto sotto processi.
In alcune aziende, c’è un impiegato o un team d’impiegati per ogni sotto processo; in altre
aziende, un impiegato gestisce tutti i compiti per una singola richiesta. Può diventare difficile
capire qual è lo stato corrente di ogni richiesta (la gestione di un carico di lavoro è in
relazione diretta con il numero del personale: più lavoro c’è, più personale è necessario
all’azienda). La richiesta può avere un sovrintendente in ogni punto del processo.
Tipicamente, un sovrintendente ricontrolla la richiesta e tutta la relativa documentazione
prima di accettare definitivamente la richiesta.
3.2.2 Il processo automatizzato
Il richiedente visita il sito web dell'azienda: gli vengono fornite tutte le informazioni
necessarie per decidere se e come procedere e poi compila il modulo di richiesta. La
tecnologia assicura che tutti i campi obbligatori siano compilati. L’azienda riceve una
richiesta, che è un insieme di dati creati dal cliente. La prima attività del workflow è
controllare la validità del modulo di richiesta e mandare una e-mail al cliente, ringraziandolo
per la sua richiesta e fornendogli un numero di riferimento. La richiesta è “clonata” in modo
che il WMS possa eseguire più attività in parallelo, riducendo il tempo speso per gestire
ognuna di esse e migliorando il servizio per il cliente. Le implementazioni del workflow
19
Workflows
hanno ridotto enormemente il tempo di lavoro. Dieci anni fa era ragionevole aspettare una
settimana buona per avere una risposta ad una richiesta di prestito: ora il richiedente ha una
risposta quasi istantanea. Da settimane, il tempo di risposta è sceso all’ordine delle ore! Con il
workflow che esegue il lavoro di routine, il manager deve solo gestire le eccezioni. La logica
dei motori dei workflow è capace di decidere se un prestito può essere garantito o meno. Con
i workflow, la base di una decisione può essere determinata automaticamente, 24 ore su 24.
Questo sta diventando requisito fondamentale per l’e-commerce. I clienti si aspettano di poter
contattare l’azienda e fare “affari” ad ogni ora del giorno. E-commerce significa anche che
un’azienda può avere opportunità di vendita in ogni parte del mondo. Il WMS aggiornerà
automaticamente anche gli altri sistemi. Testando in maniera buona il sistema, l’errore umano
sarà eliminato. Il WMS guida le applicazioni a creare lettere di rifiuto o d’accettazione, e
contratti per i prestiti. I WMS supervisionano il processo d’approvazione e portano le altre
applicazioni a distribuire i documenti elettronicamente via fax o e-mail
3.2.3 Terminologia
Tutti i Workflow Management Systems sono process oriented. Una definizione di un
processo (process definition) consiste nella creazione di un diagramma che lo rappresenti,
tipicamente poi è composto da diversi sotto processi. Un esempio di processo può essere la
valutazione di una richiesta di prestito da parte di una banca. Questo processo può essere
diviso in sotto processi come la verifica che la richiesta sia completata in ogni sua parte,
l’esecuzione di un controllo del credito del richiedente, la creazione di un nuovo contratto, la
spedizione del contratto al cliente, il controllo del contratto rispedito all’azienda, la messa a
punto del pagamento, e l’esecuzione del pagamento. Ogni processo e sotto processo
comprende delle attività. Una attività è un singolo passo logico del processo. Fare un
pagamento o non fare un pagamento è un'attività. Non è sempre utile automatizzare tutte le
attività di un processo. Il workflow system esegue le attività automatizzate mentre il process
definition descrive tutte le attività, automatizzate e manuali. Per esempio, se la legge dicesse
che i contratti per prestiti devono essere firmati davanti ad una terza parte neutrale, questa
sarebbe un’attività manuale del processo. I Business Process vengono discussi
dettagliatamente all’interno di gruppi, gli addetti all’IT generalmente partecipano alla
valutazione del business process, così come persone che curano gli aspetti legali e quelli
relativi ai costi. Una volta ottenuto il consenso generale, il process definition è inserito in un
WMS. Quando il process definition è stato testato e messo in produzione, vengono create le
istanze di quel processo. Il process definition descrive come un prestito è garantito
dall’organizzazione; l’istanza di un processo comprende activity instance che includono work
20
Workflows
item allocati ad un attore del workflow o all’utente, o ad un altro processo. Così un utente può
ricevere tutti i documenti relativi ai prestiti e avere il compito di approvarli. Alternativamente
l’activity instance potrebbe invocare una query su un sistema di credit checking, prendere il
risultato e valutarlo a seconda dei criteri predefiniti e passare alla prossima attività un risultato
binario (approved o declined).
3.2.4 Tipi di Workflow
Che tipo di Workflow si dovrebbe usare? Dipende da ciò che si vuole ottenere. Molte
organizzazioni usano più di un prodotto che riguarda i workflow fornito da diverse aziende,
ma non è inusuale per le aziende usare lo stesso prodotto in maniere differenti. Sono state
proposte molte segmentazioni diverse: quelle proposte di seguito non sono esaustive, ma sono
utili per capire le principali funzionalità di un WMS.
3.2.4.1 Production Workflow
L’obiettivo del Production Workflow è di gestire un gran numero di task simili, e di
ottimizzare la produttività. Questi obiettivi sono raggiunti automatizzando tante più attività
possibile, fino a raggiungere un livello di Straight-Through-Processing in cui le persone sono
utilizzate solo per gestire eccezioni, cioè quei work item che stanno al di fuori di
predeterminate tolleranze del processo. Gli eventi che richiedono l’intervento dell’uomo sono
minimizzati, così come la difficoltà e la durata dell’intervento. Il Production Workflow è
ottimizzato per ottenere un alto livello di qualità e accuratezza, grazie all’esecuzione di task
ripetitivi, tipicamente a ciclo continuo. Un Production Workflow può gestire processi
complessi, e può essere fortemente integrato con sistemi legacy esistenti. Infatti, il trend è
quello di integrare componenti per Workflow in grandi applicazioni, il cui ruolo è quello di un
Rules Engine. Questo ci porta ad una nuova segmentazione all’interno di Production
Workflow.
3.2.4.2 Workflow Engine autonomi
Un Workflow Management System autonomo, senza applicazioni software addizionali,
è funzionale ad eccezioni di sistemi di gestione di database e code di messaggi. Per
implementare una soluzione che comprenda Workflow autonomi, le applicazioni esterne
devono essere chiamate a runtime. I dati rilevanti per il Workflow vengono passati tra gli
attori del Workflow. Sistemi di gestione di Workflow autonomi sono pezzi separati
d’applicazioni software che forniscono le funzionalità tipiche dei Workflow. Tipicamente
hanno una loro interfaccia utente e accedono ai dati tramite altre applicazioni. Questi sistemi
21
Workflows
supportano di norma una gran varietà d’applicazioni. La progettazione d’applicazioni
riguardanti Workflow autonomi richiede di specificare delle informazioni d’interfaccia con le
applicazioni chiamate, le strutture dei dati rilevanti e gli attori coinvolti; per questi motivi tali
applicazioni sono molto complesse.
3.2.4.3 Embedded Workflow
Un Embedded Workflow Management System è utile solo se impiegato con un sistema
che lo integra, ad esempio un ERP (Enterprise Resource Planning). Le funzionalità di un
workflow integrato sono mostrate dal sistema che lo integra. Esempi tipici sono sistemi ERP e
sistemi di pagamento. I componenti che riguardano i Workflow sono utilizzati per controllare
la sequenza delle funzioni delle applicazioni, per gestire code e per aiutare il processamento
delle eccezioni.
3.2.4.4 Administrative Workflow
La caratteristica più importante di un workflow amministrativo è la libertà di
definizione dei processi. Tipicamente, esistono molte definizioni di processi eseguite in
maniera concorrente e tendono a coinvolgere un gran numero d’impiegati. Definizioni di
processi sono create tipicamente grazie all’uso dei moduli particolari, e se la definizione è
troppo complessa per un modulo si può utilizzare un altro prodotto. La flessibilità è più
importante della produttività, e sistemi del genere gestiscono un numero di istanze per ora,
minore di uno o due ordini di grandezza rispetto a sistemi di Production Workflow.
3.2.4.5 Collaborative Workflow
I workflow collaborativi si focalizzano su gruppi di persone che lavorano insieme per
raggiungere gli stessi obiettivi. I gruppi possono variare da piccoli team orientati al progetto, a
persone che hanno solo gli stessi obiettivi in comune. L’uso di workflow collaborativi per
supportare il lavoro di squadra è considerato uno dei principali elementi di successo nelle
imprese di ogni tipo. L’uso di Internet e del World Wide Web per supportare le
comunicazione tra i vari team nell’azienda è anche un fattore critico di successo per molte
imprese. Il throughput non è una caratteristica peculiare e le definizioni di processi non sono
rigide e possono essere modificate frequentemente. Il Collaborative Workflow può anche
essere chiamato Groupware. D’altro canto, ci sono certi tipi di groupware che non sono
Workflow, ad esempio videoconferenza e bacheche.
22
Workflows
3.2.4.6 Ad hoc Workflow
Sistemi di Workflow ad hoc permettono agli utenti di creare e modificare i Process
Definition in modo facile e veloce, per venire incontro ad ogni tipo di casistica. Così è
possibile avere tante definizioni di processi quante sono le istanze di queste definizioni. Un
sistema ad hoc Workflow massimizza la flessibilità nelle aree dove il throughput e la
sicurezza non sono caratteristiche fondamentali. Mentre in un Production Workflow
l’organizzazione possiede tutti i processi, in un ad hoc Workflow ogni utente ha il proprio
processo.
3.2.5 Considerazioni
Come in molte classificazioni, anche in questa esistono eccezioni e aree oscure. Ad
esempio, alcuni sistemi di produzione supportano modifiche dinamiche in una singola istanza
di un processo, modifiche che possono riguardare anche le singole attività, fornendo
funzionalità che stanno a metà tra un Production e un Ad hoc Workflow System. Il nostro
progetto resta al di fuori da questa classificazione. Può essere considerato in ogni tipo di
Workflow che abbiamo descritto, perché comprende il potere di creare applicazioni proprio
del linguaggi WebML e i concetti dei Workflow che estendono le capacità espressive di
WebRatio. La soluzione che forniamo può essere classificata come un Autonomous
Workflow Engine poiché offre le funzionalità di un tool di progettazione di alto livello per
produrre un’applicazione e un insieme di primitive per integrare un sistema di controllo tipico
dei Workflow; inoltre ha la possibilità di interagire con ogni applicazione esterna grazie al
meccanismo delle plug-in unit. Può essere utilizzato come un Administrative Workflow
System, grazie alla semplice progettazione e capacità di sviluppo proprie di WebRatio.
Progettare un nuovo Workflow sarà rapido e semplice grazie al tool di progettazione di alto
livello. Le caratteristiche dei Collaborative Workflow sono assicurate dal fatto che
produciamo applicazioni basate sul Web. Infine l’obiettivo di questo progetto è quello di
integrare i concetti di controllo tipici dei Workflow, lo sviluppo delle applicazioni con
WebRatio e il runtime di WebRatio, apportando le seguenti caratteristiche:

Semplice e rapido sviluppo di un processo.

Semplice e facile definizione e sviluppo delle applicazioni.

Un sistema integrato per gestire sia le applicazioni sia le regole dei Workflow.

Semplice integrazione con applicazioni esterne grazie alle plug-in unit, e il supporto
dei web service.

Applicazioni basate sul Web: collaborazione e distribuzione.
23
Workflows
3.2.6 Workflow Reference Model
Nel 1996, lo U.S. Department of Defense sponsorizzò uno studio iniziale per avviare il
lavoro del WfMC nel campo della definizione di un modello di riferimento per l’interazione
dei Workflow. Il risultato di questo lavoro è stato il Workflow Reference Model, che descrive
cinque interfacce [9]. Queste interfacce illustrano come un Workflow system dovrebbe
interagire con altri Workflow system, ma fondamentalmente sono utilizzate per definire le
capacità del sistema. Analizzandole si ha:

Process Definition Interface. Fondamentalmente si occupa della definizione
delle interfacce standard che permettono la comunicazione tra i Process
Definition tool e i Workflow engine.

Workflow Client Application Interface. Definiscono gli standard necessari
affinché una applicazione client esterna possa accedere alle funzioni offerte dal
workflow enactment services.

Invoked Application Interface. Questa interfaccia è per quelle applicazioni che
sono state costruite per interagire direttamente con il workflow engine.

Workflow Inter Operability Inteface. Definisce quei meccanismi che i vendors
dei prodotti di Workflow devono implementare per far sì che un Workflow
engine possa fare richieste ad altri Workflow engine per selezionare, istanziare
o avviare delle process definition conosciute da un altro Workflow engine.

System Administration & Monitoring Interface. Attraverso quest’interfaccia è
possibile analizzare e controllare diversi workflow engine.
Figura 9 - Reference Model definito dal WFMC per i Workflow
24
Workflows
3.3 Linguaggi e notazione per i workflow
Fino ad ora abbiamo parlato di cosa sono i workflow e come possono essere utilizzati
nella realtà soprattutto in un contesto aziendale. Se grazie agli sforzi del W f MC si è arrivati a
una visione comune di cosa sono e come possono essere utilizzati, altrettanto non si può dire
riguardo ai linguaggi e alle notazioni utilizzabili per la descrizione di un workflow.
In questo paragrafo introdurremo i concetti di orchestrazione e coreografia e parleremo
brevemente dei linguaggi più diffusi per rappresentarli. Tratteremo invece in maniera più
approfondita il linguaggio e soprattutto la notazione da noi scelta per la rappresentazione del
workflow su cui è basata l’applicazione Web che abbiamo sviluppato.
3.3.1 Orchestrazione e Coreografia
L’industria ha da sempre utilizzato vari termini per descrivere come i componenti
possono essere collegati tra di loro al fine di costruire un processo. I Workflow Management
Systems stessi sono nati dall’esigenza di poter gestire un processo che coinvolgesse più risorse
appartenenti all’organizzazione. Queste risorse potevano essere persone, o sistemi e
applicazioni e tipicamente richiedevano l’intervento umano.
Inoltre con la nascita dei web services termini come web services composition e web
services flow si sono sempre più affermati e vengono usati per descrivere la composizione tra
web services e i process flow.
In questo contesto nascono i termini Orchestration e Choreography. L’orchestrazione
descrive come i servizi interagiscono tra di loro a livello di messaggi scambiati, compreso la
logica applicativa e l’ordine di esecuzione delle interazioni. Queste interazioni possono
coinvolgere più applicazioni e/o organizzazioni. Il risultato che ne deriva, consiste nella
specifica di un processo di business “long-running” di alto livello che descrive una
applicazione eseguibile da un proprietario.
La coreografia invece tiene traccia della sequenza di messaggi che può coinvolgere più
applicazioni e organizzazioni. Essa punta a fornire una rappresentazione più collaborativa
delle interazioni dove ogni attore descrive la sua parte.
La differenza principale tra i due concetti consiste nel fatto che l’orchestrazione si
riferisce a un processo di business che può interagire con servizi interni ed esterni, mentre
l’orchestrazione il processo è sempre controllato dalla prospettiva di una delle parti. La
coreografia presuppone invece che ogni parte coinvolta nel processo descriva la parte da lui
ricoperta nell’interazione [10].
25
Workflows
Esistono molti linguaggi attraverso i quali è possibile descrivere i concetti sopra
esposti. Tutti i linguaggi da noi proposti sono basati su XML e coprono sia la coreografia che
l’orchestrazione. Possiamo dire che non esiste ancora un linguaggio dominante. La nostra
scelta per la descrizione del workflow è caduta su BPML mentre la notazione è quella BPMN.

XLang (Microsoft BizTalk language)

WSFL (Web Services Flow Language)

WSCL (Web Services Conversation Language)

BTP (Business Transaction Protocol)

ebXML (Electronic Business using XML)

WSCI (Web Services Choreography Interface)

BPEL4WS (Business Process Exec. Lang. for WS)

BPML + BPMN (Business Process Management Language + Notation)
Tralasciamo la descrizione dei vari linguaggi citati, alcuni dei quali orientati ai Web
Services, in quanto esula dallo scopo di questa tesi. Presentiamo però il linguaggio da noi
utilizzato.
3.3.2 BPML
Il Business Process Management Language (BPML) è un meta-linguaggio per la
descrizione dei processi. La specifica è stata sviluppata dal Business Process Management
Initiative (BPMI.org), una organizzazione indipendente [11].
BPML era stato inizialmente creato per la descrizione dei processi di business che
potevano essere eseguiti da un sistema BPMS. La prima specifica del linguaggio incorporava
anche il protocollo WSCI. Essi possono essere quindi usati congiuntamente, il WSCI può
descrivere le interazioni pubbliche e la coreografia, mentre il BPML le implementazioni
private. Quindi sia il BPML e il WSCI condividono lo stesso modello di esecuzione di
processo e una sintassi simile.
3.3.3 BPMN
L’obiettivo del BPMN è quello di fornire una notazione per la modellazione dei
processi di business che sia utilizzabile dagli analisti, sviluppatori e dirigenti che gestiscono e
monitorano i processi. Un obiettivo del BPMN è anche quello di poter generare le definizioni
dell’esecuzione che possano essere usate per implementare un processo di business. Il BPMN
quindi rappresenta un ponte tra la modellazione e l’esecuzione e tra le persone che eseguono il
business e i creatori del sistema che lo supporta.
26
Workflows
BPMN permette di creare un diagramma del processo che rappresenta le attività del
processo e il flusso di controllo che definisce l’ordine in cui debbano essere eseguite.
Attraverso il BPMN, il BMPI consortium che lo ha sviluppato ha cercato di trovare il miglior
compromesso possibile tra una notazione intuitiva e una notazione completa di tutte le
possibili regole comunemente utilizzate [12].
Il BPMN consente di specificare 3 tipi di processi:

Private (internal) business processes: questo tipo di processi, in genere interni
all’organizzazione, sono costituiti da una serie di attività, com’è possibile
osservare nella figura sottostante.

Abstract (public) processes:in questi processi invece abbiamo un’interazione tra
il processo ed un attore esterno. In questo tipo di processo sono mostrate quindi
solo le attività interessanti per la comunicazione con l’esterno.
27
Workflows
 Collaboration (global) processes: come mostrato nella figura nei processi
collaborativi sia ha l’interazione tra due o più processi.
28
Workflows
3.3.3.1.1 Simboli BPMN – Activity, Subprocess, Pool e Lane
Nella figura sottostante sono rappresentati i simboli che identificano le attività, i
sottoprocessi e le aree in cui sono contenute le attività di ogni partecipante.
3.3.3.1.2 Simboli BPMN – Eventi
I simboli sottostanti raffigurano i possibili eventi che possono essere inseriti in un
diagramma workflow, come ad esempio l’inizio o la fine di un processo.
TYPE DIMENSION:
FLOW DIMENSION:
29
Workflows
3.3.3.1.3 Simboli BPMN – Flussi
3.3.3.1.4 Simboli BPMN – Gateway
I gateway sono i simboli attraverso i quali vengono rappresentati vincoli logici presenti
nel workflow, come ad esempio attività in or o in and. Come è possibile i simboli BPMN non
fanno distinzione tra split e join ma possono essere utilizzati in entrambi i casi
indifferentemente.
30
Workflows
3.3.3.1.5 Simboli BPMN – Looping
A2
cond
Cycle: ciclo esplicito
con uso di gateway
A3
3.3.3.1.6 Simboli BPMN – altri
31
4 WebRatio Site Development Studio
WebRatio Site Development studio è uno strumento CASE (Computer Aided Software
Engineering) concepito specificamente per lo sviluppo di applicazioni web mediante
modellizzazione concettuale. Esso adotta WebML come modello espressivo visuale per
specificare contenuti, navigazione e business logic delle applicazioni web.
Lo scopo di WebRatio è quello di enfatizzare la procedura di analisi dei requisiti e
prototyping nel processo di sviluppo, in modo da fornire uno strumento che permetta di
affrontare eventuali nuovi requisiti o cambiamenti di richieste, senza ridisegnare
completamente l’applicazione ma semplicemente modificando il modello concettuale e
rigenerando l’applicazione.
Figura 10 - Processo di sviluppo di un'applicazione con WebRatio
WebRatio non è solo un tool, ma una metodologia completa che assiste lo sviluppatore
in tutto il ciclo di vita dell’applicazione.
32
WebRatio Site Development Studio
4.1 Introduzione a WebRatio
WebRatio copre le fasi di progettazione dei dati e dell’ipertesto, in particolare si
focalizza su cinque aspetti principali:

Progettazione dei dati: supporta il progetto dello schema dei dati Entità –
Relazione con un interfaccia grafica utente per il disegno e la specifica di entità,
relazioni, attributi e generalizzazioni gerarchiche.

Progettazione dell’ipertesto: fase di progetto delle site-view, che fornisce
funzioni per specificare le proprietà di aree, pagine unità e link.

Mapping dei dati: permette di dichiarare un insieme di data-source su cui gli
schemi dei dati concettuali sono mappati e automaticamente trasla i diagrammi
Entità relazione e le espressioni OCL nei database relazionali e in viste.

Progettazione della presentazione: Offre funzionalità per definire il
presentation style di un’applicazione, permettendo al progettista di creare XSL
style sheets e associarli con le pagine e organizzare il page layout, disponendo
le relative posizioni delle content unit nelle pagine.

Generazione di codice: Trasformazione automatica di site-view in applicazioni
Web funzionanti costruite sopra piattaforme Java2EE, Sruts e .NET.
4.2 L’architettura di WebRatio
La Figura 11 richiama l’architettura globale di WebRatio [13], che si distingue
chiaramente in tre grosse componenti:

WebRatio Site Development Studio, che supporta le attività a design-time dello
sviluppo di un’applicazione, ovvero la specifica delle site-view e la generazione
del relativo codice.

WebRatio Code Generator, un generatore di codice basato su XSL che
trasforma automaticamente le specifiche XML dei page templates in descrittori
di deployment per la piattaforma J2EE. Il motore XSL integrato genera tutto il
codice necessario incluso l’accesso ai dati, la business logic e la presentation.

Il supporto a runtime di WebRatio, che permette l’esecuzione delle applicazioni
generate da WebRatio Site Development Studio offrendo un ricco framework
per page templates e business components.
33
WebRatio Site Development Studio
Figura 11 - Schematizzazione dell'architettura di WebRatio
4.3 Progettazione di dati e ipertesto
WebRatio fornisce un’interfaccia grafica che consente ai progettisti di comporre sia il
diagramma Entità-Relazione sia le site-view dell’applicazione.
La Figura 12 mostra una schermata dell’interfaccia utente di WebRatio che è
organizzata nelle quattro aeree tipiche dei software per lo sviluppo delle applicazioni:

Un albero di progetto (riquadro in alto a sinistra), in cui sono organizzati tutti
gli elementi del progetto dell’applicazioni.

Un’area di lavoro (riquadro in alto a destra), dove le specifiche possono essere
modificate in modo visuale.

Un pannello delle proprietà (riquadro in basso a sinistra), dove è possibile
impostare le proprietà dei singoli elementi.
34
WebRatio Site Development Studio

Un’area messaggi (riquadro in basso a destra), in cui vengono mostrati
messaggi e segnalazioni d’errore.
In particolare, la Figura 12 mostra il diagramma Entità-Relazione che viene creato
quando si sceglie di lavorare su un nuovo progetto basato sui workflow.
Figura 12 - Progettazione dei dati in WebRatio
L’area di lavoro contiene lo schema dei dati, in cui il progettista può definire entità,
attributi, relazioni e gerarchie di generalizzazione. Gli elementi mostrati nel diagramma sono
presenti anche nell’albero di progetto, dove sono organizzati in modo gerarchico all’interno di
cartelle. Le proprietà dell’elemento dello schema correntemente selezionato sono visibili e
modificabili dal pannello delle proprietà. La stessa organizzazione e interfaccia grafica
supporta la modifica dei diagrammi delle site-view.
Un progetto WebRatio è composto da un singolo diagramma Entità-Relazione e da un
insieme di site-view. A ciascun progetto viene automaticamente aggiunto un modello dei dati
predefinito, il progettista può estenderlo con entità e relazioni aggiuntive. La progettazione di
una site-view è invece svolta gestendo graficamente gli elementi dell’ipertesto come unit,
pagine, aree, link, selettori e parametri di contesto.
35
WebRatio Site Development Studio
4.4 Mapping dei dati
WebRatio assiste la fase d’implementazione dei dati consentendo di associare
l’applicazione alle sorgenti dati in cui risiedono i contenuti. In particolare WebRatio supporta
le tre architetture di dati principali: basi di dati dedicata, replicata e in linea. Il massimo livello
d’assistenza è fornito per la soluzione con basi di dati dedicata. La connessione con la
sorgente dati sfrutta le interfacce di programmazione JDBC e ODBC, è possibile comunque
aggiungere ulteriori tipi di connessione.
L’attività d’implementazione dei dati procede attraverso un meccanismo di mapping
del diagramma Entità-Relazione sulle sorgenti dati definite; l’utente dichiara le sorgenti dati, e
collega entità e relazioni alle tabelle. Le informazioni di mapping che associano entità,
relazioni e attributi con tabelle e colonne, sono memorizzate in un file XML.
Se la base di dati per i contenuti applicativi non esiste, WebRatio è in grado di generare
automaticamente la base di dati standard.
Tutte le entità, le relazioni e gli elementi derivati devono essere mappati correttamente
prima di generare il codice ed eseguire l’applicazione, altrimenti la generazione del codice
può produrre risultati incorretti. WebRatio, infatti, è in grado di verificare l’allineamento tra il
diagramma Entità-Relazione e le basi di dati fisiche, facilitando così la gestione delle
modifiche in ciascuno dei due livelli.
4.5 Progettazione della presentazione
La progettazione della presentazione consiste nella definizione dei fogli di stile XSL
contenenti le regole di presentazione necessarie al generatore di codice per produrre i template
di pagina. WebRatio fornisce le funzionalità sia per selezionare stili di presentazione da una
libreria già esistente e associarli alle pagine dell’applicazione, sia per trasformare
automaticamente delle pagine HTML disegnate da un esperto di grafica in fogli di stile XSL.
Un foglio di stile XSL consiste in un insieme di regole XSL che governano il modo in
cui l’intera pagina e i vari tipi di unit vengono generati. Per rendere riusabili i fogli di stile
XSL in pagine con contenuti differenti, le regole XSL non si riferiscono alle singole unit di
ogni pagina, ma includono la specifica delle posizioni nella struttura della pagina in cui le unit
possono essere inserite. Una volta che un foglio di stile è selezionato per una pagina,
WebRatio consente di specificare l’accoppiamento delle unit di pagina con le posizioni
disponibili dichiarate dal foglio di stile, con un’interfaccia grafica che permette di trascinare
le unti stesse nelle posizioni desiderate, come mostrato in Figura 13.
36
WebRatio Site Development Studio
Per ogni unit posizionata nella pagina, e perfino per ogni attributo, link contestuale e
campo di una unit, è possibile selezionare un foglio di stile XSL differente, che definisce lo
stile di presentazione specifico da usare per la resa grafica del singolo elemento.
Figura 13 - Posizionamento delle unit di pagina nelle zone dichiarate nel foglio di stile XSL
I fogli di stile XSL per pagine e unit possono essere scritti a mano da un
programmatore XSL, oppure possono essere generati automaticamente da pagine HTML di
anteprima. In quest’ultimo caso, il progettista grafico fornisce un file HTML annotato, che
specifica un “esempio di presentazione” per una certa pagina o unit. Questo file contiene dei
tag XML personalizzati, che consentono a WebRatio di convertirlo in un foglio di stile XSL,
che a sua volta potrà essere aggiunto alla libreria di stili esistenti. Ulteriori raffinamenti della
presentazione possono essere applicati direttamente ai template di pagina prodotti dal
generatore di codice. A tale scopo, è possibile fare uso di strumenti WYSIWYG (What you
see is what you get), sia per modificare aspetti grafici e strutturali della pagina, sia per
aggiungere eventuali contenuti statici alla pagina stessa.
37
WebRatio Site Development Studio
4.6 Generazione del codice
Dopo aver specificato lo schema Entità-Relazione e i diagrammi delle site-view,
associato il modello dei dati alle sorgenti dati e assegnato i fogli di stile alle pagine, è
possibile lanciare la generazione automatica del codice, trasformando le site-view in moduli
per la piattaforma selezionata, che può essere JSP, Struts e Microsoft .NET. Prima di generare
il codice dell’applicazione, è necessario specificare la piattaforma di destinazione e il percorso
su cui effettuare la generazione.
Il
generatore
di
codice
implementa
l’architettura
Modello-Vista-Controllore
rappresentato in Figura 14.
Figura 14 - Architettura utilizzata dalle applicazioni create con WebRatio
4.7 Estensione attraverso unit personalizzate
4.7.1 Cos’è una unit personalizzata
WebML, il linguaggio su cui WebRatio si basa, è basato su pochi costrutti, essi però
sono altamente componibili e quindi possono essere utilizzati per assemblare ipertesti anche
molto complessi.
La caratteristica chiave di WebML è possibilità di definire una grande varietà di
ipertesti utilizzando le unit messe a disposizione dal linguaggio e posizionando le stesse nelle
pagine web.
Tuttavia, le unit fornite da WebRatio possono non essere sufficienti per la realizzazione
di tutte le applicazioni Web, nasce così la necessità di dover utilizzare dei propri componenti
durante lo sviluppo di una applicazione Web con WebRatio.
38
WebRatio Site Development Studio
Per questo WebML 3.0 e WebRatio permettono la creazione di proprie unit
personalizzate e il loro utilizzo nel tool di sviluppo.
In definitiva, una unit personalizzata non è altro che una content unit o operation unit,
non presente nel linguaggio WebML, che viene definita a proprio piacimento per soddisfare
dei particolari requisiti di una applicazione.
Inoltre possiamo dire che una unit personalizzata è molto simile a unit standard di
WebML, ma al tempo stesso molto diversa.

Come le unit standard, è possibile utilizzarle nel diagramma dell’ipertesto,
collegarla ad altre unit, con link in entrata e in uscita e definire le proprietà
grazie all’apposito pannello. Se poi la unit personalizzata è anche una content
unit è possibile posizionarla nella griglia della pagina web desiderata.

Diversamente dalle standard unit, una unit personalizzata ha un comportamento
completamente definito dal suo progettista. In teoria, quindi, è possibile
implementare unit che possono assolvere ai più svariati compiti, dall’invio di email alla pubblicazione di documenti XML.
4.7.2 La progettazione di unit personalizzate
Lo sviluppo di unit personalizzate necessita la conoscenza di tutte le componenti di
WebRatio, questo perché la loro creazione comporta problemi sia in fase di progettazione che
in fase di esecuzione.
Per aggiungere una nuova unit a WebRatio Site Development Studio è necessario
quindi:

Aggiungere la definizione della unit nella libreria delle unit (obbligatorio). Sarà
quindi necessario scrivere del codice XML e XSL, questo permetterà di
utilizzare la nuova unit nel diagramma dell’ipertesto e permetterà a WebRatio di
capire come la nuova unit interagisce con le altre già presenti.

Aggiungere un insieme di regole XSLT per la validazione dell’uso della unit nel
diagramma dell’ipertesto, e per la produzione di eventuali warning e/o errori
(opzionale).

Aggiungere un insieme di regole XSLT per la documentazione dell’uso della
unit nella documentazione di progetto WEBMLDOC (opzionale).
E’ necessario inoltre estendere il Code Generator di WebRatio per la gestione della
propria unit personalizzata, per fare questo bisogna:
39
WebRatio Site Development Studio

Aggiungere un insieme di regole XSLT per la produzione del rispettivo
descrittore XML associato alla unit personalizzata (opzionale).

Nel caso in cui la unit personalizzata sia una content unit, è necessario produrre
anche delle regole XSLT affinché sia possibile produrre i tag necessari per la
corretta visualizzazione della unit nelle pagine Web (obbligatorio).
Dopo aver completato i passi necessari sopra descritti, l’ultimo operazione da fare
affinché la unit possa funzionare correttamente consiste nell’implementare una classe (Java)
che si occupi di attuare la logica applicativa per cui la unit è stata ideata e progettata.
Dopo aver creato tutti le parti che compongono una unit, è possibile utilizzare la nuova
unit in WebRatio così come tutte le altre unit già presenti.
Riassumendo brevemente, possiamo dire che la creazione di una unit personalizzata è
strettamente legata al completamento di alcuni passi. Quindi per creare le proprie unit in
maniera semplice e veloce è consigliabile effettuare dei passaggi ben precisi, come quelli
rappresentati nella Figura 15.
Figura 15 - Il processo di progettazione di una unit personalizzata
40
5 Ipertesti guidati da Workflow in
WebML
In questo capitolo verrà analizzato come integrare i Workflow con gli ipertesti e in
particolare con quelli progettati in WebML e successivamente in WebRatio. Come abbiamo
visto nei capitoli precedenti, grazie a WebML è possibile costruire ipertesti collegando i
costrutti del linguaggio tra di loro posizionandoli poi nelle pagine desiderate.
Originariamente, il termine “hypertext”, coniato da Ted Nelson, indicava un “nonlinear writing” dove l’utente segue percorsi associativi in un mondo di documenti testuali.
Quindi, l’utente può in un ipertesto navigare liberamente in un modo non-lineare. Al
contrario, i Workflow pongono su dei binari il lavoro di un utente, fornendo controlli sul
flusso delle attività e solo quei documenti utili per portare a termine il lavoro che costituisce
le attività. Nei Workflow la sequenza delle possibili azioni da svolgere è predefinita e l’utente
è guidato lungo il percorso delle attività, nel rispetto della specifica.
I workflow possono avere diversi tipi di vincoli: logici (es. una attività può essere
svolta solo se una certa attività è stata completata) o temporali (es. una attività può essere
iniziata solo dopo un certo punto nel tempo). L’integrazione degli ipertesti con i workflow
implica la modellizzazione di attività e l’applicazione di vincoli per guidare la navigazione
dell’utente attraverso le attività. Chiameremo ipertesti guidati da Workflow l’ipertesto esteso
con i vincoli sopra detti, Workflow-driven hypertext (WFdHT).
Figura 16 - Ipertesti e Workflow
41
Ipertesti guidati da Workflow in WebML
La Figura 16 rappresenta in un grafico le caratteristiche dei Workflow Management
Systems, degli ipertesti e dei WFdHT [14]. I Workflow management system “puri” (WFMS)
sono caratterizzati da molti e stretti vincoli che guidano l’utente verso una predeterminata
meta, non permettono una navigazione “libera” e permettono all’utente di gestire solo quei
dati utili per raggiungere la meta prestabilita. Ipertesti “puri” (HT) sono opposti ai WFMS,
dato che non pongono alcun vincolo per l’utente che può navigare liberamente in modo nonlineare e l’informazione a cui può accedere non è vincolata a priori. I WFdHT, invece,
risiedono in mezzo al grafico, tra i due estremi HT e WFMS. Vincoli, navigazione “libera” e
informazione alla quale si può accedere sono “regolabili” per ottenere WFdHT diversi, più
vicini a puri ipertesti o più inclini a vincoli dei Workflow Management Systems.
I componenti principali delle applicazioni WFdHT sono:

Strumenti per la modellizzazione degli ipertesti: includono tutti quei concetti
per la rappresentazione di ipertesti, quali le pagine, il loro contenuto e link tra
pagine.

Strumenti per la modellizzazione dei vincoli: includono le idee per
rappresentare vincoli tipici dei Workflow.

Modello dei dati per una “Workflow/hypertext” per rappresentare i concetti
comuni a ipertesti e workflow: o controllo degli accessi: gli ipertesti sono
spesso utilizzati per servire vari gruppi di utenti, come utenti casuali, clienti,
soci, amministratori, ecc.; analogamente i workflow comportano un insieme di
utenti (participants), ognuno dei quali svolge un compito particolare. In
entrambe le applicazioni si devono gestire differenti tipi di utenti e i loro diritti
di accesso.
Le attività di un Workflow sono eseguite da utenti e usano dati: deve essere quindi
possibile rispondere a domande del genere “quali dati usa questa attività?”, “chi esegue questa
attività?”, “quali attività sono completate?”, e così via. Nelle sezioni successive verranno
spiegati più approfonditamente gli strumenti per gestire gli ipertesti, i Workflow e metamodelli per i dati. In particolare si adotterà WebML come strumento per la specifica e la
gestione degli ipertesti.
5.1 Requisiti di una applicazione Workflow-Driven Hypertext
Le specifiche di una applicazione WFdHT richiedono questi requisiti minimi:
42
Ipertesti guidati da Workflow in WebML

Semplicità e usabilità: le specifiche di un Workflow dovrebbero assicurare una
alta usabilità per l’utente inesperto, mantenendo la stessa filosofia di design di
un comune ipertesto WebML.

Leggibilità: una specifica WebML di un Workflow deve essere facilmente
leggibile.

Coerenza: i concetti tipici dei Workflow, come attività e processi, devono essere
coerentemente integrati nelle specifiche ipertestuali.

Qualità: la gestione di Workflow dovrebbe essere automatizzata il più possibile,
in modo da ridurre la possibilità di errori del designer e migliorare la qualità
delle specifiche.

Il designer dell’applicazione non dovrebbe avere accesso ai Workflow control
data, come i dati gestiti dal Workflow Management System.
Questi dati potrebbero però essere esposti ad utenti più “tecnici”, come
l’amministratore del Workflow, ad esempio. Per soddisfare questi requisiti si adotterà una
soluzione che mantiene separati gli aspetti della progettazione di una applicazione Web e la
progettazione del Workflow, sviluppando un modello di sviluppo centrato su un conceptual
modelling, fase in cui i requisiti dell’applicazione sono di alto livello e platform independent,
i cui componenti fondamentali sono:

Modello di processo: rappresenta il processo da eseguire, descritto attraverso le
attività che lo compongono, i loro vincoli di precedenza e gli attori responsabili
dell’esecuzione di ogni attività.

Modello dei dati: rappresenta gli oggetti elaborati e pubblicati dall’applicazione,
e i meta-dati necessari per implementarla (dati sugli utenti, audit data, ecc.)

Modello ipertestuale: specifica gli elementi ipertestuali utilizzati per
l’esecuzione delle attività: pagine mostrate all’utente, il contenuto di ogni
pagina, le operazioni che l’utente può effettuare e i link navigabili dall’utente.
5.1.1 Modello di processo
Per la definizione di un modello di processo per una applicazione workflow possono
essere utilizzate diverse notazioni di alto livello. Nei capitoli e nei paragrafi successivi,
utilizzeremo sempre la terminologia definita dal WFMC che è basata sui seguenti concetti

Process: il processo schematizzato dal diagramma del workflow.
43
Ipertesti guidati da Workflow in WebML

Case: l’istanza del processo che viene creata, gestita ed eventualmente
terminata dall’applicazione. Il case rappresenta quindi la specifica attivazione
del processo.

Activity: le varie attività che compongono il workflow e che se eseguite secondo
le regole prestabilite portano alla corretta conclusione del processo.

Activity Instance: l’istanza di una certa activity all’interno di un case.

Actor: l’utente che svolge i compiti previsti dal workflow.

Constraints: i vincoli logici da soddisfare per poter proseguire nello
svolgimento delle attività successive.
5.1.2 Modello dei dati
Se si sceglie di sviluppare una applicazione Web basati sui dati, l’utilizzo di una base di
dati dedicata è fortemente consigliato. In questo la modellazione dei dati ricopre un ruolo
importantissimo nell’intera progettazione dell’applicazione. Infatti in questa fase viene
definita l’organizzazione dei dati che poi dovranno essere utilizzati dall’applicazione. Il
modello dei dati è tradizionalmente costruito seguendo le regole del linguaggio EntitàRelazione, esso è basato sui concetti di entità, attributo e relazione.
5.1.3 Modello dell’ipertesto
Attraverso l’ipertesto viene definita l’interfaccia che verrà utilizzata dall’utente del
workflow. Nel linguaggio WebML è possibile definire più ipertesti, ognuno di essi viene
chiamato site-view.
Una site-view è un insieme di pagine che rappresentano le pagine Web che verranno
poi pubblicate. Ogni pagina contiene le unit che il progettista posiziona in essa. Come già
detto precedentemente combinando le unit messe a disposizione da WebML è possibile
costruire un qualsiasi ipertesto.
5.2 Workflow: terminologia
Adottando la terminologia di un generico Workflow definita dal Workflow
Management Coalition, si definisce:
5.2.1 Processo
Specifica che cosa si intende realizzare, ossia ciò che si vuole modellare. L’istanza di
un processo, nota anche con il nome di Case, è la singola attivazione del processo stesso. Ad
44
Ipertesti guidati da Workflow in WebML
esempio nell’applicazione da noi sviluppata il processo è la pubblicazione di articoli sul sito
web di una testata giornalistica. Così la pubblicazione è il processo, mentre per ogni articolo
che deve essere pubblicato esiste una istanza del processo. Ad ogni istanza del processo è
associato, istante per istante, un particolare stato, che può essere:

Active: l’istanza è in esecuzione e una o più attività del processo possono essere
eseguite.

Complete: il processo è terminato correttamente rispondendo a tutti i vincoli.

Suspended: stato nel quale non accade nulla fino ad una specifica operazione di
resume

Terminated: il processo non è terminato correttamente a causa di un errore o su
esplicita richiesta dell’utente.

Archived: questo stato è utilizzato per archiviare i case completati.
Un Workflow management system crea, gestisce e termina le istanze di un processo.
5.2.2 Attività
L’attività è l’elemento elementare (elemento logico) attraverso il quale è definito il
processo. Come per le istanze del processo anche per le istanze delle attività sono definiti
degli stati. Sempre per analogia, e per meglio chiarificare il concetto di istanza, nel processo
di pubblicazione di articoli una attività è la validazione dell’articolo da parte del direttore,
mentre un istanza di quella attività è la validazione di un determinato articolo. Ogni istanza
può dunque trovarsi in uno dei seguenti stati:

Active: esiste un task al quale è stata assegnata per l’esecuzione.

Inactive: esiste l’istanza, ma nessun task esiste ancora.

Complete: l’attività è terminata correttamente.

Suspended: non accede nulla fino a quando l’attività non sarà “resumed”.

Terminated: l’istanza non è terminata correttamente a causa di un errore o su
richiesta dell’utente.

Archived: questo stato serve per tenere traccia delle istanze delle attività
completate.
Ad un Workflow possono partecipare sia utenti umani che risorse computerizzate.
45
Ipertesti guidati da Workflow in WebML
5.3 Definizione dei dati nei Workflow
In questa sezione descriviamo i dati necessari alla gestione dei Workflow. Alcuni di
questi, chiamati Workflow data meta-model, sono necessari alla gestione del processo, e per
questo non sono veri e propri dati, sono metadati. Analizziamo ora il modello con particolare
riferimento proprio a questi metadati, che di fatto consentono la gestione dell’applicazione.
5.3.1
Workflow data meta-model
I Workflow data meta-model includono tutte quelle entità e quelle relazioni necessarie
per gestire uno o più Workflow. Nella figura sotto riportata (Figura 17) viene mostrato lo
schema base per il Workflow data meta-model. Include:

Process, che consente di tenere una descrizione del Workflow (o dei
Workflows) implementati nell’applicazione.

Case, contiene le istanze dei processi, che possono essere nei differenti stati
previsti.

Activity, le attività che compongono il processo, i passi elementari da effettuare
per poter eseguire l’intero processo.

Activity Instance, come per l’entità case, contiene le istanze delle attività. Le
istanze di una attività possono essere assegnate per l’esecuzione a un particolare
utente o a un gruppo. Come nel caso delle istanze dei processi anche le istanze
delle attività sono caratterizzate da uno stato.

User e Group, ossia i partecipanti al Workflow. Gli utenti sono suddivisi in
gruppi, per meglio assegnare le attività e per consentire le diverse viste
sull’applicazione.
I dati contenuti nelle entità del meta-modello consentono di gestire gli accessi
controllati e consentono il tracciamento di chi e quando una attività viene svolta.
Naturalmente lo schema base può essere arricchito fino a rappresentare la realtà di interesse.
Una descrizione più dettagliata delle entità coinvolte è riportata di seguito.
5.3.1.1 Entity Process
La funzione dell’entità processo è quella di consentire di conservare le informazioni
circa il processo utilizzato dall’applicazione. Un processo è caratterizzato dagli attributi:

Name: nome del processo, definito dall’utente.

Description: descrizione del processo.
46
Ipertesti guidati da Workflow in WebML

ID: nome del processo con il quale ci si riferisce al processo stesso all’interno
dell’applicazione. Definito dall’utente, deve avere la proprietà di essere unique.
5.3.1.2 Entity Case
L’entità tiene traccia delle istanze dei processi attivati durante l’esecuzione
dell’applicazione. Il case è a sua volta caratterizzato dai seguenti attributi:

Name: nome del case. Definito dall’utente è associato ad un case quando viene
creato da nuovo.

Started: indica la data e l’ora alla quale avviene la creazione del case.

Ended: indica data e ora del termine dell’esecuzione del case.
5.3.1.3 Entity Case Status
Come visto in precedenza i case hanno uno stato che li caratterizza, questi stati sono
conservati all’interno dell’entità Entity Case Status.
5.3.1.4 Entity Activity
Questa entità contiene le attività che compongono il processo. Vengono caratterizzare
dei seguenti attributi:

Name: il nome della attività definito dall’utente.

Description: descrizione dell’attività.

ID:
campo
unique
necessario
ad
identificare
l’attività
all’interno
dell’applicazione.
5.3.1.5 Entity Activity Instance
Contiene le istanze delle attività, così come Case tiene traccia delle istanze dei processi,
attivate durante l’esecuzione dell’applicazione (e dunque di un processo). Viene caratterizzata
dai seguenti attributi:

Started: data e ora della creazione.

Ended: data e ora del termine dell’esecuzione.
5.3.1.6 Entity Activity Instance Status
Come già sottolineato in precedenza tutte le istanze delle attività sono caratterizzate da
uno stato. Si rimanda alla sezione 5.2.2 .
47
Ipertesti guidati da Workflow in WebML
5.3.2 Workflow data meta-model and application data model
Il Workflow data model è integrato all’interno del data model dell’applicazione. Questo
significa che il progettista può specificare relazioni tra i dati dell’applicazione e i dati del
Workflow, anche allo scopo di meglio controllare lo sviluppo del Workflow. In figura è
rappresentato un esempio di data model che include sia la parte relativa al Workflow, sia
quella relativa all’applicazione, mostrando anche relazioni tra le entità dell’applicazione e
quelle specifiche per la gestione del Workflow.
Figura 17 - Esempio di relazione tra l'application data e il data model del workflow
48
Ipertesti guidati da Workflow in WebML
5.4 Workflows nel modello di ipertesto
La modellazione dei Workflow negli ipertesti va vista come estensione naturale della
modellazione di normali pagine e aree. In particolare pagine e aree possono essere utilizzate
per rappresentare attività di un Workflow. Di seguito viene mostrato come questo si reso
possibile dalle unit dei Workflow presenti negli ipertesti.
5.4.1 Inizio e fine di attività e case
Le pagine che costituiscono una attività devono essere racchiuse all’interno di due
particolari unit: la “Start Activity Unit” e la “End Activity Unit”. Infatti ogni volta che una
attività viene eseguite i dati relativi al Workflow subiscono cambiamenti, e questo rende
necessario che le attività siano ben definite a livello di inizio e fine. Le operazioni e le
informazioni associate allo start di una attività sono:

Il tipo dell’attività: una attività deve essere associata univocamente ad un tipo di
attività.

L’utente: colui che esegue l’attività (a runtime è considerato l’utente “current
user”).

Il case del quale l’attività fa parte: una attività deve essere associata ad un case.

Activity instance: una activity instance deve essere associata all’attività.
5.4.2 Start and end activities
Ogni volta che parte un’attività vengono svolte le seguenti operazioni:

Se una activity instance è già stata creata per il case corrente allora, se non è
ancora in stato di esecuzione per un differente utente, e il suo stato è “inactive”,
le seguenti operazioni sono eseguite:
o Se non è ancora connessa all’utente corrente la connessione viene creata
(relazione: AssignedTo)
o Il timestamp relativo all’evento viene salvato
o Il parametro globale “Current Activity Instance” viene settato con
l’activity instance corrente
o Lo stato dell’activity instance viene aggiornato a “active”
o Il parametro globale “current case” viene aggiornato con il case corrente

Se invece l’attività non esiste ancora per il case corrente
o Una istanza della tabella activity instance viene creata
49
Ipertesti guidati da Workflow in WebML
o Il timestamp che registra l’evento viene salvato
o Il parametro globale “current activity instance” viene
settato con
l’activity instance corrente
o L’istanza dell’activity instance viene connessa con il case corrente
(current case)
o Viene connessa con l’utente attuale (current user), connessa con
l’activity type dell’attività corrente e lo stato dell’activity instance viene
settato ad “active”
o Il parametro globale “current case” viene settato con il case corrente.
5.4.2.1 Input per la start activity unit
L’OID dell’utente, del gruppo, del case o di una activity instance possono essere passati
in input di una start activity unit, per consentire l’avvio dell’attività per un particolare utente,
gruppo, case, activity instance. L’OID del case è obbligatorio.
5.4.2.2 Output della start activity unit
L’unità fornisce come output l’OID dell’activity instance corrente, l’IOD della
corrispondente activity type e l’OID del processo corrispondente. Anche i seguenti parametri
devono essere specificati per la start activity unit:

Name: il nome dell’unità.

Process ID: identificativo del processo al quale l’attività appartiene

Activity ID: identificativo dell’attività che deve essere avviata

Start Case: opzione che rende la start activity anche una start case

Secure: opzione che rende la unit sicura

Comment: la possibilità di aggiungere un commento all’unità
E ogni volta che un’attività viene conclusa le seguenti operazioni sono effettuate:

Lo stato dell’activity instance corrente viene settato a “completed”

Il timestamp che registra l’evento viene memorizzato

Il parametro globale “current activity instance” viene “liberato” (unset).
5.4.2.3 Input della end activity unit
L’input della end activity instance non esiste.
5.4.2.4 Output della end activity unit
L’unità non fornisce nessun parametro come output.
50
Ipertesti guidati da Workflow in WebML
I seguenti parametri devono essere specificati per la end activity unit:

Name: nome della unità

Process ID: identificativo del processo a cui appartiene l’attività

Activity ID: identificativo della attività da terminare

End Case: opzione che specifica se l’end activity è anche una end case

Secure: specifica se l’unità e sicura a no

Comment: possibilità di specificare un commento per la unit
In Figura 18 si possono notare i simboli grafici che rappresentano rispettivamente la
start unit e la end unit.
Figura 18 - Notazione grafica per Start e End Activity
5.4.3 Start e end cases
Una attività può essere definite come la prima attività di un processo. In questo caso la
start activity di quella attività rappresenterà anche lo start case di tutto il processo. Dualmente
una o più attività possono essere definite come l’ultima (o le ultime) attività di un processo, e
in questo case l’end activity unit corrispondente sarà anche una end case. Le seguenti
operazioni sono eseguite all’avvio/termine di un case.
Ogni volta che viene eseguita una attività che è anche uno start case le seguenti
operazioni sono svolte:

Un nuovo case viene creato.

Lo stato del nuovo case viene settato a “running”.

Il timestamp che registra l’evento viene salvato.

Viene settato il parametro current case.
Ogni volta che viene terminata un’attività che rappresenta anche un end case vengono
svolte le seguenti operazioni:

Lo status del current case viene settato come “terminated”.

Il timestamp che registra l’evento viene memorizzato.

Il parametro globale current case viene rilasciato (unset).
51
Ipertesti guidati da Workflow in WebML
5.4.4 Units per il Workflow driven navigation paths: if and switch
Generalmente durante un Workflow un utente può partecipare a diverse attività e,
quando passa dall’eseguire un’attività ad eseguirne un’altra, il flusso del processo deve essere
rispettato, il che significa rispettare tutti i vincoli espressi nella precedente sezione. Questi
vincoli possono essere espressi come condizioni sull’esecuzione di attività o sui dati.
Vediamo dunque le unità coinvolte.
5.4.4.1 Switch unit
La switch unit viene utilizzata per esprimere condizioni multiple, basate su un singolo
valore in input. È caratterizzata dalle seguenti proprietà:

Name: nome assegnato all’unità da parte dell’utente.
Il valore in input che la switch richiede è rappresentato solamente da una costante, che
poi verrà elaborata e valutata attraverso una expression unit. In output vengono specificati una
serie di OK link, uno per ogni valore che viene considerato nella switch unit. Ogni OK link
trasporta anche di default il valore in input. L’OK link che viene seguito è quello che rende
vera la condizione sul dato in ingresso elaborato con un valore che il link stesso rappresenta.
Un KO link è presente, e viene seguito solamente se nessun OK link rende la condizione
verificata. In Figura 19 viene riportata l’immagine della switch unit come rappresentata nel
tool di sviluppo.
5.4.4.2 If unit
L’unità di test (if unit) viene utilizzata per valutare condizioni booleane. È
caratterizzata dalle seguenti proprietà:

Name: nome assegnato alla unit.

Expression: espressione da valutare.
In input la test unit può ricevere uno o più parametri, ma sicuramente almeno uno. Se la
condizione valutata risulta vera in output si seguirà l’OK link, mentre il KO link verrà seguito
sia nel caso in cui la valutazione fallisca o la valutazione dia risultato falso. In entrambi i link
uscenti è comunque riportato il valore dell’espressione. Nella figura sottostante si vede l’icona
della test unit nell’SDS di WebRatio.
Figura 19 - Notazione grafica per Switch e If unit
52
Ipertesti guidati da Workflow in WebML
5.4.5 Workflow-aware index unit
Per catturare i dati assegnati ad una activity instance può essere utilizzata la Workflow
Index Unit. Questa unità consente infatti di catturare e mostrare solamente le activity instance
relative ad una data entità, esattamente come viene utilizzata la index unit classica. I dati che
la caratterizzano sono:

Name: nome della unit definito dall’utente.

Entità: entità sulla quale si basa la Workflow index, ossia specifica quali oggetti
saranno mostrati.

Selector: consente di specificare un predicato di selezione.

Shown Attributes: specifica quali attributi degli oggetti saranno mostrati.

Sort Attributes: specifica secondo queli valori e in che modo sono ordinati gli
oggetti mostrati.

Process Status: specifica in che stato si deve trovare il processo a cui le activity
instance sono legate.

Activity ID: consente di specificare l’identificativo del tipo di attività che
interessa.

Activity Status: specifica in che stato si trova l’activity instance.

Relationship: nome della relazione tra i dati applicativi e l’activity instance da
considerare.

Link Order: quando esistono più link uscenti dalla unit è possibile specificare
un ordine di presentazione.

Comment: è possibile in questa proprietà specificare un commento alla unit
stessa.
La Figura 20 mostra l’icona della workflow index unit.
Figura 20 - Notazione grafica per Workflow-aware index unit
53
Ipertesti guidati da Workflow in WebML
5.4.6 Assign di oggetti alle activity instances
Per assegnare un oggetto applicativo (o una serie di oggetti) ad una activity instance si
utilizza la assign unit. Il compito della assign unit è quello di definire “data link” tra attività e
possibilmente assegnare i dati ad uno specifico utente o gruppo. Quando una attività produce
un oggetto che dovrà essere usato anche in seguito nel Workflow da un’altra attività e da altri
utenti, questi dati possono essere assegnati all’attività futura utilizzando proprio la assign unit.
Le proprietà richieste da una assign unit sono:

Name: nome assegnato dall’utente all’unità.

Activity ID: identificativo dell’attività a cui l’oggetto (gli oggetti) vanno
assegnati.

Relazione: nome della relazione tra i dati applicativi e l’activity instance che
deve essere presa in considerazione.

New activity instance: opzione che rende possibile specificare se deve essere
creata una nuova activity instance ogni volta che viene eseguito un
assegnamento.

Secure: opzione che specifica se la unit è sicura o no.

Comment: possibilità di specificare un commento.
L’input dell’unità è costituito dal set di oggetti che devono essere assegnati e
opzionalmente l’utente o il gruppo a cui devono essere più specificamente assegnati. L’output
della assign unit è costituito dall’OID della activity instance di destinazione. Come ogni unità
anche l’assign unit ha in uscita due link, l’OK link, che viene seguito se tutto viene eseguito
correttamente, ed un KO link, che viene seguito se non tutto viene compiuto correttamente.
Nella figura sottostante è riportata l’icona dell’assign unit.
Figura 21 - Notazione grafica per la Assign unit
5.4.7 Controllo dello stato di una activity instance
Per controllare lo stato di una activity instance si può utilizzare la Get Activity Instance
Status. Le proprietà da specificare per l’utilizzo di questa unit sono:

Name: nome definito dall’utente per la unit.

Activity ID: identificativo dell’attività.
54
Ipertesti guidati da Workflow in WebML

Comment: consente di specificare un commento.
L’unico output che fornisce è lo stato dell’activity instance richiesto.
Figura 22 - Notazione grafica per Get Activity Status unit
5.5 Progettazione di un Workflow-Driven Hypertext
La progettazione di WFdHT richiede la convergenza dei concetti citati all’inizio del
capitolo, cioè del modello di processo, dei dati e dell’ipertesto. In particolare, il modello di
processo influisce sul modello dei dati e dell’ipertesto:

Il modello dei dati deve contenere tutti i metadati riguardanti gli utenti del
workflow e il workflow stesso, questo consente di controllare gli utenti che
accedono al workflow e di tenere traccia dello svolgimento delle attività che
compongono il workflow.

Il modello dell’ipertesto deve esprimere i limiti delle attività (ad esempio dove
nell’interfaccia dell’applicazione una attività può essere avviata o terminata) e
le operazioni necessarie per tenere traccia dell’esecuzione del processo.
Infatti il nostro approccio considera il modello di processo una specifica di alto livello,
dal quale il designer può sviluppare un ipertesto che “realizza” il modello di processo. Questo
ipertesto utilizza i dati del modello dei dati di Figura 17. Quindi dato un modello di processo
che indica il flusso delle attività, le condizioni e gli attori del Workflow, la realizzazione di un
ipertesto che lo realizza è ottenuta con i seguenti passi:

Progettazione “in the large”: identifica le viste del sito (site-view) da
pubblicare per i diversi attori implicati nel Workflow e le attività d’ogni site
view.

Progettazione “in the small”: specifica l’interfaccia ipertestuale delle attività in
modo tale che tutti i vincoli tra esse siano rispettati in ogni site view.
55
Ipertesti guidati da Workflow in WebML
5.5.1 Metodologie di implementazione
Esistono differenti tipologie per progettare il modo in cui un’applicazione esegue i
processi e le attività che li compongono. Più in particolare vi sono due tipologie differenti di
avanzamento del controllo, una basata sui dati applicativi (controllo implicito) e una basata su
metadati (controllo esplicito). Inoltre si possono caratterizzare le due scelte in modo ulteriore,
arrivando a disporre di fatto di quattro differenti scelte implementative.
Supponendo di poter accostare su un asse le due tipologie implementative, quella
implicita e quella esplicita, arriveremmo ad ottenere due tecnologie in mutua esclusione che
presentano differenti aspetti degni di nota. L’ulteriore caratterizzazione possibile diventa
quella nota come: pull e push. La differenza tra le due opzioni è che una intende considerare il
passato dell’applicazione per decidere cosa si possa eseguire nell’istante corrente (pull),
mentre l’altra (push) intende impostare nell’istante corrente quello che dovrà essere eseguito
in futuro. Accostando le ulteriori caratterizzazioni su un altro asse si giunge a determinare le
quattro strategie implementative che si intende considerare.
Push
3
4
Pull
1
2
Implicito
Esplicito
Figura 23 - Rappresentazione stili d'implementazione
Si è voluto analizzare e implementare per ogni tipologia di sviluppo un semplice
esempio, che però, pur semplice che sia, mostra già come siano sensibilmente differenti le
scelte implementative
56
Ipertesti guidati da Workflow in WebML
5.6 Esempio
Si vuole considerare un’applicazione che permetta a differenti utenti, appartenenti a
gruppi con compiti e permessi differenti (per semplicità si ipotizzano essere uno per tipo), di
creare dei documenti, che successivamente dovranno essere tradotti.
Gli utenti si dividono in due gruppi, gli scrittori, con il compito di scrivere e inserire nel
database i documenti, e i traduttori, che hanno il compito di tradurre i documenti che gli
scrittori hanno prodotto.
Anche se in questo caso l’identificazione del flusso di lavoro risulta banale, in altri casi
potrebbe non essere così immediatamente chiaro. Nel nostro esempio è chiaro che un
traduttore non può tradurre un documento che non è ancora stato creato, unico vincolo da
rispettare nell’utilizzo dell’applicazione.
Creazione del / dei
documento/i da parte degli
scrittori
Traduzione del / dei
documento/i da parte dei
traduttori
Figura 24 - Semplice flusso di lavoro
Chiariti dunque gli aspetti preliminari passiamo ora all’implementazione e alla
discussione dei diversi casi.
5.7
Controllo Implicito
5.7.1 Utilizzo della politica pull
In questa situazione il controllo dell’applicazione viene eseguito mediante il controllo
di dati applicativi. Come si diceva in un primo momento, un documento non può essere
tradotto se non è ancora stato creato. In questa ottica uno scrittore potrà sempre inserire un
nuovo documento, senza nessuna precondizione, mentre un traduttore, per poter svolgere il
proprio compito, dovrà controllare se uno scrittore ha già prodotto almeno un documento che
non ha ancora la traduzione. Essendo il controllo implicito, il verificare se esiste un
documento da tradurre passa
proprio attraverso i dati applicativi, ossia viene eseguito un controllo sulla base dei dati
per verificare se esiste un documento che non sia stato tradotto. Nel nostro esempio esistono
due entità: Documenti, tabella del database che contiene tutti i documenti che vengono creati
da uno scrittore, e la tabella Documenti Tradotti, che contiene le traduzioni dei documenti. La
relazione che lega le due entità è una relazione che permette di individuare se un documento è
57
Ipertesti guidati da Workflow in WebML
stato tradotto e in caso affermativo quale sia la traduzione del documento preso in esame. In
un modello Entità – Relazione graficamente le cose sono così rappresentate:
Figura 25 - Schema Entità-Relazione dell'esempio
In particolare il controllo implicito avviene sulla relazione che lega i Documenti a
Documenti Tradotti, andando a controllare se per ogni documento che esiste nella tabella
Documenti esiste un corrispondente documento tradotto nella tabella Documenti Tradotti. Se
questa corrispondenza non esiste allora si è individuato un documento da tradurre, e questo
verrà sottoposto all’attenzione dei traduttori. La site-view degli scrittori sarà dunque così
implementata:
58
Ipertesti guidati da Workflow in WebML
Figura 26 - Site-view pubblica degli scrittori
All’interno della vista si ha una home page che permette di accedere alla creazione di
un nuovo documento, la possibilità di accedere a una vista privata per quegli utenti che ne
hanno il permesso (in questo esempio i traduttori) e la possibilità di visualizzare i documenti
tradotti.
59
Ipertesti guidati da Workflow in WebML
Nella vista privata dei traduttori viene implementato il controllo implicito del flusso di
lavoro:
Figura 27 - Site-view dei traduttori
Il controllo viene eseguito nella pagina iniziale, dove una index unit visualizza tutti e
solo quei documenti che non appartengono alla relazione Documenti_2_Documenti_Tradotti.
Il fatto che il controllo, implicito, avvenga nella seconda, in questo caso anche ultima,
attività, implica che si osservi il passato dell’applicazione per decidere se è possibile, ed
eventualmente cosa, fare nel momento attuale. Il controllo infatti avviene considerando i
documenti precedentemente inseriti, la source unit di tutto ciò è rappresentata dalla multidata
unit ancorata all’entità Documenti, e considerando i documenti che sono stati tradotti,
multidata unit legata ai Documenti Tradotti.
Uno sviluppo di questo tipo è chiaramente uno sviluppo implicito, legato ai dati
applicativi, e con una politica pull, infatti il controllo viene eseguito dalla seconda attività sul
risultato della prima.
5.7.2 Utilizzo della politica push
In questo tipo di implementazione il controllo viene comunque fatto implicitamente,
ossia attraverso i dati applicativi, ma la politica è quella di tipo push, il lavoro prosegue non
60
Ipertesti guidati da Workflow in WebML
osservando ciò che è successo prima, bensì assegnando un oggetto ad una attività
futura. Così il controllo si esprime con la prima attività che crea l’oggetto e lo assegna
all’attività di traduzione. La seconda attività non dovrà fare altro che tradurre il documento
che gli è stato assegnato. Più dettagliatamente si può osservare dalla site-view degli scrittori
che una volta inserito il documento da tradurre questo viene anche salvato come istanza di una
nuova tabella, documenti da tradurre. Questa contiene tutti i documenti che sono stati creati,
ma che non sono ancora stati tradotti. Quindi in realtà in questo modo si effettua la politica
push, poiché una volta acceduti alla site-view dei traduttori, dunque all’inizio dell’attività due,
quella di traduzione, non occorre effettuare un controllo sul passato, ci si trovano direttamente
gli oggetti assegnati da tradurre solamente avendo una data unit legata alla tabella delle
assegnazioni. Si può inoltre notare che al contrario della politica pull, mentre in quella
circostanza era necessario verificare le istanze di una relazione per poter procedere, in questa
politica non occorre effettuare alcun controllo, poiché gli oggetti sono direttamente assegnati
dall’attività precedente.
Figura 28 - Site-view degli scrittori
61
Ipertesti guidati da Workflow in WebML
5.8 Controllo esplicito
5.8.1 Utilizzo della politica pull
Con questo tipo di controllo l’applicazione procede ispezionando i metadati in modo
che l’attività di traduzione controlla se esistono documenti da tradurre. Occorrerà effettuare
questo attraverso la tabella activity instance, cioè occorrerà controllare se esistono istanze
completate dell’attività precedente e se ciò è verificato allora si potrà procedere con l’attività
di traduzione.
La site-view dal lato scrittore sarà semplicemente una site-view di inserimento del
documento e creazione dell’istanza dell’attività, ma non sarà presente una assign unit, tipica
del controllo push. La site-view risultante è dunque mostrata in Figura 29.
Figura 29 - Site-view degli scrittori
Dalla parte dei traduttori la site-view risultante sarà dunque quella che controlla in base
all’activity instance la presenza o meno di attività terminate con successo, che all’interno del
62
Ipertesti guidati da Workflow in WebML
processo vengono prima. Se la condizione risulta verificata allora si procede all’attività di
traduzione
5.8.2 Utilizzo della politica push
In questa politica il controllo viene associato non più ai dati dell’applicazione, bensì a
metadati associati all’applicazione e al flusso di lavoro. Per meglio chiarire come tale
controllo venga effettivamente realizzato riporto lo schema entità- relazione che lo identifica:
Figura 30 - Schema Entità-Relazione che caratterizza i metadati
Il processo che deve essere eseguito viene salvato nella tabella Process, e le sue attività
vengono registrate nella tabella Activity. Entrambe le tabelle sono legate con le loro rispettive
tabelle di istanze, ossia le tabelle che contengono quali sono i processi attualmente istanziati e
quali sono le attività istanziate delle attività. Chiaramente le due entità sono in relazione, in
63
Ipertesti guidati da Workflow in WebML
modo da poter associare quale istanza di attività appartiene a quale processo istanziato. Inoltre
sia le attività che i processi hanno uno stato, ed è proprio in base a questo che è possibile il
controllo implicito.
Una volta istaziato un processo si può trovare in stati differenti. Gli stati in cui il
processo si può trovare sono:

Active: l’istanza è in esecuzione e una o più attività del processo possono essere
eseguite.

Complete: il processo è terminato correttamente rispondendo a tutti i vincoli.

Suspended: stato nel quale non accade nulla fino ad una specifica operazione di
resume.

Terminated: il processo non è terminato correttamente a causa di un errore o su
esplicita richiesta dell’utente.

Archived: questo stato è utilizzato per archiviare i case completa.
Allo steso modo anche le attività istanziate hanno degli stati che le caratterizzano. Più
precisamente sono:

Active: esiste un task al quale è stata assegnata per l’esecuzione.

Inactive: esiste l’istanza, ma nessun task esiste ancora.

Complete: l’attività è terminata correttamente.

Suspended: non accede nulla fino a quando l’attività non sarà “resumed”.

Terminated: l’istanza non è terminata correttamente a causa di un errore o su
richiesta dell’utente.

Archived: questo stato serve per tenere traccia delle istanze delle attività
completate.
Proprio dall’analisi di questi dati, che non essendo dati applicativi prendono il nome di
metadati, il controllo dell’applicazione può essere effettuato. Analizziamo l’esempio.
Nella site-view pubblica, ancora una volta, è possibile l’inserimento dei documenti da
parte degli scrittori. A differenza del controllo pull in questo caso il controllo dell’esecuzione
passa attraverso unità della site-view precedente a quella dove le attività vengono svolte.
Come visibile nella Figura 31 un utente accede alla pagina principale, dalla quale
chiede di poter inserire un nuovo documento. In questo momento, attraverso la start unit,
viene istanziato il processo richiesto, nel nostro caso il processo di traduzione di documenti, e
viene creata anche l’attività di inserimento di un nuovo documento. Il controllo passa poi alla
pagina con l’entry unit, che permette allo scrittore di inserire il documento. Una volta ultimato
di scrivere vengono eseguite differenti operazioni. In primo luogo viene fisicamente creato il
64
Ipertesti guidati da Workflow in WebML
documento nel database, secondariamente, attraverso l’assign unit, viene assegnato l’oggetto
creato all’attività futura che, nella site-view protetta, dovrà tradurla. In questo modo si riesce a
implementare un controllo push, poiché l’attività precedente abilita quella futura, non come
nella politica pull, che deve essere l’attività futura a controllare se le precedenti hanno
terminato consistentemente. Inoltre essendo il controllo basato su metadati si parla di
controllo esplicito.
Figura 31 - Site-view nel controllo esplicito con politica push
Per completezza riportiamo ora anche la site-view dei traduttori, anche per poter
comprendere come alla seconda attività vengano assegnati gli oggetti che deve trattare.
Rilevante importanza all’interno della site-view, è rivestita dalla workflow index unit.
Questa visualizza tutti gli oggetti che sono stati assegnati dall’attività precedente a quella
corrente, basandosi si sulle relazioni intercorrenti anche tra i dati applicativi, ma considerando
principalmente gli status delle attività. In questo modo si riesce a presentare all’utente
l’oggetto o gli oggetti sui quali deve intraprendere l’attività.
65
Ipertesti guidati da Workflow in WebML
Figura 32 - Site-view dei traduttori
66
6 Progettazione e implementazione delle
unit di Workflows
Nel capitolo precedente sono state presentate le unit messe a disposizione
dall’estensione di WebML per i Workflow. Grazie ad esse è possibile quindi costruire
ipertesti basati sui workflow con il linguaggio grafico di WebML.
Se si desidera ottenere una generazione automatica delle pagine, progettare una
applicazione Web con WebML non è sufficiente, bisogna infatti riportare il progetto
dell’applicazione nel tool di sviluppo WebRatio che si preoccuperà di creare le pagine web
necessarie.
WebRatio disponeva già una apposita estensione che permetteva l’utilizzo delle unit
viste precedentemente. Durante lo sviluppo dell’applicazione Web, le unit di WebML si sono
dimostrate deficitarie.
Figura 33 - Esempio di come le limitazioni delle unit hanno complicato lo schema WebML
67
Progettazione e implementazione delle unit di Workflows
Infatti in molti casi le unit non permettevano di recuperare le informazioni necessarie
contenute nel database. Per la realizzazione di alcune pagine è stato necessario aggirare il
problema, questo ci ha costretto a complicare notevolmente lo schema WebML come visibile
in Figura 33, in cui è rappresentata la pagina contenente le unit necessarie a visualizzare i
work items, relativi ad una certa attività, assegati ad un determinato utente.
In questo capitolo viene quindi presentato il lavoro svolto sulle unit di Workflows al
fine di ovviare a tali limitazioni.
6.1 Il modello dei dati
Il modello dei dati già presente era fondamentalmente corretto. E’ stato necessario però
rivederlo in alcuni punti per offrire al designer dell’applicazione Web un modello dei dati
utilizzabile per lo sviluppo di un più ampia gamma di workflow.
Le modifiche apportate sono sostanzialmente due, è necessario però soffermarsi anche
sulle relazioni presenti tra le varie entità e sul loro significato.
Figura 34 - Modello dei dati per workflow dopo le modifiche
68
Progettazione e implementazione delle unit di Workflows
6.1.1.1 Le relazioni tra User e Activity Instance
Queste sono forse le relazioni più importanti del modello dei dati per workflow. Grazie
a queste relazioni è possibile specificare quali utenti possono eseguire una certa istanza di una
determinata attività e chi realmente ha poi eseguito quella attività.
La relazione User_Assigned_To_Activity_Instance, che è diventata una relazione moltimolti, permette al designer dell’applicazione di assegnare una certa attività agli utenti
desiderati oppure il designer può lasciare ad un altro attore del workflow il compito di
scegliere quali utenti possono svolgere l’attività.
Entrambi i casi sono riscontrabili nell’applicazione che abbiamo sviluppato e che verrà
presentata dettagliatamente nel capitolo successivo.
Il primo caso è riscontrabile quando il direttore approva l’articolo e decide quindi di
inviarlo agli impiegati affinché lo controllino più dettagliatamente. Infatti in questo caso è il
designer dell’applicazione che si preoccupa di selezionare tutti gli utenti che appartengono al
gruppo degli “impiegati” e assegnarli conseguentemente l’attività.
Il secondo caso emerge invece quando l’articolo viene creato da uno dei suoi autori.
L’autore, oltre se stesso, seleziona quelli che sono gli autori dell’articolo, dando anche a loro
la possibilità
di completare l’invio dell’articolo al direttore inserendo il testo e le foto
necessarie.
6.1.1.2 La relazione tra Group e Activity Instance
Questa relazione, presente nel modello dei dati esistente, è stata eliminata in quanto
giudicata superflua e non necessaria. Questa modifica è legata alla modifica effettuate sulle
relazioni presenti tra l’entità User e Activity Instance. Essendo cambiata la cardinalità della
relazione è sempre possibile attraverso di essa collegare più utenti ad una determinata Activity
Instance. In questo caso la modifica permette di assegnare una determinata Activity Instance a
gli utenti che si desidera senza che essi appartengano per forza ad uno stesso gruppo.
6.2 Progettazione e implementazione delle unit
In questo paragrafo presenteremo più in dettaglio le unit focalizzando l’attenzione sulle
proprietà o funzionalità che ne limitano l’utilizzo nello sviluppo di una applicazione Web.
Inoltre verranno esposte le modifiche apportate all’implementazione delle varie unit senza
però scendere troppo nei dettagli.
69
Progettazione e implementazione delle unit di Workflows
6.2.1 Start Activity Unit
La Start Activity Unit permette di far partire, e quindi di cambiare lo stato, di una
determinata activity instance. Le proprietà presenti permettevano in maniera semplice di
specificare il processo e l’attività che si voleva far partire. Attraverso poi i parametri di input
la unit era in grado di far partire soltanto l’activity instance appartenente al case del processo
desiderato. L’unica eccezione è nel caso in cui sia selezionata l’opzione Start Case, in questo
caso non è necessario nessun parametro in input in quanto significa che si sta iniziando una
nuova istanza del processo.
Per quanto riguarda i parametri in input, come riscontrabile da un confronto tra la
Figura 35e la Figura 36, sono state rimosse la possibilità di specificare il gruppo e l’utente.
La possibilità di specificare il parametro in input “Restrict to Group” è stata eliminata
conseguentemente alla modifica del modello dei dati, non esistendo più la relazione tra Group
e Activity Instance la relazione non aveva motivo di esistere. Nel secondo caso la possibilità
di restringere ad un singolo utente è stata eliminata in quanto si suppone che ogni activity
instance possa essere eseguita da un solo utente.
Figura 35 - I parametri in input della Start Unit prima delle modifiche
70
Progettazione e implementazione delle unit di Workflows
Figura 36 - I parametri input della Start Unit attualmente utilizzabili
La rimozione dei parametri è stata possibile attraverso la modifica del file inputparameter.xsl di cui qui in basso ne viene riportato una parte. Il file definisce i parametri in
input della unit a cui si riferisce, è stato sufficiente quindi rimuovere dal file le linee che si
riferivano ai due parametri in input da rimuovere. Nelle linee qui riportate è possibile
distinguere le linee rimosse in quanto evidenziate in corsivo.
<!-- ========================================================= -->
<!-- START ACTIVITY UNIT
-->
<!-- ========================================================= -->
<xsl:template match="STARTACTIVITY" mode="input-parameters">
<xsl:variable name="unit-id" select="@id"/>
<logic:input-parameters>
<logic:input-parameter name="{$unit-id}.case" type="entity/{'Case'}"
clear-on-incoming-link-click="yes"
label="Restrict to Case"/>
<logic:input-parameter name="{$unit-id}.activityInstance"
type="entity/{'ActivityInstance'}"
clear-on-incoming-link-click="yes"
label="Restrict to Activity Instance"/>
<logic:input-parameter name="{$unit-id}.user" type="entity/{'User'}"
clear-on-incoming-link-click="yes"
label="Restrict to User"/>
<logic:input-parameter name="{$unit-id}.group" type="entity/{'Group'}"
clear-on-incoming-link-click="yes"
label="Restrict to Group"/>
</logic:input-parameters>
</xsl:template>
Dopo aver modificato il file input-parameter.xsl della unit è stato necessario anche
rimuovere la parte di codice Java del servizio della unit che si preoccupava di gestire questi
due parametri in input.
71
Progettazione e implementazione delle unit di Workflows
6.2.2 End Activity Unit
Questa unit consente di terminare (settare lo stato dell’activity a complete) l’istanza di
una attività. Anche in questo caso le proprietà e i parametri in input erano sufficienti al
funzionamento della unit.
La unit è stata però potenziata con la possibilità del passaggio di parametri in output.
La End Unit adesso fornisce in output l’OID del case corrente, L’OID del processo associato
al case corrente, l’OID dell’activity instance corrente e L’OID dell’activity associata
all’activity instance corrente.
Figura 37 - I parametri in output disponibili per la End Unit
Al contrario della Start Unit dove si è andati a modificare il file input-parameter.xsl per i
parametri di input, questa volta il file da modificare è stato output-parameter.xsl relativo alla
End Unit. Le linee relative ai parametri di output visibili nella Figura 37 sono riportate di
seguito.
<!-- ========================================================= -->
<!-- ENDACTIVITY
-->
<!-- ========================================================= -->
<xsl:template match="ENDACTIVITY" mode="output-parameters">
<logic:output-parameters>
<logic:output-parameter name="processOID" type="entity/{'Process'}"
label="Process"/>
<logic:output-parameter name="caseOID" type="entity/{'Case'}"
label="Case"/>
<logic:output-parameter name="activityOID" type="entity/{'Activity'}"
label="Activity"/>
<logic:output-parameter name="activityInstanceOID"
type="entity/{'ActivityInstance'}"
label="Activity Instance"/>
</logic:output-parameters>
</xsl:template>
Inoltre è stato modificato il significato dell’opzione End Case. La modifica non
riguarda strettamente l’ipertesto ma influenza il database dell’applicazione Web. In
72
Progettazione e implementazione delle unit di Workflows
precedenza selezionando l’opzione End Case l’unica operazione svolta dalla unit era quella di
terminare l’attività e il case corrispondente.
Esistendo nella nostra applicazione due activity in mutua esclusione, anche al termine
del processo l’attività che non veniva eseguita rimaneva nel database con lo stato impostato a
“Inactive”, inoltre in alcuni casi può succedere che lo stato di alcune activity rimanga “active”
nonostante il case sia terminato.
Abbiamo deciso quindi di modificare l’implementazione della unit in modo che
l’opzione End Case comporti anche la cancellazione delle activity “Inactive” di quel
determinato case e la terminazione delle activity con stato “active” (in questo caso lo stato
dell’activity viene settato a terminated).
Qui di seguito riportiamo la parte di codice del servizio della unit che gestisce
l’opzione “End Case”.
/**
* End Activity Instance Unit
* Cambio lo stato dell’attività desiderata a 'Complete'
* Se la proprietà 'End-case' è selezionata, tutte le activity instances
*'Inactive' del case selezionato sono cancellate e tutte le activity
instances
* 'Active' del case sono impostate allo stato ‘Terminated’
*
* @author Furlan Tiziano <[email protected]>
* @author Giordano Giuseppe <[email protected]>
* @version 1.0
*/
// La classe del servizio della End Unit
public class EndActivityService extends AbstractActivityService
implements RTXOperationUnitService {
(…)
// Il metodo in cui è presente il codice che esegue le operazioni
// della unitunit
public Object execute(Map operationContext, Map sessionContext)
throws RTXException {
(…)
// Controlla se è selezionata l’opzione End Case
if (endCase) {
//
//
//
//
//
//
//
//
Opzione End Case selezionata
1. Imposta lo status del case a Complete
2. Imposta il timestamp di end del case alla data
corrente
3. Imposta a Terminated lo status dell’activity
Instances Active
4. Cancella tutte le activity Instances Inactive del
case corrente
logDebug("Ending case: " + caseOID);
73
Progettazione e implementazione delle unit di Workflows
// Il metodo setCaseStatus imposta lo stato del case
// desiderato
setCaseStatus(CaseStatus.COMPLETE, caseOID,
operationContext, sessionContext);
modifyCase(getStringArray(caseOID), null, null,
new Date(), operationContext, sessionContext);
String[] statusName;
String[] statusOIDs;
// Imposta a Terminated lo status dell’activity Instances
// Active
logDebug("Setting Active Activity Instances to
Terminated");
statusName = new String[1];
statusName[0] = ActivityStatus.ACTIVE;
statusOIDs = activityStatusByName(statusName, con,
operationContext, sessionContext);
String[] activityInstanceActiveOIDs =
findActivityInstance(
getStringArray(caseOID), statusOIDs, null, null, null,
con, operationContext, sessionContext);
int activityFound = activityInstanceActiveOIDs.length;
while (activityFound > 0) {
// Il metodo setActivityInstanceStatus serve per
// cambiare lo stato delle activity instance
setActivityInstanceStatus(ActivityStatus.TERMINATED,
activityInstanceActiveOIDs[activityFound - 1],
operationContext,
sessionContext);
activityFound--;
}
// Eliminazione delle activity instances inactive
logDebug("Deleting Inactive Activity Instances");
statusName = new String[1];
statusName[0] = ActivityStatus.INACTIVE;
statusOIDs = activityStatusByName(statusName, con,
operationContext, sessionContext);
removeActivites(getStringArray(caseOID), statusOIDs,
null, null, null, null,
operationContext, sessionContext);
}
(…)
6.2.3 Expression Parsing Unit – Test Unit
Durante la realizzazione del sito, ci siamo resi conti che era molto utile avere unit che
permettessero di calcolare espressioni o di decidere la pagina da visualizzare in base a
condizioni espresse.
74
Progettazione e implementazione delle unit di Workflows
Nel caso di queste unit, quindi, non è stata apportata nessuna modifica alle proprietà o
ai parametri di input ed output, ma il lavoro si è concentrato sul potenziamento del loro potere
espressivo. Per maggiori informazioni riguardo il potere espressivo delle unit, gli operatori
logico-matematici supportati e l’utilizzo delle funzioni disponibili è possibile fare riferimento
all’Appendice A.
Sia la Expression Parsing Unit che la Test sono basate sulle API Java JEP (Java
Mathematical Expression Parser) versione 2.24, distribuite sotto la GNU public license.
Grazie a questa libreria è possibile valutare una formula arbitraria inserita come stringa. E’
possibile scaricare il codice sorgente e ottenere maggiori informazioni riguardanti la libreria
all’indirizzo http://jep.sourceforge.net.
La Expression Parsing Unit può essere utilizzata per risolvere diversi tipi di espressioni
(ad esempio booleane o matematiche) presentando poi in output il risultato dell’espressione
valutata in base ai parametri ricevuti in ingresso. La unit accetta come proprietà l’espressione
da valutare. Questa espressione può essere composta da un numero variabile di predicati il cui
valore deve essere fornito poi come parametro in input. Il risultato dell’espressione viene
fornito in output attraverso l’OK link, mentre se la unit non è in grado di valutare
l’espressione viene seguito il KO link.
La Test Unit invece è utilizzabile per valutare espressioni logiche. Anche la Test Unit
accetta come proprietà l’espressione logica da valutare. Così come nel caso della Expression
Parsing Unit, anche la Test Unit accetta espressioni composte da un numero arbitrario di
predicati, il cui valore deve naturalmente deve essere fornito in input. Nel caso della Test Unit
però, l’OK link viene seguito se l’espressione logica risulta vera altrimenti viene seguito il
KO link.
Per aumentare il potere espressivo delle unit abbiamo aggiunto alla libreria JEP delle
funzioni da noi implementate affinché potessero essere utilizzate per lo sviluppo degli
ipertesti. Per aggiungere le funzioni da noi scritte abbiamo esteso la classe JEP creando così
una nostra classe Java chiamata MyJEP, il cui codice viene riportato integralmente qui di
seguito.
/**
* Extended JEP class.
* The JEP Library standard documentation can be found at this url: <a
* href="http://jep.sf.net">http://jep.sf.net</a>
*
* @author Furlan Tiziano <[email protected]>
* @author Giordano Giuseppe <[email protected]>
*/
public class MyJEP extends JEP {
String RESOURCE_DESCRIPTOR_PATH = "/jep-functions.prop";
75
Progettazione e implementazione delle unit di Workflows
/**
* Class constructor
*
* @see JEP#JEP()
*/
public MyJEP() {
super();
}
/**
* Adds the standard functions. Used to overwrite the standard sum()
* function of the JEP library
*/
public void addStandardFunctions() {
//add functions to Function Table
addTrigonometricFunctions();
addLogFunctions();
addOtherFunctions();
// We use our custom sum() function
addFunction("sum", new
com.webratio.workflow.math.function.Summ());
}
/**
* Adds the SQL functions.
*/
public void addSQLFunctions() {
//add functions to Function Table
addFunction("sum", new
com.webratio.workflow.math.function.Summ());
addFunction("count",new
com.webratio.workflow.math.function.Count());
addFunction("max", new
com.webratio.workflow.math.function.Max());
addFunction("min", new
com.webratio.workflow.math.function.Min());
addFunction("avg", new
com.webratio.workflow.math.function.Avg());
}
/**
* Adds the Date functions
*/
public void addDateFunctions() {
//add functions to Function Table
addFunction("compareDates", new
com.webratio.workflow.math.function.CompareDates());
addFunction("today", new
com.webratio.workflow.math.function.Today());
addFunction("datesum", new
com.webratio.workflow.math.function.DateSum());
}
/**
* Adds other functions
*/
public void addOtherFunctions() {
addFunction("angle", new Angle());
addFunction("abs", new Abs());
76
Progettazione e implementazione delle unit di Workflows
addFunction("mod", new Modulus());
addFunction("rand", new org.nfunk.jep.function.Random());
addFunction("sqrt", new SquareRoot());
}
/**
* Adds the logarithm functions
*/
public void addLogFunctions() {
addFunction("log", new Logarithm());
addFunction("ln", new NaturalLogarithm());
}
/**
* Adds the trigonometric functions
*/
public void addTrigonometricFunctions() {
addFunction("sin", new Sine());
addFunction("cos", new Cosine());
addFunction("tan", new Tangent());
addFunction("asin", new ArcSine());
addFunction("acos", new ArcCosine());
addFunction("atan", new ArcTangent());
addFunction("sinh", new SineH());
addFunction("cosh", new CosineH());
addFunction("tanh", new TanH());
addFunction("asinh", new ArcSineH());
addFunction("acosh", new ArcCosineH());
addFunction("atanh", new ArcTanH());
}
/**
* Adds the custom functions
*
* @throws RTXException the exception is generated on errors
*/
public void addCustomFunctions() throws RTXException {
try {
Properties prop = new Properties();
prop.load(this.getClass().getResourceAsStream(RESOURCE_DESCRIPTOR_PAT
H));
Enumeration e = prop.propertyNames();
while (e.hasMoreElements()) {
String function = (String) e.nextElement();
Class functionService =
Class.forName(prop.getProperty(function));
addFunction(function, (PostfixMathCommandI)
functionService.newInstance());
}
}
catch (Throwable e) {
throw new RTXException("Add Custom functions error");
}
}
}
77
Progettazione e implementazione delle unit di Workflows
Esaminando il codice notiamo che la classe è fondamentalmente formata dal metodo
addFunction(). Questo metodo permette di aggiungere una funzione alla libreria JEP. Ad
esempio:
addFunction("max", new com.webratio.workflow.math.function.Max());
significa che la funzione di nome "max" implementata dal metodo Max() situato nel package
indicato verrà aggiunta alla libreria. Utilizzando questo metodo per aggiungere funzioni alla
libreria il parser della libreria potrà sempre sapere quali sono le funzioni utilizzabili nelle
espressioni [15].
Com’è possibile notare le funzioni da aggiungere sono state poi organizzate in gruppi
in modo che sia sufficiente richiamare un solo metodo per caricare nella libreria tutte le
funzioni dello stesso genere, se ad esempio viene invocato il metodo addSQLFunctions(), le
funzioni sum, count, max, min, avg diventeranno disponibili per l’uso.
Le funzioni da noi implementate sono le seguenti:

sum

count

max

min

avg

today

Datesum

compareDates
Per comprendere meglio il funzionamento e le potenzialità di queste funzioni è
possibile fare riferimento all’Appendice A.
Una cosa interessante da notare è la presenza della funzione sum. Infatti come sarebbe
logico attendersi la libreria dispone già di una funzione che permette di sommare numeri. JEP
però permette di sovrascrivere le funzioni in essa presenti in modo da poter aggiungere
funzionalità.
Nel nostro caso infatti ci interessava poter effettuare la somma di numeri contenuti in
un vettore. Abbiamo così creato la nostra funzione sum. Qui basso viene riportato la parte di
codice dal quale è possibile intuire come la classe da noi implementata possa gestire i vettori e
i numeri in esso contenuto.
while (i < curNumberOfParameters) {
param = inStack.pop();
if (param instanceof Double) {
r += ((Double) param).doubleValue();
78
Progettazione e implementazione delle unit di Workflows
}
else if (param instanceof Vector) {
Enumeration e=((Vector)param).elements();
while (e.hasMoreElements()) {
r += ((Double) e.nextElement()).doubleValue();
}
}
Notiamo come la variabile param che contiene il parametro passato alla funzione possa
essere di tipo Double, quindi un numero, oppure Vector. Nel caso in cui sia Vector con un
semplice ciclo è possibile estrarre i numeri contenuti nel vettore e sommarli per ottenere il
risultato.
Fino ad ora abbiamo visto come sia possibile aggiungere nuove funzionalità alla
libreria attraverso il metodo addFunction(). Esiste però anche un altro modo per aggiungere
funzioni alla libreria.
Se
si
osserva
attentamente
il
codice
è
possibile
notare
il
metodo
addCustomFunctions(), questo metodo è in grado di caricare da file a runtime le nuove
funzioni. Il file in cui sono contenute le informazioni riguardanti le funzioni deve essere
dichiarato come segue:
String RESOURCE_DESCRIPTOR_PATH = "/jep-functions.prop";
Nel file jep-functions.prop sono presenti I nomi e il package delle nuove funzioni, ad
esempio:
isnull=com.webratio.workflow.math.function.IsNull
int=com.webratio.workflow.math.function.ToInteger
Come è possibile notare sono dichiarate altre due nuove funzioni la cui funzione è
facilmente intuibile.
6.2.4 Workflow Index Unit
Possiamo dire che la Workflow Index Unit è la unit simbolo dell’estensione per i
workflow. La unit può essere utilizzata per recuperare i dati contenuti nell’entità collegata
all’entità Activity Instance, chiameremo questa entità d’ora in avanti Work Item, così come
visibile nella Figura 34.
Grazie a questa unit è quindi possibile recuperare tutti i work item collegati con una
certa activity instance. Per fare in modo che la unit possa recuperare queste informazioni è
necessario specificare innanzitutto la relazione tra il work item e l’activity instance, inoltre
bisogna specificare l’ID del processo e dell’activity e i loro rispettivi stati. La unit visualizzerà
quindi la lista dei work item come una normale index unit.
Ancora una volta, sviluppando la nostra applicazione Web, abbiamo incontrato
difficoltà nel recuperare dal database informazioni utili per rendere l’ipertesto più funzionale
79
Progettazione e implementazione delle unit di Workflows
per l’utente. Abbiamo deciso quindi di potenziare questa unit affinchè potessero essere
disponibili parametri in input.
Ad esempio sarebbe stato interessante per la nostra applicazione poter visualizzare tutte
le activity instance assegnate ad un certo utente (naturalmente all’interno di una istanza di un
processo). Per ottenere questo risultato, per prima cosa, è necessario selezionare come entità
non il “Work Item” ma “Activity Instance”, in questo modo la workflow index unit
visualizzerà tutte le activity instance del processo, sempre con la possibilità di poter scegliere
lo stato sia del processo che dell’attività. Naturalmente tutto questo non era sufficiente per il
nostro scopo.
Abbiamo quindi aggiunto come parametri di input

Restrict on Assign

Restrict on Executor
Entrambi servono per selezionare l’utente di interesse, la differenza risiede naturalmente dal
legame che l’utente ha con l’activity.
Nel caso di “Restrict on Assign” vengono selezionate soltanto le activity che sono state
assegnate all’utente specificato come parametro di input.
Nel caso in cui l’OID dell’utente venga passato come parametro a “Restrict on
Executor” le attività visualizzate saranno quelle eseguite dall’utente specificato.
Naturalmente la possibilità di elaborare parametri in input aumenta notevolmente il
potenziale della Workflow Index Unit e più in generale di qualsiasi unit. I parametri in input
sopra descritti possono infatti essere utilizzati anche per selezionare i “Work Item” assegnati
ad un utente.
Come già visto in precedenza per aggiungere parametri in input e necessario modificare
il relativo file xsl e modificare il codice del servizio della unit affinchè possa gestire questi
parametri. Di seguito riporteremo la figura che mostra la possibilità di utilizzare i due
parametri e la parte del file input-parameter.xsl in cui vengono definiti i due parametri,
omettiamo invece il codice Java della unit in quanto molto complicato e quindi difficilmente
spiegabile in questo contesto.
80
Progettazione e implementazione delle unit di Workflows
Figura 38 - Parametri in input della Workflow Index Unit
<xsl:template match="WORKFLOWINDEXUNIT" mode="input-parameters">
<xsl:variable name="unit-id" select="@id"/>
<logic:input-parameters>
<logic:input-parameter name="{@id}.user" type="entity/{'User'}"
clear-onincoming-link-click="yes" label="Restrict on Assign"/>
<logic:input-parameter name="{@id}.executor" type="entity/{'User'}"
clearon-incoming-link-click="yes" label="Restrict on
Executor"/>
6.2.5 Assign Unit
La funzione della Assign Unit è quella di collegare il work item con l’activity instance e
con degli utenti. Nella versione esistente la unit si limitava a collegare il work item con
l’activity instance mentre l’assegnamento agli utenti del work item era opzionale. Durante lo
studio dei workflow, applicati soprattutto in attività aziendali, abbiamo capito che assegnare
ad un attore una attività non poteva essere una operazione opzionale ma sarebbe dovuta essere
la regola. In una azienda non avrebbe senso infatti avere un compito da eseguire e nessuno
preposto a farlo.
Abbiamo deciso quindi di rendere i seguenti parametri in input obbligatori:

Set of Work Items

Set of Users
Inoltre precedentemente l’Assign Unit permetteva di fare l’assegnamento del work item
soltanto una volta, cioè una volta assegnato il work item ad una activity instance, ed
eventualmente ad un utente, non era più possibile modificarlo.
Pensando ai workflow utilizzati realmente, si può facilmente capire che questa era una
limitazione piuttosto grossolana che limitava il designer nello sviluppo dell’applicazione. Per
capire meglio basti pensare ad una gerarchia dove un supervisore assegna i compiti ai vari
81
Progettazione e implementazione delle unit di Workflows
attori del workflow. Se ad esempio il supervisore si accorgesse di aver sbagliato
l’assegnamento o che è disponibile nuovo materiale, oppure semplicemente che il numero di
persone a cui ha assegnato quel compito non è sufficiente, non potrebbe fare nulla per riparare
all’errore.
Ci è sembrato quindi logico aggiungere questa possibilità per aumentare il potenziale
della unit e la flessibilità dei workflow sviluppati con WebRatio. Le modifiche effettuate alla
unit sono state principalmente due:

L’aggiunta di parametri in input, affinchè si potesse specificare l’activity
instance a cui modificare l’assegnamento e il case d’appartenenza.

L’introduzione nella unit di due proprietà che permettono di decidere se
mantenere gli assegnamenti preesistenti oppure cancellarli a favore dei
nuovi.
Nella figura sottostante sono raffigurati tutti i parametri in input della unit.
Figura 39 - Input parameters della Assign Unit
82
Progettazione e implementazione delle unit di Workflows
Figura 40 - Proprietà della Assign Unit
In Figura 40 sono visibile le due proprietà, chiamate rispettivamente Work Items Policy
e Users Policy, che danno la possibilità di scegliere se aggiungere i nuovi assegnamenti
oppure sovrascrivere i vecchi.
Selezionando Add, che è la politica di default, gli assegnamenti del work item e degli
utenti all’activity instance saranno semplicemente aggiunti a quelli preesistenti. Nel caso in
cui invece la politica selezionata sia Replace verrano prima di tutto cancellati gli
assegnamenti preesistenti e successivamente creati quelli nuovi.
Anche questa volta è stato necessario modificare il file in cui vengono definiti i
parametri di input, è stato però anche necessario modificare il file operation.xsl. In questo file
sono definite le regole che permettono di generare le query SQL che saranno poi utilizzate dal
servizio Java per recuperare i dati dal database. Riportiamo solo una piccola parte del codice
Java, e in particolare la parte in cui vengono chiamati i metodi che permettono di connettere il
work item e gli utenti all’activity instance a seconda della politica selezionata.
if (inputAI == true) {
// Users Policy
if (usersPolicy.equals(ADD_POLICY)) {
logDebug("Connecting users to Activity Instance (Add Policy)");
aas.assign2User(getStringArray(users),
getStringValue(activityInstanceOID),
operationContext,sessionContext);
}
else if (usersPolicy.equals(REPLACE_POLICY)) {
logDebug("Connecting users to Activity Instance (Replace Policy)");
disconnectUsers(activityInstanceOID,
operationContext, sessionContext);
83
Progettazione e implementazione delle unit di Workflows
aas.assign2User(getStringArray(users),
getStringValue(activityInstanceOID),
operationContext,sessionContext);
}
else {
throw new RTXException("Undefined Users policy");
}
}
else {
aas.assign2User(getStringArray(users),
getStringValue(activityInstanceOID),
operationContext, sessionContext);
}
entityOID = operationContext.get(id + WfConstants.WITEM_OP_KEY);
if (null != entityOID) {
if (inputAI == true) {
// Work Items Policy
if (workItemsPolicy.equals(ADD_POLICY)) {
logDebug("Connecting work items to Activity Instance
(Add Policy)");
connectItems(getStringArray(activityInstanceOID),
getStringArray(entityOID), operationContext, sessionContext);
}
else if (workItemsPolicy.equals(REPLACE_POLICY)) {
logDebug("Connecting work items to Activity Instance
(Replace Policy)");
disconnectItems(activityInstanceOID,
operationContext, sessionContext);
connectItems(getStringArray(activityInstanceOID),
getStringArray(entityOID),
operationContext, sessionContext);
}
else {
throw new RTXException("Undefined Work Items policy");
}
}
else {
connectItems(getStringArray(activityInstanceOID),
getStringArray(entityOID),
operationContext, sessionContext);
}
}
6.2.6 Get Activity Status Unit
Qeusta unit permette di recuperare lo stato di una determinata activity instance. Essa è
particolarmente utile nel caso in cui l’assegnamento dell’attività successiva è legata a
particolari vincoli riguardanti le attività precedenti. Attraverso questa unit è possibile quindi
recuperare lo stato di altre attività ed utilizzare queste informazioni per decidere il percorso
navigazionale dell’utente e più in generale del workflow.
La unit si rivela molto utile anche nel caso in cui si voglia avere una panoramica dello
stato delle varie attività del workflow. Utilizzando l’output della unit congiuntamente ad altre
84
Progettazione e implementazione delle unit di Workflows
unit è possibile realizzare pagine web da cui è possibile monitorare l’avanzamento del
workflow.
Anche per questa unit è stato aggiunto il parametro in input che permette di specificare
il case del processo. La unit permette poi di aver come risultato di output l’OID dell’activity
instance status oppure il nome dello stato in cui si trova l’activity. Questo permette al designer
dell’applicazione di costruire in maniera più semplice la pagina contenente la unit.
Figura 41 - Input parameter della Get Status Unit
Figura 42 - I due parametri in output forniti dalla Get Status Unit
85
7 L’applicazione Web Online
Publications
In questo capitolo presenteremo l’applicazione Web che abbiamo sviluppato con
WebRatio. L’applicazione è stata progettata appositamente per rilevare gli eventuali limiti
delle unit del tool. Possiamo dire quindi di aver raggiunto l’obiettivo, infatti durante la
progettazione dell’applicazione numerose sono state le limitazioni emerse. Abbiamo in primo
luogo cercato di sviluppare comunque l’applicazione in modo da capire quali potessero i
riflessi sullo schema WebML dell’applicazione. Successivamente abbiamo progettato e
implementato le modifiche necessarie alle unit affinché potessero essere utilizzate in maniera
più proficua nella nostra applicazione ma in generale in qualsiasi ipertesto basato sui
workflow.
Dopo aver modificato le unit, abbiamo riprogettato l’applicazione in modo da vedere i
benefici derivanti dalle modifiche effettuate. Le modifiche hanno permesso di rendere lo
schema WebML più semplice e leggibile ed hanno inoltre facilitato quello che è il lavoro del
designer senza contare il notevole aumento delle funzionalità delle unit.
86
L’applicazione Web Online Publications
Figura 43 - Home Page dell'autore
87
L’applicazione Web Online Publications
7.1 Descrizione dello scenario
L’applicazione ha come obbiettivo quello di consentire una gestione online del
processo che porta alla pubblicazione di un articolo sul sito Web di una testata giornalistica.
Secondo il modello, un autore registrato propone la pubblicazione di un articolo,
specificando il titolo, la data di pubblicazione desiderata, il testo ed eventuali foto, oltre ad
altri eventuali autori, che possono collaborare alla stesura dello stesso. L’inserimento del testo
e delle foto può essere effettuata da uno qualsiasi degli autori selezionati al momento della
creazione della pubblicazione e le due attività possono essere effettuate a distanza di tempo e
nell’ordine desiderato.
Una volta terminate queste attività di inserimento, è compito del direttore esaminare
l’articolo e decidere se dovrà essere analizzato ulteriormente oppure scartato. Nel primo caso,
il direttore darà l’autorizzazione affinché l’articolo venga analizzato da altre persone, mentre
nel secondo caso verrà semplicemente eliminato.
La prima persona coinvolta, dopo l’approvazione da parte del direttore, è un generico
impiegato che potrà decidere se mandare l’articolo indietro all’autore affinché possa
apportarvi delle migliorie, allegando una breve descrizione delle modifiche da apportare,
oppure se continuare il processo che porterà alla pubblicazione dell’articolo. Se l’impiegato
giudica negativamente il testo, uno degli autori autorizzati potrà effettuare le modifiche
richieste e a sua volta allegare un messaggio per l’impiegato (ad esempio spiegando il perché
di talune scelte). Invece nel caso in cui l’articolo sia giudicato positivamente, il processo potrà
continuare e si suddividerà in due attività parallele.
In una attività il testo sarà esaminato per eliminare eventuali errori grammaticali
sempre da un impiegato, mentre nell’altra un publisher avrà la possibilità di effettuare una
selezione sulle foto inviate dall’autore (sia con la possibilità sia di aggiungerne di nuove, che
di eliminare quelle inviate dall’autore). Al termine di entrambi questi ulteriori controlli
l’articolo corretto e le foto selezionate saranno passati ad un altro impiegato (publisher) che
avrà il compito di pubblicare l’articolo sul sito terminando così il processo.
Passando allo sviluppo vero e proprio dell’applicazione occorre innanzitutto
considerare il flusso di lavoro, le attività che lo compongono e gli attori incaricati di svolgere
queste attività. Di seguito verranno presentate la lista degli attori con i loro requisiti
funzionali, la lista delle attività e il workflow del processo.
88
L’applicazione Web Online Publications
7.2 Lista degli attori
L’applicazione presenta cinque diversi attori, che possono svolgere attività differenti.

Utente generico

Autore

Direttore

Impiegato

Editore
Ad ogni attore è associata una specifica site-view in cui può svolgere le attività di sua
competenza. Di seguito sono presentati i requisiti funzionali di ogni singolo attore coinvolto.
7.2.1 Utente generico
Nome del gruppo
Utente esterno non registrato
Descrizione
Visitatori generici interessati agli articoli pubblicati
Dati di profilo
Nessun profilo – gli utenti esterni non hanno bisogno di
credenziali per l’autenticazione e non necessitano di alcuna
personalizzazione
Oggetti accessibili in lettura
Articoli pubblicati e informazioni varie
Oggetti accessibili in scrittura
Nessuno. Le operazioni di gestione dei contenuti non sono
consentite
7.2.2 Autore
Nome del gruppo
Utente esterno non registrato
Descrizione
Visitatori generici interessati agli articoli pubblicati
Dati di profilo
Nessun profilo – gli utenti esterni non hanno bisogno di
credenziali per l’autenticazione e non necessitano di alcuna
personalizzazione
Oggetti accessibili in lettura
Articoli pubblicati e informazioni varie
Oggetti accessibili in scrittura
Nessuno. Le operazioni di gestione dei contenuti non sono
consentite
89
L’applicazione Web Online Publications
7.2.3 Direttore
Nome del gruppo
Utente esterno non registrato
Descrizione
Visitatori generici interessati agli articoli pubblicati
Dati di profilo
Nessun profilo – gli utenti esterni non hanno bisogno di
credenziali per l’autenticazione e non necessitano di alcuna
personalizzazione
Oggetti accessibili in lettura
Articoli pubblicati e informazioni varie
Oggetti accessibili in scrittura
Nessuno. Le operazioni di gestione dei contenuti non sono
consentite
7.2.4 Impiegato
Nome del gruppo
Utente esterno non registrato
Descrizione
Visitatori generici interessati agli articoli pubblicati
Dati di profilo
Nessun profilo – gli utenti esterni non hanno bisogno di
credenziali per l’autenticazione e non necessitano di alcuna
personalizzazione
Oggetti accessibili in lettura
Articoli pubblicati e informazioni varie
Oggetti accessibili in scrittura
Nessuno. Le operazioni di gestione dei contenuti non sono
consentite
7.2.5 Editore
Nome del gruppo
Utente esterno non registrato
Descrizione
Visitatori generici interessati agli articoli pubblicati
Dati di profilo
Nessun profilo – gli utenti esterni non hanno bisogno di
credenziali per l’autenticazione e non necessitano di alcuna
personalizzazione
Oggetti accessibili in lettura
Articoli pubblicati e informazioni varie
Oggetti accessibili in scrittura
Nessuno. Le operazioni di gestione dei contenuti non sono
consentite
90
L’applicazione Web Online Publications
7.3 Activity List e Workflow

Creazione della pubblicazione (titolo, data e lista degli autori)

Inserimento del testo

Inserimento delle immagini

Approvazione del direttore

Controllo contenuti

Invio di un commento (opzionale)

Modifica del testo (opzionale)

Controllo ortografico

Controllo e selezione delle immagini

Approvazione finale
Le attività di “Inserimento testo” e di “Inserimento immagini” possono essere effettuate
in ordine differente e non necessariamente una di seguito all’altra. Inoltre possono essere
svolte da uno qualsiasi degli autori selezionati al momento della creazione della
pubblicazione.
Le attività di “Modifica del testo” e di “Invio di un commento” vengono effettuate
solamente se al momento del “Controllo” l’impiegato non giudica positivamente l’articolo.
Le attività di “Controllo ortografico” e di “Controllo e selezione delle immagini” sono
svolte in parallelo da due attori differenti ed è possibile svolgere l’ultima attività solo al
termine di quest’ultime.
Notiamo inoltre che
tutte le attività successive all’“Approvazione del direttore”
vengono svolte solamente se il giudizio del direttore è positivo.
91
L’applicazione Web Online Publications
7.3.1 Il workflow dell’applicazione
E’ ora analizzato il flusso dell’applicazione in modo grafico (Figura 44), utilizzando
rettangoli per rappresentare le attività e frecce per rappresentare la successione temporale
degli eventi.
Article
Publication
Article
Text
Author
Comment
Articles
Photos
Modify
Validation
Content
Check
Employ
ee
Directo
r
No Photo
Spell Check
Publish
er
Photo
Selection
Publication
Figura 44 - Il workflow dell'applicazione
7.4 L’applicazione
Prendendo in considerazione l’applicazione creata con WebRatio è utile strutturare la
documentazione come lo sviluppo dell’applicazione stessa, ovvero considerando in un primo
momento lo schema Entità – Relazione della stessa e successivamente le differenti site-view
che la compongono, evidenziando gli aspetti più importanti.
7.4.1 Il modello entità–relazione
Il modello E-R su cui si basa l’intera applicazione è un modello che oltre a essere stato
creato in base ai requisiti dell’applicazione stessa, deve contenere anche i meta-dati utilizzati
per effettuare un controllo esplicito di tipo pull sull’avanzamento del processo. Il risultato
finale della progettazione è visibile in Figura 45.
92
L’applicazione Web Online Publications
Le tabelle relative ai meta-dati (Process, Activity, Case, Activity Instance, CaseStatus,
Activity Instance Status) contengono le informazioni specifiche sul processo, le attività e gli
stati associati, mentre altre tabelle (User, Group, SiteView) sono tabelle standard che vengono
prese in considerazione in ogni progetto, vista la sempre presente necessità di associare agli
utenti un gruppo ed una specifica vista associata.
Le restanti entità sono necessarie per contenere i dati relativi all’articolo (Publication), i
dati relativi alle immagini associate ad un certo articolo (Photo) ed i commenti e suggerimenti
degli impiegati e degli autori (rispettivamente Employee Comment e Author Comment).
L’entità TextChunk è utilizzata per memorizzare le informazioni testuali o le immagini
utilizzati per la composizione delle pagine dell’applicazione.
Figura 45 - Il modello dei dati dell'applicazione Online Publications
Analizziamo ora più in dettaglio le entità specifiche dell’applicazione.
93
L’applicazione Web Online Publications
7.4.1.1 Entità User
Attributo
Tipo di
Dato
Descrizione
OID
OID
Identificativo dell’oggetto
UserName
Stringa
Specifica l’identificativo univoco
dell’utente
Password
Password
Indica la password utilizzata per l’accesso
EMail
Stringa
Specifica l’indirizzo e-mail dell’utente
Name
Stringa
Nome dell’utente
LastName
Stringa
Cognome dell'utente
Attributo
Tipo di
Dato
Descrizione
OID
OID
Identificativo dell’oggetto
UserName
Stringa
Specifica l’identificativo univoco
dell’utente
Password
Password
Indica la password utilizzata per l’accesso
EMail
Stringa
Specifica l’indirizzo e-mail dell’utente
Name
Stringa
Nome dell’utente
LastName
Stringa
Cognome dell'utente
7.4.1.2 Entità Publication
94
L’applicazione Web Online Publications
7.4.1.3 Entità Photo
Attributo
Tipo di
Dato
Descrizione
OID
OID
Identificativo dell’oggetto
UserName
Stringa
Specifica l’identificativo univoco
dell’utente
Password
Password
Indica la password utilizzata per l’accesso
EMail
Stringa
Specifica l’indirizzo e-mail dell’utente
Name
Stringa
Nome dell’utente
LastName
Stringa
Cognome dell'utente
Attributo
Tipo di
Dato
Descrizione
OID
OID
Identificativo dell’oggetto
Text
Testo
Specifica il testo del commento
Attributo
Tipo di
Dato
Descrizione
OID
OID
Identificativo dell’oggetto
Text
Testo
Specifica il testo del commento
7.4.1.4 Entità Employee Comment
7.4.1.5 Entità Author Comment
95
L’applicazione Web Online Publications
7.4.1.6 Entità TextChunk
Attributo
Tipo di
Dato
Descrizione
OID
OID
Identificativo dell’oggetto
Title
Testo
Il titolo del textchunk
Text
Testo
Specifica il testo che verrà visualizzato
Image
BLOB
L’immagine associata al textchunk
7.4.2 Struttura dell’applicazione
L’applicazione è composta da più site-view (una per ogni attore più una per il visitatore
generico), di cui daremo ora una visione complessiva, analizzando in particolare le strutture
più complesse e che hanno richiesto una particolare attenzione.
Figura 46 - Elenco delle site-view presenti nel sito
7.4.2.1 Public site-view
E’ la site-view visualizzata dal visitatore generico al momento della visita nel sito.
Permette agli utenti del sito web di visualizzare gli articoli pubblicati e di avere alcune
informazioni di base sulla testata giornalistica online. E’ presente un’area che permette agli
utenti registrati di effettuare il login (Figura 47).
96
L’applicazione Web Online Publications
Figura 47 - Public Site-View
7.4.2.2 Author site-view
Questa site-view è la più estesa e più complessa dell’intera applicazione. Analizziamo
quindi le parti fondamentali che la compongono, riportando un’accurata descrizione dei
passaggi più importanti che altrimenti risulterebbero quasi incomprensibili.
7.4.2.2.1 Home page
La home page è la pagina in cui si trova l’autore in seguito ad un login effettuato con
successo. Dalla home page l’autore può creare un nuovo articolo, così come mostrato in
Figura 43.
97
L’applicazione Web Online Publications
E’ possibile indicare il titolo e selezionare da una lista gli autori che potranno
collaborare alla stesura dell’articolo stesso. Sono visibili le tre Assign Unit necessarie per
creare le tre attività che verranno svolte successivamente nel corso del processo assegnandole
agli utenti selezionati . Si noti come, nonostante siano in mutua esclusione, è necessario creare
sia l’activity Articles Photo che l’activity NoPhoto (Figura 48).
Figura 48 - Creazione di un nuovo articolo
Inoltre è necessario salvare l’OID delle activity create in tre variabili globali in modo
da poterli utilizzare nelle sezioni di inserimento del testo e di selezione delle immagini.
Soltanto in questo modo è possibile poi evitare un nuovo inserimento da parte di uno degli
autori del testo o delle immagini e rispettare la condizione di “and” presente tra le due
activity.
Dalla Home Page inoltre, l’autore può trovare i link che lo conducono alla Todo Page e
alla Publication to Modify sezioni la cui funzione è spiegata nei paragrafi seguenti.
7.4.2.2.2 Todo Page
98
L’applicazione Web Online Publications
Questa sezione permette di visualizzare gli articoli ancora da completare di competenza
dell’utente, suddivisi in base all’activity ancora da compiere (inserimento testo o selezione
immagini). Nella prima versione dell’applicazione a causa delle limitazioni poste dalla
Workflow Index Unit lo schema WebML della pagina risultava molto confuso come
constatabile in Figura 33. Infatti non era prevista la possibilità di visualizzare solamente le
attività assegnate all’utente presente in quel momento nel sito web.
A seguito della reimplementazione della unit lo schema è costituito soltanto dalle
workflow index unit, esse visualizzeranno rispettivamente gli articoli senza testo e quelli
senza foto, oltre è presente una Get Unit che fornisce in input alla workflow index unit
l’utente corrente (Figura 49).
Figura 49 - Todo Page dell'autore
7.4.2.2.3 Publication to modify
Questa parte della site-view permette ad uno degli autori associati all’articolo di
modificarlo in seguito ad un parere negativo da parte di un impiegato. Inoltre permette di
99
L’applicazione Web Online Publications
associare un commento alle modifiche che potrà essere letto dall’impiegato che visionerà
nuovamente l’articolo.
Anche la sezione Publication to modify ha beneficiato dei migliorie apporta alla
Workflow Index Unit, basta infatti confrontare le due figure qui di seguito per constatare
l’enorme differenza.
Figura 50 - Publication to modify prima della reimplementazione delle unit
Figura 51 - La nuova pagina Publication to modify
7.4.2.2.4 Inserimento del testo
In questa sezione, a cui l’autore accede o dopo aver creato la pubblicazione o dalla
Todo Page, uno degli autori selezionati al momento della creazione dell’articolo ha la
100
L’applicazione Web Online Publications
possibilità di inserire il testo dell’articolo stesso. Se all’articolo sono già state allegate delle
foto oppure si è scelto di non allegarvi foto, al completamento dell’attività di inserimento del
testo l’articolo viene passato automaticamente al direttore affinchè lo approvi.
7.4.2.2.5 Inserimento delle foto
Qui l’autore ha due possibilità, così come si può dedurre dal diagramma del workflow
(Figura 44). Può scegliere se allegare una o più immagini all’articolo oppure se non allegarne
alcuna. Nel primo caso ha la possibilità sia di selezionare una delle immagini disponibili del
database del giornale sia di inserire a sua volta un’immagine (Figura 52). Nel secondo caso
invece l’autore semplicemente decide che l’articolo non avrà nessuna immagine. Al termine
di una di queste attività, se l’inserimento del testo è stato completato, l’articolo viene passato
all’attività successiva.
Figura 52 - L'area che contiene la pagine che permettono di aggiungere foto all'articolo
Nella Figura 52 possiamo anche notare l’utilizzo della Get Status Unit grazie ad essa è
possibile sapere se l’attività di inserimento del testo è stata già completata oppure no. Il
parametro sarà trasportato dai vari link fino a raggiungere la Test Unit che valuterà se
entrambe le attività necessarie affinchè l’articolo possa essere passato al direttore sono state
completate correttamente.
Un altro particolare interessante che si può notare nella Figura 52 è l’utilizzo della Test
Unit per controllare se è stata effettivamente selezionata la foto. Durante il lavoro sulla Test
101
L’applicazione Web Online Publications
Unit ci siamo anche concentrati sul tipo di dati supportato dalle varie funzioni, aggiungendo
tra l’altro il tipo BLOB tra i tipi di dato supportato almeno dalle funzioni più semplici come ad
esempio isnull( )
7.4.2.3 Director site-view
E’ la site-view riservata ai direttori della testata giornalistica online.
7.4.2.3.1 Approvazione dell’articolo
Gli utenti appartenenti al gruppo Director possono visionare l’articolo, leggendo il testo e
visualizzando le eventuali immagini corredate ad esso, quindi decidere se approvare l’articolo
oppure scartarlo (Figura 53). Se l’articolo viene approvato verrà successivamente analizzato
dagli impiegati.
Figura 53 - Area contenente le pagine utilizzate dal direttore per approvare l'articolo
102
L’applicazione Web Online Publications
7.4.2.4 Employee site-view
Questa site-view è dedicata agli impiegati del giornale, che possono effettuare sia la verifica
dei contenuti sia il controllo ortografico dell’articolo.
7.4.2.4.1 Controllo dei contenuti
In questa sezione l’impiegato visiona i contenuti dell’articolo e decide se gli argomenti trattati
sono esposti in modo chiaro e corretto oppure se è necessario apportare delle modifiche
all’articolo per procedere con la pubblicazione. Nel caso in cui l’articolo non superi il
controllo, l’impiegato ha la possibilità di inserire un commento che verrà visionato dall’autore
al momento della correzione (Figura 54).
Figura 54 - La pagina che permette di inserire un commento per l’autore
7.4.2.4.2 Controllo ortografico
Oltre ad effettuare il controllo dei contenuti, l’impiegato deve effettuare, in un secondo
momento, il controllo ortografico dell’articolo correggendo così eventuali errori di
digitazione. Tale attività è svolta in parallelo al controllo e selezione delle immagini inserite
svolta dal publisher.
103
L’applicazione Web Online Publications
7.4.2.5 Publisher site-view
Il publisher (editore) è l’ultimo attore del workflow, il quale, selezionando prima le foto
con cui verrà pubblicato sul sito l’articolo e successivamente pubblicando l’articolo stesso
(previo controllo ortografico da parte dell’impiegato), conclude il processo di pubblicazione.
Figura 55 - Home Page del publisher
7.4.2.5.1 Controllo e selezione immagini
Come spiegato sopra, una delle attività dell’editore è quella di selezionare le foto
allegate all’articolo da parte dell’autore, eventualmente eliminandone qualcuna e/o
104
L’applicazione Web Online Publications
aggiungendone delle nuove
presenti nel database del giornale (naturalmente attinenti
all’articolo)
7.4.2.5.2 Pubblicazione
In questa parte della site-view l’editore può concludere il processo decidendo di
pubblicare l’articolo con le eventuali foto sul sito, in modo da rendere disponibile sul sito del
giornale l’articolo (Figura 56).
Figura 56 - Home Page del sito dal quale è possibile leggere gli articoli pubblicati
105
8 Conclusioni
Il lavoro di tesi si è concentrato sullo studio dei Workflow e del loro utilizzo in
ipertesti. Si è cercato di capire come si potessero progettare ipertesti basati sui workflow in
WebML. Sono stati analizzati i costrutti esistenti in WebML cercando di individuare le
possibili debolezze e limitazioni.
Individuate le limitazioni si sono progettate le migliorie necessarie per poter utilizzare
al meglio i costrutti di WebML nella progettazione degli ipertesti basati sui workflow.
L’attività di implementazione svolta è consistita quindi nel migliorare le unit di Workflow.
Il lavoro è stato quindi completato con successo e l’implementazione dell’applicazione
è stata eseguita seguendo le specifiche stabilite in fase di progettazione. Il lavoro di sviluppo
dell’applicazione è stato in un primo tempo mirato a produrre una soluzione compatibile con
l’attuale versione di WebRatio, con particolare attenzione per quanto riguarda
l’individuazione di possibili espansioni future da implementare, e successivamente si è
sviluppata la versione definitiva dell’applicazione che rappresenta un esempio significativo
dell’utilizzo dei workflow in ipertesti e mostra tutte le potenzialità di WebML e della sua
estensione orientata ai workflow.
8.1 Sviluppi futuri
Nel corso del lavoro di tesi sono state riscontrate alcune limitazioni del modello
WebML per i workflow. Gran parte di esse sono state affrontate e risolte nel corso
dell’attività svolta: le unit di workflow, in seguito alle migliorie apportate, possono essere
utilizzate per sviluppare una più ampia gamma di ipertesti basati su processi di business.
Un aspetto non affrontato dal presente lavoro e su cui in futuro è previsto uno sviluppo
ulteriore è sicuramente quello della sicurezza dell’applicazione Web. Attualmente in
WebRatio è possibile utilizzare il protocollo https; questo però non è sufficiente ad assicurare
una sicurezza legata alle singole sessioni degli utenti, che ad esempio sono direttamente
accessibili attraverso url salvati in precedenza. Le nuove unit introdotte inoltre richiedono una
verifica più approfondita dei criteri di sicurezza e robustezza che una applicazione di business
richiede.
106
Conclusioni
Inoltre per migliorare l’utilizzo dei workflow sarà necessario aggiungere la possibilità
di gestione degli errori e delle eccezioni. In più casi infatti, durante il testing
dell’applicazione, si è incappati in uno stato di inconsistenza per il workflow [16].
Le situazioni di errore si sono verificate principalmente per due motivi:
 Un incorretto comportamento dell’utente durante la navigazione.
 Un errore tecnico nel sistema di gestione del workflow o del sito Web.
A seguito di errori di questo tipo, il workflow si ritrova in uno stato inconsistente e
quindi non è possibile continuare il processo. Sarà quindi necessario in futuro definire una
politica di recupero dello stato e implementarla nel tool.
Un altro aspetto da aggiungere per aumentare la gamma di workflow progettabili
utilizzando WebML è la possibilità di utilizzare vincoli temporali nella definizione del
workflow.
Per quanto riguarda WebRatio, una funzione che potrebbe risultare utile ed interessante
da sviluppare è la possibilità di generare in modo automatico, a partire dallo schema BPML
del workflow, lo scheletro dell’ipertesto dell’applicazione web rappresentante il workflow.
107
Appendice A – Potere Espressivo Unit
In questa Appendice descriveremo come scrivere espressioni e quali funzioni sono
supportate dalle due unit che utilizzano la libreria JEP [15], cioè la Expression Parsing Unit e
la Test Unit.
In primo luogo descriviamo la sintassi delle espressioni e la grammatica
utilizzata dalla libreria, quindi attraverso l’utilizzo di tabelle riportiamo le varie funzioni
utilizzabili e i tipi di dati da esse supportate. Infine presentiamo alcuni esempi che possono
chiarire l’utilizzo delle funzioni e un paragrafo dedicato alla formattazioni delle date che sono
utilizzabili nelle funzioni che gestiscono questo tipo di dato.
1
Sintassi
La sintassi delle espressioni accettate dalle unit è simile alla tradizionale sintassi
matematica. Sia i predicati che le variabili sono naturalmente supportati. Formalmente, non ci
sono limiti sulla complessità delle espressioni valutate.
Alcuni esempi sono riportati di seguito:
x + y
log(x) + sin(y)
sum([x, y, z])
today()
avg([x, y], max(sum(z, w), v))
x && (y || z)
x >= (y % z)
2
Grammatica
Questa grammatica è stata generata dal file Parser.jjt usando l’utility jjdoc contenuta in
JavaCC. Gli Operatori sono ordinati in ordine di precedenza, dal minore al maggiore.
108
Appendice A – Potere Espressivo Unit
3
Start
::=
Expression
OrExpression
::=
::=
AndExpression
::=
EqualExpression
::=
RelationalExpression
::=
AdditiveExpression
::=
MultiplicativeExpression
::=
UnaryExpression
::=
PowerExpression
::=
UnaryExpressionNotPlusMinus
::=
Variable
Function
ArgumentList
Identifier
AnyConstant
::=
::=
::=
::=
::=
Array
RealConstant
::=
::=
( Expression <EOF>
| <EOF> )
OrExpression
AndExpression (
( "||" AndExpression ) )*
EqualExpression (
( "&&" EqualExpression ) )*
RelationalExpression (
( "!=" RelationalExpression )
| ( "==" RelationalExpression ) )*
AdditiveExpression (
( "<" AdditiveExpression )
| ( ">" AdditiveExpression )
| ( "<=" AdditiveExpression )
| ( ">=" AdditiveExpression ) )*
MultiplicativeExpression (
( "+" MultiplicativeExpression )
| ( "-" MultiplicativeExpression ) )*
UnaryExpression (
( PowerExpression )
| ( "*" UnaryExpression )
| ( "/" UnaryExpression )
| ( "%" UnaryExpression ) )*
( "+" UnaryExpression )
| ( "-" UnaryExpression )
| ( "!" UnaryExpression )
| PowerExpression
UnaryExpressionNotPlusMinus (
( "^" UnaryExpression ) )?
AnyConstant
| ( Function | Variable )
| "(" Expression ")"
( Identifier )
( Identifier "(" ArgumentList ")" )
( Expression ( "," Expression )* )?
<IDENTIFIER>
( <STRING_LITERAL>
| RealConstant
| Array )
"[" RealConstant ( "," RealConstant )* "]"
( <INTEGER_LITERAL>
| <FLOATING_POINT_LITERAL> )
Tipi di variabili
La Expression Parsing Unit permette l’utilizzo di vari tipi di variabili, non tutte le
funzioni però accettano tutti i tipi di dato supportati.
109
Appendice A – Potere Espressivo Unit
Nella figura sottostante è possibile vedere i tipi di dato utilizzabili per una variabile.
Figura 57 - Tipi di dato utilizzabili per le variabili
Quattro sono i tipi di dato utilizzabili:




String: il classico tipo stringa
Number: qualsiasi numero reale
Date: una data valida. Il formato di default è gg/mm/aaaa
Boolean: variabile di tipo booleano. I possibile valori per vero sono: 1, “true”,
“yes”
4
Operatori
Tutti i comuni operatori aritmetici sono supportati. Gli operatori booleani sono
anch’essi supportati. Le espressioni booleane possono naturalmente essere vere o false (1 e 0
rispettivamente)
Il simbolo
indica che l’operatore può essere con quello specifico tipo di variabile.
Function
Power
Boolean Not
Unary Plus, Unary Minus
Modulus
Division
Multiplication
Addition
Subtraction
Less or Equals, More or
Equal
Less Than, More Than
Not Equal, Equal
Boolean And
Boolean Or
Symbol
^
!
+x, -x
%
/
*
+
<=, >=
String
Number
Date
Boolean
Array
<, >
!=, =
&&
||
110
Appendice A – Potere Espressivo Unit
5
Funzioni predefinite
5.1 Funzioni matematiche
Ciascuna delle seguenti funzioni possono essere utilizzate con i tipi di dato indicati.
Function
Power
Boolean Not
Unary Plus, Unary Minus
Modulus
Division
Multiplication
Addition
Subtraction
Less or Equals, More or
Equal
Less Than, More Than
Not Equal, Equal
Boolean And
Boolean Or
6
Symbol
^
!
+x, -x
%
/
*
+
<=, >=
String
Number
Date
Boolean
Array
String
Number
Date
Boolean
Array
<, >
!=, =
&&
||
Altre funzioni
6.1 Funzioni SQL
Function
Sum
Maximum
Minimum
Average
Enumeration
Symbol
sum()
max()
min()
avg()
count()
6.1.1 Sum
sum(( RealConstant | Array ) ( “,” ( RealConstant | Array ) )*)
Ritorna un RealConstant che rappresenta la somma dei numeri.
Se la funzione riceve un Array sommerà tutti gli elementi dell’array.
6.1.2 Maximum
max(( RealConstant | Array ) ( “,” ( RealConstant | Array ) )*)
Ritorna un RealConstant che rappresenta il numero maggiore tra quelli ricevuti in
ingresso.
111
Appendice A – Potere Espressivo Unit
Se viene fornito in ingresso un Array allora la funzione ritornerà come risultato il
numero maggiore tra quelli presenti nell’array.
6.1.3 Minimum
min(( RealConstant | Array ) ( “,” ( RealConstant | Array ) )*)
Ritorna un RealConstant che rappresenta il numero minore tra quelli ricevuti in
ingresso.
Se viene fornito in ingresso un Array allora la funzione ritornerà come risultato il
numero minore tra quelli presenti nell’array.
6.1.4 Average
avg(( RealConstant | Array ) ( “,” ( RealConstant | Array ) )*)
Ritorna un RealConstant che rappresenta la media dei numeri ricevuti in ingresso.
Se viene fornito in ingresso un Array allora la funzione ritornerà come risultato la
media di tutti gli elementi presenti nell’array.
6.1.5 Count
count( AnyConstant ( “,” AnyConstant )*)
Ritorna un RealConstant che rappresenta il numero di elementi ricevuti in ingresso
Se viene fornito in ingresso un Array allora la funzione ritornerà come risultato il
numero di elementi presenti nell’array.
7
Funzioni operanti sulle date
Tutte le date sono formattare nel formato gg/mm/aaaa di default. Più avanti
nell’appendice è presente un paragrafo dove vengono spiegati i vari tipi di formato
utilizzabili.
7.1 Sum of dates
datesum( date date, string period [, string output format [,
string input format]] )
date: una data correttamente formattata (es. “30/01/1984”).
period: il periodo da aggiungere alla data. Il periodo deve essere obbligatoriamente
seguito da un suffisso. Inoltre è possibile aggiungere periodi composti.
ms : milliseconds
s : seconds
m : minutes
h : hours
d : days
112
Appendice A – Potere Espressivo Unit
es. 1d sta per un giorno, 55s per cinquantacinque secondi.
output format: il formato di output della data.
input format: il formato di input della data.
Ritorna la nuova data.
7.2 Compare Dates
compareDates( date date1, date date2 [, string format] )
date1, date2: una data correttamente formattata (es. “30/01/1984”).
format: il formato delle due date fornite come input.
Ritorna 0 se le date sono uguali, un numero negativo se la prima data è antecedente
rispetto la seconda e un numero positivo se invece è il contrario.
7.3 Today
today( [string output date format] )
output date format: il formato di output della data
Ritorna la data corrente.
8
Esempi
In questa parte dell’appendice riportiamo una serie di esempi che possono aiutare a
capire meglio come utilizzare le funzioni messe a disposizione dalle unit. In tutti gli esempi
saranno utilizzate sempre variabili (es. X1, X2), per conoscere quali sono i tipi di variabili
supportati dalle varie funzioni si può fare riferimento alle tabelle precedentemente riportate.
Espressioni con operatori
L’utilizzo degli operatori in una espressione è molto semplice, riportiamo comunque di
seguito alcuni esempi.
( (X1^2) + (X2%X3) ) / X4
X1 * X2 / X3
X1<=X2 || X3>=X4
X1&&X2||X3
Espressioni con funzioni matematiche
Le funzioni matematiche disponibili utilizzano la tradizionale sintassi matematica.
Naturalmente è possibile combinare le varie funzioni tra di loro, utilizzando anche operatori,
in modo da comporre espressioni matematiche anche molto complesse.
sin(x) + cos(y)
sum(acos(x) + ln(y))
113
Appendice A – Potere Espressivo Unit
abs(x - y)
sqrt(x ^ (y + z))
Espressioni con le funzioni SQL
Le unit permettono anche l’utilizzo di cinque funzioni che appartengono tipicamente al
linguaggio SQL, questo significa che è possibile utilizzarle come si fa normalmente in SQL.
Le enormi potenzialità di queste funzioni derivano dal fatto che è possibile utilizzare gli array
come normali parametri.
sum(X1, [X2, X3], X4)
max(X1, X2)
min(X1, X2, sum(X3, X4, X5))
avg(X1, X2, sum(X3, X4), max(X5, X6))
count([X1, X2], X3)
Espressioni con funzioni operanti sulle date
Le funzioni che operano sulle date utilizzano nella Expression Unit permettono la
manipolazione delle date.
datesum(01/02/2003, 1d)
datesum(25/11/2000, 1d3h, MM/dd/yyyy)
compareDates(01/01/1983, 02/02/2002)
compareDates(12/27/1982, 05/25/2004,
MM/dd/yyyy)
today()
today(dd/MM/yyyy k z)
9
Il formato delle date
Per specificare il formato del tempo è necessario utilizzare un determinato schema
utilizzando gli adeguati suffissi. In questo schema i suffissi sono tutte lettere ASCII riportate
nella seguente tabella:
114
Appendice A – Potere Espressivo Unit
Symbol
G
y
M
d
h
H
m
s
S
E
D
F
w
W
a
k
K
z
Meaning
Era designator
Year
Month in year
Day in month
Hour in am/pm (1-12)
Hour in day (0-23)
Minute in hour
Second in minute
Millisecond
Day in week
Day in year
Day of week in month
Week in year
Week in month
Am/pm marker
Hour in a day (1-24)
Hour in am/pm (0-11)
Time zone
Presentation
Text
Number
Text & Number
Number
Number
Number
Number
Number
Number
Text
Number
Number
Number
Number
Text
Number
Number
Text
‘
‘’
Escape for text
Single quote
Delimiter
Literal
Example
AD
1996
July & 07
10
12
0
30
55
978
Tuesday
189
2 (2nd Wed in July)
27
2
PM
24
0
Pacific Standard
Time
‘
Il numero di lettere utilizzate determina il formato.
Text: 4 o più lettere riservate--usa il formato completo, < 4--usa il formato abbreviato
se esiste.
Number: il numero necessario per la specifica del formato, un numero inferiore non
viene considerato. L’anno fa eccezione, infatti se il numero di 'y' is 2, l’anno sarà mostrato a
due cifre
Text & Number: 3 o maggiore, usa text, altrimenti usa number
Qualsiasi carattere che non sia compreso tra ['a'..'z'] e ['A'..'Z'] sarà trattato come testo
tra apici. Per esempio, caratteri come ':', '.', ' ', '#' e '@' appariranno nel risultato come testo.
Uno schema contenente lettere invalide causerà il lancio di un’eccezione durante
l’elaborazione della data.
9.1 Esempi
Format Pattern
Result
"yyyy.MM.dd G 'at' hh:mm:ss z"
1996.07.10 AD at 15:08:56 PDT
"EEE, MMM d, ''yy"
Wed, July 10, '96
115
Appendice A – Potere Espressivo Unit
"h:mm a"
12:08 PM
"hh 'o''clock' a, zzzz"
12 o'clock PM, Pacific Daylight
Time
"K:mm a, z"
0:00 PM, PST
"yyyyy.MMMMM.dd GGG hh:mm
1996.July.10 AD 12:08 PM
aaa
116
Bibliografia
[1]
Paolo Atzeni, Giansalvatore Mecca, Paolo Merialdo: Design and Maintenance of
Data-Intensive Web Sites. EDBT 1998: 436-450.
[2]
Web Modelling Language web site: www.webml.org
[3]
Stefan Jablonski, Christoph Bussler: Workflow Management: Modeling Concepts,
Architecture and Implementation, Itp New Media, October 1996
[4]
Stefano Ceri, Piero Fraternali, Stefano Paraboschi: Data-Driven, One-To-One Web
Site
[5]
Generation for Data-Intensive Applications, VLDB 1999: 615-626.
[6]
Yongjie Ren, Kam-Fai, Wong, Boon Toh Low: An Integrated Approach for Flexible
Workflow Modeling. ICSC 1999
[7]
Stefano Ceri, Piero Fraternali, Aldo Bongio, Marco Brambilla, Sara Comai,
Maristella Matera: Designing Data-Intensive Web Applications, Morgan-Kaufmann,
December 2002.
[8]
Workflow Management Coalition web site: www.wfmc.org
[9]
Rob Allen: Workflow: An Introduction, WfMC External Relations Committee, 2001
[10]
WfMC White Paper: Workflow and Internet: Catalyst for Radical Change, June 1998
[11]
Chris Peltz: Web services orchestration: a review of emerging technologies, tools and
standards, Hewlett Packard, Co. January 2003
[12]
The Businesses Process Management Initiative web site: www.bpmi.org
[13]
The ebPML web site: www.ebpml.org
[14]
WebRatio web site: www.webratio.org
[15]
M. Brambilla, S. Ceri, S. Comai, P. Fraternali, I. Manolescu: Specification and
Design of Workflow-Driven Hypertexts, Journal of Web Engineering (JWE), vol.1,
number 2, pp.163-182, April 2003
[16]
JEP - Java Math Expression Parser web site: www.singularsys.com/jep/
[17]
M. Brambilla, Nicola D’Elia: Exception Handling within Workflow-based Web
Applications, ICWE, Monaco, July 2004
117
Bibliografia
[18]
M. Brambilla, Extending hypertext conceptual models with process-oriented
primitives, ER 2003 (International Conference on Conceptual Modeling), October
2003, Chicago
[19]
S. Ceri, I. Manolescu, Constructing and integrating data-centric Web Applications:
Methods, Tools, and Techniques, tutorial at VLDB 2003, Berlin
[20]
M. Brambilla, S. Ceri, S. Comai, M. Dario, P. Fraternali, I. Manolescu. “Declarative
Specification of Web Applications exploiting Web Services and Workflows”, ACM
SIGMOD/PODS 2004 Conference, 2004, Paris, France
[21]
M. Brambilla, S. Ceri, S. Comai, P. Fraternali, I. Manolescu, Specification and design
of workflow-driven hypertexts, poster at WWW 2003, Budapest
118