Muy interesante pregunta la que se planteaban hace unos días en Coding the Architecture. ¿Está UML en decadencia?
La verdad es que hace diez años, cuando estaba en la facultad y tocaba estudiar lo poquísimo que te enseñaban sobre UML, te imaginabas el llegar a las empresas con tu título de ingeniero-sabedor-de-modelado y empezar a trabajar en modo artista: secuencia por aquí, clase por allá, transición por aquí. Incluso tengo que confesar que en mis primeros años, hasta había ocasiones en las que me tengo esforzado y creado cosas bastante interesantes en UML. ¡Qué digo cosas interesantes! ¡Sí hasta tengo probado varias herramientas que me transformasen el UML a código!
Con el paso de los años, no sé si es que he caido en sitios menos profesionales (que lo dudo), más vagos (que también lo dudo) o es que simplemente me he dado de bruces con la realidad. Y es que a la hora de la verdad, que más da si la mayoría de la gente con la que vas a tratar o bien no sabe lo que es UML, o bien sabe las dos pinceladas básicas, o bien conoce un par de diagramas. Eso sí, hay casos como en la administración pública en los que a la hora de entregar la documentación de determinados proyectos es probable que te pidan literalmente toneladas de diagramas que nadie leerá. Claro, nada que no solucione un buen generador automático :-)
Visto el panorama, ¿de qué vale hacer tu super-diagrama en UML 2.0 si nadie lo va a entender? Sí, es triste, pero es que a mi me da la impresión de que es la realidad. Y si al final nadie entiende tu diagrama, entonces el hacerlo en UML 2.0, por muy cool y estándar que sea, es algo totalmente inútil ya que va contra el primer principio del lenguaje de modelado que es la expresividad. En los últimos años, a la hora de mostrar diagramas, me he encontrado con los siguientes tipos de personas:
- Los que realmente entienden UML: desarrolladores y arquitectos a los que les interesa el tema, que han tenido también que dibujar en numerosas ocasiones, y a los que les puedes enseñar cualquier tipo de diagrama por complejo que sea porque entenderán a la primera lo que estás expresando. La minoría.
- Los que entienden UML pero se han quedado en lo básico: desarrolladores y arquitectos a los que les suena UML porque lo han estudiado o leído en su momento pero que realmente no les importa un comino. Saben lo básico, es decir que hay cajitas y flechas. Conocen estructuras básicas como la herencia y los diagramas más habituales. Pero que sin embargo no saben distinguir entre una dependencia y una implementación, o entre una llamada síncrona y asíncrona.
- Los que simplemente no entienden UML: La mayoría de managers, project managers, business analysts, etc. Verán un conjunto de figuras y flechas. Nada que no pueda hacerse en PowerPoint.
Visto el panorama, es triste ver como mis diagramas en los últimos años han ido evolucionando a un híbrido entre todos los tipos. Personalmente utilizo los siguientes diagramas: de clase, de secuencia, de casos de uso, de despliegue y de componentes. En los diagramas de clase suelo quedarme en lo básico y la verdad es que la mayoría de las veces me como clases e interfaces, o hago uso extensivo de paquetes. Dibujo lo mínimo para que sea legible y entendible, incluso por un no-informático.
En los diagramas de secuencia, cuadrados y flechas. Quizás alguna llamada asíncrona, pero es que tiene que estar realmente clara. En los diagramas de despliegue y componentes, bueno, eso casi que con el tiempo lo he transformado en un diagrama despliegue-componentes porque al final últimamente acabo por poner todo en el mismo diagrama, quedando una mezcla atroz aderezada con diferentes tipos y sabores de formas básicas del Microsoft Visio. Sniff.
Y es que hace unos meses tenía una conversación con un gran amigo mio, versado en UML, que me comentaba que mis diagramas no eran "exactamente" UML. Yo le comentaba, "Lo sé. Pero ya sabes que el UML es en sí un lenguaje de modelado libre, y lo que cuenta es la expresión". Mi amigo discrepaba, ya que considera que ese no es su problema y que la gente debería esforzarse en aprender UML, no esforzarnos nosotros en tratar de encontrar una manera de romper las normas de dibujado para expresarnos de forma que lo puedan entender. Totalmente de acuerdo con esto último, pero es que lo veo tan lejos...
¿Qué opináis vosotros sobre esto? ¿Creéis que el uso de UML ha ido decayendo con el paso de los años? ¿Alguien usa UML 2.0? O habéis tenido la desgracia de ir cayendo en los híbridos por las exigencias del mercado.
