# Ejercicio de Aplicación

**Arquitectura de Software**
**Grupo**: Grupo N7A - Equipo 3
**Integrantes**:
* #173630 - Fabio Orlinski
* #202393 - Felipe Osano
* #68694 - Martín Vidal
* #193254 - Daniela Waldeck
* #180110 - Sebastián Zawrzykraj
* #148894 - Oliver Cortinas

---

Se identifican los siguientes atributos de calidad:

- Performance
- Modificabilidad/Mantenibilidad
- Interoperabilidad/Integrabilidad
- Escalabilidad

#### **Performance:**
La performance es crítica debido a la naturaleza del sistema que maneja datos en tiempo real y atiende a un gran número de usuarios simultáneamente.

Específicamente:

* ***Tiempo de Respuesta***: La funcionalidad de consulta de horarios y de visualización en tiempo real de la ubicación de los ómnibus requiere tiempos de respuesta rápidos (entre 0.5 y 1 segundo para las consultas y actualizaciones cada 30 segundos para la posición del ómnibus). Esto asegura una experiencia de usuario fluida y mejora la eficacia del sistema de transporte.
* ***Concurrencia***: Con hasta 50,000 usuarios concurrentes durante las horas pico y 800 ómnibus transmitiendo su posición, el sistema debe manejar altas cargas sin degradar la calidad del servicio.

#### **Modificabilidad/Mantenibilidad:**
La modificabilidad es esencial para permitir la evolución continua del sistema sin interrupciones significativas y para adaptarse a cambios externos, como:

* ***Flexibilidad frente a Cambios***: La integración con APIs de terceros para datos de horarios y paradas implica que cualquier cambio en estas APIs no debe afectar la operación del servicio TripLogic. Esto requiere una arquitectura que aísle los cambios y permita adaptaciones rápidas.
* ***Costo y Esfuerzo de Cambios***: Mantener el sistema actualizado y corregir defectos de manera eficiente sin introducir problemas en otras áreas del sistema.

De este atributo se desprenden inevitablemente **Interoperabilidad** y **Escalabilidad**

#### **Interoperabilidad/Integrabilidad**
Este atributo asegura que los diferentes componentes y sistemas externos trabajen juntos de manera coherente y eficiente:

* ***Comunicación entre Componentes***: El sistema debe integrarse sin problemas con diversas plataformas y servicios, utilizando estándares abiertos como HTTPS y APIs REST para las comunicaciones. Esto facilita la integración y garantiza la compatibilidad entre sistemas dispares.
* ***Adaptabilidad a Estándares Externos***: Adaptarse a diferentes estándares de comunicación impuestos por proveedores de datos o regulaciones de tránsito.

#### **Escalabilidad**
Dada la amplia gama de usuarios y la intensidad de los datos procesados, la escalabilidad es crucial para:

* ***Manejo de Carga Dinámica***: La capacidad de escalar recursos según sea necesario para manejar variaciones en la carga de usuarios, especialmente durante horas pico y eventos especiales.
* ***Expansión Futura***: Permitir el crecimiento del sistema, tanto en términos de número de usuarios como de expansión geográfica o integración de nuevas funcionalidades sin degradar el rendimiento o la usabilidad.

Cada uno de estos atributos contribuye directamente a la robustez, eficiencia y sostenibilidad del sistema, asegurando que el sistema no solo cumpla con los requisitos actuales sino que también pueda adaptarse y escalar en respuesta a futuras necesidades y desafíos.

ADRs - Decisiones

|ADR 001: | Adopción del Patrón CQRS |
| -------- | -------- |
| Título: | Adopción del Patrón Command Query Responsibility Segregation (CQRS) |
| Estado: | Aceptado |
|Contexto: | El sistema enfrenta desafíos relacionados con el manejo de altas cargas de lectura y escritura, especialmente con visualizaciones en tiempo real y acceso a datos históricos voluminosos.|
|Decisión: |Implementar el patrón CQRS para separar las operaciones de lectura y escritura en diferentes modelos, permitiendo optimizaciones específicas para cada tipo de operación.|
|Consecuencias: |Mejora en la performance de las consultas y las actualizaciones, simplificación de la lógica en cada lado (comando y consulta), y reducción de la carga en un único sistema de almacenamiento mejorando asi la escalabilidad y performance.|

|ADR 002: |Implementación de un Bus de Eventos|
| -------- | -------- |
|Título: |Implementación de un Bus de Eventos para Integración de Servicios|
|Estado:| Aceptado|
|Contexto:| Necesidad de desacoplar los componentes del sistema para mejorar la escalabilidad y facilitar el desarrollo y mantenimiento independiente.|
|Decisión:| Introducir un bus de eventos para manejar la comunicación entre los diferentes servicios y componentes, utilizando el patrón Publisher/Subscriber.|
|Consecuencias:| Reducción del acoplamiento directo entre componentes, mejorando la modificabilidad y la capacidad de escalar los servicios de manera independiente.|

|ADR 003:| Estrategia de Caché para Datos en Tiempo Real|
| -------- | -------- |
|Título:| Implementación de Caché para Mejorar la Performance de Consultas en Tiempo Real|
|Estado:| Aceptado|
|Contexto:| La alta demanda de datos en tiempo real por parte de usuarios móviles requiere un acceso rápido y eficiente a la información de ubicación de los autobuses.|
|Decisión:| Implementar un sistema de caché que almacene temporalmente los datos más solicitados, reduciendo así la carga sobre la base de datos principal y mejorando los tiempos de respuesta, aplicando la tactica de mantenin multiple copies of data.|
|Consecuencias:| Mejora significativa en la performance para el usuario final; sin embargo, es necesario gestionar la coherencia de la caché para asegurar que los datos no estén desactualizados.|

|ADR 004:| Utilización de APIs de Datos Abiertos|
| -------- | -------- |
|Título:| Integración con Proveedor de Datos Abiertos mediante APIs REST|
|Estado:| Aceptado|
|Contexto:| La necesidad de integrar información actualizada y confiable sobre horarios y paradas de autobuses de varias compañías, ofrecida por un proveedor de datos abiertos|
|Decisión:| Utilizar APIs REST proporcionadas por el Proveedor de Datos Abiertos para acceder a datos externos necesarios para las funcionalidades del sistema, utilizando la tactica de split module. |
|Consecuencias:| Dependencia de un servicio externo, lo cual implica riesgos relacionados con la disponibilidad y la actualización de estos datos, pero permite mantener la información del sistema actualizada y precisa sin necesidad de mantenimiento directo de estos datos, esto mejora los atributo de calidad de modificabilidad y integrabilidad |

## Diagrama UML con los cambios propuestos