un’infrastruttura per dispositivi mobile - luigivigneri.org · dispositivi Android, a cui verrà...

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.


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


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.


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


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


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


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.


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.


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


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


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.


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


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


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


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


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


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


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;


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


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


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


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.


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


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


Intero Si


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


Intero Si


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


Intero Si


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


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.


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.


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


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


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());


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();


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.


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


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.


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.


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


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.


47


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

http://lia.deis.unibo.it/Staff/PaoloBellavista/

http://www.wikipedia.it/Domotica

http://www.domotica.it/

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

un’infrastruttura per dispositivi mobile - luigivigneri.org · dispositivi Android, a cui verrà...

Documents

Transcript of un’infrastruttura per dispositivi mobile - luigivigneri.org · dispositivi Android, a cui verrà...