Vista de Información

Modelo Flujo De Datos E Información

El modelo presentado permite visualizar de forma global los flujos de información que harán parte de nuestro sistema según el alcance definido con base a las diferentes Historias de usuario detalladas y priorizadas de nuestro backlog Backlog de Historias de Usuario.

Enlace para imagen ampliada

Flujo seleccionado

Adicional a esto, con el fin de identificar las diferentes tácticas de arquitectura y patrones de diseño seleccionados para dar respuesta a los ASR’s que guiaran los experimentos del proyecto ASR escogidos, nos enfocaremos en el flujo especifico en el que un usuario de la Aplicación Web/Móvil de Sport App hace el registro de eventos deportivos y registro de Alarmas de accidente, y el sistema se encarga de la propagación de las notificaciones a los diferentes interesados con base a la prioridad de cada una.

Enlace para imagen ampliada

Estilo Utilizado

El estilo seleccionado para esta vista es el de Microservicios, y esto se puede evidenciar ya que cada de entidad con múltiples instancias representa un Microservicio totalmente independiente, altamente cohesivo, con una única responsabilidad bien definida y que dependiendo de la necesidad puede escalar horizontalmente con la finalidad de satisfacer la demanda de recursos necesaria en un momento determinado.

Adicional a lo anterior, aplicando tácticas de procesamiento asíncrono como lo es el uso de una plataforma de mensajería, se puede lograr un bajo acoplamiento entre entidades del sistema, lo que permite una alta disponibilidad, escalabilidad y flexibilidad, que son algunas de las características más representativas de la arquitectura de microservicios, sin dejar a un lado la mantenibilidad y la evolución del sistema sin afectar a las entidades existentes.

Tácticas Utilizadas

• Táctica Balanceo de Carga para la distribución de carga y favorecer Disponibilidad y Latencia.
• Táctica Procesamiento Asíncrono para el manejo de eventos y favorecer la Disponibilidad.
• Táctica Publicación/Suscripción para el manejo de eventos y favorecer la Disponibilidad.
• Táctica Priorización de Eventos para el manejo de eventos y favorecer la Disponibilidad.

Patrones Utilizados

• Bajo acoplamiento: El flujo de envio de notificaciones permite un acoplamiento mínimo entre los diferentes componentes, ya que implementa procesamiento asíncrono a través del uso de colas de mensajería.
• Alta cohesión y Principio de Responsabilidad Única: Cada entidad del sistema se encarga de suministrar funcionalidades que están asociadas entre sí y hacen parte de un mismo objetivo, es decir tienen una única razón para cambiar. Por ejemplo, la entidad Servicios expone las funcionalidades asociadas con la gestión de eventos deportivos, como lo es el registro y envio de eventos deportivos; si se llegase a necesitar otro tipo de funcionalidad asociada con eventos deportivos es en este componente que se agregaría.
• Patrón Fachada y Principio de Abierto/Cerrado: Como se puede visualizar en el diagrama, la implementación del Balanceador de carga ofrece un único punto de entrada a las diferentes funcionalidades del sistema y si se desease extender o agregar nuevas funcionalidades, no habría afectación ya que las funcionalidades existentes seguirían siendo las mismas (sus firmas no cambian).
• Singleton: Este patrón de diseño se puede visualizar en las diferentes entidades del sistema, como los son Servicios, Entrenamientos, Notificaciones, etc. Ya que, aunque existen puedan existir varias réplicas de cada uno (esto se puede apreciar mejor en el apartado Modelo Vista de despliegue), solo hay una instancia de este ejecutándose en un solo Pod. Esto se puede detallar mejor en el Diagrama de Despliegue.
• Mediador: Este patrón de diseño está muy de la mano con las tácticas de procesamiento asíncrono y el patrón de bajo acoplamiento (descritos anteriormente), ya que permite centralizar las comunicaciones entre entidades del sistema a través del uso de componentes itermedios como los es la plataforma de mensajeria, evitando así que estas interactúen directamente, lo que permite un mayor desacoplamiento y simplifica la comunicación.

Razonamiento sobre Principales decisiones de Diseño

Decision de Diseño	Razonamiento
Balanceo de carga	Esta táctica depende de la implementación de la táctica de Escalamiento horizontal, ya que el balanceador de carga distribuirá equitativamente la carga entre las múltiples réplicas de componentes de servicio para evitar cuellos de botella, garantizando así una alta disponibilidad y baja latencia.
Procesamiento asíncrono	Como se puede observar en la comunicación de los componentes Gestor Servicios y Gestor Entrenamientos se realizarán operaciones de manera asíncrona, esto con la finalidad para liberar recursos y permitir que otros procesos continúen sin generar un bloqueo en el sistema.
Publicación/Suscripción	Esta táctica hace parte del Procesamiento asíncrono pero detalla un poco más el proceso. Como se puede observar en la comunicación de los componentes Gestor Servicios y Gestor Entrenamientos (publicadores) publican eventos a una cola de mensajería de Notificaciones. El componente Gestor Notificaciones (suscriptor) se registra para recibir los eventos que lleguen a la cola de mensajería y realiza el procesamiento correspondiente.
Priorización de Eventos	Esta táctica permite asignar una prioridad a los eventos según su importancia, asegurando que los eventos críticos se procesen antes. En este diagrama se puede visualizar el componente Gestor Entrenamientos al igual que el componente Gestor Servicios hacen envio de mensajes a la cola de Notificaciones, sin embargo, el mensaje que viene del componente Gestor Entrenamientos (punteado por línea morada más gruesa) tiene una mayor prioridad ya que los eventos que dispara son Alertas de accidentes.