diff --git a/docs/images/03_Business_Context_Diagram.png b/docs/images/03_Business_Context_Diagram.png new file mode 100644 index 00000000..6010a5c8 Binary files /dev/null and b/docs/images/03_Business_Context_Diagram.png differ diff --git a/docs/images/03_Technical_Context.png b/docs/images/03_Technical_Context.png new file mode 100644 index 00000000..9b202551 Binary files /dev/null and b/docs/images/03_Technical_Context.png differ diff --git a/docs/images/05_Level_3_Diagram.png b/docs/images/05_Level_3_Diagram.png new file mode 100644 index 00000000..4c654c43 Binary files /dev/null and b/docs/images/05_Level_3_Diagram.png differ diff --git a/docs/images/05_level1Diagram.png b/docs/images/05_level1Diagram.png new file mode 100644 index 00000000..eb2fdd29 Binary files /dev/null and b/docs/images/05_level1Diagram.png differ diff --git a/docs/images/05_level2Diagram.png b/docs/images/05_level2Diagram.png new file mode 100644 index 00000000..6e4ddedb Binary files /dev/null and b/docs/images/05_level2Diagram.png differ diff --git a/docs/images/08_domain_model.png b/docs/images/08_domain_model.png new file mode 100644 index 00000000..1fcf2a76 Binary files /dev/null and b/docs/images/08_domain_model.png differ diff --git a/docs/images/QualityTree.png b/docs/images/QualityTree.png new file mode 100644 index 00000000..6266b73f Binary files /dev/null and b/docs/images/QualityTree.png differ diff --git a/docs/images/deployment.png b/docs/images/deployment.png new file mode 100644 index 00000000..cc2c2080 Binary files /dev/null and b/docs/images/deployment.png differ diff --git a/docs/src/01_introduction_and_goals.adoc b/docs/src/01_introduction_and_goals.adoc index ddb2ae3d..87c25b63 100644 --- a/docs/src/01_introduction_and_goals.adoc +++ b/docs/src/01_introduction_and_goals.adoc @@ -41,6 +41,17 @@ See https://docs.arc42.org/section-1/[Introduction and Goals] in the arc42 docum **** +The WIQ web application allows users to play a game similar to the one of Saber y Ganar quiz show. This game consists on answering a number of questions with different types and subjects obtaining a prize for each question well answered. Game´s questions are automatically generated from data available in Wikidata (https://www.wikidata.org/). + +* The system will have at least a web front-end which will be available and accessible through the web. +* Users will be able to register to the system and obtain the historical data from their participation: number of games, questions passed and failed, times, etc .. +* Questions will be automatically generated from data available in Wikidata. +* Questions have to be answered before some specific time. +* Each question will have one right answer and several incorrect ones or distractors. Both the right answer and the distractors should be automatically generated. +* The system will give access to the information about the users through an API. +* The system will give access to information about the generated questions through an API. + + === Quality Goals [role="arc42help"] @@ -62,6 +73,17 @@ If you as an architect do not know how the quality of your work will be judged.. .Form A table with quality goals and concrete scenarios, ordered by priorities **** +.Quality goals ordered by priority (from most to least important) +[options="header",cols="1,3"] +|=== +|Quality Goal|Description +| _Satisfaction_ | _Users will not get repeated questions in at least a hundred questions._ +| _Modularity_ | _The application will be divided in modules so that a change on one component has minimal impact on other components._ +| _Testability_ | _The application should be able to go through different test and complete them successfully._ +| _Learnability_ | _Any user must be able to use the app with ease. The interface must remind the user to the one in Saber y Ganar quiz show._ +| _Time behaviour_ | _Users will not have to wait more than 500ms to get a new question._ +|=== + === Stakeholders @@ -88,6 +110,10 @@ Table with role names, person names, and their expectations with respect to the [options="header",cols="1,2,2"] |=== |Role/Name|Contact|Expectations -| __ | __ | __ -| __ | __ | __ +| _Professors_ | _ASW module professors_ | _Get a great project which can be evaluated and shown in their github._ +| _Developers_ | _wiq_es6c team_ | _Carrying out a full real project using all the knowledge obtained in the degree._ +| _Responsible company_ | _HappySw_ | _Development of an experimental version of the Saber y Ganar quiz show._ +| _Client_ | _RTVE_ | _Getting a Web App to promote its famous Saber y Ganar quiz show by letting their viewers enjoy a similar experience._ +| _Main beneficiaries_ | _Public users_ | _Having a great time playing an interesting and easy to use quiz game._ +| _Side beneficiaries_ | _Wikidata_ | _Obtain free promotion of their application and its ease to use in multiple projects._ |=== diff --git a/docs/src/02_architecture_constraints.adoc b/docs/src/02_architecture_constraints.adoc index 226e501f..3e7ebafa 100644 --- a/docs/src/02_architecture_constraints.adoc +++ b/docs/src/02_architecture_constraints.adoc @@ -3,7 +3,6 @@ ifndef::imagesdir[:imagesdir: ../images] [[section-architecture-constraints]] == Architecture Constraints - [role="arc42help"] **** .Contents @@ -25,3 +24,43 @@ conventions (e.g. programming or versioning guidelines, documentation or naming See https://docs.arc42.org/section-2/[Architecture Constraints] in the arc42 documentation. **** + +=== Technical constraints + +[cols="2,4" options="header"] +|=== +|Constraint |Explanation +|*OS/Browser Independence* |The project must be available to the maximum amount of users feasible. That includes support for mainstream OSs (_Windows_, _Linux_, _MacOS_) and browsers. (_Chrome_, _Safari_, _Firefox_, _Edge_) +|*Usage of _REACT_* |The _REACT JS_ framework will be used to develop the front-end of the project. +|*Docker* | The application will operate within a Docker environment. +|*Version Control* |In order of the project to be graded adequately, it must use _GitHub_ as its version control system. The contributions of each team member and agreements reached must be easily traceable. +|*Wikidata* | To generate questions, WikiData would be used as a knowledge base. Wikidata is a free and open knowledge base that can be read and edited by both humans and machines. Wikidata acts as central storage for the structured data of its sister Wikimedia projects, including Wikipedia, Wikivoyage, Wiktionary, Wikisource and others. +|*Continuous integration and delivery* |The development must progress through frequent integration of small changes into the main branch. New features must be automatically deployed with ease. (In our case, using _Docker_) +|=== + +=== Organizational constraints + +[cols="2,7" options="header"] +|=== +|Constraint |Explanation +|*Time* |The team has to complete the project during the semester. +|*Team size* |The development teams must be composed of 5-7 members. In our case, the final team is composed of 6 members. +|*Budget* |No budget is provided for the development, so any costs that may arise have to be covered by the development team. +|*Deliverables* |Along the development process, the team must prepare deliverables set for certain dates, consisting of documentation and/or application prototypes. +|*Team meetings* |In order to plan the development of the project, as well as to assign tasks and make design decisions, the team will participate in several meetings. These meetings can be done in and out of the classroom, as needed. A record must be created for every meeting, summarizing the progress made. +|*Project testing* |The development team must test acceptable coverage of the project using different methods (_unit testing_, _integration testing_, _acceptance testing_... etc.) +|*Knowledge* |There are many aspects of the development of this project that are foreign to some of us (usage of _REACT_, deployments, microsystems architecture... etc.) so some research is required to keep up. +|=== + +=== Conventions + +[cols="2,4" options="header"] +|=== +|Constraint |Explanation +|*Use of English* |The totality of the project must be written in English, as to facilitate its understanding internationally. +|*Programming Language conventions* | We ought to follow the conventions specific to the programming languages we're employing. +|*Documentation format* |The documentation must adhere to the Arc42 method, ensuring it is clear, simple, and effective. +|*Clean code* |In order to ease the understanding and maintenance of the project, all code written must be organized, descriptive and easy to read. +|*Accesibility* |The application should be user-friendly, allowing all individuals to navigate effortlessly, irrespective of any disabilities, ensuring inclusivity for all users. +|*Microservices* | The application will be divided into microservices to facilitate its development. +|=== diff --git a/docs/src/03_system_scope_and_context.adoc b/docs/src/03_system_scope_and_context.adoc index c528e907..0d7b66c8 100644 --- a/docs/src/03_system_scope_and_context.adoc +++ b/docs/src/03_system_scope_and_context.adoc @@ -3,7 +3,6 @@ ifndef::imagesdir[:imagesdir: ../images] [[section-system-scope-and-context]] == System Scope and Context - [role="arc42help"] **** .Contents @@ -25,10 +24,8 @@ Various options: .Further Information See https://docs.arc42.org/section-3/[Context and Scope] in the arc42 documentation. - **** - === Business Context [role="arc42help"] @@ -48,9 +45,13 @@ The title of the table is the name of your system, the three columns contain the **** -**** - -**** +[cols=3 options="header"] +|=== +|Entity |Input |Output +|*User* | App usage and experience. | The user will introduce and send its credentials every time it creates a new account or logs into an existing one. +|*WebApp* | User data and input, as well as external API calls received. | Handled API calls, sent to their respective microservice in order to be processed and answered. +|*Wikidata* |Calls to Wikidata's REST API asking for certain data, which will be used to construct the questions. | Said data. Its format may vary, according to the necessities of the questions generator. +|=== === Technical Context @@ -68,8 +69,5 @@ together with a mapping table showing the relationships between channels and inp **** -**** - -**** +image::03_Technical_Context.png[] -**** diff --git a/docs/src/04_solution_strategy.adoc b/docs/src/04_solution_strategy.adoc index 7bf03f7a..84832e17 100644 --- a/docs/src/04_solution_strategy.adoc +++ b/docs/src/04_solution_strategy.adoc @@ -3,30 +3,51 @@ ifndef::imagesdir[:imagesdir: ../images] [[section-solution-strategy]] == Solution Strategy +=== Technology Decisions -[role="arc42help"] -**** -.Contents -A short summary and explanation of the fundamental decisions and solution strategies, that shape system architecture. It includes +In order to develop the application and adhere to the constraints, we selected the following technologies: -* 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. +- ReactJS: JavaScript library that streamlines the development of graphical interfaces for web applications. +- TypeScript: Extension of JavaScript, bolstering it with type support for improved development. +- GitHub: Platform offering remote repository services for project development, task management, and version control. +- MongoDB: A non-linear database selected to oversee storage of diverse application contents, with each microservice possessing its dedicated database. +- NodeJS: Facilitates efficient management of asynchronous events, notably beneficial for scalable network applications and database administration. +- Docker: Employed for seamless deployment of the application environment. -.Motivation -These decisions form the cornerstones for your architecture. They are the foundation for many other detailed decisions or implementation rules. +=== Top-level Decomposition -.Form -Keep the explanations of such key decisions short. +==== Diagramming tools -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. +We will use PlantUML and UMLet for creating the documentation's diagrams. +=== Approaches to Achieve Top Quality Goals -.Further Information +[cols="1,2,3"] +|=== +| Quality Goal | Scenario | Solution Approach -See https://docs.arc42.org/section-4/[Solution Strategy] in the arc42 documentation. +| Privacy +| Users seek reassurance in the safety and privacy of their data within our app. +| Ensuring user data security and privacy within the application. -**** +| Usability +| Seamless execution of all application functions is crucial for user satisfaction. +| Optimizing usability through the utilization of React. + +| Maintainability +| Application architecture must facilitate seamless addition or modification of functionalities with minimal code changes. +| Implementing design patterns and adhering to code conventions to ensure clean and maintainable code. Additionally, prioritizing testing during development for long-term maintainability. + +| Scalability +| The application's design must accommodate changes effortlessly throughout its lifecycle. +| Employing a microservices approach to minimize code repetition and enhance understanding of application distribution, ensuring future scalability. + +|=== + +=== Organizational Decisions + +We've established the following organizational guidelines: + +- *Language*: Adhering to international standards, the project, encompassing code and documentation, will be developed in English as the primary language. +- *Issues:* All deliberations will be documented as issues on GitHub. +- *GitHub Projects:* Employing this tool, we'll plan the application's development process, utilizing GitHub's integrated features for efficient project management in accordance with AGILE methodology. diff --git a/docs/src/05_building_block_view.adoc b/docs/src/05_building_block_view.adoc index df5c29c8..a386e81f 100644 --- a/docs/src/05_building_block_view.adoc +++ b/docs/src/05_building_block_view.adoc @@ -1,212 +1,166 @@ ifndef::imagesdir[:imagesdir: ../images] [[section-building-block-view]] - - -== Building Block View - [role="arc42help"] **** .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, ...) - This view is mandatory for every architecture documentation. In analogy to a house this is the _floor plan_. - .Motivation Maintain an overview of your source code by making its structure understandable through abstraction. - This allows you to communicate with your stakeholder on an abstract level without disclosing implementation details. - .Form The building block view is a hierarchical collection of black boxes and white boxes (see figure below) and their descriptions. - image::05_building_blocks-EN.png["Hierarchy of building blocks"] - *Level 1* is the white box description of the overall system together with black box descriptions of all contained building blocks. - *Level 2* zooms into some building blocks of level 1. Thus it contains the white box description of selected building blocks of level 1, together with black box descriptions of their internal building blocks. - *Level 3* zooms into selected building blocks of level 2, and so on. - - .Further Information - See https://docs.arc42.org/section-5/[Building Block View] in the arc42 documentation. - **** -=== Whitebox Overall System +== Building block view + [role="arc42help"] **** Here you describe the decomposition of the overall system using the following white box template. It contains - * an overview diagram * a motivation for the decomposition * black box descriptions of the contained building blocks. For these we offer you alternatives: - ** use _one_ table for a short and pragmatic overview of all contained building blocks and their interfaces ** use a list of black box descriptions of the building blocks according to the black box template (see below). Depending on your choice of tool this list could be sub-chapters (in text files), sub-pages (in a Wiki) or nested elements (in a modeling tool). - - * (optional:) important interfaces, that are not explained in the black box templates of a building block, but are very important for understanding the white box. Since there are so many ways to specify interfaces why do not provide a specific template for them. In the worst case you have to specify and describe syntax, semantics, protocols, error handling, restrictions, versions, qualities, necessary compatibilities and many things more. In the best case you will get away with examples or simple signatures. - **** -_****_ +=== Level 1: Overall System's whitebox + +image::05_level1Diagram.png[Level 1 Diagram] -Motivation:: -__ +==== Motivation -Contained Building Blocks:: -__ +This level shows how the application will work internally in generaly. The client, WebApp, access to the different services provided by the microservices which make up the program. -Important Interfaces:: -__ +==== Contained Building Blocks [role="arc42help"] **** Insert your explanations of black boxes from level 1: - If you use tabular form you will only describe your black boxes with name and responsibility according to the following schema: - [cols="1,2" options="header"] |=== | **Name** | **Responsibility** -| __ | __ -| __ | __ +| __ | __ +| __ | __ |=== - - - 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. **** - -==== - -[role="arc42help"] -**** -Here you describe -according the the following black box template: - -* Purpose/Responsibility -* Interface(s), when they are not extracted as separate paragraphs. This interfaces may include qualities and performance characteristics. -* (Optional) Quality-/Performance characteristics of the black box, e.g.availability, run time behavior, .... -* (Optional) directory/file location -* (Optional) Fulfilled requirements (if you need traceability to requirements). -* (Optional) Open issues/problems/risks - -**** - -__ - -__ - -_<(Optional) Quality/Performance Characteristics>_ - -_<(Optional) Directory/File Location>_ - -_<(Optional) Fulfilled Requirements>_ - -_<(optional) Open Issues/Problems/Risks>_ - - - - -==== - -__ - -==== - -__ - - -==== - -... - -==== - - - -=== Level 2 +[options="header"] +[cols="1,2"] +|=== +|Name |Description +|User +|Client of the application which will interact with it. +|WIQ App +|System developed to be used by the users. The games will be based on the information obtanined from WikiData +|WikiData +|Service external to the application from which the application questions will be obtained. Wikidata is a collaboratively edited multilingual knowledge graph hosted by the Wikimedia Foundation. +|=== [role="arc42help"] **** Here you can specify the inner structure of (some) building blocks from level 1 as white boxes. - You have to decide which building blocks of your system are important enough to justify such a detailed description. 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 __ - [role="arc42help"] **** ...describes the internal structure of _building block 1_. **** -__ - -==== White Box __ - - -__ - -... - -==== White Box __ - - -__ - - - -=== Level 3 +=== Level 2 [role="arc42help"] **** -Here you can specify the inner structure of (some) building blocks from level 2 as white boxes. - -When you need more detailed levels of your architecture please copy this -part of arc42 for additional levels. +Here you describe +according the the following black box template: +* Purpose/Responsibility +* Interface(s), when they are not extracted as separate paragraphs. This interfaces may include qualities and performance characteristics. +* (Optional) Quality-/Performance characteristics of the black box, e.g.availability, run time behavior, .... +* (Optional) directory/file location +* (Optional) Fulfilled requirements (if you need traceability to requirements). +* (Optional) Open issues/problems/risks **** -==== White Box <_building block x.1_> +image::05_level2Diagram.png[Level 2 Diagram] -[role="arc42help"] -**** -Specifies the internal structure of _building block x.1_. -**** +==== Motivation -__ +*_WiQ_* application is the general structure of a system in which users will have the possibility to play a video game implementation of the popular RTVE programme, "Saber y Ganar". +==== Contained Building Blocks -==== White Box <_building block x.2_> +[options="header"] +[cols="1,2"] +|=== +|Name |Description +|Web App +|Layer in which the user will interact directly and which will connect with the different services. +|Questions Service +|Microservice to generate the questions used by the application from WikiData +|Game Service +|Microservice that implements the quiz game +|Question Historic Service +|Microservice that stores the generated questions for later consultation +|User Statistics Service +|Microservice that stores the statistics of the games played by the user. +|Authentification Service +|Authentication microservice that allows the user to register and log in. +|=== + +=== Level 3 -__ +image::05_Level_3_Diagram.png[Level 3 Diagram] +==== Motivation +To display the inner architecture of the different microservices, as well as how do their components interact with themselves and with other components from other microsystems. All microservices follow the MVC architectural pattern, to the exception of the questions generator service. (since it has no UI to handle) -==== White Box <_building block y.1_> +==== Contained Building Blocks -__ +[options="header"] +[cols="1,2"] +|=== +|Name |Description +|Questions Generator +|Contains the required templates and proceedings to construct questions. In order to do so, it delegates the Wikidata querying to the Wikidata extractor. When the data is returned, the question is formulated through templates. +|Wikidata Extractor +|Handles extraction and formatting of Wikidata’s output. It’s queries must cover all necessary information in order to construct the question(s), including not only the correct response, but also believable and coherent “decoy responses”. +|Questions Historic Controller +|Receives the generated questions, and sends them to the database. Besides, it also handles recovering them from the database and sending them where they are needed. (e.g: as response from an API call, or to the UI) +|User Statistics Controller +|Receives various information about the player’s performance in the match. There, some processing may occur before storing it in the database. Also handles retrieving the information and sending it where it’s needed (e.g: as response from an API call, or to the UI). +|Game Controller +|Handles all the game’s logic; where the user input’s processing takes place. It can request questions to the Questions Microservice, and also gather user statistics, to later be set to the User Statistics Controller. +|UI for the game and statistics +|Handles appeareance and presentation. Actions taken by the user are communicated to their respective controllers, that may respond accordingly. +|=== diff --git a/docs/src/06_runtime_view.adoc b/docs/src/06_runtime_view.adoc index e10f375b..5fe3e4e2 100644 --- a/docs/src/06_runtime_view.adoc +++ b/docs/src/06_runtime_view.adoc @@ -37,29 +37,115 @@ See https://docs.arc42.org/section-6/[Runtime View] in the arc42 documentation. **** -=== +=== User plays a match. Only one question batch is needed. +[plantuml,"Question generation 1",png] +---- + +@startuml +!theme vibrant +autonumber + +actor "User" as user + +user -> "Game Service": Begins game +"Game Service" -> "Question Service" : Requests n questions +"Question Service" -> "Wikidata REST API" : Requests information to create questions +"Wikidata REST API" -> "Question Service" : Returns information +"Question Service" -> "Question Service" : Creates questions +"Question Service" -> "Game Service" : Returns questions + +loop n times + "Game Service" -> user : Shows question + … + user -> "Game Service" : Responds question +end + +"Game Service" -> "Question Historic Service" : Sends the shown questions +"Game Service" -> "Player Statistics Service" : Sends the user's match data +@enduml + +---- + +In circumstances in which few questions are needed for the game, it may be possible to extract all of them in a batch without affecting performance and response times. Besides, extracting them this way opens up the possibility of using multiple threads to gather the data, greatly increasing performance. However, if the querying times are too high, this strategy may cause great delays while loading the game. A possible alternative is explained below: + +=== User plays a match. An example of dynamic question generation. + +[plantuml,"Question generation 2",png] +---- + +@startuml +!theme vibrant +autonumber + +actor "User" as user + +user -> "Game Service": Begins game +"Game Service" -> "Question Service" : Requests n questions +"Question Service" -> "Wikidata REST API" : Requests information to create questions +"Wikidata REST API" -> "Question Service" : Returns information +"Question Service" -> "Game Service" : Returns questions + +loop Until the game ends + loop n-k times + "Game Service" -> user : Shows question + ... + user -> "Game Service" : Responds question + end + + "Game Service" -> "Question Service" : Requests n questions + "Question Service" -> "Wikidata REST API" : Requests information to create questions + "Wikidata REST API" -> "Question Service" : Returns information + "Question Service" -> "Question Service" : Creates questions + "Question Service" -> "Game Service" : Returns questions + + loop k times + "Game Service" -> user : Shows question + ... + user -> "Game Service" : Responds question + end +end + +"Game Service" -> "Question Historic Service" : Sends the shown questions +"Game Service" -> "Player Statistics Service" : Sends the user's match data +@enduml + +---- -* __ -* __ +In cases where a lot of questions are needed, or wikidata querying has a great impact on performance, this alternative may prove to be convenient. By distributing the data fetching along the entire match, bottlenecks on performance will be reduced. Depending on the system load (or, optionally client device's specifications!) batch sizes may vary, adapting to maintain responsiveness. -It is possible to use a sequence diagram: +=== User consults its game statistics. -[plantuml,"Sequence diagram",png] +[plantuml,"Consult Statistics",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 + +@startuml +!theme vibrant +autonumber + +actor "User" as user + +user -> "Player Statistics Service" : Requests user data +"Player Statistics Service" -> "MongoDB Server" : Makes petition through REST API +"MongoDB Server" -> "Player Statistics Service" : Returns information +"Player Statistics Service" -> user : Shows data +@enduml + ---- -=== +=== User consults questions used in games. -=== ... +[plantuml,"Consult questions",png] +---- +@startuml +!theme vibrant +autonumber -=== +actor "User" as user + +user -> "Question Historic Service" : Requests user data +"Question Historic Service" -> "MongoDB Server" : Makes petition through REST API +"MongoDB Server" -> "Question Historic Service" : Returns information +"Question Historic Service" -> user : Shows data +@enduml +---- diff --git a/docs/src/07_deployment_view.adoc b/docs/src/07_deployment_view.adoc index 22b45c27..239f6db9 100644 --- a/docs/src/07_deployment_view.adoc +++ b/docs/src/07_deployment_view.adoc @@ -2,7 +2,6 @@ ifndef::imagesdir[:imagesdir: ../images] [[section-deployment-view]] - == Deployment View [role="arc42help"] @@ -56,39 +55,17 @@ Describe (usually in a combination of diagrams, tables, and text): For multiple environments or alternative deployments please copy and adapt this section of arc42 for all relevant environments. **** -_****_ +image::deployment.png["Deployment View"] + +In addition to what is shown in the diagram, we will also use Graphana and Prometheus during the production stage as code monitoring systems. Motivation:: -__ +Our goal is to run the application with Docker in a Azure VM. +However, during the production stage, each contributor will deploy the project locally. +Final product will be deployed in http://wiq.sytes.net/ (if that does not work, try http://20.77.37.219:3000/). Quality and/or Performance Features:: - -__ - -Mapping of Building Blocks to Infrastructure:: -__ - - -=== 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. -**** - -==== __ - -__ - -==== __ - -__ - -... - -==== __ - -__ +As for performance features, our current Azure MV has 2 GiB RAM and 1vCPU. +If that was not enough, we can always switch to an Oracle VM, which has better resources for free. +Each microservice has its own container aswell as its own database in case of needing one. \ No newline at end of file diff --git a/docs/src/08_concepts.adoc b/docs/src/08_concepts.adoc index 591ccf1f..e12e3995 100644 --- a/docs/src/08_concepts.adoc +++ b/docs/src/08_concepts.adoc @@ -56,18 +56,5 @@ See https://docs.arc42.org/section-8/[Concepts] in the arc42 documentation. **** -=== __ - -__ - - - -=== __ - -__ - -... - -=== __ - -__ +=== Domain model +image::08_domain_model.png["Domain model"] \ No newline at end of file diff --git a/docs/src/09_architecture_decisions.adoc b/docs/src/09_architecture_decisions.adoc index 51e9aad9..ee0816e2 100644 --- a/docs/src/09_architecture_decisions.adoc +++ b/docs/src/09_architecture_decisions.adoc @@ -33,3 +33,22 @@ See https://docs.arc42.org/section-9/[Architecture Decisions] in the arc42 docum There you will find links and examples about ADR. **** + +[options="header",cols="1,3,3"] +|=== +|Architecture decisions +|Advantages +|Disagvantanges + +|Use of React +|It is the most used javascript framework and there is a lot of documentation about it. +|All of us in the team will have to learn how to use it because we have never worked with it. + +|Use of JavaScript +|It is a language we have all used. +|It is a complex language that can cause us problems while other simpler languages could make our work easier. + +|Use of MongoDB +|Being a non-relational database, it is easier to use. In addition, it is used by large telecommunications companies. +|Non-relational databases are the ones with which we have the least experience. +|=== diff --git a/docs/src/10_quality_requirements.adoc b/docs/src/10_quality_requirements.adoc index 68475e80..13134a57 100644 --- a/docs/src/10_quality_requirements.adoc +++ b/docs/src/10_quality_requirements.adoc @@ -6,7 +6,6 @@ ifndef::imagesdir[:imagesdir: ../images] [role="arc42help"] **** - .Content This section contains all quality requirements as quality tree with scenarios. The most important ones have already been described in section 1.2. (quality goals) @@ -25,6 +24,9 @@ See https://docs.arc42.org/section-10/[Quality Requirements] in the arc42 docume **** +To describe the quality requirements that the game will have, we will use quality scenarios. Quality scenarios describe +the action to be performed by the user or the system (stimulus) in order to generate a response to the interaction. + === Quality Tree [role="arc42help"] @@ -43,9 +45,10 @@ The quality tree is a high-level overview of the quality goals and requirements: In any case the tree should include links to the scenarios of the following section. - **** +image::QualityTree.png[] + === Quality Scenarios [role="arc42help"] @@ -71,3 +74,40 @@ more precisely down to a level of scenarios that can be discussed and evaluated. .Form Tabular or free form text. **** + +Quality scenarios, also known as use cases, are detailed descriptions of situations in which a user interacts with +a system and describe the expected outcomes along with the conditions of the environment in which the interaction +occurs. + +[options="header",cols="1,3,3,1"] +|=== +|Quality goal +|Motivation +|Usage Scenarios +|Priority + +|Usability +|The ease of interaction with the user should be enhanced through intuitive and simple interfaces to enhance the user experience. +|Users will be able to understand how the game works thanks to the clarity of its rules and ease of navigation. +|High + +|Diversity +|The questions provided by the application will be of various topics. +|The user must correctly answer questions on different topics. This will improve the user experience and maintain the interest of the participants. +|High + +|Integrity +|The game must be played without errors. +|The answer determined as correct for each question by the system shall be the one that is actually correct. +|Medium + +|Interactivity +|The user must answer a series of questions in which the user must select the correct answer in each case. +|For each of the questions, the user must select the correct answer from those provided by the system. +|Medium + +|Privacy +|In order to be able to play, the user must log in to the application. +|Only the user who created/owns the account will have access to it (unless he/she gives someone else his/her credentials). +|Low +|=== \ No newline at end of file diff --git a/docs/src/11_technical_risks.adoc b/docs/src/11_technical_risks.adoc index dc5575fc..b488dee0 100644 --- a/docs/src/11_technical_risks.adoc +++ b/docs/src/11_technical_risks.adoc @@ -23,3 +23,11 @@ List of risks and/or technical debts, probably including suggested measures to m See https://docs.arc42.org/section-11/[Risks and Technical Debt] in the arc42 documentation. **** + +[options="header"] +|=== +|Risk |Consequence + +|Knowledge of REACT |It is a framework that no team member has used before. Therefore, we have all had to learn how to use it. +|Internal group conflicts |Lack of free time for team members makes group work difficult. +|=== \ No newline at end of file diff --git a/docs/src/12_glossary.adoc b/docs/src/12_glossary.adoc index 192b2353..fcc1b635 100644 --- a/docs/src/12_glossary.adoc +++ b/docs/src/12_glossary.adoc @@ -32,11 +32,12 @@ See https://docs.arc42.org/section-12/[Glossary] in the arc42 documentation. [cols="e,2e" options="header"] |=== -|Term |Definition - -| -| - -| -| +|Term |Definition + +|MongoDB |NoSQL database system that, instead of storing data in tables as a relational database does, stores data in JSON-like documents with a flexible schema. +|REACT |Open source JavaScript library developed by Facebook to build interactive and responsive user interfaces (UI). It is one of the most popular tools for modern web application development. +|Usability |Ease with which users can interact with a product, system or application to achieve their objectives effectively, efficiently and satisfactorily. +|Dynamic question generation | There may be circumstances where pre-generating the questions isn't feasible. So instead, questions can be generated while the user is playing the game and answering questions. +|Decoy answer | For questions that offer multiple options to select the correct answer from, it will be necessary to generate believable incorrect answers, that match the topic and theme of the question. For example, when asking about the longest river in Egypt, along with the correct answer (The Nile) some other river names of the country could be chosen for alternatives. +|Question template | General structure of a question, which can or cannot transcend topics. For example, valid templates for questions could be: "What's the tallest mountain in ?" "What is ?" "Who invented ?" |===