El software es difícil de ver completo. Por eso usamos diagramas: representaciones visuales que ayudan a comprender, explicar y discutir partes de un sistema. Un diagrama puede mostrar actores, procesos, clases, componentes, estados, datos, interacciones o decisiones de arquitectura.
UML, sigla de Lenguaje Unificado de Modelado, es una notación estándar para representar distintos aspectos de un sistema de software. No es la única forma de diagramar, pero es una de las más conocidas.
En este tema veremos una introducción a UML y a otros diagramas de apoyo. El objetivo no es dominar toda la notación, sino entender para qué sirven los diagramas y cómo usarlos con criterio.
UML es un lenguaje visual de modelado que permite representar estructuras, comportamientos e interacciones de un sistema. Está compuesto por distintos tipos de diagramas, cada uno orientado a responder preguntas diferentes.
UML puede utilizarse para:
Los diagramas son útiles cuando ayudan a entender algo que sería difícil explicar solo con texto. Pueden servir en análisis, diseño, comunicación, documentación, pruebas y mantenimiento.
Algunos usos frecuentes:
Un diagrama debe responder una pregunta concreta. Si no ayuda a entender o decidir, probablemente no aporta valor.
Muchos diagramas pueden agruparse en dos grandes familias: estructurales y de comportamiento.
| Tipo | Qué muestra | Ejemplos |
|---|---|---|
| Estructural | Elementos relativamente estables y sus relaciones. | Clases, componentes, paquetes, despliegue. |
| De comportamiento | Acciones, flujos, estados, mensajes o cambios en el tiempo. | Casos de uso, actividades, secuencia, estados. |
Ambos tipos se complementan. La estructura muestra qué elementos existen; el comportamiento muestra cómo actúan o cambian.
El diagrama de casos de uso muestra actores externos y objetivos que pueden lograr interactuando con el sistema. Es útil para comprender alcance funcional y actores principales.
Responde preguntas como:
Ejemplo de casos de uso para una biblioteca:
Este diagrama no detalla pasos internos. Para eso se pueden usar descripciones de casos de uso o diagramas de actividad.
El diagrama de clases muestra clases, atributos, operaciones y relaciones. Puede usarse en análisis para representar conceptos del dominio o en diseño para representar estructuras de software.
En análisis, podría mostrar conceptos como:
En diseño, puede mostrar clases concretas, métodos, interfaces y dependencias técnicas. Es importante distinguir el nivel de abstracción usado.
El diagrama de secuencia muestra cómo interactúan actores, objetos, servicios o componentes a lo largo del tiempo mediante mensajes. Es útil para entender una operación concreta.
Puede responder preguntas como:
Por ejemplo, al confirmar una compra, el diagrama podría mostrar interacción entre interfaz, servicio de pedidos, servicio de pagos, inventario y notificaciones.
El diagrama de actividades representa flujos de trabajo, decisiones y pasos de un proceso. Es útil para analizar procesos de negocio o flujos funcionales.
Puede mostrar:
Por ejemplo, un proceso de inscripción puede incluir: seleccionar curso, verificar cupo, validar requisitos previos, registrar inscripción, generar comprobante y enviar confirmación.
El diagrama de estados muestra los estados posibles de un objeto o entidad y los eventos que provocan cambios entre ellos. Es útil cuando un concepto tiene un ciclo de vida importante.
Ejemplos:
Este diagrama ayuda a descubrir reglas como: una reserva cancelada no puede volver a activa, o un pedido entregado no puede pasar a pendiente.
El diagrama de componentes muestra partes principales del sistema y sus dependencias. Es más técnico que un diagrama de casos de uso o actividades, y suele usarse para hablar de arquitectura o diseño.
Puede representar elementos como:
Ayuda a entender dependencias, responsabilidades técnicas e integraciones.
No todo diagrama debe ser UML. En muchos proyectos se usan diagramas simples que comunican mejor que una notación formal.
| Diagrama | Uso principal | Ejemplo |
|---|---|---|
| Diagrama de contexto | Mostrar el sistema y sus relaciones externas. | Usuarios, sistemas externos y límites de la solución. |
| Mapa de procesos | Representar procesos de negocio. | Flujo de compra desde pedido hasta entrega. |
| Modelo entidad-relación | Representar datos y relaciones. | Clientes, pedidos, productos y pagos. |
| Wireframe | Mostrar estructura inicial de una interfaz. | Boceto de pantalla de inicio de sesión. |
| Diagrama de arquitectura simple | Comunicar componentes técnicos principales. | Frontend, API, base de datos y servicios externos. |
| Mapa de navegación | Mostrar pantallas y caminos posibles. | Menú, listado, detalle, edición y confirmación. |
El diagrama adecuado depende de la pregunta que se quiere responder. Antes de dibujar, conviene definir el propósito.
| Pregunta | Diagrama útil |
|---|---|
| ¿Quién usa el sistema y para qué? | Casos de uso o diagrama de contexto. |
| ¿Qué conceptos del negocio existen? | Modelo de dominio o diagrama de clases conceptual. |
| ¿Cómo fluye un proceso? | Diagrama de actividades o mapa de procesos. |
| ¿Cómo interactúan componentes en una operación? | Diagrama de secuencia. |
| ¿Qué estados puede tener una entidad? | Diagrama de estados. |
| ¿Cómo se organiza técnicamente el sistema? | Diagrama de componentes o arquitectura. |
No todos los diagramas necesitan la misma formalidad. En una conversación temprana, un boceto puede ser suficiente. En documentación técnica o sistemas críticos, puede requerirse mayor precisión.
El nivel de formalidad depende de:
La precisión es útil cuando ayuda a evitar errores. La formalidad excesiva puede ser un problema si produce diagramas que nadie mantiene ni usa.
Para un sistema de turnos médicos se podrían usar varios diagramas:
Cada diagrama aporta una vista distinta del mismo sistema.
Un diagrama es útil mientras refleja una decisión, una comprensión o una estructura vigente. Si queda desactualizado, puede confundir más de lo que ayuda.
Para mantener diagramas útiles conviene:
Al usar UML y diagramas suelen aparecer errores como:
Algunas recomendaciones iniciales:
UML y los diagramas de apoyo permiten representar visualmente aspectos del software que serían difíciles de explicar solo con texto. Ayudan a analizar, diseñar, comunicar y mantener sistemas, siempre que se usen con propósito y nivel de detalle adecuado.
Para quien comienza, la idea principal es esta: un buen diagrama no es el más complejo, sino el que permite que las personas entiendan mejor una parte importante del sistema.
En el próximo tema veremos diseño de software: responsabilidades, módulos e interfaces, avanzando desde el análisis hacia decisiones de organización de la solución.