From c7c6ba2db40ae35852829e981dab116b28549d16 Mon Sep 17 00:00:00 2001 From: AGC <158510532+AlvaroGlezC@users.noreply.github.com> Date: Mon, 13 May 2024 23:11:58 +0200 Subject: [PATCH 1/2] #1 Update 09_architecture_decisions.adoc --- docs/src/09_architecture_decisions.adoc | 44 ++++++++----------------- 1 file changed, 14 insertions(+), 30 deletions(-) diff --git a/docs/src/09_architecture_decisions.adoc b/docs/src/09_architecture_decisions.adoc index 51e9aad..0b4ecca 100644 --- a/docs/src/09_architecture_decisions.adoc +++ b/docs/src/09_architecture_decisions.adoc @@ -3,33 +3,17 @@ ifndef::imagesdir[:imagesdir: ../images] [[section-design-decisions]] == Architecture Decisions - -[role="arc42help"] -**** -.Contents -Important, expensive, large scale or risky architecture decisions including rationales. -With "decisions" we mean selecting one alternative based on given criteria. - -Please use your judgement to decide whether an architectural decision should be documented -here in this central section or whether you better document it locally -(e.g. within the white box template of one building block). - -Avoid redundancy. -Refer to section 4, where you already captured the most important decisions of your architecture. - -.Motivation -Stakeholders of your system should be able to comprehend and retrace your decisions. - -.Form -Various options: - -* ADR (https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions[Documenting Architecture Decisions]) for every important decision -* List or table, ordered by importance and consequences or: -* more detailed in form of separate sections per decision - -.Further Information - -See https://docs.arc42.org/section-9/[Architecture Decisions] in the arc42 documentation. -There you will find links and examples about ADR. - -**** +|=== +|Decision|Details|Advantages +|Hexagonal architecture|At the beginning of the project I decided that the backend would be governed by a hexagonal architecture, this because of the great power that this type of structure has, allowing the use of microservices and the great decoupling that it has|One of the advantages that we found is that this project is for the subject of Software Architecture, so adding a hexagonal architecture to the project gives it more strength. In addition, the intrinsic advantages of a hexagonal architecture, which are decoupling from the database, web and drivers, since the project does not care about the implementation of these, focus more on the application domain, decouple the layers of the backend, this leads to that it was easier for us to perform tests and modifications added. +|Design architecture | We will use a hexagonal structure oriented MVC pattern for the API and the view-component model in the frontend | The main advantage is that these are fairly well documented and easy to assemble. +|Database|We chose MySQL to store all the information|Familiar technology that does not leave the already known stablishment +|Mockito|Used for unit testing|big power to mock up data +|React|Utilizamos los Hooks y funcionalidades de React en frontend, aprovechando sus utilidades porque es intuitivo +|Typescript|Typescript was used to be able to type the variables in frontend| That is its main advantage, that typing, that gives a lot of value to the code, avoiding a lot of errors. +|Internationalisation|Internationalisation of documentation in English and the application in English and Spanish|With this internationalisation we greatly improve accessibility|Time can be a factor and internationalisation in two languages can be very time consuming. +|MUI| MUI is used because of the facilities given by some of its components| It´s a good friend of react. +|SCSS|Used to make our application more beautiful and to make all pages elements stay in its positions.|Is a known language if you know CSS. +|Seeding the database in Docker|the database will be seed in the build of his image| No need to worry about empty database deployments +|Azure|The decision to use Azure was that the school give support to spend money in azure and because azure give support to docker containers and images.| Save images and run containers in the same platform. +|=== From 641e3241d844877bd31aca377642af7a3d42a3d8 Mon Sep 17 00:00:00 2001 From: AGC <158510532+AlvaroGlezC@users.noreply.github.com> Date: Tue, 14 May 2024 19:25:16 +0200 Subject: [PATCH 2/2] #1 Update 10_quality_requirements.adoc --- docs/src/10_quality_requirements.adoc | 75 ++++----------------------- 1 file changed, 10 insertions(+), 65 deletions(-) diff --git a/docs/src/10_quality_requirements.adoc b/docs/src/10_quality_requirements.adoc index 68475e8..12dfbba 100644 --- a/docs/src/10_quality_requirements.adoc +++ b/docs/src/10_quality_requirements.adoc @@ -3,71 +3,16 @@ ifndef::imagesdir[:imagesdir: ../images] [[section-quality-scenarios]] == Quality Requirements - -[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) - -Here you can also capture quality requirements with lesser priority, -which will not create high risks when they are not fully achieved. - -.Motivation -Since quality requirements will have a lot of influence on architectural -decisions you should know for every stakeholder what is really important to them, -concrete and measurable. - - -.Further Information - -See https://docs.arc42.org/section-10/[Quality Requirements] in the arc42 documentation. - -**** - -=== Quality Tree - -[role="arc42help"] -**** -.Content -The quality tree (as defined in ATAM – Architecture Tradeoff Analysis Method) with quality/evaluation scenarios as leafs. - -.Motivation -The tree structure with priorities provides an overview for a sometimes large number of quality requirements. - -.Form -The quality tree is a high-level overview of the quality goals and requirements: - -* tree-like refinement of the term "quality". Use "quality" or "usefulness" as a root -* a mind map with quality categories as main branches - -In any case the tree should include links to the scenarios of the following section. - - -**** +image:10_quality_tree.png["Quality Requirements"] === Quality Scenarios -[role="arc42help"] -**** -.Contents -Concretization of (sometimes vague or implicit) quality requirements using (quality) scenarios. - -These scenarios describe what should happen when a stimulus arrives at the system. - -For architects, two kinds of scenarios are important: - -* Usage scenarios (also called application scenarios or use case scenarios) describe the system’s runtime reaction to a certain stimulus. This also includes scenarios that describe the system’s efficiency or performance. Example: The system reacts to a user’s request within one second. -* Change scenarios describe a modification of the system or of its immediate environment. Example: Additional functionality is implemented or requirements for a quality attribute change. - -.Motivation -Scenarios make quality requirements concrete and allow to -more easily measure or decide whether they are fulfilled. - -Especially when you want to assess your architecture using methods like -ATAM you need to describe your quality goals (from section 1.2) -more precisely down to a level of scenarios that can be discussed and evaluated. - -.Form -Tabular or free form text. -**** +|=== +|Quality goal|Scenario|User Priority|Developer Priority +| Maintainability | The app is built following architectural and coding architecture and design patterns in a way that simplifies the understanding of the code and the code itself, making it easy to make changes to the code.| Low | High +| Scalability | The product must continue evolving without neglecting the other requirements, meaning it should not stagnate. However, for this project, once the delivery is completed, it would only represent an initial version for future developments | Medium | Medium +| Security | Keycloak will be used as an external framewirk for backend and frontend security, as well as for user authentication | High | High +| Performance |the app is able to respond quickly to different user requests | High | High +| Usability | Users are able to navigate, play and visualise the different elements of the site in a comfortable, simple and easy way | High | Medium +| Reliability | The application does not crash or crashes strangely | High | High +|===