Introducción

---

Visión general

UML 2.0 organiza los diagramas en dos categorías principales:

Categoría	Propósito
Diagramas estructurales	Capturan la organización física de los elementos: cómo los objetos se relacionan entre sí
Diagramas comportamentales	Se centran en cómo los elementos interactúan, cambian de estado y procesan el comportamiento con el tiempo

💡 Principio clave: Un modelo UML consta de uno o más diagramas. Cada diagrama representa una perspectiva particular o un interés específico en el sistema modelado. Los elementos individuales suelen aparecer en múltiples diagramas.visión o interés en el sistema que se está modelando. Los elementos individuales suelen aparecer en múltiples diagramas.

---

🔷 Diagramas estructurales

Los diagramas estructurales modelan la arquitectura estática de su sistema: el «qué» en lugar del «cómo».

1. Diagramas de clases

Propósito: Clases de modelo, interfaces y sus relaciones estáticas.

Elementos clave:

• Clases con atributos y operaciones

• Interfaces y relaciones de realización

• Asociaciones, agregaciones, composiciones y generalizaciones

• Modificadores de visibilidad (+, -, #, ~)

• Especificaciones de multiplicidad (1, 0..*, 1..5)

Uso de ejemplo:Cuándo usarlo:

Estereotipos y tipos de clase

El diagrama utiliza estereotipos (indicados por texto dentro de corchetes angulares, como <<entidad>>) para categorizar el papel de cada clase:

• Clases de Límite (<<límite>>): Estas manejan la interacción entre el sistema y sus actores (usuarios o sistemas externos).

• Ejemplos: ConsoleWindow y DialogBox.

• Clases de Control (<<control>>): Estas gestionan la coordinación, las transacciones y el flujo de lógica de negocio de la aplicación.

• Ejemplos: DrawingContext y DataController.

• Clases de Entidad (<<entidad>>): Estas representan los datos centrales o la información persistente que el sistema rastrea.

• Ejemplos: Frame, Window, Event, Shape, Círculo, Rectángulo, Polígono, y Punto.

• Clase abstracta: La Forma la clase representa un concepto abstracto. Sirve como plantilla base para formas específicas y no puede instanciarse directamente por sí sola.

---

Anatomía de una clase

Una caja de clase UML estándar se divide en compartimentos. Al observar la Círculo clase como ejemplo:

• Nombre de la clase: Ubicado en el compartimento superior (Círculo).

• Atributos: Ubicado en el compartimento central, que representa los campos de datos.

• -radio : flotante (El signo menos - indica un atributo privado).

• -centro : entero sin signo

• Operaciones (Métodos): Ubicado en el compartimento inferior, que representa los comportamientos o funciones.

• +area(radio en : float) : double (El signo más + indica un método público).

• +circun(), +setCentro(), y +setRadio().

---

Relaciones y enlaces

Las líneas y flechas que conectan las clases definen cómo interactúan y dependen unas de otras:

Generalización (Herencia)

Representado por una línea sólida con una punta de flecha hueca apuntando hacia la clase padre. Esto indica una relación «es-un» donde una clase hija hereda atributos y comportamientos de una clase padre.

• Ventana hereda de Marco.

• VentanaConsola y CuadroDiálogo heredan de Ventana.

• Círculo, Rectángulo, y Polígono heredan de la clase abstracta Forma (por ejemplo, un Círculo es una Forma).

Agregación

Representado por una línea sólida con un diamante hueco en el extremo del contenedor. Esto indica una relación suelta de tipo “tiene-un” o de todo-parte, donde el hijo puede existir independientemente del padre.

• Ventana agrega Forma (multiplicidad 1 a *). Una Ventana puede contener múltiples (*) formas, pero si la ventana se cierra, las formas en sí mismas aún pueden existir conceptualmente en la memoria o en otro contexto.

Composición

Representado por una línea sólida con un diamante lleno (negro) en el extremo del contenedor. Esto indica una relación fuerte de tipo “tiene-un” con una vida útil coincidente: si el contenedor se destruye, las partes también se destruyen.

• Círculo está compuesto por Punto objetos (multiplicidad 1 a *). Un círculo no puede existir sin su centro ni sus puntos frontera; destruir el círculo destruye estas referencias específicas a puntos.

Dependencia

Representado por un flecha punteada. Muestra que una clase depende de otra, lo que significa que un cambio en la clase objetivo puede afectar a la clase de origen.

• Ventana tiene una dependencia con Evento (indicado por la flecha punteada que apunta a Evento). La ventana depende de desencadenadores de eventos para ejecutar operaciones como handleEvent().

Asociación

Representado por una línea simple y continua. Indica una relación estructural en la que los objetos de una clase están conectados a objetos de otra.

• Cuadro de diálogo está asociado con ControladorDeDatos, lo que significa que se comunican entre sí para intercambiar información o coordinar su comportamiento.

---

Elementos de documentación

• Nota: El diagrama presenta una caja de nota con una esquina doblada conectada mediante una línea punteada con la Ventana clase. Proporciona contexto legible para humanos: “La ventana principal de la aplicación.”

• Diseñando arquitectura de software orientado a objetos

• Documentando modelos de dominio

• Generando esqueletos de código

---

2. Diagramas de componentes

Propósito: Muestra la organización y las dependencias de las unidades de implementación.

Elementos clave:

• Componentes (esterotipados como «componente»)

• Interfaces proporcionadas/requeridas (notación de bola y enchufe)

• Conectores de ensamblado y relaciones de dependencia

• Artefactos (salidas compiladas: JARs, DLLs, ejecutables)

Uso ejemplo:Cuándo usarlo:

Componentes y límites modulares

subsistema o contenedor general.Terminal componente, que actúa como un subsistema o contenedor. Dentro de este contenedor residen componentes internos más pequeños y especializados: a saber, Inspección de seguridad, Personal, Defecto, y Mapa. Cada una de estas unidades internas representa una pieza modular de software o lógica de gestión de datos que trabaja conjuntamente para cumplir con las responsabilidades de la Terminal.

Interfaces como contratos

Los componentes no exponen directamente su lógica interna; en cambio, interactúan mediante interfaces bien definidas que actúan como contratos arquitectónicos.

• Interfaces proporcionadas:Representadas por un símbolo de “caramelo” o círculo, estas indican los servicios, datos o operaciones que un componente implementa y ofrece a su entorno. Por ejemplo, el componente Terminal externo expone interfaces proporcionadas externas comoEstado, Detalles, y Elemento de inspección, indicando qué pueden solicitar los clientes externos de él.

• Interfaces requeridas:Representadas por un símbolo de “enchufe” o medio círculo, estas especifican los servicios o datos que un componente necesita de otra entidad para funcionar correctamente. En el lado derecho del diagrama, el componente Terminal expone explícitamente interfaces requeridas paraCuenta y ID de inspección, mostrando sus dependencias con subsistemas externos.

Puertos y conexión interna

Para gestionar el flujo de datos y control preservando la encapsulación, el sistema utiliza puertos y relaciones de delegación.

• Puertos:Los pequeños cuadrados situados en el borde de los componentes representan puertos. Actúan como puntos de interacción distintos a través de los cuales la estructura interna del componente se conecta con el mundo exterior. Los puertos permiten que un componente aísle su conexión interna del entorno externo, lo que significa que los componentes internos pueden reemplazarse o modificarse sin alterar cómo aparece el componente padre al exterior.

• Delegación y ensamblaje:Dentro del Terminal, las líneas conectan estas interfaces para formar el ensamblaje estructural. Una interfaz proporcionada en el puerto externo delega las solicitudes entrantes directamente a la interfaz proporcionada de un componente interno (como se ve con las rutas deEstado y Detalles que conducen a Inspección de seguridad). Por el contrario, los componentes internos conectan sus interfaces de enchufe requeridas directamente a las interfaces de caramelo proporcionadas de componentes vecinos. Por ejemplo, el componenteInspección de seguridad depende de la interfazInspector proporcionada por Personal, el Detalles del defecto interfaz proporcionada por Defecto, y la Ubicación interfaz proporcionada por Mapa, creando un ecosistema interno estrechamente coordinado pero débilmente acoplado.

• Planificación de la arquitectura modular del sistema

• Gestión de dependencias de compilación

• Documentación de bibliotecas de componentes reutilizables

---

3. Diagramas de estructura compuesta(Añadido en UML 2.0)

Elementos clave:

• Partes (propiedades con relaciones todo-parte)

• Puertos (puntos de interacción con interfaces proporcionadas/requeridas)

• Conectores (enlaces en tiempo de ejecución entre partes)

• Ocurrencias de colaboración

Uso de ejemplo: Modelado de un Automóvil:

Clasificador encapsulante (Clase)

El rectángulo exterior representa el clasificador contenedor, en este caso, el Automóvil clase. En un diagrama de estructura compuesta, esta frontera actúa como un contenedor que encapsula la configuración interna en tiempo de ejecución del sistema. Define el contexto en el que las instancias individuales colaboran para alcanzar un propósito conductual más amplio, ocultando la complejidad de cómo funciona internamente un «Automóvil» a entidades externas.

Partes (Estructura interna)

Los rectángulos internos dentro del límite del automóvil representan Partes. Una parte explica un rol desempeñado por un conjunto de instancias durante la ejecución del clasificador contenedor. A diferencia de mostrar una relación estática en tiempo de compilación (como un diagrama de clases estándar), estas partes indican instancias en tiempo de ejecución que ocupan ranuras arquitectónicas específicas:

• -t : Transmisión: Una instancia que desempeña el rol del sistema de transmisión.

• -e : Motor: Una instancia que desempeña el rol de la fuente de energía del motor.

• -s : Sistema de dirección: Una instancia que desempeña el rol del mecanismo de dirección.

La notación de dos puntos indica que estas son roles estructurales tipificadas por sus clases respectivas, definiendo exactamente qué componentes deben existir dentro de un automóvil operativo.

Puertos y límites

Los pequeños cuadrados incrustados en el límite del clasificador externo y en los límites de las partes internas representan Puertos. Los puertos son puntos de interacción distintos que desacoplan la estructura interna de un clasificador de su entorno externo.

• Puertos externos en el límite del automóvil—como : Rueda, : Palanca de gas, y : Volante—exponen cómo el automóvil interactúa con el mundo exterior o el entorno físico sin exponer cuálespartes internas están gestionando esas interacciones.

• Los puertos en las partes internas (como los puertos en los bloques de Transmisión o Motor) rigen cómo estos subsistemas se comunican entre sí o con el límite padre.

Conectores y cableado interno

Las líneas sólidas que unen los puertos representan Conectores. Los conectores definen las vías de comunicación entre partes o entre una parte y un puerto externo en tiempo de ejecución.

• Conectores de delegación: Conectan un puerto externo del contenedor directamente a un puerto interno de una parte. Por ejemplo, el puerto externo : Rueda puerto rutas directamente al Transmisión, y el externo : Volante rutas directamente al Sistema de Dirección. Esto garantiza que los estímulos externos se deleguen sin problemas al actor interno correcto.

• Conectores de Montaje: Enlaza partes internas para permitir la colaboración. El conector entre el Transmisión y el Motor muestra que estas dos funciones de tiempo de ejecución distintas intercambian directamente señales, datos o fuerza mecánica para que el coche funcione como un todo unificado.

Cuándo usarlo:

• Documentar patrones de diseño

• Modelar colaboraciones internas complejas

• Puentes entre el diseño de clases y la implementación de componentes

---

4. Diagramas de Despliegue

Propósito: Mapear artefactos de software a entornos de ejecución de hardware.

Elementos clave:

• Nodos (dispositivos, entornos de ejecución)

• Artefactos (unidades desplegables)

• Camino de comunicación entre nodos

• Especificaciones de despliegue (detalles de configuración)

Uso de ejemplo:Cuándo utilizarlo:

Nodos e infraestructura física

A diferencia de los diagramas de diseño lógico que modelan la disposición del código o las estructuras de clases, un diagrama de despliegue se centra en la topografía del hardware. Los bloques fundamentales sonNodos, que se representan visualmente como cubos tridimensionales. Los nodos ilustran recursos computacionales físicos o entornos de ejecución donde los elementos de software realmente se ejecutan:

• <<procesador>> Nodos: Cubos con estereotipo de<<procesador>> (comoServidor de caché, Servidor principal, y genéricosServidor bloques) representan nodos con capacidad computacional, memoria y potencia de procesamiento capaces de ejecutar binarios de software.

• <<red>> Nodos: El cubo alargado etiquetado comoRed local representa una ruta de comunicación o infraestructura de enrutamiento en lugar de una computadora individual. Representa la estructura física que permite a los procesadores conectados intercambiar flujos de paquetes de datos.

• Nodos de dispositivo: Nodos sin estereotipo comoInternet yBanco de módems representan componentes de hardware de frontera o infraestructura física externa necesaria para enrutar el tráfico externo hacia el entorno central del sistema.

Asociaciones y vías de comunicación

Las líneas sólidas que conectan los cubos tridimensionales representanAsociaciones. En un diagrama de despliegue, estas asociaciones muestran los caminos de comunicación física, enlaces de red o conexiones de hardware entre nodos.

• La línea entre Internet y Banco de Módemsilustra el punto de entrada de los datos públicos externos en la pila de hardware.

• La asociación que se extiende desde el Banco de Módemshacia abajo hasta el Servidor de Cachémuestra la ruta física del tráfico entrante hasta la capa de caché de borde.

• Asociaciones que conectan el Servidores de Caché y el Servidor Principal agrupado con el Red Localestablecen cómo los componentes internos se comunican a través de una infraestructura compartida de bus local de alta velocidad o conmutador de red.

Agrupación topológica y redundancia

La disposición de los nodos en el diagrama muestra explícitamente la topología de despliegue y las decisiones de diseño arquitectónico para alta disponibilidad y distribución de carga.

• Capa de Caché de Borde: Colocados directamente debajo del hardware del módem de entrada se encuentran dos nodos de Servidor de Caché nodos. Esta configuración demuestra visualmente una capa de borde redundante diseñada para distribuir la carga del tráfico entrante y almacenar en caché activos antes de que las solicitudes alcancen la infraestructura profunda.

• Granja de Servidores Internos: Colocado en la parte inferior de la pila, conectado mediante la Red Local, se encuentra un grupo de servidores centrales. La diferenciación entre el Servidor Principal y el genérico adyacente Servidor los nodos representan visualmente una arquitectura maestro-replica o primario-secundario, asegurando que la persistencia de datos y las cargas de trabajo intensivas de cálculo se coordinen de forma segura dentro del entorno del centro de datos interno.

Propósito: Modelar la estructura interna de clasificadores y patrones complejos.

• Planificación de la infraestructura del sistema

• Documentación de arquitecturas distribuidas

• Especificación de estrategias de conmutación por fallo y redundancia

---

5. Diagramas de paquetes

Propósito: Organizar y gestionar espacios de nombres mediante agrupaciones lógicas.

Elementos clave:

• Paquetes (rectángulos con pestañas)

• Relaciones de importación/acceso («importar», «acceso»)

• Relaciones de fusión («fusionar»)

• Visibilidad (+ público, - privado)

Uso ejemplo:

Límites de subsistemas y paquetes

El diagrama depende en gran medida de la notación de “carpeta” para representar agrupaciones lógicas de elementos de diseño.

• Subsistema: La gran carpeta externa estereotipada como <<subsistema>> Ordenamiento representa una unidad de comportamiento principal y encapsulada del sistema físico. Actúa como un contenedor de alto nivel que agrupa componentes y paquetes relacionados necesarios para ejecutar la gestión de pedidos.

• Paquete: Las carpetas más pequeñas dentro y fuera del subsistema (tales como UI, Procesamiento de Pedidos, y GUIManager) son paquetes estándar. Se utilizan para organizar elementos en grupos manejables, establecer espacios de nombres y definir los límites de visibilidad dentro de la arquitectura.

Dependencias y capas

Las flechas punteadas indican Dependencias, estableciendo que un cambio en un paquete (el destino) puede afectar el funcionamiento del paquete origen (el fuente).

• Dependencias internas: Dentro del subsistema de Ordenamiento, es visible una clara estructura arquitectónica de arriba hacia abajo. El UI paquete depende de Procesamiento de Pedidos, que a su vez depende del Calculadora de Precios y Almacenamiento Externo. Esto representa un flujo arquitectónico en el que los elementos de presentación de nivel superior dependen de las capas lógicas de negocio principal y acceso a datos.

• Dependencia de un paquete externo: Los paquetes también pueden depender de elementos fuera de los límites inmediatos de su subsistema. Por ejemplo, el UI paquete tiene una dependencia con el externo GUIManager. De manera similar, el Almacenamiento Aleatorio y Almacenamiento de Flujo paquetes en la parte inferior cruzan el límite del subsistema para depender de estructuras de datos externas, destacando cómo el subsistema se integra en un ecosistema de software más amplio.

Abstracción e Herencia (Generalización)

El diagrama utiliza un estilo especializado y flechas de relación para demostrar patrones de diseño abstractos aplicados a una arquitectura modular.

• Paquetes Abstractos frente a Paquetes Concretos: Los paquetes que contienen elementos abstractos o definen una estructura similar a una interfaz se representan con nombres en cursiva (como Almacenamiento Externo y Gestión de Almacenamiento). Por el contrario, los paquetes que contienen implementaciones de código operativo, como Repositorio y Almacenamiento de Archivos, utilizan texto estándar para indicar que son paquetes concretos.

• Generalización: Representado por una línea sólida con un triángulo abierto y hueco que apunta al paquete padre. Esto indica una relación de herencia o implementación. Dentro del subsistema, Almacenamiento Aleatorio y Almacenamiento de Flujo especializan o implementan la interfaz abstracta Almacenamiento Externo interfaz. Fuera del subsistema, el paquete concreto Repositorio y Almacenamiento de Archivos los paquetes generalizan hacia lo abstracto GestiónDeAlmacenamiento paquete, mostrando cómo se puede modelar el comportamiento polimórfico y la clasificación estructural a nivel de paquete.

  

• Cuándo usar:

• Gestión de bases de código grandes

• Definición de límites de módulos

• Control de dependencias de compilación

---

6. Diagramas de objetos

Propósito: Mostrar instantáneas de instancias y sus enlaces en un momento específico.

Elementos clave:

• Objetos (nombres subrayados: miCoche:Coche)

• Enlaces entre instancias de objetos

• Valores de atributos en tiempo de ejecución

Uso de ejemplo:

Objetos e instancias concretas

A diferencia de los diagramas de clases que muestran configuraciones abstractas de nivel de plano, un diagrama de objetos captura instancias reales que viven en la memoria. Los objetos se representan mediante rectángulos, y sus nombres siempre están subrayados para denotar la instanciación.

• Objetos con nombre: Estos siguen la sintaxis nombreInstancia : NombreClase. Por ejemplo, c : Empresa representa una instancia específica de empresa llamada “c”, y p : Persona representa una instancia específica de individuo llamada “p”.

• Objetos anónimos: Cuando el identificador específico de la instancia se omite o no es relevante para el escenario, solo se proporciona el nombre de la clase, precedido por dos puntos (por ejemplo, : Información de contacto). Esto especifica que existe una instancia concreta de información de contacto y está adjunta a la estructura, pero no necesita un nombre de variable único en este contexto.

Estado y valores de atributos

El compartimento inferior de un rectángulo de objeto contiene su estado específico, definido por valores explícitos asignados a sus atributos en ese momento dado. En lugar de simplemente listar tipos de datos, estas entradas utilizan el formato de asignación atributo = valor de asignación para reflejar la realidad:

• La instancia de departamento d1 contiene el valor del atributo nombre = Ventas.

• Otra instancia distinta de departamento d2 contiene el valor nombre = I+D.

• La instancia de persona p contiene un conjunto completo de datos de estado, que define un perfil específico: nombre = Derek, IDEmpleado = D-12821, y cargo = Gerente.

Enlaces y relaciones

Las líneas sólidas que conectan los objetos representan Enlaces. Un enlace es una instancia concreta de una asociación definida entre clases. Si un diagrama de clases indica que las empresas tienen departamentos, el diagrama de objetos demuestra las conexiones reales en tiempo de ejecución entre ellos.

• La instancia de empresa c está activamente vinculada a instancias de departamento d1 (Ventas) y d2 (I+D).

• El diagrama también muestra la conexión jerárquica de instancias, donde d1 : Departamento (Ventas) se vincula hacia abajo con una instancia de subdepartamento también tipificada como Departamento (nombre = Ventas EE.UU.).

• Finalmente, la instancia de persona p (Derek) está vinculada a la instancia del departamento de Ventas EE.UU., al mismo tiempo que mantiene una conexión con una instancia anónima : Información de contacto que contiene su dirección física.

Cuándo usarlo:

• Validar diseños de diagramas de clases

• Depurar relaciones de objetos complejas

• Demostrar estados de tiempo de ejecución de ejemplo

---

🔶 Diagramas de comportamiento

Los diagramas de comportamiento modelan aspectos dinámicos: cómo se comporta el sistema con el tiempo.

7. Diagramas de actividad

Propósito: Modelar flujos de trabajo, procesos empresariales y lógica algorítmica.

Elementos clave:

• Acciones (rectángulos redondeados)

• Nodos de control: inicial, decisión, fusión, bifurcación, unión, final

• Nodos de objeto y pines

• Particiones (carriles) para la asignación de responsabilidades

• Manejadores de excepciones y regiones interrumpibles

Uso de ejemplo: Flujo de trabajo de procesamiento de pedidos

Organización estructural (carriles y particiones)

El diagrama está organizado verticalmente en columnas grandes conocidas indistintamente comoCarriles o Particiones. Estas fronteras categorizan las responsabilidades de las acciones contenidas en ellas, asignando pasos a roles o unidades de negocio específicos:

• Interfaz de ventas al cliente: Posee el ciclo de vida orientado al cliente, gestionando la inicialización del cliente, el enrutamiento alternativo y la presentación final.

• Propietario de la propuesta: Gestiona la planificación principal, el análisis operativo y la compilación de las estructuras de datos formales de la propuesta.

• Propietario de la cotización: Se enfoca únicamente en la valoración financiera y en la preparación de las métricas específicas de la cotización.

Flujo de control y estados de acción

La ejecución paso a paso del procedimiento está dirigida por nodos de control y rutas dirigidas.

• Nodo inicial: Representado por el círculo sólido negro en la parte superior, esto indica el punto de inicio de todo el flujo de trabajo de actividad.

• Acción: Los rectángulos redondeados (por ejemplo, Iniciar contacto, Buscar alternativa, y Compilar información adicional) representan pasos o tareas individuales e indivisibles dentro de la secuencia de ejecución.

• Flujo de control: Las flechas sólidas que conectan los elementos determinan la progresión secuencial del flujo de trabajo, indicando exactamente qué acción debe completarse antes de que comience la siguiente.

• Nodo final de actividad: El símbolo de diana (un círculo sólido dentro de un anillo hueco) en la parte inferior marca el punto absoluto de terminación de toda la ejecución del proceso.

Enrutamiento y lógica con condiciones (nodos de decisión)

Los símbolos en forma de diamante representanNodos de decisión, que modelan el bifurcación condicional en el flujo de trabajo.

• Las rutas de control entrantes se dividen en múltiples rutas salientes mutuamente excluyentes según entradas específicas.

• Las condiciones que determinan qué ruta tomar están encerradas entre corchetes, conocidas como condiciones de guarda (por ejemplo,[aceptado], [rechazado], y[unirse con otro proveedor o cambiar requisitos]). El proceso evalúa estas condiciones durante la ejecución para dirigir la ejecución por la ruta funcional adecuada.

Procesamiento paralelo (nodos de bifurcación y unión)

Las barras negras sólidas en el diagrama actúan como puntos de sincronización para gestionar flujos de ejecución concurrentes o paralelos.

• Nodo de bifurcación (etiquetado como Nodo de flujo en el puntero del diagrama): Una única corriente de control entrante entra en la barra y se divide en múltiples hilos de ejecución independientes y concurrentes. Aquí, después de crear un plan de proyecto, el proceso se bifurca para permitir que el Propietario de la Propuesta ejecute el análisis y la planificación de entrega, mientras que el Propietario de la Cotización gestiona simultáneamente la preparación de la cotización.

• Nodo de unión: Una barra de sincronización que fusiona múltiples caminos concurrentes de nuevo en un único flujo de control. El proceso no puede pasar más allá del Nodo de unión hasta quetodos las corrientes paralelas entrantes hayan alcanzado con éxito la barra, asegurando que la compilación de la cotización y el borrador de la propuesta estén completamente finalizados antes de proceder a compilar el paquete final.

Integración de datos (nodos de objeto)

Los rectángulos estándar indicanNodos de objeto, que introducen el flujo de datos en el diagrama de actividad orientado al control.

• Los nodos de objeto representan instancias de datos específicos o artefactos físicos producidos o consumidos por acciones, utilizando elnombreDeInstancia : NombreDeClase convención (por ejemplo, unaPropuesta : Propuesta y unPlan : Plan de Proyecto de Entrega).

• Marcado explícitamente crear las flechas muestran exactamente cuándo una acción instancia o actualiza una estructura de datos, demostrando cómo fluye la información de tarea a tarea junto con la ejecución operativa.

Cuándo usar:

• Documentar procesos de negocio

• Modelar realizaciones de casos de uso

• Especificar algoritmos complejos

---

8. Diagramas de máquinas de estado (Statecharts)

Propósito: Modelar el ciclo de vida y el comportamiento dependiente del estado de los objetos.

Elementos clave:

• Estados (rectángulos redondeados con actividades de entrada/salida/hacer)

• Transiciones (disparador[guarda]/efecto)

• Pseudoeestados: inicial, elección, bifurcación, unión, historial, terminar

• Estados compuestos y regiones ortogonales

Uso de ejemplo: configuración de telefonía

Estados y condiciones del sistema

El diagrama captura el comportamiento de un sistema—específicamente una configuración de telefonía—mediante el mapeo de sus diversas situaciones o condiciones discretas.

• Estados: Los rectángulos redondeados representan estados (por ejemplo, Ocupado, Tono de marcado, Marcando, Conectando, y Conectado). Un estado representa un período en el ciclo de vida de un objeto durante el cual satisface alguna condición, ejecuta una actividad o espera un evento.

• Estado pseudo inicial: El círculo sólido negro en el extremo izquierdo representa el punto de inicio de la máquina de estados. Es un estado pseudo en lugar de un estado verdadero, sirviendo únicamente como puntero al estado activo predeterminado cuando se instancia el objeto (Inactivo).

• Estado final: El símbolo de diana en el extremo derecho representa la terminación de la ejecución de la máquina de estados, indicando que el objeto ha completado su ciclo de vida.

Transiciones y enrutamiento impulsado por eventos

Las líneas dirigidas que conectan los estados son Transiciones, que representan el movimiento de un estado a otro como respuesta a un desencadenante específico.

• Transiciones estándar: Activadas por eventos específicos, como una acción del usuario o una respuesta del sistema, indicados a lo largo de las líneas. Por ejemplo, pasar de Inactivo a Tono de marcado ocurre cuando se activa el evento onHook se activa, y pasar de Tono de marcado a Marcando ocurre cuando un dígito(n) evento es recibido.

• Transiciones autónomas: Una flecha de transición que sale de un estado y regresa directamente al mismo estado (como se ve en el Marcando estado con el dígito(n) disparador). Esto indica que el evento se procesa y actualiza el contexto de estado interno (por ejemplo, registrar un dígito recién marcado) sin que el objeto salga o cambie su estado operativo general.

Camino alternativo y manejo de errores

Las máquinas de estado destacan al mostrar la lógica de comportamiento y el bifurcación de errores basada en condiciones variables durante la ejecución.

• Camino de ejecución exitoso: La canalización horizontal central traza el camino óptimo: Inactivo $rightarrow$ Tono de marcado $rightarrow$ Marcando $rightarrow$ Conectando $rightarrow$ Sonando $rightarrow$ Conectado $rightarrow$ Desconectado.

• Estados de manejo de excepciones y errores: El sistema tiene en cuenta fallas o retrasos al bifurcarse hacia estados dedicados de manejo. Si un número está ocupado durante la conexión, el sistema activa el númeroOcupado transición para ingresar al TonoOcupado estado. Si un usuario pausa demasiado tiempo durante la marcación, un tiempo de espera evento cambia el sistema a un Advertencia o Tiempo de espera estado. Si se detecta una secuencia incorrecta, un númeroInválido disparador redirige el sistema a un MensajeGrabado estado, asegurando que el sistema maneje de forma segura todos los casos límite del mundo real.

 

Cuándo usarlo:

• Modelado de sistemas embebidos o implementaciones de protocolos

• Especificación de la gestión de estados de la interfaz de usuario

• Documentación de las reglas del ciclo de vida de los objetos

---

9. Diagramas de interacción

Cuatro tipos de diagramas enfatizan aspectos diferentes de la colaboración entre objetos:

a) Diagramas de secuencia(El más común)

Propósito: Muestra los intercambios de mensajes ordenados por tiempo entre líneas de vida.

Elementos clave:

• Líneas de vida (líneas punteadas verticales)

• Mensajes (flechas sólidas/punteadas con etiquetas)

• Ocurrencias de ejecución (barras de activación)

• Fragmentos combinados: alt, opt, bucle, par, interrumpir

Uso de ejemplo:

Líneas de vida y contextos de ejecución

El diagrama se lee de izquierda a derecha para establecer a los participantes, y de arriba hacia abajo para denotar el paso del tiempo.

• Líneas de vida: Las cajas en la parte superior unidas a líneas verticales punteadas representan líneas de vida. Modelan a los participantes individuales en la interacción, siguiendo el nombreInstancia : NombreClase convención (por ejemplo, ventana : UI, unaCadena : CadenaHoteles, y unHotel : Hotel). La línea punteada rastrea la existencia de ese participante a lo largo de la secuencia.

• Barras de activación: Los delgados rectángulos verticales de color apoyados sobre las líneas de vida indican una Activación (o ocurrencia de ejecución). Estas barras muestran exactamente cuándo un objeto está ejecutando activamente una operación o esperando que una llamada anidada devuelva un resultado.

• Detenido: El gran símbolo “X” en la parte inferior de la ventana : UI la línea de vida indica destrucción o terminación, mostrando que el ciclo de vida de este participante específico ha terminado y sus recursos se han liberado.

Tipos de mensajes y comunicación

La comunicación entre participantes se modela mediante flechas horizontales que representan mensajes, ordenados secuencialmente utilizando un sistema de numeración jerárquico (por ejemplo, 1, 1.1, 1.1.1).

• Mensajes síncronos: Líneas sólidas con puntas de flecha sólidas (como 1: hacerReserva y 1.1: hacerReserva) indican llamadas síncronas. El remitente bloquea la ejecución y espera a que el objeto receptor complete su procesamiento.

• Mensajes auto: Un bucle de mensaje que comienza y termina en la misma barra de activación (como 1.1.1: disponible(idHabitación, fecha): esHabitación ejecutado por aHotel) representa un mensaje auto. Esto indica una ejecución de método interna en la que un objeto llama a una de sus propias operaciones.

• Mensajes de creación: Una línea punteada con una punta de flecha abierta que apunta directamente a una caja de objeto (como el mensaje 1.1.2: que apunta a aReserva : Reserva) representa la creación de un objeto. Esto muestra que la instancia aHotel instancia instancía dinámicamente el objeto aReserva en ese momento exacto en la secuencia de tiempo de ejecución.

Fragmentos combinados y flujo de control

Los grandes cuadros rectangulares que rodean secciones de la secuencia son Fragmentos combinados, que utilizan operadores de interacción para gestionar lógica compleja, ramificación e iteración.

• Fragmento de bucle: La caja exterior etiquetada como bucle con la condición de guardia [cada día] representa iteración. Todas las interacciones contenidas dentro de esta caja se repetirán continuamente para cada día especificado en la solicitud de reserva.

• Fragmento combinado alternativo (Alt): Incrustado dentro del bucle hay un alt fragmento (anotado como “Si” en el puntero del diagrama), que maneja la ramificación condicional. Evalúa la condición de guardia [isRoom = true]. Si la condición se cumple, la secuencia ejecuta la ruta específica dentro de ese bloque—creando la instancia aReservation e inmediatamente desencadenando el mensaje 2: para instanciar aNotice : Confirmación. Si la condición fuera falsa, se tomaría una ruta alternativa (o no se realizaría ninguna acción).

  

b) Diagramas de comunicación

Propósito: Enfatizan las relaciones entre objetos sobre la sincronización de mensajes.

Elementos clave:

• Objetos como nodos

• Enlaces con mensajes numerados y dirigidos

• Enfoque en “quién habla con quién”

c) Diagramas de vista general de interacción

Propósito: Flujo de control de alto nivel utilizando notación de diagrama de actividad.

Elementos clave:

• Ocurrencias de interacción como nodos de actividad

• Decisión/combinación para ramificación

• División/unión para paralelismo

d) Diagramas de temporización

Propósito: Modelar restricciones de tiempo precisas (sistemas en tiempo real).

Elementos clave:

• Líneas de tiempo de estado para cada línea de vida

• Escala de tiempo y restricciones

• Flechas de mensaje con marcadores de duración

Cuándo usar interacciones:

• Especificación de realizaciones de casos de uso

• Depuración de flujos de mensaje complejos

• Documentación de patrones de uso de API

• Modelado del tiempo de protocolos en tiempo real

---

10. Diagramas de casos de uso

Propósito: Capturar requisitos funcionales desde la perspectiva de un actor externo.

Elementos clave:

• Casos de uso (óvalos o rectángulos de clasificador)

• Actores (figuras de palo o clasificadores)

• Asociaciones (actor ↔ caso de uso)

• Relaciones: «include», «extender», generalización

• Cuadro de límites del sistema

Uso de ejemplo: Sistema ATM

Cuándo usarlo:

• Recolección de requisitos con partes interesadas

• Definición del alcance y límites del sistema

• Planificación de escenarios de prueba

---

🎯 Elección del diagrama adecuado: Guía de decisión

Objetivo	Diagrama(s) recomendado(s)
Diseño de la estructura de clases	Clase, Objeto, Paquete
Modelado de interacciones en tiempo de ejecución	Secuencia, Comunicación
Documentar flujos de trabajo empresariales	Actividad, Caso de uso
Especificar el ciclo de vida del objeto	Máquina de estados
Planificar la implementación del sistema	Implementación, Componente
Modelar patrones internos complejos	Estructura compuesta
Capturar restricciones en tiempo real	Diagrama de temporización
Definir requisitos	Caso de uso, Actividad

---

🔑 Principios clave de modelado

1. Empieza simple: Comienza con el tipo de diagrama que mejor se ajuste a tu objetivo inmediato.

2. Itera: Perfecciona los modelos a medida que aumenta la comprensión—ningún diagrama es «definitivo» en el primer borrador.

3. El público importa: Ajusta el nivel de detalle según el lector (desarrolladores frente a partes interesadas).

4. Combina vistas: Usa múltiples diagramas para contar una historia completa (por ejemplo, Caso de uso → Secuencia → Clase).

5. Extiende con cuidado: Usa estereotipos, valores etiquetados y perfiles para necesidades específicas del dominio, pero documenta las convenciones.

6. Manténlo legible: Omite detalles irrelevantes; usa notas para contexto complementario.

📌 Recuerda: «UML es un lenguaje, no una metodología.» Proporciona notación, no proceso. Elige diagramas que aclaren la comunicación, no aquellos que solo marquen casillas.

Conclusión