Page 1

UNIVERSITA’ DEGLI STUDI DI PADOVA

FACOLTA’ DI SCIENZE MATEMATICHE, FISICHE E NATURALI Corso di Laurea Triennale in Informatica

Integrazione di un’applicazione di BPM: visualizzare lo stato di un processo

Tesi di Laurea Triennale in Informatica

Relatore: Prof. Livio Colussi Laureando: Andrea Alberti

Anno Accademico 2009/10


Pagina 2 di 56


Indice 1 Introduzione .................................................................................. 1 1.1 Azienda..................................................................................... 2 1.2 Il progetto di stage .................................................................. 4 1.3 Inserimento in azienda e fattori di rischio ............................ 5 2 Pianificazione delle attivitĂ ........................................................... 7 3 Analisi dei requisiti ...................................................................... 11 3.1 Tecnologie............................................................................... 11 3.1.1 JBoss...................................................................................................... 11 3.1.2 JBPM...................................................................................................... 14 3.1.3 Servlet................................................................................................... 17 3.2 Ambiente di progetto: Finanza 3000.................................... 18 3.3 Use case e descrizioni ........................................................... 24 3.3.1 Utente avanzato.................................................................................. 25 3.3.1 Utente finale........................................................................................ 26 3.4 Requisiti ................................................................................. 27 3.3.1 Requisiti funzionali ............................................................................. 27 3.3.2 Requisiti di qualitĂ  .............................................................................. 28 3.3.3 Requisiti di interfacciamento e di ambiente.................................. 29 4 Realizzazione del prodotto......................................................... 31 4.1 Strumenti per la realizzazione............................................. 31 4.1.1 Netbeans e relativi plug-ins .............................................................. 31

Pagina 3 di 56


4.1.2 Maven plug-in ...................................................................................... 32 4.1.3 Mercurial .............................................................................................. 33 4.2 Installazione e configurazione dell’ambiente ..................... 34 4.3 La JBPM console e la servlet base........................................ 35 4.4 Visualizzazione dell’immagine del grafico dei processi ...... 37 4.5 Visualizzazione dello stato di un’istanza di processo ......... 38 4.5.1 Due soluzioni a confronto................................................................ 38 4.5.2 Visualizzazione mediante codice CSS ............................................. 39 4.6 Analisi statica e dinamica ..................................................... 46 5 Consuntivo e conclusioni ............................................................ 47 5.1 Confronto fra il preventivo ed il consuntivo ....................... 47 5.2 Diagramma di Gantt............................................................. 48 5.3 Analisi critica dello stage ...................................................... 50

Pagina 4 di 56


Capitolo 1 – Introduzione

Capitolo 1

Introduzione

Il corso di laurea in Informatica prevede lo svolgimento di uno stage presso un’azienda, all’interno della quale si ha l’opportunità di apprendere le dinamiche di progettazione e sviluppo di un prodotto informatico. La presente relazione si pone l'obiettivo di illustrare l'attività di stage svolta presso l'azienda Visionest S.r.l.. Il contatto con l’azienda è stato reperito grazie all'iniziativa Stage-It promossa dall'Università degli Studi di Padova per l'anno 2009. Il progetto svolto all’interno della suddetta azienda consiste

nell’integrazione

di

un’applicazione

di

business

process

management attraverso la visualizzazione grafica dello stato del processo corrente. Lo scopo dell’attività svolta, che in seguito verrà approfondito, è stato, in particolare, quello di chiarificare la procedura e snellire l’acquisizione delle informazioni ad essa relative.

1


Capitolo 1 – Introduzione

1.1 Azienda

Visionest è un’azienda di Padova che opera nel settore della consulenza in ambito ICT (Information e Communication Technology). La missione aziendale è di introdurre l’innovazione all’interno delle aziende clienti, promuovendo il collegamento fra le variabili organizzativa e tecnologica. Visionest è consapevole che “Organizzazione” e “ICT” sono competenze che necessitano di essere sviluppate congiuntamente per assicurare il successo dei progetti di ammodernamento riguardanti le forme organizzative e gli apparati tecnologici delle imprese, per questo, cerca di supportare il management sia nella definizione degli obbiettivi strategici, che nella predisposizione degli strumenti utili alla loro attuazione. Le organizzazioni che si rivolgono a Visionest manifestano l’esigenza di rafforzare le proprie abilità nel campo delle tecnologie dell’informazione e della comunicazione e dell’integrazione dei sistemi informativi e ricercano perciò un servizio di consulenza completo e approfondito. Visionest mette a disposizione la propria esperienza dimostrandosi capace di ricoprire un ruolo non solo di mero fornitore bensì di vero e proprio partner strategico, su orizzonti di medio-lungo termine. L’azienda opera attraverso le fasi che partono dallo studio dei requisiti (problem setting) fino a giungere alla scelta delle soluzioni (problem solving). Laddove, inoltre, le attività di consulenza investano aree caratterizzate da un alto fattore di specializzazione, Visionest si mostra in grado di individuare e supportare il fornitore verticale maggiormente adeguato per la fase di attuazione. In seno all’impresa opera un gruppo di dieci consulenti che vantano ampie esperienze di organizzazione e sistemi informativi. La struttura di Visionest si dirama in quattro macroaree di attività:

2


Capitolo 1 – Introduzione



Ingegneria ed informatizzazione dei processi (process & information engineering): verte nella ricerca e realizzazione di nuovi modelli organizzativi che si realizzano lungo la catena del valore, includendo l'integrazione con attori a monte o a valle dell'organizzazione aziendale. Le attività di business process reengineering (BPR) permetteranno, quindi, di individuare le soluzioni

più

appropriate

per

supportare

i

processi

dell'organizzazione attraverso il sistema informativo aziendale. 

Gestione

strategica

della

conoscenza

(strategic

knowledge): l’organizzazione che intraprende progetti di knowledge

management

svolgerà, in

modo

cosciente

e

continuativo, attività di raccolta, organizzazione, condivisione e analisi della conoscenza presente al suo interno in termini di risorse, documenti e competenze, attraverso strumenti per il supporto alle decisioni strategiche e operative. 

Sicurezza

e

conformità

(business

&

information

protection): Il tema della sicurezza ha come obbiettivo fornire al management delle organizzazioni gli strumenti per individuare e monitorare il livello di rischio a cui sono sottoposte le informazioni gestite dall’azienda. Vengono, inoltre, trattate le tematiche di conformità a particolari aspetti normativi e regolamentari (es. privacy – d.lgs. 196/03; Responsabilità persone giuridiche – d.lgs. 231/01). 

Consulenza IT (IT advisory): Visionest rappresenta per il cliente, laddove non siano presenti, o vi siano solo parzialmente, le competenze in materia di information technology , a partire dalle infrastrutture di comunicazione per arrivare alla gestione del servizio informatico aziendale. 3


Capitolo 1 – Introduzione

1.2 Il progetto di stage

Visionest cercava uno stagista con le competenze necessarie a portare a termine un progetto inerente la piattaforma Finanza 3000. Finanza 3000 è la piattaforma gestionale recentemente adottata, in sostituzione alla precedente “Finanza 2004”, che oramai mal rispondeva alle esigenze dei clienti e ai cambiamenti nel contesto normativo. In particolare era fortemente sentito all’interno di Visionest il bisogno di introdurre un sistema che permettesse al cliente di implementare e governare i processi software senza richiedere l’assistenza di sviluppatori e/o tecnici specializzati. Finanza 3000 è stata sviluppata da Visionest attraverso l’utilizzo del framework proprietario “aplus BPM” e sfruttando alcune applicazioni open source, tra le quali JBPM, Drools, ed altre. Il sistema poggia

su

un’architettura

3-tiers

che

distribuisce

su

tre

livelli,

rispettivamente, le componenti che si occupano di memorizzazione e allocazione dei dati, di esecuzione di operazioni su di essi e di interfaccia per l’end user. Nell’ambito del sistema gestionale così costituito la parte sviluppata sull’applicazione di gestione dei processi JBPM necessitava di alcune rivisitazioni che permettessero di rendere maggiormente agevole l’utilizzo dello strumento dal punto di vista dell’interfaccia grafica e delle visualizzazioni. In particolare JBPM presentava delle lacune per quanto atteneva alla visualizzazione della struttura e dello stato di avanzamento dei processi. Il progetto di stage attivato presso la Visionest ha, perciò, avuto come obbiettivo quello di integrare la visualizzazione grafica dello schema processuale. Nello specifico si è proceduto all’introduzione di un’immagine che indicasse in maniera chiara lo stato attuale del processo in ogni fase di avanzamento e la possibilità di interrogare il sistema per

4


Capitolo 1 – Introduzione

ottenere ulteriori informazioni quali altri metadati e variabili coinvolti nello svolgimento delle attività. La pianificazione delle attività e l’attuazione dei compiti affidati allo stagista saranno esaminati nel dettaglio nel corso della trattazione.

1.3 Inserimento in azienda e fattori di rischio

Lo stagista si è inserito nell’ambiente aziendale grazie all’affiancamento del tutor, Michele Mauro, programmatore all’interno di Visionest. Il dott. Mauro ha curato le comunicazioni con lo stagista e si è occupato di svolgere una funzione di intermediazione per il suo inserimento all’interno delle attività dell’impresa. Per ciò che riguarda in maniera particolare i rischi collegati allo svolgimento del lavoro di stage, se ne possono individuare due categorie: i fattori di rischio meramente tecnici e quelli invece legati all’ambito strategico. Tra i rischi di natura tecnica si ritrovano in particolare: 

la scarsa familiarità con l’ambiente e il linguaggio di sviluppo;



le difficoltà legate a problemi di comprensione riguardanti i requisiti del programma e i bisogni dell’azienda ;



la variazione della tecnologia in uso.

Come fattori di rischio di tipo strategico si individuano, invece: 

impossibilità per lo stagista di recarsi sul posto di lavoro (causata da malattia, sciopero dei mezzi di trasporto, ecc);

5


Capitolo 1 – Introduzione



rispetto delle tempistiche durante il periodo di svolgimento delle attivitĂ ;



scarsa adattabilitĂ  a nuovi metodi di impostazione del lavoro.

6


Capitolo 2 – Pianificazione delle attività

Capitolo 2

Pianificazione delle attività

Lo stage avrà una durata complessiva di 300 ore. Ogni settimana è composta da 5 giorni lavorativi di 8 ore ciascuno per un totale stimato di 7 settimane e mezza. Il dettaglio delle modalità operative è stato concordato assieme al tutor Michele Mauro, con scadenza pressoché settimanale. Piano di contingenza e revisioni: “Qualora dovessero presentarsi delle anomalie gravi che richiedano immediata attenzione, può essere concordato un giorno a settimana per affrontare tali problematiche, in modo da abbassare l’influenza dei fattori di rischio con l’assistenza del tutor presente all’interno dell’azienda.”. Per correggere eventuali errori, sono previste una serie di revisioni formali, da svolgersi con il tutor aziendale per tutta la durata dello stage. Suddette revisioni avranno luogo al compimento di ogni fase definita del progetto e si focalizzeranno su eventuali anomalie riscontrate durante tale arco di tempo. La seguente tabella riporta il piano preventivato per ogni settimana di lavoro a partire dal 28/09/2009 con indicazione delle principali attività e del carico di 7


Capitolo 2 – Pianificazione delle attività

lavoro stimato.

SETTIMANA

ORE

ATTIVITA’

1

40

- comprensione dell’ambiente di utilizzo del sistema e degli strumenti di sviluppo - setup e preparazione dell’ambiente di lavoro - pianificazione del progetto e relativa documentazione

2

40

- analisi del framework Spring - studio di JBPM

3

40

- analisi e rilevazione del modo in cui la feature è realizzata nella console standard - analisi della struttura dei metadati

4

40

- studio dell’applicazione esistente sulla base delle informazioni reperite in precedenza - produzione della documentazione di analisi

5

40

- progettazione che dovrà risolvere principalmente due problemi: come recuperare i dati e visualizzarli per l’utente, come caricare le immagini

6

40

- stesura dei documenti di progettazione - codifica della parte logica

8


Capitolo 2 – Pianificazione delle attività

7

40

- codifica della parte grafica - integrazione e standardizzazione con il sistema - verifica e validazione tramite test

8

20

- correzione degli errori - stesura della documentazione finale

Come si nota chiaramente dalla tabella, durante le prime fasi del progetto un consistente numero di ore è stato dedicato alla comprensione dell’ambiente di sviluppo e allo studio delle soluzioni già presenti nell’ambiente aziendale. In particolare risulta evidente come più del 45% delle ore lavorative siano state impiegate per un’accurata preparazione della piattaforma di lavoro, per lo studio dei sistemi implementati e per la produzione dei documenti relativi all’analisi. Solo nella successiva fase attuativa si avrà l’occasione di apprezzare quanto un’attenta e scrupolosa analisi sia fondamentale per snellire e facilitare lo svolgimento delle attività operative. La seconda parte del progetto è stata dedicata allo svolgimento di attività di progettazione legate alla ricerca di soluzioni idonee per problemi quali:  recupero e visualizzazione dati;  caricamento immagini; ed in massima parte alla stesura del codice sia per quanto attiene alla parte logica, sia per quanto attiene alla parte grafica. Il progetto ha trovato la sua naturale conclusione nello svolgimento di attività di test e verifica mirate a collaudare il funzionamento integrato delle applicazioni e nella stesura della documentazione finale.

9


Capitolo 2 – Pianificazione delle attività

Le fasi nodali, sulle quali era focalizzato il preventivo originario, erano le seguenti:  Inserimento nel contesto aziendale e acquisizione di skills relative alle prassi operative adottate all’interno del contesto lavorativo;  Comprensione della situazione che si presentava e analisi delle logiche di intervento;  Studio di una soluzione efficiente rispetto agli obiettivi;  Realizzazione delle parti software e verifica della rispondenza alle funzionalità richieste;  Verifica dell’integrazione e della standardizzazione con il sistema;  Verifica del funzionamento e correzione di eventuali errori. Al di là delle naturali complessità relative alle fasi di codifica, dovute al tipo di attività che richiede specifiche e mirate competenze in materia, una delle difficoltà maggiori è stata riscontrata nella necessità di integrare l’applicazione all’interno di un sistema già presente, quindi di individuare una serie di caratteristiche che permettessero al software di funzionare sinergicamente col sistema nel suo complesso.

10


Capitolo 3 – Analisi dei requisiti

Capitolo 3

Analisi dei requisiti

3.1 Tecnologie

Le tecnologie utilizzate nel progetto fanno parte della piattaforma JEE, che è costituita da un insieme di specifiche che definiscono le caratteristiche e le interfacce di un insieme di tecnologie pensate per la realizzazione di applicazioni di tipo Enterprise. Queste componenti estendono le funzionalità di base della piattaforma Java e la rendono quindi facile la realizzazione di un’implementazione di tali specifiche per produrre application server compatibili.

3.1.1 JBoss

JBoss è un application server open source che implementa l’intera suite di 11


Capitolo 3 – Analisi dei requisiti

servizi legati allo standard J2EE. Il programma è interamente compilato in linguaggio Java, ed è, perciò, utilizzabile da qualsiasi sistema operativo che supporti Java. Un application server è un’applicazione che fornisce l’infrastruttura, le funzionalità esecutive e di supporto necessarie per l’implementazione di componenti server in un contesto distribuito. In particolare, gli application server sono utilizzati per la realizzazione di applicativi complessi, solitamente multilivello ed Enterprise, orientate per gli sviluppi sul web. Un application server è generalmente costituito da moduli generati seguendo schemi strutturali standard, generalmente approvati dalla comunità dei programmatori (ad esempio il protocollo HTTP). All’interno di un application server è inoltre possibile fare operare una servlet che sarà appunto l’obiettivo del progetto di stage. I moduli che solitamente si ritrovano in un application server sono i seguenti:  contenitore di componenti server-side;  gestore degli accessi degli utenti e della sicurezza;  gestore accessi a database o, in generale, a sorgenti dati esterne;  gestore delle transazioni;  interfaccia per accesso a sistemi lagacy;  altri componenti utili per la massimizzazione delle prestazioni. Lo sfruttamento di programmi di tipo application server presenta numerosi benefici legati allo sviluppo, all’esecuzione e alla gestione integrata dei sistemi, quali:  Semplificazione delle attività di sviluppo, ottenuta grazie alla possibilità di usare gli strumenti a maggiore diffusione sul mercato, che permettono di produrre e distribuire in modo rapido ed efficace

12


Capitolo 3 – Analisi dei requisiti

applicazioni transazionali altamente scalabili;  Riduzione dei tempi di realizzazione e messa in esercizio dei programmi negli ambienti distribuiti;  Supporto di vari linguaggi;  Riusabilità

del

codice

grazie

all’uso

delle

tecniche

di

programmazione ad oggetti e dell’approccio a componenti, la logica applicativa può essere condivisa e riutilizzata;  Gestione delle transazioni e garanzia dell’integrità transazionale e dell’affidabilità dei back-end multipli per le risorse e i dati;  Scalabilità: sono supportati il partizionamento delle applicazioni e la distribuzione in rete delle componenti;  Alte Prestazioni: gli application server sono configurati con determinate caratteristiche architetturali che permettono di erogare alte prestazioni: multithreating, load balancing, caching e pooling degli oggetti e delle connessioni di database;  Estendibilità: l’architettura modulare e il supporto per moduli e server permettono di caricare dinamicamente gli elementi;  Robustezza: i componenti del server e la logica applicativa possono essere

riconfigurati, aggiunti

o

rimossi

senza

interrompere

l’erogazione del servizio, ciò rende i sistemi altamente disponibili e permette di non interferire con lo svolgimento di core activities aziendali;  Sicurezza: gli application server implementano funzioni spoecifiche di sicurezza end-to-end, necessarie per la messa a punto di operazioni aziendali che richiedano alti livelli di controllo e sicurezza sui dati. Le comunicazioni fra client e server sono preservate attraverso l’uso di

13


Capitolo 3 – Analisi dei requisiti

algoritmi standard ampiamente testati e collaudati sul web ( ad esempio quelli offerti dal protocollo SSL), e sono forniti servizi di protezione relativi agli accessi non autorizzati. JBoss, in particolare, sfrutta la tecnologia Java, per la cui produzione l’azienda Sun si avvale del lavoro sinergico svolto da sviluppatori di tutto il mondo. E’ per questo motivo che, grazie anche al supporto della comunità open source l’applicazione JBoss mostra qualità notevoli in termini di affidabilità, robustezza e flessibilità e occupa una posizione di leadership nel mercato degli application server open source.

3.1.2 JBPM

JBPM è una libreria open source. Fornisce una piattaforma per i linguaggi di processo che vanno dal business process management (BPM) sui workflow alla service orchestration. Supporta 3 diversi tipi di linguaggi di processo, ognuno dei quali è mirato verso una specifica funzione e ambiente: jPDL, BPEL, Pageflow. Tutti e tre sono sviluppati nativamente in seno ad una singola tecnologia: la Process Virtual Machine (PVM) che è una semplice libreria Java per lo sviluppo e l’esecuzione di grafici di processi.

FIGURA 3.1

14


Capitolo 3 – Analisi dei requisiti

Le funzionalità della piattaforma utilizzate riguardo al progetto di stage saranno quelle relative al BPM ed il linguaggio jPDL.

BPM Il Business Process Management è l’insieme di attività necessarie a creare, organizzare, gestire e migliorare i processi di business. La caratteristica peculiare del BPM consiste nell’avvalersi della tecnologia dell’informazione e della comunicazione (ICT) per amministrare i processi operativi delle imprese e incrementarne l’efficienza e l’efficacia. L’elemento innovativo è, perciò, costituito dalla possibilità, offerta dal BPM, di integrare le variabili tecnologica e organizzativa per migliorare sensibilmente la gestione dei processi d’impresa. L’utilizzo di logiche di BPM permette di risparmiare tempo durante lo svolgimento dei processi e, quindi, di guadagnare risorse utili che possono venir utilizzate nelle core activities dell’impresa. Le applicazioni di BPM permettono di elaborare un gran numero di variabili quantitative in real time, e, così, di scambiare informazioni utili relative allo stato di avanzamento dei processi e alle attività che li compongono, in modo da mettere in grado gli operatori di svolgere le proprie mansioni in modo più efficiente e produttivo. Le piattaforme che utilizzano software modellati sulle logiche di BPM permettono di rendere più chiare le procedure dell’azienda, sia per ciò che attiene alla successione delle attività, sia per quanto riguarda la visualizzazione grafica del complesso delle operazioni in corso di esecuzione. I programmi che riguardano il business process management possono basarsi su più applicativi differenti e integrati solo successivamente, oppure su software nativamente integrati. Una delle possibilità più interessanti che si aprono attraverso l’utilizzo di questo tipo di applicazioni si riferisce alle caratteristiche sempre più avanzate dei programmi che si inquadrano nelle logiche di BPM. I più moderni standard 15


Capitolo 3 – Analisi dei requisiti

nell’ambito dell’ICT permettono, infatti, di inserire in queste piattaforme alcuni software in grado di analizzare grandi quantità di dati e di fornire così report dettagliati che agevolano l’analisi dei processi, consentendo al management di improntare nuove e più efficaci strategie operative laddove riscontrassero lacune e malfunzionamenti nell’avanzamento delle attività. Le applicazioni software create secondo questa logica risultano, perciò, modellate secondo la struttura dei processi lavorativi aziendali, dei quali ricalcano l’intelaiatura sia per ciò che riguarda l’ambito applicativo, sia per quanto attiene al contesto dell’interfaccia utente (Figura 3.2)

FIGURA 3.2

Il BPM trascina con sé due importanti vantaggi. Innanzi tutto, costringe alla costruzione di un dialogo tra chi svolge un ruolo all’interno degli apparati organizzativi e chi si occupa della questione tecnologica, in modo da integrare organizzazione e tecnologia per raggiungere eccellenti risultati in termini di sfruttamento delle potenzialità dei moderni software gestionali. In secondo luogo, consente di monitorare i miglioramenti di performance dovuti all’implementazione del software e, quindi, permette di estrapolare dati utili per creare strategie volte ad un ancora maggiore miglioramento 16


Capitolo 3 – Analisi dei requisiti

dell’efficienza.

JPDL JPDL è un linguaggio di processo caratterizzato da una spiccata versatilità, offre diverse possibilità di integrazione con Java e si mostra maneggevole nell’ambito dell’ organizzazione dei task. La base del linguaggio è costituita dalla grafica e ciò determina un notevole incremento della semplicità d‘uso di JPDL, in questo modo la transizione fra il modello di analisi e il modello di esecuzione diviene estremamente facile e comprensibile. Può essere utilizzato in due modalità: attraverso un designer, oppure tramite una basilare sintassi XML. Viene fornito in una suite corredata da tutti gli elementi: il designer, la documentazione, gli esempi, le librerie.

3.1.3 Servlet

Una servlet è un programma eseguibile in un application server (nel nostro caso JBoss) ed ha molteplici funzionalità. Nella maggior parte dei casi, tuttavia, viene sfruttato per la generazione di pagine web in forma dinamica, a seconda dei parametri della richiesta che sono spediti dal browser. La servlet è, quindi, un programma che deve rispettare determinate regole e che processa una richiesta HTTP in una maniera specifica. All’interno dello stesso application server possono, naturalmente, girare più servlets, associate a indirizzi diversi e, dunque, con compiti diversi; sarà, così, ampliata l’estensione delle funzionalità del web server. La realizzazione di una servlet che estenda le funzionalità di una applicazione web di Visionest è proprio l‘obbiettivo primario del progetto qui descritto.

17


Capitolo 3 – Analisi dei requisiti

3.2 Ambiente di progetto: Finanza 3000

Finanza 3000 è un sistema informativo gestionale progettato e realizzato ad hoc per l’amministrazione dei servizi di erogazione di prodotti di Finanza Agevolata. Il prodotto è destinato ad operatori finanziari, pubblici e privati, e permette di gestire agevolmente ed in maniera completa i fondi di terzi (fondi pubblici, statali, regionali, UE) e il rilascio di garanzie (Confidi). Il gestionale mira, nello specifico, a risolvere i problemi di back office (gestione operativa), controllo e reporting di processi istruttori, rendicontazione ed erogazione di fondi. La peculiarità di Finanza 3000 è il riferimento a due concetti innovativi, che abbandonano la strada delle architetture gestionali di transizione, per concentrarsi su due punti fondamentali:  La gestione per processo - definisce e controlla un processo end to - end dall’inizio alla fine;  La gestione dei contenuti - organizza i documenti e le informazioni afferenti i processi operativi in ambiente internet e intranet. In particolare, il processo di istruttoria viene gestito dalla fase di start alla fase di end, seguendo le linee organizzative del back e front office e integrando le componenti di calcolo finanziario e le regole di compliance. Finanza 3000 è organizzato in moduli nativamente integrati che si snodano attraverso tre macrosezioni gestionali:

1. GESTIONALE che comprende i moduli:

 Anagrafica (il programma si integra con l‘anagrafica aziendale per 18


Capitolo 3 – Analisi dei requisiti

gestire in modo centralizzato e sicuro i soggetti coinvolti a vario titolo nello svolgimento dei processi. Permette di censire gli attori delle attività finanziarie e di certificare le informazioni acquisite attraverso l‘integrazione con i servizi infocamere.);  Gestione del sistema (organizza i parametri di configurazione dei processi, delle regole e dei vocaboli di business,dei dizionari dati, dei ruoli utente e dei report.)  Tassi e cambi (consente di gestire i valori di tassi e cambi anche attraverso la storicizzazione).

2. PROCESSI che è costituita dai moduli:

 Finanziamenti (governa tutte le fasi di erogazione del finanziamento, dall‘istruttoria all‘estinzione, passando per la rendicontazione e la gestione post vendita);  Contributi (si occupa della gestione dei contributi, amministrando il processo in tutte le sue fasi);  Prodotto complesso (consente la gestione di tutti gli strumenti finanziari complessi: combinazioni di leasing-finanziamenti contributi e garanzie).

3. DIREZIONALE, composta dai moduli:

 Report operativo (genera un set completo di report per supportare le funzioni di back e front office, producendo documenti utili agli attori interni - CDA, direzione finanza, direzione generale, ecc. - ed 19


Capitolo 3 – Analisi dei requisiti

esterni - beneficiari, intermediari finanziari, banche, ecc. - );  Report direzionale (permette l‘estrapolazione dei report necessari a coadiuvare le funzioni direzionali e di controllo);  Report engine (consente di generare qualsiasi genere di reportistica specifica);  BAM - business activity monitoring (calcola gli indicatori di performance relativi ai processi gestiti con Finanza 3000 e agevola le stime dei miglioramenti che si riscontrano con l‘uso del gestionale).

Per lo sviluppo di Finanza 3000 Visionest ha utilizzato il framework proprietario “aplus“. Nell’ambito di questo framework viene collocato il progetto per lo stagista. Aplus è una potente piattaforma di BPM attraverso la quale si rende possibile l’implementazione di applicazioni che hanno come scopo la gestione dei processi organizzativi, l’evoluzione degli stessi con un sostanziale contenimento dei costi e lo sviluppo di complesse applicazioni che si prestino ad essere utilizzate dagli utenti di front e back office. Visionest per rendere più efficienti le attività di progettazione del software Finanza 3000 ha adottato un “principio progettuale”. Questo “principio” è servito ad assegnare in maniera precisa i ruoli specifici ad ognuna delle componenti architetturali, consentendo di focalizzare i compiti che la piattaforma aplus avrebbe dovuto assolvere nell’ambito di ciascuna

componente. In

particolare, sono

state

evidenziate

le

“responsabilità” che ha lo strumento aplus nei confronti dei compiti da svolgere:  Definire i processi di business;  Definire le condizioni che devono essere soddisfatte affinchè un processo possa passare da uno stato al successivo; 20


Capitolo 3 – Analisi dei requisiti

 Fornire strumenti per verificare il comportamento del processo e le sue correlazioni con altri processi sistema prima della messa in opera;  Decidere quali utenti hanno accesso all’applicazione e con che privilegi;  Produrre rapporti a partire dalla struttura del processo e dal suo stato;  Operare in tempo reale sui processi;  Permettere l’apporto di nuove informazioni da parte di utenti esterni;  Fornire a potenziali beneficiari informazioni riguardo i processi disponibili. La piattaforma aplus è stata creata sulla base di un framework strutturato su tre componenti essenziali (Fig. 3.3: componenti del framework di aplus, fonte “aaaPLUS”,Visionest srl).: 1. BPMS - business process management system - motore di elaborazione dei processi, è il nucleo del sistema. I processi memorizzati nel database vengono eseguiti in tempo reale e i relativi output sono visualizzabili attraverso l’interfaccia utente, oppure traducibili in diversi tipi di report e stampabili. 2. CMS - content management system - modulo di gestione dei contenuti, è un’applicazione affidabile che nasce integrata con i servizi di BPM. 3. PMS - performance management system - modulo estrazione dei report. E’ un motore di estrazione, elaborazione, aggregazione e presentazione dei dati analitici che circolano all’interno del sistema: sia per ciò che riguarda le pratiche finanziarie, sia per quanto attiene all’efficienza

21


Capitolo 3 – Analisi dei requisiti

con la quale vengono svolti i processi.

FIGURA 3.3

E’, inoltre, presente, un tool grafico (modulo disegno dei processi) che permette di chiarificare le fasi del processo attraverso la sua rappresentazione grafica. Le componenti del framework sono state sviluppate attraverso moduli dedicati (Fig. 3.4: complesso dei moduli componenti il framework, fonte “aaaPLUS”,Visionest srl.):  il motore di BPM;  il motore di CMS;  il motore di DWH;  Il DB;  il BUS di integrazione;  il modulo di U.I.;  il modulo di analisi dei processi.

22


Capitolo 3 – Analisi dei requisiti

FIGURA 3.4

L’architettura di Finanza 3000 è di tipo service oriented, strutturata in moduli e componenti collegati fra loro dal framework Spring, leader nel campo delle moderne applicazioni Java Enterprise. I moduli si basano su foundation opensource altamente affidabili, quali:  Il motore di BPM (JBPM, JBoss);  Il motore di CMS (Alfresco);  Il motore di DWH (Jasper Reports);  BUS di integrazione (JBoss ESB);  Il modulo di U.I. (EXT JS);  Il modulo di analisi dei processi (JBPM, o altri tool standard quali BPM - Visual, Paradigm, Oynx).

23


Capitolo 3 – Analisi dei requisiti

Il database, infine, può essere di qualsiasi tipo, visto l’utilizzo della libreria di persistenza Hibernate che consente di utilizzare qualsiasi database relazionale come back-end.

FIGURA 3.5

3.3 Use case e descrizioni

In questa sezione vengono analizzate e descritte le funzioni che il sistema offre, così come percepite dagli utenti che interagiscono con il sistema stesso; si rappresentano, inoltre, i requisiti funzionali del prodotto. Essi

24


Capitolo 3 – Analisi dei requisiti

saranno essenzialmente due: l’utente avanzato (business user) e l’utente finale. I diagrammi sono accompagnati dalle loro descrizioni, per consentire una migliore comprensione.

3.3.1 Utente avanzato

L’utente avanzato, detto anche business user, vuole controllare il grafico di una definizione di processo caricato a sistema, quindi richiede al sistema l’intera immagine.

FIGURA 3.6

ATTORI COINVOILTI: solamente l’utente finale PRECONDIZIONE: l’utente ha effettuato il login con esito positivo e si trova quindi nella condizione di poter consultare il grafico. AZIONE: l’utente può consultare il grafico generale tramite richiesta HTTP alla servlet.

25


Capitolo 3 – Analisi dei requisiti

3.3.1 Utente finale

L’utente finale ha bisogno di capire dove un’istanza di processo si trovi all’interno del grafico, quindi richiede la definizione del processo dell’istanza in cui sta lavorando, annotata con evidenziato il nodo corrente.

FIGURA 3.7

ATTORI COINVOILTI: solamente l’utente finale PRECONDIZIONE: l’utente ha effettuato il login con esito positivo e si trova quindi nella condizione di poter consultare il grafico. AZIONE: l’utente può consultare il grafico con evidenziato il nodo corrente tramite richiesta HTTP alla servlet.

26


Capitolo 3 – Analisi dei requisiti

3.4 Requisiti

In questa sezione saranno elencati i requisiti del prodotto, utilizzando una opportuna classificazione per aiutarne la lettura. Per tali requisiti sarà adottata una apposita nomenclatura:  Una lettera iniziale per tutti “R” ad indicare che si tratta di un requisito;  Una lettera identificativa per specificarne la tipologia: “F” funzionale, “Q” di qualità, “I” di interfacciamento ed ambiente;  Una lettera per identificarne la priorità: “O” obbligatorio, “D” desiderabile, “P” opzionale;  Un numero univoco progressivo per i requisiti della categoria.

3.3.1 Requisiti funzionali

OBBLIGATORI:

 RFO01: deve rendere visualizzabile lo stato del processo corrente  RFO02: il prodotto deve essere una servlet  RFO03: il prodotto deve essere una funzione a se stante integrabile nella applicazione esistente

DESIDERABILI:

27


Capitolo 3 – Analisi dei requisiti

 RFD04: possibilità di visualizzare lo stato del nodo ossia se in esecuzione, sospeso o cancellato

OPZIONALI:

 RFP05: possibilità visualizzare il nome del task del nodo corrente  RFP06: possibilità di visualizzare i metadati coinvolti nel processo

3.3.2 Requisiti di qualità

OBBLIGATORI:

 RQO01: Il prodotto deve garantire un livello accettabile di affidabilità  RQO02: il prodotto deve essere facile da modificare e integrare in vista di future rivisitazioni da parte del team di Visionest

DESIDERABILI:

 RQD03: la visualizzazione dello stato dovrebbe essere comprensibile all’utente  RQD04: produzione di una adeguata documentazione  RQD05: il codice possibilmente ben commentato

28


Capitolo 3 – Analisi dei requisiti

OPZIONALI:

 RQP06: il prodotto risponde in tempi brevi alla richiesta HTTP

3.3.3 Requisiti di interfacciamento e di ambiente

OBBLIGATORI:

 RIO01: l’applicazione web deve essere compatibile con i browser più diffusi (Explorer, Firefox, Safari, Chrome, ecc);

DESIDERABILI:

 RID02: la servlet è realizzata partendo da uno scheletro per l’automazione del progetto maven

OPZIONALI:

 RIP03: la servlet dovrà interfacciarsi durante la messa in produzione al gestionale Finanza 3000 di Visionest

29


Capitolo 3 – Analisi dei requisiti

30


Capitolo 4 – Realizzazione

Capitolo 4

Realizzazione del prodotto

In questo capitolo vengono esposte le considerazioni e le descrizioni del prodotto, motivando le scelte architetturali ed altre decisioni tecniche. Sono, inoltre, presentati gli strumenti utilizzati per la realizzazione, e le descrizioni dettagliate delle componenti.

4.1 Strumenti per la realizzazione

4.1.1 Netbeans e relativi plug-ins

L’ambiente di sviluppo (IDE) è stato NetBeans. Questo ambiente è stato

31


Capitolo 4 – Realizzazione

sviluppato dalla Sun Microsystem e rilasciato con una particolare licenza open-source (CDDL che sta per Common Development and Distribution License). Esso fornisce una base multi-linguaggio, ma è scritto interamente in Java mediante l’utilizzo delle librerie grafiche standard (Swing). Poiché scritto in Java, il suo punto di forza primario è la versatilità, ossia la disponibilità a lavorare con numerose piattaforme. Inoltre, grazie alla sua struttura basata sui plug-ins, si offre come ambiente di sviluppo software per i più svariati linguaggi di programmazione ed integra

molte

altre

funzioni

utilissime

allo

sviluppatore,quali

la

compilazione assistita, il versionamento dei files e le modellazioni UML. Il motivo per cui NetBeans è stato scelto, in accordo con il tutor aziendale, è stata essenzialmente la dimestichezza precedentemente acquisita dallo stagista con tale strumento nell’ambito del progetto di ingegneria del software.

4.1.2 Maven plug-in

Nel corso della codifica si è sentita la necessità di uno strumento che rendesse pratica e veloce la stesura delle servlet, quindi, con l’assenso del tutor aziendale, si è scelto di utilizzare il plug-in standard di Maven per Netbeans. Maven è uno strumento software per l’organizzazione dei progetti e la costruzione automatica sviluppato dalla Apache software foundation e rilasciato con una licenza software free, compatibile con la GNU GPL. Si tratta di uno strumento autoinstallante, che procede all’installazione non appena si effettua il download automatico tramite il

32


Capitolo 4 – Realizzazione

gestore di plug-ins proprio dell’IDE. Questo strumento è predisposto per la rete in quanto scarica in maniera autonoma le librerie Java necessarie e i Maven plug-ins dai vari repository. Maven ha la caratteristica di possedere un costrutto particolare conosciuto come Project Object Model (POM) per descrivere il progetto software, le sue dipendenze da moduli e componenti esterni e l’ordine di costruzione. Questo plug-in è stato utile nell’ambito del progetto per la costruzione di una servlet definita di base, al fine di estendere successivamente le sue funzionalità con la visualizzazione dell’immagine del grafico di processo richiesta dall’utente.

4.1.3 Mercurial

Uno strumento già utilizzato presso l’azienda Visionest è Mercurial, un sistema distribuito di versionamento del codice, open-source e disponibile per gli ambienti più diffusi. Fin dall’inizio si è avvertita la necessità di tale strumento, per permettere al tutor aziendale di seguire gli steps realizzati giornalmente, consigliare e correggere il lavoro dello stagista, disponendo in tempo reale delle varie versioni prodotte. Questo tool consente, infatti, di eseguire tutte le operazioni di gestione delle versioni principali (inserimento, rimozione, modifica e merging) fornendo, contemporaneamente, supporto alla condivisione dei repository in modo distribuito. La sua particolarità sta nel fatto che ogni repository creato con Mercurial può essere scambiato e aggiornato, attraverso l’utilizzo di bundle 33


Capitolo 4 – Realizzazione

(pacchetto contenente tutte le modifiche a partire da una certa revisione), in maniera tale da consentire al ricevente di applicare semplicemente le modifiche al proprio repository locale, ottenendo una stessa versione finale ed una sincronizzazione dei contenuti.

4.2 Installazione e configurazione dell’ambiente

L’installazione e la configurazione dell’ambiente è avvenuta con l’assistenza diretta del tutor aziendale, affinché fosse possibile iniziare il lavoro disponendo dei programmi corretti nella versione idonea. Ovviamente, è stata prima verificata all’interno del sistema la presenza di Java EE, per poi procedere all’installazione dei tre strumenti sopra elencati. E’ stato inoltre aggiunto il bundle di JBPM in versione 3.2.1 contenente l’application server JBoss, la libreria JBPM, la documentazione e i relativi plug-ins per gli IDE più comuni (Eclipse, Netbeans, eccetera). Questo bundle è stato utile soprattutto per l’ampia documentazione contenuta al suo interno. Questo manuale ha rappresentato infatti una fonte adeguata per comprendere la struttura dei metadati utilizzati da JBPM e, inoltre, per capire in che modo la console standard interagisca con le servlet, inquadrando il tutto nell’ambito delle funzionalità del sistema, analoghe a quelle del gestionale di Visionest.

34


Capitolo 4 – Realizzazione

4.3 La JBPM console e la servlet base

La JBPM console standard è un applicativo di esempio che utilizza le funzioni della libreria JBPM. Al suo interno possiede delle servlets predefinite che sono state prese come punto di partenza per la realizzazione

della

nuova

servlet. E’

stata

dunque

studiata

la

documentazione di questa console per comprendere la struttura dei metadati, delle funzioni di base e l’interazione con questi ultimi. La servlet, in seguito all’avvio del web server JBoss, deve rispondere ad una richiesta HTTP da parte del browser. La richiesta può configurarsi come segue:

http://localhost:8080/ProcessImage-0.1/processImage?definitionId=2

In questo path è inserita la richiesta ad una data servlet di un certo id di processo. Essa andrà a reperire l’immagine per visualizzarla all’interno del browser e renderla disponibile all’utente. La cosa può essere resa in modo grafico attraverso il seguente diagramma di sequenza:

35


Capitolo 4 – Realizzazione

FIGURA 4.1

Secondo queste specifiche, grazie all’aiuto di Maven, è stato possibile produrre una servlet base, senza funzionalità integrate, ma che rispondesse correttamente ad una richiesta HTTP all’interno della JBPM console. Questo avviene perché è stata costituita una classe derivata da HttpServlet:

public class processImageServlet extends HttpServlet

Suddetta classe, nel momento evidenziato, non fa altro che visualizzare una pagina bianca nel browser. A partire da questo primo step si è potuta avviare la realizzazione del progetto.

36


Capitolo 4 – Realizzazione

4.4 Visualizzazione dell’immagine del grafico dei processi

Tramite la libreria JBPM è possibile estrarre dal database l’immagine generale del processo, ossia quella che incorpora il workflow completo dei processi. Questo è il risultato del primo obbiettivo del progetto di stage, ed

è

stato

possibile

raggiungerlo

partendo

dalla

servlet

base

precedentemente creata, con l’innesto di funzionalità atte a svolgere il compito richiesto. Ciò avviene essenzialmente tramite la classe processImageServlet che possiede al suo interno la funzione:

protected

void

doGet(HttpServletRequest

request,

HttpServletResponse

response)

che acquisisce l’id dell’immagine indicata dall’utente e, in seguito, ricerca nel database l’immagine richiesta, tramite il comando:

processDefinition.getFileDefinition().getBytes("processimage.jpg")

Questo è possibile in quanto JBPM chiama, di default, tutte le immagini create con lo stesso nome ed estensione, ossia processimage.jpg. In questo modo l’immagine viene individuata e mostrata nel browser; è stato così prodotto il primo output del progetto e relativala funzionalità è

37


Capitolo 4 – Realizzazione

stata messa in produzione all’interno del gestionale di Visionest, di cui possiamo vedere a seguito uno screenshot di effettivo utilizzo.

FIGURA 4.2

4.5 Visualizzazione dello stato di un’istanza di processo

4.5.1 Due soluzioni a confronto

Per quanto riguarda la realizzazione della funzionalità di visualizzazione dello stato di un’istanza di processo per l’utente finale, in prima battuta è

38


Capitolo 4 – Realizzazione

stata ricercata una soluzione, poi bocciata a favore di un’altra. Dapprima si era pensato, infatti, di seguire una interpretazione secondo la quale si lavorava sull’immagine stessa, presa dal database come spiegato in precedenza. L’immagine sarebbe stata reinterpretata e ad essa si sarebbe aggiunta una cornice in via grafica. Infine si sarebbe proceduto ad un secondo salvataggio che visualizzava il processo corrente così incorniciato. Questa opzione sarebbe stata complessa dal punto di vista realizzativo, perché richiedeva librerie grafiche per poter reinterpretare l’immagine. Inoltre la servlet avrebbe necessitato di un tempo eccessivo per rispondere alla richiesta, quindi è stata solo analizzata e mai sviluppata. Con l’approvazione del tutor aziendale si è, quindi, pensato di intraprendere un’altra via. Attraverso un‘approfondita analisi si è giunti alla conclusione che sarebbe stato conveniente procedere con la realizzazione di una maschera da apporre all’immagine tramite codice CSS e HTML per evidenziare lo stato corrente. In questo modo, non si sarebbe resa necessaria nessuna manipolazione all‘immagine. La soluzione è stata inizialmente proposta a livello teorico allo staff di Visionest, e, solo in seguito all’approvazione è stato possibile avviare il lavoro. L’iniziativa è risultata valida in quanto sarebbe stato possibile integrarla agilmente anche all’interno dell’ambiente gestionale Finanza 3000.

4.5.2 Visualizzazione mediante codice CSS

La visualizzazione dello stato di processo corrente viene così effettuata

39


Capitolo 4 – Realizzazione

tramite una cornice rettangolare, disegnata attraverso un foglio di stile a cascata opportunamente codificato. Esso viene chiamato all’interno di una pagina JSP (Java Server Page) che permette di visualizzare l’immagine di base, con l’aggiunta però di richiami al foglio di stile appositamente creato, che contiene il comando per generare appropriate cornici attorno allo stato che deve essere evidenziato. Le pagine JSP forniscono contenuti dinamici in formato HTML, esse sono una tecnologia Java per lo sviluppo di application server. Si basano su un insieme di speciali tags con cui possono essere invocati funzioni predefinite o codice Java. All’interno del file JSP viene instanziato un oggetto della classe processUtility, che è stata creata appositamente. Instanziare un oggetto di questa classe infatti serve per andare a leggere un particolare file di JBPM, il gdp.xml, che serve per descrivere i grafici dei processi mediante il comodo formato XML.Vediamo un semplice esempio:

<?xml version="1.0" encoding="UTF-8" ?> <process-diagram name="simple" width="469" height="438"> <node name="start" x="150" y="25" width="140" height="40"> <transition name="to_state" /> </node> <node name="first" x="150" y="125" width="140" height="40"> <transition name="to_end" /> </node>

40


Capitolo 4 – Realizzazione

<node name="end" x="150" y="225" width="140" height="40" /> </process-diagram>

Come si può notare, questo file contiene le informazioni principali del diagramma di flusso. Queste informazioni vengono, quindi, elaborate dalla classe processUtility, per essere salvate all’interno di oggetti appositamente creati, appartenenti alle due classi DiagramInfo e DiagramNodeInfo, che contengono rispettivamente le informazioni sull’intero diagramma e sul singolo nodo. Queste informazioni verranno richieste, appunto, a questi oggetti nei vari punti del file JSP e saranno, quindi, sempre disponibili per poter creare la cornice che evidenzi il nodo in questione. Per un esempio completo viene mostrata questa parte di codice estrapolata dalla pagina JSP:

<% style = "top:" + node.getY() + "px;left:" + node.getX() + "px;width:" + (node.getWidth() - 3) + "px;height:" + (node.getHeight() - 3) + "px"; styleClass = "pbox"; if (token.getEnd() != null) styleClass = "pbox_e"; if (token.isSuspended()) styleClass = "pbox_s"; %> 41


Capitolo 4 – Realizzazione

Come si può vedere, le coordinate e le dimensioni sono prese da delle funzioni

get

apposite,

ottenute

dalla

classe

DiagramNodeInfo,

successivamente viene caricata la cornice dal file CSS, di cui possiamo vedere una porzione:

div.pbox { border-color:#0000ff; } div.pbox_s { border-color:#aa6600; } div.pbox_e { border-color:#cc0000; }

Lo stato del nodo può trovarsi in 3 situazioni distinte, e ciò si rileva tramite una cornice di colore diverso ed una scritta sopra che attribuiscono chiarezza alla visualizzazione. Anche questa informazione viene prelevata, come abbiamo avuto occasione di apprezzare nel codice della pagina JSP, tramite una funzione booleana che ritorna la situazione. E’ possibile vederne un esempio nello screenshot seguente.

42


Capitolo 4 – Realizzazione

FIGURA 4.3

L’immagine rappresenta un nodo in stato di esecuzione, con la scritta Running sopra e contornato da una cornice blu. Se, invece, il nodo si trova sospeso, appare la scritta Suspended, con la cornice ocra, se è finito la cornice è rossa e appare la scritta Ended, come possiamo vedere gli screenshot seguenti.

43


Capitolo 4 â&#x20AC;&#x201C; Realizzazione

FIGURA 4.4

44


Capitolo 4 – Realizzazione

FIGURA 4.5

Questa funzionalità è stata globalmente accettata dal team di Visionest e verrà presto integrata nel gestionale Finanza 3000.

45


Capitolo 4 – Realizzazione

4.6 Analisi statica e dinamica

Al termine di ognuna delle fasi di sviluppo è stato verificato il codice prodotto. Una prima verifica veniva compiuta essenzialmente tramite analisi statica, al fine di accertare che il flusso dei vari dati fosse corretto in ogni punto del software prodotto. Sono stati approntati, inoltre, molti test facenti parte dell’analisi dinamica: principalmente di natura funzionale, strutturale e di integrazione fra le componenti, in modo tale da correggere la maggior parte degli errori. In generale, questi test non hanno sollevato problematiche di rilievo, ed anzi, hanno dimostrato una buona affidabilità ed una sostanziale robustezza del sistema. Con la supervisione del tutor aziendale si è così proceduto al collaudo, che ha dato, anche esso, esito positivo, conferendo il via libera alla messa in produzione dello strumento.

46


Capitolo 5 â&#x20AC;&#x201C; Consuntivo e conclusioni

Capitolo 5

Consuntivo e conclusioni

Questa sezione presenterĂ  un confronto fra il tempo preventivato per ogni attivitĂ  che ha concorso alla realizzazione del progetto e quello effettivamente impiegato; inoltre saranno presentate alcune considerazioni personali riguardo allo svolgimento dello stage e le conclusioni tratte da tale esperienza.

5.1 Confronto fra il preventivo ed il consuntivo

Le attivitĂ  che si sono svolte durante lo stage sono state essenzialmente quelle preventivate inizialmente. 47


Capitolo 5 – Consuntivo e conclusioni

La progettazione ha richiesto più tempo rispetto a quanto preventivato inizialmente; la fase di codifica, in compenso, è stata più breve, permettendo di rispettare appieno i tempi di realizzazione. Dapprima, infatti, si era cercato di intervenire sull’immagine reperita tramite la servlet, andando a modificarla e salvarla nuovamente, per poi visualizzarla di nuovo assieme allo stato del processo, che viene rappresentato da una sorta di cornice. Questa operazione sarebbe stata molto delicata e la sua realizzazione avrebbe richiesto molto tempo, al di là dell‘incremento dell‘attività della servlet per la reinterpretazione dell‘immagine. Si è quindi deciso di intraprendere una strada più semplice, utilizzando un semplice foglio di stile CSS (di cui abbiamo parlato nel capitolo dedicato alla realizzazione); ma molto più lunga per quanto ha riguardato la progettazione. Il problema fondamentale era cercare di capire se tale soluzione si poteva adattare al software Finanza 3000 di Visionest. Il team Visionest ha giudicato positivamente la soluzione, ritenendola molto brillante, di facile utilizzo, e adatta ad essere manipolata in futuro, perciò, in seguito all’approvazione, si è proceduto alla realizzazione del progetto. Per questo motivo è stata necessaria una progettazione più intensa e attenta ai dettagli e, quindi, sono state riscontrate alcune discrepanze con quanto preventivato.

5.2 Diagramma di Gantt

Quanto detto in precedenza può essere esposto in maniera visiva tramite il seguente diagramma di Gantt, che relaziona il tempo preventivato per ogni attività, segnato in azzurro, con quello effettivamente portato a 48


Capitolo 5 â&#x20AC;&#x201C; Consuntivo e conclusioni

consuntivo, segnato in rosso.

FIGURA 5.1 49


Capitolo 5 – Consuntivo e conclusioni

5.3 Analisi critica dello stage

Pur essendoci stato un buon inserimento nel team di lavoro e nel contesto dell’azienda, l’adozione di metodologie appropriate e di nuovi strumenti non è stata banale: molto tempo lavoro, infatti, è stato dedicato allo studio della piattaforma. Importantissime sono state la comunicazione con il tutor aziendale e la sua collaborazione, che hanno permesso di superare con facilità le difficoltà iniziali e hanno realmente accelerato i tempi di adattamento ai ritmi di lavoro aziendali. Gli obbiettivi sono stati complessivamente raggiunti: è stata realizzata la servlet secondo le specifiche richieste; sono stati soddisfatti anche requisiti opzionali e desiderabili, oltre a quelli obbligatori; è stata già avviata la messa in produzione del prodotto realizzato durante lo stage. Lo stage è stato senza dubbio utile, in quanto ha introdotto nuovi strumenti di sviluppo e di lavoro non inseriti nel programma di studi. La formazione fornita dall’Università in merito alle attività svolte è risultata in diversi casi più che sufficiente. E’ stata molto utile la dimestichezza appresa nei linguaggi orientati ad oggetti e soprattutto nell’ambito della piattaforma Java, acquisita durante i corsi di Programmazione 1 e di Programmazione concorrente e distribuita. Per quanto riguarda, invece, il linguaggio XML, le lezioni di Basi di dati 2 sono state molto importanti per capire a fondo la sintassi usata. Il corso di Ingegneria del software ha, inoltre, fornito solide fondamenta per lo svolgimento del progetto, soprattutto per ciò che riguarda l’esperienza acquisita nel contesto di una realtà aziendale, nella quale non si è più fini a se stessi ma tutti fanno parte di un progetto comune, ognuno con compiti specifici che vanno realizzati spesso in simbiosi. Una critica negativa può essere rivolta al programma di studi

50


Capitolo 5 – Consuntivo e conclusioni

universitari in quanto non ha fornito una base sufficiente per quanto riguarda un ambito molto attuale quale Java Enterprise, gli application server e le applicazioni web in generale, che sono molto in voga di questi tempi, soprattutto nel campo aziendale. Gli strumenti utilizzati in corso d’opera si sono rivelati molto utili ed hanno rispettato le aspettative nei loro confronti, il giudizio su di essi non può essere quindi che positivo. Trovandosi però lo stagista a confronto con strumenti da lui a volte mai utilizzati ha avuto bisogno di un periodo di apprendimento dei medesimi. Questo problematica non c’è stata per quanto riguarda l’IDE Netbeans in quanto già adottata durante il corso di ingegneria del software, ma si è rivelata soprattutto per l’uso di Apache Maven e delle servlets in generale, due tools che non erano mai stati utilizzati in passato. Dal punto di vista formativo lo stage si è presentato come una esperienza reale che è si è rivelata utile per comprendere le più generali problematiche aziendali, quali il rispetto delle scadenze, la misura dei risultati prodotti, la gestione del personale; il giudizio, in questo senso, quindi, non può essere che positivo. Lo svolgimento dello stage è stato uno dei modi migliori per introdurre lo studente nel mondo del lavoro ed è stato foriero, sia per lo stagista, sia per l’azienda, di buoni risultati: lo studente ha potuto apprendere nuovi linguaggi, realtà e ambienti di lavoro, per l’azienda, invece, è stato un mezzo per raggiungere un ampliamento delle funzionalità del proprio prodotto software e l’occasione per conoscere una nuova personalità che in futuro potrebbe essere inserita all’interno come dipendente. Non bisogna, infatti, scordare che l’azienda ha approvato il lavoro dello stagista e ne ha avviato la messa in produzione all’interno del proprio gestionale proprietario: Finanza 3000.

51


Bibliografia

[1] JBoss, http://www.jboss.com [2] JBoss Community, http://www.jboss.org [3] Visionest, http://www.visionest.com [4] Wikipedia, http://www.wikipedia.org [5] Java, http://www.java.com [6] Maven, http://maven.apache.org [7] BPM, http://www.bpm.com [8] Novocode, http://www.novocode.com/doc/servlet-essentials [9] Tecnoteca, http://www.applicationserver.it [10] Javaportal, http://www.javaportal.it

52


Tesi - Integrazione di un’applicazione di BPM - visualizzare lo stato di un processo  

Anno Accademico 2009/10 Tesi di Laurea Triennale in Informatica Laureando: Andrea Alberti Relatore: Prof. Livio Colussi FACOLTA’ DI SCIENZE...

Advertisement
Read more
Read more
Similar to
Popular now
Just for you