Skip to content

Commit

Permalink
Merge branch 'develop' of https://github.com/Arquisoft/wiq_es1d into …
Browse files Browse the repository at this point in the history 
…develop
  • Loading branch information
@AlvaroGlezC
AlvaroGlezC committed May 14, 2024
2 parents 8ac9123 + 641e324 commit 07f7236
Show file tree
Hide file tree
Showing 2 changed files with 24 additions and 95 deletions.
44 changes: 14 additions & 30 deletions docs/src/09_architecture_decisions.adoc
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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.
|===
75 changes: 10 additions & 65 deletions docs/src/10_quality_requirements.adoc
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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
|===

0 comments on commit 07f7236

Please sign in to comment.