http://edenti.deis.unibo.it/Ling/2008-2009/BestProjects/Zamagni/

1. Camera Parser
autore: Carlo Zamagni
Progetto per l’esame di linguaggi e modelli computazionali LS
Prof. Enrico Denti anno accademico 2006/2007

2. Problematica e scopo del progetto
Le telecamere IP sono controllate mediante parametri passati via HTTP a degli script CGI
esempio:
http://192.168.0.240/control/control?
set&section=general&coverimage_area=0,540,380,200,200,2
%0A1,320,100,100,150,2
tratto dalle HTTP-API di Mobotix
• leggibilità nulla
• soggetti a variazioni anche all’interno di uno stesso modello da un firmware all’altro
• difficilissimo gestire ambienti con dispositivi eterogenei

3. Problematica e scopo del progetto
Sarebbe comodo disporre di un semplice linguaggio con il quale specificare in modo “umano” dei comandi e
gestirne l’invio a delle entità:
...qualcosa di simile a questo:
nuova telecameraX 192.168.0.240 tipo: mobotix
copertura 540 380 200 200 opacità 2 su telecameraX
area sensibile 0 0 10 100 soglia 30 su telecameraX
nuova telecameraY 192.168.0.2 tipo: axis
risoluzione 640*480 su telecameraY

4. Dominio applicativo
Le informazioni che il parser dovrà trattare rappresentano dei comandi e pertanto si può individuare una “forma”
comune che permetta di specificare:
• il tipo di comando: verranno inseriti i comandi basilari per l’impostazione di una
telecamera quali le regolazioni di luminosità, contrasto, risoluzione; per il rilevamento
del movimento e la rotazione del dispositivo.
• il destinatario dell’informazione: un dispositivo già specificato nell’ambiente che si
andrà a creare. Sarebbe opportuno che anche la definizione di nuove entità potesse
essere espressa dal linguaggio.
• l’argomento del comando selezionato dall’utente: tipicamente un intero oppure una
serie di valori interi.
• eventuali parametri aggiuntivi.

5. Gli strumenti
JavaCC

6. La grammatica (notazione jj)
Scopo della grammatica: la definizione di un generico comando
Altri token
< CAM: "camera:" >
void Scope():{}{Cmd() Cam() <EOF>} | < DOT: "." >
| < MAKE: "make:" >
| < NEW: "new" >
| < MOTION: "motion" >
| < BACKLIGHT: "backlight" >
| < SHARPNESS: "sharpness" >
| < RESOLUTION: "resolution" >
| < ROTATE: "rotate" >
| < LEFT: "left" >
Valori interi ed identificatori: | < RIGHT: "right" >
| < PORT: "port" >
< INT: ["0"-"9"] (["0"-"9"])* > | < ADD: "add" >
| < REMOVE: "remove" >
< IDENT: (<CHAR> | ["0"-"9"] | <SYMBOL>)+>
| <#SYMBOL: "_" | "$" | "%" | "-" | "^" | "#" | "&" | "," | ";" | "°">
| <#CHAR: ["a"-"z"] | ["A"-"Z"] | "à" | "è" | "é" | "ì" | "ò" | "ù">

7. La grammatica (notazione jj)
Problema: bisogna rappresentare degli indirizzi ip, ovvero sequenze di 4 interi compresi fra 0 e 255 separati da un
punto.
Non crea alcun problema al
riconoscitore, ma permette la
void Ip():{}{ <INT> <DOT> <INT> <DOT> <INT> <DOT> <INT> (<PORT> <INT>)?} definizione di un insieme di indirizzi
più ampio di quello accettabile
Così non siamo però in grado di
Si potrebbe definire un token “IPBLOCK” che validi un intero compreso fra 0 e 255 discriminare fra interi e blocchi ip, il
parser fa match con il primo
elemento che incontra, inoltre vi è
[0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5]
una sovrapposizione fra le definizioni
quindi: void Ip():{}{ <IPBLOCK> <DOT> <IPBLOCK> <DOT> <IPBLOCK> <DOT> <IPBLOCK> (<PORT> <INT>)?}

8. La grammatica (notazione jj)
Dal momento che si è interessati sia agli interi che al loro sottoinsieme “ipblock”, è possibile introdurre
un’espressione regolare che permetta il match di un intero indirizzo ip
< IP: "ip:" (["1"-"9"]["0"-"9"] | ["0"-"9"] | "1"["0"-"9"]["0"-"9"] | "2"["0"-"4"]["0"-"9"] | "25"["0"-"5"])"."
(["1"-"9"]["0"-"9"] | ["0"-"9"] | "1"["0"-"9"]["0"-"9"] | "2"["0"-"4"]["0"-"9"] | "25"["0"-"5"])"."
(["1"-"9"]["0"-"9"] | ["0"-"9"] | "1"["0"-"9"]["0"-"9"] | "2"["0"-"4"]["0"-"9"] | "25"["0"-"5"])"."
(["1"-"9"]["0"-"9"] | ["0"-"9"] | "1"["0"-"9"]["0"-"9"] | "2"["0"-"4"]["0"-"9"] | "25"["0"-"5"]) >
e a questo punto la relativa produzione diventa: Ora il parser riconosce
correttamente gli indirizzi ip e
abbiamo mantenuto la capacità
void Ip():{}{ <IP> (<PORT> <INT>)?} di rappresentare gli interi

9. La grammatica (produzioni)
void Scope():{}{Cmd() Cam() <EOF>} La sintassi di un generico comando ha la
forma: <azione> <argomento> <dispositivo>
void Cmd():{}{New()|Motion()|Backlight()|Sharpness()|Resolution()|Rotate()}
void Cam():{}{<CAM> <IDENT>}
void Make():{}{<MAKE> <IDENT>}
void New():{}{<NEW> Ip() Make()}
void Motion():{}{<MOTION> Area() (<ADD>|<REMOVE>)}
void Backlight():{}{<BACKLIGHT> <INT>} Sintassi dei singoli comandi
void Sharpness():{}{<SHARPNESS> <INT>}
void Resolution():{}{<RESOLUTION> Res()}
void Rotate():{}{<ROTATE> <INT> (<LEFT>|<RIGHT>)}
void Area():{}{<INT> <DOT> <INT> <DOT> <INT> <DOT> <INT> <DOT> <INT>} //punto iniziale, punto finale, sensibilità
void Res():{}{<INT> "*" <INT>}
La correttezza semantica di
void Ip():{}{ <IP> (<PORT> <INT>)?} aree, indirizzi e risoluzioni
viene valutata a posteriori

10. Considerazioni sulla grammatica ottenuta
• La grammatica realizzata è di tipo “context-free” (tipo 2 secondo la classificazione di Chomsky), ma priva di self -
embedding, pertanto il linguaggio ottenuto è di tipo 3.
• Non è utile definire ε-rules nello scopo, un comando vuoto equivale a nessun comando.
• La grammatica appartiene alla classe LL(1), pertanto non è stato necessario inserire nel file di specifica alcuna
istruzione di lookahead.

11. Architettura del sistema
Modello
Consiste di una aggregazione di istanze di oggetti che implementano la classe astratta “Camera”. Questa si occupa
di definire il comportamento di base di un dispositivo video, lasciando alle sue implementazioni il compito di
specificare le reazioni ai vari comandi specifici.
Si è voluto uniformare il comportamento dei vari modelli di telecamere.

12. Architettura del sistema
Valutazione semantica dei comandi ricevuti in input e loro attuazione
Il visitor estende il “DepthFirstVisitor” generato automaticamente ed ha il compito di costruire una
rappresentazione del comando mano a mano che procede nella valutazione della frase.
Pattern Command
Permette di incapsulare una richiesta, costituita dal metodo execute (logica) e dai suoi parametri (state),
delegandone l’esecuzione ad un’entità ricevente (nel nostro caso il controller).
✓ si evita di fare agire il visitor direttamente sul modello
✓ si semplifica la gestione dei comandi
✓ facilita la creazione di log e rapporti
✓ è facile aggiungere nuovi comandi
✓ possibilità di rollback

13. Architettura del sistema
Gestione dell’interfaccia grafica ed aggiornamento delle viste
Vengono utilizzati i pattern “model-view-control” ed “observer”: tutti gli elementi grafici implementano le interfacce
InputDevice e/o OutputDevice. Il problema di notificare ad alcuni dispositivi le modifiche che vengono
effettuate sul dominio viene risolto facendo in modo che tali elementi si “registrino” in una lista di soggetti da
notificare in caso di variazioni presso il controller.

14. Visione d’insieme

15. Esempi d’uso - creazione entità
Definizione di due dispositivi
new make:Mobotix ip:62.123.180.9 camera: prova1
new make:Mobotix ip:151.38.133.10 port 2001 camera: prova2
Finestra principale dell’applicazione
Visualizzazione in dettaglio di un dispositivo (click sull’anteprima)

16. Esempi d’uso - esecuzione comandi
Variazione della luminosità e del contrasto
backlight 30 camera: prova1
sharpness 25 camera: prova2
http://62.123.180.9/control/control?set&section=imagecontrol&backlight=30
http://151.38.133.10:2001/control/control?set&section=imagecontrol&sharpness=25

17. Esempi d’uso - procedure da file
Il sistema utilizza il parser inviandogli le frasi digitate dall’utente, ma è possibile scrivere delle procedure di comandi
su file, valutarli e applicarli in sequenza.
new make:mobotix ip:192.168.1.197 camera:casa
motion 10.10.500.500.6 add camera:casa
backlight 9 camera:casa
sharpness 2 camera:casa
resolution 640*480 camera:casa
casa ready
Address: 192.168.1.197
new motion detection area: from 10,10 to 500,500 trigger: 6
http://192.168.1.197/control/control?set&section=event&motiondef=0,10,10,500,500,a=6
set backlight to 9
http://192.168.1.197/control/control?set&section=imagecontrol&backlight=9
set sharpness to 2
http://192.168.1.197/control/control?set&section=imagecontrol&sharpen=2
set resolution to: 640 X 480
http://192.168.1.197/control/control?set&section=imagecontrol&size=640x480

18. Sviluppi futuri
• Realizzazione di una versione da linea di comando ed eventualmente di una libreria Java
• Implementazione di ulteriori modelli
• Ricerca di una soluzione alternativa per implementare le specifiche dei singoli dispositivi