Ambienti di Sviluppo Integrati per Sistemi Domotici Intelligenti - e-Lite

Transcript

POLITECNICO DI TORINO
III Facoltà 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 funzionalità 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, cioè
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 è la scienza interdisciplinare che si occupa dello studio di tecnologie
e di soluzioni architetturali atte a migliorare la qualità della vita in un ambiente
domestico. L’obiettivo di un impianto domotico è quello di rendere più “intelligente”
l’ambiente nel quale è installato al fine di aumentarne la sicurezza, centralizzare il
controllo dell’abitazione, semplificare lo svolgimento delle più comuni operazioni
anche ad individui che possiedano delle disabilità, e attuare politiche di risparmio
energetico. Le funzionalità di una rete domotica possono essere suddivise in due
categorie:
1. funzionalità di monitoraggio;
2. funzionalità di controllo centralizzato.
Le funzionalità di monitoraggio sono quelle che forniscono all’ambiente una maggiore affidabilità 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 capacità 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
dovrà agire di conseguenza attivando gli sprinkler, sistema automatico di estinzione
a pioggia, oppure effettuando una telefonata per contattare i soccorsi.
Le funzionalità 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
funzionalità sono molto importanti per persone con disabilità 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 più comuni tecnologie utilizzate nell’ambito di una rete domotica
filare, cioè 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 necessità 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 è 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 è 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 è possibile una comunicazione diretta tra un computer su
rete Ethernet ed un computer su rete WiFi, cosı̀ non è possibile una comunicazione
diretta tra un dispositivo Konnex ed un dispositivo BTicino. In generale non è
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 è il tradizionale modello della smart
home. Per smart home, infatti, si è 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 più limitante in relazione al continuo espandersi del mercato della domotica ed alle sempre più complesse funzionalità richieste.
Inoltre è 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 è normale che i dispositivi non siano forniti tutti dallo stesso produttore con la conseguenza che, in alcuni casi, non è possibile un’interazione diretta
per via delle diverse tecnologie utilizzate.
Da queste problematiche nasce la necessità di inserire, in un impianto domotico,
un nodo centrale capace di fare da ponte per la comunicazione tra dispositivi disomogenei: il gateway domotico; in questa tesi, in particolare, tale gateway sarà DOG
(Domotic OSGi Gateway) sviluppato al Politecnico di Torino dal gruppo e-Lite.
DOG permette di espandere il tradizionale modello domotico diventando il 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 funzionalità 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 più 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 determinerà 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 è 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 è la
conoscenza dell’ambiente in cui viene installato: DOG deve essere “informato” su
come è strutturato l’ambiente (piani, stanze), da quali elementi architetturali è
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 è DogOnt, un metamodello basato sulla modellazione semantica
e composto da due parti:
• un’ontologia (DogOnt Ontology), espressa in OWL, il cui compito è 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 è dovuta al fatto che è
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 dovrà 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 potenzialità
del gateway, dall’altro introduce delle problematiche di configurazione. Produrre un
documento istanza di DogOnt è 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 Protégé) crea molte difficoltà al
progettista: richiede di essere fortemente specializzati ed è dispendioso di tempo. Per
alleggerire questa problematica è 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 più
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 può essere considerata definitiva per il problema: anche se il formato proposto
è più 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 è 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 è quello di creare un’istanza dell’ontologia DogOnt utilizzando software come Protégé. 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 priorità 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,
potrà:
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
proprietà) 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 è realizzato sulla base della piattaforma Eclipse RCP e del plug-in
GMF (Graphical Modeling Framework). Inoltre il modello dati di lavoro è costruito
per essere accessibile ad eventuali, ulteriori, plug-in che in futuro potranno estendere
l’applicazione fornendo funzionalità aggiuntive.
1.3
Struttura della tesi
Il presente documento è organizzato nei seguenti capitoli:
Stato dell’arte (cap. 2) - ha lo scopo di di approfondire il contesto in cui 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 è recente ed è 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 multimedialità.
Le attuali soluzioni domotiche presentano però 2 problematiche che ne frenano lo
sviluppo:
• la presenza di molti produttori di componenti domotici, ognuno dei quali è
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 interoperabilità con i sistemi prodotti dagli altri vendor: non è
infatti possibile fare interagire direttamente dispositivi costruiti da diversi produttori
perchè, 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’interoperabilità era secondario. Oggi invece queste tecnologie trovano applicazione anche in grandi strutture (hotel, università, ospedali,
7
2 – Stato dell’arte
ecc.) dove è scontata la presenza di dispositivi costruiti con tecnologie diverse che
necessitano di essere coordinati da un unico sistema centrale.
L’altro problema sopra citato è legato alla concezione dei componenti domotici
come un’evoluzione dei dispositivi elettrici. Questo approccio è riduttivo in quanto le
funzionalità richieste ad un sistema domotico sono sempre più 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 più complesse
funzionalità.
Al fine di risolvere queste problematiche è necessario estendere il modello proposto dalla smart home inserendo, nel sistema domotico, un dispositivo (il gateway)
in grado, grazie alle sue capacità computazionali, di supportare l’interoperabilità 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 capacità, indipendentemente dagli aspetti tecnologici. Ad esempio una lampada viene modellata come un oggetto in grado emettere
luce, indipendentemente dalla tecnologia con cui è 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 è stato sviluppato dal gruppo e-Lite il linguaggio DogOnt, un metamodello in formato OWL il cui scopo è permettere la descrizione di sistemi domotici.
Attualmente DogOnt viene utilizzato per permettere la modellazione dell’ambiente
e per introdurre capacità di ragionamento all’interno del gateway domotico DOG.
Nel paragrafo successivo sarà 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) è tipicamente composto da uno
o più sistemi domotici, da un insieme di elettrodomestici e da un Home Gateway che
permette di implementare politiche di interoperabilità e comportamenti intelligenti.
8
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 funzionalità 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”, cioè capaci di offrire funzionalità 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 interoperabilità: dispositivi appartenenti a sistemi diversi non possono
interagire per via delle diverse tecnologie e dei diversi protocolli utilizzati per comunicare. L’ home gateway è 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 priorità:
9
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 capacità 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 funzionalità avanzate ed opzionali).
2.2
Il linguaggio DogOnt
DogOnt è 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 è in grado di affrontare problemi di
interoperabilità consentendo di descrivere:
• dov’è situato un dispositivo domotico;
• le capacità e le funzionalità di un dispositivo;
• le specifiche tecnologiche necessarie per interfacciarsi con un dispositivo;
• le possibili configurazioni che un dispositivo può assumere;
• come è strutturata l’abitazione (piani, stanze, muri);
• gli elementi architetturali e di arredamento presenti nell’ambiente.
Queste informazioni possono poi essere sfruttate da sistemi basati sull’inferenza
per fornire le funzionalità avanzate richieste al sistema domotico.
DogOnt è composto di due parti: un’ontologia (DogOnt Ontology), espressa in
OWL, il cui compito è formalizzare tutti gli aspetti di un IDE, e un insieme di regole
(DogOnt Rules), che facilitano il processo di modellazione generando automaticamente gli stati e le funzionalità relativi ai dispositivi, e associandoli automaticamente
alle opportune istanze attraverso regole sematiche.
10
2.2.1
DogOnt Ontology
Un’ontologia è una rappresentazione formale di un’interpretazione condivisa di uno
specifico dominio di conoscenza. Non esistendo l’ontologia perfetta, la rappresentazione di un determinato dominio può 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 - proprietà, 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.
È 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 ereditarietà (isA). Ad esempio, come si osserva nella Figura 2.2, la classe Garage (che descrive
l’ambiente garage) è una specializzazione della classe BuildingEnviroment: eredita cioè le proprietà di ogni tipologia di ambiente incrementandole con le proprie
caratteristiche specifiche.
Anche se non rappresentate nella figura, sono possibili situazioni di ereditarietà multipla. Tutte le classi che descrivono un dispositivo (Computer, AlarmClock, ecc.), ad esempio, derivano sia dalla classe Controllable (che definisce
le funzionalità 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 è 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’interoperabilità tra i dispositivi in quanto permette uniformità nel linguaggio utilizzato per la loro descrizione. L’insieme delle classi definite da DogOnt può essere
diviso in 8 gruppi:
• Building Thing: per modellare qualsiasi elemento controllabile e non controllabile. Si definisce elemento controllabile (o dispositivo) un elemento che
può 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 funzionalità
(Functionality, rintracciate dalle relazioni hasFunctionality) e può assumere
11
Figura 2.2.
La struttura di DogOnt Ontology
diverse configurazioni di stato (State, identificate mediante la relazione hasState). La quantità ed il tipo di stati e di funzionalità 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 può contenere una o più stanze (cucina, camera da letto, bagno,
ecc.);
• Functionality: per modellare le operazioni che si possono effettuare su un
dispositivo. Tutte le funzionalità definiscono i comandi necessari per modificare o per interrogare una specifica proprietà del dispositivo. Sono suddivise in
12
diverse categorie in relazione al loro scopo: le ControlFunctionality modellano la capacità di controllare un dispositivo. Le NotificationFunctionality riguardano l’abilità di un dispositivo di segnalare un proprio cambiamento
di stato. Le QueryFunctionality permettono di interrogare un dispositivo
che fornirà, quindi, informazioni sulla propria configurazione attuale. Infine le
funzionalità 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 proprietà che possono assumere solo valori discreti. Le relazioni
hasNotification e hasCommand contengono rispettivamente i riferimenti alle
notifiche ed ai comandi che realizzano concretamente le funzionalità svolte
dalle NotificationFunctionality e ControlFunctionality;
• State: per modellare le configurazioni che un dispositivo può assumere. Come
per le funzionalità, anche gli stati vengono classificati in base ai valori che
possono assumere: i ContinuosState, che riguardano quelle proprietà che
possono assumere valori continui, ed i DiscreteState, associati alle proprietà
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
intensità luminosa regolabile. Questo dispositivo, nel formato OWL utilizzato da
DogOnt, è 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
Figura 2.3.
Esempio di interconnessione tra una lampada ed uno switch
funzionalità definite nelle super classi: dalle classi Lamp, Controllable e HousePlant vengono ereditate rispettivamente le funzionalità 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 è inoltre caratterizzata dalla
funzionalità LightRegulationFunctionality e dallo stato LightIntensityState:
LightRegulationFunctionality definisce i comandi StepUpCommand, StepDownCommand e SetCommand(value) per governare l’incremento ed il decremento dell’intensità luminosita, LightIntensityState tiene traccia, in percentuale, del valore
dell’intensità 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 proprietà della
lampada sono descritte dalle relazioni:
14
• hasState: relazione che contiene il riferimento ad un’istanza della classe LighIntensityState che, tramite il valore LightIntensityStateValue, tiene traccia del valore corrente dell’intensità luminosa (nell’esempio 77%);
• isIn: relazione che descrive la posizione dell’oggetto nell’ambiente. Nell’esempio la lampada è inserita in una LivingRoom;
• hasFunctionality: relazione che contiene il riferimento ad un’istanza di una
classe funzionalità. Ogni lampada di tipo DimmerLamp è 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’intensità luminosa della lampada.
Il controllo che il dispositivo OnOffSwitch esercita sulla lampada è 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 è in posizione “Off” la
lampada deve essere spenta, quando è 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) è una piattaforma che permette l’interfacciamento,
la gestione e l’integrazione di dispositivi domotici prodotti da diversi costruttori.
Nell’architettura OSGi i protocolli e gli altri moduli aggiuntivi, come ad 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 è l’elevata flessibilità del sistema: un bundle può
15
essere infatti aggiunto all’architettura in modo da estenderne le sue capacità, può 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 è 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 entità (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. È
costituito da:
• DogDeviceManager : rileva la registrazione di servizi Device e associa
questi dispositivi all’opportuno Driver service;
• DogDevice: è l’oggetto Dog che rappresenta la classe dispositivi definita
in DogOnt. Si tratta del software proxy del dispositivo reale il cui compito
è interfacciare il dispositivo con l’opportuno Driver service;
16
• 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 uniformità nella rappresentazione dei diversi dispositivi.
Attualmente è composto da 3 bundle:
– Konnex Network Driver, per i sistemi KNX;
– BTicino Network Driver, per i sistemi MyHome BTicino;
– Emulator Network Driver che permette di emulare i dispositivi fisicamente non disponibili, consentendo cosı̀ di utilizzare il software anche
in assenza di un ambiente domotico reale, cioè in simulazione.
• HouseModel : bundle che contiene l’istanza dell’ontologia DogOnt che descrive la struttura, le proprietà e le capacità dello specifico ambiente IDE
nel quale il gateway è installato. Questo modulo sfrutta le informazioni
derivanti dalle classi e dalle istanze di DogOnt per implementare funzionalità di ragionamento e politiche intelligenti per l’ambiente. In particolare
HouseModel permette la generazione delle regole necessarie per realizzare
l’interoperabilità 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 interoperabilità
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
interoperabilità. Le regole prodotte vengono infine comunicate al bundle
DogRules.
2. Device Control include i bundle dedicati a controllare ed a monitorare i
dispositivi. È 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
• 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 interoperabilità (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 è basata sullo
scambio di oggetti DogMessage ognuno dei quali è 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:
• difficoltà nella creazione del modello di un singolo appartamento/edificio;
• capacità computazionali richieste da DOG.
Il primo punto riguarda il fatto che il funzionamento del gateway DOG si basa
sul modello dell’ambiente contenuto nel bundle HouseModel ed espresso nel formato
OWL. Produrre un documento istanza dell’ontologia DogOnt è 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 Protégé) e questo
crea molte difficoltà: la complessità del processo richiede un’alta specializzazione
18
che esula dalle capacità dell’installatore medio. Per ridurre questo problema occorre
produrre degli strumenti il cui compito è facilitare la produzione di un modello OWL.
Il lavoro di questa tesi si pone l’obiettivo di fornire al progettista un 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 è relativo alle difficoltà nell’elaborare informazioni complesse
e nell’applicare sistemi inferenziali in tempo reale su sistemi con capacità 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’interoperabilità tra dispositivi domotici diversi e l’aggiunta di funzionalità avanzate. Se da un lato DOG incrementa le capacità 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, è 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 è dovuta al fatto
che è 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 è che produrre un documento istanza
di DogOnt è 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 Protégé) crea molte difficoltà al progettista: richiede di essere
fortemente specializzati ed è dispendioso di tempo.
Questo approccio frena quindi lo sviluppo e l’installazione di ambienti domotici
basati su DOG in quanto è molto difficile produrre un file di configurazione corretto
ed è comunque pensabile solo per la descrizione di sistemi semplici, dove gli elementi
e le interazioni presenti siano pochi.
Per alleggerire questa problematica è stato proposto, sempre dal gruppo e-Lite,
un tool in grado di generare automaticamente un file di ontologia partendo da un
20
3 – Obiettivi
documento di configurazione XML. Il formato XML proposto (xmldog) ha una struttura più semplice rispetto al formato OWL e permette al progettista di descrivere
l’ambiente inserendo solo le informazioni essenziali. È 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 può essere considerata
come la soluzione definitiva per il problema: anche se il formato proposto è più 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 possibilità 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 funzionalità 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 priorità. 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 proprietà)
relativi agli ambienti creati ed ai componenti inseriti;
4. layout dell’applicazione costituito da almeno:
• Design View : vista nella quale l’utilizzatore progetta l’impianto 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 proprietà 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 già 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 è considerato valido se tutte le sue proprietà sono compilate ed
assumono un valore sintatticamente corretto;
22
3 – Obiettivi
5. permettere la creazione di una struttura abitativa più 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. funzionalità 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 dovrà essere costruita sulla base della piattaforma Java Eclipse
RPC. Proprio per questa ragione ogni scelta progettuale dovrà 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 è strutturata come composizione
di plug-in ognuno dei quali fornisce funzionalità diverse. I plug-in vengono
classificati in 2 categorie: i core plug-in, che definiscono le funzionalità di base
del workbench e gli add-on plug-in, che contengono funzionalità 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 funzionalità che realizzano;
3. viste multiple: ogni plug-in può 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 è descritto in base ad un insieme di proprietà (nome, tipo, descrizione, funzionalità che possiede, configurazioni
che può assumere,ecc.).
Project plug-in
Rappresenta l’ossatura dell’applicazione. Ha il compito di:
• definire il formato del file di progetto;
• supportare le seguenti operazioni su file: salvataggio, caricamento, chiusura 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 è composta
da un insieme di finestre organizzate in tab ognuna delle quali permette l’editing di
una categoria specifica di proprietà 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 funzionalità 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 proprietà 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 è quella di utilizzare come base
per l’applicazione un progetto Open Source (come ad esempio CADEMIA o
SweetHome3D) che realizza le funzionalità di editing 2D permettendo di realizzare graficamente un ambiente domestico. In questo caso il lavoro di tesi
consiste nell’integrare il progetto con le funzionalità 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 proprietà, ecc.
Vantaggi - funzionalità di disegno 2D già realizzate e di buona qualità.
Svantaggi - difficoltà nell’integrare il modello dati basato sull’ontologia DogOnt: è 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 già 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 funzionalità: 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
funzionalità 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 funzionalità di disegno 2D sono di base, il progetto generato è
complesso e difficilmente estendibile.
La soluzione adottata è quella basata sull’uso del plug-in GMF. La ragione di
questa scelta è legata al fatto che l’obiettivo primario dell’applicazione è quella di
fornire un ambiente di modellazione per sistemi domotici anche con capacità 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 funzionalità 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 necessità di scrivere codice per molti
dei casi più comuni.
4.1
La piattaforma Eclipse
La piattaforma Eclipse è 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, è 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 popolarità risiedono sia nella sua
natura aperta, sia nella sua versatilità. Eclipse non è infatti strettamente dipendente da Java e non è nemmeno limitato al settore degli ambienti di sviluppo. In
particolare, grazie al sottoinsieme di componenti denominato RCP 1 , è possibile realizzare applicazioni per qualunque tipo di funzione (tool di supporto per l’analisi
di molecole chimiche, strumenti finanziari, ecc.).
Questa versatilità è 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; è inoltre piuttosto semplice suddividere
la programmazione di un applicativo in più moduli, per poi integrarli a lavoro finito.
La Figura 4.1 mostra i componenti principali della piattaforma: alla base di tutto
viene posizionato il Platform Runtime, un kernel che fornisce tutte le funzionalità
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 particolarità di quest’architettura è che, ad eccezione del Platform Runtime,
tutti i componenti, anche quelli forniti di default, sono di fatto dei plug-in.
Un plug-in è la più piccola unità funzionale sviluppabile e distribuibile 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, può essere costituito da più
plug-in ognuno dei quali, a sua volta, può essere frammentato in più 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, cioè 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
Grazie ai file di manifesto è 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: facilità di integrazione grazie agli extension point, flessibilità e dinamicità grazie alla disponibilità 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 è 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 è quello di fornire un punto di incontro tra il mondo
della modellazione e quello della programmazione.
La funzionalità principale di EMF è 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 consisterà innanzitutto nel creare il modello, e quindi, dopo aver generato il codice tramite EMF, nell’implementare i comportamenti
specifici che il modello non è in grado di rappresentare (ad esempio la funzionalità
di un metodo in una classe Java). Le parti più 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 funzionalità come il supporto
alla personalizzazione del codice, una Reflective API per generare dinamicamente
modelli, serializzazione e deserializzazione dei dati (in formato XMI) e la possibilità
di generare semplici editor grafici.
4.2.1
Componenti
L’Eclipse Modeling Framework è 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. È 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 è EObject (equivalente a java.lang.Object),
28
Figura 4.2.
La gerarchia del modello ECore
mentre, a scendere nell’albero, vengono posizionate le varie classi che 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
funzionalità
avanzate
e
di
alto
livello,
comandi che permettono la modifica delle proprietà degli oggetti istanziati, con il
supporto alle operazioni di undo e redo.
L’ultima componente di EMF è EMF Codegen le cui funzionalità 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 è l’importazione di un modello dati. Allo stato
attuale sono quattro i formati che si possono utilizzare:
• XMI : si può definire il proprio modello interamente in XMI, cosı̀ com’è definito
il meta-modello ECore;
• XMLSchema: se si ha già a disposizione un modello espresso in questo formato è 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: è supportato il
formato Rational Rose;
• interfacce Java annotate: se non si dispone di un editor grafico UML, o se non
si è pratici del linguaggio e si è più propensi a scrivere codice, questa opzione
risulta un’interessante alternativa.
Nell’ambito di questa tesi il modello dati per EMF è stato sviluppato utilizzando
la tecnica delle interfacce Java annotate, per questa ragione vale la pena analizzarla
con più attenzione.
Un programmatore che scelga di utilizzare questa soluzione deve scrivere le interfacce per le classi di cui avrà 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
proprietà “name” allora, nella relativa interfaccia, il programmatore dovrà 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 ereditarietà e di contenimento.
30
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 è 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 può 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
può 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 è 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
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 è facilitare lo sviluppo di rappresentazioni grafiche di modelli esistenti, creando editor dotati di funzionalità quali drag & drop, copia/incolla,
undo e redo. Una classica applicazione GEF consente di disegnare diagrammi di
vario tipo, con la possibilità di collegare le figure, ridimensionarle e spostarle.
4.3.1
Componenti
GEF si basa sul paradigma Model-View-Controller. Il modello deve essere definito
in codice Java senza vincoli particolari, GEF si occupa di realizzare le parti View e
Controller.
A tal fine è composto da due framework: Draw2D, incaricato della parte grafica,
ed il Graphical Editing Framework vero e proprio che si occupa di tutte le restanti
funzionalità.
• Draw2D è una libreria grafica utilizzabile indipendentemente sia da GEF che
da Eclipse. Offre grande flessibilità nella gestione delle figure: forme, colori,
contorni e layout si possono impostare con grande libertà 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 possibilità 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 è 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
ConnectionEditPart (quest’ultima non è 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 è 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 può quindi essere
riassunta in questa maniera:
1. generazione di una richiesta da parte del framework in relazione al comportamento dell’utente o, più 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 capacità dal punto di
vista grafico ma che necessita di un modello dati già pronto, dall’altro EMF, che
agevola la costruzione di un modello dati ma che fornisce solo funzionalità basilari
per l’editing grafico.
Sfruttando gli aspetti positivi di entrambi si può 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
incompatibilità (prima fra tutte quella fra i due stack di comandi) che rendono
tutt’altro che banale la loro integrazione.
33
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, è un framework il cui scopo è 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 è 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 è 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 è necessario disporre di un modello del dominio, rappresentato
nel formato ECore: per farlo è 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, cioè con la capacità
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 è 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
Figura 4.4.
Il workflow di GMF
grafico, ad esempio, definisce la classe Canvas, che può 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,
potrà realizzare la rappresentazione grafica desiderata.
Una volta completati questi tre modelli il lavoro è sostanzialmente finito: GMF
genererà automaticamente il Generator Model da cui, dopo aver eventualmente
personalizzato alcuni parametri, si passerà direttamente alla generazione del codice.
Sfruttando EMF Edit e GEF, GMF creerà comandi, EditPart, provider di contenuti
e tutto il necessario per realizzare un editor funzionante.
L’editor creato offrirà all’utente una serie di caratteristiche più 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 sarà descritta la prima fase, cioè 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 proprietà grafiche e funzionali di base dell’applicazione stessa. Il
procedimento che porta alla generazione dell’applicazione può 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 proprietà 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 è 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
Le interfacce create a partire da DogOnt sono riferite alle opportune interfacce definite nel DataModel Structure tramite relazioni di ereditarietà. Il modello prodotto
è 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 ereditarietà verso un’interfaccia del DataModel Structure).
Consideriamo ad esempio la classe lampada (Lamp) in DogOnt, essa rappresenta
un dispositivo con capacità di emettere luce. Essendo la lampada un dispositivo,
la sua interfaccia può essere riferita all’interfaccia DeviceElement che contiene le
dichiarazioni degli attributi tipici di ogni dispositivo. L’interfaccia Lamp, quindi,
estenderà l’interfaccia DeviceElement, più o meno direttamente.
Il package di interfacce risultante da questa prima fase di mapping tra DogOnt 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 provvederà 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
Come si osserva nella Figura 5.1, il plug-in domoticIde generato da EMF non è
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 è quella mostrata in Figura 5.2:
nel package dataModel.interface sono presenti le interfacce Lamp e DeviceElement
(legate da una relazione di ereditarietà).
Figura 5.2.
Esempio di interfacce e di classi implementazione
DeviceElement definisce l’attributo description, il cui contenuto rappresenta
una descrizione delle funzionalità 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 assumerà un valore diverso (setDescription(’’A machine for performing
calculations automatically, to work and play’’)). Naturalmente questo esempio ha scopo chiarificatore e quindi semplifica la realtà: l’interfaccia DeviceElement contiene infatti più attributi di quelli mostrati in Figura 5.2 e la definizione di
ogni dispositivo non è cosı̀ banale. I valori utilizzati per inizializzare gli attributi di
ogni elemento vengono ricavati dall’ontologia DogOnt.
39
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 baserà 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, cioè 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. È 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 è necessario creare gli oggetti Node e Figure Descriptor. Node
permette la descrizione delle informazioni grafiche di carattere generale. Figure
Descriptor invece descrive la forma e la composizione grafica dell’elemento. 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 è 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 proprietà dell’elemento stesso. Le corrispondenze create permettono
40
a GMF di generare il codice in modo tale che, ad ogni voce della palette degli oggetti,
corrisponda uno specifico oggetto grafico ed uno specifico elemento del modello dati.
Infine occorre osservare che solo una parte degli elementi descritti nel 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, più in generale, elementi
con una forma fisica, ma sono anche comandi, stati e notifiche, che descrivono il
comportamento e le funzionalità offerte dai singoli dispositivi. È 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 è 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 può 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 è relativa
ad uno specifico elemento istanziabile dall’utente nella Design View. Ogni
EditPart è completamente descritta e può 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 proprietà degli oggetti
istanziati.
41
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 proprietà 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
interfaccia prodotta avrebbe dovuto contenere al suo interno la definizione di tutte
le caratteristiche, con conseguente duplicazione delle informazioni.
Un ambiente domotico (classe Environment) può contenere un insieme generico
di elementi (classe Element) ognuno dei quali è 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 può, ad esempio, essere governata da un DoorActuator (che ne
gestisce l’apertura e la chiusura) il quale, a sua volta, può 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 può 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 più stanze. La forma di ogni ambiente, in una rappresentazione bidimensionale, è definita da un insieme di punti (xpoints, ypoints),
che costituiscono i vertici di un poligono.
Figura 5.7.
La classe BuildingArea
43
Figura 5.8.
Il DataModel Structure
44
I dispositivi (classe DeviceElement, Figura 5.9) sono elementi dell’ontologia 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 può assumere (states) variano per
ogni tipologia di dispositivo.
Figura 5.9.
La classe DeviceElement
Ogni dispositivo reale (fisicamente presente in un impianto domotico) è 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, può assumere 3 valori: BTicinoNetworkComponent, KonnexNetworkComponent
ed EliteNetworkComponent. BTicinoNetworkComponent contiene i parametri che
è necessario definire al fine di comunicare con un dispositivo BTicino MyHome
45
(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 è
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 può 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) può 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
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 è 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 luminosità di una
DimmerLamp, ha un parametro che rappresenta il valore desiderato di intensità
luminosa.
Ogni parametro (classe Param, Figura 5.11) è 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, è uno stato che può assumere solo due valori discreti (“On” e “Off”). Lo
stato LightIntensityState, che tiene traccia del valore di intensità luminosa di una
DimmerLamp, invece assume valori continui compresi tra 0% ed 100% (percentuale
di intensità 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
più 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
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
funzionalità di controllo. Ogni dispositivo controller contiene un riferimento a tutti
i dispositivi controllati (lista controlLinks) e la descrizione delle relazioni di controllo in cui è 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 è 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 è accendere la luce. La seconda è 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 è spegnere la luce. In questo caso è quindi necessario creare 2
istanze della classe ControlProperties.
48
La classe ActuatorElement (Figura 5.14) modella tutti i dispositivi attuatori.
Ogni attuatore può essere connesso ad un elemento architetturale (actuatorLink):
un DoorActuator, ad esempio, governa l’apertura e la chiusura di una porta.
I dispositivi sensori (SensorElement, Figura 5.14) possono essere sia connessi 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 è caratterizzato dall’avere almeno una rappresentazione grafica. Nella classe VisualElement (Figura
5.15) sono definite quelle proprietà 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
• dispositivi con capacità di controllo - classe ControlElement;
• dispositivi attuatori - classe ActuatorElement;
• dispositivi sensori - classe SensorElement;
• network level gateway - classe HomeGateway;
• i restanti dispositivi (elettrodomestici, dispositivi appartenenti all’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 proprietà 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
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 è 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
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 è definito, permette, con relativa semplicità, 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 capacità 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 consentirà di accedere alla lista di dispositivi.
Le relazioni di ereditarietà 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 ereditarietà 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. È 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 è relativa ai dispositivi controller, mappati sull’interfaccia ControlElement;
• la terza è relativa ai dispositivi sensori, mappati sull’interfaccia SensorElement;
• la quarta query estrae tutti i dispositivi rimanenti, mappati sull’interfaccia
DeviceElement.
52
Nella generazione delle interfacce si fa uso delle seguenti annotazioni:
@model - inserito all’inizio del file, definisce che l’interfaccia contenuta è 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 può essere modificato.
La Figura 5.17 mostra un esempio di 2 interfacce annotate: la prima (a) è 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 può osservare, l’interfaccia DeviceElement contiene la dichiarazione
53
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 è 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
(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
può assumere il dispositivo). La configurazione di una lampada (che può
solo essere accesa o spenta) è 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
• 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 baserà
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 funzionalità 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 è un modello ECore) corredato da un apposito
editor grafico.
56
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 proprietà 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, avrà forma
rettangolare e conterrà un’etichetta il cui scopo è visualizzare il nome dell’oggetto.
Il Node Descriptor (prima riga) contiene un riferimento al Figure Descriptor
(ComputerFigure, descrizione della composizione grafica dell’elemento Computer) e
permette di definire le caratteristiche grafiche di carattere generale.
Figura 5.21.
Descrizione grafica del dispositivo Computer
Osservando la figura si può notare come il Figure Descriptor associato all’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 proprietà del modello dati ed
un’etichetta. Nel caso in esempio Child Access permette di visualizzare il nome
dell’oggetto (il valore della proprietà name) nell’etichetta ComputerNameFigure.
La rappresentazione grafica descritta è analoga per tutti gli altri elementi estratti dall’ontologia DogOnt. Per ognuno di essi è 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, cioè oggetti grafici filiformi che connettono i dispositivi interessati dalla
relazione. Sulla base della tipologia di relazione vengono definiti 3 tipologie di link:
57
• 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 può 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
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 può inserire nel suo progetto (Door, Entrance, Gate, Shutter e Window).
Ogni elemento istanziabile dall’utente deve essere descritto da un Creation Tool,
che inserisce una voce nella palette abilitando l’utente ad istanziare quello specifico
elemento all’interno del foglio di lavoro. Ogni Creation Tool può 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.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 proprietà.
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 è 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
proprietà. 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 proprietà 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 permetterà
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 proprietà
60
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 può 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 è un dispositivo attuatore (ActuatorElement)
e la destinazione un elemento architetturale (ArchitecturalElement);
• Sensor Link: la sorgente del collegamento è un dispositivo sensore (SensorElement)
e la destinazione un elemento architetturale (ArchitecturalElement).
5.5
Generazione dell’editor
I 3 modelli costruiti vengono forniti come input ad un tool di GMF che produce 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
2. definisce la Palette View, la Design View e la Property View e descrive inoltre
i contenuti dei menù 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) fornirà 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 è possibile istanziare gli elementi
contenuti nella palette e, quindi, descrivere un impianto domotico;
• Property View: permette all’utente di effettuare l’editing delle proprietà degli
oggetti istanziati nel foglio di lavoro. È 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 menù:
• File, contiene le voci per la gestione dei file di progetto (new, open, close, ecc);
• Edit, fornisce le operazioni di cut, copy, paste, undo e redo;
• Diagram, per la personalizzazione dell’aspetto degli oggetti;
• Window, consente di aprire una nuova istanza dell’applicazione;
• Help, contiene informazioni generali sull’applicazione (es. Version).
62
Figura 5.27. Screenshot dell’applicazione DogDomoticIde versione base, cioè 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 proprietà. La Property View, infatti, visualizza e
permette la modifica delle proprietà dell’oggetto selezionato. Le modifiche effettuate
agli attributi di un oggetto vengono registrate nella relativa EditPart.
Lo scopo della fase di implementazione è quello di intervenire in questa architettura al fine di:
• introdurre nuovi componenti:
– la Summary View, vista ad albero il cui scopo è 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 agirà:
– sulla Design View, per incrementare le funzionalità 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 proprietà
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 affinchè possa aggiornare il proprio contenuto.
6.2
La gestione degli ambienti stanza
Le funzionalità fornite dall’applicazione generata da GMF consentono all’utente di
istanziare, all’interno del foglio di lavoro, uno o più appartamenti, nei quali è possibile posizionare gli oggetti che definiscono l’impianto domotico. Questo approccio
non è completo in quanto, normalmente, un oggetto assume una posizione all’interno
di una stanza, la quale è 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
l’elemento appartamento come contenitore di stanze (Room, Kitchen, BedRoom,
ecc) che, a loro volta, vengono descritte come contenitori di oggetti (dispositivi,
arredamento, ecc). In questo caso l’utente dell’applicazione deve provvedere alla:
1. creazione di oggetti appartamento;
2. creazione, all’interno di ogni appartamento, di uno o più oggetti stanza;
Questa soluzione, che ha il vantaggio di essere facilmente implementabile (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 è di tipo rettangolare, l’utente può istanziare solo stanze
di quella forma.
Si è quindi deciso di adottare una soluzione alternativa nella quale una stanza è
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 più oggetti appartamento;
2. istanziare e posizionare uno o più 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 libertà 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
è quindi possibile, ad esempio, creare stanze di forma circolare (in quanto non è
possibile istanziare muri concavi).
(a)
Figura 6.2.
(b)
Esempio di struttura di due ambienti appartamento
66
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 proprietà della stanza che
rappresenta (nome e tipologia di stanza).
6.2.1
L’algoritmo RoomDetection
Lo scopo dell’algoritmo RoomDetection è 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 verrà descritto il funzionamento dell’algoritmo (Figura 6.4) e, parallelamente, sarà trattato un caso di studio (Figura 6.5) al fine di semplificare la
comprensione dell’algoritmo stesso.
67
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
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
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 è di tipo orizzontale le
aree di intersezione individuate vengono ordinate da sinistra verso destra (rispetto al
foglio di lavoro). Se il muro è 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
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 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 già 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 è già 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
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 è quello di immaginare le aree
di intersezione ottenute in precedenza come nodi di un grafo, ognuno dei quali è
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 profondità di questo grafo: è possibile “muoversi” su un nodo direttamente connesso al nodo in esame. Il nodo A, ad
71
esempio, consente di “spostarsi” sui nodi B o F che, a loro volta, consentiranno 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 profondità 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 è arrivati da A).
La rilevazione di un ciclo nella visita del grafo (si vuole visitare un nodo che
è già stato attraversato in passato) è la condizione necessaria che può condurre
72
all’individuazione di una stanza. All’inizio di ogni iterazione il metodo contain
verifica se graphSearch contiene il nodo che deve essere visitato (currentArea). 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 può 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 è la lista roomList che contiene la descrizione delle camere trovate.
Implementazione
Le funzionalità 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
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 verrà 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 è stato spostato (nel
foglio di lavoro) delle quantità dx (orizzontale) e dy (verticale) rispetto alla
sua posizione precedente;
74
• 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 è stato dimostrato che il primo approccio risulta il migliore
dal punto di vista dello user-experience. Per sopperire alla problematica del costo
computazionale si è 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 può 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 può 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
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
rappresentano graficamente le stanze presenti nell’appartamento permettendo
all’utente di visualizzare e modificare le proprietà 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 diventerà 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
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 è 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
• livello 3: contiene i nodi successori dei nodi Rooms, Walls, Doors e Windows.
È quindi composto dai nodi che descrivono le stanze, i muri, le porte e 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
• 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 sarà 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 è indicato nel suo secondo parametro (object.getFlat().getName() fornisce il nome dell’appartamento
dentro il quale è 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
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 funzionalità della Summary View
L’esempio in Figura 6.14 mostra l’aspetto tipico della Summary View. Un appartamento (“Appartamento1”) è 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 è 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 funzionalità di ricerca degli oggetti: la selezione di un
81
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 proprietà 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 è un puntatore ad una funzione il cui
scopo è aggiornare i campi “Position” e “Size” del tab CommonProperties;
82
Figura 6.16.
Il tab CommonProperties
2. quando l’oggetto viene spostato o ridimensionato si procede con l’invio di 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 proprietà “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 affichè la componente di rete sia valida) e “PhysicalType”
(opzionale).
Figura 6.17.
Il tab Network/BTicinoComponent
La voce “KonnexComponent” (Figura 6.18) consente di impostare una componente di rete di tipo Konnex. I controlli visualizzati nel form permettono di
inizializzare i parametri definiti da questa tecnologia.
83
Figura 6.18.
Il tab Network/KonnexComponent
Il tab NetworkGateway (Figura 6.19), visualizzato solo in caso di selezione 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
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 intensità 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 può assumere e valore dato). Il comando SetCommand, ad
esempio, definisce il parametro value, livello di intensità 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’intensità 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
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 è spegnere la lampada.
È 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
• 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 è 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 può 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 è standard
(non ha parametri di configurazione specifici per ogni singolo comando o
notifica e non è 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
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) è 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 è 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 è spegnere la luce (“Lampada1OffCommand1”);
88
Figura 6.24.
Descrizione di un dispositivo nel formato xmldog
89
Capitolo 7
Casi di studio
Questo capitolo descrive la progettazione di scenari domestici reali/verosimili in 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 funzionalità di progettazione offerte da DogDomoticIde;
2. la validità del file di configurazione generato.
Il terzo caso di studio (SimpleHome) viene affrontato con lo scopo di confrontare (in
termini di tempi impiegati e difficoltà 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 Protégé).
Per realizzare i test descritti nel seguito è 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 è 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 è una conseguenza
del fatto che l’appartamento può solo avere forma rettangolare.
Vengono poi costruite 2 finestre (posizionate nel muro di confine sud), 4 porte
(posizionate nei muri 1, 2, 3 e 4) ed un’entrata (nel muro di confine est).
L’impianto domotico è composto da lampade OnOffLight (il cui scopo è 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
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
è 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 è 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) determinerà 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), dovrà essere generato un comando
OffCommand il cui scopo è 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 è possibile generare il file di configurazione selezionando,
dal menù File di DogDomoticIde, la voce Build configuration file. Tale file viene
infine installato sul gateway DOG (all’interno del bundle HouseModel). La validità
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 è possibile, mediante l’interfaccia fornita da DogSimpleClient, controllare
l’accensione e lo spegnimento delle lampade.
92
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 più 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 è stato istallato il solo impianto di illuminazione
(lampade, interruttori, pulsanti e relè).
Figura 7.2.
Caso di studio 2
93
I dispositivi “Lamp LobbyR”, “ Relay1”, “Light BedR” e “Relay2” vengono simulati in quanto non fisicamente disponibili (non richiedono cioè 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 relè. “Button LobbyR”, ad esempio, controlla il relè “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 relè: se il relè
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 relè 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 più appartamenti; ciò
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 difficoltà
incontrate nel progettare un ambiente domotico più articolato (SimpleHome, Figura
7.3) con DogDomoticIde.
All’interno di ogni stanza sono stati istanziati oggetti di arredamento (es. letto
matrimoniale, guardaroba, tavolo, sofà, ecc.), dispositivi di automazione per finestre
94
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 può 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
in maniera tale che:
• quando “Button open” viene tenuto premuto l’attuatore aprirà la finestra;
• quando “Button close” viene tenuto premuto l’attuatore chiuderà la finestra;
• quando “Button open” o “Button close” vengono rilasciati allora l’azione 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 provvederà a far salire
la serranda;
• quando “Button down” viene tenuto premuto l’attuatore provvederà 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 è provato a modellare la SimpleHome mediante 2 tecniche di
progettazione:
1. DogDomoticIde (descritta in precedenza);
2. creazione del file di ontologia mediante il software Protégé.
96
Setup sperimentale
• utente esperto di ontologie e di tecnologie domotiche, capace sia di utilizzare
DogDomoticIde, sia di creare istanze di DogOnt mediante Protégé;
• distribuzione delle prove in 2 sessioni di test distinte:
1. progettazione SimpleHome mediante DogDomoticIde;
2. progettazione mediante Protégé (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 quantità di tempo
richiesto per modellare la SimpleHome mediante le 2 tecniche di progettazione.
Risultati ottenuti
T ecnica
DogDomoticIde
Protégé
T empo
∼1 ora
∼40 ore
Dif f icoltà
bassa
elevata
L’applicazione DogDomoticIde, grazie alla sua interfaccia grafica a componenti,
ha permesso una più 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 funzionalità 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 capacità di editing grafico,
sia per la gestione del modello dati. Allo stato attuale non è possibile, ad esempio,
rappresentare appartamenti di forma non rettangolare. Il modello dati, 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 è 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 funzionalità aggiuntive. Il plug-in domoticIde.diagram
98
8 – Conclusioni
(generato da GMF) è 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 è stato molto complesso, dispendioso di tempo ed
ha richiesto l’applicazione di strategie un po’ “forzate”. È 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 è risultato che GMF, per via delle limitate capacità di rappresentazione
grafica, è uno strumento poco adatto per la creazione di applicazioni CAD. L’obiettivo del plug-in GMF è infatti quello di semplificare lo sviluppo di editor per
la creazione e la rappresentazione logica di modelli di dati. Quest’ultimo limite
non è risultato particolarmente sconveniente per la realizzazione di DogDomoticIde,
in quanto gli obiettivi primari di quest’applicazione riguardano principalmente la
capacità 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

Ambienti di Sviluppo Integrati per Sistemi Domotici Intelligenti - e-Lite

Transcript

Documenti analoghi

GO Lamps - Sixpol.com

Zoo Med Powersun UV 100W

Zoo Med Powersun UV 160W

717513516 Philips Lampada a sospensione

Igrostato FLZ 600 Unità combinata Igrostato/Termostato FLZ 610

Lampada a sospensione Avengers blu

X-48MKII

Il “suolo” come riferimento Politecnico di Milano

Matteo Milani