Visage

Stefano Montesi  •  Niccolò Mencarini  •  Michael Tamanti  •  Mattia Baldani
abstract

Descrizione

Il nostro progetto consiste in una piattaforma web social-style in cui ogni utente si registra rendendo pubblici (all'interno della piattaforma) i propri account (email, twitter, facebook, etc). Ogni utente potrà accedere alle informazioni di una qualsiasi persona tramite il riconoscimento facciale, a patto che essa sia registrata oppure che sia stata "schedata" tramite le api di facebook. Il riconoscimento potrà avvenire:
  • lato desktop con il caricamento di una foto attraverso l'applicazione web
  • lato mobile tramite il caricamento e anche attraverso un sistema di realtà aumentata.
Il progetto prevede la realizzazione di:
  • un'applicazione web, in cui gli utenti potranno registrarsi, modificare i propri dati, cancellare ed aggiungere le proprie foto, caricare foto per riconoscere le persone presenti.
  • applicazione android (in seguito anche iphone), in cui gli utenti potranno registrarsi, (modificare i propri dati), richiedere il riconoscimento tramite caricamento foto o tramite realtà aumentata.

Estensioni

Integrazione di un servizio che tracci la posizione e indichi all'utente quali utenti sono vicini a lui, o che dia comunque la possibilità di limitare la ricerca tra gli utenti che sono effettivamente nei paraggi.

Server

Il server si deve occupare di gestire tutte le richieste che gli giungono dai client desktop e mobile e di interfacciarsi con le API di face.com (servizio al quale ci appoggiamo attualmente per gli algoritmi di riconoscimento facciale). Deve perciò gestire login/logout, registrazione, profile editing, riconoscimento delle immagini date le url e interazione con i database. Per le specifiche più dettagliate si rimanda ai casi d'uso.

Client

I vari client, che siano mobile o desktop devono invece preoccuparsi di inviare al server informazioni riguardo la registrazione e la modifica dei dati dell'utente, il login al nostro servizio e la scelta dell'immagine della persona di cui richiedere il riconoscimento facciale.

Registrazione

Al momento dell'iscrizione chiediamo (tutti gli elementi sono obbligatori):
  • Nome e Cognome,Sesso, Mail e Password, Data di nascita
  • Almeno 3 foto in cui è presente solo l'utente (una sorta di immagine del profilo)
  • Collegamento con account Facebook (e/o Twitter) tramite login per confermare l'identità.

Glossario

piattaforma web social-style: piattaforma web che fornisca servizi "sociali", ovvero che permetta l'interazione fra utenti.utente registrato: qualsiasi persona che si sia registrata fornendo nome, cognome, email, password e altri dati al fine di poter essere riconosciuto e poter riconoscere altri utenti registrati, (requisito fondamentale per la registrazione è il caricamento delle proprie foto).riconoscimento facciale: è una tecnica di intelligenza artificiale utilizzata in biometria per identificare o verificare l'identità di una persona a partire da una o più immagini che la ritraggono.applicazione web: un'applicazione accessibile via web per mezzo di Internet dalla quale è possibile gestire i dati del proprio account registrato.applicazione mobile: un'applicazione appositamente realizzata per dispositivi mobili, e che incorporano almeno una fotocamera, un sistema di localizzazione GPS e una connessione a rete dati a pacchetto.realtà aumentata: è una tecnica che consiste nel sovrapporre livelli contenenti informazioni all'immagine reale che viene ripresa tramite un dispositivo.database: è un insieme di archivi collegati secondo un particolare modello logico (relazionale, gerarchico o reticolare) e in modo tale da consentire la gestione dei dati stessi (inserimento, ricerca, cancellazione ed aggiornamento) da parte di particolari applicazioni software dedicate.social-account: con questo termine indichiamo un profilo di un social network che l'utente ha collegato durante o dopo la registrazione confermando tramite un processo di autenticazione la reale corrispondenza dell'utente col profilo stesso; ogni profilo collegato viene contraddistinto con l'id del corrispondente servizio/social network.feedback: è una sorta di commento o consiglio che l'utente invia al nostro team per segnalare anomalie o proposte per il miglioramente della nostra piattaforma.posizione: è la collocazione spaziale dell'utente determinata dalle coordinate geografiche al momento della richiesta di riconoscimento al nostro servizio.tag: consiste nell'associare l'account di un utente ad una foto in cui è stato riconosciuto il suo volto.Activity: una specie di "schermata" o finestra di cui sono composte le applicazioni Android, visualizzabile sullo schermo del dispositivo. Per una definizione più rigorosa consultare la documentazione di Android: http://developer.android.com/guide/topics/fundamentals/activities.html

Casi d'uso

I casi d'uso del nostro sistema sono riassunti chiaramente e semplicemente dal seguente schema, che suggerisce anche come abbiamo pensato di strutturare la loro risoluzione. usecase.png Lo schema è abbastanza autoesplicativo, ma sono comunque necessarie alcune considerazioni. Con User si intendono tutti i "tipi" di utenti, sia che essi accedano al servizio tramite web application che tramite piattaforme mobile. Con Operator si intendono coloro che avranno il compito di "sorvegliare" che i contenuti caricati dagli utenti non siano "scorretti", previa consultazione dei feedback dagli utenti, ed inoltrare report all'admin, il quale è l'unico a poter prendere provvedimenti.

Requisiti non funzionali

Oltre ai requisiti funzionali necessari per l'effettivo funzionamento del sistema, è necessario fare attenzione a quelle caratteristiche che rendono il sistema ben progettato e che garantiscono la bontà del progetto.Usabilità Considerando il tipo di sistema che stiamo sviluppando ci si aspetta un minimo di preparazione informatica o dimestichezza con i dispositivi mobili o desktop. Nonostante queste è indispensabile che ogni tipo di utente riesca a fruire del sistema senza la necessità di nessun tipo di istruzioni preliminari.Affidabilità Essendo il sistema completamente dipendente dall'interazione con un database ci si aspetta che anche in casi di guasti o di problemi elettrici nella server-farm che ospita i nostri server, si possa comunque ripristinare entro breve la situazione precedente e il servizio rimanga comunque funzionante per quanto possibile. In questo senso sarà importante prevedere dei backup e delle copie consistenti del database e fare in modo che ci sia almeno una copia di ogni componente in grado di sopperire al sovraccarico o al malfunzionamente di uno di essi.Sicurezza La nostra politica prevede che solo chi è regolarmente registrato possa accedere ai nostri servizi, sarà quindi necessaria la presenza di un sistema di autenticazione tramite username/password. Inoltre è fondamentale garantire una struttura che prevenga la possibilità di attacchi informatici vista comunque la presenza nel database di dati personali come foto e password anche se non gestiamo dati sensibili.Prestazioni e scalabilità Considerando la natura dell'ambiente web e la comprensibile poca pazienza dell'utente che necessita di un servizio rapido, il numero dei server e della banda utilizzabile deve essere scalabile rispetto al numero degli utenti. Per questo si ritiene necessaria una struttura che preveda la possibilità di ampliare il servizio sia in termini di qualità sia quanto riguarda la quantità, il sistema deve essere infatti in grado di interagire potenzialmente con un numero anche elevato di utenti. Inoltre, anche se inizialmente non verranno sviluppate tutte le funzionalità a cui abbiamo pensato, è fondamentale che il sistema possa essere ampliato senza riscontrare problemi riguardo la modifica di componenti già creati.

Architettura generale del sistema

Dal seguente schema si evince come abbiamo deciso di utilizzare un'approccio modulare per suddividere le funzioni del sistema. In questo modo ci risulterà più semplice apportare modifiche a singole parti del sistema o aggiungere ulteriori funzionalità. Si è cercato di individuare le funzionalità che il sistema deve offrire e suddividerle in moduli logici. L'obiettivo è quello di avere moduli che siano il più possibile indipendenti tra loro.

DESCRIZIONE DEI MODULI

registration: il processo attraverso cui una persona diventa utente del servizioauthentication: il processo attraverso cui una persona dimostra di essere un utente già registrato fornendo nome utente e pasword, consente di identificare l'utente per l'utilizzo del serviziouserPanel: l'insieme delle procedure attraverso cui un utente ha la facoltà di modificare i dati e le foto che ha inserito al momente della registrazione, collegamento di account compreso.photo: l'insieme dei processi che riguardano il caricamento e il tagging delle fotolocal: l'insieme dei processi che si occupano della posizione spaziale dell'utentecms: l'insieme delle procedure che consentono all'amministratore e/o agli operatori di disabilitare utenti ed ottenere il log.dbManager: l'insieme delle procedure che si occupano dell'interazione col database.managment: il processo che permette di gestire i feedback rilasciati dagli utenti Modules.jpg Nello schema si evidenza inoltre come abbiamo deciso di tenere la gestione del DB separata dal resto del sistema, di modo da renderla trasparente al sistema. Gli unici vincoli, facilmente rilassabili, che abbiamo deciso di introdurre sono quelli legati all'interazione tra i client e il sistema, che deve avvenire tramite HTTP request, e tra il sistema e il gestore del DB, che deve avvenire tramite un meccanismo di RPC. Un primo schema generale di soluzione può essere il seguente. package.png Per motivi di sicurezza, la comunicazione dei vari moduli con il server del database può avvenire solamente tramite il modulo DBOperator che gira su un server separato, con un protocollo RPC da noi ideato basato su richieste HTTP. In pratica i vari moduli non possono collegarsi direttamente al server database con il protocollo MySQL, ma possono chiamare le varie funzioni di DBOperator, le quali a loro volta si occuperanno di comunicare con il server database vero e proprio. In DBOperator c’è una funzione per ogni operazione che può essere effettuata sul database, per esempio insertUser(Failed to execute the [velocity] macro. Cause: [Nested scripts are not allowed. Current Script Macro [velocity] (source [xwiki:Courseprojects.Sheet]) is executed inside Script Macro [velocity] (source [xwiki:Courseprojects.Sheet])]. Click on this message for details.
) , getUser() , nelle quali viene creato il codice SQL corrispondente, sanitizzando tutti i parametri, in modo da essere invulnerabili ad attacchi SQL Injection. In questo modo se vengono compromessi i server Apache dove girano i vari moduli, essi non possono eseguire codice SQL arbitrario sul DBMS, ma solo le operazioni consentite tramite DBOperator.

Architettura dei componenti del sistema

Prima ipotesi prima.png

Nel disegno ogni cerchio azzurro è un server ed ogni freccia è una richiesta HTTP, le faccine sono i client degli utenti. Sopra ogni cerchio azzurro c'è scritto l'indirizzo pubblico di quel server. Il sistema è composto da:
  • molti server Apache, hanno indirizzo api1,2,..,n.visageme.com, sopra sono presenti tutte le classi php di tutti i componenti del nostro sistema, quindi sono in grado di eseguire qualunque tipo di funzione gli venga chiesta (migliore sfruttamento delle risorse che abbiamo a disposizione)
  • molti server database Mysql Cluster (NON CI SONO NEL DISEGNO!)
  • molti server di immagini che devono avere solo degli hard disk di grandi dimensioni,per permettere di scaricare ed uploadare le immagini.
Per quanto riguarda il load balancer, se utilizziamo il Virtual Server via IP Tunneling attraverso il "proxy" si fanno passare gli header http di richiesta, le risposte, quindi il traffico grosso vero e proprio, vanno direttamente dai server apache ai client senza passare per il proxy. Per quanto riguarda l'upload di immagini da memorizzare nell'hard disk sui server img.visageme.com pensavamo di fare in modo che il client viene autorizzato ad uploadare una foto facendo una richiesta al modulo Photo, il quale gli restituirà un token, con il quale il client può connettersi direttamente ai server img.visageme.com. Per la questione del database: seguendo la stessa filosofia dei server che fanno un po' di tutto, sarebbe coerente mettere un server Mysql Cluster su ogni server Apache, in modo da risparmiare banda, altrimenti i server apache dovrebbero continuamente comunicare con i server del database, ed in questo modo avremmo un cluster molto più grosso che da più ridondanza al database. L'unico problema che sorgerebbe sarebbe quello della sicurezza in quanto se compromettessero il server apache non dovrebbero poter far danni direttamente al database; questo problema potremmo risolverlo mettendo su ogni server fisico due macchine virtuali separate, una sulla quale ci gira il server apache, una sulla quale ci gira il server mysql cluster. La rete virtuale tra le due macchine virtuali ovviamente è velocissima quindi è come se fosse un unico server, però abbiamo la stessa sicurezza di avere due server separati, uno per apache ed uno per il database.

Seconda ipotesi seconda.png

Intendiamo i componenti completamente distribuiti e distribuibili su server diversi. L'idea consiste nell'utlizzo di minimo 3 server:
  • il primo che si occupa solamente di prendere le richieste iniziali (homepage molto minimale)
  • il secondo che si occupa del solo modulo foto
  • il terzo che si occupa di tutti gli altri moduli
(inizialmente ipotizziamo di adottare questa soluzione in quanto il modulo foto è quello + pesante e quello che richiede in assoluto + banda mentre gli altri sono relativamente abbastanza leggeri; in futuro se ce ne sarà bisogno potremmo usare anche un server per ogni modulo) La questione del load balancing viene gestita interamente inserendo nelle chiamate una funzione getBestServer(modulo) al posto dell'indirizzo vero e proprio. In questo caso in base a dove sappiamo essere disponibile il modulo e in base al traffico disponibile nei server che lo contengono verrà effettuata la chiamata. Vantaggi: in questo modo i componenti sono estendibili, modulabili e completamente distribuibili, miglior distribuzione nella rete e non c'è una duplicazione completa. Svantaggi: ovviamente in questo modo le chiamate a procedura sono completamente in remoto, e l'utilizzo dell'rpc potrebbe creare ulteriori difficoltà oltre a spreco di banda e di tempo. In questa soluzione l'rpc è necessario per la comunicazione tra qualunque modulo. Caso limite: questa idea potrebbe rimanere valida nel caso in cui mettessimo tutti i componenti sullo stesso server ma l'rpc diverrebbe ovviamente inutile. Fault tolerance: nel caso in cui un componente risulti non disponibile per qualche motivo (l'rpc ritorna errori o non ritorna perchè il server è morto) la successiva chiamata alla getBestServer(modulo) ci porterà su un'altro server.dove un componente analogo sarà pronto a soddisfare la nostra richiesta. E' quindi necessario comunque un minimo di duplicazione per garantire il servizio, sarebbe meglio almeno 2 componenti uguali su server diversi.

Soluzione finale finale2.png

La soluzione consiste nell'avere un certo numero di server (per adesso cominciamo con 2), che gestiscono le richieste provenienti da zone diverse. Lo smistamento viene gestito da un load balancer principale che in base alla banda disponibile in quel momento la indirizza a uno dei due server, ogni server ha al suo interno tutti i moduli del sistema ed è quindi autonomo. Nel caso in cui il server scelto non sia funzionante o riscontri dei problemi dobbiamo essere in grado di rigirare la richiesta al load balancer che si occuperà di inviarla ad un'altro server che nel frattempo dovrebbe rimanere funzionante. In questo modo la maggior parte delle chiamate avviene in locale all'interno del server senza sprechi di tempo e di banda, mentre per quanto riguarda l'interazione col database va comunque utilizzato un sistema in remoto che garantisca un certo distacco dal resto dei moduli; in questo modo aumentiamo la sicurezza dagli attacchi perchè nascondiamo nei parametri (che sono encodificati) i dettagli del database. (Vedi immagine in "architettura generale del sistema"). Essendo il modulo "photo" il più pesante soprattutto in termini di spazio possiamo ipotizzare di dover utitlizzare altri 2 server con un hard-disk di dimensioni maggiori esclusivamente per lo storage di immagini. Per la questione del database invece riteniamo troppo pesante doverlo replicare ogni volta che si aggiunge un nuovo server, per questo motivo adottiamo la soluzione di utilizzare dei server al solo scopo di contenere dei Mysql Cluster. In questo modo garantiamo anche maggior sicurezza in quanto se venissero compromessi i server apache non è comunque possibile prendere possesso dei database in quanto essi sono esterni. Per quanto riguarda le frecce gialle vanno direttamente sui server img.visageme.com ma non immediatamente: infatti il browser fa la richiesta ai server apache passando per il load-balancer, esso gli ritorna l'indirizzo del server effettivo sul quale deve fare l'upload (e forse anche un token per autorizzare ad uploadare) e solo a quel punto il browser uploada sul server che gli è stato indicato. Vantaggi: ovviamente in questo modo le chiamate a procedura sono quasi completamente in locale, quindi evitiamo spreco di banda e di tempo. Svantaggi: vi è una duplicazione completa dei moduli sui server che in certi momenti risulta inutile. (Sarebbe bello poter creare e distruggere moduli e componenti a tempo di esecuzione ma per il momento ci limitiamo alla creazione statica) Fault tolerance: nel caso in cui un componente risulti non disponibile per qualche motivo la chiamata deve poter essere inoltrata al componente analogo sull'altro server quindi si deve ritornare la chiamata al load balancer che la gira dall'altra parte. Sarebbe una buona idea tenere ogni immagine su almeno 2 server distinti in modo che in caso di grave guasto di un server le immagini rimangano comunque accessibili e ripristinabili. Il database inoltre potrebbe, per comodità e risparmio di server, essere collocato nei server delle immagini.

Server Side

Diagrammi delle classi ADministratoR2.png Authenticator.jpg

Feedbackmanager.jpg Locator.jpg PhotoManager.jpg REGISTRATor.jpg Paneleditor.jpg DBOPERATOr.jpg

Diagrammi di interazione dei componenti per le principali operazioni Registration.png

AddDeletePhoto.png ReadFeedback.png Recognize.png

Client Side

Diagrammi del comportamento dei client

Desktop.png Mobile.png

Piani di collaudo

In allegato lo zip delle Test Unit
Download PhpTestUnit

Il modello dei dati del sistema

DB Side

Schema ER: ERDomainModel.png
Diagramma Logico: LOGICO.png

Application Side

Diagramma UML: UMLDomainModel.png

Diagramma dell'interazione MobileClient - Server

VisageMobileClientBackEnd.png

Sviluppo mobile client

L'idea iniziale da cui siamo partiti per il nostro progetto è lo sviluppo di una applicazione per dispositivi mobili che consenta il riconoscimento facciale tramite Realtà Aumentata. Per questo l'esperienza dell'utente sarà incentrata principalmente nell'utilizzo di questa applicazione per la fruizione del servizio e del sito web per la gestione dell'account e delle varie preferenze sulla privacy. Lo sviluppo è stato inizialmente pensato per dispositivi basati su piattaforme Andoid ed iOS e poi realizzato solamente per Android per la facilità di sviluppo in suddetto ambiente e per la diretta disponibilità di soli smartphone dotati di tale sistema.Il tutto è stato diviso in UserInterface e Controller development garantendo uno sviluppo separato ed indipendente delle 2 parti.La parte UserInterface comprende la gestione grafica dell'interfaccia.La parte Controller invece comprende:
  • l'interazione con il server;
  • la gestione dello storage;
  • il riconoscimento facciale;

UserInterface:

Descritto dal grafico seguente, abbiamo esposto la relazione tra le Activities del nostro client. Untitleddrawing1.jpg

Il Controller:

La gestione dello storage:Crediamo non sia rilevante soffermarsi su questo in dettaglio; comprende l’utilizzo delle API Android per il salvataggio delle preferenze e dei dati dell’utente loggato.Il riconoscimento facciale:Questa sezione comprende le classi specializzate nel riconoscere le facce inquadrate dalla fotocamera, o da una immagine selezionata dal filesystem, nel ritagliarle e tramite le nostre API inviarle al Server per il riconoscimento.Interazione con il Server:Gestisce la comunicazione con il server tramite richieste HTTP (HTTPS in futuro). Abbiamo fatto in modo che fornisse a tutte le altre parti dell’applicazione un’interfaccia di alto livello che permettesse di nascondere i veri dettagli dell’interazione con il Server stesso. Ogni metodo di questa interfaccia corrisponde ad un certo tipo di richiesta che può essere effettuata al server. A seguire elenchiamo le principali caratteristiche del sistema di comunicazione con il server:
  1. è basato sulla libreria Apache HttpClient integrata di default in tutte le versioni di Android
  2. Non è dipendente della piattaforma Android, il codice può essere riutilizzato su qualsiasi altra piattaforma Java
  3. Supporta l'esecuzione di richieste concorrenti, si possono utilizzare thread diversi per ogni richiesta.
  4. Cerca il più possibile di riutilizzare le connessioni TCP già instaurate per le richieste successive.
  5. la comunicazione con il server avviene a basso livello tramite JSON trasferiti con delle richieste HTTP POST, in grado quindi di attraversare senza problemi NAT, firewall e proxy di vario tipo, frequentemente utilizzati nelle connessioni mobile. Essendo l’HTTP un protocollo stateless, vengono tollerate le disconnessioni tra una richiesta e l’altra, ed anche un cambio di indirizzo ip, che avviene per esempio passando da una connessione Wifi ad una UMTS. L’upload dei file avviene invece inviando un’entità HTTP di tipo MIME multipart, in modo da non sprecare banda con l'encoding base64.
  6. Ad ogni richiesta viene inviato al server il proprio token di autenticazione, tuttavia questo viene mascherato agli utilizzatori, tramite una classe che rappresenta una sessione di comunicazione con il server, nella quale viene memorizzato il token.
  7. le classi sono state scritte in modo da essere altamente riutilizzabili per un'applicazione che richiede una interazione con un server simile a questa.
  8. può utilizzare connessioni criptate HTTPS anche con un certificato del server autofirmato copiato sul cellulare tramite un canale di comunicazione sicuro, come il market di Android. In questo modo si può avere una connessione sicura senza dover acquistare un certificato SSL da una Certification Authority

Tecnologie di riferimento

Server Side

Per Quanto riguarda il core del sistema:

  • Linguaggio di riferimento: PHP
  • MySql Cluster
  • Zend Framework
  • Facebook e face.com API
  • Meccanismo di comunicazione JSON

Client Side

Per quanto riguarda l'applicazione web:

  • JavaScript
  • HTML5
  • CSS3

Per quanto riguarda l'applicazione mobile:

  • Android SDK
  • Meccanismo di comunicazione JSON
  • Facebook API

Sviluppo e Deployment del sistema

Abbiamo scelto un dominio collegato ad un web server Apache2 che risiede su un Linux Ubuntu Server 11.04 già in nostro possesso; per quanto riguarda il database è stato utilizzato un DBMS MySQL in quanto era una tecnologia da noi conosciuta in corsi precedenti.
Per quanto riguarda l'applicazione web, essa è stata sviluppata seguendo i paradigmi della programmazione ad oggetti tramite il linguaggio PHP.
Sono state costruite classi per ogni modulo e per ogni oggetto che era stato individuato in precedenza; le varie pagine web del sito che ospita il nostro servizio si preoccupano di chiamare determinati metodi statici di quelle classi e solo nel caso in cui ci si debba interfacciare con il database i moduli stessi richiamano un modulo esterno tramite metodo POST. Il tutto è gestito tramite eccezioni e in caso di errori il database viene ripristinato tramite un rollback manuale.
Abbiamo munito il servizio di un sistema di log che ci permette di controllare l'attività degli utenti per comprendere quali sono i passi compiuti con più frequenza e per poter individuare gli errori che avvengono durante l'utilizzo.
Inoltre consentiamo agli utenti di informarci tramite feedback riguardo i loro interessi e i possibili sviluppi che gradirebbero vedere nel nostro servizio e soprattutto a proposito dei problemi che hanno riscontrato. Abbiamo perfezionato l'iscrizione al servizio con un sistema di conferma del possesso della mail con cui ci si registra come fa la maggior parte dei siti di un certo livello, che consiste nell'inserimento di un codice che viene inviato via mail.

Note critiche e possibili sviluppi futuri

Per il momento il nostro servizio è totalmente dipendente da Face.com che ci permette il riconoscimento facciale tramite delle API relativamente semplici; nel caso in cui esso dovesse fallire o per qualche motivo diventare a pagamento dovremmo verificare se sia più conveniente implementare un riconoscimento interno o preferire un altro tipo di servizio.

Al momento il sistema è stato predisposto per gestire anche la posizione degli utenti in modo che la ricerca nel database dei volti venga ristretta a determinate aree geografiche per limitare lo spreco di risorse, ma questa funzionalità non è ancora stata implementata.
Sarebbe possibile recuperare le immagini del profilo e i nomi degli amici di facebook delle persone che si registrano al nostro servizio ma per il momento abbiamo lasciato da parte questo metodo di recuperare volti che aiutino la ricerca per evitare problemi legati alla privacy. In questo caso la ricerca verrà effettuata seguendo delle priorità (foto caricate priorità 1, foto catturate tramite api di facebook priorità 2).
Un ulteriore sviluppo potrebbe essere quello di chiedere all'utente che ottiene il risultato della ricerca se effettivamente ha trovato la persona che stava cercando e in caso di risposta positiva aggiungere quella foto alle foto di quella persona in modo da affinare una ricerca successiva.
Volendo incrementare il legame con facebook potremmo inviare delle notifiche alla persona che viene riconosciuta nella foto in modo da poter avere anche delle conferme dirette sul fatto che sia lei o meno e quindi dei feedback diretti.
Per il momento ci siamo occupati di gestire un solo tipo di account (Facebook) ma è ovviamente consequenziale che estendere alla gestione di altri account andrebbe solo ad intaccare la registrazione e la visualizzazione degli account al momento del riconoscimento senza creare alcun tipo di problema.

Conclusioni

Tramite questo progetto siamo riusciti ad ideare un sistema che sia in grado di funzionare anche in presenza di guasti ad uno qualsiasi dei server, e che riesca a servire un numero grande a piacere di utenti semplicemente aggiungendo nuovi server quando è necessario.
Nella nostra realizzazione sperimentale del progetto, per il momento abbiamo utilizzato un solo server per testare il corretto funzionamento del software da noi realizzato. Tuttavia abbiamo implementato il tutto in modo che sia in grado di funzionare con un numero molto elevato di server, soddisfacendo quindi i requisiti di scalabilità e fault tolerance.