docs: update documentation and fix some typo

Author: andrea-acampora

docs/03-devops/buildAutomation.md

@@ -15,5 +15,5 @@ Per automatizzare le attività di compilazione del codice sorgente, la gestione
 </div>
 Al fine di garantire il principio DRY e gestire in modo organizzato, centralizzato e chiaro le dipendenze presenti nei microservizi, si è scelto di utilizzare il *Gradle Version Catalog* in formato *TOML*.
 
-Inoltre, è stato configurato il sistema di reporting *[Gradle build scans](https://scans.gradle.com/)* al fine di pubblicare un report ogniqualvolta vi sia un fallimento nel processo di build. Questo ci ha aiutati ad ispezionare ed analizzare i servizi in caso di fallimenti.
+Inoltre, è stato configurato il sistema di reporting *[Gradle build scans](https://scans.gradle.com/)* al fine di pubblicare un report ogniqualvolta vi sia un fallimento nel processo di build. Questo ci ha aiutati ad ispezionare ed analizzare i microservizi in caso di fallimenti.
 

docs/03-devops/continuousIntegration.md

@@ -20,7 +20,7 @@ Il primo *workflow* è stato sviluppato a supporto dei microservizi dell'*Applic
 Il *workflow* viene eseguito ogniqualvolta viene effettuato un *push* o una *pull request*.
 I *job* che vengono eseguiti sono i seguenti:
 
-1. *validation*: per prima cosa viene validato il *wrapper* di *Gradle* al fine di verificare che esso sia un *wrapper* valido e riconosciuto e non parte di un qualche attacco di *supply chain*.
+1. *validation*: per prima cosa viene validato il *wrapper* di *Gradle* al fine di verificare che esso sia valido, riconosciuto e non parte di un qualche attacco di *supply chain*.
 2. *build*: dopo che il *job* *validation* è passato, viene eseguita la *build* del microservizio. Essa consiste nell'esecuzione dei test e dei controlli di qualità del codice su tutte le combinazioni di diversi sistemi operativi e diverse versioni del linguaggio utilizzato al fine di assicurare il corretto funzionamento sulle piattaforme d'interesse.
    Infine viene caricata la coverage, calcolata tramite *JaCoCo* come anticipato, sul tool cloud-based *[Codecov](https://about.codecov.io/)*.
 3. *release-and-delivery*: dopo che la *build* viene completata con successo, se il *workflow* ha accesso ai segreti (quindi solo nel caso di *push* sulla *repository* originale) viene eseguita la *release* su *GitHub Release* e il *delivery* su *GitHub Packages* del microservizio stesso. Questo viene effettuato sfruttando la *GitHub Action* **release-and-delivery-action** sviluppata dal team e descritta in seguito. 
@@ -48,7 +48,7 @@ I *job* che vengono eseguiti sono i seguenti:
 ## Digital Twins
 
 Il terzo *workflow* è stato sviluppato a supporto dei modelli *Digital Twins* modellati tramite il linguaggio *Digital Twins Definition Language* (*DTDL*).
-In questo *workflow* è presente un singolo *job* - *validate* -, eseguito ogniqualvolta viene eseguito il *push* o una *pull request*, il quale, tramite l'ausilio della *GitHub Action* **dtdl-validator-action**, sviluppata dal team, verifica la validità dei modelli *DTDL* sviluppati.
+In questo *workflow* è presente un singolo *job*  *validate*, eseguito ogniqualvolta viene effettuato il *push* o una *pull request*, il quale tramite l'ausilio della *GitHub Action* **dtdl-validator-action** sviluppata dal team verifica la validità dei modelli *DTDL* sviluppati.
 
 ## Azure Function
 
@@ -68,25 +68,27 @@ I *job* che vengono eseguiti sono i seguenti:
 
 ### release-and-delivery-action
 
-La *GitHub Action* [`release-and-delivery-action`](https://github.com/SmartOperatingBlock/release-and-delivery-action) è stata sviluppata con lo scopo di agevolare la gestione del processo di release e di delivery di un progetto. Dapprima, l'azione si occupa di effettuare la *release* attraverso l'esecuzione dei comandi definiti in input, successivamente, se la release è stata effettuata, costruisce l'*immagine Docker* con la stessa versione della *release* appena effettuata. Infine ne effettua il delivery su un *Container Registry* fornito in input. Al fine di permettere un utilizzo generico è possibile escludere il processo di *release* ed effettuare solamente la costruzione e il *delivery* dell'*immagine* del container o viceversa.
+La *GitHub Action* [`release-and-delivery-action`](https://github.com/SmartOperatingBlock/release-and-delivery-action) è stata sviluppata con lo scopo di agevolare la gestione del processo di release e di delivery di un progetto. Dapprima, l'azione si occupa di effettuare la *release* attraverso l'esecuzione dei comandi definiti in input, successivamente, se essa è stata effettuata, costruisce l'*immagine Docker* con la stessa versione della *release* appena effettuata. Infine ne effettua il delivery su un *Container Registry* fornito in input. 
+
+Al fine di permettere un utilizzo generico è possibile escludere il processo di *release* ed effettuare solamente la costruzione e il *delivery* dell'*immagine* del container o viceversa.
 
 ### documentation-ghp-action
 
 La *GitHub Action* [`documentation-ghp-action`](https://github.com/SmartOperatingBlock/documentation-ghp-action) è stata sviluppata con lo scopo di agevolare la generazione e la pubblicazione della documentazione dei microservizi. In particolare, vengono messi a disposizione per l'utilizzatore tre tipi di documentazione:
 
-- *Documentazione del codice sorgente*: per quanto riguarda la documentazione del codice sorgente, al fine di supportare qualsiasi linguaggio e qualsiasi *documentation engine,* i comandi di generazione vengono specificati in input da parte dell'utilizzatore.
+- *Documentazione del codice sorgente*: al fine di supportare qualsiasi linguaggio e qualsiasi *documentation engine*, i comandi di generazione vengono specificati in input da parte dell'utilizzatore.
 - *Documentazione delle API REST*: per quanto riguarda la documentazione delle *API REST* si richiede l'adozione della specifica [*OpenAPI*](https://swagger.io/resources/open-api/). In particolare viene richiesto all'utilizzatore di fornire in input il *path* del file in formato *yaml* contenente la documentazione.
 - *Documentazione degli eventi*: per quanto riguarda la documentazione degli eventi si richiede l'adozione della specifica [*AsyncAPI*](https://www.asyncapi.com/). In particolare viene richiesto all'utilizzatore di fornire in input il *path* del file in formato *yaml* contenente la documentazione.
 
 Le documentazioni generate vengono pubblicate su un sito web associato alla *repository* tramite il servizio di hosting *GitHub Pages*. Al fine di permettere un utilizzo generico è possibile selezionare quali documentazioni generare.
 
 ### dtdl-validator-action
 
-La *GitHub Action* [`dtdl-validator-action`](https://github.com/SmartOperatingBlock/dtdl-validator-action) è stata sviluppata con lo scopo di permettere la validazione dei modelli dei Digital Twins scritti in *DTDL*. In particolare, essa sfrutta il validatore [*DTDL Validator*](https://github.com/Azure-Samples/DTDL-Validator) sviluppato da *Microsoft*, adattandolo ad un utilizzo in pipeline di Continuous Integration.
+La *GitHub Action* [`dtdl-validator-action`](https://github.com/SmartOperatingBlock/dtdl-validator-action) è stata sviluppata con lo scopo di permettere la validazione dei modelli dei Digital Twins scritti in *DTDL*. In particolare, essa sfrutta il validatore [*DTDL Validator*](https://github.com/Azure-Samples/DTDL-Validator) sviluppato da *Microsoft*, adattandolo ad un utilizzo in pipeline di *Continuous Integration*.
 
 ## Automatic Dependency Update
 
 Al fine di automatizzare l'aggiornamento delle dipendenze dei software sviluppati sono stati utilizzati i seguenti bot:
 
-- [*Renovate*](https://www.mend.io/renovate/): configurato per creare una *pull request* su un branch ad-hoc ogniqualvolta è presente una nuova versione di una dipendenza utilizzata nel progetto. Al fine di permettere il *DRY* delle configurazioni è stata creata una *repository* [`renovate-config`](https://github.com/AndreaGiulianelli/renovate-config) contenente tutte le configurazioni utilizzate.
+- [*Renovate*](https://www.mend.io/renovate/): configurato per creare una *pull request* su un branch ad-hoc ogniqualvolta sia presente una nuova versione di una dipendenza utilizzata nel progetto. Al fine di permettere il *DRY* delle configurazioni è stata creata una *repository* [`renovate-config`](https://github.com/AndreaGiulianelli/renovate-config) contenente tutte le configurazioni utilizzate.
 - [*Mergify*](https://mergify.com/): utilizzato per velocizzare ed automatizzare i merge delle *pull request* nel branch di sviluppo principale. Come *merging strategy* è stato impiegato il *rebase*.

docs/03-devops/licence.md

@@ -18,7 +18,9 @@ Di seguito una tabella che elenca i permessi, le limitazioni e le condizioni che
 | ✅ Distribuzione   |             |                                |
 | ✅ Uso privato   |             |                                |
 
-Tramite le funzionalità offerte da *Intellij-IDEA* e *VSCode*, utilizzati per lo sviluppo, abbiamo applicato il corrispettivo *Copyright Notice Header* in ogni file sorgente. 
+Tramite le funzionalità offerte da *Intellij-IDEA* e *VSCode*, utilizzati per lo sviluppo, abbiamo applicato il corrispettivo *Copyright Notice Header* in ogni file sorgente.
+
+Di seguito vengono descritte le licenze delle principali librerie e framework utilizzati.
 
 | Strumento / Libreria / Framework | Licenza                                        |
 | -------------------------------- | ---------------------------------------------- |

docs/03-devops/qualityAssurance.md

@@ -9,17 +9,18 @@ has_children: false
 # Quality Assurance
 
 Una buona pratica della Build Automation e in generale del DevOps è l'utilizzo di tools per la validazione della qualità del codice prodotto. 
+
 Per i microservizi basati su Kotlin: 
 
 + **Static Code Analysis**: [*Detekt*](https://github.com/detekt/detekt), [*Cpd*](https://pmd.github.io/pmd/pmd_userdocs_cpd.html) 
 + **Style Checking**: [*Ktlint*](https://github.com/pinterest/ktlint)
 
 Per i microservizi basati su Java: 
 
-+ **Static Code Analysis**: [*PMD*](https://pmd.github.io/), [*Cpd*](https://pmd.github.io/pmd/pmd_userdocs_cpd.html) , [*SpotBugs*](https://spotbugs.github.io/)
++ **Static Code Analysis**: [*PMD*](https://pmd.github.io/), [*Cpd*](https://pmd.github.io/pmd/pmd_userdocs_cpd.html), [*SpotBugs*](https://spotbugs.github.io/)
 + **Style Checking**: [*CheckStyle*](https://checkstyle.org/)
 
 Per agevolare la configurazione di entrambi gli stack si è fatto uso di due plugin *Gradle*, rispettivamente [`gradle-kotlin-qa`](https://github.com/DanySK/gradle-kotlin-qa) e [`gradle-java-qa`](https://github.com/DanySK/gradle-java-qa).
 L'esecuzione di questi controlli avviene anche prima di ciascun commit effettuato tramite l'*hook pre-commit* descritto precedentemente.
 
-Al fine di supportare ulteriormente il processo di Quality Assurance tramite ad esempio l'analisi e il rilevamento di code smell, problemi di sicurezza, debito tecnico e duplicazione di codice si è fatto uso dei servizi cloud-based [*SonarCloud*](https://www.sonarsource.com/products/sonarcloud/) e [*GitGuardian*](https://www.gitguardian.com/).
+Al fine di supportare ulteriormente il processo di *Quality Assurance* tramite ad esempio l'analisi e il rilevamento di *code smell*, problemi di sicurezza, debito tecnico e duplicazione di codice si è fatto uso dei servizi cloud-based [*SonarCloud*](https://www.sonarsource.com/products/sonarcloud/) e [*GitGuardian*](https://www.gitguardian.com/).

docs/03-devops/workflowOrganization.md

@@ -29,22 +29,22 @@ I branch utilizzati dal workflow sono i seguenti:
 Inoltre, al fine di esplicitare maggiormente il significato dei commit si è scelto di utilizzare la specifica *[Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/)*, che ha semplificato l'utilizzo di tool automatici per il versionamento dell'applicazione. I tipi di commit adottati sono i seguenti:
 
 - `build`: riguardano cambiamenti che interessano il build system oppure dipendenze esterne
-- `chore`: riguardano cambiamenti generici, indica l'aggiunta o la modifica di codice correlato a attività di manutenzione generale, come la gestione dei file o altre attività che non introducono nuove funzionalità o risolvono bug.
+- `chore`: riguardano cambiamenti generici, indica l'aggiunta o la modifica di codice correlato a attività di manutenzione generale come la gestione dei file o altre attività che non introducono nuove funzionalità o risolvono bug
 - `ci`: riguardano cambiamenti nella configurazione dei file e negli script di *Continuous Integration*
 - `docs`: riguardano cambiamenti alla documentazione di progetto
 - `feat`: riguardano l'aggiunta di una nuova feature
 - `fix`: riguardano la risoluzione di un bug
 - `perf`: riguardano un cambiamento del codice per il miglioramento delle performance del sistema
-- `refactor`: riguardano un cambiamento del codice che non risolve un bug e non aggiunge nessuna feature, quindi un'attività di refactoring.
+- `refactor`: riguardano un cambiamento del codice che non risolve un bug e non aggiunge nessuna feature, quindi un'attività di refactoring
 - `style`: riguardano modifiche allo stile del codice che non impattano le funzionalità
-- `revert`: riguardano l'annullamento di modifiche portate da commit precedenti.
+- `revert`: riguardano l'annullamento di modifiche portate da commit precedenti
 - `test`: riguardano l'aggiunta o la modifica di test
 
 Al fine di controllare il corretto utilizzo della specifica *Conventional Commits* ed il rispetto degli standard di qualità sul codice prodotto sono stati utilizzati i seguenti *hook* per *Git*:
 
-- *Pre commit*: si verifica il rispetto degli standard di qualità sul codice mediante l'utilizzo dei task *Gradle* forniti dalle suite di *Quality Assurance* descritte nel seguito
-- *Commit msg*: si verifica il rispetto della specifica *Conventional Commit*
-- *Post commit*: si verifica che il commit prodotto sia *signed*. In caso di mancata firma del commit verrà visualizzato un warning utile per lo sviluppatore, ma non verrà fatto fallire
+- *pre-commit*: verifica il rispetto degli standard di qualità sul codice mediante l'utilizzo dei task *Gradle* forniti dalle suite di *Quality Assurance* descritte in seguito
+- *commit-msg*: verifica il rispetto della specifica *Conventional Commit*
+- *post-commit*: verifica che il commit prodotto sia *signed*. In caso di mancata firma del commit verrà visualizzato un warning utile per lo sviluppatore, ma non verrà fatto fallire
 
 Essi sono stati configurati attraverso il plugin *Gradle* [`gradle-pre-commit-git-hooks`](https://github.com/DanySK/gradle-pre-commit-git-hooks).
 

docs/04-implementation/index.md

@@ -1,28 +1,28 @@
 ---
 title: Implementazione
 layout: default
-has_children: true
+has_children: false
 nav_order: 5
 ---
 # Implementazione
 
 Considerando l'obbiettivo della relazione, in questa sezione verranno presentati i principali linguaggi e le principali tecnologie utilizzate senza entrare nei dettagli implementativi. 
 
-## Phisical Layer
+## Physical Layer
 
 La *Centralina di zona* è stata sviluppata utilizzando il linguaggio *C++* sfruttando il framework *Wiring* mentre il *Gateway di blocco* è stato sviluppato utilizzando [*Node-RED*](https://nodered.org/). 
 
 ## Digital Twins Layer 
 
-Per la modellazione dei Digital Twins si è sfruttato il linguaggio *Digital Twins Definition Language* (DTDL) mentre per lo sviluppo della *Azure Function* si è utilizzato *C#*.
+Per la modellazione dei *Digital Twins* si è sfruttato il linguaggio *Digital Twins Definition Language* (DTDL) mentre per lo sviluppo della *Azure Function* si è utilizzato *C#*.
 
 ## Application Layer 
 
 Considerando che ogni microservizio, seguendo i principi dello stile architetturale, può essere implementato utilizzando lo stack tecnologico più adeguato, si è fatto uso del linguaggio *Java* per il microservizio *Automation Management* e di *Kotlin* per i restanti. 
 Le principali librerie e framework utilizzati sono stati: 
 
 + **Kafka Clients**, per l'interazione con l'event broker
-+ **Ktor**, per la realizzazione delle API Rest
++ **Ktor**, per la realizzazione delle API REST
 + **Kmongo**, per l'interazione con MongoDB
 + **JaCaMo**, per lo sviluppo del sistema multi-agente presente nel microservizio *Automation Management*
 + **Vert.X**, per lo sviluppo del microservizio *API Gateway*

docs/05-conclusion/index.md

@@ -6,9 +6,8 @@ nav_order: 6
 ---
 # Conclusioni
 
-L'impiego delle tecniche di *Domain-Driven Design* ha permesso di comprendere in modo approfondito un dominio complesso come quello sanitario. In particolare, grazie alle tecniche di *knowledge crunching* utilizzate nei primi meeting, è stato possibile comprendere il funzionamento attuale e il funzionamento atteso del sistema, oltre che i processi, le responsabilità e il linguaggio tecnico. L'utilizzo di un sito di progetto su *Confluence* e di strumenti come *Miro* e *Figma* ha permesso da un lato di simulare un contesto reale, mentre dall'altro ha semplificato la collaborazione e permesso una condivisione della conoscenza tra i componenti del team. 
+L'impiego delle tecniche di ***Domain-Driven Design*** ha permesso di comprendere in modo approfondito un dominio complesso come quello sanitario. In particolare, grazie alle tecniche di *Knowledge Crunching* utilizzate nei primi meeting, è stato possibile comprendere il funzionamento attuale e il funzionamento atteso del sistema oltre che i processi, le responsabilità e il linguaggio tecnico. L'utilizzo di un sito di progetto su *Confluence* e di strumenti come *Miro* e *Figma* ha permesso da un lato di simulare un contesto reale, mentre dall'altro ha semplificato la collaborazione e permesso una condivisione della conoscenza tra i componenti del team. 
 
-Inoltre, l'utilizzo degli elementi del design strategico del DDD, in particolare l'identificazione dei sottodomini e la progettazione dei *bounded context* con le relative relazioni espresse nella *context map*, ha permesso una migliore gestione della complessità evitando al tempo stesso di inserire ambiguità nella conoscenza e nella progettazione. 
-
-Infine, l'utilizzo di pratiche di *DevOps* e la progettazione di pipeline di *Continuous Integration* hanno evitato la ripetizione di attività manuali, in particolare l'analisi statica del codice, l'esecuzione di test di regressione, il rilascio e il delivery del software, automatizzando i processi ed aumentando la qualità e la produttività. 
+Inoltre, l'utilizzo degli elementi del design strategico del DDD, in particolare l'identificazione dei sottodomini e la progettazione dei *bounded context* con le relative relazioni espresse nella *Context Map*, ha permesso una migliore gestione della complessità evitando al tempo stesso di inserire ambiguità nella conoscenza e nella progettazione. 
 
+Infine, l'utilizzo di pratiche di ***DevOps*** e la progettazione di pipeline di *Continuous Integration* hanno evitato la ripetizione di attività manuali come l'analisi statica del codice, l'esecuzione di test di regressione ed il rilascio e delivery del software, automatizzando così i processi ed aumentando la qualità e la produttività.