Acta 24/05/20: Planeación y avance Sprint 4

• Asistentes: Santiago Bolaños, Daniel García, Mario Hurtado, Nicolás Potes.
• Reporta: Mario Hurtado.

Tareas y responsabilidades:

-Actualizar los diagramas de componentes y despliegue en LucidChart para reflejar las decisiones de latencia y facilidad de mantenimiento tomadas. Adicionalmente, modificar los diagramas para satisfacer lo planteado con los ASR's.

-Implementar los elementos de arquitectura (de los modelos) que sean necesarios para la alineación con los ASR's escogidos.

-Hacer el despliegue de por lo menos cuatro (4) microservicios implementados en dos (2) tecnologías diferentes.

-Documentar y revisar los escenarios de prueba de cada ASR.

-Implementar al menos un patrón de microservicios diferente a los de "descomposición por capacidades y subdominios".

-Reportar y analizar los resultados de las pruebas de los escenarios.

-Recibir comentarios por partes de los instructores para poder mejorar la solución en la medida de lo posible.

-Argumentar la selección de tecnologías y frameworks que se usaron en el experimento: Implementación de modelos y pruebas.

-Actualizar la wiki a medida que se realicen cambios en el cualquier aspecto del Sprint.

ASR's:

Facilidad de mantenimiento:

1. Como desarrollador, dado que el sistema se encuentra en producción, cuando se adicione un nuevo componente de servicios al sistema, quiero que el componente sea agregado sin alterar la calidad del código del sistema en general. Debe suceder que el porcentaje de duplicaciones de código en el sistema en general sea menor o igual a 5%.

Latencia:

2. Como tendero, dado que el sistema funciona correctamente, cuando el inventario esté disminuyendo y presione la opción "Consultar Sugerencias", quiero que el servidor resuelva las peticiones de consulta de datos de las sugerencias de productos que tengan mayor rotación en mi zona. Debe suceder que la latencia de las peticiones no sea mayor a 3 segundos.

Escenarios de prueba de los ASR's:

ASR 1: Se subirá la implementación de los ASR's a la herramienta SonarQube, para que esta haga un análisis general de código para verificar el porcentaje de duplicaciones de código.

Se eliminarán las duplicaciones de código en el sistema general, para realizar un segundo análisis con SonarQube.

El objetivo es lograr mantener las duplicaciones de código del sistema general en un porcentaje que no puede superar el 5%.

ASR 2: Cuando el tendero acceda al inventario de su tienda y haya pulsado la opción de Consultar Sugerencias, se verificará que las peticiones de consultas de datos no tarda más de 3 segundos para desplegar un listado de sugerencias de productos para el tendero.

Tácticas a implementar:

DRY (ASR 1):

La táctica, cuyo significado es Don't Repeat Yourself o también conocida como Duplication is Evil (DIE) corresponde al atributo de calidad de mantenibilidad; que se garantiza al evitar repetir información (de cualquier tipo). Esto permite que cuando se hagan cambios en una parte del proyecto no se vean afectados elementos que no estén directamente relacionados, y los que sí estén relacionados, cambien de forma predecible y uniforme.

Uso de Patrones de Diseño Detallado (ASR 2):

La táctica corresponde al atributo de calidad de desempeño; esto se garantiza haciendo uso de MongoDB Atlas y del patrón Subset Pattern. La primera herramienta permite crear una base de datos documental, mientras que la segunda favorece el atributo de calidad mencionado para las consultas que se realicen sobre la base de datos que se cree. De esta manera se garantiza que las consultas que se hagan sobre la base de datos no excedan los 3 segundos, dado que el punto de inflexión de la arquitectura es mayor al utilizar el patrón especificado.