2. UML dentro del análisis, diseño y comunicación del software
2.1 Introducción
UML no debe verse como una actividad aislada que se realiza después de entender todo el sistema. Su mayor utilidad aparece cuando se integra al trabajo diario de análisis, diseño y comunicación. Un diagrama puede ayudar a descubrir un problema, explicar una decisión, comparar alternativas o dejar documentado un aspecto importante de la solución.
En Ingeniería de Software se trabaja con información incompleta, cambios frecuentes y personas con distintos puntos de vista. Quien solicita el sistema suele pensar en necesidades y procesos de negocio. Quien analiza intenta ordenar requisitos. Quien diseña piensa en responsabilidades y estructura. Quien programa necesita decisiones concretas. Quien prueba necesita comportamientos verificables. UML puede actuar como un puente entre esas miradas.
2.2 UML durante el análisis
Durante el análisis se busca comprender el problema antes de definir una solución técnica detallada. En esta etapa, UML ayuda a representar actores, objetivos, procesos, conceptos del dominio, reglas importantes y situaciones que conviene aclarar con los interesados.
Por ejemplo, un diagrama de casos de uso puede mostrar qué servicios espera recibir cada actor. Un diagrama de actividades puede ordenar los pasos de un proceso actual o propuesto. Un diagrama de clases conceptual puede mostrar conceptos relevantes del dominio, como Cliente, Pedido, Producto, Factura o Turno, sin entrar todavía en detalles de programación.
2.3 UML durante el diseño
Durante el diseño, el foco cambia. Ya no se trata solo de comprender el problema, sino de proponer una solución de software. En esta etapa, UML permite representar clases de diseño, interfaces, componentes, servicios, mensajes entre objetos, módulos y decisiones arquitectónicas.
Un diagrama de secuencia puede mostrar cómo colaboran una interfaz, un controlador, un servicio y un repositorio para completar una operación. Un diagrama de componentes puede mostrar dependencias entre módulos. Un diagrama de despliegue puede mostrar dónde se ejecutan la aplicación, la base de datos y otros servicios externos.
El diseño no debe copiar mecánicamente el análisis. El análisis ayuda a entender el problema; el diseño define cómo se organizará la solución. UML puede usarse en ambos momentos, pero con distinto nivel de detalle y con distintos objetivos.
2.4 UML como medio de comunicación
Una de las funciones más importantes de UML es facilitar la comunicación. Un diagrama bien construido permite que varias personas discutan sobre la misma representación, en lugar de depender de interpretaciones distintas de una explicación verbal.
Los diagramas son útiles en reuniones de análisis, revisiones técnicas, planificación de cambios, explicación de funcionalidades, capacitación interna y documentación de decisiones. Cuando el diagrama es claro, ayuda a que las preguntas aparezcan antes de escribir código o antes de avanzar con una solución incorrecta.
Esto no significa que UML elimine la necesidad de texto. Muchos diagramas necesitan notas, descripciones o reglas complementarias. La comunicación mejora cuando el diagrama y el texto se apoyan mutuamente.
2.5 UML en el ciclo de trabajo del software
UML puede acompañar distintas actividades del desarrollo de software. A partir de requisitos y casos de uso, los diagramas ayudan a analizar el problema, diseñar una solución, comunicar decisiones al equipo, orientar la implementación, apoyar las pruebas y servir como documentación para mantenimiento. La idea central es que UML no pertenece a una única etapa: puede aportar valor cada vez que sea necesario comprender, decidir o explicar algo importante del sistema.
2.6 Diferencia entre analizar y diseñar
Analizar y diseñar son actividades relacionadas, pero no son lo mismo. Analizar significa comprender el problema, sus necesidades, restricciones y conceptos principales. Diseñar significa decidir cómo se organizará una solución de software para resolver ese problema.
| Actividad | Pregunta principal | Diagramas frecuentes |
|---|---|---|
| Análisis | ¿Qué necesita el sistema y qué conceptos del problema debemos entender? | Casos de uso, actividades, clases conceptuales, estados. |
| Diseño | ¿Cómo organizaremos la solución para cumplir esos requisitos? | Clases de diseño, secuencia, componentes, paquetes, despliegue. |
| Comunicación | ¿Cómo explicamos y validamos una idea con otras personas? | El diagrama que mejor responda la pregunta de la conversación. |
2.7 Nivel de detalle adecuado
Un mismo tipo de diagrama puede construirse con distintos niveles de detalle. Un diagrama de clases conceptual puede mostrar solo conceptos del dominio y relaciones generales. Un diagrama de clases de diseño puede incluir métodos, visibilidad, interfaces, dependencias y decisiones más cercanas al código.
El nivel de detalle debe depender del propósito. Si el objetivo es validar una idea con usuarios, conviene evitar elementos técnicos innecesarios. Si el objetivo es guiar una implementación, puede ser necesario incluir más precisión. Si el objetivo es documentar arquitectura, tal vez sea mejor un diagrama de componentes o despliegue en lugar de un diagrama de clases enorme.
2.8 UML y requisitos
Los requisitos indican qué necesita cumplir el sistema. UML ayuda a organizar y visualizar esos requisitos desde diferentes perspectivas. Un requisito funcional puede relacionarse con un caso de uso, una actividad, una secuencia de mensajes o un cambio de estado.
Por ejemplo, el requisito "el paciente debe poder cancelar un turno" puede aparecer en un caso de uso, en un diagrama de actividades que muestra el proceso de cancelación, en un diagrama de secuencia que detalla la colaboración entre objetos y en un diagrama de estados que muestra cómo el turno pasa de reservado a cancelado.
Cuando varios diagramas representan partes del mismo requisito, deben ser coherentes entre sí. Si un diagrama dice que un turno puede cancelarse y otro no contempla ese estado, existe una inconsistencia que debe resolverse.
2.9 UML y código fuente
UML puede estar más cerca o más lejos del código, según el uso que se le dé. En algunos casos se crean diagramas conceptuales para razonar sobre el problema. En otros, se crean diagramas de diseño que reflejan clases, interfaces, módulos y dependencias que luego aparecerán en la implementación.
No siempre conviene documentar cada clase o cada método. Si el código ya expresa claramente una parte simple del sistema, un diagrama demasiado detallado puede volverse redundante y difícil de mantener. UML tiene más valor cuando aclara estructuras complejas, colaboraciones importantes, decisiones arquitectónicas o comportamientos difíciles de entender solo leyendo código.
2.10 UML y pruebas
Los diagramas también pueden apoyar el trabajo de pruebas. Un diagrama de actividades ayuda a identificar caminos alternativos y decisiones que deben verificarse. Un diagrama de estados permite revisar transiciones válidas e inválidas. Un diagrama de secuencia ayuda a comprobar si una operación produce los mensajes esperados entre componentes.
Cuando los diagramas se basan en requisitos reales, pueden servir como puente entre lo que se espera del sistema y los casos de prueba que verifican ese comportamiento.
2.11 UML en mantenimiento y evolución
Después de construir un sistema, muchas tareas consisten en corregir errores, agregar funcionalidades, adaptar integraciones o modificar reglas. En ese contexto, UML puede ayudar a entender una parte existente antes de cambiarla.
Un diagrama actualizado permite visualizar dependencias y riesgos. Si un componente depende de varios servicios externos, si una clase participa en muchos escenarios o si un estado se usa en distintos procesos, el cambio puede tener más impacto del que parece al principio. UML ayuda a hacer visible ese impacto.
2.12 Cuándo conviene usar UML
Conviene usar UML cuando el diagrama ayuda a reducir ambigüedad, explicar una decisión o comprender una parte compleja. También es útil cuando varias personas necesitan compartir una misma visión del sistema.
No conviene usar UML como una formalidad vacía. Un diagrama que nadie consulta, que no se mantiene o que no responde ninguna pregunta concreta termina perdiendo valor. Antes de crear un diagrama, es conveniente preguntarse: qué necesito comunicar, quién lo usará y qué decisión ayudará a tomar.
2.13 Errores frecuentes
- Usar UML solo al final del proyecto, cuando ya no ayuda a decidir nada.
- Crear diagramas demasiado técnicos para conversaciones de análisis.
- Crear diagramas demasiado generales para decisiones de diseño.
- No actualizar diagramas que se usan como documentación importante.
- Mezclar requisitos, diseño, código e infraestructura sin aclarar el nivel de abstracción.
- Construir diagramas sin explicar qué problema o pregunta resuelven.
2.14 Qué debes recordar de este tema
- UML puede utilizarse durante el análisis, el diseño, la comunicación, las pruebas y el mantenimiento.
- En análisis ayuda a comprender el problema; en diseño ayuda a organizar la solución.
- Un diagrama debe tener un propósito claro y un nivel de detalle adecuado.
- UML mejora la comunicación cuando el equipo comparte el significado de los símbolos y del modelo.
- No todos los diagramas son necesarios en todos los proyectos.
- Los diagramas deben ser coherentes con los requisitos, con otros diagramas y con las decisiones relevantes del sistema.
2.15 Conclusión
UML aporta valor cuando se usa para comprender, decidir y comunicar. Durante el análisis permite ordenar el problema; durante el diseño permite representar la solución; durante la comunicación permite compartir ideas con mayor claridad; y durante el mantenimiento ayuda a entender impactos antes de modificar el sistema.
En el próximo tema veremos los tipos de diagramas UML y cómo se agrupan según representen estructura, comportamiento o interacción.