Sviluppo di un’applicazione web per la gestione dei ... La vita ed i sogni sono fogli di uno...

90
Univesit` a di Roma Tor Vergata Ingegneria dell’Informazione - Ind. Sistemi Sviluppo di un’applicazione web per la gestione dei consuntivi scientifici dell’I.N.F.N. Antonello Paoletti Relatore: Prof.ssa Berta Buttarazzi Correlatori: Dott.ssa Marina Candusso Anno Accademico 2005 / 2006

Transcript of Sviluppo di un’applicazione web per la gestione dei ... La vita ed i sogni sono fogli di uno...

Univesita di Roma Tor Vergata

Ingegneria dell’Informazione - Ind. Sistemi

Sviluppo di un’applicazione web

per la gestione dei consuntivi scientifici dell’I.N.F.N.

Antonello Paoletti

Relatore:

Prof.ssa Berta Buttarazzi

Correlatori:

Dott.ssa Marina Candusso

Anno Accademico 2005 / 2006

La vita ed i sogni sono fogli di uno stesso libro.

Leggerli in ordine e vivere...sfogliarli a caso e sognare.

(Arthur Schopenhauer)

Ringraziamenti

Per chi ci ha creduto e chi ci crede tuttora.

Indice

Introduzione 6

1 L’istituto Nazionale di Fisica Nucleare 8

1.1 Attivita di ricerca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.1.1 Organizzazione amministrativa dell’ente . . . . . . . . . . . . . . . 10

1.1.2 I consuntivi scientifici . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.1.3 Sistema di gestione . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.1.4 Il servizio Dataweb . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.1.5 Soluzioni precedenti . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2 L’interfaccia 15

2.1 Autenticazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2 Home Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3 Il menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.3.1 Esperimenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.3.2 Common Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3.3 Sommari . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3.4 Modifica dati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.4 Funzionalita offerte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.4.1 Brief report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.4.2 Inserimento dei dati . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.4.3 Collaborations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.4.4 More on the experiment . . . . . . . . . . . . . . . . . . . . . . . . 28

2.4.5 Milestones 2004 and Level of Completion(%) . . . . . . . . . . . . . 28

2.4.6 Milestones 2005 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.4.7 Leadership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.4.8 Internationalization . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.4.9 Spin-off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2

INDICE 3

2.4.10 Fall-out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3 Analisi ed Implementazione 39

3.1 Requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.2 Analisi degli User Requirements . . . . . . . . . . . . . . . . . . . . . . . . 39

3.2.1 Struttura delle precedenti schede di Consuntivo . . . . . . . . . . . 39

3.2.2 Nuove schede di Consuntivo: struttura proposta . . . . . . . . . . . 41

3.2.3 Modalita di accesso utenti . . . . . . . . . . . . . . . . . . . . . . . 42

3.2.4 Produttivita scientifica comune a piu esperimenti / iniziative scien-

tifiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.2.5 Milestone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.2.6 Leadership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.2.7 Grado di Internazionalizzazione . . . . . . . . . . . . . . . . . . . . 44

3.2.8 Spin-off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.2.9 Produttivita: Ricadute . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.2.10 Collaborazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.3 Caso d’uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.4 Struttura degli script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.5 Funzioni utilizzate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.5.1 Presa dati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.5.2 Inserimento dati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.5.3 Cancellazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.6 Struttura dell’output HTML . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.6.1 Validazione W3C . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.6.2 Componente client-side . . . . . . . . . . . . . . . . . . . . . . . . . 54

4 Database 57

4.1 Database Management System . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.1.1 Definizione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.1.2 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.2 Database utilizzato dall’applicazione . . . . . . . . . . . . . . . . . . . . . 60

4.2.1 Entita e relazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.3 Realizzazione del Database: Catalogo dei dati . . . . . . . . . . . . . . . . 63

4.3.1 Entita ActivityReport . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.3.2 Entita Collaborazione . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.3.3 Entita Commissione . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.3.4 Entita Esperimento . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

INDICE 4

4.3.5 Entita Internazionalizzazione . . . . . . . . . . . . . . . . . . . . . . 68

4.3.6 Entita Leadership . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

4.3.7 Entita Milestone . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

4.3.8 Entita Ricaduta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

4.3.9 Entita Settore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

4.3.10 Entita Spin off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

4.4 Esempi di inserimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

4.5 Struttura precedente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Elenco delle figure

1.1 Acceleratore di particelle Daphne . . . . . . . . . . . . . . . . . . . . . . . 9

1.2 Le strutture locali INFN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.3 Personale I.N.F.N. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.4 Organigramma INFN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.5 Scala temporale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1 Accesso al sito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2 Home Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3 Terzo livello del menu: esperimenti . . . . . . . . . . . . . . . . . . . . . . 19

2.4 Terzo livello del menu: common activities . . . . . . . . . . . . . . . . . . . 21

2.5 Terzo livello del menu: sommari in lettura . . . . . . . . . . . . . . . . . . 22

2.6 Terzo livello del menu: sommari in modifica . . . . . . . . . . . . . . . . . 24

2.7 Brief report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.8 Collaborations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.9 More on the experiment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.10 Milestone 2004 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.11 Milestone 2005 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.12 Leadership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.13 Internationalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.14 Spin-off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

2.15 Fall-out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.1 Use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.2 Webserver con PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.3 HTML 4.01 compliant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

3.4 Rapporto validazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.1 Logo di MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.2 Motore di MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5

ELENCO DELLE FIGURE 6

4.3 Architettura 2-tier thin client . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.4 Diagramma E-R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.5 ActivityReport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.6 Collaborazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4.7 Commissione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.8 Esperimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

4.9 Internazionalizzazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

4.10 Leadership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

4.11 Milestone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

4.12 Ricaduta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

4.13 Settore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

4.14 Spinoff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

4.15 ActivityReport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

4.16 Collaborazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

4.17 Commissione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

4.18 Esperimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

4.19 Internazionalizzazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

4.20 Leadership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

4.21 Milestone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

4.22 Ricaduta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

4.23 Settore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

4.24 Spinoff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

4.25 Inserimento milestone nella vecchia applicazione . . . . . . . . . . . . . . . 89

Introduzione

Questo progetto si pone come obiettivo la realizzazione di un’applicazione web per la

gestione di informazioni sull’attivita di ricerca dell’Istituto Nazionale di Fisica Nucleare

(INFN). Scopo ultimo del lavoro e fornire un’interfaccia, fruibile da web, per la raccolta di

dati scientifici degli esperimenti, includendo tesi universitarie, pubblicazioni, conferenze,

risultati, previsioni e ricadute nel mondo industriale. I dati di consuntivo costituiscono

un importante riscontro per l’istituto, poiche evidenziano in dettaglio i risultati raggiunti

dai singoli esperimenti e forniscono una visione globale sui progressi della ricerca.

Il codice e stato completamente riscritto, a partire da una versione precedente, inte-

grando la vecchia interfaccia con nuove funzionalita e contenuti, tali da poter soddisfare i

requisiti utente, raccolti in precedenza e formalizzati in un documento. Lo sviluppo delle

pagine, la progettazione del nuovo database ed i vari test del sistema, hanno richiesto un

periodo di lavoro di due mesi, avviato a Gennaio 2005 con la raccolta dei requisiti. La

messa in opera e la successiva fase di presa dati, ha coinvolto le sedi locali dell’ente per

tutto il mese di marzo, con una deadline fissata al 31.

Sono state introdotte nuove modalita di inserimento delle informazioni, strutturando

in maniera piu ordinata l’interfaccia di presa dati e lo stesso database, riscritto ex-novo,

affinche potesse sfruttare appieno le potenzialita offerte da un Relational Database Ma-

nagement System (RDBMS). L’organizzazione dei dati e stata radicalmente cambiata,

grazie alla nuova struttura relazionale che ha permesso di raggruppare informazioni tra

loro omogenee ed ordinate, consentendo una maggiore facilita d’uso e di consultazione.

7

Capitolo 1

L’istituto Nazionale di Fisica

Nucleare

1.1 Attivita di ricerca

L’INFN e l’ente dedicato allo studio dei costituenti fondamentali della materia e svolge

attivita di ricerca, teorica e sperimentale, nei campi della fisica subnucleare, nucleare e

astroparticellare. Nella seconda meta degli anni ’50 l’INFN progetto e costruı il primo

acceleratore italiano, l’elettrosincrotrone realizzato a Frascati, dove nacque il primo Labo-

ratorio Nazionale dell’Istituto. La ricerca fondamentale in questi settori richiede l’uso di

tecnologie e strumenti di ricerca d’avanguardia che l’INFN sviluppa nei propri laboratori

e in collaborazione con il mondo dell’industria. In particolare il supporto informatico

ricopre un ruolo di rilievo nei confronti dell’attivita scientifica.

L’attivita dell’INFN si basa su due tipi di strutture di ricerca complementari: le

Sezioni e i Laboratori Nazionali. Le 19 Sezioni hanno sede in dipartimenti universitari

e realizzano il collegamento diretto tra l’Istituto e le Universita. I quattro Laboratori,

con sede a Catania, Frascati, Legnaro e Gran Sasso, ospitano grandi apparecchiature e

infrastrutture messe a disposizione della comunita scientifica nazionale e internazionale.

Il personale dell’INFN conta circa 2000 dipendenti propri e quasi 2000 dipendenti

universitari coinvolti nelle attivita dell’Istituto e 1300 giovani tra laureandi, borsisti e

dottorandi.

L’attivita scientifica e suddivisa in cinque grandi branche di ricerca, riguardanti le

principali aree tematiche della fisica. Ad ognuna di queste afferisce un numero variabile

di esperimenti dislocati su tutto il territorio nazionale. Ogni esperimento e rappresentato

8

CAPITOLO 1. L’ISTITUTO NAZIONALE DI FISICA NUCLEARE 9

Figura 1.1: Acceleratore di particelle Daphne

Figura 1.2: Le strutture locali INFN

CAPITOLO 1. L’ISTITUTO NAZIONALE DI FISICA NUCLEARE 10

Figura 1.3: Personale I.N.F.N.

da persone di rilievo o esperti nel campo, che dirigono e coordinano le attivita di ricerca

svolte nelle singole sezioni, in qualita di rappresentante nazionale. Il lavoro di un singolo

esperimento puo essere portato avanti con l’appoggio di una o piu sezioni, il cui coordi-

namento e gestito da un responsabile locale. All’interno di ogni sezione e laboratorio gli

esperimenti di uno stesso gruppo (branca di ricerca) sono soggetti alla linea decisionale

imposta dal coordinatore di gruppo.

1.1.1 Organizzazione amministrativa dell’ente

L’organo decisionale dell’Istituto e il Consiglio Direttivo, costituito dal Presidente e dalla

Giunta Esecutiva, dai quattro Direttori dei Laboratori Nazionali e da 19 Direttori delle

Sezioni, da rappresentanti del MIUR, del Ministero dell’Industria, del Cnr e dell’Enea.

L’attuazione delle decisioni del Consiglio compete, secondo i casi al Presidente alla Giunta,

ai Direttori di Laboratorio o di Sezione per l’organizzazione delle attivita a livello locale,

il tutto con l’ausilio dei dirigenti dell’Amministrazione Centrale.

L’attivita di ricerca necessita di mezzi e risorse da convogliare nelle singole rappresen-

tanze locali di ogni esperimento. Il Ministero dell’Economia sostiene le spese di ricerca

con finanziamenti corrisposti all’Istituto, sulla base di preventivi presentati dai rappre-

sentanti d’esperimento e convalidati da figure di garanzia interne ed esterne all’Istituto (i

referee).

CAPITOLO 1. L’ISTITUTO NAZIONALE DI FISICA NUCLEARE 11

Figura 1.4: Organigramma INFN

CAPITOLO 1. L’ISTITUTO NAZIONALE DI FISICA NUCLEARE 12

In questo contesto si inquadra il dominio del problema: gestione coordinata e distri-

buita di dati scientifici ed economici in fase di preventivo, assegnazione e consuntivo.

Questi dati, forniti dai responsabili di esperimento in periodi prefissati, costituiscono la

base decisionale sulla quale valutare l’entita dei finanziamenti di cui ogni commissione

scientifica dispone. Le richieste di fondi sono distribuite durante l’anno durante apposite

sessioni con particolare rilievo per la sessione di luglio, in cui le commissioni scientifiche

accolgono e valutano la maggior parte delle richieste provenienti dai responsabili locali di

esperimento. Come per le richieste, le assegnazioni avvengono in diverse sessioni, anch’es-

se distribuite durante l’anno. La principale e tenuta nel mese di settembre per soddisfare

le proposte di spesa presentate a luglio per l’anno successivo e per redigere il bilancio

preventivo.

Figura 1.5: Scala temporale

1.1.2 I consuntivi scientifici

Successivamente alle fasi di richiesta ed assegnazione di fondi, gli esperimenti sono tenuti

a descrivere l’attivita svolta ed i risultati scientifici ottenuti, affinche sia possibile valutare

oggettivamente la produttivita della ricerca. In questa fase, definita di Consuntivo, i

responsabili nazionali d’esperimento stilano un rapporto di attivita, in cui descrivono i

risultati ottenuti nell’ultimo anno di ricerca e tutte le attivita connesse all’esperimento,

riguardanti pubblicazioni, tesi di laurea e conferenze.

La quantita di informazioni da gestire e notevolmente elevata, poiche l’INFN si com-

pone di 5 commissioni scientifiche a cui afferiscono un centinaio di esperimenti, attivi in

tutte le strutture locali, dislocate sull’intero territorio nazionale. Questo implica che un si-

stema di gestione informatica sia veloce, affidabile e facilmente raggiungibile da postazioni

remote.

CAPITOLO 1. L’ISTITUTO NAZIONALE DI FISICA NUCLEARE 13

1.1.3 Sistema di gestione

L’ampia diffusione del web, in questi ultimi anni, ha reso obsoleti molti sistemi proprietari

di accesso a banche dati, favorendo lo sviluppo di strutture aperte e scalabili per l’utilizzo

e la creazione di database. Si tratta di infrastrutture server a due o tre livelli, costituite da

un supporto di persistenza, (Database server) una componente applicativa ed un servizio

di presentazione (Web server). Questa base Hardware e Software costituisce, oggi il sup-

porto piu diffuso per la realizzazione di servizi ed applicazioni distribuite. In particolare,

per l’implementazione di un sistema di presa dati, per i consuntivi, si e scelto di utilizzare

una configurazione server largamente diffusa, basata su Apache, PHP e MySQL.

1.1.4 Il servizio Dataweb

Introduction E’ stato realizzato negli ultimi due anni presso il centro di Calcolo dei La-

boratori un sistema di web servers e database MySQL, finalizzato a migliorare la di-

stribuzione di informazioni scientifiche e amministrative all’interno dell’INFN. Di recente

questa attivita e evoluta in un vero e proprio servizio INFN denominato Servizio Coor-

dinamento Banche Dati Ricerca (DATAWEB). L’attivita principale di questo servizio

e’ il supporto alle commissioni scientifiche Nazionali per la realizzazione dei Preventivi,

Assegnazioni finanziarie e Consuntivi Scientifici. I dati raccolti durante queste tre fasi

principali vengono messi a disposizione in alcune sue parti sia agli uffici amministrativi

per la formazione del bilancio annuale, sia al grande pubblico specializzato e non per

quanto riguarda il contenuto scientifico. Di recente e diventato lo strumento principale

per la raccolta della documentazione al fine di redigere la documentazione per la valuta-

zione e la selezione dei prodotti dell’Istituto secondo quanto richiesto dal Ministero della

Ricerca Scientifica. In aggiunta il Servizio ha realizzato il sito per la formazione interna

INFN ed il sito per le procedure di Associazione Scientifica che coinvolge circa 3000 tra

professori,ricercatori, dottorandi e laureandi delle maggiori Universita’ Italiane. Una par-

te dell’attivita’ e’ dedicata anche alla raccolta della documentazione multimediale per la

realizzazione di database di immagini e video realizzati all’interno delle strutture INFN

che verranno usati per il sito dell’INFN dedicato al grande pubblico. Nel prossimo futuro

il sistema verra’ messo in comunicazione con il nuovo sistema informativo Centralizzato

della Oracle-Bull per una maggiore efficenza di scambio tra le informazioni scientifiche e

quelle amministrative.

CAPITOLO 1. L’ISTITUTO NAZIONALE DI FISICA NUCLEARE 14

1.1.5 Soluzioni precedenti

Il lavoro di tesi e stato inquadrato all’interno di un’attivita di reingegnerizzazione, volta

alla scrittura di un’applicazione ottimizzata per la presa dati e la consultazione. Lo scopo

finale che ci e prefissati, e quello di ottenere un prodotto simile all’applicazione in uso,

fino al 2003, ma radicalmente diverso dal punto di vista implementativo e di database,

soprattutto per la strutturazione dei dati inseriti. Il vecchio sistema, gia basato su un’in-

frastruttura web, aveva diverse mancanze e non permetteva di soddisfare molti requisiti

di usabilita (interfaccia) e di accesso ai dati, a causa di un database non strutturato con

criteri relazionali.

Capitolo 2

L’interfaccia

L’applicazione si compone di un numero di pagine web dinamiche, scritte in linguaggio

server-side, interfacciate ad un database relazionale per il salvataggio delle informazioni

inserite. Le funzionalita di presa dati e sommarizzazione sono suddivise fra i vari script

PHP, raggiungibili da un menu di navigazione sempre visibile sulla sinistra del browser.

La home page dell’applicazione e raggiungibile all’indirizzo web

http://www.infn.it/consuntivi/2004

da qualsiasi browser in grado di supportare javascript e la navigazione a frame. Questo

comporta la necessita di utilizzare client recenti poiche la componente di navigazione e

validazione dei dati inseriti fa uso di scripting client-side (javascript) per funzionalita di

controllo e gestione altrimenti non fruibili utilizzando il solo HTML.

2.1 Autenticazione

Ogni pagina presente nel subtree dell’applicazione viene servita dopo un processo di au-

tenticazione cui l’utente viene sottoposto al momento dell’accesso. Questo serve, innanzi

tutto, per vistare la consultazione e l’inserimento a persone estranee all’Istituto, ma anche

per differenziare l’offerta di funzionalita a seconda dell’utente che si autentica

La figura 2.1 mostra la finestra di dialogo aperta dal browser all’atto dell’accesso. Sono

previste diverse classi di utenti con privilegi di lettura e/o scrittura su singole porzioni di

dati o sulla totalita degli stessi:

• Amministratore: privilegi globali di lettura e scrittura;

15

CAPITOLO 2. L’INTERFACCIA 16

Figura 2.1: Accesso al sito

• Presidente di commissione: privilegi di scrittura sui dati riguardanti la propria

commissione e privilegi globali di lettura;

• Responsabile d’esperimento: privilegi di scrittura sui dati relativi al proprio esperi-

mento e privilegi globali di lettura;

• Visitatore: privilegi globali di lettura;

• CVI - International Evaluation Committee: privilegi di lettura, con viste par-

ticolareggiate sui dati, per la valutazione della ricerca ad opera di un comitato

internazionale

• CIVR - Comitato Italiano di Valutazione: privilegi di lettura, con viste parti-

colareggiate sui dati, per la valutazione della ricerca od opera di un comitato

italiano.

2.2 Home Page

Una volta autenticato, l’utente accede alla pagina principale. Questa e suddivisa in due

frame verticali, per ospitare il menu e la pagina web relativa alla sezione che si sta con-

sultando. Questa scelta permette di mantenere sempre in vista il menu rendendo la

navigazione fra le varie sezioni piu semplice ed immediata.

La figura 2.2 mostra la disposizione dell’area di lavoro, comune a tutti gli utenti

autenticati, con una pagina di benvenuto che presenta l’applicazione fornendo cenni e

suggerimenti sull’accesso e l’uso.

CAPITOLO 2. L’INTERFACCIA 17

Figura 2.2: Home Page

CAPITOLO 2. L’INTERFACCIA 18

2.3 Il menu

L’area di sinistra della schermata ospita il menu di navigazione che, esploso su tre livelli,

permette ai presidenti di commissione, ai responsabili ed ai visitatori di indirizzare la

propria navigazione attraverso la scelta della commissione, dell’esperimento e quindi della

funzionalita richiesta.

Si nota la prima differenziazione fra i link proposti che indirizzano la navigazione verso

una delle 5 commissioni scientifiche nazionali di cui si compone l’I.N.F.N. Ad ognuna di

queste afferiscono diversi esperimenti, in atto presso le sedi locali dell’istituto, dislocate

sul territorio nazionale

Il primo sottomenu si suddivide in 4 sezioni, visibili e fruibili a seconda dei privilegi

d’accesso posseduti dall’utente autenticato:

• Sommari : e una lista di report che riassumono la situazione globale della commis-

sione, riportando i dati inseriti da tutti i responsabili d’esperimento, differenziati

per voce.

• Modifica dati : mostra un prospetto, simile al precedente, mediante il quale gli utenti

con privilegi di scrittura (in questo caso solamente i Presidenti di commissione)

possono fare modifiche su tutte le voci compilate dai responsabili d’esperimento

• Esperimenti : ogni esperimento afferente alla commissione ha una propria pagina di

inserimento dati accessibile in scrittura al solo Responsabile

• Common Activities : permette di accedere alla maschera di compilazione per le voci

d’attivita comuni a collaborazioni fra due o piu esperimenti.

2.3.1 Esperimenti

Poiche la prima e la seconda categoria di link offrono una visione globale delle informa-

zioni inserite, mostreremo prima in dettaglio le operazioni di inserimento per i singoli

esperimenti.

Il terzo livello del menu elenca le funzioni messe a disposizione dei Responsabili

d’esperimento per quanto riguarda:

• Brief report : Rapporto annuale sull’attivita di ricerca portata avanti dall’esperi-

mento nell’anno 2004.

• Publications : Lista delle pubblicazioni afferenti all’esperimento presentate nell’anno

2004.

CAPITOLO 2. L’INTERFACCIA 19

Figura 2.3: Terzo livello del menu: esperimenti

CAPITOLO 2. L’INTERFACCIA 20

• Talks : Lista delle conferenze afferenti all’esperimento tenute nell’anno 2004.

• Thesis : Lista delle tesi di laurea sviluppate nell’ambito dell’esperimento nell’anno

2004.

• Summary : Breve descrizione dell’esperimento (in lingua inglese), logo e collegamenti

al sito ufficiale

• Short Descr.: Breve descrizione dell’esperimento in lingua italiana

2.3.2 Common Activities

Il sottomenu relativo alle Common Activities include funzionalita simili applicate alle

collaborazioni fra due o piu esperimenti della stessa commissione scientifica

A differenza del precedente sottomenu, questo non include alcun tipo di descrizione

poiche le operazioni comuni a piu esperimenti riguardano esclusivamente pubblicazioni,

conferenze, tesi e collaborazioni con personale di altri istituti.

2.3.3 Sommari

Il sottomenu che segue presenta una serie di link a report, suddivisi per voce, che presen-

tano la situazione globale dei dati inseriti riguardo gli esperimenti della commissione.

La figura 2.5 mostra come il terzo livello del menu sia visibilmente piu consistente

rispetto allo stesso menu degli esperimenti o delle Common Activities. Molte voci presenti

all’interno di questo menu riguardano dati presenti del Brief report ampiamente descritta

nel capitolo seguente. I link permettono di raggiungere i seguenti sommari:

• Research Proj.: Resoconto dell’attivita di ricerca portata avanti della commissione

• Responsibles : Elenco dei responsabili d’esperimento

• Collaborations : Elenco delle collaborazioni avute con personale esterno o altre

istituzioni

• Exp. Location: Luoghi di svolgimento dei singoli esperimenti

• Goals : Risultati raggiunti dagli esperimenti

• Activity 2004 : Resoconto dell’attivita svolta dai singoli esperimenti

• INFN Contr.: Contributi in denaro corrisposti dall’Istituto per le attivita di ricerca

CAPITOLO 2. L’INTERFACCIA 21

Figura 2.4: Terzo livello del menu: common activities

CAPITOLO 2. L’INTERFACCIA 22

Figura 2.5: Terzo livello del menu: sommari in lettura

CAPITOLO 2. L’INTERFACCIA 23

• FTE count : Ricercatori Full Time Equivalent suddivisi per linea di ricerca

• Budget count : Percentuali di bilancio assegnate alle linee di ricerca

• Milestones 2004 : Risultati raggiunti dagli esperimenti nell’anno di consuntivo con

percentuale di successo

• Milestones 2005 : Risultati previsti dagli esperimenti per l’anno in corso

• Milestones average: Percentuali medie di raggiungimento delle milestone suddivise

per esperimento

• Milestones count : Conteggio delle milestone

• Leadership: Elenco dei ruoli di leadership

• Innovat.Instr.: Strumenti innovativi utilizzati dagli esperimenti per lo sviluppo di

apparecchiature

• Compet.Exper.: Esperimenti che competono sullo stesso obiettivo di ricerca

• Int. Committee: Comitato internazionale che ha il compito di supervisionare l’atti-

vita di ricerca dell’esperimento

• Publications : Pubblicazioni su riviste scientifiche uscite nell’anno di consuntivo

• Publications count : Conteggio delle pubblicazioni suddivise per linea di ricerca

• Publ. IF : Riviste scientifiche con relativo Impact Factor

• Publ. average: Conteggio e medie sugli autori delle pubblicazioni

• Tassonomia 1 : Classificazione delle ricadute della Attivita di Ricerca

• Tassonomia 2 : Ricadute della Attivita di ricerca verso altri esperimenti INFN

• Talks : Lista delle conferenze tenute nell’anno di consuntivo dagli esperimenti

• Talks count : Conteggio delle conferenze suddivise per linea di ricerca

• Thesis : Lista delle tesi discusse nell’anno di consuntivo dagli esperimenti

• Thesis count : Conteggio delle tesi suddivise per linea di ricerca

• Ages and durations : Durata degli esperimenti

CAPITOLO 2. L’INTERFACCIA 24

Figura 2.6: Terzo livello del menu: sommari in modifica

• Internationalization: Grado di internazionalizzazione

• Spin-off : Realta industriali di ricerca, in altre discipline e per l’INFN nelle quali il

sotto-prodotto puo essere utilizzato

• Fall-out : Classificazione delle ricadute della Attivita di Ricerca

2.3.4 Modifica dati

Alcune delle voci mostrate nel precedente sottomenu possono essere modificabili (per

l’accesso come Presidente di commissione o Amministratore) seguendo i link alla voce

Modifica Dati.

CAPITOLO 2. L’INTERFACCIA 25

2.4 Funzionalita offerte

Come descritto nel paragrafo precedente, le operazioni di inserimento dati, elencate nei

sottomenu, richiamano pagine web visualizzate nel frame di destra. Di seguito saranno

discusse in dettaglio le funzionalita offerte da ognuna di esse, seguendo l’ordine proposto

dal sottomenu relativo agli esperimenti.

2.4.1 Brief report

Il Brief report e un rapporto annuale compilato dal responsabile d’esperimento, riguardo

le attivita connesse alla ricerca, nell’ambito del campo di studi in cui opera l’esperimento.

La schermata e suddivisa in tre regioni:

• Intestazione: logo e nome dell’esperimento

• Area di validazione: le informazioni inserite di seguito necessitano della validazione

ad opera del presidente di commissione. E’ qui riportata la data e l’ora in cui e stato

validato l’intero consuntivo. Eventuali modifiche successive a tale data saranno

considerate non affidabili.

• Area di inserimento: qui si trovano le maschere di inserimento accessibili diretta-

mente o tramite link ad altre pagine

2.4.2 Inserimento dei dati

Le classi di utente con privilegi di scrittura sono in grado di modificare le informazioni

inserite nel Brief report agendo sui diversi punti di cui il rapporto si compone:

• Collaborations : collaborazioni con enti o istituti esteri, personale esterno o altre

sezioni I.N.F.N.

• Experiment Location: Luogo di svolgimento dell’esperimento (ed eventuale accele-

ratore utilizzato)

• Status : stato dell’esperimento

• First year of experiment financing : anno di inizio attivita e primo finanziamento da

parte dell’I.N.F.N.

• Experiment duration (years): durata prevista dell’esperimento

• National INFN Responsible: responsabile nazionale dell’esperimento

CAPITOLO 2. L’INTERFACCIA 26

Figura 2.7: Brief report

CAPITOLO 2. L’INTERFACCIA 27

• Goal of the Experiment : obiettivi finali che l’esperimento si propone di raggiungere

• More on the Experiment : Logo, descrizione e collegamento al sito ufficiale dell’espe-

rimento

• Physics activities during 2004 : descrizione dell’attivita svolta nell’anno di consun-

tivo

• Milestones 2004 and Level of Completion(%): milestone raggiunte nell’anno di

consuntivo con livello di completamento espresso in percentuale

• Milestones 2005 : milestone concordate per l’anno in corso

• INFN contribution to the experiment in terms of manpower and financial support :

contributo finanziario e di manodopera, corrisposto dall’I.N.F.N. per supportare le

attivita di ricerca

• Publication in refereed journals : numero di pubblicazioni edite nell’anno di consun-

tivo

• Conference talks : numero di conferenze tenute nell’anno di consuntivo

• Number of undergraduate and doctoral thesis on the experiment : numero di tesi

discusse nell’anno di consuntivo

• Leadership role in the experiment : ruoli di dirigenza dell’organico afferente all’espe-

rimento

• Innovative instruments : tecnologie innovative connesse al campo di studi dell’espe-

rimento

• Competing experiments : Esperimenti che competono nello stesso obiettivo di ricerca

• International committee which has reviewed the experiment : comitato internazionale

che ha il compito di supervisionare l’attivita di ricerca dell’esperimento.

• Internationalization: grado di internazionalizzazione dell’esperimento in termini di

collaborazioni con istituzioni estere

• Spin-off : Realta industriali di ricerca, in altre discipline e per l’I.N.F.N. nelle quali

il sotto-prodotto puo essere utilizzato

• Fall-out : Classificazione del tipo di sotto-prodotto che puo essere utilizzato nelle

diverse attivita (industria, INFN, altre discipline)

CAPITOLO 2. L’INTERFACCIA 28

Gran parte di queste informazioni sono accessibili direttamente dalla pagina principale

del Brief report, in cui e presente una maschera di inserimento o consultazione. Questi dati

possono essere inseriti, inviati e quindi validati. Per quanto riguarda le Collaborazioni, le

Milestone, le Leadership, il Grado di Internazionalizzazione, lo Spin-Off ed il Fall-out, il

discorso cambia, poiche si tratta di informazioni strutturate, piu complesse di una semplice

area di testo, che richiedono maschere di inserimento a parte, residenti su diverse pagine

web.

2.4.3 Collaborations

Il primo link presente nel Brief report rimanda alla pagina di inserimento delle collabora-

zioni con istituti o personale esterno all’I.N.F.N. Questa pagina e suddivisa in tre zone,

intestazione, area di consultazione e modifica, area di inserimento.

Per ogni record e necessario descrivere l’istituto, l’ente od il ricercatore con cui il

personale dell’esperimento ha collaborato. Qualora l’ente differisca da una delle sezioni

I.N.F.N, occorre definire la nazione in cui tale istituto opera, corredando infine il record

di eventuali note.

2.4.4 More on the experiment

Il secondo link raggiungibile del Brief report conduce alla maschera di inserimento mo-

strata in figura.

Questa pagina permette di inserire informazioni che descrivono l’esperimento senza

entrare nel dettaglio dell’attivita scientifica svolta. Qui il responsabile e in grado di

inserire una breve descrizione in lingua inglese, la URL al sito ufficiale dell’esperimento

ed il logo, utilizzato nelle pagine di questa applicazione. Sempre da questa pagina, e

possibile validare le informazioni inserite, senza bisogno di tornare al Brief report.

2.4.5 Milestones 2004 and Level of Completion(%)

I contributi finanziari che l’I.N.F.N. corrisponde, sono spesso subordinati al raggiungi-

mento di obiettivi parziali che i responsabili d’esperimento si propongono di raggiungere

entro date stabilite in fase di preventivo. Questi obiettivi, definiti milestone, costituiscono

una serie di tappe intermedie, attraverso le quali gli esperimenti perseguono gli obiettivi

proposti. Ognuna di queste milestone e costituita da una breve descrizione del risultato

previsto, una data di massima, entro cui tale risultato viene raggiunto, ed un livello di

successo, espresso in percentuale, concordato in fase di formazione del bilancio.

CAPITOLO 2. L’INTERFACCIA 29

Figura 2.8: Collaborations

CAPITOLO 2. L’INTERFACCIA 30

Figura 2.9: More on the experiment

CAPITOLO 2. L’INTERFACCIA 31

Figura 2.10: Milestone 2004

CAPITOLO 2. L’INTERFACCIA 32

La maschera di inserimento proposta in questa pagina e strutturata in maniera simile

alla pagina relativa alle collaborazioni, suddivisa anch’essa in tre regioni: intestazione,

area di consultazione e modifica, area di inserimento.

2.4.6 Milestones 2005

Questa maschera di inserimento e simile alla precedente, sia come struttura che come

tipologia di dati inseribili. L’unica differenza sta nel fatto che le milestone inserite qui

si riferiscono all’anno in corso e descrivono obiettivi non ancora raggiunti o per cui non

e possibile esprimere una percentuale di raggiungimento (se non come stima). Queste

milestone andranno ad integrare quelle inserite in fase di preventivo per la formazione del

bilancio 2006.

2.4.7 Leadership

Questa pagina permette di aggiungere o modificare nominativi di ricercatori che ricoprono

ruoli di responsabilita nell’esperimento. Le informazioni di cui ogni record si compone

sono il nome, la qualifica ed il settore di competenza. La struttura di questa maschera e

simile alle precedenti, con un’intestazione standard, un’area di visualizzazione e modifica

ed un’area di inserimento, a cui si aggiunge una quarta regione in cui e possibile esprimere

il numero di ruoli inseriti rispetto all’organico di cui dispone l’esperimento.

2.4.8 Internationalization

Il grado di internazionalizzazione, descrive l’impegno finanziario e scientifico dell’I.N.F.N.

per l’esperimento, in collaborazioni internazionali a cui partecipano altri istituti di ricerca.

L’area di inserimento, modifica e consultazione e posta sotto l’intestazione, rispettando

la struttura analoga alle altre pagine. Le informazioni inserite riguardano il numero di

ricercatori coinvolti e di pubblicazioni edite in collaborazioni estere, oltre alla percentuale

di spesa corrisposta dall’I.N.F.N per sostenerle.

2.4.9 Spin-off

Da questa maschera, i responsabili, sono in grado di esprimere considerazioni sull’utilizzo

di tecnologie o teorie, sviluppate nell’ambito dell’esperimento, all’esterno dell’istituto, ad

esempio in realta industriali o medicali, o in altri esperimenti.

L’area di inserimento e costituita da tre campi di testo riguardanti

• Risultati applicabili ad altri esperimenti

CAPITOLO 2. L’INTERFACCIA 33

Figura 2.11: Milestone 2005

CAPITOLO 2. L’INTERFACCIA 34

Figura 2.12: Leadership

CAPITOLO 2. L’INTERFACCIA 35

Figura 2.13: Internationalization

CAPITOLO 2. L’INTERFACCIA 36

Figura 2.14: Spin-off

CAPITOLO 2. L’INTERFACCIA 37

• Risultati applicabili ad altre discipline

• Impatto sulla realta industriale e della ricerca

2.4.10 Fall-out

Gli obiettivi proposti da ogni esperimento possono avere ricadute nell’ambito della ricerca,

di realta industriali, medicali o riguardanti discipline a cui possono essere applicati. In

questa pagina, il responsabile puo specificare in dettaglio quali esperimenti I.N.F.N. o

quali realta esterne all’istituto potranno beneficiare dei risultati conseguiti, esprimendo

stime di applicabilita o giudizi sullo stato attuale di tali ricadute.

L’area di inserimento, consultazione e modifica, e suddivisa in quattro regioni, dove il

responsabile puo specificare:

• Il campo in cui avranno effetto le ricadute

• Le tecnologie ed i prodotti che ne possono derivare

• Risultati applicabili ad altre discipline

• Ricadute verso realta industriali specificandone il genere e lo stato dell’applicazione

in tale campo

• Attivita di ricerca interdisciplinare per altre applicazioni

CAPITOLO 2. L’INTERFACCIA 38

Figura 2.15: Fall-out

Capitolo 3

Analisi ed Implementazione

3.1 Requisiti

L’attivita di sviluppo e stata preceduta da un periodo di raccolta requisiti, formalizzati

in un Preliminary draft riportato in appendice. Queste informazioni sono fondamentali

per la progettazione dell’interfaccia d’uso e del database, definendo tipologie di dati per

le diverse maschere di inserimento.

3.2 Analisi degli User Requirements

3.2.1 Struttura delle precedenti schede di Consuntivo

Le informazioni scientifiche di consuntivo compilate fino al 2003, disponibili sul sito uf-

ficiale dei consuntivi INFN (http://www.infn.it/consuntivi/) sono suddivise in 6 schede

principali: 1) Scheda Brief Activity Report, 2) Scheda Publications, 3) Scheda Conference

Talks, 4) Scheda Thesis, 5) Scheda Summary, 6) Scheda Breve Descrizione (in italiano).

La scheda Activity Report e composta dai seguenti punti:

• Collaboration - campo testo (non strutturato)

• Experiment Location - campo testo (non strutturato)

• Status - campo strutturato a selezione unica - Construction -

• Upgrading - Data Taking - Data Analysis

• National INFN Responsible - campo testo (non strutturato)

39

CAPITOLO 3. ANALISI ED IMPLEMENTAZIONE 40

• Goal of the Experiment - campo testo (non strutturato

• More on the Experiment - Web link alla URL contenente la

• Scheda Summary on the experiment contenente

- Home Page URL - campo testo (non strutturato)

- logo URL - campo testo (non strutturato)

- Summary on the Experiment - campo testo (non strutturato)

- Additional Information on the Experiment URLs - campo testo (non strutturato)

• Physics activities during 2003 - campo testo (non strutturato)

• Milestones 2003 and Level of Completion(%) - campo testo (non strutturato)

• Milestones 2004 - campo testo (non strutturato)

• General Planning for 2005 - campo testo (non strutturato)

• INFN contribution to the experiment in terms of manpower and financial support -

campo testo (non strutturato)

• Publication in refereed journals - campo testo (non strutturato)

• Conference talks - campo testo (non strutturato)

• Number of undergraduate and doctoral thesis on the experiment - campo testo (non

strutturato)

• Leadership role in the experiment - campo testo (non strutturato)

• Innovative instruments - campo testo (non strutturato)

• Competing experiments - campo testo (non strutturato)

• International committee which has reviewed the experiment - campo testo (non

strutturato)

• Scheda Publications Publications 2003 - unico campo testo (non strutturato)

• Scheda Conference Talks Conference Talks 2003 - unico campo testo (non struttu-

rato)

• Scheda Thesis Thesis 2003 - unico campo testo (non strutturato)

CAPITOLO 3. ANALISI ED IMPLEMENTAZIONE 41

• Scheda Summary on the experiment (cfr punto More on the Experiment sopra, nella

scheda Activity Report)

• Scheda Breve Descrizione (in italiano) Breve Descrizione dell’Esperimento - unico

campo testo (non strutturato)

L’assenza di struttura di alcune di queste informazioni nel database rende impossibile

l’estrazione automatica e la ricerca per chiavi delle informazioni memorizzate. Ne con-

segue una impossibilita di utilizzo di tali dati per qualsiasi fine statistico. In base allo

studio delle caratteristiche dei dati richiesti dalle valutazioni annuali e triennali, sorge

la necessita di stabilire una struttura, attraverso lo studio degli user requirements per

quei dati fondamentali e loro attributi, dai quali dovranno essere estratte informazioni

esatte in modo automatico mediante semplici query al Database. Per alcune di queste

informazioni non sara necessario procedere ad una analisi dettagliata e potranno essere

non strutturate.

3.2.2 Nuove schede di Consuntivo: struttura proposta

Verranno quindi, di seguito, analizzate solo le informazioni per le quali dovremo stabilire

una struttura . I punti contenuti nelle schede descritte rimarranno invariati, salvo l’ag-

giunta di alcuni campi che sono necessari per la valutazione scientifica a consuntivo di

alcune commissioni scientifiche. I campi da analizzare sono quindi i seguenti:

• 1. Publications

• 2. Conference Talks

• 3. Thesis (Laurea e Dottorato)

• 4. Scheda Activity Report :

- Milestones 2004 (effettive)

- Milestones 2005 (concordate)

- Collaborations

- Leadership role

- INFN contribution to the experiment in terms of manpower and financial support

Campi da aggiungere in questa scheda :

• Grado di Internazionalizzazione

CAPITOLO 3. ANALISI ED IMPLEMENTAZIONE 42

I campi seguenti (da aggiungere nella scheda) sono stati richiesti dalla csn5 e saranno

opzionali per le altre commissioni:

• Durata dell’esperimento

• Anni di vita dell’esperimento (0 se nuovo)

• Dati Spin-off :

- Results of special relevance for other INFN experiments

- Results of special relevance for other scientific disciplines

- Impact for applied research and industrial applications

• Dati Ricadute:

- Classificazione delle ricadute dell’Attivita di Ricerca (campo o prodotto)

- Ricadute dell’attivita di Ricerca (verso altri esperimenti, discipline, realta indu-

striali)

- Attivita di ricerca interdisciplinare esplicitamente finalizzata verso applicazioni

3.2.3 Modalita di accesso utenti

A differenza delle altre commissioni, la csn4 ha una diversa procedura per la compilazione

dei consuntivi. Questa viene fatta a cura dei coordinatori delle varie sezioni. Per consentire

cio e necessario diffenziare la modalita di accesso degli utenti del gruppo teorico rispetto

a quelle delle altre commissioni scientifiche. In particolare per la csn4 saranno definiti gli

accessi per struttura (Coordinatori) mentre per gli altri saranno definiti gli accessi per

esperimento (RN).

3.2.4 Produttivita scientifica comune a piu esperimenti / inizia-

tive scientifiche

Per alcune commissioni scientifiche (3, 4, 5) l’attribuzione esatta di alcuni lavori, come ad

es. le pubblicazioni, e impossibile. Vi sono infatti lavori che sono a cavallo di piu Inizia-

tive Specifiche od Esperimenti. E’ necessario quindi definire una sigla fittizia ’Common

Activity’ all’interno di una commissione, dove potranno essere inseriti i lavori che non

appartengono ad un unico esperimento/IS.

3.2.5 Milestone

Milestones effettive 2004. La compilazione deve essere effettuata in base allo stato di

raggiungimento effettivo delle milestones al 31 dicembre 2004. I dati iniziali nelle schede

CAPITOLO 3. ANALISI ED IMPLEMENTAZIONE 43

sono importati in automatico dal sistema dal database delle assegnazioni per il bilancio

2004. Per alcune commissioni scientifiche, i dati relativi alla percentuale effettivamente

raggiunta, dichiarata dal referee, per le milestones con data posteriore a quella della

riunione di settembre 2004, sono mancanti. I dati definitivi, per alcune commissioni, sono

contenuti nelle schede esperimento disponibili sul sito Web della commissione.

• Nome Esperimento: viene identificato automaticamente dall’applicazione Web al

momento dello user login

• Data: giorno, mese (anno automatico) concordato con il referee dell’esperimento

relativo al raggiungimento effettivo della milestone.

• Descrizione: dettaglio descrittivo della milestone compilato a cura del responsabile

nazionale.

• Percentuale raggiungimento: validata dal referee dell’esperimento a consuntivo,

dopo la chiusura del bilancio 2004.

Milestones concordate 2005. Sono state inserite nel database delle assegnazioni duran-

te le riunioni di settembre 2004 per il bilancio 2005. La compilazione iniziale nel database

e completamente automatica per gli esperimenti che hanno inserito i dati. Sono da com-

pilare invece dove i dati sono mancanti o incompleti. Anche per i dati importati in modo

automatico sara comunque necessario l’aggiornamento della situazione a consuntivo

• Nome Esperimento: viene identificato automaticamente dall’applicazione Web al

momento dello user login

• Data: giorno, mese (anno automatico) concordata dal responsabile di esperimento

con il referee per il raggiungimento della milestone nel 2005.

• Descrizione: dettaglio descrittivo della milestone 2005, concordata con il referee

dell’esperimento, compilato a cura del responsabile nazionale.

3.2.6 Leadership

La codifica completa dei ruoli di leadership risulta piuttosto complessa. Sono stati

suddivisi in 2 macro categorie, indicando, in quella di sola gestione, i principali.

• Nome Esperimento: viene identificato automaticamente dall’applicazione Web al

momento dello user login

CAPITOLO 3. ANALISI ED IMPLEMENTAZIONE 44

• Nome: Cognome e nome della persona che ricopre un ruolo di responsabilita rico-

perto nell’esperimento

• Tipo Ruolo: tipologia del ruolo di responsabilita ricoperto nell’esperimento, a scelta

tra:

- Ruolo di gestione

- Ruolo scientifico o equivalente

per il ruolo di gestione e possibile scegliere da una lista precompilata:

1. Spokesperson

2. Co-spokesperson

3. Project-Leader

4. Detector-Leader

5. Altro

Per i campi 4) 5) si attivera un ulteriore campo di inserimento di testo dove potra

essere inserito il nome del Detector o il dettaglio della tipologia del ruolo. Per il

ruolo scientifico o equivalente sara possibile inserire in un ulteriore campo di testo

la descrizione del ruolo ricoperto.

Sara inoltre necessario specificare anche il numero totale di ruoli di responsabilita

ricoperti nell’esperimento.

• N.Ruoli italiani : indica il numero totale di ruoli di responsabilita italiani/INFN

ricoperti nell’esperimento.

• N. Ruoli disponibili : numero totale di ruoli di responsabilita disponibili nell’esperi-

mento.

3.2.7 Grado di Internazionalizzazione

Nome Esperimento/IS : viene identificato automaticamente dall’applicazione Web al mo-

mento dello user login

• Impegno Finanziario: espresso in percentuale, indica la frazione d’impegno finan-

ziario INFN rispetto all’impegno totale della Collaborazione.

• N. totale Ricercatori : numero totale di ricercatori nella Collaborazione.

• N.firm.Ricercatori : numero di ricercatori che si firmano (anche) INFN nella Colla-

borazione.

CAPITOLO 3. ANALISI ED IMPLEMENTAZIONE 45

• N.Rubbl.Inter.: numero di pubblicazioni in Collaborazioni Internazionali.

• N.totale Pubbl.: numero totale di pubblicazioni.

3.2.8 Spin-off

La struttura per i dati sulla produttivita e mutuata da quella adottata per la CSNV

• Nome Esperimento: viene identificato automaticamente dall’applicazione Web al

momento dello user login

• Results of special relevance for other INFN experiments : campo di testo contente

la descrizione.

• Results of special relevance for other scientific disciplines : campo di testo contente

la descrizione.

• Impact for applied research and industrial applications : campo di testo contente la

descrizione.

3.2.9 Produttivita: Ricadute

La struttura per i dati sulla produttivita e mutuata da quella adottata per la CSNV

• Nome Esperimento: viene identificato automaticamente dall’applicazione Web al

momento dello user login

• Classificazione delle ricadute della Attivita di Ricerca:

- nel campo

- nuovo prodotto

in entrambi i casi deve essere selezionata la tipologia di campo o di caratteristica

del nuovo prodotto da una lista precompilata.

• Ricadute della Attivita di ricerca: viene indicato verso quali altri campi o esperimenti

avviene la ricaduta, - altri esperimenti INFN

- altre discpline

- realta industriali

Inoltre deve essere specificato se tale ricaduta e

- in atto

- in via di definizione

- potenziale

CAPITOLO 3. ANALISI ED IMPLEMENTAZIONE 46

- nessuna nei primi 2 casi e possibile specificare in campi di testo il nome del utente

target (esperimento, ente, ditta etc.)

• Attivita di ricerca interdisciplinare esplicitamente finalizzata verso applicazioni : in-

dicazione del campo specifico di applicazione da selezionare in una lista suddivisa

per macro categorie (mediche, beni culturali,industriali).

3.2.10 Collaborazione

La struttura per i dati sulla collaborazione e in parte mutuata da quella adottata per la

CSNIV.

• Nome Esperimento: viene identificato automaticamente dall’applicazione Web al

momento dello user login

• Istitituto/Collaboratore: nome dell’istituto(ricercatore) o laboratorio che collabora

con l’esperimento/IS. Nel caso di struttura o laboratorio INFN il nome potra essere

selezionato da una lista precompilata.

• Nazione: nazione estera dell’istituto(ricercatore) che collabora con l’esperimento/IS.

Non deve essere specificato se l’istituto o laboratorio e in Italia.

• Note: campo di testo contente una eventuale descrizione (opzionale).

3.3 Caso d’uso

L’attore di riferimento e il Responsabile nazionale d’esperimento, il quale accede ad un’in-

terfaccia di presa dati distribuita fisicamente su piu pagine web. Questo affinche sia pos-

sibile gestire, separatamente, informazioni di natura eterogenea che, pur essendo legate

strettamente fra di esse, devono essere consultabili separatamente. Il diagramma che se-

gue, mostra come l’interfaccia del report di attivita rimandi alle altre interfacce per la

consultazione e l’inserimento, secondo la gerarchia proposta in fase di analisi e mostrata

nel capitolo precedente:

3.4 Struttura degli script

Ogni pagina web, di cui si compone l’applicazione, e strutturata in maniera modulare,

permettendo di dividere su piu file le diverse funzionalita di cui fa uso ed evitando di

scrivere piu volte parti di codice comuni a piu script.

CAPITOLO 3. ANALISI ED IMPLEMENTAZIONE 47

Figura 3.1: Use case diagram

In particolare, le impostazioni relative alla connessione al DBMS, le tavole hash, la

traduzione dei parametri passati fra le pagine e le funzioni sono contenuti dentro file a

parte, inclusi al momento dell’avvio dello script.

Le pagine che si occupano di presa dati, poi, includono all’inizio ed alla fine, rispetti-

vamente un’intestazione ed un pie di pagina comuni a tutte le pagine dell’applicazione

I file di configurazione sono richiamati dal file

config.inc.php

in maniera da evitare inclusioni multiple all’interno di uno stesso file e rendere piu semplice

la costruzione di un modello (template) su cui basare tutte le pagine del sito:

<?

# includo il file di configurazione per

# la connessione al database, le tavole hash

# e le variabili di ambiente

include ("include/config.inc.php");

# includo il file delle funzioni di libreria

CAPITOLO 3. ANALISI ED IMPLEMENTAZIONE 48

include ("include/functions.inc.php");

# inizializzazione delle variabili

include ("include/init.inc.php");

?>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

<title></title>

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

</head>

<body>

<? include ("include/header.inc.php"); ?>

<? include ("include/footer.inc.php"); ?>

</body>

</html>

Questa versione base non prevede l’inclusione di un foglio di stile (CSS ) ne della

libreria di funzioni javascript utilizzate per applicazioni di HTML dinamico (DHTML).

L’esecuzione di una pagina, strutturata in questo modo, e a totale carico del webserver

che ne esegue il parsing, genera un output HTML e lo invia al browser, che lo mostra

senza eseguire linee di codice. La gran parte degli script rispecchia questo modello, poiche

non richiede elaborazioni client-side (controlli eseguiti dal browser dopo la ricezione della

pagina) ne effetti DHTML, come invece accade per la pagina del menu e per alcune

maschere.

In questo caso occorre includere un file di testo con le funzioni javascript da attivare

all’avvio della pagina o in presenza di particolari eventi, come la pressione di un pulsante.

L’inclusione avviene mediante l’inserimento di un TAG di scripting nella sezione HEAD

della pagina

<head>

<title></title>

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

CAPITOLO 3. ANALISI ED IMPLEMENTAZIONE 49

<script src="include/functions.js" language="javascript" type="text/javascript">

</script>

</head>

3.5 Funzioni utilizzate

Le funzioni per il trattamento dei dati inseriti o caricati dal database sono, come gia detto,

raccolte e centralizzate all’interno di un unico file, costituendo una libreria raggiungibile

da ogni script con una semplice inclusione. Questo avvantaggia la scrittura del codice

da molti punti di vista, non solo della semplicita. In particolare, se una stessa funzione

fosse utilizzata da tanti script e necessitasse di una modifica, questo implicherebbe la

riscrittura di tutti i file in cui e contenuta, causando un’inutile dispendio di forze, a fronte

di un piccolo overhead a carico del webserver, per l’inclusione di un file esterno.

Sono state sviluppate delle funzioni di presa dati dal db, che si occupano di costruire le

query di selezione ritornando al programma chiamante le sole informazioni di cui necessita

la pagina. Questa sorta di middleware fra il database driver e la componente di presenta-

zione supplisce alla mancanza di un application server per l’elaborazione e, soprattutto,

l’interfacciamento al database. Pur non utilizzando un linguaggio ad oggetti, si e cercato

di orientare la gestione delle interazioni con il db facendo largo uso di funzioni Get e Set,

come se i result-set del database fossero degli attributi privati cui non e possibile accedere

direttamente. Un sistema a livelli di questo tipo e vantaggioso e scalabile, ma soprattutto

molto versatile, poiche un eventuale cambiamento del database driver non implicherebbe

alcuna modifica al presentation layer, ma solo alla componente di connessione e presa

dati.

3.5.1 Presa dati

La funzione di tipo Get e costituita da una segnatura a singolo parametro formale, poiche

tutte le informazioni per costruire la query sono strutturate all’interno di una tavola hash

strutturata come segue:

$params = array("tablename" => "",

"dbname" => "",

"link_id" => "",

"expname" => "",

"gid" => "",

"sez" => "",

CAPITOLO 3. ANALISI ED IMPLEMENTAZIONE 50

"ip" => "",

"remote_user" => "");

• tablename: il nome della tabella su cui agira la query

• dbname: il nome del database

• link id : l’id della connessione al DBMS server

• expname: l’esperimento

• gid : la commissione scientifica (o gruppo)

• sez : la struttura I.N.F.N.

• ip: l’indirizzo ip del computer client

• remote user : l’utente autenticato via HTTP

Per mostrare un esempio, riportiamo la funzione di presa dati utilizzata dalla pagina

per le informazioni relative allo spin-off:

function getSpinoff($params) {

# query di default che interroga solo sulla base del gruppo

$query =

"SELECT *

FROM ".$params["tablename"]."

WHERE gid=’".addslashes($params["gid"])."’";

# query estesa basata sul singolo esperimento

if ($params["expname"] != "")

$query .= " and sigla_exp=’".addslashes($params["expname"])."’";

# query inviata al database

$result = mysql_query($query, $params["link_id"]) or die(mysql_error($params["link_id"]));

# il result-set viene ritornato

CAPITOLO 3. ANALISI ED IMPLEMENTAZIONE 51

return(mysql_fetch_array($result));

}

La funzione costruisce, per prima cosa, una semplice query basata sul solo gruppo,

per poi estendere i criteri di selezione al nome dell’esperimento, se specificato nell’array

dei parametri, quindi invia la query e ritorna il result-set.

3.5.2 Inserimento dati

Analogamente, una funzione di tipo Set, utilizza una segnatura a tre parametri per iden-

tificare mediante tavola hash tutte le opzioni di cui necessita per interfacciarsi con il

database e costruire query di inserimento o aggiornamento dati. Il secondo parametro

e un’altra tavola hash contenente i valori da assegnare ai campi della tabella, mentre il

terzo, se presente, identifica univocamente il record da aggiornare. Quest’ultimo valore e

fondamentale per la funzione, per poter discriminare fra query di inserimento e query di

aggiornamento.

function setSpinoff($params, $values, $id) {

# Se non e specificato alcun record in particolare,

# l’id e nullo e la query sara di inserimento

if ($id == 0) {

$query =

"INSERT INTO ".$params["tablename"]."

SET sigla_exp = ’".addslashes($params["expname"])."’,

gid = ".$params["gid"].",

infn_exp = ’".addslashes($values["infn_exp"])."’,

discip_scient = ’".addslashes($values["discip_scient"])."’,

appl_res = ’".addslashes($values["appl_res"])."’,

ip = ’".$params["ip"]."’,

remote_user = ’".$params["remote_user"]."’";

}else{

CAPITOLO 3. ANALISI ED IMPLEMENTAZIONE 52

# Se l’id e non nullo e la query sara di aggiornamento

$query =

"UPDATE ".$params["tablename"]."

SET sigla_exp = ’".addslashes($params["expname"])."’,

gid = ".$params["gid"].",

infn_exp = ’".addslashes($values["infn_exp"])."’,

discip_scient = ’".addslashes($values["discip_scient"])."’,

appl_res = ’".addslashes($values["appl_res"])."’,

ip = ’".$params["ip"]."’,

remote_user = ’".$params["remote_user"]."’

WHERE sid = ".$id;

}

# Eseguo la query

mysql_query($query, $params["link_id"]) or die(mysql_error($params["link_id"]));

}

Come si nota, i nomi del database e delle tabelle non sono mai esplicitati come stringhe

costanti: questo costituisce un ulteriore vantaggio nella gestione delle connessioni al db

server poiche la modifica al nome di una tabella o dell’intero db, coinvolgera una ed

una sola modifica dal punto di vista dell’applicazione, che si preoccupera di valorizzare

correttamente le variabili, propagando i nomi.

3.5.3 Cancellazione

Un ultimo tipo di funzione per l’interfacciamento al database riguarda la cancellazione di

record dalle tabelle. Non sono molte le maschere che ne fanno uso, poiche molte tabelle

sono in relazione 1:1 con la tabella degli esperimenti e la cancellazione di un record ha senso

solo se subordinata alla cancellazione di un esperimento. Da cio si evince che le relazioni

1:n dovranno, invece, prevedere questa eventualita, come succede per la gestione delle

collaborazioni, delle leadership e delle milestone. Una funzione di tipo Del e strutturata

come segue:

function delCollaborations($params, $id) {

# costruisco la query sulla base del solo id, chiave primaria

CAPITOLO 3. ANALISI ED IMPLEMENTAZIONE 53

$query =

"DELETE

FROM ".$params["tablename"]."

WHERE cid = ".$id;

# eseguo la query

$result = mysql_query($query, $params["link_id"]) or die(mysql_error($params["link_id"]));

}

3.6 Struttura dell’output HTML

Ogni pagina e costituita da una struttura HTML statica, all’interno della quale e annegato

del codice server-side PHP. Il parsing di tale codice, ad opera del webserver, genera un

flusso di puro HTML, che va ad integrarsi con le linee non dinamiche ignorate dal parser

ed inviate direttamente al browser.

Figura 3.2: Webserver con PHP

La figura 3.2 mostra come il webserver interagisca con il modulo PHP per ottenere

codice HTML da restituire al browser, a cui questo processo e del tutto trasparente.

3.6.1 Validazione W3C

Cio che il browser riceve e puro codice HTML da interpretare e tradurre in schermate

grafiche. Questo implica che la generazione del flusso HTML rispetti delle regole di

semantica e, soprattutto, di sintassi, come e lecito attendersi da qualsiasi linguaggio, sia

esso compilato o interpretato. La famiglia di meta-linguaggi SGML, da cui deriva HTML,

utilizza file Document Type Definition (DTD) per la parte semantica e regole standard di

sintassi che restano invariate fra le varie versioni.

CAPITOLO 3. ANALISI ED IMPLEMENTAZIONE 54

Il DTD a cui fanno riferimento le pagine web di questa applicazione e stato rilasciato

dal W3C del C.E.R.N. per HTML versione 4.01 Transitional.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

Questo significa che qualsiasi browser certificato per HTML 4.01 sara in grado di

interpretare e visualizzare correttamente le pagine web, indipendentemente dalla versione

o dal sistema operativo. Tutte le pagine sono sottoposte ad un processo di validazione,

mediante un servizio messo a disposizione dallo stesso C.E.R.N. in grado di certificare

on-the-fly la piena correttezza formale del codice ricevuto.

<a href="http://validator.w3.org/check/referer">

<img border="0"

src="http://www.w3.org/Icons/valid-html401"

alt="Valid HTML 4.01!" height="31" width="88">

</a>

Figura 3.3: HTML 4.01 compliant

Basta cliccare sull’immagine che appare in fondo ad ogni pagina per ottenere imme-

diatamente un rapporto sul codice della pagina stessa.

3.6.2 Componente client-side

Lo schema di una transazione fra webserver e browser prevede un ultimo passaggio, per

quanto riguarda la piena elaborazione di una pagina web e la successiva visualizzazio-

ne. Abbiamo visto come uno script PHP venga elaborato dal server per generare codice

HTML, sottolineando il fatto che questo aspetto e del tutto trasparente al browser, che

si comporta come un mero interprete di meta-linguaggi. Quest’ultimo passaggio, tipico

delle recenti versioni di HTML, prevede che una pagina sia in grado di modificare il pro-

prio stato (Behavior) anche dopo l’invio al client, poiche e il client stesso ad eseguire del

codice. Analogamente al PHP, questo codice, definito client-side, viene elaborato da un

interprete che interagisce con il browser per mostrare in tempo reale l’output generato da

un dato evento.

CAPITOLO 3. ANALISI ED IMPLEMENTAZIONE 55

Figura 3.4: Rapporto validazione

CAPITOLO 3. ANALISI ED IMPLEMENTAZIONE 56

Uno script puo includere sia codice server-side che codice client-side che codice HTML,

secondo la gerarchia di elaborazione che coinvolge il parser (PHP), il webserver, la virtual

machine (javascript) ed infine il browser (HTML).

Le applicazioni piu comuni di scripting client-side sono legate ad effetti DHTML (pa-

gine dinamiche) o controlli sui dati inseriti nelle form, eseguiti all’atto dell’invio. Questa

applicazione fa uso di entrambe le tipologie sia per lo sviluppo del menu che per le maschere

di inserimento. Quest’ultimo aspetto ha portato allo sviluppo di funzioni javascript anche

per limitare la quantita di dati inseribili nelle aree di testo, evitando cosı di sovraccaricare

il webserver, il database server ed in ultimo la rete.

Di seguito e riportato il codice javascript utilizzato nella pagina di inserimento relativa

allo spin-off, per limitare i dati inseribili ad una dimensione di 400 caratteri:

function textCounter(field, countfield, maxlimit) {

# Se i caratteri inseriti superano il limite,

# taglio quelli in eccesso

if (field.value.length > maxlimit) // if too long...trim it!

field.value = field.value.substring(0, maxlimit);

# altrimenti aggiorno il campo che mostra

# il numero di caratteri ancora inseribili

else

countfield.value = maxlimit - field.value.length;

}

Questa funzione viene attivata dall’attributo onKeyDown del TAG Textarea ogni qual

volta viene premuto un tasto.

<textarea name="SPINOFF[infn_exp]" cols="80" rows="4"

wrap="PHYSICAL" id="infn"

onKeyDown="textCounter(getElementById(’infn’), getElementById(’count1’), 400);"

onKeyUp="textCounter(getElementById(’infn’), getElementById(’count1’), 400);">

<?=$spinoff["infn_exp"]?>

</textarea>

Capitolo 4

Database

4.1 Database Management System

Un database e una collezione di dati che viene gestita e organizzata da un software spe-

cifico, il DBMS (Database Management System). Un DBMS e uno strato software che si

frappone tra utente e dati. Grazie a questo strato intermedio l’utente e le applicazioni

non accedono ai dati cosı come sono memorizzati effettivamente, ovvero, alla loro rappre-

sentazione fisica, ma ne vedono solamente una rappresentazione logica. Cio permette un

elevato grado di indipendenza fra le applicazioni e la memorizzazione fisica dei dati.

4.1.1 Definizione

Un DBMS, per essere considerato tale, deve avere determinate caratteristiche:

• Un DBMS e fatto per gestire grandi quantita di dati : convenzionalmente si puo in-

tendere che un gruppo di informazioni sia di grandi dimensioni quando questo non

possa essere contenuto tutto simultaneamente nella memoria centrale del compu-

ter. In generale un DBMS non dovrebbe porre limiti alle dimensioni, tranne quelle

imposte dai supporti fisici in cui devono essere memorizzate le informazioni.

• I dati devono poter essere condivisibili : l’idea che sta alla base dei sistemi di gestione

dei dati e quella di accentrare le informazioni in un unico sistema di amministrazione.

In questo senso e necessario che tali dati siano condivisibili da diverse applicazioni

e da diversi utenti.

57

CAPITOLO 4. DATABASE 58

• I dati devono essere persistenti e affidabili : i dati sono persistenti quando continua-

no a esistere dopo lo spegnimento della macchina con cui vengono elaborati; sono

affidabili quando gli eventi per cui si possono produrre alterazioni accidentali sono

estremamente limitati.

• L’accesso ai dati deve essere controllabile: dovendo trattare una grande mole di

dati in modo condiviso, e indispensabile che esistano dei sistemi di controllo degli

accessi, per evitare che determinate informazioni possano essere ottenute da chi non

e autorizzato, oppure che vengano modificate da chi non ne e il responsabile.

4.1.2 MySQL

MySQL e stato originariamente sviluppato dalla T.c.X. AB di Stoccolma per uso interno:

avevano bisogno di gestire database di grosse dimensioni in maniera estremamente veloce

e, non trovando nessun prodotto che facesse al loro caso, decisero di sviluppare una libreria

ISAM (Index Sequential Access Method) proprio per quello scopo.

Figura 4.1: Logo di MySQL

Nei primi anni ’90 la T.c.X. aggiunse un parser SQL alla propria libreria ISAM e fu

cosı che nacque MySQL come lo conosciamo noi oggi: un database relazionale che ha la

capacita di gestire tabelle di grosse dimensioni in modo estremamente veloce (la T.c.X.

afferma di utilizzare MySQL per gestire database le cui dimensioni sono dell’ordine di

centinaia di megabyte). La grande velocita di esecuzione di MySQL e frutto di una serie

di compromessi: non sono state implementate tutte quelle caratteristiche penalizzanti dal

punto di vista delle prestazioni.

Tra le features non implementate, spicca l’assenza della gestione delle transazioni e

delle viste su di una tabella, mentre e presente una gestione minimale dei lock (e possibile

mettere un lock soltanto su di una tabella e non sul singolo record della tabella). Sempre

per privilegiare la velocita d’esecuzione, molti comandi SQL presentano delle limitazioni:

il comando SELECT, ad esempio, non permette di effettuare delle sotto query utilizzando

in cascata piu comandi SELECT.

Nonostante tutto, alla T.c.X. lavorano sempre per aggiungere nuovi comandi SQL,

ampliare la sintassi di quelli esistenti ed implementare nuove caratteristiche, senza alcun

CAPITOLO 4. DATABASE 59

Figura 4.2: Motore di MySQL

CAPITOLO 4. DATABASE 60

Figura 4.3: Architettura 2-tier thin client

un impatto negativo sulla velocita d’esecuzione. Un esempio di quanto appena affermato

e che la versione beta di MySQL supporta un nuovo gestore di tabelle a basso livello

(il Berkeley DB) che implementa una sofisticata gestione delle transazioni: anche se le

tabelle create da questo nuovo gestore non sono compatibili con l’implementazione attuale,

e comunque possibile utilizzare i due tipi di tabelle nella stessa query SQL, potendo cosı

godere dei vantaggi di entrambe. Di MySQL esistono distribuzioni contenenti i file binari,

pronti per l’installazione, e distribuzioni contenenti soltanto i file sorgenti.

4.2 Database utilizzato dall’applicazione

L’applicazione web dei Consuntivi 2004 utilizza un RDBMS con driver MySQL come

supporto di memorizzazione persistente. Trattandosi di un’architettura two tier non e

presente alcun livello applicativo fra il database layer ed il presentation layer costituiti

rispettivamente dal database server e dal web server.

4.2.1 Entita e relazioni

Il database e costituito da un numero di tabelle di entita, ottenute a partire dal raffina-

mento di un diagramma Entity-Relationship. Il nuovo db e stato progettato allo scopo di

ottimizzare la struttura gia presente, adattandola ai nuovi requisiti utente e rendendola

pienamente relazionale.

Di seguito sono riportate le tabelle di entita:

• Commissione: Ognuna delle 5 commissioni scientifiche nazionali ha un proprio re-

cord all’interno di questa tabella, in cui viene specificato il nome del presidente, il

suo indirizzo email ed una descrizione sull’attivita di ricerca della commissione.

• Esperimento: Questa tabella mantiene le informazioni relative agli esperimenti

I.N.F.N: partecipando ad una relazione n:1 con la tabella Commissione. Gli attribu-

ti di questa entita sono il nome dell’esperimento, il nome del responsabile nazionale,

il suo indirizzo email, la URL al logo e la URL alla home page

CAPITOLO 4. DATABASE 61

• Settore: Ogni esperimento conduce la propria attivita di ricerca all’interno di uno

specifico settore e questo si traduce in una relazione 1:n con l’entita Esperimento.

L’unico attributo di questa entita e il nome del settore

• Activity Report : Questa e la tabella d’entita principale, riguardo le informazioni

inserite sull’attivita scientifica svolta. E’ in relazione 1:1 con la tabella d’esperimento

ed ospita tutti i dati non strutturati inseribili direttamente dalla pagina dell’Brief

Report

• Collaborazione: In questa tabella sono salvati tutti i record relativi alle collaborazio-

ni avute, nell’ambito di un esperimento, con personale ed istituti esterni all’I.N.F.N o

strutture locali dell’istituto. Questa tabella e in relazione n:1 con la tabella d’entita

Esperimento

• Leadership: In questa tabella sono salvati tutti i record relativi ai ruoli di responsa-

bilita ricoperti dai ricercatori in un esperimento. Questa tabella e in relazione n:1

con la tabella d’entita Esperimento

• Milestone: Le milestone concordate o raggiunte da un esperimento sono salvate indi-

stintamente all’interno di questa tabella, con un attributo d’entita che le distingue.

Questa tabella e in relazione n:1 con la tabella d’entita Esperimento

• Internazionalizzazione: Questa tabella e utilizzata per salvare le informazioni relati-

ve alle collaborazioni internazionali in cui si inserisce un esperimento, esprimendo il

contributo finanziario e d’organico offerto dell’I.N.F.N. Questa tabella e in relazione

1:1 con l’entita Esperimento.

• Spin-Off : Entita che ospita tutti i dati relativi allo spin-off di un esperimento. Si

trova in relazione 1:1 con la tabella d’esperimento.

• Ricaduta: Qui sono specificati i campi che descrivono le future ricadute sul mondo

scientifico ed industriale, a partire dai risultati ottenuti da un esperimento.

Di seguito e riportato il diagramma Entita-Relazioni da cui si e partiti per ottenere

il database finale. Il gran numero di weak-entities e relazioni 1:1 ha fatto sı che molte

relazioni venissero inglobate all’interno delle stesse entita per evitare inutili e costose

operazioni di join nelle query di selezione.

CAPITOLO 4. DATABASE 62

Figura 4.4: Diagramma E-R

CAPITOLO 4. DATABASE 63

4.3 Realizzazione del Database: Catalogo dei dati

Sulla base del modello E-R mostrato in figura 4.4, e stato creato il Database e le relative

tabelle, utilizzando front-end grafici e testuali di supporto alla progettazione. Sono di

seguito riportate le query SQL di creazione, e le relative tabelle create, mostrando in

dettaglio i tipi di attributo, le chiavi ed i vincoli.

4.3.1 Entita ActivityReport

CREATE TABLE ‘ActivityReport‘ (

‘sectid‘ int(3) unsigned NOT NULL default ’0’,

‘groupid‘ int(1) unsigned NOT NULL default ’0’,

‘expid‘ int(6) unsigned NOT NULL default ’0’,

‘linea\_ric\_code‘ int(2) default NULL,

‘linea\_ricerca‘ varchar(80) default NULL,

‘status‘ varchar(4) default NULL,

‘exp\_start‘ int(4) NOT NULL default ’0’,

‘exp\_duration‘ int(3) NOT NULL default ’0’,

‘lab\_beam‘ text,

‘goal‘ text,

‘activity‘ text,

‘infn\_contrib\_mp‘ text,

‘infn\_contrib\_bud‘ text,

‘infn\_contrib\_fte‘ int(5) default NULL,

‘infn\_contrib\_ric‘ int(5) unsigned default NULL,

‘inno\_instr‘ text,

‘esp\_compet‘ text,

‘int\_committee‘ text,

‘relazione\_comm‘ text,

‘summary‘ text,

‘descrizione‘ text,

‘n\_tot\_talks‘ int(5) NOT NULL default ’0’,

‘n\_ruoli\_infn‘ int(4) NOT NULL default ’0’,

‘n\_ruoli\_tot‘ int(5) NOT NULL default ’0’,

‘convalida‘ int(1) default NULL,

‘conv_date‘ date default NULL,

‘datamod‘ timestamp(14) NOT NULL,

CAPITOLO 4. DATABASE 64

‘ip‘ varchar(15) default NULL,

‘remote_user‘ varchar(80) default NULL,

PRIMARY KEY (‘sectid‘,‘groupid‘,‘expid‘)

) TYPE=MyISAM;

4.3.2 Entita Collaborazione

CREATE TABLE ‘Collaborazione‘ (

‘collid‘ int(6) unsigned NOT NULL auto_increment,

‘expid‘ int(6) unsigned NOT NULL default ’0’,

‘sectid‘ int(3) unsigned NOT NULL default ’0’,

‘groupid‘ int(1) unsigned NOT NULL default ’0’,

‘sezione‘ varchar(80) default NULL,

‘istituto‘ varchar(255) NOT NULL default ’’,

‘tipo‘ tinyint(1) NOT NULL default ’0’,

‘nazione‘ varchar(80) NOT NULL default ’’,

‘note‘ longtext NOT NULL,

‘data_mod‘ timestamp(14) NOT NULL,

‘ip‘ varchar(15) NOT NULL default ’’,

‘remote_user‘ varchar(80) NOT NULL default ’’,

PRIMARY KEY (‘collid‘,‘expid‘,‘sectid‘,‘groupid‘)

) TYPE=MyISAM AUTO_INCREMENT=6 ;

4.3.3 Entita Commissione

CREATE TABLE ‘Commissione‘ (

‘groupid‘ int(1) unsigned NOT NULL default ’0’,

‘presidente‘ varchar(30) NOT NULL default ’’,

‘email‘ varchar(50) NOT NULL default ’’,

‘descrizione‘ text,

PRIMARY KEY (‘groupid‘)

) TYPE=MyISAM;

4.3.4 Entita Esperimento

CREATE TABLE ‘Esperimento‘ (

CAPITOLO 4. DATABASE 65

Figura 4.5: ActivityReport

CAPITOLO 4. DATABASE 66

Figura 4.6: Collaborazione

CAPITOLO 4. DATABASE 67

Figura 4.7: Commissione

CAPITOLO 4. DATABASE 68

‘expid‘ int(6) unsigned NOT NULL auto_increment,

‘groupid‘ int(1) unsigned NOT NULL default ’0’,

‘sectid‘ int(3) unsigned NOT NULL default ’0’,

‘sigla_exp‘ varchar(20) NOT NULL default ’’,

‘email_resp‘ varchar(50) NOT NULL default ’’,

‘logo‘ varchar(80) NOT NULL default ’’,

‘home_page_url‘ varchar(80) NOT NULL default ’’,

‘datamod‘ timestamp(14) NOT NULL,

‘ip‘ varchar(15) NOT NULL default ’’,

‘remote_user‘ varchar(80) NOT NULL default ’’,

PRIMARY KEY (‘expid‘,‘groupid‘,‘sectid‘)

) TYPE=MyISAM AUTO_INCREMENT=6 ;

4.3.5 Entita Internazionalizzazione

CREATE TABLE ‘Internazionalizzazione‘ (

‘expid‘ int(6) unsigned NOT NULL default ’0’,

‘sectid‘ int(3) unsigned NOT NULL default ’0’,

‘groupid‘ int(1) unsigned NOT NULL default ’0’,

‘tot_ric‘ int(5) NOT NULL default ’0’,

‘ric_firm‘ int(5) NOT NULL default ’0’,

‘pub_int‘ int(5) NOT NULL default ’0’,

‘tot_pub‘ int(5) NOT NULL default ’0’,

‘perc_imp_fin‘ int(3) NOT NULL default ’0’,

‘data_mod‘ timestamp(14) NOT NULL,

‘ip‘ varchar(15) NOT NULL default ’’,

‘remote_user‘ varchar(80) NOT NULL default ’’,

PRIMARY KEY (‘expid‘,‘sectid‘,‘groupid‘)

) TYPE=MyISAM;

4.3.6 Entita Leadership

CREATE TABLE ‘Leadership‘ (

‘lid‘ int(6) NOT NULL auto_increment,

‘sectid‘ int(3) unsigned NOT NULL default ’0’,

‘groupid‘ int(1) unsigned NOT NULL default ’0’,

CAPITOLO 4. DATABASE 69

Figura 4.8: Esperimento

CAPITOLO 4. DATABASE 70

Figura 4.9: Internazionalizzazione

CAPITOLO 4. DATABASE 71

‘expid‘ int(6) unsigned NOT NULL default ’0’,

‘nome‘ varchar(80) NOT NULL default ’’,

‘cognome‘ varchar(80) NOT NULL default ’’,

‘tipo_ruolo‘ varchar(80) NOT NULL default ’’,

‘incarico‘ varchar(80) NOT NULL default ’’,

‘settore_tipo‘ varchar(80) NOT NULL default ’’,

‘data_mod‘ timestamp(14) NOT NULL,

‘ip‘ varchar(15) NOT NULL default ’’,

‘remote_user‘ varchar(80) NOT NULL default ’’,

PRIMARY KEY (‘lid‘,‘sectid‘,‘groupid‘,‘expid‘)

) TYPE=MyISAM AUTO_INCREMENT=6 ;

4.3.7 Entita Milestone

CREATE TABLE ‘Milestone‘ (

‘milid‘ int(3) unsigned NOT NULL auto_increment,

‘sectid‘ int(3) unsigned NOT NULL default ’0’,

‘groupid‘ int(1) unsigned NOT NULL default ’0’,

‘expid‘ int(6) unsigned NOT NULL default ’0’,

‘data‘ date NOT NULL default ’0000-00-00’,

‘idass_mil‘ int(6) default NULL,

‘idmil_o‘ int(6) default NULL,

‘data_str‘ varchar(80) default NULL,

‘descrizione‘ varchar(255) NOT NULL default ’’,

‘percentuale‘ int(3) NOT NULL default ’0’,

‘commento‘ varchar(255) default NULL,

‘data_mod‘ timestamp(14) NOT NULL,

‘ip‘ varchar(15) NOT NULL default ’’,

‘remote_user‘ varchar(80) NOT NULL default ’’,

‘tipo_mil‘ int(1) unsigned default NULL,

PRIMARY KEY (‘milid‘)

) TYPE=MyISAM AUTO_INCREMENT=6 ;

4.3.8 Entita Ricaduta

CREATE TABLE ‘Ricaduta‘ (

CAPITOLO 4. DATABASE 72

Figura 4.10: Leadership

CAPITOLO 4. DATABASE 73

Figura 4.11: Milestone

CAPITOLO 4. DATABASE 74

‘sectid‘ int(3) unsigned NOT NULL default ’0’,

‘groupid‘ int(1) unsigned NOT NULL default ’0’,

‘expid‘ int(6) unsigned NOT NULL default ’0’,

‘ric_campo‘ varchar(80) NOT NULL default ’’,

‘nuovo_prod‘ varchar(80) NOT NULL default ’’,

‘altri_exp‘ varchar(80) NOT NULL default ’’,

‘exp1‘ varchar(80) NOT NULL default ’’,

‘exp2‘ varchar(80) NOT NULL default ’’,

‘altre_discip‘ varchar(80) NOT NULL default ’’,

‘osp1‘ varchar(80) NOT NULL default ’’,

‘osp2‘ varchar(80) NOT NULL default ’’,

‘industria‘ varchar(80) NOT NULL default ’’,

‘ind1‘ varchar(80) NOT NULL default ’’,

‘ind2‘ varchar(80) NOT NULL default ’’,

‘medicali‘ tinyint(4) NOT NULL default ’0’,

‘beni_cult‘ tinytext NOT NULL,

‘industriali‘ tinyint(4) NOT NULL default ’0’,

‘data_mod‘ timestamp(14) NOT NULL,

‘ip‘ varchar(15) NOT NULL default ’’,

‘remote_user‘ varchar(80) NOT NULL default ’’,

PRIMARY KEY (‘sectid‘,‘groupid‘,‘expid‘)

) TYPE=MyISAM;

4.3.9 Entita Settore

CREATE TABLE ‘Settore‘ (

‘sectid‘ int(3) unsigned NOT NULL auto_increment,

‘settore‘ varchar(200) NOT NULL default ’’,

PRIMARY KEY (‘sectid‘)

) TYPE=MyISAM AUTO_INCREMENT=6 ;

4.3.10 Entita Spin off

CREATE TABLE ‘Spin_off‘ (

‘sectid‘ int(3) unsigned NOT NULL default ’0’,

‘infn_exp‘ text,

CAPITOLO 4. DATABASE 75

Figura 4.12: Ricaduta

CAPITOLO 4. DATABASE 76

Figura 4.13: Settore

CAPITOLO 4. DATABASE 77

‘groupid‘ int(1) unsigned NOT NULL default ’0’,

‘expid‘ int(6) unsigned NOT NULL default ’0’,

‘discip_scient‘ text NOT NULL,

‘appl_res‘ text NOT NULL,

‘data_mod‘ timestamp(14) NOT NULL,

‘ip‘ varchar(15) NOT NULL default ’’,

‘remote_user‘ varchar(80) NOT NULL default ’’,

PRIMARY KEY (‘sectid‘,‘groupid‘,‘expid‘)

) TYPE=MyISAM;

4.4 Esempi di inserimento

Sono di seguito riportati alcuni esempi di inserimento per mostrare la struttura finale dei

record, generati dall’applicazione in fase di presa dati. Si tratta di schermate tratte da

un front-end grafico basato su web, largamente diffuso ed open-source: PhpMyAdmin

4.5 Struttura precedente

La differenza principale fra il nuovo database, e quello in uso fino al 2003, sta nella

strutturazione di molti tipi di dato sulla base di un modello relazionale. Questo ha

permesso di modificare la cardinalita di molte relazioni da un modello 1:1 (dati aggregati

ed indistinguibili) ad uno 1:n (dati separati in record) favorendo una piu netta distinzione

fra le entita e semplificando la consultazione. Il modello di riferimento per il vecchio DB

era prettamente monolitico, con una singola tabella e tutte le relazioni (esclusivamente

1:1) incluse in essa. Dati che, ora, sono strutturati e relazionati a dovere, erano semplici

righe all’interno di un’area di testo rendendo praticamente impossibile o inaffidabile ogni

genere di statistica. Per fare un esempio, la nuova struttura di inserimento delle milestone

e basata su una tabella di entita in relazione n:1 con la tabella degli esperimenti ed esprime

in dettaglio (in campi separati) tutte le voci relative alla milestone. La vecchia struttura

aveva una pagina di inserimento di questo tipo:

Come mostrato in figura 4.25, non era assolutamente possibile distinguere la data,

dal testo, dalla percentuale di raggiungimento o addirittura una milestone dall’altra. Un

procedimento analogo e stato previsto anche per le collaborazioni, i ruoli di leadership,

le pubblicazioni, le tesi e le conferenze, snellendo la tabella principale di informazioni di

non diretta competenza con l’entita esperimento.

CAPITOLO 4. DATABASE 78

Figura 4.14: Spinoff

CAPITOLO 4. DATABASE 79

Figura 4.15: ActivityReport

CAPITOLO 4. DATABASE 80

Figura 4.16: Collaborazione

CAPITOLO 4. DATABASE 81

Figura 4.17: Commissione

CAPITOLO 4. DATABASE 82

Figura 4.18: Esperimento

CAPITOLO 4. DATABASE 83

Figura 4.19: Internazionalizzazione

CAPITOLO 4. DATABASE 84

Figura 4.20: Leadership

CAPITOLO 4. DATABASE 85

Figura 4.21: Milestone

CAPITOLO 4. DATABASE 86

Figura 4.22: Ricaduta

CAPITOLO 4. DATABASE 87

Figura 4.23: Settore

CAPITOLO 4. DATABASE 88

Figura 4.24: Spinoff

CAPITOLO 4. DATABASE 89

Figura 4.25: Inserimento milestone nella vecchia applicazione