Segundo Trimestre: Entornos de Desarrollo

Un equipo de desarrollo mantiene una aplicación de gestión interna para una cadena de clínicas. La solución es multiplataforma y se compone de dos partes: una app de escritorio para administración (JavaFX) y una app móvil para el personal (Android). Ambas comparten una API de acceso a datos y una base de datos central.

El trabajo comienza cuando se solicita una mejora o corrección (por ejemplo, “añadir la gestión de citas”, “mejorar el login con caducidad de sesión”, “sincronizar historial de pacientes” o “corregir un error en la carga de listados”). A partir de ahí, el equipo arranca el flujo de una de estas dos formas:

• Si la funcionalidad se implementa sobre un módulo existente, se abre el proyecto en el IDE con su configuración ya preparada (dependencias, perfiles de ejecución, conexión a base de datos, emuladores y dispositivos registrados).

• Si es un módulo nuevo (por ejemplo, un submódulo de informes o un componente móvil nuevo), se inicializa la estructura, se define el empaquetado y se conecta con el repositorio y el sistema de construcción.

Durante el desarrollo, los programadores trabajan en el código fuente y se alternan tareas en móvil y escritorio. En esta etapa suelen repetirse acciones como:

• Ejecutar la aplicación en local (JavaFX) o en emulador/dispositivo (Android) para validar el comportamiento.

• Revisar logs y depuración para detectar fallos funcionales o de rendimiento.

• Ejecutar pruebas unitarias (por ejemplo, sobre la lógica de negocio o los servicios).

• Generar una build de prueba (APK para móvil o paquete ejecutable para escritorio) para que otra persona del equipo pueda validar.

• Confirmar cambios y subirlos al repositorio mediante una rama de trabajo.

Cada vez que se suben cambios, el sistema lanza un proceso automatizado de validación. Ese proceso incluye comprobaciones como:

• Compilación del proyecto y verificación de dependencias.

• Ejecución de pruebas unitarias.

• Validación básica de calidad (por ejemplo, reglas de estilo o análisis estático).

• Generación de artefactos de entrega (APK debug o release candidate, y paquete de escritorio).

En función del resultado:

• Si la validación falla, el flujo vuelve a desarrollo para corregir y repetir el ciclo.

• Si la validación es correcta, el sistema marca los cambios como listos para revisión.

Antes de preparar una entrega, una persona del equipo revisa la propuesta de cambios. En esta revisión se comprueba, por ejemplo, que:

• No se han roto pantallas clave.

• La funcionalidad cumple los requisitos.

• La solución es mantenible y coherente con el resto del proyecto.

La decisión de la revisión puede provocar:

• Solicitud de cambios, lo que devuelve el trabajo a desarrollo y reinicia la validación automatizada.

• Aprobación, lo que permite integrar los cambios en la rama principal y preparar una versión candidata.

Tras la integración, el sistema prepara una versión para pruebas internas. En esta fase se puede detectar un problema de compatibilidad (móvil), un fallo de ejecución (escritorio) o un error al conectar con la base de datos. Si ocurre, el flujo vuelve atrás para corregir y repetir.

Finalmente, cuando todo está validado, el sistema ejecuta el despliegue o distribución:

• En móvil, se genera el paquete final para distribución (por ejemplo, una release firmada) y se publica en el canal interno o tienda correspondiente.

• En escritorio, se genera el instalador o ejecutable definitivo y se distribuye al personal.

Si el despliegue falla o se detecta un error crítico tras la publicación, el flujo contempla una acción de recuperación (retirar versión, revertir cambios o publicar hotfix).

Parte 1: Diagrama de Actividades

Crea un diagrama de actividades UML que modele el flujo completo descrito, incluyendo:

• Inicio con bifurcación: abrir módulo existente o crear módulo nuevo.

• Acciones del equipo: desarrollar, ejecutar (Android/JavaFX), depurar, ejecutar pruebas, generar build, commit y push.

• Acciones del sistema: validación automática, build de artefactos, publicación/distribución.

• Decisiones: validación OK/KO, revisión aprobada/solicita cambios, pruebas internas OK/KO, despliegue OK/KO.

• Bucles: correcciones tras validación, correcciones tras revisión y correcciones tras pruebas internas.

Parte 2: Diagrama de Estados

A partir del diagrama de actividades, deduce estados estables del sistema (entorno de trabajo/pipeline/distribución) y diseña un diagrama de estados UML que refleje:

• Estados típicos: “proyecto cargado”, “en desarrollo”, “pendiente de subida”, “en validación”, “validación fallida”, “pendiente de revisión”, “revisión rechazada”, “aprobado”, “integrado”, “build candidata”, “en pruebas internas”, “listo para distribución”, “distribuido”, “rollback/hotfix”.

• Eventos que disparan transiciones: push, pipeline OK/KO, solicitud de cambios, aprobación, generación de APK/instalador, publicación OK/KO.

• Bucles y retornos a estados anteriores cuando haya fallos o solicitudes de cambios.

Justificación

Incluye una breve justificación explicando:

• Qué decisiones y bucles has incluido y por qué son necesarios en un entorno real.

• Cómo has convertido actividades en estados y qué criterio has seguido para no mezclar acciones con estados.

• Cómo garantizas que el diagrama de estados se deduce del de actividades sin contradicciones.

Entrega esperada

• Diagrama de actividades UML del flujo completo.

• Diagrama de estados UML coherente con el anterior.

• Justificación breve del diseño.

Formato de presentación

PowerPoint o Presentaciones de Google.