Indice - Politecnico di Milano

Transcript

I
__________________________________________________________________________________________________________________________________________________________
Indice
1
INTRODUZIONE .............................................................................................................................................4
2
WORKFLOW....................................................................................................................................................7
2.1
WORKFLOW MANAGMENT COALITION (WFMC) ......................................................................................8
2.2
LINGUAGGI ...............................................................................................................................................10
2.2.1
2.2.1.1
Flow object ................................................................................................................................................14
2.2.1.2
Connection objects ....................................................................................................................................15
2.2.1.3
Swimlane ...................................................................................................................................................16
2.2.1.4
Artifact.......................................................................................................................................................17
2.2.1.5
Utilizzo di BPMN......................................................................................................................................19
2.2.1.6
Vantaggi di BPMN ....................................................................................................................................20
2.2.2
BPEL4WS (Business Process Executive Language for Web Services) ..............................................21
2.2.3
WSCI (Web Services Choreography Interface) ..................................................................................27
2.2.4
XLang (Microsoft BizTalk Language) ................................................................................................31
2.2.5
WSFL (Web Services Flow Language) ...............................................................................................31
2.2.6
UML ....................................................................................................................................................32
2.2.7
Linguaggi a confronto.........................................................................................................................33
2.3
3
BPML e BPMN (Business Process Management Language / Notation)............................................10
TOOLS .......................................................................................................................................................34
2.3.1
Collaxa BPEL Designer & Server ......................................................................................................34
2.3.2
Popkin’s System Architect...................................................................................................................35
2.3.3
IBM Business Process Execution Language for Web Services JavaTM Run Time (BPWS4J) ..........38
2.3.4
Intalio|n³ BPMS ..................................................................................................................................39
2.3.5
BEA WebLogic Workshop...................................................................................................................40
2.3.6
Metamill - Visual UML CASE Tool ....................................................................................................41
2.3.7
Visual UML .........................................................................................................................................43
TENDENZE ATTUALI NELLO SVILUPPO DI APPLICAZIONI WEB...............................................44
3.1
APPLICAZIONI PER LA REALIZZAZIONE DI PROCESSI DI BUSINESS .............................................................44
__________________________________________________________________________________________________________________________________________________________
II
__________________________________________________________________________________________________________________________________________________________
3.2
WEB SERVICE ...........................................................................................................................................46
3.3
MODELLAZIONE AD ALTO LIVELLO ..........................................................................................................46
3.3.1
Il modello di struttura .........................................................................................................................49
3.3.2
Modello di composizione ....................................................................................................................50
3.3.3
Modello di navigazione.......................................................................................................................51
3.3.3.1
Link............................................................................................................................................................52
3.3.3.2
Non-contestual link ...................................................................................................................................52
3.3.3.3
Automatic e Transport link........................................................................................................................53
3.3.4
Generazione automatica di applicazioni web.....................................................................................53
3.3.4.1
3.4
MODEL VIEW CONTROL ...........................................................................................................................55
3.4.1.1
4
5
Funzionamento di Struts............................................................................................................................57
VERIFICA FORMALE..................................................................................................................................59
4.1
MODELLO DELL’APPLICAZIONE ...............................................................................................................60
4.2
SPECIFICA DELLE REGOLE DI VERIFICA .....................................................................................................61
4.3
VALIDAZIONE AUTOMATICA ....................................................................................................................63
SCELTE PROGETTUALI.............................................................................................................................64
5.1
USE CASE DIAGRAM .................................................................................................................................64
5.2
REQUISITI DI FLESSIBILITÀ .......................................................................................................................65
5.3
SPECIFICA REQUISITI PER LA NOTAZIONE GRAFICA ..................................................................................65
5.3.1
5.4
6
Unit WebML per la modellazione di workflow ........................................................................................54
Elementi di BPMN adottati.................................................................................................................66
MAPPATURA DI WORKFLOW IN LTL.........................................................................................................68
TOOL ...............................................................................................................................................................69
6.1
L’INTERFACCIA GRAFICA (GUI) ...............................................................................................................69
6.1.1
Toolbar principale ..............................................................................................................................70
6.1.2
La canvas ............................................................................................................................................72
6.1.3
La toolbar della canvas ......................................................................................................................73
6.1.4
Panoramica del diagramma ...............................................................................................................73
6.1.5
Pannello informazioni.........................................................................................................................74
6.2
SALVATAGGIO DIAGRAMMI WORKFLOW ..................................................................................................75
__________________________________________________________________________________________________________________________________________________________
III
__________________________________________________________________________________________________________________________________________________________
6.2.1
6.3
FILE CONFIGURAZIONE .............................................................................................................................79
6.4
TRASFORMAZIONE LINEAR TEMPORAL LOGIC (LTL) ..............................................................................81
6.4.1
6.5
7
Output della trasformazione ...............................................................................................................81
PREDISPOSIZIONE AL MULTILIVELLO ........................................................................................................82
IMPLEMENTAZIONE ..................................................................................................................................83
7.1
7.1.1
CLASS DIAGRAM .......................................................................................................................................84
Implementazione del class diagram....................................................................................................85
7.2
LIBRERIA GRAFICA ...................................................................................................................................86
7.3
STRUTTURA DATI ......................................................................................................................................89
7.4
SALVATAGGIO FILE XML.........................................................................................................................91
7.5
GENERAZIONE TRASFORMAZIONE XSL....................................................................................................92
7.5.1
eXstensible Stylesheet Language (XSL) e XPath ................................................................................93
7.5.2
Alcuni esempi di codice ......................................................................................................................95
7.6
8
Documento XML generato..................................................................................................................77
FUNZIONI PARTICOLARI (POSIZIONAMENTO FRECCE) ...............................................................................96
CONCLUSIONI E SVILUPPI FUTURI ....................................................................................................100
APPENDICE A: BIBLIOGRAFIA .......................................................................................................................102
__________________________________________________________________________________________________________________________________________________________
Introduzione
4
__________________________________________________________________________________________________________________________________________________________
1
Introduzione
Dalla nascita di Internet ad oggi molte cose sono cambiate nella strutturazione delle
applicazioni web. Inizialmente erano disponibili solo semplici pagine html con scopi divulgativi
o informativi. Oggigiorno le necessità e le potenzialità della rete sono notevolmente aumentate
e di pari passo sono cresciute la complessità e le funzionalità offerte dalle applicazioni web:
sino a pochi anni fa era possibile solamente avere informazioni relative all’andamento dei titoli
di borsa, ora gli istituti finanziari forniscono anche servizi come Home Banking e Trading online.
Risulta quindi evidente che le applicazioni attuali necessitano di una progettazione molto
accurata e strutturata, sia dal punto di vista della formalizzazione del processo di sviluppo, sia
dal punto di vista delle notazioni formali e semiformali per la specifica dei requisiti e la
progettazione. In tale ambito esistono diversi linguaggi di modellazione che consentono la
generazione semiautomatica delle applicazioni.
Questi linguaggi forniscono dei costrutti atti a descrivere la realtà d’interesse ad un alto livello
di astrazione, prescindendo dai dettagli dell’architettura, tramite una modellazione che può
essere visuale o solamente formale. Per questo, si punta a distinguere i diversi ambiti di
realizzazione della appicazioni web consentendo di progettare in maniera indipendete tra loro
modello dei dati, modello dell’ipertesto e modello di rappresentazione dell’ipertesto.
Le applicazioni generate mediante questi linguaggi sono sempre più orientate ai processi, per
questo motivo è bene avere un modello di workflow sottostante che sia in grado di descriverle
in maniera semplice e comprensibile. Tramite questo modello è possibile definire delle regole
formali che consentano di verifcare la correttezza delle applicazioni rispetto a certe proprietà.
La verifica formale è un nuovo strumento che serve a validare la progettazione rispetto alla
specifica di partenza. Negli ultimi anni è nata un’intera disciplina che se ne occupa.
Tali concetti vengono trattati diffusamente in questa tesi, dando particolare importanza sia alla
specifica formale delle proprietà da soddifare che al modello delle applicazioni sulle quali viene
realizzata la validazione.
__________________________________________________________________________________________________________________________________________________________
Introduzione
5
__________________________________________________________________________________________________________________________________________________________
Per poter sfruttare le caratteristiche di questo tipo di verifica l’applicazione deve essere
specificata formalmente. Se questo vincolo viene rispettato allora il controllo del
soddisfacimento di proprietà formali può essere effettuato tramite dei verificatori automatici.
L’utilizzo di questo tipo di verifica permette la diminuzione dei tempi e dei costi nella
progettazione dell’applicazione sfruttando al meglio il concetto di anticipazione delle
conoscenze. Difatti, grazie a questa tecnica, è possibile avere un feedback prima ancora che la
realizzazione dell’applicativo venga terminata.
In particolare, questo lavoro di tesi si focalizza sulla verifica delle proprietà orientate ai
processi, concentrando l’attenzione sull’ordine di esecuzione delle attività e sul
soddisfacimento di vincoli sia temporali che logici.
Le proprietà delle applicazioni che vanno verificate, molto spesso sono specificate tramite
formule logiche temporali. Nel caso particolare delle proprietà dei workflow ben si adattano
linguaggi formali come Linear Temporal Logic (LTL). Scrivere e comprendere il tipo di
formule relative a questi linguaggi risulta essere molto complesso per un utente umano, ma ben
si adatta alle caratteristiche di una macchina. Nasce così l’idea di realizzare un tool che
consenta di generare automaticamente regole di logica temporale partendo da una descrizione
formale dell’applicazione web. Dopo un’attenta analisi della struttura delle applicazioni più
diffuse ci si è resi conto di come questa possa essere ben rappresentata tramite un processo di
business ma per la formalizzazione si rende necessario definire una notazione standard.
L’intento è quindi quello di facilitare il compito del progettista per ciò che concerne l’aspetto di
verifica formale delle proprietà associate alle applicazioni web. A tale scopo è stata definita una
notazione grafica, basata su uno standard esistente per la definizione dei workflow: BPML.
La rappresentazione grafica del modello di processo ha come scopo quello di descrivere le
proprietà (pre-condizioni, vincoli, ecc…) che la struttura dell’applicazione deve soddisfare. A
partire da tale rappresentazione vi è poi l’obiettivo di generare automaticamente, tramite
un’apposita trasformazione, formule temporali basate sulla logica di LTL.
Questa tesi è stata sviluppata presso il dipartimento di Elettronica e Informazione del
Politecnico di Milano, nell’ambito del gruppo di Basi di Dati.
Nella sua forma finale, il lavoro si presenta suddiviso in capitoli, del cui contenuto forniamo
una breve descrizione:
•
nel capitolo 2 viene fatta un’analisi degli standard candidati alla modellizzazione dei
processi di business. Inoltre vengono presentati alcuni tool basati su tali notazioni;
__________________________________________________________________________________________________________________________________________________________
Introduzione
6
__________________________________________________________________________________________________________________________________________________________
•
nel capitolo 3 sono presentate le tendenze attuali nello sviluppo di applicazioni web, in
modo particolare si tratterà di modellazione ad alto livello, model view control (MVC);
•
nel capitolo 4 si parla delle potenzialità offerte dalla verification e di come questa stia
assumendo un ruolo sempre più importante nello sviluppo di applicazioni complesse;
•
nel capitolo 5 sono presentate le scelte progettuali fatte per la realizzazione del tool
visuale di modellazione. Saranno analizzati in particolare due aspetti: l’analisi dei
requisiti che dovrà soddisfare la notazione grafica adottata per la rappresentazione dei
diagrammi di workflow e le regole di mapping tra i diagrammi di workflow e le
formule temporali espresse in LTL.
•
nel capitolo 6 si illustra il funzionamento del tool, dall’interfaccia grafica al salvataggio/caricamento dei file. In questo capitolo è descritta anche l’implementazione della
trasformazione LTL;
•
nel capitolo 7 si presentano le scelte implementative effettuate tra cui le librerie grafiche
e la struttura dati, oltre ad alcune funzioni ritenute di particolare rilevanza.
•
il capitolo 8 è dedicato alle conclusioni e ai possibili sviluppi futuri mentre l’ultima
sezione riporta la bibliografia delle fonti che hanno contribuito ad arricchire questa tesi
e la nostra formazione.
__________________________________________________________________________________________________________________________________________________________
WorkFlow
7
__________________________________________________________________________________________________________________________________________________________
2
WorkFlow
La tendenza attuale delle appicazioni web tendono è quella di assumere un carattere sempre
più orientatato verso i processi. Per questo motivo diviene necessario utilizzare i diagrammi
di workflow per modellizzare le proprietà che devono soddisfare. In questo capitolo
andremo ad analizzare in dettaglio alcuni standard esistenti soffermandoci sulla loro
capacità espressiva.
I vantaggi che si possono trarre dall’utilizzo di questo genere di diagrammi possono essere
riassunti nei punti seguenti:
•
il lavoro non arriva in postazioni errate e non si blocca. Gli addetti sono raramente
chiamati a recuperare il lavoro in seguito ad errori;
•
i manager possono concentrarsi su problemi riguardanti l’azienda e il personale, come le
prestazioni individuali e le procedure di ottimizzazione, piuttosto che sull’assegnamento
dei compiti. Agli impiegati non è più richiesto d’inviare il lavoro ad un’altra postazione
e di controllarne il progresso;
•
le procedure sono documentate formalmente ed eseguite esattamente, assicurando che il
lavoro sia eseguito in maniera corretta e rispettando i requisiti a cui è vincolato;
•
ad ogni processo è assegnata la persona (o la macchina) più competente e i processi più
importanti sono assegnati per primi. Gli utenti non perdono tempo a cercare su quale
oggetto lavorare, magari procrastinando lavori importanti ma difficili;
•
il parallelismo, dove due o più compiti sono eseguiti in concorrenza, è più semplice da
realizzare rispetto ad un workflow tradizionale.
Se la persona più competente svolge il compito più importante e 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 stia svolgendo correttamente, gli utenti sono più soddisfatti.
Per questi motivi l’utilizzo di un workflow è un’ottima soluzione sia dal punto di vista
dell’azienda che del cliente.
__________________________________________________________________________________________________________________________________________________________
WorkFlow
8
__________________________________________________________________________________________________________________________________________________________
2.1 Workflow Managment Coalition (WFMC)
La WFMC, fondata nell’Agosto del 1993, è un organizzazione internazionale no-profit
costituita dalle principali aziende sviluppatrici di software basato sui workflow, da utenti,
analisti e gruppi di ricercatori. Il suo scopo è quello di promuovere e sviluppare i workflow al
fine di definire degli standard nella terminologia, nell’interoperabilità e nella connettività tra i
software che ne fanno uso. Costituita da più di 300 membri in tutto il mondo, la WFMC è il
principale riferimento per il mercato del software di questo settore. Adottando la terminologia di
un generico workflow definita dalla WFMC, si definisce [25]:
•
Attività: elemento basilare (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, facendo
l’esempio di una conferenza una delle attività è quella di “bidding”, mentre un istanza di
quell’attività è “l’espressione delle preferenze da parte dei revisori per i documenti
sottoscritti alla conferenza sull’integrazione degli ipertesti estesi con i workflow”. Ogni
istanza può dunque trovarsi in uno dei seguenti stati:
o inactive:
esiste l’istanza, ma nessun task esiste ancora;
o active:
esiste un task al quale è stata assegnata per l’esecuzione;
o suspended:
non accade nulla fino a quando l’attività non sarà resumed;
o completed:
l’attività è terminata consistentemente (correttamente).
Attori di un workflow possono essere sia utenti umani sia risorse computerizzate.
•
Processo di business: insieme di una o più attività collegate tra loro in modo da
realizzare un obiettivo di politica di business, ponendosi, generalmente, in un contesto di
struttura organizzativa con ruoli e relazioni.
•
Processo: rappresentazione di un “processo di business” che supporta una
manipolazione automatica come la gestione da parte di un workflow managment system.
La definizione del processo è data tramite una rete di attività, le relative relazioni,
elementi per indicarne l’inizio e la fine e informazioni riguardo le singole attività, come,
__________________________________________________________________________________________________________________________________________________________
WorkFlow
9
__________________________________________________________________________________________________________________________________________________________
per esempio, gli attori che ne prendono parte, le applicazioni informatiche e i dati
associati, ecc…
•
Workflow: automazione, parziale o totale, di un processo di business durante il quale
documenti, informazioni o compiti sono passati, tramite determinate regole procedurali,
da un attore ad un altro per eseguire operazioni.
•
Workflow Managment System: un sistema che definisce, crea e gestisce l’esecuzione di
workflow attraverso l’uso di software in grado di interpretare la definizione di processo,
di interagire con gli attori e, dove richiesto, di richiedere l’utilizzo di tool e applicazioni
informatiche.
Business Process
(i.e. qualcosa che dovrà
succedere)
è definito in una
è gestito da un
Process Definition
Workflow Managment System
(una rappresentazione di
quello che dovrà succedere)
(controlla gli aspetti automatici del Business
Process)
Sub-Processes
composto da
usato per creare
e gestire
attaverso
Activities
Process Instances
(una rappresentazione di quello che sta
attualmente succedendo)
che possono essere
Activities manuali
Activities automatizzate
durante l’esecuzione
sono rappresentate da
Activity Instances
(non sono gestite come
parte del Workflow System)
che includono
e/o
Work Items
(compiti assegnati ad un
attore del workflow)
Invoked
Applications
(applicazioni/ tool utilizzati
per supportare una activity)
Figura 2-1: relazioni tra gli elementi definiti dalla WFMC
In Figura 2-1 possiamo vedere le relazioni che intercorrono tra i vari elementi definiti dalla
Coalizione:
__________________________________________________________________________________________________________________________________________________________
WorkFlow
10
__________________________________________________________________________________________________________________________________________________________
2.2 Linguaggi
Nel mondo dei workflow, per sfruttarne al meglio le potenzialità, sono nati diversi linguaggi
ognuno dei quali con i suoi pregi e difetti. Alcuni sono ormai “datati” e sono stati rimpiazzati da
altri più “moderni” che hanno aggiunto nuove caratteristiche, non disponibili in precedenza,
senza toglierne alcuna. Tra i principali troviamo BMPL e la sua notazione grafica BPMN [14] e
YAWL [9].
Per quanto riguarda la rappresentazione dei workflow la tendenza attuale è quella di includere
nella notazione elementi per l’utilizzo dei web service. Tra questi citiamo BPEL4WS (che usa
come notazione BPMN) [14].
Nell’analisi daremo una visione generale dei linguaggi, parlando anche del supporto che questi
possono dare ai web service. Accenneremo quindi anche a Coreografia ed Orchestrazione
termini spesso utilizzati nella descrizione dei servizi. Nonostante la definizione di questi termini
non colga un consenso universale, ne forniremo ugualmente una sommaria. La Coreografia, che
in genere descrive i processi di più alto livello, tiene traccia della sequenza di messaggi che può
coinvolgere più applicazioni attraverso una visione globale del processo: tende a dare una
visione più collaborativa delle interazioni. L’Orchestrazione descrive come i servizi
interagiscano tra loro a livello di messaggi scambiati. Fornisce una descrizione della logica di
business e dell’ordine d’esecuzione delle interazioni.
Vediamo una panoramica dei linguaggi candidati, dal punto di vista notazione, alla
realizzazione del tool grafico.
2.2.1 BPML e BPMN (Business Process Management Language / Notation)
BPML è un meta-linguaggio per la modellazione dei processi di business così come XML è un
meta-linguaggio per la modellazione dei dati. BPML fornisce un modello esecutivo astratto per
creare processi di business collaborativi e transazionali basato concettualmente su una macchina
a stati finiti transazionale.
__________________________________________________________________________________________________________________________________________________________
WorkFlow
11
__________________________________________________________________________________________________________________________________________________________
Allo stesso modo di come i documenti XML sono solitamente descritti da un XML Schema, i
processi BPML possono essere descritti in un linguaggio di modellazione chiamato extensible
BPML XML Schema.
Definito come mezzo per la convergenza delle applicazioni aziendali esistenti verso
l’orientamento ai processi, BPML offre il supporto esplicito a transazioni distribuite sia di tipo
sincrono che asincrono.
BPMN serve a definire un Business Process Diagram (BPD), questo diagramma sarà un insieme
di oggetti grafici collegati tra loro da frecce che rappresentano i controlli di flusso, il cui scopo è
quello di definire l’ordine di svolgimento delle azioni. Questi oggetti consentono il facile
sviluppo di semplici diagrammi di flusso che hanno il pregio di risultare familiari ed intuitivi
alla maggior parte degli utenti che ne fanno uso (es. flowchart). Gli elementi che compongono il
BPD sono stati definiti rispettando due criteri principali: il primo è che siano il più possibile
distinguibili l’uno dall’altro; il secondo che la forma risulti il più possibile familiare. Le attività
sono rettangolari mentre le decisioni hanno la forma di rombi.
Ciò che si evidenzia, in BPMN, è la ricerca di semplici meccanismi in grado di creare un
modello dei processi di business che forniscano la necessaria espressività del linguaggio per
gestire la complessità intrinseca dei processi di business. L’approccio che si è seguito per
soddisfare questi due requisiti, in apparente contrasto tra loro, è quello di organizzare gli aspetti
grafici della notazione in specifiche categorie. La generazione di questo ristretto gruppo di
categorie permette, a chi legge un BPD, di riconoscere facilmente a quale tipo di categoria
appartiene ogni elemento del diagramma, portando quindi ad una più intuitiva comprensione del
BPD stesso. All’interno di ogni categoria di base è possibile introdurre delle varianti che
permettono di arricchire l’espressività della notazione, senza comunque discostarsi dall’aspetto
originario.
Presentiamo di seguito i simboli utilizzati per la definizione di un processo di business:
•
Activity, Sub-process, Pool e Lane:
Name
Name
Activity: unitàdi lavoro
Subprocess: attività che può essere a sua volta
scomposta in un sottoprocesso
Lane: partizione di una pool, per scopi vari
Pool: rappresenta un partecipante
Figura 2-2: Activity, Sub-process, Pool e Lane in BPMN
__________________________________________________________________________________________________________________________________________________________
WorkFlow
12
__________________________________________________________________________________________________________________________________________________________
•
Eventi (Figura 2-3) caratterizzati per Flow Dimension e Type Dimension:
Flow Dimension
Type Dimension
Start
(avvio di un processo)
End
(conclusione di processo)
Intermediate (evento nel
corso del processo)
Figura 2-3: Eventi in BPMN
•
Flussi (Figura 2-4), nei quali, dove necessario, è possibile specificare condizioni:
Control/ sequence flow:
Sequenza di esecuzione
Default flow: in presenza di più
scelte, flusso scelto di default
Message flow
Conditional control/sequence flow:
seguito se la condizione specificata
all’inizio del flow è verificata
Association: associazione o
flusso di data-objects
Figura 2-4: Flussi in BPMN
__________________________________________________________________________________________________________________________________________________________
WorkFlow
13
__________________________________________________________________________________________________________________________________________________________
•
Gateway (Figura 2-5): punto di fusione, separazione e/o decisione tra diversi flussi:
Figura 2-5: Gateway in BPMN
Cust
Rappresentiamo ora (Figura 2-6) un esempio d’utilizzo di BPMN relativo ad una richiesta di
prestito:
Loan request
Application
Mgr
Preliminary
validation
Application
Final approval
Application
Financial check
+
Empl
+
JobCheck Req
Application
GetJobCheck
[type Send]
[type Receive]
Application
Application
SVC
Job Check
JobCheckS
JobCheckE
Figura 2-6: esempio d’utilizzo di BPMN
L’esempio rappresenta una transazione in cui un cliente può effettuare una richiesta di prestito
mediante la compilazione di alcuni form. Un manager eseguirà dei controlli preliminari e quindi
passerà la pratica ad un impiegato che svolgerà controlli più approfonditi. Sarà poi lo stesso
manager a prendere una decisione finale in base ai dati rilevati dall’impiegato.
Nei prossimi paragrafi saranno analizzati in dettaglio gli elementi principali di BPMN.
__________________________________________________________________________________________________________________________________________________________
WorkFlow
14
__________________________________________________________________________________________________________________________________________________________
2.2.1.1
Flow object
Un BPD è basato fondamentalmente su tre oggetti base, che costituiscono la categoria dei flow
object, in tal modo l’utente non deve essere in grado di riconoscere un elevato numero di
differenti forme. I tre flow object sono:
Event :
è rappresentato graficamente da un cerchio ed è “qualcosa” che accade
durante lo svolgimento di un processo di business. Ci sono tre differenti
tipi di event che variano in funzione del momento in cui sono utilizzati
all’interno del BPD: Start, Intermediate e End (Figura 2-7).
Figura 2-7: rappresentazione grafica di Start, Intermediate e End
Activity:
è rappresentata graficamente da un rettangolo con gli angoli arrotondati
ed indica una generica mansione svolta all’interno di un processo. Ogni
attività può essere di due tipi o atomica (task) o non atomica (subprocess), in quest’ultimo caso l’activity avrà disegnato al suo interno
nella parte inferiore il simbolo ‘+’ che precisa la presenza di un sotto
processo all’interno della stessa. Tramite questa proprietà è possibile
generare dei diagrammi di tipo multi-livello.
Figura 2-8: rappresentazione grafica di Activity e Activity con Sub-Process
Gateway :
vengono rappresentati graficamente tramite un rombo e utilizzati per
controllare sia la divisione (split) che la riunificazione (merge) del flusso
di informazione all’interno di un BPD. In ogni rombo viene inserito un
simbolo che indica quale è il criterio di valutazione logica dello specifico
gateway. Nella Figura 2-9 sono descritti in successione i gateway And,
Or e Xor.
Figura 2-9: rappresentazione grafica di And, Or e Xor
__________________________________________________________________________________________________________________________________________________________
WorkFlow
15
__________________________________________________________________________________________________________________________________________________________
2.2.1.2
Connection objects
I flow object, definiti nel capitolo precedente, vengono tra loro collegati all’interno di un
diagramma così da creare la struttura base di un processo di business. Vi sono vari tipi di
Connecting object definiti dalla notazione di BPMN:
Sequence flow:
è rappresentato da una linea continua con una freccia posta ad un
estremo della linea per indicare il flusso che seguono i dati.
Tramite i sequenze flow è possibile conoscere quale è l’ordine con
cui vengono svolte le attività all’interno di un BPD;
Association:
è rappresentato graficamente da una linea tratteggiata con una
freccia posta al suo estremo. A differenza del sequence flow non
serve per collegare due attività, ma ha il compito di associare alle
flow object dati, testo o altre entità chiamate Artifact. Vedremo in
seguito, con un esempio, quali sono i possibili impieghi;
Message flow:
è rappresentato come una linea tratteggiata che ha un cerchio
aperto ad un capo e una freccia aperta all’altro, come si vede nella
seguente figura. E’ utilizzato per mostrare il flusso di messaggi tra
due differenti partecipanti al processo di business. In BPMN, i
due partecipanti sono rappresentati tramite due separate pool.
__________________________________________________________________________________________________________________________________________________________
WorkFlow
16
__________________________________________________________________________________________________________________________________________________________
Di seguito (Figura 2-10) riportiamo un semplice esempio di BPD dove sono rappresentati gli
elementi base descritti nei precedenti paragrafi:
Figura 2-10: esempio di processo di business
2.2.1.3
Swimlane
BPMN inserisce nella propria notazione un concetto che era già presente in altri linguaggi di
modellazione (i.e. gli Activity Diagram di UML) cioè le swimlane. Tali costrutti hanno lo scopo
di organizzare graficamente le attività, in diversi gruppi, per illustrarne le diverse competenze
e/o funzionalità richieste.
I due tipi di elementi base che costituiscono la categoria delle swimlane sono:
Pool:
rappresenta un partecipante all’interno di un processo di business. Funge da
contenitore grafico per raggruppare tra loro le activity. Il nome che dà il titolo ad
ogni pool indica l’attore del processo associato. Questo ricopre un aspetto
importate nella definizione di processi di tipo Business to Business (B2B). Le
pool sono utilizzate quando il diagramma implica almeno due soggetti che
ricoprono dei ruoli distinti uno dall’altro, per questo all’interno del BPD
risultano fisicamente separati.
Figura 2-11: rappresentazione grafica di una pool
__________________________________________________________________________________________________________________________________________________________
WorkFlow
17
__________________________________________________________________________________________________________________________________________________________
Lane:
sono una sotto-partizione di una pool, servono ad organizzare e a specializzare le
activity all’interno della pool.
Figura 2-12: rappresentazione grafica di una Lane
Come si può notare dall’esempio, nella Figura 2-13, i sequence flow che collegano le activity
possono attraversare i bordi di una lane per collegare tra loro delle activity che hanno come
riferimento due differenti partecipanti al processo:
Figura 2-13: segmento di processo con lane
2.2.1.4
Artifact
Lo scopo di BPMN è quello di garantire la maggiore flessibilità possibile nello sviluppo di un
generico diagramma. Per ottemperare a questa specifica sono presenti nella notazione degli
artifact. Non c’è limite al numero di artifact che è possibile inserire in un diagramma, questo
per consentire di descrivere nel modo più accurato possibile i processi di business. La notazione
definisce tre oggetti per questa categoria:
__________________________________________________________________________________________________________________________________________________________
WorkFlow
18
__________________________________________________________________________________________________________________________________________________________
Data object:
sono utilizzate per mostrare quali sono i dati richiesti o prodotti da
un’activity. Le data object vengono collegate alle activity tramite un
collegamento di tipo association (vedi Figura 2-17 ).
Figura 2-14: rappresentazione grafica di una data object
Group:
è un rettangolo che ha gli angoli arrotondati, disegnato con una linea
tratteggiata. Può essere utilizzato per generare la documentazione o scopi
d’analisi, ma non ha alcuna influenza sui sequence flow.
Figura 2-15: rappresentazione grafica di un group
Annotation:
è un meccanismo per consentire a chi disegna il BPD di inserire dei
commenti testuali che aiutino ulteriormente il lettore nella comprensione
del diagramma del processo di business.
Figura 2-16: rappresentazione grafica di annotation
__________________________________________________________________________________________________________________________________________________________
WorkFlow
19
__________________________________________________________________________________________________________________________________________________________
Di seguito viene riportato un esempio in cui si dimostra come gli oggetti del gruppo artifact
vengono utilizzati all’interno di un BPD:
Figura 2-17: processo con elementi della categoria artifact
E’ bene sottolineare che l’introduzione degli elementi della categoria artifact in un diagramma
non altera in alcun modo la struttura base di un qualsiasi processo composto da activity,
gateway e sequence flow. Per questo è possibile fare un raffronto tra la Figura 2-13 e la Figura
2-17.
2.2.1.5
Utilizzo di BPMN
BPMN è utilizzato per descrivere un’ampia varietà d’informazioni a differenti tipi d'utenza. E’
possibile descrivere diversi tipi di processo di business, per ognuno dei quali è permessa la
rappresentazione di ogni singola parte a diversi livelli di dettaglio. Uno dei possibili utilizzi di
BPMN permette la realizzazione di un modello base sviluppabile all’interno di un BPD. Tale
modello prende il nome di processo Business to Business (B2B) di tipo collaborativo. Un
processo B2B descrive l’interazione tra due o più entità di business. I diagrammi per questo tipo
__________________________________________________________________________________________________________________________________________________________
WorkFlow
20
__________________________________________________________________________________________________________________________________________________________
di processo generalmente hanno una rappresentazione molto generale. Per questo motivo, un
processo non viene analizzato dal punto di vista di uno dei partecipanti ma è utilizzato per
descrivere l’interazione che c’è tra i partecipanti. Nella Figura 2-18 vediamo un esempio di
processo B2B.
Figura 2-18: esempio di processo B2B di tipo collaborativo
2.2.1.6
Vantaggi di BPMN
BPMN è il risultato di una lunga ricerca sui linguaggi di modellazione da parte del BPMI
notation working group, all’interno del quale confluisce una larga parte della comunità degli
sviluppatori di notazioni per modelli inerenti i processi di business.
La definizione di BPMN punta a ridurre la frammentazione che si è sviluppata con la
proliferazione di una miriade di tool per la modellazione dei processi di business. Lo scopo del
BPMI working group è stato quello di prendere da queste notazioni, tra loro divergenti, le idee
migliori e raggrupparle in un’unica notazione standard.
Le notazioni da cui si è preso spunto per la definizione di BPMN sono: UML Activity Diagram,
IDEF, ebXML, Activity Decision Flow e Rosettanet.
L’utilizzo di un unico standard consentirebbe, inoltre, una più rapida adozione da parte del
pubblico di strumenti per la modellazione dei processi di business, riducendo così il divario che
esiste tra la fase di analisi e la fase di implementazione del processo. Basti considerare che
__________________________________________________________________________________________________________________________________________________________
WorkFlow
21
__________________________________________________________________________________________________________________________________________________________
solitamente i due ambiti sono gestiti da persone che hanno una visione del problema
sostanzialmente diversa l’una dall’altra. In genere, l’analisi viene sviluppata a livello di
management di una azienda, che si concentra su aspetti del processo che non necessariamente
hanno la stessa rilevanza a livello implementativo, dove il progettista dovrà invece tenere conto
di altri fattori.
2.2.2 BPEL4WS (Business Process Executive Language for Web Services)
BPEL4WS, attualmente giunto alla versione 2.0 (Aprile 2004), è una notazione per specificare
il comportamento di processi di business basato su web service [14]. I processi in BPEL4WS
esportano e importano funzionalità usando esclusivamente interfacce di web service. BPEL4WS
nasce come risultato dalla fusione di XLang e WSFL (che vedremo nelle prossime sezioni). Si
pone uno strato sopra WSDL poiché ogni processo BPEL4WS può essere esposto come servizio
in WSDL, di cui, tra l’altro, sfrutta le definizioni di data types per descrivere il passaggio di
informazioni. BPEL4WF può anche referenziare servizi esterni specificati in WSDL.
In questo linguaggio i processi di business possono essere descritti in due modi:
•
i processi di business eseguibili modellano il comportamento reale di un partecipante in
un’interazione di business;
•
i protocolli di business usano descrizioni di processo per specificare lo scambio
reciproco di messaggi eseguito da ogni parte coinvolta nel protocollo, senza però
rivelare il relativo comportamento interno. Le descrizioni dei processi per protocolli di
business sono chiamate processi astratti.
BPEL4WS fornisce un linguaggio per la specifica formale di un processo di business e di
protocolli d’interazione di business. Così facendo, BPEL4WS estende il modello d’interazione
con i web service e consente di supportare transazioni di business. BPEL4WS definisce un
modello d’integrazione interoperabile che dovrebbe facilitare l’espansione verso l’integrazione
dei processi automatizzati sia nell’area intra-corporate che in quella B2B.
Uno degli scopi principali di BPEL è “diminuire il costo dell’automazione dei processi di
business tra imprese”.
__________________________________________________________________________________________________________________________________________________________
WorkFlow
22
__________________________________________________________________________________________________________________________________________________________
Nella Figura 2-19 è illustrato un significativo esempio di utilizzo di BPEL4WS. L’esempio è di
tipo RFQ(Request for Qualifications)/Ordine/Pagamento tra un compratore (Buyer) e un
fornitore (Supplier):
Figura 2-19: esempio d’utilizzo di BPEL4WS
Questo esempio descrive contemporaneamente i tre diversi componenti del processo globale: il
processo privato dell’acquirente, il processo privato del fornitore e la collaborazione tra il
compratore, il fornitore, la banca e l’organizzazione che controlla il credito. Il processo privato
dell’acquirente inizia mandando, come parte della sua activity “GetQuote”, un documento RFQ
al venditore (in questo momento inizia la collaborazione). Quando il fornitore riceve il
documento lo invia alla sua activity “ProcessRFQ”. Quest’ultima invoca l’activity
“PrepareQuote” che è effettivamente eseguita da un utente. Come parte di questa activity,
l’utente invoca la “ManageAccount” la quale ha il compito di creare, se il cliente è nuovo, la
sua registrazione e, in ogni caso, di verificarne il credito attraverso un ente associato. Se tutto è
confermato, viene mandato un preventivo alla “processRFQ” che lo inoltra al cliente. Se il
__________________________________________________________________________________________________________________________________________________________
WorkFlow
23
__________________________________________________________________________________________________________________________________________________________
cliente accetta il preventivo, il suo processo stabilisce che inizierà la sua activity “SendOrder” la
quale crea e invia un ordine relativo al preventivo ricevuto. Quando l’ordine viene ricevuto dal
fornitore, questi lo invia alla sua activity “processRFQ”, che a questo punto finisce, e viene
quindi attivata l’activity “processOrder” che avvisa la “IssueInvoice” di inviare una fattura come
risposta all’ordine, e così via…
Andiamo ad analizzare in seguito, Figura 2-20, la struttura di un documento BPEL4WF:
<process attributi>


<faultHandlers>
<catch faultName=“…“ …>activity</catch>
<catchAll>activity</catchAll>
</faultHandlers>
<eventHandlers>
<onMessage partnerLink=“…" portType=“…” operation=“…">
<correlations>
<correlation set="ncname" initiate="yes|no“/> …
</correlations>
activity
</onMessage>
<onAlarm for="duration" until="deadline"?>
activity
</onAlarm>
</eventHandlers>
activity
</process>
Figura 2-20: struttura di documento BPEL4WS
All’interno di quest’esempio troviamo delle activity. L’elenco delle activity di base utilizzate in
BPEL4WS è il seguente:
•
<receive>:
ricezione di un messaggio di web service;
•
<reply>:
risposta a un messaggio di web service;
•
<invoke>:
chiamata di un servizio;
•
<assign>:
assegnamento di valore a variabile;
•
<throw>:
generazione di un fault (errore);
•
<wait>:
attesa (intervallo o deadline);
•
<empty>:
no-operation (es. utile per la sincronizzazione di thread concorrenti);
•
<terminate>: termina il processo (solo per processi eseguibili).
__________________________________________________________________________________________________________________________________________________________
WorkFlow
24
__________________________________________________________________________________________________________________________________________________________
Oltre alle activity di base ne esistono anche di strutturate che hanno il vantaggio di poter essere
innestate a piacere:
•
<sequence>:
sequenza di attività;
•
<switch>:
selezione esclusiva di un ramo;
•
<while>:
ciclo su espressione booleana;
•
<pick>:
attende
un
evento
(onAlarm|onMessage);
•
<flow>:
specifica attività concorrenti;
•
<scope>:
dichiara un’attività innestata, con la stessa struttura di processo;
•
<compensate>: attività di compensazione.
ed
esegue
le
activity
specificate
In BPEL4WS possono essere inoltre specificati i partner, ovvero i partecipati, e i loro ruoli. Un
esempio d’utilizzo si può vedere in Figura 2-21:
<partner name=“Amazon">
<partnerLink name="Venditore"/>
<partnerLink name="Addetto alla spedizione"/>
</partner>
Figura 2-21: partner in BPEL4WS
I ruoli in gioco vengono definiti tramite l’utilizzo di partner link e il loro tipo prende il nome di
partner link type. In Figura 2-22 è visualizzato il codice della dichiarazione di un partner link:
<partnerLinks>
<partnerLink name=“UPS" partnerLinkType=“trasporto"/>
... elenco di partner links
</partnerLinks>
Figura 2-22: partnerLink in BPEL4WS
__________________________________________________________________________________________________________________________________________________________
WorkFlow
25
__________________________________________________________________________________________________________________________________________________________
In particolare il partner link type serve per specificare le relazioni tra i servizi partecipanti alla
conversazione e ogni servizio non è altro che un port type WSDL. Vediamo (Figura 2-23) un
esempio anche di questo:
<partnerLinkType name="LinkAcquirenteVenditore">
<role name="Acquirente">
<portType name="buy:PortTypeAcquirente"/>
</role>
<role name="Venditore">
<portType name="sell:PortTypeVenditore"/>
</role>
</partnerLinkType>
Figura 2-23: partnerLinkType in BPEL4WS
Per eseguire il binding tra port type e port dei web service, BPEL4WS mette a disposizione le
endpoint references. Per ogni istanza di processo BPEL4WS, ad ogni partner role viene
associato un endpoint. Questa associazione può avvenire in due modi diversi: in modo statico
all’inizio del processo; in modo dinamico, ovvero durante l’esecuzione.
BPEL4WS consente l’utilizzo di identificatori di variabili che risultano essere univoci
all’interno di uno scope. Di ognuno può essere specificato sia il nome che il tipo. Quest’ultimo
può essere:
•
Message type: tipo di messaggio WSDL;
•
Type:
tipo semplice di XML Schema;
•
Element:
riferimento ad un XML Schema.
Le variabili hanno il compito di mantenere le informazioni di stato del processo e sono
modificabili tramite l’activity assign che permette la copia di valori di espressioni compatibili:
<assign>
<copy> from to </copy>
</assign>
Figura 2-24: utilizzo dell’activity “assign” in BPEL4WS
In BPEL4WS all’interno delle activity <invoke>, <receive> e <reply> si può utilizzare
un insieme di proprietà, chiamato <CorrelationSet>, che serve per definire la correlazione
all’interno di uno scope.
__________________________________________________________________________________________________________________________________________________________
WorkFlow
26
__________________________________________________________________________________________________________________________________________________________
Un esempio di utilizzo può essere quello di Figura 2-25:
<correlationSets>
<correlationSet name="OrderID"
properties="cor:customerID cor:orderNumber"/>
</correlationSets>
<receive partnerLink="Buyer" operation="AsyncPurchase” ...>
<correlations>
<correlation set="OrderID" initiate="yes"/>
</correlations>
</receive>
<invoke partnerLink="Buyer" operation="AsyncPurchaseResp” ...>
<correlations>
<correlation set="OrderID" initiate="no" pattern="out">
</correlations>
</invoke>
Figura 2-25: correlationSet in BPEL4WS
Per quanto invece riguarda la gestione degli errori verificatisi in uno scope il tutto è reso
possibile dal Fault Handler il cui scopo è disfare il lavoro parziale/errato dello scope. È
permesso l’utilizzo di complesse regole di matching su nomi e variabili associate al fault.
L’handler che viene utilizzato di default è il catch all, eccone un esempio:
<faultHandlers>
<catch faultName=“…“ faultVariable=“…“>
activity
</catch>
<catchAll> activity </catchAll>
</faultHandlers>
Figura 2-26: utilizzo dell’handler “catch all” in BPEL4WS
Per quanto invece riguarda la gestione degli eventi esiste un Event Handler che si occupa di
gestire:
•
onMessage:
ricezione di messaggi;
•
onAlarm:
evento di timeout. Il conteggio del tempo, per il timeout, parte dall’inizio
del rispettivo scope;
__________________________________________________________________________________________________________________________________________________________
WorkFlow
27
__________________________________________________________________________________________________________________________________________________________
Ecco, anche di questo, un esempio di codice:
<eventHandlers>
<onMessage partnerLink=“…" … operation=“…">
activity
</onMessage>
<onAlarm (for="duration" | until="deadline“)>
activity
</onAlarm>
</eventHandlers>
Figura 2-27: gestione di errori “onMessage” e “onAlarm” in BPEL4WS
2.2.3 WSCI (Web Services Choreography
Interface)
WS
1
WSCI
Nato nell’Agosto del 2000, WSCI serve per
descrivere il comportamento interattivo tra
web service osservabile dall’esterno [27]. Le
caratteristiche peculiari di questo linguaggio
sono il supporto alla correlazione di messaggi,
alle regole di sequenza, alle transazioni e alla
collaborazione dinamica, oltre al fatto che è in
grado di gestire le eccezioni.
WSCI
WS
2
WSCI
WS
3
Figura 2-28: documenti WSCI e web service
Per quanto riguarda i documenti generati da
WSCI bisogna dire che, al contrario di quelli
ottenuti da BPEL4WF, non definiscono dei
processi di business eseguibili. Viene però
permesso di specificare dipendenze temporali e
logiche tra i messaggi scambiati. Ogni documento WSCI descrive solamente la partecipazione di un singolo partner nell’interazione.
Questo non consente di avere una visione globale
dell’interazione.
Figura 2-29: relazione tra WSCI e WSDL
I documenti WSCI sono composti da process,
activity (di tipo complesso) e action (di tipo
elementare) più una serie di altri elementi minori.
Le action referenziano operation dichiarate nel
WSDL.
__________________________________________________________________________________________________________________________________________________________
WorkFlow
28
__________________________________________________________________________________________________________________________________________________________
In WSCI può essere aggiunto un ulteriore livello per la coreografia (per esempio usando
BPML), per la quale vengono utilizzati molteplici documenti WSCI i quali a loro volta
referenziano dei WSDL come illustrato nella Figura 2-29. WSDL serve per descrivere le
operazioni dei web service e WSCI descrive le possibili interazioni che queste possono avere.
Detto questo è facile capire come WSCI si ponga uno strato al di sopra di WSDL e in genere la
sua specifica si trovi direttamente all’interno del documento WSDL.
Vengono di seguito illustrate le activity presenti in WSCI:
•
Activity atomica: <ACTION> è l’operazione atomica di scambio messaggio e
corrisponde ad una operation WSDL. È l’activity base in WSCI e al suo interno si
possono specificare due azioni:
o <CORRELATE>:
serve a specificare che si fa uso di un elemento di
correlazione dichiarato in un comando <Correlation>;
o <CALL>:
serve per eseguire la chiamata di un processo;
Un esempio applicativo è illustrato in Figura 2-30:
<action name = "ReceiveConfirmation“
role = "TravelAgent“
operation = "TAtoTraveler/bookTickets">
<correlate correlation="tns:bookingCorr"/>
<call process = "tns:BookSeats" />
</action>
Figura 2-30: esempio di utilizzo di <Correlate> e <Call>
•
Activity complessa: composta da una serie di <ACTION> secondo una determinata
“coreografia”, specificata utilizzando gli elementi:
o
All:
o
Sequence;
esecuzione non sequenziale;
o Choice;
o For-each;
o Switch:
funziona anche con condizioni basate su eventi;
__________________________________________________________________________________________________________________________________________________________
WorkFlow
29
__________________________________________________________________________________________________________________________________________________________
•
Activity “speciale”: ne esistono di diversi tipi:
o Empty: vuota;
o Fault: genera un errore;
o Join.
In WSCI un process non è altro che una porzione di documento che viene etichettata con un
nome. Può contenere elementi sia di tipo <Activity> che di tipo <Action>. La sua
esecuzione avviene in seguito ad uno di questi tre eventi:
•
<call process=“nome”>:
•
<spawn process=“nome”>: chiamata esplicita asincrona in una action (esecuzione
in un nuovo thread);
•
ricezione di un messaggio di richiesta;
chiamata esplicita sincrona in una action (che resta
in attesa);
All’interno del process si dichiara il tipo d’attivazione tramite la variabile instantiation che può
assumere il valore “message” o “other”.
Altri elementi utilizzati in WSCI sono:
• <INTERFACE>:
raggruppa tutti i processi che coinvolgono un web service rispetto
ad un certo scenario. Se un web service partecipa a più scenari
allora avrà anche più interfacce;
•
<CORRELATION>: serve per dichiarare un elemento di correlazione, vale a dire un ID
che viene utilizzato per correlare diversi messaggi tra loro; l’ID così
dichiarato è, in seguito, usato nell’operatore <Correlate>
all’interno delle <Action>;
•
<PROPERTY>:
•
<TRANSACTION>: specifica le proprietà transazionali di un insieme di <Activity>
e consente di dichiarare attività comparative. Le <Transaction>
possono essere di tipo atomico o di tipo open-nested, ovvero
costituite a loro volta da <Transaction>;
serve per referenziare un “valore” all’interno di un’interfaccia.
Corrisponde alla variabile dei linguaggi di programmazione;
__________________________________________________________________________________________________________________________________________________________
WorkFlow
30
__________________________________________________________________________________________________________________________________________________________
Vediamo in Figura 2-31 la struttura di un documento WSCI:
<wsdl:definitions name = "">


<correlation name = “bookingCorr" property = “B_ID“/>
<interface name = "TravelAgent">
<process name = “…” instantiation = "message">

<sequence>
<action> …
</action>
<activity> …
</activity>
<action> …
</action>
…
</sequence>
</process>
<process name = “…" instantiation = "other">
…
</process>
</interface>
</wsdl:definitions>
Figura 2-31: esempio di documento WSCI
In WSCI l’ambiente, all’interno del quale una serie di elementi <Activity>/<Action>
vengono eseguiti, prende il nome di Context. Questo permette di definire property, correlatori,
eccezioni e proprietà transazionali per tutte le attività presenti in quel context.
Per quanto riguarda la gestione delle eccezioni, WSCI supporta tre tipi: quelle dovute a Fault,
quelle causate da Timeout e quelle che vengono riconosciute in seguito al ricevimento di un
particolare messaggio. Ogni eccezione è associata ad un insieme di <Activity> che viene
eseguito nel caso in cui si verifichi l’eccezione. La sua struttura è del tipo:
<exception>
content:((onMessage | onTimeout | onFault){+})
</exception>
Figura 2-32: un’eccezione in WSCI
__________________________________________________________________________________________________________________________________________________________
WorkFlow
31
__________________________________________________________________________________________________________________________________________________________
2.2.4 XLang (Microsoft BizTalk Language)
È nato nel 2001 per desrivere interazioni tra web service in MS BizTalkServer [29]. È basato su
WSDL e lo estende con alcune primitive che servono per descrivere, all’interno dello stesso
WSDL, il comportamento reciproco dei web service. XLang permette di specificare sequenze,
condizioni ed esecuzioni parallele di web service. È inoltre in grado di gestire eccezioni
nell’esecuzione. In seguito alla nascita di BPEL4WS viene considerato un linguaggio obsoleto.
In Figura 2-33 rappresentiamo una porzione di documento XLang. Possiamo notare dei
comandi già visti in WSDL come operation e port:
<switch>
<branch>
<case> inventory:InStock </case>
<sequence>
<xlang:action operation="AskLastTradePrice"
port="pGetRequest" activation="true"/>
<xlang:action operation="SendLastTradePrice"
port="pSendResponse"/>
</sequence>
</branch>
<branch>
<case> inventory:OutOfStock </case>
...
</branch>
</switch>
Figura 2-33: esempio di documento XLang
2.2.5 WSFL (Web Services Flow Language)
Realizzato da IBM e nato nel 2001, WSFL fornisce due livelli di specifica [28]:
•
Flow Model:
descrive un processo di business in termini di operazioni tra web
service, specificando i possibili usage pattern, ovvero le possibili
combinazione di web service, e gli obiettivi che questi consentono
di ottenere;
•
Global Model:
descrive gli interaction pattern di un insieme di web service:
fornisce una visione globale delle possibili interazioni tra più
partner;
Anche questo linguaggio è divenuto obsoleto con la nascita di BPEL4WS.
__________________________________________________________________________________________________________________________________________________________
WorkFlow
32
__________________________________________________________________________________________________________________________________________________________
2.2.6 UML
Nato nell’ottobre del 1994 e diventato nel novembre del 1997 uno standard OGM, è giunto oggi
alla versione 1.5 (la versione 2.0 è già in fase di lavorazione) [21]. UML è un linguaggio
universale per rappresentare qualunque tipo di sistema. Permette di rappresentare sistemi sia
nuovi che già esistenti e consente la comunicazione tra i diversi ruoli coinvolti nello sviluppo e
nell’evoluzione dei sistemi. UML è in grado di coprire l’intero processo di produzione e
riunisce aspetti dell’ingegneria del software, delle basi di dati e della progettazione di sistemi.
Ha il vantaggio di essere indipendente da qualsiasi linguaggio di programmazione.
Le potenzialità di UML che interessano questa tesi sono quelle relative agli Activity Diagram.
Questi, che derivano da Event Diagram e reti di Petri, forniscono la sequenza di operazioni che
definiscono un’attività più complessa ovvero ci permettono di rappresentare un workflow.
In Figura 2-35 si vede una panoramica degli elementi grafici offerti da UML per la
rappresentazione di Activity Diagram:
Figura 2-35: elementi grafici degli Activity Diagram di UML
Inoltre in UML è possibile utilizzare le swimlane, ovvero
delle corsie che servono a identificare le unità organizzative. Figura 2-34: esempio d’utilizzo di
UML
Nella Figura 2-34 è possibile vedere un esempio di utilizzo.
__________________________________________________________________________________________________________________________________________________________
WorkFlow
33
__________________________________________________________________________________________________________________________________________________________
2.2.7 Linguaggi a confronto
Come poter confrontare i vari linguaggi analizzati e il loro potere espressivo? Un modo è quello
di catalogarli verificando quali pattern di workflow ogni linguaggio è in grado di coprire [8].
Nella Tabella 2-1 diamo una rappresentazione sommaria delle differenze tra i linguaggi
analizzati. Nella colonna a destra troviamo la lista dei pattern considerati come interessanti. Per
ogni combinazione è stato analizzato se è possibile realizzare il pattern con il linguaggio. Se un
linguaggio supporta direttamente il pattern attraverso uno dei suoi costrutti allora è stato
classificato con il simbolo “+”. Nel caso invece non sia direttamente supportato è stato
classificato tramite “+/-“. Nel caso in cui il pattern non sia assolutamente supportato, o per la
sua descrizione sia richiesta una programmazione molto complicata o astrusa, allora la
compatibilità è stata indicata col simbolo “-“. Da notare che un pattern è stato considerato come
supportato direttamente solo se il linguaggio fornisce una caratteristica in grado di supportare il
costrutto senza ricorrere ad alcuna soluzione riguardante la parte implementativa del pattern.
pattern
Sequence
Parallel Split
Synchronization
Exclusive Choice
Simple Merge
Multi Choice
Synchronizing Merge
Multi Merge
Discriminator
Arbitrary Cycles
Implicit Termination
MI without Synchronization
MI with a Priori Design Time
Knowledge
MI with a Priori Runtime
Knowledge
MI without a Priori Runtime
Knowledge
Deferred Choice
Interleaved Parallel Routing
Milestone
Cancel Activity
Cancel Case
standard
XLANG WSFL
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
UML
+
+
+
+
+
-
BPEL
+
+
+
+
+
+
+
+
+
BPML
+
+
+
+
+
+/+
+
WSCI
+
+
+
+
+
+/+
+
+
+
+
+
+
+
+
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
+/+
+
+
+
+
+
+
+
+
+
+
+
+
Tabella 2-1: confornto tra i linguaggi analizzati
__________________________________________________________________________________________________________________________________________________________
WorkFlow
34
__________________________________________________________________________________________________________________________________________________________
2.3 Tools
Prima della realizzazione dell’applicativo, il lavoro è stato orientato all’analisi dei tool esistenti
sul mercato e delle loro funzionalità.
2.3.1 Collaxa BPEL Designer & Server
Si tratta di un editor per la specifica BPEL 1.1 che funziona
anche sotto la piattaforma Eclipse (il test è stato effettuato
con questa “modalità”, la versione del Designer era la
0.0.6) [15]. Il server viene utilizzato per l’esecuzione dei
processi BPEL. Questo tool permette il debugging e il
monitoring di processi BPEL4WS tramite interfaccia web e
ne copre completamente l’orchestrazione.
Nella versione testata è possibile vedere
di un processo, sia una panoramica
(Overview) che il processo nei dettagli
(selezionando ProcessMap). Una volta
selezionato
ProcessMap
vengono
visualizzate le primitive BPEL utilizzate
nel processo tramite delle icone del tipo
mostrato in Figura 2-36:
specifica la primitiva <receive> di BPEL
indica l’utilizzo di una <assign>
specifica la primitiva <invoke> di BPEL
Figura 2-36: esempio di elementi BPEL in Collaxa
__________________________________________________________________________________________________________________________________________________________
WorkFlow
35
__________________________________________________________________________________________________________________________________________________________
In Figura 2-36 sono state rappresentate solo le principali
activity utilizzabili. Altre activity possono essere
selezionate da un menù appositamente definito per
Eclipse riportato in Figura 2-37.
Durante la creazione del processo, mediante notazione
grafica, è sempre possibile passare dalla visualizzazione
grafica a quella del codice BPEL generato.
Il tool, essendo basato su BPEL, è fortemente orientato
all’utilizzo dei web service, cosa che lo differenzia
fortemente da quanto si vuole realizzare in questa tesi.
2.3.2 Popkin’s System Architect
Questo software, giunto alla versione 10.0, si presenta
come un potente e completo tool per la modellazione e
sviluppo di sistemi aziendali [19]. L’obiettivo degli
sviluppatori di System Architect è di integrare, in un
unico prodotto multi-utente, il supporto ai più diffusi
strumenti di modellazione presenti sul mercato (come ad
esempio BPMN e UML), permettendo perciò di modellare Figura 2-37: BPEL Palette in Collaxa
processi di business, progetti object-oriented, database
relazionali, design di architetture di rete e analisi strutturali.
Nell’analisi effettuata, si è provato a realizzare un esempio di workflow per vedere cosa poteva
essere generato in seguito. La versione testata del tool è stata la 9.1.
Durante l’installazione viene richiesto l’utilizzo di un server SQL (è possibile utilizzarne uno
fornito insieme al tool) il cui utilizzo avviene unicamente per salvare i progetti all’interno di file
di database chiamati, nel software di Popkin, enciclopedie e aventi estensione .mdf.
Passando alla notazione BPMN utilizzata da System Architect, si nota che non è possibile, per i
sequenze flow, avere inizio in una pool e fine in un'altra (cosa invece possibile con le lane).
L’interazione tra differenti pool è permessa solo tramite message flow come si può vedere dallo
screenshot di Figura 2-39:
__________________________________________________________________________________________________________________________________________________________
WorkFlow
36
__________________________________________________________________________________________________________________________________________________________
Non è possibile collegare
una activity ad un gateway
tramite un message flow
Figura 2-39: esempio utilizzando le pool
Una volta appurata questo, è stato effetto un altro tentativo utilizzando una sola pool al cui
interno abbiamo messo tre lane e ottenendo così quanto si può vedere dallo screenshot in Figura
2-38:
Figura 2-38: esempio ottenuto usando le lane
__________________________________________________________________________________________________________________________________________________________
WorkFlow
37
__________________________________________________________________________________________________________________________________________________________
Per quanto riguarda invece le data object in System Architect è possibile utilizzarle solo come
negli esempi raffigurati in Figura 2-41: non è consentito fare un’associazione tra la data object e
due activity diverse.
Figura 2-41: problemi con message flow e data object
I message flow sono consentiti solo tra una pool ed un’ altra: non è possibile avere due elementi
della stessa pool (anche se di lane diverse!) collegati da un message flow. In Figura 2-40
mostriamo un diagramma BPMN (fornito come esempio di utilizzo in System Architect) che
utilizza correttamente le pool:
Figura 2-40: esempio di diagramma BPMN in System Architect
__________________________________________________________________________________________________________________________________________________________
WorkFlow
38
__________________________________________________________________________________________________________________________________________________________
In seguito alla creazione del diagramma BPMN abbiamo appurato che il software di Popkin
consente solo di passare ad uno Use Case di UML.
In conclusione questo tool, per quanto riguarda BPMN, consente di disegnare tutto quanto
definito dalla notazione rispettandone i vincoli e di passare, in seguito, allo Use Case Diagram.
Questo software presenta buone idee per la realizzazione dell’interfaccia grafica, ma non è in
grado di compiere trasformazioni sul diagramma BPMN generato, come invece richiesto dalle
specifiche di questo progetto.
L’idea è quella di ottenere una rappresentazione grafica simile a quella del tool di Popkin (in
quanto rispetta la notazione BPMN), con alcuni piccoli accorgimenti tra cui la possibilità di
salvare in un formato standard (cosa che non viene fatta da questo tool).
2.3.3 IBM Business Process Execution Language for Web Services JavaTM Run Time
(BPWS4J)
Giunto oggi (Aprile 2004) alla versione 2.1, supporta la versione 1.1 di BPEL4WS [13]. Questo
software include: una piattaforma in grado di eseguire i processi di business modellati
utilizzando BPEL4WS; un insieme di esempi dimostrativi riguardanti l’utilizzo di BPEL4WS e
un tool che permette la validazione dei documenti BPEL4WS.
La piattaforma di BPWS4J include anche un plug-in di Eclipse che fornisce un semplice editor
grafico per la creazione e la modifica dei file BPEL4WS. Le caratteristiche principali sono:
•
il sorgente XML risulta essere sempre sincronizzato con la visione ad albero del
processo appena creato;
•
flessibilità nell’utilizzo sia di un approccio bottom-up che di un approccio top-down
nella progettazione del processo;
•
menù sensibili al contesto che facilitano notevolmente la creazione di processi
corrispondenti alle specifiche;
•
permette la validazione dei processi, secondo determinate specifiche, durante la sessione
di editing;
__________________________________________________________________________________________________________________________________________________________
WorkFlow
39
__________________________________________________________________________________________________________________________________________________________
2.3.4 Intalio|n³ BPMS
È un software bastato su standard BPMS (Business Process Managment System) che partendo
da progetti di processi di business genera processi eseguibili platform indipendent gestibili
direttamente dagli utenti [16].
Permette la specifica e la gestione di WFMS e consente l’utilizzo di specifiche BPMN-like. Si
presenta come un ambiente di sviluppo di processi integrati e vuole essere in grado di coprire
l’intera vita del processo di business cercando di incrementare la visibilità e la maneggevolezza
del processo per quanto riguarda l’end-to-end.
In Figura 2-42 possiamo vedere uno screenshot del tool (versione 2.5):
Figura 2-42: screenshot di un diagramma generato con Intalio|n³
__________________________________________________________________________________________________________________________________________________________
WorkFlow
40
__________________________________________________________________________________________________________________________________________________________
2.3.5 BEA WebLogic Workshop
Sviluppato da BEA, è giunto alla versione 8.1.È un ambiente di sviluppo Java che permette di
costruire in maniera visuale applicazioni web, web service, pagine JSP, Portali, EJB, e
workflow [12]. Per quanto riguarda questi ultimi, bisogna sottolineare che BEA è ottimizzato
per il design di workflow orientati ai web service e quindi, ancora una volta, un tool che si
discosta da quanto noi vogliamo realizzare.
In Figura 2-43 è mostrato uno screenshot di come si presenta il tool:
Figura 2-43: screenshot di BEA WebLogic Workshop
__________________________________________________________________________________________________________________________________________________________
WorkFlow
41
__________________________________________________________________________________________________________________________________________________________
2.3.6 Metamill - Visual UML CASE Tool
Questo tool, sviluppato da una piccola softwarehouse lussemburghese è giunto oggi alla
versione 4.0, consente di disegnare dei workflow utilizzando diverse notazioni tra cui gli
activity diagram e i sequence diagram di UML [18]. In Figura 2-44 si può vedere un
diagramma di workflow realizzato con la versione demo del tool:
Figura 2-44: screenshot di workflow disegnato con Metamill
L’esempio risulta scarno perché la versione Demo consente solo l’utilizzo di un numero limitato
di elementi. Il tool rispetta la notazione UML e il file di salvataggio è in XMI (XML Metadata
Interchange), un formato che permette l'interscambio di metadati fra sistemi differenti sotto
forma o di flussi di dati o di file conformi all'architettura XML. Tramite l’analisi del file salvato
si sono ricavate delle idee utili alla realizzazione del tool grafico. Il codice XMI è suddiviso in
due parti principali. La prima denominata XMI.content contiene una specie di DTD di UML
mostrato, in parte, in Figura 2-45:
__________________________________________________________________________________________________________________________________________________________
WorkFlow
42
__________________________________________________________________________________________________________________________________________________________
<XMI.content>
<UML:Model name="Java Base Model" xmi.id="mm:20158658-c3c4-11d7-835d">
<UML:ModelElement.taggedValue>
<UML:TaggedValue tag="mpacksdir" value="${BASEMPACKSDIR}"/>
<UML:TaggedValue tag="sourcedir" value="${BASESOURCEDIR}"/>
<UML:TaggedValue tag="scriptdir"/>
<UML:TaggedValue tag="imprules"/>
…
<UML:StateMachine>
<UML:StateMachine.top>
<UML:PseudoState xmi.id="mm:2" name="start"
visibility="publ"/>
…
</UML:StateMachine>
…
</XMI.content>
Figura 2-45: XMI.content
La seconda parte invece è denominata XMI.extensions, descrive il diagramma e al suo interno è
possibile definire pre e post condizioni e le impostazioni per il passaggio di parametri:
<XMI.extensions xmi.extender="Metamill">
<UML:Diagrams>
<UML:Diagram name="Loan example" xmi.id="mm:09a82f42" kind="Act Diag">
<UML:Diagram.taggedValue>
<UML:TaggedValue tag="exportFile" value="?"/>
<UML:TaggedValue tag="flags"/>
</UML:Diagram.taggedValue>
<UML:Diagram.elements>
<UML:DiagElem vcode="Swiml" xmi.id="mm:3066"
geom="x=24;y=54;h=11"/>
<UML:DiagElem vcode="Swiml" xmi.id="mm:32c8"
geom="x=51;y=54;h=10"/>
<UML:DiagElem vcode="Text" xmi.id="mm:3a88" geom="x=129;y=25">
…
Figura 2-46: XMI.extensions
Dall’analisi si nota che codice generato è poco chiaro: risulta a volte difficile comprendere
alcuni attributi utilizzati e quale sia il criterio per la loro generazione.
__________________________________________________________________________________________________________________________________________________________
WorkFlow
43
__________________________________________________________________________________________________________________________________________________________
2.3.7 Visual UML
È un tool di modellazione che supporta la realizzazione di diagrammi compatibili con le
versioni 1.3, 1.4 e 2.0 dello standard UML: permette di disegnare Use Case diagram, Class
diagram, Object diagram, Activity diagram, Collaboration diagram, Sequence diagram, State
Machine diagram e altri. Il test è stato effettuato realizzando un esempio di workflow di cui è
riportato il risultato in Figura 2-47. Il software risulta abbastanza completo e semplice da usare,
ma con specifiche diverse da quanto si vuole realizzare.
Figura 2-47: screenshot dell’esempio realizzato con Visual UML
__________________________________________________________________________________________________________________________________________________________
Tendenze attuali nello sviluppo di applicazioni web
44
__________________________________________________________________________________________________________________________________________________________
3
Tendenze attuali nello sviluppo di
applicazioni web
L’evoluzione del web sta comportando un passaggio dai siti web “tradizionali” ad applicazioni
più complesse. Tale tendenza si concretizza in diverse direzioni:
•
applicazioni complesse per la realizzazione di processi di business;
•
integrazione di applicazioni web attraverso l’uso di web service;
•
modellazione ad alto livello: permette di gestisce applicazioni complesse consentendo
di concentrare l’attenzione sull’analisi e la progettazione piuttosto che sulla stesura del
codice (risparmio di tempo e denaro) attraverso una modellazione visuale;
•
model view control: permette di disaccoppiare il più possibile tra loro le parti
dell’applicazione adibite al controllo, all’accesso ai dati e alla presentazione;
•
verfication: consente una migliore qualità complessiva delle applicazioni grazie
all’utilizzo di una verifica automatica applicata già in fase di sviluppo.
3.1 Applicazioni per la realizzazione di processi di business
Lo scopo è quello di consentire all’utente di generare workflow che descrivano un generico
processo di business. Dai workflow deve essere possibile estrarre dei pattern noti in precedenza,
dai quali passare, tramite una determinata trasformazione, alla generazione di una prima bozza
dell’ipertesto finale. Si evidenzia quindi la necessità di mettere in relazione lo sviluppo di un
workflow con la generazione di un ipertesto. In genere, un ipertesto è un insieme di pagine
collegate tra loro tramite dei link, per questo la navigazione all’interno delle pagine risulta
essere del tutto arbitraria, ovvero priva di qualsiasi tipo di vincolo sulla possibile sequenza di
azioni da compiere. Al contrario, nei workflow si definiscono anticipatamente quali sono le
azioni che un utente può compiere, andando a gestire tutti i controlli sul flusso delle attività in
modo da rispettare i vincoli e fornendo all’utente le risorse necessarie per portare a termine il
__________________________________________________________________________________________________________________________________________________________
45
__________________________________________________________________________________________________________________________________________________________
lavoro che costituisce le attività. La sequenza delle possibili azioni da svolgere è predeterminata
e l’utente è guidato, nel rispetto delle specifiche, lungo il percorso delle attività. I vincoli di un
workflow possono essere di diverso tipo:
•
logico:
una attività può essere svolta solo nel momento in cui una certa altra
attività è stata completata;
•
temporale:
una attività può essere avviata solo dopo un certo punto nel tempo;
L’integrazione degli ipertesti con i workflow implica la modellizzazione delle attività e
l’applicazione di vincoli per guidare la navigazione dell’utente attraverso le attività.
Chiameremo l’ipertesto esteso con i vincoli introdotti dai workflow “workflow-driven
hypertext” (in breve WFdHT).
Figura 3-1: workFlow e ipertesti
La Figura 3-1 rappresenta le caratteristiche dei Workflow Management Systems, degli ipertesti e
dei WFdHT. 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. Gli ipertesti “puri” (HT) sono opposti ai WFMS, dato che non pongono alcun
vincolo per l’utente che può navigare liberamente in modo non-lineare 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.
__________________________________________________________________________________________________________________________________________________________
46
__________________________________________________________________________________________________________________________________________________________
3.2 Web service
Il crescente interesse verso applicazioni che usano i web service è principalmente dovuto al
passaggio dall’interazione uomo-web all’interazione macchina-macchina. In questo tipo
d’interazione è richiesto che i software realizzati con diversi linguaggi di programmazione e in
diversi sistemi operativi possano comunicare tra loro in maniera interoperabile. I web service
nascono per consentire questo scambio di informazioni. La loro potenza risiede non solo
nell’interoperabilità ed estensibilità ma anche nel fatto che possono essere combinati, per
ottenere servizi complessi, semplicemente facendo interagire un insieme di programmi che
forniscono, ognuno, un servizio semplice.
Tuttavia l’analisi di questo tipo d’applicazioni web non vuole essere oggetto di questa tesi.
3.3 Modellazione ad alto livello
La modellazione ad alto livello nasce dall’esigenza di gestire applicazioni complesse
consentendo di concentrare l’attenzione sull’analisi e la progettazione piuttosto che sulla stesura
del codice. A quest’esigenza vanno ad aggiungersi la necessità di una parziale o totale
generazione automatica del codice e il supporto alla prototipazione.
Queste richieste vengono soddisfatte tramite modellazione visuale. In particolare verrà descritta
quella proposta da WebML [23]. WebML è un linguaggio concettuale per la specifica e la
progettazione di applicazioni data-intensive[1] e viene definito come l’UML del web.
In particolare WebML propone una notazione per la specifica, la progettazione e la
pubblicazione automatica di un sito web a partire da specifiche di 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 un’applicazione web e di
descrivere l’organizzazione e la presentazione di ogni contenuto in un ipertesto.
Il modello UML 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.
__________________________________________________________________________________________________________________________________________________________
47
__________________________________________________________________________________________________________________________________________________________
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 le informazioni presenti nelle pagine, dalla navigazione e dalla presentazione,
che possono essere definite e sviluppate separatamente (logica a tre livelli);
•
immagazzinamento 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 realizzare 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.
In WebML la realizzazione di un sito web può essere schematizzata individuando dei modelli
ortogonali, ognuno dei quali permette al progettista di concentrare la sua attenzione su una
particolare dimensione, senza che questo interferisca in alcun modo con le altre [11].
Figura 3-2: panoramica sui modelli usati da WebML
__________________________________________________________________________________________________________________________________________________________
48
__________________________________________________________________________________________________________________________________________________________
I modelli utilizzati da WebML sono:
•
Modello di struttura:
descrive l’organizzazione concettuale dei dati trattati, in
maniera compatibile con il diffuso modello EntitàRelazione e con i 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. Ognuna di queste
rappresenta la visione di una diversa dimensione dei dati dell’applicazione, con lo
scopo di soddisfare un insieme ben definito di requisiti che coprono i differenti
interessi dei gruppi d’utenza. Partendo dal modello WebML generato è poi possibile
ottenere automaticamente il codice di navigazione dei dati in un linguaggio di
scripting come ASP o JSP.
•
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);
__________________________________________________________________________________________________________________________________________________________
49
__________________________________________________________________________________________________________________________________________________________
Nelle sezioni seguenti andremo ad analizzare più in dettaglio il funzionamento e il ruolo di
alcuni modelli qui sopra elencati. In particolare analizzeremo il modello dei dati dato dal
modello di struttura, e quello dell’ipertesto dato dai modelli di composizione e navigazione.
3.3.1 Il modello di struttura
In questo modello viene definita la struttura del sito web ovvero viene fatto il data design.
Questa attività è di fondamentale importanza nella progettazione di applicazioni data-intensive:
permette al progettista di formalizzare e, quindi, comprendere al meglio l’organizzazione dei
dati dell’applicazione che sta andando a sviluppare. L’obiettivo che questo modello si pone è
quello di dare una rappresentazione degli oggetti essenziali del dominio dell’applicazione, delle
loro proprietà e delle relazioni che intercorrono tra essi [4]. Il risultato di questa fase di
progetto è una rappresentazione chiara ed intuitiva dei dati a disposizione dell’applicazione che
verrà sviluppata.
Questo modello è compatibile con il modello Entità/Relazione e con i class diagram di UML.
Gli elementi utilizzati sono le entità, definiti come contenitori di dati, e le relazioni, definite
come connessioni semantiche tra le entità.
In Figura 3-3 è rappresentato un esempio di struttura dati di un sito in cui sono visualizzate: le
entità che rappresentano gli utenti ed i possibili gruppi: Product, Combination, BigImage e
TechRecord.
Figura 3-3: rappresentazione della struttura dati di un sito in WebML
__________________________________________________________________________________________________________________________________________________________
50
__________________________________________________________________________________________________________________________________________________________
Ogni prodotto può avere: “0” o “N” Combination; “0” o “N” BigImage; “0” o “1” Technical
Record, invece le entità TechRecord e BigImage sono legate univocamente ad uno specifico
prodotto.
3.3.2 Modello di composizione
Lo scopo di questo modello è di definire i nodi che compongono l’ipertesto pubblicato in un
sito web [7]. In particolare serve per specificare:
•
quali pagine compongono l’ipertesto;
•
gli elementi atomici di informazione attualmente fornite all’utente, le unit;
•
le site view, cioè il 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 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; consente di
visualizzare i dati relativi a più istanze di un’entità;
•
IndexUnit:
permette di definire e visualizzare indici d’accesso ai dati; mostra
una lista di proprietà descrittive di alcuni oggetti, senza presentare
le informazioni di dettaglio di ogni oggetto;
__________________________________________________________________________________________________________________________________________________________
51
__________________________________________________________________________________________________________________________________________________________
•
ScrollerUnit:
visualizza i dati relativi a più istanze tramite una navigazione del
tipo “avanti/indietro - primo/ultimo”;
•
EntryUnit:
modella un’EntryForm, 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 DataUnit 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à d’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 DataUnit, mostranti il contenuto di un oggetto,
si alternano alle altre permettendo varie forme di interconnessione tra oggetti correlati.
L’associazione tra entità e DataUnit è di tipo uno a molti; la stessa entità può essere associata a
diverse DataUnit, ciascuna mostrante un diverso insieme di attributi dell’entità. Perciò, le
DataUnit rappresentano diverse “viste virtuali” su concetti definiti nel modello di struttura,
adattabili a diversi requisiti.
Le EntryUnit servono per visualizzare o modificare informazioni ma soprattutto per inserire
nuovi dati attraverso maschere d’inserimento.
IndexUnit, MultidataUnit e ScrollerUnit sono tipicamente usate per specificare strutture
d’accesso al contenuto del sito e per raggruppare in una pagina diversi frammenti correlati
d’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 site view.
3.3.3 Modello di navigazione
Le unità e le pagine non possono esistere da sole senza essere connesse a formare una
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.
__________________________________________________________________________________________________________________________________________________________
52
__________________________________________________________________________________________________________________________________________________________
La principale nozione del modello di navigazione è quella di link (contestuale, non contestuale,
di trasporto).
3.3.3.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 una 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 contestual link, mentre quelli a cui non è associata nessuna
informazione prenderanno il nome di non-contestual link.
Le informazioni di contesto sono tipicamente necessarie per assicurare la computabilità del
contenuto di un’unità. Ad esempio, una DataUnit che mostra i dettagli di un artista può essere
collegata ad una IndexUnit che mostri un indice di album pubblicati. Per calcolare la lista di
album pubblicati dall’artista mostrato dalla DataUnit, l’identificativo di tale artista deve essere
trasferito alla IndexUnit.
3.3.3.2
Non-contestual link
La Figura 3-4 mostra un non-contestual link che connette due pagine. Il link connette una
pagina sorgente (PopArtistPage) contenente una MultidataUnit che mostra gli artisti pop, con
una pagina (JazzArtistPage) destinazione contenente una MultidataUnit 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 3-4: esempio di utilizzo di non-contestual link
__________________________________________________________________________________________________________________________________________________________
53
__________________________________________________________________________________________________________________________________________________________
3.3.3.3
Automatic e Transport link
Gli automatic link 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 finora, infatti,
richiedono, per poter essere utilizzati, che l’utente prema un bottone. Ci sono casi in cui un link
è usato semplicemente per trasportare informazione e non è associato a nessun bottone di
navigazione. Questo tipo di link è chiamato transport link, per sottolineare il fatto che il link
serve solo per il passaggio dei parametri e non per la navigazione dell’utente. In Figura 3-5
mostiamo un esempio di transport link: la pagina CelineDionAlbums contiene una DataUnit
ArtistDetails, la quale contiene i dettagli dell’artista, e la IndexUnit PublishedAlbums che
contiene la lista degli album che ha pubblicato.
CelineDionPage
CelineDionAlbums
ArtistDetails
Artist
[FirstName="Celine"]
[LastName="Dion"]
ARTIST
PublishedAlbums
Album
[ ArtistToAlbum ]
FirstName: Celine
LastName: Dion
Photo:
ALBUMS
°
°
°
°
All the way
New day has come
Hits of ...
Colour of ...
Figura 3-5: esempio di transport link e relativa visualizzazione in una pagina HTML
3.3.4 Generazione automatica di applicazioni web
Partendo da un workflow, è possibile generare un ipertesto che rispetti i vincoli sia temporali
che logici introdotti dai workflow stessi. Quello di cui si ha bisogno per compiere questo
passaggio è la definizione di un trasformazione che in funzione delle informazioni in ingresso,
provenienti dal workflow, sia in grado di generare in uscita una prima bozza della struttura
dell’ipertesto. Questa parte esula dagli intenti di questa tesi, nonostante ciò, si è sempre tenuto
in considerazione questo possibile sviluppo futuro, specialmente nel momento in cui è stato
necessario definire i pattern che la notazione avrebbe dovuto supportare. Vengono presentate
nel prossimo paragrafo le unit che WebML mette a disposizione per la modellazione di
workflow.
__________________________________________________________________________________________________________________________________________________________
54
__________________________________________________________________________________________________________________________________________________________
3.3.4.1
Unit WebML per la modellazione di workflow
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. Diamo ora un elenco delle unit disponibili in
WebML:
• Start activity ed End activity: le pagine/unit associate all’esecuzione di un’activity
devono essere racchiuse tra queste due operazioni:
Figura 3-6: Start activity ed End activity
Delimitano una porzione dell’ipertesto dedicata
all’esecuzione di un’activity e hanno “l’effetto collaterale”
di aggiornare i dati del workflow.
•
Switch unit ed If unit:
la navigazione di un workflow può essere condizionata
dallo stato delle activity. Queste unit servono per
esprimere una navigazione condizionale:
Figura 3-7: Switch unit ed If unit
Entrambe ricevono in input un insieme di parametri e li
usano per valutare un’espressione. Se la valutazione
fallisce viene seguito il KO-link, altrimenti viene seguito
uno dei link di output (a seconda del risultato della
valutazione). L’if unit vaulta un booleano, mentre la
switch unit valuta un’espressione costante.
•
Workflow-aware indexunit: viene utilizzata per accedere ai dati di una particolare
activity instance. Questa unit è simile alla normale content
unit di WebML, ma permette di gestire l’espressione di
predicati che coinvolgono sia i dati dell’applicazione che
del workflow. La sua notazione grafica è quella di Figura
3-8.
__________________________________________________________________________________________________________________________________________________________
55
__________________________________________________________________________________________________________________________________________________________
Figura 3-8: Workflow-aware index unit
•
Assign unit:
viene utilizzata per collegare un’application object ad
un’activity instance. Può anche essere utilizzata per
specificare lo user incaricato di eseguire l’applicazione.
Figura 3-9: Assign unit
•
Activity status unit:
si utilizza per controllare lo stato di un’activity instance.
Figura 3-10: Activity status unit
3.4 Model View Control
Uno dei principali requisiti di qualsiasi applicazione web è quello di definire un modello
applicativo che consenta di disaccoppiare i diversi componenti dell'applicazione in base al loro
ruolo nell'architettura per ottenere vantaggi in termini di riusabilità e manutenibilità. Il pattern
MVC è un’implementazione di quello che va sotto il nome di "Model 2"; il Model 2 introduce il
concetto di controllo centralizzato dell'applicazione, implementato da una servlet di controllo
che gestisce tutte le richieste e le soddisfa delegando l'elaborazione a opportune classi Java.
In questo modello i ruoli di presentation, control e business logic vengono affidati a
componenti diversi e sono tra di loro disaccoppiati, con evidenti vantaggi in termini di
riusabilità, manutenibilità, estensibilità e modularità. In un'applicazione costruita secondo il
pattern MVC si possono quindi individuare tre livelli logici ben distinti che molto
schematicamente svolgono i seguenti compiti:
•
controller:
determina il modo in cui l'applicazione risponde agli input dell'utente.
Esamina le richieste dei client, estrae i parametri della richiesta e li
convalida, si interfaccia con lo strato di business logic dell'applicazione.
__________________________________________________________________________________________________________________________________________________________
56
__________________________________________________________________________________________________________________________________________________________
Sceglie la successiva
dell'elaborazione;
vista
da
fornire
all'utente
al
termine
•
model:
contiene i dati visualizzati dalle viste; è ciò che viene elaborato e
successivamente presentato all'utente;
•
view:
visualizza all'utente i dati contenuti nel model. È la rappresentazione
dello stato corrente del model;
In particolare si andrà ad analizzare l’implementazione di Struts del design pattern MVC [20].
Struts è un framework opensource per la generazione di applicazioni web in Java sviluppato
dalla Apache Software Foundation. Il nucleo del framework di Struts è basato su tecnologie
standard come Servlets Java, JavaBeans, ResourceBoundles, e XML oltre che su vari package
di Jakarta Commons (che è un sottoprogetto di Jakarta centrato su ogni aspetto dei componenti
di Java riusabili).
I componenti fonadamentali che Struts presenta sono:
•
actionServlet:
è la servlet di controllo centralizzata che gestisce tutte le richieste
dell'applicazione;
•
struts- config.xml:
è il file XML di configurazione di tutta l'applicazione. In questo
file vengono definiti gli elementi dell'applicazione e le loro
associazioni;
•
action:
le action sono le classi alle quali la actionServlet delega
l'elaborazione della richiesta;
•
actionMapping:
contiene gli oggetti associati ad una action nello struts-config.xml
come ad esempio gli actionForward;
•
actionForm:
sono classi contenitori di dati. Vengono popolati automaticamente
dal framework con i dati contenuti nelle request http;
•
actionForward:
contengono i path ai quali la servlet di Struts inoltra il flusso
elaborativo in base alla logica dell'applicazione;
•
custom-tags:
Struts fornisce una serie di librerie di tag per assolvere a molti dei
più comuni compiti delle pagine JSP.
__________________________________________________________________________________________________________________________________________________________
57
__________________________________________________________________________________________________________________________________________________________
Struts fornisce un suo componente Controller e si integra con altre tecnologie per fornire il
Model e la View. Per ciò che concerne il Model, Struts può interagire con le tecnologie standard
esistenti per l’accesso ai dati, come JDBC e EBJ. Per quanto riguarda invece la View, Struts si
integra sia con le Java Server Pages (JSP), includendo anche JSTL e JSF, sia con Velocity
Templates e XSLT.
Il framework di Struts provvede a fornire, in backgroud, le strutture invisibili di cui una
applicazione web ha bisogno per progredire. Struts aiuta a creare un ambiente di sviluppo
estendibile per le applicazioni, basato su standard esistenti e su pattern di progettazione
prestabiliti.
3.4.1.1
Funzionamento di Struts
Un’applicazione web usa un descrittore di struttura per inizializzare le risorse come le JAVA
Servlets e le Tag Libraries. Il descrittore di struttura, in questo caso, non è altro che un
documento XML chiamato “web.xml”.
In Struts tutto è controllato dalla servlet di controllo denominata actionServlet. Questa gestisce
tutte le richieste client e smista il flusso applicativo in base alla logica configurata. Si potrebbe
definire come la 'spina dorsale' di una applicazione costruita su Struts. Tutta la configurazione
dell'applicazione è contenuta nello struts-config.xml. Questo file XML viene letto in fase di
start-up dell'applicazione dalla actionServlet e definisce le associazioni tra i vari elementi di
Struts. Nello struts-config.xml sono ad esempio definite le associazioni tra i path delle richieste
http e le classi action associate alla richieste stesse. Le associazioni tra le action e gli
actionForm, che vengono automaticamente popolati dal framework con i dati della richiesta ad
essi associata e passati in input alla action. Contiene inoltre l'associazione tra la action e le
actionForward , ovvero i path configurati nello struts-config.xml ai quali l’actionServlet
redirigerà il flusso applicativo al termine dell’elaborazione della action.
Nella pagina successiva (Figura 3-11) riportiamo un esempio di file di configurazione di Struts
per un workflow di Login. Oltre a quelle riportate in questo file ci sono molte altre risorse che
possono essere specificate in un file di configurazione di Struts. Ad esempio, si può specificare
la validazione per gli actionForm usando lo Struts Validator.
Struts è un framework estendibile: ogni classe presente in Struts può essere rimpiazzata da una
classe di default definita e personalizzata dall’utente. Le proprietà di questa classe possono
essere impostate usando la funzione set-property di Digester (un package per la configurazione
__________________________________________________________________________________________________________________________________________________________
58
__________________________________________________________________________________________________________________________________________________________
di file XML tramite regole che vengono attivate al riconoscimento di particolari pattern
all’interno del file). Questa è una delle ragioni per cui esistono tante estensioni per Struts.
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE struts-config PUBLIC
"-//Apache Software Foundation//DTD Struts Configuration 1.2//EN"
"http://struts.apache.org/dtds/struts-config_1_2.dtd">
<struts-config>
<form-beans>
<form-bean
name="logonForm"
type="app.LogonForm"/>
</form-beans>
<action-mappings>
<action
path="/Welcome"
forward="/pages/Welcome.jsp"/>
<action
path="/Logon"
forward="/pages/Logon.jsp"/>
<action
path="/LogonSubmit"
type="app.LogonAction"
name="logonForm"
scope="request"
validate="true"
input="/pages/Logon.jsp">
<forward
name="success"
path="/pages/Welcome.jsp"/>
<forward
name="failure"
path="/pages/Logon.jsp"/>
</action>
<action
path="/Logoff"
type="app.LogoffAction">
<forward
name="success"
path="/pages/Logoff.jsp"/>
</action>
</action-mappings>
<message-resources parameter="resources.application"/>
</struts-config>
Figura 3-11: esempio di file di configurazione di Struts per un workflow di Login
Struts presenta solo una base di framework, che può essere personalizzato per soddisfare le
esigenze del programmatore. Ovviamente questo aumenta la complessità nell’utilizzo, è quindi
poco indicato per chi vuol scrivere applicazioni semplici.
__________________________________________________________________________________________________________________________________________________________
59
__________________________________________________________________________________________________________________________________________________________
4
Verifica Formale
Nel contesto dei sistemi hardware e software, la verifica formale rappresenta l’atto di validare
la correttezza di un sistema rispetto a certe specifiche formali o proprietà.
La possibilità di realizzare nella fase di progettazione la verifica della correttezza del software
permette di anticipare la conoscenza riducendo così al minimo l’eventualità di compiere errori
di sviluppo.
I tipi di sistemi considerati nella letteratura per la verifica formale comprendono macchine a
stati finiti (FSM), Reti di Petri, protocolli di crittografia e astrazioni di parti generali di
software.
Esistono diverse strade per compiere la verifica formale nell’ambito dei sistemi software. Nel
caso si utilizzi un modello visuale per la realizzazione di ipertesti, come ad esempio WebML, è
possibile fare una prima verifica del progetto su specifici aspetti dello sviluppo come il
passaggio di parametri tra attività diverse.
L’obiettivo è spingersi oltre questa semplice validazione, cercando di definire un modello che
sia in grado di descrivere l’insieme di attività che l’applicazione deve implementare. Da questa
rappresentazione ad alto livello deve essere possibile estrarre delle formule logiche con le quali
valicare la correttezza dell’applicazione.
E’ bene sottolineare che la specifica formale di questi requisiti si riferisce alla fase di
esecuzione dell’applicazione, della quale si vuole garantire l’aderenza alle specifiche di
processo. Per questo motivo tali specifiche sono costituite generalmente da un insieme di
sequenze di input, azioni, e stati che risultano dall’interazione con l’utente. Ad esempio in
un’applicazione di e-commerce è bene che nessun prodotto venga spedito fino a quando non si
è ricevuto il pagamento, oppure si vorrebbe verificare che le transizioni tra le pagine non siano
ambigue (la prossima pagina da raggiungere è definita univocamente in qualsiasi istante del
processo), o che tutte le pagine siano raggiungibili dalla home page.
Questa modalità di verifica permette di realizzare delle applicazioni più robuste con una
struttura ben definita che garantisce una correttezza rispetto alla proprietà che l’applicazione
deve soddisfare.
__________________________________________________________________________________________________________________________________________________________
60
__________________________________________________________________________________________________________________________________________________________
Nella maggior parte dei casi le proprietà da verificare vengono espresse tramite una logica
temporale. Esistono diverse notazione formali atte allo scopo, come linear-time temporal logic
(LTL) o computatiol tree logic (CTL).
Dato che il progetto è stato sviluppato in un più ampio ambito di ricerca, ci si è orientati verso
l’utilizzo della notazione presentata in LTL. Tale notazione rispetto alle altre possibili
soluzioni, garantisce sia un maggiore potere espresso che una migliore adattabilità rispetto al
progetto a cui è stata applicata.
L’utilizzo di LTL per la verifica formale delle applicazioni risulta molto complesso nel caso in
cui si cerchi di realizzarlo senza l’ausilio di tool in grado di estrarre automaticamente le regole,
partendo da una rappresentazione grafica dell’applicazione. L’obiettivo di questa tesi è cercare
di sopperire a questa mancanza fornendo una possibile soluzione.
In questo capitolo andremo ad analizzare quali sono i requisiti che bisogna soddisfare per
realizzare la verifica formale. Concentrando l’analisi, non solo sulla definizione della logica
temporale, ma anche andando a definire il modello delle applicazioni che è possibile validare.
4.1 Modello dell’Applicazione
Per poter realizzare la verifica delle applicazioni è necessario che sia data una specifica formale
delle applicazioni stesse. In particolare, il lavoro di tesi mira a modellizzare le applicazioni web
basate dai dati. Si assume quindi di rappresentare le applicazioni con il modello composto da:
•
un database nel quale vengono salvati tutti i dati riguardanti le istanze del processo;
•
un insieme di stati che variano, durante lo svolgimento del processo, in funzione degli
input provenienti dall’utente;
•
un insieme di schemi di pagine web, tra le quali è necessariamente definita una home
page;
•
ogni schema di pagina web definisce quali sono le possibili scelte che l’utente può fare,
all’interno della pagina stessa, in funzione di una query al database e dello stato attuale.
A seconda della scelta presa dell’utente sarà necessario conoscere la nuova transizione
di stato, l’azione da compiere e lo schema della pagina web successiva;
__________________________________________________________________________________________________________________________________________________________
61
__________________________________________________________________________________________________________________________________________________________
Per esprimere tali proprietà è possibile utilizzare una generica rappresentazione formale, come
ad esempio, quella specifica nell’articolo [5]. Questo per due principali motivi:
•
ogni esecuzione di un processo deve soddisfare determinate condizioni sulla sequenza di
input, azioni e stati;
•
gestire il caso in cui vi siano esecuzioni simultanee dello stesso processo.
Figura 4-1: modello dell’applicazione
4.2 Specifica delle regole di verifica
In questo paragrafo vengono presentate le regole, definite dalla notazione di LTL, per la
verifica formale delle applicazioni. In particolare si evidenzia la relazione tra la specifica
formale delle regole stesse e la loro rappresentazione formale nell’ambito dei diagrammi di
workflow
__________________________________________________________________________________________________________________________________________________________
62
__________________________________________________________________________________________________________________________________________________________
Partendo dal presupposto che le attività sono dei “compiti” da svolgere è necessario tenere in
considerazione in quale stato si trovino tali attività.
Introduciamo la seguente notazione per descrivere gli stati:
•
An a = > An . status = “ACTIVE”
•
An c = > An . status = “COMPLETED”
TEMPORAL LOGIC
BEFORE
( An c B An+1 a )
ALWAYS
G A na
AND
( F An a And F An+1 a )
OR
( F An a Or F An+1 a )
XOR
( F An a Xor F An+1 a )
BPMN
Tabella 4-1: relazione tra notazione di BPMN e LTL
__________________________________________________________________________________________________________________________________________________________
63
__________________________________________________________________________________________________________________________________________________________
4.3 Validazione Automatica
Terminata la fase di estrazione delle regole temporali, sia dal workflow che dagli schemi delle
pagine web attraverso la modellazione descritta nel paragrafo 4.1, è possibile passare le formule
temporali ad un validatore per verificarne la coerenza. Ciò consente, in maniera completamente
automatica, di verificare che il processo rappresentato dal workflow venga implementato
correttamente, con i vincoli sia temporali che logici, nell’insieme di pagine web che
costituiscono l’applicazione data-intensive. Esistono dei software, come ad esempio SPIN
(Design and Validation of Computer Protocols) [6], che vengono utilizzati a tale scopo; cioè
come validatori di formule LTL. Difatti, SPIN supporta tutti i requisiti di correttezza esprimibili
tramite costrutti di tipo Liner Temporal Logic.
Passando tramite la validazione software è possibile fare un controllo finale sulla correttezza
dell’applicazione. Infatti, compiendo un confronto tra i vincoli introdotti nell’applicazione e
quelli presenti nel workflow si può evitare di avere discrepanze tra le due rappresentazioni.
__________________________________________________________________________________________________________________________________________________________
Scelte progettuali
64
__________________________________________________________________________________________________________________________________________________________
5
Scelte progettuali
In questo capitolo vengono presentate le scelte progettuali fatte per la realizzazione del tool
visuale. Saranno analizzati in particolare due aspetti:
•
l’analisi dei requisiti che dovrà soddisfare il tool dalla flessibilità alla notazione grafica
adottata per la rappresentazione dei diagrammi di workflow;
•
le regole di mapping tra i diagrammi di workflow e le formule temporali espresse in
LTL.
5.1 Use Case diagram
Cerchiamo di dare una definizione del comportamento del sistema tramite un diagramma Use
Case di UML.
disegno diagramma
workflow
salvo il diagramma
utente
carico diagramma
da file
eseguo una
trasformazione
Figura 5-1: use case diagram
__________________________________________________________________________________________________________________________________________________________
Scelte progettuali
65
__________________________________________________________________________________________________________________________________________________________
In Figura 5-1 possiamo vedere le principali funzioni che presenterà il tool. L’utente dovrà poter
realizzare un diagramma di workflow e in seguito salvarlo. Dovrà essere garantita la possibilità
di ricaricare un qualsiasi diagramma in precedenza salvato e, partendo dal diagramma, generare
le trasformazioni disponibili nel tool in quel momento.
5.2 Requisiti di flessibilità
Per soddisfare i requisiti posti nel paragrafo precedente e tenere aperti diversi orizzonti di
utilizzo, il tool deve essere configurabile, senza che questo comporti la modifica, e quindi anche
la conoscenza, del codice sorgente.
L’aspetto di personalizzazione deve essere accessibile in modo trasparente alla realizzazione a
basso livello e deve consentire sia l’aggiunta di nuove trasformazioni utilizzabili dall’utente sia
la modifica degli attributi degli elementi grafici. In particolare, bisogna permettere all’utente di
poter visualizzare nel diagramma di workflow anche solo alcuni degli attributi con cui ha
personalizzato gli elementi grafici. Grazie a questa caratteristica il tool potrà essere adattato a
più tipi di applicazione nell’ambito della progettazione tramite diagrammi di workflow.
Per soddisfare questi requisiti si è così deciso di consentire la configurazione del software
tramite dei file di documento in formato XML che hanno il vantaggio di essere facilmente
leggibili e modificabili (basta un semplice editor di testo), ma allo stesso tempo permettono di
gestire un’informazione articolata e ben strutturata che può essere facilmente interpretata ed
utilizzata all’interno di un programma senza appesantirne il funzionamento.
5.3 Specifica requisiti per la notazione grafica
La scelta dello standard da adottare per la realizzazione dei diagrammi di workflow ha
comportato un’attenta analisi dei requisiti.
Uno dei principali criteri di valutazione si basa sulla definizione, da parte dello standard, di una
notazione grafica, che descriva le fasi di lavoro all’interno di un generico processo di business.
Per questo, il modello deve essere in grado sia di coordinare la sequenza dei processi che il
passaggio di informazioni tra i processi coinvolti nella realizzazione di un certo numero di
attività.
__________________________________________________________________________________________________________________________________________________________
Scelte progettuali
66
__________________________________________________________________________________________________________________________________________________________
Lo standard ricopre un molteplice ruolo: permettere ad un utente di leggere e comprendere
senza difficoltà un diagramma e consentire allo sviluppatore di arricchire il diagramma con le
informazioni necessarie per una sua corretta implementazione.
Grazie a queste caratteristiche sarà possibile creare un collegamento, tra la fase di design del
processo di business e la fase di realizzazione.
Vista la necessità di rappresentare i workflow da implementare anche in ambito web, diviene
fondamentale avere degli strumenti per la suddivisione in categorie degli attori coinvolti nel
processo, così da individuare istantaneamente sia le possibili responsabilità sia le funzionalità
richieste.
Per soddisfare queste specifiche abbiamo orientato la nostra scelta verso la Business Process
Modeling Notation (BPMN) definita nel paragrafo 2.2.1.
5.3.1 Elementi di BPMN adottati
Per soddisfare le specifiche del progetto si è deciso di utilizzare solo una parte della notazione
definita da BPMN. Dalle quattro categorie base (Flow object, Connection object, Swimlane e
Artifact) sono stati estratti gli elementi necessari per la realizzazione del tool grafico. Una loro
classificazione è stata riportata in Tabella 5-1.
__________________________________________________________________________________________________________________________________________________________
Scelte progettuali
67
__________________________________________________________________________________________________________________________________________________________
CATEGORIA
ELEMENTO
TIPO
SIMBOLOGIA
Start
Event
End
Activity
Task
Flow object
And
Gateway
Or
Xor
Sequence flow
Connection object
Association
Swimlane
Lane
Artifact
Data object
Tabella 5-1: ogettti della notazione BPMN presenti nel tool grafico
Rispetto alla lista degli elementi in Tabella 5-1, è in previsione l’aggiunta delle activity con subprocess. Per farlo è necessario completare la loro implementazione nel tool grafico. Il codice è
stato progettato in modo che questa possibilità futura sia facilmente realizzabile, tramite
l’apposita predisposizione descritta nei precedenti paragrafi.
__________________________________________________________________________________________________________________________________________________________
Scelte progettuali
68
__________________________________________________________________________________________________________________________________________________________
5.4 Mappatura di workflow in LTL
Per la generazione delle regole introdotte dalla logica temporale è necessario analizzare tutti gli
elementi che compongono i diagrammi di workflow e per ognuno di questi si produce una
determinata regola. Di seguito riportiamo le regole di traduzione:
REGOLA
START
( F An a )
ACTIVITY
( An c B An+1 a )
SPLIT
GATEWAY
(Gn B ¬ ( F An a Oper F An+1 a))
MERGE
GATEWAY
(( F An c Oper F An+1 c) B ¬ Gn )
END
( F An c )
BPMN
Tabella 5-2: regole di traduzione tra operatori BPMN e LTL
Nella Tabella 5-2 non sono stati rappresentati tutti i casi che riguardavano gli operatori logici
And, Or e Xor; nella pratica la dicitura “Oper” sarà sostituita da And, Or o Xor in funzione della
rappresentazione grafica.
Mettendo un “AND” tra le regole generate dall’analisi del workflow si ottiene la formula
completa per descrivere un generico processo rispettando la notazione LTL.
__________________________________________________________________________________________________________________________________________________________
Tool
69
__________________________________________________________________________________________________________________________________________________________
6
Tool
Questo capitolo presenta le caratteristiche e il funzionamento del tool visuale. In particolare si
analizzerà:
•
l’interfaccia grafica;
•
il salvataggio dei diagrammi;
•
i file di configurazione;
•
la trasformazione LTL.
6.1 L’interfaccia grafica (GUI)
Per quanto riguarda l’interfaccia grafica abbiamo optato per una divisione del tool in quattro
parti fondamentali:
1. canvas all’interno della quale viene realizzato il disegno del diagramma di workflow;
2. toolbar relativa alla canvas, tramite questa serie di pulsanti è possibile decidere di
effettuare diverse operazioni come: disegnare gli oggetti, collegare tra loro gli oggetti o
fare dello zoom sulla canvas;
3.
panoramica del diagramma consente di ottenere sempre, indipendentemente dallo
zoom selezionato per la canvas, una visione globale del workflow che si sta realizzando;
4. pannello informazioni permette di visualizzare le informazioni relative all’oggetto
selezionato ed eventualmente di modificarle;
Vediamo nella Figura 6-1 uno screenshot di come appare il tool all’avvio:
__________________________________________________________________________________________________________________________________________________________
Tool
70
__________________________________________________________________________________________________________________________________________________________
2
3
1
4
Figura 6-1: screenshot del tool all’avvio
Come in tutti i software vi è una toolbar che presenta i menù a tendina File,
Transformation, Options e ?(About).
Andiamo ora a vedere come funzionano e cosa permettono di fare le vaire parti del tool
6.1.1 Toolbar principale
Come è possibile vedere dall’immagine qui a
fianco (Figura 6-2) nella toolbar sono presenti
quattro menù.
Figura 6-2: la toolbar principale
Selezionando il menù File vengono visualizzati gli elementi:
•
New:
consente di ripulire la canvas per la creazione di un nuovo
diagramma;
__________________________________________________________________________________________________________________________________________________________
Tool
71
__________________________________________________________________________________________________________________________________________________________
•
Open..:
apre un file chooser che permette di scegliere quale file
aprire. È consentita la visualizzazione dei soli file con
estensione XML;
•
Save As..:
apre un file chooser che consente di selezionare la
locazione e il nome del file in cui salvare il progetto
selezionato. Nel caso in cui l’estensione del nome del file
digitato sia diversa da .xml viene aggiunta;
•
Quit:
chiude il tool.
Nel menù Transformation troviamo le trasformazioni attualmente disponibili per il tool. Il
caricamento di questa “lista” viene fatto all’avvio del tool andando a leggere il file delle opzioni
Option.xml (vedi paragrafo 6.3). Le scelte possibili in questo menù variano a seconda degli
elementi presenti nella “lista”. Viene fornita a corredo la trasformazione:
•
Temporal Logic:
effettua la trasformazione del workflow in una formula di
Logica Temporale Lineare, ne salva il risulato in un file
HTML (che ha il nome uguale a quello del progetto
salvato) e lo visualizza tramite una finestra di Dialog.
Selezionando il menù Options appaiono, invece, 2 checkbox:
•
Button Autoselect:
quando è selezionato i bottoni della toolbar relativa alla
canvas (indicata con il numero 2 nella Figura 6-1)
rimangono selezionati, questo consente all’utente di
disegnare più oggetti dello stesso tipo senza dover
riselezionare ogni volta il tool desiderato;
•
Dialog Enabled:
serve per disabilitare o abilitare i messaggi di
avvertimento (come “file salvato con successo”, “vuoi
veramente cancellare l’oggetto?”, …) che il tool apre.
L’ultimo menù, indicato con il simbolo ?, non è altro che l’About.. , una finestra di dialogo
all’interno della quale vi sono le informazioni relative agli sviluppatori del tool.
Per l’analisi delle restanti parti del tool ci avvaliamo di un esempio, relativo alla realizzazione
di un workflow che descrive una richiesta di prestito. Si vuole creare un diagramma in cui un
cliente può effettuare una richiesta di prestito mediante la compilazione di alcuni form. Una
volta che i form sono stati compilati, la società di prestito effettua dei controlli, se tutto va a
__________________________________________________________________________________________________________________________________________________________
Tool
72
__________________________________________________________________________________________________________________________________________________________
buon fine il cliente verrà contattato da un impiegato per la stipula del contratto finale. I controlli
effettuati iniziano con il vedere se la richiesta è valida o meno. Nel caso non sia valida il
processo termina immediatamente, altrimenti viene comunicato al cliente un numero di
riferimento che gli permette di conoscere lo stato della sua richiesta; in contemporanea vengono
effettuati altri controlli dalla società di prestito. In seguito ai risultati di questi ulteriori controlli
la società prende una decisione relativa alla richiesta di prestito e termina il processo di
validazione. In questo processo abbiamo supposto che i manager effattuino l’inizio e la fine
dell’attività di validazione, mentre gli impiegati si occupino dei controlli. I controlli effettuati
dagli impiegati possono essere di due tipi: finanziario o situazione lavorativa, a seconda del tipo
di prestito richiesto dal cliente.
6.1.2 La canvas
Nella Figura 6-3 è realizzata una possibile rappresentare dell’esempio presentato in precedenza.
Come si può vedere gli elementi corrispondono a quelli della notazione BPMN descritta nel
paragrafo 2.2.1.
Figura 6-3: esempio di prestito: la canvas
__________________________________________________________________________________________________________________________________________________________
Tool
73
__________________________________________________________________________________________________________________________________________________________
6.1.3 La toolbar della canvas
1
2
3
4
5
6
7
8
Figura 6-4: screenshot della toolbar della canvas
In Figura 6-4 ne vediamo uno screenshot. Come si vede alcuni dei pulsanti sono stati
raggruppati: questa logica è stata pensata per avere una divisione dei bottoni secondo la
tipologia di funzionalità svolte.
Il primo bottone (indicato in figura con il numero 1) permette la selezione, lo spostamento e il
ridimensionamento degli oggetti.
Il gruppo di bottoni 2, 3, e 4 è relativo alle funzioni di ingrandimento/rimpicciolimento della
canvas. In particolare le loro funzioni sono, nell’ordine: ingrandire una determinata zona
utilizzando un rettangolo di selezione ottenuto attraverso il trascinamento del mouse;
rimpicciolire la canvas di un valore prefissato; impostare la dimensione della canvas in modo da
poter visualizzare tutto il progetto nella stessa schermata.
I bottoni seguenti(5, gruppo 6, 7 e 8) sono relativi alla realizzazione del diagramma di
workflow. Il bottone 5 permette di inserire una lane; i bottoni del gruppo 6 permettono di
inserire gli oggetti che devono essere posti all’interno di una lane: start, end, activity, and, or e
xor; il 7 inserisce una data object, oggetto che non deve essere posto in una lane; infine l’8
serve per creare un flow object: il tipo di oggetto realizzato cambia a seconda degli elementi che
stiamo collegando: se la connessione è tra un oggetto qualsiasi e una data object verrà creata
una association, negli altri casi (ricordiamo) verrà creato un sequence flow. E’ stato posto come
vincolo che non sia possibile collegare tra loro due data object, oltre a questo ne abbiamo posti
altri per evitare casi non contemplati dalla notazione BPMN: non è possibile creare un link che
parta e arrivi alla medesima activity, non è possibile fa terminare un link in un elemento start,
così come non è possibile far partire un link da un elemento end.
6.1.4 Panoramica del diagramma
Con quest’elemento (Figura 6-5) non è possibile interagire
direttamente, il suo cambiamento avviene in base alle modifiche
effettuate sulla canvas principale. Serve per avere una visione
panoramica del workflow, indipendentemente dal livello di
ingrandimento utilizzato sulla canvas principale. Come possiamo
Figura 6-5: esempio di prestito:
vedere in alto a destra è presente una linguetta che sta ad indicare
panoramica del diagramma
__________________________________________________________________________________________________________________________________________________________
Tool
74
__________________________________________________________________________________________________________________________________________________________
il livello di profondità del workflow a cui siamo. Il suo significato verrà spiegato più avanti
quando parleremo della “predisposizione al multilivello” (paragrafo 6.5).
6.1.5 Pannello informazioni
In questa sezione del tool, vengono visualizzati i dati relativi all’oggetto selezionato. Facciamo
un esempio per spiegarne il funzionamento. Selezioniamo un’activity tra quelle presenti nel
nostro workflow. Il bordo di questa si colora di rosso (Figura 6-6a) e nel pannello informazioni
vengono visualizzate le informazioni relative (Figura 6-6b).
a
b
Figura 6-6: a è l’activity selezionata e b il pannello informazioni relativo
Le informazioni visualizzate nel pannello sono personabilizzabili tramite un file di
configurazione XML che verrà descritto nel paragrafo 6.3. In questo caso gli attributi
dell’activity sono quattro: Name, Description, Type e Other. Andiamo a modificare i
campi vuoti della tabella presente nel pannello informazioni nel modo illustrato in Figura 6-7b:
a
b
Figura 6-7: a è l’activity dopo le modifiche effettuate nel pannello informazioni b
__________________________________________________________________________________________________________________________________________________________
Tool
75
__________________________________________________________________________________________________________________________________________________________
L’activity risultante dopo la suddetta modifica sarà quella che possiamo vedere in Figura 6-7a.
Come possiamo vedere sotto l’oggetto vengono visualizzati i valori di Description tra
parentesi tonde e di Type tra parentesi quadre come indicato anche nella tabella. Il campo
Other non viene visualizzato perché è stato specificato di non visualizzarlo nel file di
configurazione, ma anche, per quanto riguarda la spiegazione di questo punto rimandiamo al
paragrafo 6.3.
6.2 Salvataggio diagrammi workflow
Il salvataggio dei diagrammi di workflow è realizzato mediante l’utilizzo di costrutti, specificati
formalmente con XML. Analizziamo brevemente quali sono le caratteristiche e le funzionalità
messe a disposizione da questo linguaggio.
L’EXtensible Markup Language (XML) è un metalinguaggio, ossia un linguaggio destinato alla
creazione di linguaggi a marcatori, ufficializzato dal W3C (World Wide Web Consortium) nel
febbraio del 1998 con l’uscita della XML Recommendation 1.0.
XML è utilizzato per descrivere i dati, focalizzandosi su cosa essi rappresentino. I tag in XML
non sono predefiniti (come ad esempio in HTML) ma sono personalizzabili dall’utente. Questo
comporta l’utilizzo di un Document Type Definition (DTD) o di un XML Schema per descrivere
come i dati sono strutturati. E’ quindi sufficiente avere il documento XML con il rispettivo
DTD o XML Schema per determinare la natura e il tipo delle informazioni presenti nel
documento.
XML non è stato concepito per compiere azioni o istruzioni, l’ unico scopo è quello di
strutturare e memorizzare le informazioni, per questo può essere utilizzato per lo scambio di
dati tra sistemi incompatibili, riducendo di molto la complessità dovuta alla traduzione. Per
garantire l’indipendenza dalla piattaforma, sia essa hardware e/o software, i documenti XML
vengono salvati in formato testo, questo garantisce la loro condivisione da parte di differenti
applicazioni.
Nel progetto del tool grafico, il documento XML salvato, rappresenta un punto di partenza da
cui generare altre forme di output attraverso diverse possibili trasformazioni, tra cui le
trasfomzioni di tipo XSL (vedi paragrafo 7.5.1).
__________________________________________________________________________________________________________________________________________________________
Tool
76
__________________________________________________________________________________________________________________________________________________________
Osserviamo in dettaglio la sintassi utilizzata per scrivere un documento in XML:
1
2
3
4
5
<?xml version="1.0" encoding="ISO-8859-1"?>
<meeting date="29/11/2004">
<to>Rob</to>
<from>Frank</from>
</meeting>
Figura 6-8: esempio di codice XML
La prima riga del documento prende il nome di XML declaration, serve a definire la versione
dell’XML e il tipo di codifica utilizzata per il carattere. Nel caso specifico il documento è
conforme alla specifica 1.0 di XML e utilizza come carattere ISO-8859-1(Latin-1/West
European). La seconda riga del codice descrive l’elemento radice del documento “<meeting>”
a cui viene associato un attributo “date”. Le righe 3 e 4 descrivono i figli del nodo radice,
mentre la riga 5 è il tag di chiusura dell’elemento radice. E’ facile intuire come questo
documento contenga informazioni inerenti un certo incontro, tra due persone, ad una certa data.
Tramite questo esempio si dimostra la facilità di interpretazione dei documenti XML.
Del codice in Figura 6-8 è importante sottolineare alcuni aspetti; tutti gli elementi di XML
devono avere un tag di chiusura. A questa regola fa eccezione solo l’XML declaration che,
d’altra parte, non è un elemento del documento XML e perciò non necessita del tag di chiusura.
Tutti gli elementi devono essere correttamente annidati, prima di chiudere un elemento bisogna
assicurarsi di aver inserito il tag di chiusura a tutti gli elementi contenuti al suo interno. Il valore
degli attributi, associati ad un elemento, deve essere sempre racchiuso tra virgolette, come
mostrato nella riga 2 del codice di Figura 6-8.
__________________________________________________________________________________________________________________________________________________________
Tool
77
__________________________________________________________________________________________________________________________________________________________
6.2.1 Documento XML generato
Presentiamo un semplice esempio di workflow, con il relativo documento XML salvato:
<?xml version="1.0" encoding="UTF-8"?>
<SDSToolWF xmlns:auxiliary="http://www.webratio.com/ausiliario" xmlns:graphic="http://www.webratio.com/grafica">
<DIAGRAM graphic:go="Diagram_go" id="Diagram" version="0.9.2" creationDate="Wed Nov 10 2004">
<LANE graphic:go="lane1_go" id="Lane1" Name="Lane 1" Description="">
<START graphic:go="start1_go" id="Start1" Name="Start 1" Event="">
<LINK graphic:go="link1_go" id="Link1" to="Act1" Name="Link 1" Attr1="" Attr2=""/>
</START>
<ACTIVITY graphic:go="act1_go" id="Act1" Name="Activity 1" Description="" Type="" Other="">
</ACTIVITY>
<ACTIVITY graphic:go="act2_go" id="Act2" Name="Activity 2" Description="" Type="" Other="">
<LINK graphic:go="link3_go" id="Link3" to="End1" Name="Link 3" Attr1="" Attr2=""/>
</ACTIVITY>
<END graphic:go="end1_go" id="End1" Name="End 1" Event=""/>
</LANE>
<DATAOBJECTS/>
</DIAGRAM>
<auxiliary:GraphMetaData>
<graphic:Lane id="lane1_go" x="122.0" y="55.0" width="565.0" height="101.0"/>
<graphic:Start id="start1_go" x="179.5" y="83.75" width="31.0" height="31.0"/>
<graphic:Connection id="link1_go" xp1="195.0" yp1="99.25" xp2="336.0" yp2="99.0"/>
<graphic:Activity id="act1_go" x="298.0" y="76.0" width="75.0" height="45.0"/>
<graphic:Activity id="act2_go" x="443.0" y="76.0" width="75.0" height="45.0"/>
<graphic:End id="end1_go" x="598.5" y="82.75" width="33.0" height="33.0"/>
</auxiliary:GraphMetaData>
</SDSToolWF>
Figura 6-9: diagramma di workflow con documento XML associato
La Figura 6-9 consente di comprendere il risultato che si ottiene salvando un diagramma di
workflow. Il documento XML è suddiviso in due parti fondamentali, contraddistinte dagli
elementi:
•
DIAGRAM contenente informazioni inerenti la struttura del diagramma di workflow;
•
auxiliary:GraphMetaData contenente le informazioni per la rappresentazione grafica
degli oggetti;
Analizziamo in dettagli solamente la sintassi XML presente nell’elemento DIAGRAM, visto che
le informazioni nell’elemento auxiliary:GraphMetaData, hanno una valenza relativa alla solo
rappresentazione grafica generata dal tool grafico.
__________________________________________________________________________________________________________________________________________________________
Tool
78
__________________________________________________________________________________________________________________________________________________________
Ogni oggetto del diagramma di workflow è presente, ad un diverso livello di “annidamento”,
all’interno dell’elemento DIAGRAM. Il livello di annidamento di ogni oggetto segue il criterio
della struttura dati presente in memoria, descritta nel paragrafo 7.3.
I figli dell’elemento DIAGRAM sono tutte le LANE presenti nel diagramma più l’elemento
DATAOBJECTS che conterrà come figli tutte le data object specificate nel diagramma.
Nell’esempio di Figura 6-9 è presente un solo elemento di tipo LANE. Nel nodo LANE vengono
posti tutti gli elementi che fanno riferimento agli oggetti grafici posti all’interno della LANE
stessa come il nodo START, END e le due ACTIVITY. Nel caso in cui da uno di questi ultimi
elementi “esca” un collegamento verso un altro elemento, allora viene creato un ulteriore
elemento chiamato LINK che sarà posto come nodo figlio dell’elemento da cui esce.
Tutti gli attributi, ad eccezione di graphic:go, id e to (solo per gli elementi LINK), associati agli
elementi sono definibili a discrezione dell’utente tramite il file di configurazione (vedi
paragrafo 6.3). E’ interessante notare come tramite l’attributo to, presente in tutti gli elementi di
tipo LINK, sia possibile conoscere quali oggetti sono collegati tra loro nel diagramma di
workflow. L’oggetto di partenza del collegamento si conosce dato che è il nodo padre
dell’elemento LINK nel documento XML, mentre l’oggetto di arrivo viene trovato attraverso il
suo id posto come valore dell’attributo to del LINK.
Nelle esempio di Figura 6-9 non sono presenti data object, ma il meccanismo di salvataggio nel
documento XML è del tutto simile a quello utilizzato per gli altri elementi . L’unica sostanziale
differenza è che le data object fanno tutte riferimento ad un unico nodo padre rappresentato
dall’elemento DATAOBJECTS .
…….
<DATAOBJECTS>
<DATAOBJECT graphic:go="data1_go" id="Data1" Name="Data Object 1" Type=""/>
<DATAOBJECT graphic:go="data2_go" id="Data2" Name="Data Object 2" Type="">
</DATAOBJECT>
</DATAOBJECTS>
…….
Figura 6-10: documento XML inerente le Data object
L’esempio di Figura 6-10 rappresenta due data object, la prima non ha alcun elemento LINK in
uscita, mentre la seconda ne ha uno. Questo ci consente di sapere che la seconda data object è
collegata ad un oggetto di tipo activity con valore dell’id pari a “Act2”.
__________________________________________________________________________________________________________________________________________________________
Tool
79
__________________________________________________________________________________________________________________________________________________________
6.3 File configurazione
Per la realizzazione di questo progetto, si è reso necessario l’utilizzo di due distinti file di
configurazione, entrambi scritti in formato XML. Questi file hanno il compito di dare una
maggiore modularità al progetto, tenendo in considerazione i possibili sviluppi futuri.
Per il corretto funzionamento del tool è necessario che i file di configurazione, il cui nome è
Configuration.xml e Option.xml, siano presenti nella stessa directory del progetto.
Come evidenziato nel paragrafo 6.1.5, ad ogni oggetto grafico, vengono associate delle
proprietà (oltre all’id). Tali proprietà sono personalizzabili tramite il file Configuration.xml.
Lo scopo del file Option.xml è invece quello di definire il numero e il tipo di trasformazioni che
è possibile applicare al documento XML generato con il salvataggio del diagramma di
workflow. Tali trasformazioni appariranno nel menù Transformation. Sempre con il file
Option.xml si tiene traccia delle impostazioni, selezionate dall’utente nel menu Options (vedi
paragrafo 6.1.1).
<CONFIGURATION>
<LANE>
<Name visual="true"/>
<Description visual="true"/>
</LANE>
<ACTIVITY>
<Description visual="true" Open="(" Close=")"/>
<Type visual="true" Open="[" Close="]"/>
<Other visual="false"/>
</ACTIVITY>
<START>
<Event visual="true" Open="[" Close="]"/>
</START>
<END>……….</END>
<OR>
<Name visual="false"/>
<Type visual="true" Open="[" Close="]"/>
</OR>
<AND>……….</AND>
<XOR>……….</XOR>
<DATAOBJECT>
<Share visual="true" Open="[" Close="]"/>
</DATAOBJECT>
<CONNECTION>
<Description visual="false"/>
<Typer visual="false"/>
</CONNECTION>
</CONFIGURATION>
Figura 6-11: file Configuration.xml
__________________________________________________________________________________________________________________________________________________________
Tool
80
__________________________________________________________________________________________________________________________________________________________
In Figura 6-11 è riportato il documento Configuration.xml. Come accennato, ad ogni oggetto
grafico è possibile legare delle proprietà. Ad ogni proprietà che si definisce deve essere,
necessariamente, associato una serie di attributi. Gli attributi variano al variare del tipo di
proprietà. Se il nome dell’attributo è Name bisogna assegnare all’attributo Visual i possibili
valori booleani true o false, per tutti gli altri tipi di attributo è necessario specificare altri
due attributi: Open e Close che hanno, come possibile valori, un dato di tipo char.
Specifichiamo l’utilità di questi attributi:
•
Visual:
se il valore è true il nome dell’oggetto, oltre a comparire nel
pannello informazioni, compare anche nella rappresentazione
grafica dell’oggetto.
•
Open / Close:
Sono i tag che vengono posti, nella rappresentazione grafica,
all’inizio e alla fine delle proprietà, questo per aumentare la
leggibilità e la chiarezza dei diagrammi.
L’unico vincolo, posto sui tag d’apertura e chiusura delle proprietà, è che il carattere utilizzato
sia uno solo. La scelta del carattere da utilizzare è lasciato all’utente, eventualmente è possibile
definire dei tag di apertura e chiusura anche diversi tra loro.
<OPTIONS>
<TOOL>
<ButtonToolUnselect value="false"/>
<Dialog value="false"/>
</TOOL>
<TRANSFORMATIONS>
<T1 Name="Temporal Logic" Source="C:\Software\Jar File\ltlTransformation.xsl" Type="XSL"/>
<T2 Name="Java Transformation" Source="c:\T2.class" Type="JAVA"/>
</TRANSFORMATIONS>
</OPTIONS>
Figura 6-12: file Option.xml
Dalla Figura 6-12 si vede come il documento XML del file Option.xml sia suddiviso in due
parti:
•
TOOL:
in quest’elemento sono salvate le impostazioni selezionate
dall’utente nelle due checkbox del menù Option.
•
TRANSFORMATION:
vengono definite le trasformazioni che compariranno
all’interno del menù Trasformation.
Gli attributi che devono essere impostati per ogni trasformazione definita sono: Name, Source
e Type. Il primo è la stringa visualizzata nel menù Trasformation, il secondo è il percorso
__________________________________________________________________________________________________________________________________________________________
Tool
81
__________________________________________________________________________________________________________________________________________________________
del file che contiene la trasformazione ed il terzo è il tipo di trasformazione che si vuole
realizzare. Per l’attributo Type sono possibili due valori:
• XSL:
la trasformazione è definita tramite il linguaggio XSL.
• JAVA:
la trasformazione è definita all’interno di una classe JAVA
Nel seguente paragrafo descriveremo la trasformazione di tipo XSL a corredo del tool.
6.4 Trasformazione Linear Temporal Logic (LTL)
Il suo scopo è trasformare il workflow rappresentato graficamente in una formula di logica
temporale lineare rispettando la notazione presentata nel paragrafo 5.4. Questa trasformazione
avviene tramite XSL.
XSL è un linguaggio per scrivere stylesheet: serve per descrivere come dovranno essere
rappresentati i dati strutturati presenti all’interno di un certo tipo di file XML. Permette di
descrivere lo stile, il layout e la paginazione all’interno di un qualsiasi media, come ad esempio
la finestra di un browser piuttosto che quella di un dispositivo portatile. Nel caso specifico di
questo progetto, XSL è stato utilizzato per riconoscere elementi in particolari pattern all’interno
del diagramma e trasformarli in formule LTL come descritto nel paragrafo 5.4.
6.4.1 Output della trasformazione
La trasformazione viene eseguita partendo dal file XML del diagramma salvato. Per questo
motivo il tool richiede il salvataggio del progetto prima di generare l’output in LTL. Al file
salvato si applica la trasformazione XSL che genera la formula temporale, come evidenzia il
seguente esempio (Figura 6-13):
__________________________________________________________________________________________________________________________________________________________
Tool
82
__________________________________________________________________________________________________________________________________________________________
Figura 6-13: diagramma di workflow con relativa formula logica
La formula logica ottenuta dal diagramma presentato in quest’esempio rispetta le regole di
mapping definite nella Tabella 5-2. Nel caso specifico si nota come l’estrazione delle regole
non segue l’ordine con cui i rispettivi operatori BPMN compaiono all’interno del workflow,
nell’esempio la regola che esprime il gateway Or2 precede l’ultima regola che esprime la
precedenza tra l’attività Act2 e l’attività Act3 anche se nel workflow avviene il contrario.
Questo può rendere più difficile la lettura ad un utente “umano”, ma non inficia in alcun modo
la veridicità della regola temporale.
6.5 Predisposizione al multilivello
Come accennato nel paragrafo Panoramica del diagramma (6.1.4), il tool
è stato predisposto per supportare la realizzazione di workflow
multilivello, come definito dalla notazione BPMN. Per consentire
quest’ulteriore sviluppo è necessario aggiungere le unità di tipo activity
con sub-process (Figura 6-14). Lo scopo è quello di consentire
Figura 6-14: activity
all’utente, una volta selezionata activity con sub-process, di aprire una
con sub-process
nuova finestra all’interno della quale disegnare i sotto-processi. Questi
sotto-processi sono anch’essi specificabili tramite workflow, quindi una activity con subprocess non sarà altro che un insieme di diagrammi di workflow. La vista panoramica del
diagramma consente si avere sempre una visione globale del workflow. Per la realizzare della
finestra con la panoramica è stato utilizzando un pannello con linguette, in modo che sia
possibile selezionare la visualizzazione di uno dei livelli presenti nel diagramma.
__________________________________________________________________________________________________________________________________________________________
Implementazione
83
__________________________________________________________________________________________________________________________________________________________
7
Implementazione
Per lo sviluppo del tool si è deciso di utilizzare, come linguaggio di programmazione, Java. La
scelta è stata supportata dal fatto che esistono, per questo linguaggio, dei compilatori freeware e
che funziona indipendentemente dalla piattaforma d’esecuzione.
Java è nato originariamente come linguaggio per la rete, verso la metà degli anni novanta. Data
la giovane età è sempre in fase di sviluppo e ogni anno circa viene rilasciata una nuova
versione.
Da linguaggio nato solo per la rete è divenuto un vero e proprio linguaggio di programmazione
paragonabile, dal punto di vista delle funzionalità, al più blasonato C++. Il paragone può essere
fatto solo dal punto di vista delle funzionalità messe a disposizione perché funzionano in
maniera profondamente diversa: Java compila i sorgenti dei suoi programmi in un codice detto
bytecode, diverso dal linguaggio della macchina su cui è compilato; i linguaggi come il C++
compilano i sorgenti dei programmi in un codice che è il codice della macchina su cui è
compilato. Per eseguire un programma Java è necessario avere uno strumento che è chiamato
Java Virtual Machine (JVM), la quale interpreta il bytecode generato dal compilatore e lo
esegue sulla macchina su cui è installata. La JVM rende Java completamente indipendente dalla
piattaforma in quanto il programma compilato è legato solo alla JVM e non al sistema
operativo. Supponendo di avere due piattaforme, una Windows e l’altra Linux, per eseguire un
programma scritto in Java è sufficiente avere installato all’interno dei due sistemi operativi la
rispettiva versione della JVM. Le due JVM installate sono lo stesso programma compilato
rispettivamente per Windows e per Linux.
Per questo progetto è stato utilizzato, come compilatore, Java 2 Software Development Kit
versione 1.4.2_04, che comprende sia il compilatore che la JVM. Adottando questa soluzione è
possibile realizzare software senza alcuna spesa per l’acquisto di diritti come avviene invece
per certi ambienti di sviluppo proprietari.
Nonostante Java fornisca una grande quantità di funzionalità, per l’aspetto prettamente grafico,
si è deciso l’utilizzo di una libreria che andasse otre il semplice utilizzo di tabelle, liste o
bottoni. Questo perché ciò di cui abbiamo bisogno è uno strumento grafico che consenta di
rappresentare sia degli oggetti che le relazioni tra essi.
__________________________________________________________________________________________________________________________________________________________
Implementazione
84
__________________________________________________________________________________________________________________________________________________________
Per questo scopo sono state scelte le librerie grafiche denominate JKit/GO. Una panoramica
sufficientemente dettagliata sarà data in seguito. Nel prossimo paragrafo viene presentata la
struttura base del tool attraverso un diagramma delle classi.
7.1 Class diagram
Rappresentiamo qui di seguito il diagramma delle classi, realizzato in fase di progettazione, che
dà una sommaria visione di quelle che sono le classi java e i relativi metodi, che abbiamo in
seguito utilizzato per realizzare il tool:
Tool
+redraw()
+close()
#getFrame()
1
1
1
1
-compone
-compone
1
1..*
-compone
panoramica diagramma
pannello info
toolbar
-è formato da
finestra canvas
-color_background
#repaint()
#update()
#clear()
#redraw()
#clear()
#setInfo()
+open()
+close()
+update()
1
usato in
Salva
usato in
usato in
Carica
1
Trasformazione
+open_file()
-color_background
-dimension
-zoom
+selectGO()
+showGO()
+getTool()
+transform_xml()
-è composto da
-compone
canvas
-type
+select_file()
-compone
1
-compone
canvas_toolbar
-tool_number
+getSelectedTool()
contiene
utilizzato in
oggetto grafico
-dimension
-position
+add()
+remove()
+selected()
+unselected()
Lane
+getHeader()
+getBody()
Activity
+getName()
+getAttrib(i)()
And
Gateway
+getLinkIn()
+getLinkOut()
Or
Data Object
+getSource()
+getTarget()
+getEntity()
Xor
Link
-getParent
-getSource
Sequence
Association
Figura 7-1: diagramma delle classi
__________________________________________________________________________________________________________________________________________________________
Implementazione
85
__________________________________________________________________________________________________________________________________________________________
Nel paragrafo seguente si spiega come sono state implementate le classi partendo dal class
diagram, nel rispetto dei vincoli imposti dall’utilizzo delle librerie grafiche Jkit/GO, che
abbiamo utilizzato per lo sviluppo del tool grafico.
7.1.1 Implementazione del class diagram
Il class diagram presentato in Figura 7-1 è stato preso come traccia per la realizzazione delle
classi presenti nel progetto: le librerie Jkit/GO richiedono un elevato numero di listener per la
gestione degli eventi riguardanti gli oggetti, e quasi tutti sono stati implementati tramite classi
aggiuntive.
Analizziamo in generale, le relazioni tra le classi generate per il tool grafico e il class diagram
di Figura 7-1.
•
Tool ha preso il nome di SDSGraphicalTool ed è la classe principale del progetto;
•
Toolbar può essere associato alla classe FileListener che richiama le classi
OpenToolXML (Carica), SaveToolXML (Salva) e TransfActionListener
(Trasformazione);
•
Pannello Info ha preso il nome di InfoTabPanel;
•
Panoramica diagramma ha preso il nome di AeroCanvas;
•
FinestraCanvas è stata implementata mediante un metodo all’interno di
SDSGraphicalTool e solo alcuni dei suoi componenti sono stati realizzati come
classi separate: Canvas è diventato ScrollableCanvas, Lane è diventata
createLane, Activity createActivity e analogamente è avvenuto per gli altri
elementi del tipo oggetto grafico (inclusi And, Or e Xor);
Nel progetto finale sono presenti ulteriori classi, il cui compito principale è di gestire i listener
relativi agli oggetti creati.
__________________________________________________________________________________________________________________________________________________________
Implementazione
86
__________________________________________________________________________________________________________________________________________________________
7.2 Libreria Grafica
La realizzazione dell’interfaccia grafica è stata realizzata utilizzando le librerie SWING di
JAVA con l’ausilio delle librerie Jkit/GO sviluppate da Instantiations.
Le librerie JKit/GO forniscono un valido framework per la realizzazione e gestione degli
oggetti grafici. Il codice sorgente è stato scritto in Java, così da avere una completa compatibile
con tutti i compilatori Java. Utilizzando le JKit/GO è possibile realizzare dei diagrammi 2D
interattivi, grazie alla definizione di nuovi tipi di oggetti grafici non comuni in Java. Tali
oggetti contengono al loro interno delle informazioni di stato collegate alla rappresentazione
grafica. Nel capitolo precedente si è visto che un GFRoundedRectangleGO (classe per
rappresentare graficamente un rettangolo con angoli smussati) assume il significato di activity
all’interno di un workflow. Come il GFRoundedRectangleGO appare, le azioni che vengono
compiute quando viene selezionato e le opzioni che si possono selezionare sono tutte
funzionalità facilmente accessibili e personalizzabili grazie all’utilizzo delle JKit/GO.
Essendo state sviluppate nel 1998 presentano, per certi versi, delle caratteristiche obsolete, visto
che estendendo le librerie grafiche AWT di JAVA. Ciò comporta la mancanza di molti metodi
che vengono abitualmente utilizzati nelle SWING, ad esempio il metodo autoscroll (utilizzato
per scorrere automaticamente le pagine più grandi dello schermo) è presente nella classe JPanel
delle SWING mentre non lo è nella classe Panel delle AWT.
Le librerie sono basate sull’utilizzo degli eventi per conoscere lo stato in cui si trovano gli
oggetti grafici. E’ sufficiente associare un listener ad ogni oggetto, attraverso questo è possibile
inviare un opportuno messaggio nel momento in cui lo stato dell’oggetto cambia, come ad
esempio quando viene selezionato. Catturando il messaggio è possibile realizzare qualsiasi tipo
di azione in risposta all’evento generato.
Le JKit/GO introducono molte nuove classi Java, è comunque sufficiente conoscerne in
dettaglio cinque per comprenderne il funzionamento di base:
•
GFGraphicObject
•
GFDrawingManager
•
GFDrawingCanvas
•
GFHandle
•
GFTool
__________________________________________________________________________________________________________________________________________________________
Implementazione
87
__________________________________________________________________________________________________________________________________________________________
Per evitare ogni genere di conflitto con altre classi è stato introdotto il prefisso “GF” (Graphic
Frameworks) davanti al nome di tutte le classi associate alle JKit/GO. Per utilizzare
correttamente le JKit/GO non è necessario conoscere come funziona una certa classe. Bisogna
invece sapere quali sono le classi di cui si avrà bisogno e specialmente come queste
interagiscono tra loro. Analizziamo il ruolo e le responsabilità delle classi chiave definite in
precedenza:
GFGraphicObject:
questa è la classe centrale per lo sviluppo di applicazioni basate
sulle JKit/GO. Per riferirsi a questo classe in futuro si utilizzerà
l’abbreviazione “GO”. Un GO utilizza gli eventi per notificare, a
chi di dovereè interessato, tutto quello che gli accade. Gli eventi
sono utilizzati per far rispettare i vincoli e per evitare di legare il
GO con il dominio del modello che esso stesso rappresenta. Con
il seguente codice:
aGO.addSelectionListener(this)
l’oggetto grafico chiamato aGO invia un messaggio di
goSelected e di goUnselected ogni qual volta viene
selezionato dall’utente. Un GO gestisce la propria
visualizzazione, conosce quando un punto è contenuto al suo
interno e se interseca una certa area. Un GO è contenuto sempre
all’interno di un altro GO con un'unica eccezione che è il
GFDrawing. Un GFDrawing è l’oggetto grafico che contiene
tutti i GO in una finestra, esattamente un GFDrawing è un
contenitore che istanzia la classe GFDrawingManager.
GFDrawingManager:
questa classe gestisce l’editing e la manipolazione dei GO,
consentendo di aggiungere, eliminare o raggruppare gli oggetti
all’interno dei un generico disegno. Per aggiungere un oggetto al
disegno è necessario, creare un GO e colegarlo al manager, che è
una istanza di GFDrawingManager, con il seguente codice:
manager.add(aGO);
manager.redraw();
la seconda istruzione serve ad aggiornare il disegno per rendere
visibile anche il GO aggiunto.
__________________________________________________________________________________________________________________________________________________________
Implementazione
88
__________________________________________________________________________________________________________________________________________________________
GFDrawingCanvas:
è una classe che “eredita” direttamente dalle AWT di Java. Il suo
compito principale è quello di fornire una superficie dove
mostrare il disegno. Una volta creata l’istanza di questa classe è
necessario legarlo ad un manager, questo perché la gestione di
tutti gli oggetti è delegata al manager e non alla canvas. Di
seguito riportiamo il codice per associare una istanza di
GFDrawingCanvas con la istanza di GFDrawingManager:
GFDrawingCanvas canvas = new GFDrawingCanvas();
GFDrawingManager manager = new GFDrawingManager();
canvas.setManager(manager);
Creata la canvas è possibile aggiungerla come un componente
AWT all’interno di una generica finestra.
GFHandle:
tutti gli input, prodotti da un utente, su un GO vengono gestiti
tramite una istanza di GFHandle o di GFTool. Per spostare un GO
viene creata “al volo” una istanza di GFHandle, nel momento in
cui si preme il tasto del mouse all’interno dell’area del GO.
Esistono di default degli handle che sono sempre presenti in un
GO questo perché, ad esempio,è necessario ridimensionare
l’oggetto. Gli handle sono usati anche per definire un punto dove
è possibile collegare tra loro gli oggetti. Nelle JKit/GO gli handle
vengono rappresentati genericamente tramite un quadratino nero o
una “x”(dipende dal funzionalità associata), come in figura:
Figura 7-2: rappresentazione grafica degli handle
Selezionando uno dei quattro quadratini neri associato al GO è
possibile modificare la dimensione dell’oggetto. Le “x”
rappresentano invece i punti in cui vengono ancorate le linee che
collegano i GO.
GFTool:
il tool rappresenta il modo con cui si sta agendo sul disegno.
Quando si seleziona un oggetto implicitamente si utilizza il tool
chiamato GFSelectionTool, se invece si vuole creare un oggetto e
aggiungerlo alla canvas si utilizza un GFCreationTool. Per
__________________________________________________________________________________________________________________________________________________________
Implementazione
89
__________________________________________________________________________________________________________________________________________________________
decidere il tool da utilizzare è sufficiente andarlo a selezionare in
una serie di bottoni messi a disposizione dalle JKit/GO. I tool
assieme al manager sono gli strumenti per gestire la realizzazione
dei design. Una volta che il tool è impostato, tutti gli eventi
generati dall’utente sul disegno, passano attraverso di esso così da
filtrarli se necessario.
7.3 Struttura dati
Nel tool grafico, si è preferito realizzare una netta separazione tra la rappresentazione grafica
degli oggetto e il modello dei dati presente in memoria.
Visto che per il salvataggio su file si utilizza XML è stato necessario creare in memoria una
struttura che consentisse, in maniera semplice e coerente, di passare dalla rappresentazione
grafica del tool al file di salvataggio XML, per questo si è scelto una struttura dati ad albero
(vedi Figura 7-3). Ogni nodo dell’albero è definito come istanza della classe Java
DefaultMutableTreeNode, tale classe ha il pregio di definire svariati metodi per la
navigazione all'interno dell'albero; ad esempio è possibile conoscere il nodo radice, il nodo
padre, i nodi figli se esistono e il loro numero.
Il dato che viene salvato all'interno del singolo nodo è una istanza della classe GFNode
appositamente definita nel tool. In questa classe vengono salvate due informazioni, l'ID e gli
attributi dell’oggetto grafico associato. L’ID è generato in modo univoco alla creazione
dell'oggetto. Quando si crea la prima Lane, l'ID associato è "Lane1" per la seconda invece sarà
"Lane2" così via. Per creare un legame tra gli oggetti grafici disegnati sulla canvas e la struttura
in memoria è necessario, alla creazione del GO, usare questo codice:
aGO.setMetaObject(aNode);
dove aGO è una qualsiasi classe che definisce un oggetto grafico (es. GFRectangleGO),
mentre aNode è una istanza della classe GFNode. Se si conosce l’oggetto e si vuole sapere a
quale nodo dell’albero appartiene, basta utilizzare il seguente metodo che ritorna il GFNode
cercato:
aNode =
(GFNode) aGO.getMetaObject()
purtroppo questo non vale nel caso contrario, cioè quando si ha il nodo dell’albero e si vuole
risalire al GO associato. Per risolvere tale problema abbiamo utilizzato una lista, realizzata
attraverso l’istanza della classe Hashtable definita in Java.
__________________________________________________________________________________________________________________________________________________________
Implementazione
90
__________________________________________________________________________________________________________________________________________________________
1
2
3
Figura 7-3: struttura dati ad albero del tool
La struttura dati ad albero (Figura 7-3) è composta, oltre che dal livello radice, da tre livelli
fondamentali. Il primo livello contiene i nodi che fa fanno riferimento alle Lane presenti nel
disegno, più un ulteriore nodo utilizzato per raggruppare le Data Object. Al secondo vi sono i
nodi che fanno riferimento a tutti gli oggetti grafici che descrivono il workflow come lo Start,
l’End, le Activity e tutti i tipi di gateway (And, Or e Xor); questi nodi devono necessariamente
far riferimento al nodo che rappresenta la Lane dove sono posti. Sempre a questo livello
dell’albero vengono posizionate le Data Object raggruppate sotto il nodo padre Group Data
Objects. Nel terzo ed ultimo livello sono invece inseriti i nodi associati ai Link uscenti
dall’oggetto grafico a cui sono associati, in Figura 7-3 l’attività con ID “Activity 1” ha due Link
uscenti con ID rispettivamente “Link 1” e “Link 2”.
Conoscendo il Link uscente da un certo nodo, tramite l’oggetto grafico che rappresenta il Link
(solitamente un istanza di GFPolylineGO) è possibile risalire al nodo di destinazione. Come
detto in precedenza, per passare dal nodo nell’albero al GO è stato necessario utilizzare una
Hashtable.
Una Hashtable è una mappa tra chiavi univoche e entry. Ciò significa che nella tabella sono
presenti delle coppie (chiave; entry) e conoscendo la chiave si ricava la entry associata.
I due metodi per gestire l’inserimento e l’estrazione dell’informazione sono:
aHashtable.put(chiave, entry);
aHashtable.get(chiave);
__________________________________________________________________________________________________________________________________________________________
Implementazione
91
__________________________________________________________________________________________________________________________________________________________
è detta hashtable perchè il posizionamento effettivo della entry nella memoria e' determinato da
un "rimescolamento" (hashing) basato sulle chiavi. Ciò fornisce delle desiderabili proprietà
statistiche, tali che chiavi diverse tendono a generare posizioni diverse. Formalmente avremo
una funzione del tipom hash(chiave) che genera, ad esempio, un indice in un array.
L’implementazione dei due metodi di put e get sarà quindi:
•
put(chiave,entry)
:
array[hash(chiave)] = entry
•
get(chiave)
:
return
array[hash(chiave)]
il che garantisce una notevole velocità di accesso se comparata alle consuete strutture dati. Con
una lista unidirezionale, per implementare il metodo get(chiave) bisogna scorrere la lista
dall'inizio fino a quando o s’individua la chiave o la lista e' finita. Nel caso in cui due chiavi
diverse generino lo stesso indice si ha una "collisione", questo perché bisognerebbe mettere due
elementi distinti nella stessa posizione dell'array. Siccome questo non è possibile, per ovviare al
problema viene messa nell'array una “lista” (o altra struttura dati) di entry, invece che mettere
una sola entry. Inserendo un elemento, in caso di collisione, se nella posizione hash (chiave) c'è
già una entry, si fa semplicemente l'append sulla lista.
Nel caso specifico del tool grafico la chiave è istanza del GFNode mentre l’entry è il GO
associato.
Con l’utilizzo simultaneo della strutture dati ad albero e della Hashtable, è possibile gestire in
maniera completa sia l’inserimento sia la cancellazione degli oggetti nei disegni. Un caso
emblematico è rappresentato dalla cancellazione di una Lane. Ciò comporta la cancellazione di
tutti i GO presenti al suo interno oltre che dei Link entranti o uscenti dagli stessi GO cancellati.
7.4 Salvataggio file XML
Come visto nel precedente paragrafo in memoria è presente una struttura dati che contiene le
informazioni riguardanti i diagrammi di workflow disegnati. Partendo da questa struttura si
genera, in modalità completamente automatica, il documento XML che la descrive.
Al momento del salvataggio del diagramma di workflow viene richiamata un’istanza della
classe SaveToolXml, che ha il compito di creare il file XML. In Figura 7-4 riportiamo la parte
significativa della classe SaveToolXml:
__________________________________________________________________________________________________________________________________________________________
Implementazione
92
__________________________________________________________________________________________________________________________________________________________
1
2
3
4
5
6
7
8
9
10
11
12
Document doc = builder.newDocument();
Element SDSTool = doc.createElement("SDSToolWF");
…..
Element Diagram = doc.createElement("DIAGRAM");
…..
new SaveTreeDiagram(Tree, Diagram, doc, nodeGODict);
SDSTool.appendChild(Diagram);
Element GraphMetaData = doc.createElement("auxiliary:GraphMetaData");
new SaveTreeGraph(Tree, GraphMetaData, doc, nodeGODict);
SDSTool.appendChild(GraphMetaData);
doc.appendChild(SDSTool);
…..
Figura 7-4: classe SaveToolXml.java
Nella riga 1 viene creato il documento XML, nella riga 2 è definito l’elemento radice chiamato
SDSToolWF. All’elemento radice sono collegati i due elementi figli DIAGRAM e
auxiliary:GraphMetaData, rispettivamente alle righe 7 e 10. Questi due elementi, come detto
nel paragrafo 6.2.1, costituiscono la struttura base del documento. Per inserire le informazioni
presenti nei due elementi vengono richiamate rispettivamente le istanze delle classi
SaveTreeDiagram e SaveTreeGpaph. Le due classi sono entrambe di tipo ricorsivo; il
loro scopo è quello di scorrere la struttura dati ad albero ed estrarre le informazioni necessarie
al completamento del documento XML. Ad esempio la classe SaveTreeDiagram analizza i
nodo dell’albero e da ognuno di essi ricava: l’id, il nome e il valore degli attributi associati
all’oggetto grafico, tali dati verranno poi riportati nel file XML con la corretta sintassi.
7.5 Generazione trasformazione XSL
Per definire le trasformazioni presenti nel tool grafico vi sono due possibilità di codifica:
•
utilizzare una trasformazione XSL;
•
implementare una classe atta allo scopo;
Dato che nell’applicativo è presente una sola trasformazione (di tipo XSL), daremo una visione
generale dei linguaggi XSL e XPath. In conclusione si preseterà il codice che consente la
realizzazione della trasformazione dai diagrammi di workflow a formule logiche temporali
basate su LTL.
__________________________________________________________________________________________________________________________________________________________
Implementazione
93
__________________________________________________________________________________________________________________________________________________________
7.5.1 eXstensible Stylesheet Language (XSL) e XPath
XSL è un linguaggio per scrivere Stylesheet. Descrivere lo stile, il layout e la paginazione
all’interno di un qualsiasi media, come ad esempio la finestra di un browser.
Prima di presentare gli elementi più significativi di XSL è necessario introdurre XPath: un
insieme di regole di sintassi per definire le parti in un documento XML. Senza conoscere,
queste regole, non è possibile spiegare gran parte del codice XSL che abbiamo scritto. Bisogna
introdurre il concetto di asse: un asse definisce un insieme di nodi in relazione al nodo corrente.
Viene utilizzato un test di nodo per identificare un nodo attraverso un’asse. Un test di nodo può
essere effettuato sia per nome che per tipo. Ecco in Tabella 7-1 alcuni degli assi che abbiamo
utilizzato:
Nome dell’asse
Attribute
Child
descendant-or-self
Parent
Self
Tabella 7-1: assi principali di XPath
Descrizione
Contiene tutti gli attribute del nodo corrente
Contiene tutti i figli del nodo corrente
Contiene il nodo corrente più tutti I suoi discendenti (figli, nipoti, ecc.)
Contiene il padre del nodo corrente
Contiene il nodo corrente
Per velocizzare l’utilizzo degli assi si usano delle abbreviazioni che vediamo in Tabella 7-2:
Abbrev. Significato
nessuna child::
@
attribute::
Esempio
LINK è abbreviativo di child::LINK
LINK[@to="Act"] è abbreviativo di
child::LINK[attribute::to="Act"]
.
self::node()
.//LINK è abbreviativo di self::node()/descendant-orself::node()/child::cd
..
parent::node()
../LINK è abbreviativo di parent::node()/child::LINK
//
/descendant-or//LINK è abbreviativo di /descendant-orself::node()/
self::node()/child::LINK
Tabella 7-2: abbreviazioni degli assi utilizzati in XPath
Dopo aver dato una panoramica a XPath, si passa all’analisi degli elementi XSL utilizzati per la
realizzazione della trasformazione LTL. Di seguito riportiamo alcune delle più significative
istruzioni XSL:
•
<xsl:value-of>:
questo elemento può essere usato per selezionare il valore
di un elemento XML e aggiungerlo all’output della
trasformazione. Per esempio nel nostro codice:
<xsl:value-of select="@to"/>
Inserisce nel file di output che verrà visualizzato il valore
dell’attributo to dell’elemento analizzato in quel punto;
__________________________________________________________________________________________________________________________________________________________
Implementazione
94
__________________________________________________________________________________________________________________________________________________________
•
<xsl:for-each>:
può essere usato per selezionare ogni elemento XML di
uno specifico insieme di nodi. Riportiamone un esempio:
<xsl:for-each select="//START">
In questo caso dal for-each verranno selezionati tutti
quegli elementi che hanno come tag START;
•
<xsl:if>:
serve per effettuare un test condizionale sul contenuto del
file, per esempio:
<xsl:if test="starts-with(@to,'Act')">
Controlla che il valore dell’attributo to dell’elemento
attualmente selezionato inizi con il valore Act, se ciò
avviene allora il codice all’interno dell’if viene eseguito;
•
<xsl:choose>:
serve per inserire un test condizionale. Il suo utilizzo è
leggermente più complesso di quello dell’if, perché la
condizione favorevole e il relativo codice si inseriscono
utilizzando <xsl:when> mentre il codice da eseguire
se non si verifica la condizione espressa nel when si
inserisce all’interno di <xsl:otherwise> nel seguente
modo:
<xsl:choose>
<xsl:when test="position()=1"></xsl:when>
<xsl:otherwise> AND </xsl:otherwise>
</xsl:choose>
In questo esempio il when controlla che l’elemento
selezionato sia in prima posizione (ovvero il primo figlio),
se così non avviene viene eseguito il codice presente nel
blocco otherwise.
__________________________________________________________________________________________________________________________________________________________
Implementazione
95
__________________________________________________________________________________________________________________________________________________________
7.5.2 Alcuni esempi di codice
Vengono presentati di seguito alcune parti di codice per far comprendere il funzionamento della
trasformazione XSL che ci permette di visualizzare il risultato del workflow in LTL.
<xsl:for-each select="//START">
<xsl:choose>
<xsl:when test="position()=1"></xsl:when>
<xsl:otherwise> AND </xsl:otherwise>
</xsl:choose>
<xsl:for-each select="./LINK">
(<b> F </b>
<i><xsl:value-of select="@to"/></i>
<xsl:if test="starts-with(@to,'Act')">a</xsl:if>
 )
</xsl:for-each>
</xsl:for-each>
Questa prima parte ricerca gli elementi START e li trasforma in una funzione “F elem a” dove
elem è l’ID dell’elemento collegato allo START. La “a” finale viene messa solo se “elem = act”.
Nel caso vengano trovati più elementi START ai successivi viene aggiunto un AND prima di
scrivere la formula.
Quindi passiamo all’analisi di tutte le lane:
<xsl:for-each select="./LANE">
<xsl:variable name="laneid" select="@id"/>
Da questo punto fino alla chiusura del tag <xsl:for-each select="./LANE"> gli
elementi considerati saranno tutti quelli presenti nella lane. AND, OR e XOR sono tra loro simili,
per quanto riguarda il codice della trasformazione, per questo commenteremo solo alcune parti
del codice dell’AND.
<xsl:choose>
<xsl:when test="$numOfChild>1">

<xsl:for-each select="//LINK[@to=$andID]">

<xsl:if test="not(starts-with(parent::*/attribute::id,'Start'))">
 AND (<i><xsl:value-of select="parent::*/attribute::id"/></i>
<xsl:if test="starts-with(parent::*/attribute::id,'Act')"> c
</xsl:if>
<b> B ¬</b><i><xsl:value-of select="$andID"/> )</i>
</xsl:if>
 AND ( <i><xsl:value-of select="$andID"/></i><b> B ¬</b>(
</xsl:for-each>
…
__________________________________________________________________________________________________________________________________________________________
Implementazione
96
__________________________________________________________________________________________________________________________________________________________
Questa parte di codice è eseguita relativamente ad un gateway per riconoscere se è uno SPLIT
piuttosto che un MERGE. Il gateway è riconosciuto come SPLIT se il numero dei figli, che
possono essere solo di tipo LINK, è maggiore di uno ($numOfChild>1). Se è questo il caso,
viene in seguito ricercato il link entrante nel gateway, che può essere solo uno per definizione,
tramite la funzione XPath:
parent::*/attribute::id.
Questa funzione ritorna l’attributo id del nodo padre del LINK, cioè l’elemento da cui parte il
LINK che va a collegarsi al gateway.
7.6 Funzioni particolari (posizionamento frecce)
I Link tra gli oggetti presenti in un diagramma sono realizzati istanziando la classe
GFPolylineGO. Questo consente di generare una linea spezzata composta da un numero non
predefinito di segmenti. Le JKit/GO danno la possibilità di inserire all’inizio o al termine delle
linea alcuni oggetti predefiniti, come frecce, rombi o cerchi come si può vedere in questa Figura
7-5:
Figura 7-5: linee realizzabili con le JKit/GO
Tra queste, l’ultima rappresentata è quella che abbiamo adottato per collegare i GO, con
l’eccezione delle Data object. Adottando questa soluzione sono sorti diversi problemi legati al
posizionamento del punto a cui ancorare la linea sul GO di destinazione. Nella versione base
delle JKit/GO il collegamento tra il Link e un generico GO deve avvenire in punto prestabiliti
che contraddistinguono un GFHandle, definito tale punto non è più possibile muoverlo
dinamicamente. Solitamente viene scelto o un punto che si trova sul bordo (vedi Figura 7-2) o
al centro dello stesso.
__________________________________________________________________________________________________________________________________________________________
Implementazione
97
__________________________________________________________________________________________________________________________________________________________
Entrambe le soluzioni presentano diversi problemi come si vede nella seguente Figura:
Figura 7-6: collegamento sul bordo e al centro dei GO
Nel primo caso la freccia è collegata correttamente sul bordo ma perde l’esatto orientamento
verso il centro dell’oggetto quando questi viene spostato, nel secondo caso invece
l’orientamento è corretto ma l’ancoraggio della freccia sul GO non risulta esatta, visto che
inoltre va a coprire il GO. Per ovviare a questi inconvenienti, la soluzione è quella di usare
come punto di ancoraggio il centro dei GO, siano essi rettangoli o cerchi, definendo
contestualmente una diversa politica di posizionamento delle frecce in funzione della forma del
GO, così che risultino sempre posizionate sul bordo. È infatti possibile svincolare il punto di
ancoraggio della linea, dal posizionamento della freccia.
Stabilito a quale oggetto la linea viene collegata, si determinano i punti di posizionamento della
freccia, di seguito riportiamo il codice generato per la realizzazione di queste funzionalità
(Figura 7-7):
1 GFPolylineGO aGO = new GFPolylineGO(initialPoint, endPoint);
2 aGO.setLineColor(Color.black);
3 aGO.setLineEnd(GFLineEnd.END_POINT,GFGOLineEnd.newArrow(8,16,black,1));
4 …
5 GFGOLineEnd arrow = (GFGOLineEnd) aGO.getLineEnd(GFLineEnd.END_POINT);
6 …
7 if(node.getID().toString().startsWith("Act")){
8
…
9
policy = newArrowToActivityEdgeLineEndPolicy(ActGO());
10
arrow.setLineEndPolicy(policy);}
11 if(node.getID().toString().startsWith("End")){
12
policy = new ArrowToDiamondLineEndPolicy(EndGO());
13
arrow.setLineEndPolicy(policy);}
__________________________________________________________________________________________________________________________________________________________
Figura 7-7: calcolo della posizione della freccia
Implementazione
98
__________________________________________________________________________________________________________________________________________________________
Nelle righe di codice 1, 2 e 3 viene creato l’oggetto che rappresenta il Link, inserendo una
freccia al termine della linea. Alla riga 5 si ottiene dalla line la freccia che vi è attaccata. Alle
righe 7 e 11 si verifica rispettivamente,se l’oggetto di arrivo della linea, sia o una Activity o una
End. Nel primo caso la forma grafica dell’oggetto sarà un rettangolo con gli spigoli arrotondati,
nel secondo sarà un cerchio.
Alla riga 9 si istanzia la classe ArrowToActivityEdgeLineEndPolicy passando come parametro il
GO che sappiamo essere un rettangolo, tale classe viene richiamata a run-time ogni qual volta il
GO viene spostato.Questo serve a ricalcolare il punto del bordo dove la freccia va collocata,
alla riga 10 viene associata tale politica alla freccia. Medesimo discorso viene fatto alle righe 12
e 13 dove la forma del GO non è più un rettangolo ma bensì un cerchio, in questo caso il
calcolo della posizione viene comunque fatta ma non comporta la stessa difficoltà di calcolo,
dato che i punti sono calcolati in coordinate polari. Analizziamo in dettaglio la classe
ArrowToActivityEdgeLineEndPolicy:
public class ArrowToActivityEdgeLineEndPolicy extends GFArrowLineEndPolicy{
private GFGO graphNodeRenderer;
public GFGOLineEndPolicy copyForLineEnd ()
{
return copyForLineEndInto(new ArrowToActivityEdgeLineEndPolicy(graphNodeRenderer));
}
1 public GF2DGO computeDisplayedGO (GF2DGO aGO)
2 {
3
GF2DGO displayedGO = (GF2DGO) aGO.copyForCreation();
4
displayedGO.rotate(getTangentialTheta(), 0, 0);
5
6
int endPointIndex = getLineEnd().getPointIndex();
7
int orientationPointIndex = endPointIndex > 0 ? endPointIndex-1 : 1 ;
8
GF2DVector vector = new GF2DVector(getLineEnd().getPoint(),
getLineEnd().getLine().getPoint(orientationPointIndex));
9
GF2DVector resultVect = vector.liangBarskyClipTo(graphNodeRenderer.displayBox());
10
11
setLineEndAttachment(resultVect.p2);
12
displayedGO.translate(resultVect.p2);
13
14
15
return displayedGO;
16 }
public ArrowToActivityEdgeLineEndPolicy(GFGO gnR){
super();
graphNodeRenderer = gnR;
}
}
Figura 7-8: codice della classe ArrowToActtivityEdgeLineEndPolicy
__________________________________________________________________________________________________________________________________________________________
Implementazione
99
__________________________________________________________________________________________________________________________________________________________
Questa routine ha un parametro in ingresso che è il GO a cui la linea viene collegata. Ogni volta
che il GO è spostato nel disegno la routine viene richiamata. Lavorando su una copia della linea
è in grado di ritornare la posizione e l’orientamento che la freccia deve assumere. Le righe di
codici che compiono questa funzione vanno dalla 3 alla 15. Alla riga 4 la copia della freccia è
ruotare di una quantità pari all’inclinazione della linea stessa a cui è associata, in modo che
risulti orientata correttamente. Nelle righe dalla 6 alla 9 si determina sia l’ultimo che il
penultimo punto della linea (dato che la linea può essere un insieme di spezzate), ottenendo un
vettore di punti sul quale è calcolata la funzione Liang-Barsky che, dato il GO e la linea,
determina il punto di intersezione tra le due. Avendo il punto la freccia viene spostata in tale
posizione, come riportato alla riga 13 . La routine ArrowToActivityEdgeLineEndPolicy è del
tutto simile avendo come parametro gli oggetti di riferimento un cerchio.
__________________________________________________________________________________________________________________________________________________________
Conclusioni e sviluppi futuri
100
__________________________________________________________________________________________________________________________________________________________
8
Il lavoro di tesi, che si è completato con la realizzazione del tool grafico, ha rischiesto lo studio
e l'analisi di argomenti provenienti da ambiti tra loro diversi: la verifica formale di applicazioni
web, i diagrammi di workflow, le notazioni grafiche per la rappresentazione dei diagrammi
stessi, i linguaggi formali come Linear Temporal Logic (LTL), le librerie grafiche JKit/GO, il
meta-linguaggio XML e le trasformazioni XSL.
Lo studio sulla validazione formale rientra in un più ampio progetto svolto in collaborazione
con l’Università di San Diego nel quale si mira a generare delle applicazioni web robuste e ben
strutturate. L’obiettivo è quello di specificare le caratteristiche delle applicazioni web in
funzione degli input dati dall’utente, dello stato dell’applicazione e delle informazioni presenti
nel suo database. Per fare questo viene consentito agli sviluppatori di specificare le proprietà
che le applicazioni web devono soddisfare verificandone staticamente la correttezza nella fase
di design.
Il lavoro relativo alla realizzazione del tool è stato completato coprendo la rappresentazione
degli elementi base della notazione LTL che già permettono la verifica formale di numerose
applicazioni web. La progettazione del software è stata però effettuata in modo da consentire lo
sviluppo di un’estensione per sfruttare completamente il potere espressivo di LTL come
specificato nell’articolo [5].
Sin dall’inizio della progettazione l’intento è stato quello di generare un applicativo modulare
non limitato alla sola fase di verifica. Per questo il progetto è stato suddiviso in due parti ben
distinte: la prima consiste in un’interfaccia grafica per la modellizzazione delle applicazioni; la
seconda è la trasformazione che consente di passare dal diagramma a formule di logica
temporale.
Strutturando il progetto in questo modo si lasciano aperti numerosi scenari d’impiego. Difatti i
diagrammi di workflow disegnati sono salvati nel formato standard XML dal quale, tramite
apposite trasformazioni, è possibile ottenere svariati tipi di output. La flessibilità del tool è
garantita da una serie di file di configurazione attraverso i quali è possibile sia personalizzare i
diagrammi di workflow, definendo arbitrariamente gli attributi degli elementi, sia aggiungere
nuove trasformazioni che possono essere integrate senza dover modificare in alcun modo il
software.
__________________________________________________________________________________________________________________________________________________________
101
__________________________________________________________________________________________________________________________________________________________
Grazie a questa caratteristica il tool trova un impiego anche nella generazione di modelli di
ipertesto basati sullo standard WebML. Lo scopo è quello di generare del codice compatibile
con il tool CASE (Computer Aided Software Engineering) WebRatio [24].
In particolare, uno dei possibili sviluppi è quello di ottenere, tramite una trasformazione, un
primo modello dell’ipertesto realizzato con WebRatio partendo dai diagrammi di workflow
definiti con il tool. A tale scopo sono stati introdotti degli elementi specifici per questo utilizzo,
sebbene non utilizzati nella fase di verifica formale.
Inoltre il software è predisposto per supportare diagrammi di workflow multilivello. Questa
caratteristica, presente nella notazione BPMN, si rivela di particolare utilità per dare una
definizione più dettagliata di un’attività. Sfruttando tale potenzialità si potrebbe realizzare,
come sviluppo futuro, anche un livello “finale” nel quale inserire direttamente pagine web in
JSP e unit per automatizzare il passaggio dei dati.
__________________________________________________________________________________________________________________________________________________________
Bibliografia
102
__________________________________________________________________________________________________________________________________________________________
Appendice A:
Bibliografia
[1]
Paolo Atzeni, Giansalvatore Mecca, Paolo Merialdo, Design and Maintenance of DataIntensive Web Sites. EDBT 1998: 436-450
[2]
BPMI, Business Process Modeling Language, November 13, 2002 edited by Michael
Dailey
[3]
BPMI, Business Process Modeling Notation, Version 1.0, May 3, 2004 edited by
Stephen A. White, IBM Corporation
[4]
Stefano Ceri, Piero Fraternali, Aldo Bongio, Marco Brambilla, Sara Comai, Maristella
Matera, Designing Data-Intensive Web Applications, Morgan-Kaufmann, December
2002
[5]
A.Deutsch, L.Sui, V.Vianu, Specification and Verification of Data-Driven Web
Services, University of California San Diego, Computer Site and Engineering, 2004
[6]
Gerard J. Holzmann, Design and Validation of Computer Protocols, Prantice Hall, 1991
[7]
Yongjie Ren, Kam-Fai, Wong, Boon Toh Low, An Integrated Approach for Flexible
Workflow Modeling. ICSC 1999
[8]
W.M.P. van der Aalst, A.H.M. ter Hofstede, B. Kiepuszewski and A.P. Barros,
Workflow Patterns
[9]
W.M.P. van der Aalst and A.H.M. ter Hofstede, YAWL: Yet Another Workflow
Language, FIT Technical Report, June 2002
[10]
Workflow Management Coalition, Terminology & Glossary, Issue 3.0, February 1999,
Winchester (UK). Questo documento può essere trovato all’indirizzo web:
http://www.wfmc.org/standards/docs/TC-1011_term_glossary_v3.pdf
[11]
Stefan Jablonski, Christoph Bussler, Workflow Management: Modeling Concepts,
Architecture and Implementation
__________________________________________________________________________________________________________________________________________________________
Bibliografia
103
__________________________________________________________________________________________________________________________________________________________
[12]
Bea WebLogic Workshop website:
www.bea.com/framework.jsp?CNT=index.htm&FP=/content/products/workshop/
[13]
BPWS4J website: http://alphaworks.ibm.com/tech/bpws4j
[14]
BPMI e BPMN website: http://www.bpmi.org e http://www.bpmn.org
[15]
Collaxa website: http://www.collaxa.com
[16]
Intalio website: http://www.intalio.com
[17]
Linear Temporal Logic UCSD project: http://www.cs.ucsd.edu/~lsui/project/index.html
[18]
Metamill website: http://www.metamill.com
[19]
Popkin website relativo all’ultima versione del tool (la 10.0):
www.popkin.com/products/system_architect/system_architect_v10_new_features.htm
[20]
Struts website: http://struts.apache.org
[21]
UML website: http://www.uml.org
[22]
W3Schools website: http://www.w3schools.com
[23]
Web Modelling Language web site: http://www.webml.org
[24]
WebRatio website: http://www.webratio.com
[25]
Workflow Management Coalition website: http://www.wfmc.org
[26]
Workflow pattern website di Wil van der Aalst:
http://tmitwww.tm.tue.nl/research/patterns/patterns.htm
[27]
WSCI website: http://www.w3.org/TR/wsci
[28]
WSFL website: www-306.ibm.com/software/solutions/webservices/pdf/WSFL.pdf
[29]
XLang website: http://www.gotdotnet.com/team/xml_wsspecs/xlang-c/default.htm
__________________________________________________________________________________________________________________________________________________________

Indice - Politecnico di Milano

Transcript

Documenti analoghi

Carteo Caratteristiche

Workflow della Ricerca 2.0

Esercitazione Pianificazione di un progetto software..

CASE STUDY Program Management

CURRICULUM VITAE Ai sensi della Legge 675/96

Acquisti - ARXivar

La gestione degli adempimenti fiscali del dipendente

la gestione informatizzata dell`organizzazione - Tsiouras

Tecnologia - Antica Bottega Digitale srl