UML significa Lenguaje Unificado de Modelado. Es un lenguaje visual utilizado en Ingeniería de Software para representar sistemas mediante diagramas. Su propósito no es reemplazar al código ni a la documentación escrita, sino ayudar a comprender, analizar, diseñar y comunicar cómo está organizado un sistema y cómo se comporta.
Cuando un equipo trabaja en un sistema de software, debe tomar muchas decisiones: qué partes tendrá el sistema, cómo se relacionarán entre sí, qué hará cada usuario, qué objetos participarán en una operación, qué estados puede tener una entidad importante y dónde se ejecutarán los componentes. UML permite expresar esas ideas mediante modelos gráficos más fáciles de revisar que una explicación extensa en texto.
En cursos anteriores se estudiaron conceptos generales de Ingeniería de Software, requisitos y casos de uso. UML se apoya en esos temas: toma necesidades, escenarios y reglas ya descubiertas, y las representa desde distintas perspectivas para que el equipo pueda razonar mejor sobre el sistema que se desea construir o modificar.
Podemos definir UML de la siguiente manera:
Esta definición contiene varias ideas importantes:
La imagen muestra que UML permite observar un mismo sistema de software desde diferentes puntos de vista. En el centro se ubica el sistema que se desea comprender o diseñar, y alrededor aparecen distintos tipos de diagramas. Cada uno destaca una parte diferente: los casos de uso muestran objetivos y actores, las clases muestran la estructura, las secuencias muestran mensajes entre objetos, las actividades muestran flujos de trabajo, los estados muestran ciclos de vida, los componentes muestran módulos y el despliegue muestra servidores o dispositivos.
UML sirve para pensar y comunicar. Antes de programar, permite analizar el problema, descubrir dudas y acordar una solución general. Durante el diseño, permite representar responsabilidades, relaciones, colaboraciones y decisiones técnicas. Después de construido el sistema, puede servir como documentación para mantenimiento, evolución y capacitación de nuevos integrantes del equipo.
Sus usos más frecuentes son:
Un error frecuente es pensar que UML consiste simplemente en hacer dibujos bonitos. Un diagrama UML debe tener intención, consistencia y precisión. Cada elemento que aparece en el diagrama debería ayudar a responder una pregunta: quién usa el sistema, qué partes lo componen, cómo se comunican los objetos, qué pasos sigue un proceso o qué estados atraviesa una entidad.
Un diagrama con demasiada información puede ser tan difícil de entender como no tener diagrama. Por eso, en UML es fundamental elegir qué mostrar y qué omitir. Un buen modelo simplifica la realidad sin deformarla: conserva lo importante para el objetivo del análisis y deja fuera los detalles que no aportan en ese momento.
Para usar UML correctamente conviene distinguir tres conceptos: el sistema real, el modelo y el diagrama. El sistema real es el software que existe o que se desea construir. El modelo es una representación simplificada de ese sistema. El diagrama es una vista gráfica de una parte del modelo.
Esto significa que un mismo sistema puede tener muchos diagramas. Un diagrama de clases puede mostrar la estructura de entidades importantes; un diagrama de secuencia puede mostrar cómo colaboran los objetos para registrar una venta; un diagrama de estados puede mostrar las etapas por las que pasa un pedido; y un diagrama de despliegue puede mostrar en qué servidores se ejecutan los componentes.
No todos los diagramas son necesarios en todos los proyectos. La decisión depende del tamaño del sistema, la complejidad del problema, el nivel de formalidad requerido y las personas que usarán el modelo.
UML agrupa sus diagramas en grandes familias. Esta clasificación ayuda a entender qué pregunta responde cada tipo de diagrama.
| Familia | Qué representa | Ejemplos de diagramas |
|---|---|---|
| Estructura | Elementos estables del sistema y relaciones entre ellos. | Clases, objetos, paquetes, componentes, despliegue, estructura compuesta. |
| Comportamiento | Procesos, estados, actividades y funcionalidades observables. | Casos de uso, actividades, estados. |
| Interacción | Comunicación entre objetos o partes del sistema a lo largo de un escenario. | Secuencia, comunicación, tiempo, vista global de interacción. |
Los diagramas de estructura muestran cómo está formado el sistema o una parte de él. Permiten representar elementos relativamente estables: clases, objetos, módulos, paquetes, componentes, interfaces, nodos físicos y relaciones entre ellos.
Por ejemplo, un diagrama de clases puede mostrar que una clase Pedido se relaciona con Cliente y Producto. Un diagrama de componentes puede mostrar que una aplicación web depende de un servicio de autenticación y de un servicio de pagos. Un diagrama de despliegue puede mostrar que la aplicación se ejecuta en un servidor y usa una base de datos en otro nodo.
Estos diagramas son útiles cuando necesitamos comprender la organización de la solución, las dependencias entre partes o la arquitectura general del sistema.
Los diagramas de comportamiento muestran qué ocurre en el sistema. Se enfocan en funcionalidades, procesos, decisiones, eventos y cambios de estado. Ayudan a comprender cómo se comporta el sistema ante determinados estímulos o durante un flujo de trabajo.
Un diagrama de casos de uso muestra los servicios que el sistema ofrece a actores externos. Un diagrama de actividades muestra pasos, decisiones, bifurcaciones y tareas paralelas. Un diagrama de estados muestra las situaciones por las que puede pasar un objeto importante, por ejemplo un pedido que puede estar pendiente, pagado, enviado, entregado o cancelado.
Los diagramas de interacción muestran cómo colaboran distintos objetos, componentes o partes del sistema para completar un escenario. Son especialmente útiles cuando se necesita entender el orden de los mensajes y las responsabilidades de cada participante.
El diagrama de secuencia es uno de los más usados. Representa participantes en columnas y mensajes ordenados en el tiempo. Por ejemplo, puede mostrar cómo una interfaz de usuario solicita una operación a un controlador, cómo el controlador consulta un servicio, cómo el servicio guarda información en un repositorio y cómo vuelve la respuesta al usuario.
El diagrama de comunicación muestra una idea similar, pero enfatiza la red de objetos que colaboran y los mensajes numerados entre ellos.
UML aporta una forma ordenada de pensar sistemas. No alcanza con saber programar instrucciones: también es necesario comprender problemas, abstraer información, separar responsabilidades, detectar relaciones y explicar soluciones. Los diagramas UML obligan a tomar decisiones explícitas y facilitan la revisión de esas decisiones.
Además, UML ayuda a desarrollar vocabulario técnico. Conceptos como clase, objeto, asociación, dependencia, interfaz, componente, actor, estado, transición, mensaje y nodo aparecen constantemente en análisis, diseño, arquitectura, documentación y mantenimiento de software.
UML es una herramienta, no una solución automática. Un diagrama puede estar dibujado con símbolos correctos y aun así representar mal el problema. La calidad del modelo depende de la comprensión del dominio, de la claridad de los requisitos, de las decisiones de diseño y de la capacidad del equipo para validar lo que modela.
Tampoco es obligatorio usar todos los diagramas en cada proyecto. En sistemas pequeños puede alcanzar con pocos diagramas bien elegidos. En sistemas grandes o críticos, puede ser necesario usar varios diagramas y mantenerlos actualizados con más disciplina.
Supongamos un sistema de gestión de turnos médicos. UML permite mirarlo desde varias perspectivas. Desde los casos de uso, podemos identificar actores como Paciente, Médico y Administrador. Desde un diagrama de clases, podemos representar conceptos como Turno, Profesional, Especialidad y Agenda. Desde un diagrama de secuencia, podemos mostrar los mensajes necesarios para reservar un turno. Desde un diagrama de estados, podemos representar que un turno puede estar disponible, reservado, cancelado o atendido.
La ventaja de UML es que no obliga a explicar todo con un único dibujo. Cada diagrama responde una pregunta distinta y, en conjunto, ofrecen una comprensión más completa del sistema.
Cuando se empieza a trabajar con UML, suelen aparecer algunos errores:
UML permite representar un sistema de software desde distintas perspectivas. Sus diagramas ayudan a ordenar ideas, detectar problemas, comunicar decisiones y documentar aspectos importantes del análisis y del diseño. En este primer tema vimos qué es UML, para qué sirve y por qué existen distintos tipos de diagramas.
En los próximos temas veremos cómo se ubica UML dentro del proceso de análisis, diseño y comunicación del software, y luego profundizaremos en los diagramas más importantes con ejemplos concretos.