Merge pull request #77 from Arquisoft/Doc06

Doc06

docs/index.adoc

@@ -5,7 +5,7 @@
 
 // configure EN settings for asciidoc
 include::src/config.adoc[]
-
+[.text-justify]
 = image:arc42-logo.png[arc42] Template
 :revnumber: 8.2 EN
 :revdate: January 2023

docs/src/06_runtime_view.adoc

@@ -39,7 +39,7 @@ See https://docs.arc42.org/section-6/[Runtime View] in the arc42 documentation.
 
 === Login scenario
 
-When the user wants to login into the application (KaW), the user navigates to the login page. The Frontend will show a form that allows the user to enter their details (username and password), which are then sent to the backend in order to be verified if they are correct or not. Then, the Backend asks the Database for the password given the username. The Database will return an encrypted password. The Backend will encrypt the password provided by the user and then compare it with the one from the database. If the passwords do not match, an error message showing "Incorrect credentials" will appear to the user and if they are correct, a success message "Login successful" confirms the login and the user finally will be able to access the application.
+When the user wants to login into the application (KaW), the user navigates to the login page. The WebApp will show a form that allows the user to enter their details (username and password), which are then sent to the User Service by means of the Gateway in order to be verified. Then, the User Service asks the Database for the password given the username. The Database will return an encrypted password. The User Service will encrypt the password provided by the user and then compare it with the one from the database. If the passwords do not match, an error message showing "Invalid credentials" will appear to the user, and if they are correct, a success message "Login successful" confirms the login and the user finally will be able to access the application.
 
 This case scenario is also represented on the following diagram:
 
@@ -48,33 +48,36 @@ This case scenario is also represented on the following diagram:
 sequenceDiagram
     actor User as User
     
-    User->>Frontend: Enters details (username, password)
-    Frontend->>Backend: Sends user details
-    Backend->>Database: Asks for encrypted password by username
-    Database-->>Backend: Responds with the encrypted password of the user
-    Backend-->Backend: Tests if passwords are equal after encryptation
+    User->>WebApp: Enters details (username, password)
+    WebApp->>Gateway: Sends user details
+    Gateway->>User Service: Sends user details
+    User Service->>Database: Asks for encrypted password by username
+    Database-->>User Service: Responds with the encrypted password of the user
+    User Service-->User Service: Tests if passwords are equal after encryption
     alt Credentials are incorrect
-        Backend-->>Frontend: Sends error message "Incorrect credentials"
-        Frontend-->>User: Displays error message "Incorrect credentials"
+        User Service-->>Gateway: Sends error message "Invalid credentials"
+        Gateway-->>WebApp: Sends error message "Invalid credentials"
+        WebApp-->>User: Displays error message "Invalid  credentials"
     else Credentials are correct
-        Backend-->>Frontend: Sends success message "Login successful"
-        Frontend-->>User: Displays success message "Login successful"
+        User Service-->>Gateway: Sends success message "Login successful"
+        Gateway-->>WebApp: Sends success message "Login successful"
+        WebApp-->>User: Displays success message "Login successful"
     end
 ....
 
 
 === Question Generation
 
-When a user starts a game through the Frontend, it triggers a request for generating questions to the Backend. The Backend (Gateway) works with the QS (Question Service) to generate questions. For each question, first QS requests a question template from the Database, which is then filled with relevant data from the WQS (Wikidata Query Service). After filling the template, QS asks WQS for answers and distractors. Once all questions are generated, QS sends them back to the Backend, so again the response then can be redirected towards the Frontend. Finally, the Frontend displays the questions of the game.
+When a user starts a game through the WebApp, it triggers a request for generating questions to the Gateway. The Gateway works with the QS (Question Service) to generate questions. For each question, first QS requests a question template from the Database, which is then filled with relevant data from the WQS (Wikidata Query Service). After filling the template, QS uses the previous data, obtained from WQS, to also generate answers and distractors. Once all questions are generated, QS sends them back to the Gateway, so again the response can then be redirected towards the WebApp. Finally, the WebApp displays the questions of the game.
 
 This case scenario is also represented on the following diagram:
 
 [mermaid]
 ....
  sequenceDiagram
     actor U as User
-    participant FE as Frontend 
-    participant BE as Backend 
+    participant FE as WebApp 
+    participant BE as Gateway 
     participant QGS as Question Service
     participant WQS as Wikidata Query Service 
     participant DB as Database 
@@ -89,8 +92,7 @@ This case scenario is also represented on the following diagram:
         QGS->>WQS: Request Data
         WQS-->>QGS: Return Data
         QGS-->QGS: Fill Template
-        QGS->>WQS: Request Answer + Distractors
-        WQS-->>QGS: Return Answer + Distractors
+        QGS-->QGS: Generate Answer + Distractors
         QGS-->QGS: Create Question
     end 
     QGS-->>BE: Return Questions
@@ -100,16 +102,16 @@ This case scenario is also represented on the following diagram:
 
 === User statistics recording scenario
 
-When a user answers a question, the Frontend determines if the answer was correct or not. Then, that data is sent to the Backend and then forwarded to the User Service, which is in charge of updating the Database with the updated user history. This process is repeated for each answer to a question.
+When a user answers a question, the WebApp determines if the answer was correct or not. Then, that data is sent to the Gateway and then forwarded to the User Service, which is in charge of updating the Database with the updated user history. This process is repeated for each answer to a question.
 
 This case scenario is also represented on the following diagram:
 
 [mermaid]
 ....
  sequenceDiagram
     actor U as User
-    participant FE as Frontend 
-    participant BE as Backend 
+    participant FE as WebApp 
+    participant BE as Gateway 
     participant HS as User Service
     participant DB as Database