Skip to content

Laboratorio: Modelado UML (Análisis y Diseño)

Resumen Ejecutivo

Esta sesión práctica profundiza en la aplicación de diferentes diagramas UML (Dominio, Actividad, Estados, Despliegue, Componentes y Diseño) aplicados a casos de uso complejos. Se contrasta el enfoque riguroso del Proceso Unificado (hacer todos los modelos) frente al enfoque Ágil (hacer solo los modelos útiles), adoptando este último para la vida profesional pero enseñando todos para fines académicos. El núcleo de la clase se centra en la resolución detallada de ejercicios complejos para entender la "traducción" de requisitos textuales a estructuras visuales.

Conceptos Clave

  • Modelo de Dominio (Análisis): Representación de las clases conceptuales del mundo real. No es un esquema de base de datos; define estructura y relaciones a nivel de negocio/aplicación.
  • Clase de Asociación vs. Entidad Intermedia: Diferencia crítica basada en la necesidad de mantener un histórico de relaciones entre dos objetos.
  • Región de Expansión (Actividad): Estructura en diagramas de actividad para procesar colecciones de objetos (de forma iterativa o paralela).
  • Estado Compuesto y Nodo Historia (Estados): Mecanismos para agrupar sub-estados y recordar el último estado activo tras una interrupción.
  • Patrón DAO (Data Access Object): Patrón de diseño para desacoplar la lógica de negocio de la persistencia de datos.

Desarrollo del Temario

1. Contexto Metodológico: ¿Cuándo modelar?

El profesor aclara la vigencia del modelado en la ingeniería de software moderna:

  • Enfoque Proceso Unificado (Estricto): Si decides usar UP, estás obligado a generar todos los modelos (casos de uso, análisis, diseño, despliegue, etc.) para cumplir con los hitos.
  • Enfoque Ágil (Scrum/XP): La documentación se reduce a lo útil o exigible. No se modela por obligación, sino cuando hay una necesidad específica (ej. un algoritmo complejo o una estructura de datos difícil).

    Cita del profesor: "Para qué voy a reinventar la rueda, ya hay un lenguaje comúnmente aceptado que es UML [...] Si tengo esas necesidades de aplicar esos modelos, entonces es cuando utilizo UML."

2. Ejercicio 1: Modelo de Dominio (Empresa de Seguridad)

Objetivo: Crear un diagrama de clases a nivel de análisis para la empresa "Me siento seguro".

A. Identificación de Herencia vs. Atributos

Al modelar empleados (Oficina y Vigilantes), surge la duda de si usar una herencia o un atributo "Tipo".

  • Regla de Oro: Se usa herencia cuando:
  • Existen atributos diferentes entre las entidades.

  • Existen relaciones diferentes con otras clases.

  • Caso Práctico: Aunque Vigilantes y Personal de Oficina compartan datos personales (DNI, Nombre), los Vigilantes tienen relaciones específicas (con Turnos, Armas, Vehículos) que los de Oficina no.

  • Vigilantes de Vehículo: Tienen atributo extra (carnet de conducir) y relación con Vehículo. -> Requiere Herencia.

B. El Problema del "Registro" (¡IMPORTANTE!)

Se analiza cómo modelar la relación entre un Vigilante y una Instalación.

  • Opción A (Clase de Asociación): Solo permite un objeto de enlace por cada par único de (Vigilante, Instalación).

  • Problema: Si el vigilante va hoy a la instalación y vuelve mañana, al ser los mismos objetos, se sobrescribiría la información (fecha entrada/salida). No permite histórico.

  • Opción B (Clase Intermedia "Registro"): Se crea una clase Registro independiente.

  • Solución: Un Vigilante tiene muchos Registros. Una Instalación tiene muchos Registros. Cada visita crea un objeto Registro nuevo. Esto permite guardar el histórico completo.

Ejemplo de la "Memoria": El profesor explica que una clase de asociación es como tener solo 28 bytes de espacio entre dos objetos. Si vuelves a relacionarlos, tienes que borrar lo anterior. Para guardar un historial, necesitas crear objetos nuevos (Registros) cada vez.

C. Herencia en el Registro

El registro de una visita en vehículo requiere guardar datos del coche (km entrada/salida) que el registro presencial no necesita.

  • Solución: Clase padre Registro (datos comunes: hora, fecha) -> Clases hijas RegistroPresencial y RegistroVehículo.
  • Conexión: RegistroVehículo se asocia con la clase Vehículo.
  • Nota: Aquí SÍ vale una clase de asociación (o atributos en la relación) entre RegistroVehículo y Vehículo porque un registro específico (hoy a las 5pm) solo se relaciona una vez con un coche específico.

3. Ejercicio 2: Diagrama de Actividad (Compra de Entradas)

Objetivo: Modelar el flujo funcional de la compra.

A. Estructura Básica

  • Inicio -> Seleccionar Evento -> Número de Entradas -> Comprobar Disponibilidad.
  • Nodo de Decisión: ¿Hay disponibilidad? (Sí/No). Si no, mensaje de error y fin.

B. Región de Expansión (Entradas VIP)

Para las entradas VIP, el usuario debe elegir al menos 2 extras y personalizarlos.

  • Concepto: Se usa una Región de Expansión con la palabra clave Iterative.
  • Funcionamiento:
  • Entra una colección de objetos (los extras seleccionados).
  • Se ejecutan las acciones (Personalizar -> Aplicar Promoción) de forma secuencial para cada objeto.

  • El flujo no sale de la región hasta que todos los objetos han sido procesados.

  • Manejo de Interrupciones: Se modela un evento (rayo) "Cancelar". Si ocurre, se elimina el extra y se obliga a seleccionar otro (vuelta atrás).

C. Finalización

  • Se unen los flujos (Merge) de entrada Normal y VIP.
  • Pago -> Validación -> Generar Justificante (Objeto de salida) -> Fin.

4. Ejercicio 3: Máquina de Estados (Robot de Almacén)

Objetivo: Modelar el ciclo de vida y reacciones de un robot.

A. Estados Compuestos

El estado Navegando es un estado compuesto secuencial. Dentro ocurren sub-estados:

  • Calculando ruta -> Avanzando -> (Si hay obstáculo) Esquivando.

B. Transiciones y Eventos

  • Sintaxis: Evento [Condición] / Acción.
  • Ejemplo: DestinoAlcanzado [operación == cargar] / Ir a ProcesandoCarga.

C. El Nodo Historia (H)

Si ocurre un error (ej. obstáculo no previsto), el robot pasa al estado ActivandoAlarma.

  • Si el operario resuelve el problema (Evento: ProblemaResuelto), el robot debe volver a Navegando.
  • ¡OJO AL DATO!: No vuelve al inicio de Navegando, vuelve al Nodo Historia (H). Esto significa que si estaba "Esquivando obstáculos" cuando falló, al volver regresará exactamente a "Esquivando obstáculos", no a "Calculando ruta".

5. Diagramas Técnicos: Despliegue, Arquitectura y Diseño

Diagrama de Despliegue

  • Muestra la topología física (Nodos) y software (Artefactos).
  • Elementos:
  • Nodos: <<Device>> (Móvil, Servidor), <<ExecutionEnvironment>> (Apache, JVM).

  • Artefactos: Archivos .jar, .xml desplegados en los nodos.

  • Realidad vs. Teoría: El profesor admite que en la vida real a veces son "cajas en una pizarra", pero académicamente se debe usar la sintaxis de estereotipos correcta.

Diagrama de Clases de Diseño (El "Real")

A diferencia del modelo de dominio (conceptual), este diagrama debe coincidir 1:1 con el código.

Implementación del Patrón MVC + DAO: Se modela un sistema simple de "Gestión de Clientes" para ver la arquitectura:

  1. Vista (UI): Clases con botones y campos de texto (Android/Web).
  2. Controlador/Negocio: GestorCliente. Recibe datos primitivos (Strings) de la vista.
  3. Patrón DAO (Data Access Object):
  4. El Gestor crea un objeto de dominio (Cliente) con los datos.
  5. Llama al DaoCliente pasando el objeto Cliente.

  6. El DaoCliente usa DBUtils para ejecutar el SQL (INSERT, SELECT).

  7. Beneficio: Desacopla la lógica de negocio de la base de datos. Si cambias de Oracle a MySQL, solo tocas el DAO, no el Gestor.

Preguntas de Autoevaluación para el Examen

  1. Dominio: En un diagrama de clases de análisis, si un "Profesor" imparte una "Asignatura" varios años consecutivos y necesitamos guardar la fecha de inicio/fin de cada año, ¿usarías una Clase de Asociación o una clase intermedia "Impartición"? ¿Por qué?
  2. Actividad: ¿Cuál es la diferencia de ejecución entre una Región de Expansión "Iterative" y una "Parallel"?
  3. Estados: ¿Qué función cumple el pseudo-estado de "Historia Profunda" (H*) o Historia (H) dentro de un estado compuesto cuando se produce una interrupción y posterior retorno?
  4. Diseño: Explica cómo el patrón DAO utiliza las clases del Modelo de Dominio (Entidades) para comunicar la Capa de Negocio con la Capa de Persistencia.
  5. General: Según lo explicado sobre herencia, si dos tipos de empleados tienen exactamente los mismos atributos pero relaciones completamente diferentes con otros objetos del sistema, ¿está justificado usar herencia?