Professional Documents
Culture Documents
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