📝 Update documentation to end Sprint4

it.unibo.sembrava_qualcuno.sprint1/userDocs/BongiovanniDeCola_Sprint1.html

@@ -459,7 +459,7 @@ <h2 id="tests">Testing</h2>
 				</ul>
 				These conditions were individually changed by the single tests if they needed some other context, as described below.<br>
 				We decided to implement the tests relative to this sprint under two test classes: one that holds tests concerning the WeightSensor, the ClientService and the SpringController (<a href="../test/it/unibo/sembrava_qualcuno/sprint1/test/Sprint1ParkingAreaTests.kt">Sprint1ParkingAreaTests.kt</a>)
-				and one that holds tests concerning the Trolley, BasicRobot, ClientService and the SpringController (<a href="../test/it/unibo/sembrava_qualcuno/sprint1/test/Sprint1TrolleyTests.kt">Sprint1TrolleyTests.kt</a>), in order to fire tests without having to start up every qak context if not needed for the current test.
+				and one that holds tests concerning the Trolley, BasicRobot, ClientService and the SpringController (<a href="../test/it/unibo/sembrava_qualcuno/sprint1/test/Sprint1TrolleyTests.kt">Sprint1TrolleyTests.kt</a>).
 				<br>Hereafter is a description of the functional tests for this <a href="#sprint1"> sprint requirements</a>:
 			<ul>
 				<li>Test if there are no parking slots available, a proper response is returned by the SpringController (e.g. {slotnum:0}), as per <k>F3</k></li>

it.unibo.sembrava_qualcuno.sprint2/userDocs/BongiovanniDeCola_Sprint2.html

@@ -375,7 +375,7 @@ <h4>The SonarController and SonarMock</h4>
 						</td></tr>
 					</table>
 
-			<h2>Testing</h2>
+			<h2 id="tests">Testing</h2>
 			To exploit the qak CoAP observable resources for testing purposes, as already done during the <a href="../../it.unibo.sembrava_qualcuno.tf21Start/userDocs/BongiovanniDeCola_tf21Start.html#tests">first test plans</a> of the analysis phase<br> and the <a href="../../it.unibo.sembrava_qualcuno.sprint1/userDocs/BongiovanniDeCola_Sprint1.html#tests">tests of the sprint1</a>, the <a href="../test/it/unibo/sembrava_qualcuno/sprint2/test/CoapObserverForTesting.kt">CoapObserverForTesting.kt</a> has been reintroduced in this sprint tests.
 			For all the tests we assumed these starting conditions:
 				<ul>
@@ -386,7 +386,7 @@ <h2>Testing</h2>
 				</ul>
 				These conditions were individually changed by the single tests if they needed some other context, as described below.<br>
 				We decided to implement the tests relative to this sprint under three test classes: one that holds tests concerning the SonarController and mock, the ClientService and the SpringController (<a href="../test/it/unibo/sembrava_qualcuno/sprint2/test/Sprint2ParkingAreaTests.kt">Sprint1ParkingAreaTests.kt</a>),
-				one that holds tests concerning the Trolley, BasicRobot, ClientService and the SpringController (<a href="../test/it/unibo/sembrava_qualcuno/sprint2/test/Sprint2TrolleyTests.kt">Sprint1TrolleyTests.kt</a>) and one for the SonarController/Mock unit tests (<a href="../test/it/unibo/sembrava_qualcuno/sprint2/test/SonarTests.kt">SonarTests.kt</a>), in order to fire tests without having to start up every qak context if not needed for the current test.
+				one that holds tests concerning the Trolley, BasicRobot, ClientService and the SpringController (<a href="../test/it/unibo/sembrava_qualcuno/sprint2/test/Sprint2TrolleyTests.kt">Sprint1TrolleyTests.kt</a>) and one for the SonarController/Mock unit tests (<a href="../test/it/unibo/sembrava_qualcuno/sprint2/test/SonarTests.kt">SonarTests.kt</a>).
 				<br>Hereafter is a description of the functional tests for this <a href="#sprint2"> sprint requirements</a>:
 			<ul>
 				<li>Test that, if there is at least one parked car, the trolley is not stopped and the OUTDOOR area is not engaged (<k>F6</k>), a reqexit client request is accepted by the ClientService, as per <k>F2</k>-<k>NF5</k>. If not, the SpringController should return a <tt>403 forbidden http error code</tt></li>

it.unibo.sembrava_qualcuno.sprint3/userDocs/BongiovanniDeCola_Sprint3.html

@@ -299,6 +299,7 @@ <h2>Project</h2>
 				the components we require for this sprint: SpringController/View, ClientService. Furthermore, we want to specify that all what we developed in Sprint2 stand also for this sprint and only changes and updates to it are hereby presented. 
 
 				<h3>SpringIndoorView</h3>
+					We used <a href="https://getbootstrap.com/">bootrastrap</a> to develop all the view in the project.
 					<table>
 						<tr><td>
 							<h4>Client home page</h4>
@@ -352,13 +353,15 @@ <h4>Client correct tokenid</h4>
 							<center><img src="./img/ClientReqexit.png" width="70%"></center>
 						</td></tr>
 					</table></center>
-
+				<div class="remark">
+					<lr>F1</lr>, <lr>F4</lr> and <lr>F7</lr> are now met.
+				</div>
 				<h3>SpringController</h3>
 					<table style="width:98%">
 						<tbody>
 						<tr><td style="width:60%">
 							<h4>Using RESTful APIs for the M2M interaction (cont.d) and JS for H2M interaction</h4>
-							As already known, the M2M interaction has been developed using RESTful APIs (<a href=" ../../it.unibo.sembrava_qualcuno.sprint1/userDocs/REST-APIdocs.html">API docs</a>).
+							As already known, the M2M interaction has been developed using RESTful APIs (<a href="../../it.unibo.sembrava_qualcuno.sprint1/userDocs/swagger-ui/REST-APIdocs.html">API docs</a>).
 							These are managed by the already known <a href="../parkmanagerservice/src/main/kotlin/controller/SpringController.kt">SpringController</a>; the H2M interaction, however, is orchestrated by
 							a client-side <a href="../parkmanagerservice/src/main/resources/static/app.js">app.js</a> file and a <a href="../parkmanagerservice/src/main/kotlin/controller/BaseController.kt">BaseController</a>: the BaseController
 							accepts <tt>/client</tt> or <tt>/clientOut</tt> request to return to the home pages while the app.js changes the DOM elements of the page according to the responses of the SpringController (e.g. changes
@@ -454,17 +457,17 @@ <h4>The ClientService as a Moore's Finite State Machine (cont.d)</h4>
 			<h2>Deployment</h2>
 				To end this sprint we thought to deploy what has been completed, as all the client business logic has been developed. We decided to divide our system in 5 nodes:
 				<ul>
-					<li>The <em>indoorarea</em> node: holds the WeightSensorMock and Interface and its configuration files</li>
-					<li>The </em>outdoorarea</em> node: holds the SonarMock and Interface and its configuration files</li>
-					<li>The </em>parkmanagerservice</em> node: holds two artifacts:
+					<li>The <em>indoorarea</em> node: holds the WeightSensorMock and its configuration files</li>
+					<li>The <em>outdoorarea</em> node: holds the SonarMock and its configuration files</li>
+					<li>The <em>parkmanagerservice</em> node: holds two artifacts:
 						<ul>
-							<li><em>parkmanagerservice-1.0.tar</em>: contains the ClientService, Trolley, WeightSensor/Sonar Interface and SonarController and its configuration files. Also contains the prolog knowledge base for the qak infrastructure</li>
-							<li><em>parkmanagerservice-boot-1.0.tar</em>: contains the SpringBoot components: BaseController, SpringController and the SpringModel (e.g. ParkingSlot.kt, ApiError.kt, etc...)</li>
+							<li><tt>parkmanagerservice-1.0.tar</tt>: contains the ClientService, Trolley, WeightSensor/Sonar Interface and SonarController and its configuration files. Also contains the prolog knowledge base for the qak infrastructure</li>
+							<li><tt>parkmanagerservice-boot-1.0.tar</tt>: contains the SpringBoot components: BaseController, SpringController and the SpringModel (e.g. ParkingSlot.kt, ApiError.kt, etc...)</li>
 						</ul>
 						Depends on the indoorarea, outdoorarea and basicrobot.
 					</li>
-					<li>The </em>basicrobot</em> node: holds the BasicRobot; depends on wenv</li>
-					<li>The </em>wenv</em> node: holds the WEnv and the virtual robot</li>
+					<li>The <em>basicrobot</em> node: holds the BasicRobot; depends on wenv</li>
+					<li>The <em>wenv</em> node: holds the WEnv and the virtual robot</li>
 				</ul>
 				See the image below for a deployment diagram:<br>
 				<center><img id="Deployment" src="./img/Sprint3Deployment.png" width="70%"></center>
@@ -473,7 +476,7 @@ <h2>Deployment</h2>
 				<h3>indoorarea Dockerfile</h3>
 					We provide a <a href="../indoorarea/Dockerfile">Dockerfile</a> to build and run a Docker image for the indoor area.<br>
 
-<pre><tt># To build (in the indoorarea/ folder):</tt>
+<pre id="dockerDepl"><tt># To build (in the indoorarea/ folder):</tt>
 docker build --rm -t indoorarea .
 <tt># To run:</tt>
 docker run -rm -i -p8025:8025 indoorarea 
@@ -496,7 +499,7 @@ <h3>parkmanagerservice image creation</h3>
 				<h3>Deployment using Docker</h3>
 					We also provide a <a href="../automatedcarparking.yaml">script</a> to automatically deploy the system using one container per node, as described above.<br>
 					Use it invoking 
-<pre>docker-compose -f automatedcarparking.yaml</pre>
+<pre id="compose">docker-compose -f automatedcarparking.yaml</pre>
 			<h2>Sprint Summary</h2>
 
 			The coming figure represents the final outline resulting from the Sprint3. The dashed lines that group components together gives a glance of the physical deployment organization<br> 			<div>