Add DOCUMENTO_FINALE + final small changes

README.md

@@ -7,20 +7,22 @@
 Repo del progetto per il corso di *Ingegneria del Software*.
 
 Si tratta di un *sistema di gestione di un magazzino*, che permette di svolgere una serie di attività, tra cui:
+
 - Tenere traccia dei depositi e dei prelievi degli articoli, con le relative destinazioni;
 - Monitorare le quantità disponibili, con la possibilità di impostare una soglia minima di scorta a magazzino;
 - Tenere traccia delle caratteristiche di ogni singolo prodotto.
 
 ## Membri del gruppo
 
 Questo progetto è stato realizzato da:
-- Brambilla Davide
-- Brivio Lorenzo
-- Gervasoni Massimiliano
+
+- **Brambilla Davide** - Matr. 1080752
+- **Brivio Lorenzo** - Matr. 1073423
+- **Gervasoni Massimiliano** - Matr. 1069211
 
 ## Documentazione
 
-Tutta la documentazione del progetto risiede nella cartella `/docs`; fare riferimento al documento [/docs/README.md](./docs/README.md) per averne una panoramica.
+Tutta la documentazione del progetto risiede nella cartella `/docs`. Fare riferimento al documento [/docs/README.md](./docs/README.md) per averne una panoramica.
 
 Nella sezione *Projects* della repo è presente anche la *Kanban board* dove vengono gestiti gli issue/PR e le attività divise in *da fare* | *in corso* | *fatte*.
 

docs/Modelling.md

@@ -55,6 +55,6 @@ Dopo aver completato queste azioni, il magazziniere ritorna allo stato "senza mo
 
 Col *diagramma di sequenza* siamo andati a modellare la sequenza di interazioni tra il *Responsabile Ordini*, *Magazziniere Qualificato* e il *Modello degli Ordini* volte alla creazione e gestione degli ordini.
 
-![sequence diagram](./UML/SequenceDiag%20-%20Ordini.jpg)
+![Sequence diagram](./UML/SequenceDiag%20-%20Ordini.jpg)
 
 Principalmente si denota ovviamente il ruolo principale del *Responsabile Ordini* nella gestione degli ordini. In particolare, una volta creato e prima di essere approvato, un ordine può essere cancellato o eventualmente modificato più volte solo se si tratta di un ordine in uscita. Un ordine poi può essere approvato: se si tratta di un rifornimento (`IN`) deve essere approvato da un *Magazziniere Qualificato* alla consegna delle merci ordinate, se invece si tratta di un ordine commissionato (`OUT`) deve essere approvato dal *Responsabile Ordini* e in questo caso il sistema si assicura che sia preparabile controllando le disponibilità. All'approvazione, il modello genera le movimentazioni, cambia lo stato dell'ordine e, una volta completate tutte le movimentazioni, lo contrassegna come completato.

docs/README.md

@@ -12,6 +12,7 @@ Nella cartella `UML` si possono trovare i seguenti diagrammi UML:
 - State diagram
 - Activity diagram
 - Sequence diagram
+- Component diagram
 
 Tutti questi vengono raggruppati nel [*capitolo del Modeling*](./Modelling.md) della documentazione.
 
@@ -29,4 +30,5 @@ Oltre a questo, troviamo i vari file dei capitoli della documentazione:
 - [Modeling](./Modelling.md)
 - [Software Architecture](./SoftwareArchitecture.md)
 - [Software Design](./SoftwareDesign.md)
-- [Testing](./Testing.md)
+- [Testing](./Testing.md)
+- [Software Maintenance](./SoftwareMaintenance.md)

docs/SoftwareArchitecture.md

@@ -1,8 +1,8 @@
-# Architettura Software
+# Software Architecture
 
 ![alt](UML/ComponentDiagram.jpg)
 ### Introduzione
-Il software é stato sviluppato seguendo un'architettura modulare basata sul pattern Model-View-Controller, in cui i due moduli view e controller sono stati accorpati in quanto fortemente legati; questa andrà ad interfacciarsi, attraverso l'utilizzo di jOOQ, con un database creato usando SQlite. La connessione al database SQLite è gestita da un componente  che si trova nel package "smartmag.db", il quale fornisce un'interfaccia per stabilire e gestire la connessione (unica) con il database, garantendo l'integrità e la persistenza dei dati.
+Il software é stato sviluppato seguendo un'architettura modulare basata sul pattern Model-View-Controller, in cui i due moduli view e controller sono stati accorpati in quanto fortemente legati; questa andrà ad interfacciarsi, attraverso l'utilizzo di jOOQ, con un database creato usando SQlite. La connessione al database SQLite è gestita da un componente  che si trova nel package `smartmag.db`, il quale fornisce un'interfaccia per stabilire e gestire la connessione (unica) con il database, garantendo l'integrità e la persistenza dei dati.
 
 
 ### Modello

docs/SoftwareDesign.md

@@ -34,7 +34,7 @@ Ciascun modello (Observable) contiene una lista di observer, i quali ricevono un
 Ogni view (Observer) è stata registrata al relativo modello per ricevere le notifiche in caso di aggiornamenti.
 
 ## Misurazione del codice
-### JDepend:
+### JDepend
 Per misurare le metriche indicate nella tabella seguente e valutare così la qualità della progettazione del software, abbiamo fatto ricorso a *JDepend*.  
 Dalla tabella si può notare che il livello di astrazione del software è generalmente basso. Per aumentare questo valore, si dovrà effettuare del refactoring in fase di manutenzione.
 
@@ -54,7 +54,7 @@ Dove:
 - Ca: accoppiamento afferente
 - Ce: accoppiamento efferente
 
-### Structure101:
+### Structure101
 Per avere un'ulteriore valutazione sulle dipendenze delle classi e dei pacchetti, abbiamo utilizzato *Structure101*.  
 Principalmente sono state valutate le classi contenute nei pacchetti e quindi il loro livello di coesione e la presenza di loop.
 

docs/SoftwareMaintenance.md

@@ -1,4 +1,5 @@
-### Software Maintenance
+# Software Maintenance
+
 Durante il ciclo di sviluppo del software l'attenzione dedicata alla manutenzione è cruciale per garantire la solidità e l'efficacia del sistema. In questo contesto, abbiamo condotto una serie di interventi mirati attraverso due fasi distintive di manutenzione.
 
 Nella prima fase, ci siamo concentrati sul refactoring, una pratica essenziale per migliorare la struttura interna del codice. Abbiamo rimosso metodi superflui, ottimizzato quelli esistenti e modificato le visibilità dei metodi per garantire una più efficiente gestione delle funzionalità. Questo approccio ha contribuito a rendere il software più snello, maneggevole e preparato ad affrontare futuri sviluppi.

docs/SoftwareQuality.md

@@ -10,15 +10,15 @@ Per lo sviluppo del progetto sono stati seguiti alcuni dei fattori di qualità d
   con un certo grado di precisione.
 
 - _Manutenibilità:_ È stato ottenuto un certo livello di manutenibilità grazie all'utilizzo dei *design patterns* che hanno permesso di dare al software una struttura
-  che lo rendesse di facile commprensione e di conseguenza, in caso di guasti da risolvere, anche semplice da manutenere.  
+  che lo rendesse di facile comprensione e di conseguenza, in caso di guasti da risolvere, anche semplice da manutenere.  
   Difatti durante la manutenzione di un software, è molto importante comprenderne il funzionamento.
   A tal proposito è stato utilizzato intensivamente *Javadoc*, in particolare per la descrizione delle funzioni svolte dai metodi presenti all'interno del software.
 
 - _Usabilità:_ L'interfaccia grafica che è stata sviluppata è intuitiva e semplice da utilizzare. Questa semplicità di utilizzo è favorita     
   dalla presenza di pulsanti autoesplicativi e da una buona suddivisione in finestre contenenti funzionalità affini.
 
 - _Testabilità:_ Il software che è stato realizzato, pur utilizzando un DB (che potrebbe introdurre difficoltà nella realizzazione dei casi di test), è semplice da testare.
- Quest'ultima è stata ottenuta grazie alla realializzazione di metodi che, invocati al termine dei test, ripuliscono il DB da eventuali modifiche apportate.
+ Quest'ultima è stata ottenuta grazie alla realizzazione di metodi che, invocati al termine dei test, ripuliscono il DB da eventuali modifiche apportate.
  Inoltre nel caso non servisse lavorare su dati già presenti nel DB dell'applicazione, è stata data la possibilità di utilizzare altri DB sui quali effettuare casi di test.
 
 - _Portabilità:_ Il software è stato realizzato nel linguaggio *Java*, il quale garantisce portabilità grazie alla *JVM* (Java Virtual Machine) e al *bytecode*.

docs/Testing.md

@@ -1,11 +1,12 @@
-# Unit testing
+# Testing
 
 Abbiamo creato dei *casi di test* con *JUnit 5* per esaminare la maggior parte delle funzionalità del sistema.
 L'obiettivò è individuare il maggior numero possibile di *difetti* (*bug*) durante la fase di build. Ciò viene fatto in vari modi: invocando le funzionalità da testare con parametri non validi, utilizzandole in contesti in cui non dovrebbe essere permesso o semplicemente simulando scenari e sequenze di azioni che riflettono l'uso tipico dell'applicazione.
 
 ## Focus sui modelli
 
 In particolare, abbiamo deciso di concentrare la nostra attività di testing sui *modelli* (MVC) in quanto ricoprono un ruolo chiave nel sistema sviluppato:
+
 - implementano la *business logic*;
 - espongono le *interfacce* attraverso cui è effettivamente possibile *svolgere operazioni sui dati* gestiti;
 - garantiscono l'*integrità dei dati* e la *persistenza* degli stessi.
@@ -27,7 +28,7 @@ Abbiamo realizzato in totale *74 casi di test* che interessano circa l'*80% del
 
 ![JUnit](./img/screens_tests/JUnit.jpg)
 
-![coverage](./img/screens_tests/coverage.png)
+![Coverage dei test](./img/screens_tests/coverage.png)
 
 ## Maven e GitHub Action per la Continuous Integration
 
@@ -40,4 +41,4 @@ Configurando poi ad-hoc una *GitHub Action*
 
 ![GitHub CI Action](./img/screens_tests/GH_action.png)
 
-![GitHub CI Action](./img/screens_tests/GH_action_fail.png)
+![GitHub CI Action fail](./img/screens_tests/GH_action_fail.png)