miércoles, abril 09, 2008

¿Está UML en decadencia?

miércoles, abril 09, 2008 por Martín


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.

comments

6 Respuestas a "¿Está UML en decadencia?"
deuteros dijo...
9:38

En principio yo diría que no ha triunfado todo lo que se preveía.

Mi experiencia personal es la siguiente: me lo enseñaron en la Universidad hará unos 8 años en plan dogma (creo que era un error común por entonces). Me refiero a que te decían que empezaras por los casos de uso, después al de clases, etc. Todo muy metódico y aburrido, infernal.

Así que en mis primeros años de trabajo prácticamente lo abandoné. Pero allá por el 2006 ya tenía la sensación de que el problema no era yo si no cómo me lo habían enseñado. En ese momento me encontré con la famosa frase "El 80% de los problemas se resuelve con un 20% de UML", así que a principios del 2007 me reciclé con un curso en el Instituto Tecnológico Informático de Valencia. Menudo cambio.

Aún así mi uso del UML es casi interno (personal) tal como explicon en http://deuteria.blogspot.com/2008/03/modelando-con-argouml-aplicaciones-en.html
uso los casos de uso para descubrir/definir interfaces gráficos de usuario, los diagramas de clases de diferente forma para para análisis, diseño o generación de código (incluida documentación). A partir de ahí es posible que use mas diagramas pero poco probable.

De cara al exterior puedo apoyar algún documento con diagramas pues en principio creo que casi cualquiera puede leer, interpretar, un diagrama UML que no sea excesivamente complicado.

Un saludo


Emilio Bravo dijo...
10:14

Si introduces UML en una metodologia Model Driven Development cobra mas sentido su uso. Nosotros básicamente usamos el diagrama de clases para definir entidades, servicios y DTOs. Utilizamos AndroMDA que a partir de estos diagramas nos genera la infraestructura base de clases y de ficheros de configuración para Spring e Hibernate.

En vez de usar UML se podría utilizar la nomenclatura que utilizan en el Domain Driven Design o crear algun tipo de DSL a tu medida a partir del cual generar los artefactos necesarios.

La idea principal es abstraerse de las tecnologías e intentar modelar en un lenguaje mas próximo a las personas.

Saludos.


Jorge Ubeda dijo...
21:38

Coincido contigo en cuanto a la adopción general, al menos en el ambiente que está y estuvo a mi alcance durante años. Encontrar una empresa que lo aplique, y más como herramienta de uso requerido, no es lo más común. Pero lo mismo vale para muchos otros estándares, en muchos más sitios que lo deseable, más allá de una primera línea. Más aún, he visto muchas veces estilos de representación basados en el diseño estructurado, que se diría difunto...
Quizá pese también el tamaño de los grupos de desarrolladores, y la necesidad de agilidad, algo que conoces bien.
Pero por otra parte, estoy de acuerdo con el comentario de Emilio: las extensiones de su uso que permite el diseño basado en modelos debería potenciar su adopción, dentro de las facilidades que MDA debiera ofrecer.


Martín dijo...
23:30

A mi, lo que más me ha llamado la atención, volviendo al tema original que me dió la idea de escribir esta entrada, es que en una conferencia como la QCon, donde hay cientos de personas en las salas, cuantas personas utilizan UML 2.0 y sólo un par de manos se levantan en la sala. Y estamos hablando de un estándar de cinco años.

En mi pasada empresa, empezamos un proyecto importante con UML 2.0 y fue un fracaso. No el proyecto en sí, sino el hecho de modelarlo con UML 2.0, ya que la gente no entendía los diagramas ni los nuevos conceptos; tampoco estaban acostumbrados a utilizar herramientas de modelado tipo Enterprise Architect sino que eran más de Visio que otra cosa.

Total que las reuniones se pasaban más en discutir porque estabamos utilizando UML 2.0, y lo que significaba cada cosa, que en hablar realmente del proyecto en si mismo. Cuando el seguir una aproximación con un subconjunto de UML suficientemente inteligible por todos los desarrolladores habría agilizado mucho más la evolución del proyecto.


Jose Manuel Beas dijo...
23:00

Nosotros (en DEGESYS) hemos pasado del UML-para-todo-todo (desde el más mínimo de los requisitos hasta un diagrama de despliegue que representara la arquitectura física de toda la empresa) a no hacer diagramas ni en las pizarras... :-(

Todo tiene una explicación y tiene más que ver con una reacción "alérgica" al "sobrepeso" de nuestra metodología anterior y a que muchos no han entendido aún lo que significa "viajar ligero" en un contexto de agilismo.

De todos modos, yo sigo buscando una herramienta de modelado UML sencilla y ligera. Para mi, lo más parecido era EnterpriseArchitect (se dibuja muy bien, está muy madura y no requiere una barrera de entrada alta -ni de aprendizaje ni económica-). Sin embargo, llevo más de un año luchando contra VisualParadigm y lo estoy pasando realmente mal porque es justamente todo lo contrario.

Yo, realmente (en el día a día) no necesito hacer MDA ni ingeniería inversa, ni ligar de ninguna manera mis xml con mis UML. Simplemente quiero no tener que pintar una y otra vez en la pizarra ese diagrama que sale en dos de cada tres discusiones con mi equipo.

Un saludo,
JMB


José Luis Barros dijo...
19:44

Hace bastante rato que leí el ya legendario libro de Steve McConnel, Desarrollo y Gestión de Proyectos Informáticos. En dicho libro, comentaba el autor, el círculo vicioso de los ingenieros de sistemas: vivimos demasiado ocupados con los cronogramas de entrega de manera que no tenemos tiempo para ponernos a estudiar en serio cómo hacer más rápido y mejor nuestro trabajo; pero por otro lado, nunca vamos a tener tiempo a menos que nos demos a la tarea de aprender cómo hacer mejor nuestro trabajo.

Esa paradoja me ha perseguido siempre en mi trabajo, hasta que un buen día tomé la decisión de tomar el toro por los cuernos: aprender de verdad que me ofrecen las nuevas metodologías y APLICARLAS en mi próximo proyecto. La verdad es que los resultados han sido muy significativos:

1. Es necesario entender que nuestro trabajo tiene un factor de complejidad generalmente alto. Luego, al pretender resolverlo de manera simplista lo más probable es que terminemos complicando aún más las cosas.

2. UML no es más que una forma estándarizada (la más sofísticada creada hasta ahora) para "pintar" el dominio de un problema. Todas las ingenierías cuentan con planos que permiten direccionar el avance de un proyecto. Ahora bien, UML es mucho más que un simple plano, es una vista multidimensional. Pero, por mucho que sepas UML sino lo utilizas dentro de un Proceso de Desarrollo adecuado, de muy poco te va a servir. Más bien por el contrario. Va a terminar convirtiéndose en un problema más a resolver. He utilizado UML como herramienta base del Proceso Unificado de Rational Sotfware y, la verdad, al principio fue difícil contener las ganas de irme rápidamente al modelamiento tradicional, pero manteniendo la disciplina y siguiendo el plan establecido por el Proceso Unificado, poco a poco fui entendiendo las bondades del proceso. Hoy en día soy un convencido de que con UML y el Proceso Unificado el camino que parece más complicado termina a la larga siendo el más rápido y fluido. Una vez que se han quemado las etapas del proceso, codificar termina siendo una tarea pueril. He comprobado que en un buen proceso de desarrollo, el 70% del tiempo se va en entender y modelar adecuadamente el problema.

Cuando uno empieza a estudiar UML se siente abrumado por los nueve diagramas y la cantidad enorme de artefactos y conexiones. Una vez que uno entiende bien donde encaja cada diagrama y cómo hacerlos adecuadamente, las cosas toman forma.

3. Como mínimo, pienso, un buen proyecto de software debería por lo menos contar con cuatro diagramas UML: Casos de Uso, Clases, Secuencias y Colaboraciones.

En muchas ocasiones, el diagrama de Componentes me ha resultado muy útil para organizar mejor el modelo.

Igualmente, cuando la implementación resulta un poco compleja, me he ayudado mucho con los Diagramas de Distribución. Con estos diagramas he podido preveer a tiempo sobrecarga de servidores y cuellos de botella.

Los otros diagramas los utilizo sólo cuando existe algún aspecto del problema que considero que podría esclarecerse con esos diagramas.

Los Casos de Uso me han parecido los más importantes. Prácticamente vitales. Los otros diagramas dependen enormemente de lo bien documentados que se encuentren los Casos de Uso.

Mi conclusión es que UML no es usado adecuadamente y por ello es que es difícil encontrar empresas que lo aprovechen en todo su potencial. Pero si se aprende bien a crear diagramas UML y se ejecuta el proyecto siguiendo un Proceso de Desarrollo adecuado, las posibilidades de éxito y satisfación de los clientes suben inmensamente.