You are on page 1of 3

Laurea Triennale in Comunicazione Digitale

Progetto Laboratorio Reti di Calcolatori


Anno Accademico 2011/2012

Contatti reali VS virtuali


Gennaio 2012
Introduzione e motivazioni
In molte discipline scientifiche, tra cui linformatica, sta emergendo un sempre pi vivace interesse verso le relazioni sociali tra individui. Tale interesse dettato dal rapido sviluppo, negli ultimi 5 anni, di social networks quali Facebook, MySpace, Linkedln e il pi giovane Google+, etc... . Tali networks rappresentano forse una delle pi vaste collezioni di dati di tipo sociale, sia per quanto riguarda il numero di persone coinvolte sia per quanto riguarda la grande eterogeneit delle relazioni che coinvolgono i loro iscritti. Se da un lato la grande mole di dati rappresenta una grande opportunit, dallaltro lato non tutte le relazioni (amicizie) tra utenti sono significative oppure rispecchiano effettive relazioni che avvengono anche nel mondo reale. Per questo motivo assumono sempre pi importanza sperimentazioni che tentano di confrontare i contatti tra persone con le connessioni che queste persone hanno nei social networks. Questo progetto segue questo trend ed finalizzato al campionamento e allanalisi della struttura dei precedenti oggetti di studio (contatti reali / amicizie virtuali).

Specifiche del progetto


Il progetto suddiviso in 3 fasi separate. Nella prima fase si deve implementare unarchitettura client-server per registrare i contatti reali in cui lesecutore del progetto coinvolto. Nella seconda fase, invece, si dovranno reperire le relazioni di amicizia sul social network Facebook. Tali dati saranno inviati al docente che li aggreger e rielaborer. Il terzo step coinvolge lanalisi del grafo delle amicizie dei partecipanti al progetto. Su tale grafo verr richiesto di calcolare alcuni indici visti a lezione relativi sia alla struttura globale sia alle propriet del singolo nodo corrispondente allo studente.

Fase 1
Si implementi unarchitettura client-server coi seguenti vincoli sugli elementi costitutivi: Client: Il fine ultimo del client quello di inviare al server i dati relativi ai contatti in cui 1

un utente coinvolto. Il client, quindi, dovr offrire uninterfaccia di tipo testuale che riconosca determinati comandi per linserimento dei dati relativi ad un contatto. Il client dovr essere multithread per quanto riguarda la gestione dellinput da tastiera e della comunicazione col server. Il client riconosce i seguenti comandi: q: chiude la connessione col server e il client stesso add <contatto>: aggiunge un contatto del <id_contatto>: cancella un contatto con un prefissato id Il formato del contatto il seguente: Nome,Cognome,Data,Durata,gradoConoscenza,tipoRelazione,tipoLuogo dove Nome e Cognome: nome e cognome della persona con cui entro in contatto Data: data in cui avvenuto il contatto nel formato GG-MM-AA Durata: durata approssimativa del contatto (in minuti) gradoConoscenza: grado di conoscenza con la persona in contatto. Pu assumere i valori alto,medio,basso. tipoRelazione: tipo di rapporto con la persona in contatto. Pu assumere uno dei seguenti valori: amico, conoscente, sconosciuto (prima del contatto), parente, collega, altro. tipoLuogo: dove avvenuto il contatto. Pu assumere i valori: casa, universit, lavoro, sport (si intende luoghi dove si pratica una qualsiasi attivit sportiva), tempolibero (si intende luoghi con valenza sociale), altro. Server: il server riceve le varie informazioni dei contatti e le memorizza in modo permanente su un file chiamato contatti.csv. Anche in questo caso il server deve essere di tipo multithread. Il server reagisce ai comandi inviati nel seguente modo: add: Il server inserisce il contatto e gli associa un identificativo univoco <id_contatto>. Il server, come risposta al client, invia lid del contatto se linserimento andato a buon fine, altrimenti invia un messaggio di errore del: Il server elimina il contatto associato all <id_contatto> e inoltre comunica al client la buona riuscita o meno della rimozione I contatti reali ricevuti dal client dovranno essere salvati nel seguente formato: Nome,Cognome,Data,Durata,gradoConoscenza,tipoRelazione,tipoLuogo Nome,Cognome,Data,Durata,gradoConoscenza,tipoRelazione,tipoLuogo ... La politica di gestione della memorizzazione su file viene lasciata allo studente. Il fine che deve essere raggiunto mantenere la consistenza con i dati inviati. Questo significa che, anche se il server dovesse cadere, tutti i contatti ricevuti devono essere salvati su file.

Fase 2
Come primo passo lutente deve creare, se non gia stato fatto a lezione, unapplicazione Facebook. Il secondo passo consiste nel reperire i propri amici di Facebook utilizzando le Graph API del social network. Dalle risposte in formato JSON si devono estrarre lid dellutente, nome e cognome. Le precedenti informazioni vanno salvate in formato csv in un file nominato amci_<id_user>.csv, dove <id_user> lid del vostro profilo di Facebook. Il file deve rigorosamente seguire la seguente struttura: <id-user>,<id_amico>,nome,cognome (dellamico) Per poter ricevere il token di accesso potete utilizzare la classe FacebookConnection presentata a lezione.

Fase 3
Nella terza parte lo studente dovr analizzare il grafo degli amici di tutti i partecipanti al progetto. Il precedente grafo e la sua componente pi numerosa verranno inviate via e-mail ai partecipanti. I file saranno denominati grafoTotale.dgs e componente.dgs. Come software per lanalisi si consiglia luso della libreria GraphStream presentata a lezione. Su tali grafi lo studente deve calcolare i seguenti indici obbligatori: numero di componenti connesse diametro della componente pi numerosa cammino minimo medio (sui cammini finiti) media del grado betweenness centrality del nodo che rappresenta lo studente, da ora indicato con n_user E lasciato alla facolt dello studente il calcolo di ulteriori indici. Il file contenente il grafo seguir il seguente formato: <id_user>,<id_user> <id_user>,<id_user> Al fine di analizzare la centralit di un n_user singolarmente, ad ogni studente, verr inviato, insieme ai grafi, lid del nodo_user a cui associato.

Modalit di consegna
Il codice inerente alla prima e alla seconda fase e i file, contatti.csv e amici_<id_user>, devono essere consegnati entro le 23:59:59 del 9 gennaio 2012. Tutti i file deve essere uploadati mentiante lapposito form allindirizzo http://reti.dsi.unimi.it/consegna.php. Il codice relativo alla terza fase deve essere consegnato entro le 23:59:59 del 30 gennaio 2012. Oltre al codice relativo alla terza fase, deve essere inviata anche una breve relazione (un paio di pagine) sui risultati ottenuti dallanalisi. Anche per la relazione vale la scadenza del 30 gennaio 2012. Valgono tassativamente le seguenti regole: 1. Il codice che non compila non verr considerato 2. La cartella contenente il codice deve essere compressa (formati riconosciuti: 7z, zip, tar.gz) 3. File non correttamente formattati non verranno considerati 4. La relazione deve essere in formato PDF

Per chiarimenti, dubbi potete contattare il docente allindirizzo reti@dsi.unimi.it, specificando come oggetto obbligatorio Progetto Reti Gennaio. Nota Al fine di preservare la privacy tutti i dati sensibili verranno opportunamente anonimizzati. Ultima modifica: 6 dicembre 2011

You might also like