Por qué UML no sirve

En el año 1999 cursé una materia de ingeniería de software y tuve la desdicha de encontrarme con el “lenguaje” de moda para el análisis y diseño (supuestamente) orientado a objetos: UML (“Unified Modelling Language” o “Lenguaje Unificado de Modelado“) y su metodología asociada: el “Proceso Unificado“.

Ya desde el comienzo (al leer el manual de referencia de este lenguaje visual y el libro que describe la metodología), me resultó bastante incómodo, poco expresivo y hasta inconsistente en algunos aspectos. Con el correr del tiempo (al conocer otras metodologías de diseño de sistemas y al adquirir mayor experiencia en el campo), fui afianzando mi opinión sobre UML: es totalmente inútil y contraproducente.

Se que quizás estas afirmaciones suenen un poco fuertes, pero realmente no puedo utilizar términos más suaves para describir a este “lenguaje visual” y su metodología asociada. Reconozco que algunos de sus diagramas pueden ser útiles para modelar algunos aspectos de algunos tipos de sistemas, pero en general, es una pésima idea utilizar UML para documentar el proceso de desarrollo de software y el Proceso Unificado para conducirlo.

Para empeorar la situación, es tal la campaña publicitaria que se ha montado alrededor de UML desde su aparición, que en la actualidad es la notación preferida por muchos que dicen utilizar metodologías orientadas a objetos (entre ellos el Object Management Group). El por qué del éxito y la inutilidad de UML parecen estar explicados en un sólo párrafo (extraído del artículo “A Comparison of the Business Object Notation and the Unified Modeling Language” de Richard Paige y Jonathan Ostroff, cuya lectura recomiendo ampliamente):

En 1995, existían entre 20 y 50 notaciones y lenguajes de este tipo. A menudo, los usuarios tenían que elegir entre varios lenguajes de modelado similares con diferencias menores en poder expresivo global. Pero en un encuentro decisivo en Silicon Valley en 1995, metodistas y productores de herramientas acordaron que los usuarios necesitaban un estándar mundial para el metamodelado y la notación. En ese momento nació UML, y ha sido adoptado por desarrolladores de software principales.

Está claro entonces que UML nació de la necesidad de unificar un gran número de notaciones diferentes, y más como un acuerdo comercial que como el producto de una investigación profunda. Esto también queda en evidencia por el hecho que sus tres principales autores (Grady Booch, Ivar Jacobson y James Rumbaugh) se asociaron para crear una empresa (Rational Software, luego adquirida por IBM). Nada demasiado bueno puede surgir de la unión apresurada de un montón de cosas incompletas guiada por objetivos comerciales. UML y el Proceso Unificado nunca fueron más que eso.

Afirmo esto sin importarme que UML sea quizás la notación más utilizada en la industria actualmente. Como bien dijo Dijkstra, “los errores industriales no son sacrosantos sólo porque se cometan a gran escala“. (Si lo que usted busca es trabajo, probablemente necesite conocer UML, pero eso no lo transforma en una mejor herramienta.)

En 1997 Bertrand Meyer (creador del lenguaje Eiffel que se apega al método BON) escribío un artículo de tono gracioso (en el que un supuesto estudiante escribe a su profesor) llamado “UML: The positive spin” en el que desnuda las principales falencias de UML (en un tono para nada respetuoso, debo decir).

Después de años de tenerlo en mi lista de artículos a traducir, finalmente me he decidido a hacerlo. Ojalá sirva de utilidad a quienes hayan sido víctimas de la campaña publicitaria en favor de UML.

(También puede descargar la versión en PDF de este artículo.)

UML: El giro positivo

Por Bertrand Meyer

 

De: Cándido Smith, alumno de OO-101
A: Profesor Severa Stern
Asunto: Mi solicitud para el cambio de calificación

Estimado Profesor Stern:

El auxiliar de cátedra de su clase OO-101 me ha indicado que le escriba directamente sobre la calificación D-menos que obtuve en mi artículo “Una evaluación sobre el Lenguaje de Modelado Unificado (UML) propuesto“. Espero que usted considere cambiarla por una mejor (¿quizás una D?), ya que sería un alivio para mi promedio de calificaciones, ya debilitado luego del “Reprobado” que me puso en su última clase. (Quizás recuerde que en el examen final escribí “debe haber otras cosas entre las rebanadas de pan y Java“. Ahora me doy cuenta de lo poco aconsejable que fue ese comentario, y sinceramente pido disculpas si herí los sentimientos de alguien.)

Por supuesto, me doy cuenta del motivo de mi D-menos y aprecio su generosidad en no ser haber sido más duro. Como el auxiliar de cátedra me indicó, ¡no hay nada positivo sobre UML en mi artículo! Seguramente no puede ser correcto. Todo el mundo sabe que UML abre una brecha en la ingeniería de software, ¿y quién soy yo para cuestionar esto? Este es el por qué no le pido que cambie mi nota sólo por el efecto en mi promedio, aunque espero entenderá que no es agradable perder mi seguro de Buen Estudiante, por no mencionar novias y cosas por el estilo. No, admito que estaba equivocado y quiero enmendar mi error. Debe haber algo bueno que decir sobre UML.

Y puedo asegurarle que aprenderé la lección: ser positivo. Cualquiera sea el tema, siempre es posible darle un giro positivo. ¡El diario de esta mañana hasta imprimió un adjetivo que puede ser interpretado como no poco favorecedor en un artículo sobre Newt Ginrich! ¿Por qué entonces no sobre UML?

¡Se positivo!

Por lo tanto he seguido el consejo del auxiliar de cátedra. Por ejemplo, podría haber cosas buenas que decir sobre la notación misma. Podría ser simple, usable, convincente, fácil de aprender. Y hay de hecho tal notación para el análisis y el diseño orientados a objetos, cuyo conjunto completo de símbolos gráficos cabe en una página y cubre todas las técnicas básicas de descripción de sistemas Orientadas a Objetos, y el cual es particularmente bueno al escalar hasta la descripción de sistemas de gran envergadura: la Notación de Objetos de Negocios (BON) de Waldén y Nerson, como está descripta en su libro [3]. Por supuesto UML no tiene ninguna de esas propiedades. En su intento de mostrar que ha incluido las ideas de todos, es un desborde de símbolo tras símbolo bizarros. Solo el “Resumen de la notación” ocupa 60 páginas y ¡tiene su propio índice! UML es, de hecho, tan complejo como un lenguaje de programación grande y críptico, con un uso generoso de “$” y “#” y “-” y “*” y “triángulos sólidos sin cola” y rectángulos y diamantes y líneas sólidas y líneas punteadas y elipses sólidas y elipses punteadas y flechas de todo tipo y palabras reservadas tomo “const” y “sorted” (no confundir con “ordered“) y semánticas distintas para una clase dependiendo si su nombre aparece en letra “romana” o “itálica”. ¡Pero al menos un lenguaje de programación, incluso el peor de ellos, es ejecutable! Aquí hay que aprender toda esa complejidad monstruosa para construir diagramas de un posible sistema futuro.

Lo cual nos lleva a la pregunta del desarrollo continuo (“seamless”). Una vez que usted tiene su hermoso (o no tan hermoso) diagrama, querrá construir un sistema, salvo que el presupuesto ya se haya gastado en herramientas CASE (algo común para empresas que toman demasiado enserio la publicidad exagerada de la “metodología” y terminan sin dinero para el desarrollo real). Pero entonces debe recomenzar con un lenguaje de programación para hacer el trabajo real. ¿Y cómo mantiene la consistencia entre el programa y los diagramas? Waldén y Nerson convincentemente discuten el objetivo de continuidad (proveer un proceso único y continuo) y reversibilidad (ser capaces de moverse hacia atrás y hacia adelante entre el análisis, el diseño y la implementación). Herramientas como EiffelBench y EiffelCase soportan esta inquietud, pero no parece ser para nada una inquietud con UML. Pero por supuesto cualquiera que use UML debe ser listo -no solamente para aprender todos los símbolos- y por lo tanto hará un análisis correcto desde la primera vez, luego un diseño correcto desde la primera vez y luego nunca tendrá que cambiar nada en los próximos diez años de la vida del proyecto. O quizás UML es para proyectos cuyas especificaciones nunca cambian. Mi abuela me contó que una vez escuchó sobre un proyecto así en su juventud. Creo que dijo que tenía algo que ver con calcular el 6to. número de Fibonacci.

¿Orientado a Objetos?

Así es que tengo que buscar en otra parte para encontrar algo positivo que decir sobre UML. Estoy tratando con esfuerzo, y espero que lo tome en cuenta antes de enviar las notas finales a la administración. (Recuerde, sólo estoy pidiendo una D, aunque por supuesto una C-menos sería más que apreciada.) Por ejemplo, he intentado ver si podría caracterizar a UML como “orientado a objetos”; todos sabemos que este es un gran logro. Gran oportunidad. Por supuesto los autores hacen uso de los requeridos “objeto“, “herencia“, etc. Pero una simple mirada a los diagramas muestra a UML como lo que es: una extensión del modelado de entidad-relación. Los ejemplos básicos muestran asociaciones binarias y ternarias, tales como (página 16 de [1]) asociaciones entre “vuelo“, “asiento” y “persona“; esto es diametralmente opuesto al diseño orientado a objetos, donde, como todos sabemos, el mundo está estructurado en clases, construido sobre tipos de objetos y cada operación o propiedad pertenece a una clase. Seguramente en diseño orientado a objetos, ¡no podrá tener un enlace “pasajero” que trate simétricamente a “asiento“, “vuelo” y “persona“! En un sistema orientado a objetos, pertenecerá a una de las clases; así es como se obtiene la consistencia, simplicidad, modularidad y reusabilidad de la arquitectura OO. Fíjese en BON o Eiffel y disfrute los resultados. Los autores de UML saben esto, por supuesto; para entender por qué llaman a UML orientado a objetos debemos apreciar su famoso sentido del humor. Obviamente lo dicen en broma. (¿Es esto lo suficientemente positivo?)

La evidencia posterior de la broma es provista por la referencia frecuente a los “casos de uso” como un elemento central del método. Cuando “caso de uso” era la consigna de la Web, traté de entender de qué se trataba, y me fue difícil hasta que le pregunté a mi abuelo, quien me lo explicó todo: es el nuevo nombre para el análisis funcional descendente (top-down) de su adolescencia. Uno se fija en qué debe hacer el sistema (“casos de uso”) y deduce su arquitectura de ese análisis. Esto es diametralmente opuesto al diseño orientado a objetos, el cual conscientemente rechaza prestar demasiada atención, durante las primeras etapas, a las funciones principales del sistema, porque están muy sujetas a cambios, porque reproducen el comportamiento de sistemas previos (aquellos que estamos tratando de reemplazar con el nuevo sistema), porque llevan a un compromiso temprano con el orden de operación (¿el aspecto más volátil del software?) y porque se enfocan en las cualidades superficiales del sistema -su interfaz con el resto del mundo- en vez de en sus propiedades fundamentales. En cambio, el diseño OO se concentra en el tipo de los objetos manipulados por el sistema, y define cada uno de esos tipos a través de la lista de todas las operaciones aplicables y sus propiedades abstractas -contratos- sin importar el orden de aplicación. Mi abuelo agregó que estaba agradecido de que los casos de uso estuvieran presentes en UML, porque le traían recuerdos de los buenos viejos tiempos y que nunca le gustaron los objetos. (Creo que este es un comentario positivo.)

Encontrando un uso para UML

Obviamente UML no será útil a ningún desarrollador de software. ¿Podría quizás ser útil a alguien más? ¿Líderes de proyectos, quizás? ¿Ejecutivos de empresas? ¿Las empresas mismas? Por supuesto, no. De hecho, la documentación no hace ninguna pretensión de tal utilidad, y por buenas razones. Es difícil de imaginar qué benericio podría obtener un negocio de páginas de diagramas crípticos sobre propiedades confusas de un sistema pobremente comprendido.

Por lo tanto, busco más allá. A veces una propuesta ofrece una solución fallida, pero tiene el mérito de plantear el problema correcto. ¿Podemos decir esto de UML? Espero que sí. Aunque sea podría ayudar a mi promedio y, haciendo esto, me ayudaría a levantar mi autoestima, por no mencionar las novias y cosas por el estilo, pero me estoy desviando. Dicho sea de paso, ¿a qué problema apunta UML? He tratado con empeño, en los interminables documentos del sitio web de Rational, de encontrar una descripción del problema (lo cual se nos enseñó en nuestros cursos de ingeniería, debería aparecer en la introducción de cualquier documento técnico). Me temo que no he encontrado nada útil que reportar.

Amanda al rescate

Para ver qué metas debería haber perseguido, revisé el artículo de mi amiga Amanda Suertuda, la única que obtuvo un A-mas:
Los desafíos de la industria del software“. (De paso, profesor, no logro comprender por qué Amanda siempre consigue los temas interesantes.) Su reporte, muy agradable debo confesar, hace un buen trabajo al describir los obstáculos técnicos que los desarrolladores deben superar. El buen software debe ser correcto; olvidemos una aserción en una rutina, y tendremos un desastre de u$s500 millones como la reciente explosión del Ariane 5, resultado de un intento equivocado de reutilizar una rutina de Ada sin un mecanismo de aserciones como el de Eiffel (ver la edición de enero de 1997 de IEEE Computer). No veo nada en UML que ayude a la corrección; sólo algo de palabrería dedicada a la noción de contrato, pero los autores muestran que no entienden nada de la idea del Diseño por Contratos (por ejemplo, ¡mezclan requerimientos semánticos con simples declaraciones de tipos!). El buen software debe ser robusto. ¿Cómo ayuda UML? El buen software debe ser fácil de modificar (Amanda llama a esto “extensibilidad“); pero el aparato pesado de UML garantiza cualquier cosa menos que los desarrolladores serán capaces de producir alguna descripción del sistema en la cual no será horroroso cambiar algo. El buen software debe ser reutilizable; nada en UML apunta a los desafíos de la reutilización, tales como las convenciones de estandarización de interfaces, separación de comandos y opciones, separación de comandos y consultas, etcétera. El buen software debe ser eficiente -oh, lo lamento, esto está relacionado a la implementación, y no hablamos sobre implementación en compañía educada. (Si UML se ocupara de la implementación, debería ocuparse de cuestiones relacionadas con el software; lo bueno de las burbujas y flechas, en oposición a los programas, es que nunca se cuelgan.)

En cambio, los documentos de UML parecen tener un único objetivo: una y otra vez convencer al lector de que no ha omitido ninguna consigna, como en este extracto, página 31 de [2], que intenta explicar que los patrones (patterns) son interesantes pero están cubiertos por el concepto de los autores de “diagrama de interacción“, cualquier cosa que esto sea (no puedo imaginarlo):

El aspecto interesante de muchos patrones es su comportamiento dinámico. Ciertamente podemos mostrar esto con diagramas de interacción, pero sólo en el contexto de un modelo específico. Es difícil mantener la “patronidad” de los patrones abierta. A fin de cuentas, los patrones son plantillas (en algún sentido), en los cuales las clases, asociaciones, atributos y operaciones pueden estar asignadas a distintos nombres, manteniendo la esencia del patrón. Necesitamos una forma de parametrizar claramente los patrones. Sin embargo, creemos que tenemos suficientes formas de capturar patrones en UML expresándolos en términos de interacciones.

Francamente, ¿quién está interesado en esta farsa? ¿Cómo puede alguien creer que tiene algo que ver (en algún sentido) con la industria del software? Y ni siquiera he citado cosas sobre el “metamodelo“. Quizás usted podría pedirle a Amanda que dedique su próximo artículo a la “patronidad“. Hablando de desafíos.

Un amigo que asistió recientemente a una conferencia sobre orientación a objetos me contó sobre las bromas sobre UML que los expertos en OO -algunas de las personas más respetadas en el área- intercambiaron durante los intervalos y en el fondo de las salas. Él no podía creer el contraste entre el bombo público y el menosprecio privado. Pero los CEOs y otros tomadores de decisiones sólo escuchan el bombo publicitario; se les dice que UML es orientado a objetos o, más a menudo, que orientación a objetos significa UML. Cuando no pueda ayudar al desarrollo de software, UML le dará un mal nombre a todo el campo de la OO. Dado los bombardeos de mercadotecnia a su alrededor, UML, al no cumplir con sus promesas, tiene el potencial de retrasar el progreso de la tecnología de objetos por diez años.

¿La respuesta al final?

Así pues, profesor, ¿qué puedo decir, qué puedo decir? Fui con el auxiliar de cátedra y le pregunté si decir “La página principal de Rational tiene lindos colores” ayudaría. Pero me dijo que no, que tendría que encontrar algo más sustancioso. Intenté con “al menos en su última revisión han dejado de llamar a sus cosas “método”, lo que muestra que tienen algún sentido del ridículo“. Tampoco le bastó. Así que busqué y busqué y, finalmente -estoy tan excitado- ¡lo encontré! ¡Sí, UML tiene un propósito después de todo!

La razón por la cual no lo descubrí antes es que sólo aparece en la conclusión. Un lugar extraño para describir sobre qué uno estuvo escribiendo, pero mejor que no hacerlo en ninguna parte. Por supuesto que lo que encontré no es un objetivo técnico (UML, como ya dije, no sirve a ningún propósito relacionado con el software, lo cual está bien para mí -algunas personas tienen mejores cosas que hacer con sus vidas que tratar de mejorar la tecnología del software). No es un objetivo gerencial, al menos no para personas que administren proyectos de software. No es un objetivo de negocios, al menos no para negocios que usen UML. Pero es un objetivo.

Cuando finalmente descubrí el objetivo, casi rompo en llanto por el espíritu generoso y noble de los autores. Sería injusto decir que las parvas de documentación de UML están vacías de toda substancia, cuando de hecho contienen una idea genuina. La encontré en el último párrafo del último reporte que describe la revisión 0.91 [2]. Allí estaba, con toda franqueza, explicando todo lo que había malinterpretado en mi joven inocencia. ¿Cómo podría criticar el método por no ayudar a los desarrolladores de software o gerentes, cuando no se ocupa en absoluto del desarrollo de software, sino sólo de desarrollar un mercado para consultores y capacitadores? Todo comenzó a tener sentido: la complejidad y rareza de la notación, lo que tontamente tomé como una deficiencia, son de hecho unas de sus cualidades más atractivas, dado que crean infinitas oportunidades de negocios, para Rational y quizás también para otros; así como también su tibia adopción de las ideas de la orientación a objetos, lo que significa que un consultor no tiene que conocer ni apreciar la tecnología de objetos para sacar provecho de UML.

Mi larga búsqueda no ha sido en vano. Me ha llevado a una total comprensión de UML, su admirable máquina auto-alimentada, dedicada de la A a la Z a la creación de un nuevo mercado, libre de todas las dificultades asociadas al desagradable negocio del desarrollo de software: ¡Libros de UML! ¡Cursos de UML! ¡Cursos sobre los libros! ¡Libros sobre los cursos! ¡Revisiones! ¡Journals de UML! ¡Conferencias! ¡Workshops! ¡Tutoriales! ¡Estándares! ¡Comités! ¡Remeras! Mientras más se piensa en las posibilidades, más deslumbrante aparece. Y para cualquier lector valiente o lo suficientemente aburrido como para leer la documentación hasta el final, el esquema global está allí, presentado en el párrafo final.

Todo empezaba a encajar. Con el aire de inevitabilidad que revela una auténtica obra maestra, en toda la gloria del estilo inimitable del documento, las últimas seis líneas repentinamente dieron sentido a los centenares de páginas anteriores:

Hay varios cursos públicos, y tenemos conocimiento de que están siendo escritos varios otros libros, que se ocupan de distintos aspectos de UML, todos basados en nuestras publicaciones preliminares previas. Esperamos una amplia difusión de herramientas de soporte, cursos de capacitación y uso de consultores en el futuro. Alentamos fuertemente este tipo de soporte [¡Bien por ustedes al alentar el soporte de sus propios productos! ¡Qué desinteresado!] y trabajaremos conjuntamente con autores, capacitadores y consultores para asegurar que sus consultas sean atendidas, de manera de lograr una difusión y soporte consistentes para UML.

A la espera de una respuesta favorable a mi pedido,

Respetuosamente suyo,

Cándido Smith

Referencias

[1] Rational Software Corporation: 0.8 version of the Unified Method: Notation Summary, en http://www.rational.com.

[2] Rational Software Corporation: 0.91 Addendum to the Unified Modeling Language, en http://www.rational.com.

[3] Kim Waldén and Jean-Marc Nerson: Seamless Object-Oriented Software Architecture: Analysis and Design of Reliable Systems, Prentice Hall, 1995.

Mi conclusión

Más allá de la excelente ironía de Meyer, a modo de resumen me gustaría destacar los siguientes puntos sobre UML:

  • Es por demás complejo.
  • No es orientado a objetos.
  • Carece totalmente de una semántica formal.
  • Dificulta extremadamente la reversibilidad.

Para finalizar, una famosa frase de C.A.R. Hoare:

. . . Hay dos maneras de construir un diseño de software: una es hacerlo tan
simple que obviamente no tenga deficiencias, y la otra es hacerlo tan complicado
que no tenga deficiencias obvias.

Dejar un comentario

110 comentario(s).

  1. Buenas barrapuntero.

    Interesantísimo el artículo, y muchas gracias por la traducción. Iba a leerme el enlace en inglés que has puesto, pero al leer una línea más abajo, y ver que tenías la traducción me has dado un alegrón :D

    De UML opino absolutamente lo mismo, pero no lo podría haber expresado ni la mitad de bien.

    PD: tengo tu blog en los rss desde el artículo que anunciaste en /. de programación de redes y concurrencia, porque me parece interesantísimo.

    saludos

  2. Excelente!!! observo con este artículo que no solo yo pienso de esa forma acerca del UML, que alivio :)

  3. Guau! Nunca nadie habia resumido mis sentimientos de esa manera.

    Bravo!

  4. Che, es medio contradictorio que Google AdSense te publicite UML en el blog, justo en tu articulo contra UML.
    Que paradoja..¿Como ganar plata criticando UML? jejeje.
    Buenisimo el post.

  5. ¡Con razón me parecía tan ambigüo en mi curso de UML! :)

  6. Alguien me puede decir cuál sería la mejor alternativa al uso del UML? o simplemente el UML es el menos peor hasta el momento?

  7. A mi no me parece tan terrible el estado en que se encuientra hoy dia la especificacion. Hay que tener en cuenta que cuando Mayer escribio eso eran los primeros pasos de UML ( y ademas para Mayer tenia mucho para perder con la salida de UML), hoy es mucho mas consistente que en aquel entonces.

    Con respecto al planteo que haces sobre los caso de uso y el ooa/d creo que cometes un error, el pensar que los casos de uso tienden a imitar lo hecho y por ende limitar la creatividad tiene mas que ver con un mal uso de un artefacto de analisis y no habla del artefacto en si mismo.
    Un sistema debe ser planteado desde distintas vistas y una de ellas es la vista del usuario (representada por casos de uso o por lo que a vos se te ocurra), eso no debe afectar la forma en que modeles tu sistema. Les recomiendo leer algo de Alistair Cockburn, el tiene una vision muy interesante sobre el uso de casos de uso para dirigir la construccion de un sistema.

    De todas maneras me parece interesante poder cuestionr las cosas y me encantaria si te diera el tiempo en algun momento escribieras algun caso especifico donde hayas encontrado que el modelado con UML hace agua.

  8. Demian:

    Si bien debo reconocer que no he seguido el estado de UML, no creo que hayan simplificado de forma sensible la notación, ni salvado los inconvenientes centrales de la misma.

    Con respecto a los casos de uso, la afirmación de que no son orientados a objetos proviene del hecho de que se pone énfasis en la secuencialidad. Y estoy de acuerdo en que podrían no utilizarse como la base del análisis, pero el Proceso Unificaco es propone un análisis totalmente “centrado en casos de uso” (como lo repiten una y otra vez en la bibliografía “oficial”). Dicho de otra forma, un análisis centrado en la secuencialidad de las acciones no es orientado a objetos.

    Agradezco tu comentario y tu respeto por el disenso. Saludos!

  9. Ah, que lindo ver esto!! A mí también me reprobaron de un curso por criticar UML. De hecho, me echaron del curso y hasta el decano me hizo un llamado de atención personal por decir que era “una basura”. Poco sutil lo mío, lo sé, y contraproducente habida cuenta de que todavía no terminé la carrera por eso :(.

    Tendrían que enseñar UML en el primer año de la carrera. No me hubieran robado cinco años de mi vida.

    Un saludo y gracias por la traducción.

  10. La verdad que concuerdo mas con algunos comentarios vertidos por Damian…a mi me parece que UML es monstruoso, pero nadie, absolutamente nadie te obliga a usar todos los diagramas y notaciones, etc que propone.

    Y por ende en vez de preocuparnos po lo malo que puede ser UML debemos preocuparnos por ser pragmaticos para usarlo. Con esto quiero decir que si bien cada enemigo tiene su arma, en UML despues de 20 años de sistemas he encontrado una forma de representacion de sistemas por demas completa, eso es cierto, pero cada vez que necesite algo para describir y representar un sistema lo encontre.

    Por otro lado es cierto que que hay otras metodologías que pueden ser mejores en algunos aspectos y en otros no, las muy cerradas optan por la falta de flexibilidad cuando dejamos de hablar de objetos o acaso pensamos que toda una solucion para una empresa es objetos? si muchas veces ni siquiera programamos una solucion sino que la integramos o la utilizamos para construir un Portal, un sistema o un tablero de comandos, veamos si el resto de las metodologías son eficientes para contemplar otras tecnologías o el uso de herramientas….ahi encontraras lo util de los Use Cases…

    Sobre esto ultimo no comparto que los Use Cases sean secuenciales, pero será para debatir en profundidad, de hecho no vi nunca un Use Case que sea parecido solamente un workflow, sino mas bien un diagrama de posibilidad de interaccion que muy bien representa la realidad, mas que el hecho mismo de construir un artefacto de software.

    Por ultimo comparar metodologías es cuasi imposible es como tratar de tapar la superficie de un cuadrado con un circulo (obvio que depende del diametro del circulo).

    Igualmente la opinion de todos las respeto, pero me parece que Mayer de objetivo tiene NADA, o el no lucra con esto?

    Saludos.

  11. ¿UML tiene defifiencias? Dios si ¿Significa eso que no vale para nada? Pues va a ser que no. UML es una herramienta muy util de comunicación. Uno puede pasarse horas explicando como ve el sistema a un compañero o subordinado hasta que este entiende lo que le quieres decir. O puedes hacerte un diagrama UML en un rato y hacerte entender.

    Por cierto que una cosa es el lenguaje de modelado y otra muy distinta la metodologia que se use. Hasta ahora nunca he usado la metodologia de los “tres amigos” pero si he usado, y bastante, UML.

  12. Soy implementador de sistemas ERP en argentina, trabajo con sistemas bastante completos/complejos, el año pasado estuve en un proyecto de migracion de un erp completo de VB6 sobre sql server a C# sobre cualquier rdbms todo documentado con UML, onda hacer la piramide de Keops para dimensionarlo.
    (ANtes que nada aclaro que soy funcional puro, de programacion nada (nada en serio bah, solo de oido)).
    A los 6 meses del proyecto aun estabamos con el tema del diccionario en un .doc, BD en el visio de MS para tener la estructura de la BD siempre documentada, los casos de uso funcionales en .doc y los diagramas de interacccion de los CU en el EAP (Enterprise aplication no se que).
    Obviamente cuando se habian gastado los primeros U$S120K se pudrio todo y se metio el proyecto al freezer (creo que no terminamos el alta de clientes siquiera).
    EL comentario es que me asuste del uml, pero ahoraen todos los proyectos lo piden, pero…………CADA UNO USA EL UML COMO QUIERE, esto es increible, en dos entrevistas con los lideres de los potenciales proyectos me dieron ideas totalmente distintas del uso del uml….de hecho quisiera hacer un curso de uml y no sabria ni donde hacerlo.

    Saludos a todos/as

  13. El diseñar en UML te sirve por lo menos para que el cliente vea lo que estás haciendo. Así viendo esos diagramas va a ver que trabajaste. Además se ve más profesional y por lo tanto puedes cobrar más :).

  14. De acuerdo a este ultimo comentario, creo que hay que hacer varias cosas, lo primero es que coincido con la primer afirmación.

    Lo segundo es un tipico error de un profesional de sistemas (o no) de creer que cuando uno trabaja en el desarrollo de un sistema, aplicación o lo que fuere, solo importa la parte técnica.

    En mi experiencia la componente técnica en un proyecto de desarrollo es a lo sumo el 30% del total de la torta, de ahi lo importante de usar una metodologías para las distintas areas de un proyecto donde UML es solo una mas.

    No creo, insisto, que UML sea la panacea, pero si creo en una frase que escuche hace muchos años, una mala metodología es mejor que ninguna y aca comzamos discutir otro aspecto, sera que actualmente nadie quiere usar metodología?

  15. Estoy muy feliz de leer esto, porque ahora se que no soy el unico que piensa asi.

    Lo que opino de UML es que, como dijeron mas arriba, “el producto final se ve mas profesional si se usa UML”. (O acaso no es mas lindo que cuando te compras un par de zapatos o lo que sea, te lo den en una linda bolsita de colores? :P )

    Lo triste es que para vender hay que usar bolsita :(

  16. Blog de Javier Smaldone » No tener ni idea - pingback on 10 de diciembre de 2006 @22:20
  17. No estoy de acuerdo con que para que un producto sea profesional hay que usar UML. Para ser que un producto sea profesional tiene que ser de calidad y para hacer un producto de calidad no basta con usar solo una buena envoltura.

    La documentacion es solo una herramienta para los que desarrollan sistemas, como herramienta tiene que ser util para los que estan desarrollando. Si el UML no es una herramienta util, no lo debes usar, tenes que usar una con la que el equipo de desarrollo sea realmente productivo y logre la calidad del producto.

    El libro del Proceso Unificado dice que el proceso unificado es solo una forma de trabajo generica y que se puede amoldar.

    Una cosa mas que se hayan gastado gran parte del presupuesto en documentar y no hayan avanzado nada en el proyecto no es probleam de la herramienta es problema del que lideraba el proyecto.

  18. Perdon por los horrores de ortografia, de semantica y de casi todo, los postie a las 4.30 de la mañana.

  19. Fernando el mendocino

    Me llamó la atención la supina ignorancia que se observa en este artículo y por esa razón decidí usar parte de mi tiempo en responder.

    Los errores que detecto en general son:

    1) Se critican los efectos del mal uso del UML y se castiga al UML. Seguramente muchos apoyarían a quien critique a los políticos, pero eso no quiere decir que la política sea una disciplina mala.
    2) Se critica al UML sin considerar que es una herramienta. Es como si se criticara a una pala: la pala es buena o mala según muchas consideraciones (contexto, momento, posibilidades, finalidad, etc.)
    3) Se confunde en muchos momentos un lenguaje (UML) con un proceso de desarrollo de software; se están mezclando peras con manzanas

    Voy a entrar en detalle. El autor, Javier Smaldone, comienza su exposición cometiendo errores a granel.
    - El proceso unificado no es una metodología sino un proceso marco para el desarrollo de software; si no se puede distinguir eso, seguro se errará en su análisis
    - El UML no está asociado al proceso unificado, dado que el UML es independiente de los procesos de desarrollo de software. A lo sumo, y siendo generoso, el proceso unificado está asociado al UML
    - Plantea que el UML es poco expresivo. Yo puedo expresar lo que se me dé la gana con UML. Es más, hace un par de años biólogos franceses describieron el genoma humano con UML; ¡usaron UML para la biología y Smaldone dice que no expresivo!
    - Dice que con el tiempo aprendió otras metodologías de diseño de sistemas y con eso se dio cuenta de que el UML no sirve: primero, me gustaría saber qué metodologías aprendió (seguro que nuevamente está opinando sin saber qué es una metodología); segundo, no basta con aprender diseño de sistemas para demostrar que UML sirve o no y tercero, si bien acepto que pueda haber adquirido experiencia en proyectos, dudo que sea la experiencia real necesaria para opinar sobre UML y decidir tan categóricamente si sirve o no.
    - Plantea ignorantemente que es una pésima idea documentar el proceso de desarrollo de software con UML pero en realidad no sé en qué momento habrá documentado el proceso. Si bien UML es un lenguaje y permite expresar lo que uno quiera con él, normalmente no se documenta un proceso con UML.
    - Plantea ignorantemente que es una pésima idea usar el proceso unificado para conducir un proceso de desarrollo. Es como decir que es pésimo usar una pala. Mi respuesta es: si querés peinarte, la pala es una pésima herramienta; si querés hacer un pozo, el peine es una pésima herramienta. La naturaleza de los procesos (iterativo e incremental, en cascada, por prototipos, etc.) depende de la naturaleza del proyecto en particular; ninguno es pésimo o excelente. Primero denme el problema y después diré si la herramienta es buena o no.
    - Plantea temerariamente que la mayoría de los que se dedican a la orientación a objetos usan UML por la campaña publicitaria montada. ¿No será que la mayoría que se dedica a la orientación a objetos lo usa porque le sirve? ¿Y no será que, si lo usa la mayoría el equivocado puede ser Javier Smaldone?
    - Plantea absurdamente que, a partir de una cita con errores, el negocio fue hacer UML a partir de entre 20 y 50 notaciones. Primero, no eran entre 20 y 50 sino más de 60. Segundo no eran notaciones, sino métodos; de hecho a esa época se la llamó la de “la guerra de los métodos”. Cuarto, dice que el encuentro decisivo se hizo en 1995 en Silicon Valley, cuando en realidad la idea del UML (en su origen el Unified Method) ya existía en OOPSLA ’94. Quinto, de la lectura del párrafo citado no se sigue la inutilidad del UML sino todo lo contrario.
    - Plantea absurdamente que el UML no surge de una investigación. ¡Cómo puede saber que nadie investigó o si lo hizo fue sin la profundidad suficiente! ¿Conoce Javier la agenda de Booch o a sus colaboradores?
    - El UML no nació para unificar notaciones diferentes, sino métodos. La prueba es que la primera versión del UML fue la 0.8 y se llamó Unified Method. ¿Entendiste de una vez, Javier, que “Method” no significa notación? Pero es claro que para vos método, notación, proceso, metodología no son términos demasiado claros, lo que hace que no estés a la altura de opinar al respecto y es la prueba de tu ignorancia para emitir los juicios temerarios que está emitiendo.
    - Por otra parte, el negocio estaba antes del UML. Había más de 60 métodos (¿entendiste Javier?; dije “métodos”) justamente porque todos querían vender sus libros, sus consultorías, ganar prestigio, etc. haciendo lo mismo que los demás, pero necesitaban diferenciarse en algo y por eso proponían métodos distintos. Justamente Booch llamó a sincerarse, a que todos se unan para en vez de proponer lo mismo de distinto modo, propongan lo mismo del mismo modo.
    - Booch, Rumbaugh y Jacobson no se asociaron para crear Rational. Booch estaba en Racional y Rumbaugh fue a trabajar allí desde General Electric. Jacobson se unió más o menos un año después (cuando de la versión 0.8 de Unified Method se pasó a la versión 0.9 del UML).
    - Otra prueba de ignorancia absoluta es decir que se unieron apresuradamente y decir que salen cosas malas de los apuros, como el UML y el proceso unificado. El UML en realidad se aceptó como estándar en noviembre de 1997, después de tres años de trabajo y basado, además, en trabajos ya existentes ¿o acaso los diagramas de clases, de secuencias, de estados se inventaron en ese momento?
    - Por otra parte el proceso unificado no surgió de allí tampoco. Proviene de muchos años de uso exitoso por parte de Jacobson en la empresa Ericsson, Suecia, bajo el nombre de Objectory. A tal punto es así, que el proceso unificado inicialmente se llamaba Objectory. Después su nombre mutó a “Rational Objectory Process” y por último “Rational Unified Process”. ¡Es increíble la ignorancia de Javier, pero peor que la use haciendo gala de opinólogo!
    - Por último voy a las conclusiones de Javier, que así como Meyer llamó Cándido a su personaje, a Javier lo llamaría Ignorancio Smaldone.
    - En las conclusiones dice que el UML es por demás complejo. No estoy de acuerdo, a no ser que el grado de complejidad que Javier sea capaz de soportar tenga niveles más bajos que el común de la gente con la que trabajo y no ve las cosas de ese modo.
    - Javier dice que el UML no es orientado a objetos. ¡Fantástico, yo también lo afirmo! ¡Y los autores del UML lograron su objetivo! El UML no es orientado a objetos justamente porque entre sus objetivos es que sea un lenguaje amplio, que sea independiente de los lenguajes de programación, de los paradigmas y de los procesos de desarrollo. Ahora, en cuanto es un lenguaje, con él se pueden describir realidades orientadas a objetos, no orientadas a objetos u orientadas a lo que se nos dé la gana, recordemos a los biólogos franceses describiendo genoma humano que es…. ¡orientado a la biología!
    - Dice temerariamente que el UML carece de una semántica formal. Decir eso es un absurdo, porque tiene una semántica formal. A lo sumo no tiene el grado de formalidad pretendido por Javier, pero me gustaría que le avise a los biólogos franceses, porque ellos eligieron al UML justamente por su formalidad. Y hasta el momento, la mayor parte de la comunidad informática opina lo contrario de Ignorancio Smaldone.
    - Plantea que dificulta la reversibilidad. Primero, me gustaría saber qué es lo que Javier opina que debe ser reversible. ¡De hecho acabo de probar y pude escribir LMU en lugar de UML! ;-)

    Saludos a todos. En otro momento la sigo con Meyer.

  20. Evidentemente este planteo hecho por Fernando el mendocino reviste cierta parcialidad, ya que denota nunca haber utilizado esta herramienta para el desarrollo de software.
    Claro está que para muchos la implementación de esta herramienta es más un negocio en vez de una verdadera necesidad.
    Comparto el comentario de DementialDuck del 30 de Noviembre de 2006:
    “El diseñar en UML te sirve por lo menos para que el cliente vea lo que estás haciendo. Así viendo esos diagramas va a ver que trabajaste. Además se ve más profesional y por lo tanto puedes cobrar más :).”
    saludos

  21. Fernando el mendocino

    Ahora voy a la carga por Meyer. Y por supuesto, Ignorancio Smaldone también va a ligar de vez en cuando algún garrotazo, por cómplice ;-)

    - Simplemente para empezar, y para que se vea el grado de honestidad del autor, Bertrand Meyer fue parte de la creación del UML. De hecho, en los libros de la trilogía del UML se lo puede encontrar en la parte de agradecimientos. Por supuesto, quizás se quedó fuera del negocio y por eso empezó a criticarlo.
    - Allí mismo, en esos agradecimientos aparece uno al Object Technology User’s Group, del que fui parte y en el que recibí numerosos mensajes, entre ellos del mismo Meyer haciendo aportes al UML.
    - Pero la deshonestidad de Meyer y la ignorancia de Smaldone hicieron un cóctel explosivo que dio origen a esta discusión.
    - Es muy gracioso que Ignorancio Smaldone hable del negocio que hay detrás del UML y después pegue una cita en donde se promocionan explícitamente productos tales como EiffelBench y EiffelCase ¡A no ser que los dueños de estos productos donen el 100% de las ganancias a UNICEF!
    - Por otra parte, el negocio del UML no parece ser tan negocio desde el momento en que se entregó el UML al Object Management Group, su actual dueño. Pero a pesar de que el UML fue entregado al OMG y no así el BON o EiffelBench y EiffelCase, Ignorancio Smaldone ve sólo el problema del lado que él quiere verlo.
    - A todo esto, ahora que me acuerdo, Ignorancio Smaldone escribió “método BON” cuando justamente la “N” de BON significa “Notation”. ¡Ignorancio, seguís confundiendo notación con método!
    - Siguiendo con Meyer, y en cuanto a que BON es compacto, sirve para describir sistemas orientados a objetos y permite alcanzar proyectos de envergadura. Él mismo es deshonesto al saber que el UML posee un núcleo que permite lo mismo y que el mismo Booch menciona (cuando habla del 20% de UML que es necesario para modelar casi todo). Sin dudas Meyer se apropió de esa idea –y característica actual y real del UML- y ahora la usa para sus propósitos.
    - Con malicia, Meyer dice que hay que “aprender toda esa complejidad monstruosa para construir diagramas de un posible sistema futuro” cuando sabe que no es cierto. Hemos construido muchos sistemas y de diversos tamaños con una notación que sólo necesitó como mucho una semana de entrenamiento no sólo en notación sino incluso partiendo de conceptos básicos.
    - También Meyer dice que “al menos un lenguaje de programación, incluso el peor de ellos, es ejecutable”. ¿Y quién quiere ejecutar algo con UML? Está bueno para divertirse con la historia de Cándido Smith, pero no para criticar al UML
    - Si alguien se asombró con el argumento de la “reversibilidad” de BON en contraposición a su carencia en el UML hay que destacar dos cosas: 1) el UML no tiene por qué ser reversible; es un lenguaje. Es como decir que la lengua española no viene con corrector ortográfico para hablar!!! Una cosa es el UML y otra la herramienta del mismo modo que lo es el español y el procesador de textos con el que estoy escribiendo esto; 2) salvada la falacia anterior, existen numerosas herramientas que permiten esa reversibilidad solicitada por Meyer. Entren a http://www.sparxsystems.com.ar y descarguen y prueben una herramienta que lo permite.
    - Meyer reclama que el UML no es orientado a objetos cuando no lo es ni quiere serlo. Ya dije que en mi otro comentario que el UML nació para ser independiente de los lenguajes de programación, paradigmas y procesos de desarrollo. Y eso Meyer lo sabe bien.
    - Lo que me llama la atención es la estupidez de Meyer. Veámoslo de este modo: ¿podría decir que el español no sirve porque alguien dijo un insulto? O lo que es lo mismo ¿podemos decir que el UML no es orientado a objetos porque alguien dibujó un diagrama no orientado a objetos con él, como lo expresa Meyer?
    - Ahora Meyer presenta una enorme ignorancia, de la que se debe haber contagiado Smaldone, al decir que los casos de uso son semejantes al análisis top-down, cuando en realidad, al enseñar casos de uso lo primero que hacemos repetir a los asistentes es “no se equivoquen, un enfoque de casos de uso es diametralmente opuesto a la descomposición funcional”. Me parece que a Meyer le hace falta aprender el ABC y está haciendo lo mismo que Smaldone: hablar sin saber.
    - Otra cuestión que Meyer ignora (¡¡¡y debería saber, si fue parte en la creación del UML!!!) es que es más que claro que los casos de uso son orientados a procesos y no a objetos y que la arquitectura del software no se desprende de ellos. Ellos simplemente (y no es poco!) soportan los requisitos funcionales del sistema y la arquitectura orientada a objetos del software surge en modelos bastante posteriores. Todo esto suponiendo que queremos desarrollar software orientado a objetos, porque en caso de querer hacerlo con otros lenguajes, el UML lo permitiría.
    - Meyer llega a la locura de decir que el UML no le sirve a nadie. Supongamos que pudiera aceptar esta locura ¿cómo hago ahora para convencer a toda la gente a la que el UML le sirvió diciéndole “tenés que pensar que no te sirvió? ¿la hipnotizo para que repita eso?
    - Por otra parte, con su ejemplo de la explosión del Ariane 5, Meyer confunde álgebra con estadística. Perdón, me equivoqué de disciplinas, quise decir dirección de proyectos de software y modelado de software. Pero da lo mismo, total, si para Meyer estas dos disciplinas son iguales también para mí lo pueden ser el álgebra y la estadística.
    - Pregunta Meyer ¿cómo ayuda el UML a que el software sea robusto? El software será robusto intrínsecamente por las disciplinas de captura de requisitos y de programación, por ejemplo, y no por el UML. Este lenguaje simplemente les da soporte.
    - También afirma Meyer categóricamente que “nada” del UML ayuda a la reutilización. Justamente la reutilización es una de mis especialidades (además de preparar buenas caipirinhas), por lo que no tengo problemas en compartir con Meyer lo que me ayudó el UML en esta disciplina. Agrego además que la reutilización depende más del proceso de reutilización en sí que del lenguaje; incluso reutilizamos muchas cosas que tenemos “soportadas” en lenguaje natural a pesar de que el castellano no se “creó” pensando en la reutilización.
    - No voy a tomarme el trabajo de comentar el final del artículo de Meyer que, si bien es divertido, apunta a indicar que todo es un negocio luego de promover en este mismo artículo su nombre, el de otros autores, el de otra notación, el de herramientas CASE, etc. después de haber sido parte de la creación del UML.

    Termino con un trabalenguas: lamento que Meyer no sepa distinguir entre proceso de desarrollo y lenguaje de modelado; más lamento que no quiera distinguirlo; y mucho más el saber que lo distingue, pero cuando escribió este artículo no le convenía mostrar que lo distingue.

  22. Fernando el mendocino

    Perdón, me olvidé de algo. Si fuera como Meyer, en lugar de mi seudónimo “Fernando el mendocino” hubiera usado mi verdadero nombre así me contratan consultoría!!!

  23. A pesar de las agresiones personales, dejaré intactos los comentarios del señor Fernando Pinciroli (“el mendocino”), como un ejemplo muy claro de la comisión de varias falacias lógicas.

    Y no, no voy a hacer ningún comentario adicional ;)

  24. Fernando el mendocino

    ¡Cómo no se me ocurrió antes!!!
    La verdad que, en lugar de haber respondido con cuidado y con precisión a cada error grosero, a cada opinión basada en la ignorancia, a cada mezcla de conceptos, etc., podría haber escrito:

    “Los comentarios de Smaldone responden a varias falacias lógicas”… ¡y seguro hubiera quedado como un genio!!!

    Fernando Pablo Incirillo, Mendoza

  25. Finalmente, el razonamiento falaz es decorado con una mentira. :)

  26. Che, todo de muy lindo, pero vamo a toma una cervecita? y si quieren que vengan UML, MEYER, el Mendocino, total, con sacarse los ojos no van a ganar una mierda chichoneandose y mostrando cuanto saben… si al final es evidente que ninguno de los dos va a cambiar de opinion y a uml le chupa un huevo jajajjajaja

  27. Analizando solamente los argumentos lógicamente válidos del señor Fernando Pinciroli (“el mendocino” o “Fernando Pablo Incirillo”), se me ocurrió publicar la traducción de un artículo de Dijkstra en donde responde a preguntas de alumnos de Ingeniería de Software.

    En el mismo, pueden encontrarse varias explicaciones a la postura y visión de algunos “Ingenieros de Software”, como así también de la pobre calidad que, en general, poseen los sistemas que diseñan y construyen.

    Si bien Dijsktra no hace referencia explicitamente a UML, cualquiera que conozca su visión de la programación entenderá que cae dentro de su categoría de “formalismos indeseables”.

  28. “Siguiendo con Meyer, y en cuanto a que BON es compacto, sirve para describir sistemas orientados a objetos y permite alcanzar proyectos de envergadura. Él mismo es deshonesto al saber que el UML posee un núcleo que permite lo mismo y que el mismo Booch menciona (cuando habla del 20% de UML que es necesario para modelar casi todo). Sin dudas Meyer se apropió de esa idea –y característica actual y real del UML- y ahora la usa para sus propósitos.”

    No se porque me sorprendió el encontrar esto en medio de tantas palabras vituperosas. Dice todo. Fernando prefiere escribir mas que pensar. Si fuera el reves hubiera tratado de escribir en menos palabras, con palabras mejor organizados, y con espacio entre tus parafos.

    Por supuesto que alquien que escribe sin pensar, sin demostrar pensamiento claro, tamnbién prefiere herramientas que incluye 80% basura inutil. Me recuerda de los parafos de Fernando. :)

    Lo mas innecesario es insultar el dueño de la casa en su propio salon. Evitable, triste, y otra demostación de pensamiento nublado.

    Los que leen este sitio y blog son los que por lo general piensan que Javier es intelligente y tiene algo interesante que decir. Para mi es un poco dificil leer todo este sitio puesto que solamente estoy apprendiendo el Castellaño, pero todavía vale la pena.

    Lo que has hecho es como vestirse con una camisa de River y insultar a Maradona en el medio del Jugador Number 12 en la cancha de Boca.

    Chau Fernando. Que disfrutes de tu UML. Lo han creado particularmente para los que prefieren fingir hacer cosas en vez de hacarlos, para los que prefieren decir mil palabras cuando 10 sirven, y para los que necesitan insultar en vez de pensar.

  29. Es cierto Curtis, que es mas fácil insultar que pensar, y como no tengo ganas de pensar me gustaría decirle a…Pinchiroli? (de paso Curtis, te doy un ejercicio para el castellano, Pinchi-roli, una buena idea para que investigues el castellano-cordobés y descubras de que se trata), como decía, Pinchiroli, el medocino, mmmh…buen seudónimo para un asesino múltiple (quién diría, al contrario que Hans Reiserf). En definitiva, no tengo nada que decir, solamente que el tipo de agresión a un amigo como Javier, me saca de las casillas, además de haber sido innecesario. Bueno Pinchiroli, feliz año nuevo! y que los reyes magos hagan de UML una “herramienta” para el proceso de desarrollo de software.

  30. La verdad que estos mensajes dan para analizar bastante y me parece que se estan discutiendo dos cosas diferentes (ademas de poder analizar como se pelean los argentinos!!!).

    Por un lado las agresiones del mendocino que si bien no comparto la forma en la que escribio tampoco me parecen tan insultantes, sino mas bien siguio con la ironia de Bertrand Meyer del alumno Candido llamando Ignorancio a Smaldone. Hasta me parecen un poco mas insultantes los mensajes de Curtis y de Seba, pero entiendo que son reacciones.

    Por el lado del UML no encontre sustento en lo de Smaldone, porque como se lee en otros mensajes no parece distinguir lo que significa una herramienta, como aclaran Malvenido y el mendocino.

    Otro aporte importante del mendocino es que parece tener fundamentos que nadie hasta ahora mostro, porque muchas de las citas que menciona Smaldone no necesariamente apoyan su hipotesis sino que hasta pueden ser a favor de la postura de los que defienden UML.

    Por favor, mandenme la direccion de correo del mendocino (que debe haberla colocado como yo hice con la mia) porque me gustaria seguir profundizando el tema.

    Y de paso dejo un saludo para Colo Colo, que estuvo a punto de ganar su segundo titulo internacional pero que no lo hizo por poco.

Deja un comentario

Trackbacks y pingbacks: