Merge pull request #42 from Arquisoft/chore/gonzaSuarez/docs

Chore/gonza suarez/docs

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>

docs/src/08_concepts.adoc

@@ -56,3 +56,16 @@ We decided to use a React based frontend with BootSpring for the backend, which
 
 .User Experience
 As this is a game, the focus must be in user experience so players can have an enjoyable experience, for achieving this, the response time should be as low as possible and the interfaces should be intuitive and beautiful.
+
+.Safety and Security concepts:
+Authentication is done in SpringBoot3. Passwords must be hashed both in client and in API to ensure as much security as possible.
+
+.Robustness:
+It is desired to make the application as independant as possible from Wikidata. This way, if it is down our application can still manage to be available for our users.
+In order to archieve this, we will implement two modules regarding questions, one for retrieving it from Wikidata and storing it in our own DB and another for getting questions from it.
+
+.Development concepts:
+Our code will be deployed within an Azure's Virtual Machine using continuous integration. 
+
+.Under-the-hood:
+Regarding Data persistence, our project has two DB, one for storing questions as stated before while the other one will be in charge of storing any other meaningful data for the game such us users or game's histories.