A mi tampoco me gusta el UML aunque sea necesario… y deba usarlo.

(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.

3 comentarios en “A mi tampoco me gusta el UML aunque sea necesario… y deba usarlo.”

  1. en mi opinion “todo” en informatica puede ser facil usarlo mal ( incluso a nivel de programacion hardcode, asistentes, etc… )

    ya lo dice el refran “cada zapatero a su zapato” y como bien indicas en proyectos grandes donde hay arquitectos, gurus , etc… un lenguaje intermedio de lo que se tiene que hacer y como hacerlo puede ser UML… y evidentemente los arquitectos, usabilidad,mandamas o quien corresponda no tienen ni porque entrar a ver el codigo ya sea en .net en java en vb o como los analistas ( o quien corresponda ) definan mejor su implementación del caso..

    El problema reside que cuando estudias te enseñan UML y despues cuando empiezas la pifias pork la mentalidad en españa ( empresas pequeña – mediana ) es que el informatico hace de todo y es cuando vienen los problemas.. porque hacer el uml, el codigo, la documentación, la demostracion, el mantenimiento y encima tenerlo todo sincronizado…para una aplicacion normalita pues no tiene mucho sentido, mucho esfuerzo que no se ve recompensado. Yo he utilizado en un proyecto un poco grande UML y si… la documentacion se quedo desfasadisima con el tiempo, pero para empezar fue muy bien para tener una vision global y no empezar a picar a lo loco.

    Pero bueno creo que UML o otro que cumpla con su funcion es IMPRESCINDIBLE en proyectos muy grandes, no me imagino a los mandamas de proyecto visual studio mirando la documentacion del codigo del visual studio ni nada similar… imaginense las lineas que debe tener…

    solo es mi opinión que no soy un experto como rodrigo o tu ni de coña PAZ ;p

  2. Nadie a defendido aquí que no haya que documentar ojo!!!.Documentar es importante en proyectos pequeños y grandes. Solo que UML no es una buena herramienta. A mi no me sirve.

  3. Básicamente yo lo veo de la siguiente forma, UML permite describir las características que tendrá un sistema, desde su origen (problema) a su solución.

    Sin embargo UML carece de la capacidad de documentar el código y los algoritmos usados en el, minuciosamente. UML nos permitirá entender el problema y como se ha planteado su solución, pero el código que realiza el trabajo es algo totalmente diferente.

    Cuanto más grande es un proyecto, esto nos permitirá de manera más rápida ver que subsistema ó parte de la solución debemos retocar para alterar el comportamiento de la misma, pero una vez allí, nos encontraremos con el código que implementa dicha solución que es una historia totalmente diferente.

Deja un comentario

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