Fundamentos de Modelado & UML

1. ¿Qué son los modelos?

Un modelo es una descripción completa de un sistema desde una perspectiva particular y actúa como una representación simplificada de la realidad. Construyes modelos porque los sistemas complejos no pueden ser comprendidos completamente en su totalidad.

Cuatro objetivos fundamentales del modelado:

1. Visualizar un sistema según lo previsto.

2. Especificar la estructura o el comportamiento de un sistema.

3. Proporcionar una plantilla para guiar la construcción del sistema.

4. Documentar las decisiones de diseño.

Cuatro principios del modelado

• El modelo que eliges influye directamente en cómo se aborda un problema.

• Cada modelo puede expresarse en diferentes niveles de precisión.

• Los modelos más efectivos permanecen estrechamente conectados con la realidad.

• Ningún modelo único es suficiente; los sistemas complejos requieren múltiples perspectivas.

¿Qué es UML?

El Lenguaje Unificado de Modelado (UML) es un lenguaje gráfico estandarizado gestionado por el Grupo de Gestión de Objetos (OMG). Está explícitamente no es una metodología ni un procedimiento sino una especificación técnica y gráfica utilizada para:

“Visualizar, especificar, construir y documentar los artefactos de un sistema intensivo en software.”

UML proporciona un formato de plano universal tanto para elementos conceptuales (procesos de negocio, funciones del sistema) como para implementaciones concretas (sentencias de código, esquemas de bases de datos, componentes reutilizables).

Los Cuatro Pilares de UML

Propósito	Descripción
Visualización	Asegura que todas las partes interesadas hablen el mismo idioma. Los modelos explícitos eliminan errores de comunicación y revelan aspectos del sistema invisibles sin modelado.
Especificación	Crea definiciones de sistemas precisas, inequívocas y completas.
Construcción	Se mapea directamente a lenguajes de programación (Java, C++, VB), tablas de RDBMS o almacenes de OODBMS. Soporta ingeniería directa (modelo → código) y ingeniería inversa (código → modelo).
Documentación	Captura la arquitectura del sistema, los requisitos, los planes de prueba, los cronogramas del proyecto y la gestión de lanzamientos.

---

2. El Ecosistema de Diagramas de UML

UML 2.2 define 14 tipos de diagramas, categorizados en dos grupos principales:

1. Modelos Estructurales (Arquitectura estática)

2. Modelos de Comportamiento e Interacción (Procesos dinámicos)

Diferentes diagramas sirven a diferentes perspectivas de las partes interesadas:

• Vista de Casos de Uso: Funcionalidad del usuario final

• Vista Lógica: Analistas y Diseñadores (estructura del sistema)

• Vista de Proceso: Gestión de software (rendimiento, escalabilidad, capacidad de procesamiento)

• Vista de Implementación: Programadores (componentes concretos)

• Vista de Despliegue: Integradores de sistemas (topología, instalación, comunicación)

---

3. Diagramas principales de UML explicados

🔹 Diagrama de Casos de Uso

• Propósito: Modela las funciones previstas del sistema y su entorno. Actúa como un contrato entre clientes y desarrolladores.

• Componentes: Actores, Casos de Uso y sus relaciones.

• Diagramas de apoyo: Actividad (flujo dentro de un caso de uso), Secuencia (colaboración de objetos para realizar un caso de uso).

🔹 Diagrama de Actividad

• Propósito: Visualiza el flujo paso a paso de eventos dentro de un proceso o caso de uso.

• Elementos clave:

  • Acción: Un paso discreto en el flujo de trabajo.

  • Flujo: Secuencia de actividades.

  • Decisión: Divide el flujo según una condición de guarda[condición].

  • Bifurcación: Inicia hilos concurrentes.

  • Unión: Finaliza hilos concurrentes (sincronización).

• Ejemplo: Flujo de inscripción en cursos con verificaciones, resolución de conflictos y actualizaciones concurrentes del horario.

🔹 Diagrama de secuencia

• Propósito: Muestra cómo interactúan los objetos a lo largo de tiempo para cumplir un caso de uso.

• Elementos clave:

  • Línea de vida: Línea vertical que muestra la existencia de un objeto a lo largo del tiempo.

  • Objeto/Clase: Participante en la interacción.

  • Mensaje: Datos o llamadas a métodos intercambiados entre objetos.

  • Ocurrencia de ejecución: Rectángulo delgado que muestra cuándo un objeto está procesando activamente.

  • Fragmentos combinados: opt (ejecución opcional), loop (ejecución repetida), ref (hace referencia a otra interacción).

🔹 Diagrama de comunicación

• Propósito: Alternativa a los diagramas de secuencia. Hace énfasis en relaciones estructurales entre objetos en lugar del orden temporal.

• Elementos clave: Objetos enlazados entre sí, con mensajes numerados que indican la secuencia de interacción a lo largo de los enlaces.

🔹 Diagrama de componentes

• Propósito: Muestra la estructura en tiempo de ejecución a nivel de componentes de software.

• Elementos clave: Partes modulares del sistema ocultas detrás de interfaces externas. A menudo incluye clases para mostrar relaciones de implementación.

🔹 Diagrama de despliegue

• Propósito: Mapea los artefactos de software al hardware físico.

• Elementos clave:

  • Nodo: Representa una máquina física o un entorno de ejecución.

  • Artefacto: Representa un archivo físico o una unidad desplegable.

  • Elemento propietario: Muestra relaciones anidadas o de contención.

---

4. Dominar los diagramas de clases y las relaciones

Los diagramas de clases representan la estructura estática de un sistema. Son fundamentales para las especificaciones de datos (por ejemplo, INSPIRE) y no no muestran información temporal.

Anatomía de la clase

Compartimento	Descripción
Nombre	Identificador de la clase (por ejemplo, Parcela Catastral). A menudo incluye estereotipos como «TipoDeCaracterística».
Atributos	Propiedades nombradas con tipos de datos (por ejemplo, - Dirección : char, - Edad del árbol : int). Tipos admitidos: Integer, LongInt, Double, Char, Date, Boolean, String, Geometry, etc.
Operaciones	Comportamientos/métodos de la clase. Formato: + nombreOperación(tipoEntrada) : tipoSalida.

Tipos de relación

Relación	Símbolo	Significado
Asociación	───────	Enlace general entre clases. Incluye nombres de roles, flechas de navegación y cardinalidad (1..*, 0..*, 1..2, etc.).
Generalización	─────▷	Herencia. La subclase (origen) hereda todas las características de la superclase (destino).
Agregación	◇─────	Relación de “parte de”. La parte puede existir independientemente del todo. (Diamante hueco)
Composición	◆─────	Relación fuerte de “parte de”. La existencia de la parte depende enteramente del todo. (Diamante relleno)

Ejemplo del material de formación:

• Persona → Leñador (Generalización: el leñador hereda Nombre, Género)

• Bosque ◇─ Árbol (Agregación: los árboles pueden existir sin un bosque específico)

• Leñador ◆─ Empleados (Composición: los empleados no pueden existir independientemente de la entidad Leñador en este contexto)

---

5. Aplicación práctica: Modelado de catastro INSPIRE

El material de formación utiliza el Especificación de datos de INSPIRE sobre catastro para demostrar la aplicación de UML en el mundo real.

Ejercicio 1: Modelado de una clase principal

Tarea: Cree el CadastralParcel clase.
Estructura de la solución:

«featureType» CadastralParcel
- Dirección : char
- APN (Número de parcela) : char
- Límite : GM_Surface
- Centroide : GM_Point
- Etiqueta : char
- Referencia Catastral Nacional : String
- Valor de Área : double (opcional)
- Punto de Referencia : GM_Point (opcional)

Nota: Existen múltiples soluciones válidas. Los atributos deben reflejar características comunes del mundo real.

Ejercicio 2: Modelado de relaciones

Tarea: Conecte CadastralParcel, CadastralBoundary, y AdministrativeZone.
Decisiones clave de modelado:

• CadastralParcel ──── CadastralBoundary: Asociación/Composición (el límite define la parcela; a menudo 1..1 o 1..* cardinalidad). Roles: +isBorder / +hasBorder.

• Parcela Catastral ◇── Zona Administrativa: Agregación/Asociación. La existencia de la zona no depende de la parcela. La parcela pertenece a múltiples zonas jerárquicas (1..* a 0..*).

• Lección: Elija tipos de relaciones basándose en la dependencia del ciclo de vida y las reglas de negocio. Los diagramas deben reflejar la realidad, no forzar restricciones artificiales.

---

6. Mejores prácticas para un modelado UML efectivo

1. Use los diagramas de forma estratégica: Los diagramas visualizan perspectivas específicas. Ningún sistema complejo puede entenderse a partir de un solo diagrama.

2. Reutilice elementos en varios diagramas: Una sola clase puede aparecer en diagramas de clases, máquinas de estado, diagramas de secuencia y vistas de despliegue, cada uno destacando un aspecto diferente.

3. Adapte la precisión a la audiencia: Ajuste la complejidad del diagrama según si el espectador es un usuario final, desarrollador, integrador de sistemas o gerente de proyecto.

4. Valide contra la realidad: Verifique continuamente que los elementos del modelo, las relaciones y las cardinalidades reflejen el comportamiento real del sistema y las reglas del dominio.

5. Aproveche el soporte de herramientas: Utilice herramientas compatibles con UML (por ejemplo, Sparx Systems) para ingeniería directa/inversa, verificación de consistencia y generación de código.

---

Conclusión

UML es un lenguaje potente y estandarizado para comunicar, diseñar y documentar sistemas de software y sistemas intensivos en datos. Al dominar los diagramas centrales (especialmente Clases, Secuencia, Actividad y Casos de uso) y comprender la semántica de las relaciones (Asociación, Generalización, Agregación, Composición), los profesionales pueden crear planos precisos y alineados con la realidad que cierren la brecha entre los requisitos conceptuales y la implementación técnica.