Generazione Automatic A Di Applicazioni Web

POLITECNICO DI MILANO
Facoltà di Ingegneria dell’Informazione
POLO REGIONALE DI COMO

Corso di Laurea Specialistica in Ingegneria Informatica
Generazione automatica di applicazioni web

a partire da modelli di processo estesi
Relatore: Ing. Marco BRAMBILLA

Correlatore: Prof. Luigi CASALEGNO
Tesi di Laurea di:
Francesco MAGNI
Matricola n. 711327
Anno Accademico 2007/2008

POLITECNICO DI MILANO
Facoltà di Ingegneria dell’Informazione
POLO REGIONALE DI COMO

Master of Science in Computer Engineering
Automatic generation of web applications

from extended business process models
Supervisor: Ing. Marco BRAMBILLA

Assistant Supervisor: Prof. Luigi CASALEGNO
Master Graduation Thesis by:
Francesco MAGNI
Student Id n. 711327
Academic Year 2007/2008

Abstract
This work deals with the complete generation of web applications from
extended process models.
The purpose is to provide some tools which can support the development
of the application in all its phases, from the requirements specification to the
design and the final deployment.
The proposed method is based on a model-to-model trasformation; this
mechanism starts from the business process model and produces a simplified
web application model. Workflow diagrams are represented using the BPMN
notation. This notation has been extended with a new property, called
typization, in order to specify the action type of activities. This new feature
brings to a more precise definition of application models.
In addition, this work deals with the problem of the process status control;
a workflow control panel has been designed and implemented in order to
monitor the system status.
The result of this master thesis is an automatic method for generating
model-driven web applications, based on BPMN diagrams. Some special
WebML components set the hypertext model free from process management
tasks; for this reason the model obtained is more readable and easier to
mantain. The generated web applications are based on workflow constraits,
and allow users to execute the activities and monitor the system status.
i
Sommario
Questo lavoro di tesi si occupa della generazione completa di applicazioni

web a partire da modelli di processo estesi.
Lo scopo è quello di fornire degli strumenti in grado supportare tutte le
fasi di sviluppo dell’applicazione, dalla specifica dei requisiti di business alla
progettazione e alla messa in funzione dell’applicazione stessa.
Il metodo proposto si basa su un meccanismo di trasformazione di mo-
delli che ha come punto di partenza il modello di processo aziendale e come
risultato un modello semplificato dell’applicazione web basata sul proces-
so. Per rappresentare i diagrammi di workflow è stata utilizzata la notazione
BPMN. Questa è stata estesa con una nuova proprietà, chiamata tipizzazione,
che permette di specificare per ogni attività la tipologia di azione da svolgere.
Ciò consente una generazione più precisa del modello dell’applicazione.
Inoltre, questa tesi affronta la problematica relativa al controllo dello stato
dei processi aziendali; è stato quindi progettato un cruscotto di controllo
processi in grado di monitorare lo stato del sistema.
Il presente lavoro ha come risultato un metodo di generazione automatica
di applicazioni web, basate sui requisiti imposti dal workflow, a partire da
diagrammi BPMN. Il modello di applicazione dal quale viene generato il
codice delega le funzioni di gestione degli elementi processuali ad apposite
componenti, risultando cosı̀ più leggibile e mantenibile. L’applicazione creata
rispetta i vincoli imposti dal flusso di lavoro e permette agli attori del processo
di svolgere le attività e di controllare lo stato del sistema.
ii
Ringraziamenti
Vorrei innanzitutto ringraziare il Prof. Luigi Casalegno per avermi pro-

posto e per aver reso possibile questo lavoro di tesi.
Un grazie particolare va all’Ing. Marco Brambilla, per avermi seguito
in tutte le fasi del lavoro, per avermi sempre indicato la strada migliore da
seguire e per avermi continuamente supportato con consigli e suggerimenti
in tutti questi mesi.
Inoltre vorrei ringraziare il team di WebRatio per l’assistenza che mi ha
sempre offerto, con gentilezza e professionalità, nella messa in pratica de-
gli argomenti trattati. In particolare, un grosso grazie va ad Aldo Bongio
e Sebastian Anzani che, oltre ad avermi sempre aiutato a trovare una solu-
zione ai problemi che ho incontrato, mi hanno anche guidato nell’impostare
l’implementazione in modo strutturato ed ingegneristico.
Un ringraziamento speciale è per la mia famiglia, che mi ha appoggiato
sia economicamente che moralmente durante questi anni di studi, e per tutti
gli amici con cui ho condiviso i momenti belli e che mi hanno supportato (e
sopportato) in quelli brutti.
iii
Indice
1 Introduzione 1
2 Background 4
2.1 Workflow e BPMN . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Eclipse BPMN Modeler . . . . . . . . . . . . . . . . . 8
2.2 WebML e WebRatio . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1 BPMN Modeler in WebRatio . . . . . . . . . . . . . . 13
2.3 Tecnologie di trasformazione . . . . . . . . . . . . . . . . . . . 15
3 Da BPMN a WebML 18
3.1 Trasformazione da BPMN a WebML . . . . . . . . . . . . . . 22
3.1.1 Specifica dei requisiti . . . . . . . . . . . . . . . . . . . 22
3.1.2 Progettazione . . . . . . . . . . . . . . . . . . . . . . . 24
3.2 Tipizzazione delle attività . . . . . . . . . . . . . . . . . . . . 35
3.2.2 Progettazione . . . . . . . . . . . . . . . . . . . . . . . 38
3.3 Cruscotto di controllo processi . . . . . . . . . . . . . . . . . . 43
3.3.2 Progettazione . . . . . . . . . . . . . . . . . . . . . . . 45
4 Implementazione 55
4.1 Trasformazione da BPMN a WebML . . . . . . . . . . . . . . 56
4.2 Tipizzazione nel BPMN Modeler . . . . . . . . . . . . . . . . . 57
4.3 Tipizzazione in WebRatio . . . . . . . . . . . . . . . . . . . . 60
iv
INDICE v
4.4 Cruscotto di controllo processi . . . . . . . . . . . . . . . . . . 62

4.5 Dal modello WebML al codice applicativo . . . . . . . . . . . 66
5 Caso di studio 68
5.1 Generazione dello scheletro dell’applicazione . . . . . . . . . . 69
5.2 Generazione basata su tipizzazione delle attività . . . . . . . . 72
5.3 Raffinamento del modello . . . . . . . . . . . . . . . . . . . . 74
5.4 Salvataggio e riuso dei nuovi tipi . . . . . . . . . . . . . . . . 76
6 Lavori correlati 78
7 Conclusioni e sviluppi futuri 82
Bibliografia 84
Capitolo 1
Introduzione
Le applicazioni web, con il passare degli anni, stanno assumendo un ruo-

lo sempre più importante come supporto al mondo del lavoro, anche al di
fuori del settore dell’informatica. Ormai sono all’ordine del giorno processi
aziendali che coinvolgono un numero elevato di attori dislocati in diverse se-
di, sempre più spesso situate in diverse città o addirittura in diversi paesi.
La necessità di avere degli strumenti che consentano di fornire un adeguato
sostegno nella gestione di tali processi porta inevitabilmente all’esplorazione
del terreno ad oggi più fertile nell’ambito della distribuzione di applicazioni:
il web.
Fino a pochi anni fa tutte le applicazioni B2B (business-to-business, ov-
vero rivolte all’uso aziendale) si basavano sulle onerose architetture client-
server: su ogni postazione utente doveva essere installato un software neces-
sario per l’interazione con il sistema. In questo modo qualsiasi modifica dello
stesso, in particolare del lato server, costringeva le aziende a sostenere ele-
vati costi (sia in termini economici che temporali) per mantenere aggiornate
anche le postazioni client. L’arrivo delle applicazioni web rappresenta una
svolta nello sviluppo di software orientato al business. Infatti, attraverso di
esse le aziende possono ottenere dei sistemi integrati, distribuiti, facilmente
mantenibili ed aggiornabili a costi sensibilmente ridotti. Per questo, anche
nell’ambito della gestione dei processi, si tende a sfruttare le potenzialità
1
CAPITOLO 1. INTRODUZIONE 2
delle applicazioni web.

Nel contesto dei processi aziendali, è sempre più frequente la necessità
di supportare la gestione del workflow con degli strumenti in grado di coor-
dinare tutti gli aspetti ad essa relativi. E’ dunque necessario estendere le
tradizionali applicazioni web con nuove funzionalità in grado di integrare gli
elementi del flusso di lavoro con quelli classici relativi al modello dei dati,
alla navigazione ed alla presentazione. Questa problematica è ovviamente da
affrontare in modo esauriente e con un approccio ingegneristico, quindi è im-
portante partire dalla specifica dei requisiti per arrivare poi alla progettazione
e all’implementazione di questi nuovi strumenti.
Questo lavoro di tesi si propone di analizzare tutto il processo di creazione
di un’applicazione web basata sul flusso di lavoro. Si affrontano gli aspetti
legati alle modalità di rappresentazione dei processi aziendali, utilizzando la
notazione BPMN (Business Process Management Notation) e l’integrazione
di questi con il mondo della modellazione di applicazioni web.
In particolare, viene proposta una soluzione che consente di ottenere in
modo rapido e funzionale un’applicazione in grado di gestire e monitorare
il processo su cui si basa, trasformando il diagramma BPMN in un modello
applicativo. Questa trasformazione permette di definire un parallelismo tra
i diagrammi che definiscono il workflow ed i modelli di applicazione web
che li rappresentano. Il linguaggio di modellazione utilizzato è WebML. Si
introducono inoltre aspetti paralleli alla semplice trasformazione, come la
generazione automatica di contenuti all’interno del modello e la progettazione
di strumenti di controllo del flusso di lavoro. Lo studio viene poi sperimentato
in pratica attraverso lo strumento CASE WebRatio, grazie al quale è possibile
generare il codice applicativo finale dell’applicazione in modo immediato.
Nel capitolo 2 si introducono i concetti su cui si basa il lavoro. Si
parte dalla definizione di workflow, per poi descrivere in che modo esso viene
rappresentato e quali strumenti esistono a supporto della modellazione dei
processi aziendali.
Il capitolo 3 contiene la parte principale del lavoro: la definizione del
CAPITOLO 1. INTRODUZIONE 3
processo di trasformazione da un modello di business ad un modello di ap-

plicazione web. Inoltre vengono trattati nel dettaglio gli aspetti riguardanti
la tipizzazione, nuova funzionalità introdotta per semplificare l’inserimento
dei contenuti all’interno del modello. Infine si descrivono le specifiche e gli
aspetti progettuali del cruscotto di controllo processi, particolare strumento
nato da esigenze quali il controllo dello stato dei processi e l’analisi statistica.
Nel capitolo 4 si affrontano gli aspetti implementativi delle problemati-
che introdotte; si descrive in termini più tecnici come avviene la trasforma-
zione, si spiega come si inserisce al suo interno la tipizzazione e si illustra
come viene realizzato il cruscotto.
Il capitolo 5 tratta invece un’applicazione reale della trasformazione e
degli aspetti ad essa correlati; partendo da un diagramma BPMN vengono
esaminati e descritti tutti i passaggi per arrivare all’applicazione web finale.
Nel capitolo 6 vengono citati alcuni lavori che trattano le stesse proble-
matiche affrontate in questa tesi.
Per concludere, il capitolo 7 contiene le conclusioni a cui si è giun-
ti al termine di questo lavoro e quali sono le possibili strade per poterlo
sviluppare.
Capitolo 2
Background
Lo scenario di questo lavoro di tesi è collocato a metà strada tra la gestione

di processi business e il design di applicazioni web.
E’ dunque necessario delineare le principali caratteristiche degli standard,
degli ambienti di sviluppo e delle tecnologie che sono coinvolte nel processo di
trasformazione. Si parte dal concetto di workflow (flusso di lavoro) e dalla sua
rappresentazione grafica più usata, ovvero i diagrammi BPMN, per arrivare
ad ambiti strettamente legati alla progettazione di applicazioni web, come
l’ambiente di sviluppo WebRatio e il linguaggio di modellazione WebML.
Vi sono inoltre nuovi sviluppi che creano dei punti di intersezione tra
questi settori apparentemente distanti; in particolare la ricerca attuale si
sta concentrando sull’integrazione dei già disponibili editor BPMN con gli
ambienti di design di applicazioni web. In questo modo, nell’ambito delle
applicazioni web basate sul flusso di lavoro, si ottiene una perfetta dualità
tra modello di business e modello WebML.
In questo capitolo si fornisce una breve descrizione delle tematiche che
sono alla base del presente lavoro.
4
CAPITOLO 2. BACKGROUND 5
2.1 Workflow e BPMN

Il workflow, o flusso di lavoro, è un concetto che nasce nell’ambito della
gestione dei processi aziendali. Esso indica la sequenza di operazioni che
vanno effettuate per il completamento di un determinato processo. Inoltre
definisce quali sono gli attori che si occupano di effettuare tali attività. I
concetti principali su cui si basa, secondo le specifiche del WFMC (Workflow
Management Coalition [31]), sono i seguenti:
• processo: astrazione del lavoro che deve essere eseguito; insieme di tutte
le operazioni da svolgere e delle informazioni sull’ordine in cui vanno
effettuate;
• case: istanza di un processo, ovvero esecuzione reale del flusso di lavoro

contenuto in un processo;
• attività: indica l’unità di lavoro che deve essere eseguita; l’insieme delle
attività e dei collegamenti tra loro vanno a costituire il processo;
• istanza di attività: come il case per il processo, indica una particolare

esecuzione di un’attività. Diversamente dall’attività, che è un concetto
astratto, l’istanza di attività è concreta, ha un inizio e una fine e viene
eseguita da un attore specifico;
• vincolo: i vincoli servono ad indicare i criteri attraverso i quali vengono

gestite le varie possibilità offerte dal workflow; è in base ai vincoli che
viene gestita la reale esecuzione di un processo;
• attore: entità che si occupa di svolgere il lavoro; non è necessariamente

un essere umano, può anche essere un sistema informatico se ad esempio
l’attività da eseguire è di tipo automatico.
Modelli di workflow
Esistono diversi modelli in grado di descrivere il flusso di lavoro in modo
rigoroso; i più usati sono UML, XPDL e BPMN.
UML, Unified Modeling Language [22], è un linguaggio di notazione de-

rivante dall’approccio ad oggetti verso la progettazione. Esso offre due tipi
di diagrammi per la descrizione del workflow: gli use case e gli activity dia-
gram. Questi sono tuttavia basati sulla funzione ed il comportamento degli
oggetti, e le loro potenzialità trovano spazio nel supporto del ciclo di vita del
software.
XPDL [32] è invece una notazione basata sui grafi1 . Le attività sono
rappresentate come i nodi del grafo, mentre gli archi rappresentano i passag-
gi da un’attività ad un’altra. Queste transizioni possono essere soggette a
condizioni.
Il riferimento per il presente lavoro è tuttavia la notazione BPMN.
Business Process Management Notation

La notazione BPMN [20] è stata ideata dal BPMI (Business Process Ma-
nagement Initiative [3]) e viene attualmente sviluppata dall’OMG (Object
Management Group [21]).
Il motivo principale per cui è stata creata è quello di permettere a diversi
tipi di utente, dall’analista allo sviluppatore, dal progettista al responsabile
del controllo di un processo, di utilizzare un’unica notazione, immediata e di
facile comprensione.
Gli elementi principali di un diagramma BPMN sono rappresentati in figu-
ra 2.1. Di seguito vengono elencati e descritti i principali elementi considerati
nella presente tesi2 :
• forme di base (basic BPMN shapes):
– pool: è l’ambiente all’interno del quale si sviluppa il processo;

solitamente il nome del pool corrisponde a quello del processo;
1
Un grafo è un insieme di elementi detti nodi o vertici collegati fra loro da archi o lati.
2
Alcuni degli elementi in figura 2.1 non sono rilevanti ai fini della trattazione e non
verranno analizzati.
Figura 2.1: I principali elementi dei diagrammi BPMN
– lane: è una suddivisione del pool in sotto-categorie; serve a speci-

ficare quale parte dell’azienda (ad esempio ufficio commerciale o
ufficio amministrazione) o quale ruolo (come ad esempio cliente e
venditore) è incaricato di svolgere le attività;
– attività (task): l’attività rappresenta una delle operazioni da com-
piere all’interno del processo; se l’attività non è atomica può essere
rappresentata come sotto-processo (sub-process);
– connettore di flusso (flow connector): freccia necessaria per indi-
care i rapporti di consequenzialità tra le attività e tra attività e
gateway (trattati successivamente);
• eventi (events):
– start: rappresenta l’inizio del processo; è posto nella lane corri-

spondente all’attore che avvia le operazioni;
– end: rappresenta la fine del processo; analogamente all’evento
di tipo start viene collocato all’interno della lane corrispondente
all’attore che esegue l’ultima operazione;
• gateway3 (gateway shapes):
– AND (parallel): le attività contenute tra due gateway di tipo AND

devono essere tutte eseguite; in caso contrario il workflow non può
proseguire;
– OR (exclusive): deve essere eseguita almeno un’attività tra quelle
presenti tra due gateway OR; è sufficiente il completamento di
un’attività per poter passare all’attività successiva al gateway.
2.1.1 Eclipse BPMN Modeler

Una particolare menzione merita il tool per la creazione di diagrammi
BPMN sviluppato per l’ambiente Eclipse [11].
Attraverso questo tool (di cui si può vedere uno screenshot in figura 2.2) è
possibile modellare i diagrammi BPMN che rappresentano il flusso di lavoro.
Questo strumento è dotato di caratteristiche di estensibilità e integrabilità
con altre piattaforme. Il tool rappresenta la base dell’integrazione dei dia-
grammi BPMN con le applicazioni web. Nel paragrafo 2.2.1 verrà descritto
più dettagliatamente come l’Eclipse BPMN Modeler viene utilizzato come
punto di partenza della trasformazione all’interno dell’ambiente di sviluppo
WebRatio.
3
Un gateway è un elemento che consente di controllare il workflow, ovvero come e
quando il processo si suddivide e si ricongiunge.
Figura 2.2: L’ambiente di sviluppo Eclipse e il BPMN Modeler
2.2 WebML e WebRatio

Il linguaggio di modellazione WebML [28] fornisce una rappresentazione
formale e chiara per il design di applicazioni basate sul web. Gli obiettivi
principali che si pone il design basato su tale linguaggio sono i seguenti:
• esprimere la struttura di un’applicazione web con una descrizione di

alto livello;
• fornire più viste diverse per gli stessi contenuti;
• separare il contenuto informativo dalla sua composizione in pagine e da-

gli aspetti di navigazione e presentazione, i quali possono essere definiti
e sviluppati autonomamente;
• salvare le meta-informazioni raccolte durante il processo di design in

un repository 4 , che può essere usato durante la vita dell’applicazione

per generare dinamicamente la pagine web;
• modellare utenti e gruppi di utenti esplicitamente nel repository, per

permettere di specificare regole di accesso personalizzate alle varie parti
dell’applicazione;
• consentire la specifica delle operazioni di manipolazione dei dati per

aggiornare il contenuto dell’applicazione o interagire con servizi esterni.
Gli elementi principali di un modello WebML sono tre: il modello dei

dati (data model ), il modello dell’ipertesto (hypertext model ) e il modello di
presentazione (presentation model ).
Il modello dei dati è un adattamento dei modelli concettuali per il design
delle strutture di dati, come quelli usati nell’ingegneria del software. E’ com-
patibile con il modello Entità-Relazione [34] e con il diagramma delle classi
UML, usato nella modellazione orientata agli oggetti. Gli elementi fondamen-
tali dei modelli dei dati sono le entità, ovvero i contenitori degli elementi dei
dati, e le relazioni, definite come connessioni semantiche tra entità. Le entità
hanno delle proprietà dotate di nome e tipo, chiamate attributi. Le entità
possono essere organizzate in gerarchie e le relazioni possono essere regolate
da vincoli di cardinalità. Le entità sono identificate attraverso un attributo
chiave univoco, chiamato OID (Object IDentifier ). Tale chiave rappresenta
un concetto astratto, implementabile in modi diversi a seconda dell’effettiva
architettura del database su cui i dati vengono archiviati. In figura 2.3 un
semplice esempio di data model.
Il modello dell’ipertesto specifica la composizione e la navigazione dell’ap-
plicazione web. La composizione descrive quali pagine costituiscono l’iperte-
sto, e quali informazioni contengono le pagine. Le pagine di un sito sono i
4
Un repository (che può essere italianizzato con il termine reposito) è un ambiente di
un sistema informativo in cui vengono gestiti i metadati, attraverso tabelle relazionali;
l’insieme di tabelle, regole e motori di calcolo tramite cui si gestiscono i metadati prende
il nome di metabase [35].
Figura 2.3: Esempio di modello dei dati in WebML
contenitori dei dati che vengono offerti all’utilizzatore. Le unit sono dei con-
tenitori atomici di informazioni, utilizzati per pubblicare i dati descritti nel
data model. Esistono sette tipi predefiniti di unit in WebML: Data, Multi-
Data, Index (con le sue varianti Multichoice e Hierarchical), Entry e Scroller.
Ogni unit è associata ad un’entità sottostante, dalla quale viene prelevato il
contenuto informativo. In alcuni casi è utile associare alla unit un selettore,
per specificare quali istanze delle entità devono essere considerate. La navi-
gazione del sito è specificata attraverso i collegamenti. Questi possono essere
definiti tra le unit interne ad una singola pagina, tra unit posizionate in pa-
gine diverse e tra le pagine stesse. Le informazioni trasportate attraverso un
link sono chiamate contesto di navigazione, o più semplicemente contesto. I
collegamenti che trasportano il contesto sono chiamati contestuali, gli altri
non contestuali. In figura 2.4 un esempio di specifica di un ipertesto.
Il modello di presentazione è necessario per definire l’aspetto delle pagine.
WebML non include un modello specifico per esprimere la presentazione a
livello concettuale, ma utilizza approcci standard, più familiari agli esper-
ti di grafica e comunicazione. Dato che le specifiche WebML possono essere
rappresentate usando XML [27], la presentazione è considerata come una tra-
sformazione di un documento WebML in una pagina scritta con un linguaggio
di implementazione concreto, come JSP o ASP.NET. Di conseguenza, la pre-
sentazione in WebML è gestita applicando dei fogli di stile XSL alle pagine,
alle unit e ai sotto-elementi di queste. I fogli di stile XSL hanno come input le
Figura 2.4: Esempio di modello di ipertesto in WebML
specifiche WebML codificate come documenti XML e come output le pagine

costruite.
Il linguaggio WebML è accompagnato da un CASE tool5 , WebRatio
[29], in grado di generare in modo automatico applicazioni web funzionanti
partendo da diagrammi WebML.
In figura 2.5 è rappresentata la logica di generazione di un’applicazione
web tramite WebRatio. Per prima cosa è necessario progettare i tre mo-
delli WebML precedentemente citati, ovvero quello dei dati, quello dell’iper-
testo (qui chiamato modello logico) e quello di presentazione. Dopo aver
definito i modelli, WebRatio è in grado di generare automaticamente tutta
l’applicazione web con un click:
• a partire dal modello dei dati viene generato il database fisico. Vice-
versa è anche possibile connettersi ad un database già esistente e rico-
struire automaticamente il corrispondente modello dei dati. E’ possibile
definire più di un database fisico per la propria applicazione;
5
Gli strumenti CASE (Computer-Aided Software Engineering, ovvero ingegneria del
software assistita dal computer) sono particolari programmi che supportano lo sviluppo
del software attraverso interfacce grafiche e librerie di funzionalità.
• a partire dal modello logico (dell’ipertesto) vengono generate tutte le

classi Java e i file di configurazione necessari per lo svolgimento del-
le funzioni dell’applicazione: lettura e scrittura di dati, transazioni,
procedure, notifiche, calcoli, ecc.;
• a partire dal modello di presentazione vengono generate tutte le pagine

dinamiche JSP che producono l’interfaccia desiderata secondo i più
diffusi standard: HTML, CSS, Flash, AJAX.
Il codice generato da WebRatio è completamente personalizzabile. Le

personalizzazioni non avvengono sul codice generato ma sulle regole di ge-
nerazione. WebRatio è un ambiente di sviluppo aperto, dove l’utente può
definire i propri componenti e le proprie regole di generazione.
WebRatio è in grado di gestire un’applicazione in tutte le fasi del suo
ciclo di vita: dalla produzione del primo prototipo, al rilascio in produzione,
alla manutenzione correttiva ed evolutiva.
Figura 2.5: Il funzionamento di WebRatio
2.2.1 BPMN Modeler in WebRatio

Il modellatore BPMN citato nel paragrafo 2.1.1 è stato integrato nella
piattaforma WebRatio al fine di poter gestire da un unico ambiente di svi-
luppo tutte le fasi della generazione dell’applicazione basata su workflow. In

figura 2.6 uno screenshot del modellatore. Si può notare come il pannello delle
Properties sia stato modificato per poter specificare alcune informazioni ag-
giuntive sulle attività, necessarie per impostare la trasformazione progettata
(vedi capitolo 3).
Figura 2.6: Eclipse BPMN Modeler integrato in WebRatio

2.3 Tecnologie di trasformazione

Lo stato dell’arte relativo alle tecnologie di trasformazione da modello di
workflow a modello di applicazione web comprende diversi approcci.
In [5] vengono presi in analisi vari metodi per impostare il processo di tra-
sformazione: il controllo del processo attraverso la topologia dei collegamenti,
quello basato sulla condivisione dei dati relativi al processo e l’estensione dei
modelli di applicazioni con primitive process-aware (letteralmente “consape-
voli del processo”, ovvero in grado di gestire gli eventi relativi al flusso di
lavoro).
Il primo approccio basa il controllo dei processi sui collegamenti all’in-
terno degli ipertesti. Il principio è quello di associare ogni attività ad una o
più pagine web, e mostrare agli utenti un collegamento alla pagina iniziale
dell’attività solo quando i vincoli del processo consentono all’utente di ese-
guire tale attività. Questa soluzione è quella più immediata per garantire
la sequenzialità della navigazione. La topologia dell’ipertesto è usata per
rinforzare i vincoli di precedenza tra le attività desiderati. Questo tipo di
approccio è trattato anche in [23].
Un altro modo per affrontare il problema di gestire i vincoli di un processo
in un’applicazione web si basa sull’utilizzo delle informazioni presenti nella
struttura dati (spesso un database) su cui poggia l’applicazione. L’idea chiave
è quella di codificare l’avanzamento del case (ovvero l’istanza reale di un
processo), ad esempio l’avvio e la conclusione delle istanze di attività, nella
struttura dati. In questo modo, la sincronizzazione all’interno di ogni site
view6 è garantita ancora dai collegamenti, mentre la sincronizzazione tra una
site view e la successiva/precedente è ottenuta salvando lo stato delle attività
all’interno del database, e usando la navigazione condizionale (basata sui reali
valori memorizzati all’interno del database).
Un ulteriore approccio per garantire il funzionamento di applicazioni web
6
Una site view è un raggruppamento di pagine all’interno di un modello WebML.
Suddividere l’applicazione in site view è utile per fornire a diversi gruppi di utenti diverse
modalità di accesso all’applicazione.
basate sul flusso di lavoro è quello di estendere il modello WebML con delle
nuove primitive7 in grado di gestire le attività ed i case, recuperare le infor-
mazioni necessarie per l’esecuzione delle attività e tenere traccia dello stato
del processo. In questo modo la gestione del flusso di lavoro viene delegata
a queste nuove unit, che si occupano di tutti gli aspetti legati al workflow.
Queste unit possono essere considerate delle macro8 in grado di farsi carico
della gestione dei processi. Utilizzando questo approccio è comunque neces-
sario estendere il modello dei dati per consentire di rendere persistenti i dati
utilizzati dalle nuove primitive.
Le prime due soluzioni citate hanno però diverse controindicazioni:
• la topologia dei collegamenti non può esprimere da sola i vincoli in caso

di processi con più di un attore;
• la condivisione dei dati integra le informazioni relative al processo

con quelle dell’applicazione, rendendo più difficile la comprensione del
modello dei dati;
• entrambe le tecniche sfruttano i collegamenti di navigazione: in questo

modo l’ipertesto contiene sia i collegamenti relativi alla navigazione che
quelli necessari per la gestione del flusso di lavoro. Tuttavia, questa
distinzione non è evidenziata nell’ipertesto, il quale viene dunque reso
più difficile da interpretare e da modificare;
• la condivisione dei dati prevede l’inserimento nell’ipertesto di opera-

zioni aggiuntive (aggiornamento dei dati, creazione e cancellazione di
relazioni, ecc.) necessarie per registrare lo stato del processo. Anche
queste operazioni contribuiscono a rendere meno leggibile l’ipertesto;
• alterare il modello di processo di partenza implica modifiche sia a livello

di dati che di ipertesto, in modi non chiaramente comprensibili dalle
7
Per primitiva si intende una delle operazioni di base messe a disposizione da un
linguaggio di programmazione, in questo caso da un linguaggio di modellazione.
8
Una macro, in questo caso, può essere vista come una combinazione di concetti WebML
elementari.
specifiche; questo rappresenta un freno per l’evoluzione del processo

secondo le specifiche di business.
Per questi motivi, come punto di partenza per lo sviluppo del presente
lavoro, è stato scelto il terzo tipo di approccio, vale a dire quello che prevede
l’estensione del modello WebML con nuove primitive orientate al workflow.
Capitolo 3
Da BPMN a WebML
Lo scopo del presente lavoro è la progettazione di un metodo di tra-

sformazione che a partire da un diagramma BPMN permetta di ottenere
un’applicazione web completa.
Per effettuare tale operazione si procede per gradi:
1. per prima cosa è necessario descrivere il processo tramite la notazione

BPMN, sfruttando l’editor di WebRatio (vedi paragrafo 2.2);
2. attraverso l’introduzione della tipizzazione (vedi paragrafo 3.2) è pos-

sibile assegnare un tipo alle attività presenti nel diagramma, in modo
da permettere la generazione di moduli con dei contenuti predefiniti;
inoltre si possono creare ed importare dei tipi personalizzati (vedi fase
4);
3. una volta generata la struttura dell’applicazione (ed i contenuti dei

moduli predefiniti) è possibile progettare e modellare i contenuti dei
moduli che rappresentano le attività personalizzate;
4. successivamente è possibile salvare questi moduli personalizzati in una

o più librerie utente, in modo da poterli riutilizzare nella fase 2 per dia-
grammi BPMN contenenti attività analoghe a quelle già implementate;
18
CAPITOLO 3. DA BPMN A WEBML 19
5. attraverso il generatore automatico di codice di cui WebRatio è dotato

è possibile ottenere il codice applicativo.
In figura 3.1 si può vedere uno schema riassuntivo delle fasi attraver-
so le quali avviene la trasformazione. Nella figura vengono evidenziate le
operazioni che non richiedono l’intervento dell’utente ma vengono svolte in
automatico.
Figura 3.1: Le fasi della trasformazione
Grazie al metodo proposto è possibile, qualora le attività del diagramma

di partenza siano tra quelle tipiche dei processi (e quindi presenti nella libre-
ria di attività fornita insieme all’editor), generare un’applicazione completa
molto rapidamente. In questo modo l’utente può ottenere un sistema fun-
zionante senza necessariamente conoscere a fondo lo standard WebML e la
piattaforma WebRatio. Quando invece il processo da trasformare include at-
tività più particolari, al designer toccherà soltanto inserire dei contenuti nei
moduli corrispondenti a tali attività. Un altro aspetto innovativo del presen-
te lavoro è la possibilità di salvare i moduli personalizzati e riutilizzarli allo
stesso modo di quelli predefiniti nella trasformazione di altri processi.
Due sono i tipi di approccio possibili per affrontare tale problematica,
ognuno dei quali si adatta ad un particolare scenario e tipo di utente:
1. generazione del solo scheletro dell’applicazione ed implementazione ma-

nuale dei moduli corrispondenti alle attività, nel caso in cui i processi
aziendali contengano attività proprie del contesto dell’azienda e quindi

non ancora implementate (vedi figura 3.2);
2. generazione di un’applicazione interamente tipizzata a partire dalle spe-

cifiche di business, nel caso in cui i moduli corrispondenti alle attività
siano stati precedentemente implementati (vedi figura 3.3).
Figura 3.2: Generazione dello scheletro e design successivo dei moduli
Nel primo caso il designer WebML si avvale della trasformazione per

ottenere la struttura base dell’applicazione, in grado di gestire il flusso di
lavoro. Successivamente dovrà, attraverso la piattaforma WebRatio, inserire
dei contenuti nei moduli fino a questo punto vuoti. Inoltre, potrà salvare i
moduli creati in modo da permetterne il successivo riuso.
Nel secondo caso invece l’esperto BPMN potrà ottenere un’applicazione
funzionante senza dover intervenire sul modello WebML.
Per capire meglio quali sono le situazioni in cui viene richiesta una parti-
colare soluzione si possono fare due brevi esempi:
1. richiesta di un prestito personalizzato da parte di un cliente di una

banca;
2. iscrizione ad un esame da parte di uno studente universitario.

Figura 3.3: Generazione completa dell’applicazione basata sulla tipizzazione
Nel primo caso, dato che le attività sono strettamente legate alle politiche
aziendali, non è possibile in fase di modellazione BPMN consentire all’ana-
lista business di scegliere tra attività già pronte. Sarà dunque necessario
modellare manualmente i moduli richiesti. L’aspetto innovativo, in questo
caso, riguarda la possibilità di salvare i moduli implementati in apposite li-
brerie, in modo da renderli riusabili al momento della modellazione di altri
processi contenenti attività analoghe.
Nel secondo caso, con attività ad esempio quali “Ricerca esame” o “Scel-
ta appello”, i moduli corrispondenti sono tipici del contesto universitario e
quindi spesso utilizzati. Dare la possibilità di scegliere all’interno di una li-
breria di attività già implementate, al momento della creazione del diagram-
ma nel tool BPMN, rappresenta un’innovazione che rende la generazione
dell’applicazione finale più semplice e veloce.
E’ possibile inoltre ottenere il risultato finale come combinazione tra i due
approcci citati: se per processi precedenti sono già stati implementati i modu-
li personalizzati propri del contesto dell’azienda, questi saranno selezionabili
nel diagramma BPMN cosı̀ come quelli predefiniti.
In questo capitolo si spiega attraverso quali passaggi viene effettuata
la trasformazione e quali vantaggi vengono offerti dalle nuove funzionalità
progettate ed implementate.
3.1 Trasformazione da BPMN a WebML

Una volta che i diagrammi che rappresentano il flusso di lavoro sono stati
definiti, è possibile effettuare la trasformazione attraverso un’apposita fun-
zionalità dell’ambiente di sviluppo (nel caso del presente lavoro WebRatio),
al fine di ottenere lo scheletro di un progetto web. Il risultato sarà un’applica-
zione con un modello di dati ben definito e con una struttura di navigazione
basata sul flusso di lavoro.
3.1.1 Specifica dei requisiti

Il processo di trasformazione deve produrre la struttura base di un’ap-
plicazione web che rispetti i vincoli espressi nel diagramma di workflow. Il
risultato dell’operazione è dunque un modello WebML (nel caso del presente
lavoro in ambiente WebRatio) contenente le informazioni relative al diagram-
ma BPMN di partenza. Nei prossimi paragrafi vengono descritti i requisiti
che la trasformazione deve rispettare.
Modello dei dati
Innanzitutto il WebML prodotto dalla trasformazione dovrà basarsi su un

modello di dati fissato e in grado di rendere persistenti le specifiche implemen-
tate visivamente nel diagramma. Questo data model, come viene chiamato
all’interno di WebRatio, deve dunque essere unico e fissato per qualsiasi web
project (sempre per usare la terminologia dell’ambiente di sviluppo), e deve
permettere un parallelismo totale tra elementi del BPMN ed entità/relazioni
del modello dei dati. Oltre a questo, deve essere possibile salvare le informa-
zioni relative a tutto quello che concerne lo stato degli elementi del workflow
e degli attori del sistema (ad esempio i dati sull’inizio e la fine delle atti-
vità o sull’utente che le ha eseguite). Ecco le linee guide per la successiva
progettazione del data model (vedi paragrafo 3.1.2):
• devono essere modellate tutte le entità necessarie alla gestione e al

controllo dei processi;
• deve essere possibile gestire utenti e gruppi di utenti e le loro associa-

zioni con le entità proprie del workflow;
Vincoli del workflow
La navigazione all’interno delle pagine deve essere soggetta alle regole

del BPM (Business Process Management). Per fare un breve esempio, se
un’attività è in parallelo con un’altra, l’attività successiva non potrà partire
fino a quando entrambe non saranno concluse. Allo stesso modo, se due
pagine prevedono che l’utente effettui determinate operazioni, e queste pagine
corrispondono all’esecuzione di attività in parallelo, la pagina successiva,
corrispondente all’attività successiva, non sarà accessibile fino a quando tutte
le operazioni relative alle due pagine precedenti non saranno state svolte.
Questo fa immaginare la quantità di regole di cui il modello web dovrà tenere
conto per gestire correttamente il flusso. Inoltre, un’applicazione web ha tra i
suoi fini quello di permettere l’utilizzo distribuito della stessa, per cui bisogna
fare in modo che il rispetto dei vincoli sia garantito anche in condizioni di
accessi multipli.
Calcolo dell’attività successiva
Il modello generato deve anche integrare un sistema di decisione in gra-

do di stabilire, al termine dell’esecuzione di un’attività, quale sia il passo
successivo del processo. In particolare, tale sistema deve valutare:
• quali sono le scelte possibili al termine dello svolgimento di un’attività;
• se le condizioni per le quali queste scelte possono essere eseguite sono

rispettate (ad esempio il fatto che attività precedenti in parallelo con
quella appena eseguita siano concluse);
• se è necessaria la scelta di un utente o se i vincoli di workflow impongono

una decisione univoca;
• se l’attività successiva prevede l’interazione con un operatore o meno

(in caso negativo questa potrà partire in automatico).
3.1.2 Progettazione
Modello dei dati
Il modello dei dati progettato è rappresentato in figura 3.4 sotto forma

di diagramma ER1 . Le entità2 necessarie alla gestione del workflow sono le
seguenti:
• Process: il processo è l’entità attorno alla quale ruota tutto il flusso

di lavoro; ad ogni diagramma BPMN corrisponde una e una sola riga
nella tabella corrispondente a questa entità. I suoi attributi principali
sono:
– name: nome del processo (nel diagramma BPMN corrisponde al

nome assegnato al pool)
– description: breve descrizione del processo
• Case: particolare istanza di un processo. Esso segue il flusso di lavoro

del processo che istanzia. Gli attributi sono:
– name: nome del case (ad esempio “Richiesta prestito Mario Rossi”
per il processo “Richiesta prestito”)
– status: attuale stato del case; gli stati possibili sono i seguenti:
1. Instantiated: il case è stato creato ma non è ancora entrato
in esecuzione
2. Executing: il case è attualmente in esecuzione (almeno la
prima attività ha avuto inizio)
1
il diagramma ER, o entità-relazione, è un modello per la rappresentazione concettuale
dei dati; per ulteriori informazioni si veda [34].
2
Rappresentano classi di oggetti che hanno proprietà comuni ed esistenza autonoma ai
fini dell’applicazione di interesse. Un’occorrenza di un’entità è un oggetto della classe che
l’entità rappresenta [34].
Figura 3.4: Il modello dei dati
3. Suspended: il case è stato sospeso (non possono esserci atti-

vità in esecuzione)
4. Concluded: il case è concluso (tutte le attività necessarie al
completamento del case sono state completate)
– startedTimeStamp: indicatore temporale della prima volta che il
case è stato messo in esecuzione
– concludedTimeStamp: data e ora di conclusione del case
• CaseLogEntry: rappresenta una linea del cosiddetto log, ovvero l’e-

lenco di passaggi da uno stato ad un altro3 . Ecco una breve descrizione
dei suoi attributi:
– entryStatus: nuovo stato impostato al momento del passaggio da

uno stato all’altro
– entryTimeStamp: istante temporale in cui tale passaggio è avve-
nuto
• ActivityType: entità necessaria per la costruzione di un processo.

Esso è infatti costituito da una serie di ActivityType collegati tra loro
con delle frecce. Un tipo di attività non rappresenta un’attività real-
mente eseguita, ma ne descrive le proprietà; è dunque un’astrazione
dell’attività vera e propria (ActivityInstance), come il Process lo è per
il Case. I suoi attributi sono:
– name: nome dell’ActivityType; corrisponde al nome dell’attività

inserito nel diagramma BPMN
– description: breve descrizione dell’attività
– execution: modalità di esecuzione; questo attributo può avere solo
due valori:
1. Manual: l’attività deve essere eseguita da un utente reale
2. Automatic: l’attività è costituita da una serie di operazioni
che non richiedono l’intervento di un utente
• Condition: questa entità serve per descrivere le condizioni che rego-

lano il passaggio da un’attività ad un’altra; in presenza di gateway è
possibile che il flusso di lavoro sia influenzato dal valore di un deter-
minato parametro, in base ad una condizione particolare, espressa nel
seguente attributo:
3
in termini generali un log è la registrazione cronologica delle operazioni che vengono
eseguite, nel caso specifico si è scelto di considerare soltanto i cambiamenti del valore dello
stato.
– condition: espressione che mette in relazione alcuni parametri at-

traverso una relazione logica da valutare durante l’esecuzione del-
l’applicazione (ad esempio:
“(parametro1==“false”)&&(parametro2>2)”
• ActivityInstance: rappresenta un’istanza di ActivityType. E’ l’e-

quivalente del Case per il Process, ovvero l’entità concreta sulla quale
l’utente interviene. Questi sono i suoi attributi:
– type: numero che corrisponde all’identificatore del tipo di attività

– status: stato attuale dell’istanza (vedi l’attributo status dell’entità
Case per l’elenco degli stati possibili)
– startedTimeStamp: timestamp della prima volta che l’attività
entra in stato di esecuzione
– concludedTimeStamp: indicatore dell’istante temporale in cui l’at-
tività viene portata a termine
• ActivityLogEntry: equivalente di CaseLogEntry per le attività. I

suoi attributi sono:
– entryStatus: nuovo stato in cui viene posta l’attività

– entryTimeStamp: istante temporale in cui avviene il passaggio di
stato
• ParameterType: un’attività può avere dei parametri in entrata o in

uscita; il ParameterType indica l’astrazione di un parametro, ovvero le
sue caratteristiche principali; con la prossima entità, ParameterInstan-
ce, si completa il terzo caso di parallelismo astrazione-istanza. I suoi
attributi sono:
– name: nome del parametro

– description: breve descrizione del parametro
– type: tipo di dato che lo rappresenta (string, int, boolean...)
• ParameterInstance: istanza di un parametro, ovvero parametro reale

che viene utilizzato nel flusso di lavoro. In questo caso il suo attributo
principale è il seguente:
– value: attributo che dà vita al parametro, ovvero valore effettiva-

mente inserito durante l’uso dell’applicazione
Inoltre vi sono le seguenti entità, obbligatorie quando si crea un WebML

in ambiente WebRatio:
• User: utente generico dell’applicazione con i seguenti attributi:
– userName: nome utente; questo nome viene usato anche come

login per l’accesso alle parti protette dell’applicazione
– password : password con la quale l’utente può accedere ai servizi
a lui riservati
– email : indirizzo e-mail di contatto dell’utente
• Group: gruppo di utenti; per suddividere le varie parti dell’appli-

cazione e limitarne l’uso ad un certo numero di utenti, è necessario
suddividerli in gruppi. In questo modo si può stabilire quali gruppi
di utenti abbiano accesso a quali site view dell’applicazione. L’unico
attributo rilevante è:
– groupName: nome del gruppo
• Module: per Module si intende una particolare site view, ovvero una
serie di pagine eventualmente collegate tra loro ma non con il resto
dell’applicazione. La suddivisione in moduli (o site view) è utile per la
gestione degli accessi degli utenti. Gli attributi sono:
– moduleID: identificatore della site view

– moduleName: nome della site view
Per quanto riguarda le relazioni prese in considerazione si ometterà la

lunga (e piuttosto intuitiva) lista; ecco tuttavia una serie di informazioni sui
rapporti tra le varie entità descritte, utile per capire le dinamiche interne al
data model:
• l’entità attorno alla quale ruota il sistema è il Process;
• ogni Process può essere istanziato da più Case;
• un Process è costituito da una serie di ActivityType collegati tra loro;
• ogni ActivityType può essere collegato al successivo/precedente at-

traverso una particolare condizione (ad esempio: “Acquista libro” è
collegato a “Calcola sconto” attraverso la condizione con espressione
“totaleOrdine > 10”);
• ogni ActivityType può avere più ParametrType di input/output;
• ogni ActivityType può essere istanziato da più ActivtyInstance, una per

ogni Case del Process che contiene l’ActivityType. Questa affermazione
è valida in assenza di loop 4 ; nel caso della presenza di loop possono
esserci più istanze di un’attività all’interno dello stesso Case;
• un ParameterType può essere input per più ActivityType ma può essere

output solo di un ActivityType;
• le entità Process, ActivityType e ParameterType descrivono l’esecuzio-

ne astratta di un processo; non contengono quindi dei valori reali per
i parametri e per le condizioni. Posseggono tuttavia tutte le informa-
zioni necessarie per gestire un workflow reale soggetto a parametri e
condizioni;
4
un loop è un ciclo, ovvero una serie di attività che in determinate condizioni possono
essere ripetute all’interno di uno stesso Case; la possibile presenza di loop è comunque già
visibile dal diagramma BPMN di partenza.
• l’esecuzione reale è espressa attraverso le entità Case, ActivityInstance

e ParmeterInstance: attraverso di esse il flusso di lavoro prende vita e
le condizioni assumono dei valori;
• per ogni Case ed ActivityInstance viene registrato un log, contenente

tutti le informazioni sui cambi di stato avvenuti;
• un’ActivityInstance, se è un’istanza di un ActivityType con esecuzione

manuale, viene eseguita da uno e un solo User
• uno User può tuttavia eseguire un numero illimitato di ActivityInstan-

ce;
• un ActivityType viene assegnato ad uno o più Group; il che significa che

l’User che eseguirà l’istanza di un certo ActivityType dovrà appartenere
ad un Group assegnato allo stesso ActivityType;
• uno User appartiene ad un Group principale (DefaultGroup) ma può

appartenere a più Group;
• ogni Group ha accesso ad un Module principale (DefaultModule) ma

può avere accesso a più Module;
Sono state inoltre inserite due entità volatili5 , DataModel e Selecte-

dAttributes, necessarie per il funzionamento delle pagine di ricerca all’in-
terno del cruscotto di controllo (vedi paragrafo 4.4 per maggiori dettagli).
Infine è stata inserita un’ultima entità, ConfigurationParameter, che
serve per il testing del funzionamento del cruscotto di controllo (vedi 3.3 e
4.4).
5
un’entità volatile è un’entità che non viene salvata su un database vero e proprio, ma
memorizzata soltanto all’interno dell’applicazione stessa per la durata della sessione; si usa
quando le informazioni da memorizzare sono necessarie per lo svolgimento di particolari
operazioni ma non richiedono di essere rese persistenti.
Generazione del modello
Una volta che è stato fissato il modello dei dati del WebML finale, è possi-
bile definire i passaggi attraverso i quali avviene il cuore della trasformazione,
ovvero la generazione del modello.
Nella figura 3.5 è rappresentato un esempio di diagramma BPMN creato
con il Modeler in ambiente WebRatio. Un esempio simile verrà trattato in
dettaglio nel capitolo 5, dalla fase di creazione del diagramma di workflow
alla generazione del modello con attività tipizzate e cruscotto di controllo.
Attraverso la trasformazione verrà generato un modello web contenente il
data model trattato nel paragrafo precedente ed una module view necessaria
alla gestione del flusso. In questa module view saranno presenti un modulo
per ogni attività presente nel diagramma (vedi figure 3.6 e 3.7) ed uno per
ogni gateway (vedi figura 3.8).
Figura 3.5: Esempio di diagramma BPMN
I moduli vengono creati in modo standard, a seconda del tipo di attività

che istanziano (automatica o manuale). Ci sono tuttavia degli elementi co-
muni: entrambi i tipi di modulo hanno infatti come punto di partenza una
unit di tipo Input Collector 6 , con lo scopo di raccogliere tutti i parametri
necessari all’esecuzione dell’attività. La Input Collector Unit è poi collegata
ad una pagina che contiene uno scheletro del contenuto del modulo per le
6
La Input Collector Unit è il punto di ingresso di un modulo dal quale la catena di
operazioni ha inizio. Permette di definire tutti i parametri di input del modulo [30].
attività manuali, o ad una Operation Unit fittizia (che non effettua alcuna
operazione) per quelle automatiche. Gli elementi interni di un modulo devono
essere in generale trattati dal designer in modo da ottenere tutto il necessa-
rio (pagine, link, unit, script...) per l’esecuzione dell’attività corrispondente.
Nel paragrafo 3.2 si analizzeranno tuttavia dei metodi per trattare in modo
automatizzato anche i contenuti dei moduli.
Figura 3.6: Moduli generati (1 di 3)
Nei moduli che corrispondono ad attività o gateway manuali, ovvero do-

ve è richiesto l’intervento dell’utente, è presente una particolare componente,
chiamata Activity Info, che permette di ottenere in modo rapido le infor-
mazioni basilari sull’istanza di attività corrente e sul processo di cui essa fa
parte. E’ il designer a decidere se consentire o meno di visualizzare que-
ste informazioni all’utente che accede alla pagina corrispondente all’attività.
Alla fine di ogni modulo una particolare unit, la Next Activity Unit [10], si
occupa di stabilire, in base ai criteri dettati dal workflow, quali attività è
possibile eseguire. Questa unit va ad analizzare i vincoli da rispettare e a

valutare le condizioni per le quali un’attività può essere eseguita, utilizzando
i parametri effettivamente in gioco. Inoltre, se la fine dell’attività implica
l’esecuzione di una e una sola attività e questa è di tipo automatico, la Next
Activity Unit è in grado di lanciare direttamente l’esecuzione dell’attività
successiva. Il funzionamento di questa particolare unit è stato trattato in
modo più approfondito in [10].
Gateway
Per chiarire il funzionamento dei gateway è necessaria una piccola paren-

tesi. Questi elementi, necessari a gestire le varie diramazioni del flusso di
lavoro, vengono trasformati in moduli proprio come le attività (vedi figura
3.8); all’interno di questi particolari moduli vengono create delle unit neces-
sarie a valutare le condizioni che regolano la logica del gateway, a consentire
la scelte tra le attività possibili e a passare di conseguenza all’attività sele-

zionata. Il trattamento di gateway complessi è tuttavia un argomento in fase
di sviluppo.

3.2 Tipizzazione delle attività

Quando si parla di tipizzazione delle attività, si intende il processo trami-
te il quale i moduli che rappresentano gli ActivityType vengono “riempiti”
con dei contenuti. Per capire qual’è l’importanza e l’innovatività della ti-
pizzazione bisogna ricordarsi che una trasformazione pura ha come risultato
un’applicazione web che rispetta i vincoli espressi nel diagramma BPMN, ma
è compito del designer inserire dei contenuti all’interno delle attività.
Per mostrare i vantaggi di questa nuova funzionalità progettata, si in-
troducono due ruoli fondamentali all’interno del processo di trasformazione:
l’esperto di BPMN e il designer WebML.
Il primo tipo di utente si occupa di definire e modellare sotto forma di
diagrammi BPMN i processi aziendali. E’ a conoscenza dei concetti relativi
al workflow ma non ha competenze relative all’uso del linguaggio WebML.
Il designer WebML invece non si occupa della creazione dei diagrammi
iniziali; tuttavia, date le specifiche di business, è in grado di riempire i moduli
che rappresentano le attività con dei contenuti.
Figura 3.9: Esempio di modulo non tipizzato
Attraverso il processo di tipizzazione sarà possibile assegnare già nel tool

BPMN un tipo ad ogni attività; questo verrà scelto all’interno di una libre-
ria di attività predefinite, pre-implementate e fornite insieme al tool stesso.
Alla libreria predefinita potranno essere aggiunte delle librerie contenenti dei
moduli personalizzati, implementati dai designer WebML presso l’azienda o

esterni. In questo modo si andrà ad arricchire sempre di più la collezione di
moduli e di conseguenza la possibilità di scelta all’interno del tool. I moduli
personalizzati possono essere creati da zero oppure come estensione dei mo-
duli predefiniti. Attraverso il sistema di tipizzazione si garantisce quindi il
totale riuso delle attività implementate e si ottiene una netta separazione dei
ruoli all’interno del processo di trasformazione.
I passaggi tramite i quali avviene la tipizzazione sono due:
1. se il processo di partenza contiene attività già presenti nelle librerie

(predefinite o personalizzate), prima di effettuare la trasformazione si
può assegnare ad ogni attività un tipo “preconfezionato”, scelto all’in-
terno di una libreria. Se le attività sono già state tutte implemen-
tate precedentemente non è necessaria alcuna competenza a livello di
WebML per ottenere un’applicazione completa e funzionante;
2. se le attività non sono presenti nelle librerie, è necessario l’intervento

di un designer: questo può, una volta ottenuta la struttura (vuota o
tipizzata solo per alcune attività) dell’applicazione, inserire i contenuti
nei moduli e salvare il tutto. In questo modo, se in altri processi della
stessa azienda viene utilizzata una delle attività implementate, non
sarà necessario crearne ogni volta i contenuti ma si potranno caricare i
moduli salvati al pari di quelli predefiniti.
In figura 3.9 possiamo vedere il modulo generato a partire dall’attività

“Ricerca esame”. Questa attività, applicata la tipizzazione, potrebbe ad
esempio portare alla creazione di un modulo simile a quello rappresentato in
figura 3.10. L’esempio in questione, seppur molto semplice, rende l’idea di
quello che è possibile fare attraverso la tipizzazione. Nei prossimi paragrafi
(soprattutto nel paragrafo 3.2.2) verrà descritto in dettaglio come è stata
progettata questa funzionalità.
Figura 3.10: Modulo tipizzato

Per maggiore chiarezza d’ora in poi si parlerà di tipi predefiniti quando ci
si riferisce alle attività fornite insieme al tool e di tipi personalizzati quando
si parla dei moduli riempiti manualmente e salvati del designer WebML.
Vi sono tuttavia una serie di requisiti che entrambe le categorie di tipi
dovranno rispettare:
• il “riempimento” dei moduli non deve in alcun modo interferire con il

workflow;
• i parametri in ingresso e in uscita delle attività non devono subire

variazioni una volta che è stato assegnato un tipo al modulo;
• i moduli tipizzati potranno richiedere l’uso di entità o relazioni non pre-

senti nel data model di base; di conseguenza sarà necessario coordinare
moduli e data model in modo coerente e funzionale.
La tipizzazione si colloca in diversi punti nello sviluppo dell’applicazione,

a seconda della quantità di tipi già implementati; i passaggi attraverso i
quali avviene il processo di trasformazione abbinato alla tipizzazione sono i
seguenti:
1. creazione del diagramma BPMN;
2. scelta del tipo per le attività già presenti nelle librerie;
3. generazione del modello WebML;
4. inserimento dei contenuti nei moduli privi di tipo;
5. salvataggio dei moduli modificati per il successivo riuso.
Sincronizzazione
Particolare rilevanza ha in questo caso il problema della sincronizzazione

tra diagramma BPMN e modello WebML: infatti, sebbene la trasformazione
trattata nel paragrafo 3.1 sia stabile anche a fronte di successive modifiche del
diagramma, quando si ricorre alla tipizzazione il discorso è più complicato.
Nel caso di generazione senza l’uso dei tipi, quello che si ottiene non è
altro che una serie di moduli vuoti; tutte le informazioni relative al flusso di
lavoro sono salvate nel database e quindi indipendenti dal modello web. Sarà
compito della Next Activity Unit andare a verificare nei dati del processo
quale sia il flusso di lavoro da rispettare, ma a livello di trasformazione tutto
ciò che è richiesto è aggiungere o rimuovere dei moduli.
Quando però le attività hanno un tipo, è necessario che questo venga
mantenuto anche a fronte di modifiche del diagramma BPMN; ovviamente
questo deve accadere soltanto per le attività che non vengono rimosse dal
diagramma.
E’ quindi molto importante garantire la stabilità del modello web anche
nel caso in cui sia stata utilizzata la tipizzazione.
3.2.2 Progettazione
Entriamo ora nel dettaglio di come è stato progettato il processo di
tipizzazione.
Per prima cosa andiamo ad analizzare come vengono trasformate le at-

tività senza l’utilizzo della tipizzazione, applicando una trasformazione sem-
plice da BPMN a WebML. Innanzitutto, ad ogni attività, o meglio, ad ogni
ActivityType, corrisponde un modulo con lo stesso nome dell’attività pre-
sente nel diagramma BPMN. Tutti i moduli sono contenuti in un’unica, par-
ticolare, module view, chiamata BP Activities. Questa speciale module view
rappresenta il terreno sul quale andrà ad agire la tipizzazione. Si ricorda
infatti che nessuna attività è a conoscenza delle informazioni sul flusso di
lavoro, ma la gestione di questo è delegata alla speciale Next Activity Unit
(vedi 3.1.2, [10]).
Figura 3.11: Modulo di un’attività automatica privo di tipizzazione
In una trasformazione priva di tipizzazione, quello che si ottiene dalle

attività sono degli stub 7 dei moduli che le rappresentano. Il contenuto in-
serito in automatico rende comunque l’attività eseguibile secondo i vincoli
del workflow, ma non vi sono reali operazioni che l’utente può svolgere o che
vengono svolte in automatico. L’utente può avviare o concludere un’attività
in modo fittizio, senza effettivamente svolgere il lavoro previsto dalla stessa.
Tuttavia, generare un’applicazione non tipizzata può essere utile quando si
vuole testare la corretta impostazione del diagramma BPMN, soprattutto
nel caso di processi complessi.
Lo stub di un’attività manuale è rappresentato in figura 3.9, mentre quello
di un’attività automatica in figura 3.11.
7
Uno stub, nell’informatica, è una sorta di bozza del contenuto reale che andrà poi
implementato.
Per descrivere come è stata progettata la tipizzazione, si simuleranno i

passi di una trasformazione, indicando in quali di questi la tipizzazione ha
effetto e quali sono i risultati a cui essa porta.
Come primo passo, attraverso l’editor BPMN di WebRatio si crea il dia-
gramma BPMN. Si creano le attività, gli eventi, si imposta il flusso di lavoro,
si indicano i parametri e si impostano come input/output delle attività crea-
te. A questo punto, se sono già stati salvati dei moduli personalizzati, o se
nelle librerie fornite con il tool sono presenti moduli applicabili alle attività
create, nel pannello delle Properties relativo all’attività selezionata si può
scegliere, da un menu a tendina, il tipo di interesse (vedi figura 3.12). Nella
figura, per semplicità, sono stati pre-caricati solamente due tipi, ma l’utente
troverà nel menu corrispondente al Type tutte le attività già utilizzabili, sia
quelle predefinite che quelle personalizzate precedentemente salvate.
Figura 3.12: Scelta del tipo di un’attività
A questo punto è possibile sfruttare la trasformazione per ottenere lo sche-

letro dell’applicazione. Diversamente dalla trasformazione semplice, per le
attività delle quali si è indicato il tipo non si troveranno gli stub dei moduli,
bensı̀ dei contenuti reali, effettivamente utilizzabili all’interno dell’applicazio-
ne. Se invece per un’attività non si è selezionato il tipo, il modulo generato
sarà quello di base.
E’ ora possibile intervenire sui moduli generati. In particolare si dovran-
no creare i reali contenuti per i moduli non tipizzati e verificare se quanto
generato dalla tipizzazione è coerente con i requisiti di business. Ad esem-
pio, è possibile che l’attività “Ricerca Esame”, nel contesto del Politecnico
di Milano, possa richiedere più o meno parametri della stessa nel contesto di
un’altra università. Terminate le operazioni di design dei moduli, attraverso

un’apposita funzionalità introdotta è possibile salvare il modulo implemen-
tato (vedi figura 3.13). Si noti che questa operazione può essere effettuata
sia per i moduli creati a partire dallo stub, che per le estensioni dei moduli
predefiniti.
Figura 3.13: Salvataggio di un modulo personalizzato
Quando tutti i moduli sono stati completati, si può passare alla fase di
generazione dell’applicazione web vera e propria (vedi capitolo 4).
I moduli personalizzati che sono stati salvati saranno poi utilizzabili al pa-
ri dei moduli predefiniti. In figura 3.14 si può vedere come nella lista dei tipi
disponibili sia stato inserito il tipo “Controllo piano di studi”, implementato
e salvato dal designer.
Sincronizzazione
Come anticipato nella specifica dei requisiti, il problema della sincronizza-
zione richiede una particolare attenzione. Infatti le attività tipizzate possono
creare dei problemi quando il diagramma BPMN viene modificato e si cerca
di aggiornare successivamente il modello WebML.
Figura 3.14: Successivo riuso di un modulo personalizzato
E’ importante, per garantire una sincronizzazione stabile a fronte di mo-

difiche delle specifiche di business, che un tipo salvato imponga dei vincoli
sui parametri di input e di output. Quindi, se per esempio il tipo “Ricerca
esame” ha un solo parametro di output (ad esempio “Codice esame”) l’atti-
vità alla quale si vuole assegnare il tipo dovrà avere le stesse caratteristiche.
Un’attività di ricerca di un esame che preveda come uscita altre informazioni
rispetto al codice dell’esame potrà essere implementata manualmente (esten-
dendo o modificando, se esiste, un’attività simile) e successivamente salvata.
Per continuare con l’esempio della ricerca di un esame si può pensare a di-
versi tipi che rappresentino diverse interfacce della stessa attività, come per
esempio:
• ricerca esame (nessun input, codice esame come unico output);
• ricerca esame in base a esami da sostenere (matricola studente come

input, codice esame come output);
• ricerca esame in base al professore (codice professore come input, codice

esame come output).
3.3 Cruscotto di controllo processi

Una volta completata la fase di trasformazione e di tipizzazione si ot-
tiene, attraverso la generazione del codice, un’applicazione web completa e
funzionante.
A questo punto gli utenti incaricati di eseguire le attività presenti all’in-
terno dei processi possono accedere all’applicazione e partecipare al workflow.
Dato che il numero di case in esecuzione per un processo può in alcuni
casi essere elevato, cosı̀ come il numero di attività e di utenti in gioco, si
pone il problema del controllo dello stato del sistema. E’ infatti importante
avere la possibilità di monitorare e visualizzare le informazioni su quello che
sta attualmente accadendo.
Inoltre è opportuno tenere traccia di quanto avviene anche a fini stati-
stici. Se per esempio un case sta richiedendo un tempo di esecuzione molto
più elevato di quello medio impiegato dagli altri case dello stesso processo,
è probabile che ci si trovi ad un punto di stallo. Le informazioni di tipo
statistico aiutano dunque ad evidenziare eventuali criticità e problemi.
Il cruscotto di controllo processi nasce sulla base delle considerazioni
appena fatte, ed è stato progettato per far fronte alle seguenti esigenze:
• monitorare lo stato attuale del sistema;
• valutare le prestazioni degli attori in gioco;
• evidenziare eventuali criticità all’interno dei processi;
• fornire informazioni di tipo statistico.
Nei seguenti paragrafi verranno evidenziati i requisiti che il cruscotto di

controllo processi deve rispettare e come è stato progettato.

Le esigenze elencate nell’introduzione sul cruscotto di controllo portano
ad una serie di requisiti che si dovranno considerare nella fase di progetta-
zione. Ognuno di essi verrà trattato in un apposito paragrafo.
Monitorare lo stato attuale del sistema
Al fine di poter tenere sotto controllo tutto quello che sta avvenendo in
un determinato momento è utile rappresentare in modo veloce ed intuitivo
il numero di case e di attività in esecuzione. Deve essere possibile accede-
re rapidamente al log degli eventi attivi e ai dati sugli utenti e sui gruppi
attualmente impegnati. E’ inoltre molto utile avere informazioni temporali,
come i tempi di esecuzione, e numerici, come il numero di entità in stato di
esecuzione.
Valutare le prestazioni degli attori in gioco
In questo caso il punto di vista da considerare è quello degli utenti: è

importante poter valutare i tempi medi di esecuzione delle attività per ogni
singolo utente, per ricavare informazioni sulle prestazioni. Tali dati possono
essere utilizzati a diversi scopi:
• capire se un utente si trova in difficoltà ad eseguire alcuni tipi di attività;
• individuare comportamenti non efficienti da parte di qualche utente;
• ottimizzare le prestazioni di ogni utente riassegnando le attività in base

alle prestazioni.
Evidenziare eventuali criticità all’interno dei processi
Un altro aspetto molto importante è legato agli indicatori temporali medi

e in tempo reale relativi ad attività e case.
Con un’analisi statistica è infatti possibile individuare in modo molto
veloce se un determinato processo presenta problemi di varia natura:
• alcune attività durano molto di più delle altre e di conseguenza, rallen-

tando il processo, ne rappresentano un punto critico;
• esistono processi che se eseguiti secondo un determinato workflow han-

no una durata sensibilmente diversa dalla media.
Fornire informazioni di tipo statistico
Infine, la persistenza dei dati relativi all’esecuzione dei processi porta

alla creazione di una database ricco di informazioni statistiche molto utile in
caso vi sia la necessità di effettuare analisi di business sui processi aziendali.
Dal punto di vista gestionale, avere la possibilità di accedere in modo veloce
ed intuitivo ad una serie di informazioni su processi, case, tipi ed istanze
di attività rappresenta un potente strumento di studio, fondamentale per il
miglioramento nella gestione del workflow.
3.3.2 Progettazione
Il cruscotto di controllo processi è stato progettato come una particolare
site view, inseribile nei modelli WebML basati sul workflow attraverso un
plug-in di WebRatio. Una volta generato il modello web sarà possibile, at-
traverso tale plug-in, aggiungere la site view chiamata WorkflowControlPanel
(vedi figure 3.15 e 3.16).
L’inserimento della site view prevede una serie di controlli, al fine di
garantire che il modello web rispetti i requisiti dei modelli generati attraverso
la trasformazione. Affinché il cruscotto possa essere aggiunto è necessario che:
• sia stato selezionato un web project;
• tale web project abbia un data model coerente con quello dei progetti
generati attraverso la trasformazione;
• il data model sia mappato8 su un database;

8
Il mapping rappresenta l’associazione tra ogni elemento del data model ed una
tabella/attributo/view del database
Figura 3.15: Inserimento del cruscotto di controllo attraverso il plug-in
• non sia stato precedentemente inserito il cruscotto.
Figura 3.16: Risultato dell’inserimento del cruscotto
Attraverso l’uso del plug-in verranno inoltre aggiunti al workspace, se

necessario, il progetto di stile9 e le librerie necessarie per l’esecuzione di tutte
9
Un progetto di stile, in WebRatio, contiene i dati relativi alla resa visiva dell’appli-
cazione; contiene tutte le informazioni necessarie per generare in modo appropriato le
pagine.
le operazioni previste dal cruscotto.

Grazie all’uso di uno wizard, è possibile inoltre selezionare quali elemen-
ti del cruscotto aggiungere secondo le specifiche esigenze. In questo modo
l’utente può scegliere, tramite opportuni menu, quali parti del cruscotto ot-
tenere nella site view generata. Il designer potrebbe infatti consentire agli
addetti al controllo di visualizzare solo i dettagli di alcune entità scelte, op-
pure di visualizzare un insieme più ristretto delle informazioni disponibili
su un’entità. Ad esempio, per un responsabile delle risorse umane potreb-
be essere utile visualizzare le informazioni sugli utenti, ma non quelle sui
processi.
Entriamo ora nel dettagli più strettamente progettuali relativi alla site
view del cruscotto.
La home page, chiamata Overview, è rappresentata in figura 3.17; questa
pagina permette di avere una rapida panoramica su quanto sta accadendo
nel sistema. Vengono infatti mostrati i case e le attività in esecuzione e gli
utenti che stanno al momento partecipando al processo. La pagina propone
inizialmente una Power Index Unit che elenca i case in stato di esecuzione.
L’utente può selezionare uno di essi per visualizzare i dettagli sia sul case
stesso che sul relativo processo (tramite due semplici Data Unit). Viene inol-
tre proposto l’elenco delle istanze di attività al momento in esecuzione che
fanno parte del case scelto. In modo analogo, scegliendo un’attività dall’e-
lenco, vengono mostrati i dettagli su di essa, sul relativo tipo e sull’utente
che la sta eseguendo.
Le tre aree principali sono le seguenti:
1. Process and Activities
2. Users and Groups
3. Search
Ognuna di queste sarà trattata successivamente, nei paragrafi alla fine di

questo capitolo.
Figura 3.17: Home page del cruscotto di controllo processi
Prima di procedere con i dettagli sulle aree, è opportuno aprire una paren-
tesi sullo strumento utilizzato per la rappresentazione dinamica dei grafici:
Google Chart API 10 . La Google Chart API è un tool estremamente sempli-
ce che permette di creare facilmente un diagramma partendo da una serie
di dati e di inserirlo in una pagina web. Si includono i dati e i parametri
di formattazione in una richiesta HTTP, e Google restituisce un’immagine
PNG del diagramma. Sono supportati molti tipi di grafico, e collocando la
richiesta in un tag di un’immagine si può includere il diagramma in una pa-
gina web in modo semplice [12]. All’interno delle pagine di dettaglio, che
verranno analizzate nei paragrafi successivi, è stata sfruttata questa API per
tutti i tipi di rappresentazione grafica.
Entriamo ora nelle specifiche progettuali delle aree del cruscotto. Per
ognuna delle seguenti aree è stata inserita l’immagine di una delle pagine
modellate, a titolo esemplificativo.
10
La Application Programming Interface (API), o Interfaccia di Programmazione di
un’Applicazione, è un insieme di procedure disponibili al programmatore, di solito
raggruppate per formare un set di strumenti specifici per un determinato compito [33].
Process and Activities
L’area Process and activities contiene tutte le informazioni relative a pro-

cessi, case, tipi di attività ed attività. In questa area è presente una home
page che elenca i processi ed i case presenti all’interno del sistema, con la
possibilità di visualizzare solo l’elenco dei case relativi ad un dato processo.
Figura 3.18: Pagina di dettaglio di un case
Sono poi presenti le seguenti pagine, di cui si elencano gli elementi prin-
cipali:
• Process details: i dettagli sul processo. Questa pagina contiene, oltre

alle informazioni basilari sul processo, alcuni indicatori statistici, co-
me il tempo medio di esecuzione dei case e delle attività e il numero
di case suddivisi per stato. Quest’ultima informazione viene rappre-

sentata attraverso un grafico, sfruttando la Google Chart API. Sono
inoltre presenti i collegamenti a tutti i case e i tipi di attività relativi
al processo;
• Case details (vedi figura 3.18, spiegata successivamente): pagina che

riassume le principali informazioni riguardanti il case. Sono presenti i
dati principali sul case e sul relativo processo, il log con l’elenco delle
operazioni effettuate, i collegamenti alle istanze di attività e l’indicatore
del tempo di esecuzione. Inoltre vi sono due grafici, entrambi relativi
alle istanze di attività del case: il primo ne rappresenta il numero,
suddiviso per stato, e il secondo il diagramma di GANTT11 ;
• ActivityType details: dettagli sui tipi di attività. Le informazioni pre-

senti sono il tempo medio di esecuzione delle istanze del tipo, i colle-
gamenti ad esse e ai gruppi assegnati a tale tipo, i dati sul processo di
appartenenza e un grafico che riassume il numero di istanze di attività
suddivise per stato;
• ActivityInstance details: pagina di dettaglio sulle istanze di attività.

Oltre alle informazioni su processo, case e tipo di attività collegati al-
l’istanza, sono presenti le informazioni sull’utente che l’ha eseguita o
che la sta eseguendo e il log delle operazioni effettuate. Infine, attra-
verso alcuni collegamenti, è possibile navigare il flusso di lavoro reale
del case passando alle istanze precedenti o successive.
La pagina mostrata in figura 3.18 si basa sulla Data Unit relativa ai

dettagli del case (“Case Details”). Da questa vengono ricavate una serie di
informazioni: i dati sul relativo processo, il log, le istanze di attività e il tempo
11
Un diagramma di GANTT è uno strumento di supporto alla gestione dei progetti, nel
caso del presente lavoro applicato ai processi. Rappresenta la durata delle attività come
una serie di barre orizzontali in rapporto al tempo totale di esecuzione del case. L’asse
delle ascisse indica appunto il tempo di esecuzione, partendo dall’inizio del case fino ad
arrivare all’istante di conclusione, se il case è concluso, o alla data e ora correnti, se il case
non è terminato.
di esecuzione (calcolato attraverso una Script Unit). Inoltre, sfruttando due

Query Unit (unit che permettono di eseguire delle ricerche all’interno della
sorgente dei dati) e due Script Unit vengono costruiti i grafici: le Query Unit
ricavano dal database i dati necessari, mentre le Script Unit costruiscono la
stringa da passare alla Google Chart API per la resa finale. In figura 4.4
si può vedere uno screenshot di una pagina generata a partire da questa
porzione di modello.
Users and Groups
In questa area sono invece contenute le informazioni riguardo utenti e

gruppi. E’ presente una home page con l’elenco di gruppi ed utenti ed i
collegamenti alle pagine di dettaglio; l’area contiene inoltre le seguenti pagine:
Figura 3.19: Pagina di dettaglio di un utente
• User details (vedi figura 3.19, descritta alla fine di questa sezione):
contiene i dettagli sull’utente e sui gruppi di appartenenza, i collega-
menti alle attività assegnate all’utente e alcune informazioni statistiche:
le attività in esecuzione, sospese e terminate e la media dei tempi di
esecuzione;
• Group details: pagina di dettaglio del gruppo; in questa pagina so-

no presenti i collegamenti agli utenti del gruppo e ai tipi di attività
assegnati.
La pagina in figura 3.19 ruota intorno alla Data Unit contenente i det-
tagli sull’utente (“User Details”). Oltre ai dati sui gruppi e sulle istanze di
attività relative all’utente, alcune Query Unit e una Script Unit si occupano
di ricavare ed elaborare i dati necessari per il riempimento di una Entry Unit
contenente alcune informazioni di tipo statistico sull’utente, come il numero
di attività divise per stato ed il tempo medio di esecuzione delle attività.
Search
La sezione dedicata alla ricerca è stata strutturata su due livelli: Simple

search e Advanced search.
Figura 3.20: Pagina di ricerca avanzata

Entrambe le pagine di ricerca si basano tuttavia su due innovative unit

di WebRatio: la Data Model Unit e la Query Unit.
La prima consente di passare in rassegna tutti gli elementi del modello
dei dati (o solo alcuni di essi, selezionabili tra i parametri di configurazione
della unit) per fornirli come input ad altre unit (come le Index o Entry Unit).
In questo modo, nel contesto delle pagine di ricerca, si possono creare menu
dal quale l’utente può scegliere gli elementi sui quali basare la ricerca stessa.
La Query Unit si occupa invece di eseguire la ricerca vera e propria. Può
essere utilizzata in due modalità, statica e dinamica.
La modalità statica prevede l’inserimento di una query manuale ben de-
finita (in linguaggio HQL o SQL), all’interno della quale si possono usare
parametri di input o di output ma senza variarne la logica. La Query Unit
statica è stata sfruttata per calcolare ad esempio i tempi di esecuzione nelle
altre aree.
La modalità dinamica è invece quella che è stata sfruttata nell’area Sear-
ch. Tale uso prevede che la query venga valutata in modo dinamico, sia
per quanto riguarda gli elementi da visualizzare come risultato che per le
condizioni. L’utente, selezionando entità ed attributi che gli interessano e
condizioni da rispettare, imposta la query in modo intuitivo e veloce: sarà
poi la Query Unit a costruire il codice necessario per ottenere i risultati.
Nella pagina Simple, pensata per un utente non particolarmente esperto
dei meccanismi di ricerca nei database, è possibile selezionare l’entità di inte-
resse e gli attributi da visualizzare ed impostare una semplice condizione sui
valori di essi (ad esempio: nome e descrizione del case il cui attributo name
contiene “Mario Rossi” o nome del processo la cui descrizione non contiene
“esame”).
Nella pagina Advanced (vedi figura 3.20) invece il meccanismo di costru-
zione della query è più complesso: è infatti possibile “navigare” il modello
dei dati attraverso le sue relazioni per effettuare ricerche basate su join tra
tabelle. I passaggi attraverso i quali avviene una ricerca avanzata sono i
seguenti:
1. si seleziona l’entità principale, ovvero quella di cui si cerca la pagina di

dettaglio (ogni risultato delle ricerche avrà un link che può essere solo
verso una delle sei pagine di dettaglio);
2. si selezionano gli attributi appartenenti all’entità principale da visua-

lizzare nel risultato;
3. si navigano le relazioni un livello per volta al fine di inserire tut-

te le condizioni necessarie ed eventualmente di aggiungere attributi
appartenenti ad altre entità da visualizzare nel risultato;
4. si esegue la query e si visualizzano i risultati;
5. si accede alla pagina di dettaglio del risultato di interesse attraverso il

relativo collegamento.
La pagina rappresentata in figura 3.20 contiene innanzitutto una serie di

Operation Unit di preparazione, necessarie per assicurarsi che non vi siano
dati relativi a precedenti ricerche non ancora cancellati. All’interno della
pagina vera e propria sono presenti le unit necessarie alla navigazione del
modello dei dati e alla costruzione dell’elenco delle condizioni della query e
degli attributi da visualizzare. Tutte le informazioni sulla ricerca da esegui-
re vengono poi passate ad una No Operation Unit che raccoglie i dati e li
passa alla Query Unit che si occupa di effettuare la ricerca (nella pagina di
visualizzazione dei risultati, “Search result”).
Un breve esempio di ricerca avanzata potrebbe essere il seguente: visua-
lizzare il nome del case e del relativo processo di tutti i case che contengono
“Mario Rossi” nel valore dell’attributo nome, non hanno avuto inizio pri-
ma del 03-03-2009 e dei quali la descrizione del relativo processo contiene la
parola “richiesta”.
Capitolo 4
Implementazione
In questo capitolo si parla degli strumenti utilizzati per implementare le

funzionalità proposte.
La maggior parte del lavoro è basata sullo strumento CASE WebRatio,
che consente sia la modellazione di applicazioni web che l’integrazione dello
standard WebML con le tecnologie Java pure e le possibilità che esse offrono.
Essendo WebRatio basato sulla piattaforma Eclipse, è possibile attraverso ta-
le tool integrare le potenzialità di Java con la progettazione e la modellazione
di applicazioni web.
Nei prossimi paragrafi verrà descritto più nel dettaglio come avvengono i
passaggi della trasformazione proposta.
55
CAPITOLO 4. IMPLEMENTAZIONE 56
4.1 Trasformazione da BPMN a WebML

La fase di trasformazione, a livello implementativo, non è altro che una
semplice conversione da XML a XML [27].
I diagrammi BPMN modellati con il Modeler in WebRatio vengono infatti
salvati sfruttando tale formato. Grazie alle librerie dom4j [9], che permettono
di gestire la trasformazione di un file XML, durante la fase di trasformazione
vengono presi in analisi tutti i nodi dell’XML che rappresenta il diagramma
e convertiti a seconda del tipo.
In particolare, ogni nodo che rappresenta un’attività dà origine ad un
nodo di tipo modulo nel WebML finale; se l’attività è automatica, tale modulo
sarà un Operation Module 1 , mentre se l’attività è di tipo manuale il modulo
risultante sarà un Hybrid Module 2 .
Anche i nodi che rappresentano i gateway danno origine a dei moduli:
anche in questo caso saranno dei moduli ibridi, contenenti una Multichoice
Unit se il gateway che implementano è di tipo AND e una Index Unit se il
gateway è di tipo OR.
Tutti gli altri dati, fondamentali per la gestione del workflow, vengono
salvati in un file necessario per l’aggiornamento del database. Ricordiamo
infatti che il flusso viene gestito grazie alla già citata Next Activity Unit,
che va a leggere nel database le meta-informazioni e fa in modo che i vincoli
imposti dalle specifiche di business vengano rispettati.
Questo file sarà accessibile tramite un pannello di controllo che viene
generato attraverso la trasformazione. Tale pannello consente di avviare il
trasferimento dei metadati sulla struttura dati scelta, dopo che questa è stata
correttamente attivata.
1
Un Operation Module è un modulo composto di sole operazioni.
2
Un Hybrid Module è composto sia da Operation Unit che da Content Unit.
4.2 Tipizzazione nel BPMN Modeler

Nella fase di trasformazione, un’attività del diagramma BPMN viene tra-
sformata in un modulo: a livello implementativo significa che viene costruita
una porzione di codice XML, all’interno del modello WebML dell’applica-
zione, contenente gli elementi dello stub, ovvero gli elementi provvisori che
permettono al sistema di gestire il flusso di lavoro ma che non consentono la
reale esecuzione dell’attività. In figura 4.1 è possibile vedere un esempio di
codice generato attraverso la trasformazione di un’attività, senza sfruttare il
processo di tipizzazione.
Figura 4.1: Esempio di codice XML generato da un’attività non tipizzata
Tale codice rappresenta la porzione del modello WebML finale da cui par-
tirà la creazione dell’applicazione. Dato che questo codice contiene soltanto
lo stub del modulo, e viene generato dinamicamente per tutte le attività
non tipizzate (con elementi diversi a seconda che esse siano manuali o auto-
matiche), nella trasformazione viene sfruttata l’assegnazione dinamica degli
identificatori delle unit. A seconda del numero di attività presenti e delle
unit già implementate nel progetto web, le classi che si occupano della tra-
sformazione lasciano a WebRatio il compito di stabilire gli identificatori di
unit e link.
Nel caso in cui invece viene sfruttata la tipizzazione, il discorso è diverso:
dato che i moduli devono essere implementati in base a quelli salvati nelle
librerie, gli identificatori degli elementi presenti al loro interno dovranno es-
sere rappresentati in modo univoco e senza la possibilità di creare collisioni
dovute alla non unicità di uno di essi. Per questo, i moduli predefiniti saran-
no dotati di id speciali, formati secondo delle regole precise in base al nome
del file e della libreria in cui sono contenuti. In figura 4.2 si può vedere un
esempio di come viene generata dinamicamente una unit nel caso di attività
non tipizzata e di come la stessa unit venga trattata all’interno del file XML
di un modulo tipizzato.
Figura 4.2: Id generati dinamicamente e pre-fissati
Sfruttando la tipizzazione, all’interno del modellatore BPMN si possono

ottenere pagine utilizzabili generando l’applicazione subito dopo che il dia-
gramma di partenza è stato trasformato in modello WebML. Nella figura
4.3 un semplice esempio di come potrebbe risultare la pagina contenuta nel
modulo “Ricerca esame” utilizzando la funzionalità proposta.
Nell’esempio sono stati inseriti alcuni contenuti nel modello dei dati del-
l’applicazione; tale inserimento è totalmente indipendente dal modulo gene-
rato, purché questo abbia accesso alle entità necessarie.
Figura 4.3: Screenshot di una pagina generata da un modulo tipizzato
A questo punto è opportuno definire il comportamento della tipizzazione

nei confronti del modello dei dati. Infatti, considerando sempre l’esempio
dell’attività “Ricerca esame”, il modulo generato richiede la presenza delle
entità “Esame” e “Studente”, cosı̀ come della relazione tra le due entità;
questi elementi devono avere degli identificatori fissati, in modo che non
possano risentire della generazione automatica di identificatori fornita da
WebRatio. Dunque il file XML che contiene il tipo di un’attività necessario
alla tipizzazione sarà composto sia della parte relativa alle pagine, alle unit
e ai collegamenti, che di quella contenente le informazioni sulle entità da
inserire nel modello dei dati. Gli identificatori di tali entità saranno costruiti
in base al nome della libreria: in questo modo, se più attività della stessa
libreria fanno uso delle stesse entità, queste vengono inserite una sola volta
all’interno del modello dei dati e i moduli ne fanno uso in modo condiviso.
4.3 Tipizzazione in WebRatio

Una volta creato il modello, il designer WebML può intervenire a piacere
sui moduli desiderati, sia su quelli generati senza tipizzazione che su quelli
tipizzati. Per garantire il corretto funzionamento dell’applicazione finale è
necessario che tutti i moduli vengano riempiti con gli opportuni contenuti.
Come trattato nella parte relativa alla progettazione è possibile, alla fine
della fase di design, salvare quanto implementato in opportuni documenti
e librerie per permettere il riuso dei moduli quando le attività di un altro
diagramma BPMN sono dello stesso tipo.
A livello implementativo, l’operazione “Save Module As Type” è un plug-
in di WebRatio. Questo plug-in, sfruttando le già citate librerie dom4j, pren-
de in input i contenuti del modulo progettato e li elabora in modo da ottenere
un file XML strutturato in modo analogo a quello delle librerie predefinite.
In particolare, le operazioni che vengono eseguite salvando un modulo sono
le seguenti:
1. si traduce il codice XML del modulo in un codice analogo ma con

identificatori univoci (utilizzando il nome dell’attività come prefisso);
2. si controlla quali entità e quali relazioni presenti nel modello dei da-
ti sono necessarie per garantire il funzionamento delle unit interne al
modulo;
3. si aggiunge all’XML prodotto nel punto 1 il codice relativo alle entità e

alle relazioni da salvare, pre-trattando gli identificatori, usando questa
volta il nome della libreria come prefisso.
Il risultato di questi passaggi è un documento XML contenente la strut-

tura del modulo ed il codice delle entità e delle relazioni necessarie per il
funzionamento dello stesso. Per garantire coerenza nella gestione degli iden-
tificatori (cosa che rappresenta un punto critico nel processo di tipizzazio-
ne personalizzata) non è possibile salvare più moduli con lo stesso nome
all’interno della stessa libreria.
L’uso del nome della libreria come prefisso per gli identificatori delle entità
e delle relazioni consente di evitare collisioni nel momento in cui si cerca di
tipizzare due attività, scegliendo tra i tipi di una stessa libreria, che fanno uso
di entità o relazioni comuni. In questo modo, ad esempio, l’entità “Esame”,
essendo comune alle attività “Ricerca esame” e “Iscrizione esame”, non verrà
inserita due volte all’interno del modello dei dati.
4.4 Cruscotto di controllo processi

L’implementazione del cruscotto di controllo è partita dalla creazione
all’interno di WebRatio di una particolare site view, chiamata Workflow-
ControlPanel, all’interno di un progetto web provvisto di un modello dei
dati conforme a quello indicato nella specifica dei requisti del processo di
trasformazione (vedi paragrafo 3.1.1).
All’interno della site view sono state inserite le aree, le pagine, le unit ed
i collegamenti necessari per la costruzione degli elementi progettati.
Per il calcolo di intervalli temporali (ad esempio il tempo di esecuzione
di un case) si è fatto ricorso alle librerie Joda Time [14]; queste forniscono
una serie di metodi in grado di lavorare su dati di tipo timestamp (forma-
to in cui sono rappresentati i dati temporali all’interno del data model) ed
effettuare operazioni su di essi. Questi metodi sono stati usati in apposite
Script Unit, programmate in Groovy [13], all’interno delle pagine in cui si
volevano rappresentare informazioni ricavate da operazioni su informazioni
di tipo timestamp.
Nelle figure 4.4 e 4.5 si possono vedere due screenshot delle pagine di
dettaglio generate con il deployment 3 del cruscotto di controllo.
Queste sono solo alcune delle pagine generate, ma verranno sfruttate per
esemplificare la resa finale delle caratteristiche delineate a livello di proget-
tazione (vedi paragrafo 3.3.2). Nella figura 4.4 si può vedere la pagina di
dettaglio di un case, generata a partire dalla porzione di modello web rap-
presentata nella figura 3.18. Oltre alle informazioni ricavate dal modello dei
dati con semplici Data Unit e Power Index Unit si possono vedere i risultati
di alcune delle funzionalità sfruttate:
• nella sezione “Execution Time” possiamo vedere l’intervallo di tempo

tra l’inizio e la fine del case, calcolato sfruttando le librerie Joda Time;
• il diagramma “Activity Instances per Status chart” rappresenta un

3
Per deployment si intende la messa in opera, in funzione, di un’applicazione, dopo la
fase di programmazione.
Figura 4.4: Screenshot della pagina di dettaglio di un Case
modo standard di utilizzare la Google Chart API per visualizzare le

attività divise per stato;
• nel diagramma “Activity Instances GANTT” si può vedere infine un

modo più creativo di creare diagrammi, per rappresentare il diagramma
di GANTT relativo alle attività del case.
Figura 4.5: Screenshot della pagina di dettaglio di una ActivityInstance

In figura 4.5 si possono vedere i dettagli su una ActivityInstance: la parte

rilevante di questa pagina riguarda le sezioni “Previous Activity Instances”
e “Next Activity Instances”: tramite queste Index Unit è possibile navigare
lungo la reale esecuzione di un diagramma BPMN. In entrambe le pagine si
possono vedere degli esempi di log, ovvero la sequenza di operazioni effettuate
sul case o sull’attività.
Pagine simili sono state implementate per i processi, i tipi di attività, gli
utenti ed i gruppi. Tutte le pagine implementate sono state opportunamente
collegate tra loro; inoltre alcune Index Unit, poste in apposite pagine globali,
permettono di vedere lo stato dei processi a livello più generale.
Di particolare rilevanza sono invece le pagine relative alla ricerca. Queste
pagine sfruttano infatti due unit piuttosto innovative introdotte recentemen-
te in WebRatio: la Data Model Unit e la Query Unit. La Data Model Unit
consente di ricavare informazioni sul modello dei dati, al fine di poterlo navi-
gare all’interno delle unit dell’applicazione stessa. In questo modo, si possono
impostare particolari condizioni di ricerca, che vengono poi passate alla Que-
ry Unit. Questa si occupa invece di effettuare la query vera e propria sul
database fisico.
In figura 4.6 un esempio di ricerca avanzata effettuata attraverso il cru-
scotto di controllo processi: nella colonna di sinistra, la sezione “Current
Level” indica l’entità sulla quale si sta effettuando la query (i risultati saran-
no istanze di tale entità) e il livello di navigazione al quale si è arrivati (in
questo caso si è partiti dall’entità Case, spostandosi verso il processo di cui il
case è istanza attraverso la relazione “process”). Nella sezione “Navigate Da-
tamodel” si può continuare a navigare il modello dei dati: in questo esempio,
essendo posizionati sull’entità Process si potrà tornare a Case (per spostarsi
per esempio su CaseLogEntry o su ActivityInstance) oppure muoversi verso
ActivityType. Per capire meglio i concetti relativi alla navigazione del mo-
dello dei dati si veda la figura 3.4. Infine, nella sezione “Select Attributes”, si
possono selezionare gli attributi, stabilendo se saranno da visualizzare (“Add
Select”) o da utilizzare per esprimere le condizioni (“Add Condition”). Nella
parte destra, invece, vengono visualizzati gli attributi scelti e le entità a cui
appartengono e vengono definite le condizioni. Il codice corrispondente alla
pagina di ricerca avanzata viene generato a partire da quanto rappresentato
in figura 3.20. Il risultato di questa query viene visualizzato in un’apposita
pagina (vedi figura 4.7); in questa pagina sono presenti anche i collegamenti
per raggiungere le pagine di dettaglio delle entità prodotte come risultato
della query.
Figura 4.6: Esempio di impostazione di una query
Figura 4.7: Pagina di visualizzazione dei risultati della query

4.5 Dal modello WebML al codice applicati-

vo
La trasformazione da modello WebML ad applicazione vera e propria
avviene sfruttando il generatore automatico di codice di cui WebRatio è do-
tato. L’architettura di WebRatio è rappresentata in figura 4.8 e descritta
in [1, 2, 6]. Tutti gli elementi creati nell’interfaccia grafica di WebRatio
hanno una rappresentazione interna in formato XML. Un modulo, chiamato
Database Synchronizer, si occupa di garantire il mapping tra le entità e le
relazioni tra i dati concettuali e una o più sorgenti di dati fisiche, che possono
sia essere create dal tool che essere pre-esistenti. Il Database Synchronizer
può anche ricavare la struttura dati da un database già esistente, e riflettere
le informazioni sul data model concettuale. Al contrario può intervenire sul
database per creare gli elementi necessari alla persistenza dei dati strutturati
secondo il modello. Nel nostro caso l’uso di questo modulo rappresenta il pri-
mo passo per predisporre il corretto deployment dell’applicazione. Infatti, è
necessario che il data model sia mappato al database perché il funzionamento
del sistema sia garantito.
Figura 4.8: L’architettura di WebRatio
L’interfaccia di design di WebRatio è collegata al generatore automatico

di codice, il quale sfrutta le trasformazioni XSL per tradurre le specifiche
XML, trattate in maniera visuale attraverso l’interfaccia grafica, in codice
applicativo eseguibile all’interno dell’ambiente run-time, basato sulla piatta-

forma Java2EE. In particolare, un insieme di traduttori XSL produce una
serie di template di pagine dinamiche e di descrittori di unit; sono questi a
consentire l’esecuzione dell’applicazione. Un template di pagina dinamica,
ad esempio un file JSP, esprime il contenuto della pagina nei termini del
linguaggio di markup scelto, solitamente HTML. Un descrittore di unit è un
file XML che esprime la relazione tra la unit WebML e il livello dei dati, per
esempio il nome del database e il codice della query SQL necessari per la
computazione del riempimento di una Index Unit.
Capitolo 5
Caso di studio
In questo capitolo viene mostrato il metodo di trasformazione proposto

attraverso un esempio pratico. Si parte da un diagramma BPMN per ot-
tenere un’applicazione web funzionante. Inoltre vengono mostrate, sempre
attraverso l’uso di casi di studio verosimili, le potenzialità delle funzionalità
introdotte a supporto della trasformazione.
L’applicazione che si vuole generare prevede l’interazione di uno studen-
te con un sistema automatico che si occupa di gestire l’iscrizione ai corsi di
laurea. Lo studente deve per prima cosa inserire i suoi dati. Poi, se viene
giudicato idoneo (tramite parametri quali l’effettivo conseguimento del diplo-
ma e la relativa valutazione), potrà visualizzare l’elenco dei corsi di laurea ai
quali può iscriversi. Scelto il corso, il sistema si occuperà di verificare se ci
sono ancora posti disponibili; in caso positivo lo studente dovrà immettere
i dati necessari per l’iscrizione. Infine il sistema provvederà ad inviare allo
studente la documentazione relativa all’iscrizione e a calcolare il contributo
dovuto.
Da queste specifiche si ricava il diagramma BPMN rappresentato in figura
5.1.
68
CAPITOLO 5. CASO DI STUDIO 69
Figura 5.1: Diagramma BPMN di partenza
5.1 Generazione dello scheletro dell’applica-

zione
Dopo che il diagramma che rappresenta il flusso di lavoro è stato definito,
si può avviare il processo di trasformazione. Tale processo permette di otte-
nere lo scheletro dell’applicazione web. Per scheletro si intende un modello
WebML contente gli elementi necessari alla gestione della logica del flusso di
lavoro, ma privo di contenuti adatti all’esecuzione delle attività. Nelle figure
5.2 e 5.3 si possono vedere due esempi di moduli generati attraverso quella
che si potrebbe chiamare “trasformazione semplice”.
Figura 5.2: Modulo corrispondente all’attività “Inserimento dati utente”
I due moduli rappresentati nelle figure saranno presi come riferimento per
mostrare i passaggi successivi alla prima trasformazione nei prossimi para-
grafi. A questo punto è già possibile generare il codice applicativo a partire

dal modello, sfruttando il generatore di codice di cui è dotato WebRatio.
Figura 5.3: Modulo corrispondente all’attività “Inserimento dati iscrizione”
Insieme alla module view contenente i moduli relativi alle attività e ai

gateway del diagramma, con la trasformazione viene generata una site view
necessaria allo svolgimento delle operazioni di base relative alla configurazio-
ne dell’applicazione. In particolare, sarà necessario sincronizzare la struttura
dati indicata nel data model del modello in WebRatio con le informazioni
derivanti dalla logica di workflow del diagramma. In particolare, in figura
5.4 è mostrata la pagina da cui è possibile effettuare l’operazione descritta.
Figura 5.4: Pagina di sincronizzazione tra logica di workflow e database
Si può inoltre utilizzare l’applicazione generata, accedendovi tramite un

browser qualsiasi; non essendo però stati inseriti i contenuti veri e propri dei
moduli all’interno del WebML, le pagine generate sono delle pagine “fittizie”,
ovvero consentono soltanto di confermare il completamento dell’attività sen-
za tuttavia svolgere il lavoro previsto. In figura 5.5 è mostrata una pagina
creata a partire dallo scheletro dell’applicazione, in particolare dal modu-

lo rappresentato in figura 5.2. Come si può vedere, l’utente può soltanto
confermare il completamento dell’attività o annullarne l’esecuzione.
Figura 5.5: Pagina generata dal modulo “Inserimento dati utente”
L’applicazione generata rispetta dunque i vincoli imposti dai requisiti di

business, ma non consente una reale esecuzione del processo. Una volta
generato il modello WebML è già possibile inserire il cruscotto di controllo
processi progettato attraverso il metodo descritto nel paragrafo 3.3.
5.2 Generazione basata su tipizzazione delle

attività
Come è stato descritto nel paragrafo precedente, la generazione di un
modello WebML a partire da un diagramma BPMN crea soltanto lo sche-
letro dell’applicazione web basata sul processo. Per questa ragione è stata
introdotta la funzionalità di tipizzazione delle attività.
Ipotizziamo che nella libreria dei tipi predefiniti siano già presenti alcuni
moduli relativi al contesto universitario, tra cui il tipo “Inserimento dati
utente”, relativo alla creazione di un nuovo studente nel database dell’ateneo.
Attraverso l’apposito menu nel pannello delle Properties dell’attività, si può
selezionare il tipo dell’attività scelta, come si può vedere in figura 5.6.
Figura 5.6: Scelta di un tipo predefinito
Si può ora procedere con il secondo passaggio della trasformazione, ovvero

la sincronizzazione del modello WebML a fronte delle modifiche effettuate
nell’editor BPMN. In figura 5.7 si vede come il modulo, che nella prima fase
di trasformazione non conteneva altro che uno scheletro dell’attività, ora
contiene delle unit che permettono all’utente di interagire col sistema e che
svolgono delle operazioni. In questo caso è stata inserita una Entry Unit che
permette allo studente che vuole iscriversi al corso di laurea di inserire i suoi
dati personali. Una volta compilato e confermato il modulo, questo viene
passato ad una Create Unit che inserisce i dati immessi nel database.
Per poter garantire il corretto mapping tra le unit inserite nel modulo
ed il modello dei dati, il processo di tipizzazione prevede l’inserimento delle
entità necessarie al funzionamento del modulo all’interno del modello dei
Figura 5.7: Modulo corrispondente all’attività “Inserimento dati utente”

dopo la tipizzazione
dati. Nel caso del tipo “Inserimento dati utente”, bisogna inserire l’entità
“Nuovo utente” (rappresentata in figura 5.8).
Figura 5.8: Modifiche al modello dei dati dopo la tipizzazione
Infine, si può generare nuovamente il codice dell’applicazione in modo

da poter visualizzare il risultato di questo semplice esempio di tipizzazione
attraverso l’uso di tipi predefiniti. Come si può vedere in figura 5.9, ora la
pagina fornisce all’utente gli elementi necessari per l’esecuzione dell’attività.
Lo screenshot presente in figura 5.9 è stato generato partendo dal modulo in
figura 5.7.
Figura 5.9: Pagina generata dal modulo “Inserimento dati utente” dopo la
tipizzazione
5.3 Raffinamento del modello

Bisogna tuttavia considerare il fatto che non tutti i tipi necessari alla
generazione completa dell’applicazione saranno presenti all’interno delle li-
brerie predefinite; per questo, l’intervento del designer WebML per inserire i
contenuti nei moduli non tipizzati si rende spesso necessario. In questo caso,
prendendo come riferimento l’attività “Inserimento dati iscrizione”, ipotiz-
ziamo che il modulo di partenza venga modificato fino ad ottenere quello
rappresentato in figura 5.10.
Come si può vedere, il designer ha semplicemente inserito, a livello di
interfaccia utente, una Entry Unit per l’inserimento delle informazioni neces-
sarie all’esecuzione dell’attività. Tuttavia, per permettere il salvataggio dei
dati inseriti in modo corretto, bisogna inserire le opportune entità e relazioni
nel modello dei dati. In questo caso, il designer è partito dall’entità creata
attraverso la tipizzazione descritta nel paragrafo precedente per estendere il
modello dei dati. Come si può vedere in figura 5.11, sono state create le
entità “Dati iscrizione” e “Corso di laurea”, e sono state collegate tra loro e
Figura 5.10: Modulo corrispondente all’attività “Inserimento dati iscrizione”

dopo la tipizzazione
con “Nuovo utente” attraverso opportune relazioni.
Figura 5.11: Modifiche al modello dei dati dopo la tipizzazione
Generando nuovamente l’applicazione dopo il raffinamento manuale dei

moduli non disponibili tra quelli predefiniti, si ottiene un’applicazione com-
pleta e funzionante. In figura 5.12 si può ad esempio vedere la pagina generata
a partire dal modulo appena progettato, rappresentato in figura 5.10.
Figura 5.12: Pagina generata dal modulo “Inserimento dati iscrizione” dopo
la tipizzazione
5.4 Salvataggio e riuso dei nuovi tipi

Dopo che è stata terminata la creazione dei nuovi moduli, si può utilizzare
la funzionalità di salvataggio per rendere i tipi creati disponibili all’uso al pari
di quelli predefiniti. Supponiamo ad esempio che alla fine delle modifiche al
modulo “Inserimento dati iscrizione” questo venga salvato attraverso l’appo-
sita operazione descritta nel paragrafo 3.2. Nel diagramma BPMN in figura
5.13, si può vedere come l’attività appena salvata sia presente all’interno del
flusso di lavoro di un altro processo.
Figura 5.13: Nuovo diagramma BPMN con attività comuni a quelle salvate
Grazie alla possibilità di salvataggio dei moduli personalizzati è quindi

possibile riutilizzare il modulo salvato precedentemente, ottimizzando quindi

i tempi di design dei moduli e riducendo il lavoro del designer. Si suppone
che, creata una libreria con un sufficiente numero di moduli personalizzati
dal designer dell’azienda, la maggior parte delle attività presenti nei processi
non debbano essere tipizzate in modo manuale.
Figura 5.14: Scelta di un tipo personalizzato

Capitolo 6
Lavori correlati
In [5] sono citati molti dei progetti che affrontano l’argomento di integra-
zione tra il design di applicazioni web e i processi di business. La motivazione
dell’esistenza di cosı̀ tanti gruppi di ricerca che si occupano della stessa pro-
blematica si basa sulla convinzione, comune e giustificata, che il paradigma
dell’interazione basata su web sia quello più indicato per l’implementazione
dell’interfaccia utente nel contesto dei processi aziendali.
Il PML (Process Modeling Language [19]) è una notazione molto imme-
diata per la descrizione di schemi di flusso di lavoro, molto simili a quelli
espressi attraverso la notazione BPMN. Nell’articolo citato viene spiegato
come una specifica espressa in PML possa essere tradotta in una semplice
web application che consente agli utenti di partecipare al processo ed ese-
guirne le attività. Gli ipertesti che vengono definiti sono concettualmente
molto vicini a quelli del presente lavoro. Ci sono tuttavia alcune differenze
sostanziali che distinguono l’approccio basato su PML da quello di questa
tesi:
1. il lavoro si basa sul linguaggio di modellazione WebML, dotato di una

notazione grafica, mentre il punto di partenza considerato in [19] è un
modello di processo semplificato, rappresentato con una sintassi simile
a quella dei linguaggi di programmazione;
2. i meccanismi di controllo del processo sono differenti: l’approccio trat-
78
CAPITOLO 6. LAVORI CORRELATI 79
tato in questa tesi si basa su un modello di riferimento dei processi

coerente con il modello dei dati di WebML, mentre nel caso del PML
il controllo viene effettuato da appositi strumenti, chiamati lightweight
process runtime;
3. infine, il PML non consente la personalizzazione delle interfacce: per

ogni attività viene generata solo una pagina, indipendentemente dalla
complessità dell’attività, mentre WebML consente un controllo quasi
totale sui moduli generati.
Tra le proposte relative al design di applicazioni web, OO-H [7] e UWE

[15] si occupano, come il presente lavoro, di integrazione con la gestione dei
processi. OO-H è un approccio parzialmente orientato agli oggetti, origina-
riamente concepito per applicazioni web con un gran numero di dati ma poi
esteso per l’uso delle applicazioni a supporto dei processi. Questa proposta
parte dalla fase di analisi dei requisiti per arrivare a quella di progettazio-
ne concettuale, processuale, degli aspetti di navigazione e di presentazione.
Il design della navigazione si basa sul diagramma NAD (Navigation Access
Diagram), utilizzato per esprimere la topologia dell’ipertesto.
UWE è un metodo di design orientato agli oggetti, nel quale l’ipertesto
di navigazione è modellato attraverso i diagrammi delle classi UML, estesi
con nuovi elementi che permettono di rappresentare in modo più preciso le
applicazioni web, rispetto alle classiche applicazioni per cui tali diagrammi
sono solitamente usati.
Successivamente, in [16], gli ideatori dei progetti OO-H e UWE hanno
proposto un approccio incrociato per l’integrazione dei processi con i model-
li di navigazione. In particolare, i due metodi hanno un punto d’incontro
relativamente alla fase di analisi dei requisiti, durante la quale i diagrammi
UML vengono usati per rappresentare i requisiti dell’applicazione rispetto al
modello di business. Nella fase di design, invece, OO-H propone la tradu-
zione semi-automatica da modello di processo a modello di navigazione, che
produce i diagrammi NAD; tali diagrammi rappresentano un mix tra le classi
e i collegamenti necessari per la navigazione ricavati dal modello di processo

e alcune primitive tratte dai requisiti di navigazione. Invece, utilizzando il
metodo UWE, si mantiene il modello di processo anche nella fase di design, e
il modello di navigazione si interfaccia a quello del processo attraverso classi
e collegamenti appositi, aggiunti al diagramma di navigazione.
L’approccio OOHDM [17] estende i contenuti dei modelli di navigazio-
ne con entità e nodi di attività, rappresentati tramite primitive UML. In
più, l’esecuzione del processo avviene all’interno di un contesto di navigazio-
ne che ne specifica le regole. L’approccio OOHDM si occupa inoltre della
modellazione di processi per applicazioni orientate al commercio elettronico
(e-commerce) [24].
Nel caso di WSDM [26], il design del processo è guidato dai requisisti del-
l’utente ed è basato sulla notazione ConcurTaskTrees. Il modello del processo
viene quindi specificato a livello concettuale. In particolare, durante la pri-
ma fase, quella di modellazione delle attività, viene specificata una gerarchia
in grado di rappresentare i rapporti di consequenzialità attraverso appositi
operatori. Nella seconda fase, quella di design concettuale, viene generata
una struttura di navigazione attraverso dei collegamenti tra i componenti,
basati sulla logica del processo.
L’estensione WAE UML proposta da Conallen [8] si concentra invece su-
gli aspetti implementativi ed architetturali, e non specifica esplicitamente
l’integrazione del processo con il design del modello di navigazione. In que-
sto metodo non si affrontano in modo diretto gli aspetti legati al flusso di
lavoro, ma si produce una particolare architettura dell’applicazione basata
sul posizionamento delle componenti software.
Un approccio alternativo è proposto in [25]: BPM (Business Process Ma-
nagement) e OOWS (Object Oriented Web Solution) vengono combinati per
modellare applicazioni basate sui processi; viene proposta una trasformazione
model-to-model (da un tipo di modello ad un altro) per generare il modello
di navigazione dalla definizione del modello di business, mentre un’ulteriore
trasformazione da modello a testo può produrre una definizione di processo
in linguaggi propri della gestione dei processi business (come ad esempio il

BPEL, Business Process Execution Language).
Rispetto ai vari approcci elencati, questo lavoro di tesi offre parecchi
vantaggi. L’obiettivo comune che ci si prefigge è quello di realizzare un’ap-
plicazione web; quindi, dalla fase di modellazione a quella di deployment,
si fa uso di elementi propri del design di applicazioni pensate appositamen-
te per un utilizzo distribuito. La scelta dello standard WebML, tuttavia,
rappresenta una svolta nel campo del design di web application. Inoltre, l’u-
tilizzo di nuove primitive che si occupano della gestione del flusso di lavoro
permette di ottenere degli ipertesti chiari e leggibili. Non è necessario, come
per molti degli altri approcci, introdurre collegamenti o utilizzare gli elementi
già esistenti del modello per gestire la logica del processo. In questo modo si
ottiene una separazione tra la progettazione degli aspetti di navigazione e di
presentazione e la gestione del workflow. Infine, la trasformazione proposta
consente al designer un controllo totale sui moduli generati. Di conseguenza
è possibile creare i contenuti delle attività in modo libero da vincoli, purché
vengano rispettate le regole imposte dal diagramma BPMN.
Capitolo 7
Conclusioni e sviluppi futuri
Questo lavoro di tesi ha l’obiettivo di migliorare le attuali tecnologie di

trasformazione da BPMN a WebML, grazie ad un metodo che consente di
mantenere sempre più separati gli aspetti di design da quelli di gestione del
flusso di lavoro.
La trasformazione progettata permette di ottenere rapidamente un’ap-
plicazione web funzionante a partire da un modello di processo. Tale tra-
sformazione produce un ipertesto dotato di nuove primitive WebML che si
occupano della gestione del flusso di lavoro. Queste nuove primitive con-
sentono di non dover inserire elementi relativi al workflow all’interno degli
ipertesti, rendendoli cosı̀ più leggibili e mantenibili. Il metodo di tipizzazione
proposto, inoltre, permette di ottenere i contenuti veri e propri dell’applica-
zione in modo rapido ed efficace. Infine, il cruscotto di controllo processi è un
primo esempio di come si possa affiancare all’applicazione vera e propria uno
strumento in grado di monitorare il sistema ed i suoi attori in modo efficace
ed utile.
Sono numerosi gli sviluppi futuri che derivano dal presente lavoro: in-
nanzitutto, allo stato attuale la trasformazione considera solo un insieme
degli elementi dei diagrammi BPMN: sarà dunque opportuno introdurre nel
linguaggio di modellazione WebML nuove primitive, al fine di ottenere un
meccanismo più completo. Sarà inoltre utile arricchire le librerie di moduli
82
CAPITOLO 7. CONCLUSIONI E SVILUPPI FUTURI 83
predefiniti per consentire una scelta più ampia al momento della tipizzazione,
in modo tale da rendere necessario il design solo nei casi più particolari. Il
terreno della generazione automatica di contenuti è ancora poco esplorato:
è dunque necessario verificare le sue reali potenzialità in maniera più appro-
fondita. Inoltre, il cruscotto di controllo rappresenta soltanto uno spunto
per la progettazione di sistemi di controllo più complessi, presumibilmente
parametrici e personalizzabili in base alle esigenze del contesto aziendale in
cui vengono collocati. Infine, sarà importante mettere in atto tutte le funzio-
nalità proposte e progettate in casi di utilizzo reale, per evidenziarne i punti
deboli e per ricavare i requisiti delle migliorie che sarà necessario apportare.
Bibliografia
[1] Roberto Acerbis, Aldo Bongio, Marco Brambilla, and Stefano Butti.
Webratio 5: An eclipse-based case tool for engineering web applications.
International Conference on Web Engineering (ICWE), 2007.
[2] Roberto Acerbis, Aldo Bongio, Marco Brambilla, Stefano Butti, Stefano
Ceri, and Piero Fraternali. Web applications design and development
with webml and webratio 5.0. TOOLS Europe, 2008.
[3] BPMI. Business process management initiative.

http://www.bpmi.org.
[4] Marco Brambilla. Generation of webml web application models from

business process specifications. International Conference on Web
Engineering (ICWE), 2006.
[5] Marco Brambilla, Stefano Ceri, Piero Fraternali, and Ioana Manolescu.
Process modeling in web applications. ACM Transactions on Software
Engineering and Methodology (TOSEM), 2006.
[6] Marco Brambilla, Sara Comai, Piero Fraternali, and Maristella Matera.
Designing web applications with webml and webratio. Modeling and
Implementing Web Applications (Human-Computer Interaction Series),
2007.
[7] Cristina Cachero and Jaime Gomez. Advanced conceptual modeling of

web applications: Embedding operation interfaces in navigation design.
21th International Conference on Conceptual Modeling (JISBD), 2002.
84
BIBLIOGRAFIA 85
[8] Jim Conallen. Building web applications with uml. Addison-Wesley,

2002.
[9] dom4j.
http://www.dom4j.org.
[10] Matteo Dosmi. Automatic generation of business process based web

applications. Master’s thesis, Politecnico di Milano, 2009.
[11] Eclipse. Eclipse bpmn modeler.

http://www.eclipse.org/bpmn.
[12] Google. Google chart api.

http://code.google.com/intl/it-IT/apis/chart.
[13] Groovy.
http://groovy.codehaus.org.
[14] Joda. Joda time api.

http://joda-time.sourceforge.net.
[15] Nora Koch and Andreas Kraus. The expressive power of uml-based
engineering. Second International Workshop on Web Oriented Software
Techonlogy (CYTED), 2002.
[16] Nora Koch, Andreas Kraus, Cristina Cachero, and Santiago Melia. In-
tegration of business processes in web application models. Journal of
Web Engineering, 2004.
[17] Fernando Lyardet, Gustavo Rossi, and Hans Albrecht Schmidt. Engi-
neering business processes in web applications: Modeling and naviga-
tion issues. Third International Workshop on Web Oriented Software
Technology, 2003.
[18] Andrea Martignoni and Francesco Sposato. L’automazione dei processi

in ambiente web-based: linee guida di integrazione tra tool di model-
BIBLIOGRAFIA 86
lazione e sistemi di workflow. Master’s thesis, Politecnico di Milano,

2007.
[19] John Noll and Walt Scacchi. Specifying process-oriented hypertext

for organizational computing. Journal of Network and Computer
Applications, 2001.
[20] OMG. Business process modeling notation (bpmn).

http://www.bpmn.org.
[21] OMG. Object management group.

http://www.omg.org.
[22] OMG. Unified modeling language (uml).

http://www.uml.org.
[23] Valentina Riva. Trasformazione automatica di modelli di processo: da

bpmn a webml. Master’s thesis, Politecnico di Milano, 2006.
[24] Gustavo Rossi and Hans Albrecht Schmidt. Modeling and designing
processes in e-commerce applications. IEEE Internet Computing, 2004.
[25] Victoria Torres and Vicente Pelechano. Building business process driven
web applications. Business Process Management, 2006.
[26] Olga De Troyer and Sven Casteleyn. Modeling complex processes for
web applications using wsdm. Third International Workshop on Web
Oriented Software Technology, 2003.
[27] W3C. Extensible markup language (xml).

http://www.w3.org/XML.
[28] WebML. The web modeling language.

http://www.webml.org.
[29] WebModels. Webratio.

http://www.webratio.com.
BIBLIOGRAFIA 87
[30] WebRatio. WebRatio User Guide.
[31] WfMC. Workflow management coalition.

http://www.wfmc.org.
[32] WfMC. Workflow process definition interface - xml process definition

language. Future Strategies Inc (WfMC Services) White Papers, 2001.
[33] Wikipedia. Api.

http://it.wikipedia.org/wiki/Application programming interface.
[34] Wikipedia. Modello e-r.

http://it.wikipedia.org/wiki/Modello E-R.
[35] Wikipedia. Repository.

http://it.wikipedia.org/wiki/Repository.

Lingua

Generazione Automatic A Di Applicazioni Web

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Generazione Automatic A Di Applicazioni Web

Caricato da

Copyright:

Formati disponibili

POLITECNICO DI MILANO

Facoltà di Ingegneria dell’Informazione

POLO REGIONALE DI COMO

Generazione automatica di applicazioni web

Relatore: Ing. Marco BRAMBILLA

Tesi di Laurea di:

Anno Accademico 2007/2008

POLO REGIONALE DI COMO

Automatic generation of web applications

Supervisor: Ing. Marco BRAMBILLA

Master Graduation Thesis by:

Academic Year 2007/2008

Questo lavoro di tesi si occupa della generazione completa di applicazioni

Vorrei innanzitutto ringraziare il Prof. Luigi Casalegno per avermi pro-

4.4 Cruscotto di controllo processi . . . . . . . . . . . . . . . . . . 62

7 Conclusioni e sviluppi futuri 82

Le applicazioni web, con il passare degli anni, stanno assumendo un ruo-

delle applicazioni web.

processo di trasformazione da un modello di business ad un modello di ap-

Lo scenario di questo lavoro di tesi è collocato a metà strada tra la gestione

2.1 Workflow e BPMN

• case: istanza di un processo, ovvero esecuzione reale del flusso di lavoro

• istanza di attività: come il case per il processo, indica una particolare

• vincolo: i vincoli servono ad indicare i criteri attraverso i quali vengono

• attore: entità che si occupa di svolgere il lavoro; non è necessariamente

UML, Unified Modeling Language [22], è un linguaggio di notazione de-

Business Process Management Notation

• forme di base (basic BPMN shapes):

– pool: è l’ambiente all’interno del quale si sviluppa il processo;

Figura 2.1: I principali elementi dei diagrammi BPMN

– lane: è una suddivisione del pool in sotto-categorie; serve a speci-

– start: rappresenta l’inizio del processo; è posto nella lane corri-

• gateway3 (gateway shapes):

– AND (parallel): le attività contenute tra due gateway di tipo AND

2.1.1 Eclipse BPMN Modeler

Figura 2.2: L’ambiente di sviluppo Eclipse e il BPMN Modeler

2.2 WebML e WebRatio

• esprimere la struttura di un’applicazione web con una descrizione di

• fornire più viste diverse per gli stessi contenuti;

• separare il contenuto informativo dalla sua composizione in pagine e da-

• salvare le meta-informazioni raccolte durante il processo di design in

un repository 4 , che può essere usato durante la vita dell’applicazione

• modellare utenti e gruppi di utenti esplicitamente nel repository, per

• consentire la specifica delle operazioni di manipolazione dei dati per

Gli elementi principali di un modello WebML sono tre: il modello dei

Figura 2.3: Esempio di modello dei dati in WebML

Figura 2.4: Esempio di modello di ipertesto in WebML

specifiche WebML codificate come documenti XML e come output le pagine

• a partire dal modello logico (dell’ipertesto) vengono generate tutte le

• a partire dal modello di presentazione vengono generate tutte le pagine

Il codice generato da WebRatio è completamente personalizzabile. Le

Figura 2.5: Il funzionamento di WebRatio

2.2.1 BPMN Modeler in WebRatio

luppo tutte le fasi della generazione dell’applicazione basata su workflow. In

Figura 2.6: Eclipse BPMN Modeler integrato in WebRatio

2.3 Tecnologie di trasformazione

• la topologia dei collegamenti non può esprimere da sola i vincoli in caso

• la condivisione dei dati integra le informazioni relative al processo

• entrambe le tecniche sfruttano i collegamenti di navigazione: in questo

• la condivisione dei dati prevede l’inserimento nell’ipertesto di opera-

• alterare il modello di processo di partenza implica modifiche sia a livello

specifiche; questo rappresenta un freno per l’evoluzione del processo

Lo scopo del presente lavoro è la progettazione di un metodo di tra-