Proposte di progetto per la prova finale del corso di Tecnologie dei Linguaggi di Programmazione Corso di Laurea in Informatica A.A. 2013/2014 Docente: Romina Eramo Modalità svolgimento progetto Il progetto va svolto in gruppi preferibilmente di 2 persone. Di seguito sono elencate alcune tracce che possono essere completate e raffinate con modifiche proposte dal gruppo. Il gruppo di lavoro può inoltre proporre un proprio progetto la cui specifica deve essere discussa e valutata con il docente per stabilire la complessità e verificare la fattibilità del lavoro. Requisiti comuni Lo svolgimento di tutti i progetti deve tenere in considerazione i seguenti requisiti. In particolare, il sistema scelto deve essere implementato con un alto grado di modularità in maniera tale da: •
•
poter cambiare la gestione della persistenza senza dover modificare la logica di business dell’applicazione; poter cambiare la modalità di interazione dell’utente senza dover modificare le altre unità logiche del sistema; Tali requisiti devono essere soddisfatti mediante l’uso adeguato di interfacce, classi astratte, ereditarietà e tramite la scelta e adozione di design patterns. Note: Gli studenti possono raffinare le tracce proponendo ed implementando delle migliorie, per esempio possono pensare di adottare un’architettura client-­‐server. La valutazione degli elaborati sarà condotta considerando diversi aspetti quali: • completezza dell’implementazione • usabilità • l’organizzazione del software in librerie, classi, etc. • documentazione del codice • gestione delle eccezioni • discussione orale • uso di design patterns Ogni progetto deve essere accompagnato da una breve relazione in cui vengono spiegate ed illustrate (eventualmente mediante l’uso di diagrammi UML) le scelte adottate. E’ necessario che prima di iniziare il lavoro, ogni gruppo comunichi al docente tramite email i nomi dei componenti del gruppo, la traccia proposta ed eventuali proposte di progetto/modifiche, al fine di concordare aspetti e, se la traccia lo richiede, avere del materiale iniziale. 1
Progetti proposti Architettura software (relativa alla proposta 1) Architettura*software*
!
Gli strumenti esistenti a supporto di analisi di web reputation possono essere divisi in due categorie: Gli$strumenti$esistenti$a$supporto$di$analisi$di$Web$reputation$possono$essere$divisi$in$due$categorie:$
semantici e non semantici. I primi basano le loro valutazioni dei contenuti Web sull’interpretazione semantici$ e$ non$ semantici.$ I$ primi$ basano$ le$ loro$ valutazioni$ dei$ contenuti$ Web$ sull’interpretazione$
semantica del linguaggio naturale. I secondi basano la loro competitività sull’enorme quantità di semantica$ del$ linguaggio$ naturale.$ I$ secondi$ basano$ la$ loro$ competitività$ sull’enorme$ quantità$ di$
informazioni che analizzano (alto numero di fonti Web), limitandosi però alla sola interpretazione informazioni$che$analizzano$(alto$numero$di$fonti$Web),$fornendo$però$un’interpretazione$grossolana$
quantitativa della web reputation, ottenuta senza comprendere la semantica dei contenuti. della$reputation,$ottenuta$senza$comprendere$la$semantica$del$contenuto.$
I testi che che$
derivano da da$
fonti ufficiali, quali$
quali giornali online, possono essere assunti I$ testi$
derivano$
fonti$di di$informazione informazione$ ufficiali,$
giornali$
online,$
possono$
essere$
assunti$
come affidabili, generalmente ben scritti e semplici da interpretare. E invece derivano da siti Web 2.0, come$ affidabili,$ generalmente$ ben$ scritti$ e$ semplici$ da$ interpretare.$ Ma$ se$ derivano$ da$ siti$ Web$ 2.0,$
quali$
di$ microblogging,$devono devono$essere essere$ necessariamente necessariamente$ trattati$
da$da strumenti$
specifici$
prima$
di$ di quali siti siti$
di microblogging, trattati strumenti specifici prima poter$essere$interpretati.$$
poter essere interpretati. Inoltre,$
delle$
sfide$
maggiori$per per$il il$futuro futuro$ dell’ICT$
dell’overload$
informativo$
dovuto$
Inoltre, una una$
delle sfide maggiori dell’ICT è$è la$la gestione$
gestione dell’overload informativo dovuto all’aumento$della$disponibilità$di$acquisizione$e$scambio$di$dati.$Come$conseguenza,$diviene$cruciale$
all’aumento della disponibilità di acquisizione e scambio di dati. Come conseguenza, diviene cruciale la la$ definizione$
un$ metodo$
capace$
valutare$la la$qualità qualità$ dell’informazione$
nonché$
di$ valutare$
la$ sua$
definizione di un di$metodo capace di di$
valutare dell’informazione nonché di valutare la sua rilevanza$per$compiti$specifici.$$
rilevanza per compiti specifici. $
A$ tale$ scopo$ la$ nostra$ piattaforma$ comprenderà$ componenti$ software$ necessarie$ ad$ abilitare$
A tale scopo la piattaforma di analisi di web reputation comprende componenti software necessari ad l’interpretazione$ semantica$ del$ linguaggio$ naturale$ ottenuto$ dall’interazione$ con$ le$ fonti$ web$ di$
abilitare l’interpretazione semantica del linguaggio naturale ottenuto dall’interazione con le fonti web interesse,$ovvero$i$social$network$Facebook$e$Twitter,$e$lo$strumento$Telpress$per$l’interazione$con$le$
di interesse, come per esempio social networks, portali web, etc. Infine, sulla base dell’architettura agenzie$di$stampa.$$
Infine,$
sulla$ base$ dell’architettura$
definita$
e$ sull’analisi$
degli$
strumenti$
sono$
stati$ definiti$
definita e sull’analisi degli strumenti esistenti, sono stati definiti degli esistenti,$
indicatori in grado di stimare degli$indicatori$in$grado$di$stimare$polarità$e$pertinenza$con$i$topics$di$interesse.$Tali$indicatori$sono$
polarità e pertinenza con i topics di interesse. Tali indicatori sono quindi inclusi in una Dashboard. quindi$inclusi$in$una$dashboard.!!
!
In Figura che segue è riportata l’architettura software dello strumento, dove, con linee spesse, è In$
Figura$
che$ segue$
è$ riportata$
dello$mostrate strumento$le proposto,$
dove,$
con$
linee$
indicato il flusso dei dati mentre, l’architettura$
con frecce software$
sottili, sono interazioni tra componenti spesse,$ è$ indicato$ il$ flusso$ dei$ dati$ mentre,$ con$ linee$ sottili,$ sono$ mostrate$ le$ interazioni$ tra$
software o tra componenti e sorgenti dati. Ad interrompere il flusso di elaborazione è riportato un componenti$ software$ o$ tra$ componenti$ e$ sorgenti$ dati.$ $ Ad$ interrompere$ il$ flusso$ di$ elaborazione$ è$
Database, che è popolato con informazioni relative ai contenuti testuali di interesse e arricchito con i riportato$ un$ database,$ che$ è$ popolato$ con$ informazioni$ relative$ ai$ contenuti$ testuali$ di$ interesse$ e$
valori relativi alle stime di polarità e topics. arricchito$con$i$valori$relativi$alle$stime$di$polarità$e$topics.$$$
!
!
!
$
Facebook$
$
Social Network $
$
$
FB$connector$
SN connector $
$
$
$
$$$$id$ $$$$testo
$ prov$ $$timestamp$$$$$polarity
$$$$$$$$$topics
$
$
I$ ID$$$$$$$$$
ID$ ID$
ID$ ID$
$$$$$$$$tw/fb$
$$$$$$$$$$T1/+1$$$$$$$$$topic
T1/+1$ D$
$
$
$
$
$
$
$
$
$
$
$
$
Twitter$
Social Network Telpress$
Web $
$
TW$connector$
SN connector connector$
Data$
Aggregator$
TP$connector$
Web connector Sentiment$
analyzer$
$
DB$
$
Topic$extractor$$
Dashboard$
La componente Data Aggregator ha il compito di comunicare tramite appositi Connector (che sfruttano API o interfacce dedicate) con gli strumenti web di interesse e popolare il nostro database. Ogni tupla del database (schematicamente mostrato in Figura) è popolata con i valori degli indicatori che hanno origine da un processo in cui saranno estratti i topics di interesse ed effettuata un’analisi semantica (componenti arancioni in Figura). Proposta 1: Sviluppare la componente connettore Social Network per LinkedIn in modo che, data una lista di “risorse”, ognuna delle quali è espressa come una URL del dominio www.linkedin.com, svolge le seguenti funzionalità: 1. Restituire tutti i post (con relativo contenuto e altri dati conformemente alla struttura del DB) successivi ad una certa data o relativi ad un intervallo di date. public class AggregatorPost {
private
private
private
private
private
private
String text;
String author;
Date date;
int visibility;
String source; // for instance, linkedIn
String link; ...
}
2. Fornire tali post alla componente DataAggregator. A tal fine, si prevede l’utilizzo della seguente interfaccia: public interface AggregatorPlugin {
public List<AggregatorPost> getPosts(String resource, String type, Date from)
throws QuotaExceededException;
public List<AggregatorPost> getPosts(String resource, String type, Date from, Date to)
throws QuotaExceededException;
} Sviluppare la componente connettore Social Network per Google+ in modo che, data una lista di “risorse”, ognuna delle quali è espressa come una URL del dominio plus.google.com, svolge le stesse funzionalità descritte sopra. Sviluppare la componente connettore Web in modo che, data una lista di “risorse”, ognuna delle quali è espressa come una URL di un portale, svolge le stesse funzionalità descritte sopra. In questo caso, per ogni pagina sarà necessario parsare i contenuti e individuare metadati, dati testuali, testo alternativo o didascalia immagini. Questo connettore distinguerà due modalità di azione: a) I post saranno costituiti da porzioni di testo estrapolate da ogni pagina web, trascurando elementi decorativi. b) Ogni pagina sarà ispezionata al fine di recuperare le informazioni di interesse in modo strutturato. In altre parole, ogni pagina sarà scomposta in una struttura più complessa che distingue metadati, porzioni di testo, titoli, didascalie immagini, etc. Tale struttura sarà mantenuta in memoria oppure in database (estendendo quello base che sarà fornito dal docente) Altre proposte: Proposta 2: Realizzare un progetto integrato con il corso di Ingegneria del Software. Proposta 3: Implementazione in Java di un qualsiasi altro gioco come dama, monopoli, scacchi, battaglia navale, sudoku, forza 4.
