La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

Corso di Laurea Specialistica in Ingegneria Informatica Previsione dei Consumi Elettrici = Progetto per lesame di Linguaggi e Modelli Computazionali LS.

Presentazioni simili


Presentazione sul tema: "Corso di Laurea Specialistica in Ingegneria Informatica Previsione dei Consumi Elettrici = Progetto per lesame di Linguaggi e Modelli Computazionali LS."— Transcript della presentazione:

1 Corso di Laurea Specialistica in Ingegneria Informatica Previsione dei Consumi Elettrici = Progetto per lesame di Linguaggi e Modelli Computazionali LS realizzato da Marco Ferrari Prof. Enrico Denti Anno Accademico 2007-2008

2 Scopo del progetto Definire un linguaggio che possa aiutare lutente a scegliere la tariffa dellenergia elettrica più consona alle sue esigenze. Lutente potrà effettuare delle previsioni di spesa relativamente agli oggetti che deciderà di considerare.

3 Il problema Oggigiorno vengono offerte tipicamente due tipologie di contratto: Tariffa costante 24h/24h Tariffa bioraria Il cliente difficilmente riesce a farsi unidea sulla reale convenienza che può avere scegliere una piuttosto che unaltra.

4 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 Questultimo punto è il più complicato per lutente 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

5 Grammatica Utilizzo la notazione dello strumento jjdoc G = P è linsieme 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

6 Grammatica Previsione ::= "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. Daltro 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. Loperazione 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 allinizio ed alla fine del blocco. NON cè Self-Embedding perché le parentesi si ripetono una sola volta.

7 Grammatica Tariffa ::= "Fascia oraria" ":" "dalle" "alle" "costo al kWh:" "giorni:" "da" "a" 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é…

8 Grammatica Consumi ::= "Oggetto: "potenza:" Potenza "kW" "orario" "dalle" "alle" La seconda parte dei due blocchi principali è rappresentata dallinserimento dei vari oggetti di cui si vogliono effettuare delle previsioni di consumo. I parametri in questo caso sono: a) un nome delloggetto, b) la potenza espressa in kW, che andremo a vedere meglio come esprimere, c) la fascia oraria in cui viene utilizzato tale oggetto.

9 Grammatica Potenza ::= | "da" "a" La potenza merita una riflessione, in merito anche a quanto anticipato nellintroduzione; fondamentalmente ci si può trovare davanti a due situazioni : a) Si conosce esattamente il consumo al kW delloggetto b) Si può avere unidea che può andare da un minimo di tot kW ad un massimo di tot kW. Ecco spiegata lalternativa. Nel secondo caso, per comodità, è stato preso un valore medio tra il consumo minimo ed il consumo massimo.

10 Grammatica – Token ::= ( | )* ::= "0." ::= ( )* > ::= ( "0" | "1" | "20" | "21" | "22" | "23" ) ":"["0"-"5"] ::= ("-LUN-" | "-MAR-" | "-MER-" | "-GIO-" | "-VEN-" | "-SAB-" | "-DOM-" )

11 ::=["a"-"z"] | ["A"-"Z"] | "_" ::=["1" - "9"] ::=["0" - "9"] Le espansioni che iniziano con # sono private, in quanto sono utilizzabili solamente internamente ai soli token. Grammatica – Token

12 E stato definito un apposito token 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 è 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, 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, unintera settimana. Grammatica – Token

13 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

14 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)

15 Strumenti utilizzati Java 1.6.0_03 JavaCC 4.0 Java Tree Builder 1.3.2 NetBeans 6.0

16 Architettura packages creati e imposti dagli strumenti automatici utilizzati packages creati seguendo il modello architetturale dato dagli strumenti automatici

17 Architettura syntaxtree contiene quanto necessario allalbero 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 dallutente nelle apposite strutture dati create.

18 Architettura Il package main contiene solo la classe Main, utilizzata per lanciare lapplicazione. 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.

19 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 settimana b) se tutti i minuti della settimana sono stati etichettati con il loro rispettivo valore della tariffa.

20 Limiti dellapplicazione e sviluppi futuri Sicuramente il limite più grosso che si può notare attualmente è che se lutente non conosce precisamente il consumo di un oggetto, dando un range di valori ottiene solo un dato medio. Sarebbe meglio magari fare unanalisi 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 dellanno. 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).

21 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.


Scaricare ppt "Corso di Laurea Specialistica in Ingegneria Informatica Previsione dei Consumi Elettrici = Progetto per lesame di Linguaggi e Modelli Computazionali LS."

Presentazioni simili


Annunci Google