Sistema di videosorveglianza

{

{style:type=span|font-family=Arial,sans-serif}La Classe CamViewer sarà la classe di inizializzazione, che si occuperà anche di gestire i cambiamenti di immagine.

{style:type=div|align=justify}{style:type=span|font-family=Arial,sans-serif}Image è stata introdotta per poter permettere un futuro adattamento, ad esempio se si vogliono far visualizzare più camere insieme, mediante questa classe sarà più facile.

\

{style:type=span|font-family=Arial,sans-serif}eventList si occupa invece della raccolta degli eventi, quindi sarà l'archivio degli eventi (una sorta di cache interna).

{ \

{style:type=span|font-family=Arial,sans-serif}MapLocator è la classe che gestisce la mappa. ItemOverlay sono i punti da gestire.

{style:type=span|font-family=Arial,sans-serif}-

{style:type=div}{

{style:type=span|font-family=Arial,sans-serif}Questa è una struttura un pò più complessa, ma comunque con poche entità da definire.

{style} \

{style:type=span|font-family=Arial,sans-serif}Web Server

\ \

{style:type=span|font-family=Arial,sans-serif}Java CamViewer

{ \{style:type=div|align=justify}Queste sono le interazioni tra l'utente che usa il sito web e il sistema. Riguardo l'applicazione Android, dato che abbiamo bisogno della visualizzazione degli eventi e delle camere, avremo che tutto sarà sincrono, per meglio dire, quando richiedo la lista delle camere, aspetto la risposta e poi visualizzo. Per la lista degli eventi stessa cosa. Finchè non ho ricevuto tutto l'applicazione rimane in attesa. Vediamo ora su quali caratteristiche ci vogliamo focalizzare, in modo da iniziare a predisporre il sistema alla distribuzione. Partiamo ovviamente dalla correttezza. Che cos'è la correttezza? Un programma o sistema software si dice corretto se si comporta esattamente secondo quanto previsto dalla sua specifica dei requisiti. Più difficoltoso sarà rendere il sistema completamente affidabile, dati anche i tempi ridotti per realizzarlo, si parlerà comunque di possibili soluzioni a problemi, in modo da poter permettere in futuro un possibile miglioramento. Ovviamente il sistema deve risultare usabile, ovvero facile da utilizzare e da comprendere. Questo aspetto non è difficile da affrontare, in quanto uno stile grafico "organizzato" permette all'utente di capire qual'è la funzione che vuole attivare. Quello che ci interessa di più è la scalabilità che può essere geografica, di calcolo o amministrativa. Ci interessano al momento le prime due.  Un sistema geograficamente scalabile è quello che mantiene inalterata la sua usabilità e utilità indipendentemente dalla distanza fisica dei suoi utenti o delle sue risorse; questa condizione è già verificata dai modelli sopra descritti. Ovviamente, la scalabilità di calcolo dipende anche dalle linee di comunicazione e dalla loro velocità a trasmettere i dati, pertanto il nostro compito sarà quello di scomporre i vari componenti in modo da adattarli a cambiamenti di questo tipo. I componenti sui quali focalizzarci per ottimizzare questo tipo di scalabilità sono sostanzialmente il gestore di segnale e le forme di interazione con il web server. Perchè il gestore di segnale può causare problemi? Se 1000 utenti inviano un segnale d'allarme in contemporanea può verificarsi un rallentamento (se si utilizza un solo gestore). Una soluzione a questo problema è quella di scomporre il gestore e metterne in giro più di uno, così pure più di un server web. Ci sarà un server centrale che random reindirizzerà le richieste degli utenti ad altri server, e questi server (in caso di segnale), invieranno l'allarme a un gestore qualsiasi. In pratica una sorta di superserver, che risolve il problema dell'uso di una porta univoca. Il sistema deve quindi fare in modo che ad ogni richiesta utente sia assegnata una porta diversa e non intralciare il traffico di altre forme d'interazione. Un altra soluzione al problema potrebbe essere simile alla prima già descritta, con la variante che le porte dei gestori di segnale siano divise per area geografica. Spiegando meglio: poniamo il caso che i clienti siano metà in provincia FC, metà in provincia di Modena. Quando essi contattato il sito web, quest'ultimo assegna la porta del gestore e chiamerà il gestore in base alla zona. Se ci sono 5 sensori, i primi 2 sono in ascolto nella porta 9000 e 9001 per esempio, ebbene, questi saranno quelli chiamati. L'uno dalla provincia FC e l'altro dalla provincia MO. In questo caso si ha bisogno di riconoscere la zona e quindi di introdurre nuove funzioni. La miglior scelta sarebbe una scelta random dei gestori. Se in futuro il messaggio inviato sarà di gran lunga superiore a quello attualmente utilizzato (con sole le informazioni utente), si potrebbe adottare un'altra soluzione: fare in modo che ad ogni connessione tra segnal sender e signal receiver, venga associata una porta random. Ci interessa predisporre il sistema anche per modifiche future. Questa caratteristica è la manutenibilità o evoluzione del software. La scomposizione dei vari componenti, permette un migliore approccio verso la modifica e il miglioramento del sistema stesso. L'essere un sistema eterogeneo è invece la caratteristica cuore di questo sistema. La codifica in formato JSON permetterà la comunicazione con qualsiasi piattaforma, dato che si tratta di un formato standard. Ogni messaggio sarà spedito secondo questa codifica e gestito nel modo più appropriato. Il protocollo usato è sostanzialmente l'HTTP (con formato XML), ma per comunicazioni affidabili (per i segnali d'allarme) utilizziamo il TCP. Nel diagramma notiamo che è l'utente a inviare la segnalazione e qui c'è un attimo da chiarire le cose. Attualmente non ci è possibile implementare un sistema automatico che riconosca movimenti "estranei" della camera, quindi abbiamo introdotto una segnalazione manuale che può comunque avere un'utilità. Pensiamo al fatto che un cliente vada all'estero e dia le credenziali per controllare ad un altra persona. In quel caso se c'è qualche problema la persona può avvertire immediatamente il cliente dell'anomalia tramite sito web in modo veloce. L'anomalia in questo caso può anche rappresentare un semplice errore nella visualizzazione della camera e non solo un movimento allarmante. \

FASE PROGETTUALE

Interazione del sistema

In conclusione, l'interazione di tutti i componenti del sistema è riassunta in figura. Modello interazione

PATTERN

I pattern individuati sono: {style:type=div|align=center}{ Un proxy, nella sua forma più generale è una classe che funziona come interfaccia per qualcos'altro. L'altro potrebbe essere qualunque cosa: una connessione di rete, un grosso oggetto in memoria, un file e altre risorse che sono costose o impossibili da duplicare. Nel nostro caso è un immagine. Questo pattern è stato usato anche per il refresh dell'immagine nel sito web. l'immagine proxy è stata creata in javascript. \ { Questo pattern ci aiuta semplicemente ad evitare di creare più istanze della connessione (causerebbe solo rallentamenti o addirittura malfunzionamenti). \{ Questo pattern è molto utile per dare la giusta responsabilità alla giusta entità. Quindi un entità ha la responsabilità di leggere il messaggio, per poi darlo in mano all'entità che smista il messaggio nel modo appropriato.