Post on 17-Feb-2019
UNIVERSITA’ DEL SALENTO
FACOLTA’ DI INGEGNERIA
CORSO DI LAUREA IN INGEGNERIA DELL’INFORMAZIONE
Tesi di Laurea in Software Design Principles
Progettazione e sviluppo di
un’infrastruttura per dispositivi mobile
per la gestione di sistemi domotici
RELATORE
Ing. Andrea Pandurino
CORRELATORE
Ing. Alberto Bucciero
LAUREANDO
Luigi Vigneri
ANNO ACCADEMICO 2010/2011
Alla mia famiglia,
che mi ha sempre supportato nelle scelte.
INDICE
CAPITOLO 1 – INTRODUZIONE _________________________ 6
1.1 Analisi del contesto ………………………………………... 6
1.2 Obiettivi del progetto ………………………………………… 8
1.3 Struttura della tesi …………………………………………………….. 9
CAPITOLO 2 – STATO DELL’ARTE _________________________ 10
2.1 Domotica …………………………………………………………………. 10
2.1.1 Definizione e obiettivi 10
2.1.2 La casa di Bill Gates 12
2.2 Android ………………………………………………………………... 14
2.2.1 “Is this interesting to Google?” 14
2.2.2 Fondamenti di programmazione 17
2.2.3 Architettura 18
2.3 Impianti domotici ……………………………………………………. 20
2.3.1 Sistemi domotici 20
2.3.2 Applicazioni mobile per la domotica 23
CAPITOLO 3 – PROGETTAZIONE _________________________ 24
3.1 Programmazione del lavoro …………………………... 24
3.2 Raccolta e definizione dei requisiti utente …… 25
3.3 Use case ………………………………………………………………. 26
3.3.1 Invio comando 26
3.3.2 Eliminazione comando db lato server 28
3.4 Progettazione del database …………………………… 29
3.4.1 Diagramma ER 29
3.4.2 Modello relazionale 30
3.4.3 Dizionario dei dati 31
3.5 Progettazione dell’applicazione ……………….. 32
3.5.1 Sequence diagram 32
3.5.2 Object diagram 33
3.5.3 Deployment diagram 34
3.6 Modello di architettura ……………………………………….. 34
CAPITOLO 4 – IMPLEMENTAZIONE _________________________ 36
4.1 Descrizione sistema realizzato …………………………… 36
4.2 Implementazione TCP Server …………………………… 37
4.3 Screenshot ………………………………………………………………. 39
4.4 Testing ………………………………………………………………. 39
CAPITOLO 5 – CONCLUSIONI _______________________________ 41
5.1 Strumenti di design utilizzati ……………………………. 41
5.2 Tecnologia Near Field Communication ……. 41
5.2.1 Applicazioni context aware 41
5.2.2 Tecnologia NFC 42
5.3 Sviluppi futuri …………………………………………………… 44
5.4 Conclusioni …………………………………………………… 45
APPENDICE A – DOMOS CONTROLLER ___________________ 46
A.1 Domos Controller …………………………………………………… 46
A.2 Class diagram …………………………………………………… 46
A.3 Screenshot ………….…………………………………………………… 48
Bibliografia …………………………………………………………………………………….... 49
Ringraziamenti …………..……………………………………………………………... 50
Capitolo 1 - INTRODUZIONE
6
CAPITOLO 1 – INTRODUZIONE
1.1 ANALISI DEL CONTESTO
Negli ultimi anni l’importanza che l’informatica riveste nella vita di ogni
giorno per ciascuno di noi è aumentata esponenzialmente. Non si tratta
più di un semplice vizio o gioco per ricchi, ma di un fondamentale aiuto
che viene utilizzato talvolta senza nemmeno rendercene conto: dal
momento in cui disattiviamo la sveglia del cellulare la mattina, a quando
programmiamo il microonde, alla sera in cui impostiamo l’allarme prima di
andare a letto, l’informatica riveste un ruolo primario in tutte le nostre azioni
quotidiane. Tutta questa tecnologia non è, però, sempre di facile
comprensione per tutti coloro che non masticano bit abitualmente; anzi, la
sovraesposizione ad un eccessivo sviluppo informatico a cui siamo
sottoposti in continuazione provoca un senso di difficoltà e di
inadeguatezza a chi si perde tra GSM, WAP, iPad, RAM e ROM. Lo scopo
fondamentale del semplificare la vita, spesso diventa un incomprensibile
groviglio di informazioni aggiuntive e ridondanti che tante volte vanno a
sovraccaricare (e non poco) la nostra vita.
Capitolo 1 - INTRODUZIONE
7
La domotica è una nuova disciplina che si occupa dello sviluppo di “case
intelligenti”; consente all’immobile ad adattarsi alle condizioni e alle
abitudini di chi ci vive in modo da ottenere vantaggi in termini di
divertimento, relax e risparmio. Non è l’utente ad ingegnarsi per sfruttare
dei servizi aggiuntivi, ma è l’abitazione a modificare il proprio stato in base
al contesto: presenza di persone, data ed ora, temperatura, meteo. Per
questi motivi il concetto di domotica è estendibile non solamente ai
giovani che generalmente hanno un approccio pionieristico al campo
informatico, ma anche a quelle fasce della popolazione che spesso
interpretano la tecnologia come un corpo estraneo, un qualcosa di
superfluo che può essere bypassato senza risentire di conseguenze
tangibili: si passa dalle casalinghe ai dipendenti di imprese, dall’ambito
scolastico alle persone con problemi motori.
Lo sviluppo del settore è ancora in leggero ritardo in Italia, rispetto, per
esempio, agli Stati Uniti, dove la creazione di standard e la pubblicità
positiva a cui è sottoposta la domotica, unita al fascino di vivere in un
ambiente con cui interagire in maniera diretta, stanno contribuendo ad
una diffusione capillare.
Questo è senza dubbio un campo in continuo sviluppo ed ancora oggi non
sono state ben interpretate le prestazioni che è possibile raggiungere
attraverso la ricerca in questo settore. In particolar modo, il controllo da
remoto di dispositivi domotici è ancora per molti aspetti una scatola nera,
una black-box che deve essere esplosa per essere compresa e studiata a
Capitolo 1 - INTRODUZIONE
8
fondo. Infatti analizzando i principali market per dispositivi mobile, si
trovano ben poche applicazioni che consentono un efficace controllo di
centraline domotiche.
1.2 OBIETTIVI DI PROGETTO
Obiettivo di questa trattazione è quello di progettare e implementare
un’infrastruttura per la gestione di un impianto domotico controllato da una
qualsiasi centralina. A tale scopo, oltre allo sviluppo dell’applicazione vera
e propria, che esula dagli scopi di questa documentazione, è stato creato
un server TCP che simuli la ricezione di un comando da parte di una reale
centralina. L’infrastruttura così creata ha enormi potenzialità che spaziano
dal caricamento di singoli comandi alla possibilità di esportazione di
scenari predefiniti riusabili da una pluralità di utenti aventi accesso al
database lato server. Al momento della ricezione del comando, poi, sarà
compito della centralina, dopo aver riconosciuto e interpretato la stringa
ricevuta, mettere in funzione i corrispondenti attuatori in modo da eseguire
l’azione richiesta.
Inoltre, ulteriore sviluppo da trattare, riguarda lo stato dell’arte della
tecnologia NFC, che, molto probabilmente, nei prossimi anni si imporrà
come tecnologia leader nello scambio informativo a breve distanza.
Capitolo 1 - INTRODUZIONE
9
1.3 STRUTTURA DELLA TESI
Il presente lavoro di tesi ha lo scopo di effettuare un tuffo nel futuro
cercando di anticipare le tecnologie che tra dieci anni saranno comuni
come un telefono cellulare. Nel Capitolo 1 si analizzeranno da un punto di
vista descrittivo il sistema operativo Android e gli scopi e le principali
applicazioni domotiche, dando uno sguardo al più avanzato esempio di
“casa intelligente”, la residenza di Bill Gates. Inoltre si farà il punto sullo
stato dell’arte delle principali centrali e applicazioni in ambito domotico.
Il successivo Capitolo 2 riguarderà la progettazione dell’infrastruttura; essa
sarà sviluppata in parallelo ad un’applicazione domotica originale per
dispositivi Android, a cui verrà accennato solamente in Appendice. La
progettazione si avvarrà di diagrammi UML e dei principali modelli utilizzati
nella teoria delle basi di dati.
L’implementazione, infine, sarà trattata nel Capitolo 3, a cui seguirà una
breve descrizione della tecnologia NFC nel capitolo successivo.
Capitolo 2 – STATO DELL’ARTE
10
CAPITOLO 2 – STATO DELL’ARTE
2.1 DOMOTICA
2.1.1 Definizione e obiettivi
La domotica è nata nel corso della terza rivoluzione industriale allo scopo
di studiare, trovare strumenti e strategie per:
Migliorare la qualità della vita;
Migliorare la sicurezza;
Risparmiare energia;
Semplificare la progettazione, l’installazione, la manutenzione e
l’utilizzo della tecnologia;
Ridurre i costi di gestione;
Convertire i vecchi ambienti e i vecchi impianti.
La casa intelligente può essere controllata dall’utilizzatore tramite
opportune interfacce utente (come pulsanti, telecomando, touch screen,
tastiere, riconoscimento vocale), che realizzano il contatto, tramite invio di
comandi, con il sistema intelligente di controllo, basato tipicamente su
un’unità computerizzata centrale. Il sistema di controllo provvede a
Capitolo 2 – STATO DELL’ARTE
11
svolgere i comandi impartiti dall’utente, a monitorare continuamente i
parametri ambientali, a gestire in maniera autonoma alcune regolazioni e
generare eventuali segnalazioni all’utente o ai servizi di teleassistenza. Un
sistema domotico si completa, di solito, attraverso uno o più sistemi di
comunicazione con il mondo esterno (messaggi telefonici preregistrati,
SMS, generazione di pagine web o e-mail) per permetterne il controllo e la
visualizzazione anche da remoto.
Le soluzioni tecnologiche che possono essere adottate per la realizzazione
di un sistema domotico sono caratterizzate da peculiarità d’uso proprie
degli oggetti casalinghi: semplicità, continuità di funzionamento, affidabilità
e basso costo. Inoltre queste tecnologie permettono numerosi vantaggi, tra
i quali l’automatizzazione di azioni quotidiane e il risparmio energetico: un
sistema completamente automatizzato dovrà evitare i costi generati da
sprechi energetici dovuti a dimenticanze o ad altre situazioni, monitorando
continuativamente i consumi e gestendo le priorità di accensione degli
elettrodomestici.
A fronte di esigenze diversificate e complesse come quelle di anziani e
disabili, questi nuovi impianti tecnologici sono una risposta concreta con
ricadute positive sui familiari e la società in generale.
Il Centro Universitario Edifici Intelligenti ha studiato soluzioni abitative per
le persone con problemi mentali. L'obiettivo del progetto è di realizzare un
ambiente che offra maggiore autonomia e sicurezza, ma soprattutto fare
Capitolo 2 – STATO DELL’ARTE
12
della casa quasi uno strumento didattico, in grado di facilitare il disabile a
gestirsi da solo.
Inoltre, appena due anni fa un gruppo di ricerca dell'Università La
Sapienza di Roma ha realizzato la prima casa domotica controllata dagli
impulsi cerebrali. Una speciale cuffia munita di elettrodi capta le onde
generate dal cervello e un computer collegato alla cuffia e agli impianti
elettrici della casa legge gli impulsi e li traduce in comandi, come aprire
una porta o evitare un ostacolo. In un prossimo futuro questi ausili
aiuteranno coloro che hanno perso in parte o del tutto il controllo di arti e
muscoli.
2.2.2 La casa di Bill Gates
La casa di Bill Gates è situata sulle rive del lago Washington, vicino a
Seattle. Per realizzarla sono stati spesi circa cento milioni di dollari e
rappresenta forse l’esempio più avanzato di casa intelligente dei nostri
giorni.
Ad ogni ospite della casa viene fornita una speciale chiave elettronica che
comunica costantemente la sua posizione al sistema. In questo modo è
possibile che ogni ambiente reagisca alla presenza dei suoi occupanti
cercando quasi di anticipare i loro desideri ed esigenze: luci e temperatura
vengono regolate in modo da ricreare un ambiente familiare e
Capitolo 2 – STATO DELL’ARTE
13
confortevole; il sistema é in grado di memorizzare le scelte fatte da ogni
ospite durante la sua permanenza in una stanza, tramite placchette
sensibili posizionate opportunamente oppure grazie a un telecomando, e
di reimpostarle quando, dopo un periodo di assenza, vi ritorna. Schermi
fissati alle pareti, inoltre, propongono vari tipi di decorazioni o paesaggi e
l’impianto audio può diffondere la musica preferita. L’impianto di
comunicazione è altrettanto sofisticato: le chiamate in arrivo vengono
inoltrate automaticamente al telefono che si trova nelle immediate
vicinanze del destinatario. Se due o più persone si riuniscono nella stessa
stanza il computer può creare una miscela di stili diversi che incontri i gusti
di tutti; viene cioè memorizzato un particolare “profilo utente” per ogni
ospite che permette al sistema di autoregolarsi al suo passaggio.
La casa è inoltre dotata di una saletta per le proiezioni dove una ventina di
persone possono usufruire di uno schermo TV ad alta definizione. Nei
pressi troviamo poi un paio di uffici e una saletta-computer. I pavimenti ed
il viale di accesso sono riscaldati in modo da assicurare il massimo
comfort all’interno ed evitare la formazione di ghiaccio durante l’inverno.
Tutto questo è reso possibile da una rete di chilometri di cavi che
interconnette tra loro alcuni server (Windows NT ovviamente) parecchi PC
con le relative periferiche, e i sistemi di comunicazione.
Capitolo 2 – STATO DELL’ARTE
14
Figura 2.1: Immagine 3D della casa di Bill Gates
2.2 ANDROID
2.2.1 “Is this interesting to Google?”
Android è un sistema operativo opensource per dispositivi mobile basato
su kernel Linux. La piattaforma usa il database SQLite, la libreria dedicata
SGL per la grafica bidimensionale e supporta lo standard OpenGL per la
grafica tridimensionale. Le applicazioni vengono eseguite tramite la Dalvik
virtual machine, una macchina virtuale adattata per l’uso su dispositivi
mobili.
L’evoluzione di Android ha portato Google a sviluppare un sistema in cui
ogni nuova release rappresenta uno step evolutivo sostanziale di quello
che oggi è uno dei punti di riferimento per il mercato degli smart-phone,
giocandosi il ruolo di leader nel settore assieme a iOS e Windows Phone.
Capitolo 2 – STATO DELL’ARTE
15
Dietro quello che sembra l’ennesimo successo della società di Mountain
View, troviamo Andy Rubin e la sua idea:
“make a device about the size of a small candy bar that cost less than $10
and allowed users to scan objects and unearth information about them on
the Internet.”
cioè quella di realizzare un dispositivo di dimensioni contenute e dal costo
irrisorio che permetta agli utenti di scannerizzare (fotografare) oggetti ed
ottenere informazioni su di essi attraverso internet. Siamo nel 1999 e la
telefonia non è assolutamente una componente prevista per il dispositivo
di Rubin.
Nel 2002 nasce Sidekick e Rubin tiene una serie di seminari per presentare
il proprio prodotto e, durante un incontro presso la facoltà di ingegneria di
Stanford, incontra Page e Brin, emissari di Google. In realtà Page
accarezza da tempo l’idea di uno smart-device con funzioni di telefonia
incorporata, sulla falsa riga di
quanto fatto da Microsoft con
Pocket PC 2002 Phone Edition, e
l’ascesa delle connessioni wireless
sta aprendo nuovi scenari con utenti
sempre connessi, ovunque si
trovino. Figura 2.2: Sidekick 3, presentato nel 2006
Capitolo 2 – STATO DELL’ARTE
16
Nel 2005 arriva la svolta: Rubin, colpito dall’interessamento di Google,
chiede di incontrare Page e, durante il meeting, pronunciando la semplice
frase: “Is this interesting to Google?”, segna l’inizio dell’era dell’Androide.
In questo scenario la sua sturt-up, Android Inc. (Palo Alto - California), era
in grado di offrire una nuova tipologia di Mobile OS: open (basata su
Kernel Linux), attento agli standard, basato su una UI semplice e
funzionale e corredato da una serie di strumenti pensati per facilitare la vita
agli sviluppatori. Ma, soprattutto, il sistema era gratuito per chiunque
volesse utilizzarlo, poiché Rubin vedeva il proprio Business legato al
supporto ed ai servizi accessori.
Durante l’esposizione di Rubin, Page era completamente concentrato sul
prototipo Android-based, ben conscio che Google non era preparato alla
sfida del Web Mobile, nonostante questa potesse rivoluzionare gli equilibri
di mercato e scombussolare le proprie strategie. Page, inoltre, sapeva
bene che “sponsorizzare” una società terza significava dargli troppo potere
e così propose a Rubin ciò che quest’ultimo non si aspettava:
l’acquisizione di Android Inc.
Così nel 2005 Android Inc. si trasforma nella Google Mobile Division
affidata, ovviamente, alla cura di Rubin e degli altri tre co-fondatori (Rich
Miner, Nick Sears e Chris White).
Siamo a novembre del 2007 e Google scuote la comunità degli
sviluppatori, pubblicando la prima versione pubblica dell’Android Software
Capitolo 2 – STATO DELL’ARTE
17
Developer Kit e mettendo a disposizione 10 milioni di dollari per coloro che
realizzeranno le migliori applicazioni per il nuovo sistema. La strategia era
delineata: riuscire a rendere semplice e user-friendly la navigazione web
su dispositivi palmari, con Google punto di accesso al mondo della Rete.
2.2.2 Fondamenti di programmazione
Ai fini della programmazione, il team di Android ha specificato nella
documentazione ufficiale vari termini per definire i vari tipi di applicazioni.
Attività. Le attività sono quelle applicazioni destinate a una interazione
diretta con l’utente. Le attività vengono generalmente distribuite sotto
forma di file .APK, vengono poi installate in delle cartelle nella memoria del
dispositivo.
Servizio. I servizi sono, al contrario, quelle applicazioni che per loro natura
svolgono delle operazioni autonome e che vengono richiamati dalle
attività al bisogno. Il sistema operativo fornisce alle applicazioni vari servizi
già pronti all’uso, per ottenere l’accesso all’hardware o a risorse esterne.
Kit di sviluppo (SDK e NDK). I kit di sviluppo rendono possibile la
creazione di applicazioni per Android anche da parte di programmatori
esterni al team di Android.
Capitolo 2 – STATO DELL’ARTE
18
Frammento. Il frammento è quella porzione di codice che gestisce la parte
grafica, in base alle possibilità del dispositivo su cui è installato (ad
esempio smart-phone o tablet).
Il file APK. Il software viene solitamente distribuito sotto forma di pacchetto
autoinstallante, in un file con estensione .APK. Questo non è altro che un
file compresso, contenente il software, le sue risorse e alcuni file XML.
Android SDK. Le applicazioni di Android sono sviluppate all’interno di un
framework, ossia di una struttura dati specifica. La struttura del framework
è molto chiara se si utilizza l’ambiente di sviluppo (SDK) con Eclipse.
Dalvik Virtual Machine. Negli ambienti Android non viene utilizzata la
macchina virtuale Java: è stata scritta una nuova VM chiamata Dalvik
Virtual Machine.
2.2.3 Architettura
La piattaforma Android è ben strutturata e stratificata a tal punto che ha
poco da invidiare a quelle dei comuni sistemi desktop.
I vari elementi architetturali sono principalmente mutuati dal mondo
OpenSource. Possiamo riassumerli nei seguenti punti:
Il cuore del sistema è basato sul kernel di Linux (versione 2.6) che
costituisce il livello di astrazione di tutto l’hardware sottostante che
Capitolo 2 – STATO DELL’ARTE
19
può includere wi-fi, bluetooth, GPS, fotocamera, touchscreen … I
produttori di telefoni possono quindi intervenire già a questo livello
per personalizzare i driver di comunicazione con i propri dispositivi.
Grazie all’astrazione dell’hardware, infatti, i livelli soprastanti non si
accorgono dei cambiamenti hardware, permettendo una
programmazione ad alto livello omogenea ed una user experience
indipendente dal device.
Figura 2.3: architettura Android
Il livello superiore riguarda l’equipaggiamento software costituito
dalle librerie fondamentali che gestiscono per esempio la grafica 2D
Capitolo 2 – STATO DELL’ARTE
20
e 3D (OpenGL ES), browser con engine WebKit o il supporto al
database (SQLite).
L’ambiente di runtime è costituito invece da una libreria core e da
una macchina virtuale (VM): insieme costituiscono la piattaforma di
sviluppo per Android. La VM di Android è versione particolare della
Java Virtual Machine (chiamata Dalvik), progettata e ottimizzata
appositamente per girare su hardware non performanti, come quelli
dei cellulari appunto.
Al penultimo livello è possibile rintracciare i gestori e le applicazioni
di base del sistema. Ci sono gestori per le risorse, per le applicazioni
installate, per le telefonate, il file system e altro ancora.
Al livello più alto risiedono le applicazioni utente. Le funzionalità base
del sistema, come per esempio il telefono, non sono altro che
applicazioni utente scritte in Java e che girano ognuna nella sua
JVM.
2.3 IMPIANTI DOMOTICI
2.3.1 Sistemi domotici
Molti dei requisiti, che un sistema domotico deve necessariamente avere
per poter soddisfare le esigenze dell’utente, sono purtroppo in contrasto tra
Capitolo 2 – STATO DELL’ARTE
21
loro e questo è il motivo che ha portato i produttori a sviluppare delle
soluzioni spesso estremamente diverse tra di loro. Alcuni hanno fatto
dell’economicità il requisito fondamentale del loro sistema, spesso
rinunciando all’implementazione di caratteristiche che avrebbero
aumentato la soddisfazione dell’utente finale. Altri, invece, hanno
sviluppato sistemi capaci di integrare un numero molto elevato di
applicazioni, mettendo in secondo piano l’aspetto economico. La
conseguenza di ciò è che il prodotto di un’azienda spesso è incompatibile
con quello di una concorrente, dando vita ad uno scenario di mercato
estremamente eterogeneo.
Il settore domotico ha risentito di questa mancanza di omologazione ed è
uno dei principali fattori, oltre alla grande disinformazione e alla scarsa
offerta, che ne ha impedito l’esplosione finora. Questo processo, però,
sembra in fase di sviluppo attraverso il Konnex (KNX), il primo standard di
building automation aperto ed indipendente dalla piattaforma.
Per quanto riguarda il settore delle centraline domotiche e lo sviluppo di
sistemi di automazione, la situazione in Italia vede le principali ditte del
settore darsi battaglia per accaparrarsi questa nuova fetta di mercato.
Ogni marca ha vantaggi e peculiarità, contrapposte a dei limiti che evitano
di avere la pretesa del monopolio del settore.
La BTicino si colloca come azienda leader nel settore attraverso il suo
sistema MyHome lanciato nel 2001. Il suo successo è dovuto ad una serie
Capitolo 2 – STATO DELL’ARTE
22
di fattori ben precisi; si tratta infatti di un prodotto
fortemente orientato alla home automation, con una
particolare attenzione all’aspetto estetico e costantemente
aperto all’innovazione. Dal punto di vista tecnico si tratta di un bus
proprietario basato su un cavo twistato a due
conduttori.
Il ByMe di Vimar è un sistema basato sulle specifiche
dello standard Konnex. Grazie ad un’accurata progettazione, By-me integra
in modo semplice ed immediato le caratteristiche di un impianto elettrico
evoluto; bisogna però tenere presente che i componenti della linea ByMe
non sono programmabili con il software ETS di Konnex e ciò comporta un
procedimento laborioso in termini di semplicità d’uso e di configurazione.
La soluzione proposta da Vantage si basa su un
sistema ad architettura mista che prevede una
serie di unità centrali che comunicano con delle unità slave che a loro
volta controllano i moduli di ingresso e uscita. Il sistema utilizza un
protocollo proprietario con funzione “Plug and Play” che permette il
riconoscimento automatico degli elementi di sistema.
Gewiss ha recentemente introdotto nel proprio
catalogo una nuova linea di prodotti dedicati alla
domotica e denominata Chorus. Si tratta di un’innovativa risposta alle
esigenze di automazione della casa e dell’edificio, i cui punti di forza sono
Capitolo 2 – STATO DELL’ARTE
23
la totale integrazione estetica e la massima flessibilità funzionale ed
economica.
2.3.2 Applicazioni mobile per la domotica
Per quanto riguarda il lato client, sono ancora poche le applicazioni
disponibili sui market. In particolare, l’Android Market è completamente
sprovvisto di materiale degno di nota e nell’App Store di Apple la situazione
è solo lievemente migliore; le uniche degne di nota sono TCP/IP remote,
Vantage Home Controls e Domotica di IngnegniTech. La prima consente
di comunicare con qualsiasi tipo di centralina domotica che supporti lo
stack protocollare TCP/IP, ma ha un interfaccia grafica poco curata, simile
ad un comune telecomando; la seconda applicazione è un software
prodotto da Vantage per la sua centralina, ha il vantaggio di leggere la sua
configurazione e auto-sincronizzarsi con essa, ma opera solamente su
dispositivi della casa; infine, Domotica offre una gradevole interfaccia user-
friendly, ma ha il difetto di non utilizzare il TCP/IP, standard pressoché
universale nelle odierne centraline.
L’idea di base è quella di riprendere le funzionalità di TCP/IP remote,
migliorandone la veste grafica, realizzando così un ibrido tra le diverse
app.
Capitolo 3 - PROGETTAZIONE
24
CAPITOLO 3 - PROGETTAZIONE
3.1 PROGRAMMAZIONE DEL LAVORO
Per la realizzazione dell’infrastruttura e l’implementazione del database lato
server si opererà in stretta collaborazione con lo sviluppo dell’applicazione
che consente l’invio dei comandi da dispositivi mobile. Tralasciando la
parte relativa allo studio del sistema operativo Android e alla progettazione
e implementazione della suddetta applicazione, si può far riferimento alla
programmazione seguente.
La prima fase del lavoro prevede di analizzare il contesto definendo i
requisiti, funzionali e non, e gli use case cardine della progettazione;
successivamente seguirà la progettazione del database da implementare
lato client e lato server secondo le modalità riportate nel [3.4.1]; si prevede
di implementare le varie unità funzionali, con complessità sempre
maggiori, in tempi di circa una settimana, al termine della quale si
procederà con il relativo test per verificarne il corretto funzionamento.
Infine seguirà una parte di studio, esclusivamente per scopi di ricerca,
della nuova tecnologia NFC.
Il lavoro risentirà dello sviluppo dell’applicazione lato client, per questo
motivo non è semplice definire tempistiche realistiche, che tutto sommato
Capitolo 3 - PROGETTAZIONE
25
è possibile quantificare in non più di un mese, compresa la fase finale di
testing e analisi dei miglioramenti da apportare come eventuali sviluppi
futuri.
3.2 RACCOLTA E DEFINIZIONE DEI REQUISITI UTENTE
L’analisi dei requisiti rappresenta una delle prime fasi nel ciclo di vita di un
prodotto software; scopo generale dell’analisi è stabilire che cosa il
sistema in questione deve fare, come lo deve fare ed eventualmente i
dettagli sui tempi di consegna e sulle spese entro cui lo sviluppo deve
mantenersi.
I requisiti utente si suddividono in requisiti funzionali e non funzionali: i
primi si riferiscono alle funzionalità principali che il software deve essere in
grado di svolgere, mentre i secondi sono vincoli sul sistema o sul suo
processo di sviluppo.
Nel presente lavoro di tesi i requisiti funzionali sono:
Ricezione e interpretazione di comandi da un dispositivo mobile;
Creazione database copia lato server;
Gestione database tramite inserimento, modifica e cancellazione;
Invio comandi singoli a dispositivo mobile;
Capitolo 3 - PROGETTAZIONE
26
Invio database a dispositivo mobile;
Studiare le potenzialità della tecnologia NFC;
I requisiti non funzionali sono i seguenti:
utilizzo e gestione di socket TCP;
gestione database SQLite;
utilizzo di Eclipse come ambiente di sviluppo;
creazione server TCP fittizio in linguaggio Java.
3.3 USE CASE
3.3.1 Invio comando
Main Success Scenario:
1. L’utente seleziona il comando
2. L'applicazione invia il comando al server
3. Il server riceve il comando
4. Il server inoltra il comando al dispositivo
5. Il dispositivo esegue il comando
Extension:
2a: L'applicazione utilizza un socket TCP per l'invio
Capitolo 3 - PROGETTAZIONE
27
.1 Crea il socket con indirizzo IP e numero di porta del server
.2 Crea un buffer d'uscita associato al socket
.3 Scrive sul buffer il comando da inviare
3a: Il server notifica la ricezione
.1 Il server risponde con un messaggio di riscontro
.2 Dopo un timeout l'applicazione notifica la non-ricezione
Capitolo 3 - PROGETTAZIONE
28
3.3.2 Eliminazione comando database lato server
Main Success Scenario:
1. L’utente elimina un comando
2. L'applicazione invia la stringa del comando al server
3. Il server riceve il comando
4. Il server elabora il comando
5. Il server cancella il record corrispondente al comando ricevuto
Extension:
1a: L’utente effettua la scelta di cancellazione dal database server
4a: Il database verifica la stringa di controllo
.1 Verifica la prima linea del socket
.2 Cerca nel DB i record corrispondenti al comando da eliminare
.3 Elimina fisicamente dal database il comando
Capitolo 3 - PROGETTAZIONE
29
3.4 PROGETTAZIONE DEL DATABASE
3.4.1 Diagramma entità-relazione
Il modello concettuale ha lo scopo di esprimere il significato di termini e
concetti usati dagli esperti del dominio per discutere il problema e di
trovare le giuste relazioni tra concetti differenti. Nel contesto della
progettazione dei database, il modello entità-relazione è un modello per la
rappresentazione concettuale dei dati ad un alto livello di astrazione. Il
diagramma seguente mostra il modello base per la realizzazione
dell’applicazione; il modello fisico corrispondente è implementato e
popolato manualmente lato client, mentre lato server il database è il
medesimo, ma viene popolato nel momento in cui un certo comando
viene azionato dal dispositivo mobile.
Capitolo 3 - PROGETTAZIONE
30
3.4.2 Modello relazionale
Il modello relazionale è un modello logico di rappresentazione dei dati
implementato su sistemi di gestione di basi di dati. Esso si basa
sull’algebra relazionale e sulla teoria degli insiemi ed è strutturato attorno
al concetto di relazione (tabella).
Il modello relazionale consente al progettista di database di creare una
rappresentazione consistente e logica dell’informazione. La teoria
comprende anche un processo di normalizzazione in base al quale viene
selezionato uno schema ottimale.
CASA
COMANDO
CENTRALINA
STANZA_idNomePaeseVia
PK
_idNomeStringaLivelloUsoDataUsoStringa2TipoIdCentralinaIdStanza
PK
_idNomeIndirizzoIPNumPortaIdCasa
PK
_idNomeStringaNFCIdCasa
PK
FK
FK
FK
FK
Capitolo 3 - PROGETTAZIONE
31
3.4.3 Dizionario dei dati
Casa Nome Descrizione Tipo Chiave
_id Intero che si autoincrementa automaticamente e viene assegnato all'elemento appena inserito.
Intero Si
Nome Indica un nome associato all'elemento Stringa No
Paese Indica il paese della casa in oggetto Stringa No
Via Indica la via della casa in oggetto Stringa No
Stanza Nome Descrizione Tipo Chiave
_id Intero che si autoincrementa automaticamente e viene assegnato all'elemento appena inserito.
Intero Si
Nome Indica un nome associato all'elemento Stringa No
StringaNfc Indica eventuale Tag identificativo della stanza in presenza della tecnlogia NFC
Stringa No
Casa Indica l'id della casa a cui la stanza appartiene Intero No
Centralina Nome Descrizione Tipo Chiave
_id Intero che si autoincrementa automaticamente e viene assegnato all'elemento appena inserito.
Intero Si
Nome Indica un nome associato all'elemento Stringa No
IndirizzoIP Indica l'indirizzo IP della centralina Stringa No
NumPorta Indica il numero di porta a cui inviare il comando Intero No
Casa Indica l'id della casa a cui la centralina appartiene Intero No
Comando Nome Descrizione Tipo Chiave
_id Intero che si autoincrementa automaticamente e viene assegnato all'elemento appena inserito.
Intero Si
Nome Indica un nome associato all'elemento Stringa No
Stringa1 Indica la stringa principale associata ad un comando Stringa No
Stringa2 Indica la stringa secondaria associata ad un comando Stringa No
LivelloUso Indica un livello di utilizzo impostato dall'utente Intero No
Data Indica la data di ultimo utilizzo del comando Data No
Tipo Indica se il comando è una "luce", un "infisso" o "altro" Stringa No
Uso Indica il numero di volte che il comando è stato usato Intero No
Centralina Indica la centralina alla quale il comando deve essere inviato Intero No
Stanza Indica l'id della stanza a cui il comando fa riferimento Intero No
Capitolo 3 - PROGETTAZIONE
32
3.5 PROGETTAZIONE DELL’INFRASTRUTTURA
3.5.1 Sequence diagram
Un sequence diagram è un diagramma previsto dall’UML utilizzato per
descrivere uno scenario, ovvero una determinata sequenza di azioni in cui
tutte le scelte sono state già effettuate. Il sequence diagram descrive le
relazioni che intercorrono, in termini di messaggi, tra attori, oggetti di
business, oggetti o entità del sistema che si sta rappresentando.
Capitolo 3 - PROGETTAZIONE
33
Al momento della ricezione di una comando da parte del server TCP, esso
discrimina l’azione da compiere sulla base di una stringa che costituisce
una sorta di intestazione del socket: l’operazione di cancellazione è stata
già descritta nel paragrafo 3.3.2; l’inserimento nel database avviene
quando l’utente sceglie un comando (verrà effettuata una insert oppure
una update); per quanto riguarda l’operazione chiamata “select”, essa sarà
richiamata dal dispositivo mobile nel momento in cui si richiede il
caricamento di un comando già esistente nel database lato server.
3.5.2 Object diagram
L’object diagram è un diagramma di tipo statico previsto dall’UML per
descrivere un sistema in termini di oggetti e relative relazioni. Il diagramma
è molto simile a quello del class diagram e descrive gli oggetti e le relative
relazioni che sono istanziate in un determinato istante di tempo.
Capitolo 3 - PROGETTAZIONE
34
3.5.3 Deployment diagram
Un deployment diagram è un diagramma previsto dall’UML utilizzato per
descrivere un sistema in termini di risorse hardware detti nodi, e di
relazioni fra di esse. Spesso si utilizza un diagramma che mostra come le
componenti software sono distribuite rispetto alle risorse hardware
disponibili sul sistema (component diagram).
3.6 MODELLO DI ARCHITETTURA
Dal punto di vista architetturale il punto centrale dell’infrastruttura creata è
il server TCP, che riceve i comandi dai dispositivi mobile dopo aver
instaurato una connessione TCP con essi; sfrutta il DBMS SQLite per la
creazione del database lato server e la successiva gestione delle n-uple in
esso contenute. Sarebbe opportuno non associare il server TCP
Capitolo 3 - PROGETTAZIONE
35
direttamente alla centralina domotica, in quanto difficilmente avremo a
che fare con dispositivi programmabili; piuttosto, potrebbe essere utile far
funzionare il server da gateway che effettui lo smistamento dei comandi
solo nel caso in cui l’utente voglia azionare un determinato dispositivo
fisico e non nel caso di eliminazione di comandi o di richiesta degli stessi
dal database di configurazione.
Capitolo 4 - IMPLEMENTAZIONE
36
CAPITOLO 4 - IMPLEMENTAZIONE
4.1 DESCRIZIONE SISTEMA REALIZZATO
Il sistema realizzato si differenza leggermente da ciò che è stato
presentato in fase di progettazione. La differenza più importante è il
database che viene importato in fase di invio comandi: al posto di
memorizzare le informazioni relative ai comandi seguendo il modello
relazionale lato client, vengono riportate le informazioni utili in un’unica
tabella. In particolare viene replicata esclusivamente la tabella Comando
(vedi paragrafo 3.4.2). Questa semplificazione è stata ritenuta utile dal
momento che l’applicazione lato client non ha sviluppato le funzionalità
necessarie per la ricezione di una configurazione completa.
Un’ulteriore differenza rispetto alla fase di progettazione riguarda il ruolo di
transizione del server TCP: dal momento che non è stato possibile
effettuare la fase di testing su centraline reali per la mancanza dei mezzi
fisici adatti, si è pensato di simulare la loro azione tramite la classe Java
TCPserver.java; nell’implementazione eseguita il ruolo della centralina
coincide con il server TCP; in questo modo, la stringa in arrivo viene
Capitolo 4 - IMPLEMENTAZIONE
37
semplicemente visualizzata sulla console in modo da testare la corretta
ricezione del socket.
4.2 IMPLEMENTAZIONE TCP SERVER
TCPServer.java
package src.tcp.server;
import java.io.BufferedReader;
import java.io.DataOutputStream;
import java.io.IOException;
import java.io.InputStreamReader;
import java.net.ServerSocket;
import java.net.Socket;
import java.net.UnknownHostException;
import java.sql.*;
public class TCPServer
{
Viene stabilita la connessione al database SQLite chiamato test2.db. Alla prima connessione viene creata solamente la tabella comando denominata db_config
public static void main(String[] args) throws ClassNotFoundException,
SQLException {
Class.forName("org.sqlite.JDBC");
Connection conn = DriverManager.getConnection("jdbc:sqlite:test2.db");
Statement stat = conn.createStatement();
stat.executeUpdate("create table if not exists db_config (id, nome, str1,
str2, prior, tipo, centralina, stanza)");
Stampa a video indirizzo IP e numero di porta del server e resta in ascolto per la ricezione dei socket TCP inviati dal programma client. I dati contenuti all’interno dei pacchetti ricevuti saranno memorizzati in variabili di tipo String.
try {
ServerSocket ss = new ServerSocket(12345);
System.out.println(ss.getLocalSocketAddress().toString()+":"+ss.getLocalP
ort());
while(true){
Socket s = ss.accept();
System.out.println("Connection established");
BufferedReader input = new BufferedReader(new
InputStreamReader(s.getInputStream()));
DataOutputStream output = new
DataOutputStream(s.getOutputStream());
Capitolo 4 - IMPLEMENTAZIONE
38
String insert = input.readLine();
String var1 = input.readLine();
String var2 = input.readLine();
String nome = input.readLine();
String str1 = input.readLine();
String str2 = input.readLine();
String prior = input.readLine();
String tipo = input.readLine();
String centralina = input.readLine();
String stanza = input.readLine();
Sulla base della stringa di controllo contenuta in testa ad ogni pacchetto, vengono discriminate le query da eseguire sul database:
1. Insert: viene stampato su console il comando ricevuto (simulando l’invio dello stesso all’attuatore) e viene effettuato l’aggiornamento o l’inserimento della tabella db_config, nel caso in cui il comando sia già stato registrato o meno;
2. Select: vengono inviati al client tutte le informazioni relative ai comandi di una stanza richiesta;
3. Delete: vengono cancellati i record corrispondenti ad un determinato comando. Si è evitata l’identificazione con l’ID in quanto si perderebbe la corrispondenza per richieste di cancellazione di utenti diversi da colui che ha utilizzato per primo un certo comando.
String QUERY;
if (insert.equals("insert")) {
System.out.println("comando da eseguire = "+var1+"\n");
String QUERY_CHECK = "SELECT * FROM db_config WHERE str1 =
'" + str1 + "'";
ResultSet rs2 = stat.executeQuery(QUERY_CHECK);
if (!rs2.next()){
QUERY = "INSERT INTO db_config VALUES ( '" + var2 +
"', '" + nome + "', '" + str1 + "', '" +
str2 + "', '" + prior + "', '" + tipo + "',
'" + centralina +"', '" + stanza + "')";}
else{
QUERY = "UPDATE db_config SET nome = '" + nome +
"', str1 = '" + str1 + "', str2 = '" + str2
+ "', prior = '" + prior + "', tipo = '" +
tipo + "', centralina = '" + centralina +
"', stanza = '" + stanza + "' WHERE id = '"
+ var1 + "'";
}}
else {
if (insert.equals("select")){
QUERY = "SELECT * FROM db_config WHERE stanza =
'"+var1+"' AND db_config.tipo = '"+var2+"'";
ResultSet rs3 = stat.executeQuery(QUERY);
while (rs3.next()){
for (int i=2; i<9; i++){
output.writeBytes(rs3.getString(i)+"\n");
}
}
output.writeBytes("end\n");
}
else{
QUERY = "DELETE FROM db_config WHERE str1 = '" +
var1 + "'";}}
if (!insert.equals("select")){
stat.executeUpdate(QUERY);
}
s.close();
Capitolo 4 - IMPLEMENTAZIONE
39
}
} catch (UnknownHostException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();}
}}
4.3 SCREENSHOT
Ricezione dei comandi di test tst/001 e tst/002 da parte del server TCP.
4.4 TESTING
FUNZIONALITA’ PRIORITA’ RISULTATO TESTING Ricezione comandi Alta Ottimo Permette la ricezione e la comprensione dei comandi inviati dal dispositivo mobile.
Il test ha fornito esito positivo: è possibile stampare qualsiasi stringa ricevuta correttamente.
Portabilità dell’infrastruttura Alta Buono Garantisce che l’infrastruttura scelta sia installabile su una molteplicità di centraline domotiche.
Il test ha fornito esito positivo: la struttura semplice permette che la portabilità avvenga su un qualsiasi dispositivo che supporti il linguaggio Java.
Capitolo 4 - IMPLEMENTAZIONE
40
Creazione DB di configurazione Alta Ottimo Permette di riportare nel server TCP il database creato dall’utente sul dispositivo mobile.
Il test ha fornito esito positivo: al momento dell’invio di un comando l’infrastruttura lo inserisce o lo aggiorna all’interno del suo database senza bug.
Esportazione comandi Alta Ottimo Permette di inviare i comandi di una determinata stanza all’utente che ha effettuato la richiesta.
Il test ha fornito esito positivo: non sono stati rilevati bug nell’invio delle stringhe di risposta al dispositivo mobile.
Cancellazione comandi Media Buono Permette di cancellare un comando dall’elenco memorizzato sul server.
Il test ha fornito esito positivo: la cancellazione di un comando ha come discriminante la stringa corrispondente; a causa della pluralità di utenti concorrenti, non è possibile utilizzare l’ID.
Localizzazione server TCP Alta Buono Permette il raggiungimento del server TCP tramite rete Internet.
Il test ha fornito esito positivo: è possibile individuare la centralina tramite IP; se si adotta un IP privato ci si può connettere solamente all’interno della stessa LAN.
Capitolo 5 - CONCLUSIONE
41
CAPITOLO 5 - CONCLUSIONE
5.1 STRUMENTI DI DESIGN UTILIZZATI
L’ambiente di sviluppo utilizzato in fase di
implementazione è l’IDE integrato open source
Eclipse. Inoltre per garantire la connessione al
database di SQLite, si è dovuto far riferimento al
connettore SQLiteJDBC da inserire all’interno della
directory corrispondente alle librerie JAVA.
5.2 TECNOLOGIA NEAR FIELD COMMUNICATION
5.2.1 Applicazioni context aware
La crescente diffusione di connettività sia fissa sia mobile e di dispositivi
mobile (telefoni cellulari, PDA) ha determinato un nuovo scenario di
computazione in cui gli utenti possono accedere a risorse o servizi ed
interagire gli uni con gli altri in ogni momento e luogo. In tale scenario si
aprono nuove direzioni di ricerca orientate allo sviluppo di applicazioni
Capitolo 5 - CONCLUSIONE
42
che siano in grado di fornire un risultato in dipendenza da informazioni di
contesto, quali ad esempio la posizione dell’utente, le sue preferenze, la
capacità del dispositivo e le risorse disponibili (applicazioni context aware).
Requisito di fondamentale importanza per la progettazione, sviluppo e
messa in opera di servizi context-aware è la capacità di modellare e
comprendere l’informazione di contesto. Una volta trovati i servizi di
interesse, ciascun utente deve interagire con i servizi e con gli utenti che li
forniscono nella maniera appropriata. Ciò richiede di regolare l’interazione
tra utenti sulla base di opportune politiche che favoriscano la
collaborazione, ma nello stesso tempo garantiscano il corretto
svolgimento delle attività di ciascun utente.
5.2.2 Tecnologia NFC
Near Field Communication (NFC) è una tecnologia che fornisce
connettività wireles bidirezionale a corto raggio. Quando due apparecchi
NFC, l’initiator e il target, vengono accostati entro un raggio di 4 cm, viene
creata una rete peer-to-peer tra i due ed entrambi possono inviare e
ricevere informazioni. La tecnologia NFC opera alla frequenza di 13,56 MHz
e può raggiungere una velocità di trasmissione massima di 424 kbit/s.
L’NFC può essere integrato direttamente tramite un chip integrato oppure
tramite l’uso di una speciale scheda esterna che sfrutta le porte delle
schede SD o mini SD.
Capitolo 5 - CONCLUSIONE
43
Le applicazioni possibili sono molto varie e sta, come la storia insegna,
nella genialità degli sviluppatori a sfruttarne tutte le potenzialità. Per quanto
riguarda l’ambito domotico, potrebbe essere
interessante utilizzare questa tecnologia per
l’identificazione della stanza in cui l’utente si
trova in modo da permettere al dispositivo
mobile di adattarsi al contesto. In generale,
gli sviluppi che si possono prevedere ad
oggi, sono:
Scaricamento di giochi, file MP3, video, software;
Bigliettazione elettronica;
Scaricamento informazioni addizionali riguardo cinema, teatri, stadi,
monumenti, mezzi di trasporto;
Trasferimento di fotografie da fotocamere verso tv, PC o stampa;
Trasferimento facilitato di file o messa in rete fra sistemi wireless;
Portafoglio elettronico.
Capitolo 5 - CONCLUSIONE
44
5.3 SVILUPPI FUTURI
Per un’applicazione in ambito domotico si può facilmente ipotizzare uno
sviluppo in parallelo a quello della ricerca nel settore. Si tratta, come già
specificato, di un campo in continua espansione e per questo le reali
potenzialità sono ancora in parte nascoste. In riferimento al software
sviluppato è sicuramente indispensabile migliorare l’interfacciamento con
la tecnologia Near Field Communications (NFC), in grado di localizzare il
dispositivo mobile rendendo maggiore l’efficienza dell’applicazione e
garantendo un’immediatezza estrema nella ricerca dei comandi.
Per quanto riguarda il modello di architettura, sarebbe utile utilizzare un
server TCP intermedio funzionante da gateway che consenta di smistare i
comandi in arrivo dal dispositivo mobile e inoltrarli alla centralina
corrispondente; questa apparente ridondanza, sarebbe compensata dalla
possibilità per il server intermedio di memorizzare al suo interno il
database presente nel dispositivo Android, in modo che sia riutilizzato da
altri utenti; nel momento in cui un cui comando viene inviato per essere
eseguito, la centralina funzionante da gateway aggiornerà le sue tabelle,
prima di inoltrare il comando alla destinazione effettiva.
Un altro interessante filone di ricerca può riguardare la creazione di
scenari predefiniti, registrati seguendo le più moderne tecniche context
aware analizzando attentamente le abitudini di ciascun utente anche
Capitolo 5 - CONCLUSIONE
45
attraverso la localizzazione temporale: dal punto di vista dell’utente finale,
una scelta sui comandi da visualizzare diventa così non solamente una
sequenza preimpostata e mnemonica che, per quanto utile, non permette
di raggiungere la massima efficienza e facilità d’uso; una discriminazione
su base temporale, elaborata assieme alle statistiche riguardanti l’utilizzo e
l’importanza dei comandi e i riferimenti geografici consentono al
dispositivo di conoscere le abitudini dell’utente utilizzatore e di adattarsi di
conseguenza alle sue esigenze attraverso la consultazione di scenari
predefiniti e l’adattamento alla situazione attuale.
Lasciando così di stucco l’utente, anticipando i suoi pensieri.
5.4 CONCLUSIONE
L’infrastruttura è stata pensata per un utilizzo reale, principalmente per il
controllo da remoto all’interno dell’abitazione stessa. Per l’utilizzo lontano
dalla residenza, occorre predisporre l’impianto di un indirizzo IP pubblico in
modo da essere raggiungibile tramite la rete Internet.
La speranza dell’autore è che il presente lavoro di tesi, possa essere uno
spunto ed un punto di partenza su cui fondare la ricerca e lo sviluppo del
settore.
Appendice A – Domos Controller
46
APPENDICE A – DOMOS CONTROLLER
A.1 DOMOS CONTROLLER
L’infrastruttura sviluppata è subordinata all’utilizzo di un’applicazione che
ne richieda dei servizi; a tal proposito il progetto è stato portato avanti
parallelamente alla redazione di un software, chiamato Domos Controller:
si tratta di un’applicazione per dispositivi Android che permette il controllo
dei dispositivi elettronici di un’abitazione tramite connessione TCP con la
centralina domotica, per mezzo di stringhe proprie della centralina
utilizzata. Sfrutta la tipologia di connessione di TCP/IP remote e l’interfaccia
grafica di Domotica (vedi paragrafo 2.3.2).
A.2 CLASS DIAGRAM
Il class diagram è un tipo di diagramma UML. In termini generali consente
di descrivere tipi di entità, con le rispettive caratteristiche, e le eventuali
relazioni tra questi tipi. Gli strumenti concettuali utilizzati sono il concetto di
classe, la generalizzazione, le relazioni. Ogni classe viene inoltre
caratterizzata dai rispettivi attributi e metodi.
Appendice A – Domos Controller
47
Appendice A – Domos Controller
48
A.3 SCREENSHOT
Elenco case Inserimento nuova casa Gestione opzioni
Elenco stanze Menu Opzioni Elenco comandi
49
BIBLIOGRAFIA
Martin Fowler (2004) UML distilled, Pearson Italia
Pratap K.J. Mohapatra (2010) Software Engineering, New age
James F. Kurose, Keith W. Ross (2003) Internet e reti di calcolatori,
McGraw-Hill
Storia di Android, http://www.storiainformatica.it
Applicazioni context aware, http://lia.deis.unibo.it/Staff/PaoloBellavista
Domotica, http://www.wikipedia.it/Domotica
Domotica, http://www.domotica.it
Android, http://www.wikipedia.it/Android
50
RINGRAZIAMENTI
Ringrazio l’Ing. Andrea Pandurino per il suo supporto durante il lavoro di
tesi e l’Ing.. Alberto Bucciero che ha messo a disposizione le sue
conoscenze e competenze in ambito domotico. Ringrazio inoltre il Dott.
Roberto Vergallo per le informazioni riguardanti la tecnologia NFC. Inoltre
non posso dimenticare tutti i professori che in questi tre anni mi hanno
fornito le conoscenze necessarie per raggiungere questo traguardo; o
meglio, questo nuovo punto di partenza.
Inoltre il mio pensiero va alla mia famiglia e ai miei amici che spesso
hanno contribuito, con il loro incitamento e supporto, ai risultati raggiunti
ed ai miei compagni di corso con cui ho condiviso tre anni di studio.
Luigi Vigneri