merge with dev

docs/src/01_introduction_and_goals.adoc

@@ -3,91 +3,65 @@ ifndef::imagesdir[:imagesdir: ../images]
 [[section-introduction-and-goals]]
 == Introduction and Goals
 
-[role="arc42help"]
-****
-Describes the relevant requirements and the driving forces that software architects and development team must consider. 
-These include
-
-* underlying business goals, 
-* essential features, 
-* essential functional requirements, 
-* quality goals for the architecture and
-* relevant stakeholders and their expectations
-****
+The project is a quizz game based on the Spanish TV show "Saber y ganar", the users will be able to test their knowledge with questions from different categories and difficulties. Users will autenticate themselves into the system or create an account first.
 
 === Requirements Overview
 
-[role="arc42help"]
-****
-.Contents
-Short description of the functional requirements, driving forces, extract (or abstract)
-of requirements. Link to (hopefully existing) requirements documents
-(with version number and information where to find it).
 
-.Motivation
-From the point of view of the end users a system is created or modified to
-improve support of a business activity and/or improve the quality.
 
-.Form
-Short textual description, probably in tabular use-case format.
-If requirements documents exist this overview should refer to these documents.
 
-Keep these excerpts as short as possible. Balance readability of this document with potential redundancy w.r.t to requirements documents.
+* Users will be able to create an account and log in
+* Each question must have a prize associated to it
+* Accesible through the web
+* Historical data of a user will be saved on that user's account
+* Questions have a time limit to be answered
+* Possible answer will be given to the user, only one of them being correct
+* Information about users and questions will be obtained through API's
+* Modo multijugador y modo individual
+* Se habilitarán salas de juego en tiempo real para el modo multijugador
 
 
-.Further Information
 
-See https://docs.arc42.org/section-1/[Introduction and Goals] in the arc42 documentation.
 
-****
 
 === Quality Goals
 
-[role="arc42help"]
-****
-.Contents
-The top three (max five) quality goals for the architecture whose fulfillment is of highest importance to the major stakeholders. 
-We really mean quality goals for the architecture. Don't confuse them with project goals.
-They are not necessarily identical.
 
-Consider this overview of potential topics (based upon the ISO 25010 standard):
+
+
+//This table is just a placeholder, replace it with real quality goals once discussed !!!
+
+
 
 image::01_2_iso-25010-topics-EN.drawio.png["Categories of Quality Requirements"]
 
-.Motivation
-You should know the quality goals of your most important stakeholders, since they will influence fundamental architectural decisions. 
-Make sure to be very concrete about these qualities, avoid buzzwords.
-If you as an architect do not know how the quality of your work will be judged...
+(based upon the ISO 25010 standard):
+[options="header",cols="1,2,2"]
+|===
+|Code|Quality Goal|Scenario
+|QG1|Usability|The user can easily navigate through the app and find the information they need
+|QG2|Performance|The app should be able to handle a large amount of users at the same time
+|QG3|Security|The user's data should be protected and not accesible by anyone else
+|===
 
-.Form
-A table with quality goals and concrete scenarios, ordered by priorities
-****
 
-=== Stakeholders
 
-[role="arc42help"]
-****
-.Contents
-Explicit overview of stakeholders of the system, i.e. all person, roles or organizations that
 
-* should know the architecture
-* have to be convinced of the architecture
-* have to work with the architecture or with code
-* need the documentation of the architecture for their work
-* have to come up with decisions about the system or its development
 
-.Motivation
-You should know all parties involved in development of the system or affected by the system.
-Otherwise, you may get nasty surprises later in the development process.
-These stakeholders determine the extent and the level of detail of your work and its results.
+=== Stakeholders
 
-.Form
-Table with role names, person names, and their expectations with respect to the architecture and its documentation.
-****
 
-[options="header",cols="1,2,2"]
+
+[options="header"]
 |===
 |Role/Name|Contact|Expectations
-| _<Role-1>_ | _<Contact-1>_ | _<Expectation-1>_
-| _<Role-2>_ | _<Contact-2>_ | _<Expectation-2>_
+| _Wikidata_ | _Wikidata.org_ | _Public exposure by the use of their services deriving in a greater demand of said services_
+| _Uniovi's Software Architecture Teacher council_ | [email protected]_ | _Provide their students (development team) with a practical experience about the use of Software architecture in projects and making sure the have understood the concepts of it_
+|_Development Team_||_Acquire experience in the development process of Software Architecture and pass the subject to complete their studies_
+|_Users_|_Anyone who uses the app_|_Test their knowledge on a functional and easy to use quizz game app_
 |===
+
+
+
+=== End
+

docs/src/02_architecture_constraints.adoc

@@ -3,25 +3,43 @@ ifndef::imagesdir[:imagesdir: ../images]
 [[section-architecture-constraints]]
 == Architecture Constraints
 
+When designing the WIQ Application there are several constraints that must be taken into consideration, as they will have a large impact on the final application. These requirements that we must follow, will ensure that the final product meets the needs and expectations of final users and stakeholders.
+The following table summarizes these constraints and provides a brief explanation of each.
 
-[role="arc42help"]
-****
-.Contents
-Any requirement that constraints software architects in their freedom of design and implementation decisions or decision about the development process. These constraints sometimes go beyond individual systems and are valid for whole organizations and companies.
+[options="header", cols="1,1"]
 
-.Motivation
-Architects should know exactly where they are free in their design decisions and where they must adhere to constraints.
-Constraints must always be dealt with; they may be negotiable, though.
+|===
+| Constraint | Explanation
+| Use of Wikidata | Wikidata is a collaborative, multilingual knowledge base that provides the required information to popular websites as Wikipedia. Wikidata houses information about a wide range of entities, such as people, places, and concepts, using a linked and interconnected data model. The project will have to generate questions and responses to those questions automatically, and for this task, Wikidata can be very useful.
 
-.Form
-Simple tables of constraints with explanations.
-If needed you can subdivide them into
-technical constraints, organizational and political constraints and
-conventions (e.g. programming or versioning guidelines, documentation or naming conventions)
+| Version control and monitoring (GitHub) | GitHub and Git will be very valuable for the application, facilitating version control and team collaboration during project development. It enables the coordination and management of the development workflow, while also monitoring the modifications and contributions made by individual team members.
 
+| User Experience | The design of the application must make its use friendly and easy.
 
-.Further Information
+| Deployment | The application must be deployed.
 
-See https://docs.arc42.org/section-2/[Architecture Constraints] in the arc42 documentation.
+|===
+
+
+=== Recommended technologies to take into account
+
+The application must be a full stack application consisting of a web app and a server. These are some technologies mentioned to provide a clear understanding of this application and how it works. These are not considered constraints because they were not imposed, but they should be present in this section due to the impact they have on the project.
+
+[options="header", cols="1,1"]
+
+|===
+| Technology | Explanation
+| React | Description: React is a JavaScript library for building user interfaces with a component-based architecture. It promotes a declarative approach and utilizes a virtual DOM for efficient UI updates.
+
+Fit for the application: React's component-based structure is ideal for creating reusable UI elements, aligning well with the modular nature of a trivia app. The virtual DOM enhances performance in real-time scenarios.
+
+| ExpressJS | Description: Express is a fast and minimalist web framework for Node.js, simplifying the creation of robust web applications and APIs. It follows a middleware pattern, making it versatile for handling various server-side tasks.
+
+Fit for the application: Express's middleware architecture is well-suited for managing authentication, routing, and server-side concerns. Its lightweight nature and scalability support simultaneous user interactions in a multiplayer trivia game.
+
+| MongoDB | Description: MongoDB is a NoSQL document database storing data in flexible, JSON-like documents. It offers schema flexibility, making it suitable for applications with evolving data structures, and supports scalability and high performance.
+
+Fit for the application: MongoDB's schema-less design allows easy adaptation to different question formats in a trivia app. Its scalability and sharding capabilities make it apt for handling large data volumes and concurrent user interactions.
+
+|===
 
-****

docs/src/03_system_scope_and_context.adoc

@@ -4,72 +4,45 @@ ifndef::imagesdir[:imagesdir: ../images]
 == System Scope and Context
 
 
-[role="arc42help"]
-****
-.Contents
-System scope and context - as the name suggests - delimits your system (i.e. your scope) from all its communication partners
-(neighboring systems and users, i.e. the context of your system). It thereby specifies the external interfaces.
-
-If necessary, differentiate the business context (domain specific inputs and outputs) from the technical context (channels, protocols, hardware).
-
-.Motivation
-The domain interfaces and technical interfaces to communication partners are among your system's most critical aspects. Make sure that you completely understand them.
+=== Business Context
 
-.Form
-Various options:
 
-* Context diagrams
-* Lists of communication partners and their interfaces.
 
 
-.Further Information
+image::businessContext.png[Bussiness Context, 600, 400]
 
-See https://docs.arc42.org/section-3/[Context and Scope] in the arc42 documentation.
 
-****
+.Explanation of the Diagram
 
+The diagram shows the main 4 services the user interacts with.
 
-=== Business Context
+Login and validation of answers are handled by external services, such as *Google* and *WikiData*.
 
-[role="arc42help"]
-****
-.Contents
-Specification of *all* communication partners (users, IT-systems, ...) with explanations of domain specific inputs and outputs or interfaces.
-Optionally you can add domain specific formats or communication protocols.
-
-.Motivation
-All stakeholders should understand which data are exchanged with the environment of the system.
+=== Technical Context
+The application structure is the following:
 
-.Form
-All kinds of diagrams that show the system as a black box and specify the domain interfaces to communication partners.
+image::technicalDiagram.png[Technical Diagram, 600, 400]
 
-Alternatively (or additionally) you can use a table.
-The title of the table is the name of your system, the three columns contain the name of the communication partner, the inputs, and the outputs.
+.Explanation of the Diagram
 
-****
 
-**<Diagram or Table>**
+The application will be deployed on an Azure Server. It will consist of the following:
 
-**<optionally: Explanation of external domain interfaces>**
+The client communicates with the web app, the front-end of the application. Developed with *React* and *JavaScript*, this application retrieves information from the server, interacting with the *Gateway*.
 
-=== Technical Context
+We employ a facade pattern on the server, with a dedicated *Gateway service* redirecting requests to different internal services.
 
-[role="arc42help"]
-****
-.Contents
-Technical interfaces (channels and transmission media) linking your system to its environment. In addition a mapping of domain specific input/output to the channels, i.e. an explanation which I/O uses which channel.
+The services include:
 
-.Motivation
-Many stakeholders make architectural decision based on the technical interfaces between the system and its context. Especially infrastructure or hardware designers decide these technical interfaces.
+- *Authentication Service*
+- *Users Service*
+- *Question Generator Service*
+- *Game Service*
+- *Groups Service*
 
-.Form
-E.g. UML deployment diagram describing channels to neighboring systems,
-together with a mapping table showing the relationships between channels and input/output.
+All these services interact with the *MongoDB* database, retrieving and adding information.
 
-****
+To generate questions automatically, communication with the *WikiData API* is necessary. The *Question Generator Service* houses an algorithm for question generation.
 
-**<Diagram or Table>**
 
-**<optionally: Explanation of technical interfaces>**
 
-**<Mapping Input/Output to Channels>**

docs/src/04_solution_strategy.adoc

@@ -2,31 +2,20 @@ ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-solution-strategy]]
 == Solution Strategy
-
-
-[role="arc42help"]
-****
-.Contents
-A short summary and explanation of the fundamental decisions and solution strategies, that shape system architecture. It includes
-
-* technology decisions
-* decisions about the top-level decomposition of the system, e.g. usage of an architectural pattern or design pattern
-* decisions on how to achieve key quality goals
-* relevant organizational decisions, e.g. selecting a development process or delegating certain tasks to third parties.
-
-.Motivation
-These decisions form the cornerstones for your architecture. They are the foundation for many other detailed decisions or implementation rules.
-
-.Form
-Keep the explanations of such key decisions short.
-
-Motivate what was decided and why it was decided that way,
-based upon problem statement, quality goals and key constraints.
-Refer to details in the following sections.
-
-
-.Further Information
-
-See https://docs.arc42.org/section-4/[Solution Strategy] in the arc42 documentation.
-
-****
+This section aims to describe the strategies decided by the team.
+
+=== Technologies
+The following list names the technologies selected:
+
+- *Arc42:* this is a template for documentation and communication of software and system architectures
+- *TypeScript:* free and open-source high-level programming languaage deriving from JavaScript. The former provides tools that JavaScript does not. It will be used to program the client part of the application.
+- *React:* free and open-source front-end JavaScript library for building user interfaces based in components. It allows building complex interfaces in a simpler way, being flexible and easy to maintain.
+- *Docker:* set of platform as a service products that use OS-level virtualization to deliver software in packages called containers. It will be used to deploy the application.
+- *MongoDB:* non-relational document database that provides support for JSON-like storage. It has drivers for major programming languages and development environments.
+- *NodeJS:* cross-platform, opens-source JavaScript library for the server layer that provides the tools to implement the application. It has a large and active community that may be usefull in difficult times.
+- *ExpressJS:* nodejs web application framework that provides a robust set of features for web and mobile applications.
+- *Wikidata:* collaboratively edited multilingual knowledge graph. It's a common source of open data that anyone can use. It also can be read and edited by both humans and machines.
+
+=== Organizational
+- *Weekly meetings:* to maintain a well communicated team so all are aware of the decissions and team progress.
+- *Github:* use of issues, pull request, discussions and other tools that Github offers.