Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Documentation 4 solution strategy #32

Merged
merged 7 commits into from
Feb 23, 2025
81 changes: 81 additions & 0 deletions docs/src/04_solution_strategy.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -32,3 +32,84 @@ See https://docs.arc42.org/section-4/[Solution Strategy] in the arc42 documentat

****
endif::arc42help[]



=== Technology decisions

For the development of the following project we have decided to use the following technologies.
Many of them have been based on the project template provided by the teachers, as we do not yet have sufficient depth of knowledge in these technologies (web development libraries and frameworks, docker...).

* *JavaScript*: Programming language mainly focused on web development on the client side, mainly used to provide interactivity to a web page.
* *React*: Open source JavaScript library used to create graphical user interfaces.
* *Node.js*: Execution environment using Javascript for server-side, rather than client-side.
* *Express*: Web framework for Node.js to simplify the implementation of web applications.
* *MongoDB*: NoSQL-like database, which stores data in a JSON-like format and favours application scalability and flexibility when it comes to handling unstructured data.
* *GitHub*: Web application used in software development that allows code to be written, stored, organised by version and collaborated on by different members of a team using Git.
* *Docker*: Tool that allows you to create, deploy and run applications in containers, testing that the application works in different environments.


=== Top-level decomposition of the system

An architecture using microservices has been chosen for this project, so that each module focuses on a specific task. Some of the modules will be the following:

* *User management service*: It will manage the creation of new users, their login, store their game history ...

* *Game service*: It will generate questions and possible answers from the chosen image.

* *Chat service*: It will use the LLM to help the user with hints to facilitate the game.

* *Wikidata connection service*: It will get the image and the necessary information from Wikidata.

* *Service to export user information*: It will allow access to user information stored in the system through an API.

* *Service to export the information of the questions*: It will allow access to the information of the questions through an API.


=== Decisions taken to achieve quality goals

|===

| Quality goal | Decision made

|*Usability*
|To ensure the usability of the application, an intuitive and simple interface will be designed so that the user has no doubts about what action to take at any moment.
In addition, a sufficiently legible font with an appropriate size and weight will be used.
Finally, the application will be made responsive to facilitate its use on different devices.

|*Maintainability*
|In order to facilitate the maintainability and expansion of the application, we will try to follow the good practices for software development acquired in other previous subjects of the degree.
An example of this will be some of the SOLID principles previously studied, such as the Single responsibility principle or the Open/closed principle.

|===


=== Organizational decisions

|===

| Organizational goal | Tool chosen | Description

| *Task distribution*
| *GitHub Issues*
| It will be used to assign each of the tasks into which the project is divided to a member of the team.
These tasks will be distributed equally among the different members of the team, trying to adjust to the knowledge and tastes of each one.

| *Changes approval*
| *Pull requests*
| Once each task is finished, a pull request will be made so that at least one component of the team other than the developer of the task will review it before merging it to the main branch of the project.

| *Project timeline*
| *GitHub Projects*
| This will be used to track the development of the project and be able to see which parts are completed and which are not, as well as which parts are currently being worked on.

| *Communication*
| *Weekly meetings*
| Meetings will be held on a weekly basis to see what is the status of the project, what has been done and what remains to be done.

| *Documentation*
| *AsciiDoc*
| We have chosen Asciidoc as the primary documentation tool.
This decision is largely due to the ease and intuitiveness of deploying documentation using the tools provided by the Asciidoc ecosystem.

|===
Loading