Sei sulla pagina 1di 94

POLITECNICO DI MILANO

Facoltà 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
Facoltà 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 è 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 è stata utilizzata la notazione
BPMN. Questa è stata estesa con una nuova proprietà, chiamata tipizzazione,
che permette di specificare per ogni attività la tipologia di azione da svolgere.
Ciò consente una generazione più precisa del modello dell’applicazione.
Inoltre, questa tesi affronta la problematica relativa al controllo dello stato
dei processi aziendali; è 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ı̀ più leggibile e mantenibile. L’applicazione creata
rispetta i vincoli imposti dal flusso di lavoro e permette agli attori del processo
di svolgere le attività 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 professionalità, 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 è 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 attività . . . . . . . . . . . . . . . . . . . . 35
3.2.1 Specifica dei requisiti . . . . . . . . . . . . . . . . . . . 37
3.2.2 Progettazione . . . . . . . . . . . . . . . . . . . . . . . 38
3.3 Cruscotto di controllo processi . . . . . . . . . . . . . . . . . . 43
3.3.1 Specifica dei requisiti . . . . . . . . . . . . . . . . . . . 44
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 attività . . . . . . . . 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 più 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 più spesso situate in diverse città o addirittura in diversi paesi.
La necessità di avere degli strumenti che consentano di fornire un adeguato
sostegno nella gestione di tali processi porta inevitabilmente all’esplorazione
del terreno ad oggi più 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 potenzialità

1
CAPITOLO 1. INTRODUZIONE 2

delle applicazioni web.


Nel contesto dei processi aziendali, è sempre più frequente la necessità
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 funzionalità 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 è ovviamente da
affrontare in modo esauriente e con un approccio ingegneristico, quindi è 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 modalità 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 è 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 è 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 funzionalità 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 più 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 è 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 è collocato a metà 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 più 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 già 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 dualità
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, è 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 attività. 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;

• attività: indica l’unità di lavoro che deve essere eseguita; l’insieme delle
attività e dei collegamenti tra loro vanno a costituire il processo;

• istanza di attività: come il case per il processo, indica una particolare


esecuzione di un’attività. Diversamente dall’attività, che è un concetto
astratto, l’istanza di attività è 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 possibilità offerte dal workflow; è in base ai vincoli che
viene gestita la reale esecuzione di un processo;

• attore: entità che si occupa di svolgere il lavoro; non è necessariamente


un essere umano, può anche essere un sistema informatico se ad esempio
l’attività da eseguire è di tipo automatico.

Modelli di workflow
Esistono diversi modelli in grado di descrivere il flusso di lavoro in modo
rigoroso; i più usati sono UML, XPDL e BPMN.
CAPITOLO 2. BACKGROUND 6

UML, Unified Modeling Language [22], è 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 potenzialità trovano spazio nel supporto del ciclo di vita del
software.
XPDL [32] è invece una notazione basata sui grafi1 . Le attività sono
rappresentate come i nodi del grafo, mentre gli archi rappresentano i passag-
gi da un’attività ad un’altra. Queste transizioni possono essere soggette a
condizioni.
Il riferimento per il presente lavoro è tuttavia la notazione BPMN.

Business Process Management Notation


La notazione BPMN [20] è 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 è stata creata è 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: è l’ambiente all’interno del quale si sviluppa il processo;


solitamente il nome del pool corrisponde a quello del processo;
1
Un grafo è 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.
CAPITOLO 2. BACKGROUND 7

Figura 2.1: I principali elementi dei diagrammi BPMN

– lane: è 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) è incaricato di svolgere le attività;
– attività (task): l’attività rappresenta una delle operazioni da com-
piere all’interno del processo; se l’attività non è atomica può essere
rappresentata come sotto-processo (sub-process);
– connettore di flusso (flow connector): freccia necessaria per indi-
care i rapporti di consequenzialità tra le attività e tra attività e
gateway (trattati successivamente);

• eventi (events):

– start: rappresenta l’inizio del processo; è 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;
CAPITOLO 2. BACKGROUND 8

• gateway3 (gateway shapes):

– AND (parallel): le attività contenute tra due gateway di tipo AND


devono essere tutte eseguite; in caso contrario il workflow non può
proseguire;
– OR (exclusive): deve essere eseguita almeno un’attività tra quelle
presenti tra due gateway OR; è sufficiente il completamento di
un’attività per poter passare all’attività 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 può vedere uno screenshot in figura 2.2) è
possibile modellare i diagrammi BPMN che rappresentano il flusso di lavoro.
Questo strumento è dotato di caratteristiche di estensibilità e integrabilità
con altre piattaforme. Il tool rappresenta la base dell’integrazione dei dia-
grammi BPMN con le applicazioni web. Nel paragrafo 2.2.1 verrà descritto
più dettagliatamente come l’Eclipse BPMN Modeler viene utilizzato come
punto di partenza della trasformazione all’interno dell’ambiente di sviluppo
WebRatio.

3
Un gateway è un elemento che consente di controllare il workflow, ovvero come e
quando il processo si suddivide e si ricongiunge.
CAPITOLO 2. BACKGROUND 9

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 più 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


CAPITOLO 2. BACKGROUND 10

un repository 4 , che può 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 è 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 Entità-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 entità, ovvero i contenitori degli elementi dei
dati, e le relazioni, definite come connessioni semantiche tra entità. Le entità
hanno delle proprietà dotate di nome e tipo, chiamate attributi. Le entità
possono essere organizzate in gerarchie e le relazioni possono essere regolate
da vincoli di cardinalità. Le entità 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 può essere italianizzato con il termine reposito) è 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].
CAPITOLO 2. BACKGROUND 11

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 è associata ad un’entità sottostante, dalla quale viene prelevato il
contenuto informativo. In alcuni casi è utile associare alla unit un selettore,
per specificare quali istanze delle entità devono essere considerate. La navi-
gazione del sito è 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 più 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 è necessario per definire l’aspetto delle pagine.
WebML non include un modello specifico per esprimere la presentazione a
livello concettuale, ma utilizza approcci standard, più familiari agli esper-
ti di grafica e comunicazione. Dato che le specifiche WebML possono essere
rappresentate usando XML [27], la presentazione è 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 è 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
CAPITOLO 2. BACKGROUND 12

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 è 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 è rappresentata la logica di generazione di un’applicazione
web tramite WebRatio. Per prima cosa è 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 è 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 è anche possibile connettersi ad un database già esistente e rico-
struire automaticamente il corrispondente modello dei dati. E’ possibile
definire più 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 funzionalità.
CAPITOLO 2. BACKGROUND 13

• 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 più
diffusi standard: HTML, CSS, Flash, AJAX.

Il codice generato da WebRatio è completamente personalizzabile. Le


personalizzazioni non avvengono sul codice generato ma sulle regole di ge-
nerazione. WebRatio è un ambiente di sviluppo aperto, dove l’utente può
definire i propri componenti e le proprie regole di generazione.
WebRatio è 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 è stato integrato nella
piattaforma WebRatio al fine di poter gestire da un unico ambiente di svi-
CAPITOLO 2. BACKGROUND 14

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


figura 2.6 uno screenshot del modellatore. Si può notare come il pannello delle
Properties sia stato modificato per poter specificare alcune informazioni ag-
giuntive sulle attività, necessarie per impostare la trasformazione progettata
(vedi capitolo 3).

Figura 2.6: Eclipse BPMN Modeler integrato in WebRatio


CAPITOLO 2. BACKGROUND 15

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 è quello di associare ogni attività ad una o
più pagine web, e mostrare agli utenti un collegamento alla pagina iniziale
dell’attività solo quando i vincoli del processo consentono all’utente di ese-
guire tale attività. Questa soluzione è quella più immediata per garantire
la sequenzialità della navigazione. La topologia dell’ipertesto è usata per
rinforzare i vincoli di precedenza tra le attività desiderati. Questo tipo di
approccio è 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
è quella di codificare l’avanzamento del case (ovvero l’istanza reale di un
processo), ad esempio l’avvio e la conclusione delle istanze di attività, nella
struttura dati. In questo modo, la sincronizzazione all’interno di ogni site
view6 è garantita ancora dai collegamenti, mentre la sincronizzazione tra una
site view e la successiva/precedente è ottenuta salvando lo stato delle attività
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 è un raggruppamento di pagine all’interno di un modello WebML.
Suddividere l’applicazione in site view è utile per fornire a diversi gruppi di utenti diverse
modalità di accesso all’applicazione.
CAPITOLO 2. BACKGROUND 16

basate sul flusso di lavoro è quello di estendere il modello WebML con delle
nuove primitive7 in grado di gestire le attività ed i case, recuperare le infor-
mazioni necessarie per l’esecuzione delle attività 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 è 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 però diverse controindicazioni:

• la topologia dei collegamenti non può esprimere da sola i vincoli in caso


di processi con più di un attore;

• la condivisione dei dati integra le informazioni relative al processo


con quelle dell’applicazione, rendendo più 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 è evidenziata nell’ipertesto, il quale viene dunque reso
più 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, può essere vista come una combinazione di concetti WebML
elementari.
CAPITOLO 2. BACKGROUND 17

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, è 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 è 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 è 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) è pos-


sibile assegnare un tipo alle attività 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) è possibile progettare e modellare i contenuti dei
moduli che rappresentano le attività personalizzate;

4. successivamente è possibile salvare questi moduli personalizzati in una


o più librerie utente, in modo da poterli riutilizzare nella fase 2 per dia-
grammi BPMN contenenti attività analoghe a quelle già implementate;

18
CAPITOLO 3. DA BPMN A WEBML 19

5. attraverso il generatore automatico di codice di cui WebRatio è dotato


è possibile ottenere il codice applicativo.

In figura 3.1 si può 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 è possibile, qualora le attività del diagramma


di partenza siano tra quelle tipiche dei processi (e quindi presenti nella libre-
ria di attività fornita insieme all’editor), generare un’applicazione completa
molto rapidamente. In questo modo l’utente può 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-
tività più particolari, al designer toccherà soltanto inserire dei contenuti nei
moduli corrispondenti a tali attività. Un altro aspetto innovativo del presen-
te lavoro è la possibilità 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 attività, nel caso in cui i processi
CAPITOLO 3. DA BPMN A WEBML 20

aziendali contengano attività 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 attività
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 dovrà, attraverso la piattaforma WebRatio, inserire
dei contenuti nei moduli fino a questo punto vuoti. Inoltre, potrà salvare i
moduli creati in modo da permetterne il successivo riuso.
Nel secondo caso invece l’esperto BPMN potrà 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.


CAPITOLO 3. DA BPMN A WEBML 21

Figura 3.3: Generazione completa dell’applicazione basata sulla tipizzazione

Nel primo caso, dato che le attività sono strettamente legate alle politiche
aziendali, non è possibile in fase di modellazione BPMN consentire all’ana-
lista business di scegliere tra attività già pronte. Sarà dunque necessario
modellare manualmente i moduli richiesti. L’aspetto innovativo, in questo
caso, riguarda la possibilità di salvare i moduli implementati in apposite li-
brerie, in modo da renderli riusabili al momento della modellazione di altri
processi contenenti attività analoghe.
Nel secondo caso, con attività ad esempio quali “Ricerca esame” o “Scel-
ta appello”, i moduli corrispondenti sono tipici del contesto universitario e
quindi spesso utilizzati. Dare la possibilità di scegliere all’interno di una li-
breria di attività già implementate, al momento della creazione del diagram-
ma nel tool BPMN, rappresenta un’innovazione che rende la generazione
dell’applicazione finale più semplice e veloce.
E’ possibile inoltre ottenere il risultato finale come combinazione tra i due
approcci citati: se per processi precedenti sono già 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 funzionalità
progettate ed implementate.
CAPITOLO 3. DA BPMN A WEBML 22

3.1 Trasformazione da BPMN a WebML


Una volta che i diagrammi che rappresentano il flusso di lavoro sono stati
definiti, è possibile effettuare la trasformazione attraverso un’apposita fun-
zionalità dell’ambiente di sviluppo (nel caso del presente lavoro WebRatio),
al fine di ottenere lo scheletro di un progetto web. Il risultato sarà 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 è 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 dovrà 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 entità/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-
vità 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 entità necessarie alla gestione e al


controllo dei processi;
CAPITOLO 3. DA BPMN A WEBML 23

• deve essere possibile gestire utenti e gruppi di utenti e le loro associa-


zioni con le entità 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’attività è in parallelo con un’altra, l’attività successiva non potrà 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 attività in parallelo, la pagina successiva,
corrispondente all’attività successiva, non sarà accessibile fino a quando tutte
le operazioni relative alle due pagine precedenti non saranno state svolte.
Questo fa immaginare la quantità di regole di cui il modello web dovrà 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’attività successiva

Il modello generato deve anche integrare un sistema di decisione in gra-


do di stabilire, al termine dell’esecuzione di un’attività, quale sia il passo
successivo del processo. In particolare, tale sistema deve valutare:

• quali sono le scelte possibili al termine dello svolgimento di un’attività;

• se le condizioni per le quali queste scelte possono essere eseguite sono


rispettate (ad esempio il fatto che attività precedenti in parallelo con
quella appena eseguita siano concluse);

• se è necessaria la scelta di un utente o se i vincoli di workflow impongono


una decisione univoca;
CAPITOLO 3. DA BPMN A WEBML 24

• se l’attività successiva prevede l’interazione con un operatore o meno


(in caso negativo questa potrà partire in automatico).

3.1.2 Progettazione
Modello dei dati

Il modello dei dati progettato è rappresentato in figura 3.4 sotto forma


di diagramma ER1 . Le entità2 necessarie alla gestione del workflow sono le
seguenti:

• Process: il processo è l’entità attorno alla quale ruota tutto il flusso


di lavoro; ad ogni diagramma BPMN corrisponde una e una sola riga
nella tabella corrispondente a questa entità. 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 è stato creato ma non è ancora entrato
in esecuzione
2. Executing: il case è attualmente in esecuzione (almeno la
prima attività ha avuto inizio)
1
il diagramma ER, o entità-relazione, è un modello per la rappresentazione concettuale
dei dati; per ulteriori informazioni si veda [34].
2
Rappresentano classi di oggetti che hanno proprietà comuni ed esistenza autonoma ai
fini dell’applicazione di interesse. Un’occorrenza di un’entità è un oggetto della classe che
l’entità rappresenta [34].
CAPITOLO 3. DA BPMN A WEBML 25

Figura 3.4: Il modello dei dati

3. Suspended: il case è stato sospeso (non possono esserci atti-


vità in esecuzione)
4. Concluded: il case è concluso (tutte le attività necessarie al
completamento del case sono state completate)
– startedTimeStamp: indicatore temporale della prima volta che il
case è stato messo in esecuzione
– concludedTimeStamp: data e ora di conclusione del case
CAPITOLO 3. DA BPMN A WEBML 26

• 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 è avve-
nuto

• ActivityType: entità necessaria per la costruzione di un processo.


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

– name: nome dell’ActivityType; corrisponde al nome dell’attività


inserito nel diagramma BPMN
– description: breve descrizione dell’attività
– execution: modalità di esecuzione; questo attributo può avere solo
due valori:
1. Manual: l’attività deve essere eseguita da un utente reale
2. Automatic: l’attività è costituita da una serie di operazioni
che non richiedono l’intervento di un utente

• Condition: questa entità serve per descrivere le condizioni che rego-


lano il passaggio da un’attività ad un’altra; in presenza di gateway è
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 è la registrazione cronologica delle operazioni che vengono
eseguite, nel caso specifico si è scelto di considerare soltanto i cambiamenti del valore dello
stato.
CAPITOLO 3. DA BPMN A WEBML 27

– 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’entità concreta sulla quale
l’utente interviene. Questi sono i suoi attributi:

– type: numero che corrisponde all’identificatore del tipo di attività


– status: stato attuale dell’istanza (vedi l’attributo status dell’entità
Case per l’elenco degli stati possibili)
– startedTimeStamp: timestamp della prima volta che l’attività
entra in stato di esecuzione
– concludedTimeStamp: indicatore dell’istante temporale in cui l’at-
tività viene portata a termine

• ActivityLogEntry: equivalente di CaseLogEntry per le attività. I


suoi attributi sono:

– entryStatus: nuovo stato in cui viene posta l’attività


– entryTimeStamp: istante temporale in cui avviene il passaggio di
stato

• ParameterType: un’attività può avere dei parametri in entrata o in


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

– name: nome del parametro


– description: breve descrizione del parametro
CAPITOLO 3. DA BPMN A WEBML 28

– 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 è il seguente:

– value: attributo che dà vita al parametro, ovvero valore effettiva-


mente inserito durante l’uso dell’applicazione

Inoltre vi sono le seguenti entità, 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 può 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, è necessario
suddividerli in gruppi. In questo modo si può stabilire quali gruppi
di utenti abbiano accesso a quali site view dell’applicazione. L’unico
attributo rilevante è:

– 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) è utile per la
gestione degli accessi degli utenti. Gli attributi sono:

– moduleID: identificatore della site view


CAPITOLO 3. DA BPMN A WEBML 29

– moduleName: nome della site view

Per quanto riguarda le relazioni prese in considerazione si ometterà la


lunga (e piuttosto intuitiva) lista; ecco tuttavia una serie di informazioni sui
rapporti tra le varie entità descritte, utile per capire le dinamiche interne al
data model:

• l’entità attorno alla quale ruota il sistema è il Process;

• ogni Process può essere istanziato da più Case;

• un Process è costituito da una serie di ActivityType collegati tra loro;

• ogni ActivityType può essere collegato al successivo/precedente at-


traverso una particolare condizione (ad esempio: “Acquista libro” è
collegato a “Calcola sconto” attraverso la condizione con espressione
“totaleOrdine > 10”);

• ogni ActivityType può avere più ParametrType di input/output;

• ogni ActivityType può essere istanziato da più ActivtyInstance, una per


ogni Case del Process che contiene l’ActivityType. Questa affermazione
è valida in assenza di loop 4 ; nel caso della presenza di loop possono
esserci più istanze di un’attività all’interno dello stesso Case;

• un ParameterType può essere input per più ActivityType ma può essere


output solo di un ActivityType;

• le entità 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 è un ciclo, ovvero una serie di attività che in determinate condizioni possono
essere ripetute all’interno di uno stesso Case; la possibile presenza di loop è comunque già
visibile dal diagramma BPMN di partenza.
CAPITOLO 3. DA BPMN A WEBML 30

• l’esecuzione reale è espressa attraverso le entità 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 è un’istanza di un ActivityType con esecuzione


manuale, viene eseguita da uno e un solo User

• uno User può tuttavia eseguire un numero illimitato di ActivityInstan-


ce;

• un ActivityType viene assegnato ad uno o più Group; il che significa che


l’User che eseguirà l’istanza di un certo ActivityType dovrà appartenere
ad un Group assegnato allo stesso ActivityType;

• uno User appartiene ad un Group principale (DefaultGroup) ma può


appartenere a più Group;

• ogni Group ha accesso ad un Module principale (DefaultModule) ma


può avere accesso a più Module;

Sono state inoltre inserite due entità 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 è stata inserita un’ultima entità, ConfigurationParameter, che
serve per il testing del funzionamento del cruscotto di controllo (vedi 3.3 e
4.4).
5
un’entità volatile è un’entità 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.
CAPITOLO 3. DA BPMN A WEBML 31

Generazione del modello

Una volta che è stato fissato il modello dei dati del WebML finale, è possi-
bile definire i passaggi attraverso i quali avviene il cuore della trasformazione,
ovvero la generazione del modello.
Nella figura 3.5 è rappresentato un esempio di diagramma BPMN creato
con il Modeler in ambiente WebRatio. Un esempio simile verrà trattato in
dettaglio nel capitolo 5, dalla fase di creazione del diagramma di workflow
alla generazione del modello con attività tipizzate e cruscotto di controllo.
Attraverso la trasformazione verrà 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 attività 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 attività


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’attività. La Input Collector Unit è poi collegata
ad una pagina che contiene uno scheletro del contenuto del modulo per le
6
La Input Collector Unit è 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].
CAPITOLO 3. DA BPMN A WEBML 32

attività 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’attività 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 attività o gateway manuali, ovvero do-


ve è richiesto l’intervento dell’utente, è presente una particolare componente,
chiamata Activity Info, che permette di ottenere in modo rapido le infor-
mazioni basilari sull’istanza di attività 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’attività.
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 attività è
CAPITOLO 3. DA BPMN A WEBML 33

possibile eseguire. Questa unit va ad analizzare i vincoli da rispettare e a


valutare le condizioni per le quali un’attività può essere eseguita, utilizzando
i parametri effettivamente in gioco. Inoltre, se la fine dell’attività implica
l’esecuzione di una e una sola attività e questa è di tipo automatico, la Next
Activity Unit è in grado di lanciare direttamente l’esecuzione dell’attività
successiva. Il funzionamento di questa particolare unit è stato trattato in
modo più approfondito in [10].

Figura 3.7: Moduli generati (2 di 3)

Gateway

Per chiarire il funzionamento dei gateway è necessaria una piccola paren-


tesi. Questi elementi, necessari a gestire le varie diramazioni del flusso di
lavoro, vengono trasformati in moduli proprio come le attività (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
CAPITOLO 3. DA BPMN A WEBML 34

la scelte tra le attività possibili e a passare di conseguenza all’attività sele-


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

Figura 3.8: Moduli generati (3 di 3)


CAPITOLO 3. DA BPMN A WEBML 35

3.2 Tipizzazione delle attività


Quando si parla di tipizzazione delle attività, si intende il processo trami-
te il quale i moduli che rappresentano gli ActivityType vengono “riempiti”
con dei contenuti. Per capire qual’è l’importanza e l’innovatività della ti-
pizzazione bisogna ricordarsi che una trasformazione pura ha come risultato
un’applicazione web che rispetta i vincoli espressi nel diagramma BPMN, ma
è compito del designer inserire dei contenuti all’interno delle attività.
Per mostrare i vantaggi di questa nuova funzionalità 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, è in grado di riempire i moduli
che rappresentano le attività con dei contenuti.

Figura 3.9: Esempio di modulo non tipizzato

Attraverso il processo di tipizzazione sarà possibile assegnare già nel tool


BPMN un tipo ad ogni attività; questo verrà scelto all’interno di una libre-
ria di attività predefinite, pre-implementate e fornite insieme al tool stesso.
Alla libreria predefinita potranno essere aggiunte delle librerie contenenti dei
CAPITOLO 3. DA BPMN A WEBML 36

moduli personalizzati, implementati dai designer WebML presso l’azienda o


esterni. In questo modo si andrà ad arricchire sempre di più la collezione di
moduli e di conseguenza la possibilità 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 attività 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 attività già presenti nelle librerie


(predefinite o personalizzate), prima di effettuare la trasformazione si
può assegnare ad ogni attività un tipo “preconfezionato”, scelto all’in-
terno di una libreria. Se le attività sono già state tutte implemen-
tate precedentemente non è necessaria alcuna competenza a livello di
WebML per ottenere un’applicazione completa e funzionante;

2. se le attività non sono presenti nelle librerie, è necessario l’intervento


di un designer: questo può, una volta ottenuta la struttura (vuota o
tipizzata solo per alcune attività) 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 attività implementate, non
sarà 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’attività


“Ricerca esame”. Questa attività, 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 è possibile fare attraverso la tipizzazione. Nei prossimi paragrafi
(soprattutto nel paragrafo 3.2.2) verrà descritto in dettaglio come è stata
progettata questa funzionalità.
CAPITOLO 3. DA BPMN A WEBML 37

Figura 3.10: Modulo tipizzato

3.2.1 Specifica dei requisiti


Per maggiore chiarezza d’ora in poi si parlerà di tipi predefiniti quando ci
si riferisce alle attività 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 attività non devono subire


variazioni una volta che è stato assegnato un tipo al modulo;

• i moduli tipizzati potranno richiedere l’uso di entità o relazioni non pre-


senti nel data model di base; di conseguenza sarà 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 quantità di tipi già implementati; i passaggi attraverso i
quali avviene il processo di trasformazione abbinato alla tipizzazione sono i
seguenti:
CAPITOLO 3. DA BPMN A WEBML 38

1. creazione del diagramma BPMN;

2. scelta del tipo per le attività già 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 è più complicato.
Nel caso di generazione senza l’uso dei tipi, quello che si ottiene non è
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. Sarà
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
ciò che è richiesto è aggiungere o rimuovere dei moduli.
Quando però le attività hanno un tipo, è necessario che questo venga
mantenuto anche a fronte di modifiche del diagramma BPMN; ovviamente
questo deve accadere soltanto per le attività che non vengono rimosse dal
diagramma.
E’ quindi molto importante garantire la stabilità del modello web anche
nel caso in cui sia stata utilizzata la tipizzazione.

3.2.2 Progettazione
Entriamo ora nel dettaglio di come è stato progettato il processo di
tipizzazione.
CAPITOLO 3. DA BPMN A WEBML 39

Per prima cosa andiamo ad analizzare come vengono trasformate le at-


tività senza l’utilizzo della tipizzazione, applicando una trasformazione sem-
plice da BPMN a WebML. Innanzitutto, ad ogni attività, o meglio, ad ogni
ActivityType, corrisponde un modulo con lo stesso nome dell’attività 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 andrà ad agire la tipizzazione. Si ricorda
infatti che nessuna attività è a conoscenza delle informazioni sul flusso di
lavoro, ma la gestione di questo è delegata alla speciale Next Activity Unit
(vedi 3.1.2, [10]).

Figura 3.11: Modulo di un’attività automatica privo di tipizzazione

In una trasformazione priva di tipizzazione, quello che si ottiene dalle


attività sono degli stub 7 dei moduli che le rappresentano. Il contenuto in-
serito in automatico rende comunque l’attività eseguibile secondo i vincoli
del workflow, ma non vi sono reali operazioni che l’utente può svolgere o che
vengono svolte in automatico. L’utente può avviare o concludere un’attività
in modo fittizio, senza effettivamente svolgere il lavoro previsto dalla stessa.
Tuttavia, generare un’applicazione non tipizzata può essere utile quando si
vuole testare la corretta impostazione del diagramma BPMN, soprattutto
nel caso di processi complessi.
Lo stub di un’attività manuale è rappresentato in figura 3.9, mentre quello
di un’attività automatica in figura 3.11.
7
Uno stub, nell’informatica, è una sorta di bozza del contenuto reale che andrà poi
implementato.
CAPITOLO 3. DA BPMN A WEBML 40

Per descrivere come è 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 attività, gli eventi, si imposta il flusso di lavoro,
si indicano i parametri e si impostano come input/output delle attività crea-
te. A questo punto, se sono già stati salvati dei moduli personalizzati, o se
nelle librerie fornite con il tool sono presenti moduli applicabili alle attività
create, nel pannello delle Properties relativo all’attività selezionata si può
scegliere, da un menu a tendina, il tipo di interesse (vedi figura 3.12). Nella
figura, per semplicità, sono stati pre-caricati solamente due tipi, ma l’utente
troverà nel menu corrispondente al Type tutte le attività già utilizzabili, sia
quelle predefinite che quelle personalizzate precedentemente salvate.

Figura 3.12: Scelta del tipo di un’attività

A questo punto è possibile sfruttare la trasformazione per ottenere lo sche-


letro dell’applicazione. Diversamente dalla trasformazione semplice, per le
attività delle quali si è 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’attività non si è selezionato il tipo, il modulo generato
sarà 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 è coerente con i requisiti di business. Ad esem-
pio, è possibile che l’attività “Ricerca Esame”, nel contesto del Politecnico
di Milano, possa richiedere più o meno parametri della stessa nel contesto di
CAPITOLO 3. DA BPMN A WEBML 41

un’altra università. Terminate le operazioni di design dei moduli, attraverso


un’apposita funzionalità introdotta è possibile salvare il modulo implemen-
tato (vedi figura 3.13). Si noti che questa operazione può 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 può 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 può 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 attività tipizzate possono
creare dei problemi quando il diagramma BPMN viene modificato e si cerca
di aggiornare successivamente il modello WebML.
CAPITOLO 3. DA BPMN A WEBML 42

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-
vità alla quale si vuole assegnare il tipo dovrà avere le stesse caratteristiche.
Un’attività di ricerca di un esame che preveda come uscita altre informazioni
rispetto al codice dell’esame potrà essere implementata manualmente (esten-
dendo o modificando, se esiste, un’attività simile) e successivamente salvata.
Per continuare con l’esempio della ricerca di un esame si può pensare a di-
versi tipi che rappresentino diverse interfacce della stessa attività, 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).
CAPITOLO 3. DA BPMN A WEBML 43

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 attività 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 può in alcuni
casi essere elevato, cosı̀ come il numero di attività e di utenti in gioco, si
pone il problema del controllo dello stato del sistema. E’ infatti importante
avere la possibilità di monitorare e visualizzare le informazioni su quello che
sta attualmente accadendo.
Inoltre è opportuno tenere traccia di quanto avviene anche a fini stati-
stici. Se per esempio un case sta richiedendo un tempo di esecuzione molto
più elevato di quello medio impiegato dagli altri case dello stesso processo,
è probabile che ci si trovi ad un punto di stallo. Le informazioni di tipo
statistico aiutano dunque ad evidenziare eventuali criticità e problemi.
Il cruscotto di controllo processi nasce sulla base delle considerazioni
appena fatte, ed è stato progettato per far fronte alle seguenti esigenze:

• monitorare lo stato attuale del sistema;

• valutare le prestazioni degli attori in gioco;

• evidenziare eventuali criticità 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 è stato progettato.
CAPITOLO 3. DA BPMN A WEBML 44

3.3.1 Specifica dei requisiti


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 verrà 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 è utile rappresentare in modo veloce ed intuitivo
il numero di case e di attività 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 entità in stato di
esecuzione.

Valutare le prestazioni degli attori in gioco

In questo caso il punto di vista da considerare è quello degli utenti: è


importante poter valutare i tempi medi di esecuzione delle attività per ogni
singolo utente, per ricavare informazioni sulle prestazioni. Tali dati possono
essere utilizzati a diversi scopi:

• capire se un utente si trova in difficoltà ad eseguire alcuni tipi di attività;

• individuare comportamenti non efficienti da parte di qualche utente;

• ottimizzare le prestazioni di ogni utente riassegnando le attività in base


alle prestazioni.

Evidenziare eventuali criticità all’interno dei processi

Un altro aspetto molto importante è legato agli indicatori temporali medi


e in tempo reale relativi ad attività e case.
Con un’analisi statistica è infatti possibile individuare in modo molto
veloce se un determinato processo presenta problemi di varia natura:
CAPITOLO 3. DA BPMN A WEBML 45

• alcune attività durano molto di più 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 necessità di effettuare analisi di business sui processi aziendali.
Dal punto di vista gestionale, avere la possibilità di accedere in modo veloce
ed intuitivo ad una serie di informazioni su processi, case, tipi ed istanze
di attività rappresenta un potente strumento di studio, fondamentale per il
miglioramento nella gestione del workflow.

3.3.2 Progettazione
Il cruscotto di controllo processi è 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 sarà 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. Affinché il cruscotto possa essere aggiunto è 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
CAPITOLO 3. DA BPMN A WEBML 46

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.
CAPITOLO 3. DA BPMN A WEBML 47

le operazioni previste dal cruscotto.


Grazie all’uso di uno wizard, è possibile inoltre selezionare quali elemen-
ti del cruscotto aggiungere secondo le specifiche esigenze. In questo modo
l’utente può 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 entità scelte, op-
pure di visualizzare un insieme più ristretto delle informazioni disponibili
su un’entità. 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 più strettamente progettuali relativi alla site
view del cruscotto.
La home page, chiamata Overview, è 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 attività 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 può 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 attività al momento in esecuzione che
fanno parte del case scelto. In modo analogo, scegliendo un’attività 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 sarà trattata successivamente, nei paragrafi alla fine di


questo capitolo.
CAPITOLO 3. DA BPMN A WEBML 48

Figura 3.17: Home page del cruscotto di controllo processi

Prima di procedere con i dettagli sulle aree, è opportuno aprire una paren-
tesi sullo strumento utilizzato per la rappresentazione dinamica dei grafici:
Google Chart API 10 . La Google Chart API è 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 può includere il diagramma in una pa-
gina web in modo semplice [12]. All’interno delle pagine di dettaglio, che
verranno analizzate nei paragrafi successivi, è 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 è 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, è un insieme di procedure disponibili al programmatore, di solito
raggruppate per formare un set di strumenti specifici per un determinato compito [33].
CAPITOLO 3. DA BPMN A WEBML 49

Process and Activities

L’area Process and activities contiene tutte le informazioni relative a pro-


cessi, case, tipi di attività ed attività. In questa area è presente una home
page che elenca i processi ed i case presenti all’interno del sistema, con la
possibilità 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 attività e il numero
CAPITOLO 3. DA BPMN A WEBML 50

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 attività 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 attività e l’indicatore
del tempo di esecuzione. Inoltre vi sono due grafici, entrambi relativi
alle istanze di attività del case: il primo ne rappresenta il numero,
suddiviso per stato, e il secondo il diagramma di GANTT11 ;

• ActivityType details: dettagli sui tipi di attività. 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 attività
suddivise per stato;

• ActivityInstance details: pagina di dettaglio sulle istanze di attività.


Oltre alle informazioni su processo, case e tipo di attività 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, è 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 attività e il tempo
11
Un diagramma di GANTT è uno strumento di supporto alla gestione dei progetti, nel
caso del presente lavoro applicato ai processi. Rappresenta la durata delle attività 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 è concluso, o alla data e ora correnti, se il case
non è terminato.
CAPITOLO 3. DA BPMN A WEBML 51

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 può 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 attività assegnate all’utente e alcune informazioni statistiche:
le attività in esecuzione, sospese e terminate e la media dei tempi di
esecuzione;
CAPITOLO 3. DA BPMN A WEBML 52

• Group details: pagina di dettaglio del gruppo; in questa pagina so-


no presenti i collegamenti agli utenti del gruppo e ai tipi di attività
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
attività 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 attività divise per stato ed il tempo medio di esecuzione delle attività.

Search

La sezione dedicata alla ricerca è stata strutturata su due livelli: Simple


search e Advanced search.

Figura 3.20: Pagina di ricerca avanzata


CAPITOLO 3. DA BPMN A WEBML 53

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 può scegliere gli elementi sui quali basare la ricerca stessa.
La Query Unit si occupa invece di eseguire la ricerca vera e propria. Può
essere utilizzata in due modalità, statica e dinamica.
La modalità 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 è stata sfruttata per calcolare ad esempio i tempi di esecuzione nelle
altre aree.
La modalità dinamica è invece quella che è 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 entità ed attributi che gli interessano e
condizioni da rispettare, imposta la query in modo intuitivo e veloce: sarà
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, è possibile selezionare l’entità 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 è più complesso: è 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:
CAPITOLO 3. DA BPMN A WEBML 54

1. si seleziona l’entità principale, ovvero quella di cui si cerca la pagina di


dettaglio (ogni risultato delle ricerche avrà un link che può essere solo
verso una delle sei pagine di dettaglio);

2. si selezionano gli attributi appartenenti all’entità 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 entità 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


funzionalità proposte.
La maggior parte del lavoro è 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 possibilità che esse offrono.
Essendo WebRatio basato sulla piattaforma Eclipse, è possibile attraverso ta-
le tool integrare le potenzialità di Java con la progettazione e la modellazione
di applicazioni web.
Nei prossimi paragrafi verrà descritto più 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 è 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’attività dà origine ad un
nodo di tipo modulo nel WebML finale; se l’attività è automatica, tale modulo
sarà un Operation Module 1 , mentre se l’attività è di tipo manuale il modulo
risultante sarà 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 è di tipo AND e una Index Unit se il
gateway è 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 già 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 sarà 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 è stata
correttamente attivata.

1
Un Operation Module è un modulo composto di sole operazioni.
2
Un Hybrid Module è composto sia da Operation Unit che da Content Unit.
CAPITOLO 4. IMPLEMENTAZIONE 57

4.2 Tipizzazione nel BPMN Modeler


Nella fase di trasformazione, un’attività 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’attività. In figura 4.1 è possibile vedere un esempio di
codice generato attraverso la trasformazione di un’attività, senza sfruttare il
processo di tipizzazione.

Figura 4.1: Esempio di codice XML generato da un’attività non tipizzata

Tale codice rappresenta la porzione del modello WebML finale da cui par-
tirà la creazione dell’applicazione. Dato che questo codice contiene soltanto
lo stub del modulo, e viene generato dinamicamente per tutte le attività
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 attività presenti e delle
CAPITOLO 4. IMPLEMENTAZIONE 58

unit già 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 è 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 possibilità di creare collisioni
dovute alla non unicità 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 può vedere un
esempio di come viene generata dinamicamente una unit nel caso di attività
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 è 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 funzionalità proposta.
Nell’esempio sono stati inseriti alcuni contenuti nel modello dei dati del-
l’applicazione; tale inserimento è totalmente indipendente dal modulo gene-
rato, purché questo abbia accesso alle entità necessarie.
CAPITOLO 4. IMPLEMENTAZIONE 59

Figura 4.3: Screenshot di una pagina generata da un modulo tipizzato

A questo punto è opportuno definire il comportamento della tipizzazione


nei confronti del modello dei dati. Infatti, considerando sempre l’esempio
dell’attività “Ricerca esame”, il modulo generato richiede la presenza delle
entità “Esame” e “Studente”, cosı̀ come della relazione tra le due entità;
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’attività necessario
alla tipizzazione sarà composto sia della parte relativa alle pagine, alle unit
e ai collegamenti, che di quella contenente le informazioni sulle entità da
inserire nel modello dei dati. Gli identificatori di tali entità saranno costruiti
in base al nome della libreria: in questo modo, se più attività della stessa
libreria fanno uso delle stesse entità, queste vengono inserite una sola volta
all’interno del modello dei dati e i moduli ne fanno uso in modo condiviso.
CAPITOLO 4. IMPLEMENTAZIONE 60

4.3 Tipizzazione in WebRatio


Una volta creato il modello, il designer WebML può intervenire a piacere
sui moduli desiderati, sia su quelli generati senza tipizzazione che su quelli
tipizzati. Per garantire il corretto funzionamento dell’applicazione finale è
necessario che tutti i moduli vengano riempiti con gli opportuni contenuti.
Come trattato nella parte relativa alla progettazione è possibile, alla fine
della fase di design, salvare quanto implementato in opportuni documenti
e librerie per permettere il riuso dei moduli quando le attività di un altro
diagramma BPMN sono dello stesso tipo.
A livello implementativo, l’operazione “Save Module As Type” è un plug-
in di WebRatio. Questo plug-in, sfruttando le già 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’attività come prefisso);

2. si controlla quali entità 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 entità e


alle relazioni da salvare, pre-trattando gli identificatori, usando questa
volta il nome della libreria come prefisso.

Il risultato di questi passaggi è un documento XML contenente la strut-


tura del modulo ed il codice delle entità 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 è possibile salvare più moduli con lo stesso nome
all’interno della stessa libreria.
CAPITOLO 4. IMPLEMENTAZIONE 61

L’uso del nome della libreria come prefisso per gli identificatori delle entità
e delle relazioni consente di evitare collisioni nel momento in cui si cerca di
tipizzare due attività, scegliendo tra i tipi di una stessa libreria, che fanno uso
di entità o relazioni comuni. In questo modo, ad esempio, l’entità “Esame”,
essendo comune alle attività “Ricerca esame” e “Iscrizione esame”, non verrà
inserita due volte all’interno del modello dei dati.
CAPITOLO 4. IMPLEMENTAZIONE 62

4.4 Cruscotto di controllo processi


L’implementazione del cruscotto di controllo è 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 è 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 può 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 funzionalità 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.
CAPITOLO 4. IMPLEMENTAZIONE 63

Figura 4.4: Screenshot della pagina di dettaglio di un Case

modo standard di utilizzare la Google Chart API per visualizzare le


attività divise per stato;

• nel diagramma “Activity Instances GANTT” si può vedere infine un


modo più creativo di creare diagrammi, per rappresentare il diagramma
di GANTT relativo alle attività del case.

Figura 4.5: Screenshot della pagina di dettaglio di una ActivityInstance


CAPITOLO 4. IMPLEMENTAZIONE 64

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 è 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’attività.
Pagine simili sono state implementate per i processi, i tipi di attività, 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 più 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’entità sulla quale si sta effettuando la query (i risultati saran-
no istanze di tale entità) e il livello di navigazione al quale si è arrivati (in
questo caso si è partiti dall’entità Case, spostandosi verso il processo di cui il
case è istanza attraverso la relazione “process”). Nella sezione “Navigate Da-
tamodel” si può continuare a navigare il modello dei dati: in questo esempio,
essendo posizionati sull’entità Process si potrà 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
CAPITOLO 4. IMPLEMENTAZIONE 65

parte destra, invece, vengono visualizzati gli attributi scelti e le entità 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 entità prodotte come risultato
della query.

Figura 4.6: Esempio di impostazione di una query

Figura 4.7: Pagina di visualizzazione dei risultati della query


CAPITOLO 4. IMPLEMENTAZIONE 66

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 è do-
tato. L’architettura di WebRatio è 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 entità e le
relazioni tra i dati concettuali e una o più sorgenti di dati fisiche, che possono
sia essere create dal tool che essere pre-esistenti. Il Database Synchronizer
può anche ricavare la struttura dati da un database già esistente, e riflettere
le informazioni sul data model concettuale. Al contrario può 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, è
necessario che il data model sia mappato al database perché il funzionamento
del sistema sia garantito.

Figura 4.8: L’architettura di WebRatio

L’interfaccia di design di WebRatio è 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
CAPITOLO 4. IMPLEMENTAZIONE 67

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 è 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 potenzialità delle funzionalità
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), potrà visualizzare l’elenco dei corsi di laurea ai
quali può iscriversi. Scelto il corso, il sistema si occuperà di verificare se ci
sono ancora posti disponibili; in caso positivo lo studente dovrà immettere
i dati necessari per l’iscrizione. Infine il sistema provvederà 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 è stato definito,
si può 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 attività. 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’attività “Inserimento dati utente”

I due moduli rappresentati nelle figure saranno presi come riferimento per
mostrare i passaggi successivi alla prima trasformazione nei prossimi para-
CAPITOLO 5. CASO DI STUDIO 70

grafi. A questo punto è già possibile generare il codice applicativo a partire


dal modello, sfruttando il generatore di codice di cui è dotato WebRatio.

Figura 5.3: Modulo corrispondente all’attività “Inserimento dati iscrizione”

Insieme alla module view contenente i moduli relativi alle attività 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, sarà 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 è mostrata la pagina da cui è possibile effettuare l’operazione descritta.

Figura 5.4: Pagina di sincronizzazione tra logica di workflow e database

Si può inoltre utilizzare l’applicazione generata, accedendovi tramite un


browser qualsiasi; non essendo però 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’attività sen-
za tuttavia svolgere il lavoro previsto. In figura 5.5 è mostrata una pagina
CAPITOLO 5. CASO DI STUDIO 71

creata a partire dallo scheletro dell’applicazione, in particolare dal modu-


lo rappresentato in figura 5.2. Come si può vedere, l’utente può soltanto
confermare il completamento dell’attività 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 è già possibile inserire il cruscotto di controllo
processi progettato attraverso il metodo descritto nel paragrafo 3.3.
CAPITOLO 5. CASO DI STUDIO 72

5.2 Generazione basata su tipizzazione delle


attività
Come è 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 è stata
introdotta la funzionalità di tipizzazione delle attività.
Ipotizziamo che nella libreria dei tipi predefiniti siano già 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’attività, si può
selezionare il tipo dell’attività scelta, come si può vedere in figura 5.6.

Figura 5.6: Scelta di un tipo predefinito

Si può 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’attività, ora
contiene delle unit che permettono all’utente di interagire col sistema e che
svolgono delle operazioni. In questo caso è 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
entità necessarie al funzionamento del modulo all’interno del modello dei
CAPITOLO 5. CASO DI STUDIO 73

Figura 5.7: Modulo corrispondente all’attività “Inserimento dati utente”


dopo la tipizzazione

dati. Nel caso del tipo “Inserimento dati utente”, bisogna inserire l’entità
“Nuovo utente” (rappresentata in figura 5.8).

Figura 5.8: Modifiche al modello dei dati dopo la tipizzazione

Infine, si può 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 può vedere in figura 5.9, ora la
pagina fornisce all’utente gli elementi necessari per l’esecuzione dell’attività.
Lo screenshot presente in figura 5.9 è stato generato partendo dal modulo in
figura 5.7.
CAPITOLO 5. CASO DI STUDIO 74

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’attività “Inserimento dati iscrizione”, ipotiz-
ziamo che il modulo di partenza venga modificato fino ad ottenere quello
rappresentato in figura 5.10.
Come si può vedere, il designer ha semplicemente inserito, a livello di
interfaccia utente, una Entry Unit per l’inserimento delle informazioni neces-
sarie all’esecuzione dell’attività. Tuttavia, per permettere il salvataggio dei
dati inseriti in modo corretto, bisogna inserire le opportune entità e relazioni
nel modello dei dati. In questo caso, il designer è partito dall’entità creata
attraverso la tipizzazione descritta nel paragrafo precedente per estendere il
modello dei dati. Come si può vedere in figura 5.11, sono state create le
entità “Dati iscrizione” e “Corso di laurea”, e sono state collegate tra loro e
CAPITOLO 5. CASO DI STUDIO 75

Figura 5.10: Modulo corrispondente all’attività “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 può ad esempio vedere la pagina generata
a partire dal modulo appena progettato, rappresentato in figura 5.10.
CAPITOLO 5. CASO DI STUDIO 76

Figura 5.12: Pagina generata dal modulo “Inserimento dati iscrizione” dopo
la tipizzazione

5.4 Salvataggio e riuso dei nuovi tipi


Dopo che è stata terminata la creazione dei nuovi moduli, si può utilizzare
la funzionalità 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 può vedere come l’attività appena salvata sia presente all’interno del
flusso di lavoro di un altro processo.

Figura 5.13: Nuovo diagramma BPMN con attività comuni a quelle salvate

Grazie alla possibilità di salvataggio dei moduli personalizzati è quindi


CAPITOLO 5. CASO DI STUDIO 77

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 attività 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 più indicato per l’implementazione
dell’interfaccia utente nel contesto dei processi aziendali.
Il PML (Process Modeling Language [19]) è 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 attività. 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] è 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 attività viene generata solo una pagina, indipendentemente dalla
complessità dell’attività, 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 è 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 è un metodo di design orientato agli oggetti, nel quale l’ipertesto
di navigazione è modellato attraverso i diagrammi delle classi UML, estesi
con nuovi elementi che permettono di rappresentare in modo più 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
CAPITOLO 6. LAVORI CORRELATI 80

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 entità e nodi di attività, rappresentati tramite primitive UML. In
più, 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 è guidato dai requisisti del-
l’utente ed è 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 attività, viene specificata una gerarchia
in grado di rappresentare i rapporti di consequenzialità 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 è 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 può produrre una definizione di processo
CAPITOLO 6. LAVORI CORRELATI 81

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 è 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 è necessario, come
per molti degli altri approcci, introdurre collegamenti o utilizzare gli elementi
già 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
è possibile creare i contenuti delle attività in modo libero da vincoli, purché
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 più 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ı̀ più 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 è 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: sarà dunque opportuno introdurre nel
linguaggio di modellazione WebML nuove primitive, al fine di ottenere un
meccanismo più completo. Sarà inoltre utile arricchire le librerie di moduli

82
CAPITOLO 7. CONCLUSIONI E SVILUPPI FUTURI 83

predefiniti per consentire una scelta più ampia al momento della tipizzazione,
in modo tale da rendere necessario il design solo nei casi più particolari. Il
terreno della generazione automatica di contenuti è ancora poco esplorato:
è dunque necessario verificare le sue reali potenzialità in maniera più appro-
fondita. Inoltre, il cruscotto di controllo rappresenta soltanto uno spunto
per la progettazione di sistemi di controllo più complessi, presumibilmente
parametrici e personalizzabili in base alle esigenze del contesto aziendale in
cui vengono collocati. Infine, sarà importante mettere in atto tutte le funzio-
nalità proposte e progettate in casi di utilizzo reale, per evidenziarne i punti
deboli e per ricavare i requisiti delle migliorie che sarà 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.