GeremiaPompei / Jbudget

Progetto per l'esame di Programmazione Avanzata.

Jbudget

La descrizione delle funzionalità implementate

Le funzionalità implementate da tale applicazione sono:

• Tener traccia dei movimenti per ogni account, tag, transazione o budget per mezzo di tabelle che mostrano i relativi dati. La schermata principale è divisa in due parti: nella superiore troviamo le tabelle contenenti i dati di account, tag, transazioni e budget in base alla scheda in cui ci troviamo mentre nella parte inferiore troviamo una tabella con tutti movimenti collegati al relativo account, tag, transazione o budget selezionato.
• Poter fissare un budget, ovvero un valore monetario che pone una soglia massima rispetto a quanto viene speso per determinate attività. Tali attività vengono etichettate per mezzo dei tag che servono al momento dell’aggiunta di un movimento proprio per tener traccia e gestire le spese ed i ricavi per tale attività. Creato un tag può quindi essere associato a questo un budget. Se questo viene superato l’applicazione per mezzo di notifiche avvisa l’utente di fare attenzione mostrando tag e il valore in negativo della differenza tra la somma dei saldi dei movimenti per quel tag ed il budget prefissato.
• Poter aggiungere transazioni istantanee o programmate per il futuro scegliendo tra le due. In caso la scelta ricada nella transazione programmata dovrà essere impostata la data futura. Appena selezionata la transazione più opportuna e premuto il pulsante per aggiungerla apparirà una finestra dove poter gestire i movimenti relativi a tale transazione. Questi possono essere aggiunti, rimossi e salvati per mezzo degli opportuni bottoni.
• L’aggiornamento automatico del bilancio dell’account, infatti esso si aggiorna in automatico appena viene eseguita una transazione istantanea mentre ciò non avviene con transazioni future. Un account si aggiorna per l’esattezza con il saldo dei movimenti eseguiti da e verso di lui nel momento in cui viene aggiunta una transazione.
• Poter filtrare la visualizzazione delle transazioni per tag o data, ovvero impostare un tag o un range di date per visualizzare le transazioni che rispettano tali parametri per facilitare la loro ricerca.
• Poter modificare la descrizione di tags, accounts, transazioni e movimenti. Ciò è possibile aprendo il TiteledPane al di sotto che mostrerà la descrizione dell’elemento selezionato all’interno della tabella, modificandola e pigiando il bottone change.
• Poter salvare i dati su file json selezionando dove salvare o esportare i dati registrati. Il salvataggio permette di impostare un determinato file per eseguire tutti i salvataggi automatici su di lui successivamente al salvataggio, mentre l’esportazione permette di salvare i dati su un file senza che questo venga modificato successivamente. Per poter eseguire tali operazioni basta andare su “File” e scegliere l’operazione desiderata.
• Poter aprire un file json esistente e gestire i dati gia presenti al suo interno. Basta andare su “File” e scegliere l’opzione “Open”.
• Poter creare un nuovo file json e operare su di lui aggiungendo e gestendo i suoi dati. Basta andare su “File” e scegliere l’opzione “New”.
• Poter tener traccia dei messaggi di log attraverso il salvataggio di questi su file all’interno della directory “logging”. Tali file vengono nominati “log_” più la data e l’ora del momento in cui è stato salvato il file.

La descrizione delle classi ed interfacce sviluppate con le responsabilità associate ad ognuna di queste

Per strutturare i concetti principali in un’applicazione è stato usato il modello MVC (Model-Control-View) : MODEL:

• TAG: Questa interfaccia è implementata dalle classi come TAGBASE che hanno la responsabilità di definire una categoria di un movimento. In essa inoltre può essere fissato un budget, ovvero un valore massimo di denaro che non dovrebbe essere superato con i movimenti effettuati su tale etichetta. Tale interfaccia permette alle classi che la implementano di accedere al proprio id, nome, descrizione. Inoltre permette di accedere ad una serie di movimenti etichettati con tale tag, alla somma del saldo di questi e di aggiungere e rimuovere un movimento.
• ACCOUNT: Questa interfaccia è implementata dalle classi come ACCOUNTBASE che hanno la responsabilità di gestire un conto sul quale possono essere fatti dei movimenti che ne alterano il saldo iniziale in un saldo effettivo. Tale interfaccia permette alle classi che la implementano di accedere al proprio id, nome, descrizione, tipo, bilancio iniziale, bilancio effettivo. Inoltre permette di accedere ad una serie di movimenti eseguiti su di esso, di aggiungere e rimuovere un movimento e di essere aggiornato in base a questi.
• ACCOUNTTYPE: Enumerazione che ha la responsabilità di definire il tipo di account, ovvero se esso è una risorsa o un debito e tramite questa caratteristica un account verrà considerato con bilancio iniziale positivo o negativo.
• MOVEMENT: Questa interfaccia è implementata dalle classi come MOVEMENTBASE che hanno la responsabilità di gestire un singolo movimento che verrà associato ad una transazione da cui ne prenderà la data. Tale interfaccia permette alle classi che la implementano di accedere al proprio id, data, descrizione, tipo, saldo, transazione, account e tag.
• MOVEMENTTYPE: Enumerazione che ha la responsabilità di definire il tipo di un movimento che può essere appunto un credito, se questo è stato eseguito verso il conto, o un debito altrimenti. In base al questo il saldo sarà inteso in positivo o negativo.
• TRANSACTION Questa interfaccia è implementata dalle classi che hanno la responsabilità di gestire una singola transazione. Essa non è altro che un gruppo di movimenti eseguiti in una certa data. Tale interfaccia permette alle classi che la implementano di accedere al proprio id, data, saldo totale (dato dalla somma dei saldi dei movimenti che la compongono). Inoltre permette di accedere alla serie di movimenti che la popolano e di aggiungere uno o più movimenti. Si può anche rimuovere un movimento.
• TRANSACTIONBASE: Classe astratta che ha la responsabilità di implementare i metodi dell’interfaccia ma non dare la possibilità di essere istanziata. Essa ha due costruttori che saranno implementati in base al fatto che la transazione sarà eseguita in una data fissa o no.
• INSTANTTRANSACTION: Classe che ha la responsabilità gestire una singola transazione avvenuta nel momento corrente. Essa infatti nel costruttore non prenderà una data perché sarà impostata in automatico.
• PROGRAMTRANSACTION: Classe che ha la responsabilità di gestire una transazione programmata in una certa data passata al costrutto. Tale classe può permettere di eseguire una transazione in una data stabilita dall’utente nel futuro.
• IDGENERATOR: Questa interfaccia è implementata dalle classi come IDGENERATORBASE che hanno la responsabilità di gestire un generatore di ID. Essa permette solamente di generare un id univoco. In particolare l’implementazione data permette di generare un id che si auto incrementa.
• LEDGER: Questa interfaccia è implementata dalle classi come LEDGERBASE che hanno la responsabilità di gestire un ledger, ovvero un libro mastro che permette di gestire oggetti come account, tag e transazioni. Tale interfaccia permette alle classi che la implementano di accedere ad una serie di tag, account o transazioni, di aggiungerli o rimuoverli, accedere al generatore di id o impostarlo ad un certo id di partenza. Inoltre tali classi potranno aggiornare ogni account e accedere ad un account, tag o transazione tramite il loro id. Un’altra responsabilità associata alle classi che implementano l’interfaccia ledger è quella di mettere a disposizione un metodo per l’eliminazione dei movimenti che ne determina la perdita dei riferimenti da parte di account, tag e transazioni associati ad esso.
• BUDGET: Questa interfaccia è implementata dalle classi come BUDGETBASE che hanno la responsabilità di gestire una serie di budget, ognuno fissato per un certo tag. Tale interfaccia permette alle classi che la implementano di accedere alla tabella contenente i budget, al valore di un budget dato un tag, ad una serie di tag per i quali è stato fissato un budget e di aggiungere o rimuovere un tag.
• BUDGETREPORT: Questa interfaccia è implementata dalle classi come BUDGETREPORTBASE che hanno la responsabilità di gestire un budget report, ovvero un aggeggio capace di stilare il resoconto del valore dato dalla differenza tra un budget e il saldo totale speso per un certo tag. Con tale resoconto si possono monitorare i budget superati o quanto mancherebbe per superarli. Tale interfaccia permette alle classi che la implementano di accedere al ledger, al budget e alla tabella del resoconto.
• READER: Interfaccia generica che mette a disposizione i metodi read e close per leggere un oggetto generico O. Essa quindi permette alle classi che la implementeranno di leggere e restituire un oggetto letto e chiudere la sessione di lettura. La responsabilità di tale interfaccia è quindi quella di mettere a disposizione tali metodi ad alto livello così da garantire la facilità di implementazione della lettura di un qualsiasi oggetto in un qualsiasi modo o formato.
• WRITER: Interfaccia generica che mette a disposizione i metodi write e close per scrivere un oggetto generico O. Essa quindi permette alle classi che la implementeranno di scrivere un oggetto e chiudere la sessione di scrittura. La responsabilità di tale interfaccia è quindi quella di mettere a disposizione tali metodi ad alto livello così da garantire la facilità di implementazione della scrittura di un qualsiasi oggetto in un qualsiasi modo o formato.
• JBUDGETREADERJSON: Classe che ha la responsabilità di leggere un budget report da un file json e ritornarlo. Un budget report per essere letto viene deserializzato. Con lui vengono deserializzati tutti gli elementi contenuti in esso, ovvero un budget e un ledger che rispettivamente contiene i tag, gli account e le transazioni che rispettivamente contengono i movimenti. Per ognuna di queste interfacce è stata creata una classe deserializer specifica per la deserializzazione della classe che la estende.
• JBUDGETWRITERJSON: Classe che ha la responsabilità di scrivere un budget report su un file. Un budget report per essere scritto viene serializzato. Con lui vengono serializzati tutti gli elementi contenuti in esso, ovvero un budget e un ledger che rispettivamente contiene i tag, gli account e le transazioni che rispettivamente contengono i movimenti. Per ognuna di queste interfacce è stata creata una classe serializer specifica per la serializzazione della classe che la estende.
• UTILITY: Interfaccia che ha la responsabilità di mettere a disposizione delle classi che la implementano dei metodi di utilità che gli permettono di accedere ad ID e descrizione e di modificare quest’ultima. CONTROL:
• MAINCONTROLLER: Tale interfaccia sarà estesa dalle classi come MAINCONTROLLERBASE che hanno la responsabilità di dare un'implementazione del controller dell'MVC per coordinare le attività eseguite sull'applicazione. Le implementazioni permetteranno di gestire accounts, tags, transazioni e budgets di un budget report oltre a dare la possibilità di aggiornare lo stato dei diversi componenti, salvare il budget report, leggerlo, ritornare il generatore degli id e tener traccia del valore di superamento di un budget con relativo tag. Inoltre una classe che implementa MainController permette di modificare la descrizione di un certo oggetto istanziato da una classe che implementa Utility. VIEW:
• GUIVIEWSTART: Classe che implementa Application e quindi ha la responsabilità di far partire la GUIView principale da un file FXML dove in tale formato vi è scritta l’interfaccia grafica.
• GUIVIEWCONTROLLER: Classe che ha la responsabilità di fare da controller alla view principale permettendo di renderla dinamica e gestire l'interazione con il controller dell'MVC così da consentire l'utente di interfacciarsi in maniera dinamica con il resto dell'applicazione. L’effettiva responsabilità di tale controller è gestire l’aggiunta dei campi da parte dell’utente inviandoli al controller dell’MVC per ottenere i risultati desiderati. Esso dunque non fa altro che catturare i valori inseriti, controllarli ed in caso non ci fossero errori eseguire l’operazione desiderata tramite controller dell’MVC, se no segnalare l’utente dell’errore avvenuto.
• GUIVIEWMOVEMENTCONTROLLER: Classe che ha la responsabilità di fare da controller alla view secondaria che si occupa della gestione dei movimenti di una nuova transazione tramite l’aggiunta, rimozione e salvataggio di questi.

Vi sono per ogni interfaccia Tag, Account,Transaction, Movement, Budget, Ledger, BudgetReport e MainController un’interfaccia Manager che contiene un singolo factory method per la loro generazione mediante una loro implementazione così da facilitarne il cambiamento in caso di uso di altre implementazioni.

La descrizione dei test sviluppati per verificare il corretto comportamento del codice

Nei test sviluppati si verifica il corretto uso del codice creando tramite dei metodi appositi contrassegnati con BeforeEach la Test Fixture, ovvero l’ambiente ricreato per simulare il test. Oltre a ciò, nelle classi test che trattano del salvataggio del file, attraverso il metodo statico contrassegnato con AfterAll viene eliminato il file creato per salvare e leggere i dati del test. Alcuni dei metodi più importanti che sono stati testati sono quelli di salvataggio o lettura da file json, dove è stato scritto e letto un budget report con all’interno dei dati. Per testare il salvataggio e la lettura sono poi stati confrontati i dati iniziali con quelli letti. Altri metodi importanti che sono stati testati sono quelli riguardanti l’aggiornamento che permettono di verificare una data condizione prima e dopo l’aggiornamento confrontando lo stato dei bilanci. Ulteriori metodi importanti riguardano le tabelle dei resoconti che vengono testate creando tag e aggiungendoli alla tabella impostandoci un budget. Dopo aver riempito le tabelle vengono paragonati i valori interni con quelli aspettati.

La descrizione dei meccanismi messi a disposizione per poter integrare nuove funzionalità

Per poter integrare nuove funzionalità nel modo più semplice possibile il progetto è stato sviluppato con l’interazione tra interfacce che né garantiscono la modularità insieme alla scelta del modello MVC. In tal modo viene facilitata l’aggiunta di altri sviluppi riguardanti le implementazioni del model anche grazie alle interfacce Manager che mettono a disposizione i factory methods per istanziare l’oggetto desiderato nei vari punti del programma. Poiché sono generati in tal modo i nuovi oggetti, può essere semplicemente cambiata l’implementazione del factory method per cambiare l’implementazione dell’interfaccia utilizzata in tutti i punti del programma. Sviluppando il programma nel modello MVC è possibile separarlo in tre macro categorie che sono indipendenti tra loro così da modificarne in futuro l’implementazione. Per salvare e leggere vengono messe a disposizione interfacce che vengono implementate così da garantire la modularità ed una possibile implementazione nel futuro ad un approccio di lettura e scrittura basato su database.