(Esto empezó siendo un comentario a un post de Rodrigo)
En eso estamos…. Vamos que no me gusta el UML, que lo entiendo, lo comprendo y lo respeto, pero a mi no me gusta, que le vamos hacer. A ver si consigo explicarme …
Creo que UML es una buena herramienta y es necesaria, pero no es adecuada para todo tipo de proyectos, en especial para proyectos pequeños y medianos, supongo que es por eso por lo que Rodrigo dice que tiene “tendencia al mal uso”.
También pienso que UML requiere un nivel alto de experiencia, UML es un lenguaje y al igual que todos los lenguajes hay gente que los habla/escribe/entiende bien, muy bien, mal y regular. UML requiere mucha experiencia en el análisis de proyectos. Es como aquellos que creen que por usar el mejor editor de textos del mundo escribirán best-sellers mientras que el buen escritor escribirá bien a lápiz, boli o usando el notepad.
Yo creo que UML es para que los analistas modelen y los programadores programen, si se cambian o alteran los papeles el proyecto se convertirá en un desastre. ¿Se te ocurriría dejar a un arquitecto hacer un tabique ó lo que es peor a un albañil hacer un proyecto?
UML esta pensado para diseñar y documentar. UML debe ser como los planos de un edificio, en donde cada uno encontrará lo que busca, sin embargo creo que se olvida el hecho de que hay tres grandes cosas que documentar en un proyecto.
– El problema, la solución, y el código.
Y las tres están unidas por lo que un cambio en cualquiera de ellas, implicará un cambio en al menos una de las otras partes. Mantener toda esta documentación perfectamente sincronizada (es la única manera de que sirva de algo) supone un elevado esfuerzo.
UML propone una serie de diagramas y símbolos para documentar las tres fases, podrá estar limitado ó no, por lo que creo que cuando Rodrigo dice: “El error en este caso es que se nos olvida que significa la L de UML, Lenguaje. Y un lenguaje tiene como único cometido permitir la comunicación.”, “Seleccionar una serie de diagramas es como arrancar las páginas 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.”
De este modo da por hecho el cualquier analista con conocimientos de UML, entenderá el UML, de otro modo si cada uno hace lo que le da la gana, usa los diagramas que más le gusten con su simbología personalizada estaría por el contrario impidiendo la comunicación de igual forma.
Para que dos o más personas se entiendan necesitan establecer un lenguaje común que ha de estar formado por un conjunto de símbolos (alfabeto). Esto es lo que propone UML.
Tú puedes diseñar una solución a un problema y documentarla usando UML yo puedo entenderla usando mis conocimientos de UML, sin necesidad de mirar y entender el código. Piensa que puede estar programada en Berzotas.Net del cual yo no tengo ni idea.
En cuanto a la documentación, UML puede que no sea la panacea para documentar el código, pero ayudará a identificar cada uno de los sistemas de nuestro aplicativo y como interactúan entre ellos. Obviamente a los programadores nos gusta más (también por que lo hemos hecho así durante mucho tiempo) ver otra case de documentación.
Con lo expuesto, coincido plenamente con lo que dice Rodrigo acerca que solo es un lenguaje, que es muy fácil usarlo mal, exige mucho esfuerzo de aprendizaje, que no proporciona muchas ventajas salvo en proyectos grandes o complejos.