"UML no sirve para nada" – Reflexiones

En el post menos afortunado de este blog hubo un comentario acerca de UML en el que se aseguraba que UML no vale para nada. Yo contesté que UML no vale para nada si se utiliza mal. Quiero aprovechar para matizar este comentario en este post.


Creo que RUP tiene un problema serio, es demasiado pesado. Y en mi opinión sólo vale para generar toneladas de papel que luego casi nadie se lee. Y si bien la idea de UML de ser una «lingua franca» es interesante, en este tiempo que vivimos, con un auge de las metodologías ágiles, puede parecer un método un tanto draconiano de comunicar las ideas. También es cierto que UML según fue evolucionando se alejó bastante de ser un lenguaje sencillo (con los estereotipos, etc…) Y a día de hoy, alguno de sus creadores reniega de él.


Veo las ventajas que puede tener una metodología ágil en un equipo pequeño, y mucho más si ese equipo está compuesto por programadores muy competentes, ya que eliminar de un plumazo el peso que puede tener una metodología más pesada, en la que se dedica casi más tiempo en generar documentación no entregable que a generar código, es una ganancia de productividad muy interesante. Ojo, que no digo que no haya que generar documentación, y más en un negocio en el que la gente cambia con bastante frecuencia de trabajo, con lo que si no tienes una documentación suficiente, la curva de aprendizaje de una persona que entre para cubrir una vacante será bastante dura de superar.


Lo que no termino de ver es cómo puede encajar una metodología ágil en un proyecto en el que esté involucrado un equipo numeroso de programadores. Cuanto más numeroso es el equipo, más heterogéneo suele ser. Es decir, que las habilidades de los programadores no están equilibradas. En un proyecto de estas características tendrás un equipo de personas que se encarguen de recoger requisitos del cliente, y de alguna forma se tienen que comunicar a las personas que los van a implementar. A ser posible, debería de ser de una forma que sólo tenga una posible interpretación. Y de alguna forma se tiene que planificar o establecer cómo se van a comunicar los diferentes componentes de nuestro sistema, o los diferentes sistemas entre sí.


También he de confesar que las metodologías ágiles no son mi fuerte. De ser así, no tendría las dudas que expongo. Así que aprovecho para lanzar un par de preguntas al aire:



  • ¿Qué libros pueden explicar la problemática expuesta anteriormente? Me refiero a cómo encaja una metodología ágil en un proyecto grande.

  • Ya que UML está condenado, o al menos así parece… ¿Cuáles son las alternativas? ¿Algo similar a UML con colorines como los diagramas de clases de Visual Studio 2005? Creo que estamos todos de acuerdo en que simplemente explicar con palabras la arquitectura de un sistema no sirve, y que es necesario tener algún lenguaje de interpretación única (característica que no posee el lenguaje natural) para poder explicarla. Y lo mismo pasa con muchos otros aspectos, como por ejemplo el despliegue de las aplicaciones, la interacción con el sistema…

  • El hecho de que UML no sirva… No quiere decir que sigamos utilizando aquello que puede ser útil, no? Por ejemplo un diagrama de casos de uso, o diagramas de clases, de estados…

En fin, que estoy pidiendo que me iluminéis… Y que me comentéis vuestras opiniones 🙂

12 comentarios sobre “"UML no sirve para nada" – Reflexiones”

  1. Aupa!!!

    Me alegro de tu interés por las metodologías ágiles!!!

    El miito de que las metodologías ágiles no escalan tiene su origen en que cuando surgieron no se emplearón en proyectos grandes. Lógicamente, los ‘experimentos’ se hacer con proyectos pequeños. Según las metodologías ágiles han ido madurando y se ha ido ganando experiencia se han ido aplicando en proyectos más y más grandes. Hoy por hoy nadie discute que las metodologías ágiles son aplicables a grandes proyectos. Una lectura interesante sobre el tema es Scaling Agile Methods: eXtreme programming work for large projects?(http://www.ddj.com/dept/architect/184411706).

    Tanto en Agile Project Management with Scrum de Ken Schwaber (http://geeks.ms/blogs/rcorral/archive/2006/08/09/He-le_ED00_do_3A00_-Agile-Project-Management-with-Scrum-de-Ken-Schwaber.aspx), como en Managing Agile Projects de Sanjiv Augustine (http://geeks.ms/blogs/rcorral/archive/2006/11/13/He-le_ED00_do_3A00_-Managing-Agile-Projects-de-Sanjiv-Augustine.aspx), se describen técnicas para escalar las metodologías ágiles a proyectos grandes.

    Sobre UML decir que me parece que el problema esta en que a menudo se sobreutiliza. Es una herramienta más, pero no es una bala de plata. Si un diagrama de estados es la mejor manera de transmitir una determinada información, perfecto. Pero no creo que haya que diagramar por que sí. El mejor lenguaje de comunicación es el lenguaje natural por que es el que todos los interlocutores implicados en un proyecto con seguridad manejan mejor.

    Saludos!!!

  2. Hola a todos.

    Estoy de acuerdo que para sacar provecho de una metodologia hay que utilizarla. De nada sirve que se hagan diagramas si no se miran antes de meterte con el codigo de otra persona. Yo personamente utiizo dos que para mi son los que mas utilidad me dan: el diagrama de clases y el de colaboracion. Ambos los utilizo cada vez que tengo que meterme con un codigo que no es el mio para destriparlo y saber qué hace exactamente antes de cambiar una sola linea. Me pasa lo mismo cuando reviso un codigo que hace muchos meses que no he tocado; hago los diagramas de la parte que voy a tocar y me sirve para refrescarmelo todo.

  3. Klagges si alguna vez lees esto, te lo dedico.

    Metete tus documentaciones de software por el culo, cuando salgas a trabajar te las van a tirar por la cabeza, viejo maricón.

  4. bueno yo no se casi mucho de esO y acaban de pedirme la profe q es UML 🙂 nose si me pudieras ayudar es algo nuevo para mi ya q resien toy q comienso mi msn es niko_acuario@hot bueno es bueno saber tambien sus defectos del UML

  5. HOLA EN MY OPINION UML ES LA MAYOR HERRAMIENTA DE LA PROGRAMACION ORINTADA A OBJETOS EL PROPIO VIL GEIS LO AFIRMA PARA EL SIGLO VEINTIUNO SERA NECESARIO DOCUMENTAR TODO SISTEMA DE INFORMACION ANTES DE CODIFICARLO ESA ES MI OPINION………………………………..

  6. Hola Harri,

    Me alegro que tengas tu orientación sexual clara. Quizá este no sea el sitio más conveniente para salir del armario, pero en fin, tú mismo.

    En cuanto a que UML es una mierda… ¿por qué?

  7. Me parece interesante las ideas que manejan.. tengo como ingeniero de software aprox. 4 meses ya que akabo de egresar de la escuela… tengo el reto de documentar en mi trabajo un sistema grandisimo con varios aplicativos y que internamente en BD es complejo…

    Mi pregunta es como usar UML en un sistema ya hecho?? y de esta magnitud???? por dsonde empiezo :S???

  8. monica Puedes hacer ingenieria Inversa en cualquier programa que decidas utilizar, eso sirve bastante almenos con los diagramas de clases y los de componentes, al mismo tiempo desarrollas los diagramas de caso de Uso, tambien hay varios programas como el magicdraw para hacer ingenieria inversa a los diagramas de secuencia en lo particular son demasiado especificos, prefiero hacerlos generalizados. Claro antes de hacer todo esto analiza bien las BD para que puedas tener clara imagen de la informacion que manejas
    SUERTE!!!
    Si estoy de acuerdo UML no sirve de mucho pero por lo menos te orienta en el funcionamiento del sistema.

Responder a anonymous Cancelar respuesta

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