From 44b19baeb5137f8d2027bbbb9e5bb42a36e65134 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Gonzalo=20Su=C3=A1rez=20Losada?=
 <113936619+uo283928@users.noreply.github.com>
Date: Sun, 18 Feb 2024 12:37:43 +0100
Subject: [PATCH] chore: Update 06_runtime_view.adoc

---
 docs/src/06_runtime_view.adoc | 111 ++++++++++++++++++++++------------
 1 file changed, 71 insertions(+), 40 deletions(-)

diff --git a/docs/src/06_runtime_view.adoc b/docs/src/06_runtime_view.adoc
index e10f375b..44dc3513 100644
--- a/docs/src/06_runtime_view.adoc
+++ b/docs/src/06_runtime_view.adoc
@@ -2,64 +2,95 @@ ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-runtime-view]]
 == Runtime View
+Here we can see what the main workflow of main parts of the project.
 
+=== General Game's life cycle
+* This diagram shows how should the application behave for an expected normal case scenario.
 
-[role="arc42help"]
-****
-.Contents
-The runtime view describes concrete behavior and interactions of the system’s building blocks in form of scenarios from the following areas:
+[plantuml,"Game's life cycle diagram",png]
+----
+@startuml Game's life cycle
+
+actor Client
+
+skinparam Style strictuml
+skinparam SequenceMessageAlignment center
 
-* important use cases or features: how do building blocks execute them?
-* interactions at critical external interfaces: how do building blocks cooperate with users and neighboring systems?
-* operation and administration: launch, start-up, stop
-* error and exception scenarios
+Client --> API : start game
+loop One question
+  API --> QuestionRetriever         : ask for question
+  QuestionRetriever --> QuestionDB  : querying question
 
-Remark: The main criterion for the choice of possible scenarios (sequences, workflows) is their *architectural relevance*. It is *not* important to describe a large number of scenarios. You should rather document a representative selection.
+  QuestionDB --> QuestionRetriever  : return first question and all answers
+  QuestionRetriever --> API         : return first question and all answers
 
-.Motivation
-You should understand how (instances of) building blocks of your system perform their job and communicate at runtime.
-You will mainly capture scenarios in your documentation to communicate your architecture to stakeholders that are less willing or able to read and understand the static models (building block view, deployment view).
+  API --> Client : return first question and all answers
+  Client -> API  : send chosen answer
+  API --> API    : check answer is correct
+  API --> Client : inform user guessed right
+end loop One question
 
-.Form
-There are many notations for describing scenarios, e.g.
 
-* numbered list of steps (in natural language)
-* activity diagrams or flow charts
-* sequence diagrams
-* BPMN or EPCs (event process chains)
-* state machines
-* ...
+API --> Client : inform user guessed right last question
+API --> API    : update ranking
+API --> Client : show ranking
 
+@enduml
+----
+
+=== Sign Up
+[plantuml,"Sign up diagram",png]
+----
+@startuml sign up
 
-.Further Information
+actor Client
 
-See https://docs.arc42.org/section-6/[Runtime View] in the arc42 documentation.
+skinparam Style strictuml
+skinparam SequenceMessageAlignment center
 
-****
+Client --> API : enters credentials
+API --> BD     : check credentials unused
+API --> BD     : register user
+BD --> Client  : return user token
 
-=== <Runtime Scenario 1>
+@enduml
+----
 
+=== Login
+[plantuml,"Login diagram",png]
+----
+@startuml login
 
-* _<insert runtime diagram or textual description of the scenario>_
-* _<insert description of the notable aspects of the interactions between the
-building block instances depicted in this diagram.>_
+actor Client
+skinparam Style strictuml
+skinparam SequenceMessageAlignment center
 
-It is possible to use a sequence diagram:
+Client --> API : enters credentials
+API --> BD     : check credentials correct
+BD --> API     : return user token
+API --> BD     : save SWT
+API --> Client : return user token
 
-[plantuml,"Sequence diagram",png]
+@enduml
 ----
-actor Alice
-actor Bob
-database Pod as "Bob's Pod"
-Alice -> Bob: Authentication Request
-Bob --> Alice: Authentication Response
-Alice  --> Pod: Store route
-Alice -> Bob: Another authentication Request
-Alice <-- Bob: another authentication Response
+
+=== Question Generation
+[plantuml,"Question generation diagram",png]
 ----
+@startuml question generator
+skinparam Style strictuml
+skinparam SequenceMessageAlignment center
 
-=== <Runtime Scenario 2>
+QuestionGenerator --> WikiDataQS  : querying correct answer
+QuestionGenerator <-- WikiDataQS  : return correct answer
 
-=== ...
+QuestionGenerator --> WikiDataQS  : querying wrong answers
+QuestionGenerator <-- WikiDataQS  : return wrong answers
+
+QuestionGenerator --> QuestionDB  : store question
+QuestionGenerator --> QuestionDB  : store correct answer
+QuestionGenerator --> QuestionDB  : store wrong answers
+
+@enduml
+----
 
-=== <Runtime Scenario n>