Por qué no me gusta UML

UML es una herramienta que casi todos los proyectos utilizan mal y que tiene tendencia al mal uso. Siempre que se plantea utilizar UML en un proyecto, se pone el enfasis en generar documentación, en realizar tal o cual diagrama, en seleccionar aquellos diagramas de UML que nos serán de utilidad.

El error en este caso es que se nos olvida que significa la L de UML, Lenguage. Y un lenguaje tiene como único cometido permitir la comunicación. Seleccionar una serie de diagramas es como arrancar las paginas a partir de la J del diccionario de la RAE y obligar a que la gente solo use las palabras que quedan. Seleccionar diagramas concretos es limitar la capacidad de comunicación usando UML.

La comunicación es algo que ocurre en un cotexto en un momento dado en el tiempo, y el motivo de la comunicación cambia continuamente, pensar que la documentación generada en un momento dado del tiempo será útil meses más tarde es pecar de ingenuo. A no ser que realmente pongamos más peso en la documentación que en el desarrollo de software, y la documentación tiene el problema de que no es ejecutable. La documentación ejecutable ya nos la vendieron las herramientas CASE y ¿alguien recuerda el nombre de una de esas herramientas? ¿Quien no ha estado un proyecto que despues de 10 meses solo tenia una cantidad infumable de documentación?

Que nadie piense que la postura que defiendo es que la documentación es innecesaria, solo defiendo que la documentación no asociada al código fuente o directamente generada desde el, pierde su validez tan rápido que no merece la pena generarla y mantenerla. Este tipo de documentación solo sirve para transmitir información en un momento del tiempo, comprender problemas y pensar sobre cuestiones y pierde su validez en cuanto a realizado su comentido, por tanto no merece la pena poner mucho enfasis en que sea correcta, siga estandares o plantillas, debemos poner el enfasis en que nos sirva para comunicar y sea flexible y facil de modificar, una pizarra es el elemento de comunicación ideal: lo escrito se modifica fácilmente, permite la colaboración de múltiples personas y puede mantenerse la información mientras es relevante y luego borrarse.

Tampoco defiendo que UML no tenga valor, pero solo como herramienta de comunicación, no como paradigma o método de documentación, que es como se tiende a utilizar. Aunque si cuestiono que sea mejor como herramienta de comunicación que cualquier otra herramienta, creo que es peor. Exige que todo el equipo conozca un lenguaje impuesto, que puede no ser natural al dominio de aplicación que nos ocupa, quiza DSL resuelva este problema, pero tiene mucho que demostrar aún.

Además UML no promueve de por si ninguna buena práctica de desarrolo de sofware. Solo es un lenguaje, uno que es facil de utilizar mal, que exige mucho esfuerzo de aprendizaje, demasiado para lo que proporciona y que es dificil de leer por alguien no iniciado. Ya todos contamos ya con un lenguaje y la capacidad de dibujar diagramas, de manera casi innata, creo que es mucho mejor ejercicio aprender a usar las herramientas con las que contamos en nuevos dominios. Si que es cierto que en ciertos contextos, facilita la comunicación, por ejemplo cuando se habla de patrones, pero solo es por un motivo cultural: los patrones tradicionalmente se han explicado usando UML.

La única documentación útil es la que emerge del código fuente y el código fuente de calidad es la principal documentación de cualquier proyecto.

24 comentarios sobre “Por qué no me gusta UML”

  1. Palabra de Dios. Totalmente de de acuerdo con tu postura pero, ¿que pasa si el proyecto que has desarrollado pasa a manos de otro equipo de desarrollo? ¿Deberian de leerse el código para entender lo que se está haciendo? Eso me suena a inviable. Quizas yo propondía la creación y almacenaje de pequeñas historias (como propone la XP) que expliquen el objetivo del programador aunque no siempre encaje con la version final. Esto ahorraría cientos de horas de mirar código. ¿No te parece?

    Saludos

  2. Ciertamente los Documentos requeridos por UML en su totalidad son muy tediosos de realizar y muchas veces toman mas tiempo realizarlos que desarrollarlos, pero yo pienso que es muy necesario, porque es nuestro sustento del trabajo o el desarrollo que se ah realizado. Porque luego viene los nuevos requerimientos y si no tenemos un sustento de lo que se acordó no tendríamos fecha de termino de desarrollo. En resumen se desarrolla solo que este especificado.
    Si la gente del proyecto no entiende UML se capacita y si no aprende, se cambia de personas por unas que si entiendan.

    Dario Qquecho Quispe

  3. Yo me he topado con que UML y en especial casos de uso son tomados como interpretativos, cada quien tiene un estilo para diseñar los diagramas, eso es basura por que al final no se determina como algo que siempre es exacto si Juan dice que son 3 bolitas pedro dice que es una y en realidad son 3 acciones del usuario ejem ALTA, BAJA, MODIFICACION, inclusive hay quienes no los toman en cuenta y prefieren poner algo como Transaccion cuando no determinaron que hay que llenar primeramente datos antes de hacer las transacciones,
    la verdad esto un rollo esto y la neta hoy odio mas esas metodologias por que se supone que en UML esta es la base para los diagramas siguientes.
    Creo que lo que debemos entender es que los casos de uso son las interacciones de los usuarios con el sistema y sobre esto enfocar nuestros desarrollos. pero por favor ponganse de acuerdo al sacar estandares.

  4. Creo que esto no es una discusion sobre si te gusta o no el UML.
    Es mas bien la justificacion para el desconocimiento que tienes de UML y las pocas ganas de aprender algo que realmente es valioso cuando se usa a conciencia (no con toda su pureza, no aplica para todos los proyectos) y poder aprender de los proyectos anteriores. Al parecer consideras que todos los proyectos son diferentes… acaso aun crees que un programa es diferente a otro?
    No te das cuenta que siempre escribes las mismas sentencias?
    Y que tal si desde el modelamiento te das cuenta que algo ya lo hiciste antes o alguien en otro proyecto ya lo tiene?
    No piense en UML como un poco de documentacion que no sirve para nada… imaginate que desde una diagrama en blanco estas pudiendo armar un rompecabezas de cosas y creando nuevas que mas adelante vas a poder reutilizar.

  5. Hola Ryan:

    No se que te lleva a prejuzgar mi conocimiento de UML. Te puedo asegurar que lo he conocido a fondo, durante un tiempo pense que era la solución a algunos problemas y lo estudie y aplique con interés… luego descubrí que no sirve y esto es lo que me llevo a «repertir las mismas sentencias» sobre este tema. No quiero que otros pierdan su tiempo como yo hice.

    Ahora, UML, ha ido al desván de mi cerebro donde guardo las cosas que aprendo, uso y no me sirven.

    Creo que confundes modelado con reutilización. ¿Necesitas UML para rehutilizar los componentes de terceros, el framawork de .Net o la clases de J2EE? La rehutilización es algo que detecta durante el proceso de diseño… usar UML para modelar durante el proceso de diseño no implica más o facilita la reutilización. Modelar es importante pero no nos da sistemas que podemos comenzar a usar, eso solo surge del código: http://geeks.ms/blogs/rcorral/archive/2007/12/12/no-persigas-tu-cola.aspx

    El problema es que no ves que lo que tu afirmas «desde una diagrama en blanco estas pudiendo armar un rompecabezas de cosas y creando nuevas que mas adelante vas a poder reutilizar» no es cierto. Se reutilizan clases, librerías, componentes, servicios… no cajitas y flechitas…

    Gracias por tus comentarios!!

  6. Hola Rodrigo,

    Considero que UML es mucho mas que una herramienta de documentación (y creo que en el fondo tu lo sabes). Acaso no conoces o has oído acerca de MDA y sobre todo MDD? teconolgías en donde el modelo (creado en UML) es el artefacto de primera categoría en el desarrollo de software, porque a partir de transformaciones del modelo conceptual, puedes llegar a generar código fuente en forma automática (y vaya que si yo lo he realizado).
    Saludos.

  7. Yo no digo para nada que UML sea una herramienta solo de documentación… digo que desgraciadamente es como mayoritariamente se usar… UML es una herramienta de modelado sobre todo o eso debería ser…

    Sobre la generación de código son muchos los riesgos que entraña… pero eso es otra historia…

  8. Hola de nuevo Rodrigo,

    El riesgo es algo que siempre estará presente en el mundo del desarrollo de software.

    Personalmente considero que en MDA/MDD la generación automática de artefactos (no solo código, sino documentación, archivos de configuración, casos de prueba, etc.) ha llegado a un nivel tal que podemos estar hablando que estamos ingresando verdaderamente a la era de la industrialización del desarrollo de software.

    No significa que se acabó el trabajo para los profesionales de la programación, sino por el contrario, ahora se requiere que se especializen para programar ya no en el dominio de las aplicaciones, sino en el dominio de los modelos (o inclusive meta-modelos) para implementar las transformaciones entre modelos. Es decir, se eleva su nivel de abstracción sin dejar de lado el profundo conocimiento que deben tener de la plataforma tecnológica.

    Sería muy bueno que abras una entrada sobre el tema MDA/MDD para que la comunidad pueda vertir sus comnetarios.

    Un gran saludo

    Sashir (desde Perú)

  9. Saludos, muy interesante y bastante acertada su apreciación, pero una pregunta: a pesar de que usted dice que la documentación mas efectiva es la del código, pero si el éxito de un sistema esta basado en su diseño en gran parte ¿que otra opción propone para documentar, modelar y avanzar dentro de las diferentes etapas de un proyecto?

  10. hola, pues creo que estas en tu postura y la respeto, el 60% del intelecto esta en el analisis del proyecto, por eso el documentarlo bien y el uso de UML, y utilizar un lenguaje como UML.

  11. No coincido:
    Sin leer la totalidad del artículo, solo escudriñé algunas partes y no coincido con ninguna, sobre todo la última; donde decís:

    «La única documentación útil es la que emerge del código fuente y el código fuente de calidad es la principal documentación de cualquier proyecto.»

    El código fuente de calidad nace de un cuidadoso diseño y no al revés.

    Vos querés hacer las cosas al revés; o sea, generar documentación a partir del código y eso no tiene pies ni cabeza. Muchos ingenieros en esta disciplina pecan de esto, justamente es al revés, el código se genera a partir de la documentación y no a la inversa; de lo contrario es documentar por documentar y eso no sirve, más de un tonto me dijo: «Después del código hacemos el diseño», le daba la razón; armaba el diseño en papel, codificaba y después le daba como documentación lo que había escrito en papel al principio, así he tenido que lidiar con aprendices de ingenieros, lamentablemente.

Responder a anonymous Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *