wkf applicazioni
Transcript
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