Sviluppo di una interfaccia grafica basata sul linguaggio PQL per interrogazioni di modelli di processo in Apromore

Transcript

1 Corso di laurea Magistrale in Ingegneria Informatica Tesi di laurea Sviluppo di una interfaccia grafica basata sul linguaggio PQL per interrogazioni di modelli di processo in Apromore Relatore Prof. Giancarlo FORTINO Relatore Prof. Marcello LA ROSA Candidato Luigi CORNO matr Candidato Anno Accademico 2013/2014

2 Abstract Apromore è una piattaforma web sviluppata per la gestione e il salvataggio di modelli di processo. Una caratteristica unica di questa piattaforma è la sua capacità di salvare e lavorare con modelli scritti in diversi linguaggi (BPMN, YAWL, EPML, ecc). Le operazioni che Apromore mette a disposizione degli utenti riguardano principalmente l analisi dei modelli presenti nel repository, vedasi la similarity search e il clustering (operazioni queste che si soffermano solo sulla struttura dei modelli). Un interessante problematica di ricerca, riguarda la definizione e sviluppo di procedure di analisi della semantica dei modelli, al fine di comprendere quando due differenti modelli facciano riferimento al medesimo contesto. Affinché sia possibile raggiungere tale obiettivo, bisogna innanzitutto trovare un modo per interrogare un insieme di modelli. Purtroppo però, i normali linguaggi di interrogazione per modelli di processo non sono sufficienti, dato che si concentrano solo sulla struttura dei modelli stessi. Nel presente lavoro di tesi si descriverà l integrazione del linguaggio PQL (un linguaggio di interrogazione per modelli di processo sviluppato da un ricercatore del QUT) in Apromore ed in particolare si proporrà la progettazione ed implementazione di un interfaccia grafica capace di supportare tale linguaggio. ~ 1 ~

3 Sommario Abstract... 1 Introduzione... 4 Ringraziamenti... 6 CAPITOLO 1: Apromore (Advanced Process Model Repository) Zk Background: Static-HTML e applicazioni puramente AJAX Zk: Cos è e cosa non è Zk: Architettura del framework Components, Pages e Desktop Ciclo di vita dei componenti Performance: Zk vs JSF (Java ServerFaces) Apache Maven Convenzione sulla configurazione Interfaccia comune A cosa servono i plugin Maven? POM (Project Object Model) Plugin Ciclo di vita di Maven Sistema di gestione delle dipendenze Riepilogo Spring framework Architettura di Spring Dependency Injection Spring AOP (Aspect Oriented Programming) Architettura CPF (Canonical Process Format) Interfaccia Apromore Vantaggi nell uso di Apromore CAPITOLO 2: PQL: A Process Query Language Sintassi Semantica di PQL ~ 2 ~

4 2.3 Esempi di interrogazioni PQL Progettazione modulo per PQL Specifiche Integrazione modulo PQL nell architettura Apromore Progettazione Progettazione modulo PQL FolderProcessTree: l albero dei modelli di processo VariableText: dichiarazione delle variabili QueryText: definizioni dell interrogazione ButtonAction: shortcut per aiutare l utente TableProcess: la tabella delle versioni Salva/Carica: memorizzazione e riuso vecchie interrogazioni Portal-client: l applet comunica col portale TabQuery: come vengono rappresentati i risultati Indicizzazione dei modelli di processo Multi-threading: indicizzazione più efficiente Conclusioni Bibliografia ~ 3 ~

5 Introduzione BPM, o Business Process Management, è un approccio sistematico mirato ad analizzare e migliorare i risultati derivanti da un processo in seno ad un organizzazione o ad un azienda. Definire il concetto migliorare i risultati di un processo, può risultare più difficile di quanto si pensi. Infatti, in dipendenza del processo che l azienda vuole analizzare tramite le tecniche di BPM, migliorare può riferirsi al tempo con cui un processo è eseguito, alla quantità di prodotti alla fine della lavorazione, al soddisfacimento di determinate condizioni, ecc. [16] Naturalmente, l obiettivo che si vuole conseguire non dipende solo dal tipo di processo che si sta analizzando, ma dipende anche dalle specifiche dettate dall azienda in cui quel processo si svolge. Oltretutto non è pensabile, ma neanche possibile, analizzare un processo a fondo senza avere a disposizione determinati tool o senza avere delle precise regole di schematizzazione dei processi. Per ovviare a queste carenze, il BPM adotta non solo software mirati per l analisi dei modelli di processo, ma soprattutto si basa su un vero e proprio standard di rappresentazione dei modelli. I modelli di processo costituiscono un aiuto cospicuo nella gestione di un ente, sia esso privato o pubblico, grazie alla loro capacità schematica di riuscire a rappresentare ciò che davvero accade in un organizzazione. I loro punti di forza sono sicuramente la facilità di lettura, anche per chi non è un esperto di BPM, nonché la presenza di standard di rappresentazione (come scrivere le etichette in un attività di lavoro, o come rappresentare transizioni temporali). Di contro però, esistono molte varietà di linguaggi (BPMN, EPML, YAWL, ecc.) mediante i quali poter rappresentare un modello, e questo crea grossi problemi in fase di analisi e salvataggio degli stessi. Infatti, pur rappresentando lo stesso processo o comunque avendo due modelli di processo simili, le rappresentazioni in due diversi linguaggi possono variare anche sostanzialmente. Inoltre essendo scritti in linguaggi diversi, ~ 4 ~

6 non si ha la possibilità di salvarli mediante un unico programma né tantomeno si riesce ad analizzarli. Una soluzione a questi problemi è la piattaforma web Apromore [12], che grazie alla creazione di un linguaggio che rappresenta solo la struttura dei modelli, è riuscita a fornire all utente validi strumenti di analisi, nonché un database in grado di salvare tutti i modelli in diversi linguaggi. In questo modo l utente è in grado di poter confrontare modelli e stabilirne la somiglianza, raggrupparli secondo algoritmi di clustering, effettuare persino interrogazioni che possano restituire i modelli rispondenti a determinati criteri, senza dimenticare naturalmente la creazione, il salvataggio e l importazione dei modelli stessi. Nella presente tesi, si proporrà un ampia panoramica circa le funzionalità della piattaforma web Apromore, ponendo particolare attenzione sulle tecnologie che usa e che consentono alla piattaforma di avere notevoli prestazioni (Capitolo 1). Successivamente l attenzione si sposterà sulla formulazione di un linguaggio di interrogazione (PQL) capace di analizzare la semantica di un modello e che dia la possibilità di poter confrontare in virtù di ciò una grande quantità di modelli nel modo più fedele possibile (Capitolo 2). Infine, si descriverà la progettazione e lo sviluppo di un interfaccia grafica capace di esaltare le potenzialità del linguaggio PQL, principale contributo della presente tesi. Infine (Capitolo 3). Infine si presenteranno le conclusioni e alcune direzioni di sviluppi futuri. ~ 5 ~

7 Ringraziamenti Desidero ricordare tutti coloro che mi hanno aiutato nella stesura della tesi con suggerimenti, critiche ed osservazioni: a loro va la mia gratitudine, anche se a me spetta la responsabilità per ogni errore contenuto in questa tesi. Ringrazio anzitutto i professori Giancarlo Fortino e Marcello La Rosa, Relatori, per il loro supporto e la loro guida nella stesura della tesi, ma soprattutto per avermi dato l opportunità di svilupparla in Australia. Proseguo ringraziando i dottori Raffaele Conforti e Artem Polyvyanyy, Supervisori, per la pazienza dimostrata durante lo sviluppo del mio progetto di tesi. Vorrei ringraziare la mia famiglia, sempre pronta a sostenermi durante questi lunghissimi anni di università. Grazie per i numerosi sacrifici che mi hanno permesso di arrivare a questo giorno. Grazie per il grandissimo affetto che mi avete dato, e che spero continuerete a darmi. Questa tesi è soprattutto dedicata a loro, con la speranza che sia solo la prima delle numerose soddisfazioni che potrò offrirgli in futuro. Grazie a alla famiglia Straface: Santo, Luisa, Samuele, Marika e Mirko, che mi hanno visto crescere e che sono come una seconda famiglia. Un sentito Grazie! va ai miei amici: Andrea, Carmine, Elina, Emanuele, Fabiola, Ferdinando, Francesca, Iacopo, Ivan, Karim, Marika, Manuel, Pierluigi, Roberta; grazie per i tanti momenti passati insieme, per avermi contagiato con la loro voglia di scoprire il mondo ma soprattutto per esserci stati quando ne avevo bisogno. Infine, ma non perché meno importanti, vorrei ringraziare tutte quelle persone conosciute durante questi sei anni di università: Antonio, Emanuele, Francesco, Gabriele, Giacomo, Nicola, Romualdo, Rosario (Barresi), Rosario (Bova), Simone, Virginio; grazie per avermi tenuto compagnia in questi anni, per la vostra ospitalità e per avermi svegliato. Spero di non aver dimenticato nessuno, ma qualora così fosse, un grazie anche a te che in qualche modo hai contribuito a rendermi come sono. ~ 6 ~

8 CAPITOLO 1: Apromore (Advanced Process Model Repository) La modellazione dei processi di business è diventata una forma molto popolare di modellazione concettuale. Un modello di processo descrive, spesso attraverso notazioni grafiche, come una certa procedura sia in realtà formata da diverse azioni, che tipo di risorse vengono utilizzate da ogni azione, e quale sia lo scopo ultimo di questo processo. Tali processi possono far riferimento ad una varietà di ambiti anche molto diversi tra loro: dal settore IT a quello commerciale, dall ambito sanitario a quello dei trasporti. Grazie alla diffusione di applicazioni che permettono di modellare in veste grafica un processo aziendale, molte organizzazioni hanno iniziato a produrre centinaia, e a volte perfino migliaia, di modelli rappresentanti le loro attività. Come conseguenza di questo uso quasi indiscriminato di rappresentazione di modelli, le varie organizzazioni hanno avuto la necessità di trovare applicazioni in grado di immagazzinare questa grande mole di informazioni, ma soprattutto un modo per poter analizzare ed elaborare tali dati. Inoltre un ulteriore difficoltà per le aziende è rappresentata dalla varietà di linguaggi con cui un modello può essere espresso in via grafica. Infatti pur esistendo uno standard a livello internazionale (il BPMN 2.0 standardizzato da OMG nel gennaio 2011), alcune aziende hanno modelli scritti in altri linguaggi (YAWL, EMPL, ecc.) che non vengono tradotti in BPMN magari per motivi di tempo o perché semplicemente non lo ritengono necessario. In tale contesto è stato sviluppato Apromore (Advanced Process Model Repository), un open-source SaaS (Software as a Service) in grado di offrire una serie di tecniche per il salvataggio, l analisi e la visualizzazione del contenuto informativo dei modelli di processo. La scelta di rendere Apromore open-source mira ad incoraggiare coloro i quali vogliono aggiungere funzionalità al repository, ma anche quegli enti a cui esso è rivolto, che possono usufruire di tutti i tool già presenti, in maniera del tutto gratuita. ~ 7 ~

9 A seguire analizzerò sia i framework usati per lo sviluppo di Apromore (Zk, Maven e Spring), che la struttura della piattaforma web, soffermandomi non solo sull architettura, ma avendo un occhio di riguardo su cosa lo rende diverso da altri tool commerciali (in particolare come la piattaforma riesca a gestire ed analizzare modelli di processo scritti con diversi linguaggi di rappresentazione, senza che sia necessario effettuare traduzioni da un linguaggio ad un altro). 1.1 Zk Background: Static-HTML e applicazioni puramente AJAX Le prime applicazione Web erano basate sul modello di comunicazione stateless, ovvero un modello in cui una pagina web conteneva tutte le informazioni visualizzate all utente ed era scambiata tra il client ed il server. Come si può vedere in [Figura 1], ogni richiesta da parte del client era elaborata grazie ad una specifica servlet (ovvero un programma java residente sul server in grado di gestire determinate richieste del client), che finita la sua elaborazione reindirizzava ad un'altra pagina web. Un approccio di questo tipo però, non era in linea con le esigenze dei client. Basti pensare che anche per semplici operazioni, era necessario ricorrere a più pagine statiche, ognuna delle quali conteneva uno step dell operazione richiesta dall utente. Così facendo era impossibile per l utente avere una visione globale di ciò che stava facendo. Figura 1 - Ottenimento di nuove pagine web statiche mediante servlet Ricorrendo ad un esempio, se un cliente richiedeva un preventivo per l acquisto di un oggetto, doveva aprire una pagina per la ricerca, successivamente occorreva ~ 8 ~

10 aprirne una seconda per la visualizzazione dei prezzi, ed infine una terza per effettuare l acquisto. Ciò risultava in utenti confusi e scontenti. Parlando invece di aspetti maggiormente tecnici, si vede come il server sia oberato di operazioni da effettuare: dal processare la richiesta dell utente alla visualizzazione delle varie pagine, dalla gestione degli errori alla gestione dei link presenti nelle pagine. [2] Per avere prestazioni migliori, ma soprattutto per creare applicazioni che si avvicinassero maggiormente ai bisogni dell utente, le pagine web hanno subito una graduale evoluzione: da statiche sono diventate dinamiche, e quest ultime hanno lasciato spazio alle applicazioni AJAX (Asynchronous JavaScript and XML). Questa evoluzione, oltre ad essere dettata dalla necessità di avere applicazioni leggere lato server e con prestazioni elevate, fu resa necessaria anche per avvicinarsi alle esigenze degli utenti. Infatti, col passare del tempo non solo la mole d informazioni con cui l utente doveva lavorare aumentava, ma soprattutto le operazioni da svolgere online diventavano più complesse. Inoltre, questi due fattori mal combaciavano con applicazioni sviluppate su più pagine web, che risultavano essere molto dispersive. Il passo successivo, fu così l introduzione di applicazioni AJAX tramite cui l utente era in grado di ottenere prestazioni simili a quelle di un applicazione desktop sul web, avendo al contempo la possibilità di visualizzare grandi quantità d informazioni in una pagina (garantendo una visione globale sul contesto al quale si lavorava). [Figura 2] Figura 2 - Aggiornamento contenuti in pagine web dinamiche Dal punto di vista tecnico, AJAX riesce a cambiare dinamicamente il contenuto di una pagina web in base alle esigenze dell utente. Per farlo, usa il linguaggio di scripting JavaScript, tramite cui riesce a ~ 9 ~

11 catturare e gestire gli eventi generati dall utente, ed in base a tali eventi, a ristrutturare il contenuto della pagina in cui si trova l utente. Naturalmente a mutare, non saranno solo le informazioni contenute nella pagina, ma anche la sua struttura HTML (il cosiddetto Document Object Model o DOM). Mediante tali operazioni si evita di dover richiedere ogni volta una pagina al server, ma si richiedono solo le nuove informazioni da visualizzare. Inoltre, per rendere flessibile e leggero lo scambio d informazioni col server, si usa XML, in modo da poter strutturare i dati scambiati tra client e server secondo le necessità del programatore. Le comunicazioni tra i due lati dell applicazione, inoltre, avvengono in maniera asincrona, aumentando così le prestazioni dell applicazione, nonché evitando all utente frequenti periodi di attesa (nel caso di pagine web statiche, ogni qualvolta l utente effettuava un operazione, veniva inviata una richiesta al server che rispondeva inviando una nuova pagina. Questo meccanismo costringeva l utente ad aspettare ogni volta che l intera pagina fosse scaricata prima di poter nuovamente riprendere ad interagire con essa). Una precisazione, non bisogna farsi fuorviare eccessivamente da AJAX usa JavaScript o XML. Infatti, ai programmatori è consigliato il loro uso soprattutto per la compatibilità con la maggior parte dei browser web, ma nessuno vieta l utilizzo di un qualsiasi linguaggi di scripting o di trasmissione dati sul web. Naturalmente rientrerà poi nelle mansioni del programmatore adattare la sua applicazione ai browser, magari attraverso l uso di plugin. Nonostante AJAX riesca ad offrire buone prestazioni, purtroppo però ci sono alcuni lati negativi che hanno spinto col tempo sempre più programmatori a trovarne una valida alternativa. Alcune delle maggiori limitazioni sono: la notevole complessità che l intera architettura ha per i neofiti di AJAX, la necessità di ricorrere a JavaScript per l elaborazione del DOM delle pagine web nonché per lo scambio di informazioni col server, ed infine la necessità di replicare i dati e parte della logica dell applicazione sul browser (questo per poter consentire una migliore interazione utente-applicazione, con tutte le conseguenti problematiche inerenti alla consistenza dei dati ed al loro aggiornamento). Dunque le pagine AJAX sembrano mantenere di fondo le medesime problematiche di cui le vecchie ~ 10 ~

12 applicazioni page-based soffrivano, anche se con risultati indiscutibilmente migliori. Occorre trovare una soluzione che abbia prestazioni simili, se non migliori a quelle offerte da AJAX, ma che riesca al contempo a superarne le limitazioni esposte in precedenza. Una valida alternativa sembra essere costituita da Zk (una framework sviluppato dalla Potix Corporation) che sta riscuotendo un particolare successo. Tale piattaforma, pur avendo elementi in comune con AJAX, adotta un approccio differente che mira soprattutto alle prestazioni e alla semplicità nello sviluppare un applicazione anche da parte dei neofiti di applicazioni sul web Zk: Cos è e cosa non è Zk è un framework event-driven basato su componenti ad hoc che permette lo sviluppo di R.I.A. (Rich Application Web), ovvero applicazioni web dinamiche anche molto complesse. Gli elementi caratterizzanti tale framework sono tre: un motore AJAX event-driven, una vasta gamma di tag nei linguaggi XUL [Codice 3] e XHTML [Codice 2] e un linguaggio di markup chiamato ZUML [Codice 1], o ZK User Interface Markup Language (tutti i precedenti linguaggi sono basati sul formato extensible Markup Language o XML). Se uno sviluppatore avesse intenzione di costruire un applicazione web tramite Zk, non deve far altro che costruire la grafica mediante i tag XUL, XHTML e ZUML e definire le eventuali azioni in risposta agli eventi generati dall utente. Tutto il resto è svolto dal motore AJAX di cui è fornito Zk, dalla sincronizzazione dei contenuti della pagina rispetto alle informazioni contenute lato server al processamento degli eventi. In questo modo, si eliminano a monte il problema di Codice 1 decidere cosa elaborare lato client e cosa elaborare invece lato server, come avveniva nelle applicazioni AJAX pure. Inoltre non si ~ 11 ~

13 Codice 2 Codice 3 hanno problemi di consistenza dei dati dovuti alla loro replicazione, dato che adesso tutto ciò che riguarda i dati è contenuto lato server al servizio del motore AJAX di cui dispone Zk. [3] Tutto questo permette di avere prestazioni paragonabili ad un'applicazione desktop, sia per quanto riguarda la velocità di risposta ad un azione da parte dell utente, sia per quanto concerne la facilità nel programmare una pagina per la propria applicazione. Inoltre, per quanto riguarda la creazione della grafica per una pagina web, l utente può ricorrere a diverse soluzioni: programmare interamente in XML (utilizzando quindi i tag XUL, XHTML oppure usando entrambi nella stessa pagina grazie al linguaggio ZUML), programmare interamente in Java (creando quindi una classe che eredita da un container Zk, ~ 12 ~

14 come descritto nelle API online), oppure poter fondere le due tipologie precedenti. Anche se per adesso si è fatto riferimento solo agli elementi di base di Zk, il medesimo discorso può essere fatto per gli elementi sviluppati dal programmatore (siano essi scritti in XML o in Java). Infatti, esattamente come nei linguaggi di programmazione ad oggetti, si può creare un nuovo componente partendo da un elemento base. In questo modo si può ampliare il set di tag a cui un programmatore può attingere, che non sarà costretto ad inventarsi soluzioni sempre nuove che si avvicinino alle sue esigenze. Infine, si possono introdurre espressioni EL (o Expression Language, una sorta di linguaggio ispirato a xpath ed user-friendly capace di accedere ad oggetti esterni direttamente dalla pagina web) nonché codice di scripting (che può essere di qualsiasi tipo, da Java a PHP, da JavaScript a Groovy, ecc.) all interno di una pagina ZUML (da notare come tale codice insito nella pagina ZUML, venga poi eseguito lato server e non lato client, in ordine a ciò che prima si è accennato). [14] Purtroppo, come le soluzioni viste in precedenza, anche ZK soffre di alcune pecche, di cui le maggiori riguardano: il non disporre di sistemi di persistenza dei dati e di comunicazione inter-server; il non fornire all utente un modo per far comunicare il lato client col lato server (non si può cioè disporre di tunnel quali RMI o API per scambiare informazioni tra client e server); il non forzare l utente ad usare il pattern MVC per la costruzione delle proprie applicazioni (anche se quest ultimo aspetto è da rimandare sicuramente alle capacità dello sviluppatore) Zk: Architettura del framework Come già accennato, Zk include un sistema AJAX per automatizzare l interattività tra i vari componenti architetturali, un vasto insieme di componenti XUL e un linguaggio di markup per semplificare lo sviluppo della propria applicazione. Questi tre aspetti del framework, si rispecchiano nei tre componenti fondamentali di cui è costituita l architettura: ~ 13 ~

15 ZK Loader: componente responsabile del caricamento e dell interpretazione di una pagina Zk. La selezione della pagina è effettuata mediante l URL Request proveninete dal client browser. Il risultato è una pagina HTML che viene inviata al client pronta per essere visualizzata; Zk Client Engine: componente che invia richieste ZK Request ed ottiene risposte ZK Response dal server. Tramite queste risposte, l albero DOM della pagina da visualizzare è aggiornato lato client. E la parte adibita alla cattura degli eventi generati dall utente sulla pagina, che a sua volta li invia al ZK AU Engine per ottenere una risposta. Pertanto, si può affermare che il Client Engine, è la parte client di AJAX; ZK AU (Asynchronous Update) Engine: è la parte server di AJAX ed ha il compito di processare gli eventi generati dall utente. Seguendo le istruzioni specificate a priori dal programmatore, si generano messaggi che inviati lato client permettono la modifica del DOM, e il conseguente aggiornamento della pagina sul browser. Da notare come questo processo non sia sincrono, come specificato peraltro nel nome del componente, e dunque non costringe l utente a rimanere bloccato in attesa dell update della pagina; In [Figura 3] è mostrato il processo di richiesta, acquisizione, interazione e aggiornamento di una pagina Zk con cui un utente lavora, e a seguire una breve descrizione di come siano gestite le richieste e le risposte dal motore AJAX. [6] ~ 14 ~

16 Figura 3 Architettura framework Zk 1. Quando un utente digita un URL o clicca su un collegamento ipertestuale, una richiesta è inviata al Web Server. IL Zk Loader prende in consegna tale richiesta. 2. Lo Zk Loader carica la specifica pagina e la elabora, in modo da costruire i componenti al suo interno. 3. Dopo averla interpretata, lo Zk Loader trasforma la pagina in una HTML web-page pronta per essere inviata al Zk Client Engine. 4. Lo Zk Client Engine è adibito al riconoscimento delle azioni da parte dell utente. Così quando esso individua un cambiamento di valore, un click del mouse o un qualsiasi altro evento, il Zk Client Engine lo cattura e lo invia al Zk AU Engine tramite una Zk Request. 5. Una volta ricevuta una Zk Request dal Client Engine, l AU Engine aggiorna il contenuto del componente che ha generato l evento, salvo poi notificare l applicazione tramite il corrispondente event-handler. 6. Se l applicazione deve cambiare il contenuto di un componente, rimuoverlo o aggiungere di nuovi, allora lo Zk AU Engine notifica lo Zk Client Engine tramite una Zk Response. ~ 15 ~

17 7. Le Zk Response contengono al loro interno comandi su come cambiare l albero DOM della pagina che l utente sta visionando Components, Pages e Desktop Dopo aver visto il funzionamento dell architettura Zk, mi concentro ora su come costruire un interfaccia grafica, iniziando dai tasselli fondamentali: componenti, pagine e desktop [Figura 4]. Figura 4 Struttura di una pagina web in Zk Per quanto riguarda i componenti, essi sono gli elementi di base che permettono la costruzione di una pagina (label, button, textbox, ecc). Lo sviluppatore combinando tali elementi, e creandone anche di nuovi basandosi sugli elementi di base, è in grado di costruire la propria interfaccia grafica. Tali componenti però, devono essere inseriti in una Page per poter essere visualizzati nel browser, e tale operazione è effettuata dallo Zk Loader nel momento in cui va a interpretare la page. Una particolarità di Zk è però il componente Desktop, creato per poter contenere una o più pagine che servono la medesima Zk Request. In questo modo si evita di dover fare più chiamate al server risparmiando in termini di tempo. Naturalmente una qualsiasi azione dell utente, se prevista da un gestore degli eventi, è in grado di rimuovere o aggiungere una o più pagine da un Desktop, garantendo ancora una volta un'unica chiamata al server ed al Zk AU Engine. Questo approccio mira ~ 16 ~

18 soprattutto a non appesantire il server con chiamate multiple quando in realtà ne basta semplicemente una. Una piccola parentesi ivi è doverosa. Come già accennato precedentemente, lo sviluppatore può scegliere se costruire la grafica mediante classi java, usando i componenti forniti da XHTML, ZUL o ZUML, oppure unire i Figura 5 Esempio di ambiti in una pagina Zk due approcci in accordo alle proprie esigenze. Ebbene qualunque sia la scelta dello sviluppatore, la pagina web che l utente finale vedrà sembrerà essere fatta interamente in HTML, nascondendo così l implementazione che vi è dietro. Inoltre, in ogni pagina possono essere presenti tutti i componenti del framework e anche più componenti radice (componenti cioè che sono figli direttamente al tag Page). Viceversa non è detto che ogni componente possa avere come figli tutti i componenti forniti dal framework (vedasi come esempio il componente Listbox che accetta solo determinati componenti come figli e non tutti). Inoltre, ogni componente è fornito di un identificatore, che può essere dato dall utente o viene generato automaticamente in fase di creazione della pagina. Questo permette allo sviluppatore di poter acquisire un determinato componente tramite un espressione EL o mediante metodi Java appositi, e cambiarne il contenuto o il layout. Attenzione però, questi identificatori sono univoci solo all interno di un ambito, che può essere anche il semplice componente all occorrenza. Questo per permettere allo sviluppatore di usare lo stesso ID per diversi componenti appartenete a diversi ambiti, anche se tali componenti si trovano nella stessa Page. In [Figura 5] si può vedere come nella Page P, esistano tre ambiti: P, A, C. I componenti figli di P sono: A, C, F e G; i componenti figli di A sono: B, C, D; i componenti figli di C sono: E. All interno di ambiti diversi si possono avere due componenti che hanno come id X (ad esempio il componente F e il componente B, appartenendo ad ambiti diversi possono avere entrambi ID pari a X). Viceversa ~ 17 ~

19 se due componenti appartengono al medesimo ambito, essi devono avere ID diverso (ad esempio B e D che appartengo ad A, non possono avere X come ID). Inoltre se un componente ambito ha come figlio un altro componente ambito (vedasi la relazione tra A e C), allora i figli del secondo ambito non appartengono al primo ambito (il componente E appartiene all ambito C soltanto e non ad A. Rimarrà comunque discendente di A come tag XHTML, ZUL o ZUML, ma semplicemente questo).[15] Come ulteriore metodo per l identificazione di un componente, esiste l UUID (Universal Unique ID), che è poco usato dagli sviluppatori e serve in realtà allo Zk Client Engine per poter individuare il componente che deve essere cambiato a seguito di un evento. Tale identificatore non può essere assegnato dall utente, ma è generato automaticamente dallo Zk Loader in fase di costruzione della pagina, ed è immutabile. In questo modo la logica lato server potrà interagire con la grafica automaticamente senza il coinvolgimento dello sviluppatore Ciclo di vita dei componenti Si passa ora ad analizzare le varie fasi che occorrono allo Zk Loader per la creazione dei componenti in una pagina. 1. Page Initial Phase: ZK processa le istruzioni chiamate init, ovvero quelle istruzioni da effettuare quando il componente non è ancora stato creato e la pagina a cui quest ultimo appartiene non è stata aggiunta ad un Desktop. Se tutti i componenti di una pagina sono creati tramite Java, e non tramite ZUML, allora questa fase è tralasciata. 2. Component Creation Phase: è la fase in cui lo Zk Loader interpreta una pagina ZUML, creando ed inizializzando i componenti delle varie pagine. Questa fase si suddivide a sua volta in più parti: a. Per ogni elemento viene calcolato il valore degli attributi if e unless, qualora siano presenti. Se le condizioni non sono rispettate, ~ 18 ~

20 allora l elemento che ha la condizione booleana, così come tutti i suoi discendenti, sono ignorati. b. Se è specificato l attributo foreach con una collezione di elementi, allora i seguenti passi sono ripetuti per ogni elemento appartenente alla suddetta lista. c. Il componente viene creato basandosi sul nome del tag (<textbox>, <listbox>, ), oppure in base alla classe Java specificata nell attributo use presente nel tag corrente. d. Si inizializzano i membri uno ad uno basandosi sull ordine degli attributi specificati nella pagina ZUML. e. Si interpretano gli elementi innestati del tag corrente e si ripetono le operazioni precedentemente esposte. f. Si invoca il metodo aftercompose qualora qualche elemento ne sia provvisto, in modo da effettuare le operazioni in esso specificate. g. Quando ogni componente è stato creato nella pagina, si invia il metodo oncreate al rispettivo componente per permettere l inizializzazione del contenuto di alcuni componenti. 3. Event Processing Phase: Zk invoca ogni ascoltatore per ogni evento nella coda degli eventi per il Desktop corrente. Tale operazione è effettuata mediante un thread separato che scorre il DOM della pagina e per ogni elemento ne controlla il relativo ascoltatore. In questo modo si consente all utente di fermare il thread, e quindi la gestione degli eventi in esso contenuti, per permettere ad altri eventi di poter essere eseguiti perché maggiormente prioritari (come forse si sarà intuito, ad ogni Desktop è affidato un proprio thread che processa gli eventi al suo interno. In questo modo si dà libertà al programmatore di scegliere quali eventi di quali Desktop far concludere prima). ~ 19 ~

21 4. Rendering Phase: dopo aver processato tutti gli eventi, Zk raffigura questi componenti in una pagina HTML e invia tale pagina al browser. Le suddette fasi, ad eccezione della prima e della seconda che sono prettamente usate per la creazione di una pagina, sono riprese con qualche modifica anche nel caso in cui occorra aggiornare una pagina a seguito della generazione di un evento. Si avrà così: 1. Request Processing Phase: lo ZK AU Engine aggiorna i contenuti dei componenti interessati dalla richiesta, in modo che le informazioni contenute lato server siano allineate con quelle contenute lato client. 2. Event Processing Phase: svolge la medesima funzione espressa nella creazione di una pagina. 3. Rendering Phase: dopo che tutti gli eventi sono stati processati, Zk raffigura i componenti aggiornati, genera le corrispondenti Zk Response, e invia le corrispondenti risposte al client. In questo modo il Client Engine può aggiornare l albero DOM della pagina (senza aver bisogno di creare una nuova pagina, ma cambiando semplicemente alcuni tag). Urge però una piccola precisazione su come sia gestita la distruzione dei componenti che, magari a seguito di un evento, sono rimossi da una pagina. Fin tanto che l elemento non è rimosso dalla pagina, e quindi dal DOM, esso continua a farne parte. Con quest ultima affermazione, non si intende che un componente che appartiene ad una pagina sia sempre visualizzato all utente, ma solo che l elemento è contenuto nel DOM (infatti un elemento può trovarsi in una pagina, ma essere hidden, ovvero invisibile al client). Affinché la JVM su cui gira l applicazione possa riacquisire lo spazio occupato da un componente, esso deve essere rimosso fisicamente dal DOM. In questo modo l applicazione non ha più alcun riferimento al componente che viene quindi acquisito dal garbage collector, proprio come se ci trovassimo in un applicazione Java che non ha più riferimenti ad una variabile. ~ 20 ~

22 1.1.6 Performance: Zk vs JSF (Java ServerFaces) Per capire perché uno sviluppatore dovrebbe scegliere Zk come framework di sviluppo, piuttosto che un altro ambiente di programmazione sul web come AJAX, JSF (JSP) o altro ancora, vengono riportati di seguito dei test effettuati su due indici prestazionali: il tempo di risposta del server e la memoria consumata. Il test è stato effettuato su 4 distinte configurazioni (due configurazioni riguardano Zk, in cui vengono usate sia la versione Standard che la versione Enterprise, ovvero a pagamento; le restanti due riguardano JSF con differenti impostazioni), che dovranno lavorare su una tabella contenente 2000 righe e 10 colonne. [7] Di seguito sono riportate le specifiche hardware e software: Hardware o CPU: AMD Athlon II X4 635 GHz o Memoria: 8 GB Software o ZK CE o ZK EE o PrimeFaces 3.2 impostazioni S/C/R o PrimeFaces 3.2 impostazioni S/S/S o JDK o JBOSS 6 o JMeter 2.6 e Visual VM (tool per il calcolo dei tempi di risposta dal server e l occupazione di memoria Configurazioni ~ 21 ~

23 o JBOSS 6 Session time-out: default -Xms 2048 MB -Xmx 2048 MB -XX:PermSize 1024 MB -XX:MaxPermSiza 1024 MB maxthreads: 2000 acceptcount: 1024 Il test è stato condotto su una tabella avente 2000 righe e 10 colonne. Di queste 10 colonne, 3 sono caselle di testo mentre le restanti 7 sono label [Figura 6] e [Figura 7]. Il test è stato condotto caricando la pagina una sola volta, al seguito del quale sono state fatte due ROD Request (ovvero richieste per ottenere la restante parte della pagina dovuta allo scroll). Figura 6: Tabella costruita grazie a Zk ~ 22 ~

24 Figura 7: Tabella costruita grazie a PrimeFaces Figura 8 - Tempi di risposta: in ordinate è riportato il tempo di risposta, mentre in ascissa il numero di thread ~ 23 ~

25 Figura 9 Memoria occupata: in ordinata è riportata la memoria occupata, mentre in ascissa il numero di thread Come si può notare dalle statistiche riportate in [Figura 8] e [Figura 9] si vede come ZK fornisca una migliore risposta in termini di tempo, pagando però questo aspetto in termini di memoria occupata, che risulta essere fino a 1.5 volte superiore del corrispettivo usato da JSF. Sta di fatto però che nonostante questa unica pecca, Zk sia preferibile ad un implementazione PrimeFaces di un applicazione, dato che elevati livelli di memoria non sono più un problema per le applicazioni moderne. ~ 24 ~

26 1.2 Apache Maven Maven è uno strumento di gestione di progetti comprendente un file chiamato POM (Project Object Model), un insieme di standard, un determinato ciclo di vita del progetto, un sistema di gestione delle dipendenze ed una logica per l esecuzione dei plugins obiettivi durante le fasi del ciclo di vita del progetto. [8] Anche se piuttosto scarna, questa definizione mette in luce alcuni degli aspetti fondamentali su cui Maven si fonda: POM Plugins Sistema di gestione delle dipendenze Ciclo di vita di un progetto Le suddette parole chiave verranno trattate in maggior dettaglio in seguito, mostrando in che modo entrino a far parte dell architettura del progetto Maven, e come essi aiutino lo sviluppatore nella costruzione del proprio software. Inoltre si spiegheranno di seguito alcuni concetti utilizzati da Maven e che hanno portato in auge, in poco tempo, questo framework di sviluppo: Convenzione sulla configurazione Interfaccia comune A cosa servono i plugins Maven? Convenzione sulla configurazione Esprime la necessità di avere impostazioni di default, in modo da semplificare la vita del programmatore durante lo sviluppo di un progetto (non è più il programmatore a decidere come organizzare il progetto, al suo posto ci pensa Maven). A differenza di altri framework come EJB 3 e Ruby on Rails che hanno iniziato a sposare questa filosofia, Maven è stato costruito apposta per rappresentarne al meglio le potenzialità. ~ 25 ~

27 Analizzando la struttura di un progetto Maven [Figura 10], ci si rende subito conto di come l utente sia pilotato nelle directory in cui andare a posizionare il codice sorgente (${basedir}/src/main/java), le risorse del progetto (${basedir}/src/main/resources), gli eventuali test per il controllo di errori nel codice (${basedir}/src/test), i file compilati (${basedir}/target/classes) e perfino l eventuale jar del progetto che si vuole produrre (${basedir}/target). Figura 10 Struttura di un progetto Maven Anche se può sembrare una forzatura per lo sviluppatore, basti pensare che alcuni framework come Ant costringono l utente a specificare le directory di ogni tipo di file che si vuole produrre, il che molte volte può causare non pochi problemi allo sviluppatore meno esperto. [18] Oltre alla struttura rigida delle directory, Maven adotta la tecnica della convenzione sulla configurazione anche per quanto riguarda i suoi plugin principali, ovvero quelli messi a disposizione per la compilazione del codice, la generazione di artefatti da poter distribuire e molti altri processi. Ed è proprio da queste due principali caratteristiche che deriva la forza, ma al contempo, la facilità di Maven. L unico sforzo che è richiesto al programmatore è quello di porre il codice sorgente nella giusta directory, sarà poi il framework, tramite il suo ciclo di vita predeterminato, a svolgere la costruzione del progetto e la sua compilazione. Bisogna comunque sottolineare che Maven non costringe necessariamente a seguire la filosofia della convenzione sulla configurazione alla lettera. Nonostante la sua struttura apparentemente rigida, il framework consente ~ 26 ~

28 comunque una certa flessibilità su dove mettere il codice sorgente, come denominare il file jar prodotto dall esecuzione e molte altre caratteristiche. Basta solo che lo sviluppatore acquisisca familiarità con i plugin che vengono messi a disposizione e Maven farà il resto. [8] Interfaccia comune Prima che Maven offrisse un interfaccia comune per la compilazione del codice, ogni progetto doveva prevedere qualcuno che si occupasse esclusivamente di come integrare le varie parti di un progetto e compilarle. Ciò portava a grandi sprechi di tempo qualora si dovevano aggiungere nuovi test o file sorgente che dovevano essere integrati nel progetto. Infatti prima ancora di poter passare alla compilazione del codice, bisognava capire come poter inserire il nuovo codice senza causare il blocco dell intero progetto. Ad oggi invece, grazie all introduzione di Maven, progetti complessi e modulari, possono essere compilati con grande facilità proprio perché il framework usa un interfaccia comune che permette di non curarsi della struttura di un progetto, ma solo della sua implementazione. In tal modo basta scrivere a riga di comando mvn install e Maven farà il resto, grazie anche all ausilio dei suoi plugin che si occuperanno della gestione delle dipendenze di un progetto (sia rispetto a librerie esterne sia rispetto a moduli inter-progettuali) A cosa servono i plugin Maven? Nei paragrafi precedenti, il termine plugin è stato espresso più volte, anche se non è mai stato approfondito né tantomeno calato nel contesto dell architettura del framework. Per avere subito un quadro abbastanza completo dell interazione che ha Maven con i suoi plugins, basta sottolineare come il framework di base non fa altro che interpretare alcuni file XML e tenere traccia del ciclo di vita di un progetto. ~ 27 ~

29 Quindi essenzialmente Maven da solo può essere considerato abbastanza dummy (stupido) da questo punto di vista. A rendere il framework davvero potente, è l insieme di plugins messi a disposizione dal Central Maven Repository, ovvero la banca dati online da cui un progetto Maven prende non solo le dipendenze necessarie affinché il progetto funzioni, ma anche alcuni plugins fondamentali che permettono di effettuare testing del codice, packaging e molte altre funzionalità [19]. Da sottolineare però, che non tutti i plugins sono messi a disposizione dello sviluppatore quando si esegue il comando mvn install. Tale scelta è dettata dal fatto sia di rendere Maven leggero, ma soprattutto perché in tal modo uno sviluppatore può sempre avere la versione aggiornata di un plugin, senza avere l onere di effettuare egli stesso un aggiornamento. Inoltre il fatto di poter ricevere dipendenze e plugins dal Central Maven Repository, consente di avere codice che è riusabile da qualsiasi sviluppatore Maven, senza la preoccupazione di dover cambiare il proprio codice per integrare librerie esterne oppure di scrivere file di configurazione. Dopo aver esposto in cosa Maven crede, si è ora pronti a mostrare cosa Maven offre ai suoi programmatori per poter sviluppare codice pulito, performante e portabile POM (Project Object Model) I progetti Maven, le dipendenze, gli artefatti, sono tutti oggetti che possono essere descritti e modellati tramite un apposito file XML inserito in un progetto. Tale file, chiamato Project Object Model (POM), descrive che tipo di progetto, cosa modificare e come dei file sorgente contenuti nelle directory specificate. Esattamente come un applicazione Java per il web, ha il suo web.xml per descrivere, configurare e personalizzare il codice, così un applicazione Maven ha il pom.xml. Ci sono anche altri tools a cui poter fare riferimento e che sembrano avere un file di configurazione simile a quello di Maven (vedasi il build.xml di Ant o il Makefile di GNU). Ma a differenza dei precedenti, il Project Object ~ 28 ~

30 Model avrà a che fare con descrizioni del tipo: dov è il codice sorgente? Dove sono le risorse? Che tipo di packaging bisogna produrre? Tutto il resto è semplificato dalla struttura che ogni progetto Maven ha e dalla maggior parte dei suoi plugins che svolgono il lavoro sporco al posto del programmatore. [20] Anche se spesso il framework è usato per lo sviluppo di applicazioni Java sul web, questo non vuol dire che Maven, attraverso il suo pom.xml, non possa lavorare con altri linguaggi come C#, Scala, Ruby e molti altri. Se il programmatore conosce i plugin giusti, un progetto può compilare e produrre ciò che si vuole: dal produrre war piuttosto che jar per il packaging del progetto fino a suddividere un progetto unico in moduli che possono essere esportati per altri progetti. Di seguito si riporta un immagine che sintetizza le varie informazioni contenute in un file pom.xml [Figura 11]. Figura 11 Elementi costitutivi del POM Maven Il POM contiene quattro tipi d informazione, due descrittive e due di configurazione: 1. General Project Information: sono le informazioni relative al nome del progetto, dell organizzazione che l ha sviluppato, dell URL in cui trovare tale progetto, degli sviluppatori e dei collaboratori che vi hanno partecipato, nonché la licenza sotto cui il software è rilasciato. ~ 29 ~

31 2. Build settings: ivi si può personalizzare la compilazione e la struttura del nostro progetto. Affinchè sia possibile cambiare la locazione dei sorgenti e dei tests, si possono aggiungere nuovi plugin, si possono aggiungere obiettivi al ciclo di vita di un plugin preesistente, e si possono personalizzare i parametri di generazione del progetto. 3. Build eviroment: l ambiente di sviluppo consiste di diversi profili che possono essere attivati a discrezione del programmatore, per consentire di lavorare al progetto in differenti contesti operativi. Ad esempio potremmo voler lavorare in fase di sviluppo su un determinato server, mentre in fase produttiva spostarci su un altro server con differenti caratteristiche. 4. POM relantionships: raramente un progetto è un entità a se stante, o comunque tanto semplice da non richiedere codice esterno. Per venire incontro a queste esigenze si sono previste dipendenze che aiutano ad integrare codice esterno nella propria applicazione, scomposizione di progetti in moduli, ereditare impostazioni da un progetto padre, e molte altre funzionalità. Tutte queste informazioni vanno a completare quelle di base che ogni progetto Maven eredita dal POM padre, il file di configurazione che viene scaricato automaticamente quando si installa Maven per la prima volta. Tali informazioni permettono ad ogni progetto di avere accesso ad un insieme fondamentale di plugins (quelli di base che servono per la compilazione, l installazione, la generazione del jar, ecc inerenti ai progetti sviluppati) ed inoltre specificano la struttura base di ogni progetto Maven. Tale file si può trovare nel jar maven uber.jar ubicato in ${M2_HOME}/lib: ~ 30 ~

32 ~ 31 ~

33 Figura 12 - Particolare del POM principale di Maven Dal file POM padre [Figura 12], ognuno dei suoi figli acquisisce in modo standard quattro configurazioni standard: 1. Definisce un Maven repository remoto avente come ID central, comune ad ogni client, e da cui vengono scaricati i plugin di base. Quest impostazione può essere sovrascritta tramite il settings.xml che si trova nella directory di Maven sul localhost. 2. Il central Maven repository contiene i plugin ed ha l attributo updatepolicy pari a false per non permettere l update automatico dei plugin in fase di compilazione del software. Quando un utente vorrà aggiornare un plugin, gli basterà cambiare la version del relativo plugin nel campo dependency. 3. L elemento build definisce la struttura di un progetto Maven, come precedentemente esposto. 4. La versione di Maven è quella specificata di default, nel caso in cui un utente non ne specificasse una nel suo progetto. Grazie ai suddetti quattro punti, un POM figlio risulta essere molto più snello e comprensibile per lo sviluppatore: Figura 13 Identificatori di un progetto nel POM Maven Dei quattro attributi contenuti nel POM appena mostrato [Figura 13], modelversion, groupid, artifactid, version, gli ultimi tre sono necessari per ~ 32 ~

34 l identificazione delle coordinate del progetto. Essi infatti identificano la locazione dell eventuale packaging del software nel repository di Maven. Ciò permette ad un altro sviluppatore di poter integrare tale progetto nel proprio codice, semplicemente dichiarando nelle dipendenze del suo POM la tripla groupid, artifactid e version. Naturalmente non tutti i POM sono così semplici, possono essere ulteriormente arricchiti con indicazioni per il build del progetto, la dichiarazione delle dipendenze (come già accennato prima) ma anche con l inserimento di plugin aggiuntivi rispetto a quelli di base Plugin Un plugin Maven è una collezione di uno o più goal [Figura 14]. Esempi di plugin Maven possono essere: il Jar plugin, adibito alla creazione dei file jar; il Compiler plugin adibito alla compilazione del codice sorgente e delle unità di test; il Surfire plugin che si occupa di eseguire il codice di test e di generare dei report. Oltre a questi plugins di base, ne esistono molti altri molto più specializzati e che spesso lavorano con librerie esterne come Hibernate. Inoltre è data la possibilità allo sviluppatore di implementare il proprio plugin personalizzato, con i relativi goals. Per svilupparlo si può scegliere non solo il linguaggio Java, ma anche altri linguaggi come Ruby, Ant, Groovy, beanshell e molti altri. Questo garantisce flessibilità al codice che si sta sviluppando, ma anche la possibilità di avere una configurazione del progetto che non dipende dal linguaggio di sviluppo del software. Figura 14 Struttura di un plugin ~ 33 ~

35 Un goal è un determinato lavoro che può essere compiuto in maniera a sé stante, oppure insieme ad altri goals. Per lanciarne l esecuzione in Maven, basta scrivere nella shell: mvn pluginid:goalid. Figura 15 Esempio di comando Maven La [Figura 15], mostra come lanciare il goal create appartenente al plugin Archetype. Le tre dichiarazioni successive (-DgroupId=, -DartifactId=, - DpackageName= ) sono parametri che il goal create riceve in ingresso affinché possa effettuare il suo lavoro. Esistono però anche plugins i cui goals non richiedono parametri obbligatori, in questo caso possono non esserci parametri in ingresso, o essere opzionali. I plugin, insieme ai goals che contengono al loro interno, rappresentano il motore di Maven. Infatti senza di essi, il framework non saprebbe fare altro che gestire i classpath di progetto, controllare il file POM e controllare la sintassi dei comandi da shell. Dunque ciò che davvero fa funzionare Maven, sono i suoi plugins, con la peculiarità che ogni sviluppatore può anche decidere di adottarne di propri al posto di quelli già offerti di base Ciclo di vita di Maven Maven supporta differenti cicli di vita, ma ve ne è uno, che è anche quello maggiormente usato, di default. Questo ciclo, inizia con la fase di validazione del progetto e finisce con la fase di rilascio del progetto. Ognuna delle fasi coinvolte in questo ciclo di vita, sono lasciate intenzionalmente vaghe, per consentire la massima flessibilità in base alla tipologia di progetto che si sta sviluppando. Se ad esempio si sta sviluppando un applicazione desktop, il progetto può essere rilasciato sotto forma di jar, ma se invece si sta sviluppando un applicazione software, allora preferiremmo un war. [21] In [Figura 16] è riportato il ciclo di vita di un progetto Maven, comprendente anche i vari goals associati ad ogni fase. Tali goals non appartengono però alle ~ 34 ~

36 fasi del ciclo di vita, ma bensì a plugins che possono essere usati nella compilazione del progetto. Infatti ogni plugins agisce in una determinata fase, e rispettando un preciso ordine (da sottolineare come ogni fase possa avere zero o più di un goals): resources:resources: copia ogni risorsa contenuta in src/main/resources e qualsiasi altri directory di resource specificata, nella directory di output. compiler:compile: compila tutti i file contenuti in src/main/java e li sposta nella directory di output. resources:testresources: copia tutte le risorse contenute in src/test/resources nella directory test di output. compiler:testco mpiler: compila i testcase in src/test/java e li sposta nella directory di output. surefire:test: esegue tutti i test e costruisce i files di output. jar:jar: trasforma la directory di output in un jar file (se invece si ha a che fare con un applicazione per il web, invece di usare il plugin Jar, si può usare quello che produce in output un file war). Figura 16 Ciclo di vita di Maven ~ 35 ~

37 Ma come è possibile far partire questo ciclo di vita? Basta semplicemente scrivere Figura 17 - Comando per la specifica manuale dei goal di una compilazione a shell il comando mvn install (trovandosi naturalmente nella cartella in cui è situato il POM del progetto). Ma vi è anche un'altra alternativa, più macchinosa, ma che permette di specificare a mano che tipo di plugins e goals eseguire durante la compilazione del progetto [Figura 17], anche se questa opzione risulta essere molto più onerosa per lo sviluppatore che è costretto a specificare i plugins per ogni fase Sistema di gestione delle dipendenze Affinché Maven possa usare librerie esterne o progetti sviluppati da terzi, necessita delle cosiddette dipendenze da aggiungere al file POM. Tali dipendenze come già accennato in precedenza permettono di individuare in maniera univoca una libreria all interno del repository grazie alla terna groupid, artifactid e version. Ma avendo solo dipendenze e non un sistema che sia in grado di gestirle, non è possibile importare codice esterno nel proprio progetto automaticamente Figura 18 Dipendenze transitive in Maven ~ 36 ~

38 (soprattutto se si hanno dipendenze transitive da dover gestire). Una delle peculiarità che rende Maven tanto potente è proprio nella gestione delle dipendenze transitive, ovvero quelle dipendenze che non servono direttamente al nostro progetto, ma che occorrono ad una libreria che si sta usando per poter eseguire il nostro codice. In parole povere se un Progetto A contiene nelle sue dipendenze il Porgetto B, e il Progetto B necessita del Progetto C per poter essere eseguito, allora Maven si occuperà di andare a prendere il Progetto C automaticamente. [Figura 18] Tramite questo procedimento si evita al programmatore di scrivere in maniera esplicita ogni dipendenza che serve al suo codice, semplificando il POM ma evitando anche di inserire librerie superflue per errore che andrebbero ad aumentare la grandezza del nostro progetto. Inoltre Maven riesce anche a risolvere i conflitti dovuti alle dipendenze, in modo tale da non causare blocchi dovuti a loop di dipendenze. Per capire come il framework riesca a gestire le dipendenze transitive, basta dare un occhiata ad una libreria scaricata dal Central Maven Repository, come junit : Figura 19 - Contentuto directory junit in Maven Come si può notare in [Figura 19], nella directory in cui è contenuto il jar di junit, non è presente solo la libreria che sarà usata nel progetto, vi sono anche altri file, di cui uno in particolare è molto importante: junit-version.pom. Tramite questo file Maven riesce a ricostruire che tipo di dipendenze occorrono a junit, e ad integrarle in qualsiasi progetto che usi junit. Quindi il repository non salva solo bytecode, salva meta-informazioni contenente informazioni sugli artefatti contenuti in Maven. Inoltre, altra peculiarità e punto di forza del framework, le librerie dichiarate come dipendenze transitive non vengono aggiunte al classpath del progetto, che così non le incorpora direttamente. ~ 37 ~

39 Sono disponibili anche diversi scope per le dipendenze contenute in un progetto, tra cui quelle più frequenti sono: test: specifica che quella determinata libreria non viene usata in fase di compilazione ma solo durante l esecuzione dei test del progetto. In questo modo la libreria non viene aggiunta al jar risultante dal processo di esecuzione del ciclo di vita del progetto. Se invece si vuole generare un WAR, nel caso in cui si debba avere a che fare con un progetto web, allora si può anche imporre di aggiungere tale libreria nel bundle, apportando le opportune modifiche al POM del progetto. provided: in questo caso invece la libreria serve in fase di compilazione, ma anche qui essa non viene aggiunta nel package risultante (sia esso jar, war, o altro) a meno che non sia specificato altrimenti nel POM Riepilogo Nei precedenti paragrafi, si è visto cosa sia Maven e quali miglioramenti abbia apportato nello sviluppo di un progetto, avente o meno più moduli, quali siano i suoi punti di forza, ma soprattutto cosa abbia di diverso rispetto a framework preesistenti e di successo come Ant o EJB. Inoltre si è effettuata una panoramica per quanto generale e semplice possibile su tutti i concetti di base su cui si fonda Maven, e come questi ne influiscano sulla propria struttura. Per saperne di più si consiglia una lettura delle numerose guide che si possono trovare online o dei libri dedicati. 1.3 Spring framework Quando a metà degli anni 90 Java fu presentato al mondo, quasi tutti gli esperti del settore ne intravidero le grandi potenzialità grazie alla sua caratteristica di poter scrivere applicazioni complesse in modo modulare. Ciò che però maggiormente colpì i programmatori, fu la possibilità di sviluppare RIA (Rich ~ 38 ~

40 Internet Application) usando le applets messe a disposizione dal linguaggio di programmazione. Nel Dicembre del 1996 la Sun Microsystem pubblicò una specifica per quanto riguarda i JavaBeans [22]. Tale specifica prevedeva la descrizione di un modello per i componenti software, nonché un insieme di regole per poter rendere il proprio codice modulare e riusabile in applicazioni più grandi. Nonostante queste politiche però, gli sviluppatori usarono principalmente i JavaBeans come modello per la costruzione di widgets nelle interfacce grafiche, non ritenendoli adatti per essere utilizzati in applicazioni complesse. Per ovviare a queste problematiche, la Sun pubblicò nel 1998 la versione 1.0 degli Enterprise JavaBeans (EJB), che aveva lo scopo di venire incontro alle esigenze dei programmatori, ma al contempo mantenere la semplicità che contraddistingueva i primi JavaBeans. Purtroppo però pur andando a semplificare aspetti strutturali come le transazioni e la sicurezza, gli EJB introdussero alcune complicazioni quali file di configurazione e codice non necessario. Col passare del tempo, molti sviluppatori abbandonarono gli EJB alla ricerca di soluzioni più facili con cui poter costruire i loro software. La risposta ai bisogni dei programmatori, arrivò alcuni anni dopo, quando fu presentato lo Spring framework sotto licenza Apache. Esso garantiva un ritorno alla semplicità dei JavaBeans, ma con l introduzione di alcune nuove caratteristiche che ne avrebbero fruttato il successo a discapito dei suoi concorrenti più famosi (Struts per fare un esempio). Di seguito sono elencate alcune delle caratteristiche che hanno convinto gli sviluppatori a passare a Spring (caratteristiche approfondite in maggior dettaglio in seguito): leggerezza: Spring è un framework leggero e grazie alla sua architettura estremamente modulare è possibile utilizzarlo nella sua interezza o solo in parte. L adozione di Spring in un progetto è molto semplice, può avvenire in maniera incrementale e non ne sconvolge l architettura esistente. Questa sua peculiarità ne permette anche una facile integrazione con altri framework esistenti. ~ 39 ~

41 Spring è un lightweight container e si propone come alternativa/complemento a J2EE. A differenza di quest ultimo, Spring propone un modello più semplice e leggero (soprattutto rispetto ad EJB) per lo sviluppo di entità di business. Tale semplicità è rafforzata dall utilizzo di tecnologie come l Inversion of Control e l Aspect Oriented che danno maggiore spessore al framework e favoriscono la focalizzazione dello sviluppatore sulla logica applicativa essenziale. A differenza di molti framework che si concentrano maggiormente nel fornire soluzioni a problemi specifici, Spring mette a disposizione una serie completa di strumenti atti a gestire l intera complessità di un progetto software. Si analizzerànno in dettaglio gli strumenti offerti, per ora è sufficiente affermare che Spring fornisce un approccio semplificato alla maggior parte dei problemi ricorrenti nello sviluppo software (accesso al database, gestione delle dipendenze, testing, etc.). Spring è un framework nato con la concezione che il codice di qualità debba essere facilmente testato. Le tematiche appena citate quali Inversion of Control, Dependency Injection, architettura di Spring e Aspect Oriented Programming saranno approfondite nei prossimi paragrafi, andando di volta in volta a capire come abbiano potuto contribuire al successo del framework Architettura di Spring Spring Framework è composto, come già accennato, da diversi moduli. Tali moduli, all incirca 20 jar, sono scaricati automaticamente in fase di installazione del framework. ~ 40 ~

42 Figura 20 Architettura del framework Spring Naturalmente non tutti i jar con cui si lavora rientrano nella medesima area di competenza, così come non tutti e 20 i jar riguardano ambiti diversi. In generale si possono riconoscere circa 6 area in cui poter suddividere l architettura di Spring, ognuna delle quali collabora con le altre, senza però risultare indispensabile per gli altri moduli. Grazie a questa peculiarità, lo sviluppatore è sia in grado di poter costruire la propria applicazione enterprise in toto, sia in grado di scegliere di non usare alcuni dei moduli messi a disposizione da Spring [1]. In [Figura 20] è riportata la suddivisione dei 20 moduli nelle 6 tipologie, ognuna delle quali è adibita ad un particolare ambito: Core Spring Container: come già accennato dal nome costituisce il cuore dell intera architettura di Spring: esso gestisce, crea e configura i beans creati in un applicazione. All interno di questo modulo si trova lo Spring bean factory, ovvero la porzione di Spring dedita alla depency injection. Tramite il factory, Spring rende disponibile diverse implementazioni dell application context (in parole povere ciò che consente all applicazione che si sta sviluppando di poter accedere ai beans che un programmatore ha ~ 41 ~

43 dichiarato in un suo file di configurazione), ognuno dei quali fornisce una diversa configurazione di Spring. Inoltre tale modulo fornisce servizi come , accesso JNDI (Java Naming and Directory Interface, un API Java che fornisce servizi per directory sul server), integrazione con EJB, e schedulazione. Ognuno di questi servizi è offerto in maniera trasparente all utente, non costringendolo ad usare file di configurazione o a scrivere codice in eccesso per poterli usare nelle proprie applicazioni Modulo AOP Spring: fornisce un ampio supporto per la programmazione orientata agli aspetti. Come la dependncy injection, la programmazione ad aspetti supporta il rilassamento dei vincoli che intercorrono tra le classi adibite ad una funzione e la funzione in se (sicurezza, transazioni, ecc). In questo modo si mira a far diventare un applicazione più modulare, leggera e che abbia codice riusabile.[23] Data access and integration: dovendo lavorare con un database, spesso il programmatore è costretto a scrivere alcune linee di codice superflue necessarie alla creazione della connessione, lavorazione dei risultati e rilascio della connessione col database. Tutto questo codice in eccesso può rendere le nostre classi lunghe e difficili da interpretare da terze persone, per non contare poi della possibilità di errori dovuta alla mancata chiusura di una connessione. Per ovviare a questi inconvenienti, il modulo Data access and integration offre due sotto moduli (JDBC e DAO) che prendono in carico il problema della creazione, gestione e chiusura delle connessioni del database, in modo che l utente si occupi solo dei dati necessari per la propria applicazione. Inoltre, viene offerto una metodologia di gestione degli errori causati dal database, che non è dipendente dal tipo di DBMS che si sta usando, ma viene offerta da questo modulo. Così facendo l utente non dovrà avere a che fare con diverse diciture per il medesimo errore (ad esempio la colonna cercata non esiste in questa tabella). ~ 42 ~

44 Inoltre per chi volesse usare l Object-relational mapping (ORM) è messo a disposizione un modulo apposito. Spring non implementa una propria soluzione ORM, anzi fornisce un supporto per l integrazione con altri framework che ne dispongono: Hibernate, Java Persistence API, Java Data Object, ecc. Altre funzionalità offerte da questo modulo sono: Java Message Service (JMS) per la comunicazione asincrona con altre applicazioni attraverso messaggi; la trasformazione object-to-xml; servizi per la gestione delle transazioni. Web and remoting: nonostante Spring si integri con molti framework MVC già popolari ed efficienti, Spring ne propone una sua versione che aggiunge due varianti: un servlet-base framework per le applicazioni web convenzionali ed un'applicazione portlet-based per lo sviluppo di applicazioni da contrapporre al Java portlet API. In aggiunta all aspetto puramente grafico delle applicazioni sul web, tale modulo offre anche molte opzioni per lo sviluppo di applicazioni che interagiscono con altri programmi (RMI, Hessian, Burlap, JAX-WS e un HTTP invoker). Testing: Spring riconosce gli sforzi di quei programmatori che scrivono non solo la logica e la grafica della loro applicazione, ma che pensano anche allo sviluppo dei test per le loro applicazioni. In quest ottica, il framework dispone di un modulo interamente dedicato al testing del software, naturalmente con il relativo supporto per l integrazione di tali test nel progetto che si sta sviluppando (ciò è garantito dalla presenza di classi mock per il testing di servlet, JNDI e portlet). Dopo aver visto l architettura modulare di Spring, ed aver capito come essa aiuti il framework ad essere leggero e massimamente flessibile alle esigenze del programmatore, si possono introdurre altri due concetti che hanno il medesimo obiettivo: Dependency Injection e AOP. ~ 43 ~

45 1.3.2 Dependency Injection La Dependency Injection fa la sua apparizione per la prima volta in un post di Marti Fowler del 2004, in cui esso lo descrive come un implementazione dell Inversion of Control [Figura 21]. Per IoC si intende un principio Figura 21 Diagramma che esprime il paradigma della dependency injection architetturale che va a stravolgere il punto di vista circa il normale flusso di controllo creato in un programma. Se nella logica tradizionale è lo sviluppatore a decidere il flusso di controllo così come la creazione, inizializzazione e uso dei metodi degli oggetti in un applicazione, nella IoC sarà il framework a occuparsi di tali aspetti. La DI rientra in tale ambito, concentrandosi però solo sulla risoluzione delle dipendenze tra le classi di un applicazione. Se prima era lo sviluppatore che aveva il compito di creare in una classe un oggetto per poterne usare i suoi metodi (e creando in questo modo una dipendenza della Classe A sulla Classe B), ora invece si affida tutto ad un componente esterno alla logica applicativa, il cosiddetto Assembler, che avrà il compito di creare ed istanziare gli oggetti nelle classi in cui sono richiesti. [5] In generale, esistono tre tipologie di Injection: 1. Constructor Injection, dove la dipendenza viene iniettata tramite l argomento del costruttore 2. Setter Injection, dove la dipendenza viene iniettata attraverso un metodo set ~ 44 ~

46 3. Interface Injection che si basa sul mapping tra interfaccia e relativa implementazione (non utilizzato in Spring) Una sorta di Injection Dependency è il pattern factory, usato spesso per istanziare un oggetto demandando però il compito ad una classe adibita al compito. Anche se questo approccio sembra poter disaccoppiare i codici delle classi con cui si lavora, in realtà non fa altro che spostare il problema nella classe factory che si è creata. L unico modo per poter davvero usufruire della DI, consiste nell utilizzare un IoC Container che dovrà prendersi carico della gestione di tutte le dipendenze (in sostanza si tratterebbe di un container che segue le operazioni presenti in un file di configurazione, in cui vi è scritto che la Classe A userà la Classe B). Tale Container, va quindi a sostituirsi alla dichiarazione esplicita di una classe in un'altra, rendendo il compito dello sviluppatore più semplice, ma anche lasciando il codice più leggibile. In Spring tale Container viene direttamente fornito dal framework, e i componenti che esso gestisce vengono chiamati tecnicamente bean. A differenza di altri framework che usano heavyweight container, ovvero container in cui gli oggetti al loro interno devo estendere classi o interfacce, in Spring un bean può essere rappresentato da qualsiasi classe. Si ha così un lightweight container, ovvero un container in cui non vi sono vincoli di nessun tipo. Lo IoC Container è realizzato da due interfacce: BeanFactory, che definisce le funzionalità di base per la gestione dei bean ApplicationContext, che estende queste funzionalità basilari aggiungendone altre tipicamente enterprise come ad esempio la gestione degli eventi, l internazionalizzazione e l integrazione con AOP L interfaccia BeanFactory è il più semplice IoC Container in Spring. Esso si assume il compito di: creare i bean necessari all applicazione, inizializzare le loro dipendenze attraverso l uso dell injection, gestirne l intero ciclo di vita. Per svolgere questi compiti, il container si appoggia a configurazioni impostate dall utente che, riflettendo lo scenario applicativo, specificano i beans che ~ 45 ~

47 dovranno essere gestiti dal container, le dipendenze che intercorrono tra questi oltre alle varie configurazioni specifiche. Si riporta di seguito una delle numerose implementazioni di BeanFactory messe a disposizione da Spring [Figura 22]: l XMLBeanFactory, in cui attraverso uno o più file xml l utente è in grado di specificare le dipendenze che intercorrono tra le varie classi. [4] Figura 22 - Dichiarazione di alcuni bean in Spring Dopo l intestazione del file XML, racchiuse tra i tag <beans>, si trovano le definizioni dei bean e, per ognuno di questi, le eventuali proprietà che ne descriveranno la struttura e il comportamento: Id: identifica univocamente un bean che così può essere usato tramite invocazione al container. Class: indica il nome della classe che si vuole costruire. Risoluzione di dipendenze: mediante metodi getter o setter o attraverso il costruttore, si indica se una classe dipenda da un'altra (un esempio può essere l uso di una classe A nel costruttore). Proprietà comportamentali: definiscono il modo in cui il bean deve essere gestito dal container (scope, ciclo di vita, ecc). Una volta configurato l XMLBeanFactory, basterà usare l ApplicationContext all interno delle classi in cui voler usare uno dei nostri bean. ~ 46 ~

48 Figura 23 - Esempio sulla creazione di bean in Spring Con questo procedimento, qualora si volesse cambiare qualcosa dell implementazione del bean, o se ne volessero creare altri, basterà semplicemente andare nel relativo file di configurazione ed apportare le nostre modifiche. E come è visibile dall esempio in [Figura 23], l impatto per il codice in un applicazione è minimo, dato che consiste semplicemente nell inserire due righe di codice per usare i metodi di una classe esterna al nostro codice Spring AOP (Aspect Oriented Programming) Presente fin dalla prima versione del framework, l Aspect Oriented Programming rappresenta, insieme all Inversion of Control, una delle caratteristiche principali alle quali Spring deve la sua popolarità. Il suo supporto è garantito da Spring AOP, un modulo nativo del framework che nasce con lo scopo di fornire una completa integrazione con il container di IoC. Grazie a questa caratteristica, Spring AOP pur non essendo una delle soluzioni più complete sul mercato risulta essere estremamente flessibile e versatile. A partire dalla versione 2.x Spring AOP è stato esteso con il supporto alle annotation AspectJ (@AspectJ), portando di fatto un forte cambiamento nel modo di concepire AOP in Spring. Prima di iniziare a scoprire le potenzialità AOP di Spring, bisogna introdurre alcuni aspetti fondamentali della programmazione orientata agli Aspetti: ~ 47 ~

49 Crosscutting concern: comportamento trasversale all applicazione che si ripercuote in più punti dell object model. Ne sono un esempio il caching, il logging, l autenticazione o il Transaction Management. AOP nasce per cercare di isolare i crosscutting concern in moduli ben precisi. Aspect: è l equivalente di una classe in OOP ed è utilizzata nella programmazione ad aspetti per modularizzare i crosscutting concern. Grazie agli aspect è possibile aggiungere dinamicamente comportamenti agli oggetti di dominio senza che questi ne siano a conoscenza. All interno di un Aspect, si possono trovare un insieme di Advice, che ne implementano le logiche applicative, ed alcuni pointcut, che ne regolano il flusso. Join Point: rappresenta un punto preciso nell esecuzione del programma, come l invocazione di un metodo o il verificarsi di un eccezione. Advice: descrive l operazione da compiere da parte di un aspetto ad un determinato Join Point. Un advice, a differenza di un metodo che deve essere invocato esplicitamente, viene eseguito automaticamente ogni volta che ad un determinato evento (Join Point) si verifica una particolare condizione (Pointcut). [Figura 24] Figura 24 - Tabella inerente agli Advice in AOP ~ 48 ~

50 Pointcut: descrive le regole con cui associare l esecuzione di un Advice ad un determinato Join Point. Sostanzialmente attraverso un predicato viene specificato che al verificarsi di un determinato Join Point sia applicato un determinato Advice (es: Before). Target: anche chiamato Advised Object rappresenta l oggetto sul quale agisce l Advice. I punti appena elencati, costituiscono le fondamenta della programmazione orientata agli Aspetti, che naturalmente sono ripresi, con qualche cambiamento, in Spring. Per modellare un Advice in Spring è abbastanza semplice e si riduce all implementazione di apposite interfacce con le quali definire le azioni da intraprendere [Figura 25]. Figura 25 - Tabella rappresentante gli Advice in Spring ~ 49 ~

51 Figura 26 - Esempio d uso dell interfaccia MethodBeforeAdvice Come si può notare dall immagine sopra riportata [Figura 26], per la gestione di un Advice, basta far implementare una delle interfacce riportate in tabella ad una classe ed implementare il metodo richiesto dall interfaccia (nel caso dell interfaccia MethodBeforeAdvice il metodo è before). Rimane però ora da occuparsi della gestione del target, ma anche in questo caso Spring limita al minimo le azioni che lo sviluppatore deve compiere. Per poter associare un Advice ad un target object, basta semplicemente andare nel file XML dell IoC Container e specificare tramite i bean chi deve invocare cosa [Figura 27]: Figura 27 Esempio di gestione degli Advice in Spring tramite xml ~ 50 ~

52 Come si può vedere in [Figura 27], il bean avente id bookdaoproxy, tramite il property name interceptornames, riesce a gestire gli advices dichiarati a fine immagine. In questo modo i riferimenti non sono specificati come codice all interno dell applicazione, lasciando così le classi leggibili e senza codice superfluo. Anche se il metodo di gestione e costruzione degli Aspetti precedentemente mostrato sembra abbastanza lineare e di facile utilizzo, Spring dalla versione 2.x ha offerto una metodologia molto più flessibile e potente, basata sull uso delle annotazioni di AspectJ. Ora un Aspect viene trattato come un POJO (Plain Old Java Object, ovvero un semplice oggetto Java) e al suo interno quando viene dichiarato un metodo, deve essere annotato con un tipo di Advice e il conseguente Pointcut avente la lista dei metodi che lo invocano. Così facendo si riducono anche le linee di codice nell IoC Container, dato che ora dovrà solo contenere il nome della classe che farà da Aspect: Figura 28 - Esempio sull uso delle annotation in Spring ~ 51 ~

53 Figura 29 - Esempio sull uso delle annotation in Spring L ultimo bean dichiarato è l Aspect con la relativa logica che si è scelto di implementare. Una peculiarità che aiuta a semplificare il lavoro dello sviluppatore è data dall auto-proxy [Figura 29] [Figura 28]che Spring 2.x mette a disposizione. Come si è potuto notare, rispetto alla versione precedente che era anche più classica come approccio, l ultima modalità ha ridotto di non poco il codice, facendo anche risparmiare tempo. Dopo aver dato un occhiata alle strutture principali usate dal progetto Apromore, si passa ora ad una disamina sull architettura che esso utilizza e su come tali software entrino in gioco. Partendo dal background che ha portato allo sviluppo di Apromore, si passerà ad una breve approfondimento sull architettura su cui esso si fonda, passando poi per esaminare alcuni dei moduli principali che lo costituiscono nonché alcuni dei tools, utilizzabili anche stand-alone, che ne fanno parte. 1.4 Architettura Apromore è stato implementato con un architettura a tre livelli [Figura 30]: livello presentation, livello logic e livello data. [17] ~ 52 ~

54 Figura 30 - Architettura di Apromore Il livello Presentation costituisce l interfaccia del repository, esso contiene il Portal, la vera e propria interfaccia grafica in cui l utente lavora con i suoi modelli, che si interfaccia al Repository Manager, il servizio adibito ad esporre i metodi forniti da Apromore (importare/esportare modelli in differenti linguaggi, effettuare query su un insieme di modelli, sicurezza, controllo delle versioni dei modelli, ecc). Come si evince dalla [Figura 32], l unico punto di accesso al resto dell architettura è costituito dal servizio Repository Manager. Attraverso quest ultimo si andranno a richiamare i servizi adibiti al salvataggio dei modelli nel database, i vari algoritmi attualmente offerti da Apromore (Process Similarity, Process Merger, Business Process Clone Detection, ecc) ed infine il salvataggio dei modelli in un linguaggio particolare (il Canonical Process Format) di cui ci si occuperà in seguito. Nel livello Logic si hanno altre due entità cardine dell architettura: il Canonizer e il Toolbox, entrambi servizi con scopi differenti ma complementari. Il primo opera sui modelli preoccupandosi di creare un interfaccia per la logica sottostante. Ivi si trova il salvataggio dei modelli, la creazione dei formati canonici, delle ~ 53 ~

55 informazioni aggiuntive per ogni modello, ecc. La seconda entità cardine, il Toolbox, si occupa invece di fornire gli algoritmi precedentemente elencati all utente. Grazie alla scelta di frapporre servizi tra i dati e la grafica, si ha così la possibilità di mantenere l architettura flessibile ed aperta all aggiunta di nuovi componenti, nonché di nuovi servizi. Il livello Data incapsula i dati dell architettura software, ivi si trovano un insieme di servizi che operano sui dati e sul loro salvataggio in un DBMS. In particolare, quando un utente crea un nuovo modello, entrano in gioco cinque entità principali, ognuna delle quali svolge un determinato compito [11]: Archivio modelli: i modelli di processo nel loro formato originale XML sono contenuti in questo archivio. Archivio modelli canonici: per ogni modello nel suo formato originale, viene prodotto il relativo modello in formato canonica. Tale formato supera le specifiche di ogni linguaggio di rappresentazione, permettere agli algoritmi presenti in Apromore di lavorare su una specifica comune. Archivio annotazioni: quando un modello canonico viene creato, ad esso si aggiungono alcuni metadati relativi alla rappresentazione del modello, per migliorare gli indici di ricerca,ecc. Tali metadati sono salvati poi sotto forma di annotazioni riferite a quel modello ed organizzate in profili. Archivio patterns: librerie riusabili di definizioni di processi, ovvero pattern che possono essere riusati in altri modelli. Capita spesso infatti che alcuni processi abbaino elementi in comune, e tramite questi pattern si evita di dover perdere tempo ogni volta nel modellare un blocco già fatto in precedenza. Archivio relazioni: le relazioni tra rappresentazioni canoniche di differenti modelli di processo, oppure tra modelli di processo e le loro estensioni. Alla fine del processo nel repository, saranno così salvate due versioni di ogni modello. La prima versione è il modello così come l utente lo ha creato (ovvero il ~ 54 ~

56 modello nel linguaggio scelto dall utente, XPDL, BPMN, ecc). Tale versione non è tuttavia usata direttamente da Apromore e dai suoi algoritmi. Ciò con cui lavorano gli algoritmi è in realtà il Canonical Process Format, ovvero un formato canonico creato ad hoc per permettere il confronto e l elaborazione di modelli costruititi attraverso diversi linguaggi. Esso viene creato in contemporanea al modello originale, e viene salvato nell apposito archivio, pronto ad essere usato qualora l utente voglia effettuare un operazione su qualche modello. Si vede ora in cosa consiste il CPF e come grazie alla sua flessibilità è possibile lavorare con un ampia gamma di tipi di modello. 1.5 CPF (Canonical Process Format) Il formato canonico fornisce una rappresentazione comune e non ambigua di un processo scritto in un linguaggio particolare e con un determinato grado di astrazione. L idea di base è quella di rappresentare solo gli elementi strutturali di un processo, tralasciando gli aspetti grafici propri del linguaggio di rappresentazione da cui proviene il modello. Infatti i primi sono comuni alla maggior parte dei linguaggi di rappresentazione, mentre i secondi variando, rendono spesso impossibile la comparazione tra modelli scritti in linguaggi differenti. Si ha così un linguaggio puramente strutturale, che non ha elementi di rappresentazione come linee, forme o posizioni di oggetti. Tutte queste informazioni superflue ai fini della descrizione di un processo, sono salavate in via separata tramite le annotazioni. Grazie a questa struttura si hanno dei benefici sostanziali rispetto a cinque aspetti: Standardizzazione: non vi è più la necessita di avere differenti algoritmi che lavorano su diverse tipologie di modello. Avendo algoritmi che possano lavorare su un CPF, si riuscirà in realtà lavorare contemporaneamente su diversi modelli scritti in diversi linguaggi. ~ 55 ~

57 Efficienza: non avendo più linguaggi con cui lavorare, si eliminano problemi dovuti alla conversione da un modello ad un altro, così come i tempi di traduzione da un linguaggio ad un altro. Intercambiabilità: grazie alle annotazioni che accompagno ogni modello, si possono operare trasformazioni da un CPF al linguaggio originario, così come da CPF ad un altro linguaggio diverso dall originale. Riusabilità: grazie a modelli standardizzati, è possibile individuare porzioni comuni in differenti processi che possono essere eletti a pattern riusabili all occorrenza. Flessibilità: gli elementi di un CPF sono definiti attraverso un meccanismo di ereditarietà che fa in modo che un processo sia visto, a livello più alto di astrazione, come un grafo diretto. Ciò permette di eseguire operazioni sia a livello di grafo, come ad esempio trovare eventuali cicli, sia di poter effettuare operazioni più specifiche, come ad esempio ricerca di porzioni similari all interno del processo. Grazie al CPF si evita di dover implementare un algoritmo per ogni tipologia di linguaggio supportato dal repository. Per capire come tale risultato sia stato possibile, occorre analizzare il grafico UML che modella un processo. In questo modo si può capire come sia possibile trasformare un processo, per quanto complicato, in un astrazione di un grafo formato solo da archi e nodi. [16] ~ 56 ~

58 Figura 31 - UML del Canonical Process Format Dalla [Figura 31] si evince come un CanonicalProcess, il modello presente nel repository, sia formato da un insieme di Net, ResourceType ed Object. Una Net rappresenta un processo o un sotto-processo, ed è rappresentato da un grafo orientato. Il processo padre, ovvero quello da cui seguono tutti gli altri sotto-processi, è indicato come root. Ogni rete è formata naturalmente da Node e da Edge, in cui questi ultimi devono avere necessariamente una sorgente e una destinazione. Per quanto concerne i Node [Figura 32] essi si suddividono in: Work e Routing. I primi hanno un contenuto informativo rilevante per quanto riguarda il processo, hanno al più un arco entrante ed al più un arco uscente, e si suddividono a loro volta in Event e Task. Un Event può essere: Message: scambio di messaggi tra due entità appartenenti ad un processo (ad esempio l invio di una lettera, la ricezione di una mail, ecc) Time: un azione legata al tempo. Può essere una scadenza, un azione ripetuta per un certo lasso temporale oppure anche solo un tempo morto (un esempio sono l attesa nella ricezione di un pezzo di ricambio, l aggiornamento giornaliero di una DB, ecc) ~ 57 ~

59 Figura 32 - Dettaglio dell elemento Node in CPF Un Task rappresenta invece un elemento in grado di compiere attivamente un azione nel processo (il processare una lettera, registrare un paziente, ecc). Possono essere eventi atomici oppure composti (è il caso dei sottoprocessi). Per quanto riguarda i nodi di Routing, rappresentano quei nodi in cui non si svolgono azioni ma soltanto scelte. Per questo motivo essi possono avere più archi entranti e più archi uscenti. Tali nodi si suddividono in: Split: sono nodi avente un arco entrante e più archi uscenti e rappresentano le scelte possibili conseguenti ad un Work. Essi si suddividono in: OrSplit, XORSplit e ANDSplit. Join: sono i nodi a valle di uno Split, e rappresentano la conseguenza di una scelta. Essi hanno più nodi entranti, corrispondenti alla cardinalità di scelte che si potevano effettuare, ed un solo arco uscente che permette al processo di continuare. Dualmente come nei primi nodi, si ha: ORJoin, XORJoin e ANDJoin. State: per indicare o stato prima di una decisione event-driven oppure uno stato subito dopo una merge. Per quanto riguarda gli Object [Figura 33], essi rappresentano contenuto informativo essenziale che viene adoperato nello svolgimento del processo. Esso si suddivide in due categorie: Hard: rappresenta artefatti fisici come lettere, immagini, ecc; ~ 58 ~

60 Soft: tutto ciò che è digitale come file, tuple in un DB, ecc; Tali oggetti saranno usati dai ResourceType, ovvero dipendenti (identificati dall oggetto Human ResourceType) oppure da sistemi informatici (identificati dall oggetto Non-Human ResourceType). Figura 33 Dettagli degli elementi ResourceType e Object Combinando insieme tali elementi di base, si riesce così a tradurre modelli provenienti da differenti linguaggi, in un modello universale su cui APROMORE potrà eseguire i suoi algoritmi. Tutto questo è stato possibile grazie all analisi effettuata su sei tipi di linguaggi di rappresentazione (EPC, BPMN 1.1, WF-Net, Protos 8.0, YAWL 2.0, WS-BPEL 2.0), che ha portato a stabilire che in realtà esistono elementi strutturali comuni (come può essere un ORSplit o un Task), che però sono graficamente differenti. ~ 59 ~

61 1.6 Interfaccia Apromore Figura 34 Portale di Apromore Ecco in [Figura 34] come si presenta il portale di Apromore, dopo che un utente ha effettuato l accesso tramite il sito (stesso discorso vale per la versione standalone che un utente ha installato sul proprio pc). La grafica è stata interamente sviluppata tramite il frameowork Zk e le sue funzionalità. Le tre zone evidenziate, forniscono all utente tutte le informazioni di cui ha bisogno per poter trovare e scegliere il modello su cui deve lavorare. Mentre i menu a tendina, Process, Filtering e Design hanno un elenco di opzioni che saranno esplicitate in seguito. Nel box verde è racchiuso l albero che permette all utente di poter navigare attraverso le sottocartelle contenute nel repository. Come radice principale dell albero vi è la cartella Home, sotto cui si trovano le altre sottocartelle create dall utente. La Home a differenze della altre cartelle, non può essere rinominata o cancellata. Da notare come nell albero siano presenti solo cartelle e non anche processi. Se infatti un utente volesse visualizzare i modelli contenuti in una cartella, basterà che egli selezioni la cartella a cui è interessato, e il contenuto sarà poi visualizzato nel box blu. Qui l utente visualizza informazioni come: Name: scelto liberamente dall utente quando crea un modello o una sottocartella. ~ 60 ~

62 Id: costituito da un numero, viene dato in modo automatico sia alle cartelle che ai modelli. Per non assegnare medesimo identificativo a due oggetti differenti (che siano cartelle o modelli), l id è incrementale e parte dal numero 0 associato alla cartella Home. Original Language: esprime in che tipo di linguaggio è costruito il modello. Domain: indica se il processo è pubblico per tutti gli utenti oppure se appartiene ad un dominio specificato dal creatore del modello. Ranking: è una valutazione effettuata dagli utenti sul modello. Latest Version: indica l ultima versione disponibile per quel determinato modello. Le precedenti versioni comunque, non vanno sono sovrascritte dall ultima, sono anch esse conservate nel DB a meno che l utente non le distrugga. Owner: indica il proprietario del modello. Ognuna di queste colonne è poi fornito anche di ordinamento automatico, in modo da aiutare l utente nella ricerca di un particolare modello. Come anticipato, di un modello vengono conservate tutte le versioni, ma come e dove esse siano rese disponibili all utente, è mostrato nel box rosso. In quel riquadro al di sotto dell albero, l utente può scorrere tutte le precedenti versioni disponibili di un modello, quando esse hanno subito l ultima modifica, il Branch a cui appartengono e il campo Annotation che specifica il linguaggio in cui è stato editato il modello. Se l utente volesse aprire una di queste versioni, basterebbe selezionare dal campo annotazioni il linguaggio con cui si vuole lavorare, fare doppio click sulla modello ed aspettare infine l apertura dell editor grafico [Figura 37]. ~ 61 ~

63 Figura 35 Editor di Apromore Come si può vedere in [Figura 35], l editor è suddiviso in due zone principali. A destra (riquadro rosso) si trovano tutti i componenti per la costruzione di un modello, suddivisi in varie categorie: Activities, Gateways, Swimlanes, Artifacts, Data Objects, Start Events, Cacthing Intermediate Events, Throwing Intermediate Events, End Events. A sinistra (riquadro verde) vi è la zona in cui disegnare il processo. Per costruire un modello, l utente seleziona l oggetto di cui ha bisogno tra quelli a disposizione a sinistra, lo trasporta nell area verde e lo posiziona dove ne ha necessità. Naturalmente gli oggetti a disposizione dell utente cambiano in base al tipo di linguaggio che esso sceglie per costruire il suo modello. La barra che compare sopra ai due riquadri evidenziati contiene operazioni di base come il salvataggio del modello, copia, incolla e taglia, ma anche funzionalità più avanzate come l autoridimensionamento del modello, l export/import da json il verificatore di sintassi del modello. Facendo riferimento alla schermata in [Figura 37], si spiegheranno ora il contenuto dei menu a tendina Process, Filtering e Design. ~ 62 ~

64 Per quanto riguarda la voce Process [Figura 36], esso contiene la creazione, l import/export, la cancellazione, la modifica, ecc. Una volta selezionato il modello, basta semplicemente selezionare l opzione a cui si è interessati. Figura 36 Dettaglio del menu Process In alcuni casi, vedasi Create model, si aprirà una finestra aggiuntiva in cui l utente può specificare alcune opzioni come [Figura 37]: nome del modello, dominio, linguaggio, proprietario, ecc. Figura 37 Interfaccia per la creazione di un nuovo processo Per quanto riguarda il menu Filtering [Figura 38], ivi si trovano due opzioni molto utili nell analisi dei modelli di processo: Similarity Search e Clone Detection. ~ 63 ~

65 Figura 38 Dettaglio del menu Filtering Il Similarity Search è un opzione che dato un modello in input, e selezionata una cartella del repository, è in grado di trovare i modelli simili a quello in input che hanno una similarità maggiore o uguale a quella della soglia specificata. Figura 39 Interfaccia dell algoritmo Similarity Search La [Figura 39] compare una volta selezionato il modello e cliccato su Similarity Search. Come si può notare vi è la possibilità di scegliere tra due tipi di algoritmi (Greedy e Hungarian), nonché di poter variare alcuni parametri come soglia di similarità delle label, oppure del modello, del contesto ecc. Inoltre si ha la ~ 64 ~

66 possibilità di ricercare solo tra le ultime versioni dei modelli contenuti nella cartella selezionata a sinistra, oppure tra tutte le versioni disponibili. Il risultato della ricerca sarà poi visualizzato nel portale, e riporterà per ogni modello lo score di similarità rispetto al modello padre, nonché le altre informazioni di base dei modelli [Figura 40]. Figura 40 Risultato del Similarity Search Per quanto riguarda il Clone Detection, è un algoritmo che lavora all interno di un modello e ne ricerca i frammenti uguali. Ad esempio se in un processo è presente più volte un ordine di pagamento, probabilmente sarà composto dalle medesime attività. L algoritmo si occupa di trovare proprio queste ripetizioni, in modo che chi gestisce il modello di processo possa creare dei pattern facili da riutilizzare (ad esempio creando sottoprocessi). Figura 41 Interfaccia grafica per il clustering in Apromore Basta scegliere il tipo di algoritmo (DBSCAN o HAC), la grandezza del clone da identificare (ovvero il numero di nodi minimo per cui due frammenti si possono dire uguali) ed infine selezionare show Clusters per visualizzare le componenti uguali [Figura 41]. ~ 65 ~

67 Figura 42 Dettaglio del menu Design Si analizza ora all ultimo menù, Design, ed alle sue funzionalità [Figura 42]. Ivi si trovano tre opzioni: Merging: in grado di fondere insieme un certo numero di modelli scelto dall utente e di produrre il modello nella cartella da cui provengono i processi sorgente. Questionnaire-driven configuration: Define model: questionnaire mapping: 1.7 Vantaggi nell uso di Apromore Dopo aver visionato l architettura di Apromore, come riesca a gestire diversi linguaggi di rappresentazione dei modelli di processo, ed avere avuto un piccolo scorcio della grafica user-friendly di cui dispone, si può ora passare all analizzare i vari motivi per cui un ente (sia pubblico o privato) o un gruppo di ricercatori nell ambito del Business Process Management, possano trarre beneficio dall uso della piattaforma. Innanzitutto il primo beneficio consiste nella distribuzione gratuita del software Apromore. In questo modo chiunque abbia interesse nell analisi di modelli tramite tecniche avanzate e non commerciali si può tranquillamente avvicinare alla piattaforma. Da questo punto di vista il guadagno è sia per l utente che può usare tutti i tool messi a disposizione nel repository, sia per il progetto che aumenta il ~ 66 ~

68 proprio bacino di utenza, rendendolo di rimando anche più famoso alla comunità accademica e non. Per quanto riguarda le aziende, la piattaforma mette a disposizione molte opzioni di cui altri software attualmente in commercio non dispongono (un esempio è la capacità di gestire più linguaggi nella stessa piattaforma, ed avere elementi di analisi avanzati come il Similarity Search e il Clone Detection). In questo modo l uso di Apromore non viene limitato alle sole aziende che adottano un particolare linguaggio nella modellazione dei loro processi. Inoltre tale flessibilità permette ad un azienda di poter avere i propri modelli in differenti linguaggi, senza che la stessa debba adoperare del personale per la traduzione di un modello. Per quanto concerne invece gli algoritmi presenti su Apromore, essi sono offerti in maniera chiara e trasparente, aiutando così coloro i quali che non sanno nulla di programmazione ad andare avanti nel loro lavoro e a produrre risultati professionali. Da non dimenticare poi il fatto Apromore è disponibile sia online che in versione standalone. Ciò permette di poter caricare i propri modelli sul repository, non usando un server aziendale proprietario, e di poter creare, tramite la creazione di un Dominio, gruppi di lavoro in seno all azienda per determinati modelli. Di contro, la versione standalone può essere utile per coloro i quali vogliano ampliare il progetto immettendo una propria funzionalità, oppure semplicemente avere tutto ciò di cui Apromore dispone sul proprio pc, senza caricare necessariamente i modelli online. Ultimo punto, ma non meno importante, è l ambito di ricerca che ha dato vita al progetto, e che da esso può continuare a trarne beneficio. Nato dalla collaborazione di diverse università sparse per il mondo (Eindhoven University of Technology, University of Grenoble, University of Tartu, Vienna University of Business and Economics, Cooperative State University Karlsruhe, Bonn-Rhein- Sieg University of Applied Sciences) e coordinate dal Queensland Universit of Technology, il progetto ha stimolato, e continua a stimolare, la produzione di software che va ad arricchire Apromore con nuove funzionalità. Questo è garantito dall architettura a servizi di cui dispone il software, che rende possibile ~ 67 ~

69 lo sviluppo di plugin per il web (di cui è presente una guida sul sito Apromore.org) che possono essere integrati facilmente. ~ 68 ~

70 CAPITOLO 2: PQL: A Process Query Language Grazie al grande successo avuto dal business process management in ambito aziendale, il numero di modelli per la rappresentazione dei processi è aumentato in maniera critica, arrivando a numeri di centinaia, ed a volte, migliaia di modelli per un singolo ente. Naturalmente non tutti i modelli sono formati da pochi task o hanno un flusso di facile comprensione, rendendo così il lavoro degli analisti aziendali molto difficile e dispendioso. Per ovviare a tali problemi, col passare degli anni si sono sviluppati linguaggi d interrogazione per collezioni di modelli di processo. Tramite questi linguaggi (BPMN-Q o BP-QL per citarne alcuni) l analista può confrontare e recuperare informazioni da centinaia di modelli, senza avere la necessità di effettuare un lavoro manuale. Come si può vedere nell esempio di [Figura 43], si nota che i due processi Figura 43 Esempio di due modelli simili in BPMN ~ 69 ~

71 esprimono la medesima operazione (l'apertura di un conto bancario da parte di un utente). Entrambi hanno lo stesso numero di task, ma struttura leggermente diversa. Infatti, il primo modello effettuerà sempre un Analyse customer credit history, mentre nel secondo caso vi è la possibilità di terminare il processo in Open VIP account. Tramite uno dei linguaggi d interrogazione precedentemente citati, un analista potrebbe estrarre questi due modelli da un insieme di centinaia, tramite un interrogazione del tipo Ritorna tutti i modelli che iniziano con Receive customer request e finiscono con Analyse customer credit history. Anche se quest approccio potrebbe sembrare adatto a lavori di questo tipo, ci si rende conto che spesso non è del tutto fedele alle richieste dell utente. Infatti se nel primo modello Analyse customer credit history segue sempre il task Receive customer request, nel secondo caso questo non avviene. Quindi non ci si può solo servire della struttura del modello per poter effettuare interrogazioni, si deve anche inserire una certa semantica che permetta di distinguere casi come il precedente. Per questo motivo sono stati sviluppati in seguito linguaggi che tenessero conto anche del tipo di operazioni che venivano effettuati in un modello, in modo da poter permettere interrogazioni sempre più fedeli alle richieste fatte dall utente. PQL (Process Query Language) è nato con il proposito di unire analisi sintattica e analisi semantica di un modello per accrescere l accuratezza di un interrogazione. Un esempio di come la semantica aumenti il numero di risultati coerenti con l interrogazione effettuata consiste nella disambiguazione delle etichette in un modello. Molte volte capita di trovare in un modello etichette che hanno il medesimo significato di quella immessa nell interrogazione, costituita però da parole diverse (per esempio le frasi Acquista prodotto e Compra prodotto hanno lo stesso significato nonostante siano scritte in modo diverso). Inoltre con l aggiunta di un punteggio di similarità è data la possibilità di limitare la somiglianza tra etichette ad una determinata soglia, in modo da poter filtrare tutti quei risultati poco conformi ai criteri dell utente. ~ 70 ~

72 Di seguito saranno spiegata in breve la sintassi e la semantica del linguaggio PQL, riportando anche alcuni esempi per facilitarne la comprensione. 2.1 Sintassi PQL è un linguaggio d interrogazione che è indipendente dal modello di processo e dal linguaggio in cui esso è rappresentato. Grazie a questa peculiarità è possibile interrogare vari modelli scritti anche in linguaggi differenti, sicuri che PQL si concentrerà solo sui contenuti del modello, tralasciando gli aspetti visivi. Affinché sia possibile conseguire gli obiettivi sopra proposti, è necessario individuare aspetti come le occorrenze dei task in un processo, così come le relazioni che intercorrono tra i vari task in un modello. Una volta compiuta tale operazione, si può passare a definire determinati predicati di base che li rappresentano e che vanno a costituire il nucleo del linguaggio PQL. In seguito si utilizzerà t per indicare un task all interno di un modello r ed i per identificare una traccia di esecuzione per un processo, e con essi si vedranno tutti i predicati di base, scritti in una sintassi astratta, che compaiono all interno del linguaggio: 1. posoccur(t,r): indica che il task t ricorre almeno una volta nell esecuzione del modello r; 2. alwoccur(t,r): indica che il task t ricorre in tutte le esecuzioni del processo r; 3. exclusive(t 1,t 2,r): indica che il non è possibile avere nella medesima esecuzione di un processo il task t 1 e il task t 2 ; 4. concur(t 1,t 2,r): indica che ambo i task, in una qualsiasi esecuzione del processo r, devono verificarsi (non importa se prima t 1 e dopo t 2 o viceversa); 5. succession any (t 1,t 2,i): nella traccia di esecuzione i, per quante siano le ricorrenze di t 1, almeno una di esse deve precedere t 2 ; 6. succession every (t 1,t 2,i): nella traccia di esecuzione i, per quante siano le ricorrenze di t 1, ognuna di esse deve precedere necessariamente t 2 ; ~ 71 ~

73 7. precedence any (t 1,t 2,i): nella traccia di esecuzione i, per quante siano le ricorrenze di t 1, almeno una di esse deve succedere t 2 ; 8. precedence every (t 1,t 2,i): nella traccia di esecuzione i, per quante siano le ricorrenze di t 1, ognuna di esse deve succedere necessariamente t 2 ; 9. isucc any (t 1,t 2,i): nella traccia di esecuzione i, t 1 ricorre almeno una volta ed è immediatamente succeduto da un istanza di t 2 ; 10. isucc every (t 1,t 2,i): nella traccia di esecuzione i, ogni istanza di t 1 deve essere susseguita da un istanze di t 2 ; 11. ipred any (t 1,t 2,i): nella traccia di esecuzione i, esiste almeno un istanza di t 1 ed essa è seguita immediatamente da t 2 ; 12. ipred every (t 1,t 2,i): nella traccia di esecuzione i, ogni istanza di t 1 è seguita immediatamente da t 2 ; Questi sono solo alcuni dei predicati di base, i restanti si formano utilizzando le seguenti formule sui predicati dal numero 5 al numero 12 (il simbolo Φ indica uno dei predicati in precedenza esposti): [9] Φ (t 1,t 2,r): Φ(t 1,t 2,i) il predicato è vero per ogni esecuzione i del processo r; Φ (t 1,t 2,r): Φ(t 1,t 2,i) il predicato è vero per almeno un esecuzione i del processo r; Dopo aver elencato gli elementi base del linguaggio, si può ora passare alla sua formulazione astratta, soffermandoci ogni volta sugli elementi di maggior rilievo. La grammatica che seguirà, segue la notazione descritta da B. Meyer nel suo articolo Introduction to the Teory of Programming Languages. Essa consiste semplicemente di una grammatica astratta, in cui i costrutti elencati hanno funzione puramente logica ed esplicativa. Nessuno di essi può essere sostituito in un interrogazione usata dall utente, perché le parole usate, non sono riconosciute come parole chiavi del linguaggio. Come ultima peculiarità, questa notazione permette di esprimere la grammatica come un insieme di costrutti ed un insieme finito di produzioni (ognuna di esse è associata ad un costrutto ). Ogni ~ 72 ~

74 costrutto a sua volta descrive un insieme di oggetti chiamati campioni, usando produzioni di tre tipi: choice, list e aggregate. Query vars: Variables; atts: Attributes; locs: Locations; pred: Predicates La definizione sopra riportata è il costrutto di più alto livello nella grammatica di PQL. Esso descrive infatti da quali elementi sia composta un interrogazione nel Process Query Language. Il costrutto Query è definito come una produzione aggregata di quattro componenti (Variables, Attributes, Locations e Predicates, ognuna preceduta dal suo tag). In questo momento l ordine con cui sono elencati i componenti di un interrogazione è irrilevante ai fini della definizione della Query. La posizione che dovranno ricoprire all interno di un interrogazione sarà specificata solo in ultima analisi, per permettere al programmatore di potersi concentrare solo sulla struttura dei componenti. Variables, Attributes e Locations sono definite attraverso una produzione list di campioni facente riferimento ad un altro costrutto (una lista è essenzialmente una sequenza di zero, uno o più elementi): Variables Variable * Attributes Attribute + Locations Location + Si ha così che in un interrogazione PQL vi è la presenza di zero, una o più variabili e la presenza di almeno un attributo, così come deve essere necessaria la presenza di almeno una locazione. [10] Una variabile è definita da due costrutti: il nome della variabile ed un insieme di lavori appartenenti ad alcuni dei modelli che si hanno a disposizione. Variable name:variablename; tasks: SetOfTasks Come si vedrà più avanti, le variabili serviranno nei predicati per sostituire l insieme dei lavori che rappresentano, col nome della variabile. Tramite questa scelta, l utente non è costretto a scrivere interrogazioni troppo complesse, piene di nomi di lavori oltre che dei vari costrutti necessari, ma risulta tutto ordinato e ~ 73 ~

75 comprensibile. Quando poi l interrogazione sarà processata, in fase di esecuzione i nomi delle variabili presenti nei predicati saranno sostituiti dal loro contenuto. L Attribute è qualsiasi cosa che riesca ad identificare univocamente una collezione di processi o anche solo un processo, sia esso un ID, un nome o un altro identificativo. Per quanto riguarda un Attribute nel contesto di Apromore, esso può assumere i valori di: Universe, ID, Name, Domain, Language, Owner, Ranking e Version. Per quanto riguarda la prima parola chiave precedentemente elencata, essa ha il medesimo valore della * nel linguaggio SQL, restituire all utente l insieme di tutti gli attributi che costituiscono un modello. Per le altre parole chiave esse hanno un significato auto-esplicativo e non richiedono un ulteriore approfondimento. La cosa importante da sottolineare, è come tali parole possano essere combinati a seconda delle necessità degli utenti. Qualora sia necessario, si possono scegliere anche dei sottoinsiemi dalla lista precedentemente fatta, ed effettuare interrogazione che restituiscano solo ID e Name dei processi, piuttosto che Owner, Language e ID. Inoltre è anche data la possibilità di inserire sempre, per quanto possa essere contro intuitivo, la parola chiave Universe. Se si ha così un interrogazione avente come attributi ID, Name e Universe, il risultato sarà naturalmente tutti gli attributi caratterizzanti un processo (ovvero ID, Name, Language, Version, Owner, ecc). Attribute Universe ID Name Language Version Owner Ranking Domain Occupandoci ora delle Location, esse identificano i modelli di processo da cui voler estrarre le informazioni specificate negli Attributes. Per fare un paragone col linguaggio SQL, una Location è il corrispettivo di una tabella nella clausola FROM. Location Universe LocationID LocationDirectory Come riportato dalla definizione sopra citata, una Location può assumere quattro valori. ~ 74 ~

76 Universe: permette ad un utente di selezionare tutti i modelli contenuti nel repository in cui sta lavorando; LocationID: sarebbe l identificativo univoco che distingue un modello da un altro; LocationDirectory: si è già visto che Apromore raggruppa i modelli tramite un sistema di cartelle e sotto-cartelle. Sfruttando questa struttura, l utente può decidere di selezionare tutti i modelli contenuti in una cartella. Qualora la cartella contenesse sotto cartelle, i modelli appartenenti alle sotto cartelle, sarebbero comunque considerate nel processamento dell interrogazione; A differenza degli Attributes, in cui un utente poteva comporre più Attribute a suo piacimento, nelle Locations l utente è costretto a fare una choice. Dunque o si sceglie di selezionare tutti i modelli di processo presenti nel repository (Universe), o si usano solo LocationID dei modelli che ci interessano, oppure si possono scegliere le LocationDirectory per selezionare i modelli appartenenti a quelle cartelle. Pur rappresentando un vincolo un po scomodo per l utente, tale scelta fa solo parte della definizione della grammatica. In fase implementativa può essere superata dando la possibilità all utente di specificare Universe oppure un insieme di LocationID e LocationDirectory. Sarà poi compito del programmatore tradurre tali locazioni in un formato univoco da passare al motore che interpreterà l interrogazione. Si nota ancora una volta come la grammatica sia scevra dall implementazione postuma che effettuerà il programmatore. L ultimo costrutto rimasto, ovvero il Predicate, è formato da una produzione choice di costanti e costrutti che elencati a breve. Per permettere al lettore di capire intuitivamente a cosa servano i Predicates, si ricorre ancora una volta ad un paragone con il linguaggio SQL. In quest ultimo linguaggio è presente la clausola WHERE, in cui un utente mediante delle condizioni può discriminare le tuple appartenenti ad una tabella. I Predicates rappresentano quelle condizioni, e permettono similmente di discernere i modelli di processo che rispettano i criteri dell utente. ~ 75 ~

77 Predicate UnaryPredicate BinaryPredicate LogicalTest UnaryPredicateMacro BinaryPredicateMacro SetPredicate TruthValue Negation Conjunction Disjunction Di seguito vengono analizzati uno ad uno ognuno dei suddetti tipi di predicato: Negation, Conjunction e Disjunction: sono il corrispettivo degli operatori logici negazione, congiunzione e disgiunzione. TruthValue: indicano un valore di verità tra true, false e unknown. UnaryPredicate: indicano un predicato che ha come argomento un tasks appartenente a qualche modello. BinaryPredicate: come il predicato sopra descritto ma che riceve in ingresso due tasks anziché uno soltanto. UnaryPredicateMacro: sostanzialmente svolge il medesimo ruolo di un UnaryPredicate, con la differenza però che è applicato su un insieme di lavori ed ha un quantificatore che determina se ai fini del valore di verità del predicato influisce almeno un modello di quelli elencati o tutti. UnaryPredicateMacro UnaryPredicateName; SetOfTasks; AnyAll AnyAll ricopre la funzione di quantificatore (esistenziale o universale), mentre SetOfTasks è l insieme di lavori su cui applicare il predicato specificato da UnaryPredicateName. Per come è definita la grammatica, e per come è stato già anticipato, SetOfTasks può contenere sia una lista di lavori specificati dall utente, ma può essere sostituita anche da una Variable. BinaryPredicateMacro: svolge una funzione simile al BinaryPredicate, solo che questa volta gli argomenti possono essere Task/SetOfTasks oppure SetOfTasks/SetOfTasks. LogicalTest: è usato come stimatore del valore di verità di un predicato. Avendo a che fare con una logica con tre possibili valori di verità (vero, falso e sconosciuto), si dà la possibilità all utente di testare il valore di un predicato tramite: IsTrue IsNotTrue IsFalse IsNotFalse IsUnknown IsNotUnknown ~ 76 ~

78 SetPredicate: è usato per verificare se un task appartiene ad un dato insieme di tasks, oppure effettuare operazioni insiemistiche su due insiemi di task (Identical, Different, OverlpsWith, SubsetOf, ProperSubsetOf). A seguire sarà mostrata una possibile grammatica concreta del linguaggio PQL scritta tramite ANTLR (ANother Tool for Language Recognition). Una particolarità che non sarà sfuggita al lettore, riguarda la definizione di query presente a riga 9 di [Figura 46]. Come si può vedere si adottano le medesime parole chiavi usate nel linguaggio d interrogazione SQL: SELECT, FROM e WHERE. Tale scelta è motivata proprio dalla grande notorietà che SQL ha acquisito col passare del tempo, ma anche dal fatto che è un linguaggio usato in molti DMBS commerciali (se non per intero in qualche sua variante). Così facendo si aiuta l utente a familiarizzare prima con PQL, consentendo un facile apprendimento della sua sintassi. A seguire sarà mostrata il resto della grammatica [Figura 44]. ~ 77 ~

79 ~ 78 ~

80 Figura 44 - Sintassi PQL 2.2 Semantica di PQL In questo paragrafo sarà spiegato, in modo formale, il significato di ogni costrutto non terminale precedentemente esposto nella sintassi. Come primo passo s introdurranno alcune definizioni che permetteranno di capire meglio in seguito il significato delle operazioni non terminali. Definizione 1 (unione prevalente): l unione prevalente di f : X -> Y da g : X -> Y, denotata da f g, è definita come f U g / {(x, f(x)) x dom(f) dom(g)}. Definizione 2 (lavoro non-silente): sia N un modello di processo e T l insieme dei lavori in esso contenuti, per ogni t 1,t 2 T e φ BP b : Formula 1 Lavoro non silente ~ 79 ~

81 ovvero, la relazione dovrebbe essere era se ambo i lavori non sono silenti contemporaneamente. Per BP b si intende l insieme dei predicati binari presenti nel linguaggio, per φ un predicato appartenete al precedente insieme, per L N (t) la label associata al lavoro t. Definizione 3: sia N un modello di processo e T l insieme dei lavori in esso contenuti, per t T e ψ BP U : Formula 2 Predicati unari la suddetta relazione dovrebbe valere in N se t non è un lavoro silente. Per BP U si intende l insieme dei predicati unari presenti nel linguaggio, per ψ un predicato appartenente al precedente insieme. Definizione 4 (Binding): data la possibilità di definire variabili, che saranno poi usate o meno in un interrogazione, bisogna definire un legame tra la variabile e l insieme di lavori ad essa associata: Binding ProcessModel XVarname -> 2 Task Definizione 5 (Repository): per repository si intende l insieme di tutti i modelli di processo su cui un utente può effettuare un interrogazione: Repository 2 ProcessModel Definizione 6 (valutazione interrogazione): la funzione valutazione interrogazione restituisce i modelli di processo che soddisfano l interrogazione effettuata: M Query : Query X Repository -> 2 ProcessModel La valutazione dell interrogazione dipende naturalmente da che predicati sono stati usati e dagli assegnamenti dati alle variabili, si parlerà così d insieme di assegnamenti. In tale insieme una variabile può comparire più volte e può ~ 80 ~

82 incamerare differenti valori (da ricordare che un variabile non è altro che una notazione ristretta che rappresenta un insieme di lavori). Naturalmente ai fini della valutazione dell interrogazione varrà solo l ultimo assegnamento. M Assignements : Assignamets X Repository X Binding -> Binding Formula 3 - Assegnamenti Definizione 7 (predicato): produce tutti i processi di modello sufficientemente simili al task specificato nel predicato (in congruenza alla similarità delle label dei tasks coinvolti): M Predicate : Predicate X Repository X Binding -> 2 ProcessModel Formula 4 - Predicato Definizione 8 (relazione tra Task): un predicato può produrre anche relazione tra i task, ed in questo caso genera tutti i modelli di processo che soddisfano tale relazione: ~ 81 ~

83 M TaskRel : TaskRel X Repository X Binding -> 2 ProcessModel Formula 5 Relazione tra task Definizione 8 (insieme di Task): di base indica una collezione di lavori appartenenti ad un modello di processo, però può anche essere riferito all insieme di lavori assegnati ad una variabile dichiarata nell interrogazione. In ultima analisi un insieme di Task può essere anche Costruito (adoperando gli operatori ~ 82 ~

84 UNION, INTERSECTION e DIFFERENCE ) oppure Applicato (definito attraverso proprietà di base riferite ad alcuni predicati). M TaskSet : TaskSet X Repository X Binding -> (ProcessModel -> 2 Task ) Formula 6 Insieme di Task 2.3 Esempi di interrogazioni PQL A seguire saranno mostrati alcuni esempi d interrogazioni sviluppate con il linguaggio PQL. Alcune delle primitive che saranno usate, apparterranno alla sintassi astratta del linguaggio d interrogazione (nel momento in cui tale tesi è ~ 83 ~

85 scritta, PQL non ha ancora concluso la sua traduzione da linguaggio astratto a linguaggio concreto in toto). Le funzionalità mancanti saranno comunque aggiunte in futuro, permettendo così all utente di poter sfruttare appieno le potenzialità del linguaggio. La struttura degli esempi che si mostreranno seguirà lo schema: Interrogazione in linguaggio naturale Interrogazione in linguaggio PQL Esempio di modello di processo che soddisfa l interrogazione Per quanto riguarda le lettere in maiuscolo all interno delle interrogazioni, esse rappresentano etichette che identificano lavori all interno di un processo (tali lettere vanno da A L). Q1: Seleziona tutti i modelli di processo in cui il lavoro A è presente in alcune esecuzioni, mentre il lavoro B è presente in ogni traccia di esecuzione. SELECT * FROM * WHERE TaskPos("A") AND TaskAlw("B"); Figura 45 - Esempio di processo Figura 46 Esempio di processo Si sono riportati due esempi, [Figura 45] e [Figura 46], di modello di processo che aiutano a capire meglio la formulazione dell interrogazione Q1. Come si può notare il primo esempio non è altro che una serie di lavori in cascata, mentre il secondo modello ha una diramazione XOR (in cui è possibile intraprendere solo una delle scelte a disposizione). In ambo i casi, il lavoro A è sempre effettuato, la discriminate è però il lavoro B. Infatti se nel primo caso il lavoro B è sempre ~ 84 ~

86 effettuato, data la natura a cascata del processo, nel secondo esempio lo XOR fa sì che il lavoro B abbia una possibilità di non essere eseguito. Dunque solo il primo modello risponde ai fini dell interrogazione, mentre il secondo risulta non adatto. Q2: Seleziona tutti i modelli di processo dove è possibile che il lavoro A sia svolto prima del lavoro D. SELECT * FROM * WHERE AlwSuccAny("A","D"); Q3: Seleziona tutti i modelli di processo in cui il lavoro A è svolto sempre prima dello svolgimento del lavoro D. SELECT * FROM * WHERE AlwSuccEvery("A","D"); Figura 47 Esempio di processo Le interrogazioni Q1 e Q2 sono entrambe soddisfatte dal suddetto modello di processo [Figura 47]. Infatti come si può notare il lavoro A è effettuato sempre prima del lavoro D (grazie agli AND gate presenti dopo il lavoro A, i lavori B, C, D, E ed F sono sempre effettuati, verificando così le due interrogazioni precedenti). Inoltre l esempio appena riportato, soddisfa anche le seguenti interrogazioni: Q4: Seleziona tutti i modelli di processo in cui può accadere che in qualche esecuzione il lavoro A avvenga prima del lavoro B, e che il lavoro B avvenga prima del lavoro K. SELECT * FROM * WHERE PosSuccAny("A","B") AND PosSuccAny("B","K"); Q5: Seleziona tutti i modelli di processo in cui il lavoro A avviene sempre prima del lavoro B in qualche esecuzione. SELECT * FROM * WHERE PosSuccEvery("A","B"); ~ 85 ~

87 Q6: Seleziona tutti i modelli di processo in cui il lavoro B avviene il parallelo con il lavoro C. SELECT * FROM * WHERE Concur("B","C"); Figura 48 Esempio di processo (d) La [Figura 48] soddisfa le ultime due interrogazioni effettuate (Q5 e Q6), basta notare i lavori nella zona evidenziata. A seguire verrà formulata un'altra interrogazione verificata per il modello appena proposto. Q7: Seleziona tutti i modelli di processo in cui il lavoro B avviene in parallelo con il lavoro C, ed in cui il lavoro A avviene in parallelo con il lavoro H. SELECT * FROM * WHERE Concur("B","C") AND Concur("A","H"); ~ 86 ~

88 Progettazione modulo per PQL Nel capitolo precedente si è ampiamente discusso del linguaggio d interrogazione PQL e della sua utilità per l utente nell ambito della ricerca di particolari modelli. Tale linguaggio, solo mostrato nella sua sintassi nonché nella sua semantica, deve ora essere tradotto in un pacchetto software che sarà integrato all interno della piattaforma APROMORE e dovrà essere fornito di un interfaccia grafica che guidi l utente nella formulazione delle proprie interrogazioni. Naturalmente per usufruire al meglio delle potenzialità offerte dal linguaggio PQL, è necessario costruire un interfaccia grafica il quanto più possibile semplice per l utente, ma che al contempo fornisca un valido supporto nella formulazione di un interrogazione. Si parlerà così di tutte le funzionalità presenti nel modulo software che si è sviluppato, di come siano state organizzate le classi per ottimizzare le prestazioni del modulo, nonché delle interrogazioni, il processo attraverso il quale il modulo è stato integrato nella piattaforma APROMORE ed infine si fornirà una piccola guida per l utente in cui si vedranno, attraverso alcuni esempi, le potenzialità che il software è in grado di offrire. 3.1 Specifiche Come già spiegato nell introduzione della tesi, il software che si è andato a sviluppare consiste essenzialmente in un interfaccia grafica, il quanto più semplice possibile, che dovrà pilotare l utente nella formulazione delle sue interrogazioni PQL. Infine, bisognerà poi visualizzare, in maniera apposita, i risultati di tali interrogazioni. La vera sfida per il conseguimento delle due operazioni, riguarda la costruzione di un interfaccia mediante il framework Zk, con cui è costruito il portale web APROMORE. Infatti pur sembrando scontata e di facile implementazione come scelta, nei prossimi paragrafi si vedrà invece come essa risulta più ardua da conseguire, e richieda per tale motivo un compromesso tecnico. ~ 87 ~

89 Dunque il primo requisito fondamentale deve essere necessariamente una grafica in stile APROMORE, e per ottenere questo obiettivo bisogna ricorrere a ZK, il framework tramite il quale è stata costruita l interfaccia della piattaforma web. Tale scelta è dettata soprattutto dal fatto che avere diverse grafiche nella stessa piattaforma, oltre a non essere visivamente accattivante per l utente, può introdurre confusione e portarlo ad abbandonare la piattaforma. In secondo luogo, usando le medesime classi già usate nell interfaccia grafica di APROMORE, si può riutilizzare del codice già esistente, abbattendo così i tempi necessari alla costruzione del nuovo modulo. Naturalmente qualora si renda necessario si può migliorare o variare in alcune sue parti un componente già definito, per adattarlo alle proprie necessità. Avendo individuato così la scelta migliore con cui costruire la grafica, si può passare a trattare la sua struttura. Prima di azzardare una possibile struttura per la grafica, si devono innanzitutto individuare le parti fondamentali del linguaggio a cui dovrà dare supporto (ovvero il linguaggio PQL). Come si è visto nel secondo capitolo, tale linguaggio è essenzialmente diviso in quattro parti fondamentali: 1. Enumerazioni delle variabili 2. Clausola SELECT, in cui l utente specifica che informazioni ricavare dai vari modelli (una lista di attributi quali ID, name, original language, ecc) 3. Clausola FROM, in cui si specificano i vari modelli o directory da cui ricavare i risultati (si ha così una lista di modelli o directory separate da virgole) 4. Clausola WHERE, in cui si enumerano le condizioni che i modelli devono soddisfare affinché facciano parte del risultato (predicati unari o binari, combinazioni d insiemi di variabili o modelli, ecc) Dall elenco sopra riportato si notano due cose fondamentali: che l elenco delle variabili non ha una struttura rigida come il resto dell interrogazione e che la parte più complessa dell interrogazione riguarda la clausola WHERE. Alla luce di quanto esposto, si può decidere di separare le variabili dal resto dell interrogazione, separare le quattro parti o lasciarle tutte insieme. Si inizia con ~ 88 ~

90 l esaminare l ultima scelta, ovvero quella di tenere legate la parte delle variabili con le tre clausole. In questo caso si ricorrerebbe al massimo ad un area di testo unica, in cui l utente può scrivere prima le variabili e successivamente l interrogazione (in accordo a quanto specificato nella sintassi del linguaggio). Nonostante il vincolo della sintassi, nessuno costringe l utente a poter scrivere prima l interrogazione ed in seguito la lista delle variabili che vuole usare. Naturalmente in quest ultimo caso si restituirà un errore all utente, ma invece di costringere quest ultimo ad effettuare in seguito tale correzione, sarebbe meglio pilotarlo nella costruzione dell interrogazione. Dunque l idea di usare un'unica area di testo è da accantonare in favore delle altre due opzioni precedentemente esposte. Ritornando ai punti in cui è divisa un interrogazione, sarebbe allora ovvio separare tutte e quattro le parti, usando per ognuna di esse un area di testo. In questo modo l utente saprà cosa scrivere in ognuna delle aree, evitando una prima fonte di errori. Naturalmente nessuno obbligherà l utente a dover necessariamente scrivere le variabili nell apposito spazio, ma in questo caso egli saprà a priori che l interrogazione è malformata e che quindi riceverà un errore. Inoltre mettendo a disposizione un area di testo per ogni parte dell interrogazione, si possono adottare contromisure adeguate nel caso che l utente commetta degli errori (ad esempio andando ad evidenziare solo le parti contenenti gli errori, evitando così che l utente sia costretto ad interpretare tutto ciò che abbia scritto). Il lato negativo risultante da tale approccio, come si può intuire, è una ridondanza eccessiva delle aree di testo. Queste ultime danno l impressione all utente di dover riempire un questionario online, piuttosto che un'interrogazione SQL-like. Come ultima motivazione si riporta il confronto con i più famosi database commerciali (MySQL, PostgreSQL), che come aree in cui poter scrivere un interrogazione, mettono a disposizione dell utente un'unica area di testo ingrandibile all occorrenza. Una volta scartata anche quest ultima scelta, si può passare a descrivere quella più logica, che sarà anche poi quella adottata nel modulo sviluppato, ovvero quella di due aree distinte, una in cui poter scrivere la lista delle variabili e l altra in cui poter scrivere il resto dell interrogazione. ~ 89 ~

91 La scelta di suddividere l interrogazione in due parti offre all utente una maggiore chiarezza su dove scrivere cosa, ed inoltre permette al contempo di poter trovare in modo semplice gli errori commessi. Basti pensare che nella prima parte si avranno solo liste di variabili, e che quindi se l utente visualizzerà un messaggio di variabile non dichiarata, dovrà aggiungerla in tale area. Naturalmente in tale area è possibile aggiungere un meccanismo d individuazione degli errori in tempo reale, in modo da permettere le adeguate contromisure immediatamente, e non dopo aver lanciato un interrogazione (un approccio simile a molti IDE di sviluppo come Eclipse e NetBeans, che sottolineano gli errori di sintassi immediatamente). Per quanto concerne la seconda parte, quella relativa all interrogazione, si può usufruire degli stessi benefici precedentemente citati. Infatti anche qui è possibile individuare in modo mirato gli errori che l utente può commettere, ma è anche possibile aiutarlo a ridurli al minimo. Tale scopo è infatti raggiunto con l introduzione di opzioni per l auto-completamento delle parole chiavi e/o dei processi che si vogliono ricercare, costruzione automatica delle clausole SELECT e FROM ed evidenziando le parole chiavi, i valori delle clausola SELECT e i processi con colori diversi. Le scelte appena esposte saranno esaminate nel dettaglio, e per ognuna di esse si esporranno eventuali pregi e difetti. Si parte con l esporre come poter offrire la funzionalità di auto-completamento all interno di un area di testo. Anche qui le scelte possono essere molte, ma di sicuro quella forse più intuitiva, e maggiormente utilizzata da molti DBMS e software per la programmazione, consiste nell adottare una piccola schermata vicino alla parola correntemente scritta. In questo modo l utente può visionare le possibili scelte, e semplicemente cliccando sulla parola ricercata inserirla dove ne ha bisogno. Un possibile problema riguarda naturalmente il numero di suggerimenti disponibili. Nel caso precedentemente riportato si nota come la parola whe scritta dall utente abbia soltanto due parole chiavi simili: when e where. Entrambe possono essere visualizzate dato che lo spazio occupato da queste due parole sia molto ristretto. Nel caso in cui però, le parole dovessero essere in numero maggiore, per esempio 10 o 15, visualizzarle tutte potrebbe ~ 90 ~

92 Figura 49 Particolare della grafica MySql essere un problema, dato che la schermata dei suggerimenti si andrebbe ad ingrandire notevolmente. Come è visibile in [Figura 49] riportato qui a lato (ripreso da MySQL Workbench), per ovviare alla mancanza di spazio derivante dal grande numero di parole, si ricorre ad una finestra con barra scrollevole a lato. In questo modo si possono visualizzare le prime parole, lasciando poi all utente la possibilità di ricercare la parola desiderata tramite l uso della barra. Come osservazione banale, si può evincere come le parole elencate nella finestra dei suggerimenti, siano in ordine alfabetico ed abbiano a lato un icona che le identifica ( k per keyword e f() ad indicare una funzione) per aiutare l utente nella sua ricerca. Inoltre qualora l utente volesse raffinare la sua ricerca, potrebbe digitare una lettera, per esempio a, e la finestra dei suggerimenti si aggiornerebbe mostrando solo parole la cui iniziale sia a, come ad esempio abs, acos, ecc [Figura 50]. Figura 50 Particolare del menu di suggerimento in MySql ~ 91 ~

93 Per agganciarci al secondo punto precedentemente citato, l uso di colori diversi per evidenziare e distinguere le parole, si possa fare ancora riferimento agli esempi mostrati. Come si può notare le parole select e from sono colorate in celeste, mentre le parole appartenenti alla clausola select non hanno una particolare colorazione [Figura 50]. Un ulteriore esempio [Figura 51] aiuta a capire come l uso di colorazioni diverse riesca a distinguere in un sol colpo le varie parti dell interrogazione (parole chiavi, commenti, nomi di tabelle, attributi). Purtroppo però, pur essendo un vantaggio, l uso di colori per distinguere le diverse tipologie di parole, può trasformarsi in un arma a doppio taglio. Se infatti i colori sono troppo vivaci, come può esser il giallo, o le tipologie di parole sono in gran numero, l utente potrebbe confondersi. L uso di colori troppo forti infatti, Figura 51 Colorazione delle parole chiavi in MySql può dare fastidio all utente che si appresta a scrivere un interrogazione anche molto complessa, causando non poche fonti di distrazione. Per quanto riguarda la molteplicità di colori dovuta alla varietà di tipologie di parole, esso rappresenta più una cacofonia agli occhi dell utente che in questo modo può non riuscire a distinguere in maniera adeguata le varie parti dell interrogazione. In sostanza bisogna riuscire a trovare un giusto compromesso tra tipi di colori, e il loro numero. L ultimo punto da esporre, la composizione automatica delle clausole SELECT e FROM, è un aggiunta pensata apposta per venire incontro alle necessità degli utenti più pigri. In nessun DBMS commerciale infatti è prevista l opzione di ~ 92 ~

94 poter generare in automatico parte della interrogazione mediante valori predefiniti. Per esplicitare meglio il concetto, si pensi a cosa debba fare l utente per scrivere un interrogazione in MySQL: scrivere select, scrivere gli attributi a cui esso è interessato, scrivere from, scrivere la/le tabelle da cui estrarre le informazioni, scrivere where, scrivere le condizioni relative al risultato voluto. Come si può notare dalla catena di azioni precedentemente scritta, vi sono i primi quattro punti che sono obbligatori e al contempo molto semplici, mentre gli ultimi due sono opzionali. Dunque si potrebbe permettere di generare in automatico i primi quattro punti mentre gli ultimi due sarebbero da far scrivere a mano all utente qualora egli lo ritenga necessario. Naturalmente adottando per la clausola select dei valori di default, mentre per la clausola from trovare un modo per specificare quali processi voler analizzare con l interrogazione. In questo modo l utente può produrre molto velocemente le interrogazioni più banali (per intenderci quelle in cui non esiste la clausola where ), e può comunque risparmiare tempo nella stesura delle interrogazioni più complesse, non dovendosi preoccupare delle prime parti (infatti in queste ultime interrogazioni la parte più corposa è rappresentata dalla clausola where, in cui la presenza di più predicati rende impegnativa la formulazione del risultato che si vuole raggiungere). Con quest ultimo punto si è conclusa la trattazione riguardante le aree adibite alla composizione dell interrogazione da parte dall utente, spiegando di volta in volta le scelte che si sono effettuate. Rimane però un ultimo aspetto fondamentale, quello della continuità con il portale di Apromore. ~ 93 ~

95 Figura 52 Portale Apromore Per conseguire questo aspetto bisogna innanzitutto individuare quali sono le parti fondamentali nella grafica della piattaforma online. Come si può notare dalla [Figura 52], si hanno tre componenti fondamentali che risaltano subito all occhio dell utente: l albero dei processi, la tabella delle versioni di un singolo processo ed infine l elenco dei modelli di processo contenuti in una cartella. Nel nostro modulo sarebbe preferibile ricostruire una schermata di questo tipo, trovando spazio per l inserimento delle aree di testo, ed eliminando le parti non necessarie. Riflettendo sull obiettivo che si vuole conseguire, ovvero una grafica per la formulazione di interrogazioni SQL-like, si può eliminare in prima battuta l elenco dei modelli nel riquadro azzurro. Esso infatti, oltre ad occupare un consistente spazio, può essere integrato Figura 53 Aggiunta dei modelli di processo nell albero di Apromore ~ 94 ~

96 nell albero a lato recuperando spazio e mantenendo al contempo una forma ordinata. Inoltre, eliminando la parte relativa alla cornice azzurra, si è ricavato lo spazio necessario all inserimento delle aree di testo nonché di altre funzionalità. Per quanto riguarda invece l albero delle cartelle e la tabella nel riquadro rosso, esse possono rimanere, al massimo apportando qualche piccolo cambiamento funzionale al nostro modulo. L albero, come si può notare [Figura 53], può essere migliorato con l introduzione dei modelli di processo nella gerarchia delle cartelle. In questo modo non occorre un ulteriore lista in cui far vedere all utente il contenuto di una cartella. Inoltre, l albero può essere usato come fonte di scelta da cui l utente seleziona i modelli da inserire nella clausola FROM della sua interrogazione. Anche in questo caso vi sono diverse scelte, tra cui spiccano due metodologie di fondo: permettere all utente di selezionare solo modelli di processo oppure permettere di selezionare cartelle e modelli di processo (ed aggiungere in ambo i casi, nella clausola FROM, ciò che si è selezionato). Il primo approccio è sicuramente da sconsigliare dato che costringerebbe l utente a dover aprire le cartelle contenenti sotto-cartelle, e selezionare da esse i modelli contenuti. Sarebbe fattibile se le gerarchie delle cartelle non fossero profonde, ma sarebbero comunque scomode per quanto riguarda la praticità. La seconda scelta risulta sicuramente la migliore, dato che l utente potrebbe selezionare una cartella, contenente cartelle e modelli di processo, ed aggiungere il tutto con pochi click all interrogazione. Solo quando l utente ha selezionato le sorgenti, l utente può trascinare le selezioni nell area di testo, ed esse compariranno nella clausola FROM (ovviamente evitando di inserire modelli di processo già esistenti). Un'ultima accortezza è data dalla scelta di non mescolare identificativi di modelli di processo e cartelle, onde evitare di creare confusione nell utente, ma soprattutto per seguire un discorso incentrato esclusivamente sui modelli di processo. Infine, quando l utente seleziona una cartella e la trascina sull area di testo dell interrogazione, si selezioneranno tutti i modelli di processo contenuti in essa. Così facendo sarà possibile inserire nella clausola FROM dell interrogazione, solo gli identificativi dei processi, in modo da poter disambiguare processi con medesimo nome contenuti in cartelle differenti. ~ 95 ~

97 Per quanto riguarda la tabella al di sotto dell albero, quella Figura 504 Tabella versioni Apromore bordata di rosso in [Figura 52], può essere usata per apportare delle migliorie funzionali ai nostri scopi. Dall ingrandimento di [Figura 54], si possono notare i quattro campi di cui essa è costituita: Branch (o ramo della versione), Version (indica appunto le release di un processo, dato che quest ultimo può averne anche più di una), Last Update (o ultimo aggiornamento) e Annotations (ovvero i linguaggi di rappresentazione disponibili per quel modello di processo). Ai fini della nostra applicazione, non tutti i suddetti campi sono necessari. Infatti si deve riuscire ad identificare i modelli di processo che saranno poi inseriti nella FROM della nostra interrogazione, in che formato siano essi scritti è irrilevante. Dunque si può eliminare l ultima colonna e trasformare la tabella nel seguente formato. Come si può notare il modello di processo che l utente ha selezionato ha solo due versioni disponibili. Nel caso in cui le versioni fossero molte di più, si potrebbe pensare di far comparire a lato della tabella una barra scrollabile per aiutare l utente nella sua ricerca della versione da selezionare, ed una volta trovata codesta versione, trascinarla nell area di testo dell interrogazione. Come ultimo accorgimento si potrebbe addirittura pensare di effettuare un ordinamento delle versioni del modello di processo mediante il click su Figura 55 Trasformazione della tabella delle versioni uno dei titoli della tabella (naturalmente l ordinamento sarà effettuato lessicograficamente se si clicca sul titolo BRANCH e numericamente nel caso di click su VERSION o LAST UPDATE) [Figura 55]. Ricapitolando, si sono esposte tre specifiche essenziali che il modulo software a supporto del linguaggio PQL deve offrire (campi in cui inserire variabili e ~ 96 ~

98 interrogazione, un albero dei modelli di processo da cui selezionare le locazioni e una tabella per poter selezionare le versioni relative ai modelli). Non si sono considerate però eventuali implicazioni e/o rapporti che tali componenti possono generare. Come citato nei precedenti capoversi, sia l albero che la tabella delle versioni, permetterebbero all utente di poter selezionare un modello da inserire nella clausola FROM. E possibile quindi far in modo che una dipenda dall altra, e che tutte e due insieme forniscano un miglior supporto all utente. In poche parole, si potrebbe pensare di far selezionare all utente un modello dall albero, e consentirgli poi di selezionare tutte le versioni, la versione più recente o solo alcune versioni dalla tabella posta sotto l albero [Figura 56]. Figura 56 Esempio della grafica che dovrà avere il tool per la stesura delle interrogazioni (a) Purtroppo, pur potendo scegliere la versione che più ci interessa dalla tabella, sarebbe scomodo ricercare ogni volta l ultima versione o selezionare tutte le versioni disponibili di un modello. Pur avendo a disposizione l ordinamento delle colonne nella tabella, bisogna fornire all utente un metodo più facile e veloce per scegliere i modelli di cui necessita. Avendo elencato prima le tre possibili azioni che l utente può intraprendere (ultima versione, tutte le versioni, un sotto insieme ~ 97 ~

99 delle versioni di un modello), si deve offrire il modo migliore per la selezione del modello di processo per l utente. La natura intrinseca del problema ci porta a scegliere un approccio basato o su un menù a tendina o su una serie di checkbox, con cui l utente può cambiare ogni volta la modalità di selezione dei modelli di processo. Si espongono vantaggi e svantaggi del menu a tendina per constatare se esso vada bene o no. Innanzitutto il menù non occupa molto spazio ed è facilmente sistemabile all interno della grafica. Di contro però non permette all utente di avere in vista le possibili opzioni a disposizione, e risulterebbe macchinoso nel caso in cui l utente debba fare più selezioni magari diverse tra loro. Passando invece ai checkbox, essi costituiscono componenti forse ingombranti ai fini della grafica, ma permettono all utente di avere tutte le opzioni a disposizione e non risultano troppo ardui nel caso si voglia cambiare spesso modalità. Dunque è molto meglio scegliere i checkbox, perdendo dal punto di vista dello spazio nella grafica, ma guadagnando in funzionalità per l utente. Inoltre si potrebbe anche pensare di far in modo che le versioni nella tabella apparissero e scomparissero a seconda della modalità di seleziona scelta dall utente. In sostanza quando l utente attiva la modalità ultima versione o tutte le versioni, i processi si possono direttamente scegliere dall albero dei processi. Di contro nella modalità seleziona versioni, selezionando un processo dall albero, immediatamente apparirebbero le sue versioni nella tabella, permettendo all utente di scegliere quelle a cui è interessato. Da notare un problema la cui risoluzione è pressoché immediata: se l utente è in modalità seleziona versioni, l albero deve consentire la scelta multipla? E negli altri due casi (ultima versione e tutte le versioni) si deve permettere la selezione multipla dall albero? La risposta alla prima domanda è necessariamente no. Sia perché è poco logica come azione (si tratterebbe di mescolare versioni appartenete a due processi diversi) sia perché l utente ha comunque la possibilità in pochi click di scegliere posteriormente le versioni dal secondo modello. Per quanto concerne invece la seconda domanda che si è formulata, la risposta è dipende. Infatti garantire la multi-selezione dei modelli ~ 98 ~

100 dall albero, favorisce naturalmente il compito dell utente, però non è detto che debba essere un obbligo. Si è dunque introdotta una nuova funzionalità che porterà a cambiare la grafica nel modo seguente [Figura 57]: Figura 57 - Esempio della grafica che dovrà avere il tool per la stesura delle interrogazioni (b) Si sono così snocciolate tutte le possibili azioni per assistere l utente nella formazione della propria interrogazione (dalla finestra dei suggerimenti, all autocompletamento, al drag and drop dei modelli nell area di testo). E il caso però di concentrarsi anche su aspetti quali il salvataggio di dati o finestre di riepilogo aggiuntive che forniscono maggiori informazioni sulle interrogazioni che sta effettuando l utente. Ragionando a fondo, si può affermare che di dati da salvare nella nostra applicazione non ve ne sono. Vi sono però variabili e interrogazioni che potrebbero servire in futuro all utente e che quindi quest ultimo sarebbe costretto a riscrivere ogni volta salvo che non gli si fornisca un metodo per il loro salvataggio/caricamento. Dove queste informazioni siano salvate, o da dove esse siano caricate lascia però un interrogativo. Infatti si può dare la possibilità di salvare le interrogazioni sia in locale, ma anche di poter fornire una cartella online qualora non si voglia occupare dello spazio sul proprio pc, o per permetterne la ~ 99 ~

101 condivisione con altri utenti. Inoltre è una funzionalità che anche i maggiori DBMS ormai hanno (vedasi MySql), ed è di facile implementazione qualora si voglia mettere a disposizione. Non è una problematica nemmeno trovare uno spazio in cui inserire tale comando, dato che basta aggiungere un menù. Per quanto riguarda invece l introduzione di componenti riepilogativi (come tabelle o aree di testo non editabili), si può prendere spunto dai software per l interrogazione delle basi di dati. In essi, oltre allo spazio in cui scrivere l interrogazione, compare anche una finestra in cui si visualizzano gli errori sintattici, e i motivi per cui un interrogazione è fallita. Funzionalità questa molto utile per l individuazione degli errori da parte dell utente, e che ci motiva ad inserire un suo omologo all interno del nostro modulo. Le modalità con cui si andranno ad inserire saranno probabilmente le stesse presenti nei DBMS, ovvero tramite un area di testo non editabile, e non rappresenterebbe uno sforzo eccessivo data la natura di semplice cattura dell errore che si propaga dall interrogazione. Altra funzionalità che si potrebbe aggiungere, a quelle finora fornite, è una tabella riepilogativa riguardo ai modelli inseriti nell interrogazione. Se ad esempio l utente prende in esami molti modelli, ognuno dei quali ha molte versioni, la clausola FROM tende a crescere molto velocemente, non permettendo all utente di poter avere una visione d insieme sulle operazioni che sta facendo. Onde evitare questi problemi, si mette a disposizione tale tabella in cui si fornirà all utente: ID, nome, owner, language, version, ed altri campi qualora sia necessario. Il vero problema però consiste nel non poter inserire questa tabella nella grafica principale, ma nel doverla far apparire pop-up (problema di per se non enorme e che risulta elegante come soluzione). Elencate di seguito, vi sono tutte le principali funzionalità che il nostro software deve avere: Area di testo per le variabili Area di testo per l interrogazione Albero per la scelta dei modelli di processo Tabella riassuntiva per le versioni dei modelli ~ 100 ~

102 Tre diverse modalità di scelta dei modelli di processo (ALL, LAST e CHOOSE) Tabella riepilogativa dei modelli presenti nella FROM Area di testo per gli errori di sintassi Salva/Carica dei modelli sul filesystem o sul web Conclusa così l analisi delle specifiche del software da implementare, si focalizza l attenzione sulla fase di integrazione della logica PQL all interno della piattaforma APROMORE. Dato che tale procedura consta di più passi, ed è legata intimamente con le tecnologie Maven ed OSGI, si riporteranno varie screenshot per una migliore comprensione del processo nonché i risultati ottenuti. 3.2 Integrazione modulo PQL nell architettura Apromore Nel capitolo due della tesi è stato spiegato approfonditamente la sintassi e la semantica del linguaggio PQL, ivi si spiegherà invece come la libreria adibita all interpretazione del linguaggio sia stata integrata nell architettura di APROMORE. Particolare enfasi sarà rivolta alla traduzione di tale libreria in modulo Maven spiegandone, in prima analisi, le motivazioni e le difficoltà del procedimento, e solo in seguito si passerà a spiegare la parte prettamente tecnica mediante opportune screenshot. Come esposto nel primo capitolo, la piattaforma APROMORE si poggia fortemente su tecnologie quali Maven, per la generazione dei moduli di cui è composto Figura 58 Contenuto del jar org.jbpt nonché per esplicitare le dipendenze tra moduli, e Spring, ~ 101 ~

103 come contenitori dei moduli derivanti da Maven e la loro gestione. Dunque qualsiasi libreria che si trova all interno della piattaforma è già in formato Maven e non crea alcun problema laddove, nell implementazione di un nuovo modulo, si volesse usare un jar appartenente al repository. Il problema ivi sorge a causa della mancanza di qualcosa adibito alla gestione del linguaggio PQL. Tale libreria infatti, sviluppata dal ricercatore del QUT Artem Polyvyanyy, è esterna all architettura di APROMORE e di base non è in formato Maven. L obiettivo sarà quindi quello di trovare una soluzione a questo primo problema, cercando di trovare laddove possibile una soluzione elegante. Innanzitutto, come fa la libreria PQL a lavorare con modelli di processo scritti in diversi linguaggi? [Figura 58] Ebbene essa non è in grado di riconoscere BPMN, EPML o YAWL, ma solo reti di Petri, con l ulteriore vincolo che esse siano sound ed appartengano alla categoria delle workflow-net (ovvero una rete avente unico input ed unico output). Come sia stata possibile la traduzione di tutte le reti presenti nel repository di Apromore, nel formato precedentemente esposto verrà spiegato più avanti nel paragrafo della progettazione, qui si sposta l attenzione sui passi che la libreria esegue nella valutazione di una rete passata in input. Si inizia quindi col verificare se un determinato modello di processo sia effettivamente una workflow net. Per farlo si deve prima tradurre ogni elemento del modello di processo in un oggetto java usando la libreria open source disponibile all indirizzo Effettuata questa prima operazione, si può, tramite le classi contenute in org.pql.mc, verificare la soundness della rete così costruita. Per la verifica si ricorre ad un tool esterno chiamato Lola model checker, che è uno dei maggiori software per la verifica strutturale sulle reti di Petri. Naturalmente, sia la libreria jbpt che Lola dovranno essere inserite in APROMORE ricorrendo anche qui a Maven. Una volta appurata la soundness della rete, il prossimo passo consiste nel salvataggio delle informazioni relative alla rete (posti, transizioni, etichette, token presenti nella rete, ecc). Le informazioni, salvate in due basi di dati differenti (MySql e PostgreSQL), sono gestite dalle classi presenti in org.jbpt, org.pql.label e org.pql.persist (l uso dei due DB è stato reso necessario soprattutto per alcune funzionalità che PostgreSQL ~ 102 ~

104 offre a dispetto di MySql). Si sta cercando però di integrare le tabelle salvate in PostgreSQL nel DB MySql, in modo da non costringere gli utenti a dover installare due basi di dati sullo stesso computer, qualora vogliano sviluppare codice standalone sulla propria macchina. Per quanto riguarda le informazioni salvate, bisogna porre maggior attenzione su come siano salvate le etichette relative ai lavori presenti nei processi. Esse non sono semplicemente estratte dai modelli e salvate, ma subiscono un processo di stemming (un processo mediante cui si ha la riduzione di una parola in forma flessa nella sua forma radice). Tale processo è reso necessario affinché l utente possa effettuare interrogazioni sui modelli, pur non sapendo con esattezza le etichette contenute in essi (si ricorda che PQL offre la possibilità di inserire una soglia si somiglianza riguardo le etichette, proprio per facilitare il compito nelle interrogazioni dell utente). Una volta effettuata l indicizzazione del modello, ovvero il processo di salvataggio nei database delle informazioni, l utente può effettuare le sue interrogazioni sul modello (e qui intervengono le classi in org.pql.query). Il prossimo passo da compiere, dopo aver visto la struttura della libreria, consiste nel trasformarla da semplice libreria java, a modulo Maven da importare all interno di APROMORE. Per compiere tale operazione, bisognerà però controllare prima le varie librerie da cui PQL dipende, e verificare che anche queste ultime siano in formato Maven. Alcune dipendenze sono già state esplicitate precedentemente (MySql e PostgreSQL), di seguito si elencano ora le altre librerie utilizzate da PQL: Antlr4: è un potente generatore di parser per la lettura, l'elaborazione, l'esecuzione, o la traduzione di testo strutturato o file binari. E 'ampiamente utilizzato per creare linguaggi, strumenti e framework. Da una grammatica, ANTLR genera un parser in grado di costruire e navigare alberi di analisi Ini4j: un API Java per gestire la configurazione dei file Windows.ini Themis: è una libreria adibita all Information Retrival. ~ 103 ~

105 Jbpt-petri: utile per la costruzione e gestione di reti di Petri Json: una libreria adibita allo scambio di dati. Essa adotta un formato di testo completamente indipendente dal linguaggio di programmazione Si è ora pronti a spiegare i passaggi necessari affinché le librerie sopra esposte diventino in formato Maven, e permettano così l integrazione di PQL nella piattaforma web. Il processo che si andrà a spiegare rappresenta una delle maggiori barriere incontrate durante il processo di sviluppo del modulo software. Basti pensare che senza tutti i software descritti precedentemente, lo sviluppo di una grafica per la formulazione d'interrogazioni sarebbe stata fine a se stessa, non potendo interagire con la logica per cui era stata implementata. Una delle prime operazioni compiute riguardo le librerie citate, è stata una ricerca online nel repository di Maven. Ivi si possono ricercare le librerie che sono già in formato Maven, e che quindi non necessitano una traduzione ma soltanto l aggiunta della relativa dipendenza nel pom destinazione. Tale ricerca ha portato a constatare che le librerie Maven-ready, erano: MySql, PostgreSQL, Ini4j, Json e Antlr4. Le uniche librerie così che rimanevano da tradurre erano Jbpt-Petri, PQL e Themis. Per effettuare tale operazione bisognava scaricare il codice sorgente di ognuna delle precedenti librerie, costruire un progetto Maven che ripercorresse il loro packaging ed infine scrivere il file pom.xml per ognuno di essi. Pur sembrando un processo semplice e lineare, bisognava solo dare un nome al progetto Maven e inserire le giuste dipendenze all interno del file pom, in realtà ha presentato non pochi problemi. Infatti una volta compilati ed inseriti all interno di APROMORE come librerie Maven, tali librerie generavano conflitti che non permettevano l esecuzione del modulo Apromore-Manager. Dopo svariati tentativi, in cui si è variata la struttura del pom dei vari progetti, si è arrivati infine ad adottare un approccio basato su OSGI. Quest ultima tecnologia, spiegata in parole semplici, non fa altro che prendere un file.jar e trasformarlo in un bundle, mediante l opportuna riscrittura del file MANIFEST.MF. Sostanzialmente, una libreria jar standard contiene al suo interno due oggetti: la cartella META-INF (in ~ 104 ~

106 cui è contenuto il MANIFEST.MF) e la cartella contenente i file.class (nel caso sotto riportato la cartella org) [Figura 59]. Figura 59 Contenuto di un file.jar Qualora alcune delle classi presenti nel jar avessero bisogno di librerie, queste ultime potrebbero essere assegnate ad una terza cartella, dal nome lib, proprio all interno del jar. Ciò che trasforma un jar in bundle, non è la struttura del jar, per quanto diversa da quella del bundle, ma il file MANIFEST.MF [Figura 60]. Figura 60 MANIFEST.MF di un file.jar ~ 105 ~

107 Figura 61 MANIFEST.MF di un bundle Come si nota dalle immagini [Figura 60] e [Figura 61], il manifest di un bundle contiene molte più informazioni rispetto a quello di un jar (da notare che l esempio di bundle manifest riportato, non è nemmeno completo. In rosso sono inoltre evidenziate le parti salienti del manifest). Non si spiegherà a cosa servano i numerosi campi del bundle manifest perché esula dai compiti di questo paragrafo, però si porrà particolare enfasi su Export-Package. Quest ultimo attributo elenca le varie cartelle, contenenti.class, di cui è composto il nostro bundle, e per ognuna di tali cartelle elenca le dipendenze. Per rendere al meglio il concetto, basta notare la prima riga di Export-Package. Si vede infatti che le classi contenute in org.postgresql usano le classi contenute in org.postgresql.copy, org.postgresql.fastpath, ecc. Come si può intuire questo approccio è molto simile alla tecnologia Maven, con la differenza però che OSGI elenca per ogni package le sue dipendenze. Bisogna dunque trasformare i jar generati dalla compilazione Maven in bundle OSGI. Ma come si possono trasformare i manifest all interno delle librerie PQL, Jbpt-Petri e Themis evitando di svolgere tutto il lavoro a mano? Ad aiutarci in questa operazione è un plugin Maven, maven-bundle- ~ 106 ~

108 plugin. Tramite questo plugin è possibile analizzare la struttura del packagin della libreria che si vuole trasformare in bundle, e per ogni package al suo interno è possibile ricavare da quali altre librerie esso dipenda. Un esempio ripreso dal pom di jpbt-petri, chiarirà meglio quanto spiegato a parole poc anzi: Figura 62 File POM del progetto jbpt-petri OSGI Nell esempio di [Figura 62] si evince innanzitutto il goal che si intende raggiungere al termine della compilazione con Maven (punto numero uno, packaging bundle). Appurato il prodotto che si vuole conseguire, bisogna però specificare cosa inserire al suo interno. A tale scopo servono le istruzioni dichiarate a seguito del punto numero 2 configuration. Come si può notare ogni campo dichiarato sotto il precedente tag, ha un corrispettivo anonimo nel ~ 107 ~

109 MANIFEST.MF del bundle che si verrà a generare a seguito della compilazione. Unica eccezione riguarda il tag Import-Package, che non avendo figli o testo, non verrà poi riportato nel file manifest. Inoltre ciò che manca nel pom, è la parte relativa alle librerie che ogni package usa (quell elenco di package a seguito della parola uses presente nel MANIFEST.MF). Quest ultima parte è generata in automatico dal plugin ed inserita senza che l utente si debba adoperare per controllare a mano ogni dipendenza, facendo risparmiare così tempo. Un tag particolare su cui prima non ci si è soffermati a lungo, è Embed-Dependency. In questo tag l utente può inserire una lista di librerie che si vuole importare nel proprio bundle, e che quindi verrà inserita nella cartella specificata da Embed- Directory. Se si pone maggiore attenzione a quanto dichiarato nel pom file sopra riportato, si noterà come nella lista delle librerie embedded, si trovi jbpt-petri, che è la libreria che bisognerà trasformare in OSGI. Quindi ora rimane il dubbio, jbptpetri, è stata o no trasformata in libreria OSGI? Ebbene la risposta è no. Infatti si è deciso di non trasformare direttamente la libreria, soggetta a cambiamenti, in formato OSGI, bensì si è pensato di creare un wrapper di tale libreria, e con esso costruire una libreria OSGI che ne ripercorresse fedelmente la struttura. In questo modo, se la libreria sorgente (jbpt per intenderci), subisse variazioni sulla struttura, basterebbe cambiare la parte relativa a Export-Package nel pom e si risolverebbero i problemi relativi. Stesso approccio è stato usato anche per le altre due librerie, PQL e Themis, permettendo al contempo di guadagnare altro tempo. Infine, per completezza, si è deciso di trasformare in librerie OSGI anche PostgreSQL, Ini4j, Antlr4, Json e Jbpt-Core. Una precisazione, tutte le librerie precedentemente citate hanno subito una trasformazione che non è disponibile online, ma che comunque serve a far funzionare APROMORE in locale. Dunque se un utente dovesse scaricare APROMORE e non cambiasse tali librerie, riscontrerebbe numerosi problemi all atto dell installazione della piattaforma. Per risolvere quest ultimo problema si è deciso di aggiungere ad APROMORE un modulo speciale che contenesse i pom relativi ad ogni libreria trasformata in OSGI (il modulo in questione è stato rinominato Apromore-OSGI-Bundle ). Si sono poi inseriti ognuno di questi moduli nel pom padre relativo al progetto APROMORE, per evitare all utente di doverli compilare uno ad uno. [Figura 63] ~ 108 ~

110 Come ultima osservazione a conclusione del paragrafo, si riporta un immagine raffigurante una delle suddette librerie nel repository Maven [Figura 64]. Come si può notare vi sono due cartelle facenti riferimento alla medesima libreria. In sostanza la prima, pql, è quella originale non in formato OSGI, ed è quella che qualsiasi utente può scaricare da internet. La seconda invece, pql-osgi, è la libreria OSGI ottenuta tramite il progetto Maven. In questo modo, se ci dovessero essere cambiamenti in una libreria, o se uscisse una nuova release, basterà cambiare qualcosa nel pom della libreria associata, compilare, e il tutto verrà Figura 64 Contenuto della cartella pql contentua in.m2 generato in automatico. Si conclude così la nostra panoramica sull integrazione di librerie esterne in APROMORE, facendo vedere come trasformare una libreria esterna in libreria OSGI tramite l aiuto di Maven. Spiegato quali benefici questi cambiamenti hanno apportato al progetto, e cosa bisogna fare qualora ci fossero delle variazioni nelle librerie sorgenti. Figura 63 Moduli trasformati in OSGi Dopo aver visto come la logica del linguaggio PQL sia stata integrata, si sposta ora l attenzione sulla progettazione del modulo software che dovrà garantire le specifiche espresse nel primo paragrafo del capitolo. Ricorrendo a diagrammi UML, sequence diagram e casi d uso, si cercherà di esprimere al meglio tutte le relazioni tra le classi e laddove necessario si useranno screenshot per far ~ 109 ~

111 comprendere meglio le relazioni tra le classi e le funzionalità messe a disposizione. 3.3 Progettazione Prima di iniziare con i vari diagrammi UML e quindi a parlare della progettazione del modulo software, è necessario effettuare un piccolo riepilogo delle principali funzionalità del modulo che si andrà a descrivere: Auto-completamento delle parole chiavi e dei nomi dei modelli di processo Evidenziazione degli errori di sintassi Drag and drop dei modelli di processo da un albero Tabella delle versioni dei modelli di processo Tabella riassuntiva dei modelli inseriti nella FROM Salvataggio/caricamento delle interrogazioni Tre modalità di scelta dei modelli di processo (ultima versione, tutte le versioni, versioni a scelta) L elenco fa riferimento alle principali caratteristiche che il mostro modulo deve supportare, ma questo non vieta di inserire altre funzionalità qualora lo si renda necessario. Innanzitutto occorre effettuare un analisi riguardante il contesto a cui si fa riferimento, per permettere di capire meglio le scelte che si sono effettuate in fase progettuale. Innanzitutto è noto si dovrà sviluppare un modulo adibito al riconoscimento e all elaborazione dei interrogazioni PQL. Tale modulo fa però parte della piattaforma web Apromore, che come già visto nei precedenti capitoli, offre una serie di servizi all utente. E lecito dunque immaginare che tali servizi saranno necessari anche in fase di sviluppo del modulo per poter accedere a informazioni quali modelli di processo, costruzione dell albero delle cartelle, versioni dei modelli, ecc. Inoltre, si dovrà usufruire anche del portale per poter ~ 110 ~

112 visualizzare i risultati derivanti dalle interrogazioni effettuate dall utente. Si individuano così due parti ben distinte ancor prima di passare a progettare l architettura delle classi: la prima riguardante la costruzione dell interrogazione da parte dell utente (ed è la parte che sarà interamente sviluppata nel modulo che si è costruito), mentre la seconda è la parte che deve fornire informazioni sui modelli di processo al modulo e deve visualizzare i risultati dell interrogazione all utente (la parte che interagisce con i vari moduli di APROMORE). Si spezzerà così la spiegazione della progettazione in queste due parti, cercando di favorire il più possibile la comprensione del lettore. 3.4 Progettazione modulo PQL Per quanto concerna la progettazione del modulo PQL, ovvero della parte adibita alla formulazione dell interrogazione, esso si basa sul pattern Model-View- Controller (MVC). Per analizzare al meglio ognuna delle tre parti, si è deciso di descriverne le peculiarità prima singolarmente e successivamente mostrare le connessioni che intercorrono tra loro. In questo modo si spera di generare un analisi approfondita ma anche abbastanza chiara. Il primo componente che si andrà ad analizzare riguarda la grafica, che è anche la parte maggiormente corposa. Come esposto ad inizio capitolo, si richiede che la grafica segua lo stile della piattaforma APROMORE, e che quindi possibilmente sia sviluppata in Zk. Si è così deciso all inizio di sviluppare una grafica sfruttando i tag messi a disposizione dalla versione base di Zk. Purtroppo però dopo poco tempo ci si è accorti che tale strada era impraticabile a causa della mancanza di componenti adatti a fornire all utente figure quali auto-completamento ed evidenziazione degli errori. Si è passati allora a cercare librerie, magari sviluppate in Zk, che fossero gratuite e di facile comprensione, onde evitare di perdere troppo tempo. Vedendo però che molte ricerche portavano alle versioni a pagamento di Zk, si è deciso così di abbandonare l approccio Zk puro. Per avere comunque una sorta di continuità con il portale APROMORE, si è allora deciso di provare un ~ 111 ~

113 approccio misto Zk/Java (albero e tabelle sviluppati tramite componenti Zk, mentre aree di testo e altre funzionalità sviluppate con la Swing di Java). Purtroppo però anche questo tentativo non è andato a buon fine a causa dell architettura di Zk. Infatti il framework genera un area virtuale per far costruire i suoi componenti e generare il codice javascript che costituisce la pagina html sviluppata. Quest'area virtuale però entra in contrasto con la seconda area virtuale generata dal codice Java, non rendendo possibile lo scambio di informazioni tra componenti sviluppati in Zk e componenti sviluppati in Java (non era possibile eseguire il drag and drop dei processi dall albero alla textarea). Un modo per far comunicare le due parti in teoria c è, e sarebbe quello di creare una sorta di ponte tra le aree virtuali in RMI o tramite socket, purtroppo però tali approcci sono abbastanza complessi e possono creare problemi non facilmente risolvibili. Dunque anche questo secondo approccio è stato abbandonato ed ha portato alla scelta di una grafica puramente in Java. Il problema ora però da risolvere è come poter inserire un applicazione Java in una pagina scritta in Zk (si ricorda che tutto ciò che si trova nel portal di APROMORE è scritto in Zk, e quindi il nostro modulo deve essere ospitato in una di queste pagine). La soluzione è direttamente offerta dal framework tramite il tag applet, che permette così di poter scrivere un applicazione interamente in Java. Unico problema rimane l aspetto della grafica palesemente diverso rispetto a quello del portale APROMORE. C è da dire però che Java mette a disposizione un ampia gamma di look and feel, nonché la possibilità di crearne altri, che ci permettono cosi di avere un effetto quanto più simile possibile alla grafica della piattaforma web. ~ 112 ~

114 Figura 65 - Dichiarazione dell applet all interno del file.zul Figura 66 Costruzione del contenuto dell applet tramite file Java In [Figura 65] è riportata la pagina Zk che ospiterà la nostra applet Java (Come si può notare dal tab, il nome della pagina è apqlfilter.zul, è tornerà utile a breve). Il tag principale della pagina è window che come si può vedere ha alcuni attributi (id, width, height, closable, position) di facile comprensione. Quello che però non è chiaro, è che tipo di finestra sarà la nostra pagina html (si ritaglierà uno spazio nel portale, sarà una finestra a scomparsa, aprirà un'altra pagina nel browser, ecc). Le informazioni sul tipo di pagina in costruzione, sono codificate all interno di una classe Java adibita al raccoglimento di alcune informazioni [Figura 66]. Come si vede in [Figura 65], la finestra è creata usando la pagina apqlfiler.zul, ed è assegnata alla variabile querywindow. D ora in poi tutte le operazioni che si faranno sulla variabile querywindow, si ripercuoteranno sulla finestra visualizzata all utente (vedasi l assegnazione del titolo alla finestra alla riga successiva). Come ultimo comando, si nota che sulla finestra è richiamata ~ 113 ~

115 un operazione domodal. Ebbene con questo comando si trasforma la nostra finestra in una sorta di popup che non permette all utente di interagire con nient altro che non sia la finestra stessa. In questo modo l utente potrà solo costruire la sua interrogazione, oppure, nell eventualità che abbia finito di effettuare le sue operazioni, abbandonare la nostra finestra e ritornare al portale APROMORE. Un ultima osservazione da fare sulle poche righe di codice visualizzate, consiste nella definizione della nostra applet. Come si può vedere anch essa viene prelevata dalla pagina zul precedentemente mostrata affinché sia possibile aggiungere alcuni parametri che saranno chiari più tardi. Rimane però il problema di come identificare la nostra applet, o meglio come fare ad imporre alla pagina zul il caricamento di una determinata applet. La soluzione è fornita dagli attributi presenti nel tag applet. Infatti come si può notare dalla prima immagine, il codice da usare è identificato dall attributo archive, in cui si deve specificare il jar contenente il codice dell applet che si vuol far girare. Inoltre, come avviene per ogni applet, bisogna specificare la classe che fa girare l applicazione, ovvero segnalare la classe java che estende la superclasse Applet (da notare in questo caso l attributo code ). Con queste semplici operazioni si è in grado di inserire l applet, di cui per adesso non si conosce il contenuto, all interno della pagina zul che verrà visualizzata all utente. Si espone adesso l organizzazione dei contenuti nell applet. Tramite un classdiagram si esporranno, per adesso, le classi principali rinviando in seguito una discussione più approfondita sui singoli elementi [Figura 67]. ~ 114 ~

116 Figura 67 - Class diagram del tool Come si può vedere dall immagine [Figura 67], i componenti principali costituenti l applicazione sono pochi (si porta il lettore ad osservare che nell immagine sono riportati solo componenti grafici, altre classi attinenti al lato Controller, saranno mostrate in seguito onde evitare confusione). Si parte naturalmente dalla classe base che è l Applet, che a sua volta usa un JPanel (la classe Main) per poter ospitare altri componenti. Affinché tali componenti si possano disporre nella nostra applet, si deveò specificare il tipo di layout che si vuole usare. Nella nostra applicazione si è deciso di optare, dopo un attenta analisi benefici/svantaggi, di uno SpringLayout capace di garantire una certa flessibilità nella disposizione dei componenti, nonché di adattarsi automaticamente ai cambiamenti di dimensionamento del contenitore. Unico aspetto negativo, a mio avviso, riguarda la prolissità del codice [Figura 68], dato che il programmatore è costretto ad individuare per ogni componente almeno due punti di riferimento che consentono al componente di adattarsi in maniera automatica ad un cambiamento nella grafica. L immagine riportata qui a lato aiuta il lettore a capire meglio il discorso appena fatto in merito ai punti di riferimento per un componente. ~ 115 ~

117 Figura 68 Esempio d uso dello SpringLayout Java Avendo visto come sistemare gli elementi della grafica, si può ora passare ad analizzarli uno ad uno per capire le loro peculiarità FolderProcessTree: l albero dei modelli di processo Figura 69 Class diagram della classe FolderProcessTree Innanzitutto si analizza l albero dei modelli di processo [Figura 69]. Come si può constatare il fulcro è la classe FolderProcessTree, erede di JTree (la classe grafica fornita da Java per la costruzione di alberi), che usa come nodi oggetti di tipo DraggableNodeTree, erede di DefaultMutableTreeNode. A sua volta quest ultima classe si specializza in due versioni: DraggableNodeFolder (per rappresentare le ~ 116 ~

118 cartelle del repository) e DraggableNodeProcess (per rappresentare i modelli di processo). Tramite questa distinzione si può associare ad ogni nodo dell albero un immagine che la identifica in quanto cartella o modello, ma si consente anche di intraprendere azioni differenti a seconda del tipo di nodo selezionato dall utente. Infatti, come è facile intuire dal nome, qualsiasi nodo dell albero gode della funzione drag and drop, che permette all utente di trascinare uno o più nodi all interno dell area adibita all interrogazione (si ricorda che nelle specifiche si è parlato ampiamente di questa funzionalità). Tale funzionalità è offerta mediante le interfacce DragGestureListener (mediante la quale si riconosce il movimento di trascinamento di un nodo) e DragSourceListener (che identifica l albero come sorgente del movimento di drag & drop). Quello che ancora non è chiaro è la modalità di selezione degli elementi appartenenti all albero. Infatti consente all utente di selezionare un solo nodo per volta, di avere una selezione multipla ma contigua oppure una seleziona multipla ma discontinua. Tale politica è scelta mediante un metodo della classe JTree che permette di cambiare la modalità di selezione a seconda dello stato in cui l applicazione si trova (se si ricorda, nelle specifiche, si è parlato della possibilità di far scegliere all utente se: selezionare l ultima versione di un modello, selezionare tutte le versioni del modello oppure selezionare solo alcune versioni del modello). Più in particolare, se l utente volesse scegliere solo l ultima versione o tutte le versioni appartenenti ad un modello, si potrebbe consentire una selezione multipla e discontinua (scelta effettuabile direttamente dall albero selezionando solo i modelli a cui si è interessati). Viceversa, se l utente volesse selezionare solo alcune versioni di un modello, questo necessiterebbe una selezione singola dall albero (relativa al modello in questione) e il divieto di poter effettuare il drag&drop (dato che la scelta delle versioni di un modello deve avvenire tramite la tabella mostrata nel secondo paragrafo). Bisogna inoltre riuscire a distinguere tra nodi folder e nodi process. Infatti nel primo caso, trovandoci nella modalità ogni versioni o ultima versione, bisogna selezionare anche tutte le sotto-cartelle e i modelli in esse contenute, mentre in modalità scegli versione le cartelle non devono produrre alcuna selezione, ma solo mostrare il loro contenuto. Nel secondo caso, quello relativo ai processi, la selezione è sempre permessa in ogni modalità, ~ 117 ~

119 naturalmente con le dovute restrizioni. Le politiche di selezione appena descritte, inducono a pensare l esistenza di uno stato associato all applicazione. Tale stato è naturalmente scelto dall utente, e può variare nel corso della stesura di un interrogazione (nelle specifiche si è parlato di una serie di JRadioButton che servivano allo scopo). Si avrà dunque bisogno di una variabile che contenga questa informazione, nonché di una classe adibita alla sua gestione ed a cui il nostro FolderProcessTree si rivolge quando l utente seleziona un modello di processo. Tale classe è QueryController, che ha al suo interno tre costanti (CHOOSEVERSION, LATESTVERSION e ALLVERSION) ed una variabile stato in accordo alla modalità voluta dall utente. Naturalmente la classe non è adibita al solo controllo dello stato dell applicazione, ma per una trattazione più approfondita si rimanda alla parte dedicata ai controller dell applicazione (cosi come per ServiceController e ViewController). Un osservazione in merito a come sono ricavate le informazioni contenute nell albero è d obbligo. Come già ampiamente spiegato nel capitolo dedicato ad APROMORE, ogni utente ha una determinata visibilità su un insieme di processi. Così, un utente riesce a vedere un modello di processo che invece altri utenti non sono in grado di poter vedere (si ricorda che uno dei target per la piattaforma web, sono le aziende, che naturalmente non vogliono far sapere a terze persone i loro processi). Dunque quando si vuole scrivere un interrogazione, ma più in generale quando si accede ad APROMORE, bisogna riconoscere l utente e sfruttare tale informazione per ricavare i modelli che bisogna visualizzare. Quest operazione è fatta tramite i servizi web messi a disposizione dal modulo Apromore-Manager, che naturalmente contiene tutta una serie di servizi per effettuare anche operazioni di ricerca di un determinato processo o di creazione/cancellazione/aggiornamento di un processo. Per quanto riguarda il nostro modulo per le interrogazioni, l unica operazione che ci interessa è la ricerca di quei modelli che l utente può visionare, e più in particolare dei modelli che sono sound (condizione necessaria affinché sia possibile effettuare un interrogazione su tali modelli). Per quanto concerne la soundness dei modelli, essa non è verificata all interno delle classi del modulo PQL, ma è trattata in un servizio web apposito per le interrogazioni PQL di cui si ~ 118 ~

120 parlerà più avanti. La ricerca dei modelli di processo è ad opera del ServiceController, che prelevando le informazioni utente salvate in ViewController, accede al servizio APROMORE adibito alla gestione del repository. Il ViewController è il custode delle credenziali utente a causa dell uso dell applet in una piattaforma sviluppata in Zk. Come si è visto ad inizio paragrafo, l applet è inserita in una pagina.zul tramite un tag apposito. In questo modo, anche se il portale conosce l utente correntemente loggato, l applet, essendo una area virtuale a parte, non ha modo di accedere a tali informazioni se non attraverso l uso di parametri specifici. Esattamente il caso a cui la nostra applicazione fa riferimento. I due parametri necessari ad identificare un utente sono così USERID e SESSIONID, che passati tramite il ServiceController al manager di APROMORE, permettono di avere i processi dell utente. Rimane aperta un ultima questione relativa al caricamento di tutti i processi da visualizzare nell albero. Nel caso la cardinalità dell insieme dei processi appartenenti ad un utente fosse piccola, ad esempio un centinaio di modelli, allora non si creerebbero problemi nel visualizzare subito l albero dei processi. Se invece la cardinalità aumenta, allora potrebbero volerci alcuni secondi, o addirittura minuti, a causa della mole di informazioni che devono pervenire all applicazione tramite internet (una discriminante in questo caso potrebbe essere anche la lentezza della connessione). Onde evitare tali problemi un possibile approccio potrebbe essere quello di richiedere solo modelli di processo nei primi due o tre livelli dell albero, richiedendo i modelli nei livelli più bassi solo quando l utente ne faccia davvero uso. Naturalmente quest approccio può andare bene qualora vi siano molti modelli in diverse cartelle annidate, ma non va bene qualora i modelli si trovino in poche cartelle e tutte al medesimo livello. Inoltre vi è il problema legato al drag&drop dei modelli nell area di testo relativa alle interrogazioni. Qualora l utente selezionasse una cartella con vari livelli di sotto cartelle, l operazione di visualizzare i modelli di processo annidati richiederebbe comunque qualche secondo, facendo perdere il guadagno in merito alla posticipazione del caricamento dell albero. Si è deciso così di caricare l intero albero quando l applet è lanciata dall utente, in modo che il drag&drop sia ~ 119 ~

121 immediato, e non costringa l utente ad aspettare alcuni secondi prima di veder visualizzati i suoi processi all interno dell area di testo VariableText: dichiarazione delle variabili Figura 70 Class Diagram VariableText Come si può notare dall immagine di [Figura 70], la struttura relativa alle classi attinenti alla gestione delle variabili per un interrogazione PQL è molto semplice. Infatti esse non devono fare altro che individuare un determinato pattern per la dichiarazione di variabili, e qualora tale pattern non sia rispettato da una dichiarazione di variabile, sottolinearla in modo da far capire all utente che è in presenza di un errore. Descrivendo in dettaglio questa architettura, si nota che l area di testo, VariableText, usufruisce di QueryController (solo per passare a quest ultimo un suo riferimento) e di VariableListener (adibito proprio all individuazione degli errori da parte dell utente). Dunque la parte principale è proprio quest ultima classe che ha la duplice funzione di individuazione degli errori tramite un determinato pattern e la segnalazione nei confronti dell utente sottolineando l errore [Figura 71]. Figura 71 Pattern riconoscimento variabili ~ 120 ~

122 Per una migliore comprensione del pattern di riconoscimento delle variabili, nonché della lista ad esso associata, si riporta un estratto del codice della classe VariableListener [Figura 79]. Come si può vedere il nome di una variabile PQL, può essere costituita da numeri (0 9) lettere minuscole (a z) e dal carattere underscore ( _ ). Inoltre una variabile può iniziare con una lettera oppure con un underscore, ma mai con un numero. Tutto ciò che segue il primo carattere obbligatorio è naturalmente a discrezione dell utente, entro i canoni prima stabiliti. Per quanto riguarda invece le etichette contenute in ogni lista, esse devono contenere solo numeri o lettere, ed inoltre, ogni etichetta deve essere racchiusa tra apici. Riporto alcuni semplici esempi per una migliore comprensione: a_0e = { Aa0 }; dichiarazione corretta _a0 = { aa9, Bb2 }; dichiarazione corretta 0_a = { a }; dichiarazione errata (il nome della variabile inizia con un numero) Naturalmente qualora una dichiarazione fosse errata, nell area di testo apparirebbe la segnalazione grafica sotto riportata [Figura 72]: Figura 72 Particolare della textarea adibita alla dichiarazione delle variabili ~ 121 ~

123 3.4.3 QueryText: definizioni dell interrogazione Figura 73 Class diagram della classe QueryText Nel grafico in [Figura 73] è evidente come la classe QueryText necessiti di un buon numero di classi affinchè sia in grado di offrire all utente tutte le funzionalità enunciate nel paragrafo relativo alle specifiche (auto-completamento, suggerimenti, parole chiave evidenziate, ecc). I primi due elementi su cui bisogna soffermarsi sono: DropTargetListener e JTextPane. Il primo elemento, un interfaccia per il drag&drop, va a completare il duo sorgente/destinazione precedentemente visto nel paragrafo dedicato all albero dei processi. Infatti i modelli di processo sono trascinati dall albero, e una volta rilasciati nel QueryText vengono inseriti nella clausola FROM dell interrogazione. Qualora l utente non abbia scritto nulla, o abbia solo accennato la parola SELECT, allora il trascinamento di alcuni elementi causa il completamento dell interrogazione in automatico. Inoltre, si hanno comportamenti diversi a seconda che l elemento trascinato nell area dell interrogazione sia un modello o una cartella. Nel primo caso verrà inserita nella clausola FROM il nome relativo al modello, o ai modelli trascinati; nel secondo caso, non verrà visualizzato il nome della cartella, ma bensì tutti i modelli contenuti in essa ed anche i modelli contenuti all interno delle sotto cartelle. Unico problema in questo caso sarebbe come disambiguare due modelli ~ 122 ~

124 aventi medesimo nome ma cartella differente. La soluzione che si è proposta, riguarda il percorso da seguire all interno dell albero per arrivare ad un determinato processo. Infatti non è possibile trovare due modelli aventi medesimo nome all interno della stessa cartella. Così quando l utente inserisce un modello all interno dell area di testo, esso comparirà come un path, alla cui fine si troverà il modello di nostro interesse: Home/cartella1/ /modello Vi è però un altro problema legato alle tre modalità di selezione delle versioni relative ad un modello di processo. Infatti, come già spiegato, l utente può selezionare ultima versione, tutte le versioni o solo alcune versioni di un determinato modello. Tali informazioni, se si decidesse di inserire in QueryText solo i path dei modelli, farebbero dimenticare all utente che tipo di versioni si selezionano per ogni modello. Onde questo tipo di problemi, si è deciso di inserire alla fine del path appartenente ad un modello, un identificativo fittizio (non è una parola chiave facente parte del linguaggio PQL) del tipo: LATESTVERSION, ALLVERSIONS o CHOOSEVERSION. In questo modo l utente riesce a riconoscere con che tipo di versioni sta scrivendo la sua interrogazione. Home/cartella1/ /modello{allversions} Nel caso però della terza modalità, quella in cui un utente sceglie un sottoinsieme di versioni con cui eseguire l interrogazione, una sola parola chiave come CHOOSEVERSION può non andare bene (ad esempio per inserire due versioni di uno stesso modello i nomi verrebbero a collidere). La soluzione è riportare allora una tripla che identifica la versione del modello con cui si sta trattando. Dato che, come accennato nei precedenti paragrafi, la versione di un modello è scelta trascinandola dalla tabella posta sotto l albero dei modelli, e che tale tabella è formata da id, branch e version, bisogna cambiare il path del processo in: Home/cartella1/ /modello{id/branch/version} In questo modo si ha la sicurezza di quali modelli sono stati inseriti nella nostra interrogazione. ~ 123 ~

125 Una peculiarità molto interessante legata all approccio appena descritto, riguarda i ripensamenti che l utente ha nel scrivere un interrogazione. Infatti ammettendo che il nostro utente selezioni determinati modelli con la modalità ALLVERSIONS, ma che in seguito ci ripensi e voglia prendere in esame le ultime versioni di determinati modelli, si può pensare di non costringere l utente a cancellare a mano quei modelli ormai inutili, ma forzare l utente a cancellare a mano i modelli che sono inutili. Il modo più semplice ed elegante per dare soluzione a questo problema, riguarda la sostituzione dei path appartenenti ai modelli che si vogliono eliminare dall interrogazione con quelli che invece si vogliono inserire. In questo modo se nella clausola from avessimo: Home/cartella/modello{ALLVERSIONS} diventa Home/cartella/modello{LATESTVERSION} Medesima soluzione nel caso in cui un utente volesse cambiare il primo modello, con un insieme di modelli scelti dalla tabella delle versioni. Si passa ora ad analizzare cosa permette di fare il JTextPane nell area di testo. Innanzitutto è bene partire da cosa ci permette di fare una semplice area di testo, per capire meglio il perché non sia stata scelta come alternativa nello sviluppo dell area adibita all interrogazione. Le uniche operazioni ammesse da una JTextArea, riguardano solamente il font dei caratteri, la loro formattazione e il colore che si vuole dare al testo. In particolare mi soffermo sull ultima caratteristica enunciata, il colore che si può dare all intero testo, perché risulta il vero limite per cui si è scartata tale scelta. Infatti, è vero che si vuole fornire all utente un modo semplice ed efficace per evidenziare le parole chiave del linguaggio PQL, ma attraverso una JTextArea questo non risulta possibile dato che dovremmo colorare interamente il testo. Possibilmente bisogna trovare un oggetto capace di comportarsi come una pagina HTML, ovvero che abbia la capacità di strutturare in qualche modo il testo, e ci permetta di concentrarci solo su determinate parole dell interrogazione. Il JTextPane ci permette di evidenziare solo determinate parola del testo agendo sullo StyleDocument associato. Cosi facendo si è in grado di evidenziare le parole chiave di PQL, cambiare colore al ~ 124 ~

126 contenuto della clausola SELECT, cambiare font per i modelli di processo o locazioni presenti nella clausola FROM. Insomma è possibile creare a piacimento l intera interrogazione. Ora se il JTextPane ci permette di costruire l interrogazione con diversi colori e font, si deve avere una classe che, presa l interrogazione correntemente scritta dall utente, l analizzi e individui le parole da evidenziare. Guardando il nostro grafico UML, si capisce che tale classe può essere solamente Highlight. Quando l utente digita una lettera nell area di testo, l azione è catturata tramite il WordListener (ascoltatore erede di KeyListener), e tutto ciò che è presente nel JTextPane viene inviato alla classe Highlight per essere evidenziata. Naturalmente se vi sono già parole evidenziate, esse vengono ignorate, si andranno solo a colorare le ultime parti aggiunte. Per capire meglio tale meccanismo, basti pensare che un interrogazione non è altro che un insieme di parole del tipo: parole chiavi, locazioni, attributi ed etichette. Le parole chiavi sono un insieme fisso (o poco variabile dato che probabilmente le parole al suo interno verranno estese in un prossimo futuro), le locazioni seguono una determinata struttura, gli attributi (appartenenti alla SELECT) sono anch essi limitati e scelti all inizio, e le etichette si possono solo trovare dopo la WHERE. Seguendo queste semplici regole, è possibile individuare facilmente ogni tipo di elemento contenuto nell interrogazione, ed evidenziarlo nella maniera più opportuna. Ad esempio, nella prima implementazione del modulo, si è scelto di evidenziare le parole chiave in rosso, gli attributi in blu mentre locazioni ed etichette non sono state evidenziate. Naturalmente qualora si volessero cambiare colori o font o entrambe le cose, basterebbe cambiare solo alcune variabili all interno della classe per avere l effetto voluto. Ora che si è spiegato come si evidenziano le parole, si possono spendere due parole su come riconoscerle. Banalmente, basta avere una lista delle parole chiavi, degli attributi, un pattern per riconoscere le locazioni e un altro per riconoscere le etichette. Inoltre si può sfruttare la divisione dell interrogazione in tre macro parti, corrispondenti naturalmente alle clausole presenti in essa: SELECT, FROM, WHERE. Infatti, facendo un piccolo ragionamento, si avrà che: ~ 125 ~

127 La parola SELECT non è preceduta da nessun altra parola (altrimenti l interrogazione sarebbe malformata) ed a valle può avere solo attributi (ID, name, version, owner, ecc) prima di incontrare la parola chiave FROM; La parola FROM è preceduta da attributi ed è seguita da locazioni. Dato che la parola WHERE è opzionale e non obbligatoria, si deve avere che l interrogazione finisca dopo l elenco delle locazioni, oppure prosegue con la clausola WHERE; La parola WHERE è preceduta da locazioni e termina con il ;, indicante appunto che l interrogazione è conclusa. Grazie a questa suddivisione è possibile sia evidenziare correttamente le parole, ma anche di fornire adeguati suggerimenti all utente nella stesura della query. Intatti WordListener, non solo fornisce aiuto alla classe Highlight, ma offre anche le funzionalità di auto-completamento e suggerimenti. Si espone innanzitutto cosa si intende per auto-completamente e per suggerimento all interno della nostra interrogazione. La prima funzionalità consiste essenzialmente nel completare una parola scritta a metà con un insieme di parole aventi medesima radice (esempio se si ha pro, risulteranno opzioni come: prodotto, produzione, ecc). Inoltre sarebbe auspicabile che se la parola di cui vorremmo l auto-completamento si trovasse nella clausola FROM, allora l applicazione ci deve fornire solo le parole attinenti a quella clausola (ovvero solo locazioni e la parola chiave WHERE, e non attributi o etichette). Per ottenere questo risultato si devono quindi individuare determinati contesti all interno dell interrogazione, lavoro non semplicissimo date le numerose possibilità offerte dal problema: Interrogazione vuota: ovvero non si è scritta alcuna parola all interno dell area di testo E presente solo la parola SELECT ~ 126 ~

128 E presenta la parola SELECT e un attributo E presente la parola chiave FROM, senza locazioni, anticipata dalla clausola SELECT Sono presenti le clausole SELECT e FROM, entrambe con elementi al loro interno Vi è la parola WHERE, ma senza predicati al suo interno Vi è la parola WHERE con alcuni predicati al suo interno Interrogazione Malformata A queste casistiche vanno poi aggiunti i casi in cui una locazione non è completa, lasciando così la possibilità all utente di adoperare le opzioni di autocompletamento e suggerimento (basti pensare ad un caso del tipo Home/cartella1/ nel quale è necessario restituire all utente tutti i modelli contenuti nella cartella1 più tutte le sotto-cartelle). Insomma un lavoro del genere, affinché sia il codice reso il più chiaro possibile, non può essere messo nella classe WordListener, adibita al riconoscimento delle parole. Si è così scelto di creare un controller apposito per la gestione dei contesti all interno dell interrogazione, che collaborando con WordListener, Highlight e QueryText, fosse in grado di effettuare tutte le distinzioni precedentemente elencate. Inoltre, in base al contesto, essa è in grado di fornire i giusti suggerimenti tramite l uso di una finestra popup che l utente può visualizzare tramite la combinazione di tasti CTRL+SPACE [Figura 82]. ~ 127 ~

129 Figura 74 Particolare del menu per il suggerimento delle parole chiavi nel tool Come si può vedere [Figura 74] la finestra è anche fornita di barra scrollabile in modo che se le parole sono in gran numero, vengono visualizzate solo le prime cinque opzioni, mentre tutte le altre saranno raggiungibili tramite barra. Inoltre, qualora l utente volesse raffinare la ricerca aggiungendo caratteri alla parola di cui vuole il suggerimento, il contenuto della finestra viene aggiornato automaticamente ed inoltre la finestra si allinea sempre con l ultimo carattere della parola. Naturalmente, la logica che è alla base di tale finestra, segue le medesime dinamiche di individuazione della parola e ricerca delle parole simili. Un caso particolare, per quanto riguarda auto-completamento e suggerimento, è quello delle locazioni. Infatti qualora un utente volesse un aiuto per completare il nome di una locazione, o anche solo per ricercarlo, si è costretti a scorrere l albero per individuare il giusto modello o la giusta cartella. Inoltre, se l utente sbagliasse nel selezionare un modello o una cartella, cancellando l ultima parola o anche solo un carattere di essa, bisognerebbe aggiornare il contenuto della finestra popup dei suggerimenti. ~ 128 ~

130 3.4.4 ButtonAction: shortcut per aiutare l utente Come mostrato in [Figura 83], la nostra applicazione dispone di alcune shortcut utili per velocizzare la stesura delle interrogazio ni da parte dell utente. La funzione di alcune di esse è già abbastanza nota, dato Figura 75 Class diagram della classe TextAction che la maggior parte dei programmi commerciali usa le medesime combinazioni di tasti. Altre invece sono state create appositamente per poter svolgere funzioni di aiuto nell ambito della formulazione di interrogazioni PQL: CTRL+X (taglia): elimina una parte di testo dall area; CTRL+V (incolla): incolla una porzione di testo precedentemente copiata o incollata; CTRL+C (copia): copia una porzione di testo; CTRL+A (seleziona tutto): seleziona tutto il testo presente nell area di testo; CTRL+Z (undo): elimina le conseguenze dell ultima operazione effettuata; CTRL+Y (redo): operazione contraria dell undo; CTRL+SPACE (suggerimento): visualizza la finestra popup contenente i suggerimenti; ~ 129 ~

131 CTRL+BACK (collassamento/rilassamento): collassa/rilassa la clausola FROM per visualizzare/nascondere le locazioni; Ognuna delle suddette operazioni deve innanzitutto interagire con l area di testo in cui è racchiusa l interrogazione (si pensi alle operazioni di copia, incolla e taglia) e naturalmente si deve appoggiare sui controller ViewController e QueryController (JTextPane, VIewController e QueryCOntroller, non sono stati inseriti nel diagramma UML per motivi di chiarezza). In sostanza i controllori terranno, tramite variabili, una copia dell interrogazione correntemente salvata nell area di testo, e in dipendenza delle shortcut usate dall utente tale stringa verrà modificata o usata così com è. Si hanno però delle eccezioni che riguardano questa regola: suggerimento, redo e undo. Infatti, per quanto riguarda il suggerimento, esso modifica solo una parte dell interrogazione (ad esempio quando si selezionia un modello di processo da aggiungere nella clausola FROM) oppure visualizza solo una finestra popup di cui l utente può anche non selezionare nulla. Per quanto concerne invece undo/redo esso servono ad avere una cronologia di ciò che l utente ha scritto nell interrogazione. Così facendo l utente non è costretto a riscrivere a mano una parte dell interrogazione che aveva cancellato erroneamente. Affinché tale meccanismo sia reso disponibile all utente, occorre implementare una piccola lista in cui ogni posizione contiene una copia dell interrogazione in diversi momenti. Ogni volta che l utente userà CTRL+Z o CTRL+Y, un indice scorrerà la lista prelevando man mano l interrogazione in quella locazione (se l utente dovesse premere CTRL+Z e il cursore è in posizione zero, allora l interrogazione nell area di testo rimarrà invariata. Stessa cosa in caso di ultima posizione quando l utente userà CTRL+Y) TableProcess: la tabella delle versioni Si sposta ora l attenzione sulla tabella da cui l utente può selezionare le versioni da inserire nella clausola FROM della propria interrogazione. Come si evince dal diagramma UML [Figura 76], la tabella non è altro che un semplice pannello che sarà poi integrato nella grafica del modulo. TableHeader e TableRow, come si ~ 130 ~

132 Figura 76 - Class diagram della classe TableProcess intuisce dal nome, rappresentano l intestazione della tabella (dove vengono inseriti i titoli delle colonne) e le righe della stessa (quelle in cui sono elencate le versioni del processo selezionato nell albero). Una particolarità riguardante la tabella, è quella di non avere un numero di colonne fisse, bensì variabile. In questo modo, se in futuro si volesse aggiungere un campo alla tabella, l utente dovrà soltanto aumentare il numero di colonne, come esse saranno gestite sarò compito della tabella. L interfaccia Observable è stata pensata appositamente seguendo il pattern Observer (da notare anche la presenza dell interfaccia Observable legata al TableHeader), per far aggiornare il contenuto della tabella a seconda delle operazioni effettuate dall utente sul TableHeader. Infatti, se l utente clicca o trascina una delle colonne avrà due effetti differenti: cliccando su un titolo, vedrà un ordinamento alfabetico della tabella in dipendenza del campo in cui si è cliccato (ad esempio, cliccando sull ID si avrà un ordinamento in base all ID, se si clicca sul branch si vedrà un ordinamento in base al branch, e cosi via), se invece si trascina una colonna, essa si ridimensionerà secondo le necessità dell utente (naturalmente si è previsto una grandezza minima e massima, in modo ~ 131 ~

133 da non costringere la tabella ad ingrandirsi in maniera sproporzionata). Un ultima osservazione in merito al TableHeader, è l uso della classe HeaderLabel che rappresenta il titolo di ogni colonna. Tramite esso si è potuto aggiungere un animazione nel caso in cui l utente compia un ordinamento su una colonna (un click e compare una freccia che segue il tipo di ordinamento, discendente/ascendente, della colonna). Per quanto riguarda invece TableRow, la seconda classe usata da TableHeader, essa racchiude una versione di un modello, ed è anch essa formata da più label che racchiudono a loro interno le informazioni di ogni colonna (ID, version e branch). Come si può notare dal diagramma UML, essa sfrutta quattro interfacce, ognuna che ricopre un preciso compito: MouseListener: è possibile selezionare più righe della tabella che saranno poi inserite nell area dell interrogazione. Quando l utente clicca su una riga, essa cambia colore, notificando così di essere stata selezionata dall utente. Una volta che le righe sono state inserite nell area di testo, esse tornano al loro colore originale. Comparable: tale interfaccia serve solo nel caso in cui un utente, cliccando su un titolo della tabella, volesse ordinare le righe. A seconda del titolo cliccato, le righe sono comparate tra loro, inserite in maniera ordinata in una lista e a seguito visualizzate nella tabella. DragSourceListener, DragGestureListener: sono le due interfacce adibite al trascinamento delle righe nell area dell interrogazione. Così facendo, le informazioni contenute in una riga sono visualizzate nell interrogazione nell apposita clausola FROM. Per quanto riguarda la trattazione della tabella delle versioni non vi è più nulla di aggiungere. Vi è però un'altra tabella simile a quella descritta finora, ma che ha tutt altro scopo. Come anticipato nelle specifiche ad inizio capitolo, vorremmo anche avere una tabella che potesse riassumere tutti i modelli inseriti nella clausola FROM. Ebbene tale tabella è costruita con le medesime classi adoperate ~ 132 ~

134 per la tabella delle versioni, ma contiene più colonne (ID, name, version, branch, owner, latest release, ecc). Naturalmente tale tabella non offre un sistema di trascinamento delle colonne, dato che serve solo come fonte di riepilogo, ma ha il ridimensionamento delle colonne. Per poter accedere a questa tabella di riepilogo, è messo a disposizione un apposito tasto nella schermata principale della grafica, che aprirà una finestra che rimarrà in primo piano a meno che non venga chiusa Salva/Carica: memorizzazione e riuso vecchie interrogazioni Come nella maggior parte delle applicazioni attuali, si offre all utente la possibilità di salvare e caricare i propri dati sul disco locale, o in casi molto particolari anche in rete. Per quanto riguarda la nostra applicazione, essa al momento offre la possibilità di salvare/caricare interrogazioni dal disco locale. In futuro si mira ad espandere questa funzionalità incorporando il Figura 77 - Struttura di un generico file per il salvamento delle interrogazioni salvataggio/caricamento d interrogazioni dal WebDav (un estensione del protocollo http che permette all utente di accedere a risorse remote con la praticità della navigazione sul disco locale). Ritornando a ciò che il modulo offre, il salvataggio di un interrogazione su file è effetuata mediante un semplice xml avente la seguente struttura: Come si può vedere in [Figura 77] i tag presenti nella struttura sono due: variablestext, in cui sono salvate le dichiarazioni delle variabili, e querytext, in cui è presente il testo dell interrogazione. Tale struttura è stata scelta per due motivi principali: 1. Nel dichiarare le variabili, l utente può inserire, tra una variabile ed un'altra, un qualsivoglia numero di spazi bianchi e/o andate a capo, rendendo il compito di separare variabili e interrogazione arduo. ~ 133 ~

135 2. Avendo nell interfaccia grafica due sezioni in cui l utente può scrivere, si è deciso di far corrispondere nel file una sezione dedicata alle variabile ed un'altra dedicata all interrogazione. Seguendo le suddette considerazioni risulta molto più comodo elaborare un semplice xml, che analizzare riga per riga il contenuto del file. Inoltre grazie all xml non è necessario preoccuparsi di simboli dalla duplice funzione (ad esempio un medesimo simbolo usato come separatore tra variabili e interrogazione, che può comparire anche in una delle due sezioni). Ciò che si andrà a prelevare è solo il testo scritto dall utente. Si è così analizzata tutta la grafica sviluppata ai fini della stesura dell interrogazione, vedendo in modo approfondito ogni singola funzionalità e come essa è stata implementata, nonché le scelte chi si sono fatte e le motivazioni che ci hanno spinto a quelle scelte. Prima di passare a vedere come i risultati prodotti dalle interrogazioni effettuate dall utente vengano visualizzate sul portale, si riporta di seguito una sreenshot riepilogativa del tool che si è sviluppato [Figura 78]. ~ 134 ~

136 Figura 78 Grafica del tool completa 3.5 Portal-client: l applet comunica col portale Come già accennato più volte nei capitoli precedenti, far comunicare direttamente applet e Apromore non è possibile a causa della formazione di due aree virtuali (quella adibita a Zk con cui è costruito Apromore, e quella creata dalla nostra applet). Si è accennato anche ad alcune possibili soluzioni quali utilizzo di RMI o socket, che costituiscono canali di comunicazione tra due diverse aree virtuali. Purtroppo tali idee, seppur fattibili anche se complesse da implementare, risultavano essere troppo poco flessibili, soprattutto considerando che bisognava trovare un modo per inserire informazioni generate in qualsivoglia modo (da applet o tramite un modulo appartenente ad Apromore) sul portale. In sostanza quello che si cercava di implementare, riguardava una sorta di servizio espandibile secondo le esigenze degli sviluppatori, capace di trasformare la grafica del portale, senza ovviamente snaturarla, per inserire nuove informazioni. Dopo molti tentativi, si è così arrivati alla progettazione di un servizio web interamente dedicato al portale. ~ 135 ~

137 Una volta trovata la soluzione bisognava però risolvere alcuni problemi riguardanti: lo spazio in cui visualizzare i risultati (come si vede dalla fotografia in basso, il portale di Apromore è interamente dedicato alla lista dei modelli contenuti in una cartella) e come rendere tale servizio il più generale possibile. Dopo un attenta analisi dello spazio a disposizione, ed avendo preso spunto dalla grafica presente in numerosi programmi, si è deciso di optare per la costruzione di un sistema di tab da aggiungere alla grafica principale. Le motivazioni che hanno condotto ad abbracciare tale scelta sono principalmente legate alla gestione dello spazio offerto dal portale (non si poteva stravolgere la grafica esistente, e non potendo aggiungere nulla bisognava creare altro spazio), ma anche dalla flessibilità che offriva. Infatti aggiungendo una tab, oltre ad avere un intera pagina in cui poter inserire una lista di risultati, si è in grado di creare diverse strutture, ognuna diversa in dipendenza di cosa si vuole mostrare all utente. In questo modo, se per esempio, si visualizzano i risultati dell interrogazione tramite una lista, un altro sviluppatore potrà costruire una tabella per i suoi scopi ed inserirla in un tab senza alcuno sforzo (naturalmente dovrà modellare la struttura della sua tab, ma il contenitore è lo stesso. Non cambia). Figura 79 Flusso delle informazioni per la visualizzazione dei risultati Come si può vedere dall immagine in [Figura 79], i moduli coinvolti nella creazione del servizio attraverso cui viaggiano le informazioni sono tre: PQL (il ~ 136 ~

138 modulo in cui si è sviluppata l applet), portal-client (la sede del nostro servizio web), e Apromore-Portal (in cui è contenuta tutta la grafica della piattaforma Apromore). Naturalmente le informazioni che sono scambiate tra questi moduli, non possono certo essere come semplici oggetti. Avendo costruito un web-service bisogna codificare i messaggi attraverso xml-schema, e solo allora essi potranno viaggiare attraverso la rete e raggiungere il destinatario (in questo caso il portale Apromore) [Figura 80]: Figura 80 Dichiarazione dei messagi scambiati tra il tool e il servizio adibito alla visualizzazione dei risultati Il primo complextype ad essere dichiarato è il contenitore di tutto ciò che verrà visualizzato lato portale. Come si può vedere esso è composto da più campi: userid: contenente l identificativo dell utente che ha effettuato l interrogazione; query: contenente l interrogazione e le variabili usate in essa; ~ 137 ~

139 namequery: è il nome che si è voluto dare all interrogazione e che sarà visualizzato sulla tab che ospiterà i risultati; results: i modelli che corrispondono all interrogazione effettuata; details: ovvero eventuali dettagli aggiuntivi che provengono dalla logica del linguaggio PQL; Di questi cinque campi, uno ha una valenza particolare senza cui non sarebbe stato possibile implementare la soluzione dei tab: userid. Infatti, tramite esso è possibile identificare l utente che ha scritto un interrogazione, e tramite esso far visualizzare ad un utente solo i suoi tab e non quelli di altri utenti. Infatti trovandoci di fronte ad un servizio web che è usato da ogni utente, bisognava trovare un modo per associare una lista di tab ad un utente e viceversa, ed inoltre bisognava assicurare che ogni utente facesse riferimento a tale supervisore. Il metodo più elegante, ma anche quello più semplice, consisteva nel creare una classe singleton [Figura 81] che attraverso una mappa memorizzasse al suo interno utenti e rispettive liste di tab: Figura 81 Classe SessionTab ~ 138 ~

140 Come si può vedere il costruttore è naturalmente dichiarato private affinché la classe possa essere singleton. Per quanto riguarda gli ultimi due metodi, settabssession e gettabssession, essi garantiscono che ogni utente acceda alla propria lista dei tab. Quello che però non è chiaro, è come i tab siano aggiunti alla lista appartenente ad ogni utente, poiché tramite questa classe si può solo prelevare o cambiare la lista di un utente. Ebbene questa parte è affidata alla classe MainController, ovvero la classe adibita alla gestione del portale Apromore. Di seguito è riportato il metodo adibito alla creazione e all aggiunta del nuovo tab nella lista di un utente [Figura 82], e come il lettore potrà constatare, vi saranno tutte le informazioni che si sono trasmesse grazie a TabAPQLInputMessageType (ovvero il messaggio mostrato in precedenza). Figura 82 Metodo per la visualizzazione dei tab nel portale Apromore TabQuery: come vengono rappresentati i risultati Nel precedente paragrafo l attenzione è stata focalizzata su come le informazioni, dall applet, arrivino al portale. Il tema di questo capitolo sarà invece i contenitori di queste informazioni, i TabQuery. Il punto di partenza consiste nello specificare che tipo di classe essi siano, o meglio dire che tipo di oggetti siano. Infatti, come visto nel capitolo Apromore, la grafica della piattaforma è interamente sviluppata in Zk, che risulta quindi la fonte di ogni classe che si sviluppa nella grafica. Nel nostro caso, si è estesa la classe Tab disponibile in varie versioni e di cui sono presenti diversi tutorial online. L obiettivo a cui si è voluti giungere però, non consisteva nel costruire un semplice tab come quelli presenti online, ma creare ~ 139 ~

141 qualcosa di nuovo e particolare. Di seguito sono elencate le peculiarità del nostro TabQuery [Figura 83]: ogni utente ha a disposizione una lista di tab, ognuno facente riferimento ad un interrogazione. Onde evitare di saturare lo schermo di tab, si è deciso di dare la possibilità all utente di chiudere quelli di cui non ha più bisogno. Attenzione, il primo tab sarà riservato alla lista dei modelli contenuti in una cartella del repository, e tale tab non dovrà mai chiudersi [Figura 83]. Figura 83 Portale Apromore con la presenza dei tab per i risultati Quando una tab viene chiusa dall utente, essa dovrà rimuoversi automaticamente dalla lista associata all utente. Analizzando il codice di gestione della lista dei tab, si è potuto vedere che in nessun modo è possibile eliminare la tab, infatti sarà essa stessa a rimuoversi senza affidare il compito ad altre classi. Ogni tab contiene un nome tramite cui l utente può identificare la rispettiva interrogazione. In sostanza nell applet, vi è un campo editabile in cui l utente può scrivere il nome da associare all interrogazione [Figura 84]. Qualora l utente non assegnasse nessun nome, allora il nome del tab sarà costituito da un indice incrementale. ~ 140 ~

142 Figura 84 Se un utente sceglie un nome per la sua interrogazione, lo stesso nome comparirà nel tab risultato Cliccando sul nome del tab, sarà visualizzata una tabella contenente ulteriori informazioni sull interrogazione. In pratica sarà visualizzata una tabella e un area di testo non editabile, nella prima saranno visualizzate le etichette usate nell interrogazione e le parole ad esse simili contenute nel database, mentre nella seconda sarà visualizzata l interrogazione associata a quel tab. In questo modo l utente potrà confrontare i risultati e interrogazione, per confermarne l esatta formulazione. La lista dei risultati [Figura 85], che come si è visto è simile alla lista dei modelli di processo, avrà l ordinamento in base alla colonna selezionata. In pratica se l utente clicca su una colonna, i risultati si disporranno in ordine alfabetico (crescente/decrescente a seconda del numero di click su quella colonna). Si è così completata la panoramica riguardante l implementazione dei tab, spiegando anche in linea generale le funzioni disponibili per l utente. Figura 85 Visione generale del portale Apromore avente un risultato ~ 141 ~

143 3.6 Indicizzazione dei modelli di processo Nei paragrafi esposti in precedenza, è stato mostrato come utilizzare il linguaggio PQL per effettuare interrogazioni su un insieme di modelli di processo, ma soprattutto come effettuare interrogazioni attraverso l apposito tool analizzato in questo capitolo. Si è visto inoltre come un modello, affinché possa essere interrogato, debba essere rappresentato attraverso una workflow net e contemporaneamente essere sound. Dato che Apromore lavora con più tipi di linguaggi di rappresentazione (YAWL, BPMN, EPML, ecc.) mentre PQL lavora solo con reti di Petri, si è accennato ad una traduzione dei modelli dal formato originale in workflow net (di cui successivamente si analizza la soundness). Infine, se il modello soddisfa tutti i requisiti, si passa alla memorizzazione delle sue informazioni per consentire all utente di poter effettuare le proprie interrogazioni. Pur sembrando una sequenza di operazioni banali, in realtà costituiscono una criticità per quanto concerne il salvataggio dei modelli in Apromore. Infatti, ogni qual volta un utente crea, modifica o importa un modello nel repository Apromore, si deve necessariamente analizzare quest ultimo per aggiornare i due database presenti al momento in Apromore: MySql, adibito al salvataggio delle informazioni dei modelli nel loro formato originale, e PostgreSQL, adibito all indicizzazione del modello (ovvero a salvare le informazioni utili al linguaggio PQL). Per aiutare il lettore a seguire la sequenza di passi necessari affinché un modello sia salvato ed indicizzato, si riporta di seguito [Figura 94]: ~ 142 ~

144 Figura 86 Flusso di informazioni per l indicizzazione di un modello Da [Figura 86] è evidente come il processo di salvataggio di un modello sia in realtà diviso in tre macro-sezioni. La prima, riguardante l utente e la sua interazione con l editor di Apromore per creare un modello. Successivamente, qualora l utente voglia salvare il suo lavoro nel repository, interviene il ProcessServiceImpl, ovvero il servizio presente in Apromore adibito al salvataggio dei modelli nel database. Infine vi è PQLServiceImpl, che come intuibile dal nome, svolge attività prettamente legate alla libreria PQL (quella adibita ad effettuare interrogazioni sui modelli). Quello che è stato tralasciato di proposito nel modello, è un indicazione circa la modalità con cui avviene tale processo. Quello che è sicuro, oltre alle funzioni ricoperte da ogni parte mostrata, è che vi sarà uno scambio di messaggi tra le varie componenti con lo scopo di pilotare le funzioni di ogni parte. Quando si parla di scambio di messaggi tra due o più parti, è naturale chiedersi se le comunicazioni tra le parti coinvolte sia sincrona o asincrona. Con la prima s intende una comunicazione in cui il mittente, per poter proseguire nelle sue operazioni, deve attendere che il ricevente risponda al messaggio appena inviato. La seconda tipologia invece, in antitesi con la precedente, permette al mittente di inviare un messaggio e proseguire nelle sue operazioni fintanto che il destinatario ~ 143 ~

145 del messaggio non risponde. Nel caso di [Figura 94], quello del salvataggio di un modello, è lecito chiedersi quale approccio sia migliore per garantire prestazioni elevate all utente, o riformulando, per evitare che l utente sia costretto ad aspettare a lungo prima di poter riprendere a lavorare in Apromore. Come è facile intuire, la prima parte del modello, quella in cui l utente interagisce con l editor di Apromore per la creazione del modello, è ininfluente riguardo la scelta operazioni sincrone/asincrone. Infatti, per creare un modello l utente impiega tutto il tempo di cui ha bisogno ed è sicuramente un operazione sincrona, dato che non può effettuare altre operazioni. Non appena l utente avrà finito di rappresentare il suo modello di processo, e sceglierà di voler salvare tale modello nel repository, allora lì si avrà una prima criticità. Come detto nei paragrafi precedenti, affinché un modello sia univoco, e possa quindi essere salvato correttamente, è indispensabile che abbia la tripla: id, version e branch. Questi tre attributi costituiscono la chiave per individuare in maniera univoca un modello nel database di Apromore. Così, quando il ProcessServiceImpl deve verificare se poter salvare o meno un modello nel repository (tralasciando eventuali errori di sintassi del modello verificati in altra sede), fa una semplice richiesta al database con i tre valori passati dall utente: id, version e branch. Qualora la tripla non sia presente, il modello è salvato ed una notifica di salvataggio avvenuto correttamente è visualizzata all utente. Di contro, se il modello che si vuole salvare ha la medesima tripla di un modello già presente nel database di Apromore, all utente sarà richiesto di cambiare version o branch (si ricorda che l id è assegnato in maniera automatica ad ogni modello). Dunque, analizzando il riquadro relativo al ProcessServiceImpl in [Figura 94], si nota che prima il modello è mappato su un ProcessModelVersion (l oggetto che in Apromore fa le veci del modello rappresentato nell editor). Tramite esso, s inoltra una richiesta al database (entra in gioco Spring grazie alle sue Injection) per verificare se l identificativo del modello è già presente ed in caso di risposta affermativa si passa ad indicizzare il modello grazie al PQLServiceImpl. Si capisce dunque come tali operazioni debbano essere necessariamente sincrone dato che bisogna cambiare l identificativo del modello che si vuole salvare (e ~ 144 ~

146 dunque o branch o version), l utente lo deve sapere immediatamente e non quando magari sta effettuando un'altra operazione. Infatti, qualora il salvataggio del modello in Apromore fosse effettuato asincronamente, l utente potrebbe anche avviare un operazione di Similarity Search che abbia come obiettivo il modello appena costruito. Purtroppo però il modello potrebbe ancora non essere presente nel database, magari perché contiene troppe informazioni da salvare o perché ha un identificativo già presente nel database. Questa prima comunicazione (editor ProcessServiceImpl) sarà sicuramente sincrona e non potrà influire più di tanto sui tempi in merito al salvataggio dei modelli. Per quanto riguarda invece l indicizzazione di un modello, è possibile adottare un approccio asincrono per il salvataggio delle informazioni relative al linguaggio PQL? Ebbene, prima di accennare ad una risposta, si può analizzare PQLServiceImpl e le sue operazioni, per constatare se abbia o meno elementi importanti ai fini del salvataggio di un modello. Come si evince dalla [Figura 87], le operazioni compiute dal servizio sono essenzialmente tre: Figura 87 Operazioni svolte dal PQLServiceImpl 1. Transform Model in WF Model: traduce il modello che si vuole salvare in una WF-net per permettere alla libreria jbpt-petri (usata da PQL) di verificarne la soundness; 2. Check soundness: analizzando la struttura della rete e usando un algoritmo particolare, si stabilisce se la rete è sound. Se il controllo ha esito positivo, allora si passa all ultimo stadio (index model) altrimenti il modello non è indicizzabile; ~ 145 ~

147 3. Index Model: le informazioni relative al modello sono salvate sul database PostgreSQL (ad esempio viene effettuato lo stemming delle label, vengono salvate le connessioni tra i lavori, ecc.) Non appena tutti e tre i passi sono effettuati, l indicizzazione del modello è conclusa. Come si è potuto costatare, in nessuna delle precedenti tre operazioni ha la necessità di operare col database di Apromore (salvo per prelevare il modello che si vuole indicizzare, ma anche in questo caso si tratta di una lettura d informazioni già presenti nel database, informazioni peraltro che non saranno modificate dal processo). Dunque essendo completamente scevro dalla logica di salvataggio di un modello, l indicizzazione può essere effettuata in maniera asincrona rispetto alle precedenti operazioni (disegnare il modello e salvarlo). Cronologicamente, dovrà anche essere l ultima operazione che si dovrà effettuare proprio perché necessita di un modello che è già presente nel database, ma che non ha nessun vincolo per quanto concerne il tempo di indicizzazione (ovvero il tempo necessario a salvare tutte le informazioni utili alla libreria PQL). Ricapitolando, quando un utente crea un modello, quest ultimo è salvato nel database di Apromore in modo sincrono, mentre per quanto riguarda l indicizzazione, tale operazione è compiuta asincronamente. Naturalmente il processo di [Figura 94] può essere esteso ai casi di aggiornamento/importazione di un modello, dato che a cambiare sarà solo la prima parte, mentre le restanti due saranno praticamente identiche. Attenzione però, salvataggio/aggiornamento e importazione di modelli pur essendo operazioni simili, differiscono però in un caso. Infatti nel caso in cui si sceglie se salvare o aggiornare un modello, si lavora appunto con un solo file, nel caso dell importazione si può avere a che fare con più modelli contemporaneamente. Questa differenza non cambia il modo in cui un modello viene indicizzato, ma costituisce un eventuale collo di bottiglia nel salvataggio delle informazioni per PQL. Altra insidia si nasconde dietro le tempistiche inerenti all indicizzazione del modello (basti pensare che verificare la soundness di modelli molto complessi è un operazione alquanto lunga è ~ 146 ~

148 complicata, e di rimando salvare così tante informazioni riguardo un modello complesso impiega non poco tempo). Inoltre se si pensa che per adesso i modelli vengono importati ed indicizzati uno per volta, e soprattutto che Apromore è una piattaforma web virtualmente utilizzabile da centinaia di persone contemporaneamente, si capisce come risolvere i due problemi esposti in precedenza sia un fattore determinante per le prestazioni di Apromore Multi-threading: indicizzazione più efficiente Avendo individuato il problema nel precedente paragrafo, si può ora passare ad analizzare la soluzione. Come già accennato, l unica parte in cui è possibile operare riguarda il servizio PQLServiceImpl e le sue operazioni. Inoltre avendo a che fare con operazioni asincrone, è lecito pensare all utilizzo di thread che possano prendere in carico il lavoro di analisi e memorizzazione dei modelli di processo. Quello che rimane da stabilire però, è il numero di thread adibiti a tale Figura 88 Class Diagram per lo scambio di informazioni tra ProcessServiceImpl e PQLServiceImpl compito (dato che almeno uno dovrà servire le operazioni di salvataggio del modello nel repository o comunque altre operazioni legato ad Apromore) e soprattutto dove usarli. Per quanto riguarda l ultimo punto, ovvero dove usare i thread, la [Figura 88] può aiutarci. Come si vede, essa rappresenta il pattern Observer, generalmente utilizzato per notificare ad una o più classi che l oggetto che si sta osservando è variato. Nel nostro caso, il ProcessServiceImpl è la classe che è osservata, mentre il ~ 147 ~