1. Introduction and Goals
1.1. Requirements Overview
+The system will follow the functionality of the "Saber y Ganar" TV program, and so it will allow the users to select an answer between some options. +The questions and answers will be automatically generated using the WikiData API, that will also determine which of the answers is in fact the correct one. +The system will also store the historical data of the users and will be accessible through the web.
+1.1. Requirements Overview
1.2. Quality Goals
+| Quality attribute | +Scenario | +
|---|---|
Usability |
+The user must be able to understand the function of the application before the minute mark. |
+
Performance |
+The application will be able to operate within reasonable response times, taking into account the already present waiting times (time to answer, between questions, etc). |
+
Security |
+The information stored about a user can only be accessed by said user, never others. |
+
Robustness |
+The application will be able to handle any user error that could happen at runtime. |
+
Accessibility |
+The application will be accessible by all users, even if the suffer from visual impediments such as colorblindness. |
+
1.3. Stakeholders
<Role-1>
<Contact-1>
<Expectation-1>
Development team
Lucía Ruiz Núñez, Mario Junquera Rojas, Jorge Cano Martinez, Laura Gómez Menéndez, Ahmet Erdem Yabaci, Daniel Sinne Argüelles
A working, tested and well documented application.
<Role-2>
<Contact-2>
<Expectation-2>
Professors
Pablo González
Provide guidance and help during the whole development, as well as evaluate the final product.
RTVE
RTVE
A working and robust application that the users can enjoy using.
Users
Users
A working and enjoyable application to play with.
1.3. Stakeholders
2. Architecture Constraints
2.1. Technical constraints
+-
+
- Wikidata +
-
+
The information needed must be got from this central storage.
+
+ - GitHub +
-
+
All the communication and code-sharing will be done by GitHub, so all the work will be recorded there.
+
+ - API +
-
+
Give access about users and generated questions through an API.
+
+
2.2. Organizational constraints
+-
+
- Team size +
-
+
The team is formed by 6 people.
+
+ - Meetings +
-
+
There will be a meeting every week where will be discussions about problems we could have, make an overview about the work done and the work to be done among other things.
+
+ - Time +
-
+
There will be several deliveries and the entire project must be developed and finished in the semester of the course.
+
+ - Budget +
-
+
There will not be any financial support.
+
+
2.3. Political constraints
+-
+
- Data protection +
-
+
The private information of the users must be stored securely.
+
+
2.4. Conventions
+-
+
- English +
-
+
As this course is taught in English, the project must be also developed in that language.
+
+ - ARC42 +
-
+
The documentation must follow the arc42 template
+
+
3. System Scope and Context
3.1. Business Context
<Diagram or Table>
+
+<optionally: Explanation of external domain interfaces>
+Table for entities, inputs and outputs
| Entity | +Inputs | +Outputs | +
|---|---|---|
User Interface UI |
+Users request a question to be shown |
+The question and the set of answers corresponding to that question are presented |
+
Question Generation |
+User requests a question and the information extracted from wikidata |
+The question and the set of answers corresponding to that question are created |
+
Wikidata API |
+Some part or topic related to the creation of a question |
+Some concepts that will facilitate the creation of the question such as wrong answers |
+
3.2. Technical Context
@@ -831,14 +1005,26 @@3.2. Technical Context
+The user will access the web application via the HTTPs protocol
+<Diagram or Table>
+The home will allow user to be redirected to the login and authentication phase via the HTTPs protocol
<optionally: Explanation of technical interfaces>
+The login will allow the user to enter the game and so the question generation will start, this will happend through a redirect
<Mapping Input/Output to Channels>
+The login will access the database directly via TCP/IP protocol
4.1. Technology decisions
SpringBoot : An extension of the Spring framework for creating Java applications. SpringBoot offers many preconfigurations that accelerate the code production process.
Wikidata access library :
+Wikidata Toolkit : Wikidata Toolkit is a Java library for accessing Wikidata and other Wikibase installations. It can be used to create bots, to perform data extraction tasks (e.g., convert all data in Wikidata to a new format), and to do large-scale analyses that are too complex for using a simple SPARQL query service.
Docker :
+Docker : Docker provides tools and a runtime environment to manage these containers efficiently, allowing developers to build, ship, and run applications consistently across different environments.
Oracle DBMS :
+MySql : MySQL is an open-source relational database management system that uses SQL for managing and manipulating data.
Mongo DB :
+Mongo DB : MongoDB is a popular open-source NoSQL database management system that stores data flexible, JSON-like documents with dynamic schemas.
4.2. Top-level Decomposition
4.2.1. Architectural Patterns
- +-
+
-
+
Microservices : Selected as our main architecture. We will have various small independent services that interact between them to support all the fuctionalities of the web application
+
+
4.2.2. Design Patterns
-
-
Façade : Pattern used to communicate between different parts of the back-end of the web-application
+Façade : Pattern used to communicate between different parts of the whole application (APIs)
4.2.2. Design Patterns
4.3. Decisions for achieving quality goals
+Quality Goal |
+Decision |
+
Usability |
+We will try to make some rounds of usability tests with people outside of the development team |
+
Performance |
+Our goal is to have a system that will response under 1 second to all petitions, however the consecuences of peak times are unknow |
+
Security |
+Using HTTPS, applying input validation, encripting sensible information (As we face new security failures we will add measures) |
+
Robustness |
+We will apply different mechanism to reduce the risks that could crash the application |
+
Accesibility |
+Testing our User Interface with third party tools like Google’s Lighthouse in order to correct them |
+
Will be updated whenever we find a new quality goal or we change the approach to achieve it
4.4. Organizational Decisions
+Third Party Product |
+Reason |
+
Git |
+Easy to use distributed version control application |
+
Github |
+Web-based platform for hosting and managing Git repositories. It also provides different services like: a wiki, issues, github actions and many more |
+
Microsoft Azure |
+Cloud service use for creating virtual machines in order to deploy the application |
+
5. Building Block View
5.1. Whitebox Overall System
-5.1. Scope and Context
+Here you describe the decomposition of the overall system using the following white box template. It contains
+
+-
+
- Motivation +
-
+
In this level of descomposition of our system we present an overall view of it. This captures the whole system interaction at once without much detail.
+
+ - Contained Building Blocks +
-
+
-
-
an overview diagram
-
- -
-
a motivation for the decomposition
+WIQ: Resembles the whole system. Manages the interactions with the users and communicates with the outside services (wikidata).
- -
-
black box descriptions of the contained building blocks. For these we offer you alternatives:
+
+ -
-
5.2. Level 1
+
+-
+
- Motivation +
-
+
In this level of descomposition we separate the main services of our system showing how not every part of the system communicates with the exterior.
+
+ - Contained Building Blocks +
-
+
-
-
use one table for a short and pragmatic overview of all contained building blocks and their interfaces
+WIQ HOME : Service which will collect the user interaction and redirect it to the corresponding service.
-
-
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).
-
-
WIQ USER MANAGEMENT : Service that will manage the user information, login, authentication, etc.
- -
(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.
+WIQ QUESTION GAME Service that will generate and show the different questions for our game.
-
-
<Overview Diagram>
+5.3. Level 2
+
+- Motivation
-
-
<text explanation>
+In this level of descomposition of the system we start to identify the different microservices of the system.
- Contained Building Blocks
-
-
<Description of contained building block (black boxes)>
-
- - Important Interfaces -
-
-
<Description of important interfaces>
-
-
5.1.1. <Name black box 1>
- -5.1.2. <Name black box 2>
+6. Runtime View
+5.2. Level 2
- -5.2.1. White Box <building block 1>
- -<white box template>
-5.2.2. White Box <building block 2>
-<white box template>
-…
-5.2.3. White Box <building block m>
-<white box template>
-5.3. Level 3
- -5.3.1. White Box <_building block x.1_>
- -<white box template>
-5.3.2. White Box <_building block x.2_>
-<white box template>
-5.3.3. White Box <_building block y.1_>
-<white box template>
-6. Runtime View
-The runtime view describes concrete behavior and interactions of the system’s building blocks in form of scenarios from the following areas:
+The runtime view describes concrete behavior and interactions of the system’s building blocks in form of scenarios from the following areas:
-
@@ -1327,37 +1435,68 @@
6. Runtime View
6.1. <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.>
-
-
6.1. Runtime Scenario: Retrieval of questions
+
It is possible to use a sequence diagram:
6.2. Runtime Scenario: Answer questions
+
+6.3. Runtime Scenario: Login successful
+
+6.4. Runtime Scenario: Login failure
+
6.2. <Runtime Scenario 2>
- +6.5. Runtime Scenario: Signup successful
+
+6.3. …
- +6.6. Runtime Scenario: Signup failure
+
+6.7. Runtime Scenario: Wikidata error
+
+6.4. <Runtime Scenario n>
+6.8. Runtime Scenario: DB error
+
+7.1. Infrastructure Level 1
<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>
-
-
TBD
7.2. Infrastructure Level 2
7.2.1. <Infrastructure Element 1>
-<diagram + explanation>
-7.2.2. <Infrastructure Element 2>
-<diagram + explanation>
-…
-7.2.3. <Infrastructure Element n>
<diagram + explanation>
+TBD
8. Cross-cutting Concepts
8. Cross-cutting Concepts
8.1. <Concept 1>
+8.1. Domain concepts
+8.1.1. Domain model
+
+8.2. User experience concepts
+8.2.1. Consistency
<explanation>
+Design elements should be consistent throuhgout the design so that the user does not get confused.
+8.2.2. Progress indicators
+Provide the users with some sort of progress indicator within the quiz. This helps users understand their current position in the quiz.
+8.2.3. Feedback on correct or incorrect answers
+Provide immediate feedback to users after they answer each question, indicating whether their response was correct or incorrect.
+8.2.4. Internationalization
+Provide other language options other than english.
+8.2. <Concept 2>
+8.3. Security and Safety concepts
+8.3.1. Secure storage
<explanation>
+Make sure to never store the user passwords in plain text, to secure the users data.
+8.3.2. Data encryption
…
+Utilize encryption techniques to secure data in any transmission between actors of owr application.
+8.4. Architecture and design patterns concepts
+8.4.1. Microservices
+The microservices pattern combines design patterns to create multiple services that work interdependently to create a larger application. Because each application is small, it’s easier to update them when needed. We will be using this pattern during development.
+8.5. Under-the-hood concepts
+TBD
+8.6. Developement concepts
+8.6.1. Testing
+TBD
+8.6.2. Deployment
+TBD
+8.6.3. Task branching
+We should create 1 branch per task and merge them as soon as possible.
+8.3. <Concept n>
+8.7. Operational concepts
+TBD
+<explanation>
+<All concepts are subject to change>
8.3. <Concept n>
9. Architecture Decisions
The application will be carried out following a Microservices architecture.
+The Rest API in charge of comunicating with WikiData will be coded using Java.
+(More details to de added)
10. Quality Requirements
10.1. Quality Tree
+
+