Public Light Manager - Una GUI per la gestione remota di un impianto di illuminazione pubblica

1,266 views

Published on

Implementazione di una
interfaccia grafica (GUI) per la gestione di una rete di illuminazione pubblica. L’applicazione, legge da un database esterno i dati della rete di illuminazione e li presenta all’utente. Questi dati comprendono le coordinate
GPS, le caratteristiche tecniche e l’indirizzo seriale di ciascun lampione. Mediante questi dati la rete di illuminazione viene rappresentata su una mappa
topografica e sottoforma di lista ordinata.
L’operatore ha quindi a disposizione una serie di strumenti e di criteri
per la seleziare i lampioni e per inviare determinati comandi da remoto.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,266
On SlideShare
0
From Embeds
0
Number of Embeds
13
Actions
Shares
0
Downloads
13
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Public Light Manager - Una GUI per la gestione remota di un impianto di illuminazione pubblica

  1. 1. ` Universita Politecnica delle Marche ` Facolta di Ingegneria Corso di Microelettronica Public Lighting ManagerUna GUI per la gestione di impianti di illuminazione pubblica Relatore Studente Prof. Claudio Turchetti Gianluca Ritrovati Correlatore matr: 221143 Prof. Giorgio Biagetti Anno Accademico 2011/2012
  2. 2. ` Universita Politecnica delle Marche ` Facolta di Ingegneria Corso di Microelettronica Public Lighting ManagerUna GUI per la gestione di impianti di illuminazione pubblica Relatore Studente Prof. Claudio Turchetti Gianluca Ritrovati Correlatore matr: 221143 Prof. Giorgio Biagetti Anno Accademico 2011/2012
  3. 3. Abstract In questa tesina viene relazionato il lavoro di implementazione di unainterfaccia grafica (GUI) per la gestione di una rete di illuminazione pub-blica. L’applicazione, legge da un database esterno i dati della rete di illu-minazione e li presenta all’utente. Questi dati comprendono le coordinateGPS, le caratteristiche tecniche e l’indirizzo seriale di ciascun lampione. Me-diante questi dati la rete di illuminazione viene rappresentata su una mappatopografica e sottoforma di lista ordinata. L’operatore ha quindi a disposizione una serie di strumenti e di criteriper la seleziare i lampioni e per inviare determinati comandi da remoto. 1
  4. 4. Indice1 Introduzione 4 1.1 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3 Scelte tecnologiche . . . . . . . . . . . . . . . . . . . . . . . . 6 1.4 Struttura della tesina . . . . . . . . . . . . . . . . . . . . . . . 72 Background 8 2.1 La libreria Qt . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.1 Il Meta-Object System . . . . . . . . . . . . . . . . . . 10 2.1.2 Meta-Object Compiler . . . . . . . . . . . . . . . . . . 11 2.1.3 Signals and Slots . . . . . . . . . . . . . . . . . . . . . 11 2.1.4 L’architettura Model/View . . . . . . . . . . . . . . . 14 2.2 Sistemi di coordinate . . . . . . . . . . . . . . . . . . . . . . . 17 2.2.1 Il sistema WGS84 . . . . . . . . . . . . . . . . . . . . 17 2.2.2 Il sistema cartesiano . . . . . . . . . . . . . . . . . . . 17 2.2.3 Conversione di coordinate . . . . . . . . . . . . . . . . 18 2.3 I servers WMS . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.3.1 Il progetto OpenStreetMap . . . . . . . . . . . . . . . 22 2.3.2 I tiles . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.3.3 Trasformazione di coordinate . . . . . . . . . . . . . . 233 Il Public Lighting Manager 25 3.1 L’interfaccia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.1.1 Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.1.2 Barra degli strumenti . . . . . . . . . . . . . . . . . . 27 3.1.3 Vista mappa . . . . . . . . . . . . . . . . . . . . . . . 28 3.1.4 Pannello filtri . . . . . . . . . . . . . . . . . . . . . . . 28 2
  5. 5. INDICE 3 3.1.5 Vista elenco . . . . . . . . . . . . . . . . . . . . . . . . 29 3.1.6 Barra di stato . . . . . . . . . . . . . . . . . . . . . . . 29 3.2 Gestione database . . . . . . . . . . . . . . . . . . . . . . . . 29 3.2.1 Avviare una nuova connessione . . . . . . . . . . . . . 29 3.2.2 Aprire un file di connessione . . . . . . . . . . . . . . . 31 3.2.3 Modifica database . . . . . . . . . . . . . . . . . . . . 31 3.2.4 Chiusura della connessione . . . . . . . . . . . . . . . 34 3.3 Selezione e filtraggio . . . . . . . . . . . . . . . . . . . . . . . 34 3.3.1 Selezione da mappa . . . . . . . . . . . . . . . . . . . 35 3.3.2 Selezione da tabella . . . . . . . . . . . . . . . . . . . 35 3.3.3 Selezione con filtro . . . . . . . . . . . . . . . . . . . . 36 3.4 Invio comandi . . . . . . . . . . . . . . . . . . . . . . . . . . . 364 Implementazione software 38 4.1 Gestione della mappa . . . . . . . . . . . . . . . . . . . . . . 38 4.1.1 Struttura di QMapControl . . . . . . . . . . . . . . . 39 4.1.2 Le geometrie . . . . . . . . . . . . . . . . . . . . . . . 39 4.1.3 I livelli . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 4.1.4 Richiesta dei Tiles . . . . . . . . . . . . . . . . . . . . 43 4.2 Struttura del progetto . . . . . . . . . . . . . . . . . . . . . . 44 4.3 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.3.1 Connessione . . . . . . . . . . . . . . . . . . . . . . . . 46 4.3.2 Database Editor . . . . . . . . . . . . . . . . . . . . . 49 4.4 L’architettura Model/View . . . . . . . . . . . . . . . . . . . 53 4.4.1 Implementazione del model . . . . . . . . . . . . . . . 53 4.4.2 Implementazione del view . . . . . . . . . . . . . . . . 54 4.5 Selezione e filtraggio . . . . . . . . . . . . . . . . . . . . . . . 55 4.5.1 Selezione singola da mappa . . . . . . . . . . . . . . . 55 4.5.2 Selezione multipla da mappa . . . . . . . . . . . . . . 55 4.5.3 La funzione performMouseSelection() . . . . . . . . . . 55 4.5.4 Selezione e filtraggio da pannello . . . . . . . . . . . . 56 4.6 Operazioni di Input/Output . . . . . . . . . . . . . . . . . . . 56 4.6.1 Operazioni di input . . . . . . . . . . . . . . . . . . . 56 4.6.2 Operazioni di output . . . . . . . . . . . . . . . . . . . 575 Conclusioni e sviluppi futuri 58
  6. 6. Capitolo 1Introduzione In questo capitolo si descrive il contesto teconologico nel quale il progetto` stato ideato. Vengono fissati gli obiettivi da raggiungere ed illustrate leemotivazioni che hanno portato alla scelta di determinate tecnologie. Viene infine descritta la struttura della tesina.1.1 Scenario Nell’ambito di politiche di risparmio energetico sempre pi` stringenti [5], uil settore dell’illuminazione sta vivendo un profondo moto di rinnovamento.Sia in campo domestico, che in campo industriale infatti, le tecnologie ener-geticamente meno efficienti, vengono progressivamente sostituite con nuovisistemi con alto rendimento e minor consumo. Il settore pubblico non fa eccezione, basti pensare che la voce di spesamaggiore per un bilancio comunale, ` quella relativa alla pubblica illumi- enazione, sia per quanto riguarda il consumo energetico e sia per i costi digestione e manutenzione. Le soluzioni che permettono un risparmio economico, implicano quindisia l’uso di dispositivi di illuminazione pi` efficienti, come ad esempio proiet- utori a tecnologia LED e sia una gestione telecontrollata di questi dispositivi,capace di regolare in tempo reale i flussi luminosi a seconda delle esigenze edella variabilit` delle condizioni di luce naturale. a Da un punto di vista tecnico quindi, ` facile prevedere l’uso sempre mag- egiore di elettronica di controllo ed in particolare, l’uso di protocolli wirelesscome lo ZigBee [1] [8]. Lo sviluppo futuro sar` quello di creare una rete a 4
  7. 7. 1.2 Obiettivi 5 Fig. 1.1: Una rete di lampioniintelligente di illuminazione, la cui gestione ` affidata ad un computer cen- etrale, dal quale poter avviare opportuni programmi di illuminamento o sucui ricevere tutte le informazioni sullo stato e sul consumo dei proiettori.1.2 Obiettivi Ipotizzando uno scenario come quello descritto precedentemente, il la-voro svolto in questo progetto, ` stato quello di sviluppare una interfac- ecia grafica (Graphical User Interface), per la gestione remota della rete diilluminazione pubblica. L’applicazione deve poter leggere da un database esterno i dati relativiai singoli lampioni della rete. Questi dati sono: • l’identificativo (ID) dell’apparato illuminante; • le coordinate geografiche del lampione, espresse come latitudine e lon- gitudine; • il nome della via dove il lampione ` situato; e • il gruppo (circoscrizione, quartiere, ecc.) al quale il lampione appar- tiene; • il tipo di supporto (su palo, a sospensione, a muro ecc.) e la data ultima di sostituzione;
  8. 8. 1.3 Scelte tecnologiche 6 • il tipo di lampada (a LED, ai vapori di sodio, alogena ecc.) e la data ultima di sostituzione; • il nome dell’operatore che ha effettuato l’installazione o l’ultimo inter- vento; • l’indirizzo seriale per l’invio dei comandi. L’applicazione deve prevedere la possibilit` modificare e di integrare, asuccessivamente, tutte le voci del database a seconda delle necessit`. a La rete di illuminazione deve essere rappresentata su una mappa, secondole coordinate di ciascun elemento. Inoltre l’operatore deve poter selezionare sulla mappa i singoli lampioni,sui quali poter effettuare le operazioni del caso. L’applicazione deve prevedere anche una forma di rappresentazione tabel-lare, con un pannello filtri che permetta la selezione per ubicazione, pergruppo, per lampada montata e per operatore tecnico. Al momento della stesura del progetto non ` stato ancora definito nello especifico l’hardware di comunicazione dei lampioni, pertanto le operazionieffettuabili su questi dispositivi sono limitati ai comandi di accensione espegnimento. Per lo stesso motivo non sono implementati gli algoritmi peril trattamento dei segnali di comunicazione con i dispositivi, ma i comandisi riducono alla semplice scrittura su un file di log ( log file.txt).1.3 Scelte tecnologiche Il progetto, che d’ora in avanti chiameremo “Public Lighting Manager” (oabbreviato P.L.M.), ` stato scritto in linguaggio C++, utilizzando il frame- ework Qt versione 4.7 [2]. Si tratta di una libreria di propriet` della Nokia, adistribuita gratuitamente, appositamente studiata per la realizzazione in-terfacce grafiche, con un approccio particolarmente orientato agli oggetti.Questo framework ` multipiatatforma, quindi permette il porting dell’appli- ecazione su diversi sistemi operativi (Linux, Windows e Mac) e su sistemi em-beded, come PDA e smartphones. Inoltre, Qt ingloba una serie di API (Ap-plication Programming Interface) di generica utilit`, che ci hanno agevolato anel creare le funzioni per l’accesso dell’applicazione al database SQL, nellaprogrammazione di rete e nella lettura/scrittura in formato XML.
  9. 9. 1.4 Struttura della tesina 7 Per lo storage dei dati abbiamo utilizzato un database di tipo MySql [3].Si tratta di un database open source, ormai diffusissimo grazie alle sue ottimeprestazioni, alla sua elevata affidabilit` e alla facilit` d’utilizzo. E’ anch’esso a amultipiattaforma ed ` ben supportato da Qt. e Per la visualizzazione della mappa ` stato utilizzato il servizio Open- eStreetMap [6]. Si tratta di un sistema partecipativo, simile a Wikipedia,per la condivisione di dati cartografici da apparati GPS. Rispetto al notoservizio Google Maps le mappe OSM possono essere utilizzate liberamente (egratuitamente) all’interno delle applicazioni, a patto che se ne citi la fonte.La natura collaborativa del progetto OSM fa si che il materiale mappale siasempre aggiornato e corretto. In presenza di nuove urbanizzazioni, ad es-empio, ` sufficiente aggiornare i dati caricando i nuovi tracciati con l’ausilio edi un normale dispositivo GPS.1.4 Struttura della tesina • Capitolo 2: Background. In questo capitolo viene presentata una panoramica sulle tecnologie adottate che sono alla base del progetto e sulle motivazioni che ne hanno determinato la scelta. • Capitolo 3: Il Public Lighting Manager. In questo capitolo illustreremo il funzionamento dell’applicazione dal punto di vista dell’utilizzatore finale. • Capitolo 4: Implementazione dell’applicazione. Viene presentata la struttura del progetto, sotto l’aspetto dell’implementazione del codice. Segue una panoramica sulle classi e le funzioni principali. • Capitolo 5: Conclusioni e sviluppi futuri. Si presentano i risultati dei test dell’interfaccia e le problematiche riscontrate. Si analizzano inoltre i possibili sviluppi dell’interfaccia.
  10. 10. Capitolo 2Background2.1 La libreria Qt Il framework Qt nasce da un progetto di Haavard Nord e Eirik Chambe-Eng (fondatori della Trolltech) nell’ambito della realizzazione di un ambi-ente per lo sviluppo di interfacce grafiche in C++ [10]. Mentre erano im-pegnati in questo progetto, ai due venne l’idea di rendere quel frameworkmultipiattaforma, garantendo la presenza delle stesse API sotto ogni sistemaoperativo. Nel 1995 venne pubblicata la prima versione del framework Qt. Nella programmazione di interfacce grafiche si richiede una buona effi-cienza a tempo di esecuzione ed un elevato grado di flessibilit`. Per soddis- afare questi requisiti che Qt combina alla velocit` del C++ la flessibilit` del a asuo modello ad oggetti. Nello specifico, Qt aggiunge le seguenti potenzialit` al C++: a • un potente meccanismo di comunicazione tra oggetti chiamato Signals and Slots; • un potente sistema di eventi e filtraggio degli eventi; • l’internazionalizzazione delle applicazioni; • la possibilit` di richiedere all’oggetto le sue propriet` dinamicamente; a a • un sistema di timer; • una gerarchia di oggetti, dove QObject n´ ` la radice; ee • un sistema di puntatori; 8
  11. 11. 2.1 La libreria Qt 9 • un cast dinamico che opera attraverso le librerie. Molte di queste caratteristiche vengono implementate con le tecnichestandard del C++, mentre altre, come la comunicazione Signals and Slotse il sistema dinamico delle propriet`, richiede il Meta-Object System imple- amentato da Qt attraverso il Meta-Object Compiler (MOC). Le classi che stanno alla base del modello ad oggetti di Qt sono: • QMetaClassInfo: contiene le informazioni su una classe • QMetaEnum: contiene i meta dati dei tipi enumerativi • QMetaMethod: contiene i meta dati sulle funzioni membro • QMetaObject: contiene meta informazioni sugli oggetti Qt • QMetaProperty: contiene meta data che riguardano le propriet` a • QMetaType: gestisce i nomi dei tipi nel Meta-Object System • QObject: la radice della gerarchia di oggetti Qt • QObjectCleanupHandler: gestisce il ciclo di vita degli oggetti • QPointer: classe che implementa i puntatori agli oggetti • QSignalMapper: gestisce i segnali dai sender identificati • QVariant: questa classe agisce come l’unione dei principali tipi degli oggetti Qt Un oggetto Qt valido deve avere: • Un nome univoco; • un posto nella gerarchia degli oggetti; • pu` essere connesso ad altri oggetti per inviare o ricevere segnali; o • deve avere un insieme di propriet`. a
  12. 12. 2.1 La libreria Qt 102.1.1 Il Meta-Object System Il Meta-Object System ` un estensione del C++ che rende il linguaggio epi` adatto alla programmazione di GUI mediante componenti che sfruttan- udo le elevate prestazioni del C++ e che non potrebbero essere raggiuntealtrimenti. Questo si base su tre aspetti: 1. la classe QObject fornisce una classe base per gli oggetti che possono usufruire del Meta-Object System; 2. la macro Q OBJECT all’interno della sezione privata della dichiarazione di classe viene utilizzata per abilitare alcune funzionalit` del meta a oggetto come le propriet` dinamiche, ed il sistema di comunicazione a Signals and Slots; 3. il Meta-Object Compiler fornisce ad ogni QObject il codice necessario per l’implementazione delle caratteristiche del meta oggetto. Inoltre, per fornire i meccanismi di comunicazione tra oggetti medianteSignals and Slots, il Meta-Object System mette a disposizione le seguentifunzionalit`: a • QObject::metaObject(): restituisce il meta oggetto associato alla classe • QMetaObject::className(): restituisce il nome della classe a tempo di esecuzione • QObject::inherits(): permette di discriminare se l’oggetto ` istanza di e una classe ereditata • QObject::tr() e QObject::trUtf8(): permettono la traduzione di stringhe per la propriet` di internazionalizzazione a • QObject::setProperty() e QObject::property(): permettono di leggere e settare le propriet` dell’oggetto dinamicamente a • QMetaObject::newInstance(): costruisce una nuova istanza della classe • qobject cast() utilizzato su un QObject da la possibilit` di eseguire un a cast dinamico dell’oggetto.
  13. 13. 2.1 La libreria Qt 112.1.2 Meta-Object Compiler Il Meta-Object Compiler (MOC) ` un applicazione di Qt per la gestione edelle estensioni C++. In particolare esso si occupa di creare un file sorgente,contenente il codice del meta oggetto, per ogni file sorgente contenente lamacro Q OBJECT o altre macro come PROPERTY e Q ENUMS. Questosorgente verr` poi incluso nel vecchio file o compilato e linkato all’implemen- atazione della classe. La creazione del file contenente il codice per il metaoggetto ` necessaria per implementare meccanismi come la comunicazione etra gli oggetti, la gestione delle propriet` dinamicamente e le informazioni adei tipi a runtime (RTTI). Un tipico file sorgente dove il MOC agisce ` emostrato di seguito: c l a s s MyClass : p u b l i c QObject{ Q OBJECTpublic : MyClass ( QObject ∗ p a r e n t =0) ; MyClass ( ) ;signals : void mySignal () ;public slots : v o i d mySlot ( ) ;}; La creazione dei sorgenti che contengono i meta dati pu` avvenire secon- odo due diverse modalit`: una che prevede l’utilizzo diretto del MOC addeb- aitando al programmatore l’onere di inserire delle regole per la gestione delMOC all’interno dei makefile, l’altra che prevede l’utilizzo del tool qmakeche crea automaticamente i makefile con le regole idonee per il correttofunzionamento del MOC.2.1.3 Signals and Slots Il sistema Signals and Slots implementa la comunicazione tra gli ogget-ti. Questa ` una caratteristica peculiare di Qt che lo differenzia da altri eframework per GUI in circolazione. Nell’ambito della programmazione di interfacce grafiche, ci si aspetta cheal variare di dati corrisponda la variazione di qualche elemento della GUI.Nei vecchi framework per la programmazione di GUI, questo meccanismo
  14. 14. 2.1 La libreria Qt 12viene implementato utilizzando dei riferimenti a delle funzioni detti callback.I problemi principali che affliggono questo sistema sono due: innanzituttonon ` type-safe, nel senso che non possiamo essere sicuri che la funzione echiamante invochi una funzione callback con i parametri adeguati, in secondoluogo, una funzione callback ` strettamente legata alla funzione chiamante, equindi quest’ultima deve conoscere con precisione la funzione da invocare. Il sistema Signals and Slots di Qt, rappresenta una valida alternativaal meccanismo del callback. Ogni oggetto Qt ` caratterizzato dall’avere euna serie di segnali e di slot, alla quale il programmatore pu` aggiungere oquelli creati autonomamente. Un segnale viene emesso da un oggetto alverificarsi di un determinato evento, mediante il metodo emit(), mentre loslot rappresenta l’azione, o la sequenza di azioni, da intraprendere quandoquesto viene attivato dal segnale al quale ` collegato. in pratica uno slot e` l’equivalente di un metodo con degli opportuni argomenti in ingresso. Aedifferenza del meccanismo di callback, Signals and Slots ` type-safe, nel senso eche la firma del segnale emesso deve coincidere con la firma dello slot chedeve essere eseguito. Inoltre, segnali e slot sono disaccoppiati, ci` vuol dire oche un segnale non deve conoscere lo slot a cui ` collegato. La connessione etra un segnale ed uno slot avviene mediante il metodo: c o n n e c t ( Sender , SIGNAL ( s i g n a l ( ) ) , R e c e i v e r , SLOT( s l o t ( ) ) ) dove i parametri assumono il seguente significato: → Sender: l’oggetto (o il thread ) che invia il segnale; → SIGNAL(signal()): il segnale che viene emesso dal Sender; → Receiver: l’oggetto (o un thread ) che riceve il segnale; → SLOT(slot()): le funzioni che il receiver deve eseguire alla ricezione del segnale. La Fig. 2.1 mostra un esempio di connessione tra oggetti. Questo mec-canismo prevede non solo la connessione tra segnale e slot, ma anche laconnessione tra due segnali, tra un segnale e pi` slot e tra pi` segnali ed uno u uslot. Ovviamente non ` contemplata la connessione tra due slot, in quanto enon ` possibile emettere uno slot. e Quando un segnale viene emesso, l’esecuzione dello slot avviene istan-taneamente e solo al termine della sua esecuzione, il chiamante riprende il
  15. 15. 2.1 La libreria Qt 13 Fig. 2.1: Esempio di collegamento Signal/Solt.controllo. Esiste anche la possibilit` di creare una coda di connessioni, in aquesto caso l’esecuzione dello slot associato all’emissione di un segnale nonavviene istantaneamente. La connessione tra segnale e slot pu` essere interrotta mediante la chia- omata alla funzione disconnect(). L’unico punto a sfavore di questo sistema di comunicazione ` che risulta eessere circa 10 volte pi` lento, rispetto a chiamare direttamente la funzione uda eseguire. Questo tempo ` dovuto all’overhead richiesto per localizzare el’oggetto, creare la connessione ed effettuare il marshall dei parametri. Tut-tavia questo rallentamento influisce in minima parte nel tempo complessivodi esecuzione del programma e rimane comunque pi` veloce dell’allocazione udi un nuovo oggetto mediante new. Vediamo infine un esempio pratico dell’utilizzo del sistema Signal /Slot. Si pu` notare come la creazione di un segnale avviene all’atto del- ola creazione della classe che definisce l’oggetto, mentre, la creazione di unoslot oltre a richiedere la dichiarazione, come avviene per il segnale, deveessere implementato allo stessa maniera di un metodo. public slots : void setValue ( int value ) ;signals v a l u e C h a n g e d ( i n t newValue ) ;
  16. 16. 2.1 La libreria Qt 14 void Counter : : SetValue ( i n t e v a l u e ){ i f ( v a l u e != m v a l u e ) { m v a l u e=v a l u e ; emit valueChanged ( value ) ; }}Couter a , b ;QObject : : c o n n e c t (&a , SIGNAL ( v a l u e C h a n g e d ( i n t ) ) , &b , SLOT( s e t V a l u e ( i n t ) ) ) ;a . s e t V a l u e ( 1 2 ) ; // a . v a l u e ( ) ==12, b . v a l u e ( ) ==12b . s e t V a l u e ( 4 8 ) ; // a . v a l u e ( ) ==12, b . v a l u e ( ) ==48 Siano a e b due oggetti di tipo Counter. L’invocazione del metodo set-Value() sull’oggetto a (uno slot pu` essere invocato anche come un normale ometodo) provoca la variazione dell’attuale valore dell’oggetto che emette ilsegnale valueChanged(int), attivando di conseguenza lo slot dell’oggetto bche provveder` ad assegnare il valore ricevuto come parametro. a2.1.4 L’architettura Model/View Il framework Qt introduce lo schema di progettazione Model/View Con-troller (MVC). Si tratta di un pattern architetturale molto usato nell’ingeg-neria del software, che consiste nel separare nettamente il problema dei datidalla loro rappresentazione, con dei vantaggi enormi in termini di flessibilit`. aIl pattern ` cos` composto: e ı • il model: fornisce i metodi per accedere ai dati utili all’applicazione; • il view: visualizza i dati contenuti nel model e si occupa dell’inter- azione con utenti e agenti; • il controller riceve i comandi dell’utente (in genere attraverso il view) e li attua modificando lo stato degli altri due componenti. Quando, come nel frmework Qt, il view ed il controller sono combi-nati si ottiene l’architettura model/view. Questa ha anch’essa il fine ul-timo di separare il modo il cui i dati sono memorizzati, dal modo in cuisono presentati, ma con un’architettura pi` semplice. Questa separazione u
  17. 17. 2.1 La libreria Qt 15 Fig. 2.2: Il pattern Model/View Controller.permette di rappresentare gli stessi dati in modi differenti, e da la possi-bilit` di implementare nuove views, senza dover cambiare la struttura dati asottostante. Per permettere la gestione flessibile dei dati da parte dell’utente, vieneintrodotto il concetto di delegate. Questo elemento gestisce la conversionedei dati, nello scambio tra model e view. Lo schema dell’archittettura model/view in Qt ` presentato in Fig. 2.2. e Il model comunica con la sorgente dati, provvedendo ad interfacciarlicon gli altri componenti dell’architettura. La natura della comunicazionedipende dal tipo di dati e dal modo il model ` implementato. e Il view ottiene dal model un sistema di indici riferito ai dati. Questiindici verranno utilizzati per recuperare i dati dalla sorgente. Nelle view standard, un delegate converte i singoli dati. Quando undato ` modificato, il delegate comunica direttamente con il model utilizzando ela sua indicizzazione. La comunicazione tra queste componenti avviene mediante il sistemaSignals and Slots: → i segnali provenienti dal model informano il view del cambiamento nei dati; → i segnali provenienti dal view contengono le informazioni nate dalle iterazioni dell’utente con la visualizzazione; → i segnali provenienti dal delegate aggiornano model e view: nello speci- fico informano il model se bisogna aggiornare o prelevare dei dati e il
  18. 18. 2.1 La libreria Qt 16 view se bisogna aggiornare la vista. Ognuna delle componenti descritte sono implementate in Qt da clas-si astratte che definiscono una interfaccia comune e, in alcuni casi, im-plementano alcune propriet` di defautl. Le classi astratte necessitano di aessere sottoclassate per ottenere un set completo di funzioni necessarie aicomponenti.Model Tutti gli oggetti model in Qt derivano dalla classe astratta QAbstrac-tItemModel. Questa classe implementa i metodi comuni a tutti i tipi dimodel. E’ flessibile a sufficienza da permettere al view di rappresentare idati come tabelle, liste o alberi. Strutture dati complesse possono esseremodellati creando delle sottoclassi di QAbstractItemModel. Per le strutturedati pi` comuni, Qt fornisce un’ampia scelta di sottoclassi. Per la gestione udel database MySql ad esempio, in questo progetto abbiamo utlizzato leclassi QSqlTableModel e QSqlRelationalTableModel.View Implementazioni complete sono fornite per diversi tipi di rappresen-tazione: QListView visualizza i dati in formato lista, qtQTableView vi-sualizza i dati di un modello in forma tabellare, mentre QTreeView mostrai dati come lista gerarchica. Ognuna di queste classi deriva dalla classe as-tratta QAbstractItemView. Tutte queste classi possono essere a loro voltasottoclassate per ottenere visualizzazioni personalizzate.Delegate Diversamente dal pattern MVC, la progettazione Model/View non com-prende una completa separazione delle componenti per la gestione delle iter-azioni con l’utente. In generale il view ` responsabile della presentazione dei edati e della gestione degli input da parte dell’utente. Per consentire maggiorflessibilit` nel modo in cui si ottengono questi input, le iterazioni con l’utente avengono gestite dal delegate. Questo componente oltre a gestire gli inputdall’utente, include anche delle funzionalit` di rendering per la modifica di aoggetti nelle viste. Le classi base dei delegate sono: QAbstractItemDelegatee QItemDelegate.
  19. 19. 2.2 Sistemi di coordinate 17 Questi aspetti del framework Qt verranno ripresi nei prossimi capitoli,quando tratteremo l’implementazione del framework model/view all’internodel nostro progetto.2.2 Sistemi di coordinate Verranno di seguito descritti due sistemi di coordinate, necessari perpoter lavorare con materiale mappale. Il World Geodatic System ` uno dei etanti sistemi di riferimento per mappe, ed uno dei pi` usati. u2.2.1 Il sistema WGS84 Il World Geodatic System (WGS84) ` un sistema di riferimento terrestre, ecartesiano e geocentrico. Il sistema tiene conto della non perfetta sfericit` adella terra. Esso ` realizzato con una precisione di ±1m. Le coordinate sono eespresse in gradi secondo due parametri: latitudine e longitudine. La longitudine, chiamata anche meridiano, giace perpendicolarmenteall’equatore e corre da un polo all’altro. E’ suddiviso in 360◦ , 180◦ nell’em-isfero orientale e 180◦ nell’emisfero occidentale. Il meridiano nullo passa perl’osservatorio di Greenwich, in Inghilterra. La latitudine, chiamata anche parallelo, giace parallelamente all’equa-tore. E’ suddivisa in 180◦ , 90◦ a nord dell’equatore e 90◦ a sud. Tra questecoordinate si pu` indicare anche la quota sul livello del mare. Le coordinate osono illustrate in Fig. 2.3. Il WGS84 costituisce il sistema di coordinate utilizzato anche dai sistemiGlobal Positioning System (GPS).2.2.2 Il sistema cartesiano Il sistema di coordinate cartesiano ` quello pi` diffuso in ambiti generali. e uGli assi delle coordinate sono disposti perpendicolarmente tra loro e si in-contrano in corrispondenza dell’origine. A seconda delle necessit`, l’origine apu` essere posta in corrispondenza di un qualsiasi punto di riferimento. o Sull’asse x (ascissa) i valori di coordinata crescono generalmente dasinistra a destra. Sull’asse y (ordinate) crescono in base all’applicazione: da sotto a soprao da sopra a sotto. Nella computer grafica ad esempio l’origine corrisponde
  20. 20. 2.2 Sistemi di coordinate 18 Fig. 2.3: Il sistema di coordinate WGS84. Fig. 2.4: Il sistema di coordinate cartesiano.all’angolo visualizzato in alto a sinistra. In questo caso i valori negativi nonsono accettabili poich´ non corrispondono alla posizione di pixel. Questo esistema di coordinate ` rappresentato in Fig. 2.4. e2.2.3 Conversione di coordinate Nel rappresentare dati geografici su uno schermo, nasce la necessita dioperare una conversione di coordinate da un sistema sferico, come il WGS84,in un sistema piano come quello cartesiano. Esistono diversi metodi diproiezione di coordinate ma tutti questi comportano inevitabilmente ancheuna distorsione. Non esiste una proiezione migliore, tutte si caratterizzanoper una determinata “semplicificazione“, occorre quindi solo scegliere quellapi` adatta ad una determinata applicazione. u Gli obiettivi di massima da osservare per una proiezione sono:
  21. 21. 2.2 Sistemi di coordinate 19 Fig. 2.5: Esempi di proiezione su solidi ♦ l’equidistanza; ♦ isogonalit`, cio` il mantenimento degli angoli; a e ♦ equivalenza delle aree. Le proiezioni si distinguono per il solido che funge da superficie di proiezione.Pertanto esistono proiezioni a cilindro, a cono e a livelli, come mostra-to in Fig. 2.5. Ad esempio una proiezione a cilindro non subisce distor-sione in corrispondenza dell’equatore, mentre avr` distorsione massima in acorrispondenza dei poli. La proiezione utilizzata nelle mappe OpenStreetMap ` quella di Merca- etore.La proiezione di Mercatore La proiezione di Mercatore ` una proiezione cartografica conforme e ecilindrica proposta nel 1569 dal geografo e cartografo fiammingo Gerard deCremer noto come Gerardus Mercator (italianizzato in Gerardo Mercatore). La rappresentazione di Mercatore ` uno sviluppo cilindrico diretto mod- eificato da un procedimento misto geometrico-analitico che rende le carteisogoniche (angoli uguali). Essa ` diventata la proiezione cartografica pi` e uusata per le mappe nautiche per la sua propriet` di rappresentare linee di acostante angolo di rotta (linee lossodromiche) con segmenti rettilinei. Men-tre la scala delle distanze ` costante in ogni direzione attorno ad ogni punto, econservando allora gli angoli e le forme di piccoli oggetti (il che rende laproiezione conforme), la proiezione distorce sempre pi` la dimensione e le uforme degli oggetti estesi passando dall’equatore ai poli, in corrispondenza
  22. 22. 2.3 I servers WMS 20 Fig. 2.6: La proiezione di Mercatore.dei quali la scala della mappa aumenta a valori infiniti (secondo un grigliatodelle latitudini crescenti). Lo schema della proiezione ` rappresentato in Fig. 2.6. Si pu` vedere e ocome le proiezioni partono dal centro della terra passando per gli angolicrescenti di latitudine fino ad intersecare la superficie di un cilindro. Laproiezione indicata con la linea rossa fuoriesce dal cilindro e pertanto nonpu` essere considerata. Per questa ragione gli angoli di latitudine sono da oconsiderarsi da +85,0511◦ fino a -85,0511◦ (invece che da +90◦ a -90◦ ). Lamappa piana risultante da questo tipo di proiezione ` illustrata in Fig. 2.7 e2.3 I servers WMS Per Web Map Service (WMS) si intende una specifica tecnica definitadall’Open Geospatial Consortium atta a produrre mappe dinamiche di datispazialmente riferiti a partire da informazioni geografiche. Questo stan-dard internazionale [4] definisce una mappa come la rappresentazione diinformazioni geografiche sottoforma di immagine digitale, idonea ad esserevisualizzata su browser web. Generalmente le mappe prodotte da un servizioWMS sono rese in un formato immagine quale PNG, GIF o JPEG, occa-
  23. 23. 2.3 I servers WMS 21 Fig. 2.7: Risultato della proiezione di Mercatore.sionalmente come elementi vettoriali in formato Scalable Vector Graphics(SVG) o Web Computer Graphics Metafile (WebCGM); contrariamente aun Web Feature Service (WFS), che restituisce dati vettoriali, o a un WebCoverage Service (WCS), che restituisce dati raster. Lo standard definisce tre operazioni: ♦ restituisce metadati a livello di servizio; ♦ restituisce una mappa dai parametri geografici e dimensionali definiti; ♦ restituisce informazioni sugli oggetti della cartografia visualizzata (opzionale). Le operazioni del Web Map Service vengono invocate usando un clientche supporti il protocollo HTTP, in forma di Uniform Resource Locators(URL). Il contenuto dell’URL dipende dalle operazioni richieste. In partico-lare, la composizione dell’indirizzo va fatta indicando quali informazioni de-vono essere visualizzate sulla mappa, quale porzione della Terra deve essererappresentata, il sistema di coordinate desiderato, il formato e le dimensionidell’immagine di output. Qualora due o pi` mappe siano prodotte con gli stessi parametri ge- uografici e di dimensione dell’immagine, i risultati possono essere sovrappostiper produrre una mappa composita. L’uso di formati che supportano la
  24. 24. 2.3 I servers WMS 22trasparenza (GIF o PNG per esempio) permette di visualizzare le parti dimappa sottostanti; inoltre mappe diverse possono essere richieste a differentiserver. In questa maniera il Web Map Service abilita la creazione di una retedi server cartografici che l’utente pu` utilizzare per costruire mappe person- oalizzate. Generalmente un Web Map Service non ` invocato direttamente; evengono utilizzate applicazioni client che forniscono all’utente controlli in-terattivi. Queste applicazioni client possono anche non essere web-based.La specifica WMS ` diventata standard ISO19128 nel 2005. e2.3.1 Il progetto OpenStreetMap L’OpenStreetMap ` un progetto collaborativo finalizzato a creare mappe emondiali a contenuto libero. La caratteristica fondamentale dei dati ge- e `ografici presenti in OSM ` che possiedono una licenza libera. E cio` possi- ebile utilizzarli liberamente per qualsiasi scopo con il solo vincolo di citare lafonte e usare la stessa licenza per eventuali lavori derivati dai dati di OSM. Le mappe sono create usando come riferimento i dati registrati da dis-positivi GPS portatili, fotografie aeree ed altre fonti libere. Sia le immaginirenderizzate che i dati vettoriali, oltre che lo stesso database di geodati, sonorilasciati sotto licenza Creative Commons Attribution-ShareAlike 2.0. OpenStreetMap ` stato ispirato da siti come Wikipedia. La comunit` e acollabora per integrare o modificare le mappe esistenti. Infatti ogni mappaconsultabile espone in evidenza l’etichetta Edit, per procedere alla mod-ifica dei dati. Tutti gli utenti registrati possono caricare nei database delprogetto, le tracce GPS e modificare i dati vettoriali usando gli editor forniti.2.3.2 I tiles Servizi come Open Street Map, Google Maps o Yahoo! Map, fornisconole mappe sottoforma di map tiles (piastrelle), cio` di immagini con una edimensione fissa. Per ogni fattore di zoom, la mappa del globo ` suddivisa ein un reticolo di tiles sempre pi` fitto. Per il primo fattore di zoom, ad uesempio, l’intero globo ` compreso in un unico tile. Ad ogni incremento di equesto fattore, il numero di tile cresce come il quadrato, secondo la regoladescritta in Tabella 2.1. La risoluzione della mappa quindi, ` direttamente eproporzionale al livello di zoom.
  25. 25. 2.3 I servers WMS 23Fig. 2.8: Una mappa con zoom differenti. Ad un incremento dello zoom itiles si quadruplicano. Grazie a questa suddivisione delle mappe, ` sufficiente scaricare dal server esolo la porzione di mappa che ci interessa. Questa porzione viene calcolatadal client in base alla posizione che vogliamo visualizzare e allo zoom. Larichiesta ` formulata sottoforma di indirizzo HTTP ad uno specifico server. ePer i server OSM, ad esempio, la richiesta di un tile allo zoom 16 assumequesta forma: http://tile.openstreetmap.org/16/34271/22224.png grado Zoom num. Tiles 0 1 1 2x2 2 4x4 n 2n x 2n Tabella 2.1: Numero di tiles per fattore di zoom2.3.3 Trasformazione di coordinate La proiezione di Mercatore, utilizzata dal servizio OpenStreetMap, trasfor-ma le coordinate geografiche in coordinate cartesiane bidimensionali. Questecoordinate cartesiane sono espresse in pixel, poich` sono riferite alle immag- eini tiles che costituiscono la mappa da visualizzare [9]. La longitudine va trasformata nella coordinata x mentre la latitudinenella coordinata y. Il range di variazione della longitudine va da -180◦ a+ 180◦ , pertanto la trasformazione comporterebbe valori negativi di pixel.
  26. 26. 2.3 I servers WMS 24Per evitare ci` ` necessario shiftare tutto l’intervallo di longitudine di 180◦ . oePertanto la longitudine andr` da 0 a 360◦ . La regione R di variazione della acoordinata x, dove sono proiettate le coordinate Cartesiane assolute, dipen-dono dal livello di zoom che andiamo a considerare. Per uno zoom pari a2, la terra ` rappresentata da un reticolo di 2*2 tiles. Dato che ogni tile ha edimensione pari a 256 pixel, la regione R avr` dimensione pari a 512*512 apixel. La longitudine varia linearmente, quindi la coordinata x si ricava con laformula: λ + 180◦ x= ∗ R; con R = 2z ∗ t 360◦ dove λ= longitudine in gradi, R=range in pixel, z =livello di zoom,t=dimensione singolo tile in pixel. La latitudine varia da -85,0511◦ a + 85,0511◦ . Dato che i tiles sonoquadrati, la coordinata y ` mappata sullo stesso range R in pixel della elongitudine. La coordinata y si ricava dalla formula: log(tan( π + ϕ )) 1−( 4 2 ) y= π ∗ R; con R = 2z ∗ t 2 dove ϕ= longitudine in gradi, R=range in pixel, z =livello di zoom,t=dimensione singolo tile in pixel.
  27. 27. Capitolo 3Il Public Lighting Manager L’applicazione Public Lighting Manager ` stata progettata per operare in euno scenario come quello rappresentato in Fig. 3.1. In fase di installazionedi una nuova rete pubblica di illuminazione, o in caso di adeguamento diuna rete esistente, vengono catalogati, mediante dispositivi portatili (PDAo tablet) connessi alla rete, i dati dei singoli lampioni. Per ciascun apparatosono registrati su un database remoto, le informazioni sulla locazione urbana,la posizione GPS, i dati tecnici e l’indirizzo seriale. L’applicazione P.L.M.,preleva questi dati dal database, e ricostruisce graficamente la disposizionedella rete d’illuminzione sulla mappa. Mediante l’interfaccia grafica, sem-plice ed intuitiva, l’operatore pu` selezionare ed inviare comandi di gestione oai lampioni, sia singolarmente che per gruppi. Nei paragrafi successivi illustreremo il funzionamento dell’applicazioneP.L.M, nei suoi aspetti principali.3.1 L’interfaccia L’interfaccia del P.L.M. presenta una grafica semplice ed intuitiva. L’usopertanto ` immediato, anche per utenti non specializzati. Inoltre, la grafica eadottata si presta bene ad un successivo porting su dispositivi portatili contouch-screen. In Fig. 3.2 ` mostrata la schermata che si presenta all’utente dopo l’avvio edell’applicazione e la connessione ad un database.Si possono distinguere seizone: 1. Menu 25
  28. 28. 3.1 L’interfaccia 26 Fig. 3.1: Scenario in cui opera il Public Lighting Manager 2. Barra degli strumenti 3. Vista mappa 4. Pannello filtro 5. Vista elenco 6. Barra di statoIllustriamo nel dettaglio il loro utilizzo.3.1.1 Menu Nel menu sono raccolte tutte le funzioni dell’applicazione: dalla gestionedel database, alla modalit` di visualizzazione. E’ composto dai seguenti aelementi: • File: gestione della connessione ad database e operazioni generali del- l’applicazione.
  29. 29. 3.1 L’interfaccia 27 Fig. 3.2: Interfaccia grafica del P.L.M. • Lamp: operazioni inerenti i lampioni (inserimento, eliminazione, mod- ifica, ecc.). • View: opzioni riguardanti le preferenze di visualizzazione. • Help: accesso alla guida e alle informazioni generali sull’applicazione P.L.M.3.1.2 Barra degli strumenti La barra degli strumenti ` composta da una serie di pulsanti che perme- ettono di accedere alle funzioni principali mediante un semplice click. Conriferimento alla Fig. 3.3, la barra ` suddivisibile come descritto di seguito: e(a) pannello database: funzioni di connessione ad un nuovo database, apertura di file di connessione, chiusura connessione e modifica delle voci del database.(b) pannello mappa: funzioni di zoom in e zoom out, drag della mappa e selezione rettangolare.(c) pannello lamp: funzioni di inserimento di una nuova lamp, modifica, eliminazione, accensione, spegnimento e richiamo delle informazioni.
  30. 30. 3.1 L’interfaccia 28 (a) (b) (c) Fig. 3.3: Pannelli degli strumenti (a) (b) (c)Fig. 3.4: Rappresentaizione dei lampioni:(a) stato off; (b) stato on; (c)stato di warning.Questi pannelli si trovano tutti sul lato superiore della mappa, ma durante lasessione possono essere spostati ai lati della mappa mediante trascinamentocon il mouse.3.1.3 Vista mappa In questa zona viene visualizzata la mappa OSM. Essa ` navigabile medi- eante trascinamento con il mouse (in modalit` drag) e zoommabile mediante ai pulsanti sopra descritti. La mappa ` composta da due livelli sovrapposti: e 1. livello mappa: ` sempre visibile e mostra il materiale offerto dal server e OSM 2. livello lamps: mostra la dislocazione dei lampioni sula mappa. Questi sono rappresentati nell’attuale stato, con le icone in Fig. 3.4. Questo livello pu` essere nascosto impostando il flag nel menu View oCliccando sulle icone, ` possibile selezionare una o pi` lamps. e u Cliccando con il tasto destro sulla mappa, viene aperto il menu con-testuale relativo alle lamps gi` selezionate. a3.1.4 Pannello filtri Il pannello filtri opera sulla vista elenco (Par. 3.1.5). Si possono applicarefino a tre regole che devono essere rispettate contemporaneamente. Perinstruzioni sull’utilizzo si veda il Par. 3.3.3.
  31. 31. 3.2 Gestione database 293.1.5 Vista elenco Oltre alla vista su mappa, l’applicazione elenca le lamps in forma tabel-lare. La vista elenco permette una rapida visione di tutti i lampioni instal-lati. L’elenco pu` essere ordinato cliccando sull’header dei campi desiderati. o E’ possibile inoltre selezionare una o pi` lamps cliccando sulla rispettiva uriga. Cliccando con il tasto destro sull’elenco, viene aperto il menu contes-tuale relativo alle lamps gi` selezionate. a I campi da visualizzare sono impostati attraverso il menu View->TableColumn mentre l’intera tabella pu` essere nascosta agendo sul flag Show oTable.3.1.6 Barra di stato Nella barra di stato appaiono, sulla sinistra, i messaggi dell’applicazionein risposta dei comandi impartiti dall’utente e i tool tip mentre sulla destrasono sempre visibili le coordinate attuali (riferite alla croce al centro delloschermo) e il livello di zoom corrente.3.2 Gestione database Come illustrato in Fig. 3.1, il software P.L.M. legge i dati relativi ailampioni da un database esterno, che pu` essere raggiunto attraverso la rete ointernet o attraverso una rete locale. Da questi dati ne ottiene un model,ossia una copia temporanea dei record che servono per poter rappresentarei lampioni e per poterli indirizzare. Lo schema del database e di tipo “relazionale” ed ` riportato in Fig. 3.5. eLa flessibilit` di questa particolare struttura, permette all’utente finale di aintegrare il database non solo di nuove lamps, ma anche di nuovi “attributi”per queste, senza limite alcuno. La modifica del database sar` trattata nei aprossimi paragrafi.3.2.1 Avviare una nuova connessione Cliccando su ( File > New Connection) si apre all’utente la finestradi dialogo in Fig. 3.6 con i seguenti campi:
  32. 32. 3.2 Gestione database 30 Streets strade Lamps 1 lampioni id int id int streetName varchar longitude double latitude double n Groups streetId int gruppi foreign key 1 n id int groupId int groupName varchar foreign key n bodyId int Bodies foreign key strutture 1 bodyDate date n id int bulbId int bodyName varchar foreign key bodyImage BLOB bulbDate date n operatorId int Bulbs lampade foreign key 1 id int address varchar bulbName varchar Operators operatori 1 id int operatorName varchar Fig. 3.5: Struttura del database Fig. 3.6: Finestra di dialogo per una nuova connessione • Host Name: l’indirizzo IP del database in rete. Nel caso si utilizzi un database locale questo valore ` localhost; e • User Name: l’utente con i diritti di lettura e scrittura del database; • Password: parola segreta per l’accesso; • Database Name: un server pu` contenere pi` database, occorre quindi o u specificare il nome al quale si fa riferimento. Compilati i campi si pu` decidere se salvare la connessione in un file XML o( Save), in modo da non doverli reinserire successivamente, o se procederecon la connessione al database ( Connect).
  33. 33. 3.2 Gestione database 313.2.2 Aprire un file di connessione Il pulsante ( File > Open connection file) permetter di aprire unaconnessione salvata su file XML. Il file di connessione deve avere la seguente struttura:<P L A d m i n i s t r a t o r > <Database> Nome d e l d a t a b a s e </Database> <Pass> Password </Pass> <User> Nome u t e n t e </User> <Host> I n d i r i z z o h o s t </Host></ P L A d m i n i s t r a t o r > L’applicazione verifica prima la presenza del root tag <PLAdministra-tor>, in tal caso procede con lo scaricamento dei dati, altrimenti restituisceun messaggio di errore.3.2.3 Modifica database L’editor del database consente di aggiungere, eliminare o modificare tuttele voci del database. Si pu` accedere al database editor cliccando su o (File > Database editor). La finestra ` composta da pi` widget, accessibili e ufacendo click sulle icone a sinistra.Scheda Lamps In questa scheda (Fig. 3.7(a)) ` possibile inserire una nuovo lampione a ecoordinate da specificare. Ad ogni lampione ` associata una serie di infor- emazioni come la strada ove ` ubicato ( Street), a quale gruppo appartiene e( Group), su che tipo di supporto ` montato ( Body Type) e in che data ` e estato installato( Body Date), che tipo di lampada monta ( Bulb Type) e ladata dell’ultima sostituzione ( Bulb Date), l’operatore che ha effettuato leultime modifiche ( Operator) ed infine l’indirizzo in formato esadecimale dellampione ( Digital Address). Parte di queste informazioni vengono scelte at-traverso menu a tendina, le cui voci vengono prelevate da tabelle relazionate,che possono essere editate dalle schede seguenti.
  34. 34. 3.2 Gestione database 32 (a) (b) Fig. 3.7: Schede (a)“Lamps” e (b)“Groups”Scheda Groups La definizione di un “group” ha lo scopo di facilitare la selezione diun insieme di lamps che rispondono a determinate caratteristiche definitedall’utente. Si possono ad esempio definire gruppi in base all’ubicazione(quartiere o zona), oppure in base alle caratteristiche di sezionamento dellalinea elettrica. Per aggiungere un “group” (Fig. 3.7(b)) specificarne il nome ( Name) ecliccare sul pulsante Add. Per modificare un “group”, effettuare doppio click sulla riga e cliccare suSave, per eliminarlo selezionare la riga e cliccare su Delete.Scheda Streets E’ l’elenco delle strade dove sono ubicate le lamps. Conoscere la “vi-a” di ubicazione di un lampione, ne permette la rapida localizzazione nelsistema urbano. Inoltre, grazie alle funzioni che vedremo pi` avanti, tale in- uformazione ci permetter` di selezionare tutti gli apparati situati nella stessa astrada. Per aggiungere una “street” (Fig. 3.8(a)) specificarne le tipologia ( Type),il nome ( Name). e cliccare sul pulsante Add. Per modificare una “street”, effettuare doppio click sulla riga e cliccaresu Save, per eliminarla selezionare la riga e cliccare su Delete.
  35. 35. 3.2 Gestione database 33 (a) (b) Fig. 3.8: Schede (a)“Streets” e (b)“Bodies”Scheda Bodies Elenco delle strutture dei lampioni. Oltre alla sigla body name, pu` oessere associata una immagine che presenta graficamente all’utente il fattoredi forma del lampione. Per aggiungere una struttura (Fig. 3.8(b)) specificarne il nome ( Name)e cliccare sul pulsante Add. Per caricare una immagine inserire il percorso del file nel campo Image... Per modificare un “body”, effettuare doppio click sulla riga e cliccare suSave, per eliminarlo selezionare la riga e cliccare su Delete.Scheda Bulbs Elenco dei diversi tipi di lampade utilizzate. In base alle diverse neces-sit` di illuminazione possono essere utilizzate tecnologie differenti (lampade aLED, a scarica, alogene ecc.). In sviluppi futuri, questa specifica sar` utile aper diversificare il controllo software delle lampade. Per aggiungere una lampada (Fig. 3.9(a)) specificarne il nome ( Name),la potenza in watt ( Power) e cliccare sul pulsante Add. Per modificare un “bulb”, effettuare doppio click sulla riga e cliccare suSave, per eliminarlo selezionare la riga e cliccare su Delete.
  36. 36. 3.3 Selezione e filtraggio 34 (a) (b) Fig. 3.9: Schede (a)“Bulbs” e (b)“Operators”Scheda Operators In un contesto dove un gruppo di operatori lavora sulla stessa linea,pu` essere utile conoscere quale tecnico ha operato l’ultimo intervento sul olampione. Per aggiunger un nuovo operatore (Fig. 3.9(b)) specificarne nome e cog-nome ( Name, Surname) e cliccare su Add. Per modificare un “operator”, effettuare doppio click sulla riga e cliccaresu Save, per eliminarlo selezionare la riga e cliccare su Delete.3.2.4 Chiusura della connessione Il pulsante ( File > Close connection file) disconnette l’applicazionedal database. In questo caso sia la vista mappa che la vista elenco vengono“pulite” dalle lamps Questo comando viene eseguito automaticamente anchenel caso in cui ci si avvii una nuova connessione.3.3 Selezione e filtraggio In un uso “a regime”, ` facile pensare che ci si possa trovare a gestire euna rete di illuminazione pubblica molto vasta, con un numero di lampioninell’ordine delle migliaia di unit`. Assume quindi particolare importanza a
  37. 37. 3.3 Selezione e filtraggio 35 Fig. 3.10: Scheda “Operators”l’utilizzo di strumenti che permettano di operare la selezione delle lamps inmodi diversi, secondo le varie necessit`. a3.3.1 Selezione da mappa Questa selezione viene effettuata mediante la vista mappa. In modalit` aMove map ( ) ` possibile selezionare un lampione cliccando sul simbolo eall’interno della mappa. Selezioni multiple sono possibili tenendo premuto iltasto Ctrl e facendo click sulle lamp desiderate. In modalit` Rect selection a( ) i lampioni possono essere selezionati tracciando un rettangolo sullazona scelta. I lampioni all’interno del rettangolo vengono cos` selezionati. ıLa procedura di deselezione funziona secondo lo stesso principio.3.3.2 Selezione da tabella In tabella appaiono tutti i lapioni sottoforma di elenco. La selezione sipu` effettuare cliccando su una riga della tabella. Tenendo premuto il tasto osinistro e muovendo il mouse ` possibile selezionare record contigui. Per eselezioni multiple discontigue, invece, ` sufficiente tenere premuto il tasto eCtrl e cliccare sui record desiderati. Pu` essere utile, ai fini della selezione, oordinare l’elenco delle lamps in base ai valori di un determinato campo; per
  38. 38. 3.4 Invio comandi 36 Fig. 3.11: Strumento di selezione in base a filtrofare ci` basta cliccare sugli header della tabella e procedere con la selezione. oLa procedura di deselezione funziona secondo lo stesso principio.3.3.3 Selezione con filtro Lo strumento filtro (Fig. 3.11) permette di selezionare le lamps mediantel’impostazione di determinate regole, che devono essere rispettate contem-poraneamente. E’ possibile selezionare per gruppo ( Group), per strada (Street) o per il tipo di lampada ( Bulb). I filtri vengono attivati cliccando sul Radio Button Filter o Select; nelprimo caso vengono elencati solo i lampioni che rispettano le regole selezion-ate, nel secondo caso vengono mostrati tutti i lampioni ma sono selezionatisolo quelli che rispettano le regole selezionate.3.4 Invio comandi Al momento del primo rilascio dell’applicazione, non esiste ancora unainterfaccia hardware definita, pertanto i comandi di output sono simulati elimitati all’accensione e allo spegnimento delle lamps. I comandi si applicano ai lampioni selezionati, pertanto prima di inviareun comando occorre selezionare una o pi` lamps secondo i metodi descritti unei paragrafi precedenti. Il comando di accensione viene inviato cliccando il pulsante , mentreil comando di spegnimento viene inviato cliccando su . Ad ogni comandole icone dei lampioni cambiano in base al nuovo stato.
  39. 39. 3.4 Invio comandi 37 Tutte le operazioni di output pengono tracciate sul file di log log file.txt.
  40. 40. Capitolo 4Implementazione software L’applicazione Public Lighting Manager ` stata sta scritta in linguag- egio C++, mediante Qt Creator IDE ver.2.0.1, un potente ambiente disviluppo integrato e multipiattaforma, basato sul framework Qt ver.4.7.0(32 bit), il tutto sotto sistema operativo Linux Ubuntu 10.010. Nei capitoli successivi illustreremo il principio di funzionamento e l’im-plementazione in codice, focalizzando l’attenzione sulle classi principali e leroutine pi` importanti. u4.1 Gestione della mappa Il sottoprogetto QMapControl implementa una widget per la gestione ela visualizzazione delle mappe. E’ basato su un progetto open-source [12] eopportunamente modificato per incontrare le necessit` del nostro progetto. aLa widget offre diverse peculiarit`: a • ` compatibile con diversi map provider ; e • si possono creare oggetti personalizzati da rappresentare nella mappa; • gli oggetti possono essere posizionati a qualsiasi coordinata; • la navigazione della mappa ` personalizzabile. e In questo contesto analizzeremo le caratteristiche principali che hannoriguardato il nostro progetto, mentre per una spiegazione pi` dettagliata si urimanda al sito dello sviluppatore. 38
  41. 41. 4.1 Gestione della mappa 394.1.1 Struttura di QMapControl Come abbiamo visto nel paragrafo precedente la widget che andiamo aconsiderare deve essere in grado di rappresentare allo stesso tempo la mappafornita da un opportuno provider, nel nostro case OpenStreetMap, ed inoltredegli oggetti su di essa, che devono poter essere spostati senza variare la loroposizione in relazione alla mappa. La realizzazione pertanto si avvale di unastruttura a livelli (layer). Classe MapControl: ` la classe principale, la widget vera e propria. Qui evengono istanziati i vari layer ed implementati i controlli necessari, comead esempio il panning delle mappe. Un oggetto MapControl deve essereistanziato passando come parametro un QSize che impone le dimensionidella widget in un certo layout. Queste saranno le dimensioni di riferimentodi tutti i layer istanziati, e quindi della mappa stessa. Classi Geometry: sono gli oggetti che possiamo rappresentare sulla map-pa. La classe Geometry implementa i metodi di base di tutti gli oggetti. Daquesta vengono derivate le classi Point e Light. Classi Layer: sono i livelli che compongono la mappa. Ci sono due tipi dilayer: GeometryLayer e MapLayer, ma entrambi condividono gli stessi metodi. Classe MapAdapter: ` una classe astratta e fornisce l’interfaccia dei meto- edi necessari alla widget, che dovranno essere implementati in modo diversoa seconda dei server WMS che verranno utilizzati. In questo progetto vieneutilizzato il servizio OpenStreetMap, quindi le uniche classi derivate sarannola TileMapAdapter, che gestisce l’elaborazione delle richieste ai tiles server ela classe OSMMapAdapter, specifica per i server OperStreetMap.4.1.2 Le geometrie Le caratteristiche delle geometrie utilizzate nelle mappe, e i metodi daesse supportate, sono specificate nelle Simple Feature Specification dell’OpenGeospatial Consortium [7]. La classe base, Geometry, implementa i metodicomuni a tutte le geometrie. Da questa vendono derivate classi via via pi` ucomplesse, che aggiungono nuovi metodi a quelli della classe base. In questa tesina ci siamo limitati all’utilizzo delle classi Point e Light.Mentre la prima fa parte del progetto originale del QMapControl, la seconda,che rappresenta l’oggetto “lampione” sulla mappa, ` stata implementata ad ehoc per rispondere alle necessit` del presente progetto. a
  42. 42. 4.1 Gestione della mappa 40Classe Geometry Contiene sia metodi esplicitati che metodi virtual, da implementare nellesottoclassi. Elenchiamo i pi` importanti: u • parentGeometry(): in caso di oggetti derivati, restituisce un puntatore all’oggetto “padre” altrimenti un puntatore a se stesso; • setVisible(bool visible): imposta il flag di visibilit`, ; a • boundingBox(): metodo virtuale, restituisce un oggetto di tipo QRect, con le dimensioni del rettangolo che contiene la geometria (Bounding Box ). Di particolare importanza ` il segnale geometryClicked(), che viene emes- eso quando l’utente clicca all’interno della bounding box di un oggetto. Unoggetto ` cliccabile se il layer che lo contiene ` cliccabile. e eClasse Point Un Point ` una Geometry dotato di coordinate geografiche. Questa classe epu` essere utilizzata anche per disegnare una QPixmap, o una QWidgets, in oun determinato punto, basta chiamare il relativo costruttore. Quando si disegna una pixmap, occorre tener presente che si sta aggiun- `gendo il punto in una GeometryLayer. E possibile aggiungere un punto anchead una MapLayer, ma questo dovrebbe essere fatto solo se il punto mantienecostante la sua posizione. Infatti mentre il GeometryLayer viene ridisegna-to ad ogni cambiamento del punto, il MapLayer viene ridisegnato sono incorrispondenza della modifica della finestra principale (viewport). Per una immagine o una widget sono possibili diversi allineamenti rispet-to al punto specificato. La Fig. 4.2 mostra le diverse possibilit`. a La classe Point permette di scalare l’immagine associata in base allozoom. Per fare ci`, occorre impostare con il metodo setBaseLevel() il fat- otore di zoom in corrispondenza del quale l’immagine deve avere le dimen-sioni originali. Per altri fattori di zoom l’immagine verr` cos` ingrandita o a ırimpicciolita automaticamente (Fig. 4.1). I metodi setMinSize() e setMaxSize() permettono di impostare valori dimassima e di minima dimensione per i pixmap o le widget associate al point,per evitare ad esempio che a bassi livelli di zoom le immagini non siano pi` uvisibili.
  43. 43. 4.1 Gestione della mappa 41 Fig. 4.1: Zoom di una geometria Fig. 4.2: Allineamento di una geometria Il metodo Touches() restituisce un valore booleano a seconda che il puntopassato in argomento tocchi o meno il punto della classe. Se al punto ` eassociata una pixmap, il controllo della collisione avviene considerando labounding box della figura.Classe Light La classe Light ` una sottoclasse di Point, che abbiamo introdotto al eprogetto originale QmapControl, per la rappresentazione dei lampioni sullamappa. Ogni Light ` identificato da un numero intero ( id), che corrisponde eall’indice della chiave primaria del lampione nel database. In questo modosi assicura la corrispondenza degli oggetti grafici sulla mappa con i recorddel database. La classe implementa quattro metodi che sono anche slot: • getId(), restituitsce l’identificativo del lampione. • setOnState(bool), imposta lo stato on/off per il lampione. In base allo stato, la pixmap associata viene cambiata con l’immagine di un lampione acceso o spento.
  44. 44. 4.1 Gestione della mappa 42 • SetWarningState(bool) imposta lo stato di warning per il lampione. In caso di warning positivo, il lampione viene rappresentato da una pixmap con un punto interrogativo, a segnalare lo stato anomalo. Questo stato ha priorit` sullo stato on/off. a • setToMove(bool), viene chiamato quando l’utente vuole modificare la posizione del lapione sulla mappa.4.1.3 I livelli La visualizzazione delle mappe nella widget QMapControl ` organizzata ein livelli (detti anche layers). Ci sono due tipi di layer, i MapLayer e iGeometryLayer. I primi possono visualizzare contenuti statici, come mappe,ma anche geometrie, i secondi possono rappresentare solo le geometrie. Ladifferenza sta nella modalit` con cui questi layer vengono aggiornati: mentre agli oggetti appartenenti ad una GeometryLayer vengono ridisegnati ogni voltache cambiano posizione, gli oggetti appartenenti ad un MapLayer vengonoridisegnati solo in corrispondenza dell’aggiornamento dell’intera schermata(offscreen). Per il resto le due classi hanno gli tessi metodi, ereditati dalla classemadre Layer. I metodi pubblici addGeometry() e removeGeometry() sonoutilizzati nella gestione delle geometrie del layer, mentre lo slot setVisible()ne impone la visibilit`. a Il segnale geometrySelect(int ID) viene emesso quando viene selezionato,mediante click, l’oggetto con indice ID appartenente al layer. Ogni livello ` contraddistinto da un nome e tutti sono gestiti dalla classe eLayerManager. Questa classe conserva tutti i parametri necessari alla rapp-resentazione delle mappe. Le coordinate del centro della finestra, le misuredell’area visibile all’utente e il livello di zoom. Le misure dell’area visibile(offscreenViewport) possono essere espresse in coordinate cartesiane o incoordinate di proiezione. Le coordinate di proiezione sono le coordinate inpixel relative allo specifico zoom. La widget principale fa riferimento a ques-ta classe per variare il modo di rappresentazione della mappa, chiamandonei relativi metodi. A sua volta LayerManager passa questi comandi a tutti ilayer presenti. Quando si istanzia un nuovo Layer, occorre passare al costruttore il pun-tatore ad un MapAdapter, che regola la conformit` del layer con il servizio a
  45. 45. 4.1 Gestione della mappa 43di mappe online. La classe MapAdapter verr` illustrata nel prossimo para- agrafo.4.1.4 Richiesta dei Tiles La classe MapAdapter permette alla widget di generare nel formato cor-retto, la richiesta dei dati cartografici per diversi servers. Da MapAdapter vengono pertanto derivate due sottoclassi: • TileMapAdapter, che dialoga con servers basati su immagini tiles, come OpenStreetMap o Google Maps; • WMSAdapter, che dialoga con servers di tipo WMS. La classe TileMapAdapter implementa la conversione di coordinate, sec-ondo la procedura vista nel Par.2.3.3. Queste operazioni sono necessarie performulare correttamente la richiesta di nuovi tiles, per una data posizione eper un dato fattore di zoom. L’interrogazione del server avviene medianteprotocollo HTTP, componendo una stringa del tipo: http://tile.openstreetmap.org/%1/%2/%3.png I caratteri %1, %2, e %3 sono dei “segnaposti” che grazie alla funzionequery(int x,int y,int z) vengono sostituiti con opportuni valori: • %1 rappresenta lo zoom, indicato come numero intero (da 0 a 18 per server OSM); • %2 coordinata x del tile (da 0 a 2z − 1, con z=fattore zoom); • %3 coordinata y del tile (da 0 a 2z − 1, con z=fattore zoom). Le coordinate dei tiles, per fattori di zoom da 0 a 3, sono rappresentatein Fig. 4.3. L’indirizzo dell’host e il formato della richiesta per un certo server,vengono fornite dalle sottoclassi di TileMapAdapter. Per il server Open-StreetMap viene utilizzata la classe OSMMapAdapter.
  46. 46. 4.2 Struttura del progetto 44 Fig. 4.3: Ccoordinate dei tiles, per fattori di zoom 1,2 e 34.2 Struttura del progetto In questo paragrafo andiamo ad elencare i file che compongono il progettoP.L.M. • pladministrator.cpp: ` la classe principale, l’applicazione vera e pro- e pria. Qui sono implementate le funzioni principali dell’interfaccia che illustreremo nei prossimi paragrafi; • combodelegate.cpp: ` qui implementata l’omonima classe, utilizzata e come delegate del mapper in LampPage (vedi Par.??), per l’indiciz- zazione corretta delle voci; • conndialog.cpp: finestra di dialogo per aprire una nuova connessione ad un database. • dbmanager.cpp: finestra di dialogo che riunisce una serie di widget ( QStackWidget), implementate nel file pages.cpp, per la gestione del database dei lampioni. • pages.cpp: l’insieme delle widget utili all’editing del database. Qui sono implementate tutte le operazioni di inserimento, modifica e can- cellazione dei record. Inoltre sono specificate le funzioni utili a man- tenere l’integrit` del database. a • dialogs.cpp: qui sono implementate le finestre di dialogo per la modi- fica/visualizzazione delle lamps. • main.cpp: classe per l’avvio dell’applicazione.
  47. 47. 4.3 Database 45 • proxymodel.cpp: questa classe incapsula un modello predefinito, ma stabilisce delle regole per la visualizzazione dei record.4.3 Database La struttura del database ` rappresentata in Fig. 4.4. Secondo lo schema eclassico dei database relazionali, alcuni campi della tabella principale Lamps,sono costituiti dalle chiavi dei valori di tabelle “attributi”. Questa caratter-istica permette di aggiornare ed integrare gli attributi secondo le necessit` adell’utente finale, in modo illimitato e flessibile. Le istruzioni SQL che realizzano questa struttura sono le seguenti:CREATE TABLE IF NOT EXISTS streets ( id INT NOT NULL AUTO_INCREMENT , streetName VARCHAR(40) UNIQUE, PRIMARY KEY (id))ENGINE=InnoDB);CREATE TABLE IF NOT EXISTS groups ( id INT NOT NULL AUTO_INCREMENT , groupName VARCHAR(40) UNIQUE, PRIMARY KEY (id))ENGINE=InnoDB);CREATE TABLE IF NOT EXISTS bodytype ( id INT NOT NULL AUTO_INCREMENT , bodyName VARCHAR(40) UNIQUE, bodyImage BLOB, PRIMARY KEY (id))ENGINE=InnoDB);CREATE TABLE IF NOT EXISTS bulbtype ( id INT NOT NULL AUTO_INCREMENT , bulbName VARCHAR(40) UNIQUE, PRIMARY KEY (id))ENGINE=InnoDB);CREATE TABLE IF NOT EXISTS operators ( id INT NOT NULL AUTO_INCREMENT , operatorName VARCHAR(40) UNIQUE, PRIMARY KEY (id))ENGINE=InnoDB);
  48. 48. 4.3 Database 46CREATE TABLE IF NOT EXISTS lamps ( id INT NOT NULL AUTO_INCREMENT , latitude DOUBLE, longitude DOUBLE, streetId INT , groupId INT , bodyId INT , bodyDate DATE NOT NULL, bulbId INT , bulbDate DATE NOT NULL, operatorId INT , address VARCHAR(40), PRIMARY KEY (id), FOREIGN KEY (streetId) REFERENCES streets(id), FOREIGN KEY (groupId) REFERENCES groups(id), FOREIGN KEY (bodyId) REFERENCES bodytype(id), FOREIGN KEY (bulbId) REFERENCES bulbtype(id), FOREIGN KEY (operatorId) REFERENCES operators(id) )ENGINE=InnoDB); Queste istruzioni sono invocate nella routine dbConnect(), che vedremonel dettaglio pi` avanti. u4.3.1 Connessione Come abbiamo visto nel capitolo precedente, l’utente pu` scegliere se ospecificare una nuova connessione o aprire un file contentente i parametri diuna connessione salvata. Nal primo caso la funzione newConenction istanzia un nuovo oggetto dellaclasse ConnDialog, presente nell’omonimo file. Si tratta di una finestra didialogo dove inserire i quattro parametri necessari: • Database Name; • Password; • User Name;
  49. 49. 4.3 Database 47 Streets strade Lamps 1 lampioni id int id int streetName varchar longitude double latitude double n Groups streetId int gruppi foreign key 1 n id int groupId int groupName varchar foreign key n bodyId int Bodies foreign key strutture 1 bodyDate date n id int bulbId int bodyName varchar foreign key bodyImage BLOB bulbDate date n operatorId int Bulbs lampade foreign key 1 id int address varchar bulbName varchar Operators operatori 1 id int operatorName varchar Fig. 4.4: Struttura del database • Host Address. Se i dati inseriti sono validi viene chiamata la funzione connectPLA(). connDialog implementa anche la funzione Save, che permette di salvarei parametri inseriti in un file XML. Le librerie Qt offrono una opportunaAPI per la lettura/scrittura di file XML. In questo caso ` utilizzata una einterfaccia DOM (Document Object Model), per creare una struttura adalbero con i tag specificati dall’utente. L’“albero“ cos` creato viene salvato ısu file mediante uno stream di testo ( QTextStream). La funzione openConnectionFile(), viene invocata nel caso in cui l’utentescelga di aprire un file di connessione salvato. L’interfaccia DOM converteil documento XML nella struttura ad albero corrispondente. La funzionericonosce la radice nel tag <PLAdministrator>, ed individia i nodi “figlio”che contengono i campi necessari alla connessione, quindi viene chiamata lafunzione connectPLA.
  50. 50. 4.3 Database 48Funzione dbConnect Questa funzione ` quella che avvia la connessione vera e propria al edatabase. Il modulo QtSql fornisce una efficiente interfaccia per l’accessoa diversi tipi di database SQL. Un nuovo oggetto QSqlDatabase viene creato grazie al metodo addDatabase(),specificando quale driver utilizzare per la connessione: nel nostro caso QMYSQL. Impostati le credenziali d’accesso, il metodo open() stabilisce, di fatto,la connessione. In questa funzione vengono create le tabelle del database necessarie,qualora non fossero gi` presenti. Il metodo exec() dell’oggetto QSqlQuery aesegue le opportune query viste nel paragrafo precedente. In caso di successo la funzione dbConnect() restituisce un valore booleanotrueFunzione connectPLA() La routine ha il compito di avviare tutte le procedure per la visualiz-zazione dei dati, in seguito ad una avvenuta connessione. Le chiamate a initializeModel() e initializeView(), istanziano l’architetturamodel/view (vedi Par 4.4). L’interfaccia viene divisa, mediante nuovo oggetto QSplitter, cos` da per- ımettere la visualizzazione tabellare delle lamps (funzione createListGroup-Box()). Vengono qui create anche le opportune connessioni signal/slot, per ilcorretto interfacciamento della tabella con il resto dell’applicazione (funzionecreateConnection()). Ottenuti i dati dal database non rimane che graficare sulla mappa lelamps, in base alla loro geolocalizzazione. Questo compito ` realizzato dalla efunzione drawLamps(). La lettura dello stato attuale dei lampioni, con la conseguente modificadell’icona sulla mappa, viene effettuata da due funzioni: readStatusLamps()che legge da un file txt esterno lo stato on/off dei lampioni e da read-WarningLamps() che legge da un file txt esterno quali lampioni presentanoanomalie o malfunzionamenti.
  51. 51. 4.3 Database 49Funzione disconnectPLA() Questa funzione pu` essere invocata manualmente dall’utente mediante oil comando Close Connection, oppure automaticamente quando si avvia unanuova connessione. L’effetto della procedura infatti ` quello di salvare lo sta- eto delle lamps(funzione saveStatusLamps()), cancellare le variabili di statodi queste ( warningLamps, turnedOnLamps), resettare sia model che prox-yModel e chiudere la connessione ad database (metodi removeDatabase() eclose()).4.3.2 Database Editor La classe DBManager, implementa l’interfaccia di modifica del database.Si tratta di una finestra di dialogo (sottoclasse di QDialog) strutturata comeuna QStackedWidget, ossia un insieme widget o pages, che vengono visualiz-zate all’interno della stessa finestra. Si pu` passare da una widget all’altra omediante un sistema di icone. Ogni page rappresenta una tabella del database. Il costruttore DBMan-ager() istanzia quindi le sei widget e ne organizza la paginazione. Esso riceve come argomento un puntatore al model principale, che a suavolta verr` passato alle pages. Secondo il concetto dell’architettura MVC ainfatti, le modfiche al database passano per la modifica del model associato. Gli unici metodi della classe DBManager sono createIcons() e changePage(),che definiscono la navigazione tra widget attraverso le icone associate. Nel file pages.cpp sono implementate le sei widget dell’editor: • LampPage: widget per i lampioni; • GroupPage: widget per i gruppi • StreetPage: widget per l’elenco vie; • BodyPage: widget per l’elenco supporti; • BulbPage: widget per l’elenco lampade; • OperatorPage: widget per l’elenco degli installatori. La classe LampPage permette l’overload di tre diversi costruttori chedifferiscono per il tipo ed il numero di argomenti:
  52. 52. 4.3 Database 50 • LampPage(QSqlRelationalTableModel *tableModel,QWidget *parent): viene utilizzato nel Database Editor e riceve come argomento solo il model principale; • LampPage(QPointF* point, QSqlRelationalTableModel *tableModel,QWidget *parent): rispetto al precedente ha in pi` l’argomento di tipo QPointF. u Questo costruttore viene invocato nel caso in cui l’untente decida di inserire una nuova lamp in un determinato punto della mappa (co- mando add Lamp). In questo caso l’editor della lamp si apre con i campi lonEditor e latEditor gi` completati con le coordinate del punto a nell’argomento. • LampPage(QModelIndexList indexList, QSqlRelationalTableModel *table- Model, bool ReadOnly,QWidget *parent): riceve come argomento la lista delle righe selezionate ( QModelIndexList) nel view. Questa variante viene utilizzata quando si vuole visualizzare o modificare una serie di lampioni che sono stati selezionati nel view. Il flag ReadOnly indica se i dati delle lamps devono essere solo visualizzati (comando Info) o se devono essere editati. Il terzo costruttore ` implementato con l’ausilio di un QDataWidgetMap- eper. Questa classe permette di “mappare” i dati di un model nei campi diuna widget. Questa funzione permette di scorrere facilmente tutti i recorddel database dalla stessa widget, attraverso due pulsanti avanti e indietro e,all’occorrenza, modificarli al volo. L’impego di un data mapper ha richiesto per` l’implementazione di un odelegate personalizzato, il comboDelegate, che vedremo pi` avanti.adatto che uvedremo pi` avanti. u I metodi della classe LampPage sono: • Next()/Previous(): sono due funzioni slot collegati ai pulsanti per scor- rere tra i record in fase di modifica/visualizzazione delle lamps; • addNewLamp(): il metodo, invocato dalloslot submit() aggiunge un nuovo lampione nel database; • submitEdit(): aggiorna i dati in seguito alla modifica dell’utente; • uploadImage(): serve a leggere l’immagine in formato binario dal database;
  53. 53. 4.3 Database 51 • createComboBoxModel(): questo metodo associa i menu a “discesa” (combo box) con il contenuto delle tabelle relazionate. L’associazione per` non ` diretta ma passa per la creazione di un model “intermedio” o e ( QSortFilterProxyModel) sul quale possiamo agire in modo da ordinare alfabeticamente le voci, per una lettura pi` semplice. u La struttura delle widget, per l’editing delle altre tabelle, ` pressoch` la e estessa. Si possono quindi definire tre metodi comuni, implementati all’iniziodel file: • createTableView(): riceve come argomento il model di una tabella re- lazionata, ne istanzia la visualizzazione come elenco e restituisce il puntatore al view creato; • addNewItem(): permette di inserire un nuovo record nella tabella il cui model viene passato come argomento; • deleteItem(): a differenza della funzione di inserimento, riceve come argomento l’intero model. Questo perch` il metodo verifica prima e che la tabella principale non contenga delle lamps con l’attributo da eliminare. Le pages sono costituite da una lista (view ), attraverso la quale scegliereil record da modificare o eliminare un record, ed uno o pi` campi dove poter uinserire i dati dei nuovi record. I pulsanti Add, Save e Delete sono collegati,mediante il sistema signal/slot, rispettivamente ai seguenti metodi: • submit(): insieme al metodo comune addNewItem() permette di ag- giungere nuovi record alla tabella di riferimento; • save(): salva nel model (e quindi nel database Sql) le modifiche appor- tate ad un record; • remove(): elimina dal model (e quindi dal database Sql) il record selezionato. Il database Sql ` impostato per avere valori unici. Questo vuol dire che enon ` possibile, ad esempio, inserire due vie con lo stesso nome. In questa eeventualit`, il metodo che invia le modifiche del model al database, ossia asubmitAll(), restituirebbe valore false, producendo un messaggio di errore.

×