Saludos

Aprecio el tiempo que te tomas por «intentar» poner algo de calidad en tu blog. A pesar de ser antigua, mis alumnos me preguntaron respecto a esta entrada. Hago algunas observaciones (solo observaciones, no son críticas) directas sobre tu escrito:

Observación 1.
Dices en el segundo párrafo: […fui afianzando mi opinión sobre UML: es totalmente inútil y contraproducente.]
Dices en el tercer párrafo: [… 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…]

El uso en el segundo párrafo de «totalmente» es inconsistente con el uso de «algunos» en el tercer párrafo. O sirve un poquito o no sirve nada. Pero entiendo que esa incongruencia puede estar dada porque:
1) Aceptas muy a tu pesar que algo en UML puede ser útil.
2) Tu tendencia al pensamiento polarizado (todo o nada) o a generalizar de manera excesiva, te hace ser categórico ciertas aseveraciones. El pensamiento polarizado y la generalización excesiva son, de acuerdo a David Burns, distorsiones cognitivas.

Observación 2.
El hecho de que alguien produzca algo, que decida hacer de él un negocio y que dicho producto no resulte del agrado, comprensión, utilidad, etc., del total de la gente, no significa que sea malo. Esto refiriéndome al párrafo 6 en el que dices que [Nada demasiado bueno puede surgir de la unión apresurada de un montón de cosas incompletas guiada por objetivos comerciales]. Vuelves a la misma distorsión cognitiva de polarización de pensamiento y percibo (solamente es mi percepción y puedes estar en desacuerdo con ella) que te enfurece que alguien haya obtenido beneficio de algo que a ti no te gusta (esto podría ser otra distorsión cognitiva: Razonamiento emocional). Me parece que no hay fundamento en que algo que alguien hace y lo propone con fines comerciales sea totalmente malo. De ser así, tu blog podría caer en esa categoría.

Observación 3.
De todo el material brillante que pudiste emplear para justificar tus conclusiones, utilizaste un escrito […en un tono para nada respetuoso…] (párrafo 8) y que igualmente muestra signos de «razonamiento emocional» de quien ataca un producto que no es suyo y, para atacarlo, esgrime un producto que sí es suyo (UML vs Eiffel). Y percibo (nuevamente, no puedo asegurar qué pensaba el autor) que tiene igualmente furia por no posicionar comercialmente su producto.

Observación 4.
En tus conclusiones, citas a Hoare coincidiendo nuevamente con el tipo de distorsión cognitiva: solamente distingues dos modos muy alejados uno de otro de hacer las cosas. Muy polarizado el asunto.

Como puedes constatar, las observaciones van más enfocadas a tu estilo de pensamiento que a las cuestiones técnicas. Partiendo de la forma en la que estructuras tu escrito, puedo decir que le restas objetividad y, por tanto, algo de credibilidad por el pensamiento distorsionado que exhibes. El autor que cité es bueno en temas de cognición. Podría ayudarte a mejorar tus contenidos. Y es que, el hecho de moverse en el ámbito tecnico no justifica que desechemos herramientas de otras áreas para ser mejores pensadores.

En términos técnicos, coincido con muchos: UML es una herramienta. Ni la mejor, ni la peor. Así de simple, solo una herramienta. Si te sirve, úsala; si no, no lo hagas. Y más todavía, las herramientas son para ser usadas a conveniencia de los humanos, así que si no sientes que sea de utilidad en tus manos, suéltala.

P.D. Te anticipo que pasé por aquí por causa de mis alumnos y no pienso volver porque no me agradó ni tu estilo ni tu contenido. No digo que esté incorrecto o que sea malo. Simplemente a mí no me gustó… A lo mejor lo haces con toda intención para atraer cierto tipo de lectores que les gusta la bulla, replicando lo que criticas: [Nada demasiado bueno puede surgir… guiado por objetivos comerciales]. En fin, puedes contestar y puede que alguien lea lo que escribas. Pero yo no lo haré. Fue divertido comentar.

-Backer: (…) Piensan compartir su diagrama completo de UML?
-DF Oliver: Lo haríamos si de hecho usáramos UML para planear nuestra tecnología. En realidad rara vez esto ocurre, incluso cuando termino planeando un sistema en un UML-reducido, el diagrama tiende a estar desactualizado antes de terminar el día :-)

Original:
-Backer: (…) Do you intend to share your actual full UML?
-DF Oliver: We would release it if we would actually use UML to plan our tech. In reality this rarely happens though and even if I end up planning a system in UML-lite the diagram tends to be out of date before the day is over :-)

una respuesta muy fuera de cualquier «integridad»!

Si querías un análisis científico, te hubieras tomado la molestia adicional de leer el artículo citado «A Comparison of the Business Object Notation and the Unified Modeling Language», en vez de rezongar porque el de este post está escrito en un tono humorístico. Saludos.

Entre aquí y me tomé la molestia de leer el artículo porque pensé que iba a encontrar un análisis científico respecto al tema, pero a medida que leí no pude evitar darme cuenta que está completamente sesgado, además de parcializado ¿si estás criticando UML por qué promueves otras técnicas? Eso es marketing vulgar y desleal. Por otra parte, el tono sarcástico y exagerado del artículo solo muestra la poca objetividad del autor.
Respecto a la crítica principal que hace el autor sobre “la enorme complejidad de la notación del UML” me parece un argumento falaz y ridículo, que una técnica sea compleja no significa que sea incorrecta ¿Es incorrecto el cálculo de ecuaciones diferenciales solo porque es complejo? O más allá ¿Es incorrecta la mecánica cuántica porque es incomprensible para el 99.9999999% de la humanidad?
Creo que UML tiene como propósito acercar al modelado de software hacia técnicas formales, y principalmente su potencial está en el modelado de sistemas discretos orientados a objetos.
¿Es UML la panacea de la Ingeniería del Software? No, ni mucho menos pretende serlo, quienes así lo piensan es porque carecen de conocimientos serios en ciencias de la computación, son aquellos a los que les pasa como al que tiene un martillo y entonces todo lo ve como clavos. UML es útil, decir que nadie ha hecho nada con UML es absolutamente absurdo, es decirle en la cara a cientos, miles de expertos en software que son unos imbéciles y que el autor del artículo es el DIOS del Software (“alabado sea Dios Meyer”).
Por otra parte, lo que ocurre en la mayoría de los casos es que por el mal dominio de la técnica se cometen grandes errores, así como puede ser que simplemente el equipo completo este lleno de ineptos, en tal caso no hay técnica ni herramienta que valga.
Por último, considero que cada problema tiene una solución óptima, donde UML no es aplicable así como la orientación a objetos tampoco lo es, NO TODO ES UN OBJETO, hay sistemas cuyo diseño debe abordarse desde el punto de vista estructurado.
Saludos Cordiales.
PD: Es bueno ser objetivo y menos exagerado al hacer artículos de éste tipo, ya que muchos lectores por falta de experiencia o amplitud mental se creen todas las sandeces que dice el artículo y terminan repitiendo como loros lo que leen sin someter lo leído a un juicio crítico.

UML sirve para representar cosas en forma sistémica, es decir para «formalizar» en cierta manera una aproximación a la realidad.

En software el 90% del tiempo se emplea el diagrama de clases, que en definitiva es casi el único útil, con consumo de tiempo razonable y que empleado con herramientas adecuadas permite generar código, con lo cual parte del tiempo consumido se puede recuperar. El resto carece de expresividad a menos que te comas el 90% del tiempo del proyecto modelando diagramas de interacción, estados, secuencia y deployment… o sea, si haces un proyecto con un UML expresivo lo más probable es que te echen del trabajo. Y aún cuando tengas todos los diagramas hechos, no vas a poder llevar el hilo de lo que pasa porque para analizar un solo evento vas a tener que leer 4 o 5 diagramas distintos y lo más probable es que si lo querés imprimir mates un bosque de lo que consumas en resmas de papel.

El problema es la falta de alternativas y la poquísima investigación sobre mejores técnicas y ahí sí ataco la excesiva publicidad, elogios y fanfarria de UML. Porque con el marketing y la instauración de facto en universidades, son muy pocos los que tienen la motivación de cuestionar lo enseñado. La amplia mayoría terminan aceptando que «UML es lo mejor, es profesional, blablabla» y mataron la semilla de la curiosidad que un investigador informático debería tener. Lo presentan muy perfecto y es todo un comercio, lleno de cursos, certificaciones, certificadoras, títulos… y esta práctica se ha multiplicado en cosas inimaginables hace 10 años… por ejemplo ITIL ¿quien carajo puede certificar algo como «buenas prácticas»???? Cada vez más consultoras se dedican a currar (robar) con estas cosas y en cuanto a mejoras del software 0 avance.

Hoy día si buscamos que un tercero comprenda un diseño, es cierto que UML está popularizado. Sin embargo carece de muchísimas cosas, por eso me alegra haber leído que existe una alternativa mejoradora y voy a empezar a estudiar BON a ver qué hay de eso. De momento por ejemplos de diagrama veo que es simple y en los ejemplos observo que en dos diagramas hay una especificación completa de la funcionalidad. Eso en UML no existe, pero recién estoy leyendo esto de BON con el escaso tiempo que los proyectos dejan libre.

También quiero decirles a varios que me extraña que algunos comentarios hablan de «por la fecha de tu comentario seguro que no estabas al tanto de… o capacitado en…» Realmente si trabajan con objetos y no saben que el paradigma data de 1950/1960 o antes y que ya en el 67 había lenguajes de objetos y pretenden que la investigación de objetos de los últimos 3 o 5 años «son el salto maravilloso» entonces vuelvan a estudiar o revisen sus fuentes, porque alguien se está robando el crédito de cientos de científicos, matemáticos e ingenieros que realmente hicieron aportes útiles y todos datan de al menos 20 años atrás. Se programaba en «objetos» en Turbo Pascal lo mismo que se programa hoy en Java o .Net. Lo usa mucha gente, esa es la ventaja y prácticamente se muere en el diagrama de clases porque muchas herramientas te generan el código correspondiente, sin embargo no he visto herramientas que coordinen todos los diagramas en base al código o viceversa.

Aceptemos la realidad, la ingeniería del software está estancada y muerta desde hace años. Baste como ejemplo que en vez de evolucionar hacia técnicas de programación y diseño que permitan la verificación formal del software (como sucede en programación funcional) seguimos siendo micos que programan «tests» para validar lo hecho. Que a la fecha no seamos capaces dentro del paradigma de objetos de decir que una pieza de código hace lo que se dice que hace es deprimente.

Por eso voy a ver si BON cumple algo de esto. Por lo pronto veo que al menos cuenta con la especificación del método en el propio diseño, con lo cual cuenta con más herramientas que UML. ¿Alguien sabe si se llega a la verificación de programas por este método?

PD: Quiero citar criticar específicamente a las plataformas .Net y Java porque disfrazan de evolución a cosas que roban de lenguajes funcionales como Haskell anunciándolo como las fabulosas «nuevas características». Me refiero a las funciones anónimas, los generadores, las listas por comprensión y extensión, etc… que en realidad son hibridación de dos o tres aspectos funcionales sueltos, que ahorran unas líneas de código al programador pero sin un verdadero beneficio para la calidad del software.