Diseño del Experimento

#Especificación del experimento

Título del experimento	Creación y almacenamiento de historias clinicas con balanceador de carga
ASRs involucrados	Como médico, cuando creo la historia clínica de un paciente, dado que el sistema está sobrecargado, quiero que el sistema registre y almacene la información del paciente para garantizar la integridad y disponibilidad de los datos. El sistema debe poder pasar de crear y almacenar 30 historias clínicas por día a 120 por día a partir del primer año de operación.
Propósito del experimento	Evaluar si el diseño planteado satisface el ASR involucrado.
Resultados esperados	Que el porcentaje de error al crear y almacenar una historia clinica sea menor a 5%
Infraestructura computacional requerida	Balanceador de carga en GCP, instancias VM en GCP para ejecutar el servidor de la base de datos, Computador personal para hacer las peticiones.
Descripción del experimento	Usando JMeter se van a simular solicitudes POST para crear historias clínicas, comenzando con una carga equivalente a 30 historias por día y luego incrementándola hasta 120 historias por día, evaluando si el sistema mantiene la integridad y disponibilidad de los datos bajo condiciones de sobrecarga.
Plan de uso IAG	No Aplica

Elementos de arquitectura

• Diagrama de componentes !imagen

• Diagrama de despliegue !imagen

Estilos de arquitectura

• MTV (Model-Template-View): Django tiene este estilo incorporado, asi que al usarlo, lo acoplamos mejor a su arquitectura. Ademas, que se organiza el codigo de manera clara, organizada y permite que sea reutilizable.
• Capas: El estilo por capas en nuestro caso encaja bien para darle a cada parte de la aplicacion una responsabilidad especifica. Se usaron tres capas en la construccion de la aplicacion: Primero la de presentacion donde se incluyen los templates y las vistas de MTV, y muestra la informacion al usuario. Segundo, esta la capa de negocio donde se encarga de manejar las procesos internos y reglas de negocio. Por ultimo la capa de persistencia que se encarga de acceder a la base de datos para obtener las historias.

Tácticas/patrones de arquitectura

• Balanceador de Carga - Replicación: Se utiliza para distribuir las solicitudes de creación de historias clínicas entre varias instancias del servidor en Google Cloud. Esto permite que el sistema escale progresivamente y soporte un mayor número de peticiones conforme crece la demanda (de 30 a 120 historias por día). Al evitar la sobrecarga en un único servidor, se mejora la disponibilidad del sistema y se reduce el riesgo de errores en la creación o almacenamiento de datos, contribuyendo directamente al cumplimiento del ASR al garantizar la integridad y persistencia de la información médica incluso en condiciones de alta carga.

Tecnologías

• Google Cloud: Lo utilizamos porque permite crear y configurar fácilmente el balanceador de carga junto con las instancias de VM, y asi podemos gestionar el tráfico para las pruebas en el experimento.

• JMeter: Lo utilizamos para generar múltiples solicitudes concurrentes de creación de historias clínicas, permitiéndonos simular el crecimiento en la carga del sistema desde 30 hasta 120 historias por día. Con esta herramienta podemos observar cómo responde la aplicación ante un aumento progresivo de peticiones, y evaluar si mantiene la integridad y disponibilidad de los datos. Además, nos ayuda a identificar posibles errores en el almacenamiento y analizar el comportamiento del sistema en condiciones de alta demanda.

• Django: Framework principal del sistema, lo utilizamos por su arquitectura MTV, que facilita la separación de responsabilidades entre presentación, lógica y acceso a datos. Nos provee herramientas que permitieron implementar rápidamente las funcionalidades requeridas.