Da anni l’università degli studi dell’Aquila partecipa in maniera attiva ai “programmi quadro”, strumenti finanziari dell’Unione Europea per incentivare le attività di ricerca e sviluppo che concernono quasi tutte le discipline scientifiche. I PQ sono proposti dalla Commissione Europea e adottati dal Consiglio e dal Parlamento Europeo con la procedura di codecisione. Lo scopo dell’applicazione euProjectReporting è la semplificazione della stesura delle rendicontazioni dei progetti europei appartenenti ai PQ, tramite una comoda interfaccia Web.

1. Angelini Francesco 241068
Ciprietti Luca 241632
Mennella Mario 241082
euProjectReporting
Tecniche di Persistenza
Anno 2014/2015

2. 1
euProjectReporting|2014/2015
euProjectReporting
Overview dell’Applicazione
Da anni l’università degli studi dell’Aquila partecipa in maniera attiva ai “programmi quadro”, strumenti
finanziari dell’Unione Europea per incentivare le attività di ricerca e sviluppo che concernono quasi tutte
le discipline scientifiche. I PQ sono proposti dalla Commissione Europea e adottati dal Consiglio e dal
Parlamento Europeo con la procedura di codecisione.
Il programma usufruisce di uno stanziamento di bilancio che viene distribuito per ogni progetto sotto
forma di sovvenzioni ai ricercatori in Europa e altrove con l’obiettivo di cofinanziare la ricerca, lo
sviluppo tecnologico e i progetti dimostrativi. Per cofinanziamento si intende che la Commissione eroga
delle sovvenzioni ai progetti contribuendo per una quota ai costi globali, cioè rimborsando una
percentuale dei costi sostenuti per la realizzazione dei progetti.
Per avvalersi di queste sovvenzioni è necessario rispondere agli inviti pubblicati periodicamente sulla
Gazzetta Ufficiale dell'Unione Europea.
Gli inviti sono ufficiali e rivolti ai ricercatori affinché presentino delle proposte di ricerca per un’area
specifica del Programma quadro.
Tutte le proposte inoltrate vengono valutate da un team di esperti che stila una graduatoria in base alla
qualità e priorità del progetto in esame. Tale valutazione è utilizzata dalla Commissione Europea per
stabilire la classifica finale delle proposte approvate. Dopo la sottoscrizione del contratto, in genere
vengono presentati rapporti annuali sullo stato di avanzamento del progetto e sui costi sostenuti. Per
redigere queste rendicontazioni annuali è necessario tener conto delle spese sostenute per la
realizzazione del progetto e del costo del personale che vi ha preso parte, dunque si deve tener traccia
del budget a disposizione e della quantità di lavoro svolto dal personale.
Lo scopo dell’applicativo euProjectReporting è la semplificazione della redazione delle rendicontazioni
dei progetti europei appartenenti ai PQ, tramite una comoda interfaccia Web.
Attori coinvolti nell’utilizzo del sistema
Gli attori coinvolti nell’utilizzo dell’applicazione, sono di 3 tipi:
 Utente semplice: è un qualsiasi docente o ricercatore, attivamente coinvolto in un progetto
europeo per il quale sia previsto un rimborso all’interno dei Programmmi Quadro;
 Coordinatore: è un utente che ha i privilegi di coordinatore riguardo un dato progetto, per i
quali può visualizzare informazioni ulteriori rispetto ad un semplice utente e per il quale si
occupa di effettuare la rendicontazione. Questo è probabilmente l’attore che farà maggiore uso
di euProjectReporting, perché tramite esso sarà in grado di automatizzare tutte le operazioni
che in precedenza venivano svolte manualmente, o tramite l’utilizzo di fogli di calcolo Excel.

3. 2
euProjectReporting|2014/2015
 Amministratore di Sistema: è una particolare tipologia di utenza, che non ha direttamente a che
fare con i Programmi Quadro, ma che si occupa di gestire e “configurare” (registrazione utenti,
inserimento ruoli, ecc…) l’applicazione.
Requisiti
In Rosso vengono evidenziati i requisiti più critici.
Il sistema deve gestire:
1. Le features dei progetti PQ;
1.1. Ogni progetto deve avere:
- Un codice univoco identificativo;
- Un titolo descrittivo;
- Un acronimo;
- Data inizio e data fine del progetto;
- Tipologia;
1.2. Esistono diverse tipologie di progetto (idea, people, collaboration, …);
1.3. I progetti possono essere divisi in diversi moduli chiamati workpackages;
1.3.1. Ogni workpackage è legato ad una sola tipologia di attività;
1.3.2. I workpackages sono classificati secondo:
- Codice identificativo;
- Durata espressa in mesi uomo;
- Data inizio e data fine;
- Titolo descrittivo;
1.4. Un progetto ha un budget a disposizione;
1.4.1. Il budget è diviso in base alla tipologia di costo e attività;
1.4.1.1. Le tipologie di costo sono “Costi diretti” e “Costi indiretti”:
- Costi diretti: costi del personale, attrezzature durevoli, delle missioni e dei
subcontratti;
- Costi indiretti: costi di natura amministrativa, logistica e strutturali come
affitti di immobili e/o strumentazioni, assicurazioni, bollette o costi di
comunicazione;
1.5. Le tipologie di attività possono cambiare tra le tipologie di progetto;

4. 3
euProjectReporting|2014/2015
1.5.1. Le attività presenti attualmente sono:
- RTD: attività di ricerca e sviluppo tecnologico;
- Management: attività di coordinamento finanziario, legale, etico e
amministrativo. Non comprende le attività di coordinamento scientifico;
- Demostration: attività di dimostrazione o validazione dell’attuabilità della
nuova tecnologia;
- Other: tipologia che racchiude in se tutte le attività che non appartengono alle
categorie precedenti;
2. Il personale che partecipa ai progetti;
2.1. Ogni utente deve essere registrato nel sistema;
2.1.1. Per ogni utente devono essere memorizzati:
- Nome e cognome;
- Email;
- Categoria salariale;
- Stipendio;
- Ruolo;
2.1.2. Il sistema deve essere accessibile solo dopo autenticazione;
2.1.3. La registrazione di utenti deve essere sottoposta a restrizioni;
2.1.3.1. Nuovi utenti possono essere registrati solo dall’amministratore di sistema;
2.2. Ogni utente deve poter gestire i propri dati personali;
2.3. Un utente può partecipare a zero o n progetti contemporaneamente;
2.4. Ogni utente ha un ruolo all’interno dell’università;
2.4.1. Un utente può ricoprire un solo ruolo alla volta;
2.4.1.1. Un utente può però ricoprire diversi ruoli nel tempo;
2.4.1.1.1. È necessario un meccanismo che preservi la validità dei dati nel tempo;
2.4.2. In base al ruolo esistono vincoli sulle ore di attività annuali;
2.4.2.1. I vincoli possono cambiare nel tempo;
2.4.2.1.1. È necessario un meccanismo che preservi la validità dei dati nel tempo;
3. Diversi gruppi di utenza;

5. 4
euProjectReporting|2014/2015
3.1. Il sistema deve prevedere figure di amministratore di sistema, coordinatore di progetto e
utente semplice;
3.2. Alcune funzionalità saranno accessibili in base al gruppo di utenza;
3.2.1. Viste personalizzate in base alla figura ricoperta;
3.3. L’utente registrato ha funzionalità di gestione della propria didattica e dei dati riguardanti il
proprio profilo utente; inoltre deve avere accesso ad info utili sui progetti a cui prende parte e
deve poter registrare tutte le attività svolte su ognuno di essi;
3.4. Il coordinatore di progetto ha diritto a creare un progetto, gestirne le rendicontazioni ed
associare del personale al progetto. Deve avere funzionalità per supervisionare sui timesheets
utenti riguardanti il progetto di cui è coordinatore e registrare le spese sostenute per esso.
3.5. L’amministratore di sistema ha la funzionalità per creare nuove tipologie di attività, nuovi
utenti, nuovi parametri di configurazioni e funzionalità per assegnare permessi di coordinatore
ad un utente;
4. La registrazione di spese generati da un progetto;
4.1. Le spese per il personale sono calcolabili dai timesheets di ogni utente;
4.1.1. Le spese dovranno essere catalogate in base alla tipologia (costi diretti o indiretti) e in
base alle attività (RTD, Management, Demostration, Other,…) per cui si sono verificate;
4.2. La registrazione delle spese è una peculiarità di alcuni gruppi di utenza;
4.3. Le spese che non rientrano nel costo del personale dovranno esser registrate sotto la categoria
di “Other direct cost”;
4.3.1. Le caratteristiche delle spese registrabili nel sistema devono essere:
- Data spesa;
- Quantità espressa in euro;
- Descrizione;
- Utente che ha sostenuto la spesa;
5. La produzione di timesheet;
5.1. Per ogni utente esiste un solo timesheet;
5.2. Un timesheet fa riferimento ad un'unica rendicontazione;
5.2.1. I timesheets hanno data inizio e fine corrispondenti a quelle della rendicontazione a cui
appartengono;
5.3. In un timesheet deve esser registrato giornalmente il numero di ore dedicate al progetto;
5.3.1. Le ore di attività devono specificare su quale workpackage si sono svolte;

6. 5
euProjectReporting|2014/2015
5.3.2. Le ore di attività giornaliere hanno dei vincoli da rispettare;
5.3.3. Deve essere possibile memorizzare più attività in un'unica data;
5.4. Il sistema deve assicurare che i vincoli sulle attività siano sempre rispettati;
5.5. La creazione di timesheets non è una funzionalità aperta a tutti i gruppi di utenza;
5.6. Ogni utente deve essere in grado di gestire i propri timesheets;
6. La redazione automatica di rendicontazioni per un progetto;
6.1. Una rendicontazione si riferisce ad un solo progetto e ad un determinato periodo di tempo;
6.1.1. Un progetto può avere da 0 a N rendicontazioni;
6.2. Il totale delle spese presenti in una rendicontazione sono divise in base alla tipologie dei costi e
alle categorie di attività.
6.2.1. Il costo del personale deve specificare il costo di ogni singolo dipendente relativamente
ad ogni workpackage;
6.3. Le rendicontazioni devono indicare le quote di rimborso (cofinanziamento);
6.3.1. Le percentuali di rimborso dipendono dalla tipologia di progetto;
7. Ogni utente ha associate delle attività didattiche;
7.1. La didattica deve rispettare dei vincoli giornalieri e annuali;
7.2. La didattica non ha valore nella redazione delle rendicontazioni;
7.3. Ogni utente deve essere in grado di gestire le proprie attività di didattica;
8. Funzionalità di creazione/modifica/eliminazione;
8.1. Deve esser possibile creare/modificare/eliminare un progetto;
8.1.1. Funzionalità di modifica ed eliminazione di progetti e/o di workpackages devono esser
sottoposte a vincoli restrittivi;
9. Il sistema deve essere configurabile;
9.1.1. Future modifiche non devono compromettere l’integrità dei dati memorizzati nel
sistema.
9.1.1.1. I seguenti casi incidono sull’integrità dei dati nel tempo:
9.1.1.1.1. Utente che cambia ruolo, cambiamento vincoli ore per ruolo utente,
utente che cambia categoria stipendiale, cambiamento valore mesi/uomo;
10. Funzionalità di rappresentazione di stato di un progetto;
10.1. Il sistema deve esportare dati in diversi formati;
11. Il sistema deve essere compatibile con diverse tipologie di Programmi Quadro;

7. 6
euProjectReporting|2014/2015
11.1. Al momento della realizzazione (gennaio 2016), le tipologie per cui deve essere
compatibile l’applicativo sono il Settimo Programma Quadro e Horizon2020.
Use cases diagrams
Use Case Requisiti
Gestione profilo 2.2, 3.3
Visualizza progetti attivi 2.3, 3.3
Registrazione didattica svolta 7, 3.3
Visualizza attività 5.3, 5.6
Controllo vincoli 5.4
Registrazione attività progetto 3.3
Creazione progetto 8
Assegna utente alla rendicontazione 5.1, 5.2
Visualizza progetti coordinati 3.4
Supervisione didattica e timesheets utenti 3.4

8. 7
euProjectReporting|2014/2015
Use Case Requisiti
Crea utente 3.5
Gestione storico utente 2.4
Crea tipologia attività 3.5
Class diagram
Il class diagram riportato sopra rappresenta il modello dati di euProjectReporting.
Sì tratta di un modello dati relativamente complesso, perché nella gestione dei Programmi Quadro,
entrano in gioco molti elementi rilevanti, che ha senso dividere in classi sempre più piccole, così da

9. 8
euProjectReporting|2014/2015
poter avere il maggior controllo possibile sui dati inseriti e rendere più precisi i controlli sui vincoli da
rispettare.
Come si può notare, il tutto ruota intorno a 3 classi principali: Utente, Progetto e Rendicontazione.
La classe Utente rappresenta banalmente ogni tipologia di utenza, con i relativi metodi di utilità.
La classe Progetto rappresenta il progetto di riferimento. In questo caso è stato dovuto operare una
scelta molto importante per rendere l’applicativo compatibile con diverse tipologie di progetto (nelle
prime fasi della realizzazione era in corso il Settimo Programma Quadro, mentre durante lo sviluppo, è
entrato in vigore il programma Horizon2020): abbiamo scelto di gestire la cosa, creando una classe
generica Tipologia, con due sottoclassi Tipologia7PQ (per il 7 Programma Quadro) e TipologiaH2020
(per Horizon2020), lasciando nella classe padre solamente i metodi che si riferiscono a entrambe le
tipologie di progetto.
La classe Rendicontazione, invece, può essere considerata l’output finale di tutto l’applicativo: essa
fondamentalmente si occupa di calcolare, e visualizzare al coordinatore, tutti i dati relativi a un progetto
e a un dato periodo temporale. Il calcolo delle rendicontazioni dipende strettamente dalla tipologia del
progetto in esame. Attraverso l’uso di overwriter di metodi nelle classi figlie di Tipologia è possibile
calcolare i costi in maniera opportuna.
Quest’ultima classe consente anche di esportare la rendicontazione in Excel, formato accettato dalla
Segreteria universitaria che si occupa della gestione e della rendicontazione dei Programmi Quadro.
Persistenza
Per quanto riguarda la persistenza, è stata utilizzata la specifica Java JPA, che sono le API ufficiali di Java,
per rappresentare delle classi java (comprese di relazioni fra di esse) su database relazionali, nel nostro
caso Oracle 11g Express Edition.
Il mapping eseguito a livello di codice, tramite le annotazioni JPA, non verrà trattato per tutte le classi,
ma solamente per quelle ritenute più delicate e complete.
Innanzitutto, c’è da dire che per tutte le entità è stato utilizzato il property-based access, ossia l’accesso
alle variabili di ogni entità, che avviene tramite i metodi get e set: questo per essere in grado di
effettuare controlli sui singoli campi, in maniera più semplice e precisa; è quindi questa la scelta che da
maggior robustezza alla nostra applicazione.
Utente
La prima classe presa in considerazione per il mapping è la classe Utente, che sul database è
rappresentata dalla tabella UTENTE.
Questa classe è in relazione con le classi GruppiUtenza, StoricoUtente, Didattica e Timesheet. In questo
caso, le relazioni sono tutte di tipo OneToMany, ossia ad un singolo utente possono essere associati più
oggetti della classe corrispondente.
Questo perché un utente potrà avere diversi gruppi di utenza (può essere nello stesso momento utente
semplice per un dato progetto e coordinatore per un altro progetto), più didattiche (una per ogni anno),
ecc…

10. 9
euProjectReporting|2014/2015
Un’altra cosa rilevante nella classe Utente, è l’annotazione @Embedded, riferito alla classe Avatar.
Questa classe rappresenta un’immagine dell’utente che, grazie proprio alla suddetta annotazione, viene
salvata nella stessa tabella dell’utente, come un singolo campo.
Progetto
In questa classe, l’annotazione più rilevante, riferita a un’associazione OneToMany tra progetto e
coordinatore che permette di specificare come ad un singolo progetto possono venire associati più
coordinatori, è rappresentata dalla riga:
@JoinTable(name = "coordinatori", joinColumns = @JoinColumn(name = "id"))
La prima annotazione indica che l’associazione avviene tramite la tabella coordinatori, mentre
l’annotazione @JoinColumn, indica le colonne che identificano le chiavi esterne delle due tabelle
mappate dall’associazione.
Tipologia
Questa classe viene analizzata per mostrare la scelta utilizzata nella realizzazione del mapping delle
ereditarietà.
Come si può notare dalla riga
@Inheritance(strategy=InheritanceType.JOINED)
Il mapping viene eseguito con tipologia Joined, ossia ogni sottoclasse viene rappresentata in una tabella,
mentre la tabella che rappresenta la classe padre, è comune a tutte, che la referenziano tramite una
foreign key.
Ciò permette di risparmiare notevole spazio in memoria e, nel nostro caso, non avendo alberi di
discendenza troppo vasti e profondi, non dovrebbe portare a problemi di performance, molto comuni se
si usa questa tipologia di mapping, in presenza di ereditarietà complesse.
Architettura
L’architettura utilizzata per l’applicazione è basata sulla logica multi-tier.
Il livello di presentazione si occupa di mappare e gestire tutte le chiamate effettuate dal browser
dell’utente ed è sviluppato tramite l’utilizzo del framework Spring.
Questa parte dell’applicazione è eseguita (deployata) all’interno del web server Tomcat che deve essere
configurato ad hoc, per riuscire a comunicare con gli altri tier, residenti all’interno di un diverso server.
Nello specifico, gli altri due tier, vengono eseguiti dall’application server Glassfish: ciò è fondamentale
perché Tomcat, essendo solo un web server (e non un application server), non è perfettamente
accondiscendente (“compliant”) alla specifica JEE.
Lo strato intermedio dell’applicazione, che consiste nella logica di business, è realizzato dagli EJB
(Enterprise Java Beans), richiamati tramite un processo di lookup (ricerca) eseguito dall’applicazione
web. Questi componenti effettuano le operazioni richieste prelevando i dati dallo strato di persistenza,
elaborandoli e restituendo il risultato allo strato di presentazione. Gli EJB sono UserService e
ProjectService, sono entrambi di tipo Stateless, ossia non mantengono viva la sessione tra client e server,
ed entrambi espongono un’interfaccia che verrà richiamata da remoto dal client.

11. 10
euProjectReporting|2014/2015
Nello specifico:
- UserService: si occupa di reperire e calcolare tutte le informazioni relative agli utenti, come ad
esempio lo storico utente, ossia tutti i ruoli ricoperti dall’utente, dal momento della sua
iscrizione all’applicazione;
- ProjectService: fornisce tutte le informazioni relative ai progetti, come i workpackages, le
rendicontazioni e gli utenti associati.
La persistenza, come detto, è realizzata tramite la specifica JPA, marcando le classi del dominio con
l’annotazione @Entity, e realizzando così degli Entity Beans (anch’essi residenti sull’application server
Glassfish) che comunicheranno col database Oracle.