diff --git a/index.html b/index.html index 6cece284..8bebd9de 100644 --- a/index.html +++ b/index.html @@ -444,7 +444,69 @@

arc42 T
Table of Contents
@@ -501,20 +563,8 @@

arc42 T

1. Introduction and Goals

-

<<<<<<< HEAD

-
-
-
-
-

Describes the relevant requirements and the driving forces that software architects and development team must consider. -These include

-
-
-
-

WIQ! is a project developed for the subject "Software Architecture" of the Computer Engineering degree of the School of Computer Engineering of the University of Oviedo. This project is based on the wiq project, made available to the students by the teachers of the subject. -WIQ! has been commissioned to the company HappySw by RTVE, with the aim of recreating its famous quiz show Saber y ganar in a web version accessible to everyone. This project will be carried out by the development team is formed by: ->>>>>>> bc38116a46fe4d35d847382a96c27343738d4cd4

+WIQ! has been commissioned to the company HappySw by RTVE, with the aim of recreating its famous quiz show Saber y ganar in a web version accessible to everyone. This project will be carried out by the development team is formed by:

    @@ -552,9 +602,8 @@

    1. Introduction and Goals

-
-

=== Requirements Overview

-
+
+

1.1. Requirements Overview

  • @@ -580,9 +629,9 @@

    1. Introduction and Goals

-
-

=== Quality Goals

+
+

1.2. Quality Goals

@@ -614,198 +663,172 @@

1. Introduction and Goals

-
-

=== Stakeholders

+
+

1.3. Stakeholders

-+++ - + + + - - - - + + + - + + + - + + + - - - - - - - + + + + +
<<<<<<< HEADRole/NameContactExpectations

Role/Name

Contact

Students (HappySw)

Martín Cancio Barrera, Iyán Fernández Riol, Rodrigo García Iglesias and Alfredo Jirout Cid

The students are the developers of the application. They are in charge of the complete development, which will improve their programming and teamwork skills.

Expectations

Users

Anyone who uses the application

Users are the ones who will ultimately use the application, so it must be intuitive and easy to understand.

Alfredo Jirout Cid

Teachers

José Emilio Labra Gayo, Pablo González González, Jorge Álvarez Fidalgo and Cristian Augusto Alonso.

They are the supervisors of the project, and will help the students toensure that the project comes to fruition.

UO288443@uniovi.es

Aprobar (opcional)

Rodrigo Gracía Iglesias

RTVE

RTVE

They are the main stakeholders in the application, as they are the ones who commissioned it, so that their viewers can use it.
+
+
+
+
+
+

2. Architecture Constraints

+
+ ++++ + - + + + + - + + - + + - + + - + + - + + - + + - + + - -

UO276396@uniovi.es

Architecture constraintDescription

No tomar de ejemplo a Miguel

Tecnología de Desarrollo

The application must be developed using web technologies compatible with RTVE’s requirements and standards.

Iyán Fernández Riol

Plataforma de Implementación

The application must be implemented on a web hosting platform that meets RTVE’s performance, security and scalability requirements.

UO288231@uniovi.es

Cumplimiento de Normativas de Privacidad

The architecture must ensure compliance with data privacy regulations, such as GDPR, to protect users' information.

Sacar matricula

Compatibilidad con Navegadores

The application should be compatible with a wide range of popular web browsers to ensure a consistent user experience.

Martín Cancio Barrera

Seguridad de la Información

Strong security measures, such as user authentication, access control and data encryption, must be implemented to protect users' confidential information.

UO287561@uniovi.es

Escalabilidad

The architecture must be scalable to handle increased user traffic without compromising performance.

Ser feliz

Mantenibilidad del Código

Software development practices that promote clean and well-documented code should be followed to facilitate future upgrades and maintenance.
-
-
-
-

|Role/Name|Contact|Expectations

-
-
-

| Students (HappySw) -| Martín Cancio Barrera, Iyán Fernández Riol, Rodrigo García Iglesias and Alfredo Jirout Cid -| The students are the developers of the application. They are in charge of the complete development, which will improve their programming and teamwork skills.

-
-
-

| Users -| Anyone who uses the application -| Users are the ones who will ultimately use the application, so it must be intuitive and easy to understand.

-
-
-

| Teachers -| José Emilio Labra Gayo, Pablo González González, Jorge Álvarez Fidalgo and Cristian Augusto Alonso. -| They are the supervisors of the project, and will help the students toensure that the project comes to fruition.

-
-
-

| RTVE -| RTVE -| They are the main stakeholders in the application, as they are the ones who commissioned it, so that their viewers can use it. ->>>>>>> bc38116a46fe4d35d847382a96c27343738d4cd4

-
- --- - - + +

<<<<

-

-== Architecture Constraints

Tiempo de Desarrollo

The application must be developed within a specific time frame, which may influence architectural decisions and technology selection.
-
-

| Architecture constraint | Description

-
-
-

| Tecnología de Desarrollo | The application must be developed using web technologies compatible with RTVE’s requirements and standards.

+
-
-

| Plataforma de Implementación | The application must be implemented on a web hosting platform that meets RTVE’s performance, security and scalability requirements.

-
-

| Cumplimiento de Normativas de Privacidad | The architecture must ensure compliance with data privacy regulations, such as GDPR, to protect users' information.

+
+

3. System Scope and Context

+
+
+

3.1. Business Context

+
+
+Business context
-
-

| Compatibilidad con Navegadores | The application should be compatible with a wide range of popular web browsers to ensure a consistent user experience.

-
-

| Seguridad de la Información | Strong security measures, such as user authentication, access control and data encryption, must be implemented to protect users' confidential information.

-
-

| Escalabilidad | The architecture must be scalable to handle increased user traffic without compromising performance.

+
+

3.2. Technical Context

+
+
+Technical Context
-
-

| Mantenibilidad del Código | Software development practices that promote clean and well-documented code should be followed to facilitate future upgrades and maintenance.

-
-

| Tiempo de Desarrollo | The application must be developed within a specific time frame, which may influence architectural decisions and technology selection.

+
- --- - - - - - -

<<<<

-

-== System Scope and Context

-

=== Business Context -image::businesscontext.png[Business context]

-

=== Technical Context -image::technicalcontext.png[Technical Context]

-

<<<<

-

-== Solution Strategy

-

[role="arc42help"]

+
+

4. Solution Strategy

+
-
Contents
-

A short summary and explanation of the fundamental decisions and solution strategies, that shape system architecture. It includes

+

Elaboramos una aplicacíon en la que los usuarios pueden registrarse para jugar, donde en cada juego tendran que responder varias preguntas, de distintas categorias, donde se guardará +un ranking con la máxima puntuación del usuario y se podrá comparar con otros usuarios, también tendra una sección que indique su promedio de aciertos y en que categoría acierta más preguntas.

+
Tecnologías usadas para llevar a cabo:
  • -

    technology decisions

    +

    MongoDB: MongoDB es una base de datos NoSQL de código abierto que utiliza un modelo de datos basado en documentos para el almacenamiento y recuperación de información.

  • -

    decisions about the top-level decomposition of the system, e.g. usage of an architectural pattern or design pattern

    +

    React JS: Es un framework creado por Facebook ampliamente utlizado para crear componentes de la interfaz de usuario. Escogido por el gran volumen de documentación y ser el framework utilizado durante los anteriores cursos.

  • -

    decisions on how to achieve key quality goals

    +

    WikiData: Es una base de conocimientos gratuita modificada por seres humanos como por máquinas, y es de donde obtendremos nuestras preguntas.

  • -

    relevant organizational decisions, e.g. selecting a development process or delegating certain tasks to third parties.

    +

    Microsoft Azure: plataforma de computación en la nube que proporciona servicios de infraestructura, plataforma y software como servicio para alojar, administrar y escalar aplicaciones y servicios en línea.

-
Motivation
-

These decisions form the cornerstones for your architecture. They are the foundation for many other detailed decisions or implementation rules.

+
Diseño
+

La página web diseñada está compuesta por un frontend en React, un backend en Node.js y está documentada usando Asciidoc. Cada usuario tendrá su propia cuenta donde se guardará su información. Las decisiones relacionadas con el diseño se detallan en el punto 9.

-
Form
-

Keep the explanations of such key decisions short.

+
Seguridad
+

Garantizamos la seguridad del usuario

-

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.

+
Testabilidad
+

Se realizarán pruebas para cada parte individual de la aplicación, garantizando así el correcto funcionamiento de los diferentes modulos tanto individualmente como de forma conjunta.

-
Further Information
-

See Solution Strategy in the arc42 documentation.

+
Interfaz
+

La interfaz gráfica será elegida entre todos los miembros del equipo, aportando cada uno algún boceto o idea, los cuales serán puestos en común y se decidirá cual se ajusta mejor a la apicación esperada y que elementos de dichos bocetos resultan más adecuados. +Para ello se tendrá en cuenta la usabilidad y las necesidades de los difentes tipos de usuarios.

-
-
-
-

== Building Block View

-
+
+

5. Building Block View

+
+
+
Content

The building block view shows the static decomposition of the system into building blocks (modules, components, subsystems, classes, interfaces, packages, libraries, frameworks, layers, partitions, tiers, functions, macros, operations, data structures, …​) as well as their dependencies (relationships, associations, …​)

@@ -847,13 +870,12 @@

1. Introduction and Goals

Further Information

See Building Block View in the arc42 documentation.

-
-
-
-

=== Whitebox Overall System

-
+
+

5.1. Whitebox Overall System

+
+

Here you describe the decomposition of the overall system using the following white box template. It contains

@@ -888,8 +910,8 @@

1. Introduction and Goals

-
-
+
+

<Overview Diagram>

@@ -909,8 +931,8 @@

1. Introduction and Goals

-
-
+
+

Insert your explanations of black boxes from level 1:

@@ -944,13 +966,12 @@

1. Introduction and Goals

If you use a list of black box descriptions then you fill in a separate black box template for every important building block . Its headline is the name of the black box.

-
-
-
-

==== <Name black box 1>

-
+
+

5.1.1. <Name black box 1>

+
+

Here you describe <black box 1> according the the following black box template:

@@ -977,8 +998,8 @@

1. Introduction and Goals

-
-
+
+

<Purpose/Responsibility>

@@ -997,32 +1018,34 @@

1. Introduction and Goals

<(optional) Open Issues/Problems/Risks>

-
-

==== <Name black box 2>

+
+

5.1.2. <Name black box 2>

<black box template>

-
-

==== <Name black box n>

+
+

5.1.3. <Name black box n>

<black box template>

-
-

==== <Name interface 1>

+
+

5.1.4. <Name interface 1>

…​

-
-

==== <Name interface m>

-
-
-

=== Level 2

+
+

5.1.5. <Name interface m>

+
+
+

5.2. Level 2

+
+

Here you can specify the inner structure of (some) building blocks from level 1 as white boxes.

@@ -1031,41 +1054,41 @@

1. Introduction and Goals

Please prefer relevance over completeness. Specify important, surprising, risky, complex or volatile building blocks. Leave out normal, simple, boring or standardized parts of your system

-
-
-
-

==== White Box <building block 1>

-
+
+

5.2.1. White Box <building block 1>

+
+

…​describes the internal structure of building block 1.

-
-
+
+

<white box template>

-
-

==== White Box <building block 2>

+
+

5.2.2. White Box <building block 2>

<white box template>

…​

-
-

==== White Box <building block m>

+
+

5.2.3. White Box <building block m>

<white box template>

-
-

=== Level 3

-
+
+

5.3. Level 3

+
+

Here you can specify the inner structure of (some) building blocks from level 2 as white boxes.

@@ -1073,39 +1096,42 @@

1. Introduction and Goals

When you need more detailed levels of your architecture please copy this part of arc42 for additional levels.

-
-
-
-

==== White Box <_building block x.1_>

-
+
+

5.3.1. White Box <_building block x.1_>

+
+

Specifies the internal structure of building block x.1.

-
-
+
+

<white box template>

-
-

==== White Box <_building block x.2_>

+
+

5.3.2. White Box <_building block x.2_>

<white box template>

-
-

==== White Box <_building block y.1_>

+
+

5.3.3. White Box <_building block y.1_>

<white box template>

-
-

== Runtime View

+
+
+

6. Runtime View

+
+
+
Contents

The runtime view describes concrete behavior and interactions of the system’s building blocks in form of scenarios from the following areas:

@@ -1164,11 +1190,10 @@

1. Introduction and Goals

Further Information

See Runtime View in the arc42 documentation.

-
-
-
-

=== <Runtime Scenario 1>

+
+
+

6.1. <Runtime Scenario 1>

  • @@ -1188,21 +1213,26 @@

    1. Introduction and Goals

    Sequence diagram
-
-

=== <Runtime Scenario 2>

-
-

=== …​

+
+

6.2. <Runtime Scenario 2>

+
-
-

=== <Runtime Scenario n>

+
+

6.3. …​

+
+
+

6.4. <Runtime Scenario n>

-
-

== Deployment View

+
+

7. Deployment View

+
+
+
Content

The deployment view describes:

@@ -1253,13 +1283,12 @@

1. Introduction and Goals

Further Information

See Deployment View in the arc42 documentation.

-
-
-
-

=== Infrastructure Level 1

-
+
+

7.1. Infrastructure Level 1

+
+

Describe (usually in a combination of diagrams, tables, and text):

@@ -1282,8 +1311,8 @@

1. Introduction and Goals

For multiple environments or alternative deployments please copy and adapt this section of arc42 for all relevant environments.

-
-
+
+

<Overview Diagram>

@@ -1303,46 +1332,49 @@

1. Introduction and Goals

-
-

=== Infrastructure Level 2

-
-
+
+

7.2. Infrastructure Level 2

+
+

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>

+
+
+

7.2.1. <Infrastructure Element 1>

<diagram + explanation>

-
-

==== <Infrastructure Element 2>

+
+

7.2.2. <Infrastructure Element 2>

<diagram + explanation>

…​

-
-

==== <Infrastructure Element n>

+
+

7.2.3. <Infrastructure Element n>

<diagram + explanation>

-
-

== Cross-cutting Concepts

+
+
+

8. Cross-cutting Concepts

+
+
+
Content

This section describes overall, principal regulations and solution ideas that are relevant in multiple parts (= cross-cutting) of your system. @@ -1438,98 +1470,102 @@

1. Introduction and Goals

Further Information

See Concepts in the arc42 documentation.

-
-
-
-

=== <User Interface >

+
+
+

8.1. <User Interface >

<A user interface is the space where a human and a computer or device communicate and exchange information.>

-
-

=== <Ergonomics >

+
+

8.2. <Ergonomics >

<Ergonomics is the science of designing and arranging workplaces, products, and systems to fit and adapt to the people who use them. Ergonomics aims to improve comfort, efficiency, and safety by considering human physical and psychological needs and limitations. >

-
-

=== <Internationalization >

+
+

8.3. <Internationalization >

<Internationalization is the practice of designing and developing applications that can support multiple languages, formats, and conventions>

-
-

=== <Security >

+
+

8.4. <Security >

<Security is a broad term that can refer to different aspects of protection, resilience, or prevention of harm. >

-
-

=== <Safety >

+
+

8.5. <Safety >

<Is the state of being protected from danger or harm.>

-
-

=== <Build, Test, Deploy >

+
+

8.6. <Build, Test, Deploy >

← Build: This stage involves compiling, validating, and packaging the source code into executable or deployable artifacts. - Test: This stage involves running various tests, such as unit tests, integration tests, and regression tests, to ensure the quality and functionality of the software. - Deploy: This stage involves delivering or releasing the software to the target environment, such as a server, a cloud platform, or a user device. >

-
-

=== <Code Generation >

+
+

8.7. <Code Generation >

<Code generation is the process of creating executable or deployable code from various sources of information, such as natural language, images, or other code.>

-
-

=== <Migration >

+
+

8.8. <Migration >

<Migrating from one software application or platform to another, such as switching from a legacy system to a modern one, or from a local server to a cloud service.>

-
-

=== <Configurability >

+
+

8.9. <Configurability >

<Configurability is the ability to modify or customize something, especially in computing, electronics, or de>

-
-

=== <Administration >

+
+

8.10. <Administration >

<The process or activity of managing, directing, or organizing something or someone>

-
-

=== <Management >

+
+

8.11. <Management >

<Management is the process of organizing and directing the resources of a business or organization to achieve its goals. >

-
-

=== <Disaster-Recovery >

+
+

8.12. <Disaster-Recovery >

<Is the process of restoring the functionality and data of software applications after a disaster, such as a natural calamity, a cyberattack, or a human error.>

-
-

=== <Architecture and design patterns >

+
+

8.13. <Architecture and design patterns >

<Architecture and design patterns are concepts that help software developers and architects design and build software systems that are efficient, scalable, and maintainable>

-
-

=== <Concept >

+
+

8.14. <Concept >

<explanation>

-
-

== Architecture Decisions -JavaScript: +

+
+
+
+

9. Architecture Decisions

+
+
+

JavaScript: We will use the JavaScript language to create both the front-end and the backend of the application, is the default technology of the initial project.

@@ -1556,8 +1592,8 @@

1. Introduction and Goals

The base project that they have given us uses MongoDB for the back-end of the application, a DBMS with which we are not familiar, however MySQL is another database management system that we have used in other subjects. We decided to discard this option to learn how to use MongoDB

-
-
+
+
Contents

Important, expensive, large scale or risky architecture decisions including rationales. @@ -1598,12 +1634,14 @@

1. Introduction and Goals

See Architecture Decisions in the arc42 documentation. There you will find links and examples about ADR.

-
-
+
+
-
-

== Quality Requirements

+
+
+

10. Quality Requirements

+

In our project, we have some quality goals or expectations that we want to be met. These are:

@@ -1624,9 +1662,8 @@

1. Introduction and Goals

-
-

=== Quality Tree

-
+
+

10.1. Quality Tree

  • @@ -1669,12 +1706,13 @@

    1. Introduction and Goals

-
-

=== Quality Scenarios

-
-

# Usage Scenarios

+
+

10.2. Quality Scenarios

+
+
+

10.3. Usage Scenarios

@@ -1735,9 +1773,9 @@

1. Introduction and Goals

-
-

# Change Scenarios

+
+

10.4. Change Scenarios

@@ -1799,163 +1837,92 @@

1. Introduction and Goals

== Risks and Technical Debts

JavaScript: A dynamic, weakly typed language that can have bugs and problems.

-

<<<<<<< HEAD -ReactJS: A framework for creating user interfaces, but with difficulties and challenges. A high learning curve is required

+

ReactJS: A framework for creating user interfaces, but with difficulties and challenges. A high learning curve is required

NodeJS: An environment for running JavaScript on the server, but with limitations and risks.

MongoDB: A NoSQL database that offers scalability, flexibility, and performance, but with trade-offs and challenges. It does not support transactions, joins, or schemas, which can affect the consistency, integrity, and reliability of the data. It has a different language and data model than SQL databases, which implies a paradigm shift.

Docker: A platform for building and running applications in isolated containers, but with drawbacks and risks. It can increase the complexity and cost of deploying and handling your applications as you need additional tools and configurations.

The wikidata api, since it is the first time we use it and we will have to learn how to use it to create questions and also learn how to generate templates for those questions

Communication and group work can be complicated at times, so you should always try to maintain a good working atmosphere with the whole team

-

[role="arc42help"]

+

[role="arc42help"] +* +.Contents +A list of identified technical risks or technical debts, ordered by priority

+

.Motivation +“Risk management is project management for grown-ups” (Tim Lister, Atlantic Systems Guild.)

+

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.

+

.Form +List of risks and/or technical debts, probably including suggested measures to minimize, mitigate or avoid risks or reduce technical debts.

+

.Further Information

+

See Risks and Technical Debt in the arc42 documentation.

+

*

+

<<<<

+

+== Glossary

+

[cols="e,2e" options="header"]

+
+

|Term |Definition

+
+

|Quality Tree +| Structured representation of quality attributes and their relationships.

-
Contents
-

A list of identified technical risks or technical debts, ordered by priority

+

|Quality Scenarios +| Specific instances or situations that show the behavior of a system under various quality attributes.

-
Motivation
-

“Risk management is project management for grown-ups” (Tim Lister, Atlantic Systems Guild.)

+

|Change Scenarios +| Scenarios depicting how a system responds or adapts to changes, like fixes or addings.

-

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.

+

|Usage Scenarios +| Instances demonstrating how users interact with a system in various contexts.

-
Form
-

List of risks and/or technical debts, probably including suggested measures to minimize, mitigate or avoid risks or reduce technical debts.

+

|User Interface +| The visual and interactive part of a computer program or system through which users interact.

-
Further Information
-

See Risks and Technical Debt in the arc42 documentation.

+

|Query +| Request for information from a database.

-
-
-
-
- ----- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
PriorityDescription of Risk/Technical DebtSuggested Measures

High

Vulnerabilities in user authentication

Implement additional security measures, such as password encryption

High

Potential application malfunctions

Implement unit tests for key components and critical functions, along with extensive testing with real users

Medium

Slow performance of database queries

Optimize database queries, avoid unnecessary queries

Low

Unoptimized styles

Optimize CSS styles to improve application performance and loading times

Low

Insufficient documentation

Provide comprehensive documentation of architecture, code structure, development processes, and deployment to facilitate team maintenance and collaboration

-

>>>>>>> bc38116a46fe4d35d847382a96c27343738d4cd4

+

|Database +| Organized collection of structured information.

-
-
-

== Glossary

+
+

|Documentation +| Written information regarding a system’s design, functionality, or usage.

- ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
TermDefinition

Quality Tree

Structured representation of quality attributes and their relationships.

Quality Scenarios

Specific instances or situations that show the behavior of a system under various quality attributes.

Change Scenarios

Scenarios depicting how a system responds or adapts to changes, like fixes or addings.

Usage Scenarios

Instances demonstrating how users interact with a system in various contexts.

User Interface

The visual and interactive part of a computer program or system through which users interact.

Query

Request for information from a database.

Database

Organized collection of structured information.

Documentation

Written information regarding a system’s design, functionality, or usage.

NodeJS

Runtime environment that allows the execution of JavaScript code outside of a web browser.

ReactJS

JavaScript library for building user interfaces, particularly single-page applications.

JavaScript

High-level programming language primarily used for creating interactive web pages and applications.

MongoDB

Popular NoSQL database program, known for its flexibility and scalability.

CSS

Cascading Style Sheets, used for styling and formatting web pages written in HTML.

HTML

Hypertext Markup Language, the standard markup language for creating web pages and web applications.

+
+

|NodeJS +| Runtime environment that allows the execution of JavaScript code outside of a web browser.

+
+

|ReactJS +| JavaScript library for building user interfaces, particularly single-page applications.

+
+

|JavaScript +| High-level programming language primarily used for creating interactive web pages and applications.

+
+
+

|MongoDB +| Popular NoSQL database program, known for its flexibility and scalability.

+
+
+

|CSS +| Cascading Style Sheets, used for styling and formatting web pages written in HTML.

+
+

|HTML +| Hypertext Markup Language, the standard markup language for creating web pages and web applications.

+
+ +
@@ -1963,7 +1930,7 @@

1. Introduction and Goals