#1 Update 03_system_scope_and_context.adoc

docs/src/03_system_scope_and_context.adoc

@@ -3,73 +3,34 @@ ifndef::imagesdir[:imagesdir: ../images]
 [[section-system-scope-and-context]]
 == System Scope and Context
 
+image:03BusinessContext.png["Business Context diagram"]
 
-[role="arc42help"]
-****
-.Contents
-System scope and context - as the name suggests - delimits your system (i.e. your scope) from all its communication partners
-(neighboring systems and users, i.e. the context of your system). It thereby specifies the external interfaces.
-
-If necessary, differentiate the business context (domain specific inputs and outputs) from the technical context (channels, protocols, hardware).
-
-.Motivation
-The domain interfaces and technical interfaces to communication partners are among your system's most critical aspects. Make sure that you completely understand them.
-
-.Form
-Various options:
-
-* Context diagrams
-* Lists of communication partners and their interfaces.
-
-
-.Further Information
-
-See https://docs.arc42.org/section-3/[Context and Scope] in the arc42 documentation.
-
-****
-
-
-=== Business Context
-
-[role="arc42help"]
-****
-.Contents
-Specification of *all* communication partners (users, IT-systems, ...) with explanations of domain specific inputs and outputs or interfaces.
-Optionally you can add domain specific formats or communication protocols.
-
-.Motivation
-All stakeholders should understand which data are exchanged with the environment of the system.
-
-.Form
-All kinds of diagrams that show the system as a black box and specify the domain interfaces to communication partners.
-
-Alternatively (or additionally) you can use a table.
-The title of the table is the name of your system, the three columns contain the name of the communication partner, the inputs, and the outputs.
-
-****
-
-**<Diagram or Table>**
-
-**<optionally: Explanation of external domain interfaces>**
+[options = "header",cols="1,1,1"]
+|===
+| Entity | Input | Output
+| User | The user will interact with the application through a computer or other device. The user will see the frontend of the application and send requests to the backend | The output is represented in many parts of the system, reaching almost every point in the system
+| SYG Frontend web | It is the system with which the user interacts, it receives the requests sent by the user through the interface  | It processes incoming web requests and receives the data through SYG's backend API. Once it has the requested information, it displays it to the user through the interface
+| SYG Backend API | It is the API in charge of all the business logic, it interacts with the frontend, database and external APIs  | It is the API in charge of all the business logic, it interacts with the frontend to return the data of the received requests and with the database and external APIs to get the data needed for your requests.
+| Database (MySQL) | Queries, information requests | Storaged and consistent data responding to the system needs
+|===
 
 === Technical Context
 
-[role="arc42help"]
-****
-.Contents
-Technical interfaces (channels and transmission media) linking your system to its environment. In addition a mapping of domain specific input/output to the channels, i.e. an explanation which I/O uses which channel.
-
-.Motivation
-Many stakeholders make architectural decision based on the technical interfaces between the system and its context. Especially infrastructure or hardware designers decide these technical interfaces.
-
-.Form
-E.g. UML deployment diagram describing channels to neighboring systems,
-together with a mapping table showing the relationships between channels and input/output.
-
-****
-
-**<Diagram or Table>**
-
-**<optionally: Explanation of technical interfaces>**
-
-**<Mapping Input/Output to Channels>**
+Our application is divided into frontend (React with node.js), backend (restapi with maven), testing (e2e, integration and unit Test). In backend, we use a hexagonal architecture improving the security and performance of the website, with which we get an immutable domain for the rest of the components that can attach to this domain. The system is made with the idea of microservices in mind, using docker containers, for the deployment of these microservices used both in the project and in testing (e2e and integration test), for the unit tests Mock is used. On the frontend, the React framework is used along with typescript and MUI, together with its own styles in Sass.
+The database is using MySQL, although with an immutable domain it could support other databases.
+
+image:03TechnicalContext.png["Technical Context diagram"]
+
+[options = "header",cols="1,1"]
+|===
+| Technology | Explication 
+| MySQL | Database used for accessing and modifying data at the request of the relevant restapi
+| Keycloak | Library for securing and authentication of the whole application
+| React | Technology used for the frontend integration of our application
+| TypeScript | Acompaña a react en la construccion del frontend, dando soprote y tipado a react
+| SCSS | A much more complete branch of CSS, used in the application's design styles
+| Grafana and Prometeus | They are services used for monitoring the system.
+| Postman | It is used for testing the backend functionlity
+| Docker |  Use to divide the application in multiple services (containers) based in the microservices idea. We have a container for each service (Frontend, Backend, Database, Keycloak, Grafana, Prometheus, e2e backend test, integration backend tests)
+| Azure |  Is the platform used for the system deployment. It was chosen because of its extensive support and support for deployment through images, where you can make a record of these images, plus the school gives a certain amount of money for deployment through azure
+|===