Nota: quelli proposti sono argomenti di interesse scientifico del docente di ampio respiro, non di titoli di tesi.
Per ulteriori informazioni, contattare il docente in orario di ricevimento.
L'obiettivo (di medio-lungo termine) è realizzare un'implementazione (parziale) di Java Persistence API (JPA) ma utilizzando come sistema target non una base di dati relazionale, ma piuttosto un sistema NoSQL (per i sistemi NOSQL vedere ad esempio http://en.wikipedia.org/wiki/NoSQL, http://nosql-database.org/ o meglio http://www.cattell.net/datastores/Datastores.pdf).
L'implementazione andrà probabilmente realizzata come un adattamento di uno strumento ORM open source esistente (ad esempio, EclipseLink) e non come un nuovo sistema.
Prima di procedere con l'implementazione, sarà necessario studiare come mettere in corrispondenza classi e associazioni persistenti con i costrutti del sistema NoSQL scelto, e come mettere in corrispondenza operazioni su oggetti e collegamenti con operazioni del sistema NoSQL scelto.
Pertanto, è possibile immaginare anche più tesi su questo argomento, sia svolte congiuntamente da un piccolo gruppo di tesiste che svolte sequenzialmente nel tempo.
Competenze richieste: buone capacità di analisi, progettazione e programmazione ad oggetti e testing.
Obiettivo di queste tesi è ricostruire l'architettura software di sistemi software complessi di tipo open source, al fine di identificare l'applicazione di stili architetturali e tattiche architetturali. La ricostruzione dell'architettura sarà basata sia sull'analisi del codice sorgente che sullo studio della documentazione progettuale del sistema. La ricostruzione dell'architettura avrà lo scopo di capire in che modo sono state progettate certe funzionalità e/o certe qualità, e quali sono i moduli responsabili appunto di tali funzionalità e qualità.
In particolare, sono disponibili tesi relative alla ricostruzione dell'architettura di:
L'obiettivo è fornire supporto alla sviluppo di applicazioni per basi di dati che utilizzano strumenti di Object-Relational Mapping quali Java Persistence API o Hibernate. Questi strumenti consentono, sulla base di un opportuno mapping, di interpretare richieste di lettura/creazione/modifica/cancellazione di oggetti Java in richieste di lettura/creazione/modifica/cancellazione di righe nella base di dati relazionale sottostante.
Uno schema mapping è una specifica che descrive le corrispondenze tra due schemi, solitamente chiamati lo schema sorgente e lo schema destinazione. L'obiettivo di uno schema mapping è descrivere come dei dati organizzati secondo lo schema sorgente possano essere trasformati per creare un'istanza dello schema destinazione che rappresenta le stesse informazioni, ma organizzate secondo lo schema destinazione. Esistono diverse attività relative agli schema mapping, ad esempio:
Per molte delle attività descritte in precedenza esistono degli algoritmi (descritti in letteratura) in grado di realizzare tali attività. Inoltre, è disponibile un sistema per la gestione di schema mapping (ClioSharp) che implementa alcuni di tali algoritmi.
Sono disponibili tesi volte a:
Disponibilità: immediata, anche per più di una persona.
Competenze richieste: capacità buone di analisi, progettazione e programmazione ad oggetti e testing.
Service Data Objects (SDO) è una tecnologia per scambiare dati in modo omogeneo in un'architettura orientata ai servizi (SOA). Si veda ad esempio qui, qui, qui e qui. Data Access Service (DAS) è intuitivamente una tecnologia per incapsulare sorgenti di dati (ad esempio, una base di dati relazione o un insieme di documenti XML) in oggetti SDO. Si veda ad esempio qui. Ad esempio, Apache Tuscany è un progetto open source che implementa queste tecnologie SDO e DAS.
Le tecnologie SDO e DAS sono in qualche modo correlate alle tecnologie di Object-Relational Mapping (vedi sopra). E' interessante capire come le tecnologie e gli algoritmi ORM possano essere estesi al mondo SDO e DAS.
Questo progetto ha finalità principalmente didattiche. Il tesista è tuttavia chiamato ad entrare in contatto con tecnologie d'avanguardia, dunque non si tratta di una puro esercizio accademico.
Alcune tecnologie nascono con l'obiettivo di supportare l'integrazione di applicazioni di una singola organizzazione (es., EAI) o addirittura l'integrazione delle applicazione di un'organizzazione con quelle di altre organizzazioni (es., SOA). L'utilizzo prevalente di queste tecnologie avviene pertanto con riferimento ad applicazioni pre-esistenti. Scopo della tesi è realizzare una "palestra" per l'integrazione di applicazioni. Questa "palestra" dovrebbe poter essere installata facilmente (ad esempio, non dovrebbe richiedere l'uso di application server commerciali o strumenti estremamente particolari). Inoltre dovrebbe essere composta da un certo numero di applicazioni, documentate in modo opportuno per consentire la loro integrazione.
Un primo obiettivo è quello di identificare un possibile problema di integrazione, con le relative applicazioni, la loro architettura e le loro piattaforme di esecuzione. Alcune di queste applicazioni potrebbero essere sviluppate come parte della tesi, ma non è esclusa la possibile di utilizzare delle applicazioni disponibili su Internet come demo di alcune delle tecnologie da integrare. Per quanto possibile, queste applicazioni dovrebbero avere: (i) un'architettura a componenti (Java EE e/o Microsoft .NET) e (ii) essere rilasciabili su piattaforme relativamente semplici (nel caso delle applicazioni Java, potrebbero essere applicazioni per Tomcat + JBoss + hsqldb, e non richiedere l'uso di application server commerciali).
Il secondo obiettivo è quello di identificare/caratterizzare la loro architettura architettura a componenti, e descriverla in modo sufficiente per operare l'integrazione.
Il terzo obiettivo è quello di realizzare almeno un paio di scenari di integrazione, per verificare che le applicazioni da cui la palestra è costituita siano effettivamente integrabili con uno sforzo contenuto. Questi scenari potrebbero essere basati su messaging o sull'uso delle tecnologie dei WS.
Per ulteriori informazioni, contattare il docente in orario di ricevimento.