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.