Pedro

README.md

@@ -22,8 +22,7 @@ Both the user and auth service share a Mongo database that is accessed with mong
 The fastest way for launching this sample project is using docker. Just clone the project:
 
 ```sh
-git clone https://github.com/Arquisoft/wiq_es05c.git
-```
+git clone https://github.com/Arquisoft/wiq_es05c.git 
 
 and launch it with docker compose:
 

docs/src/06_runtime_view.adoc

@@ -4,62 +4,41 @@ ifndef::imagesdir[:imagesdir: ../images]
 == Runtime View
 
 
-[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:
+=== Register user
 
-* 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
+image::06-registerSecuencia.png["Register secuence diagram image"] 
 
-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.
+1. The user wants to register in the sistem
+2. The app redirects the register request to the RegisterService
+3. The register service sends to the database the data to get information about it
+4. A response is sent by the database with information about that user in process of registration
+5. The RegisterService validates if the user is correct with that info recieved
+6. If the check was afirmative then the RegisterService registre the user
+7. The RegisterService inform with the result the app
+8. Finally the app carries that result to the user 
 
-.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).
 
-.Form
-There are many notations for describing scenarios, e.g.
+=== Login
 
-* numbered list of steps (in natural language)
-* activity diagrams or flow charts
-* sequence diagrams
-* BPMN or EPCs (event process chains)
-* state machines
-* ...
+image::06-loginSecuencia.png["Login secuence diagram image"] 
 
+1. The user wants to login his account
+2. The app redirects the login request to the LoginService
+3. The LoginService request information about that login data recieved
+4. A response is sent by the database with the requested data
+5. After checking if it's a valid login the LoginService sends a response to the app
+6. Finally the app inform the user about his login process
 
-.Further Information
 
-See https://docs.arc42.org/section-6/[Runtime View] in the arc42 documentation.
+=== Request a question
 
-****
+image::06-nextQuestion.png["NextQuestion secuence diagram image"] 
 
-=== <Runtime Scenario 1>
-
-
-* _<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.>_
-
-It is possible to use a sequence diagram:
-
-[plantuml,"Sequence diagram",png]
-----
-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
-----
-
-=== <Runtime Scenario 2>
-
-=== ...
-
-=== <Runtime Scenario n>
+1. The user asks for a new question
+2. The app redirects that request to the QuestionGenerator
+3. The QuestionGenerator generates a heather for the question
+4. The QuestionGenerator requests the correct answer to WikiData
+5. WikiData sends that answer data
+6. The QuestionGenerator builds the question with the answer and wrong options
+7. The built question is sent to the app
+8. The app shows the question to the User

docs/src/07_deployment_view.adoc

@@ -5,90 +5,12 @@ ifndef::imagesdir[:imagesdir: ../images]
 
 == Deployment View
 
-[role="arc42help"]
-****
-.Content
-The deployment view describes:
 
- 1. technical infrastructure used to execute your system, with infrastructure elements like geographical locations, environments, computers, processors, channels and net topologies as well as other infrastructure elements and
+image::07-diagramaDespliegue.png["Building Block general diagram"] 
 
-2. mapping of (software) building blocks to that infrastructure elements.
-
-Often systems are executed in different environments, e.g. development environment, test environment, production environment. In such cases you should document all relevant environments.
-
-Especially document a deployment view if your software is executed as distributed system with more than one computer, processor, server or container or when you design and construct your own hardware processors and chips.
-
-From a software perspective it is sufficient to capture only those elements of an infrastructure that are needed to show a deployment of your building blocks. Hardware architects can go beyond that and describe an infrastructure to any level of detail they need to capture.
-
-.Motivation
-Software does not run without hardware.
-This underlying infrastructure can and will influence a system and/or some
-cross-cutting concepts. Therefore, there is a need to know the infrastructure.
-
-.Form
-
-Maybe a highest level deployment diagram is already contained in section 3.2. as
-technical context with your own infrastructure as ONE black box. In this section one can
-zoom into this black box using additional deployment diagrams:
-
-* UML offers deployment diagrams to express that view. Use it, probably with nested diagrams,
-when your infrastructure is more complex.
-* When your (hardware) stakeholders prefer other kinds of diagrams rather than a deployment diagram, let them use any kind that is able to show nodes and channels of the infrastructure.
-
-
-.Further Information
-
-See https://docs.arc42.org/section-7/[Deployment View] in the arc42 documentation.
-
-****
-
-=== Infrastructure Level 1
-
-[role="arc42help"]
-****
-Describe (usually in a combination of diagrams, tables, and text):
-
-* distribution of a system to multiple locations, environments, computers, processors, .., as well as physical connections between them
-* important justifications or motivations for this deployment structure
-* quality and/or performance features of this infrastructure
-* mapping of software artifacts to elements of this infrastructure
-
-For multiple environments or alternative deployments please copy and adapt this section of arc42 for all relevant environments.
-****
-
-_**<Overview Diagram>**_
-
-Motivation::
-
-_<explanation in text form>_
-
-Quality and/or Performance Features::
-
-_<explanation in text form>_
-
-Mapping of Building Blocks to Infrastructure::
-_<description of the mapping>_
-
-
-=== Infrastructure Level 2
-
-[role="arc42help"]
-****
-Here you can include the internal structure of (some) infrastructure elements from level 1.
-
-Please copy the structure from level 1 for each selected element.
-****
-
-==== _<Infrastructure Element 1>_
-
-_<diagram + explanation>_
-
-==== _<Infrastructure Element 2>_
-
-_<diagram + explanation>_
-
-...
-
-==== _<Infrastructure Element n>_
-
-_<diagram + explanation>_
+Basically when a user wants to use the application, using his web browser
+he can connect to the application server where the web app will use some
+services also alocated there such as the QuestionGenerator or the LoginManager.
+Also these services make use of the WikiData API and database and also of 
+a database unique for the application to save things as player statistics
+or info of them.

docs/src/11_technical_risks.adoc

@@ -4,22 +4,47 @@ ifndef::imagesdir[:imagesdir: ../images]
 == Risks and Technical Debts
 
 
-[role="arc42help"]
-****
-.Contents
-A list of identified technical risks or technical debts, ordered by priority
+=== Risks
 
-.Motivation
-“Risk management is project management for grown-ups” (Tim Lister, Atlantic Systems Guild.) 
+[options="header" frame=all]
+|===
+|Risk |More detail |How to fight it  
 
-This should be your motto for systematic detection and evaluation of risks and technical debts in the architecture, which will be needed by management stakeholders (e.g. project managers, product owners) as part of the overall risk analysis and measurement planning.
+|A member quit the project
+|It's possible that due to reasons like having a lot of pressure or being overwhelmed by the project members of the group quit the project or the subject
+|Try to communicate with each other and having a sensible rhythm advancing with the project. Also helping each other when we can
 
-.Form
-List of risks and/or technical debts, probably including suggested measures to minimize, mitigate or avoid risks or reduce technical debts.
+|First time delivering a full stack app
+|We could have a lack of experience with a project as big as this that have a bit of every field.
+|Searching and learning the new things we could need during the project and talking with the other members if we know more of a determined field trying to help them
 
+|Lack of time 
+|We can have some though weeks because we have other subjects to study and other projects and exams that can consumpt our time 
+|Attemp to be responsible with our time and tasks and try to organize ourselves as good as we can
 
-.Further Information
+|New technologies
+|Some technologies that we will use in the projects are new for us such as React or managing a database due to our lack of experience
+|Learning the new things that we don't know and not being unwilling to confront new things such as technologies or languages that are new for us or near to new
 
-See https://docs.arc42.org/section-11/[Risks and Technical Debt] in the arc42 documentation.
+|Not arriving deadlines
+|It can happen that we don't archieve what it's requested into the project in time and end up sending an uncompleted final product or during the middle deadlines 
+|To avoid this we have to keep a good rhythm advancing and planing good and adequated tasks in the weekly meetings done in the labs so we don't run out of time not done
+|===
 
-****
+=== Technical Debt
+
+TO-DO 
+
+[options="header" frame=all]
+|===
+|Technical Debt |Description 
+
+|Space 1.1
+|Space 1.2
+
+|Space 2.1
+|Space 2.2
+
+|Space 3.1
+|Space 3.2
+|===