Corso di Laurea Specialistica in Ingegneria Informatica

Previsione dei Consumi Elettrici

=Progetto per l’esame di Linguaggi e Modelli Computazionali LS realizzato da Marco Ferrari

Prof. Enrico Denti

Anno Accademico 2007-2008

Scopo del progetto

• Definire un linguaggio che possa aiutare l’utente a scegliere la tariffa dell’energia elettrica più consona alle sue esigenze.

• L’utente potrà effettuare delle previsioni di spesa relativamente agli oggetti che deciderà di considerare.

Il problema

• Oggigiorno vengono offerte tipicamente due tipologie di contratto: Tariffa costante 24h/24h Tariffa bioraria

• Il cliente difficilmente riesce a farsi un’idea sulla reale convenienza che può avere scegliere una piuttosto che un’altra.

Il problema• Per effettuare una previsione serve considerare:

La tariffa Quali oggetti elettrici si utilizzano Per quanto tempo si utilizzano Soprattutto quanta corrente elettrica consumano

• Quest’ultimo punto è il più complicato per l’utente da sapere. Le soluzioni sono: Leggere sul manuale delle istruzioni il valore esatto Utilizzare uno strumento simile a questo per leggere il consumo

Lasciare un margine di incertezza sul dato

Grammatica• Utilizzo la notazione dello strumento jjdoc• G = <VT, VN, P, S>• P è l’insieme di tutte le produzioni della

grammatica

• Il fine del linguaggio è quello di effettuare una previsione sui costi, quindi lo scopo della grammatica è:Scopo::= “Previsione“ Previsione <EOF>

GrammaticaPrevisione ::= "Tariffa/e:" "{" ( Tariffa )+ "}" "Consumi:"

"{" ( Consumi )* "}" • Come si può notare, ho deciso per coerenza di mettere ( Tariffa )+. Quindi

prerogativa del linguaggio è esprimere almeno una tariffa su cui fare la previsione. D’altro canto, se non ci fosse almeno una tariffa, tutto ciò non avrebbe nessun significato.

• Mentre per quanto riguarda la parte (Consumi )*, si intende esprimere un insieme di oggetti elettrici, sui quali vorremo stimare i costi in un dato lasso di tempo. Come si può notare, il linguaggio accetta che non venga passato nessun oggetto su cui fare una previsione. L’operazione non è particolarmente significativa, ma non si può dire che sia concettualmente errata.

• Sia per le tariffe che per i consumi sono state inserite delle parentesi graffe all’inizio ed alla fine del blocco. NON c’è Self-Embedding perché le parentesi si ripetono una sola volta.

GrammaticaTariffa ::= "Fascia oraria" <NUMZERO> ":" "dalle"

<ORA> "alle" <ORA> "costo al kWh:" <QUATTROCIFREDEC> "giorni:" "da" <GIORNO> "a" <GIORNO>

• La prima parte dei due blocchi principali è rappresentata dalla dichiarazione della/e tariffe.

I parametri che la caratterizzano sono: a) fascia oraria in cui vale, b) il prezzo della corrente elettrica espresso in kWh, c) la fascia di giorni in cui vale.

• Normalmente le tariffe offerte ad oggi non sono più di due (biorarie), però in questo caso si offre la possibilità di gestirne di più.

Questa scelta complicherà leggermente le cose, vedremo perché…

GrammaticaConsumi ::= "Oggetto:“ <STRINGA_ALFA_NUMERICA>

"potenza:" Potenza "kW" "orario" "dalle" <ORA> "alle" <ORA>

• La seconda parte dei due blocchi principali è rappresentata dall’inserimento dei vari oggetti di cui si vogliono effettuare delle previsioni di consumo.

I parametri in questo caso sono: a) un nome dell’oggetto, b) la potenza espressa in kW, che andremo a vedere meglio come esprimere, c) la fascia oraria in cui viene utilizzato tale oggetto.

GrammaticaPotenza ::= <NUMZERO> | "da" <NUMZERO> "a"

<NUMZERO>• La potenza merita una riflessione, in merito anche a quanto anticipato

nell’introduzione; fondamentalmente ci si può trovare davanti a due situazioni :a) Si conosce esattamente il consumo al kW dell’oggettob) Si può avere un’idea che può andare da un minimo di tot kW ad un massimo di tot kW.Ecco spiegata l’alternativa.Nel secondo caso, per comodità, è stato preso un valore medio tra il consumo minimo ed il consumo massimo.

Grammatica – Token<STRINGA_ALFA_NUMERICA>::= <LETTERA> (<LETTERA> |

<NUMERO>)* <QUATTROCIFREDEC>::= "0."<NUMERO> <NUMERO> <NUMERO>

<NUMERO> <NUMZERO>::= <NUMEROSENZAZERO> (<NUMERO>)* ><ORA>::= ( "0" <NUMERO> | "1" <NUMERO> | "20" | "21" | "22"

| "23" ) ":"["0"-"5"] <NUMERO> <GIORNO>::= ("-LUN-" | "-MAR-" | "-MER-" | "-GIO-" | "-VEN-" |

"-SAB-" | "-DOM-" )

<#LETTERA>::=["a"-"z"] | ["A"-"Z"] | "_" <#NUMEROSENZAZERO>::=["1" - "9"]<#NUMERO>::=["0" - "9"]

• Le espansioni che iniziano con ‘#’ sono private, in quanto sono utilizzabili solamente internamente ai soli token.

Grammatica – Token

• E’ stato definito un apposito token <QUATTROCIFREDEC> perché, dalle ricerche effettuate, i costi delle tariffe al kWh sono tutti espressi con questa notazione. Quindi mi sono adeguato a quello che è lo standard.

• Il token <ORA> è stato vincolato a monte, in modo da alleggerire i controlli sulla correttezza dei parametri che dovrà effettuare il programma in un secondo momento.

• Il token <GIORNO>, mostra delle sigle che identificano i vari giorni della settimana. Questa scelta, è stata fatta perché ho deciso di prendere come periodo di riferimento per la validità della tariffa, un’intera settimana.

Grammatica – Token

• La grammatica ammette la stringa vuota nella produzione:Previsione ::= "Tariffa/e:" "{" ( Tariffa )+ "}" "Consumi:" "{"

(Consumi )* "}"

Infatti l’*, indica che può produrre da 0 a N Consumi.L’ rule può essere eliminata nel seguente modo: Previsione ::= "Tariffa/e:" "{" ( Tariffa )+ "}" "Consumi:" "{" Raccoglimento

Raccoglimento::=(Consumi )+"}" | "}"

Grammatica - osservazioni

Grammatica - osservazioni

• Secondo la classificazione di Chomsky, il linguaggio è di tipo 2 in quanto le produzioni non sono regolari, ma:Non presenta Self-Embedding quindi il linguaggio è

regolare La grammatica non è stata riscritta per leggibilità e

comodità

• Fatte queste considerazioni, si può dire che la grammatica è LL(1)

Strumenti utilizzati

• Java 1.6.0_03• JavaCC 4.0• Java Tree Builder 1.3.2• NetBeans 6.0

Architettura• packages creati e “imposti” dagli strumenti automatici

utilizzati

• packages creati seguendo il modello architetturale dato dagli strumenti automatici

Architettura

• syntaxtree contiene quanto necessario all’albero sintattico una serie di classi relative ai nodi una classe per ogni metasimbolo della grammatica

• parser contiene quanto serve per la gestione del parser classi per il parser e per i token per la gestione delle eccezioni e degli errori lessicali

• visitor contiene vari visitor di default generati dallo strumento automatico il visitor PrevisioneConsumiVisitor è stato ricavato dalla classe java

DepthFirstVisitor, fornita dagli strumenti di generazione automatica.Si occupa di inserire i dati inseriti dall’utente nelle apposite strutture dati create.

Architettura

• Il package main contiene solo la classe Main, utilizzata per lanciare l’applicazione.• Utility contiene le strutture necessarie a memorizzare una lista di tariffe e di previsioni.

Con tariffe e previsioni, opportunamente definite attraverso due classi che contengono tutti i parametri che le compongono.

• Grafica contiene la classe Form, ovvero il motore del programma. Form si occupa ovviamente della gestione della parte grafica e dell’ I/O, di valutare i dati passati in input e di avviare, nel caso tutti i dati siano corretti, la previsione.

Il problema di più tariffe ...• Come detto in precedenza, ho deciso di prendere come

periodo di validità di una tariffa, la settimana.• Questo vuol dire che, per ogni minuto della settimana, deve

essere definita una corrispettiva tariffa.• Ad occuparsi di ciò, è il metodo checkCoerenzaTariffa(), il quale

mi dovrà dire: a) se ci siano sovrapposizioni di tariffe nella settimanab) se tutti i minuti della settimana sono stati “etichettati” con il loro rispettivo valore della tariffa.

Limiti dell’applicazione e sviluppi futuri

• Sicuramente il limite più grosso che si può notare attualmente è che se l’utente non conosce precisamente il consumo di un oggetto, dando un range di valori ottiene solo un dato medio. Sarebbe meglio magari fare un’analisi differenziata caso migliore/caso peggiore.

• Sarebbe interessante poter visualizzare tramite grafici i risultati ottenuti.

• Si potrebbe espandere ulteriormente la flessibilità delle tariffe, introducendo la validità per un certo periodo dell’anno.

• Al momento il programma considera che gli oggetti vengano utilizzati tutti i giorni. Per avere dei risultati più accurati, si potrebbe introdurre una fascia relativa al periodo in cui tale oggetto viene utilizzato (es. settimana/mese/anno).

Un’ ultima considerazione...

• Questo programma è stato pensato per venire incontro ad un cliente che è interessato a valutare quale piano tariffario gli conviene sottoscrivere.

• In realtà, potrebbe essere utilizzato anche da parte dei fornitori di energia elettrica per valutare nuove possibili offerte da proporre sul mercato.