Ambienti di Sviluppo Integrati per Sistemi Domotici Intelligenti - e-Lite
Transcript
Ambienti di Sviluppo Integrati per Sistemi Domotici Intelligenti - e-Lite
POLITECNICO DI TORINO III Facoltà di Ingegneria dell’Informazione Corso di Laurea in Ingegneria Informatica Tesi di Laurea Specialistica Ambienti di Sviluppo Integrati per Sistemi Domotici Intelligenti Relatori: prof. Fulvio Corno ing. Dario Bonino Candidato: Daniele Mina Luglio 2011 Indice 1 Introduzione 1.1 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Struttura della tesi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Stato dell’arte 2.1 Sistemi domotici . . . . . . . . . . . . . . . . 2.1.1 Intelligent Domotic Environment . . . 2.2 Il linguaggio DogOnt . . . . . . . . . . . . . . 2.2.1 DogOnt Ontology . . . . . . . . . . . . 2.3 Il gateway DOG . . . . . . . . . . . . . . . . . 2.3.1 Architettura . . . . . . . . . . . . . . . 2.4 Punti critici e aree di possibile miglioramento 3 Obiettivi 3.1 Scopo della tesi . . . . . . . . . 3.2 Requisiti . . . . . . . . . . . . . 3.2.1 Requisiti funzionali . . . 3.2.2 Requisiti non funzionali 3.3 Analisi delle possibili soluzioni . . . . . . 4 Strumenti utilizzati 4.1 La piattaforma Eclipse . . . . . . 4.2 Eclipse Modeling Framework . . . 4.2.1 Componenti . . . . . . . . 4.2.2 Definire un modello EMF 4.3 Graphical Editing Framework . . 4.3.1 Componenti . . . . . . . . 4.3.2 Usare GEF con EMF . . . 4.4 Graphical Modeling Framework . II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 5 5 . . . . . . . 7 7 8 10 11 15 16 18 . . . . . 20 20 21 21 23 25 . . . . . . . . 26 26 28 28 30 32 32 33 34 5 Generazione dell’applicazione DogDomoticIde 5.1 Struttura della soluzione . . . . . . . . . . . . . . . 5.2 DataModel Structure . . . . . . . . . . . . . . . . . 5.3 Generazione del modello dati . . . . . . . . . . . . 5.3.1 Generazione delle interfacce annotate . . . . 5.3.2 Completamento delle classi implementazione 5.4 Costruzione dei modelli per GMF . . . . . . . . . . 5.4.1 Graphical Definition Model . . . . . . . . . 5.4.2 Tooling Definition Model . . . . . . . . . . . 5.4.3 Mapping Definition Model . . . . . . . . . . 5.5 Generazione dell’editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Implementazione 6.1 Architettura logica di DogDomoticIde . . . . . . . . . . . . . . . . . 6.2 La gestione degli ambienti stanza . . . . . . . . . . . . . . . . . . . 6.2.1 L’algoritmo RoomDetection . . . . . . . . . . . . . . . . . . 6.2.2 Integrazione dell’algoritmo RoomDetection nell’applicazione DogDomoticIde . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 La Summary View . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.1 Aggiornamento della Summary View . . . . . . . . . . . . . 6.3.2 Aspetto e funzionalità della Summary View . . . . . . . . . 6.4 Modifica della Property View . . . . . . . . . . . . . . . . . . . . . 6.4.1 Il tab CommonProperties . . . . . . . . . . . . . . . . . . . 6.4.2 I tab Network e NetworkGateway . . . . . . . . . . . . . . . 6.4.3 I tab ControlRelation e RelationsSummary . . . . . . . . . . 6.5 Esportazione del file di progetto . . . . . . . . . . . . . . . . . . . . 6.5.1 Il formato xmldog . . . . . . . . . . . . . . . . . . . . . . . . 6.5.2 Esempio di descrizione xmldog di un sistema domotico . . . . . . . . . . . . . 36 36 42 50 51 54 56 57 59 60 61 64 . 64 . 65 . 67 . . . . . . . . . . . 75 78 79 81 82 82 83 84 86 87 87 7 Casi di studio 7.1 Caso 1: progetto di un appartamento . . . . . . . . . . . . . . . . . . 7.1.1 Generazione del file di configurazione ed installazione su DOG 7.2 Caso 2: ambiente composto da 2 appartamenti . . . . . . . . . . . . . 7.3 Caso 3: SimpleHome . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.1 Tecniche a confronto: risultati sperimentali . . . . . . . . . . . 90 90 92 93 94 96 8 Conclusioni 98 Bibliografia 100 III Elenco delle figure 2.1 2.2 2.3 2.4 4.1 4.2 4.3 4.4 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13 5.14 5.15 5.16 5.17 5.18 5.19 5.20 5.21 5.22 Intelligent Domotic Environment . . . . . . . . . . . . . . . . . . . . La struttura di DogOnt Ontology . . . . . . . . . . . . . . . . . . . . Esempio di interconnessione tra una lampada ed uno switch . . . . . DOG Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . L’architettura di base di Eclipse . . . . . . . . . . . . . . . . . . . . . La gerarchia del modello ECore . . . . . . . . . . . . . . . . . . . . . Il funzionamento di EMF . . . . . . . . . . . . . . . . . . . . . . . . . Il workflow di GMF . . . . . . . . . . . . . . . . . . . . . . . . . . . . Struttura della soluzione . . . . . . . . . . . . . . . . . . . . . . . . . Esempio di interfacce e di classi implementazione . . . . . . . . . . . Esempio di mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . Componenti dell’applicazione DogDomoticIde generata mediante GMF Il ruolo del DataModel Structure . . . . . . . . . . . . . . . . . . . . La classe ArchitecturalElement . . . . . . . . . . . . . . . . . . . . . La classe BuildingArea . . . . . . . . . . . . . . . . . . . . . . . . . . Il DataModel Structure . . . . . . . . . . . . . . . . . . . . . . . . . . La classe DeviceElement . . . . . . . . . . . . . . . . . . . . . . . . . La gestione della componente di rete . . . . . . . . . . . . . . . . . . Le classi NotificationElement, CommandElement e Param . . . . . . La classe HomeGateway . . . . . . . . . . . . . . . . . . . . . . . . . Le classi ControlProperties e ControlElement . . . . . . . . . . . . . . Le classi ActuatorElement e SensorElement . . . . . . . . . . . . . . La classe VisualElement . . . . . . . . . . . . . . . . . . . . . . . . . Workflow per la generazione del modello dati . . . . . . . . . . . . . . Le interfacce DeviceElement e Lamp . . . . . . . . . . . . . . . . . . Classe implementazione prima e dopo l’esecuzione di FillImplementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Classe implementazione relativa allo stato OnOffState . . . . . . . . . Costruzione dei modelli per GMF . . . . . . . . . . . . . . . . . . . . Descrizione grafica del dispositivo Computer . . . . . . . . . . . . . . Descrizione grafica del ControlLink . . . . . . . . . . . . . . . . . . . IV 9 12 14 16 27 29 31 35 37 39 40 42 42 43 43 44 45 45 47 48 48 49 49 51 53 55 56 57 57 58 5.23 5.24 5.25 5.26 5.27 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 6.11 6.12 6.13 6.14 6.15 6.16 6.17 6.18 6.19 6.20 6.21 6.22 6.23 6.24 7.1 7.2 7.3 Rappresentazione grafica risultante . . . . . . . . . . . . . . . . Costruzione della palette degli oggetti . . . . . . . . . . . . . . . Mapping dell’elemento ArmChair . . . . . . . . . . . . . . . . . Generazione dell’editor . . . . . . . . . . . . . . . . . . . . . . . Screenshot dell’applicazione DogDomoticIde versione base, cioè tenuta mediante generazione automatica . . . . . . . . . . . . . Architettura logica di DogDomoticIde . . . . . . . . . . . . . . . Esempio di struttura di due ambienti appartamento . . . . . . . Muri connessi e non connessi . . . . . . . . . . . . . . . . . . . . Struttura dell’algoritmo RoomDetection . . . . . . . . . . . . . Caso di studio: appartamento dotato di un muro centrale . . . . La struttura dati intersectionList . . . . . . . . . . . . . . . . . La struttura dati intersectionMap . . . . . . . . . . . . . . . . . Esempio di grafo di aree di intersezione . . . . . . . . . . . . . . Stanze individuate dall’algoritmo RoomDetection . . . . . . . . Integrazione dell’algoritmo RoomDetection in DogDomoticIde . Aggiornamento della struttura dati builtRoom . . . . . . . . . . La Summary View . . . . . . . . . . . . . . . . . . . . . . . . . Struttura della Summary View . . . . . . . . . . . . . . . . . . Esempio di SummaryView . . . . . . . . . . . . . . . . . . . . . Modifica della Property View . . . . . . . . . . . . . . . . . . . Il tab CommonProperties . . . . . . . . . . . . . . . . . . . . . Il tab Network/BTicinoComponent . . . . . . . . . . . . . . . . Il tab Network/KonnexComponent . . . . . . . . . . . . . . . . Il tab NetworkGateway . . . . . . . . . . . . . . . . . . . . . . . Il tab ControlRelation . . . . . . . . . . . . . . . . . . . . . . . Il tab RelationsSummary . . . . . . . . . . . . . . . . . . . . . . Esportazione del file di progetto . . . . . . . . . . . . . . . . . . Descrizione della struttura di un ambiente nel formato xmldog . Descrizione di un dispositivo nel formato xmldog . . . . . . . . . Caso di studio 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . Caso di studio 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . SimpleHome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . V . . . . . . . . ot. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 59 60 61 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 64 66 67 68 68 69 70 71 74 76 77 78 79 81 82 83 83 84 84 85 86 86 88 89 91 93 95 Capitolo 1 Introduzione 1.1 Scenario La domotica è la scienza interdisciplinare che si occupa dello studio di tecnologie e di soluzioni architetturali atte a migliorare la qualità della vita in un ambiente domestico. L’obiettivo di un impianto domotico è quello di rendere più “intelligente” l’ambiente nel quale è installato al fine di aumentarne la sicurezza, centralizzare il controllo dell’abitazione, semplificare lo svolgimento delle più comuni operazioni anche ad individui che possiedano delle disabilità, e attuare politiche di risparmio energetico. Le funzionalità di una rete domotica possono essere suddivise in due categorie: 1. funzionalità di monitoraggio; 2. funzionalità di controllo centralizzato. Le funzionalità di monitoraggio sono quelle che forniscono all’ambiente una maggiore affidabilità e sicurezza; tipicamente vengono realizzate mediante la presenza di sensori controllati dall’impianto domotico. In questo caso l’“intelligenza” della rete domotica risiede nella sua capacità di reagire opportunamente in base alle informazioni che arrivano dai sensori. Consideriamo, ad esempio, un sensore di fumo: nel momento in cui questo dispositivo rileva la presenza di un incendio, la rete domotica dovrà agire di conseguenza attivando gli sprinkler, sistema automatico di estinzione a pioggia, oppure effettuando una telefonata per contattare i soccorsi. Le funzionalità di controllo centralizzato hanno come obiettivo quello di aumentare il comfort facilitando le operazioni che normalmente si eseguono in un ambiente domestico. L’utente, attraverso un’opportuna interfaccia, interagisce con la rete domotica allo scopo di eseguire azioni (accendere la luce, chiudere tutte le tapparelle, ecc.) o di visionare alcuni parametri di stato dell’abitazione. Queste 1 1 – Introduzione funzionalità sono molto importanti per persone con disabilità in quanto permettono loro di avere maggiore autonomia e maggior controllo dell’abitazione. Quando si parla di domotica molto spesso si utilizza il termine “rete” in quanto la struttura di un impianto domotico presenta molte analogie con quella di una tradizionale rete di computer. In particolare i dispositivi elettrici presenti nell’abitazione sono dotati di un componente di rete che permette loro di essere connessi con l’impianto domotico, di inviare notifiche riguardanti il loro stato e di ricevere comandi di controllo. Questa comunicazione viene realizzata attraverso l’uso di protocolli ad hoc. Le più comuni tecnologie utilizzate nell’ambito di una rete domotica filare, cioè basata sulla connessione dei dispositivi che la compongono mediante fili (bus), vengono fornite a livello Europeo dalla BTicino e dal consorzio Konnex. Recentemente stanno emergendo protocolli e standard wireless che permettono un’interazione tra dispositivi senza la necessità di fili e/o connessioni elettriche (protocolli Z-Wave e ZigBee). Ogni dispositivo presente in una rete domotica viene catalogato in base al tipo di componente che gli permette di accedere alla rete. In particolare si definisce dispositivo BTicino un dispositivo con componente di rete di tipo BTicino (che utilizza i protocolli proprietari BTicino per la comunicazione su bus), analogamente un dispositivo di tipo Konnex è un dispositivo che utilizza lo standard Konnex per la comunicazione. In un tipico scenario domotico possono potenzialmente essere presenti dispositivi disomogenei per quanto riguarda la tecnologia di accesso alla rete. Tornando all’analogia con i computer è come se nello stesso ufficio convivessero pc con scheda di rete Ethernet, altri con scheda di rete TokenRing e altri ancora con scheda di rete WiFi. Come non è possibile una comunicazione diretta tra un computer su rete Ethernet ed un computer su rete WiFi, cosı̀ non è possibile una comunicazione diretta tra un dispositivo Konnex ed un dispositivo BTicino. In generale non è possibile instaurare una comunicazione diretta tra dispositivi che utilizzano diverse tecnologie per l’accesso alla rete. Occorre inoltre tener presente che le differenze tra i vari impianti domotici non riguardano sono il livello di accesso alla rete ma interessano tutti i livelli della pila ISO-OSI. L’introduzione di sistemi hardware e software aggiuntivi, nati con lo scopo di amministrare tutti gli altri dispositivi presenti nell’ambiente, rappresenta quindi un’innovazione importante rispetto a quello che è il tradizionale modello della smart home. Per smart home, infatti, si è sempre intesa un’abitazione dotata di dispositivi sensori ed attuatori equipaggiati di hardware e software dedicati che permettono loro di autogestirsi e di realizzare politiche intelligenti semplici. Questo modello, nato nei tardi anni ’90, risulta oggi sempre più limitante in relazione al continuo espandersi del mercato della domotica ed alle sempre più complesse funzionalità richieste. Inoltre è da evidenziare che le soluzioni domotiche cominciano a trovare applicazione anche in grandi strutture ed edifici, pensiamo ad ospedali o centri commerciali. In 2 1 – Introduzione questi contesti è normale che i dispositivi non siano forniti tutti dallo stesso produttore con la conseguenza che, in alcuni casi, non è possibile un’interazione diretta per via delle diverse tecnologie utilizzate. Da queste problematiche nasce la necessità di inserire, in un impianto domotico, un nodo centrale capace di fare da ponte per la comunicazione tra dispositivi disomogenei: il gateway domotico; in questa tesi, in particolare, tale gateway sarà DOG (Domotic OSGi Gateway) sviluppato al Politecnico di Torino dal gruppo e-Lite. DOG permette di espandere il tradizionale modello domotico diventando il cervello dell’impianto. I suoi obiettivi sono quelli di permettere: 1. la gestione dei dispositivi presenti nell’ambiente assicurando la convivenza e l’interazione anche tra quelli che accedono alla rete con protocolli diversi; 2. un’espansione delle funzionalità realizzabili dalla rete domotica rispetto a quelle fornite dal modello tradizionale (semplice interazione sensore-attuatore). Il gateway rappresenta un valore aggiunto che si va a sommare al tradizionale modello domotico al fine di renderlo più funzionale. In genere si tratta di un comune personal computer connesso a tutte le reti di dispositivi presenti nell’ambiente con lo scopo di monitorare il loro stato (ricevendo le loro notifiche) e di inviare comandi da eseguire. Per rendere chiaro questo concetto si consideri il caso di un interruttore BTicino e di una lampada Konnex. Si vuole realizzare la seguente interazione: quando l’interruttore viene posizionato in posizione “On” la luce della lampada deve accendersi. Una possibile soluzione consiste nell’inserire una regola di controllo all’interno del gateway, da eseguire solo se si verificano certe condizioni. La ricezione di una notifica “On” dall’interruttore determinerà la generazione e la trasmissione alla lampada di un comando per accendere la luce. Il gateway svolge quindi la funzione di traduttore: riceve una notifica BTicino, la interpreta e genera un comando Konnex per la lampada. Nel caso specifico di DOG il gateway è costruito utilizzando come base la piattaforma 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 Access Specification: specifica indipendente da qualunque particolare venditore che definisce come un dispositivo, non necessariamente fisico, si agganci alla piattaforma OSGi e come quest’ultima provveda a rilevarlo in modo automatico. Uno degli aspetti che permettono al gateway di svolgere i suoi compiti è la conoscenza dell’ambiente in cui viene installato: DOG deve essere “informato” su come è strutturato l’ambiente (piani, stanze), da quali elementi architetturali è composto, quali sono i dispositivi presenti e come interagiscono tra di loro. 3 1 – Introduzione Tali informazioni sono contenute nel bundle HouseModel, un modulo del gateway che risulta quindi essere specifico per ogni impianto domotico che si sta progettando. Nella soluzione proposta dal gruppo e-Lite, il linguaggio utilizzato per descrivere i sistemi domotici è DogOnt, un metamodello basato sulla modellazione semantica e composto da due parti: • un’ontologia (DogOnt Ontology), espressa in OWL, il cui compito è formalizzare tutte le caratteristiche di un sistema domotico. DogOnt Ontology fornisce una libreria di classi ognuna delle quali descrive un elemento del sistema domotico; • un insieme di regole (DogOnt Rules) che facilitano il processo di modellazione dell’ambiente. La scelta di utilizzare DogOnt come formato di descrizione è dovuta al fatto che è una rappresentazione che permette al gateway DOG di attuare politiche intelligenti per l’ambiente: l’ontologia DogOnt si presta, infatti, ad essere interrogata da sistemi inferenziali che consentono l’estrazione di informazioni avanzate necessarie al gateway per poter operare. Per rappresentare un ambiente il progettista dovrà utilizzare le classi fornite dall’ontologia DogOnt per descrivere i vari elementi che lo compongono (dispositivi, arredamento, struttura dell’abitazione, interazioni). Viene quindi creato un documento, istanza dell’ontologia DogOnt, che deve essere installato sul gateway DOG all’interno del modulo HouseModel. Se da un lato il formato OWL utilizzato da DogOnt incrementa le potenzialità del gateway, dall’altro introduce delle problematiche di configurazione. Produrre un documento istanza di DogOnt è infatti molto complesso: il formato OWL richiede di organizzare le informazioni in una maniera poco intuitiva, utilizzando costrutti e ridondanze tediose. Il dover descrivere un ambiente domotico direttamente in formato OWL (attraverso l’uso di software come Protégé) crea molte difficoltà al progettista: richiede di essere fortemente specializzati ed è dispendioso di tempo. Per alleggerire questa problematica è stato proposto, sempre dal gruppo e-Lite, un tool in grado di generare automaticamente un file di ontologia sulla base di un documento di configurazione XML. Il formato XML proposto (xmldog) ha una struttura più semplice rispetto al formato OWL e permette al progettista di descrivere l’ambiente inserendo solo quelle che sono le informazioni essenziali. Tuttavia questa soluzione non può essere considerata definitiva per il problema: anche se il formato proposto è più semplice ed intuitivo, il progettista resta comunque vincolato alla descrizione testuale 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 ambiente di sviluppo integrato per la progettazione di sistemi domotici intelligenti, basati sulla modellazione semantica DogOnt e sul gateway domotico DOG. L’applicazione sviluppata vuole coprire il tassello mancante che vi è tra il progettista ed il gateway DOG per quanto riguarda la descrizione dell’impianto. Allo stato attuale, infatti, l’unico modo per configurare DOG su uno specifico sistema domotico è quello di creare un’istanza dell’ontologia DogOnt utilizzando software come Protégé. Questa procedura risulta essere poco intuitiva e vincolante in quanto richiede piena conoscenza del formato interpretabile da DOG da parte del progettista. L’ambiente di sviluppo ha come priorità quella di risolvere questa problematica fornendo gli strumenti necessari per descrivere un impianto domotico attraverso una semplice interfaccia grafica. Il progettista, attraverso l’uso di questa applicazione, potrà: 1. definire la struttura ed i contenuti di un impianto di tipo domotico, a partire da librerie di componenti (passivi o attivi) che possono essere inseriti nell’ambiente; 2. effettuare editing degli aspetti grafici (layout 2D) e dei meta-dati (elenchi di proprietà) relativi agli ambienti creati ed ai componenti inseriti; 3. descrivere in maniera semplice ed intuitiva le interazioni che intercorrono tra i dispositivi presenti nell’ambiente; 4. esportare le informazioni derivanti dal progetto in un formato direttamente utilizzabile dal gateway DOG. Il sistema è realizzato sulla base della piattaforma Eclipse RCP e del plug-in GMF (Graphical Modeling Framework). Inoltre il modello dati di lavoro è costruito per essere accessibile ad eventuali, ulteriori, plug-in che in futuro potranno estendere l’applicazione fornendo funzionalità aggiuntive. 1.3 Struttura della tesi Il presente documento è organizzato nei seguenti capitoli: Stato dell’arte (cap. 2) - ha lo scopo di di approfondire il contesto in cui si sviluppa questa tesi; 5 1 – Introduzione Obiettivi (cap. 3) - vengono evidenziati gli obiettivi del lavoro di tesi, espressi sotto forma di requisiti funzionali e non funzionali; Strumenti utilizzati (cap. 4) - vengono introdotti la piattaforma Eclipse ed i plug-in EMF, GEF e GMF; Generazione dell’applicazione DogDomoticIde (cap. 5) - descrizione delle fasi che conducono alla generazione automatica dell’applicazione di base mediante l’ausilio dei plug-in EMF e GMF; Implementazione (cap. 6) - descrizione delle operazioni di integrazione ed estensione dell’applicazione generata automaticamente al fine di supportare i requisiti funzionali primari dichiarati; Casi di studio (cap. 7) - progettazione di scenari domestici reali mediante l’uso dell’applicazione costruita; Conclusioni (cap. 8) - risultati ottenuti nel lavoro di tesi e possibili sviluppi futuri. 6 Capitolo 2 Stato dell’arte Questo capitolo ha lo scopo di di approfondire il contesto in cui si sviluppa questa tesi. A tal fine viene ripreso il concetto di sistema domotico per poi passare alla presentazione del linguaggio di modellazione semantica DogOnt e del gateway domotico DOG. 2.1 Sistemi domotici I sistemi domotici vengono studiati e sono presenti sul mercato da molti anni. Nonostante questo, la loro applicazione nell’ambito residenziale è recente ed è legata al continuo abbassamento del costo della tecnologia ed all’emergere di nuovi bisogni per quanto riguarda il comfort, il risparmio energetico, la sicurezza e la multimedialità. Le attuali soluzioni domotiche presentano però 2 problematiche che ne frenano lo sviluppo: • la presenza di molti produttori di componenti domotici, ognuno dei quali è specializzato solo in alcuni ambiti e ha ben precisi obiettivi di mercato; • la struttura dei dispositivi domotici, che sono pensati e costruiti come un’evoluzione dei 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 alla propria politica di mercato) con soluzioni specifiche per la loro gestione. Questo genera problematiche di interoperabilità con i sistemi prodotti dagli altri vendor: non è infatti possibile fare interagire direttamente dispositivi costruiti da diversi produttori perchè, per la comunicazione, si basano su tecnologie e protocolli differenti. Nella prima fase di sviluppo della domotica, dove le installazioni erano poche ed isolate, il problema dell’interoperabilità era secondario. Oggi invece queste tecnologie trovano applicazione anche in grandi strutture (hotel, università, ospedali, 7 2 – Stato dell’arte ecc.) dove è scontata la presenza di dispositivi costruiti con tecnologie diverse che necessitano di essere coordinati da un unico sistema centrale. L’altro problema sopra citato è legato alla concezione dei componenti domotici come un’evoluzione dei dispositivi elettrici. Questo approccio è riduttivo in quanto le funzionalità richieste ad un sistema domotico sono sempre più articolate, complesse e necessarie di una “intelligenza” superiore rispetto a quella garantita dalla semplice automazione. Come citato nel capitolo introduttivo, viene definita smart home un’abitazione dotata di sensori ed attuatori, di hardware e software dedicati, allo scopo di realizzare semplici interazione di automazione. Questo approccio, rivoluzionario negli anni ’90, risulta oggi limitante in quanto non consente l’introduzione di nuove e più complesse funzionalità. Al fine di risolvere queste problematiche è necessario estendere il modello proposto dalla smart home inserendo, nel sistema domotico, un dispositivo (il gateway) in grado, grazie alle sue capacità computazionali, di supportare l’interoperabilità e di attuare politiche intelligenti per la gestione dei dispositivi. Questo nuovo modello, che in letteratura viene chiamato Intelligent Domotic Environment (IDE), permette al sistema domotico di apprendere le abitudini degli abitanti dell’abitazione, di attuare avanzate tecniche di sicurezza e di implementare politiche per il comfort e per il risparmio energetico. Un passo evolutivo molto importante riguarda la modellazione astratta e formale dei dispositivi domotici e delle loro capacità, indipendentemente dagli aspetti tecnologici. Ad esempio una lampada viene modellata come un oggetto in grado emettere luce, indipendentemente dalla tecnologia con cui è realizzata e con la condizione che sia in qualche modo controllabile dal sistema domotico. L’astrazione dei dispositivi presenti in un ambiente permette al gateway di fare da ponte tra diverse tecnologie: per ogni dispositivo reale viene creata una descrizione astratta che ne esplica il funzionamento attraverso l’uso di un linguaggio comune e condiviso. A tal fine è stato sviluppato dal gruppo e-Lite il linguaggio DogOnt, un metamodello in formato OWL il cui scopo è permettere la descrizione di sistemi domotici. Attualmente DogOnt viene utilizzato per permettere la modellazione dell’ambiente e per introdurre capacità di ragionamento all’interno del gateway domotico DOG. Nel paragrafo successivo sarà approfondito il concetto di IDE per poi passare alla presentazione del linguaggio DogOnt e del gateway DOG. 2.1.1 Intelligent Domotic Environment Un ambiente domotico intelligente (IDE, Figura 2.1) è tipicamente composto da uno o più sistemi domotici, da un insieme di elettrodomestici e da un Home Gateway che permette di implementare politiche di interoperabilità e comportamenti intelligenti. 8 2 – Stato dell’arte Figura 2.1. Intelligent Domotic Environment Un sistema domotico contiene, tipicamente, diversi dispositivi domotici (attuatori per porte e finestre, luci, sensori, ecc.) ed un network gateway che, agendo da tunnel (inserendo quindi un’intestazione di rete), permette la trasmissione dei messaggi specifici del protocollo di basso livello, utilizzato dai dispositivi appartenenti al sistema domotico per la comunicazione, su di una tecnologia di interconnessione maggiormente versatile ed indipendente dal tipo di applicazione (es. Ethernet). I network gateway rappresentano quindi un punto di accesso per i sistemi domotici, ma non sono programmabili e non introducono funzionalità aggiuntive all’interno dell’IDE. Gli elettrodomestici possono essere “stupidi”, ovvero che possono essere controllati solo attivando o disattivando le prese elettriche alle quali sono collegati, o “smart”, cioè capaci di offrire funzionalità complesse e di controllare altri dispositivi attraverso uno specifico protocollo di comunicazione. La presenza nello stesso ambiente di molti sistemi domotici introduce delle problematiche di interoperabilità: dispositivi appartenenti a sistemi diversi non possono interagire per via delle diverse tecnologie e dei diversi protocolli utilizzati per comunicare. L’ home gateway è progettato con lo scopo di risolvere questa problematica: agisce da ponte tra le diverse tecnologie e supporta complesse interazioni tra i dispositivi. I compiti che un home gateway deve essere in grado di svolgere possono essere raggruppati in 3 livelli di priorità: 9 2 – Stato dell’arte 1. livello 1 : include tutte le feature necessarie per controllare diversi sistemi domotici utilizzando un unico protocollo di comunicazione di alto livello e un singolo punto di accesso; 2. livello 2 : definisce le feature necessarie per permettere l’automazione internetwork (interazione tra dispositivi appartenenti a sistemi domotici differenti); 3. livello 3 : riguarda gli aspetti di comportamento intelligente e di capacità di adattamento da parte dell’utente. Una casa domotica si definisce Intelligent Domotic Environment se il gateway soddisfa i requisiti di livello 1 e di livello 2 (quelli di livello 3 sono considerati relativi a funzionalità avanzate ed opzionali). 2.2 Il linguaggio DogOnt DogOnt è un linguaggio descrittivo di sistemi IDE basato sulla modellazione semantica. Con l’adozione di rappresentazioni ben note come le ontologie e fornendo strutture adeguate al ragionamento, DogOnt è in grado di affrontare problemi di interoperabilità consentendo di descrivere: • dov’è situato un dispositivo domotico; • le capacità e le funzionalità di un dispositivo; • le specifiche tecnologiche necessarie per interfacciarsi con un dispositivo; • le possibili configurazioni che un dispositivo può assumere; • come è 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’inferenza per fornire le funzionalità avanzate richieste al sistema domotico. DogOnt è composto di due parti: un’ontologia (DogOnt Ontology), espressa in OWL, il cui compito è formalizzare tutti gli aspetti di un IDE, e un insieme di regole (DogOnt Rules), che facilitano il processo di modellazione generando automaticamente gli stati e le funzionalità relativi ai dispositivi, e associandoli automaticamente alle opportune istanze attraverso regole sematiche. 10 2 – Stato dell’arte 2.2.1 DogOnt Ontology Un’ontologia è una rappresentazione formale di un’interpretazione condivisa di uno specifico dominio di conoscenza. Non esistendo l’ontologia perfetta, la rappresentazione di un determinato dominio può essere formalizzata in una moltitudine di modi e dipende dallo scopo per cui viene creata. Un’ontologia assume normalmente una struttura a grafo connesso con concetti e relazioni che li collegano. Le componenti fondamentali di una ontologia sono: Classi - insiemi, collezioni o tipi di oggetti; Attributi - proprietà, caratteristiche o parametri che gli oggetti possono avere e condividere; Relazioni - modi in cui gli oggetti possono essere messi in relazione gli uni con gli altri; Individui - istanze del modello. È costituita da un insieme di classi organizzate in una struttura gerarchica a grafo dove i collegamenti tra un nodo e l’altro rappresentano relazioni di ereditarietà (isA). Ad esempio, come si osserva nella Figura 2.2, la classe Garage (che descrive l’ambiente garage) è una specializzazione della classe BuildingEnviroment: eredita cioè le proprietà di ogni tipologia di ambiente incrementandole con le proprie caratteristiche specifiche. Anche se non rappresentate nella figura, sono possibili situazioni di ereditarietà multipla. Tutte le classi che descrivono un dispositivo (Computer, AlarmClock, ecc.), ad esempio, derivano sia dalla classe Controllable (che definisce le funzionalità di base di ogni dispositivo) sia da una classe NetworkComponent (BticinoComponent o KonnexComponent) che fornisce le specifiche caratteristiche di rete. La descrizione di ogni dispositivo è quindi composta da due componenti: una parte astratta che descrive il comportamento del dispositivo ed una parte tecnologica necessaria per la comunicazione. Questo tipo di approccio favorisce l’interoperabilità tra i dispositivi in quanto permette uniformità nel linguaggio utilizzato per la loro descrizione. L’insieme delle classi definite da DogOnt può essere diviso in 8 gruppi: • Building Thing: per modellare qualsiasi elemento controllabile e non controllabile. Si definisce elemento controllabile (o dispositivo) un elemento che può essere controllato dal sistema domotico (interrogato sul proprio stato o comandato). I dispositivi sono suddivisibili in due categorie: quelli appartenenti ad uno degli impianti domestici (la lampada, ad esempio, viene catalogata come appartenente all’impianto elettrico) e gli elettrodomestici (frigorifero, forno, hiFi, ecc.). Ogni dispositivo possiede diverse funzionalità (Functionality, rintracciate dalle relazioni hasFunctionality) e può assumere 11 2 – Stato dell’arte Figura 2.2. La struttura di DogOnt Ontology diverse configurazioni di stato (State, identificate mediante la relazione hasState). La quantità ed il tipo di stati e di funzionalità dipendono ovviamente dal dispositivo; in generale ogni elemento controllabile mette a disposizione almeno una QueryFunctionality che permette di fornire informazioni riguardanti la sua configurazione. Gli elementi non controllabili possono essere di 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. Contiene una descrizione delle varie tipologie di ambiente: vengono definiti gli ambienti giardino (classe Garden), garage (classe Garage) e appartamento (classe Flat). Ogni piano può contenere una o più stanze (cucina, camera da letto, bagno, ecc.); • Functionality: per modellare le operazioni che si possono effettuare su un dispositivo. Tutte le funzionalità definiscono i comandi necessari per modificare o per interrogare una specifica proprietà del dispositivo. Sono suddivise in 12 2 – Stato dell’arte diverse categorie in relazione al loro scopo: le ControlFunctionality modellano la capacità di controllare un dispositivo. Le NotificationFunctionality riguardano l’abilità di un dispositivo di segnalare un proprio cambiamento di stato. Le QueryFunctionality permettono di interrogare un dispositivo che fornirà, quindi, informazioni sulla propria configurazione attuale. Infine le funzionalità vengono organizzate anche in base a come modificano lo stato di un particolare dispositivo: le ContinuosFunctionality permettono la modifica delle caratteristiche di un dispositivo in maniera continua (ad esempio il volume di un impianto audio) e le DiscreteFunctionality sono utilizzate per quelle proprietà che possono assumere solo valori discreti. Le relazioni hasNotification e hasCommand contengono rispettivamente i riferimenti alle notifiche ed ai comandi che realizzano concretamente le funzionalità svolte dalle NotificationFunctionality e ControlFunctionality; • State: per modellare le configurazioni che un dispositivo può assumere. Come per le funzionalità, anche gli stati vengono classificati in base ai valori che possono assumere: i ContinuosState, che riguardano quelle proprietà che possono assumere valori continui, ed i DiscreteState, associati alle proprietà che assumono solo valori discreti; • NetworkComponent: per modellare le caratteristiche tecniche specifiche di ogni rete domotica. Attualmente i NetworkComponent definibili sono tre: KNXComponent utilizzato per dispositivi Konnex, BTicinoComponent dedicato ai dispositivi BTicino ed infine EliteComponent attribuito a tutti i dispositivi non reali (che non hanno componente di rete dichiarato); • Notification: per modellare tutte le notifiche che i dispositivi possono generare in seguito ad una variazione di stato; • Command: per modellare tutti i comandi per controllare ed interrogare i dispositivi; • StateValue: per modellare la tipologia di valori che gli stati dei dispositivi possono assumere: le classi ContinuosStateValue e DiscreteStateValue descrivono rispettivamente i valori continui e discreti che gli stati possono assumere. Gli stati ContinuosState e DiscreteState sono associati alle classi ContinuosStateValue e DiscreteStateValue (relazione hasStateValue). Si consideri, come esempio riassuntivo, la rappresentazione di una lampada ad intensità luminosa regolabile. Questo dispositivo, nel formato OWL utilizzato da DogOnt, è descritto dalla classe DimmerLamp che a sua volta deriva, nell’ordine indicato, dalle classi Lamp, Lighting, HousePlant e Controllable. La presenza di questa scala gerarchica permette al dispositivo DimmerLamp di ereditare le 13 2 – Stato dell’arte Figura 2.3. Esempio di interconnessione tra una lampada ed uno switch funzionalità definite nelle super classi: dalle classi Lamp, Controllable e HousePlant vengono ereditate rispettivamente le funzionalità OnOffFunctionality (che a 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 cambiamento di stato della lampada). La classe DimmerLamp è inoltre caratterizzata dalla funzionalità LightRegulationFunctionality e dallo stato LightIntensityState: LightRegulationFunctionality definisce i comandi StepUpCommand, StepDownCommand e SetCommand(value) per governare l’incremento ed il decremento dell’intensità luminosita, LightIntensityState tiene traccia, in percentuale, del valore dell’intensità luminosa. La Figura 2.3 mostra, come esempio, la descrizione OWL schematica di un dispositivo lampada (istanza della classe DimmerLamp) controllata da uno switch (OnOffSwitch). Il funzionamento, la configurazione attuale e le proprietà della lampada sono descritte dalle relazioni: 14 2 – Stato dell’arte • hasState: relazione che contiene il riferimento ad un’istanza della classe LighIntensityState che, tramite il valore LightIntensityStateValue, tiene traccia del valore corrente dell’intensità luminosa (nell’esempio 77%); • isIn: relazione che descrive la posizione dell’oggetto nell’ambiente. Nell’esempio la lampada è inserita in una LivingRoom; • hasFunctionality: relazione che contiene il riferimento ad un’istanza di una classe funzionalità. Ogni lampada di tipo DimmerLamp è caratterizzata dal possedere tre relazioni hasFunctionality che rispettivamente contengono un riferimento ad una istanza della classe: – StateChangeNotificationFunctionality: definisce la notifica per segnalare un cambiamento di stato; – OnOffFunctionality: definisce i comandi per accendere e spegnere la lampada; – LightRegulationFunctionality: definisce i comandi per regolare l’intensità luminosa della lampada. Il controllo che il dispositivo OnOffSwitch esercita sulla lampada è descritto dalle relazioni controlledObject e generatesCommand : la prima contiene il riferimento all’oggetto controllato (in questo caso la lampada), la seconda viene inserita all’interno delle istanze delle notifiche OnNotification e OffNotification. Nell’esempio si vuole realizzare la seguente interazione: quando lo switch è in posizione “Off” la lampada deve essere spenta, quando è in posizione “On” la lampada deve essere accesa. A tal fine nelle notifiche OnNotification e OffNotification dello switch vengono inserite le relazioni generatesCommand riferite rispettivamente ai comandi OnCommand e OffCommand della lampada. In questo modo quando si imposta lo switch 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) è 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 esempio le politiche di comportamento intelligente, vengono demandati a terze parti: i bundle, che possono essere dinamicamente caricati nel framework OSGi a run-time. Il grande vantaggio che ne deriva è l’elevata flessibilità del sistema: un bundle può 15 2 – Stato dell’arte essere infatti aggiunto all’architettura in modo da estenderne le sue capacità, può essere successivamente aggiornato, modificato o rimosso senza dover riavviare l’intero framework. 2.3.1 Architettura Come illustrato nella Figura 2.4, l’architettura modulare del gateway DOG è composta da un insieme di bundle organizzati in 4 livelli funzionali: Device Management, DeviceControl, API e DogLibrary. Figura 2.4. DOG Architecture 1. Device Management contiene i bundle che realizzano la Device Access Specification, specifica che definisce la logica e le entità (bundle) che devono essere realizzate per implementare il supporto all’auto-detection dei dispositivi presenti nell’ambiente e per permettere l’hot-plug/unplug di nuovi dispositivi. È costituito da: • DogDeviceManager : rileva la registrazione di servizi Device e associa questi dispositivi all’opportuno Driver service; • DogDevice: è l’oggetto Dog che rappresenta la classe dispositivi definita in DogOnt. Si tratta del software proxy del dispositivo reale il cui compito è interfacciare il dispositivo con l’opportuno Driver service; 16 2 – Stato dell’arte • Driver : contiene i bundle (Driver service) necessari per interfacciarsi con i vari tipi di rete domotica. Ogni tecnologia di rete viene gestita da uno specifico driver che consente l’accesso agli aspetti specifici del protocollo attraverso un’interfaccia di alto livello comune per tutte le tecnologie. Questo permette uniformità nella rappresentazione dei diversi dispositivi. Attualmente è 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 fisicamente non disponibili, consentendo cosı̀ di utilizzare il software anche in assenza di un ambiente domotico reale, cioè in simulazione. • HouseModel : bundle che contiene l’istanza dell’ontologia DogOnt che descrive la struttura, le proprietà e le capacità dello specifico ambiente IDE nel quale il gateway è installato. Questo modulo sfrutta le informazioni derivanti dalle classi e dalle istanze di DogOnt per implementare funzionalità di ragionamento e politiche intelligenti per l’ambiente. In particolare HouseModel permette la generazione delle regole necessarie per realizzare l’interoperabilità tra i dispositivi presenti: (a) vengono individuate le relazioni controlledObject e generatesCommand 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 interroga il modulo HouseModel al fine di ottenere le regole di interoperabilità che deve eseguire. In risposta a questa richiesta il modulo HouseModel analizza il modello DogOnt per individuare le associazioni presenti tra i dispositivi: per ogni coppia notifica-comando viene creata una regola di interoperabilità. Le regole prodotte vengono infine comunicate al bundle DogRules. 2. Device Control include i bundle dedicati a controllare ed a monitorare i dispositivi. È costituito da: • DogStateMonitor : fornisce le informazioni riguardanti lo stato corrente dei dispositivi connessi a Dog; • DogExecutor : permette l’esecuzione di comandi, ricevuti da altri bundle, sui dispositivi attraverso la chiamata dei metodi presenti negli oggeti DogDevice. Grazie al modulo HouseModel, DogExecutor verifica la correttezza sintattica e semantica dei comandi ricevuti; 17 2 – Stato dell’arte • DogScheduler : offre un servizio centralizzato per schedulare l’esecuzione dei comandi e le operazioni di monitoraggio dei dispositivi. Sfrutta i moduli DogExecutor e DogStateMonitor; • DogRuleEngine: fornisce un ambiente di esecuzione per le regole di interoperabilità (JBoss Rules) definite dall’utente. Questo modulo riceve gli eventi generati dall’ambiente e verifica se ci sono delle regole da eseguire. 3. API include bundle che definiscono le interfacce di programmazione (indipendenti dalla tecnologia) per permettere l’accesso ai servizi forniti da Dog ad applicazioni esterne e plug-in OSGi: • DogApi : permette ad applicazioni basate sulla piattaforma OSGi di ottenere informazioni sulla configurazione dell’ambiente, di riceve eventi provenienti dall’ambiente e di inviare comandi ai dispositivi gestiti da DOG; • DogXmlEndPoint: fornisce un endpoint XML-RPC per i servizi offerti dal modulo DogApi, questo permette l’accesso a DOG da parte di applicazioni non costruite sulla base di OSGi o di Java. 4. DogLibrary definisce le interfacce che permettono l’interazione tra i vari moduli che compongono il gateway. L’interazione tra diversi bundle è basata sullo scambio di oggetti DogMessage ognuno dei quali è composto dai campi typedeclaration, che identifica il tipo di messaggio, e payload che contiene il corpo del messaggio. 2.4 Punti critici e aree di possibile miglioramento I punti critici dei sistemi domotici basati sull’architettura DogOnt+Dog sono essenzialmente 2: • difficoltà nella creazione del modello di un singolo appartamento/edificio; • capacità computazionali richieste da DOG. Il primo punto riguarda il fatto che il funzionamento del gateway DOG si basa sul modello dell’ambiente contenuto nel bundle HouseModel ed espresso nel formato OWL. Produrre un documento istanza dell’ontologia DogOnt è molto complesso: il formato OWL richiede di organizzare le informazioni in una maniera poco intuitiva, utilizzando costrutti e ridondanze tediose. Il progettista che configura questi impianti domotici si trova nella situazione di dover creare un file di configurazione direttamente nel formato OWL (attraverso l’uso di software come Protégé) e questo crea molte difficoltà: la complessità del processo richiede un’alta specializzazione 18 2 – Stato dell’arte che esula dalle capacità dell’installatore medio. Per ridurre questo problema occorre produrre degli strumenti il cui compito è facilitare la produzione di un modello OWL. Il lavoro di questa tesi si pone l’obiettivo di fornire al progettista un applicazione che, attraverso un’interfaccia grafica semplice, consente di sviluppare il modello di un sistema domotico senza avere conoscenza approfondita del formato OWL. Il secondo punto è relativo alle difficoltà nell’elaborare informazioni complesse e nell’applicare sistemi inferenziali in tempo reale su sistemi con capacità computazionali ridotte. In questo caso il modulo HouseModel viene sostituito dal modulo SimpleHouseModel che contiene una rappresentazione statica e semplificata dell’ambiente (ottenuta mediante il processamento del modello di ontologia durante la fase di configurazione del gateway). Tutti i processi inferenziali vengono eseguiti off-line: DOG, durante la sua esecuzione, svolge i suoi compiti sfruttando le informazioni statiche 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 per permettere l’interoperabilità tra dispositivi domotici diversi e l’aggiunta di funzionalità avanzate. Se da un lato DOG incrementa le capacità del sistema domotico (trasformandolo in un IDE, Intelligent Domotic Environment), dall’altro introduce delle problematiche di configurazione non banali. Per il suo funzionamento, infatti, DOG si appoggia al modello DogOnt che descrive l’ambiente. L’istanza dell’ontologia, quindi, è specifica del contesto: per ogni impianto domotico in cui viene installato DOG occorre creare il file di ontologia che lo descrive. La scelta di utilizzare DogOnt come formato di descrizione è dovuta al fatto che è una rappresentazione che permette al gateway DOG di attuare politiche intelligenti per l’ambiente: esistono sistemi inferenziali che, interrogando l’ontologia, consentono l’estrazione di informazioni avanzate necessarie al gateway per poter operare. Il problema di questa rappresentazione è che produrre un documento istanza di DogOnt è molto complesso: il formato OWL richiede infatti di organizzare le informazioni in una maniera poco intuitiva, utilizzando costrutti e ridondanze tediose. Il dover descrivere un ambiente domotico direttamente in formato OWL (attraverso l’uso di software come Protégé) crea molte difficoltà al progettista: richiede di essere fortemente specializzati ed è dispendioso di tempo. Questo approccio frena quindi lo sviluppo e l’installazione di ambienti domotici basati su DOG in quanto è molto difficile produrre un file di configurazione corretto ed è comunque pensabile solo per la descrizione di sistemi semplici, dove gli elementi e le interazioni presenti siano pochi. Per alleggerire questa problematica è 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 struttura più semplice rispetto al formato OWL e permette al progettista di descrivere l’ambiente inserendo solo le informazioni essenziali. È compito del tool ricevere il file XML come input, validarlo, analizzarlo per estrarre le informazioni ed infine produrre le relative istanze di DogOnt. Il tool si prende quindi carico di introdurre tutte le restanti parti necessarie che, da un punto di vista umano, risultano essere complicate, ridondanti e tediose. Quest’idea rappresenta di certo un passo avanti ma non può essere considerata come la soluzione definitiva per il problema: anche se il formato proposto è più semplice ed intuitivo, il progettista resta comunque vincolato alla descrizione testuale dell’ambiente ed alla conoscenza del formato XML utilizzato. Il lavoro di tesi mira a risolvere queste problematiche andando a realizzare un ambiente di sviluppo integrato per la progettazione di sistemi domotici intelligenti basati sulla modellazione semantica DogOnt e sul gateway DOG: l’applicazione DogDomoticIde. Il progettista di sistemi domotici, attraverso l’uso di questo programma, ha la possibilità di descrivere un ambiente domotico utilizzando una semplice interfaccia grafica. Nel seguito verranno organizzati e trattati nel dettaglio i requisiti definiti per questa applicazione. 3.2 Requisiti I requisiti alla base della progettazione dell’applicazione DogDomoticIde possono essere suddivisi in 2 categorie: • requisiti funzionali : sono le funzionalità che devono essere rese disponibili dall’IDE; • requisiti non funzionali : caratteristiche strutturali e/o di implementazione richieste all’applicazione che non hanno impatto diretto sull’utilizzatore e sull’output prodotto. 3.2.1 Requisiti funzionali I requisiti funzionali vengono catalogati in relazione alla loro priorità. Il lavoro di tesi ha come obiettivo l’implementazione di tutti i requisiti funzionali primari. Le altre categorie (requisiti funzionali secondari e sviluppi futuri) sono considerati, per il 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 tradizionali operazioni 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, a partire da librerie di componenti (passivi o attivi) che possono essere inseriti nell’ambiente; 3. editing degli aspetti grafici (layout 2D) e dei meta-dati (elenchi di proprietà) 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 domotico inserendo, cancellando e modificando i vari elementi; • Palette View : vista che contiene la libreria degli elementi inseribili nell’impianto domotico, organizzati in relazione alla loro natura; • Property View : vista che permette di modificare le proprietà dell’elemento selezionato; 5. descrizione delle interazioni che intercorrono tra i dispositivi presenti nell’ambiente; 6. esportazione delle informazioni derivanti dal progetto in un formato utilizzabile direttamente dal gateway DOG. Requisiti funzionali secondari 1. inserimento nel layout dell’applicazione di una Summary View, vista ad albero che contiene un riepilogo degli oggetti inseriti nell’impianto; 2. esportazione delle informazioni derivanti dal progetto direttamente nel formato OWL; 3. costruzione di nuovi elementi a run-time (riferiti alle classi già esistenti in DogOnt) consentendo il loro inserimento nella libreria personale dell’utilizzatore; 4. inserire controlli di validazione sugli oggetti inseriti nell’impianto domotico: un oggetto è considerato valido se tutte le sue proprietà sono compilate ed assumono un valore sintatticamente corretto; 22 3 – Obiettivi 5. permettere la creazione di una struttura abitativa più complessa: appartamenti non rettangolari, inserimento di giardini, garage e altri ambienti complementari; 6. aggiornamento a run-time dell’ontologia DogOnt di riferimento, con un conseguente aggiornamento della palette degli elementi inseribili nel sistema domotico; 7. funzionalità di stampa su carta. Sviluppi futuri 1. simulazione dell’ambiente domotico creato; 2. aggiunta di una vista contenente la rappresentazione grafica 3D dell’ambiente progettato; 3. supporto al protocollo SVN: update e download di file di progetto da un repository server. 3.2.2 Requisiti non funzionali L’applicazione dovrà essere costruita sulla base della piattaforma Java Eclipse RPC. Proprio per questa ragione ogni scelta progettuale dovrà tenere conto del modello di sviluppo fornito da Eclipse. Le linee guida possono essere riassunte in 3 punti: 1. programmazione plug-in based : l’applicazione è strutturata come composizione di plug-in ognuno dei quali fornisce funzionalità diverse. I plug-in vengono classificati in 2 categorie: i core plug-in, che definiscono le funzionalità di base del workbench e gli add-on plug-in, che contengono funzionalità aggiuntive; 2. interfaccia grafica perspective-based : il contenuto dell’interfaccia grafica e l’organizzazione delle sue varie parti viene stabilita da una prospettiva (perspective). Le prospettive possono essere selezionate dall’utente in base al task che deve eseguire. I core plug-in contengono la definizione della prospettiva di base dell’applicazione, gli add-on plug-in possono definire prospettive aggiuntive relative alle funzionalità che realizzano; 3. viste multiple: ogni plug-in può definire un insieme di viste che possono essere inserite insieme nella stessa prospettiva in relazione al task che permettono di svolgere. 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’interno di un sistema domotico, in relazione alla versione di ontologia DogOnt di riferimento. I vari elementi sono organizzati in base alla loro natura (elementi architetturali, di arredamento, dispositivi) e ognuno di essi è descritto in base ad un insieme di proprietà (nome, tipo, descrizione, funzionalità che possiede, configurazioni che può 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 e modifica. 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 elementi inseriti nel progetto corrente: si tratta di una rappresentazione ad albero dove ogni elemento viene rappresentato, di default, dalla sua icona e dal suo nome. La Palette View permette all’utente di inserire all’interno del proprio progetto i componenti presenti nella libreria (Component Library). Infine la Property View che è composta da un insieme di finestre organizzate in tab ognuna delle quali permette l’editing di una categoria specifica di proprietà dell’oggetto selezionato; Perspective - Definisce l’aspetto di base che l’applicazione deve avere. L’interfaccia grafica deve contenere la Summary View, la Property View, la Palette View e la Design View (definita nel Design plug-in). Design plug-in Questo plug-in fornisce le funzionalità necessarie per rappresentare un impianto domotico. Definisce la Design View, vista che permette di costruire ambienti, di istanziare 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 View permettendo la modifica delle proprietà dell’oggetto selezionato. 24 3 – Obiettivi 3.3 Analisi delle possibili soluzioni Le tipologie di soluzioni analizzate per lo sviluppo dell’applicazione DogDomoticIde sono 2: • estensione di un ambiente CAD 2D: l’idea è quella di utilizzare come base per l’applicazione un progetto Open Source (come ad esempio CADEMIA o SweetHome3D) che realizza le funzionalità di editing 2D permettendo di realizzare graficamente un ambiente domestico. In questo caso il lavoro di tesi consiste nell’integrare il progetto con le funzionalità di modellazione che permettono la rappresentazione di un ambiente domotico basato sull’architettura DOG+DogOnt: modello dati basato sull’ontologia DogOnt, descrizione delle interazioni, editing delle proprietà, ecc. Vantaggi - funzionalità di disegno 2D già realizzate e di buona qualità. Svantaggi - difficoltà nell’integrare il modello dati basato sull’ontologia DogOnt: è necessario sostituire la struttura dati sulla quale si basano queste applicazioni con il nuovo modello. Questo comporta la modifica o addirittura la riscrittura di buona parte del codice già presente. • estensione di un ambiente di modellazione: questa soluzione consiste nell’utilizzare degli strumenti che consentono di rappresentare un modello dati e di generare automaticamente, su di esso, un applicazione editor di base. Il plug-in di Eclipse GMF realizza queste funzionalità: fornisce delle utility che consentono l’auto-generazione di un’applicazione editor relativa ad un modello dati definito dal programmatore. Il lavoro di tesi consiste nel creare il modello dati basato su DogOnt, utilizzare le utility fornite da GMF per la generazione dell’applicazione di base e personalizzare il codice al fine introdurre le funzionalità desiderate. Vantaggi - supporto per la creazione del modello dati, editor di base generato automaticamente, soluzione che permette uno sviluppo incrementale basato su plug-in. Svantaggi - le funzionalità di disegno 2D sono di base, il progetto generato è complesso e difficilmente estendibile. La soluzione adottata è quella basata sull’uso del plug-in GMF. La ragione di questa scelta è legata al fatto che l’obiettivo primario dell’applicazione è quella di fornire un ambiente di modellazione per sistemi domotici anche con capacità di disegno 2D limitate e di base. Il plug-in EMF fornisce inoltre gli strumenti che semplificano il processo di aggiornamento del modello dati in relazione, ad esempio, all’evoluzione dell’ontologia DogOnt. Infine la generazione automatica del codice realizza, da sola, buona parte delle funzionalità di base richieste. 25 Capitolo 4 Strumenti utilizzati Per lo sviluppo dell’applicazione DogDomoticIde viene utilizzata la piattaforma Eclipse, essendo quest’ultima un ambiente di sviluppo dotato di plug-in addizionali molto utili per la realizzazione degli obiettivi di questa tesi. In questo capitolo verranno quindi introdotti Eclipse ed i plug-in EMF, GEF e GMF che consentono lo sviluppo di tool ed editor grafici, basati su di un modello dati definito dal programmatore, limitando la necessità di scrivere codice per molti dei casi più comuni. 4.1 La piattaforma Eclipse La piattaforma Eclipse è un insieme di componenti per lo sviluppo di tool ed applicazioni di ogni genere. Nata come evoluzione dell’ambiente di sviluppo Visual Age di IBM, è diventata Open Source nel 2001 e dal 2003 viene controllata della Eclipse Foundation, un’organizzazione no profit indipendente. I motivi del suo enorme successo e della sua popolarità risiedono sia nella sua natura aperta, sia nella sua versatilità. Eclipse non è infatti strettamente dipendente da Java e non è nemmeno limitato al settore degli ambienti di sviluppo. In particolare, grazie al sottoinsieme di componenti denominato RCP 1 , è possibile realizzare applicazioni per qualunque tipo di funzione (tool di supporto per l’analisi di molecole chimiche, strumenti finanziari, ecc.). Questa versatilità è accentuata dall’uso di Eclipse come integration point: i tool sviluppati con questa piattaforma possono essere facilmente integrati tra loro, anche se realizzati da produttori di software diversi; è inoltre piuttosto semplice suddividere la programmazione di un applicativo in più moduli, per poi integrarli a lavoro finito. La Figura 4.1 mostra i componenti principali della piattaforma: alla base di tutto viene posizionato il Platform Runtime, un kernel che fornisce tutte le funzionalità 1 Rich 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, sia quelle standard, come il Workbench (l’interfaccia grafica) ed il Workspace (lo spazio contenente i file e i progetti dell’utente), sia eventuali plug-in addizionali installati. La particolarità di quest’architettura è che, ad eccezione del Platform Runtime, tutti i componenti, anche quelli forniti di default, sono di fatto dei plug-in. Un plug-in è la più piccola unità funzionale sviluppabile e distribuibile separatamente. I plug-in di Eclipse sono costituiti da codice Java (raccolto in un archivio JAR), due file di manifesto (manifest.mf e plug-in.xml) e altre risorse di vario genere (immagini, file di help, ecc.). Un tool, specialmente se di dimensioni consistenti, può essere costituito da più plug-in ognuno dei quali, a sua volta, può essere frammentato in più parti. Mentre il file manifest.mf definisce le dipendenze a runtime di un plug-in, il file plugin.xml definisce le varie extension ed extension point, cioè le integrazioni con gli altri plug-in. I plug-in vengono rilevati all’avvio dal Platform Runtime che, leggendo i loro manifesti, crea il Plug-in Registry, un registro di informazioni che viene reso disponibile a runtime tramite API (l’interfaccia di programmazione), consentendo cosı̀ l’aggiunta o la rimozione di plug-in durante l’esecuzione della piattaforma. 27 4 – Strumenti utilizzati Grazie ai file di manifesto è possibile inserire nel Plug-in Registry tutte le informazioni riguardanti extension ed extension point senza che sia necessario caricare in memoria tutti i plug-in. Con questo meccanismo si ottengono diversi vantaggi: facilità di integrazione grazie agli extension point, flessibilità e dinamicità grazie alla disponibilità a runtime del Plug-in Registry (cosa che, tra l’altro, consente di verificare se un aggiornamento 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 è un framework per la generazione di tool ed applicazioni basati su un modello dati strutturato, incentrato sul concetto di Model-Driven Architecture Development. L’obiettivo di questo framework è quello di fornire un punto di incontro tra il mondo della modellazione e quello della programmazione. La funzionalità principale di EMF è quella di ricevere come input un modello (sotto forma di diagramma UML, schema XML, interfacce Java annotate) e fornire come output una serie di classi Java che realizzano i vincoli, le relazioni e le associazioni descritte nel modello di partenza. Il lavoro del programmatore consisterà innanzitutto nel creare il modello, e quindi, dopo aver generato il codice tramite EMF, nell’implementare i comportamenti specifici che il modello non è in grado di rappresentare (ad esempio la funzionalità di un metodo in una classe Java). Le parti più ripetitive e tediose (metodi getter e setter, gestione delle relazioni tra oggetti, gestione di eventi, ecc.) vengono invece create in maniera automatica da EMF. Oltre alla generazione di codice EMF fornisce altre funzionalità come il supporto alla personalizzazione del codice, una Reflective API per generare dinamicamente modelli, serializzazione e deserializzazione dei dati (in formato XMI) e la possibilità di generare semplici editor grafici. 4.2.1 Componenti L’Eclipse Modeling Framework è costituito da tre componenti principali: EMF Core, EMF Edit ed EMF Codegen. EMF Core include la definizione del metamodello ECore: il formato in cui vengono convertiti tutti i modelli utilizzati. È interessante notare che l’implementazione di 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 quella delle API Java: la classe di base è EObject (equivalente a java.lang.Object), 28 4 – Strumenti utilizzati Figura 4.2. La gerarchia del modello ECore mentre, a scendere nell’albero, vengono posizionate le varie classi che rappresentano oggetti 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 operazioni riflessive sugli attributi dell’oggetto. Inoltre EObject estende l’interfaccia Notifier, predisponendo quindi ogni oggetto a inviare notifiche a osservatori registrati in caso di modifica del proprio stato. EMF Edit fornisce classi di supporto basate su JFace 2 che consentono la visualizzazione di oggetti del modello. Mette inoltre a disposizione un framework di 2 Tool per interfacce grafiche dotato http://www.eclipsepluginsite.com/jface.html di 29 funzionalità avanzate e di alto livello, 4 – Strumenti utilizzati comandi che permettono la modifica delle proprietà degli oggetti istanziati, con il supporto alle operazioni di undo e redo. L’ultima componente di EMF è EMF Codegen le cui funzionalità sono principalmente 2: fornire un framework estensibile per l’importazione di modelli (in futuro si prevede l’aggiunta del supporto ad altri formati di modello) ed offrire la generazione vera e propria del codice per i componenti Core ed Edit. 4.2.2 Definire un modello EMF Il primo passo per utilizzare EMF è l’importazione di un modello dati. Allo stato attuale sono quattro i formati che si possono utilizzare: • XMI : si può definire il proprio modello interamente in XMI, cosı̀ com’è definito il meta-modello ECore; • XMLSchema: se si ha già a disposizione un modello espresso in questo formato è possibile importarlo in EMF. Questa soluzione ha lo svantaggio di essere meno espressiva rispetto ad un modello descritto in UML (ad esempio XMLSchema non sono supporta i riferimenti bidirezionali); • UML: si possono importare direttamente class diagram UML: è supportato il formato Rational Rose; • interfacce Java annotate: se non si dispone di un editor grafico UML, o se non si è pratici del linguaggio e si è più propensi a scrivere codice, questa opzione risulta un’interessante alternativa. Nell’ambito di questa tesi il modello dati per EMF è stato sviluppato utilizzando la tecnica delle interfacce Java annotate, per questa ragione vale la pena analizzarla con più attenzione. Un programmatore che scelga di utilizzare questa soluzione deve scrivere le interfacce per le classi di cui avrà bisogno, avendo l’accortezza di commentarle con speciali tag definiti da EMF. Queste informazioni sono importanti in quanto permettono ad EMF Codegen di riconoscere il modello creato per poi tradurlo nel formato ECore. L’uso di interfacce Java annotate permette quindi di esprimere le caratteristiche del modello dati: il programmatore, per ogni interfaccia, inserisce gli attributi che ne descrivono il contenuto. Se, ad esempio, un elemento del modello contiene la proprietà “name” allora, nella relativa interfaccia, il programmatore dovrà inserire la linea di codice String getName che descrive il fatto che quell’elemento contiene un attributo di nome “Name” di tipo “String”. Per le relazioni che intercorrono tra una classe e l’altra si sfruttano i concetti di ereditarietà e di contenimento. 30 4 – Strumenti utilizzati Figura 4.3. Il funzionamento di EMF Una volta completata la stesura delle interfacce annotate, si utilizza il package di interfacce come input per EMF che provvede all’auto-generazione dei file ecore e genmodel. Il primo contiene la rappresentazione del modello dati nel formato ECore. Tale file è personalizzabile sfruttando l’editor ECore fornito da EMF, che rappresenta il modello in un albero e consente di aggiungere, rimuovere o modificare classi e attributi. Il file genmodel contiene invece impostazioni utili ai fini della generazione di codice. Dopo aver descritto il modello si può avviare la generazione del codice, ottenendo una versione aggiornata delle interfacce (essenzialmente per fare in modo che tutte le classi estendano EObject). Viene inoltre generata una classe implementazione per ogni elemento descritto nel modello dati. I metodi, il cui comportamento non può essere modellato in partenza, vengono prodotti sotto forma di skeleton (sono dichiarati ma vuoti) pronti per l’implementazione da parte del programmatore. Osservando la Figura 4.3 notiamo che oltre al modello Java (che è sia un input che un output) vengono generati altri due componenti: Java Edit e Java Editor. Java Edit contiene le classi di supporto fornite da EMF Edit utilizzabili per creare editor indipendenti da Eclipse. Java Editor si appoggia su Java Edit e contiene le classi che realizzano un editor avviabile in una nuova workbench window di Eclipse senza necessitare di alcuna modifica. 31 4 – Strumenti utilizzati Viene infine generato un quarto componente (non mostrato in figura) che ha lo scopo di fornire un insieme di metodi di test. Anche in questo caso, non essendo il comportamento modellato, si tratta di skeleton che tuttavia facilitano il compito per 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 istanziare gli oggetti facenti parte del modello; la classe Package, invece, consente l’accesso ai meta-dati del modello. 4.3 Graphical Editing Framework Lo scopo di questo plug-in è facilitare lo sviluppo di rappresentazioni grafiche di modelli esistenti, creando editor dotati di funzionalità quali drag & drop, copia/incolla, undo e redo. Una classica applicazione GEF consente di disegnare diagrammi di vario tipo, con la possibilità di collegare le figure, ridimensionarle e spostarle. 4.3.1 Componenti GEF si basa sul paradigma Model-View-Controller. Il modello deve essere definito in codice Java senza vincoli particolari, GEF si occupa di realizzare le parti View e Controller. A tal fine è composto da due framework: Draw2D, incaricato della parte grafica, ed il Graphical Editing Framework vero e proprio che si occupa di tutte le restanti funzionalità. • Draw2D è una libreria grafica utilizzabile indipendentemente sia da GEF che da Eclipse. Offre grande flessibilità nella gestione delle figure: forme, colori, contorni e layout si possono impostare con grande libertà e le figure possono essere annidate. Vengono offerte anche opzioni particolari per le connessioni (che a loro volta sono un tipo particolare di figura), con la possibilità di definire punti di ancoraggio e router (figura con punti di ancoraggio multipli); • Graphical Editing Framework si occupa di definire i Controller dell’applicazione: le classi EditPart, componenti principali di un’applicazione GEF, il cui compito è mappare le figure Draw2D sugli oggetti del modello dati. Le EditPart devono essere create dal programmatore implementando la classe astratta AbstractEditPart, e istanziate attraverso una factory. In genere occorre una EditPart per ogni oggetto del modello dati. A seconda che si abbia a che fare con una figura vera e propria oppure con una connessione tra figure, si possono usare le sottoclassi GraphicalEditPart e 32 4 – Strumenti utilizzati ConnectionEditPart (quest’ultima non è altro che una GraphicalEditPart con l’aggiunta dei campi source e target che definiscono il collegamento). Le operazioni di editing effettuate dall’utente vengono gestite da altri componenti: 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). Il programmatore deve creare uno specifico comando (che implementa la classe astratta Command) per ogni operazione che intende svolgere sul modello. Una classe EditPolicy ha lo scopo di definire il comportamento di una specifica EditPart (scegliendo quali comandi eseguire) in relazione agli eventi provenienti dall’interfaccia grafica. Le richieste sono gli oggetti di comunicazione utilizzati dal framework per richiedere alle EditPart un comportamento specifico. La CreateRequest, ad esempio, viene utilizzata quando è necessario creare un oggetto, la LocationRequest quando si vuole tenere traccia della posizione di un oggetto. La catena di eventi necessari per interagire con le EditPart può quindi essere riassunta in questa maniera: 1. generazione di una richiesta da parte del framework in relazione al comportamento dell’utente o, più in generale, agli eventi provenienti dall’interfaccia grafica; 2. la richiesta viene raccolta dall’EditPart che l’analizza ed esegue l’EditPolicy che realizza il comportamento desiderato; 3. l’EditPolicy esegue, infine, i comandi necessari per effettuare le modifiche desiderate sul modello. 4.3.2 Usare GEF con EMF Dopo aver analizzato separatamente EMF e GEF viene naturale pensare ad un loro uso combinato: da un lato il plug-in GEF, che offre buone capacità dal punto di vista grafico ma che necessita di un modello dati già pronto, dall’altro EMF, che agevola la costruzione di un modello dati ma che fornisce solo funzionalità basilari per l’editing grafico. Sfruttando gli aspetti positivi di entrambi si può pensare di partire da un modello UML (o interfacce Java annotate), generare il modello dati e su esso costruire EditPart e figure Draw2D, eventualmente integrando lo stack di comandi EMF con quello di GEF. Purtroppo questi due framework non sono nati per cooperare, e ci sono alcune incompatibilità (prima fra tutte quella fra i due stack di comandi) che rendono tutt’altro che banale la loro integrazione. 33 4 – Strumenti utilizzati Il framework GMF si pone l’ambizioso obiettivo di risolvere queste problematiche, con lo scopo di minimizzare il lavoro che un programmatore deve fare per costruire un editor grafico che si appoggia su un modello dati. 4.4 Graphical Modeling Framework Anche GMF, cosı̀ come GEF, è un framework il cui scopo è semplificare la realizzazione di editor grafici basati su modelli. Mentre GEF prevede una consistente parte di stesura di codice da parte del programmatore, GMF nasce con lo scopo di rimuovere quasi completamente la fase di scrittura del programma, sostituendola con la definizione di una serie di modelli intermedi per arrivare alla generazione automatica del codice dell’editor. Il concetto di base è quello di sfruttare l’idea di generazione automatica del codice di EMF per applicarla a GEF. Partendo da un modello del dominio dell’applicazione e definendo una serie di altri modelli intermedi, GMF è in grado di generare tutte quelle classi che un programmatore che utilizza GEF dovrebbe implementare manualmente: EditPart, comandi, EditPolicy. La Figura 4.4 mostra i passi necessari per creare un editor grafico utilizzando GMF. Per prima cosa è necessario disporre di un modello del dominio, rappresentato nel formato ECore: per farlo è sufficiente utilizzare EMF, importando il proprio modello 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 e la composizione degli oggetti grafici istanziabili all’interno dell’editor. Gli oggetti possono essere inoltre definiti come Compartment, cioè con la capacità di contenere al loro interno altri elementi; 2. Tooling Definition Model: serve a definire quali strumenti saranno a disposizione dell’utente nella palette dell’editor. Tipicamente per ogni oggetto viene definito un CreationTool, che ha come effetto quello di inserire nella palette una voce relativa all’oggetto in questione; 3. Mapping Definition Model: si occupa dell’unione del modello del dominio con il Tooling Definition Model ed il Graphical Definition Model. Una delle funzioni svolte da questo modello è quella di creare le associazioni tra i tool contenuti nella palette dell’applicazione e gli oggetti grafici. Per la definizione di questi modelli, GMF mette a disposizione i corrispettivi meta-modelli che, a loro volta, non sono altro che modelli ECore. Il meta-modello 34 4 – Strumenti utilizzati Figura 4.4. Il workflow di GMF grafico, ad esempio, definisce la classe Canvas, che può contenere un numero arbitrario di figure (classe Figure) che, a loro volta, hanno una posizione, una dimensione ed una certa composizione grafica. Il programmatore, usando queste classi, potrà realizzare la rappresentazione grafica desiderata. Una volta completati questi tre modelli il lavoro è sostanzialmente finito: GMF genererà automaticamente il Generator Model da cui, dopo aver eventualmente personalizzato alcuni parametri, si passerà direttamente alla generazione del codice. Sfruttando EMF Edit e GEF, GMF creerà comandi, EditPart, provider di contenuti e tutto il necessario per realizzare un editor funzionante. L’editor creato offrirà all’utente una serie di caratteristiche più avanzate rispetto a quelle fornite da un’applicazione costruita mediante GEF: zoom, assistenti per la creazione del diagramma, anteprima di stampa, supporto per la clipboard e altro ancora. 35 Capitolo 5 Generazione dell’applicazione DogDomoticIde 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 di DogDomoticIde. In questo capitolo sarà descritta la prima fase, cioè verranno spiegati nel dettaglio tutti gli step e le soluzioni che portano, come conclusione, alla generazione dell’applicazione di base. Le operazioni di adattamento/estensione dell’applicazione generata saranno presentate nel capitolo successivo. 5.1 Struttura della soluzione Il plug-in GMF consente di generare in automatico la maggior parte del codice necessario all’applicazione, sulla base di un modello dati e di altri modelli intermedi che definiscono le proprietà grafiche e funzionali di base dell’applicazione stessa. Il procedimento che porta alla generazione dell’applicazione può essere suddiviso in 3 parti: 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’ontologia DogOnt, dalla quale si ricavano l’elenco e le proprietà di tutti gli elementi istanziabili 36 5 – Generazione dell’applicazione DogDomoticIde all’interno di un ambiente domotico, e la struttura del modello dati (DataModel Structure) che definisce un insieme di classi di base in grado di rappresentare con sufficiente dettaglio tutti gli elementi definiti in DogOnt. Figura 5.1. Struttura della soluzione Il modello dati viene definito utilizzando la tecnica delle interfacce Java annotate. Un interfaccia annotata è una normale interfaccia Java in cui compaiono particolari tag che consentono ad EMF di riconoscere le dichiarazioni effettuate. La generazione delle interfacce annotate avviene mediante il seguente procedimento: 1. creazione di un’interfaccia annotata per ogni classe definita nel DataModel Structure; 2. interrogazione (query) dell’ontologia (mediante il linguaggio SPARQL1 ) al fine di 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’opportuna interfaccia del DataModel Structure. 1 RDF query language, www.w3.org/TR/rdf-sparql-query 37 5 – Generazione dell’applicazione DogDomoticIde Le interfacce create a partire da DogOnt sono riferite alle opportune interfacce definite nel DataModel Structure tramite relazioni di ereditarietà. Il modello prodotto è quindi costituito dalle interfacce relative al DataModel Structure (ognuna delle quali contiene la descrizione di una particolare classe di elementi) e dalle interfacce relative agli elementi dell’ontologia (interfacce vuote, caratterizzate da una relazione di ereditarietà verso un’interfaccia del DataModel Structure). Consideriamo ad esempio la classe lampada (Lamp) in DogOnt, essa rappresenta un dispositivo con capacità di emettere luce. Essendo la lampada un dispositivo, la sua interfaccia può essere riferita all’interfaccia DeviceElement che contiene le dichiarazioni degli attributi tipici di ogni dispositivo. L’interfaccia Lamp, quindi, estenderà l’interfaccia DeviceElement, più o meno direttamente. Il package di interfacce risultante da questa prima fase di mapping tra DogOnt ed il DataModel Structure, viene utilizzato come input per un tool fornito dal plug-in EMF che produce, come output, i file ecore e genmodel funzionali ai successivi passi di generazione automatica del codice. Sulla base di tali file, ed in particolare del file ecore, EMF provvederà alla generazione di 3 plug-in specifici dell’applicazione DogDomoticIde: • domoticIde, plug-in composto da 3 package: – dataModel.interface, che contiene una versione aggiornata delle interfacce del modello (essenzialmente per fare in modo che tutte estendano l’interfaccia EObject); – dataModel.impl, che fornisce una classe implementazione per ogni interfaccia contenuta in dataModel.interface. Le classi generate sono dotate dei metodi get e set per tutti gli attributi specificati nel modello; – dataModel.util, che contiene classi Factory per la creazione di oggetti istanza 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, IItemPropertySource, ecc.) con lo scopo di fornire, al plug-in che implementa l’editor (domoticIde.diagram), le informazioni necessarie per la rappresentazione dell’elemento in diverse tipologie di viste (TreeView, TableView, ecc) ed un framework di comandi per l’interazione con il modello dati (incluso il supporto alle operazioni undo e redo); • domoticIde.editor: plug-in che contiene le classi per la creazione di editor grafici avviabili in una workbench window di Eclipse. Non viene utilizzato nel caso di applicazioni stand-alone. 38 5 – Generazione dell’applicazione DogDomoticIde Come si osserva nella Figura 5.1, il plug-in domoticIde generato da EMF non è quello definitivo; infatti il package dataModel.impl deve essere aggiornato in modo tale che ogni classe implementazione provveda alla corretta inizializzazione dei propri attributi. Per capire questo concetto consideriamo di nuovo l’esempio della lampada. Dopo la generazione delle implementazioni la situazione è quella mostrata in Figura 5.2: nel package dataModel.interface sono presenti le interfacce Lamp e DeviceElement (legate da una relazione di ereditarietà). Figura 5.2. Esempio di interfacce e di classi implementazione DeviceElement definisce l’attributo description, il cui contenuto rappresenta una descrizione delle funzionalità offerte da un generico dispositivo. Nel package delle implementazioni vengono generate due classi: DeviceElementImpl, implementazione dell’interfaccia DeviceElement (che contiene i metodi getter e setter per l’attributo description) e LampImpl, implementazione dell’interfaccia Lamp. Allo stato attuale la classe LampImpl eredita l’attributo description dalla classe DeviceElementImpl che, inoltre, fornisce i metodi necessari all’inizializzazione dello stesso. Completare una classe implementazione consiste nell’inserire, all’interno del suo costruttore, le istruzioni necessarie ad inizializzare gli attributi. Tale operazione va eseguita per ogni classe presente nel package dataModel.impl. Il costruttore presente nella classe LampImpl viene quindi aggiornato con l’inserimento dell’istruzione setDescription(’’An artificial source of visible illumination’’). Il valore assegnato agli attributi cambia, chiaramente, in relazione all’elemento che si sta analizzando: nel caso di un dispositivo diverso (es. Computer) l’attributo description assumerà un valore diverso (setDescription(’’A machine for performing calculations automatically, to work and play’’)). Naturalmente questo esempio ha scopo chiarificatore e quindi semplifica la realtà: l’interfaccia DeviceElement contiene infatti più attributi di quelli mostrati in Figura 5.2 e la definizione di ogni dispositivo non è cosı̀ banale. I valori utilizzati per inizializzare gli attributi di ogni elemento vengono ricavati dall’ontologia DogOnt. 39 5 – Generazione dell’applicazione DogDomoticIde Terminata la fase di completamento delle implementazioni, il plug-in domoticIde diventa a tutti gli effetti la libreria di componenti (Component Library plug-in) sulla quale si baserà l’applicazione DogDomoticIde. Come mostrato in Figura 5.1 il file ecore costituisce anche l’input per la creazione dei modelli necessari alla definizione delle caratteristiche grafiche e funzionali di base dell’applicazione, cioè i modelli gmftool, gmfgraph e gmfmap. Il file gmftool (Tooling Definition Model) ha lo scopo di contenere la descrizione della palette degli oggetti inseribili dall’utente nel foglio di lavoro risultante. Per ogni elemento della libreria che si desidera inserire nella palette occorre introdurre, in questo file, un oggetto CreationTool. È inoltre possibile organizzare i CreationTool all’interno di ToolGroup in maniera tale da raggrupparli, ad esempio, in base alla loro natura. Il file gmfgraph (Graphical Definition Model) contiene la descrizione dell’aspetto grafico di tutti gli elementi istanziabili dall’utente nel foglio di lavoro. Per ognuno di essi è 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. Ad esempio, ogni elemento istanziato dall’utente nell’applicazione DogDomoticIde ha forma rettangolare e contiene un’etichetta che visualizza il nome dell’oggetto. Le relazioni di interazione tra gli oggetti vengono rappresentate da collegamenti (link), oggetti grafici la cui forma è definita da una Polyline (unione di segmenti rettilinei). Il file gmfmap (Mapping Definition Model) contiene le associazioni tra le definizioni grafiche presenti nel file gmfgraph, i CreationTool contenuti nel file gmftool e gli elementi del modello dati. Figura 5.3. Esempio di mapping Per ogni elemento occorre creare e inizializzare un Node Mapping con i riferimenti alla descrizione grafica dell’elemento, al CreationTool ed alla classe del modello dati che descrive le proprietà dell’elemento stesso. Le corrispondenze create permettono 40 5 – Generazione dell’applicazione DogDomoticIde 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 modello dati (plug-in domoticIde) possono essere istanziati dall’utente nel proprio progetto. Infatti gli elementi estratti dall’ontologia per la creazione del modello dati non sono solo dispositivi, elementi architetturali, arredamento o, più in generale, elementi con una forma fisica, ma sono anche comandi, stati e notifiche, che descrivono il comportamento e le funzionalità offerte dai singoli dispositivi. È evidente che questi ultimi non devono essere istanziabili dall’utente: non ha senso, ad esempio, inserire nell’impianto domotico un oggetto di tipo comando. Per svolgere questa operazione di filtraggio è necessario quindi agire sui file gmftool, gmfgraph e gmfmap in maniera tale che contengano i CreationTool, le descrizione grafiche ed i mapping dei soli elementi “tangibili” di un impianto domotico. Sulla base di questi 3 modelli, GMF produce in automatico il Generator Model (Figura 5.1), un ulteriore modello che contiene la descrizione completa della struttura e delle classi che devono essere generate per l’applicazione. Il file gmfgen può essere personalizzato dal programmatore, con l’accortezza di verificare che le modifiche introdotte non compromettano il risultato della generazione del codice. GMF, sulla base 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’applicazione DogDomoticIde e che permettono la gestione dei file di progetto (formato di salvataggio, apertura, chiusura e creazione di un nuovo progetto). Questo package contiene inoltre la classe PaletteFactory, sede della descrizione della Palette View (Figura 5.4), punto di accesso alla libreria di componenti che permette all’utente di istanziare oggetti EditPart nel foglio di lavoro (Design View); • ide.diagram.part: contiene le classi EditPart ognuna delle quali è relativa ad uno specifico elemento istanziabile dall’utente nella Design View. Ogni EditPart è completamente descritta e può quindi essere utilizzata senza alcuna modifica; • ide.diagram.policy: contiene le classi EditPolicy che definiscono le operazioni effettuabili sulle EditPart associate ed i comandi necessari ad aggiornare il modello dati corrispondente; • ide.diagram.property: contiene le classi per la gestione della Property View (Figura 5.4) che permette all’utente di personalizzare le proprietà degli oggetti istanziati. 41 5 – Generazione dell’applicazione DogDomoticIde Il plug-in domoticIde.diagram contiene inoltre i riferimenti ai plug-in domoticIde e domoticide.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 questa prima sezione a partire dalla definizione del modello dati. 5.2 DataModel Structure Il DataModel Structure (Figura 5.8) consiste in un insieme di classi, organizzate gerarchicamente, sulle quali vengono mappati tutti i concetti contenuti nell’ontologia DogOnt (Ontology Classes). Figura 5.5. Il ruolo del DataModel Structure I concetti modellati in DogOnt appartengono a diverse gerarchie (o alberi) omogenee che includono rispettivamente: elementi architetturali, dispositivi, stati, comandi, notifiche, ambienti, ecc. Ogni classe contenuta nel DataModel Structure ha lo scopo di descrivere una di queste categorie, rappresentandone le proprietà in maniera sufficientemente generale ed estendibile. Questo modello nasce con lo scopo di semplificare la rappresentazione del contenuto dell’ontologia DogOnt sotto forma di un insieme di interfacce Java annotate. Grazie a questo meccanismo prima vengono prodotte le interfacce che descrivono le varie categorie (es. DeviceElement per i dispositivi) e poi, per ogni elemento estratto dall’ontologia, viene creata un’interfaccia vuota che estende l’opportuna interfaccia di categoria. Se non si fosse adottato un modello di base generale ogni 42 5 – Generazione dell’applicazione DogDomoticIde interfaccia prodotta avrebbe dovuto contenere al suo interno la definizione di tutte le caratteristiche, con conseguente duplicazione delle informazioni. Un ambiente domotico (classe Environment) può contenere un insieme generico di elementi (classe Element) ognuno dei quali è caratterizzato dagli attributi name, type e description che rispettivamente contengono il nome, il tipo ed una breve descrizione dell’elemento. Gli elementi presenti in un sistema domotico possono essere suddivisi in 3 famiglie principali: elementi architetturali, dispositivi ed ambienti. Per elementi architetturali si intendono gli elementi passivi non controllabili dal gateway domotico: oggetti strutturali (muri, porte, finestre, ecc) e di arredamento (sedie, mobili, tavoli, ecc). Gli elementi architetturali (classe ArchitecturalElement, Figura 5.6) possono essere connessi a sensori e governati da attuatori (sensors, actuators). Una porta può, ad esempio, essere governata da un DoorActuator (che ne gestisce l’apertura e la chiusura) il quale, a sua volta, può venire controllato da un PresenceSensor che attiva l’attuatore a seguito della rilevazione di una presenza umana nelle vicinanze della porta. Gli attributi sensorType ed actuatorType contengono rispettivamente la tipologia di sensore e di attuatore che possono essere connessi allo specifico elemento architetturale. Figura 5.6. La classe ArchitecturalElement La classe BuildingArea (Figura 5.7) modella gli ambienti dentro i quali viene realizzato un impianto domotico (appartamenti, stanze, garage e giardini). In un sistema domotico ogni ambiente può contenere un insieme di elementi architetturali (lista uncontrollableInside), un insieme di dispositivi (deviceInside) ed, a sua volta, ulteriori ambienti (environmentInside), si pensi, ad esempio, ad un appartamento che contenga una o più stanze. La forma di ogni ambiente, in una rappresentazione bidimensionale, è definita da un insieme di punti (xpoints, ypoints), che costituiscono i vertici di un poligono. Figura 5.7. La classe BuildingArea 43 5 – Generazione dell’applicazione DogDomoticIde Figura 5.8. Il DataModel Structure 44 5 – Generazione dell’applicazione DogDomoticIde I dispositivi (classe DeviceElement, Figura 5.9) sono elementi dell’ontologia che rappresentano gli oggetti controllabili dal gateway DOG. Essi generano notifiche in relazione ad un cambiamento di stato, sono governabili dal gateway attraverso l’uso un insieme di comandi (per modificare ed interrogare lo stato) e possono assumere una serie di configurazioni diverse (stati). Naturalmente il numero ed il tipo di notifiche che il dispositivo genera (lista notifications), di comandi accettati per il controllo (commands) e di configurazioni che può assumere (states) variano per ogni tipologia di dispositivo. Figura 5.9. La classe DeviceElement Ogni dispositivo reale (fisicamente presente in un impianto domotico) è dotato di una componente di rete (NetworkComponent, Figura 5.10). Tale componente di rete definisce i parametri tecnologici necessari al gateway DOG per interagire con il dispositivo stesso. Figura 5.10. La gestione della componente di rete L’attributo networkType descrive il tipo di componente di rete e, al momento, può assumere 3 valori: BTicinoNetworkComponent, KonnexNetworkComponent ed EliteNetworkComponent. BTicinoNetworkComponent contiene i parametri che è necessario definire al fine di comunicare con un dispositivo BTicino MyHome 45 5 – Generazione dell’applicazione DogDomoticIde (physicalAddress e physicalType). Analogamente KonnexNetworkComponent fornisce i parametri necessari per l’interazione con un dispositivo Konnex. In particolare i parametri groupAddress ed individualAddress sono attributi associati al dispositivo stesso, mentre le liste commandsHexValue e commandsGroupAddress contengono rispettivamente i parametri cmdHexValue e groupAddress associati ad ogni comando e notifica che il dispositivo gestisce. EliteNetworkComponent, infine, viene utilizzato per i dispositivi non reali (che non hanno componente di rete) inseriti nel modello dell’ambiente per essere utilizzati in simulazione. Come si osserva dalla Figura 5.10, le 3 classi che implementano le componenti di rete sono specializzazione della classe NetworkComponent. Questo permette di istanziare indifferentemente una delle 3 componenti di rete all’interno di ogni dispositivo. Le classi ArchitecturalElement, BuildingArea e DeviceElement estendono la classe Element. Ogni elemento dell’ontologia mappato su una di queste 3 classi è descritto 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 del dispositivo 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 visible illumination”); • 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 (OnCommand e OffCommand, comandi per accendere e spegnere la luce); • states: configurazioni che la lampada può assumere (OnOffState; tiene traccia del fatto che la luce sia accesa oppure spenta); • networkType: specifica il tipo di tecnologia di rete (“BTicinoNetworkComponent”, “KonnexNetworkComponent”, “EliteNetworkComponent”); • networkComponent: componente di rete della lampada. Ogni notifica presente nell’ontologia (classe NotificationElement) può definire un insieme di parametri (lista params). La notifica PressureMeasurement (generata da un sensore di pressione al fine di segnalare al gateway l’attuale valore della pressione), ad esempio, contiene il parametro pressureValue di tipo double nel quale 46 5 – Generazione dell’applicazione DogDomoticIde viene inserito il valore di pressione rilevato. I comandi (classe CommandElement), come le notifiche, possono contenere parametri ed avere un valore di ritorno il cui compito è segnalare al gateway l’esito dell’operazione richiesta. I comandi di query (comandi get) hanno tipicamente un valore di ritorno: ad esempio, le informazioni sullo stato del dispositivo vengono fornite nel valore di ritorno del comando getState. Il comando SetCommand, utilizzato dal gateway per impostare la luminosità di una DimmerLamp, ha un parametro che rappresenta il valore desiderato di intensità luminosa. Ogni parametro (classe Param, Figura 5.11) è definito dagli attributi: type, che descrive il tipo di valore contenuto (integer, string, double, ecc); name, nome del parametro; value, valore assegnato al parametro. Figura 5.11. Le classi NotificationElement, CommandElement e Param Gli stati (StateElement) possono assumere valori discreti (discreteValues) o continui (continuosValues). OnOffState (che descrive lo stato della Lamp), ad esempio, è uno stato che può assumere solo due valori discreti (“On” e “Off”). Lo stato LightIntensityState, che tiene traccia del valore di intensità luminosa di una DimmerLamp, invece assume valori continui compresi tra 0% ed 100% (percentuale di intensità luminosa). Le classi StateElement, NotificationElement e CommandElement estendono la classe Element ereditando gli attributi definiti al suo interno. Le classi HomeGateway, ControlElement ed ActuatorElement sono specializzazioni della classe DeviceElement. HomeGateway (Figura 5.12) modella i network gateway, punti di accesso ai sistemi domotici contenuti all’interno di un IDE (Intelligent Domotic Environment) che permettono la trasmissione dei messaggi specifici di un singolo protocollo (es. Konnex o BTicino) su di una tecnologia di interconnessione più versatile (es. Ethernet). All’interno di questa classe vengono definiti gli attributi di rete, come ad esempio ipAddress (indirizzo ip del network gateway) e connectionTrials (numero di 47 5 – Generazione dell’applicazione DogDomoticIde Figura 5.12. La classe HomeGateway tentativi eseguiti dal gateway centrale per instaurare una connessione con il network gateway), di cui ha bisogno il gateway DOG per comunicare con i network gateway. La classe ControlElement (Figura 5.13) modella tutti i dispositivi che hanno funzionalità di controllo. Ogni dispositivo controller contiene un riferimento a tutti i dispositivi controllati (lista controlLinks) e la descrizione delle relazioni di controllo in cui è coinvolto (controlAttributes). Ogni relazione di controllo viene descritta mediante la classe ControlProperties, che definisce gli attributi notification (notifica generata dal dispositivo controllore) e command (comando da generare al dispositivo controllato). Per ogni relazione di controllo occorre inoltre specificare il dispositivo controllato (controlledDeviceName). Figura 5.13. Le classi ControlProperties e ControlElement Esempio2: relazioni di controllo tra un pulsante ed una lampada. Un pulsante è in grado di governare l’accensione e lo spegnimento della luce di una lampada mediante 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 pulsante, comporta la trasmissione di un comando OnCommand alla lampada il cui scopo è accendere la luce. La seconda è caratterizzata dall’associazione OffNotification - OffCommand: OffNotification, generata dal pulsante a seguito di un evento di rilascio del pulsante, comporta la trasmissione di un comando OffCommand alla lampada il cui scopo è spegnere la luce. In questo caso è quindi necessario creare 2 istanze della classe ControlProperties. 48 5 – Generazione dell’applicazione DogDomoticIde La classe ActuatorElement (Figura 5.14) modella tutti i dispositivi attuatori. Ogni attuatore può 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 ad un 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 uno scenario composto da una porta, una lampada ed un sensore di chiusura e apertura porta. Quest’ultimo, a seguito della rilevazione dell’apertura della porta, genera un comando di controllo che accende la luce della lampada. In questo caso sensorLink e controlLinks contengono rispettivamente i riferimenti all’oggetto porta ed all’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 è caratterizzato dall’avere almeno una rappresentazione grafica. Nella classe VisualElement (Figura 5.15) sono definite quelle proprietà che tengono traccia delle caratteristiche grafiche dell’oggetto in questione: icon, riferimento all’icona dell’elemento, xLocation e yLocation, 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’opportuna classe del DataModel Structure: 49 5 – Generazione dell’applicazione DogDomoticIde • dispositivi con capacità di controllo - classe ControlElement; • dispositivi attuatori - classe ActuatorElement; • dispositivi sensori - classe SensorElement; • network level gateway - classe HomeGateway; • i restanti dispositivi (elettrodomestici, dispositivi appartenenti all’impianto elettrico, 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 ArchitecturalElement; • ambienti - classe BuildingArea. 5.3 Generazione del modello dati La Figura 5.16 mostra la sequenza di operazioni che occorre svolgere al fine di generare il modello dati dell’applicazione DogDomoticIde sulla base del DataModel Structure e dell’ontologia DogOnt: 1. rappresentazione del DataModel Structure nel formato XMI; 2. generazione delle interfacce annotate (package dataModel.interface) relative agli elementi dell’ontologia ed alle classi del DataModel Structure; 3. creazione di un modello ECore (mediante EMF) sulla base dell’insieme di interfacce annotate; 4. modifica del file ecore generato (personalizzazione di alcune proprietà del modello); 5. auto-generazione del plug-in domoticIde che contiene le classi Java che descrivono 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 modello dati, supporto alle operazioni undo/redo, ecc); 50 5 – Generazione dell’applicazione DogDomoticIde Figura 5.16. Workflow per la generazione del modello dati 7. aggiornamento del package dataModel.impl che contiene le classi implementazione 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 Java per ogni classe del DataModel Structure e per ogni elemento presente nell’ontologia DogOnt. A tal fine è stata costruita l’applicazione InterfaceGenerator, un programma Java che richiede come parametri di ingresso l’ontologia DogOnt (nel formato OWL) ed il DataModel Structure (nel formato XMI) e che fornisce come 51 5 – Generazione dell’applicazione DogDomoticIde output il package datamodel.interface completo di tutte le interfacce annotate che definiscono il modello dati. Come prima cosa vengono generate le interfacce relative al DataModel Structure. Il formato XMI, in cui tale modello è definito, permette, con relativa semplicità, di ottenere la lista delle classi del modello e, per ognuna di esse, di estrarre gli attributi e le relazioni di contenimento in cui sono coinvolte. EMF impone che il nome di ogni attributo inizi con “get” e finisca con le parentesi “()” (getter Java): l’attributo name definito nella classe Element, ad esempio, viene inserito nella relativa interfaccia Java nella forma: String getName(). Si consideri la relazione di contenimento che rappresenta la capacità di un ambiente di contenere un numero indefinito di dispositivi. Questa caratteristica viene descritta all’interno dell’interfaccia relativa alla classe BuildingArea mediante la dichiarazione: List hDeviceElementi getDevicesInside(), dove DeviceElement rappresenta il tipo contenuto (in questo caso dispositivi) e getDevicesInside() il nome del metodo “getter” che consentirà di accedere alla lista di dispositivi. Le relazioni di ereditarietà che intercorrono tra le classi vengono realizzate mediante la keyword Java extends : la linea di codice public interface DeviceElement extends Element, ad esempio, descrive la relazione di ereditarietà presente tra le interfacce relative agli elementi DeviceElement ed Element. Le interfacce relative al DataModel Structure vengono costruite sulla base dei principi appena descritti. Terminata questa fase l’applicazione InterfaceGenerator inizia la generazione delle interfacce che descrivono gli elementi dell’ontologia. Gli elementi appartenenti ad una categoria specifica (ad es. elementi architetturali e di arredamento) vengono estratti dall’ontologia mediante l’uso del liguaggio di query SPARQL. Per ognuno di essi viene creata un’interfaccia vuota che estende l’opportuna interfaccia del DataModel Structure (gli elementi architetturali e di arredamento estendono l’interfaccia ArchitecturalElement). Questo procedimento viene ripetuto per ogni categoria di elementi dell’ontologia: dispositivi, elementi passivi (architetturali ed arredamento), comandi, notiche, ecc. È da evidenziare che la categoria dispositivi richiede una trattazione diversa. Sono infatti necessarie 4 query per modellare tutti i dispositivi: • la prima estrae dall’ontologia tutti i dispositivi attuatori, mappati sull’interfaccia ActuatorElement; • la seconda è relativa ai dispositivi controller, mappati sull’interfaccia ControlElement; • la terza è relativa ai dispositivi sensori, mappati sull’interfaccia SensorElement; • la quarta query estrae tutti i dispositivi rimanenti, mappati sull’interfaccia DeviceElement. 52 5 – Generazione dell’applicazione DogDomoticIde Nella generazione delle interfacce si fa uso delle seguenti annotazioni: @model - inserito all’inizio del file, definisce che l’interfaccia contenuta è un elemento del modello dati; @model containment = ”true” - tag da inserire sopra la dichiarazione delle liste che rappresentano relazioni di contenimento; @model changeable=”true” - tag da inserire sopra la dichiarazione degli attributi il cui contenuto può essere modificato. La Figura 5.17 mostra un esempio di 2 interfacce annotate: la prima (a) è relativa alla classe DeviceElement del DataModel Structure, la seconda (b) descrive l’elemento lampada contenuto nell’ontologia. (a) Figura 5.17. (b) Le interfacce DeviceElement e Lamp Come si può osservare, l’interfaccia DeviceElement contiene la dichiarazione 53 5 – Generazione dell’applicazione DogDomoticIde degli attributi che descrivono tutti i dispositivi. Le liste getStates(), getNotifications() e getCommands() descrivono rispettivamente le relazioni di contenimento relative a stati, notifiche e comandi. Gli attributi getNetworkProperties() e getNetworkType() sono relativi alla componente di rete associata allo specifico dispositivo. DeviceElement, inoltre, estende l’interfaccia Element ereditandone gli attributi. L’interfaccia Lamp ha contenuto vuoto ed eredita gli attributi che la definiscono dall’interfaccia DeviceElement. Il package di interfacce annotate prodotto dall’applicazione InterfaceGenerator viene poi fornito come input ad un tool di EMF che produce in uscita il file ecore, necessario per la generazione dei plug-in domoticIde, domoticIde.edit e domoticIde.editor. 5.3.2 Completamento delle classi implementazione La modifica delle classi contenute nel package dataModel.impl completa la generazione del modello dati (Figura 5.16). Ogni classe implementazione generata da EMF contiene la dichiarazione non inizializzata degli attributi che caratterizzano l’elemento corrispondente dell’ontologia. L’applicazione FillImplementation inserisce in queste classi le istruzioni che inizializzano gli attributi con i loro valori specifici (qualora siano disponibili). Per ogni classe implementazione relativa ad un elemento di ontologia (sono escluse quelle riguardanti il DataModel Structure) vengono eseguite le seguenti operazioni: 1. si analizza il DataModel Structure (formato XMI) per ricavare gli attributi e le relazioni di contenimento definiti nella super classe (ogni classe relativa ad un elemento di ontologia estende una specifica classe del DataModel Structure); 2. i valori di inizializzazione degli attributi vengono ricavati dall’ontologia (mediante l’uso del linguaggio SPARQL); 3. all’interno del costruttore della classe si inseriscono le istruzioni che initializzano gli attributi e le liste. La Figura 5.18 mostra il costruttore della classe implementazione relativa al dispositivo lampada (LampImpl.java) prima (a) e dopo (b) l’esecuzione del programma FillImplementation. Come si osserva, il costruttore originale generato da EMF contiene unicamente il richiamo alla super-classe. L’esecuzione di FillImplementation introduce un insieme di instruzioni (comprese tra le 2 linee di commento) il cui compito è inizializzare gli attributi e le liste con i valori specifici della classe lampada definita in DogOnt. Nel caso mostrato in Figura 5.18 (oggetto lampada), i parametri da inizializzare sono descritti nella classe DeviceElement del DataModel Structure: 54 5 – Generazione dell’applicazione DogDomoticIde (a) (b) Figura 5.18. Classe implementazione prima e dopo l’esecuzione di FillImplementation • gli attributi name, type e description vengono inizializzati rispettivamente dalle istruzioni setName(’’Lampada1’’), setType(’’Lamp’’) e setDescription(’’An artificial source of visible illumination’’); • la lista states contiene oggetti di tipo StateElement (configurazioni che può assumere il dispositivo). La configurazione di una lampada (che può solo essere accesa o spenta) è descritta dallo stato OnOffState. L’istruzione states.add(new OnOffStateImpl())) permette di aggiungere a states un’istanza della classe OnOffStateImpl (classe implementazione relativa allo stato OnOffState); • la lista commands contiene i comandi che possono governare il dispositivo. In particolare i comandi OnCommand e OffCommand, descritti dalle classi OnCommandImpl ed OffCommandImpl, permettono di accendere e spegnere la luce della lampada; 55 5 – Generazione dell’applicazione DogDomoticIde • la lista notifications contiene le notifiche generate dal dispositivo. Il dispositivo lampada, a seguito di un cambiamento di stato, provvede a generare la notifica StateChangeNotification (descritta dalla classe StateChangeNotificationImpl). L’applicazione FillImplementation provvede ad aggiornare anche il construttore delle classi OnOffStateImpl (Figura 5.19, super-classe StateElement), OnCommandImpl, OffCommandImpl e StateChangeNotificationImpl. Figura 5.19. Classe implementazione relativa allo stato OnOffState Al termine della fase di completamento delle implementazioni il plug-in domoticIde contiene una rappresentazione completa del modello dati sulla quale si baserà l’applicazione DogDomoticIde. 5.4 Costruzione dei modelli per GMF La fase successiva alla costruzione del modello dati consiste nella stesura di 3 ulteriori modelli (Graphical Definition Model, Tooling Definition Model e Mapping Definition Model), basati sul modello Ecore generato in precedenza e necessari per la descrizione dell’aspetto grafico e delle funzionalità di base che l’applicazione DogDomoticIde deve realizzare. Per la stesura di ogni modello, GMF mette a disposizione il relativo meta-modello (a sua volta è un modello ECore) corredato da un apposito editor grafico. 56 5 – Generazione dell’applicazione DogDomoticIde Figura 5.20. 5.4.1 Costruzione dei modelli per GMF Graphical Definition Model Questo modello ha lo scopo di contenere la descrizione dell’aspetto e della rappresentazione visiva di tutti gli oggetti istanziabili dall’utente nel foglio di lavoro. Per descrivere le proprietà grafiche di un elemento occorre utilizzare i costrutti Node Descriptor e Figure Descriptor. La Figura 5.21 mostra la rappresentazione grafica dell’elemento Computer. Ogni oggetto di tipo Computer, istanziato dall’utente nel foglio di lavoro, avrà forma rettangolare e conterrà un’etichetta il cui scopo è visualizzare il nome dell’oggetto. Il Node Descriptor (prima riga) contiene un riferimento al Figure Descriptor (ComputerFigure, descrizione della composizione grafica dell’elemento Computer) e permette di definire le caratteristiche grafiche di carattere generale. Figura 5.21. Descrizione grafica del dispositivo Computer Osservando la figura si può notare come il Figure Descriptor associato all’elemento Computer contenga un oggetto Rectangle che descrive una forma grafica di tipo rettangolare e che consente di definire, al suo interno, gli eventuali oggetti contenuti nell’elemento (nell’esempio l’etichetta ComputerNameFigure). Infine Child Access consente di creare un’associazione tra una proprietà del modello dati ed un’etichetta. Nel caso in esempio Child Access permette di visualizzare il nome dell’oggetto (il valore della proprietà name) nell’etichetta ComputerNameFigure. La rappresentazione grafica descritta è analoga per tutti gli altri elementi estratti dall’ontologia DogOnt. Per ognuno di essi è quindi necessario istanziare questi costrutti al fine di definirne l’aspetto grafico come appena descritto. Fanno eccezione le rappresentazioni delle relazioni di interazione e dell’elemento Flat (appartamento). Le relazioni di interazione tra dispositivi vengono rappresentate mediante collegamenti, cioè oggetti grafici filiformi che connettono i dispositivi interessati dalla relazione. Sulla base della tipologia di relazione vengono definiti 3 tipologie di link: 57 5 – Generazione dell’applicazione DogDomoticIde • Control Link : rappresenta graficamente una relazione di controllo tra due oggetti (es. interruttore → lampada del salotto); • Actuator Link : rappresenta una relazione tra un oggetto attuatore ed un elemento architetturale dell’abitazione (es. attuatore per la porta → porta del salotto); • Sensor Link : rappresenta una relazione tra un oggetto sensore ed un elemento architetturale dell’abitazione (es. sensore per la porta → porta del salotto). La descrizione grafica dei link richiede l’utilizzo del Connection Descriptor (al posto di Node Descriptor) e la definizione, all’interno del relativo Figure Descriptor, della forma Polyline Connection che consente di rappresentare il link come 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 ActuatorLink ed i SensorLink sono rispettivamente rappresentati dai colori verde, rosso e blu. L’elemento appartamento (Flat) viene rappresentato come contenitore di oggetti (mediante il costrutto Compartment): costituisce l’ambiente all’interno del quale il progettista può creare camere ed istanziare gli elementi che compongono l’impianto domotico. La Figura 5.23 mostra un esempio del risultato prodotto dalla rappresentazione grafica descritta nel Graphical Definition Model. Figura 5.23. Rappresentazione grafica risultante 58 5 – Generazione dell’applicazione DogDomoticIde All’interno di un appartamento (Flat1) sono stati inseriti 2 oggetti (un bottone ed una lampada) legati da una relazione di controllo (link verde) e dotati di un’etichetta che ne visualizza il nome (“pulsanteLuce” e “luce”). 5.4.2 Tooling Definition Model Questo modello contiene la descrizione della Palette View, strumento che permette all’utente dell’applicazione DogDomoticIde di accedere alla libreria dei componenti e di selezionare l’elemento che desidera istanziare nel foglio di lavoro. Anche in questo caso 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’organizzazione e l’aspetto delle voci contenute nella palette. Il costrutto Tool Group consente la creazione di raggruppamenti di voci (contenitore grafico). La Figura 5.24 mostra la descrizione del ToolGroup relativo agli elementi architetturali che l’utente può 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 specifico elemento all’interno del foglio di lavoro. Ogni Creation Tool può contenere i riferimenti a 2 immagini, rispettivamente di dimensioni 32x32 e 64x64 pixel, utilizzate dall’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 sono stati utilizzati 9 ToolGroup (Architectural, Furniture, Electrical System, HomeGateway, Sensor, Actuator, Control, BuildingTool e Link) ognuno dei quali contiene i costrutti Creation Tool relativi ad una specifica categoria di elementi. 59 5 – Generazione dell’applicazione DogDomoticIde 5.4.3 Mapping Definition Model Per ogni elemento istanziabile dall’utente, il Mapping Definition Model consente di realizzare la mappatura tra il relativo Creation Tool, definito all’interno del file gmftool, la rappresentazione grafica, descritta nel file gmfgraph, e la classe del modello dati che ne descrive le proprietà. Il Mapping Definition Model viene utilizzato dal generatore di codice di GMF per creare le classi EditPart, componenti principali di un’applicazione GEF il cui compito è unire nello stesso oggetto software le figure Draw2D che definiscono la rappresentazione grafica dell’elemento e la classe del modello dati che ne descrive le proprietà. Il Mapping Definition Model permette di definire il comportamento della Palette View in maniera tale che ogni sua voce consenta all’utente di istanziare uno specifico oggetto EditPart all’interno del foglio di lavoro. L’esempio in Figura 5.25 mostra il mapping relativo all’elemento poltrona (ArmChair). Le proprietà del mapping che occorre definire sono Element, Diagram Node e Tool che rispettivamente contengono i riferimenti alla classe del modello dati, al Node 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 permetterà all’utente di istanziare, a seguito della selezione della voce della palette associata al Creation Tool Armchair, una EditPart relativa all’elemento poltrona, rappresentata graficamente dalla figura ArmchairFigure e modellata dalla classe Armchair del 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 Sensor Link) viene inserito un Link Mapping nel quale occorre specificare le proprietà 60 5 – Generazione dell’applicazione DogDomoticIde Diagram Link, Tool e Target Feature. Le prime 2 contengono rispettivamente i riferimenti al Connection Descriptor ed al Creation Tool tramite il quale l’utente può creare un link. Target Feature specifica, invece, quali elementi sono collegabili da una tipologia di link: • Control Link: Target Feature deve essere impostato in maniera tale che l’elemento sorgente del collegamento sia un dispositivo controllore (ControlElement) e la destinazione un dispositivo qualunque (DeviceElement); • Actuator Link: la sorgente del collegamento è un dispositivo attuatore (ActuatorElement) e la destinazione un elemento architetturale (ArchitecturalElement); • Sensor Link: la sorgente del collegamento è 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 in uscita il Generator Model. Figura 5.26. Generazione dell’editor Il Generator Model: 1. unisce e riassume quanto definito nei modelli Graphical Definition Model, Tooling Definition Model e Mapping Definition Model. In particolare, per ogni elemento descritto vengono generate le informazioni ed i riferimenti necessari alla costruzione della relativa classe EditPart (EditPolicy, comandi, classe del modello dati, rappresentazione grafica, ecc); 61 5 – Generazione dell’applicazione DogDomoticIde 2. definisce la Palette View, la Design View e la Property View e descrive inoltre i contenuti dei menù dell’applicazione. Infine il generatore di codice di GMF, sulla base del Generator Model, produce il plug-in domoticIde.diagram, che implementa un applicazione editor per il modello dati descritto nei plug-in domoticIde e domoticIde.edit. L’applicazione, che nel caso di questa tesi assume il nome DogDomoticIde (Figura 5.27) fornirà un’interfaccia grafica dotata delle seguenti finestre: • Palette View: punto di accesso alla libreria dei componenti inseribili nel progetto; • Design View: foglio di lavoro dentro il quale è possibile istanziare gli elementi contenuti nella palette e, quindi, descrivere un impianto domotico; • Property View: permette all’utente di effettuare l’editing delle proprietà degli oggetti istanziati nel foglio di lavoro. È composta da 2 finestre organizzate in tab: – Appearance: permette la visualizzazione e la modifica dell’aspetto visivo dell’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 colonna visualizza 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 menù: • 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 5 – Generazione dell’applicazione DogDomoticIde Figura 5.27. Screenshot dell’applicazione DogDomoticIde versione base, cioè ottenuta mediante generazione automatica 63 Capitolo 6 Implementazione Questo capitolo descrive le operazioni di integrazione ed estensione dell’applicazione DogDomoticIde, auto-generata da GMF, necessarie al fine di supportare i requisiti funzionali 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 componenti dell’applicazione DogDomoticIde. La Palette View rappresenta il punto di accesso alla 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’aggiornamento del contenuto della finestra delle proprietà. La Property View, infatti, visualizza e permette la modifica delle proprietà dell’oggetto selezionato. Le modifiche effettuate agli attributi di un oggetto vengono registrate nella relativa EditPart. Lo scopo della fase di implementazione è quello di intervenire in questa architettura al fine di: • introdurre nuovi componenti: – la Summary View, vista ad albero il cui scopo è visualizzare un riepilogo degli oggetti istanziati nel progetto; – il modulo BuildFile, per la costruzione di documenti di configurazione installabili direttamente sul gateway DOG. • potenziare le parti generate da GMF. In particolare si agirà: – sulla Design View, per incrementare le funzionalità di editing grafico fornite all’utente, ad esempio fornendo il supporto all’auto-rilevazione delle stanze presenti in un appartamento mediante l’algoritmo RoomDetection; – sulla Property View, al fine di renderla adatta all’editing delle proprietà domotiche degli oggetti istanziati nel foglio di lavoro: l’organizzazione a tabella fornita dal tab Core risulta infatti inadeguata per la descrizione delle relazioni di interazione e dei componenti di rete. Vengono quindi implementate ed aggiunte alla Property View le finestre CommonProperties, Network, NetworkGateway, ControlRelation e RelationsSummary; – sulle classi EditPart, al fine di implementare le interazioni tra le stesse e la Summary View. Le operazioni di creazione, modifica o distruzione di oggetti EditPart (nel foglio di lavoro) devono, infatti, essere segnalate alla Summary View affinchè possa aggiornare il proprio contenuto. 6.2 La gestione degli ambienti stanza Le funzionalità fornite dall’applicazione generata da GMF consentono all’utente di istanziare, all’interno del foglio di lavoro, uno o più appartamenti, nei quali è possibile posizionare gli oggetti che definiscono l’impianto domotico. Questo approccio non è completo in quanto, normalmente, un oggetto assume una posizione all’interno di una stanza, la quale è parte di un appartamento. Al fine di introdurre il concetto di “stanza” nell’applicazione DogDomoticIde sono state valutate 2 possibili soluzioni. La prima consiste nel modellare, all’interno dei modelli Graphical Definition Model e Mapping Definition Model (sezione 5.4), 65 6 – Implementazione 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 più oggetti stanza; Questa soluzione, che ha il vantaggio di essere facilmente implementabile (basta impostare correttamente i modelli e poi GMF provvede alla generazione automatica del codice), pone delle forti limitazioni di editing: siccome la forma grafica di base di ogni elemento istanziabile è di tipo rettangolare, l’utente può istanziare solo stanze di quella forma. Si è quindi deciso di adottare una soluzione alternativa nella quale una stanza è concepita come un’area chiusa delimitata da un insieme di muri. Mediante questo principio la progettazione della struttura di un ambiente domotico consiste nel: 1. istanziare uno o più oggetti appartamento; 2. istanziare e posizionare uno o più muri all’interno dell’appartamento in modo da strutturare l’ambiente nella maniera desiderata. Le aree chiuse delimitate dai muri sono le stanze dell’appartamento. Questa strategia fornisce all’utente un maggior grado di libertà nella costruzione delle stanze: la forma di una stanza dipende dalla configurazione dei muri istanziati (Figura 6.2b). Tuttavia occorre tener presente che GMF consente la creazione di oggetti muro di forma rettangolare, orientati orizzontalmente o verticalmente. Non è quindi possibile, ad esempio, creare stanze di forma circolare (in quanto non è possibile istanziare muri concavi). (a) Figura 6.2. (b) Esempio di struttura di due ambienti appartamento 66 6 – Implementazione Ogni appartamento viene creato con i “muri di confine”, muri posizionati lungo il 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 in un appartamento (in relazione alla configurazione di muri presente). Per ognuna di esse viene istanziato automaticamente un oggetto RoomEditPart che permette all’utente di modificare (tramite la Property View) le proprietà della stanza che rappresenta (nome e tipologia di stanza). 6.2.1 L’algoritmo RoomDetection Lo scopo dell’algoritmo RoomDetection è individuare il numero, la posizione e la forma delle stanze presenti in un appartamento la cui struttura rispetta i seguenti vincoli architetturali: • muri di forma rettangolare, orientati orizzontalmente o verticalmente rispetto al piano di lavoro; • “rete” di muri connessa: ogni muro presente nell’appartamento deve essere connesso, direttamente o indirettamente, a tutti gli altri muri (interni o di confine). La Figura 6.3 mostra un esempio di rete di muri connessa (a) e non connessa (b); • sezione dei muri di confine di dimensione fissa. (a) Figura 6.3. (b) Muri connessi e non connessi Nel seguito verrà descritto il funzionamento dell’algoritmo (Figura 6.4) e, parallelamente, sarà trattato un caso di studio (Figura 6.5) al fine di semplificare la comprensione dell’algoritmo stesso. 67 6 – Implementazione Figura 6.4. Figura 6.5. Struttura dell’algoritmo RoomDetection 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 deve essere descritto in termini di posizione (rispetto ai bordi dell’appartamento) e di dimensione (larghezza, altezza). Tali informazioni (espresse in pixel) vengono inserite nella 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 6 – Implementazione La ricerca delle aree di intersezione La prima fase di esecuzione dell’algoritmo consiste nella ricerca delle aree di intersezione. Algorithm 1 La ricerca delle aree di intersezione for all wall1 in wallList do for all wall2 in wallList do if wall1 = / wall2 then intersectionArea = wall1 X wall2 if intersectionArea = / void then intersectionList.add(wall1,intersectionArea) end if end if end for sort(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 muri di confine 1 e 2 permette di individuare l’area di intersezione A, analogamente l’intersezione tra il muro 1 ed il muro interno genera l’area B e cosı̀ via. Da notare che non tutte le intersezioni eseguite individuano aree di intersezione: i muri 1 e 4, ad esempio, 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 loro posizione (metodo sort). In particolare se il muro in esame è di tipo orizzontale le aree di intersezione individuate vengono ordinate da sinistra verso destra (rispetto al foglio di lavoro). Se il muro è orientato verticalmente le aree di intersezione vengono ordinate dall’alto verso il basso. La Figura 6.6 mostra il contenuto della struttura dati intersectionList, risultato di questa prima fase di esecuzione. Figura 6.6. La struttura dati intersectionList 69 6 – Implementazione La ricerca delle aree contigue L’algoritmo provvede a ricavare le aree contigue ad ogni area di intersezione trovata in precedenza. Algorithm 2 La ricerca delle aree contigue for all wall1 in wallList do for all intersectionArea in intersectionList(wall1) do if intersectionM ap.isPresent(intersectionArea) = false then neighborAreaList = getNeighbor(intersectionArea) intersectionM ap.add(intersectionArea,neightborAreaList) end if end for end for La procedura getNeighbor, sulla base del contenuto di intersectionList, restituisce la lista delle aree contigue ad una specifica area di intersezione. Le associazioni “area di intersezione - aree contigue” vengono poi registrate nella struttura dati intersectionMap. Il metodo isPresent restituisce il valore “true” nel caso in cui l’area di intersezione che si sta valutando sia già stata descritta in intersectionMap. Si considerino, ad esempio, le 2 occorrenze dell’area A contenute in intersectionList. La prima (relativa al muro1) determina la ricerca delle aree contigue all’area A, la seconda (relativa al muro2) non viene considerata in quanto tale area è già stata valutata in passato (isPresent restituisce “true”). La Figura 6.7 mostra il contenuto della struttura dati interceptionMap relativamente all’esempio in esame. Figura 6.7. La struttura dati intersectionMap 70 6 – Implementazione La ricerca delle stanze Si procede con la ricerca delle stanze presenti nell’appartamento. Questo compito viene demandato alla procedura ricorsiva detectRooms che individua le stanze sulla base del contenuto della struttura dati intersectionMap. Algorithm 3 La procedura detectRooms procedure detectRooms(previousArea,currentArea) if contain(graphSearch,currentArea) then cycle=takeCycle(graphSearch,currentArea) checkAndRecordRoom(cycle) return end if if graphSearch.size() ≤ M AX IN T ERSECT ION P OIN T then graphSearch.add(currentArea) neighborAreaList = intersectionM ap.get(currentArea) for all nextArea in neighborAreaList do if previousArea = / nextArea then detectRooms(currentArea,nextArea) end if end for graphSearch.remove(currentArea) end if end procedure Il principio sul quale si basa questa procedura è quello di immaginare le aree di intersezione ottenute in precedenza come nodi di un grafo, ognuno dei quali è connesso 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 profondità di questo grafo: è possibile “muoversi” su un nodo direttamente connesso al nodo in esame. Il nodo A, ad 71 6 – Implementazione esempio, consente di “spostarsi” sui nodi B o F che, a loro volta, consentiranno di visitare ulteriori nodi. La struttura dati intersectionMap risulta quindi essenziale per la visita del grafo in quanto fornisce la lista dei nodi raggiungibili da ogni nodo. Si considera come nodo di partenza la prima area di intersezione descritta in intersectionMap (nel caso in esame il nodo A, currentArea=A). Tale nodo viene prima inserito nella lista graphSearch (che tiene traccia dei nodi attraversati dalla procedura detectRooms) e poi utilizzato per ottenere da intersectionMap i nodi contigui che possono essere visitati. Per ognuno di essi (nextArea) viene ricorsivamente invocata la procedura detectRooms. La costante MAX INTERSECTION POINT (impostata al valore 20) rappresenta il limite di profondità oltre il quale viene interrotta la visita del grafo. La procedura detectRooms richiede 2 parametri: previousArea, relativo al nodo visitato nell’iterazione precedente e currentArea, che descrive il nodo che si sta considerando nell’iterazione corrente. Per comprendere l’uso di entrambi si considerino le 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 la currentArea e la previousArea dell’iterazione i+1. La previousArea tiene traccia del nodo visitato nell’iterazione i con lo scopo di poterlo escludere dai nodi visitabili nell’iterazione i+2. Nell’iterazione 1, ad esempio, la previousArea consente di escludere il nodo A come prossimo nodo da visitare (in quanto si è arrivati da A). La rilevazione di un ciclo nella visita del grafo (si vuole visitare un nodo che è già stato attraversato in passato) è la condizione necessaria che può condurre 72 6 – Implementazione all’individuazione di una stanza. All’inizio di ogni iterazione il metodo contain verifica se graphSearch contiene il nodo che deve essere visitato (currentArea). In caso di esito positivo il metodo takeCycle estrae da graphSearch la sequenza di aree di intersezione che definiscono il ciclo. Infine il vettore cycle viene validato dal metodo checkAndRecordRoom che provvede, eventualmente, alla sua registrazione nella 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 rispettivamente dai vertici {A, B, E, F} ed {E, D, C, B}. Il terzo ciclo non può essere considerato una stanza valida in quanto “contiene” le altre 2 trovate in precedenza. In generale ogni ciclo viene validato in relazione a tutte le stanze registrate in precedenza: • se i vertici contenuti in cycle definiscono un area che “contiene” almeno una delle stanze registrate nella roomList allora tale ciclo viene scartato (stanza contenitore, caso 3); • vengono rimosse dalla roomList le stanze che “contengono” l’area definita dai vertici presenti in cycle (stanza contenuta). Si supponga, ad esempio, che il ciclo 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 è la lista roomList che contiene la descrizione delle camere trovate. Implementazione Le funzionalità fornite dall’algoritmo RoomDetection vengono sfruttate da DogDomoticIde per la costruzione e l’aggiornamento degli oggetti stanza a seguito delle seguenti operazioni di editing effettuate dall’utente nel foglio di lavoro: • creazione, ridimensionamento e traslazione (nel foglio di lavoro) di oggetti appartamento; • creazione, modifica (posizione o dimensione) e rimozione di muri. 73 6 – Implementazione Figura 6.9. Stanze individuate dall’algoritmo RoomDetection RoomDetection viene implementato all’interno dell’omonima classe RoomDetection che offre, come interfaccia verso l’esterno, i seguenti metodi pubblici: • setBorder(x, y, width, height, wall size): metodo che inizializza l’oggetto RoomDetection con le informazioni riguardanti la posizione e le dimensioni dell’appartamento sul quale verrà eseguito l’algoritmo di rilevazione delle stanze. Il parametro wall size descrive la dimensione della sezione dei muri di 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 dati sulle quali opera l’algoritmo (intersectionList, intersectionMap); • removeWall(wall): permette la rimozione di un muro dalla wallList con conseguente aggiornamento delle altre strutture dati; • updateWall(old wall, new wall): segnala che un muro ha cambiato posizione o dimensioni. I 2 parametri contengono rispettivamente la versione vecchia e nuova del muro; • setTraslation(dx,dy): segnala che l’appartamento è stato spostato (nel foglio di lavoro) delle quantità dx (orizzontale) e dy (verticale) rispetto alla sua posizione precedente; 74 6 – Implementazione • getRooms(): comporta l’esecuzione della procedura detectRooms e restituisce un riferimento alla lista roomList. 6.2.2 Integrazione dell’algoritmo RoomDetection nell’applicazione DogDomoticIde Per integrare l’algoritmo RoomDetection nell’applicazione DogDomoticIde sono state valutate 2 possibili soluzioni: 1. costruzione/aggiornamento automatico delle stanze a seguito di ogni operazione di modifica della struttura dell’ambiente effettuata dall’utente. • Vantaggi: costruzione/aggiornamento delle stanze trasparente per l’utente; • Svantaggi: elevato costo computazionale (ogni modifica effettuata alla struttura 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 solo su richiesta dell’utente); • Svantaggi: l’utente deve gestire la costruzione e l’aggiornamento delle stanze. Sperimentalmente è stato dimostrato che il primo approccio risulta il migliore dal punto di vista dello user-experience. Per sopperire alla problematica del costo computazionale si è agito sull’algoritmo RoomDetection in modo tale da garantire una sua convergenza in tempi accettabili. La costruzione di un appartamento da parte dell’utente comporta la creazione dell’oggetto roomService, istanza della classe RoomDetection che fornisce l’accesso a 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) e le dimensioni dell’appartamento appena creato (Figura 6.10). Un appartamento può inoltre essere ridimensionato o spostato dall’utente all’interno del foglio di lavoro (traslato). Nel primo caso roomService viene reinizializzato con le nuove dimensioni (metodo setBorder), nel secondo caso si procede con l’esecuzione del metodo setTraslation. Un muro può essere istanziato, spostato, ridimensionato e rimosso. Tali operazioni vengono gestite rispettivamente dai metodi addWall, updateWall (i 2 parametri contengono, rispettivamente, la descrizione del muro prima e dopo la modifica effettuata) e removeWall. 75 6 – Implementazione Figura 6.10. Integrazione dell’algoritmo RoomDetection in DogDomoticIde Tutti i metodi descritti sinora hanno lo scopo di aggiornare le strutture dati sulle quali si basa l’algoritmo RoomDetection: la creazione, la rimozione, lo spostamento ed il ridimensionamento di un appartamento o dei muri in esso contenuti determinano 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 classe FlatEditPart (EditPart relativa all’elemento appartamento) al fine di: • ricavare la lista delle stanze presenti nell’appartamento (esecuzione del metodo roomService.getRooms()); • aggiornare la struttura dati builtRoom che contiene le associazioni tra le descrizioni delle stanze fornite da getRooms() e le RoomEditPart, oggetti che 76 6 – Implementazione rappresentano graficamente le stanze presenti nell’appartamento permettendo all’utente di visualizzare e modificare le proprietà delle stesse. Nella prima esecuzione del metodo updateRooms (quando viene creato l’appartamento) si procede con l’inserimento in builtRoom di una voce per ogni stanza descritta nella struttura dati roomList (risultato dell’invocazione del metodo getRooms). Nelle esecuzioni successive alla prima (a seguito di operazioni di editing effettuate dall’utente) l’obiettivo di updateRooms diventerà quello di aggiornare il contenuto di builtRoom in relazione alla nuova configurazione di stanze presenti nell’appartamento. In questo contesto mantenere le voci della builtRoom che, a seguito di modifiche strutturali dell’ambiente, sono ancora valide risulta molto importante: permette di conservare i riferimenti agli oggetti RoomEditPart dentro i quali sono memorizzati i valori che l’utente ha assegnato agli attributi (nome e tipologia di stanza). Figura 6.11. Aggiornamento della struttura dati builtRoom Si consideri l’esempio mostrato nella Figura 6.11. Inizialmente l’appartamento contiene 2 stanze (CAMERA1 e CAMERA2 ). L’introduzione di un ulteriore muro determina l’invocazione dei metodi addWall ed updateRooms con lo scopo di aggiornare il contenuto di builtRoom. In particolare viene eseguita l’intersezione tra le informazioni ottenute dal metodo getRooms (lista roomList che contiene la descrizione delle nuove camere) e la struttura dati old builtRoom (che descrive la configurazione delle stanze prima dell’inserimento dell’ultimo muro). Questa operazione permette di riconoscere le stanze descritte nella old builtRoom che risultano 77 6 – Implementazione ancora valide a seguito delle modifiche effettuate dall’utente. In questo caso l’introduzione del nuovo muro mantiene inalterata la CAMERA2 con la conseguenza che la relativa voce viene copiata nella nuova builtRoom. Per ogni nuova stanza (presente nella lista roomList e non nella struttura dati old builtRoom) viene aggiunta una voce nella builtRoom (nel caso in esame vengono create le voci per le camere 3 e 4). 6.3 La Summary View La Summary View è una vista ad albero che tiene traccia di tutti gli oggetti istanziati dall’utente nel foglio di lavoro. Figura 6.12. La Summary View L’organizzazione gerarchica dei nodi che compongono l’albero (Figura 6.13) tiene conto delle naturali relazioni di contenimento che intercorrono tra i vari oggetti istanziati nel foglio di lavoro: • livello 0: definisce il nodo Home, radice dell’albero che rappresenta il contenuto del foglio di lavoro (un abitazione); • livello 1: contiene i nodi relativi agli appartamenti introdotti dall’utente nel foglio di lavoro; • livello 2: organizza gli elementi che definiscono la struttura di ogni appartamento (camere, muri, porte e finestre). A tal fine vengono introdotti staticamente, come successori di ogni nodo appartamento, i nodi Rooms, Walls, Doors e Windows, che sono “contenitori” di altri elementi: ogni muro inserito nel foglio di lavoro comporta l’aggiunta di un nodo Wall successore di Walls. Analogo discorso per i nodi Rooms, Doors e Windows che rispettivamente hanno come successori i nodi relativi alle stanze, alle porte ed alle finestre presenti nell’ambiente. Organizzare gli elementi mediante questi 4 nodi consente all’utente di avere una visione ordinata del contenuto dell’albero; 78 6 – Implementazione • livello 3: contiene i nodi successori dei nodi Rooms, Walls, Doors e Windows. È quindi composto dai nodi che descrivono le stanze, i muri, le porte e le finestre; Figura 6.13. Struttura della Summary View • livello 4: definito solo per i nodi che descrivono gli oggetti contenuti all’interno di ogni stanza (dispositivi, arredamento, ecc). Per ogni oggetto istanziato dall’utente (che non sia un muro, una finestra o una porta) viene inserito nell’albero un nodo successore al nodo che rappresenta la stanza che contiene l’oggetto stesso. 6.3.1 Aggiornamento della Summary View Il contenuto della Summary View deve essere aggiornato in relazione alle operazioni di 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’albero; 79 6 – Implementazione • lo spostamento di un oggetto da una stanza all’altra comporta lo spostamento del relativo nodo dell’albero (in maniera tale che sia sempre successore del nodo che descrive la stanza che lo contiene). Nel seguito sarà trattato nel dettaglio l’aggiornamento della Summary View conseguente 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) objectN ode=createNode(object) if object isA Flat then treeRoot.addChild(objectN ode) else f latN ode=searchNode(treeRoot,object.getFlat().getName()) if object isA Wall OR object isA Door OR object isA Window OR object isA Room then saveStructuralNode (f latN ode,objectN ode) else roomObject= searchRoom(builtRoom,object) roomN ode=searchNode(f latN ode,roomObject.getName()) roomN ode.addChild(objectN ode) end if end if end procedure La procedura addNode (definita nella Summary View) provvede alla creazione di un nodo relativo all’oggetto istanziato (metodo createNode) ed al suo successivo posizionamento all’interno dell’albero. I parametri object e builtRoom contengono rispettivamente i riferimenti all’oggetto creato nel foglio di lavoro (EditPart) ed alla 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’appartamento che “contiene” l’oggetto istanziato. A tal fine viene invocato il metodo searchNode, che provvede alla ricerca del nodo il cui nome è indicato nel suo secondo parametro (object.getFlat().getName() fornisce il nome dell’appartamento dentro il quale è stato istanziato object). Tale ricerca viene effettuata a partire dal nodo 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 6 – Implementazione 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 svolge un’analisi della struttura dati builtRoom allo scopo di individuare la stanza che contiene l’oggetto in esame (in relazione alla sua posizione); 2. individuare il nodo che descrive l’oggetto stanza trovato in precedenza. Tale ricerca 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 del nodo stanza individuato (roomNode). 6.3.2 Aspetto e funzionalità della Summary View L’esempio in Figura 6.14 mostra l’aspetto tipico della Summary View. Un appartamento (“Appartamento1”) è composto da 2 stanze (“Camera da letto” e “Cucina”), contenitori di un letto matrimoniale (“Letto matrimoniale”) ed un frigorifero (“Frigorifero”). 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 è composto da un icona, dal nome e dal tipo base 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 funzionalità di ricerca degli oggetti: la selezione di un 81 6 – Implementazione nodo dell’albero (con un doppio click del mouse) comporta la selezione del relativo oggetto nel foglio di lavoro. Tale interazione viene realizzata mediante l’invocazione del metodo setFocus() (fornito da GMF) sull’oggetto EditPart relativo al nodo selezionato. 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 RelationsSummary. Figura 6.15. 6.4.1 Modifica della Property View Il tab CommonProperties Questo tab (Figura 6.16) viene visualizzato nella Property View a seguito della selezione di uno qualsiasi degli oggetti istanziati nel foglio di lavoro. Contiene un form organizzato in 2 parti: • la parte sinistra permette la modifica della posizione (relativamente alla posizione del foglio di lavoro) e delle dimensioni dell’oggetto selezionato (espresse in pixel); • la parte destra visualizza le proprietà comuni a tutte le categorie di oggetti: type (tipologia di oggetto), description (descrizione della funzione dell’oggetto) e name (nome dell’oggetto, modificabile dall’utente). Le operazioni di spostamento/ridimensionamento di un oggetto (nel foglio di lavoro) comportano l’aggiornamento automatico dei campi “Position” e “Size”. Tale interazione viene realizzata mediante il pattern di programmazione Observer : 1. la Property View provvede a registrare un osservatore all’interno dell’oggetto EditPart selezionato. Tale osservatore è un puntatore ad una funzione il cui scopo è aggiornare i campi “Position” e “Size” del tab CommonProperties; 82 6 – Implementazione Figura 6.16. Il tab CommonProperties 2. quando l’oggetto viene spostato o ridimensionato si procede con l’invio di una notifica agli osservatori registrati. Viene quindi eseguita la procedura che aggiorna il contenuto dei campi “Position” e “Size”. Infine le modifiche effettuate dall’utente alle proprietà “Position” e “Size” si ripercuotono direttamente sull’oggetto nel foglio di lavoro (che viene spostato o ridimensionato). 6.4.2 I tab Network e NetworkGateway Il tab Network permette la definizione della componente di rete (BTicino o Konnex) di ogni dispositivo istanziato nel foglio di lavoro. Nel caso di dispositivi trattati in simulazione non occorre specificare alcuna componente di rete (di default viene impostata la componente di rete “EliteComponent”). La selezione della voce “BTicinoComponent” (Figura 6.17) rende visibili i campi “PhysicalAddress” (che deve essere valorizzato affichè 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 componente di rete di tipo Konnex. I controlli visualizzati nel form permettono di inizializzare i parametri definiti da questa tecnologia. 83 6 – Implementazione Figura 6.18. Il tab Network/KonnexComponent Il tab NetworkGateway (Figura 6.19), visualizzato solo in caso di selezione di oggetti network gateway, permette la modifica dei parametri di rete necessari al gateway DOG per comunicare con il network gateway selezionato. Figura 6.19. 6.4.3 Il tab NetworkGateway I tab ControlRelation e RelationsSummary I tab ControlRelation (Figura 6.20) e RelationsSummary (Figura 6.21), inseriti nella Property View a seguito della selezione un link di controllo (ControlLink), hanno lo scopo di permettere la gestione delle relazioni di controllo che intercorrono tra 2 dispositivi. La creazione di una relazione di controllo consiste nella definizione di una corrispondenza tra una notifica generata dal dispositivo controllore (selezionata dalla 84 6 – Implementazione ComboBox “Notification”) ed un comando che governa il dispositivo controllato (selezionato dalla ComboBox “Command”). La Figura 6.20 mostra un esempio d’uso del tab ControlRelation per la creazione di una relazione di controllo tra un oggetto pulsante (“Button1”, dispositivo controllore) ed una lampada ad intensità luminosa regolabile (“DimmableLight1”, dispositivo controllato). Figura 6.20. Il tab ControlRelation La tabella “Parameters” permette di impostare il valore dei parametri (se presenti) del comando selezionato: ogni riga contiene la descrizione di un parametro (nome, tipo di dati che può assumere e valore dato). Il comando SetCommand, ad esempio, definisce il parametro value, livello di intensità luminosa da impostare alla lampada. La relazione di controllo mostrata in Figura 6.20 ha il seguente significato logico: a seguito della ricezione della notifica OnNotification (generata da “Button1” in risposta ad un evento di pressione del pulsante) viene generato e trasmesso alla lampada “DimmableLight1” un comando SetCommand(50) (che ha lo scopo di impostare l’intensità luminosa della lampada al 50%). Il tab RelationsSummary (Figura 6.21) fornisce una visione d’insieme delle relazioni di controllo definite tra 2 dispositivi. Le colonne “Notification of Controller Device” e “Command of Controlled Device” contengono rispettivamente la notifica del dispositivo controllore ed il comando del dispositivo controllato che caratterizzano la relazione di controllo selezionata. L’esempio in Figura 6.21 mostra il tab RelationsSummary nel caso in cui siano state istanziate 2 relazioni di controllo tra il pulsante e la lampada. La prima 85 6 – Implementazione Figura 6.21. Il tab RelationsSummary (OnNotification-SetCommand) riguarda la relazione di controllo spiegata precedentemente. La seconda (OffNotification-OffCommand) gestisce l’interazione tra lampada e pulsante quando quest’ultimo viene rilasciato: la notifica OffNotification, generata dal pulsante a seguito di un evento di rilascio, determina la generazione e la trasmissione di un comando OffCommand il cui scopo è spegnere la lampada. È possibile eliminare la relazione di controllo selezionata o modificare il valore dei 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 mediante 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’albero di nodi) che descrive il progetto creato dall’utente nel foglio di lavoro. In particolare: • ogni nodo dell’albero descrive uno specifico oggetto; 86 6 – Implementazione • l’organizzazione dei nodi tiene conto delle relazioni di contenimento che intercorrono tra i vari oggetti istanziati nel foglio di lavoro (es. appartamento contiene stanza che, a sua volta, contiene un dispositivo). Questa struttura risulta utile per la generazione di documenti di configurazione nel formato xmldog, in quanto essi adottano una struttura gerarchica ed un’organizzazione del tutto simile. 6.5.1 Il formato xmldog Il formato xmldog (proposto dal gruppo di ricerca e-Lite) definisce un insieme di tag XML il cui scopo è la descrizione di ambienti domotici. La descrizione di un ambiente si sviluppa in 2 parti: 1. descrizione della struttura di un ambiente: un impianto domotico consiste di un edificio (xmldog:building) che può contenere appartamenti (xmldog:flat), garage (xmldog:garage) e giardini (xmldog:garden). Le stanze presenti in un appartamento (xmldog:room) sono delimitate da muri (xmldog:wall) e dotate di un pavimento (xmldog:floor) ed un soffitto (xmldog:ceiling); 2. descrizione dei dispositivi istanziati e delle relazioni di interazione presenti tra essi. Per ogni dispositivo viene inserito nel file di configurazione un oggetto xmldog: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. Queste informazioni devono essere introdotte solo se il dispositivo non è standard (non ha parametri di configurazione specifici per ogni singolo comando o notifica e non è connesso ad altri dispositivi); • la descrizione delle eventuali relazioni di controllo instaurate tra il dispositivo 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 dal modulo BuildFile nel formato introdotto precedentemente. Le 2 parti (descrizione della struttura e dei dispositivi) devono, ovviamente, essere integrate nello stesso documento di configurazione (una di seguito all’altra). 87 6 – Implementazione Descrizione della struttura di un ambiente Un appartamento (“Flat1”, Figura 6.23) contiene una stanza (“Cucina”) delimitata da 4 muri e dotata di un soffitto (“ceiling1”) ed un pavimento (“floor1”). Il terzo e quarto muro contengono rispettivamente una porta (“Entrata”, che consente l’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) è posizionato nella stanza “Cucina”, ha una componente di rete di tipo BTicino e controlla il funzionamento di una lampada (“Lampada1”). Tra i 2 dispositivi sono state instaurate 2 relazioni di controllo: • la generazione di una OnNotification (“PulsanteLampadaOnNotification1”) da parte del “PulsanteLampada” determina la trasmissione alla lampada di un comando OnCommand il cui scopo è accendere la luce (“Lampada1OnCommand1”); • la generazione di una OffNotification (“PulsanteLampadaOffNotification1”) da parte del “PulsanteLampada” determina la trasmissione alla lampada di un comando OffCommand il cui scopo è spegnere la luce (“Lampada1OffCommand1”); 88 6 – Implementazione 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 cui le soluzioni sviluppate nella tesi trovano applicazione. In particolare i primi due casi di studio sono semplici e hanno lo scopo di valutare: 1. le funzionalità di progettazione offerte da DogDomoticIde; 2. la validità del file di configurazione generato. Il terzo caso di studio (SimpleHome) viene affrontato con lo scopo di confrontare (in termini di tempi impiegati e difficoltà riscontrate) 2 tecniche per la generazione del documento di configurazione da installare sul gateway DOG (progettazione grafica mediante DogDomoticIde, creazione diretta di istanze dell’ontologia DogOnt mediante il software Protégé). Per realizzare i test descritti nel seguito è stato utilizzato il prototipo di sistema domotico a disposizione del gruppo di ricerca e-Lite del Politecnico di Torino. Tale architettura comprende: • un insieme di dispositivi Konnex e BTicino (lampade, interruttori, attuatori); • un gateway DOG; • l’applicazione DogSimpleClient, capace di interagire con DOG allo scopo di ricevere 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 seguito della progettazione effettuata. La struttura dell’ambiente è stata realizzate mediante le 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 (BathRoom), cucina (DiningRoom), soggiorno (LivingRoom), entrata (Lobby). Le restanti 2 stanze (posizionate a nord-est ed a sud-ovest dell’appartamento) vengono ignorate in quanto non rientrano nel progetto iniziale: la loro presenza è una conseguenza del fatto che l’appartamento può 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 è composto da lampade OnOffLight (il cui scopo è illuminare le varie stanze) e da dispositivi Switch (interruttori). I network gateway BTicino (BT) e Konnex (KNX) rappresentano i punti di accesso necessari a DOG per dialogare con i dispositivi istanziati nell’impianto. 91 7 – Casi di studio Si procede con la definizione della componente di rete di ogni dispositivo. Tale configurazione va fatta in relazione alla reale natura dei dispositivi che si hanno a disposizione per il test. Nel caso in esame la lampada “Lamp StorageR” e l’interruttore “Switch StorageR” hanno marchio BTicino. Per questi 2 dispositivi occorre quindi definire una componente di rete di tipo BTicino: mediante la tab Network (Property View) si seleziona la voce “BTicinoNetworkComponent” e si impostano i parametri relativi a questa tecnologia. Per tutti i restanti dispositivi viene dichiarata 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 quale è connesso mediante un ControlLink (collegamento di colore verde che permette la definizione 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 è possibile fare accesso alla tab ControlRelation (Property View) ed impostare le seguenti relazioni di controllo: • OnNotification (“Switch StorageR”)→ OnCommand (“Lamp StorageR”); • OffNotification (“Switch StorageR”)→ OffCommand (“Lamp StorageR”). La notifica OnNotification (generata da “Switch StorageR” a seguito di un evento di posizionamento in stato di “On” dell’interruttore stesso) determinerà la trasmissione del comando OnCommand alla lampada “Lamp StorageR” con lo scopo di accendere la luce. Analogamente, a seguito di un evento di di posizionamento in stato di “Off” dell’interruttore (OffNotification), dovrà essere generato un comando OffCommand il cui scopo è spegnere la luce della lampada. Le relazioni di controllo che intercorrono tra tutte le altre coppie interruttore - lampada sono analoghe a quelle appena descritte. 7.1.1 Generazione del file di configurazione ed installazione su DOG La stesura delle relazioni di controllo conclude la progettazione dell’ambiente in esame. A questo punto è possibile generare il file di configurazione selezionando, dal menù File di DogDomoticIde, la voce Build configuration file. Tale file viene infine installato sul gateway DOG (all’interno del bundle HouseModel). La validità del documento di configurazione prodotto da DogDomoticIde viene poi verificata mediante l’applicazione DogSimpleClient . I risultati emersi da questa prima sperimentazione sono soddisfacenti: tutti i dispositivi sono correttamente riconosciuti da DOG ed è possibile, mediante l’interfaccia fornita da DogSimpleClient, controllare l’accensione e lo spegnimento delle lampade. 92 7 – Casi di studio 7.2 Caso 2: ambiente composto da 2 appartamenti Il secondo caso di studio (Figura 7.2) ha lo scopo di valutare DogDomoticIde nel caso di progettazione di ambienti aventi una struttura architettonica più complessa. Si procede pertanto all’inserimento di un ulteriore appartamento nel progetto creato nel caso di studio iniziale. Il nuovo appartamento contiene 3 camere (BathRoom, Lobby e BedRoom) nelle quali è stato istallato il solo impianto di illuminazione (lampade, interruttori, pulsanti e relè). Figura 7.2. Caso di studio 2 93 7 – Casi di studio I dispositivi “Lamp LobbyR”, “ Relay1”, “Light BedR” e “Relay2” vengono simulati in quanto non fisicamente disponibili (non richiedono cioè la definizione di alcuna componente di rete). Per i restanti dispositivi occorre invece impostare una componente di rete di tipo Konnex (tab Network, Property View). Ogni pulsante controlla l’accensione e lo spegnimento di una lampada mediante un relè. “Button LobbyR”, ad esempio, controlla il relè “Relay1” mediante la seguente relazione di interazione: • OnNotification (“Button LobbyR”)→ ToggleCommand (“Relay1”); A seguito di un evento di pressione del pulsante “Button LobbyR” viene generato un comando ToggleCommand che fa cambiare di stato il relè: se il relè era 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 seguente funzionamento: a seguito di un evento di pressione di “Button LobbyR” viene generato un comando ToggleCommand che imposta “Relay1” in posizione “On”. Tale evento comporta la generazione di un comando OnCommand che accende la luce di “Lamp LobbyR”. Analogamente, a seguito di un successivo evento di pressione del pulsante, viene generato un comando ToggleCommand che imposta il relè in posizione “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 successiva installazione sul gateway DOG. Purtroppo la versione di DOG utilizzata per gli esperimenti non supporta ambienti domotici distribuiti su più appartamenti; ciò ha portato a delle problematiche di riconoscimento dei dispositivi e degli ambienti descritti 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 difficoltà incontrate nel progettare un ambiente domotico più articolato (SimpleHome, Figura 7.3) con DogDomoticIde. All’interno di ogni stanza sono stati istanziati oggetti di arredamento (es. letto matrimoniale, guardaroba, tavolo, sofà, ecc.), dispositivi di automazione per finestre 94 7 – Casi di studio Figura 7.3. SimpleHome e serrande (ShutterActuator, WindowActuator), lampade ed interruttori per la gestione dell’illuminazione, dispositivi DoorSensor per la segnalazione dello stato delle porte (una porta può essere aperta o chiusa). I dispositivi WindowActuator/ShutterActuator permettono di automatizzare l’apertura e la chiusura delle finestre/serrande alle quali sono connessi (ActuatorLink). WindowActuator viene controllato da 2 pulsanti (“Button open”, “Button close”) 95 7 – Casi di studio in maniera tale che: • quando “Button open” viene tenuto premuto l’attuatore aprirà la finestra; • quando “Button close” viene tenuto premuto l’attuatore chiuderà la finestra; • quando “Button open” o “Button close” vengono rilasciati allora l’azione di apertura/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 provvederà a far salire la serranda; • quando “Button down” viene tenuto premuto l’attuatore provvederà a far scendere la serranda; • quando “Button up” o “Button down” vengono rilasciati allora l’azione di salita/discesa della serranda deve interrompersi. Le relazioni di controllo che implementano tale comportamento sono analoghe a quelle descritte in precedenza. Ultimata la progettazione dell’ambiente si procede con la generazione e l’installazione del file di configurazione su DOG. 7.3.1 Tecniche a confronto: risultati sperimentali Sperimentalmente si è provato a modellare la SimpleHome mediante 2 tecniche di progettazione: 1. DogDomoticIde (descritta in precedenza); 2. creazione del file di ontologia mediante il software Protégé. 96 7 – Casi di studio Setup sperimentale • utente esperto di ontologie e di tecnologie domotiche, capace sia di utilizzare DogDomoticIde, sia di creare istanze di DogOnt mediante Protégé; • distribuzione delle prove in 2 sessioni di test distinte: 1. progettazione SimpleHome mediante DogDomoticIde; 2. progettazione mediante Protégé (sessione distribuita nell’arco di una settimana). • tempi di durata delle sessioni di test misurati mediante l’uso di un timer software. I valori riportati nel seguito sono da intendere come quantità di tempo richiesto per modellare la SimpleHome mediante le 2 tecniche di progettazione. Risultati ottenuti T ecnica DogDomoticIde Protégé T empo ∼1 ora ∼40 ore Dif f icoltà bassa elevata L’applicazione DogDomoticIde, grazie alla sua interfaccia grafica a componenti, ha permesso una più rapida modellazione dello scenario in esame e la conseguente costruzione del relativo documento di configurazione xmldog. 97 Capitolo 8 Conclusioni L’applicazione DogDomoticIde, progettata e realizzata in questa tesi, implementa le funzionalità che soddisfano tutti i requisiti funzionali primari definiti nella fase di progettazione: fornisce un’interfaccia grafica per la progettazione di ambienti domotici e consente l’esportazione delle informazioni di progetto in un formato utilizzabile dal gateway DOG. DogDomoticIde permette a progettisti non esperti di tecnologie 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 presenta notevoli margini di sviluppo, sia per quanto riguarda le capacità di editing grafico, sia per la gestione del modello dati. Allo stato attuale non è possibile, ad esempio, rappresentare appartamenti di forma non rettangolare. Il modello dati, costruito sulla base dell’ontologia DogOnt v1.0.3, contiene la descrizione completa di tutti gli elementi istanziabili all’interno di un impianto domotico. Il continuo evolversi dell’ontologia spinge alla costruzione di un modulo per DogDomoticIde che permetta di selezionare, a run-time, una nuova versione di DogOnt con conseguente aggiornamento del modello dati. Lo sviluppo di questo modulo è molto importante per il futuro di quest’applicazione: mantenere il modello dati aggiornato rispetto alla versione di ontologia utilizzata da DOG, consente la produzione di file di configurazione sempre compatibili con il gateway stesso. L’applicazione costruita risulta adatta anche per scopi simulativi. Un possibile sviluppo futuro consiste nell’introdurre moduli di simulazione che consentano al progettista di verificare il funzionamento dell’impianto creato, prima della sua applicazione in un ambiente reale. Da un punto di vista implementativo, la costruzione di DogDomoticIde tramite l’ausilio del plug-in GMF ha presentato vantaggi, ma anche punti critici. La generazione del codice ha semplificato lo sviluppo dell’applicazione, sebbene abbia determinato l’insorgere di notevoli problemi nella fase successiva; ossia per la modifica del codice al fine di introdurre funzionalità aggiuntive. Il plug-in domoticIde.diagram 98 8 – Conclusioni (generato da GMF) è infatti composto da un centinaio di classi Java, scritte e pensate per essere modificate il meno possibile. Inserirsi in quel contesto ed applicare le soluzioni descritte nel capitolo 6 è stato molto complesso, dispendioso di tempo ed ha richiesto l’applicazione di strategie un po’ “forzate”. È da segnalare la mancanza di documentazione relativa alle classi generate da GMF: le uniche informazioni reperibili sono relative a soluzioni specifiche per alcuni problemi. Infine è risultato che GMF, per via delle limitate capacità di rappresentazione grafica, è uno strumento poco adatto per la creazione di applicazioni CAD. L’obiettivo del plug-in GMF è infatti quello di semplificare lo sviluppo di editor per la creazione e la rappresentazione logica di modelli di dati. Quest’ultimo limite non è risultato particolarmente sconveniente per la realizzazione di DogDomoticIde, in quanto gli obiettivi primari di quest’applicazione riguardano principalmente la capacità di modellazione domotica. 99 Bibliografia [1] [2] [3] [4] [5] Wikipedia: Domotica. http://it.wikipedia.org/wiki/Domotica. Eclipse RCP: Rich Client Platform. http://www.eclipse.org/home/categories/rcp.php. EMF: Eclipse Modeling Framework. http://www.eclipse.org/modeling/emf/. GMF: Graphical Modeling Framework. http://www.eclipse.org/modeling/gmp/. Davide Devescovi. Sviluppo di tool basati su un metamodello editabile graficamente. 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 ON CONSUMER ELECTRONICS. vol. 54/4 ISSN: 0098-3063, pp. 1656-1664. [7] D. Bonino, E. Castellina, F. Corno. Bringing Semantics to the Home: The Dog2.0 gateway. IEEE TRANSACTIONS ON SYSTEM, MAN AND CYBERNETICS, PART C. 100