Un ambiente collaborativo a supporto delle revisioni sistematiche

TITLE

SEARCH

ON WEB

Diagramma dei casi d’uso Gestione Articolo

Figura 4.1.1 41

 si occupa dell’operazione di inserimento,

Gestione Autore:

modifica, cancellazione e ricerca dei dati del singolo autore. Un

e affiliazione. L’autore

autore può essere ricercato per cognome

è identificato tramite: Nome, Cognome, Affiliazione, Istituto

presso cui è associato e gli articoli che ha scritto.

ADD AUTHOR SEARCH

SURNAME

<include> <include> UPDATE

AUTHOR

SEARCH

AUTHOR

NEW AUTHOR DELETE

AUTHOR

AUTHOR

MANAGMENT

EVALUER AFFILIATION

MANAGMENT

ADD AFFILIATION

AFFILIATION TYPE

COUNTRY DELETE

AFFILIATION

dei casi d’uso Gestione Autore

Figura 4.1.2 Diagramma 42

 Gestione Framework: si occupa delle operazioni di inserimento,

modifica, cancellazione e ricerca dei dati relativi ai vari

framework. Per l’inserimento di un nuovo framework bisogna

definire il Nome, la descrizione, l’obiettivo e il relativo punto di

vista. Una volta salvati i dati nel database, bisogna aggiungere

un questionario di domande che vengono usate per effettuare la

valutazione degli articoli. Ogni domanda fa riferimento ad una

particolare informazione, che permette di caratterizzare

l’articolo, ottenuta analizzando l’articolo stesso. Le

informazioni che compongono la domanda sono:

o Codice domanda;

o Testo della domanda;

o Categoria: indica la tipologia di dati che intende

estrapolare la domanda (ad esempio: domanda generale,

domanda di valutazione di un particolare contesto);

o Numero domanda;

o Tipo di questionario;

Una volta inserito un questionario per il framework è possibile

rispondere alle domande del framework attraverso delle risposte

prescelte. 43

ADD DELETE POINT

QUESTION FRAMEWORK OF VIEW

ADD

ANSWER

UPDATE

FRAMEWORK FRAMEWORK

MANAGMENT

<include> NEW

FRAMEWORK

SEARCH

FRAMEWORK EVALUER

SEARCH ALL

FRAMEWORK SEARCH

NAME

FRAMEWORK

Diagramma dei casi d’uso Gestione Framework

Figura 4.1.3

 Valutazione dati: Include la possibilità di scegliere un

framework e un articolo sul quale si vuole effettuare una

valutazione. Una volta selezionato il framework e l’articolo

bisogna rispondere al questionario di domande. Tale

funzionalità si occupa di archiviare le risposte date, in base al

questionario indicato dal framework, fornendo i seguenti dati:

o Codice della domanda

o Risposta: scelta tra quelle previste; 44

o Annotazioni: indicanti tipologia e nota che specificano

il significato della risposta data ed i dati evidenziati;

Per ognuna delle domande si seleziona il valore della risposta

“Answer”, l’eventuale annotazione “Typology/note” e salvare la

risposta in archivio. Include la possibilità di visualizzare gli articoli

già valutati e da chi sono stati valutati. La visualizzazione consiste

nel vedere per ogni domanda del questionario la relativa risposta.

 Analisi dei dati: con tale funzionalità è possibile visualizzare:

o Tutte le risposte per framework e per singolo articolo

selezionato;

Gli articoli in base alla tipologia e nota scelte dall’utente;

o

o Gli articoli in base alla sola tipologia indicata

dall’utente;

o Gli in base ad una domanda ed annotazione stabilite

dall’utente.

Le funzionalità Valutazione dei dati e Analisi dei dati del Valutatore sono

casi d’uso in “figura 4.1.4”.

illustrate nel diagramma completo dei 45

Diagramma dei casi d’uso

Figura 4.1.4 Valutator

4.2 Progettazione del database

Per realizzare tale progetto è stato progettato un database in MySQL server 5.5.

Per la sua progettazione è stata eseguita una[4]:

1. Progettazione Concettuale;

2. Progettazione Logica;

3. Realizzazione del modello E-R.

Progettazione Concettuale

In tale fase è stato progettato lo schema E-R, progettando un modello Entità-

Relazione (modello ER), un modello concettuale dei dati. Come tale descrive

ad alto livello la realtà modellata indipendentemente da come i dati verranno

logicamente e fisicamente rappresentati. Il modello ER definisce 46

uno schema concettuale dei dati. Uno schema descrive la struttura o forma dei

dati, ma non descrive i dati veri e propri, vale a dire le istanze o occorrenze

dello schema. Facendo un paragone con la programmazione orientata agli

oggetti, lo schema corrisponde alla nozione di classe e una istanza dello schema

è un oggetto della classe. Inizialmente si è proceduto seguendo una strategia

Top-down, in seguito si è seguita, una strategia bottom-up, ponendo

l'attenzione solo su una determinata parte dei concetti raffinandoli in modo

separato. Quindi è stata utilizzata una strategia mista che è molto flessibile, e

permette di procedere in modo bottom-up o top-down in base alle esigenze. Le

“Modello

entità che sono stare realizzate vengono descritte nella sezione

relazionale”.

Progettazione logica

Prima di iniziare la progettazione logica è stata scelta il tipo di base di dati da

utilizzare, cioè il modello dei dati che si vuole adottare. La progettazione logica

della base di dati consiste nella traduzione dello schema concettuale dei dati in

uno schema logico che rispecchia il modello dei dati scelto, cioè, nel nostro

caso, il modello relazionale.

Strutturazione dello schema E-R dati. E’

Sono state definite diverse entità che, sono riportate nel dizionario dei

stata fornita per ognuna di essa una descrizione, attributi e identificatori. Sono

state definite le relazione e le entità coinvolte per ogni relazione. Non tutti i

costrutti del modello E-R hanno una traduzione naturale nel modello logico. Si

rende quindi necessaria una semplificazione dello schema concettuale per

realizzare quello che sarà lo schema logico della base di dati. La fase di

ristrutturazione di uno schema entità E-R si può suddividere in una serie di

passi da effettuare in sequenza[8]:

Analisi delle ridondanze: si decide se mantenere o eliminare eventuali

ridondanze (ripetizioni) presenti nello schema; Nel caso in esame le uniche

ridondanze potrebbe essere le seguenti: 47

 L’attributo “question” dell’entità “Questions”, in quanto potrebbero

esserci domande uguali (con lo stesso testo) per diversi framework.

 L’attributo “category” dell’entità “Questions”, perché possono esserci

più domande che appartengono alla stessa categoria.

 L’attributo “tipologia” dell’entità “Note”, più annotazioni possono

avere la stessa tipologia. La stessa considerazione è fatta per l’attributo

“note” della stessa entità.

 L’attributo “answer” può essere derivato dalle risposte consentite dal

framework, quindi è stata connessa la relazione “Answer” all’entità

“AnswerFramework” così si preleva da essa il testo della risposta

evitando la ridondanza.

Nei primi tre casi le ridondanze possono essere eliminate inserendo delle nuove

entità (una per ogni attributo) e nuove relazioni (una per ogni nuova entità), ma

ciò richiederebbe l’accesso ad un numero maggiore di risorse incidendo

negativamente sulle prestazioni. Si è deciso di conservare tali ridondanze a

vantaggio delle prestazioni.

Partizionamento di entità e associazioni: si decide se è opportuno

partizionare concetti dello schema, i più sotto-concetti più semplici, o

viceversa, accorpare concetti separati in un unico concetto;

Eliminazione delle gerarchie: il modello relazionale non rappresenta

le gerarchie, e quindi vanno, sono sostituite da entità e associazioni.

Selezione delle chiavi primarie: si seleziona un identificatore per quelle entità

che ne hanno più di uno. Vengono invece eliminate le identificazioni esterne.

Normalizzazione degli attributi composti o multipli. Sono stati eliminati gli

attributi multi valore non direttamente convertibili nel modello relazionale.

Nella relazione “Answer” l’attributo “note” può avere diversi valori, perché si

può indicare annotazione e classificazione per la risposta data (quindi tipologia

e note). E’ stata introdotta la nuova entità “Note” contenente tali informazioni.

La cardinalità è (1,N) perché una stessa annotazione può essere associata ad

una o più risposte di diverse domande, possono esserci più articoli che

ammettono la stessa risposta alla stessa domanda. 48

Il database è normalizzato in quanto rispetta:

Prima forma normale: Il database rispetta la prima forma normale perché ogni

tabella rispetta la prima forma normale, cioè ognuna di queste non ha attributi

multipli (gli attributi di ogni tabella sono valori atomici non divisibili in

ulteriori attributi);

Seconda forma normale: Il database rispetta la seconda forma normale perché

rispetta la prima forma normale e tutte le tabelle rispettano la seconda forma

nomale, cioè in ognuna di esse non vi sono attributi che dipendono

parzialmente dalla chiave (i campi non chiave dipendono dall’intera chiave

primaria e non da una parte di essa).

Terza forma normale: Il database rispetta la terza forma normale perché

rispetta la seconda forma normale e tutte le tabelle rispettano la terza forma

normale, cioè in queste non vi sono attributi che dipendono transitivamente

dalla chiave (i campi non chiave non dipendono da altri campi non chiave).

Eliminazione delle generalizzazioni: le generalizzazioni non sono

direttamente rappresentabili nel modello relazionale, quindi vanno convertite

in altri costrutti rappresentabili. Nel diagramma E-R non sono presenti

generalizzazioni, quindi non è stato necessario effettuare nessuna operazione

al riguardo.

Modello Relazionale rappresentate nella “Figura 4.2”:

Esso prevede le seguenti entità e relazioni

Risposte(idArticle,idRisposta,idQuestion,idFramework,idNote)

Note(idNote,note,tipology)

Questions(idQuestion,idFramework,question,category)

AnswerFramework(idAnswer,text)

AnswerAllowed(idAswer,idFramework)

Framework(idFramework,scope,description)

ViewFramework(idFramework,idOpinion)

Opinion(idOpinion,opinion) 49

Reference(idArticle, idReference)

KeywordCategory(idMasterKeyword,masterKeyword)

KeywordKeywordCategory(idMasterKeyword,idKeyword)

Keyword(idKeyword, keyword)

ArticleKeyword(idKeyword,