fix: review and correct some typos

Author: AndreaGiulianelli

docs/01-development_process/businessDomainAnalysisAndDesign.md

@@ -8,36 +8,36 @@ has_children: false
 
 # Analisi e Design del Business Domain
 
-Il campo del dominio sanitario presenta numerose sfaccettature che possono rendere estremamente complesso comprendere appieno questo ambito, soprattutto per coloro che non sono addetti ai lavori e non hanno familiarità con il linguaggio tecnico e le pratiche specifiche di questo settore.  A fronte di ciò si è reso necessario intraprendere un percorso di Knowledge Crunching, al fine di colmare il gap della lack of knowledge  e, ancora più importante, della lack of awareness. 
+Il campo del dominio sanitario presenta numerose sfaccettature che possono rendere estremamente complesso comprendere appieno questo ambito, soprattutto per coloro che non sono addetti ai lavori e non hanno familiarità con il linguaggio tecnico e le pratiche specifiche di questo settore.  A fronte di ciò si è reso necessario intraprendere un percorso di Knowledge Crunching, al fine di colmare il gap della lack of knowledge e, ancora più importante, della lack of awareness. 
 
 Considerando che il DDD ha l'obiettivo di ottenere una conoscenza condivisa del dominio è necessario stabilire un unico punto nel quale la conoscenza converge ed evolve in modo organizzato ed accessibile da tutti, anche dagli esperti di dominio in maniera semplice. A tal fine, adottando un approccio che si avvicinasse alla realtà, si è scelto di utilizzare [Confluence](https://www.atlassian.com/it/software/confluence), un software commerciale nel quale è stato documentata sia l'analisi del *problem space* che la progettazione del *solution space*. 
 
 La scelta di questo strumento è stata incentivata dalla possibilità di integrazione con strumenti di comunicazione come [Slack](https://slack.com/intl/it-it). Infatti, considerando che il processo di Knowledge Crunching necessita di più meeting, è necessario prevedere uno strumento che gestisca la comunicazione, assicurando cooperazione e collaborazione. 
 
-Il sito di progetto è visitabile al seguente link: [https://giacomoaccursi.atlassian.net/l/cp/vAxD2YKh](https://giacomoaccursi.atlassian.net/l/cp/vAxD2YKh)
+**Il sito di progetto è visitabile al seguente link: [https://giacomoaccursi.atlassian.net/l/cp/vAxD2YKh](https://giacomoaccursi.atlassian.net/l/cp/vAxD2YKh)**
 
-Seguendo le best-practice del Knowledge Crunching abbiamo cercato, insieme all'esperto del dominio (il professore del corso), di comprendere il dominio del problema. Abbiamo svolto un primo meeting con l'obiettivo di raccogliere i requisiti coarse-grained del sistema e la struttura del blocco operatorio. Durante il meeting è stato eseguito dello sketching tramite la creazione di una mind-map che riassumesse e mettesse in evidenza i concetti chiave del dominio, evitando così la perdita di informazioni. Questo primo incontro ha inoltre permesso l'identificazione degli stakeholder coinvolti e gli esperti di dominio da consultare nelle fasi successive. A seguito di ciò, al fine di delineare il comportamento del sistema, è stato effettuato un ulteriore meeting che ha condotto alla redazione dei diagrammi dei casi d'uso. 
+Seguendo le best-practice del Knowledge Crunching abbiamo cercato, insieme all'esperto del dominio (il professore del corso), di comprendere il dominio del problema. Abbiamo svolto un primo meeting con l'obiettivo di raccogliere i requisiti coarse-grained del sistema e la struttura del blocco operatorio. Durante il meeting è stato eseguito dello sketching tramite la creazione di una mind-map che riassumesse e mettesse in evidenza i concetti chiave del dominio, evitando così la perdita di informazioni. Questo primo incontro ha inoltre permesso l'identificazione degli stakeholders coinvolti e gli esperti di dominio da consultare nelle fasi successive. A seguito di ciò, al fine di delineare il comportamento del sistema, è stato effettuato un ulteriore meeting che ha condotto alla redazione dei diagrammi dei casi d'uso. 
 Partendo da essi abbiamo organizzato un ulteriore meeting al fine di raffinare, in modo iterativo ed incrementale, la conoscenza di alcuni processi ponendo domande mirate al committente. Questo ha permesso, tramite l'ausilio di strumenti di sketching come il Domain Storytelling, di ottenere un aumento della collaborazione diminuendo al tempo stesso l'ambiguità.
 Infine, gli ultimi dubbi rimasti e i dettagli prettamente tecnici sono stati chiariti effettuando un'intervista che ha coinvolto gli sviluppatori, l'esperto di dominio e un esperto tecnico dell'ospedale. 
 
-Una volta ottenuta una soddisfacente conoscenza del dominio, al fine di gestire la complessità e lo spazio del problema, sono stati individuati i relativi sottodomini che lo compongono, classificandoli in una delle tre tipologie tipiche del DDD. Questo ci ha aiutato a suddividere il problema in modo che fosse di più facile gestione e manutenibile. 
-Inoltre, per alcuni sottodomini è stata eseguita un'analisi più approfondita, accompagnata da una predizione della loro futura evoluzione, tramite l'ausilio di Core Domain Charts. 
+Una volta ottenuta una soddisfacente conoscenza del dominio, al fine di gestire la complessità e lo spazio del problema, sono stati individuati i relativi sottodomini che lo compongono, classificandoli in una delle tre tipologie tipiche del DDD. Questo ci ha aiutato a comprenderne le priorità e a suddividere il problema in modo che fosse di più facile gestione. 
+Inoltre, per alcuni sottodomini è stata eseguita un'analisi più approfondita, accompagnata da una predizione della loro futura evoluzione, tramite l'ausilio di *Core Domain Charts*. 
 
-Durante i vari meeting svolti, e per tutta la durata del progetto, si è cercato di individuare un linguaggio preciso e consistente eliminando qualsiasi forma di ambiguità, andando a creare di fatto quello che viene definito Ubiquitous Language. Nello specifico è stata creata una tabella dove ad ogni termine è associata una breve descrizione e i sottodomini d'interesse.
+Durante i vari meeting svolti, e per tutta la durata del progetto, si è cercato di individuare un linguaggio preciso e consistente eliminando qualsiasi forma di ambiguità, andando a creare di fatto quello che viene definito *Ubiquitous Language*. Nello specifico è stata creata una tabella dove ad ogni termine è associata una breve descrizione e i sottodomini d'interesse.
 
 Nell'ultima fase di analisi del dominio del problema si è provveduto, per ogni sottodominio, alla formalizzazione dei requisiti secondo la suddivisione tradizionale (business, utente, funzionali, non funzionali e di implementazione). 
 
-La suddivisione del problema in sottodomini ha permesso di comprendere quali siano le parti più importanti e in cui impiegare la maggior parte delle risorse. Quindi, dopo aver analizzato il problem space si è passati alla fase di analisi e progettazione del solution space partendo dalla progettazione dei Bounded Context che hanno permesso allo stesso tempo di iniziare il design dell'architettura del sistema stesso.
+La suddivisione del problema in sottodomini ha permesso di comprendere quali siano le parti più importanti e in cui impiegare la maggior parte delle risorse. Quindi, dopo aver analizzato il *problem space* si è passati alla fase di analisi e progettazione del *solution space* partendo dalla progettazione dei *Bounded Context* che hanno permesso allo stesso tempo di iniziare il design dell'architettura del sistema stesso.
 
-Nella progettazione dei Bounded Context abbiamo cercato di progettarli per rimpiazzo invece che per riuso, seguendo le best-practices del DDD. L'obiettivo di essi è la separazione dei modelli e dei loro vari significati, evitando così l'ambiguità e rispettando il Single Responsibility Principle (SRP). Inoltre, ogni Bounded Context è stato pensato per essere un servizio indipendente nella sua progettazione, implementazione e sopratutto nel suo versionamento ed evoluzione. Essi rappresentano non solo un boundary di modello, ma anche un boundary fisico e, cercando di simulare un contesto più reale possibile, abbiamo cercato di creare dei sotto-team (da una, fino al massimo di due persone) che si occuppassero di ogni singolo Bounded Context.
+Nella progettazione dei Bounded Context abbiamo cercato di progettarli per rimpiazzo invece che per riuso, seguendo le best-practices del DDD. L'obiettivo di essi è la separazione dei modelli e dei loro vari significati, evitando così l'ambiguità e rispettando il *Single Responsibility Principle* (SRP). Inoltre, ogni Bounded Context è stato pensato per essere un servizio indipendente nella sua progettazione, implementazione e sopratutto nel suo versionamento ed evoluzione. Essi rappresentano non solo un boundary di modello, ma anche un boundary fisico e, cercando di simulare un contesto più reale possibile, abbiamo cercato di creare dei sotto-team (da una, fino al massimo di due persone) che si occuppassero di ogni singolo Bounded Context.
 
-Come riportanto nel [sito di progetto](https://giacomoaccursi.atlassian.net/wiki/spaces/SOB/pages/3276818/Context+Map), l'analisi dettagliata svolta sui sottodomini ha portato ad una corrispondenza 1:1 tra i sottodomini e i Bounded Context, anche se i primi sono stati semplicemente individuati, mentre i secondi progettati.
+Come riportato nel [sito di progetto](https://giacomoaccursi.atlassian.net/wiki/spaces/SOB/pages/3276818/Context+Map), l'analisi dettagliata svolta sui sottodomini ha portato ad una corrispondenza 1:1 tra i sottodomini e i Bounded Context, anche se i primi sono stati semplicemente individuati, mentre i secondi progettati.
 
-Dopodichè, al fine di definire le relazioni presenti tra i diversi Bounded Context, è stata creata la relativa Context Map, sfruttando il software *Context Mapper*, che ha permesso di mettere in evidenza aspetti tecnici ed organizzativi.
+Dopodichè, al fine di definire le relazioni presenti tra i diversi Bounded Context, è stata creata la relativa *Context Map*, sfruttando il software *Context Mapper*, che ha permesso di mettere in evidenza aspetti tecnici ed organizzativi.
 
-Una volta definita la Context Map abbiamo formalizzato il modello del dominio di ogni sottodominio individuato sfruttando gli elementi del design tattico del DDD che ci hanno permesso di definire un meta-modello con cui poi mappare i concetti, individuati nel dominio, all'interno del codice, cercando di rispettare al tempo stesso l'Ubiquitous Language.
+Una volta definita la Context Map abbiamo formalizzato il modello del dominio di ogni sottodominio individuato sfruttando gli elementi del design tattico del DDD che ci hanno permesso di definire un meta-modello con cui poi mappare i concetti, individuati nel dominio, all'interno del codice cercando di rispettare al tempo stesso l'Ubiquitous Language.
 
-Dall'intervista svolta con l'esperto di dominio è emersa la necessità dello sviluppo di due tipologie di dashboard: l'*Operating Block Dashboard* e l'*Operating Room Dashboard*, perciò abbiamo organizzato un ulteriore meeting con l'obiettivo di definire i rispettivi mockup. Al fine di aumentare la collaborazione e la comprensione, si è scelto di sfruttare lo strumento *Figma* per produrre mockup *interattivi*.
+Dall'intervista svolta con l'esperto di dominio è emersa la necessità dello sviluppo di due tipologie di dashboard: l'*Operating Block Dashboard* e l'*Operating Room Dashboard*. Perciò abbiamo organizzato un ulteriore meeting con l'obiettivo di definire i rispettivi mockup. Al fine di aumentare la collaborazione e la comprensione si è scelto di sfruttare lo strumento *Figma* per produrre mockup *interattivi*.
 
 Il processo di analisi e di design del Business Domain del problema ha permesso di ottenere una conoscenza che fosse funzionale al mantenimento del software nella sua evoluzione e quindi che permettesse ad esso di essere più versatile, flessibile e manutenibile. Ciò è diverso dalle analisi dei requisiti che abbiamo svolto nei progetti precedenti con l'obiettivo di raccogliere informazioni per la progettazione di un'unica versione del software.
 

docs/01-development_process/index.md

@@ -7,10 +7,10 @@ nav_order: 2
 
 # Descrizione del processo adottato
 
-Per quanto riguarda il processo di sviluppo, considerando che il Domain-Driven Design (DDD) necessita di un approccio di project management iterativo che enfatizzi feedback frequenti da parte degli esperti di dominio e degli utenti coinvolti, il team ha deciso di adottare una metodologia agile, ispirandosi ai principi del framework *Scrum*.
+Per quanto riguarda il processo di sviluppo, considerando che il *Domain-Driven Design* (*DDD*) necessita di un approccio di project management iterativo che enfatizzi feedback frequenti da parte degli esperti di dominio e degli utenti coinvolti, il team ha deciso di adottare una metodologia agile, ispirandosi ai principi del framework *Scrum*.
 Considerando la cardinalità ridotta del team, si è adottata una versione semplificata di Scrum cercando di rimanere coerenti con la filosofia originale.
 
-Il DDD, grazie alla sua filosofia domain-centered e alle diverse sessioni di knowledge crunching che hanno accompagnato il progetto durante tutto il suo ciclo di vita, ha permesso a tutto il team di avere una visione chiara e completa del dominio, evitando i problemi tipici degli approcci agili (narrowing vision, orientazione al codice, ...). Ha permesso inoltre l'allineamento del codice con la realtà del dominio del problema facilitando l'evoluzione del software e prediligendo la collaborazione tra designers/developers ed esperti del dominio.
+Il DDD, grazie alla sua filosofia domain-centered e alle diverse sessioni di knowledge crunching che hanno accompagnato il progetto durante tutto il suo ciclo di vita, ha permesso a tutto il team di avere una visione chiara e completa del dominio, evitando i problemi tipici degli approcci agili. Ha permesso inoltre l'allineamento del codice con la realtà del dominio del problema facilitando l'evoluzione del software e prediligendo la collaborazione tra designers/developers ed esperti del dominio.
 
 Considerando che il progetto è stato portato avanti durante periodi di sessione di esami (Gennaio e Febbraio) e in seguito di lezioni (Marzo, Aprile e Maggio), gli Sprint hanno avuto due durate diverse: per il primo periodo due settimane, per il secondo un mese per un totale di sette Sprint. 
 Al termine di ogni sprint si è simulato un incontro con il committente al fine di validare il lavoro svolto e assicurare che non ci fossero discrepanze fra le aspettative e i risultati ottenuti.

docs/01-development_process/tools.md

@@ -10,13 +10,13 @@ has_children: false
 
 Come supporto delle pratiche del DDD durante tutto il progetto sono stati utilizzati diversi strumenti con lo scopo di agevolare e rendere più produttivo il team e l'interazione con gli esperti di dominio. 
 
-Di seguito verranno descritti i principali strumenti associando ognuno di essi allo scopo per cui è stato utilizzato e suddividendoli
+Di seguito verranno descritti i principali strumenti associando ad ognuno di essi lo scopo per cui è stato utilizzato.
 
 ## Knowledge crunching
 
 ### Egon.io
 
-[Egon.io](https://egon.io/) è un tool di supporto al Domain Storytelling. 
+[Egon.io](https://egon.io/) è un tool di supporto al *Domain Storytelling*. 
 
 Esso è stato utilizzato dal team per rappresentare, attraverso un linguaggio pittografico, le Domain stories raccontate dagli esperti di dominio durante i processi di Knowledge Crunching.
 
@@ -93,7 +93,7 @@ Esso è stato utilizzato dal team per raccogliere tutta la documentazione di pro
 
 ### Context Mapper
 
-[Context Mapper](https://contextmapper.org/) è un framework di modellazione per il design strategico (e tattico) del Domain Driven Design.
+[Context Mapper](https://contextmapper.org/) è un framework di modellazione per il design strategico (e tattico) del Domain-Driven Design.
 
 Esso è stato utilizzato dal team per la formalizzazione e la descrizione dei sottodomini, dei Bounded Context, della Context Map e dei modelli di dominio.
 
@@ -138,4 +138,3 @@ Esso è stato utilizzato dal team per la creazione dei mockup interattivi delle
 <div align="center">
 <img src="imgs/figma.png" alt="Figma logo" width="15%">
 </div>
-

docs/02-design/index.md

@@ -14,7 +14,7 @@ Dopo aver analizzato in dettaglio i requisiti del sistema ed aver compreso i pro
 
 ## Design architetturale ad alto livello
 
-In <a href="#simpleArchitecture">Figura 1</a>  è possibile notare la suddivisione in layer caratterizzante il sistema in esame. 
+In <a href="#simpleArchitecture">Figura 1</a> è possibile notare la suddivisione in layer caratterizzante il sistema in esame. 
 
 L'obiettivo del nostro design è proporre una soluzione che sia indipendente da specifiche scelte tecnologiche e che si concentri solamente sui paradigmi e sulle tecniche offrendo un maggior grado di astrazione ed un sistema maggiormente estendibile e manutenibile.
 

index.md

@@ -18,7 +18,7 @@ I servizi principali messi a disposizione dal sistema sviluppato sono:
 + **Monitoring e process automation**: il monitoraggio dei processi è parte fondamentale per quanto riguarda un blocco operatorio smart. Esso riguarda il monitoraggio di tutti gli interventi chirurgici, lo spostamento del personale all'interno del blocco e il monitoraggio del paziente in termini di posizione e parametri vitali. Inoltre, il monitoraggio consente di avere i dati a disposizione per poter reagire agli eventi che riguardano il processo, fornendo scenari di automazione che possano migliorare l'esperienza lavorativa del personale e la buona riuscita dell'intervento.
 + **Surgery Report**: tutti gli eventi e i dati raccolti durante il processo chirurgico partecipano alla creazione automatica del verbale operatorio che poi potrà essere integrato con le informazioni inserite dal personale autorizzato. La generazione automatica evita le imprecisioni e gli errori tipici dati dalle compilazioni manuali e permette un tracciamento più accurato delle attività coinvolte durante il processo e delle condizioni in cui esso viene svolto. In aggiunta permette un minor dispendio di tempo per il personale sanitario.
 
-Il progetto è stato portato avanti seguendo l'approccio e le buone pratiche dettate dal Domain Driven Design e utilizzando i principi e le pratiche di DevOps imparate a lezione. 
+Il progetto è stato portato avanti seguendo l'approccio e le buone pratiche dettate dal *Domain-Driven Design* e utilizzando i principi e le pratiche di *DevOps* imparate a lezione. 
 A tal fine, per simulare un contesto reale è stato realizzato un sito di progetto, condiviso con un committente ed esperti di dominio di fantasia che verrà descritto nelle sezioni seguenti.  
 
 ## Componenti