UML es una basura!

Está bien, una notación gráfica estándar para representar el diseño de software es algo bueno ¿no?, sin embargo UML parece que es lo mejor y lo peor en esta área por unas cuantas razones.

UML perdio a los programadores, no hay duda de ello. Y cuando una tecnología de diseño de software pierde a los programadores se desvanece y no importa lo que piense la academia. UML es muy bonito en papel, pero cuando se empieza a usar se puede observar su mayor falla: se parece mucho a papeleo burocrático y administrativo sin sentido.

A continuación una lista de lo que salió mal en el proceso de adoptar UML como "estándar" de diseño:

1. Redundancia:
   La representación de UML está ligada a un proceso en particular del desarrollo de sofware, por lo tanto, hay diagramas que son similares (diagramas de clase y de concepto) pero cuya mayor diferencia es que simplemente se usan en distintas fases del proceso (análisis y diseño). Inencesariamente redundantes y son tan parecidos que causan confusión.
   
2. (In)Utilidad:
   La utilidad de los diagramas es discutible, no he conseguido nadie que sea capaz de entender un diagrama de casos de uso o un diagrama de clases sin haber estado involucrado en el proceso de creación. Además creo que ningún programador vuelve a ver los diagramas de casos de uso o los diagramas de colaboración una vez que empieza a escribir el código, simplemente escribe el código para que el software cumpla con los requisitos del cliente, no para que el cliente sepa que el código es bonito y está bien estructurado.
   
3. La obsesión de ponerle precio:
   Tratar de vender herramientas costosas por una tecnología que no es lo suficientemente madura (15 años después de su concepción!) y sólo hace promesas a la gerencia (sólo expresa tus ideas en dibujos y el código será generado por nuestra varita mágica) sólo puede funcionar a corto plazo. En algún momento alguien se dará cuenta que los costos son más grandes que los beneficios.
   
4. Trata de guardar todo bajo el colchón:
   Cuando tratas de ofrecer una solución para cualquier problema, al final no estás ofreciendo algo útil para ningún problema. UML trató de resolver todos los problemas relacionados con desarrollo de software. El software es usado o puede ser usado para casi cualquier actividad humana, tratar de capturar todo es una tarea imposible, a pesar de su "capacidad", UML sólo cubre una pequeña parte de la complejidad que necesita la ingeniería de software. Es demasiado grande y a la vez demasiado genérico y abstracto.
   
5. Exceso de conceptos:
   Tratar de incorporar la manera de representar conceptos de todos los lenguajes "de moda" en los últimos 10-15 años y sin embargo nadie sabe como representar una clase interna anónima de Java.
   
6. Siempre estar actualizado:
   Es una continuación del apartado anterior, como siempre se promete que la ventaja es la generación completa de código se tienen que poder representar las construcciones específicas de cada lenguaje. ¿Se podrá lograr en algún momento?
   
7. La necesidad de una herramienta posiblemente costosa vs. un editor de texto:
   El precio para usar UML para más que simplemente compartir ideas en un pizarrón es bastante alto. Las herramientas increiblemente buenas son increiblemente costosas. Además de eso se necesita capacitación y entrenamiento porque no siempre son herramientas intuitivas. Las consultoras adoran estas herramientas porque así abren oportunidades de impartir cursos de capacitación costosos.
   
8. Falta de claridad en el modelo:
   Las imágenes son interpretables. No importa que tan bueno sea el diagrama, tienes que ver el código para realmente entender el qué y el cómo de un determinado programa.
   
9. Falta de soluciones para problemas comunes:
   A pesar de que las especificaciones son enormes, no hay soluciones buenas para problemas comunes en algunos sistemas. Algunos ejemplos son: representación de multi-tareas y comunicación entre las mismas.
   
10. Asume que puedes saberlo todo antes de escribir la primera línea de código:
    El concepto de escribir primero el manual del usuario y después generar el código basándose en éste es una idea "algo" buena pero la mayoría de las veces es imposible de conseguir. En la práctica todo es tan dinámico, que el mantenimiento de los diagramas de UML para que estos compaginen con el código se convierte rápidamente en la tarea que nadie quiere hacer.
    
11. Las herramientas UML se enfocan en la tarea equivocada:
    La mayoría de las herramientas UML prometen la generación automática de código. Esto es la mayoría del tiempo una inutilidad porque casi siempre se generan clases vacías sin ninguna lógica del negocio. También es fastidioso porque se tiene que mantener el código y los diagramas en "sincronización".
    
    La herramientas debieron enfocarse en ingeniería en reverso con propósitos de documentación, creo que no existe una herramienta lo suficientemente completa que maneje esta área; incluso algunas herramientas que logran hacer ingeniería en reverso del código, realizan un trabajo pobre en el área de documentación porque no son capaces de diferenciar lo que es esencial de lo que no. Como resultado la mayoría de los proyectos que usan UML tienen código que no se acerca a los diagramas que se hicieron al principio del proyecto.

UML simplemente retrasa el trabajo efectivo de los desarrolladores; una idea o una funcionalidad que se puede diseñar, implementar y probar en 2 semanas se convierte en un via crucis de documentos, entregables, diagramas y descripciones que pueden tardar semanas e incluso meses en ser completados.

La idea detrás de UML fue buena: una forma de lograr una comunicación "sencilla" entre los distintos grupos de desarrolladores y los clientes. Pero cuando un estándar de especificación es tan abierto y confuso pierde su valor, la gran cantidad de diagramas existentes y las mil y un formas (todas correctas) de representar un concepto hacen que UML sea un lenguaje visual recargado y monstruoso y no facilitan las cosas al momento de desarrollar nada.

Quizás UML tiene un valor oculto que no logro entender.... nah, no creo.