UNIVERSITA DEGLI STUDI DI TRENTO Facoltà di Scienze Matematiche, Fisiche e Naturali

Transcript

1 UNIVERSITA DEGLI STUDI DI TRENTO Facoltà di Scienze Matematiche, Fisiche e Naturali Corso di Laurea INFORMATICA Elaborato Finale UN REPOSITORY DISTRIBUITO PER LEARNING OBJECT Relatore/1st Reader: Laureando/Graduant: Ronchetti Marco Groff Matteo Anno accademico

2

3 INTRODUZIONE...3 Cos'è un Learning Object...4 Learning Object Metadata (LOM)...4 Implementazione di LOM...5 JaxB...5 VCARD...6 Esempio di file vcard...6 Caratteristiche di un buon repository...7 Repositori già esistenti:...7 Merlot:...7 Le Mill...8 Connexion...9 Ariadne...9 Generazione dei Metadati per Learning Object...10 Tipo Oggetto:...11 Materia:...11 Argomento:...11 Target:...12 Keywords:...12 Organizzazione del Repository...12 Architettura...12 Core...14 Tecnologie Utilizzate...15 EJB...15 Web Services...16 Database XML...17 Utilizzo del Database XML nel Core:...19 Database Relazionale...19 Generatore di Metadati...20 Estrattore:...21 Generatori...21 Funzionamento del Repository...22 Gestione degli Utenti...22 Gestione dei Meta-dati...23 Generazione...23 Generazione Automatica:...23 Completamento...23 Titolo:...23 Targhet, Tipo di Lezione Materia ed Argomenti...23 Keywords...24 Tipo di applicazione...24 Inserimento...24 Licenza:...24 Licenza pubblica:...25 Licenza Privata:...26 Ricerca:...27 Ricerca Semplice:...27

4 Approfondimento distanza di Levenshtein...27 Ricerca Avanzata...28 Search Options...28 Funzionamento Software Distribuito...28 Livelli di astrazione:...29 Possibile altra implementazione: Centralizzazione...29 Interfaccia Web...30 Framework:...30 JSF:...30 Framework per Ajax...32 IceFaces...32 Registrazione:...33 Login...34 Pannello Utente...34 Aggiunta di un nuovo Learning Object:...34 I tuoi dati...36 Ricerca...37 Risultati di una ricerca / I tuoi Learning Object...37 Dettagli di un Learning Object...38 Integrazione Facebook...38 Like Button:...38 Comments:...39 Rilevanza sociale...39 Distribuzione:...39 Launcher...39 Embedded Glassfish:...39 Avvio di SamgI e del Repository...40 Conclusioni...41 Bibliografia...41 Indice Analitico...42

5 INTRODUZIONE Questa tesi nasce nell'ambito di un grande progetto che la Provincia Autonoma di Trento sta sviluppando con lo scopo di innovare la didattica nelle scuole attraverso l'introduzione di nuove tecnologie a supporto dei docenti e degli studenti. Una parte di questo progetto, supportato dall'università degli Studi di Trento riguarda la diffusione di numerose Lavagne Interattive Multimediali (LIM) nella varie scuole Trentine: SLIM4DIDA (Supporto all'introduzione di Lavagne Interattive Multimediali per (4) la Didattica) è stato il progetto pilota, il quale sta continuando tuttora con il progetto Wii4Dida. Una LIM è un dispositivo elettronico ideato e realizzato per sostituire la tradizionale lavagna didattica, sulla quale è possibile disegnare attraverso dei pennarelli virtuali o con il metodo touch screen. Tipicamente questa lavagna è collegata ad un Pc permettendo di unire il classico paradigma didattico incentrato sulla lavagna, con l'integrazione di contenuti multimediali dinamici, quali software sviluppati ad Hoc per facilitare e migliorare l'insegnamento. Le possbilità offerte da una LIM rispetto ad una lavagna tradizionale sono enormi infatti introdurre una lavagna interattiva in aula equivale ad "aprire" la classe al digitale; significa, in qualche misura, invertire il senso di marcia della tecnologia. Non sono più infatti gli allievi ad essere "portati" in sala per la classica "ora di informatica", ma è il multimediale ad entrare in classe e a rendersi immagine, video, web, risorse interattive. Mantenendo il classico paradigma centrato sulla lavagna e utilizzando metodi tradizionali d insegnamento come la lezione frontale, il docente potenzia la possibilità d utilizzare software didattico in modo condiviso, la propria attività; facilita la spiegazione dei processi, la descrizione di situazioni e ambienti, l analisi di testi. Tutto ciò consentendo una visualizzazione diretta e condivisa dell oggetto su cui è convogliata tutta l attenzione degli allievi, avendo anche la possibilità di salvare i percorsi didattici proposti, per successivi utilizzi o per la distribuzione agli studenti (inclusi quelli assenti). Oltre che per la didattica frontale, la lavagna interattiva può essere impiegata in aula per lezioni di tipo interattivo/dimostrativo: per condurre dunque attività collaborative e laboratoriali, per svolgere le interrogazioni, per la navigazione e ricerca su web, per

6 presentare in modo innovativo studi ed elaborati realizzati dagli studenti. Molti insegnanti hanno parlato di elevati indici di gradimento e di coinvolgimento degli allievi. E fra i "perché" hanno in particolare indicato la "proprietà" della LIM di allinearsi al linguaggio, delle immagini, dei filmati, della fruizione interattiva, cui le nuove generazioni e i loro stili d apprendimento sono ormai abituate Proprio tutti i possibili contenuti ( detti Learning Object ) sono stati il punto di partenza di questa tesi in quanto la realizzazione di lezioni passa attraverso una fase di creazione e sviluppo delle stesse. Ma anche di ricerca e di riutilizzo di quanto già creato, dato che uno dei punti di maggiore forza degli strumenti elettronici per supportare la didattica è proprio la possibilità di riutilizzare materiale, facilitando e velocizzando la preparazione delle lezioni. L'obiettivo di questo progetto è quindi realizzare un sistema che permetta lo scambio e la ricerca di contenuti didattici, in particolar modo per lavagne interattive. Attraverso la realizzazione di un repository che sia disponibile e accessibile ai docenti che desiderino utilizzare contenuti per Lavagne Multimediali. Questo Repository è stato pensato per essere installato su un server di una scuola, ma che abbia la possibilità di scambiare dati con i repository installati sulle altre scuole, realizzando cosi un sistema distribuito per lo scambio dei LO. Questa tesi si suddivide in più parti principali: nella prima parte inquadreremo a fondo l ambiente in cui questa si sviluppa, analizzando gli obiettivi di questo progetto e confrontandolo con quanto è stato già stato creato nel resto del mondo per risolvere il medesimo problema. La seconda parte parla dei metadati, cioè di come classificare e indicizzare i vari Learning Objects, i metodi da me utilizzati comprendenti vantaggi e svantaggi del mio approccio. Nella terza parte iniziamo a parlare della realizzazione di questo progetto, descrivendo le scelte architetturali prese, le tecnologie utilizzate e le basi del funzionamento di questo progetto approfondendone tutti i punti fondamentali discutendone le scelte prese.

7 La quarta parte riguarda l'interfaccia utente, l'utilizzo e l'installazione del repository. Comprende degli approfondimenti su alcune tematiche della programmazione di applicazioni Web 2.0 e sulle tecnologie adottate per lo sviluppo dell interfaccia utente. Cos'è un Learning Object Iniziamo a definire che cosa è un Learning Object. Un LO è definito come ogni risorsa digitale utile a supportare l'apprendimento, cioè una mattonella di base per e-learning e può essere qualsiasi cosa, come un file pdf, un documento, un immagine, un file video o audio, la cosa importante è che il contenuto abbia lo scopo di insegnare qualche cosa. Le caratteristiche principali di un Learning Object sono: Modulari: cioè posso essere aggregati e usati assieme ad altro LO. Riusabili: significa che una risorsa può essere utilizzata infinite volte, anche in ambienti e situazioni di apprendimento diverse. Reperibili: cioè ricercabili e classificabili attraverso una fase di generazioni di metadati. Che cosa sono i metadati? I metadati sono delle informazioni associate a un LO, ma che non si riferiscono direttamente al contenuto ma hanno lo scopo di classificarlo e di raggrupparlo in categorie assieme ad altri LO, Ad esempio contengono informazioni riguardo al titolo, ma anche alla materia di cui si occupano, sul livello di difficoltà e di conoscenze richieste per comprenderne il contenuto e cosi via. Esistono degli standard internazionali per il formato dei metadati, quali ad esempio Dublin Core o lo stand ieee LOM (Learning Object Metadata). Nel repository tutti i LO inseriti saranno classificati e indicizzati attraverso un documento LOM.

8 Learning Object Metadata (LOM) Per approfondire LOM è lo standard approvato dall'ieee nel giugno 2002 e fissa il minimo insieme di proprietà necessario per la gestione, l'allocazione e la valutazione dei Learning Object. LOM è nato con lo scopo di dare coerenza e di fornire uno standard internazionale in modo che tutti i gestori di meta-dati abbiano un riferimento, potendo cosi condividere informazioni fra loro. Le radici di questo standard affondano in ARIADNE (Alliance of Remote Instructional Authoring and Distribution Networks for Europe) associazione la quale si occupa di indicizzare Learning Object già dalla meta degli anni 90 e punto di riferimento internazionale per la generazione, gestione e soprattutto lo scambio di metadati fra i vari LO. LOM composto di nove aree descrittive, contenenti gruppi di attributi strutturati ad albero: Generale: racchiude le informazioni comuni sul Learning Object; Ciclo di vita: racchiude le informazioni sulla vita del LO (versione, data di creazione, ecc.); Meta-metadati: fornisce informazioni sullo schema di meta-dati adottato; Tecnico: contiene informazioni sui requisiti e le caratteristiche tecniche del LO; Didattico: racchiude informazioni sulle proprietà didattiche del LO; Diritti: fornisce informazioni sui diritti intellettuali e simili del LO; Relazioni: contiene indicazioni sul legame tra l'oggetto e altre risorse; Annotazioni: contiene commenti sull'uso didattico del LO; Classificazioni: fornisce informazioni sulla materia e l'argomento affrontati In totale questi nove gruppi racchiudono settanta elementi descrittivi. Queste informazioni se correttamente compilate permettono di classificare in modo completo una risorsa, e ne permettono cosi delle efficacie ricerche dello stesso.

9 Implementazione di LOM I meta-dati sono rappresentati attraverso un nodo xml ben definito nelle specifiche ieee. Un semplice esempio di un possibile meta-dato è il seguente: <lom xmlns=" <general> <title> <string xml:lang="sp">julio Cesar</string> <string xml:lang="it">giulio Cesare</string> </title> <language>la</language> </general> <technical> <location type="uri"> </location> </technical> </lom> Ovviamente questo è un meta-dato molto incompleto dato che sono specificati solamente 3 dei 70 elementi descrittivi possibili ma è un buon esempio per capire com'è strutturato. Per elaborare queste informazioni nell'ambiente Java ho trovato delle api LOM4J scritte per fornire una semplice interfaccia per il formato LOM. Queste api sono usate anche negli altri repository come Ariadne e si basano su JAXB unito a un supporto per la gestione delle VCARD. JaxB JAXB è un parser XML che utilizza un approccio completamente differente rispetto a SAX o Dom. Infatti, le API jaxb creano dei veri e propri oggetti Java a partire dalla definizione del file XML, definizione che viene di solito fatta usando DTD o XML

10 Schema. Da queste definizioni sono create dinamicamente delle classi Java che poi conterranno i dati riportati nel file XML. Come potete vedere dall'immagine qui riportata il funzionamento è abbastanza semplice: sono creati degli oggetti dalla definizione del file XML. Quest approccio è utilissimo perché rende invisibile al programmatore la presenza del file xml. Si lavora semplicemente con degli oggetti java senza doversi preoccupare di problematiche di parsing o di navigazioni fra nodi. VCARD è un formato di file per i biglietti da visita elettronici. I vcard possono essere allegati a messaggi , ma possono essere scambiati anche in altri modi, generalmente su internet o tra due o più dispositivi mobili. Possono contenere informazioni come nome, cognome, indirizzo, numeri di telefono, , url, compleanno, immagini e perfino clip audio. Queste vcard sono utilizzate nel documento LOM per identificare l'autore dell'oggetto. Esempio di file vcard BEGIN:VCARD VERSION:2.1 N:Matteo NICKNAME:Matteogrf TEL;HOME;VOICE: TEL;CELL;VOICE: TEL;HOME;FAX: ADR;HOME:;;Strada del Redebus =0D=0AItalia ;PREF;INTERNET:matteogrf@aaa.it REV: T172534Z END:VCARD

11 Caratteristiche di un buon repository Un repository per aver successo ed essere ben funzionante deve soddisfare generalmente una serie di requisiti fondamentali, i quali oltre definire di direttive di funzionamento devono comprendere argomenti quali la semplicità di utilizzo e l'efficienza operativa. Poiché un sito web oltre ad essere funzionale, deve anche essere semplice e veloce, è cosa nota che una grande complessità di utilizzo allontana molti utenti, quindi: Deve essere semplice e rapido, alcuni repository richiedono moltissime informazioni per la creazione dei metadati, annoiando l'utente facendogli compilare moltissimi campi e form, questo è un problema che scoraggia l'inserimento di nuovi contenuti e perfino l'utilizzo. La ricerca deve essere semplice e intuitiva, permettendo di trovare ciò che si cerca con pochi click e poche azioni, infatti, una cattiva ricerca rende inutile un repository Deve essere disponibile un meccanismo di protezione dei contenuti, permettendo all'utente di scegliere con chi condividere il proprio lavoro. L'installazione deve essere semplice, ed eseguibile da un qualunque utente che non possiede specifiche conoscenze informatiche, in tal modo questo repository può essere installato su molti server permettendone una gran diffusione. La gestione degli utenti deve essere sviluppata nel modo più semplice possibile, chiedendo all'utente solamente le minime informazioni necessarie. E dimostrato

12 che più informazioni sono richieste, meno utenti decideranno di registrarsi e di contribuire. Il mio obiettivo è quindi realizzare un pacchetto software completo che sia funzionale e utile per soddisfare nel miglior modo possibile questi requisiti. Ora vorrei porre l'attenzione su cosa esiste già e su com è stato realizzato. Repositori già esistenti: Esistono già molti repository per lo scambio dei LO, i quali fra loro presentano rilevanti differenze che ne influenzano l'usabilità e l'utilità. Per esempio alcuni sono aperti e altri invece sono chiusi a gruppi di utenti ben definiti, come membri di un associazione o università. Alcuni possono essere pensati per argomenti o materie ben definiti, altri son più generali, in ogni modo la struttura base resta sempre la stessa. Ho analizzato i repository di maggiore fama: Merlot: Merlot è un repository nato nel 1997 in California, è complemento aperto a tutti gli utenti e al momento indicizza oltre LO. Analizzandone la struttura d inserimento e ricerca è ipotizzabile che si basi su un formato LOM per la descrizione dei contenuti. Utilizzandolo si nota che durante la fase di registrazione cerca di avere la maggior quantità possibile d informazioni sull'ambito educativo dell'utente, richiedendo di compilare numerosi form con menu a tendina, con la possibilità si scegliere elementi già definiti. Le principali informazioni richieste sono l'ambito d insegnamento, la materia e il livello d insegnamento. In seguito, le informazioni raccolte saranno utilizzate per velocizzare la generazione dei Metadati inserendo opportuni valori di default dei vari menu. Quest approccio è lo stesso che avevo pensato per il mio repository, rendendo pero l'inserimento delle informazioni aggiuntive opzionale in modo da non rallentare e scoraggiare la registrazione.

13 Il sistema d inserimento delle risorse è simile alla registrazione, cioè una volta deciso di inserire un LO si dovranno compilare numerosi form con menu a scelta rapida, per descrivere nel modo più completo possibile la risorsa che si sta inserendo. Il sistema utilizza una classificazione Materia Argomenti, i quali selezionabili ma non modificabili. Fa anche una distinzione sui vari scopi del LO, quali lezioni, esercizi, esame, prova, corso on-line. Simulazione ecc... Gli step per la descrizione sono i seguenti: Titolo e URL Descrizione Categoria Autore Informazioni Opzionali (Copyright e informazioni Tecniche) Interessante la possibilità di creare delle Collection, cioè un raggruppamento di LO che servono per raggruppare in modo completo una lezione composta di più Learning Objects. Esprimendo il concetto di Modularità di un LO. La ricerca è molto strutturata, e comprende la possibilità di specificare tutti i possibili dettagli di un filtro. A mio parere è un ottimo repository, dal quale potrei prendere molti spunti, il difetto dal mio punto di vista è l'utilizzo può diventare lento e noioso data la presenza di numerosi campi nelle form. Le Mill Si tratta di uno dei più famosi repository di metadati e utilizza un approccio completamente diverso da merlot: chiede sempre il minimo possibile, favorendo la rapidità e la semplicità a discapito della completezza e della precisione nella classificazione. La registrazione è molto semplice e non richiede nessuna informazione aggiuntiva rispetto ai dati base di un utente. Provando a inserire un nuovo LO notiamo che il repository non permette un upload locale della risorsa, ma accetta solamente un collegamento a essa.

14 Le informazioni necessarie per la creazione dei metadati comprendono Titolo, Autore Descrizione e Parole chiave, poi sono presenti menu a scelta rapida per Lingua materia Argomento target e licenza. È interessante la possibilità offerta da questo sito di creare lezioni con dei tool da loro proposti. Offre anche un sopporto multilingua e per la creazione di collection di lezioni. A differenza di Merlot offre una gran semplicità e velocita di utilizzo che viene pero pagata nel momento della ricerca poiché son presenti meno informazioni che descrivono l'oggetto e quindi è più difficile trovare ciò che si cerca. Connexion Questo repository è completamente diverso rispetto ai precedenti, è molto più sviluppato, poiché oltre alle funzionalità di Repository realizza un sistema sociale, curando la figura dell'autore e delle relazioni fra essi, con possibilità di recensione e controllo dei contenuti. Si occupa anche della creazione di contenuti, fornendo tool per la creazione e per l'esportazione nel formato standard proprietario del sito. Legate all'account utente ci sono funzionalità per il supporto e la gestione dei contenuti, una cartella personale per i propri lavori e numerosi strumenti di personalizzazione a essa associati. Le risorse sono suddivise in moduli che possono essere composti di singoli Learning Objects o raggruppamenti. Esistono anche le Colleciton di moduli, che rappresentano un percorso formativo più completo. Registrandoci si nota una procedura identica a Le Mill. La creazione dei metadati è gestita nello stesso modo degli altri repository analizzati. In conclusione possiamo considerare questo tipo di repository anche come un social network che collega i docenti fra loro.

15 Ariadne Ariadne è un associazione europea aperta al mondo, per la condivisione e il riutilizzo di Learning Object. Il cui cuore è una rete distribuita di repository i quali scambiano informazioni fra loro. E membro di globe, un sistema mondiale per lo scambio di Learning Object, di cui fanno parte tutti i maggiori repository internazionali di metadati. Questo fa si che indicizzi un numero immenso di risorse (quasi un milione) molto diverse fra loro, provenienti da repository molto diversi. Questo porta a repository a lavorare a un livello di astrazione altissimo il che crea solamente un caos generale che rende impossibile trovare qualsiasi cosa si voglia cercare. Anche a causa alle poche possibilità di scelta. Per l'indicizzazione si basa sul Generatore SamgI (sarà spiegato più avanti nel dettaglio) il quale lavora ad un livello di astrazione alto, non permettendo cosi ricerche riguardanti materie, argomenti e dettagli specifici molto importanti in un Learning Object. Come si può notare tutti questi repository presentano sia dei pregi sia dei difetti, non ho trovato ancora un repository per cosi dire perfetto da poter prendere come esempio, ma mi forniscono grandi spunti per l'implementazione del mio progetto, che ovviamente non intende, essere migliore dei repository già citati, ma ho fatto del mio meglio per renderlo il più funzionale e usabile possibile. Ho portato questi 4 repository come esempio perché rappresentano tutti i possibili approcci seguibili, difatti molti degli altri repository esistenti sono realizzati sono molti simili a quelli presentati. Analizzandone vantaggi e svantaggi possiamo affermare che esiste una regola che dice che più informazioni si richiedono più la ricerca e la classificazione sarà precisa, ma più noioso e difficile sarà il repository da utilizzare. Per la creazione del mio repository cercherò quindi di trovare un giusto bilanciamento, cercando di prendere il meglio da ogni repository analizzato.

16 Generazione dei Metadati per Learning Object In questo capitolo parleremo di come il repository genererà i metadati associati a ogni Learning Object, e discuteremo dei valori più importanti da considerare per una buona classificazione. Questo è necessario perché ogni Learning Object necessità d informazioni (meta-dati) in modo da poterlo classificare e inserire nell ambiente cui esso appartiene. Ad esempio data una presentazione multimediale è necessario conoscere chi l ha creata, di che argomento tratta, chi è il target di questa presentazione ecc... tutte queste informazione sono i meta-dati associati all'oggetto. La procedura per la loro generazione ha i seguenti requisiti per essere efficiente ed efficace: Deve generare meta-dati corretti e il più possibile completi e consoni per una corretta ricerca. Non deve causare all'utente uno spreco di tempo. Com è noto a nessun utente piace perdere tempo a inserire manualmente i meta-dati In quanti si tratta di una procedura noiosa. Per far questo ho scelto di utilizzare il tool SamgI di Ariadne, un generatore automatico di meta-dati il quale dato un file in input cerca di estrarre la maggior quantità d informazioni possibili. Presentano pero i seguenti problemi: 1. Non tutti i formati sono supportati 2. Presenta qualche errore di estrazione 3. Mancanza di alcune informazioni Questa mi porta ad adottare un approccio misto, che riesca a fondere la generazione automatica con un supporto manuale, in modo da richiedere poco tempo all'utente e di

17 porre rimedio ai limiti della generazione automatica. L'idea base di questo approccio è di creare una generazione assistita di meta-dati In pratica cercherò di affidare all'utente solo una funzione di controllo della correttezza dei meta-dati generati, e nel caso di errori o d impossibilità di generare automaticamente alcune informazioni di primaria importanza cercherò di mettere l'utente nelle condizioni di inserire questi dati nel modo più semplice veloce ad automatico possibile, supportandolo con suggerimenti, menu a scelta rapida e cosi via. Esistono dei formati standard per la creazione di questi meta-dati, io ho scelto di seguire il formato LOM (Learning Object Metadata) giacché è il meglio supportato da SamgI e a mio parere il più completo e specifico per le necessità del mio progetto. Tipo Oggetto: Questa informazione descrive di che tipo di oggetto si tratta. Ad esempio: Presentazione, Pdf, Immagine, Ecc... questo metadato può essere estratto in modo automatico in base all'estensione del file. Nel caso di estensioni sconosciute o di file applicativi verrà chiesto all'utente di inserire manualmente questo campo. Per rendere questo più efficiente l'applicazione sarà capace di imparare nuove estensioni quando un oggetto sconosciuto sarà descritto. Ci sono situazioni, come ad esempio documenti html generati da una servlet che sono disponibili sul web senza estensione. Queste situazioni sono gestite analizzando l'url e riconoscendo le servlet. Materia: Estrarre la materia in modo automatico non è semplice, e il generatore automatico non mi aiuta molto, pero per cercare di individuarla si può procedere nelle seguenti direzioni: A) In base alle informazioni sull'autore: per esempio se abbiamo altri oggetti con lo stesso autore, i quali riguardano tutti lezioni di storia, è consono ipotizzare che si tratti anche questa di una lezione di storia.

18 B) In base alle informazioni su chi inserisce tale oggetto: per esempio se chi inserisce quest oggetto, è un professore di matematica si può ipotizzare che si tratti di una lezione di matematica, oppure se l'utente in precedenza ha inserito lezioni di storia, potrebbe trattarsi di una lezione di storia. C) Cercando nel titolo, parole chiavi e descrizione: in queste parti del testo in alcuni casi è possibile trovare informazioni che riguardano le materie. Ovviamente se questo porta a un risultato errato, è compito dell'utente correggerlo cambiando la materia o aggiungendone una nuova. Argomento: si tratta di un punto specifico della materia, il quale potrebbe essere anche condiviso fra più materie, ad esempio un personaggio storico presente sia in letteratura sia in storia dell'arte. Per ricavare questa informazione è necessario un approccio simile a quello per la materia. Target: A chi è rivolta la lezione: studenti di scuola elementare, medie, superiore ecc... Per completare questo metadato è possibile inserire un menu a scelta rapida con le varie opportunità, inizializzato col valore suggerito, ricavato in base alle informazioni che si hanno sull'autore dell'oggetto. I target potrebbero essere: Tutti, Asilo, Elementare, Medio, Superiore, Università. Keywords: Parole chiave della lezione, sono estratte direttamente dal generatore, si potrebbe chiedere all'utente un loro controllo di correttezza.

19 Per i dati di minor importanza lascerò solamente una generazione automatica, poiché far perdere all'utente troppo tempo è più dannoso di qualche informazione incompleta, giacché porterebbe l'utente a non inserire il Learning Object. Organizzazione del Repository Architettura In questo capitolo parleremo di com è stato costruito il repository, analizzando le varie parti che lo compongono e approfondendo le tecnologie con le quali è stato implementato. Per prima cosa è necessario spiegare che il repository è stato realizzato come un applicazione stand-alone, cioè viene eseguito come un normale programma, questo per dare una grande semplicità e facilità d installazione. Cosi facendo hanno la massima flessibilità: potrà essere cosi installato su un server di una scuola, su un computer locale di un docente o anche su un server in internet. E comunque possibile, per chi volesse, eseguire il respository in un normale web container. Analizzando l'applicazione possiamo affermare che è composta di 5 parti principali: Core: Si occupa di gestire tutte le richieste e le operazioni, interagendo con le altre parti. Metadata Generator: E il motore SamgI per la generazione automatica dei metadati XML Database: Database nel quale sono memorizzati i metadati, in formato XML secondo lo standard LOM. SQL Database: Database nel quale sono memorizzate in modo relazionale le informazioni sugli utenti e su quanto gestito dal respository. Interfaccia Web: interfaccia realizzata attraverso un sito web per interagire col repository.

20 Il core e SamgI sono delle web application e devono essere eseguite in un Web Container, per questo ho scelto di utilizzare Embedded Glassfish, non richiedendo all'utente finale l'installazione e la conoscenza di un Web Server. Lo schema che rappresenta come queste parti interagiscono fra loro e come il tutto è strutturato è il seguente: Approfondiamo le parti fondamentali: Core Nel core si concentra la logica di funzionamento del repository stesso, e fornisce tutti i vari servizi e operazioni che sono necessarie nel repository. Le operazioni fondamentali sono: Gestione degli Utenti Gestione dei Metadati Ricerca Suggerimenti per il completamento dei metadati Scambio di dati con gli altri repository.

21 Tutto è realizzato in java, e in modo specifico tramite l'utilizzo degli EJB, e ad alto livello ogni parte fondamentali è in generale organizzata su uno schema a 3 livelli in modo da ottenere un buon livello di astrazione fra logica di funzionamento e implementazione: Al livello superiore c'è per ogni servizio fondamentale un Bean che fornisce l'interfaccia di funzionamento, la quale ha lo scopo di essere utilizzata direttamente dall'applicazione web. Questi Bean per la maggior parte delle operazioni si appoggiano su altri EJB che forniscono le interfacce per l'accesso e la modifica dei dati, i quali a loro volta utilizzano degli Entity Bean per l'accesso diretto ai dati, oppure a classi che nello stesso modo ne forniscono un interfaccia, come il gestore del database XML e di SamgI. In pratica l'applicazione è stata realizzata seguendo e utilizzando il semplice pattern chiamato Facade che letteralmente significa "facciata" e indica un oggetto che permette, attraverso un'interfaccia più semplice, l'accesso a sottosistemi che espongono interfacce complesse e molto diverse tra loro, nonché a blocchi di codice complessi. Prima di addentrarci nel particolare di ogni servizio approfondiamo le tecnologie scelte e utilizzate nella creazione del repository: Tecnologie Utilizzate EJB Gli Enterprise Java Bean (EJB) sono i componenti che implementano, lato server, la logica di business all'interno dell'architettura Java EE. Nel mio caso realizzano il core del repository, cioè il nucleo, ho scelto questa tecnologia perché fornisce automaticamente molte caratteristiche utili a una veloce e solida implementazione, tra

22 cui la persistenza, il supporto alle transazioni, la gestione della concorrenza e della sicurezza l'integrazione con altre tecnologie, come i Web Services. Lo standard attuale è EJB 3. Inoltre è una tecnologia ideale per il mio progetto poiché le specifiche EJB intendono fornire una metodologia standard per implementare la logica di funzionamento delle applicazioni di tipo enterprise, cioè che forniscono servizi via internet. Per realizzare applicazioni di questo tipo è necessario affrontare una serie di problematiche tecniche che possono rivelarsi molto complesse e laboriose da risolvere. Alle quali gli EJB intendono fornire una soluzione a questi problemi in modo da semplificare lo sviluppo di questo tipo di applicazioni. Le specifiche EJB descrivono in dettaglio come realizzare un applicazione server che fornisca le seguenti funzionalità: Persistenza Elaborazione delle transazioni Controllo della concorrenzialità Servizio di directory per elencare e nominare gli EJB (JNDI) Sicurezza Installazione di componenti software in un application server Invocazione di procedure remote tramite l'utilizzo di CORBA Fornire servizi Web Non tutte queste funzionalità sono utilizzate nel mio core, ad esempio l'unita che si occupa della persistenza è utilizzata per il salvataggio dei dati riguardanti gli utenti, ma anche per le materie e gli argomenti, cosi come per tutti gli altri dati che hanno bisogno di essere salvati: ad esempio i possibili livelli di difficoltà di una lezione o i tipi di applicazione che SamgI può gestire e analizzare. Non ho bisogno di JMS o di CORBA, pure le transazioni e la concorrenzialità non sono molto importanti in questo progetto, poiché non si tratta di operazioni critiche nelle quali un errore di questo genere può causare seri problemi.

23 Invece utilizzo i Servizi Web per realizzare un software distribuito, e anche JNDI per richiamare gli EJB dall'interfaccia Web. Esistono tre tipi di EJB: EJB di Entità (Entity EJB): il loro scopo è di inglobare gli oggetti sul lato server che memorizzano i dati. Gli Entity Bean forniscono la caratteristica della persistenza. Sono usati nel core per rappresentare gli utenti, le materie, gli argomenti e salvare i loro dati in modo persistente su un DB. EJB di sessione (Session EJB): gestiscono l'elaborazione delle informazioni sul server. Generalmente sono un interfaccia tra i client e i servizi offerti dagli elementi disponibili sul server. Ne esistono di due tipi: Con stato (stateful). I Bean di sessione con stato sono oggetti distribuiti che possiedono uno stato. Lo stato non è persistente, però l'accesso al Bean è limitato a un unico client. Questo tipo di Bean non è utilizzato pero nel mio progetto, poiché ho preferito utilizzare solamente Bean stateless e gestirmi autonomamente le sessioni e lo stato delle operazioni attraverso normali classi java, perché non richiedevo le caratteristiche di un EJB, dato che sia la sessione sia le operazioni possibili sono semplici e senza particolari problemi di concorrenza e di sicurezza. Senza stato (stateless). I Bean di sessione senza stato sono oggetti distribuiti senza uno stato associato, questa caratteristica permette un accesso concorrente alle funzionalità offerte dal Bean. Non è garantito che il contenuto delle variabili d istanza si conservi tra diverse chiamate ai metodi del Bean. Questo tipo di Bean è utilizzato per implementare tutte le principali funzionalità offerte dal core, dalla gestione degli utenti alla ricerca. EJB guidati da messaggi (Message driven EJB): sono gli unici Bean con funzionamento asincrono. Tramite il Java Message Service (JMS), s iscrivono a un argomento (topic) o a una coda (queue) e si attivano alla ricezione di un messaggio inviato all'argomento o alla coda cui sono iscritti. Non richiedono un istanziazione da parte dei client. Questi Bean non sono presenti nel repository.

24 Per realizzare un software che sia distribuito, ho utilizzato dei Web Service Basati su session Bean stateless che permettono alle varie istanze del repository di comunicare fra loro attraverso internet. Web Services Un Web Service è un sistema software progettato per supportare l'interoperabilità fra diversi elaboratori di una medesima rete. Caratteristica fondamentale di un Web Service è di offrire un'interfaccia software (descritta in un formato automaticamente elaborabile quale, ad esempio, il WSDL) utilizzabile da altri sistemi, nel mio caso un altra istanza del repository può interagire con il Web Service stesso attivando le operazioni descritte nell'interfaccia tramite appositi "messaggi" inclusi in una "busta": tali messaggi sono, trasportati sul protocollo HTTP, quindi viaggiano sulla porta 80, solitamente aperta in tutti i router e le reti. Questo è stato uno dei motivi che mi hanno fatto preferire i Web Service a sistemi operativo quali CORBA, i quali non lavorano attraverso la porta 80. Tutti i messaggi fra i WS sono formattati nel formato XML. Quando mi si è presentata la necessità di scambiare messaggi complessi fra i Web Service ho creato un Xschema che definisse il formato corretto del messaggio scambiato e ne permettesse un miglior parsing. L'elenco dei vantaggi di un utilizzo dei Web Service è il seguente: Sono indipendenti dalla piattaforma sulla quale sono eseguiti. I protocolli sono open e in formato testuale, cosa che li rende di più facile compressione e utilizzo. Funzione mediante HTTP, non richiedendo modifiche alle regole del firewall. Possono essere facilmente utilizzati in combinazione l'uno con l'altro per creare servizi complessi. Gli svantaggi sono principalmente legati a prestazioni generiche peggiori rispetto a RMI e CORBA.

25 Database XML Tutti i meta-dati, descritti nel formato LOM, sono contenuti in un file di tipo xml, quindi il modo migliore e più semplice per effettuare operazioni su di essi, quali modifiche, ricerche, inserimenti e cancellazioni è di gestirli attraverso un database XML. Io ho scelto di Utilizzare BaseX, BaseX è un database gratuito, molto leggero e con ottime performance, il quale implementa uno Xpath e Xquery processor molto avanzato, comprendendo tutte le nuove specifiche W3C per l'update e specialmente per la ricerca full text all'interno dei contenuti, parte fondamentale nella mia applicazione. Schematizzando le caratteristiche di BaseX sono: é un database XML completo di ottime prestazioni. Offre un efficiente e completo supporto per Xpath Xquery. Ha un architettura client server con transazioni, logging e controllo della sicurezza. Offra numerosi API: REST/JAX-RX, XQJ, XML:DB. E possibile integrarlo in un progetto attraverso la versione embedded. Nel repository il database XML è stato integrato con la creazione di un piccolo software che si occupa della sua installazione, avvio e gestione, la quale è richiamato al momento dell'avvio del repository stesso. Il metodo di comunicazione fra il core e il Database si basa attraverso le API JAX-RX, che in pratica sono un insieme di chiamate HTTP. Ogni operazione richiesta al database dipende dal tipo di richiesta HTTP effettuata: Per spiegare meglio questo funzionamento supponiamo che il Database sia attivo ed in ascolto all'indirizzo ogni richiesta inviata a questo indirizzo web locale sarà una operazione effettuata sul database. Metodo GET: A richieste di tipo GET sono associate delle query Xpath oppure Xquery la quali devono essere inserite come parametro di nome query. Ad esempio la query: Ritornerà tutti i nodi di nome LOM presenti all'interno del database repositorydb.

26 Questo metodo per eseguire le query però è disordinato e scomodo specialmente se si utilizza Xquery, mentre è molto semplice se si utilizza Xpath. Fortunatamente anche il metodo post permette di inviare query al database. Metodo POST: Attraverso il metodo POST è possibile eseguire 2 tipi di operazioni distinte sul database: inviare query o comandi. Per inserire una query si dovrà inserire nel corpo del messaggio un testo XML nella seguente forma: Ritorna 5 titoli dei LO presenti nel database. <query xmlns=" <text>for $l in //LOM return $l/title</text> <parameter name="count" value="5"/> <parameter name="output" value="indent=no"/> </query> Questo modo per scrivere risulta, a mio parare più ordinato e comprensibile. Nello stesso modo è possibile inviare comandi al database. Esempio: <command xmlns=" <text>show users</text> <parameter name="wrap" value="no"/> </command> Questo comando mostra tutti gli utenti del database. Metodo PUT: Tramite questo metodo si può creare un nuovo database o aggiungere elementi a esso. Ad esempio per creare un nuovo database di nome Test basterà inviare una richiesta di tipo PUT all'url Se invece si volesse aggiungere un documento XML al database, è necessario inviare una richiesta alla stessa URL, con il documento XML contenuto nel body della richiesta.

27 Nello stesso modo, attraverso il metodo DELETE si compie l'operazione inversa. L'update dei dati si effettua attraverso il metodo POST e un operazione Xquery Update. Utilizzo del Database XML nel Core: Per effettuare tutte queste operazioni ho scritto un Enterprise Bean di tipo singleton che si occupa di gestire la comunicazione e tutte le operazioni da e per il database, fornendo una semplice interfaccia per le operazioni descritte in precedenza, in modo tale da poter effettuare insert, delete, e query senza conoscere nulla del database. Database Relazionale Per mantenere le informazioni riguardanti gli utenti, e le altre informazioni che devo essere memorizzate dall'applicazione ho scelto di utilizzare un database relazionale. Dopo aver preso in considerazioni i più comuni database quali MySQL, Postgree ecc., la mia scelta è ricaduta su Apache Derby, detto anche Java DB, per il fatto di essere molto leggero e già integrato in java. In questo il server ospitante il repository non deve preoccuparsi di installare e configurare il database. Lo svantaggio è che Derby non ha le performances degli altri database ma dato che la mole di dati che deve gestire non è di grandezza critica questo non è un problema. Inoltre il tipo di database è completamente separato dall'implementazione del core attraverso una persistence unit. Modificando la Persistence Unit è possibile cambiare a piacimento il database senza dover modificare minimamente il codice sorgente del core. Questo è lo schema delle tabelle presenti nel database.

28 NextMetadataID: questa semplicissima tabella possiede solo una riga contenente l'id da assegnare al prossimo LO che verrà inserito, in quanto il database XML non ha un sistema di gestione automatico degli id, ed è necessario garantire che ogni LOM inserito nel database sia univoco. Type: contiene tutti i possibili tipi MIME utilizzabili nel repository. Questa lista è dinamica e potrebbe espandersi nel caso SamgI riconosca nuovi tipi di applicazioni non ancora inseriti o utilizzati nel repository. È inizializzata con dei valori standard durante la prima esecuzione del repository. Es: Pdf, doc, html e altri vari Mime Type. Target: questa tabella, inizializzata alla prima esecuzione del repository, contiene tutti i possibili target di una lezione. Ad esempio Elementare, Medie, Superiori ecc...

29 User: Contiene le informazioni riguardanti un utente registrato, con dei puntatori alla materia preferita e al target preferito per le sue lezioni. Subject e Topic: Sono tutte le materie che posso essere scelte nel repository con una relazione N a N con i possibili argomenti di una materia. Generatore di Metadati Il generatore di metadati (AMG) è un software open source nato nel 2005 pensato per indicizzare la notevole massa di oggetti educativi di cui Ariadne poteva disporre; analizzandone il contenuto e creando dei metadati. E stato realizzato da sotto la guida di Erik Duval professore e ricercatore presso l'università cattolica di Lovanio (Belgio) nonché presidente di Ariadne e membro del consiglio IEEE LTSC (Il gruppo che si occupa dei Learning Object Metadata). Si può certamente considerare come una delle più importanti e influenti persone dell'ambito dei Learning Object. SamgI è completamente realizzato in Java ed è composto di una serie di piccoli generatori interni che si occupano dei vari ambiti da analizzare. Si basa su Apache Lucene per l'estrazione e la ricerca dell informazione dai vari testi.

30 Estrattore: Come prima cosa il generatore cerca di estrarre il testo dai vari documenti, quali doc, pdf ecc... per questo sono stati realizzati degli estrattori i quali analizzando un generico file ne estraggono il testo e le proprietà. Generatori Successivamente entrano in azioni i vari generatori di metadati tra i quali possiamo citare un Generatore d informazioni riguardanti il Mime, uno riguardante le Keyword, Titolo, Descrizione e anche informazioni base come durata dimensione. Nonostante funzioni in un modo discreto, presenta dei limiti, che non permettono una descrizione accurata del metadato. Non tutti i file sono supportati: da alcuni tipi di file è oggettivamente molto difficile estrarre numerose informazioni, quali immagini, archivi e file eseguibili.

31 Se pensiamo a questi tipi di file, risulta impossibile estrarre informazioni significanti in modo automatico, anche perché potrebbe essere presenti nel codice o magari non esserci per niente. Impossibilità di Estrarre Alcune informazioni: di vitale importanza per una buona classificazione sono la materia e l'argomento, purtroppo queste informazioni molte volte non sono nemmeno contenute nel file, inoltre in AMG non esiste un sistema che definisca cosa è una materia e cosa è un argomento, per questo, queste informazioni, come altre non posso essere generate automaticamente. Errori di Estrazione: può anche succedere che a volte AMG estragga delle informazioni che non sono realmente corrette, poiché credo si basi su metodi probabilistici per definire alcune informazioni. Complessivamente analizzando i vantaggi e i difetti di questo generatore posso affermare che fornisce una buona descrizione globale dell'oggetto, la quale pero è insufficiente quando si scende più nel dettaglio, il quale deve essere inserito manualmente da un utente che conosce a fondo la risorsa. Nel progetto il repository è eseguito come un applicazione web che fornisce delle servlet per l'analisi di Learning Object. Il core quindi esegue una connessione http locale per comunicare col generatore. Questo è dovuto al fatto che la distribuzione più stabile e meglio funzionante che ho trovato di SamgI era quella fornita tramite un file war dai creatori stessi. Il generatore è avviato subito prima del caricamento del repository sullo stesso server web. Funzionamento del Repository Gestione degli Utenti

32 L'utente ha un ruolo centrale nel repository, e questo schema mostra ciò che un utente può fare: L'interfaccia per la gestione degli utenti è fornita dal Session Bean UserManager, il quale mette a disposizione tutte le possibili operazioni quali login, log out, registrazione, modifica dati ecc... Le politiche adottate per la gestione e la sicurezza degli utenti sono le seguenti: La registrazione richiede solamente nome utente, password e indirizzo , tutte le altre informazioni potranno essere inserite in seguito, cosi facendo si permette una registrazione veloce e senza problemi. Il nome utente è un dato univoco e permanente, una volta registrati non sarà più possibile cambiare il proprio nome utente. Le password è salvata in maniera criptato nel database, in tal modo nessuno può conoscere la password di un altro utente nemmeno se ha accesso al database.

33 Al momento del login è creata una sessione per ogni utente la quale è gestita internamente in modo molto leggero tramite una tabella degli utenti loggati. Ogni volta che un utente esegue un operazione, deve fornire l'id che le e stato assegnato durante il login, questo id viene controllato e se non è corretto l'operazione non è consentita. I dati degli utenti sono salvati nel database e gestiti dal rispettivo Entity Bean User in quale si occupa automaticamente della gestione della persistenza e della tabella. Gestione dei Meta-dati Questa parte riguarda principalmente la generazione di meta-dati, il salvataggio nel database e la loro cancellazione. Generazione Quest operazione è fondamentale nel repository e viene suddivisa in 3 distinte fasi le quali hanno bisogno dell interazione dell'utente: Generazione Automatica: In questa prima fase viene analizzato dal Generatore SamgI il Learning Object che dovrà essere inserito nel repository, ottenendo cosi una prima grezza versione. La quale è salvata in sessione in attesa di essere raffinata nella seconda fase. Completamento In questa seconda fase vengono arricchiti i meta-dati generati automaticamente, attraverso un inserimento e modifica dei campi ritenuti più importanti quali: Titolo, Parole Chiave, Materia e Argomenti, Tipo di File, Target, Licenza e tipo di lezione. Per aiutare l'utente nella scelta e nel complemento sono forniti automaticamente dei suggerimenti attraverso un apposito sistema implementato nel Suggest Bean il quale fornisce, per ognuno dei principali campi da analizzare alcuni suggerimenti e aiuti:

34 Titolo: Ho pensato che i possibili titoli che il Learning Object può avere si possono estrarre in 2 modi: Il primo e solitamente più corretto è il titolo che viene estratto dal generatore analizzando il LO, ma non sempre è possibile, per questo, viene anche inserito come suggerimento il nome del file, opportunamente formattato e ripulito dell'estensione. Esempio: un file di nome La_dinastia_Carpentigia_di_Francia.pdf diverrà: La dinastia Carpentigia di Francia In molti casi quanto viene suggerito tramite questi 2 modi è corretto, negli altri casi sarà compito dell'utente scrivere un titolo consono. Targhet, Tipo di Lezione Materia ed Argomenti Questi dati possono essere accomunati perché presentano circa le stesse problematiche e caratteristiche e sono informazioni che non possono essere individuate in nessun modo dal generatore automatico. Per questo i suggerimenti si compongono nel seguente modo: Dapprima viene suggerito il valore di default per l'utente, successivamente sono inseriti gli altri valori, in base alla loro frequenza di utilizzo da parte dell'utente e in generale negli altri meta-dati inseriti. Per il tipo di lezione inoltre viene analizzata l'estensione e associata all'evento più probabile, ad esempio se si tratta di un file di testo è probabile che la lezione sia una lettura, se è un foglio elettronico potrebbe trattarsi di un esercitazione, se è una presentazione potrebbe essere una lezione per l'autoapprendimento o di un esposizione in classe e cosi via. Keywords Le keyword vengono estratte automaticamente dal generatore, per questo all'utente è solamente chiesto di controllare quanto già estratto, dando la possibilità di inserirle o cancellarle in modo di avere un controllo di qualità delle stesse. Tipo di applicazione Questa informazione è estratta dall'estensione del file, in ogni modo è stato necessario valutare la possibilità che siano inseriti elementi con estensione sconosciuta al

35 repository, per questo dapprima viene suggerito il tipo (MIME) rilevato dall'applicazione, ma vengono anche resi disponibili altri formati per la scelta dell'utente. Casi particolari: esiste un caso particolare ed è dato da risorse che sono generate dinamicamente da servlet web. Questa situazione è stata gestita identificando le servlet e analizzando quanto sa esse generato. Questi metodi per i suggerimenti possono sembrare molto grezzi ma questo è dovuto principalmente al fatto che un LO può essere qualsiasi cosa, da un video a una presentazione o a widget per sankore, questo porta a lavorare a un altissimo livello di astrazione rispetto alla risorsa non avendo idea di che cosa si tratti. Ovviamente se si trattasse di un repository per soli file Pdf, si potrebbe pensare di analizzare il file e fornire suggerimenti molto più esatti e complessi. Inserimento L'inserimento consiste nell'aggiunta dei meta-dati nel database XML, associando a ognuno di essi un id e un riferimento all'utente in modo da garantirne l'unicità. In questa fase viene anche gestita l'url alla risorsa con una distinzione fra risorse locali e remote. L'indirizzo alla risorsa locale varia se cambia l'indirizzo IP del repository. Ma una risorsa deve essere sempre disponibile e utilizzabile, per questo ad ogni indirizzo locale verrà associato un pattern il quale indica che ogni volta che viene richiesta quella risorsa l'url deve essere trasformato in un indirizzo che punta alla macchina locale. Per risorse remote invece non può eseguita nessuna operazione e viene utilizzato l'url inserito durante la fase di generazione.

36 Licenza: Ai Learning Object presenti nel repository posso essere assegnate 2 tipi di licenza diversi: Licenza pubblica: Con questa licenza di tipo creative commons una risorsa diventa pubblica e aperta a tutti e tutti gli utenti che vogliono utilizzarla devono seguire le seguenti direttive imposte dalla licenza: Si è liberi di: Riprodurre Distribuire Comunicare al pubblico Esporre in pubblico Rappresentare Eseguire e recitare quest'opera Modificare quest'opera Alle seguenti Condizioni: Devi attribuire la paternità dell'opera nei modi indicati dall'autore o da chi ti ha dato l'opera in licenza e in modo tale da non suggerire che essi avallino te o il modo in cui tu usi l'opera. Non puoi usare quest'opera per fini commerciali. Se alteri o trasformi quest'opera, o se la usi per crearne un'altra, puoi distribuire l'opera risultante solo con una licenza identica o equivalente a questa. Prendendo atto che: E' possibile rinunciare a qualunque delle condizioni sopra descritte se ottieni l'autorizzazione dal detentore dei diritti. Nel caso in cui l'opera o qualunque delle sue componenti siano nel pubblico dominio secondo la legge vigente, tale condizione non è in alcun modo modificata dalla licenza.

37 La licenza non ha effetto sui seguenti diritti: Le eccezioni, libere utilizzazioni e le altre utilizzazioni consentite dalla legge sul diritto d'autore; I diritti morali dell'autore diritti che altre persone possono avere sia sull'opera stessa che su come l'opera viene utilizzata, come il diritto all'immagine o alla tutela dei dati personali. Licenza Privata: Con questa licenza il Learning Object resta confinato all'interno del repository e solamente gli utenti registrati a esso potranno accedervi e utilizzarla e si è liberi di: Riprodurre Comunicare al pubblico Esporre in pubblico Rappresentare Eseguire e recitare quest'opera Modificare quest'opera Alle seguenti Condizioni: L'opera, può essere utilizzata, esposta, eseguita solamente all'interno del contesto nel quale il repository si riferisce, ad esempio se si tratta di un repository di Learning Object per l'università di Trento l'opera potrà essere utilizzata solamente all'interno ditale università, e non ci potrà essere nessun utilizzo al di fuori di tale contesto. Devi attribuire la paternità dell'opera nei modi indicati dall'autore o da chi ti ha dato l'opera in licenza e in modo tale da non suggerire che essi avallino te o il modo in cui tu usi l'opera. Non puoi usare quest'opera per fini commerciali. Se alteri o trasformi quest'opera, o se la usi per crearne un'altra, puoi distribuire l'opera risultante solo con una licenza identica o equivalente a questa. Prendendo atto che:

38 E' possibile rinunciare a qualunque delle condizioni sopra descritte se ottieni l'autorizzazione dal detentore dei diritti. Nel caso in cui l'opera o qualunque delle sue componenti siano nel pubblico dominio secondo la legge vigente, tale condizione non è in alcun modo modificata dalla licenza. La licenza non ha effetto sui seguenti diritti: Le eccezioni, libere utilizzazioni e le altre utilizzazioni consentite dalla legge sul diritto d'autore; I diritti morali dell'autore diritti che altre persone possono avere sia sull'opera stessa che su come l'opera viene utilizzata, come il diritto all'immagine o alla tutela dei dati personali. Ricerca: Sono stati implementati 2 tipi di ricerca: Semplice e Avanzata. Ricerca Semplice: Consiste nel ricercare i LO secondo una parola o un insieme di parole, e si basa su una ricerca di tipo full text scegliendo quelli che contengono la parola ricercata. Per aumentare la possibilità di successo la ricerca è di tipo fuzzy, questo significa che viene fatta anche una ricerca approssimata della parola ricercata, in modo da essere flessibile a errori di scrittura da parte dell'utente, o a parole che potrebbero essere scritte al plurale invece che al singolare ecc. Questa ricerca approssimata è basata sulla distanza di Levenshtein, dove il massimo numero di errori permessi in una stringa è calcolato dividendo la lunghezza della stringa per 4, preservando pero un minimo di 1.

39 L'ordinamento di questi risultati tiene conto di quante volte la parola ricercata compare all'interno del meta-dato. Approfondimento distanza di Levenshtein La distanza di Levenshtein, o distanza di edit, è una misura per la differenza fra due stringhe. Introdotta dallo scienziato russo Vladimir Levenshtein nel 1965, serve a determinare quanto due stringhe siano simili. La distanza tra due stringhe A e B è il numero minimo di modifiche elementari che consentono di trasformare la A nella B. Per modifica elementare s intende La cancellazione di un carattere, La sostituzione di un carattere con un altro L'inserimento di un carattere. Per esempio, per trasformare "bar" in "biro" occorrono due modifiche: 1. "bar" -> "bir" (sostituzione di 'a' con 'i') 2. "bir" -> "biro" (inserimento di 'o') Ricerca Avanzata Questo tipo di ricerca è più complesso, e permette, oltre ad inserire una parola di ricerca full text di scegliere direttamente molte caratteristiche del LO, quali target, materia e argomenti, tipo di applicazione e tipo di lezione. Nell'esecuzione di questa ricerca vengono analizzati i campi specifici di ogni LOM e sono confrontati con quanto scelto dall'utente. Search Options Queste informazioni sono fondamentali per la ricerca avanzata e servono per fornire all'utente le possibili scelte sulle quali potrà effettuare una ricerca avanzata. Ad esempio se nel repository sono presenti 3 lezioni pdf e 1 widget per Lavagne Interattive nella scelta del tipo di applicazione ci sarà:

40 Esempio di Search Options riguardanti il tipo di file. Questi valori tengono conto anche di quanto è presente negli altri repository attraverso un protocollo distribuito con il quale vengono scambiate queste informazioni. Il risultato viene poi filtrato in base alle licenze, così un utente registrato vedrà le opzioni riguardanti tutti i learning Object, mentre un utente non registrato vedrà solo quelle riguardanti i learning object con licenza pubblica. Cosi facendo ogni utente vede informazioni corrette e si riduce cosi la possibilità di effettuare ricerche con risultato nullo. La gestione e generazione di queste informazioni è gestita dall'enterprise Bean SearchOptions il quale si occupa di creare queste informazioni analizzando il proprio database e cercando quelle dei repository a esso collegati. Generare queste informazioni è un operazione complessa che richiede del tempo, per questo è stato implementato un sistema di caching che le memorizza e le aggiorna quando necessario, es: cancellazione o inserimento di un nuovo LO, e a tempo per quanto riguarda le informazioni contenute negli altri repository.

41 Funzionamento Software Distribuito Per far sì che i repository possano comunicare fra loro, in modo da favore lo scambio di Learning Object fra le varie istanze e permettere una miglior disponibilità e diffusione delle risorse è stato pensato di realizzare il repository in maniera distribuita. I repository sono stati cosi organizzati in maniera gerarchica realizzando un albero dove ogni elemento può avere un solo padre e un numero illimitato di figli. Non esiste un repository server, ma sono tutte istanze identiche, le quali si occupano sia da fare da padre ai propri figli, che da figlio al proprio padre, cosi facendo non sono necessarie implementazioni differenti in base alla posizione gerarchica. Esempio di Albero dei Repository All'avvio ogni repository tenta una connessione al padre. Se questa connessione dovesse fallire, sarà riprovata a intervalli di 10 minuti, inoltre ogni repository è sempre in ascolto delle richieste di connessione di un figlio. Livelli di astrazione: Ogni istanza comunica solamente con il proprio padre e i figli, tutti gli altri sono nascosti poiché la comunicazione con quei repository è gestita in modo trasparente dal padre o dal figlio. In tal modo un repository non deve conoscere tutta la topologia della

42 rete distribuita, ma comunica solamente con i suoi vicini i quali a loro volta si faranno carico di comunicare con i loro vicini e cosi via. Per esempio nell'esecuzione di una query distribuita il repository invia la richiesta al padre i ai figli i quali faranno lo stesso estendendo cosi la query a tutta la rete di repository, facendo sempre attenzione a non creare cicli i quali porterebbero a uno stallo del sistema. I risultati di una ricerca sono combinati con quelli degli altri repository creando il risultato finale. Questo tipo d implementazione è semplice ma porterebbe ad avere scarse performances in caso di una rete con molti nodi, e a mancanza di dati nel caso una delle istanze dovesse andare off line. Quindi nel caso la rete dovesse espandersi, sarebbe meglio modificare questa implementazione con una centralizzata che sarà discussa nel prossimo paragrafo. Possibile altra implementazione: Centralizzazione Un'idea per sopperire ai limiti dell'implementazione completamente distribuita è quella di centralizzare tutti i Learning Objects pubblici nella radice, in questo modo nei repository figli restano solamente i LO privati che non devono uscire da esso, mentre quelli pubblici sono copiati dal padre, in quale ne acquisisce i compiti di gestione. Cosi facendo si avrebbe un grande repository centrale il quale gestisce tutte le risorse pubbliche. Le query verrebbero cosi effettuate su un solo repository, e non su un numero pari alla grandezza della rete riducendo di molto i tempi. Inoltre in caso di caduta di un nodo le risorse resterebbero comunque disponibili.

43 Interfaccia Web Si tratta di un sito web realizzato per permettere l'utilizzo del repository con le tecnologie JSF 2.0 e Ajax. L'interfaccia permette di registrarsi, gestire il proprio account, inserire e ricercare i Learning Object, ed è pensata per essere il più semplice e intuitiva possibile, rendondo tutte le operazioni semplici veloci e naturali. Iniziamo con un approfondimento riguardante le tecnologie e le scelte architetturali utilizzate: Framework: Lo scopo di un framework è di risparmiare allo sviluppatore la riscrittura di codice già steso in precedenza per compiti simili. In questo modo ho semplificato la realizzazione del sito web riducendone il tempo di sviluppo. Il principale framework utilizzato è JSF2 JSF: Jsf è una tecnologia java basata sul pattern architetturale Model-View-Controller (MVC). Il suo scopo è di semplificare lo sviluppo dell'interfaccia utente di una applicazione Web. Jsf prevede un ampio insieme di classi e relative API che permettono di: Definire i componenti dell interfaccia utente (UI), gestire il mantenimento del relativo stato e il verificarsi dei relativi eventi.

44 Semplificare il sistema di gestione della navigazione tra le pagine della web application; Realizzare dei componenti personalizzati (Custom Component), che estendano e potenzino le funzionalità delle classi base del framework; Supportare l internazionalizzazione e l accessibilità dell'applicazione. L'architettura di un'applicazione è stratificata su 3 livelli gerarchicamente crescenti. Alla base della gerarchia ci sono le servlet, mentre salendo troviamo il livello delle JSP e all'apice la tecnologia JSF. L'utilizzo di JSF facilita lo sviluppatore nel suo lavoro poiché consente di: Gestire eventi, basandosi su Java Beans; Utilizzare l EL (Expression Language) per la realizzazione del valuebinding e il method-binding, mediante il quale è possibile legare le proprietà dei componenti dell UI, rappresentati con tag nelle pagine, direttamente con la business logic. Analizzare il ciclo di vita di una richiesta, ben definito attraverso una serie di fasi, e recuperare in ogni istante le variabili d interesse per la logica dell'applicazione; Utilizzare i backing beans (managed beans) costituenti la business logic, con la possibilità di istanziarli in un qualsiasi momento on demand. In JSF 2 è pero possibile sostituire il livello di JSP con un livello più avanzato, che e facelets, permettendo cosi di realizzare pagine più ordinate ed efficienti: Quest opportunità di abbandonare JSP all'inizio mi è sembrata strana, in quando per abitudine da sempre sia dai corsi universitari sia da quelli alle superiori mi hanno sempre insegnato Java + JSP per realizzare un applicazione web dinamica. Ma Jsp ha sempre avuto dei limiti, che appaiono sempre più chiari nella realizzazione di applicazioni Web 2.0 quali in primo luogo l impossibilita di realizzare Template, ed anche altri problemi riguardanti il ciclo di vita di una pagina: Java Server Facies a differenza di JSP che processa gli elementi di una pagina nell ordine in cui questi appaiono, organizza i componenti in una complessa struttura ad albero.

45 Per questo è stato creato Facelets che risolve e migliora i seguenti aspetti riguardo a JSP: indipendenza dal web container compatibilità con qualsiasi versione JSF tempi di compilazione più veloci supporto per il templating supporto di Expression Language Le pagine di Facelets sono in formato Xhtml quindi sono well formed e non possono contenere codice come jsp ma solamente tag. Questa cosa le rende molto piu ordinate e comprensibili, inoltre migliora la distinzione fra visualizzazione e logica, riducendo cosi anche gli errori di programmazione. Framework per Ajax Questa è stata la parte più e difficile nella scelta dei framework, poiché esistono moltissimi framework tutti con diversi pregi e difetti. Io conoscevo già una libreria, con la quale avevo già grande familiarità e confidenza: RichFaces. Ho iniziato quindi a realizzare l'applicazione con richfaces, ma poi nei test ho notato che era troppo dipendente dall'ambiente di esecuzione. Quindi ho iniziato a testare altri framework per java e dopo numerose prove, ho scelto di utilizzare IceFaces, perché è il piu semplice da configurare e offre una maggiore portabilità fra i diversi container. IceFaces IceFaces è un framework open source che viene utilizzato dai programmatori Java EE per creare Rich Internet Application (RIA) usando il linguaggio Java. IceFaces sfrutta l'intero ecosistema di tool e ambienti di esecuzione basati su standard JavaEE. Permette di sviluppare applicazioni RIA con numerose caratteristiche sviluppate in Java senza bisogno di applet o plug-in proprietari da integrare nel

46 Browser. Le applicazioni IceFaces sono applicazioni JSF così che non ci sia bisogno dell'utilizzo di Java script, inoltre il meccanismo che sta alla base (Ajax) è completamente trasparente allo sviluppatore. Il cuore di IceFaces è formato da tre elementi: 1. Il Framework IceFaces Questo è un'estensione del framework standard JSF con la fondamentale differenza con cui è trattata la fase di rendering. Diversamente da JSF il rendering avviene nel DOM lato server e solo cambiamenti parziali sono lasciati al browser e in seguito assemblati con un bridge Ajax molto leggero. Il risultato è un render fluido, effettuato solo su certi elementi della pagina. Ajax utilizza le Api inizializzate dal server e integra il meccanismo similmente al cycle di JSF. 2. Il Bridge Ajax Presenta elementi lato server e lato client che coordinano la comunicazione (basata su Ajax) fra il browser del client e l'applicazione lato server. Il Bridge quindi si occupa di apportare i cambiamenti alla presentazione dalla fase di rendering al browser del client e del riassemblamento di questi cambiamenti nel DOM del browser per applicare i cambiamenti. Inoltre ha il compito di rilevare le interazioni dell'utente con la presentazione e di portare le azioni dell'utente indietro all'applicazione per essere processate dal JSF lifecycle. Un meccanismo chiamato partial submit è integrato nei componenti di IceFaces e facilita la generazione di eventi attraverso il bridge. La prima volta che la pagina viene caricata viene creato il bridge Ajax e coordina gli aggiornamenti della presentazione e la trasmissione degli eventi dell'utente per tutto il lifetime dell'applicazione. 3. La Suite di componenti di IceFaces La suite di componenti fornisce tutti i componenti per la costruzione dell'interfaccia grafica dell'applicazione. Include sia i componenti standard di Jsf e una vasta gamma di componenti che consente allo sviluppatore di costruire applicazioni sofisticate e dall'interfaccia intuitiva. Oltre al meccanismo succitato dell'interazione diretta con il DOM i componenti possono utilizzare un set di effetti come il drag and drop tutto ciò con la semplice modifica di attributi così che non si debba mai ricorrere a Java script.

47 Purtroppo non tutto IceFaces è libero, tutti i componenti base sono liberi e accessibili, invece alcuni componenti avanzati sono disponibili solo a pagamento, comunque con un po di pratica nei componente base è possibile ricrearsi numerosi componenti avanzati. Un altro punto di forza di IceFaces è la perfetta integrazione in NetBeans attraverso un estensione. In questo modo molte fasi d installazione e configurazione sono automatizzate rendendone semplice l'utilizzo e l'installazione. Per riassumere questo è lo schema a livelli dell'applicazione web: Presentation Tier Request Controller State Management Funzionamento delle parti principali dell'applicazione web: Registrazione: La form di registrazione richiede nome utente, password ed . Questi dati sono controllati e in caso siano corretti, si viene registrati al repository e automaticamente loggati. In caso di errori essi saranno segnalati affianco del campo errato: Il nome utente deve essere univoco ad avere almeno 4 caratteri, la password ha una lunghezza minima di 5 e l'indirizzo deve essere in un formato valido. Dopo aver completato la registrazione, è consigliabile completare i propri dati per ottenere un inserimento di risorse più agile e veloce.

48 Form per la registrazione al Repository Login Nel caso l'utente non sia loggato, nel box Pannello utente apparirà la form di login, la quale permette anche di accedere alla registrazione. Il login necessità di username e password e permette, attraverso l'opzione remember me di essere loggati in automatico nei futuri accessi, questo avviene attraverso un popup sicuro che viene salvato nel browser lato client con lo scopo di identificare l'utente. E inoltra disponibile una procedura per il recupero della password, nel caso sia stata dimenticata dall'utente, o inserita in modo errato in fase di registrazione. Form per il login Pannello Utente Quando un utente è loggato, la form per il login è sostituita con una lista delle operazioni che è possibile effettuare:

49 Aggiungere un nuovo Learning Object Modificare i Propri dati Modificare i propri Learning Object Eseguire il Log out Pannello Utente Aggiunta di un nuovo Learning Object: Quest operazione è suddivisa in 3 diversi fasi: La prima, riguardante l'upload della risorsa presenta la seguente schermata che ne permette il caricamento da url oppure dal pc dell'utente: Aggiunta di un nuovo Learning Object: Upload di una risorsa L'inserimento da url è immediato, una volta cliccato su analizza verrà controllata la correttezza del percorso inserito, in caso affermativo il learning object verrà analizzato dal generatore SamgI e si potrà passare alla fase 2. Nel caso che invece si esegue l'upload di un Lo dal pc locale, si aprirà un popup con lo scopo di gestire quest operazione. Una volta terminata, analogamente all'inserimento da url la risorsa sarà analizzata e si potrà cosi procedere alla fase 2.

50 Upload di un Lo La seconda parte riguarda il completamento dei metadati: dopo aver eseguito l'analisi del Lo sono suggerite le varie opzioni e si richiede un controllo da parte dell'utente. Aggiunta di un nuovo Learning Object: Inserimento dei Metadati