Ambienti di Sviluppo Integrati per Sistemi Domotici ...orizzontenergia.it/download/Appr/DOMOTICA/2011_07_Ambienti di... · POLITECNICO DI TORINO III Facolt a di Ingegneria dell’Informazione

POLITECNICO DI TORINO

III Facolta di Ingegneria dell’InformazioneCorso di Laurea in Ingegneria Informatica

Tesi di Laurea Specialistica

Ambienti di Sviluppo Integrati perSistemi Domotici Intelligenti

Relatori:prof. Fulvio Cornoing. Dario Bonino

Candidato:Daniele Mina

Luglio 2011

Indice

1 Introduzione 1

1.1 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3 Struttura della tesi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Stato dell’arte 7

2.1 Sistemi domotici . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 Intelligent Domotic Environment . . . . . . . . . . . . . . . . 8

2.2 Il linguaggio DogOnt . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.1 DogOnt Ontology . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3 Il gateway DOG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3.1 Architettura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.4 Punti critici e aree di possibile miglioramento . . . . . . . . . . . . . 18

3 Obiettivi 20

3.1 Scopo della tesi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2 Requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.1 Requisiti funzionali . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.2 Requisiti non funzionali . . . . . . . . . . . . . . . . . . . . . 23

3.3 Analisi delle possibili soluzioni . . . . . . . . . . . . . . . . . . . . . . 25

4 Strumenti utilizzati 26

4.1 La piattaforma Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2 Eclipse Modeling Framework . . . . . . . . . . . . . . . . . . . . . . . 28

4.2.1 Componenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.2.2 Definire un modello EMF . . . . . . . . . . . . . . . . . . . . 30

4.3 Graphical Editing Framework . . . . . . . . . . . . . . . . . . . . . . 32

4.3.1 Componenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.3.2 Usare GEF con EMF . . . . . . . . . . . . . . . . . . . . . . . 33

4.4 Graphical Modeling Framework . . . . . . . . . . . . . . . . . . . . . 34

II

5 Generazione dell’applicazione DogDomoticIde 365.1 Struttura della soluzione . . . . . . . . . . . . . . . . . . . . . . . . . 365.2 DataModel Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.3 Generazione del modello dati . . . . . . . . . . . . . . . . . . . . . . 50

5.3.1 Generazione delle interfacce annotate . . . . . . . . . . . . . . 515.3.2 Completamento delle classi implementazione . . . . . . . . . . 54

5.4 Costruzione dei modelli per GMF . . . . . . . . . . . . . . . . . . . . 565.4.1 Graphical Definition Model . . . . . . . . . . . . . . . . . . . 575.4.2 Tooling Definition Model . . . . . . . . . . . . . . . . . . . . . 595.4.3 Mapping Definition Model . . . . . . . . . . . . . . . . . . . . 60

5.5 Generazione dell’editor . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6 Implementazione 646.1 Architettura logica di DogDomoticIde . . . . . . . . . . . . . . . . . . 646.2 La gestione degli ambienti stanza . . . . . . . . . . . . . . . . . . . . 65

6.2.1 L’algoritmo RoomDetection . . . . . . . . . . . . . . . . . . . 676.2.2 Integrazione dell’algoritmo RoomDetection nell’applicazione

DogDomoticIde . . . . . . . . . . . . . . . . . . . . . . . . . . 756.3 La Summary View . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

6.3.1 Aggiornamento della Summary View . . . . . . . . . . . . . . 796.3.2 Aspetto e funzionalita della Summary View . . . . . . . . . . 81

6.4 Modifica della Property View . . . . . . . . . . . . . . . . . . . . . . 826.4.1 Il tab CommonProperties . . . . . . . . . . . . . . . . . . . . 826.4.2 I tab Network e NetworkGateway . . . . . . . . . . . . . . . . 836.4.3 I tab ControlRelation e RelationsSummary . . . . . . . . . . . 84

6.5 Esportazione del file di progetto . . . . . . . . . . . . . . . . . . . . . 866.5.1 Il formato xmldog . . . . . . . . . . . . . . . . . . . . . . . . . 876.5.2 Esempio di descrizione xmldog di un sistema domotico . . . . 87

7 Casi di studio 907.1 Caso 1: progetto di un appartamento . . . . . . . . . . . . . . . . . . 90

7.1.1 Generazione del file di configurazione ed installazione su DOG 927.2 Caso 2: ambiente composto da 2 appartamenti . . . . . . . . . . . . . 937.3 Caso 3: SimpleHome . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

7.3.1 Tecniche a confronto: risultati sperimentali . . . . . . . . . . . 96

8 Conclusioni 98

Bibliografia 100

III

Elenco delle figure

2.1 Intelligent Domotic Environment . . . . . . . . . . . . . . . . . . . . 92.2 La struttura di DogOnt Ontology . . . . . . . . . . . . . . . . . . . . 122.3 Esempio di interconnessione tra una lampada ed uno switch . . . . . 142.4 DOG Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.1 L’architettura di base di Eclipse . . . . . . . . . . . . . . . . . . . . . 274.2 La gerarchia del modello ECore . . . . . . . . . . . . . . . . . . . . . 294.3 Il funzionamento di EMF . . . . . . . . . . . . . . . . . . . . . . . . . 314.4 Il workflow di GMF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.1 Struttura della soluzione . . . . . . . . . . . . . . . . . . . . . . . . . 375.2 Esempio di interfacce e di classi implementazione . . . . . . . . . . . 395.3 Esempio di mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.4 Componenti dell’applicazione DogDomoticIde generata mediante GMF 425.5 Il ruolo del DataModel Structure . . . . . . . . . . . . . . . . . . . . 425.6 La classe ArchitecturalElement . . . . . . . . . . . . . . . . . . . . . 435.7 La classe BuildingArea . . . . . . . . . . . . . . . . . . . . . . . . . . 435.8 Il DataModel Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 445.9 La classe DeviceElement . . . . . . . . . . . . . . . . . . . . . . . . . 455.10 La gestione della componente di rete . . . . . . . . . . . . . . . . . . 455.11 Le classi NotificationElement, CommandElement e Param . . . . . . 475.12 La classe HomeGateway . . . . . . . . . . . . . . . . . . . . . . . . . 485.13 Le classi ControlProperties e ControlElement . . . . . . . . . . . . . . 485.14 Le classi ActuatorElement e SensorElement . . . . . . . . . . . . . . 495.15 La classe VisualElement . . . . . . . . . . . . . . . . . . . . . . . . . 495.16 Workflow per la generazione del modello dati . . . . . . . . . . . . . . 515.17 Le interfacce DeviceElement e Lamp . . . . . . . . . . . . . . . . . . 535.18 Classe implementazione prima e dopo l’esecuzione di FillImplemen-

tation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.19 Classe implementazione relativa allo stato OnOffState . . . . . . . . . 565.20 Costruzione dei modelli per GMF . . . . . . . . . . . . . . . . . . . . 575.21 Descrizione grafica del dispositivo Computer . . . . . . . . . . . . . . 575.22 Descrizione grafica del ControlLink . . . . . . . . . . . . . . . . . . . 58

IV

5.23 Rappresentazione grafica risultante . . . . . . . . . . . . . . . . . . . 585.24 Costruzione della palette degli oggetti . . . . . . . . . . . . . . . . . . 595.25 Mapping dell’elemento ArmChair . . . . . . . . . . . . . . . . . . . . 605.26 Generazione dell’editor . . . . . . . . . . . . . . . . . . . . . . . . . . 615.27 Screenshot dell’applicazione DogDomoticIde versione base, cioe ot-

tenuta mediante generazione automatica . . . . . . . . . . . . . . . . 636.1 Architettura logica di DogDomoticIde . . . . . . . . . . . . . . . . . . 646.2 Esempio di struttura di due ambienti appartamento . . . . . . . . . . 666.3 Muri connessi e non connessi . . . . . . . . . . . . . . . . . . . . . . . 676.4 Struttura dell’algoritmo RoomDetection . . . . . . . . . . . . . . . . 686.5 Caso di studio: appartamento dotato di un muro centrale . . . . . . . 686.6 La struttura dati intersectionList . . . . . . . . . . . . . . . . . . . . 696.7 La struttura dati intersectionMap . . . . . . . . . . . . . . . . . . . . 706.8 Esempio di grafo di aree di intersezione . . . . . . . . . . . . . . . . . 716.9 Stanze individuate dall’algoritmo RoomDetection . . . . . . . . . . . 746.10 Integrazione dell’algoritmo RoomDetection in DogDomoticIde . . . . 766.11 Aggiornamento della struttura dati builtRoom . . . . . . . . . . . . . 776.12 La Summary View . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786.13 Struttura della Summary View . . . . . . . . . . . . . . . . . . . . . 796.14 Esempio di SummaryView . . . . . . . . . . . . . . . . . . . . . . . . 816.15 Modifica della Property View . . . . . . . . . . . . . . . . . . . . . . 826.16 Il tab CommonProperties . . . . . . . . . . . . . . . . . . . . . . . . 836.17 Il tab Network/BTicinoComponent . . . . . . . . . . . . . . . . . . . 836.18 Il tab Network/KonnexComponent . . . . . . . . . . . . . . . . . . . 846.19 Il tab NetworkGateway . . . . . . . . . . . . . . . . . . . . . . . . . . 846.20 Il tab ControlRelation . . . . . . . . . . . . . . . . . . . . . . . . . . 856.21 Il tab RelationsSummary . . . . . . . . . . . . . . . . . . . . . . . . . 866.22 Esportazione del file di progetto . . . . . . . . . . . . . . . . . . . . . 866.23 Descrizione della struttura di un ambiente nel formato xmldog . . . . 886.24 Descrizione di un dispositivo nel formato xmldog . . . . . . . . . . . . 897.1 Caso di studio 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 917.2 Caso di studio 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 937.3 SimpleHome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

V

Capitolo 1

Introduzione

1.1 Scenario

La domotica e la scienza interdisciplinare che si occupa dello studio di tecnologiee di soluzioni architetturali atte a migliorare la qualita della vita in un ambientedomestico. L’obiettivo di un impianto domotico e quello di rendere piu “intelligente”l’ambiente nel quale e installato al fine di aumentarne la sicurezza, centralizzare ilcontrollo dell’abitazione, semplificare lo svolgimento delle piu comuni operazionianche ad individui che possiedano delle disabilita, e attuare politiche di risparmioenergetico. Le funzionalita di una rete domotica possono essere suddivise in duecategorie:

1. funzionalita di monitoraggio;

2. funzionalita di controllo centralizzato.

Le funzionalita di monitoraggio sono quelle che forniscono all’ambiente una mag-giore affidabilita e sicurezza; tipicamente vengono realizzate mediante la presenzadi sensori controllati dall’impianto domotico. In questo caso l’“intelligenza” dellarete domotica risiede nella sua capacita di reagire opportunamente in base alle infor-mazioni che arrivano dai sensori. Consideriamo, ad esempio, un sensore di fumo: nelmomento in cui questo dispositivo rileva la presenza di un incendio, la rete domoticadovra agire di conseguenza attivando gli sprinkler, sistema automatico di estinzionea pioggia, oppure effettuando una telefonata per contattare i soccorsi.

Le funzionalita di controllo centralizzato hanno come obiettivo quello di au-mentare il comfort facilitando le operazioni che normalmente si eseguono in unambiente domestico. L’utente, attraverso un’opportuna interfaccia, interagisce conla rete domotica allo scopo di eseguire azioni (accendere la luce, chiudere tutte letapparelle, ecc.) o di visionare alcuni parametri di stato dell’abitazione. Queste

1

1 – Introduzione

funzionalita sono molto importanti per persone con disabilita in quanto permettonoloro di avere maggiore autonomia e maggior controllo dell’abitazione.

Quando si parla di domotica molto spesso si utilizza il termine “rete” in quantola struttura di un impianto domotico presenta molte analogie con quella di unatradizionale rete di computer. In particolare i dispositivi elettrici presenti nel-l’abitazione sono dotati di un componente di rete che permette loro di essere connessicon l’impianto domotico, di inviare notifiche riguardanti il loro stato e di riceverecomandi di controllo. Questa comunicazione viene realizzata attraverso l’uso di pro-tocolli ad hoc. Le piu comuni tecnologie utilizzate nell’ambito di una rete domoticafilare, cioe basata sulla connessione dei dispositivi che la compongono mediante fili(bus), vengono fornite a livello Europeo dalla BTicino e dal consorzio Konnex. Re-centemente stanno emergendo protocolli e standard wireless che permettono un’in-terazione tra dispositivi senza la necessita di fili e/o connessioni elettriche (protocolliZ-Wave e ZigBee).

Ogni dispositivo presente in una rete domotica viene catalogato in base al tipodi componente che gli permette di accedere alla rete. In particolare si definiscedispositivo BTicino un dispositivo con componente di rete di tipo BTicino (cheutilizza i protocolli proprietari BTicino per la comunicazione su bus), analogamenteun dispositivo di tipo Konnex e un dispositivo che utilizza lo standard Konnex perla comunicazione.

In un tipico scenario domotico possono potenzialmente essere presenti disposi-tivi disomogenei per quanto riguarda la tecnologia di accesso alla rete. Tornandoall’analogia con i computer e come se nello stesso ufficio convivessero pc con schedadi rete Ethernet, altri con scheda di rete TokenRing e altri ancora con scheda direte WiFi. Come non e possibile una comunicazione diretta tra un computer surete Ethernet ed un computer su rete WiFi, cosı non e possibile una comunicazionediretta tra un dispositivo Konnex ed un dispositivo BTicino. In generale non epossibile instaurare una comunicazione diretta tra dispositivi che utilizzano diversetecnologie per l’accesso alla rete. Occorre inoltre tener presente che le differenzetra i vari impianti domotici non riguardano sono il livello di accesso alla rete mainteressano tutti i livelli della pila ISO-OSI.

L’introduzione di sistemi hardware e software aggiuntivi, nati con lo scopo diamministrare tutti gli altri dispositivi presenti nell’ambiente, rappresenta quindiun’innovazione importante rispetto a quello che e il tradizionale modello della smarthome. Per smart home, infatti, si e sempre intesa un’abitazione dotata di dispositivisensori ed attuatori equipaggiati di hardware e software dedicati che permettono lorodi autogestirsi e di realizzare politiche intelligenti semplici. Questo modello, natonei tardi anni ’90, risulta oggi sempre piu limitante in relazione al continuo espan-dersi del mercato della domotica ed alle sempre piu complesse funzionalita richieste.Inoltre e da evidenziare che le soluzioni domotiche cominciano a trovare applicazioneanche in grandi strutture ed edifici, pensiamo ad ospedali o centri commerciali. In

2

1 – Introduzione

questi contesti e normale che i dispositivi non siano forniti tutti dallo stesso pro-duttore con la conseguenza che, in alcuni casi, non e possibile un’interazione direttaper via delle diverse tecnologie utilizzate.

Da queste problematiche nasce la necessita di inserire, in un impianto domotico,un nodo centrale capace di fare da ponte per la comunicazione tra dispositivi diso-mogenei: il gateway domotico; in questa tesi, in particolare, tale gateway sara DOG(Domotic OSGi Gateway) sviluppato al Politecnico di Torino dal gruppo e-Lite.

DOG permette di espandere il tradizionale modello domotico diventando il cervel-lo dell’impianto. I suoi obiettivi sono quelli di permettere:

1. la gestione dei dispositivi presenti nell’ambiente assicurando la convivenza el’interazione anche tra quelli che accedono alla rete con protocolli diversi;

2. un’espansione delle funzionalita realizzabili dalla rete domotica rispetto a quellefornite dal modello tradizionale (semplice interazione sensore-attuatore).

Il gateway rappresenta un valore aggiunto che si va a sommare al tradizionalemodello domotico al fine di renderlo piu funzionale. In genere si tratta di un comunepersonal computer connesso a tutte le reti di dispositivi presenti nell’ambiente conlo scopo di monitorare il loro stato (ricevendo le loro notifiche) e di inviare comandida eseguire.

Per rendere chiaro questo concetto si consideri il caso di un interruttore BTici-no e di una lampada Konnex. Si vuole realizzare la seguente interazione: quandol’interruttore viene posizionato in posizione “On” la luce della lampada deve accen-dersi. Una possibile soluzione consiste nell’inserire una regola di controllo all’internodel gateway, da eseguire solo se si verificano certe condizioni. La ricezione di unanotifica “On” dall’interruttore determinera la generazione e la trasmissione alla lam-pada di un comando per accendere la luce. Il gateway svolge quindi la funzione ditraduttore: riceve una notifica BTicino, la interpreta e genera un comando Konnexper la lampada.

Nel caso specifico di DOG il gateway e costruito utilizzando come base la pi-attaforma OSGi, un framework Java che permette al sistema di essere molto flessibile.OSGi supporta, infatti, l’aggiunta ed il caricamento dinamico di moduli software,il riconoscimento e l’hot-plug/-unplug di nuovi dispositivi tramite la Device AccessSpecification: specifica indipendente da qualunque particolare venditore che definiscecome un dispositivo, non necessariamente fisico, si agganci alla piattaforma OSGi ecome quest’ultima provveda a rilevarlo in modo automatico.

Uno degli aspetti che permettono al gateway di svolgere i suoi compiti e laconoscenza dell’ambiente in cui viene installato: DOG deve essere “informato” sucome e strutturato l’ambiente (piani, stanze), da quali elementi architetturali ecomposto, quali sono i dispositivi presenti e come interagiscono tra di loro.

3

1 – Introduzione

Tali informazioni sono contenute nel bundle HouseModel, un modulo del gatewayche risulta quindi essere specifico per ogni impianto domotico che si sta progettando.

Nella soluzione proposta dal gruppo e-Lite, il linguaggio utilizzato per descriverei sistemi domotici e DogOnt, un metamodello basato sulla modellazione semanticae composto da due parti:

• un’ontologia (DogOnt Ontology), espressa in OWL, il cui compito e formal-izzare tutte le caratteristiche di un sistema domotico. DogOnt Ontology for-nisce una libreria di classi ognuna delle quali descrive un elemento del sistemadomotico;

• un insieme di regole (DogOnt Rules) che facilitano il processo di modellazionedell’ambiente.

La scelta di utilizzare DogOnt come formato di descrizione e dovuta al fatto che euna rappresentazione che permette al gateway DOG di attuare politiche intelligentiper l’ambiente: l’ontologia DogOnt si presta, infatti, ad essere interrogata da sistemiinferenziali che consentono l’estrazione di informazioni avanzate necessarie al gate-way per poter operare. Per rappresentare un ambiente il progettista dovra utilizzarele classi fornite dall’ontologia DogOnt per descrivere i vari elementi che lo compon-gono (dispositivi, arredamento, struttura dell’abitazione, interazioni). Viene quindicreato un documento, istanza dell’ontologia DogOnt, che deve essere installato sulgateway DOG all’interno del modulo HouseModel.

Se da un lato il formato OWL utilizzato da DogOnt incrementa le potenzialitadel gateway, dall’altro introduce delle problematiche di configurazione. Produrre undocumento istanza di DogOnt e infatti molto complesso: il formato OWL richiededi organizzare le informazioni in una maniera poco intuitiva, utilizzando costruttie ridondanze tediose. Il dover descrivere un ambiente domotico direttamente informato OWL (attraverso l’uso di software come Protege) crea molte difficolta alprogettista: richiede di essere fortemente specializzati ed e dispendioso di tempo. Peralleggerire questa problematica e stato proposto, sempre dal gruppo e-Lite, un tool ingrado di generare automaticamente un file di ontologia sulla base di un documentodi configurazione XML. Il formato XML proposto (xmldog) ha una struttura piusemplice rispetto al formato OWL e permette al progettista di descrivere l’ambienteinserendo solo quelle che sono le informazioni essenziali. Tuttavia questa soluzionenon puo essere considerata definitiva per il problema: anche se il formato propostoe piu semplice ed intuitivo, il progettista resta comunque vincolato alla descrizionetestuale dell’ambiente ed alla conoscenza del formato XML utilizzato.

4

1 – Introduzione

1.2 Obiettivi

Il lavoro di tesi mira a risolvere queste problematiche andando a realizzare un ambi-ente di sviluppo integrato per la progettazione di sistemi domotici intelligenti, basatisulla modellazione semantica DogOnt e sul gateway domotico DOG.

L’applicazione sviluppata vuole coprire il tassello mancante che vi e tra il pro-gettista ed il gateway DOG per quanto riguarda la descrizione dell’impianto. Al-lo stato attuale, infatti, l’unico modo per configurare DOG su uno specifico sis-tema domotico e quello di creare un’istanza dell’ontologia DogOnt utilizzando soft-ware come Protege. Questa procedura risulta essere poco intuitiva e vincolante inquanto richiede piena conoscenza del formato interpretabile da DOG da parte delprogettista.

L’ambiente di sviluppo ha come priorita quella di risolvere questa problematicafornendo gli strumenti necessari per descrivere un impianto domotico attraverso unasemplice interfaccia grafica. Il progettista, attraverso l’uso di questa applicazione,potra:

1. definire la struttura ed i contenuti di un impianto di tipo domotico, a par-tire da librerie di componenti (passivi o attivi) che possono essere inseritinell’ambiente;

2. effettuare editing degli aspetti grafici (layout 2D) e dei meta-dati (elenchi diproprieta) relativi agli ambienti creati ed ai componenti inseriti;

3. descrivere in maniera semplice ed intuitiva le interazioni che intercorrono trai dispositivi presenti nell’ambiente;

4. esportare le informazioni derivanti dal progetto in un formato direttamenteutilizzabile dal gateway DOG.

Il sistema e realizzato sulla base della piattaforma Eclipse RCP e del plug-inGMF (Graphical Modeling Framework). Inoltre il modello dati di lavoro e costruitoper essere accessibile ad eventuali, ulteriori, plug-in che in futuro potranno estenderel’applicazione fornendo funzionalita aggiuntive.

1.3 Struttura della tesi

Il presente documento e organizzato nei seguenti capitoli:

Stato dell’arte (cap. 2) - ha lo scopo di di approfondire il contesto in cui sisviluppa questa tesi;

5

1 – Introduzione

Obiettivi (cap. 3) - vengono evidenziati gli obiettivi del lavoro di tesi, espressisotto forma di requisiti funzionali e non funzionali;

Strumenti utilizzati (cap. 4) - vengono introdotti la piattaforma Eclipse edi plug-in EMF, GEF e GMF;

Generazione dell’applicazione DogDomoticIde (cap. 5) - descrizione dellefasi che conducono alla generazione automatica dell’applicazione di base mediantel’ausilio dei plug-in EMF e GMF;

Implementazione (cap. 6) - descrizione delle operazioni di integrazione ed es-tensione dell’applicazione generata automaticamente al fine di supportare i requisitifunzionali primari dichiarati;

Casi di studio (cap. 7) - progettazione di scenari domestici reali mediantel’uso dell’applicazione costruita;

Conclusioni (cap. 8) - risultati ottenuti nel lavoro di tesi e possibili sviluppifuturi.

6

Capitolo 2

Stato dell’arte

Questo capitolo ha lo scopo di di approfondire il contesto in cui si sviluppa questatesi. A tal fine viene ripreso il concetto di sistema domotico per poi passare al-la presentazione del linguaggio di modellazione semantica DogOnt e del gatewaydomotico DOG.

2.1 Sistemi domotici

I sistemi domotici vengono studiati e sono presenti sul mercato da molti anni. Nonos-tante questo, la loro applicazione nell’ambito residenziale e recente ed e legata alcontinuo abbassamento del costo della tecnologia ed all’emergere di nuovi bisogni perquanto riguarda il comfort, il risparmio energetico, la sicurezza e la multimedialita.Le attuali soluzioni domotiche presentano pero 2 problematiche che ne frenano losviluppo:

• la presenza di molti produttori di componenti domotici, ognuno dei quali especializzato solo in alcuni ambiti e ha ben precisi obiettivi di mercato;

• la struttura dei dispositivi domotici, che sono pensati e costruiti come un’evoluzionedei dispositivi elettrici tradizionali (come switch e relay) e che permettono,quindi, solo semplici interazioni di automazione.

In questo contesto ogni produttore propone solo alcuni dispositivi (in base allapropria politica di mercato) con soluzioni specifiche per la loro gestione. Questo gen-era problematiche di interoperabilita con i sistemi prodotti dagli altri vendor: non einfatti possibile fare interagire direttamente dispositivi costruiti da diversi produttoriperche, per la comunicazione, si basano su tecnologie e protocolli differenti.

Nella prima fase di sviluppo della domotica, dove le installazioni erano pocheed isolate, il problema dell’interoperabilita era secondario. Oggi invece queste tec-nologie trovano applicazione anche in grandi strutture (hotel, universita, ospedali,

7

2 – Stato dell’arte

ecc.) dove e scontata la presenza di dispositivi costruiti con tecnologie diverse chenecessitano di essere coordinati da un unico sistema centrale.

L’altro problema sopra citato e legato alla concezione dei componenti domoticicome un’evoluzione dei dispositivi elettrici. Questo approccio e riduttivo in quanto lefunzionalita richieste ad un sistema domotico sono sempre piu articolate, complessee necessarie di una “intelligenza” superiore rispetto a quella garantita dalla sempliceautomazione.

Come citato nel capitolo introduttivo, viene definita smart home un’abitazionedotata di sensori ed attuatori, di hardware e software dedicati, allo scopo di realizzaresemplici interazione di automazione. Questo approccio, rivoluzionario negli anni ’90,risulta oggi limitante in quanto non consente l’introduzione di nuove e piu complessefunzionalita.

Al fine di risolvere queste problematiche e necessario estendere il modello pro-posto dalla smart home inserendo, nel sistema domotico, un dispositivo (il gateway)in grado, grazie alle sue capacita computazionali, di supportare l’interoperabilita edi attuare politiche intelligenti per la gestione dei dispositivi.

Questo nuovo modello, che in letteratura viene chiamato Intelligent DomoticEnvironment (IDE), permette al sistema domotico di apprendere le abitudini degliabitanti dell’abitazione, di attuare avanzate tecniche di sicurezza e di implementarepolitiche per il comfort e per il risparmio energetico.

Un passo evolutivo molto importante riguarda la modellazione astratta e formaledei dispositivi domotici e delle loro capacita, indipendentemente dagli aspetti tecno-logici. Ad esempio una lampada viene modellata come un oggetto in grado emettereluce, indipendentemente dalla tecnologia con cui e realizzata e con la condizione chesia in qualche modo controllabile dal sistema domotico.

L’astrazione dei dispositivi presenti in un ambiente permette al gateway di fare daponte tra diverse tecnologie: per ogni dispositivo reale viene creata una descrizioneastratta che ne esplica il funzionamento attraverso l’uso di un linguaggio comune econdiviso.

A tal fine e stato sviluppato dal gruppo e-Lite il linguaggio DogOnt, un meta-modello in formato OWL il cui scopo e permettere la descrizione di sistemi domotici.Attualmente DogOnt viene utilizzato per permettere la modellazione dell’ambientee per introdurre capacita di ragionamento all’interno del gateway domotico DOG.

Nel paragrafo successivo sara approfondito il concetto di IDE per poi passarealla presentazione del linguaggio DogOnt e del gateway DOG.

2.1.1 Intelligent Domotic Environment

Un ambiente domotico intelligente (IDE, Figura 2.1) e tipicamente composto da unoo piu sistemi domotici, da un insieme di elettrodomestici e da un Home Gateway chepermette di implementare politiche di interoperabilita e comportamenti intelligenti.

8


Figura 2.1. Intelligent Domotic Environment

Un sistema domotico contiene, tipicamente, diversi dispositivi domotici (attua-tori per porte e finestre, luci, sensori, ecc.) ed un network gateway che, agendo datunnel (inserendo quindi un’intestazione di rete), permette la trasmissione dei mes-saggi specifici del protocollo di basso livello, utilizzato dai dispositivi appartenential sistema domotico per la comunicazione, su di una tecnologia di interconnessionemaggiormente versatile ed indipendente dal tipo di applicazione (es. Ethernet). Inetwork gateway rappresentano quindi un punto di accesso per i sistemi domotici,ma non sono programmabili e non introducono funzionalita aggiuntive all’internodell’IDE.

Gli elettrodomestici possono essere “stupidi”, ovvero che possono essere con-trollati solo attivando o disattivando le prese elettriche alle quali sono collegati, o“smart”, cioe capaci di offrire funzionalita complesse e di controllare altri dispositiviattraverso uno specifico protocollo di comunicazione.

La presenza nello stesso ambiente di molti sistemi domotici introduce delle prob-lematiche di interoperabilita: dispositivi appartenenti a sistemi diversi non possonointeragire per via delle diverse tecnologie e dei diversi protocolli utilizzati per comu-nicare. L’ home gateway e progettato con lo scopo di risolvere questa problemat-ica: agisce da ponte tra le diverse tecnologie e supporta complesse interazioni tra idispositivi. I compiti che un home gateway deve essere in grado di svolgere possonoessere raggruppati in 3 livelli di priorita:

9


1. livello 1 : include tutte le feature necessarie per controllare diversi sistemidomotici utilizzando un unico protocollo di comunicazione di alto livello e unsingolo punto di accesso;

2. livello 2 : definisce le feature necessarie per permettere l’automazione inter-network (interazione tra dispositivi appartenenti a sistemi domotici differenti);

3. livello 3 : riguarda gli aspetti di comportamento intelligente e di capacita diadattamento da parte dell’utente.

Una casa domotica si definisce Intelligent Domotic Environment se il gatewaysoddisfa i requisiti di livello 1 e di livello 2 (quelli di livello 3 sono considerati relativia funzionalita avanzate ed opzionali).

2.2 Il linguaggio DogOnt

DogOnt e un linguaggio descrittivo di sistemi IDE basato sulla modellazione se-mantica. Con l’adozione di rappresentazioni ben note come le ontologie e fornendostrutture adeguate al ragionamento, DogOnt e in grado di affrontare problemi diinteroperabilita consentendo di descrivere:

• dov’e situato un dispositivo domotico;

• le capacita e le funzionalita di un dispositivo;

• le specifiche tecnologiche necessarie per interfacciarsi con un dispositivo;

• le possibili configurazioni che un dispositivo puo assumere;

• come e strutturata l’abitazione (piani, stanze, muri);

• gli elementi architetturali e di arredamento presenti nell’ambiente.

Queste informazioni possono poi essere sfruttate da sistemi basati sull’inferenzaper fornire le funzionalita avanzate richieste al sistema domotico.

DogOnt e composto di due parti: un’ontologia (DogOnt Ontology), espressa inOWL, il cui compito e formalizzare tutti gli aspetti di un IDE, e un insieme di regole(DogOnt Rules), che facilitano il processo di modellazione generando automatica-mente gli stati e le funzionalita relativi ai dispositivi, e associandoli automaticamentealle opportune istanze attraverso regole sematiche.

10


2.2.1 DogOnt Ontology

Un’ontologia e una rappresentazione formale di un’interpretazione condivisa di unospecifico dominio di conoscenza. Non esistendo l’ontologia perfetta, la rappresen-tazione di un determinato dominio puo essere formalizzata in una moltitudine dimodi e dipende dallo scopo per cui viene creata. Un’ontologia assume normal-mente una struttura a grafo connesso con concetti e relazioni che li collegano. Lecomponenti fondamentali di una ontologia sono:

Classi - insiemi, collezioni o tipi di oggetti;

Attributi - proprieta, caratteristiche o parametri che gli oggetti possono averee condividere;

Relazioni - modi in cui gli oggetti possono essere messi in relazione gli uni congli altri;

Individui - istanze del modello.

E costituita da un insieme di classi organizzate in una struttura gerarchica agrafo dove i collegamenti tra un nodo e l’altro rappresentano relazioni di ereditari-eta (isA). Ad esempio, come si osserva nella Figura 2.2, la classe Garage (che descrivel’ambiente garage) e una specializzazione della classe BuildingEnviroment: ered-ita cioe le proprieta di ogni tipologia di ambiente incrementandole con le propriecaratteristiche specifiche.

Anche se non rappresentate nella figura, sono possibili situazioni di ereditari-eta multipla. Tutte le classi che descrivono un dispositivo (Computer, Alarm-Clock, ecc.), ad esempio, derivano sia dalla classe Controllable (che definiscele funzionalita di base di ogni dispositivo) sia da una classe NetworkComponent

(BticinoComponent o KonnexComponent) che fornisce le specifiche caratteristichedi rete. La descrizione di ogni dispositivo e quindi composta da due componen-ti: una parte astratta che descrive il comportamento del dispositivo ed una partetecnologica necessaria per la comunicazione. Questo tipo di approccio favoriscel’interoperabilita tra i dispositivi in quanto permette uniformita nel linguaggio uti-lizzato per la loro descrizione. L’insieme delle classi definite da DogOnt puo esserediviso in 8 gruppi:

• Building Thing: per modellare qualsiasi elemento controllabile e non con-trollabile. Si definisce elemento controllabile (o dispositivo) un elemento chepuo essere controllato dal sistema domotico (interrogato sul proprio statoo comandato). I dispositivi sono suddivisibili in due categorie: quelli ap-partenenti ad uno degli impianti domestici (la lampada, ad esempio, vienecatalogata come appartenente all’impianto elettrico) e gli elettrodomestici(frigorifero, forno, hiFi, ecc.). Ogni dispositivo possiede diverse funzionalita(Functionality, rintracciate dalle relazioni hasFunctionality) e puo assumere

11


Figura 2.2. La struttura di DogOnt Ontology

diverse configurazioni di stato (State, identificate mediante la relazione has-State). La quantita ed il tipo di stati e di funzionalita dipendono ovvia-mente dal dispositivo; in generale ogni elemento controllabile mette a dispo-sizione almeno una QueryFunctionality che permette di fornire informazioniriguardanti la sua configurazione. Gli elementi non controllabili possono esseredi tipo architetturale per la definizione dell’ambiente (muri, pavimenti, ecc.)e di arredamento (mobili, scrivanie, tavoli, ecc.);

• Building Environment: per modellare la posizione di un elemento. Contieneuna descrizione delle varie tipologie di ambiente: vengono definiti gli ambientigiardino (classe Garden), garage (classe Garage) e appartamento (classe Flat).Ogni piano puo contenere una o piu stanze (cucina, camera da letto, bagno,ecc.);

• Functionality: per modellare le operazioni che si possono effettuare su undispositivo. Tutte le funzionalita definiscono i comandi necessari per modifi-care o per interrogare una specifica proprieta del dispositivo. Sono suddivise in

12


diverse categorie in relazione al loro scopo: le ControlFunctionality model-lano la capacita di controllare un dispositivo. Le NotificationFunctionali-ty riguardano l’abilita di un dispositivo di segnalare un proprio cambiamentodi stato. Le QueryFunctionality permettono di interrogare un dispositivoche fornira, quindi, informazioni sulla propria configurazione attuale. Infine lefunzionalita vengono organizzate anche in base a come modificano lo stato diun particolare dispositivo: le ContinuosFunctionality permettono la mod-ifica delle caratteristiche di un dispositivo in maniera continua (ad esempioil volume di un impianto audio) e le DiscreteFunctionality sono utilizzateper quelle proprieta che possono assumere solo valori discreti. Le relazionihasNotification e hasCommand contengono rispettivamente i riferimenti allenotifiche ed ai comandi che realizzano concretamente le funzionalita svoltedalle NotificationFunctionality e ControlFunctionality;

• State: per modellare le configurazioni che un dispositivo puo assumere. Comeper le funzionalita, anche gli stati vengono classificati in base ai valori chepossono assumere: i ContinuosState, che riguardano quelle proprieta chepossono assumere valori continui, ed i DiscreteState, associati alle proprietache assumono solo valori discreti;

• NetworkComponent: per modellare le caratteristiche tecniche specifiche di og-ni rete domotica. Attualmente i NetworkComponent definibili sono tre: KNX-Component utilizzato per dispositivi Konnex, BTicinoComponent dedicato aidispositivi BTicino ed infine EliteComponent attribuito a tutti i dispositivinon reali (che non hanno componente di rete dichiarato);

• Notification: per modellare tutte le notifiche che i dispositivi possono gener-are in seguito ad una variazione di stato;

• Command: per modellare tutti i comandi per controllare ed interrogare i dis-positivi;

• StateValue: per modellare la tipologia di valori che gli stati dei dispositivipossono assumere: le classi ContinuosStateValue e DiscreteStateValue

descrivono rispettivamente i valori continui e discreti che gli stati possonoassumere. Gli stati ContinuosState e DiscreteState sono associati alle classiContinuosStateValue e DiscreteStateValue (relazione hasStateValue).

Si consideri, come esempio riassuntivo, la rappresentazione di una lampada adintensita luminosa regolabile. Questo dispositivo, nel formato OWL utilizzato daDogOnt, e descritto dalla classe DimmerLamp che a sua volta deriva, nell’ordineindicato, dalle classi Lamp, Lighting, HousePlant e Controllable. La presen-za di questa scala gerarchica permette al dispositivo DimmerLamp di ereditare le

13


Figura 2.3. Esempio di interconnessione tra una lampada ed uno switch

funzionalita definite nelle super classi: dalle classi Lamp, Controllable e House-

Plant vengono ereditate rispettivamente le funzionalita OnOffFunctionality (chea sua volta definisce i comandi On e Off per accendere e spegnere la lampada),QueryFunctionality (per permettere l’interrogazione dello stato della lampada)e StateChangeNotificationFunctionality (notifica che segnala un cambiamen-to di stato della lampada). La classe DimmerLamp e inoltre caratterizzata dallafunzionalita LightRegulationFunctionality e dallo stato LightIntensityState:LightRegulationFunctionality definisce i comandi StepUpCommand, StepDown-Command e SetCommand(value) per governare l’incremento ed il decremento dell’in-tensita luminosita, LightIntensityState tiene traccia, in percentuale, del valoredell’intensita luminosa.

La Figura 2.3 mostra, come esempio, la descrizione OWL schematica di undispositivo lampada (istanza della classe DimmerLamp) controllata da uno switch(OnOffSwitch). Il funzionamento, la configurazione attuale e le proprieta dellalampada sono descritte dalle relazioni:

14


• hasState: relazione che contiene il riferimento ad un’istanza della classe Ligh-IntensityState che, tramite il valore LightIntensityStateValue, tiene trac-cia del valore corrente dell’intensita luminosa (nell’esempio 77%);

• isIn: relazione che descrive la posizione dell’oggetto nell’ambiente. Nell’esem-pio la lampada e inserita in una LivingRoom;

• hasFunctionality : relazione che contiene il riferimento ad un’istanza di unaclasse funzionalita. Ogni lampada di tipo DimmerLamp e caratterizzata dalpossedere tre relazioni hasFunctionality che rispettivamente contengono unriferimento ad una istanza della classe:

– StateChangeNotificationFunctionality: definisce la notifica per seg-nalare un cambiamento di stato;

– OnOffFunctionality: definisce i comandi per accendere e spegnere lalampada;

– LightRegulationFunctionality: definisce i comandi per regolare l’in-tensita luminosa della lampada.

Il controllo che il dispositivo OnOffSwitch esercita sulla lampada e descritto dallerelazioni controlledObject e generatesCommand : la prima contiene il riferimento al-l’oggetto controllato (in questo caso la lampada), la seconda viene inserita all’internodelle istanze delle notifiche OnNotification e OffNotification. Nell’esempio sivuole realizzare la seguente interazione: quando lo switch e in posizione “Off” lalampada deve essere spenta, quando e in posizione “On” la lampada deve essereaccesa. A tal fine nelle notifiche OnNotification e OffNotification dello switchvengono inserite le relazioni generatesCommand riferite rispettivamente ai coman-di OnCommand e OffCommand della lampada. In questo modo quando si imposta loswitch in posizione “Off” automaticamente viene generato il comando OffCommand

che spegne la lampada. Analogamente quando si imposta lo switch in posizione“On” viene generato il comando OnCommand che accende la lampada.

2.3 Il gateway DOG

DOG (Domotic OSGi Gateway) e una piattaforma che permette l’interfacciamento,la gestione e l’integrazione di dispositivi domotici prodotti da diversi costruttori.Nell’architettura OSGi i protocolli e gli altri moduli aggiuntivi, come ad esempiole politiche di comportamento intelligente, vengono demandati a terze parti: i bun-dle, che possono essere dinamicamente caricati nel framework OSGi a run-time.Il grande vantaggio che ne deriva e l’elevata flessibilita del sistema: un bundle puo

15


essere infatti aggiunto all’architettura in modo da estenderne le sue capacita, puo es-sere successivamente aggiornato, modificato o rimosso senza dover riavviare l’interoframework.

2.3.1 Architettura

Come illustrato nella Figura 2.4, l’architettura modulare del gateway DOG e com-posta da un insieme di bundle organizzati in 4 livelli funzionali: Device Manage-ment, DeviceControl, API e DogLibrary.

Figura 2.4. DOG Architecture

1. Device Management contiene i bundle che realizzano la Device Access Spec-ification, specifica che definisce la logica e le entita (bundle) che devono essererealizzate per implementare il supporto all’auto-detection dei dispositivi pre-senti nell’ambiente e per permettere l’hot-plug/unplug di nuovi dispositivi. Ecostituito da:

• DogDeviceManager : rileva la registrazione di servizi Device e associaquesti dispositivi all’opportuno Driver service;

• DogDevice: e l’oggetto Dog che rappresenta la classe dispositivi definitain DogOnt. Si tratta del software proxy del dispositivo reale il cui compitoe interfacciare il dispositivo con l’opportuno Driver service;

16


• Driver : contiene i bundle (Driver service) necessari per interfacciarsi coni vari tipi di rete domotica. Ogni tecnologia di rete viene gestita da unospecifico driver che consente l’accesso agli aspetti specifici del protocolloattraverso un’interfaccia di alto livello comune per tutte le tecnologie.Questo permette uniformita nella rappresentazione dei diversi dispositivi.Attualmente e composto da 3 bundle:

– Konnex Network Driver, per i sistemi KNX;

– BTicino Network Driver, per i sistemi MyHome BTicino;

– Emulator Network Driver che permette di emulare i dispositivi fisica-mente non disponibili, consentendo cosı di utilizzare il software anchein assenza di un ambiente domotico reale, cioe in simulazione.

• HouseModel : bundle che contiene l’istanza dell’ontologia DogOnt che de-scrive la struttura, le proprieta e le capacita dello specifico ambiente IDEnel quale il gateway e installato. Questo modulo sfrutta le informazioniderivanti dalle classi e dalle istanze di DogOnt per implementare funzion-alita di ragionamento e politiche intelligenti per l’ambiente. In particolareHouseModel permette la generazione delle regole necessarie per realizzarel’interoperabilita tra i dispositivi presenti:

(a) vengono individuate le relazioni controlledObject e generatesCom-mand all’interno dell’ontologia DogOnt;

(b) le relazioni trovate vengono convertite in regole nel formato MVEL;

(c) tali regole sono direttamente eseguibili dal bundle DogRules.

Durante la fase di startup del gateway, il modulo DogRules interrogail modulo HouseModel al fine di ottenere le regole di interoperabilitache deve eseguire. In risposta a questa richiesta il modulo HouseModelanalizza il modello DogOnt per individuare le associazioni presenti tra idispositivi: per ogni coppia notifica-comando viene creata una regola diinteroperabilita. Le regole prodotte vengono infine comunicate al bundleDogRules.

2. Device Control include i bundle dedicati a controllare ed a monitorare idispositivi. E costituito da:

• DogStateMonitor : fornisce le informazioni riguardanti lo stato correntedei dispositivi connessi a Dog;

• DogExecutor : permette l’esecuzione di comandi, ricevuti da altri bun-dle, sui dispositivi attraverso la chiamata dei metodi presenti negli oggetiDogDevice. Grazie al modulo HouseModel, DogExecutor verifica la cor-rettezza sintattica e semantica dei comandi ricevuti;

17


• DogScheduler : offre un servizio centralizzato per schedulare l’esecuzionedei comandi e le operazioni di monitoraggio dei dispositivi. Sfrutta imoduli DogExecutor e DogStateMonitor;

• DogRuleEngine: fornisce un ambiente di esecuzione per le regole di inter-operabilita (JBoss Rules) definite dall’utente. Questo modulo riceve glieventi generati dall’ambiente e verifica se ci sono delle regole da eseguire.

3. API include bundle che definiscono le interfacce di programmazione (indipen-denti dalla tecnologia) per permettere l’accesso ai servizi forniti da Dog adapplicazioni esterne e plug-in OSGi:

• DogApi : permette ad applicazioni basate sulla piattaforma OSGi di ot-tenere informazioni sulla configurazione dell’ambiente, di riceve eventiprovenienti dall’ambiente e di inviare comandi ai dispositivi gestiti daDOG;

• DogXmlEndPoint : fornisce un endpoint XML-RPC per i servizi offer-ti dal modulo DogApi, questo permette l’accesso a DOG da parte diapplicazioni non costruite sulla base di OSGi o di Java.

4. DogLibrary definisce le interfacce che permettono l’interazione tra i vari mod-uli che compongono il gateway. L’interazione tra diversi bundle e basata sulloscambio di oggetti DogMessage ognuno dei quali e composto dai campi type-declaration, che identifica il tipo di messaggio, e payload che contiene ilcorpo del messaggio.

2.4 Punti critici e aree di possibile miglioramento

I punti critici dei sistemi domotici basati sull’architettura DogOnt+Dog sono essen-zialmente 2:

• difficolta nella creazione del modello di un singolo appartamento/edificio;

• capacita computazionali richieste da DOG.

Il primo punto riguarda il fatto che il funzionamento del gateway DOG si basasul modello dell’ambiente contenuto nel bundle HouseModel ed espresso nel formatoOWL. Produrre un documento istanza dell’ontologia DogOnt e molto complesso: ilformato OWL richiede di organizzare le informazioni in una maniera poco intuiti-va, utilizzando costrutti e ridondanze tediose. Il progettista che configura questiimpianti domotici si trova nella situazione di dover creare un file di configurazionedirettamente nel formato OWL (attraverso l’uso di software come Protege) e questocrea molte difficolta: la complessita del processo richiede un’alta specializzazione

18


che esula dalle capacita dell’installatore medio. Per ridurre questo problema occorreprodurre degli strumenti il cui compito e facilitare la produzione di un modello OWL.Il lavoro di questa tesi si pone l’obiettivo di fornire al progettista un applicazioneche, attraverso un’interfaccia grafica semplice, consente di sviluppare il modello diun sistema domotico senza avere conoscenza approfondita del formato OWL.

Il secondo punto e relativo alle difficolta nell’elaborare informazioni complessee nell’applicare sistemi inferenziali in tempo reale su sistemi con capacita com-putazionali ridotte. In questo caso il modulo HouseModel viene sostituito dal moduloSimpleHouseModel che contiene una rappresentazione statica e semplificata dell’am-biente (ottenuta mediante il processamento del modello di ontologia durante la fasedi configurazione del gateway). Tutti i processi inferenziali vengono eseguiti off-line:DOG, durante la sua esecuzione, svolge i suoi compiti sfruttando le informazionistatiche prodotte in fase di configurazione.

19

Capitolo 3

Obiettivi

3.1 Scopo della tesi

L’utilizzo del gateway DOG in un ambiente domotico rappresenta una soluzione perpermettere l’interoperabilita tra dispositivi domotici diversi e l’aggiunta di funzion-alita avanzate. Se da un lato DOG incrementa le capacita del sistema domotico(trasformandolo in un IDE, Intelligent Domotic Environment), dall’altro introducedelle problematiche di configurazione non banali.

Per il suo funzionamento, infatti, DOG si appoggia al modello DogOnt che de-scrive l’ambiente. L’istanza dell’ontologia, quindi, e specifica del contesto: per ogniimpianto domotico in cui viene installato DOG occorre creare il file di ontologia chelo descrive.

La scelta di utilizzare DogOnt come formato di descrizione e dovuta al fattoche e una rappresentazione che permette al gateway DOG di attuare politiche in-telligenti per l’ambiente: esistono sistemi inferenziali che, interrogando l’ontologia,consentono l’estrazione di informazioni avanzate necessarie al gateway per poter op-erare. Il problema di questa rappresentazione e che produrre un documento istanzadi DogOnt e molto complesso: il formato OWL richiede infatti di organizzare le in-formazioni in una maniera poco intuitiva, utilizzando costrutti e ridondanze tediose.Il dover descrivere un ambiente domotico direttamente in formato OWL (attraversol’uso di software come Protege) crea molte difficolta al progettista: richiede di esserefortemente specializzati ed e dispendioso di tempo.

Questo approccio frena quindi lo sviluppo e l’installazione di ambienti domoticibasati su DOG in quanto e molto difficile produrre un file di configurazione correttoed e comunque pensabile solo per la descrizione di sistemi semplici, dove gli elementie le interazioni presenti siano pochi.

Per alleggerire questa problematica e stato proposto, sempre dal gruppo e-Lite,un tool in grado di generare automaticamente un file di ontologia partendo da un

20

3 – Obiettivi

documento di configurazione XML. Il formato XML proposto (xmldog) ha una strut-tura piu semplice rispetto al formato OWL e permette al progettista di descriverel’ambiente inserendo solo le informazioni essenziali. E compito del tool ricevere ilfile XML come input, validarlo, analizzarlo per estrarre le informazioni ed infineprodurre le relative istanze di DogOnt. Il tool si prende quindi carico di introdurretutte le restanti parti necessarie che, da un punto di vista umano, risultano esserecomplicate, ridondanti e tediose.

Quest’idea rappresenta di certo un passo avanti ma non puo essere consideratacome la soluzione definitiva per il problema: anche se il formato proposto e piu sem-plice ed intuitivo, il progettista resta comunque vincolato alla descrizione testualedell’ambiente ed alla conoscenza del formato XML utilizzato.

Il lavoro di tesi mira a risolvere queste problematiche andando a realizzare unambiente di sviluppo integrato per la progettazione di sistemi domotici intelligen-ti basati sulla modellazione semantica DogOnt e sul gateway DOG: l’applicazioneDogDomoticIde. Il progettista di sistemi domotici, attraverso l’uso di questoprogramma, ha la possibilita di descrivere un ambiente domotico utilizzando unasemplice interfaccia grafica. Nel seguito verranno organizzati e trattati nel dettaglioi requisiti definiti per questa applicazione.

3.2 Requisiti

I requisiti alla base della progettazione dell’applicazione DogDomoticIde possonoessere suddivisi in 2 categorie:

• requisiti funzionali : sono le funzionalita che devono essere rese disponibilidall’IDE;

• requisiti non funzionali : caratteristiche strutturali e/o di implementazionerichieste all’applicazione che non hanno impatto diretto sull’utilizzatore e sul-l’output prodotto.

3.2.1 Requisiti funzionali

I requisiti funzionali vengono catalogati in relazione alla loro priorita. Il lavoro ditesi ha come obiettivo l’implementazione di tutti i requisiti funzionali primari. Lealtre categorie (requisiti funzionali secondari e sviluppi futuri) sono considerati, peril momento, opzionali e di secondo piano.

21

3 – Obiettivi

Requisiti funzionali primari

1. presenza di un’interfaccia grafica di base in grado di fornire le tradizionalioperazioni effettuabili in un IDE (drag & drop, copia/incolla, undo e redo,zoom, salvataggio su file);

2. descrizione della struttura e dei contenuti di un impianto di tipo domotico, apartire da librerie di componenti (passivi o attivi) che possono essere inseritinell’ambiente;

3. editing degli aspetti grafici (layout 2D) e dei meta-dati (elenchi di proprieta)relativi agli ambienti creati ed ai componenti inseriti;

4. layout dell’applicazione costituito da almeno:

• Design View : vista nella quale l’utilizzatore progetta l’impianto domoticoinserendo, cancellando e modificando i vari elementi;

• Palette View : vista che contiene la libreria degli elementi inseribili nel-l’impianto domotico, organizzati in relazione alla loro natura;

• Property View : vista che permette di modificare le proprieta dell’elemen-to selezionato;

5. descrizione delle interazioni che intercorrono tra i dispositivi presenti nell’am-biente;

6. esportazione delle informazioni derivanti dal progetto in un formato utilizzabiledirettamente dal gateway DOG.

Requisiti funzionali secondari

1. inserimento nel layout dell’applicazione di una Summary View, vista ad alberoche contiene un riepilogo degli oggetti inseriti nell’impianto;

2. esportazione delle informazioni derivanti dal progetto direttamente nel formatoOWL;

3. costruzione di nuovi elementi a run-time (riferiti alle classi gia esistenti in Do-gOnt) consentendo il loro inserimento nella libreria personale dell’utilizzatore;

4. inserire controlli di validazione sugli oggetti inseriti nell’impianto domotico:un oggetto e considerato valido se tutte le sue proprieta sono compilate edassumono un valore sintatticamente corretto;

22

3 – Obiettivi

5. permettere la creazione di una struttura abitativa piu complessa: appartamentinon rettangolari, inserimento di giardini, garage e altri ambienti complemen-tari;

6. aggiornamento a run-time dell’ontologia DogOnt di riferimento, con un con-seguente aggiornamento della palette degli elementi inseribili nel sistema do-motico;

7. funzionalita di stampa su carta.

Sviluppi futuri

1. simulazione dell’ambiente domotico creato;

2. aggiunta di una vista contenente la rappresentazione grafica 3D dell’ambienteprogettato;

3. supporto al protocollo SVN: update e download di file di progetto da unrepository server.

3.2.2 Requisiti non funzionali

L’applicazione dovra essere costruita sulla base della piattaforma Java EclipseRPC. Proprio per questa ragione ogni scelta progettuale dovra tenere conto delmodello di sviluppo fornito da Eclipse. Le linee guida possono essere riassunte in 3punti:

1. programmazione plug-in based : l’applicazione e strutturata come composizionedi plug-in ognuno dei quali fornisce funzionalita diverse. I plug-in vengonoclassificati in 2 categorie: i core plug-in, che definiscono le funzionalita di basedel workbench e gli add-on plug-in, che contengono funzionalita aggiuntive;

2. interfaccia grafica perspective-based : il contenuto dell’interfaccia grafica e l’or-ganizzazione delle sue varie parti viene stabilita da una prospettiva (perspec-tive). Le prospettive possono essere selezionate dall’utente in base al taskche deve eseguire. I core plug-in contengono la definizione della prospetti-va di base dell’applicazione, gli add-on plug-in possono definire prospettiveaggiuntive relative alle funzionalita che realizzano;

3. viste multiple: ogni plug-in puo definire un insieme di viste che possono essereinserite insieme nella stessa prospettiva in relazione al task che permettono disvolgere.

Nell’ambito di questa tesi verranno sviluppati i seguenti core plug-in.

23

3 – Obiettivi

Component Library plug-in

Questo plug-in contiene la definizione della libreria dei componenti inseribili all’in-terno di un sistema domotico, in relazione alla versione di ontologia DogOnt diriferimento. I vari elementi sono organizzati in base alla loro natura (elementi ar-chitetturali, di arredamento, dispositivi) e ognuno di essi e descritto in base ad un in-sieme di proprieta (nome, tipo, descrizione, funzionalita che possiede, configurazioniche puo assumere,ecc.).

Project plug-in

Rappresenta l’ossatura dell’applicazione. Ha il compito di:

• definire il formato del file di progetto;

• supportare le seguenti operazioni su file: salvataggio, caricamento, chiusura emodifica.

Definisce inoltre i seguenti elementi per il workbench:

Menu- Gestisce il menu File con le relative voci per la gestione del file di progetto(New, Open, Close, ecc.);

View- Sono dichiarate le viste Summary View, Palette View e Property View.La Summary View contiene informazioni riassuntive riguardanti tutti gli elementiinseriti nel progetto corrente: si tratta di una rappresentazione ad albero dove ognielemento viene rappresentato, di default, dalla sua icona e dal suo nome. La PaletteView permette all’utente di inserire all’interno del proprio progetto i componentipresenti nella libreria (Component Library). Infine la Property View che e compostada un insieme di finestre organizzate in tab ognuna delle quali permette l’editing diuna categoria specifica di proprieta dell’oggetto selezionato;

Perspective - Definisce l’aspetto di base che l’applicazione deve avere. L’inter-faccia grafica deve contenere la Summary View, la Property View, la Palette View ela Design View (definita nel Design plug-in).

Design plug-in

Questo plug-in fornisce le funzionalita necessarie per rappresentare un impiantodomotico. Definisce la Design View, vista che permette di costruire ambienti, diistanziare gli elementi presenti nella Component Library (tramite la Palette View)e di creare relazioni di interazione tra i dispositivi. Supporta le operazioni di drag& drop, copy, cut, paste, undo, redo e zoom. Interagisce con la Property Viewpermettendo la modifica delle proprieta dell’oggetto selezionato.

24

3 – Obiettivi

3.3 Analisi delle possibili soluzioni

Le tipologie di soluzioni analizzate per lo sviluppo dell’applicazione DogDomoticIdesono 2:

• estensione di un ambiente CAD 2D: l’idea e quella di utilizzare come baseper l’applicazione un progetto Open Source (come ad esempio CADEMIA oSweetHome3D) che realizza le funzionalita di editing 2D permettendo di re-alizzare graficamente un ambiente domestico. In questo caso il lavoro di tesiconsiste nell’integrare il progetto con le funzionalita di modellazione che per-mettono la rappresentazione di un ambiente domotico basato sull’architetturaDOG+DogOnt: modello dati basato sull’ontologia DogOnt, descrizione delleinterazioni, editing delle proprieta, ecc.

Vantaggi - funzionalita di disegno 2D gia realizzate e di buona qualita.

Svantaggi - difficolta nell’integrare il modello dati basato sull’ontologia Do-gOnt: e necessario sostituire la struttura dati sulla quale si basano questeapplicazioni con il nuovo modello. Questo comporta la modifica o addiritturala riscrittura di buona parte del codice gia presente.

• estensione di un ambiente di modellazione: questa soluzione consiste nell’u-tilizzare degli strumenti che consentono di rappresentare un modello dati edi generare automaticamente, su di esso, un applicazione editor di base. Ilplug-in di Eclipse GMF realizza queste funzionalita: fornisce delle utility checonsentono l’auto-generazione di un’applicazione editor relativa ad un modellodati definito dal programmatore. Il lavoro di tesi consiste nel creare il mod-ello dati basato su DogOnt, utilizzare le utility fornite da GMF per la gener-azione dell’applicazione di base e personalizzare il codice al fine introdurre lefunzionalita desiderate.

Vantaggi - supporto per la creazione del modello dati, editor di base generatoautomaticamente, soluzione che permette uno sviluppo incrementale basato suplug-in.

Svantaggi - le funzionalita di disegno 2D sono di base, il progetto generato ecomplesso e difficilmente estendibile.

La soluzione adottata e quella basata sull’uso del plug-in GMF. La ragione diquesta scelta e legata al fatto che l’obiettivo primario dell’applicazione e quella difornire un ambiente di modellazione per sistemi domotici anche con capacita didisegno 2D limitate e di base. Il plug-in EMF fornisce inoltre gli strumenti chesemplificano il processo di aggiornamento del modello dati in relazione, ad esempio,all’evoluzione dell’ontologia DogOnt. Infine la generazione automatica del codicerealizza, da sola, buona parte delle funzionalita di base richieste.

25

Capitolo 4

Strumenti utilizzati

Per lo sviluppo dell’applicazione DogDomoticIde viene utilizzata la piattaformaEclipse, essendo quest’ultima un ambiente di sviluppo dotato di plug-in addizionalimolto utili per la realizzazione degli obiettivi di questa tesi.

In questo capitolo verranno quindi introdotti Eclipse ed i plug-in EMF, GEFe GMF che consentono lo sviluppo di tool ed editor grafici, basati su di un modellodati definito dal programmatore, limitando la necessita di scrivere codice per moltidei casi piu comuni.

4.1 La piattaforma Eclipse

La piattaforma Eclipse e un insieme di componenti per lo sviluppo di tool ed appli-cazioni di ogni genere. Nata come evoluzione dell’ambiente di sviluppo Visual Agedi IBM, e diventata Open Source nel 2001 e dal 2003 viene controllata della EclipseFoundation, un’organizzazione no profit indipendente.

I motivi del suo enorme successo e della sua popolarita risiedono sia nella suanatura aperta, sia nella sua versatilita. Eclipse non e infatti strettamente dipen-dente da Java e non e nemmeno limitato al settore degli ambienti di sviluppo. Inparticolare, grazie al sottoinsieme di componenti denominato RCP1, e possibile re-alizzare applicazioni per qualunque tipo di funzione (tool di supporto per l’analisidi molecole chimiche, strumenti finanziari, ecc.).

Questa versatilita e accentuata dall’uso di Eclipse come integration point : i toolsviluppati con questa piattaforma possono essere facilmente integrati tra loro, anchese realizzati da produttori di software diversi; e inoltre piuttosto semplice suddividerela programmazione di un applicativo in piu moduli, per poi integrarli a lavoro finito.

La Figura 4.1 mostra i componenti principali della piattaforma: alla base di tuttoviene posizionato il Platform Runtime, un kernel che fornisce tutte le funzionalita

1Rich Client Platform, www.eclipse.org/community/rcp.php

26

4 – Strumenti utilizzati

Figura 4.1. L’architettura di base di Eclipse

basilari di Eclipse e che ha il compito di caricare all’avvio tutte le altre parti, siaquelle standard, come il Workbench (l’interfaccia grafica) ed il Workspace (lo spaziocontenente i file e i progetti dell’utente), sia eventuali plug-in addizionali installati.

La particolarita di quest’architettura e che, ad eccezione del Platform Runtime,tutti i componenti, anche quelli forniti di default, sono di fatto dei plug-in.

Un plug-in e la piu piccola unita funzionale sviluppabile e distribuibile separata-mente. I plug-in di Eclipse sono costituiti da codice Java (raccolto in un archivioJAR), due file di manifesto (manifest.mf e plug-in.xml) e altre risorse di variogenere (immagini, file di help, ecc.).

Un tool, specialmente se di dimensioni consistenti, puo essere costituito da piuplug-in ognuno dei quali, a sua volta, puo essere frammentato in piu parti. Mentreil file manifest.mf definisce le dipendenze a runtime di un plug-in, il file plug-

in.xml definisce le varie extension ed extension point, cioe le integrazioni con glialtri plug-in. I plug-in vengono rilevati all’avvio dal Platform Runtime che, leggen-do i loro manifesti, crea il Plug-in Registry, un registro di informazioni che vienereso disponibile a runtime tramite API (l’interfaccia di programmazione), consenten-do cosı l’aggiunta o la rimozione di plug-in durante l’esecuzione della piattaforma.

27


Grazie ai file di manifesto e possibile inserire nel Plug-in Registry tutte le infor-mazioni riguardanti extension ed extension point senza che sia necessario caricarein memoria tutti i plug-in.

Con questo meccanismo si ottengono diversi vantaggi: facilita di integrazione gra-zie agli extension point, flessibilita e dinamicita grazie alla disponibilita a runtimedel Plug-in Registry (cosa che, tra l’altro, consente di verificare se un aggiorna-mento o l’aggiunta di plug-in causeranno problemi o conflitti) e migliori prestazioni(in particolare all’avvio), grazie al caricamento on demand dei plug-in.

4.2 Eclipse Modeling Framework

EMF e un framework per la generazione di tool ed applicazioni basati su un modellodati strutturato, incentrato sul concetto di Model-Driven Architecture Development.L’obiettivo di questo framework e quello di fornire un punto di incontro tra il mondodella modellazione e quello della programmazione.

La funzionalita principale di EMF e quella di ricevere come input un modello (sot-to forma di diagramma UML, schema XML, interfacce Java annotate) e fornire comeoutput una serie di classi Java che realizzano i vincoli, le relazioni e le associazionidescritte nel modello di partenza.

Il lavoro del programmatore consistera innanzitutto nel creare il modello, e quin-di, dopo aver generato il codice tramite EMF, nell’implementare i comportamentispecifici che il modello non e in grado di rappresentare (ad esempio la funzionalitadi un metodo in una classe Java). Le parti piu ripetitive e tediose (metodi getter esetter, gestione delle relazioni tra oggetti, gestione di eventi, ecc.) vengono invececreate in maniera automatica da EMF.

Oltre alla generazione di codice EMF fornisce altre funzionalita come il supportoalla personalizzazione del codice, una Reflective API per generare dinamicamentemodelli, serializzazione e deserializzazione dei dati (in formato XMI) e la possibilitadi generare semplici editor grafici.

4.2.1 Componenti

L’Eclipse Modeling Framework e costituito da tre componenti principali: EMFCore, EMF Edit ed EMF Codegen.

EMF Core include la definizione del metamodello ECore: il formato in cui ven-gono convertiti tutti i modelli utilizzati. E interessante notare che l’implementazionedi Ecore usata da EMF viene generata dallo stesso code generator di EMF.

Come si osserva nella Figura 4.2, la gerarchia di ECore ricorda abbastanza quelladelle API Java: la classe di base e EObject (equivalente a java.lang.Object),

28


Figura 4.2. La gerarchia del modello ECore

mentre, a scendere nell’albero, vengono posizionate le varie classi che rappresentanooggetti tipici di un class diagram (classi, attributi, operazioni).

EObject fornisce una serie di funzioni di base ereditate da tutti gli altri oggetti.In particolare il metodo eClass() (logicamente equivalente a Object.getClass())restituisce informazioni sull’istanza corrente, mentre eGet e eSet consentono oper-azioni riflessive sugli attributi dell’oggetto. Inoltre EObject estende l’interfaccia No-tifier, predisponendo quindi ogni oggetto a inviare notifiche a osservatori registratiin caso di modifica del proprio stato.

EMF Edit fornisce classi di supporto basate su JFace2 che consentono la vi-sualizzazione di oggetti del modello. Mette inoltre a disposizione un framework di

2Tool per interfacce grafiche dotato di funzionalita avanzate e di alto livello,http://www.eclipsepluginsite.com/jface.html

29


comandi che permettono la modifica delle proprieta degli oggetti istanziati, con ilsupporto alle operazioni di undo e redo.

L’ultima componente di EMF e EMF Codegen le cui funzionalita sono prin-cipalmente 2: fornire un framework estensibile per l’importazione di modelli (infuturo si prevede l’aggiunta del supporto ad altri formati di modello) ed offrire lagenerazione vera e propria del codice per i componenti Core ed Edit.

4.2.2 Definire un modello EMF

Il primo passo per utilizzare EMF e l’importazione di un modello dati. Allo statoattuale sono quattro i formati che si possono utilizzare:

• XMI : si puo definire il proprio modello interamente in XMI, cosı com’e definitoil meta-modello ECore;

• XMLSchema: se si ha gia a disposizione un modello espresso in questo for-mato e possibile importarlo in EMF. Questa soluzione ha lo svantaggio diessere meno espressiva rispetto ad un modello descritto in UML (ad esempioXMLSchema non sono supporta i riferimenti bidirezionali);

• UML: si possono importare direttamente class diagram UML: e supportato ilformato Rational Rose;

• interfacce Java annotate: se non si dispone di un editor grafico UML, o se nonsi e pratici del linguaggio e si e piu propensi a scrivere codice, questa opzionerisulta un’interessante alternativa.

Nell’ambito di questa tesi il modello dati per EMF e stato sviluppato utilizzandola tecnica delle interfacce Java annotate, per questa ragione vale la pena analizzarlacon piu attenzione.

Un programmatore che scelga di utilizzare questa soluzione deve scrivere le in-terfacce per le classi di cui avra bisogno, avendo l’accortezza di commentarle conspeciali tag definiti da EMF. Queste informazioni sono importanti in quanto perme-ttono ad EMF Codegen di riconoscere il modello creato per poi tradurlo nel formatoECore. L’uso di interfacce Java annotate permette quindi di esprimere le caratteris-tiche del modello dati: il programmatore, per ogni interfaccia, inserisce gli attributiche ne descrivono il contenuto. Se, ad esempio, un elemento del modello contiene laproprieta “name” allora, nella relativa interfaccia, il programmatore dovra inserirela linea di codice String getName che descrive il fatto che quell’elemento contieneun attributo di nome “Name” di tipo “String”. Per le relazioni che intercorrono trauna classe e l’altra si sfruttano i concetti di ereditarieta e di contenimento.

30


Figura 4.3. Il funzionamento di EMF

Una volta completata la stesura delle interfacce annotate, si utilizza il packagedi interfacce come input per EMF che provvede all’auto-generazione dei file ecore

e genmodel. Il primo contiene la rappresentazione del modello dati nel formatoECore. Tale file e personalizzabile sfruttando l’editor ECore fornito da EMF, cherappresenta il modello in un albero e consente di aggiungere, rimuovere o modificareclassi e attributi. Il file genmodel contiene invece impostazioni utili ai fini dellagenerazione di codice.

Dopo aver descritto il modello si puo avviare la generazione del codice, ottenendouna versione aggiornata delle interfacce (essenzialmente per fare in modo che tuttele classi estendano EObject). Viene inoltre generata una classe implementazioneper ogni elemento descritto nel modello dati. I metodi, il cui comportamento nonpuo essere modellato in partenza, vengono prodotti sotto forma di skeleton (sonodichiarati ma vuoti) pronti per l’implementazione da parte del programmatore.

Osservando la Figura 4.3 notiamo che oltre al modello Java (che e sia un inputche un output) vengono generati altri due componenti: Java Edit e Java Editor.

Java Edit contiene le classi di supporto fornite da EMF Edit utilizzabili percreare editor indipendenti da Eclipse.

Java Editor si appoggia su Java Edit e contiene le classi che realizzano uneditor avviabile in una nuova workbench window di Eclipse senza necessitare dialcuna modifica.

31


Viene infine generato un quarto componente (non mostrato in figura) che ha loscopo di fornire un insieme di metodi di test. Anche in questo caso, non essendoil comportamento modellato, si tratta di skeleton che tuttavia facilitano il compitoper il programmatore.

Vengono inoltre generate alcune classi di servizio: le classi Factory e Package.La classe Factory, come si intuisce dal nome, contiene i metodi necessari per is-tanziare gli oggetti facenti parte del modello; la classe Package, invece, consentel’accesso ai meta-dati del modello.

4.3 Graphical Editing Framework

Lo scopo di questo plug-in e facilitare lo sviluppo di rappresentazioni grafiche di mod-elli esistenti, creando editor dotati di funzionalita quali drag & drop, copia/incolla,undo e redo. Una classica applicazione GEF consente di disegnare diagrammi divario tipo, con la possibilita di collegare le figure, ridimensionarle e spostarle.

4.3.1 Componenti

GEF si basa sul paradigma Model-View-Controller. Il modello deve essere definitoin codice Java senza vincoli particolari, GEF si occupa di realizzare le parti View eController.

A tal fine e composto da due framework: Draw2D, incaricato della parte grafica,ed il Graphical Editing Framework vero e proprio che si occupa di tutte le restantifunzionalita.

• Draw2D e una libreria grafica utilizzabile indipendentemente sia da GEF cheda Eclipse. Offre grande flessibilita nella gestione delle figure: forme, colori,contorni e layout si possono impostare con grande liberta e le figure possonoessere annidate. Vengono offerte anche opzioni particolari per le connessioni(che a loro volta sono un tipo particolare di figura), con la possibilita di definirepunti di ancoraggio e router (figura con punti di ancoraggio multipli);

• Graphical Editing Framework si occupa di definire i Controller dell’appli-cazione: le classi EditPart, componenti principali di un’applicazione GEF,il cui compito e mappare le figure Draw2D sugli oggetti del modello dati.

Le EditPart devono essere create dal programmatore implementando la classeastratta AbstractEditPart, e istanziate attraverso una factory. In genere occorreuna EditPart per ogni oggetto del modello dati.

A seconda che si abbia a che fare con una figura vera e propria oppure conuna connessione tra figure, si possono usare le sottoclassi GraphicalEditPart e

32


ConnectionEditPart (quest’ultima non e altro che una GraphicalEditPart conl’aggiunta dei campi source e target che definiscono il collegamento).

Le operazioni di editing effettuate dall’utente vengono gestite da altri compo-nenti: le policy, i comandi e le richieste.

I comandi sono le operazioni che vengono effettivamente svolte sul modello dati(es. creazione di una nuova figura, ridimensionamento o connessione di due figure). Ilprogrammatore deve creare uno specifico comando (che implementa la classe astrattaCommand) per ogni operazione che intende svolgere sul modello.

Una classe EditPolicy ha lo scopo di definire il comportamento di una specificaEditPart (scegliendo quali comandi eseguire) in relazione agli eventi provenientidall’interfaccia grafica.

Le richieste sono gli oggetti di comunicazione utilizzati dal framework per richiederealle EditPart un comportamento specifico. La CreateRequest, ad esempio, vieneutilizzata quando e necessario creare un oggetto, la LocationRequest quando sivuole tenere traccia della posizione di un oggetto.

La catena di eventi necessari per interagire con le EditPart puo quindi essereriassunta in questa maniera:

1. generazione di una richiesta da parte del framework in relazione al compor-tamento dell’utente o, piu in generale, agli eventi provenienti dall’interfacciagrafica;

2. la richiesta viene raccolta dall’EditPart che l’analizza ed esegue l’EditPolicyche realizza il comportamento desiderato;

3. l’EditPolicy esegue, infine, i comandi necessari per effettuare le modifichedesiderate sul modello.

4.3.2 Usare GEF con EMF

Dopo aver analizzato separatamente EMF e GEF viene naturale pensare ad un lorouso combinato: da un lato il plug-in GEF, che offre buone capacita dal punto divista grafico ma che necessita di un modello dati gia pronto, dall’altro EMF, cheagevola la costruzione di un modello dati ma che fornisce solo funzionalita basilariper l’editing grafico.

Sfruttando gli aspetti positivi di entrambi si puo pensare di partire da un mod-ello UML (o interfacce Java annotate), generare il modello dati e su esso costruireEditPart e figure Draw2D, eventualmente integrando lo stack di comandi EMF conquello di GEF.

Purtroppo questi due framework non sono nati per cooperare, e ci sono alcuneincompatibilita (prima fra tutte quella fra i due stack di comandi) che rendonotutt’altro che banale la loro integrazione.

33


Il framework GMF si pone l’ambizioso obiettivo di risolvere queste problem-atiche, con lo scopo di minimizzare il lavoro che un programmatore deve fare percostruire un editor grafico che si appoggia su un modello dati.

4.4 Graphical Modeling Framework

Anche GMF, cosı come GEF, e un framework il cui scopo e semplificare la real-izzazione di editor grafici basati su modelli. Mentre GEF prevede una consistenteparte di stesura di codice da parte del programmatore, GMF nasce con lo scopodi rimuovere quasi completamente la fase di scrittura del programma, sostituendolacon la definizione di una serie di modelli intermedi per arrivare alla generazioneautomatica del codice dell’editor.

Il concetto di base e quello di sfruttare l’idea di generazione automatica delcodice di EMF per applicarla a GEF. Partendo da un modello del dominio dell’appli-cazione e definendo una serie di altri modelli intermedi, GMF e in grado di generaretutte quelle classi che un programmatore che utilizza GEF dovrebbe implementaremanualmente: EditPart, comandi, EditPolicy.

La Figura 4.4 mostra i passi necessari per creare un editor grafico utilizzandoGMF. Per prima cosa e necessario disporre di un modello del dominio, rappresentatonel formato ECore: per farlo e sufficiente utilizzare EMF, importando il propriomodello e ottenendo cosı i file ecore e genmodel.

Occorre poi definire altri 3 modelli:

1. Graphical Definition Model: questo modello serve a definire l’aspetto ela composizione degli oggetti grafici istanziabili all’interno dell’editor. Glioggetti possono essere inoltre definiti come Compartment, cioe con la capacitadi contenere al loro interno altri elementi;

2. Tooling Definition Model: serve a definire quali strumenti saranno a dis-posizione dell’utente nella palette dell’editor. Tipicamente per ogni oggettoviene definito un CreationTool, che ha come effetto quello di inserire nellapalette una voce relativa all’oggetto in questione;

3. Mapping Definition Model: si occupa dell’unione del modello del dominiocon il Tooling Definition Model ed il Graphical Definition Model. Una dellefunzioni svolte da questo modello e quella di creare le associazioni tra i toolcontenuti nella palette dell’applicazione e gli oggetti grafici.

Per la definizione di questi modelli, GMF mette a disposizione i corrispettivimeta-modelli che, a loro volta, non sono altro che modelli ECore. Il meta-modello

34


Figura 4.4. Il workflow di GMF

grafico, ad esempio, definisce la classe Canvas, che puo contenere un numero arbi-trario di figure (classe Figure) che, a loro volta, hanno una posizione, una dimen-sione ed una certa composizione grafica. Il programmatore, usando queste classi,potra realizzare la rappresentazione grafica desiderata.

Una volta completati questi tre modelli il lavoro e sostanzialmente finito: GMFgenerera automaticamente il Generator Model da cui, dopo aver eventualmentepersonalizzato alcuni parametri, si passera direttamente alla generazione del codice.Sfruttando EMF Edit e GEF, GMF creera comandi, EditPart, provider di contenutie tutto il necessario per realizzare un editor funzionante.

L’editor creato offrira all’utente una serie di caratteristiche piu avanzate rispettoa quelle fornite da un’applicazione costruita mediante GEF: zoom, assistenti per lacreazione del diagramma, anteprima di stampa, supporto per la clipboard e altroancora.

35

Capitolo 5

Generazione dell’applicazioneDogDomoticIde

La realizzazione dell’applicazione DogDomoticIde si sviluppa in 2 fasi:

1. generazione dell’IDE tramite l’uso del plug-in GMF;

2. adattamento del codice generico derivante da GMF ai requisiti specifici diDogDomoticIde.

In questo capitolo sara descritta la prima fase, cioe verranno spiegati nel dettagliotutti gli step e le soluzioni che portano, come conclusione, alla generazione dell’appli-cazione di base. Le operazioni di adattamento/estensione dell’applicazione generatasaranno presentate nel capitolo successivo.

5.1 Struttura della soluzione

Il plug-in GMF consente di generare in automatico la maggior parte del codicenecessario all’applicazione, sulla base di un modello dati e di altri modelli intermediche definiscono le proprieta grafiche e funzionali di base dell’applicazione stessa. Ilprocedimento che porta alla generazione dell’applicazione puo essere suddiviso in 3parti:

1. definizione e generazione del modello dati;

2. costruzione dei modelli necessari per GMF;

3. generazione del codice.

Il modello dati viene costruito sfruttando 2 sorgenti di informazioni: l’ontologiaDogOnt, dalla quale si ricavano l’elenco e le proprieta di tutti gli elementi istanziabili

36

5 – Generazione dell’applicazione DogDomoticIde

all’interno di un ambiente domotico, e la struttura del modello dati (DataModelStructure) che definisce un insieme di classi di base in grado di rappresentare consufficiente dettaglio tutti gli elementi definiti in DogOnt.

Figura 5.1. Struttura della soluzione

Il modello dati viene definito utilizzando la tecnica delle interfacce Java an-notate. Un interfaccia annotata e una normale interfaccia Java in cui compaionoparticolari tag che consentono ad EMF di riconoscere le dichiarazioni effettuate. Lagenerazione delle interfacce annotate avviene mediante il seguente procedimento:

1. creazione di un’interfaccia annotata per ogni classe definita nel DataModelStructure;

2. interrogazione (query) dell’ontologia (mediante il linguaggio SPARQL1) al finedi ottenere l’elenco delle classi relative a dispositivi, elementi architetturali,ambienti, stati, comandi, ecc;

3. creazione di un’interfaccia annotata per ciascuna classe a partire dall’oppor-tuna interfaccia del DataModel Structure.

1RDF query language, www.w3.org/TR/rdf-sparql-query

37


Le interfacce create a partire da DogOnt sono riferite alle opportune interfacce def-inite nel DataModel Structure tramite relazioni di ereditarieta. Il modello prodottoe quindi costituito dalle interfacce relative al DataModel Structure (ognuna dellequali contiene la descrizione di una particolare classe di elementi) e dalle interfaccerelative agli elementi dell’ontologia (interfacce vuote, caratterizzate da una relazionedi ereditarieta verso un’interfaccia del DataModel Structure).

Consideriamo ad esempio la classe lampada (Lamp) in DogOnt, essa rappresentaun dispositivo con capacita di emettere luce. Essendo la lampada un dispositivo,la sua interfaccia puo essere riferita all’interfaccia DeviceElement che contiene ledichiarazioni degli attributi tipici di ogni dispositivo. L’interfaccia Lamp, quindi,estendera l’interfaccia DeviceElement, piu o meno direttamente.

Il package di interfacce risultante da questa prima fase di mapping tra DogOnt edil DataModel Structure, viene utilizzato come input per un tool fornito dal plug-inEMF che produce, come output, i file ecore e genmodel funzionali ai successivi passidi generazione automatica del codice. Sulla base di tali file, ed in particolare delfile ecore, EMF provvedera alla generazione di 3 plug-in specifici dell’applicazioneDogDomoticIde:

• domoticIde, plug-in composto da 3 package:

– dataModel.interface, che contiene una versione aggiornata delle interfac-ce del modello (essenzialmente per fare in modo che tutte estendanol’interfaccia EObject);

– dataModel.impl, che fornisce una classe implementazione per ogni inter-faccia contenuta in dataModel.interface. Le classi generate sono dotatedei metodi get e set per tutti gli attributi specificati nel modello;

– dataModel.util, che contiene classi Factory per la creazione di oggettiistanza delle classi contenute nel package dataModel.impl.

• domoticIde.edit: plug-in che fornisce una classe di supporto (ItemProvider)per ogni elemento contenuto nel modello dati. Ogni classe ItemProvider

implementa diverse interfacce (ITreeItemContentProvider, IItemProper-

tySource, ecc.) con lo scopo di fornire, al plug-in che implementa l’editor(domoticIde.diagram), le informazioni necessarie per la rappresentazionedell’elemento in diverse tipologie di viste (TreeView, TableView, ecc) ed unframework di comandi per l’interazione con il modello dati (incluso il supportoalle operazioni undo e redo);

• domoticIde.editor: plug-in che contiene le classi per la creazione di editorgrafici avviabili in una workbench window di Eclipse. Non viene utilizzato nelcaso di applicazioni stand-alone.

38


Come si osserva nella Figura 5.1, il plug-in domoticIde generato da EMF non equello definitivo; infatti il package dataModel.impl deve essere aggiornato in modotale che ogni classe implementazione provveda alla corretta inizializzazione dei propriattributi.

Per capire questo concetto consideriamo di nuovo l’esempio della lampada. Dopola generazione delle implementazioni la situazione e quella mostrata in Figura 5.2:nel package dataModel.interface sono presenti le interfacce Lamp e DeviceElement

(legate da una relazione di ereditarieta).

Figura 5.2. Esempio di interfacce e di classi implementazione

DeviceElement definisce l’attributo description, il cui contenuto rappresentauna descrizione delle funzionalita offerte da un generico dispositivo.

Nel package delle implementazioni vengono generate due classi: DeviceEle-

mentImpl, implementazione dell’interfaccia DeviceElement (che contiene i meto-di getter e setter per l’attributo description) e LampImpl, implementazione del-l’interfaccia Lamp. Allo stato attuale la classe LampImpl eredita l’attributo de-

scription dalla classe DeviceElementImpl che, inoltre, fornisce i metodi necessariall’inizializzazione dello stesso.

Completare una classe implementazione consiste nell’inserire, all’interno del suocostruttore, le istruzioni necessarie ad inizializzare gli attributi. Tale operazione vaeseguita per ogni classe presente nel package dataModel.impl. Il costruttore presentenella classe LampImpl viene quindi aggiornato con l’inserimento dell’istruzione set-Description(’’An artificial source of visible illumination’’). Il valoreassegnato agli attributi cambia, chiaramente, in relazione all’elemento che si staanalizzando: nel caso di un dispositivo diverso (es. Computer) l’attributo descrip-

tion assumera un valore diverso (setDescription(’’A machine for performing

calculations automatically, to work and play’’)). Naturalmente questo es-empio ha scopo chiarificatore e quindi semplifica la realta: l’interfaccia DeviceEle-

ment contiene infatti piu attributi di quelli mostrati in Figura 5.2 e la definizione diogni dispositivo non e cosı banale. I valori utilizzati per inizializzare gli attributi diogni elemento vengono ricavati dall’ontologia DogOnt.

39


Terminata la fase di completamento delle implementazioni, il plug-in domoticIdediventa a tutti gli effetti la libreria di componenti (Component Library plug-in) sullaquale si basera l’applicazione DogDomoticIde.

Come mostrato in Figura 5.1 il file ecore costituisce anche l’input per la creazionedei modelli necessari alla definizione delle caratteristiche grafiche e funzionali dibase dell’applicazione, cioe i modelli gmftool, gmfgraph e gmfmap. Il file gmftool(Tooling Definition Model) ha lo scopo di contenere la descrizione della palettedegli oggetti inseribili dall’utente nel foglio di lavoro risultante. Per ogni elementodella libreria che si desidera inserire nella palette occorre introdurre, in questo file, unoggetto CreationTool. E inoltre possibile organizzare i CreationTool all’internodi ToolGroup in maniera tale da raggrupparli, ad esempio, in base alla loro natura.

Il file gmfgraph (Graphical Definition Model) contiene la descrizione del-l’aspetto grafico di tutti gli elementi istanziabili dall’utente nel foglio di lavoro. Perognuno di essi e necessario creare gli oggetti Node e Figure Descriptor. Node

permette la descrizione delle informazioni grafiche di carattere generale. Figure

Descriptor invece descrive la forma e la composizione grafica dell’elemento. Adesempio, ogni elemento istanziato dall’utente nell’applicazione DogDomoticIde haforma rettangolare e contiene un’etichetta che visualizza il nome dell’oggetto. Lerelazioni di interazione tra gli oggetti vengono rappresentate da collegamenti (link),oggetti grafici la cui forma e definita da una Polyline (unione di segmenti rettilinei).

Il file gmfmap (Mapping Definition Model) contiene le associazioni tra ledefinizioni grafiche presenti nel file gmfgraph, i CreationTool contenuti nel filegmftool e gli elementi del modello dati.

Figura 5.3. Esempio di mapping

Per ogni elemento occorre creare e inizializzare un Node Mapping con i riferimentialla descrizione grafica dell’elemento, al CreationTool ed alla classe del modello datiche descrive le proprieta dell’elemento stesso. Le corrispondenze create permettono

40


a GMF di generare il codice in modo tale che, ad ogni voce della palette degli oggetti,corrisponda uno specifico oggetto grafico ed uno specifico elemento del modello dati.

Infine occorre osservare che solo una parte degli elementi descritti nel modellodati (plug-in domoticIde) possono essere istanziati dall’utente nel proprio progetto.Infatti gli elementi estratti dall’ontologia per la creazione del modello dati non sonosolo dispositivi, elementi architetturali, arredamento o, piu in generale, elementicon una forma fisica, ma sono anche comandi, stati e notifiche, che descrivono ilcomportamento e le funzionalita offerte dai singoli dispositivi. E evidente che questiultimi non devono essere istanziabili dall’utente: non ha senso, ad esempio, inserirenell’impianto domotico un oggetto di tipo comando. Per svolgere questa operazionedi filtraggio e necessario quindi agire sui file gmftool, gmfgraph e gmfmap in manieratale che contengano i CreationTool, le descrizione grafiche ed i mapping dei solielementi “tangibili” di un impianto domotico.

Sulla base di questi 3 modelli, GMF produce in automatico ilGenerator Model(Figura 5.1), un ulteriore modello che contiene la descrizione completa della strut-tura e delle classi che devono essere generate per l’applicazione. Il file gmfgen puo es-sere personalizzato dal programmatore, con l’accortezza di verificare che le modificheintrodotte non compromettano il risultato della generazione del codice. GMF, sullabase del Generator Model, provvede alla auto-generazione di domoticIde.diagram,plug-in composto dai package:

• ide.diagram.application: contiene le classi che costituiscono l’ossatura dell’ap-plicazione DogDomoticIde e che permettono la gestione dei file di progetto(formato di salvataggio, apertura, chiusura e creazione di un nuovo proget-to). Questo package contiene inoltre la classe PaletteFactory, sede delladescrizione della Palette View (Figura 5.4), punto di accesso alla libreria dicomponenti che permette all’utente di istanziare oggetti EditPart nel fogliodi lavoro (Design View);

• ide.diagram.part : contiene le classi EditPart ognuna delle quali e relativaad uno specifico elemento istanziabile dall’utente nella Design View. OgniEditPart e completamente descritta e puo quindi essere utilizzata senza alcunamodifica;

• ide.diagram.policy : contiene le classi EditPolicy che definiscono le operazionieffettuabili sulle EditPart associate ed i comandi necessari ad aggiornare ilmodello dati corrispondente;

• ide.diagram.property : contiene le classi per la gestione della Property View(Figura 5.4) che permette all’utente di personalizzare le proprieta degli oggettiistanziati.

41


Il plug-in domoticIde.diagram contiene inoltre i riferimenti ai plug-in domoticIde edomoticide.edit tramite i quali accede al modello dati ed interagisce con esso.

Figura 5.4. Componenti dell’applicazione DogDomoticIde generata mediante GMF

Nei prossimi paragrafi saranno approfondite tutte le parti descritte in questaprima sezione a partire dalla definizione del modello dati.

5.2 DataModel Structure

Il DataModel Structure (Figura 5.8) consiste in un insieme di classi, organizzategerarchicamente, sulle quali vengono mappati tutti i concetti contenuti nell’ontologiaDogOnt (Ontology Classes).

Figura 5.5. Il ruolo del DataModel Structure

I concetti modellati in DogOnt appartengono a diverse gerarchie (o alberi) omo-genee che includono rispettivamente: elementi architetturali, dispositivi, stati, co-mandi, notifiche, ambienti, ecc. Ogni classe contenuta nel DataModel Structureha lo scopo di descrivere una di queste categorie, rappresentandone le proprieta inmaniera sufficientemente generale ed estendibile.

Questo modello nasce con lo scopo di semplificare la rappresentazione del con-tenuto dell’ontologia DogOnt sotto forma di un insieme di interfacce Java annotate.Grazie a questo meccanismo prima vengono prodotte le interfacce che descrivonole varie categorie (es. DeviceElement per i dispositivi) e poi, per ogni elementoestratto dall’ontologia, viene creata un’interfaccia vuota che estende l’opportuna in-terfaccia di categoria. Se non si fosse adottato un modello di base generale ogni

42


interfaccia prodotta avrebbe dovuto contenere al suo interno la definizione di tuttele caratteristiche, con conseguente duplicazione delle informazioni.

Un ambiente domotico (classe Environment) puo contenere un insieme genericodi elementi (classe Element) ognuno dei quali e caratterizzato dagli attributi name,type e description che rispettivamente contengono il nome, il tipo ed una breve de-scrizione dell’elemento. Gli elementi presenti in un sistema domotico possono esseresuddivisi in 3 famiglie principali: elementi architetturali, dispositivi ed ambienti. Perelementi architetturali si intendono gli elementi passivi non controllabili dal gatewaydomotico: oggetti strutturali (muri, porte, finestre, ecc) e di arredamento (sedie, mo-bili, tavoli, ecc). Gli elementi architetturali (classe ArchitecturalElement, Figura5.6) possono essere connessi a sensori e governati da attuatori (sensors, actua-tors). Una porta puo, ad esempio, essere governata da un DoorActuator (che negestisce l’apertura e la chiusura) il quale, a sua volta, puo venire controllato daun PresenceSensor che attiva l’attuatore a seguito della rilevazione di una presen-za umana nelle vicinanze della porta. Gli attributi sensorType ed actuatorType

contengono rispettivamente la tipologia di sensore e di attuatore che possono essereconnessi allo specifico elemento architetturale.

Figura 5.6. La classe ArchitecturalElement

La classe BuildingArea (Figura 5.7) modella gli ambienti dentro i quali vienerealizzato un impianto domotico (appartamenti, stanze, garage e giardini). In unsistema domotico ogni ambiente puo contenere un insieme di elementi architetturali(lista uncontrollableInside), un insieme di dispositivi (deviceInside) ed, a suavolta, ulteriori ambienti (environmentInside), si pensi, ad esempio, ad un appar-tamento che contenga una o piu stanze. La forma di ogni ambiente, in una rapp-resentazione bidimensionale, e definita da un insieme di punti (xpoints, ypoints),che costituiscono i vertici di un poligono.

Figura 5.7. La classe BuildingArea

43


Figura 5.8. Il DataModel Structure

44


I dispositivi (classe DeviceElement, Figura 5.9) sono elementi dell’ontologia cherappresentano gli oggetti controllabili dal gateway DOG. Essi generano notifiche inrelazione ad un cambiamento di stato, sono governabili dal gateway attraverso l’usoun insieme di comandi (per modificare ed interrogare lo stato) e possono assumereuna serie di configurazioni diverse (stati). Naturalmente il numero ed il tipo dinotifiche che il dispositivo genera (lista notifications), di comandi accettati peril controllo (commands) e di configurazioni che puo assumere (states) variano perogni tipologia di dispositivo.

Figura 5.9. La classe DeviceElement

Ogni dispositivo reale (fisicamente presente in un impianto domotico) e dotatodi una componente di rete (NetworkComponent, Figura 5.10). Tale componente direte definisce i parametri tecnologici necessari al gateway DOG per interagire con ildispositivo stesso.

Figura 5.10. La gestione della componente di rete

L’attributo networkType descrive il tipo di componente di rete e, al momen-to, puo assumere 3 valori: BTicinoNetworkComponent, KonnexNetworkComponented EliteNetworkComponent. BTicinoNetworkComponent contiene i parametri chee necessario definire al fine di comunicare con un dispositivo BTicino MyHome

45


(physicalAddress e physicalType). Analogamente KonnexNetworkComponent for-nisce i parametri necessari per l’interazione con un dispositivo Konnex. In parti-colare i parametri groupAddress ed individualAddress sono attributi associatial dispositivo stesso, mentre le liste commandsHexValue e commandsGroupAddress

contengono rispettivamente i parametri cmdHexValue e groupAddress associati adogni comando e notifica che il dispositivo gestisce. EliteNetworkComponent, infine,viene utilizzato per i dispositivi non reali (che non hanno componente di rete) inseritinel modello dell’ambiente per essere utilizzati in simulazione. Come si osserva dallaFigura 5.10, le 3 classi che implementano le componenti di rete sono specializzazionedella classe NetworkComponent. Questo permette di istanziare indifferentemente unadelle 3 componenti di rete all’interno di ogni dispositivo.

Le classi ArchitecturalElement, BuildingArea e DeviceElement estendono laclasse Element. Ogni elemento dell’ontologia mappato su una di queste 3 classi edescritto sia dagli attributi contenuti nella classe di mappatura (es. DeviceElement)che dagli attributi contenuti in Element.

Esempio1: gli attributi che definiscono le caratteristiche di un’istanza deldispositivo lampada

• name: nome dato all’istanza della Lamp (es. “lampadaCucina”);

• type: tipologia del dispositivo (es. “Lamp”);

• description: descrizione del dispositivo (es. “An artificial source of visibleillumination”);

• notifications: notifiche che il dispositivo genera (StateChangeNotification,generata dalla Lamp a seguito di un cambiamento di stato);

• commands: comandi tramite i quali il gateway governa la lampada (OnCom-mand e OffCommand, comandi per accendere e spegnere la luce);

• states: configurazioni che la lampada puo assumere (OnOffState; tiene trac-cia del fatto che la luce sia accesa oppure spenta);

• networkType: specifica il tipo di tecnologia di rete (“BTicinoNetworkCompo-nent”, “KonnexNetworkComponent”, “EliteNetworkComponent”);

• networkComponent: componente di rete della lampada.

Ogni notifica presente nell’ontologia (classe NotificationElement) puo definireun insieme di parametri (lista params). La notifica PressureMeasurement (generatada un sensore di pressione al fine di segnalare al gateway l’attuale valore della pres-sione), ad esempio, contiene il parametro pressureValue di tipo double nel quale

46


viene inserito il valore di pressione rilevato. I comandi (classe CommandElement),come le notifiche, possono contenere parametri ed avere un valore di ritorno il cuicompito e segnalare al gateway l’esito dell’operazione richiesta. I comandi di query(comandi get) hanno tipicamente un valore di ritorno: ad esempio, le informazionisullo stato del dispositivo vengono fornite nel valore di ritorno del comando getState.Il comando SetCommand, utilizzato dal gateway per impostare la luminosita di unaDimmerLamp, ha un parametro che rappresenta il valore desiderato di intensitaluminosa.

Ogni parametro (classe Param, Figura 5.11) e definito dagli attributi: type, chedescrive il tipo di valore contenuto (integer, string, double, ecc); name, nome delparametro; value, valore assegnato al parametro.

Figura 5.11. Le classi NotificationElement, CommandElement e Param

Gli stati (StateElement) possono assumere valori discreti (discreteValues) ocontinui (continuosValues). OnOffState (che descrive lo stato della Lamp), adesempio, e uno stato che puo assumere solo due valori discreti (“On” e “Off”). Lostato LightIntensityState, che tiene traccia del valore di intensita luminosa di unaDimmerLamp, invece assume valori continui compresi tra 0% ed 100% (percentualedi intensita luminosa).

Le classi StateElement, NotificationElement e CommandElement estendono laclasse Element ereditando gli attributi definiti al suo interno.

Le classi HomeGateway, ControlElement ed ActuatorElement sono specializ-zazioni della classe DeviceElement. HomeGateway (Figura 5.12) modella i networkgateway, punti di accesso ai sistemi domotici contenuti all’interno di un IDE (Intelli-gent Domotic Environment) che permettono la trasmissione dei messaggi specifici diun singolo protocollo (es. Konnex o BTicino) su di una tecnologia di interconnessionepiu versatile (es. Ethernet).

All’interno di questa classe vengono definiti gli attributi di rete, come ad esem-pio ipAddress (indirizzo ip del network gateway) e connectionTrials (numero di

47


Figura 5.12. La classe HomeGateway

tentativi eseguiti dal gateway centrale per instaurare una connessione con il networkgateway), di cui ha bisogno il gateway DOG per comunicare con i network gateway.

La classe ControlElement (Figura 5.13) modella tutti i dispositivi che hannofunzionalita di controllo. Ogni dispositivo controller contiene un riferimento a tuttii dispositivi controllati (lista controlLinks) e la descrizione delle relazioni di con-trollo in cui e coinvolto (controlAttributes). Ogni relazione di controllo vienedescritta mediante la classe ControlProperties, che definisce gli attributi noti-fication (notifica generata dal dispositivo controllore) e command (comando dagenerare al dispositivo controllato). Per ogni relazione di controllo occorre inoltrespecificare il dispositivo controllato (controlledDeviceName).

Figura 5.13. Le classi ControlProperties e ControlElement

Esempio2: relazioni di controllo tra un pulsante ed una lampada. Un pul-sante e in grado di governare l’accensione e lo spegnimento della luce di una lampadamediante 2 relazioni di controllo. La prima contiene l’associazione OnNotification(notifica generata dal pulsante) - OnCommand (comando da inviare alla lampada):OnNotification, generata dal pulsante a seguito di un evento di pressione del pul-sante, comporta la trasmissione di un comando OnCommand alla lampada il cuiscopo e accendere la luce. La seconda e caratterizzata dall’associazione OffNotifica-tion - OffCommand: OffNotification, generata dal pulsante a seguito di un eventodi rilascio del pulsante, comporta la trasmissione di un comando OffCommand allalampada il cui scopo e spegnere la luce. In questo caso e quindi necessario creare 2istanze della classe ControlProperties.

48


La classe ActuatorElement (Figura 5.14) modella tutti i dispositivi attuatori.Ogni attuatore puo essere connesso ad un elemento architetturale (actuatorLink):un DoorActuator, ad esempio, governa l’apertura e la chiusura di una porta.

I dispositivi sensori (SensorElement, Figura 5.14) possono essere sia connessi adun elemento architetturale, sia utilizzati come dispositivi controllori.

Figura 5.14. Le classi ActuatorElement e SensorElement

Esempio3: uso di un sensore come dispositivo controllore. Si consideri unoscenario composto da una porta, una lampada ed un sensore di chiusura e aperturaporta. Quest’ultimo, a seguito della rilevazione dell’apertura della porta, genera uncomando di controllo che accende la luce della lampada. In questo caso sensorLink

e controlLinks contengono rispettivamente i riferimenti all’oggetto porta ed al-l’oggetto lampada (il sensore controlla la lampada). Inoltre in controlAttributes

viene descritta l’associazione di controllo (OpenNotification - OnCommand).

Ogni elemento istanziabile dall’utente nel foglio di lavoro e caratterizzato dal-l’avere almeno una rappresentazione grafica. Nella classe VisualElement (Figura5.15) sono definite quelle proprieta che tengono traccia delle caratteristiche grafichedell’oggetto in questione: icon, riferimento all’icona dell’elemento, xLocation eyLocation, posizione dell’oggetto nel foglio di lavoro, width e height, dimensioni(larghezza ed altezza) dell’oggetto.

Figura 5.15. La classe VisualElement

Ogni elemento contenuto nell’ontologia viene quindi mappato sull’opportunaclasse del DataModel Structure:

49


• dispositivi con capacita di controllo - classe ControlElement;

• dispositivi attuatori - classe ActuatorElement;

• dispositivi sensori - classe SensorElement;

• network level gateway - classe HomeGateway;

• i restanti dispositivi (elettrodomestici, dispositivi appartenenti all’impiantoelettrico, ecc) - classe DeviceElement;

• comandi per governare i dispositivi - classe CommandElement;

• notifiche generate dai dispositivi - classe NotificationElement;

• stati che descrivono le configurazioni dei dispositivi - classe StateElement;

• elementi passivi (arredamento, elementi architetturali) - classe Architec-

turalElement;

• ambienti - classe BuildingArea.

5.3 Generazione del modello dati

La Figura 5.16 mostra la sequenza di operazioni che occorre svolgere al fine digenerare il modello dati dell’applicazione DogDomoticIde sulla base del DataModelStructure e dell’ontologia DogOnt:

1. rappresentazione del DataModel Structure nel formato XMI;

2. generazione delle interfacce annotate (package dataModel.interface) relativeagli elementi dell’ontologia ed alle classi del DataModel Structure;

3. creazione di un modello ECore (mediante EMF) sulla base dell’insieme diinterfacce annotate;

4. modifica del file ecore generato (personalizzazione di alcune proprieta delmodello);

5. auto-generazione del plug-in domoticIde che contiene le classi Java che de-scrivono il modello dati;

6. auto-generazione dei plug-in domoticIde.edit e domoticIde.editor (opzionale)che contengono classi Java di servizio per il modello dati (accesso al modellodati, supporto alle operazioni undo/redo, ecc);

50


Figura 5.16. Workflow per la generazione del modello dati

7. aggiornamento del package dataModel.impl che contiene le classi implemen-tazione delle interfacce contenute in datamodel.Interface.

Di seguito le singole fasi verranno riprese ed analizzate con maggior dettaglio.

5.3.1 Generazione delle interfacce annotate

La generazione delle interfacce annotate prevede la creazione di un’interfaccia Javaper ogni classe del DataModel Structure e per ogni elemento presente nell’ontolo-gia DogOnt. A tal fine e stata costruita l’applicazione InterfaceGenerator, unprogramma Java che richiede come parametri di ingresso l’ontologia DogOnt (nelformato OWL) ed il DataModel Structure (nel formato XMI) e che fornisce come

51


output il package datamodel.interface completo di tutte le interfacce annotate chedefiniscono il modello dati.

Come prima cosa vengono generate le interfacce relative al DataModel Structure.Il formato XMI, in cui tale modello e definito, permette, con relativa semplicita, diottenere la lista delle classi del modello e, per ognuna di esse, di estrarre gli attributie le relazioni di contenimento in cui sono coinvolte. EMF impone che il nome di ogniattributo inizi con “get” e finisca con le parentesi “()” (getter Java): l’attributo namedefinito nella classe Element, ad esempio, viene inserito nella relativa interfaccia Javanella forma: String getName().

Si consideri la relazione di contenimento che rappresenta la capacita di un am-biente di contenere un numero indefinito di dispositivi. Questa caratteristica vienedescritta all’interno dell’interfaccia relativa alla classe BuildingArea mediante ladichiarazione: List 〈DeviceElement〉 getDevicesInside(), dove DeviceElementrappresenta il tipo contenuto (in questo caso dispositivi) e getDevicesInside() ilnome del metodo “getter” che consentira di accedere alla lista di dispositivi.

Le relazioni di ereditarieta che intercorrono tra le classi vengono realizzate medi-ante la keyword Java extends : la linea di codice public interface DeviceEle-

ment extends Element, ad esempio, descrive la relazione di ereditarieta presentetra le interfacce relative agli elementi DeviceElement ed Element.

Le interfacce relative al DataModel Structure vengono costruite sulla base deiprincipi appena descritti. Terminata questa fase l’applicazione InterfaceGenera-tor inizia la generazione delle interfacce che descrivono gli elementi dell’ontologia.Gli elementi appartenenti ad una categoria specifica (ad es. elementi architetturalie di arredamento) vengono estratti dall’ontologia mediante l’uso del liguaggio diquery SPARQL. Per ognuno di essi viene creata un’interfaccia vuota che estendel’opportuna interfaccia del DataModel Structure (gli elementi architetturali e diarredamento estendono l’interfaccia ArchitecturalElement). Questo procedimen-to viene ripetuto per ogni categoria di elementi dell’ontologia: dispositivi, elementipassivi (architetturali ed arredamento), comandi, notiche, ecc. E da evidenziare chela categoria dispositivi richiede una trattazione diversa. Sono infatti necessarie 4query per modellare tutti i dispositivi:

• la prima estrae dall’ontologia tutti i dispositivi attuatori, mappati sull’inter-faccia ActuatorElement;

• la seconda e relativa ai dispositivi controller, mappati sull’interfaccia Con-

trolElement;

• la terza e relativa ai dispositivi sensori, mappati sull’interfaccia SensorEle-

ment;

• la quarta query estrae tutti i dispositivi rimanenti, mappati sull’interfacciaDeviceElement.

52


Nella generazione delle interfacce si fa uso delle seguenti annotazioni:

@model - inserito all’inizio del file, definisce che l’interfaccia contenuta e unelemento del modello dati;

@model containment = ”true” - tag da inserire sopra la dichiarazione delle listeche rappresentano relazioni di contenimento;

@model changeable=”true” - tag da inserire sopra la dichiarazione degli attributiil cui contenuto puo essere modificato.

La Figura 5.17 mostra un esempio di 2 interfacce annotate: la prima (a) e rel-ativa alla classe DeviceElement del DataModel Structure, la seconda (b) descrivel’elemento lampada contenuto nell’ontologia.

(a) (b)

Figura 5.17. Le interfacce DeviceElement e Lamp

Come si puo osservare, l’interfaccia DeviceElement contiene la dichiarazione

53


degli attributi che descrivono tutti i dispositivi. Le liste getStates(), getNoti-fications() e getCommands() descrivono rispettivamente le relazioni di conteni-mento relative a stati, notifiche e comandi. Gli attributi getNetworkProperties()e getNetworkType() sono relativi alla componente di rete associata allo specifi-co dispositivo. DeviceElement, inoltre, estende l’interfaccia Element ereditandonegli attributi. L’interfaccia Lamp ha contenuto vuoto ed eredita gli attributi che ladefiniscono dall’interfaccia DeviceElement.

Il package di interfacce annotate prodotto dall’applicazione InterfaceGenera-tor viene poi fornito come input ad un tool di EMF che produce in uscita il fileecore, necessario per la generazione dei plug-in domoticIde, domoticIde.edit edomoticIde.editor.

5.3.2 Completamento delle classi implementazione

La modifica delle classi contenute nel package dataModel.impl completa la gener-azione del modello dati (Figura 5.16). Ogni classe implementazione generata daEMF contiene la dichiarazione non inizializzata degli attributi che caratterizzanol’elemento corrispondente dell’ontologia. L’applicazione FillImplementation in-serisce in queste classi le istruzioni che inizializzano gli attributi con i loro valorispecifici (qualora siano disponibili).

Per ogni classe implementazione relativa ad un elemento di ontologia (sonoescluse quelle riguardanti il DataModel Structure) vengono eseguite le seguentioperazioni:

1. si analizza il DataModel Structure (formato XMI) per ricavare gli attributi e lerelazioni di contenimento definiti nella super classe (ogni classe relativa ad unelemento di ontologia estende una specifica classe del DataModel Structure);

2. i valori di inizializzazione degli attributi vengono ricavati dall’ontologia (me-diante l’uso del linguaggio SPARQL);

3. all’interno del costruttore della classe si inseriscono le istruzioni che initializ-zano gli attributi e le liste.

La Figura 5.18 mostra il costruttore della classe implementazione relativa al dis-positivo lampada (LampImpl.java) prima (a) e dopo (b) l’esecuzione del programmaFillImplementation. Come si osserva, il costruttore originale generato da EMF con-tiene unicamente il richiamo alla super-classe. L’esecuzione di FillImplementationintroduce un insieme di instruzioni (comprese tra le 2 linee di commento) il cui com-pito e inizializzare gli attributi e le liste con i valori specifici della classe lampadadefinita in DogOnt.

Nel caso mostrato in Figura 5.18 (oggetto lampada), i parametri da inizializzaresono descritti nella classe DeviceElement del DataModel Structure:

54


(a)

(b)

Figura 5.18. Classe implementazione prima e dopo l’esecuzione di FillImplementation

• gli attributi name, type e description vengono inizializzati rispettivamentedalle istruzioni setName(’’Lampada1’’), setType(’’Lamp’’) e setDescrip-tion(’’An artificial source of visible illumination’’);

• la lista states contiene oggetti di tipo StateElement (configurazioni chepuo assumere il dispositivo). La configurazione di una lampada (che puosolo essere accesa o spenta) e descritta dallo stato OnOffState. L’istruzionestates.add(new OnOffStateImpl())) permette di aggiungere a states un’is-tanza della classe OnOffStateImpl (classe implementazione relativa allo statoOnOffState);

• la lista commands contiene i comandi che possono governare il dispositivo.In particolare i comandi OnCommand e OffCommand, descritti dalle classiOnCommandImpl ed OffCommandImpl, permettono di accendere e spegnere laluce della lampada;

55


• la lista notifications contiene le notifiche generate dal dispositivo. Il dis-positivo lampada, a seguito di un cambiamento di stato, provvede a generarela notifica StateChangeNotification (descritta dalla classe StateChangeNoti-ficationImpl).

L’applicazione FillImplementation provvede ad aggiornare anche il construt-tore delle classi OnOffStateImpl (Figura 5.19, super-classe StateElement), On-

CommandImpl, OffCommandImpl e StateChangeNotificationImpl.

Figura 5.19. Classe implementazione relativa allo stato OnOffState

Al termine della fase di completamento delle implementazioni il plug-in domoti-cIde contiene una rappresentazione completa del modello dati sulla quale si baseral’applicazione DogDomoticIde.

5.4 Costruzione dei modelli per GMF

La fase successiva alla costruzione del modello dati consiste nella stesura di 3 ulteri-ori modelli (Graphical Definition Model, Tooling Definition Model e Mapping Def-inition Model), basati sul modello Ecore generato in precedenza e necessari per ladescrizione dell’aspetto grafico e delle funzionalita di base che l’applicazione DogDo-moticIde deve realizzare. Per la stesura di ogni modello, GMF mette a disposizioneil relativo meta-modello (a sua volta e un modello ECore) corredato da un appositoeditor grafico.

56


Figura 5.20. Costruzione dei modelli per GMF

5.4.1 Graphical Definition Model

Questo modello ha lo scopo di contenere la descrizione dell’aspetto e della rappre-sentazione visiva di tutti gli oggetti istanziabili dall’utente nel foglio di lavoro. Perdescrivere le proprieta grafiche di un elemento occorre utilizzare i costrutti NodeDescriptor e Figure Descriptor.

La Figura 5.21 mostra la rappresentazione grafica dell’elemento Computer. Ognioggetto di tipo Computer, istanziato dall’utente nel foglio di lavoro, avra formarettangolare e conterra un’etichetta il cui scopo e visualizzare il nome dell’oggetto.Il Node Descriptor (prima riga) contiene un riferimento al Figure Descriptor

(ComputerFigure, descrizione della composizione grafica dell’elemento Computer) epermette di definire le caratteristiche grafiche di carattere generale.

Figura 5.21. Descrizione grafica del dispositivo Computer

Osservando la figura si puo notare come il Figure Descriptor associato all’ele-mento Computer contenga un oggetto Rectangle che descrive una forma grafica ditipo rettangolare e che consente di definire, al suo interno, gli eventuali oggetti con-tenuti nell’elemento (nell’esempio l’etichetta ComputerNameFigure). Infine Child

Access consente di creare un’associazione tra una proprieta del modello dati edun’etichetta. Nel caso in esempio Child Access permette di visualizzare il nomedell’oggetto (il valore della proprieta name) nell’etichetta ComputerNameFigure.

La rappresentazione grafica descritta e analoga per tutti gli altri elementi estrat-ti dall’ontologia DogOnt. Per ognuno di essi e quindi necessario istanziare questicostrutti al fine di definirne l’aspetto grafico come appena descritto. Fanno eccezionele rappresentazioni delle relazioni di interazione e dell’elemento Flat (appartamen-to). Le relazioni di interazione tra dispositivi vengono rappresentate mediante col-legamenti, cioe oggetti grafici filiformi che connettono i dispositivi interessati dallarelazione. Sulla base della tipologia di relazione vengono definiti 3 tipologie di link:

57


• Control Link : rappresenta graficamente una relazione di controllo tra dueoggetti (es. interruttore → lampada del salotto);

• Actuator Link : rappresenta una relazione tra un oggetto attuatore ed un el-emento architetturale dell’abitazione (es. attuatore per la porta → porta delsalotto);

• Sensor Link : rappresenta una relazione tra un oggetto sensore ed un elementoarchitetturale dell’abitazione (es. sensore per la porta → porta del salotto).

La descrizione grafica dei link richiede l’utilizzo del Connection Descriptor (alposto di Node Descriptor) e la definizione, all’interno del relativo Figure De-

scriptor, della forma Polyline Connection che consente di rappresentare il linkcome un segmento di retta dotato di indicatore di direzione (freccia).

Figura 5.22. Descrizione grafica del ControlLink

Ogni tipologia di link viene associata ad un colore: i ControlLink, gli Actua-torLink ed i SensorLink sono rispettivamente rappresentati dai colori verde, rossoe blu. L’elemento appartamento (Flat) viene rappresentato come contenitore dioggetti (mediante il costrutto Compartment): costituisce l’ambiente all’interno delquale il progettista puo creare camere ed istanziare gli elementi che compongonol’impianto domotico. La Figura 5.23 mostra un esempio del risultato prodotto dallarappresentazione grafica descritta nel Graphical Definition Model.

Figura 5.23. Rappresentazione grafica risultante

58


All’interno di un appartamento (Flat1) sono stati inseriti 2 oggetti (un bottone eduna lampada) legati da una relazione di controllo (link verde) e dotati di un’etichettache ne visualizza il nome (“pulsanteLuce” e “luce”).

5.4.2 Tooling Definition Model

Questo modello contiene la descrizione della Palette View, strumento che permetteall’utente dell’applicazione DogDomoticIde di accedere alla libreria dei componenti edi selezionare l’elemento che desidera istanziare nel foglio di lavoro. Anche in questocaso il relativo meta-modello definisce i costrutti di base. Il nodo radice, Palette,definisce la Palette View mentre gli elementi inseriti al suo interno descrivono l’or-ganizzazione e l’aspetto delle voci contenute nella palette. Il costrutto Tool Group

consente la creazione di raggruppamenti di voci (contenitore grafico). La Figura5.24 mostra la descrizione del ToolGroup relativo agli elementi architetturali chel’utente puo inserire nel suo progetto (Door, Entrance, Gate, Shutter e Window).Ogni elemento istanziabile dall’utente deve essere descritto da un Creation Tool,che inserisce una voce nella palette abilitando l’utente ad istanziare quello specificoelemento all’interno del foglio di lavoro. Ogni Creation Tool puo contenere i rifer-imenti a 2 immagini, rispettivamente di dimensioni 32x32 e 64x64 pixel, utilizzatedall’applicazione come icona per la relativa voce della palette.

Figura 5.24. Costruzione della palette degli oggetti

Nel file gmftool utilizzato per la descrizione della palette di DogDomoticIde sonostati utilizzati 9 ToolGroup (Architectural, Furniture, Electrical System, HomeGate-way, Sensor, Actuator, Control, BuildingTool e Link) ognuno dei quali contiene icostrutti Creation Tool relativi ad una specifica categoria di elementi.

59


5.4.3 Mapping Definition Model

Per ogni elemento istanziabile dall’utente, il Mapping Definition Model consentedi realizzare la mappatura tra il relativo Creation Tool, definito all’interno delfile gmftool, la rappresentazione grafica, descritta nel file gmfgraph, e la classe delmodello dati che ne descrive le proprieta.

Il Mapping Definition Model viene utilizzato dal generatore di codice di GMFper creare le classi EditPart, componenti principali di un’applicazione GEF il cuicompito e unire nello stesso oggetto software le figure Draw2D che definiscono larappresentazione grafica dell’elemento e la classe del modello dati che ne descrive leproprieta. Il Mapping Definition Model permette di definire il comportamento dellaPalette View in maniera tale che ogni sua voce consenta all’utente di istanziare unospecifico oggetto EditPart all’interno del foglio di lavoro.

L’esempio in Figura 5.25 mostra il mapping relativo all’elemento poltrona (Arm-Chair). Le proprieta del mapping che occorre definire sono Element, Diagram Node

e Tool che rispettivamente contengono i riferimenti alla classe del modello dati, alNode Descriptor ed al Creation Tool della palette.

Figura 5.25. Mapping dell’elemento ArmChair

Una volta definito l’apposito mapping, il codice generato da GMF permetteraall’utente di istanziare, a seguito della selezione della voce della palette associataal Creation Tool Armchair, una EditPart relativa all’elemento poltrona, rappre-sentata graficamente dalla figura ArmchairFigure e modellata dalla classe Armchairdel modello dati.

La descrizione del mapping dei link avviene attraverso l’uso del costrutto Link

Mapping. Per ogni tipologia di collegamento (Control Link, Actuator Link e Sen-sor Link) viene inserito un Link Mapping nel quale occorre specificare le proprieta

60


Diagram Link, Tool e Target Feature. Le prime 2 contengono rispettivamente iriferimenti al Connection Descriptor ed al Creation Tool tramite il quale l’u-tente puo creare un link. Target Feature specifica, invece, quali elementi sonocollegabili da una tipologia di link:

• Control Link: Target Feature deve essere impostato in maniera tale che l’ele-mento sorgente del collegamento sia un dispositivo controllore (ControlElement)e la destinazione un dispositivo qualunque (DeviceElement);

• Actuator Link: la sorgente del collegamento e un dispositivo attuatore (ActuatorElement)e la destinazione un elemento architetturale (ArchitecturalElement);

• Sensor Link: la sorgente del collegamento e un dispositivo sensore (SensorElement)e la destinazione un elemento architetturale (ArchitecturalElement).

5.5 Generazione dell’editor

I 3 modelli costruiti vengono forniti come input ad un tool di GMF che produce inuscita il Generator Model.

Figura 5.26. Generazione dell’editor

Il Generator Model:

1. unisce e riassume quanto definito nei modelli Graphical Definition Model, Tool-ing Definition Model e Mapping Definition Model. In particolare, per ognielemento descritto vengono generate le informazioni ed i riferimenti necessarialla costruzione della relativa classe EditPart (EditPolicy, comandi, classedel modello dati, rappresentazione grafica, ecc);

61


2. definisce la Palette View, la Design View e la Property View e descrive inoltrei contenuti dei menu dell’applicazione.

Infine il generatore di codice di GMF, sulla base del Generator Model, produce ilplug-in domoticIde.diagram, che implementa un applicazione editor per il modellodati descritto nei plug-in domoticIde e domoticIde.edit. L’applicazione, che nel casodi questa tesi assume il nome DogDomoticIde (Figura 5.27) fornira un’interfacciagrafica dotata delle seguenti finestre:

• Palette View: punto di accesso alla libreria dei componenti inseribili nel pro-getto;

• Design View: foglio di lavoro dentro il quale e possibile istanziare gli elementicontenuti nella palette e, quindi, descrivere un impianto domotico;

• Property View: permette all’utente di effettuare l’editing delle proprieta deglioggetti istanziati nel foglio di lavoro. E composta da 2 finestre organizzate intab:

– Appearance: permette la visualizzazione e la modifica dell’aspetto visivodell’oggetto selezionato nel foglio di lavoro (es. font del testo);

– Core: tabella organizzata in 2 colonne: la prima elenca tutti gli attributi(dichiarati nel modello dati) dell’oggetto selezionato. La seconda colonnavisualizza il valore di tali attributi e ne permette la modifica.

• Outline View: visione dall’alto della Design View.

Infine vengono generati e messi a disposizione dell’utente i seguenti menu:

• File, contiene le voci per la gestione dei file di progetto (new, open, close, ecc);

• Edit, fornisce le operazioni di cut, copy, paste, undo e redo;

• Diagram, per la personalizzazione dell’aspetto degli oggetti;

• Window, consente di aprire una nuova istanza dell’applicazione;

• Help, contiene informazioni generali sull’applicazione (es. Version).

62


Figura 5.27. Screenshot dell’applicazione DogDomoticIde versione base, cioe ot-tenuta mediante generazione automatica

63

Capitolo 6

Implementazione

Questo capitolo descrive le operazioni di integrazione ed estensione dell’applicazioneDogDomoticIde, auto-generata da GMF, necessarie al fine di supportare i requisitifunzionali primari per essa definiti (vedi cap. 3).

6.1 Architettura logica di DogDomoticIde

La Figura 6.1 mostra le interazioni che intercorrono tra i principali componentidell’applicazione DogDomoticIde. La Palette View rappresenta il punto di accessoalla libreria dei componenti (modello dati) e permette all’utente di istanziare oggetti,di tipo EditPart, all’interno della Design View (o foglio di lavoro).

Figura 6.1. Architettura logica di DogDomoticIde

64

6 – Implementazione

La selezione di un oggetto creato nel foglio di lavoro comporta l’aggiornamentodel contenuto della finestra delle proprieta. La Property View, infatti, visualizza epermette la modifica delle proprieta dell’oggetto selezionato. Le modifiche effettuateagli attributi di un oggetto vengono registrate nella relativa EditPart.

Lo scopo della fase di implementazione e quello di intervenire in questa architet-tura al fine di:

• introdurre nuovi componenti:

– la Summary View, vista ad albero il cui scopo e visualizzare un riepilogodegli oggetti istanziati nel progetto;

– il modulo BuildFile, per la costruzione di documenti di configurazioneinstallabili direttamente sul gateway DOG.

• potenziare le parti generate da GMF. In particolare si agira:

– sulla Design View, per incrementare le funzionalita di editing grafico for-nite all’utente, ad esempio fornendo il supporto all’auto-rilevazione dellestanze presenti in un appartamento mediante l’algoritmo RoomDetection;

– sulla Property View, al fine di renderla adatta all’editing delle proprietadomotiche degli oggetti istanziati nel foglio di lavoro: l’organizzazione atabella fornita dal tab Core risulta infatti inadeguata per la descrizionedelle relazioni di interazione e dei componenti di rete. Vengono quindi im-plementate ed aggiunte alla Property View le finestre CommonProperties,Network, NetworkGateway, ControlRelation e RelationsSummary ;

– sulle classi EditPart, al fine di implementare le interazioni tra le stessee la Summary View. Le operazioni di creazione, modifica o distruzionedi oggetti EditPart (nel foglio di lavoro) devono, infatti, essere segnalatealla Summary View affinche possa aggiornare il proprio contenuto.

6.2 La gestione degli ambienti stanza

Le funzionalita fornite dall’applicazione generata da GMF consentono all’utente diistanziare, all’interno del foglio di lavoro, uno o piu appartamenti, nei quali e pos-sibile posizionare gli oggetti che definiscono l’impianto domotico. Questo approccionon e completo in quanto, normalmente, un oggetto assume una posizione all’internodi una stanza, la quale e parte di un appartamento.

Al fine di introdurre il concetto di “stanza” nell’applicazione DogDomoticIdesono state valutate 2 possibili soluzioni. La prima consiste nel modellare, all’internodei modelli Graphical Definition Model e Mapping Definition Model (sezione 5.4),

65


l’elemento appartamento come contenitore di stanze (Room, Kitchen, BedRoom,ecc) che, a loro volta, vengono descritte come contenitori di oggetti (dispositivi,arredamento, ecc). In questo caso l’utente dell’applicazione deve provvedere alla:

1. creazione di oggetti appartamento;

2. creazione, all’interno di ogni appartamento, di uno o piu oggetti stanza;

Questa soluzione, che ha il vantaggio di essere facilmente implementabile (bastaimpostare correttamente i modelli e poi GMF provvede alla generazione automaticadel codice), pone delle forti limitazioni di editing: siccome la forma grafica di base diogni elemento istanziabile e di tipo rettangolare, l’utente puo istanziare solo stanzedi quella forma.

Si e quindi deciso di adottare una soluzione alternativa nella quale una stanza econcepita come un’area chiusa delimitata da un insieme di muri. Mediante questoprincipio la progettazione della struttura di un ambiente domotico consiste nel:

1. istanziare uno o piu oggetti appartamento;

2. istanziare e posizionare uno o piu muri all’interno dell’appartamento in mododa strutturare l’ambiente nella maniera desiderata. Le aree chiuse delimitatedai muri sono le stanze dell’appartamento.

Questa strategia fornisce all’utente un maggior grado di liberta nella costruzionedelle stanze: la forma di una stanza dipende dalla configurazione dei muri istanziati(Figura 6.2b). Tuttavia occorre tener presente che GMF consente la creazione dioggetti muro di forma rettangolare, orientati orizzontalmente o verticalmente. None quindi possibile, ad esempio, creare stanze di forma circolare (in quanto non epossibile istanziare muri concavi).

(a) (b)

Figura 6.2. Esempio di struttura di due ambienti appartamento

66


Ogni appartamento viene creato con i “muri di confine”, muri posizionati lungoil perimetro dell’appartamento stesso che, in assenza di altri elementi architetturali,delimitano una stanza (Figura 6.2a).

L’algoritmo RoomDetection garantisce l’auto-rilevazione delle stanze presenti inun appartamento (in relazione alla configurazione di muri presente). Per ognunadi esse viene istanziato automaticamente un oggetto RoomEditPart che permetteall’utente di modificare (tramite la Property View) le proprieta della stanza cherappresenta (nome e tipologia di stanza).

6.2.1 L’algoritmo RoomDetection

Lo scopo dell’algoritmo RoomDetection e individuare il numero, la posizione e laforma delle stanze presenti in un appartamento la cui struttura rispetta i seguentivincoli architetturali:

• muri di forma rettangolare, orientati orizzontalmente o verticalmente rispettoal piano di lavoro;

• “rete” di muri connessa: ogni muro presente nell’appartamento deve essereconnesso, direttamente o indirettamente, a tutti gli altri muri (interni o diconfine). La Figura 6.3 mostra un esempio di rete di muri connessa (a) e nonconnessa (b);

• sezione dei muri di confine di dimensione fissa.

(a) (b)

Figura 6.3. Muri connessi e non connessi

Nel seguito verra descritto il funzionamento dell’algoritmo (Figura 6.4) e, par-allelamente, sara trattato un caso di studio (Figura 6.5) al fine di semplificare lacomprensione dell’algoritmo stesso.

67


Figura 6.4. Struttura dell’algoritmo RoomDetection

Figura 6.5. Caso di studio: appartamento dotato di un muro centrale

La descrizione della struttura dell’ambiente

Ogni muro (di confine o interno) istanziato all’interno di un appartamento deveessere descritto in termini di posizione (rispetto ai bordi dell’appartamento) e di di-mensione (larghezza, altezza). Tali informazioni (espresse in pixel) vengono inseritenella struttura dati wallList e fornite come input all’algoritmo. Nel caso in esame(Figura 6.5) le coordinate che descrivono i muri sono:

• muri di confine:

1. posizione (x, y)=(0, 0), dimensioni (width, height)=(99, 6);

2. (x, y)=(0, 0), (width, height)=(6, 48);

3. (x, y)=(93, 0), (width, height)=(6, 48);

4. (x, y)=(0, 42), (width, height)=(99, 6);

• muro interno: (x, y)=(48, 0), (width, height)=(3, 48).

68


La ricerca delle aree di intersezione

La prima fase di esecuzione dell’algoritmo consiste nella ricerca delle aree di inter-sezione.

Algorithm 1 La ricerca delle aree di intersezione

for all wall1 in wallList dofor all wall2 in wallList doif wall1 /= wall2 thenintersectionArea = wall1 X wall2if intersectionArea /= void thenintersectionList.add(wall1,intersectionArea)

end ifend if

end forsort(intersectionList,wall1)

end for

Viene eseguita l’intersezione geometrica tra tutti i muri descritti nella wallList

(intersectionArea = wall1 X wall2). Nel caso in esame l’intersezione tra i muridi confine 1 e 2 permette di individuare l’area di intersezione A, analogamente l’in-tersezione tra il muro 1 ed il muro interno genera l’area B e cosı via. Da notare chenon tutte le intersezioni eseguite individuano aree di intersezione: i muri 1 e 4, adesempio, non si incrociano e quindi la loro intersezione non produce alcun risultato.Infine le aree di intersezione di ogni muro vengono ordinate in relazione alla loroposizione (metodo sort). In particolare se il muro in esame e di tipo orizzontale learee di intersezione individuate vengono ordinate da sinistra verso destra (rispetto alfoglio di lavoro). Se il muro e orientato verticalmente le aree di intersezione vengonoordinate dall’alto verso il basso.

La Figura 6.6 mostra il contenuto della struttura dati intersectionList, risul-tato di questa prima fase di esecuzione.

Figura 6.6. La struttura dati intersectionList

69


La ricerca delle aree contigue

L’algoritmo provvede a ricavare le aree contigue ad ogni area di intersezione trovatain precedenza.

Algorithm 2 La ricerca delle aree contigue

for all wall1 in wallList dofor all intersectionArea in intersectionList(wall1) doif intersectionMap.isPresent(intersectionArea) = false thenneighborAreaList = getNeighbor(intersectionArea)intersectionMap.add(intersectionArea,neightborAreaList)

end ifend for

end for

La procedura getNeighbor, sulla base del contenuto di intersectionList, resti-tuisce la lista delle aree contigue ad una specifica area di intersezione. Le associ-azioni “area di intersezione - aree contigue” vengono poi registrate nella strutturadati intersectionMap. Il metodo isPresent restituisce il valore “true” nel casoin cui l’area di intersezione che si sta valutando sia gia stata descritta in inter-

sectionMap. Si considerino, ad esempio, le 2 occorrenze dell’area A contenute inintersectionList. La prima (relativa al muro1) determina la ricerca delle aree con-tigue all’area A, la seconda (relativa al muro2) non viene considerata in quanto talearea e gia stata valutata in passato (isPresent restituisce “true”). La Figura 6.7mostra il contenuto della struttura dati interceptionMap relativamente all’esempioin esame.

Figura 6.7. La struttura dati intersectionMap

70


La ricerca delle stanze

Si procede con la ricerca delle stanze presenti nell’appartamento. Questo compitoviene demandato alla procedura ricorsiva detectRooms che individua le stanze sullabase del contenuto della struttura dati intersectionMap.

Algorithm 3 La procedura detectRooms

procedure detectRooms(previousArea,currentArea)if contain(graphSearch,currentArea) thencycle=takeCycle(graphSearch,currentArea)checkAndRecordRoom(cycle)return

end ifif graphSearch.size() ≤ MAX INTERSECTION POINT thengraphSearch.add(currentArea)neighborAreaList = intersectionMap.get(currentArea)for all nextArea in neighborAreaList doif previousArea /= nextArea thendetectRooms(currentArea,nextArea)

end ifend forgraphSearch.remove(currentArea)

end ifend procedure

Il principio sul quale si basa questa procedura e quello di immaginare le areedi intersezione ottenute in precedenza come nodi di un grafo, ognuno dei quali econnesso ai suoi nodi contigui (Figura 6.8).

Figura 6.8. Esempio di grafo di aree di intersezione

Ad ogni iterazione si procede con la visita in profondita di questo grafo: e possi-bile “muoversi” su un nodo direttamente connesso al nodo in esame. Il nodo A, ad

71


esempio, consente di “spostarsi” sui nodi B o F che, a loro volta, consentiranno divisitare ulteriori nodi.

La struttura dati intersectionMap risulta quindi essenziale per la visita delgrafo in quanto fornisce la lista dei nodi raggiungibili da ogni nodo.

Si considera come nodo di partenza la prima area di intersezione descritta inintersectionMap (nel caso in esame il nodo A, currentArea=A). Tale nodo vieneprima inserito nella lista graphSearch (che tiene traccia dei nodi attraversati dal-la procedura detectRooms) e poi utilizzato per ottenere da intersectionMap inodi contigui che possono essere visitati. Per ognuno di essi (nextArea) vienericorsivamente invocata la procedura detectRooms.

La costante MAX INTERSECTION POINT (impostata al valore 20) rappresenta illimite di profondita oltre il quale viene interrotta la visita del grafo.

La procedura detectRooms richiede 2 parametri: previousArea, relativo al nodovisitato nell’iterazione precedente e currentArea, che descrive il nodo che si sta con-siderando nell’iterazione corrente. Per comprendere l’uso di entrambi si considerinole seguenti 2 iterazioni:

1. iterazione 0:

• nodo di inizio = A (currentArea=A);

• previousArea=void;

• graphSearch={A};• neightborAreaList={B, F};• nextArea=B.

2. iterazione 1:

• currentArea=B;

• previousArea=A;

• graphSearch={A, B};• neightborAreaList={A, E, C};• nextArea=E.

La nextArea e la currentArea dell’iterazione i diventano rispettivamente lacurrentArea e la previousArea dell’iterazione i+1. La previousArea tiene tracciadel nodo visitato nell’iterazione i con lo scopo di poterlo escludere dai nodi visitabilinell’iterazione i+2. Nell’iterazione 1, ad esempio, la previousArea consente diescludere il nodo A come prossimo nodo da visitare (in quanto si e arrivati da A).

La rilevazione di un ciclo nella visita del grafo (si vuole visitare un nodo chee gia stato attraversato in passato) e la condizione necessaria che puo condurre

72


all’individuazione di una stanza. All’inizio di ogni iterazione il metodo contain

verifica se graphSearch contiene il nodo che deve essere visitato (currentArea). Incaso di esito positivo il metodo takeCycle estrae da graphSearch la sequenza diaree di intersezione che definiscono il ciclo. Infine il vettore cycle viene validato dalmetodo checkAndRecordRoom che provvede, eventualmente, alla sua registrazionenella struttura dati roomList.

I cicli individuati dalla procedura detectRooms nel caso in esame (Figura 6.5)sono:

1. cycle={A, B, E, F};

2. cycle={E, D, C, B};

3. cycle={E, D, C, B, A, F}

I primi 2 risultano validi e definiscono le stanze caratterizzate rispettivamentedai vertici {A, B, E, F} ed {E, D, C, B}. Il terzo ciclo non puo essere consideratouna stanza valida in quanto “contiene” le altre 2 trovate in precedenza.

In generale ogni ciclo viene validato in relazione a tutte le stanze registrate inprecedenza:

• se i vertici contenuti in cycle definiscono un area che “contiene” almeno unadelle stanze registrate nella roomList allora tale ciclo viene scartato (stanzacontenitore, caso 3);

• vengono rimosse dalla roomList le stanze che “contengono” l’area definita daivertici presenti in cycle (stanza contenuta). Si supponga, ad esempio, che ilciclo 3 venga individuato per primo. In questo caso la sequenza {E, D, C, B, A,F} viene prima inserita nella roomList e poi, a seguito delle altre rilevazioni,rimossa dalla stessa struttura dati.

Il risultato prodotto dall’esecuzione dell’algoritmo RoomDetection e la lista room-List che contiene la descrizione delle camere trovate.

Implementazione

Le funzionalita fornite dall’algoritmo RoomDetection vengono sfruttate da DogDo-moticIde per la costruzione e l’aggiornamento degli oggetti stanza a seguito delleseguenti operazioni di editing effettuate dall’utente nel foglio di lavoro:

• creazione, ridimensionamento e traslazione (nel foglio di lavoro) di oggettiappartamento;

• creazione, modifica (posizione o dimensione) e rimozione di muri.

73


Figura 6.9. Stanze individuate dall’algoritmo RoomDetection

RoomDetection viene implementato all’interno dell’omonima classe RoomDetectionche offre, come interfaccia verso l’esterno, i seguenti metodi pubblici:

• setBorder(x, y, width, height, wall size): metodo che inizializza l’ogget-to RoomDetection con le informazioni riguardanti la posizione e le dimen-sioni dell’appartamento sul quale verra eseguito l’algoritmo di rilevazione dellestanze. Il parametro wall size descrive la dimensione della sezione dei muridi confine dell’appartamento (nell’esempio in Figura 6.5, wall size=6);

• addWall(wall): metodo che permette di aggiungere un muro alla wallList

sulla quale opera l’algoritmo. Comporta l’aggiornamento delle strutture datisulle quali opera l’algoritmo (intersectionList, intersectionMap);

• removeWall(wall): permette la rimozione di un muro dalla wallList conconseguente aggiornamento delle altre strutture dati;

• updateWall(old wall, new wall): segnala che un muro ha cambiato po-sizione o dimensioni. I 2 parametri contengono rispettivamente la versionevecchia e nuova del muro;

• setTraslation(dx,dy): segnala che l’appartamento e stato spostato (nelfoglio di lavoro) delle quantita dx (orizzontale) e dy (verticale) rispetto allasua posizione precedente;

74


• getRooms(): comporta l’esecuzione della procedura detectRooms e restituisceun riferimento alla lista roomList.

6.2.2 Integrazione dell’algoritmo RoomDetection nell’appli-cazione DogDomoticIde

Per integrare l’algoritmo RoomDetection nell’applicazione DogDomoticIde sono statevalutate 2 possibili soluzioni:

1. costruzione/aggiornamento automatico delle stanze a seguito di ogni oper-azione di modifica della struttura dell’ambiente effettuata dall’utente.

• Vantaggi: costruzione/aggiornamento delle stanze trasparente per l’u-tente;

• Svantaggi: elevato costo computazionale (ogni modifica effettuata allastruttura dell’ambiente comporta l’esecuzione di RoomDetection).

2. costruzione/aggiornamento delle stanze solo su comando esplicito dell’utente.

• Vantaggi: basso costo computazionale (esecuzione di RoomDetection solosu richiesta dell’utente);

• Svantaggi: l’utente deve gestire la costruzione e l’aggiornamento dellestanze.

Sperimentalmente e stato dimostrato che il primo approccio risulta il miglioredal punto di vista dello user-experience. Per sopperire alla problematica del costocomputazionale si e agito sull’algoritmo RoomDetection in modo tale da garantireuna sua convergenza in tempi accettabili.

La costruzione di un appartamento da parte dell’utente comporta la creazionedell’oggetto roomService, istanza della classe RoomDetection che fornisce l’accessoa tutti i metodi descritti sopra. In particolare viene eseguito il metodo setBorder

che inizializza l’oggetto roomService con la posizione (relativa al foglio di lavoro) ele dimensioni dell’appartamento appena creato (Figura 6.10).

Un appartamento puo inoltre essere ridimensionato o spostato dall’utente al-l’interno del foglio di lavoro (traslato). Nel primo caso roomService viene re-inizializzato con le nuove dimensioni (metodo setBorder), nel secondo caso si pro-cede con l’esecuzione del metodo setTraslation.

Un muro puo essere istanziato, spostato, ridimensionato e rimosso. Tali oper-azioni vengono gestite rispettivamente dai metodi addWall, updateWall (i 2 parametricontengono, rispettivamente, la descrizione del muro prima e dopo la modificaeffettuata) e removeWall.

75


Figura 6.10. Integrazione dell’algoritmo RoomDetection in DogDomoticIde

Tutti i metodi descritti sinora hanno lo scopo di aggiornare le strutture datisulle quali si basa l’algoritmo RoomDetection: la creazione, la rimozione, lo sposta-mento ed il ridimensionamento di un appartamento o dei muri in esso contenutideterminano l’insorgere (o la rimozione) di aree di intersezione.

Tutte le operazioni di editing svolte dall’utente su muri ed appartamenti portano,infine, all’invocazione del metodo updateRooms (Figura 6.10), definito nella classeFlatEditPart (EditPart relativa all’elemento appartamento) al fine di:

• ricavare la lista delle stanze presenti nell’appartamento (esecuzione del metodoroomService.getRooms());

• aggiornare la struttura dati builtRoom che contiene le associazioni tra le de-scrizioni delle stanze fornite da getRooms() e le RoomEditPart, oggetti che

76


rappresentano graficamente le stanze presenti nell’appartamento permettendoall’utente di visualizzare e modificare le proprieta delle stesse.

Nella prima esecuzione del metodo updateRooms (quando viene creato l’appar-tamento) si procede con l’inserimento in builtRoom di una voce per ogni stanzadescritta nella struttura dati roomList (risultato dell’invocazione del metodo get-

Rooms). Nelle esecuzioni successive alla prima (a seguito di operazioni di editingeffettuate dall’utente) l’obiettivo di updateRooms diventera quello di aggiornare ilcontenuto di builtRoom in relazione alla nuova configurazione di stanze presenti nel-l’appartamento. In questo contesto mantenere le voci della builtRoom che, a seguitodi modifiche strutturali dell’ambiente, sono ancora valide risulta molto importante:permette di conservare i riferimenti agli oggetti RoomEditPart dentro i quali sonomemorizzati i valori che l’utente ha assegnato agli attributi (nome e tipologia distanza).

Figura 6.11. Aggiornamento della struttura dati builtRoom

Si consideri l’esempio mostrato nella Figura 6.11. Inizialmente l’appartamen-to contiene 2 stanze (CAMERA1 e CAMERA2 ). L’introduzione di un ulterioremuro determina l’invocazione dei metodi addWall ed updateRooms con lo scopo diaggiornare il contenuto di builtRoom. In particolare viene eseguita l’intersezionetra le informazioni ottenute dal metodo getRooms (lista roomList che contiene ladescrizione delle nuove camere) e la struttura dati old builtRoom (che descrive laconfigurazione delle stanze prima dell’inserimento dell’ultimo muro). Questa oper-azione permette di riconoscere le stanze descritte nella old builtRoom che risultano

77


ancora valide a seguito delle modifiche effettuate dall’utente. In questo caso l’intro-duzione del nuovo muro mantiene inalterata la CAMERA2 con la conseguenza chela relativa voce viene copiata nella nuova builtRoom. Per ogni nuova stanza (pre-sente nella lista roomList e non nella struttura dati old builtRoom) viene aggiuntauna voce nella builtRoom (nel caso in esame vengono create le voci per le camere 3e 4).

6.3 La Summary View

La Summary View e una vista ad albero che tiene traccia di tutti gli oggetti istanziatidall’utente nel foglio di lavoro.

Figura 6.12. La Summary View

L’organizzazione gerarchica dei nodi che compongono l’albero (Figura 6.13) tieneconto delle naturali relazioni di contenimento che intercorrono tra i vari oggettiistanziati nel foglio di lavoro:

• livello 0: definisce il nodo Home, radice dell’albero che rappresenta il contenutodel foglio di lavoro (un abitazione);

• livello 1: contiene i nodi relativi agli appartamenti introdotti dall’utente nelfoglio di lavoro;

• livello 2: organizza gli elementi che definiscono la struttura di ogni appar-tamento (camere, muri, porte e finestre). A tal fine vengono introdotti stati-camente, come successori di ogni nodo appartamento, i nodi Rooms, Walls,Doors e Windows, che sono “contenitori” di altri elementi: ogni muro inseritonel foglio di lavoro comporta l’aggiunta di un nodo Wall successore di Walls.Analogo discorso per i nodi Rooms, Doors e Windows che rispettivamente hannocome successori i nodi relativi alle stanze, alle porte ed alle finestre presen-ti nell’ambiente. Organizzare gli elementi mediante questi 4 nodi consenteall’utente di avere una visione ordinata del contenuto dell’albero;

78


• livello 3: contiene i nodi successori dei nodi Rooms, Walls, Doors e Windows.E quindi composto dai nodi che descrivono le stanze, i muri, le porte e lefinestre;

Figura 6.13. Struttura della Summary View

• livello 4: definito solo per i nodi che descrivono gli oggetti contenuti all’internodi ogni stanza (dispositivi, arredamento, ecc). Per ogni oggetto istanziatodall’utente (che non sia un muro, una finestra o una porta) viene inseritonell’albero un nodo successore al nodo che rappresenta la stanza che contienel’oggetto stesso.

6.3.1 Aggiornamento della Summary View

Il contenuto della Summary View deve essere aggiornato in relazione alle operazionidi editing effettuate dall’utente nel foglio di lavoro:

• la creazione di un oggetto comporta l’aggiunta di un nodo nell’albero;

• l’eliminazione di un oggetto comporta la rimozione del relativo nodo dall’al-bero;

79


• lo spostamento di un oggetto da una stanza all’altra comporta lo spostamentodel relativo nodo dell’albero (in maniera tale che sia sempre successore delnodo che descrive la stanza che lo contiene).

Nel seguito sara trattato nel dettaglio l’aggiornamento della Summary View con-seguente alla creazione di un oggetto nel foglio di lavoro.

Aggiunta di un nodo nella Summary View

Algorithm 4 La procedura addNode

procedure addNode(object,builtRoom)objectNode=createNode(object)if object isA Flat thentreeRoot.addChild(objectNode)

elseflatNode=searchNode(treeRoot,object.getFlat().getName())if object isA Wall OR object isA Door OR object isA Window OR object isARoom thensaveStructuralNode (flatNode,objectNode)

elseroomObject= searchRoom(builtRoom,object)roomNode=searchNode(flatNode,roomObject.getName())roomNode.addChild(objectNode)

end ifend ifend procedure

La procedura addNode (definita nella Summary View) provvede alla creazionedi un nodo relativo all’oggetto istanziato (metodo createNode) ed al suo successivoposizionamento all’interno dell’albero. I parametri object e builtRoom contengonorispettivamente i riferimenti all’oggetto creato nel foglio di lavoro (EditPart) edalla struttura dati che descrive le camere presenti nell’appartamento.

Un nodo appartamento viene inserito come successore del nodo radice (House).Per tutte le altre tipologie di oggetti occorre individuare il nodo relativo all’appar-tamento che “contiene” l’oggetto istanziato. A tal fine viene invocato il metodosearchNode, che provvede alla ricerca del nodo il cui nome e indicato nel suo secon-do parametro (object.getFlat().getName() fornisce il nome dell’appartamentodentro il quale e stato istanziato object). Tale ricerca viene effettuata a partire dalnodo specificato nel primo parametro (treeRoot, radice dell’albero).

Il metodo saveStructuralNode provvede a posizionare i nodi relativi a muri,porte, finestre e stanze rispettivamente come successori dei nodi Walls, Doors,

80


Windows e Rooms che, a loro volta, sono figli del nodo appartamento (flatNode)individuato in precedenza.

Per posizionare i nodi relativi agli oggetti contenuti nelle stanze (arredamento,dispositivi) occorre:

1. individuare la stanza che contiene l’oggetto: il metodo searchRoom svolgeun’analisi della struttura dati builtRoom allo scopo di individuare la stanzache contiene l’oggetto in esame (in relazione alla sua posizione);

2. individuare il nodo che descrive l’oggetto stanza trovato in precedenza. Talericerca viene effettuata nel sotto albero che ha come radice il nodo flatNode

(searchNode(flatNode,roomObject.getName());

3. aggiungere il nodo che descrive l’oggetto (objectNode) come successore delnodo stanza individuato (roomNode).

6.3.2 Aspetto e funzionalita della Summary View

L’esempio in Figura 6.14 mostra l’aspetto tipico della Summary View. Un apparta-mento (“Appartamento1”) e composto da 2 stanze (“Camera da letto” e “Cucina”),contenitori di un letto matrimoniale (“Letto matrimoniale”) ed un frigorifero (“Frig-orifero”). I nodi Walls, Doors e Windows contengono i nodi relativi al muro “Wall1”,alla porta “Porta cucina” ed alla finestra “Finestra cucina”.

Figura 6.14. Esempio di SummaryView

L’aspetto grafico di ogni nodo e composto da un icona, dal nome e dal tipobase dell’oggetto. Fanno eccezione i nodi Rooms, Walls, Doors e Windows che,essendo dei contenitori, vengono rappresentati da un icona e dal nome del nodo.La Summary View fornisce funzionalita di ricerca degli oggetti: la selezione di un

81


nodo dell’albero (con un doppio click del mouse) comporta la selezione del relativooggetto nel foglio di lavoro. Tale interazione viene realizzata mediante l’invocazionedel metodo setFocus() (fornito da GMF) sull’oggetto EditPart relativo al nodoselezionato.

6.4 Modifica della Property View

La modifica della Property View consiste nell’aggiunta, all’interno della stessa,dei tab CommonProperties, Network, NetworkGateway, ControlRelation e Relation-sSummary.

Figura 6.15. Modifica della Property View

6.4.1 Il tab CommonProperties

Questo tab (Figura 6.16) viene visualizzato nella Property View a seguito dellaselezione di uno qualsiasi degli oggetti istanziati nel foglio di lavoro. Contiene unform organizzato in 2 parti:

• la parte sinistra permette la modifica della posizione (relativamente alla po-sizione del foglio di lavoro) e delle dimensioni dell’oggetto selezionato (espressein pixel);

• la parte destra visualizza le proprieta comuni a tutte le categorie di ogget-ti: type (tipologia di oggetto), description (descrizione della funzione del-l’oggetto) e name (nome dell’oggetto, modificabile dall’utente).

Le operazioni di spostamento/ridimensionamento di un oggetto (nel foglio dilavoro) comportano l’aggiornamento automatico dei campi “Position” e “Size”. Taleinterazione viene realizzata mediante il pattern di programmazione Observer :

1. la Property View provvede a registrare un osservatore all’interno dell’oggettoEditPart selezionato. Tale osservatore e un puntatore ad una funzione il cuiscopo e aggiornare i campi “Position” e “Size” del tab CommonProperties ;

82


Figura 6.16. Il tab CommonProperties

2. quando l’oggetto viene spostato o ridimensionato si procede con l’invio di unanotifica agli osservatori registrati. Viene quindi eseguita la procedura cheaggiorna il contenuto dei campi “Position” e “Size”.

Infine le modifiche effettuate dall’utente alle proprieta “Position” e “Size” siripercuotono direttamente sull’oggetto nel foglio di lavoro (che viene spostato oridimensionato).

6.4.2 I tab Network e NetworkGateway

Il tab Network permette la definizione della componente di rete (BTicino o Kon-nex) di ogni dispositivo istanziato nel foglio di lavoro. Nel caso di dispositivi trat-tati in simulazione non occorre specificare alcuna componente di rete (di defaultviene impostata la componente di rete “EliteComponent”). La selezione della voce“BTicinoComponent” (Figura 6.17) rende visibili i campi “PhysicalAddress” (chedeve essere valorizzato affiche la componente di rete sia valida) e “PhysicalType”(opzionale).

Figura 6.17. Il tab Network/BTicinoComponent

La voce “KonnexComponent” (Figura 6.18) consente di impostare una com-ponente di rete di tipo Konnex. I controlli visualizzati nel form permettono diinizializzare i parametri definiti da questa tecnologia.

83


Figura 6.18. Il tab Network/KonnexComponent

Il tab NetworkGateway (Figura 6.19), visualizzato solo in caso di selezione dioggetti network gateway, permette la modifica dei parametri di rete necessari algateway DOG per comunicare con il network gateway selezionato.

Figura 6.19. Il tab NetworkGateway

6.4.3 I tab ControlRelation e RelationsSummary

I tab ControlRelation (Figura 6.20) e RelationsSummary (Figura 6.21), inseriti nellaProperty View a seguito della selezione un link di controllo (ControlLink), hannolo scopo di permettere la gestione delle relazioni di controllo che intercorrono tra 2dispositivi.

La creazione di una relazione di controllo consiste nella definizione di una cor-rispondenza tra una notifica generata dal dispositivo controllore (selezionata dalla

84


ComboBox “Notification”) ed un comando che governa il dispositivo controllato (se-lezionato dalla ComboBox “Command”). La Figura 6.20 mostra un esempio d’usodel tab ControlRelation per la creazione di una relazione di controllo tra un oggettopulsante (“Button1”, dispositivo controllore) ed una lampada ad intensita luminosaregolabile (“DimmableLight1”, dispositivo controllato).

Figura 6.20. Il tab ControlRelation

La tabella “Parameters” permette di impostare il valore dei parametri (se pre-senti) del comando selezionato: ogni riga contiene la descrizione di un parametro(nome, tipo di dati che puo assumere e valore dato). Il comando SetCommand, adesempio, definisce il parametro value, livello di intensita luminosa da impostare allalampada. La relazione di controllo mostrata in Figura 6.20 ha il seguente significatologico: a seguito della ricezione della notifica OnNotification (generata da “But-ton1” in risposta ad un evento di pressione del pulsante) viene generato e trasmessoalla lampada “DimmableLight1” un comando SetCommand(50) (che ha lo scopo diimpostare l’intensita luminosa della lampada al 50%).

Il tab RelationsSummary (Figura 6.21) fornisce una visione d’insieme delle re-lazioni di controllo definite tra 2 dispositivi. Le colonne “Notification of Con-troller Device” e “Command of Controlled Device” contengono rispettivamente lanotifica del dispositivo controllore ed il comando del dispositivo controllato checaratterizzano la relazione di controllo selezionata.

L’esempio in Figura 6.21 mostra il tab RelationsSummary nel caso in cui sianostate istanziate 2 relazioni di controllo tra il pulsante e la lampada. La prima

85


Figura 6.21. Il tab RelationsSummary

(OnNotification-SetCommand) riguarda la relazione di controllo spiegata preceden-temente. La seconda (OffNotification-OffCommand) gestisce l’interazione tra lam-pada e pulsante quando quest’ultimo viene rilasciato: la notifica OffNotification,generata dal pulsante a seguito di un evento di rilascio, determina la generazione ela trasmissione di un comando OffCommand il cui scopo e spegnere la lampada.

E possibile eliminare la relazione di controllo selezionata o modificare il valoredei suoi parametri (mediante la tabella “Command parameters”).

6.5 Esportazione del file di progetto

Il modulo BuildFile provvede all’esportazione del modello di ambiente creato me-diante DogDomoticIde in un formato direttamente utilizzabile dal gateway DOG(xmldog).

Figura 6.22. Esportazione del file di progetto

BuildFile riceve come input la struttura dati gestita dalla Summary View (l’al-bero di nodi) che descrive il progetto creato dall’utente nel foglio di lavoro. Inparticolare:

• ogni nodo dell’albero descrive uno specifico oggetto;

86


• l’organizzazione dei nodi tiene conto delle relazioni di contenimento che in-tercorrono tra i vari oggetti istanziati nel foglio di lavoro (es. appartamentocontiene stanza che, a sua volta, contiene un dispositivo). Questa strutturarisulta utile per la generazione di documenti di configurazione nel formato xml-dog, in quanto essi adottano una struttura gerarchica ed un’organizzazione deltutto simile.

6.5.1 Il formato xmldog

Il formato xmldog (proposto dal gruppo di ricerca e-Lite) definisce un insieme ditag XML il cui scopo e la descrizione di ambienti domotici. La descrizione di unambiente si sviluppa in 2 parti:

1. descrizione della struttura di un ambiente: un impianto domotico consiste diun edificio (xmldog:building) che puo contenere appartamenti (xmldog:flat),garage (xmldog:garage) e giardini (xmldog:garden). Le stanze presenti in unappartamento (xmldog:room) sono delimitate da muri (xmldog:wall) e dotatedi un pavimento (xmldog:floor) ed un soffitto (xmldog:ceiling);

2. descrizione dei dispositivi istanziati e delle relazioni di interazione presenti traessi. Per ogni dispositivo viene inserito nel file di configurazione un oggettoxmldog:device che contiene:

• l’indicazione della stanza che contiene il dispositivo;

• la descrizione della componente di rete del dispositivo;

• l’elenco dei comandi e delle notifiche che il dispositivo gestisce. Questeinformazioni devono essere introdotte solo se il dispositivo non e standard(non ha parametri di configurazione specifici per ogni singolo comando onotifica e non e connesso ad altri dispositivi);

• la descrizione delle eventuali relazioni di controllo instaurate tra il dis-positivo in esame e gli altri dispositivi presenti nell’ambiente.

6.5.2 Esempio di descrizione xmldog di un sistema domotico

Nel seguito viene descritto parte di un esempio di file di configurazione generato dalmodulo BuildFile nel formato introdotto precedentemente. Le 2 parti (descrizionedella struttura e dei dispositivi) devono, ovviamente, essere integrate nello stessodocumento di configurazione (una di seguito all’altra).

87


Descrizione della struttura di un ambiente

Un appartamento (“Flat1”, Figura 6.23) contiene una stanza (“Cucina”) delimitatada 4 muri e dotata di un soffitto (“ceiling1”) ed un pavimento (“floor1”). Il ter-zo e quarto muro contengono rispettivamente una porta (“Entrata”, che consentel’ingresso nell’appartamento) ed una finestra (“FinestraCucina”).

Figura 6.23. Descrizione della struttura di un ambiente nel formato xmldog

Descrizione di un dispositivo pulsante

Il pulsante “PulsanteLampada” (Figura 6.24) e posizionato nella stanza “Cucina”,ha una componente di rete di tipo BTicino e controlla il funzionamento di unalampada (“Lampada1”).

Tra i 2 dispositivi sono state instaurate 2 relazioni di controllo:

• la generazione di una OnNotification (“PulsanteLampadaOnNotification1”) daparte del “PulsanteLampada” determina la trasmissione alla lampada di un co-mando OnCommand il cui scopo e accendere la luce (“Lampada1OnCommand1”);

• la generazione di una OffNotification (“PulsanteLampadaOffNotification1”) daparte del “PulsanteLampada” determina la trasmissione alla lampada di un co-mando OffCommand il cui scopo e spegnere la luce (“Lampada1OffCommand1”);

88


Figura 6.24. Descrizione di un dispositivo nel formato xmldog

89

Capitolo 7

Casi di studio

Questo capitolo descrive la progettazione di scenari domestici reali/verosimili in cuile soluzioni sviluppate nella tesi trovano applicazione. In particolare i primi due casidi studio sono semplici e hanno lo scopo di valutare:

1. le funzionalita di progettazione offerte da DogDomoticIde;

2. la validita del file di configurazione generato.

Il terzo caso di studio (SimpleHome) viene affrontato con lo scopo di confrontare (intermini di tempi impiegati e difficolta riscontrate) 2 tecniche per la generazione deldocumento di configurazione da installare sul gateway DOG (progettazione grafi-ca mediante DogDomoticIde, creazione diretta di istanze dell’ontologia DogOntmediante il software Protege).

Per realizzare i test descritti nel seguito e stato utilizzato il prototipo di sistemadomotico a disposizione del gruppo di ricerca e-Lite del Politecnico di Torino. Talearchitettura comprende:

• un insieme di dispositivi Konnex e BTicino (lampade, interruttori, attuatori);

• un gateway DOG;

• l’applicazione DogSimpleClient, capace di interagire con DOG allo scopo diricevere notifiche dall’ambiente controllato ed inviare comandi ai dispositivi.

7.1 Caso 1: progetto di un appartamento

La Figura 7.1 mostra il contenuto della Design View di DogDomoticIde a seguitodella progettazione effettuata. La struttura dell’ambiente e stata realizzate mediantele seguenti operazioni:

90

7 – Casi di studio

Figura 7.1. Caso di studio 1

1. creazione di un appartamento;

2. creazione e posizionamento di 7 muri.

L’appartamento contiene 5 stanze: sgabuzzino (StorageRoom), bagno (Bath-Room), cucina (DiningRoom), soggiorno (LivingRoom), entrata (Lobby). Le restanti2 stanze (posizionate a nord-est ed a sud-ovest dell’appartamento) vengono ignoratein quanto non rientrano nel progetto iniziale: la loro presenza e una conseguenzadel fatto che l’appartamento puo solo avere forma rettangolare.

Vengono poi costruite 2 finestre (posizionate nel muro di confine sud), 4 porte(posizionate nei muri 1, 2, 3 e 4) ed un’entrata (nel muro di confine est).

L’impianto domotico e composto da lampade OnOffLight (il cui scopo e illu-minare le varie stanze) e da dispositivi Switch (interruttori). I network gatewayBTicino (BT) e Konnex (KNX) rappresentano i punti di accesso necessari a DOGper dialogare con i dispositivi istanziati nell’impianto.

91


Si procede con la definizione della componente di rete di ogni dispositivo. Taleconfigurazione va fatta in relazione alla reale natura dei dispositivi che si hanno adisposizione per il test. Nel caso in esame la lampada “Lamp StorageR” e l’inter-ruttore “Switch StorageR” hanno marchio BTicino. Per questi 2 dispositivi occorrequindi definire una componente di rete di tipo BTicino: mediante la tab Network(Property View) si seleziona la voce “BTicinoNetworkComponent” e si impostano iparametri relativi a questa tecnologia. Per tutti i restanti dispositivi viene dichiara-ta una componente di rete di tipo Konnex (selezione, nella tab Network, della voce“KonnexNetworkComponent”).

Ogni interruttore consente di accendere/spegnere la luce della lampada alla qualee connesso mediante un ControlLink (collegamento di colore verde che permette ladefinizione di relazioni di interazione tra 2 dispositivi). Si consideri, ad esempio,il dispositivo “Switch StorageR” che consente di accendere/spegnere la lampada“Lamp StorageR”. Mediante la selezione del relativo ControlLink e possibile fareaccesso alla tab ControlRelation (Property View) ed impostare le seguenti relazionidi controllo:

• OnNotification (“Switch StorageR”)→ OnCommand (“Lamp StorageR”);

• OffNotification (“Switch StorageR”)→ OffCommand (“Lamp StorageR”).

La notifica OnNotification (generata da “Switch StorageR” a seguito di un even-to di posizionamento in stato di “On” dell’interruttore stesso) determinera la trasmis-sione del comando OnCommand alla lampada “Lamp StorageR” con lo scopo diaccendere la luce. Analogamente, a seguito di un evento di di posizionamento instato di “Off” dell’interruttore (OffNotification), dovra essere generato un comandoOffCommand il cui scopo e spegnere la luce della lampada. Le relazioni di controlloche intercorrono tra tutte le altre coppie interruttore - lampada sono analoghe aquelle appena descritte.

7.1.1 Generazione del file di configurazione ed installazionesu DOG

La stesura delle relazioni di controllo conclude la progettazione dell’ambiente inesame. A questo punto e possibile generare il file di configurazione selezionando,dal menu File di DogDomoticIde, la voce Build configuration file. Tale file vieneinfine installato sul gateway DOG (all’interno del bundle HouseModel). La validitadel documento di configurazione prodotto da DogDomoticIde viene poi verificatamediante l’applicazione DogSimpleClient . I risultati emersi da questa prima speri-mentazione sono soddisfacenti: tutti i dispositivi sono correttamente riconosciuti daDOG ed e possibile, mediante l’interfaccia fornita da DogSimpleClient, controllarel’accensione e lo spegnimento delle lampade.

92


7.2 Caso 2: ambiente composto da 2 appartamen-

ti

Il secondo caso di studio (Figura 7.2) ha lo scopo di valutare DogDomoticIde nelcaso di progettazione di ambienti aventi una struttura architettonica piu complessa.Si procede pertanto all’inserimento di un ulteriore appartamento nel progetto creatonel caso di studio iniziale. Il nuovo appartamento contiene 3 camere (BathRoom,Lobby e BedRoom) nelle quali e stato istallato il solo impianto di illuminazione(lampade, interruttori, pulsanti e rele).

Figura 7.2. Caso di studio 2

93


I dispositivi “Lamp LobbyR”, “ Relay1”, “Light BedR” e “Relay2” vengono sim-ulati in quanto non fisicamente disponibili (non richiedono cioe la definizione di al-cuna componente di rete). Per i restanti dispositivi occorre invece impostare unacomponente di rete di tipo Konnex (tab Network, Property View).

Ogni pulsante controlla l’accensione e lo spegnimento di una lampada medi-ante un rele. “Button LobbyR”, ad esempio, controlla il rele “Relay1” mediante laseguente relazione di interazione:

• OnNotification (“Button LobbyR”)→ ToggleCommand (“Relay1”);

A seguito di un evento di pressione del pulsante “Button LobbyR” viene gen-erato un comando ToggleCommand che fa cambiare di stato il rele: se il releera in posizione “Off” allora ToggleCommand imposta il dispositivo in posizione“On” e viceversa. “Relay1”, a sua volta, controlla l’accensione e lo spegnimento di“Lamp LobbyR” mediante le seguenti relazioni di interazione:

• OnNotification (“Relay1”)→ OnCommand (“Lamp LobbyR”);

• OffNotification (“Relay1”)→ OffCommand (“Lamp LobbyR”).

Supponendo che “Relay1” sia inizialmente in posizione “Off” si ha il seguentefunzionamento: a seguito di un evento di pressione di “Button LobbyR” viene gen-erato un comando ToggleCommand che imposta “Relay1” in posizione “On”. Taleevento comporta la generazione di un comando OnCommand che accende la lucedi “Lamp LobbyR”. Analogamente, a seguito di un successivo evento di pressionedel pulsante, viene generato un comando ToggleCommand che imposta il rele inposizione “Off”. Questo comporta la generazione di un comando “OffCommand”che spegne la luce della lampada.

Infine si procede alla generazione del file di configurazione ed alla sua successivainstallazione sul gateway DOG. Purtroppo la versione di DOG utilizzata per gliesperimenti non supporta ambienti domotici distribuiti su piu appartamenti; cioha portato a delle problematiche di riconoscimento dei dispositivi e degli ambientidescritti nel file generato da DogDomoticIde.

7.3 Caso 3: SimpleHome

Quest’ultimo caso di studio ha lo scopo di valutare i tempi impiegati e le difficoltaincontrate nel progettare un ambiente domotico piu articolato (SimpleHome, Figura7.3) con DogDomoticIde.

All’interno di ogni stanza sono stati istanziati oggetti di arredamento (es. lettomatrimoniale, guardaroba, tavolo, sofa, ecc.), dispositivi di automazione per finestre

94


Figura 7.3. SimpleHome

e serrande (ShutterActuator, WindowActuator), lampade ed interruttori per la ges-tione dell’illuminazione, dispositivi DoorSensor per la segnalazione dello stato delleporte (una porta puo essere aperta o chiusa).

I dispositivi WindowActuator/ShutterActuator permettono di automatizzare l’aper-tura e la chiusura delle finestre/serrande alle quali sono connessi (ActuatorLink).WindowActuator viene controllato da 2 pulsanti (“Button open”, “Button close”)

95


in maniera tale che:

• quando “Button open” viene tenuto premuto l’attuatore aprira la finestra;

• quando “Button close” viene tenuto premuto l’attuatore chiudera la finestra;

• quando “Button open” o “Button close” vengono rilasciati allora l’azione diapertura/chiusura della finestra deve interrompersi.

Tale comportamento viene implementato dalle seguenti relazioni di controllo:

• OnNotification (“Button open”)→ OpenCommand (WindowActuator);

• OffNotification (“Button open”)→ RestCommand (WindowActuator);

• OnNotification (“Button close”)→ CloseCommand (WindowActuator);

• OffNotification (“Button close”)→ RestCommand (WindowActuator).

Analogamente ogni dispositivo ShutterActuator viene controllato da 2 pulsanti(“Button up”, “Button down”) in maniera tale che:

• quando “Button up” viene tenuto premuto l’attuatore provvedera a far salirela serranda;

• quando “Button down” viene tenuto premuto l’attuatore provvedera a farscendere la serranda;

• quando “Button up” o “Button down” vengono rilasciati allora l’azione disalita/discesa della serranda deve interrompersi.

Le relazioni di controllo che implementano tale comportamento sono analoghe aquelle descritte in precedenza. Ultimata la progettazione dell’ambiente si procedecon la generazione e l’installazione del file di configurazione su DOG.

7.3.1 Tecniche a confronto: risultati sperimentali

Sperimentalmente si e provato a modellare la SimpleHome mediante 2 tecniche diprogettazione:

1. DogDomoticIde (descritta in precedenza);

2. creazione del file di ontologia mediante il software Protege.

96


Setup sperimentale

• utente esperto di ontologie e di tecnologie domotiche, capace sia di utilizzareDogDomoticIde, sia di creare istanze di DogOnt mediante Protege;

• distribuzione delle prove in 2 sessioni di test distinte:

1. progettazione SimpleHome mediante DogDomoticIde;

2. progettazione mediante Protege (sessione distribuita nell’arco di una set-timana).

• tempi di durata delle sessioni di test misurati mediante l’uso di un timer soft-ware. I valori riportati nel seguito sono da intendere come quantita di temporichiesto per modellare la SimpleHome mediante le 2 tecniche di progettazione.

Risultati ottenuti

Tecnica Tempo DifficoltaDogDomoticIde ∼1 ora bassaProtege ∼40 ore elevata

L’applicazione DogDomoticIde, grazie alla sua interfaccia grafica a componenti,ha permesso una piu rapida modellazione dello scenario in esame e la conseguentecostruzione del relativo documento di configurazione xmldog.

97

Capitolo 8

Conclusioni

L’applicazione DogDomoticIde, progettata e realizzata in questa tesi, implementale funzionalita che soddisfano tutti i requisiti funzionali primari definiti nella fasedi progettazione: fornisce un’interfaccia grafica per la progettazione di ambientidomotici e consente l’esportazione delle informazioni di progetto in un formato uti-lizzabile dal gateway DOG. DogDomoticIde permette a progettisti non esperti ditecnologie domotiche e di ontologie di costruire modelli di impianto basati su DOG,cosı come richiesto inizialmente.

Naturalmente la versione di DogDomoticIde prodotta in questa tesi presentanotevoli margini di sviluppo, sia per quanto riguarda le capacita di editing grafico,sia per la gestione del modello dati. Allo stato attuale non e possibile, ad esempio,rappresentare appartamenti di forma non rettangolare. Il modello dati, costruitosulla base dell’ontologia DogOnt v1.0.3, contiene la descrizione completa di tutti glielementi istanziabili all’interno di un impianto domotico. Il continuo evolversi del-l’ontologia spinge alla costruzione di un modulo per DogDomoticIde che permettadi selezionare, a run-time, una nuova versione di DogOnt con conseguente aggior-namento del modello dati. Lo sviluppo di questo modulo e molto importante per ilfuturo di quest’applicazione: mantenere il modello dati aggiornato rispetto alla ver-sione di ontologia utilizzata da DOG, consente la produzione di file di configurazionesempre compatibili con il gateway stesso.

L’applicazione costruita risulta adatta anche per scopi simulativi. Un possi-bile sviluppo futuro consiste nell’introdurre moduli di simulazione che consentanoal progettista di verificare il funzionamento dell’impianto creato, prima della suaapplicazione in un ambiente reale.

Da un punto di vista implementativo, la costruzione di DogDomoticIde tramitel’ausilio del plug-in GMF ha presentato vantaggi, ma anche punti critici. La gener-azione del codice ha semplificato lo sviluppo dell’applicazione, sebbene abbia deter-minato l’insorgere di notevoli problemi nella fase successiva; ossia per la modifica delcodice al fine di introdurre funzionalita aggiuntive. Il plug-in domoticIde.diagram

98

8 – Conclusioni

(generato da GMF) e infatti composto da un centinaio di classi Java, scritte e pen-sate per essere modificate il meno possibile. Inserirsi in quel contesto ed applicare lesoluzioni descritte nel capitolo 6 e stato molto complesso, dispendioso di tempo edha richiesto l’applicazione di strategie un po’ “forzate”. E da segnalare la mancan-za di documentazione relativa alle classi generate da GMF: le uniche informazionireperibili sono relative a soluzioni specifiche per alcuni problemi.

Infine e risultato che GMF, per via delle limitate capacita di rappresentazionegrafica, e uno strumento poco adatto per la creazione di applicazioni CAD. L’o-biettivo del plug-in GMF e infatti quello di semplificare lo sviluppo di editor perla creazione e la rappresentazione logica di modelli di dati. Quest’ultimo limitenon e risultato particolarmente sconveniente per la realizzazione di DogDomoticIde,in quanto gli obiettivi primari di quest’applicazione riguardano principalmente lacapacita di modellazione domotica.

99

Bibliografia

[1] Wikipedia: Domotica. http://it.wikipedia.org/wiki/Domotica.[2] Eclipse RCP: Rich Client Platform. http://www.eclipse.org/home/categories/rcp.php.[3] EMF: Eclipse Modeling Framework. http://www.eclipse.org/modeling/emf/.[4] GMF: Graphical Modeling Framework. http://www.eclipse.org/modeling/gmp/.[5] Davide Devescovi. Sviluppo di tool basati su un metamodello editabile grafica-

mente. http://www.devedeve.com/wp-includes/files/EMF,GEF,GMF.pdf.[6] D. Bonino, E. Castellina, F. Corno. The DOG Gateway: Enabling

Ontology-based Intelligent Domotic Environments. IEEE TRANSACTIONS ONCONSUMER ELECTRONICS. vol. 54/4 ISSN: 0098-3063, pp. 1656-1664.

[7] D. Bonino, E. Castellina, F. Corno. Bringing Semantics to the Home: The Dog2.0gateway. IEEE TRANSACTIONS ON SYSTEM, MAN AND CYBERNETICS,PART C.

100

http://it.wikipedia.org/wiki/Domotica

http://www.eclipse.org/home/categories/rcp.php

http://www.eclipse.org/modeling/emf/

http://www.eclipse.org/modeling/gmp/

http://www.devedeve.com/wp-includes/files/EMF,GEF,GMF.pdf

Documents

Ambienti di Sviluppo Integrati per Sistemi Domotici ...orizzontenergia.it/download/Appr/DOMOTICA/2011_07_Ambienti di... · POLITECNICO DI TORINO III Facolt a di Ingegneria dell’Informazione