O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.
Angelini Francesco 241068
Ciprietti Luca 241632
Mennella Mario 241082
euProjectReporting
Tecniche di Persistenza
Anno 2014...
1
euProjectReporting|2014/2015
euProjectReporting
Overview dell’Applicazione
Da anni l’università degli studi dell’Aquila ...
2
euProjectReporting|2014/2015
 Amministratore di Sistema: è una particolare tipologia di utenza, che non ha direttamente...
3
euProjectReporting|2014/2015
1.5.1. Le attività presenti attualmente sono:
- RTD: attività di ricerca e sviluppo tecnolo...
4
euProjectReporting|2014/2015
3.1. Il sistema deve prevedere figure di amministratore di sistema, coordinatore di progett...
5
euProjectReporting|2014/2015
5.3.2. Le ore di attività giornaliere hanno dei vincoli da rispettare;
5.3.3. Deve essere p...
6
euProjectReporting|2014/2015
11.1. Al momento della realizzazione (gennaio 2016), le tipologie per cui deve essere
compa...
7
euProjectReporting|2014/2015
Use Case Requisiti
Crea utente 3.5
Gestione storico utente 2.4
Crea tipologia attività 3.5
...
8
euProjectReporting|2014/2015
poter avere il maggior controllo possibile sui dati inseriti e rendere più precisi i contro...
9
euProjectReporting|2014/2015
Un’altra cosa rilevante nella classe Utente, è l’annotazione @Embedded, riferito alla class...
10
euProjectReporting|2014/2015
Nello specifico:
- UserService: si occupa di reperire e calcolare tutte le informazioni re...
Próximos SlideShares
Carregando em…5
×

de

[MWT] Relazione tecniche di persistenza EuProjectReporing  Slide 1 [MWT] Relazione tecniche di persistenza EuProjectReporing  Slide 2 [MWT] Relazione tecniche di persistenza EuProjectReporing  Slide 3 [MWT] Relazione tecniche di persistenza EuProjectReporing  Slide 4 [MWT] Relazione tecniche di persistenza EuProjectReporing  Slide 5 [MWT] Relazione tecniche di persistenza EuProjectReporing  Slide 6 [MWT] Relazione tecniche di persistenza EuProjectReporing  Slide 7 [MWT] Relazione tecniche di persistenza EuProjectReporing  Slide 8 [MWT] Relazione tecniche di persistenza EuProjectReporing  Slide 9 [MWT] Relazione tecniche di persistenza EuProjectReporing  Slide 10 [MWT] Relazione tecniche di persistenza EuProjectReporing  Slide 11
Próximos SlideShares
Anderson2015
Avançar
Transfira para ler offline e ver em ecrã inteiro.

0 gostaram

Compartilhar

Baixar para ler offline

[MWT] Relazione tecniche di persistenza EuProjectReporing

Baixar para ler offline

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.

  • Seja a primeira pessoa a gostar disto

[MWT] Relazione tecniche di persistenza EuProjectReporing

  1. 1. Angelini Francesco 241068 Ciprietti Luca 241632 Mennella Mario 241082 euProjectReporting Tecniche di Persistenza Anno 2014/2015
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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.

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.

Vistos

Vistos totais

128

No Slideshare

0

De incorporações

0

Número de incorporações

3

Ações

Baixados

3

Compartilhados

0

Comentários

0

Curtir

0

×