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 Severo 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.
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
Excelente!!! observo con este artículo que no solo yo pienso de esa forma acerca del UML, que alivio :)
Guau! Nunca nadie habia resumido mis sentimientos de esa manera.
Bravo!
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.
¡Con razón me parecía tan ambigüo en mi curso de UML! :)
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?
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.
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!
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.
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.
¿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.
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
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 :).
una respuesta muy fuera de cualquier «integridad»!
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?
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 :(
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.
Perdon por los horrores de ortografia, de semantica y de casi todo, los postie a las 4.30 de la mañana.
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.
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
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.
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!!!
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 ;)
¡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
Finalmente, el razonamiento falaz es decorado con una mentira. :)
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
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».
«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.
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.
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.
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.
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.
La verdad que no entiendo porque siguen discutiendo, conozco empresas que desarrollan software de calidad y usan UML como herramienta. Al igual que hay empresas que utilizan otras herramientas y sus sistemas tambien tienen son de calidad.
No entiendo porque uno de los dos tiene que tener razon, si el UML no les sirve no deben usarlo.
Es como si me pusiera discutir que IDE es mejor eso es depende de quien lo use y para que.
No puedo creer que haya gente que piense que se puede cobrar mas por documentar.
Como si a la empresa que nos contrata le importara el proceso que utilizamos para entregar un sistema.
La gente que dice que se puede cobrar mucho por presentarle un diagrama de clases a un gerente es porque simplemente nunca hablo con un gerente.
En general a un gerente solo le interesan los beneficios del sistema, la fehca y el precio.
Las veces que se interesaron por el proceso fueron las veces que me contrato el gobierno o una empresa para tercerizar un trabajo.
De todas maneras es mediocre pensar que por un diagrama tu trabajo valga mas, la calidad de tu trabajo tiene que hablar por si sola.
Creo que todo lo podemos resumir en que cada persona utilice el método o herramienta que maneje mejor, y sea adecuada para el software que esté desarrollando.
Personalmente he usado UML, pero solo una parte del todo. Diagrama de Clases y algunas veces Diagramas de Casos de Uso. No he necesitado más. Y me ha servido para tener una visión general del problema que quiero resolver.
Como decían anteriormente si a alguien no le gusta trabajar con UML, simplemente no la use y busque otra forma de resolver sus problemas.
Además se pueden crear metodologías híbridas, sacando lo mejor de todas.
En realidad considero interesante, el artículo que escribió, pero sinceramente no entiendo muy bien, ahora en mis calses empezamos a ver lo que es UML, definicíon, características, ventajas y desventajas, software que maneja un UML, y desearía poder saber más hacerca del tema. Espero pueda ayudarme en eso, he leido varios artículos en otros sitios web, pero considero importante lo que menciona, no sabía que tenía tantas desventajas, recien acabo de entrar a los que es «fundamenteos de programación»
No sirve? y entonces por qué me he pasado en la universidad un año estudiando UML? Menudo batacazo.
Un saludo a todos.
Carlos
Creo que este articulo es una mierda, yo he usado UML para el analisis y el diseño de sistemas y me ha funcionado muy bien, en especial para capturar y documentar requerimientos con los casos de uso, el que no lo sepan usar no quiere decir que no sirva, por lo menos a mi y a una veintena de personas que conosco si nos ha servido. Bueno eso es solo mi humilde opinion.
La vdd no estoy nada deacuerdo con el articulo escrito, solo eso quiero comentar ya que mi enojo es tanto q prefiero omitir cualquier otro comentarios.
Ya q trato de respetar el punto de vista de cada persona.
Si usted no lo a utilizado en proyecto, mi pregunta es como puede ser posible q tenga el descaro de hacer un articulo con el simple hecho de preguntar ¬¬
Fernando Pinciroli
¿Que tipos de aportes Meyer trato de hacer a UML?
Desde siempre Meyer a estado a favor de un modelo simple[1]. Mas adelante un articulo sobre The Simple Model.
En algunas partes de tu articulo resaltas la ignorancia de B.Meyer sobre algunos temas. Eiffel su lenguaje es tal ves el mejor lenguaje que se haya diseñado hasta el momento con un enfoque a la ingenieria de software no tratrado en otros lenguajes, en si como Meyer dice Eiffel no es un lenguaje es mucho mas que eso, es un Metodo.
¿Deberia pensar de ahora en adelante en estar alerta a la ignorancia de B.Meyer sobre los temas que escribe?
Porque cierta gente le concederia a B.Meyer premios como el AITO prize (El nobel de la tecnologia a Objetos) http://www.aito.org
o el mas reciente galardon del ACM
Bertrand Meyer is Recipient of Software System Award for Impact on Software Quality
http://campus.acm.org/public/pressroom/press_releases/3_2007/eiffel.cfm
BON Method aca :)
http://www.bon-method.com/index_normal.htm
The Simple Model
Un lindo paper sobre Simple Model se puede ver aca
http://www.jot.fm/jot/issues/issue_2002_11/column6/index_html
Les dejo el Abstract:
«Modelling languages such
as UML are increasingly used to describe software systems at different levels of abstraction. There are two very different ways of using such languages. One approach is based on the manifestation of a single model, with construction of different views from this model, and with automatic or semi-automatic consistency checking among these views. This follows what we term the single model principle. The second approach (of which unrestricted UML is an example) is based on the independent construction of multiple models of the same system, but with no guarantee of the consistency of the various models. We propose that to best support seamless, reversible software development of reliable software, it is preferable to follow the single model principle for a specific subset of development tasks.
We describe the single model principle and its supporting infrastructure. We show how the BON/Eiffel description language, which supports both high-level abstract specifications as well as code implementations can be enhanced to satisfy the essential tenets of the single model principle, both for static and dynamic descriptions. We describe how a UML profile (including the use of Java) might provide weak support for the principle. We also consider situations and tasks when following the principle is insufficient, particularly when capturing early (goal-oriented) requirements. »
Dave Thomas : http://www.davethomas.net , ha escrito algunos articulos interesantes en JOT, y hay sobre UML :)
UML – Unified or Universal Modeling Language?
UML2, OCL, MOF, EDOC – The Emperor Has Too Many Clothes
http://www.jot.fm/jot/issues/issue_2003_01/column1/index_html
[1] Object Oriented Software Construction 1988, 2nd Edition 1997.
Una sola palabra: EXCELENTE!!! Jamas expresaron tan bien ni me dieron tan buenos argumentos para defender esta idea que comparto. Muchas Gracias
Buenisima redaccion y con mucho acierto, espero poder leer más :)
Estimados colegas:
Con respecto a lo que leo me parece genial que existan críticas tanto a favor como en contra de UML. Con mi fanática experiencia tanto en la programación como en el análisis les dejo mis comentarios.
UML–>Diagrama de Clases:
Metodología 100% Aceptable. Si programás en .NET te recomiendo el diagramador de clases del VB2005. Pero si lo hacés en ASP 3.0 ó VB6 dejá de perder el tiempo. Es muy claro ver una clase abstracta, concretas, uso de polimorfismo, métodos virtuales, etc.
UML–>Diagrama de Secuencia:
Si querés entrar en detalles y tenés tiempo de hacerlo, prefiero que lo programes y vas a tener menos errores. Para mi es 5% aceptable, solamente si se quiere demostrar algo en una especie de pseudocódigo, mensajes entre CAPAS (no entre funciones, sino a nivel genérico), aunque para hacer esto cualquier diagráma creativo sirve.
UML–>Casos de Uso:
Vendría a ser lo mismo que relevar, pero a nivel de detalle, así que bienvenido sea. Los gráficos ayudan, aunque empezar a poner herencias, demasiadas excepciones, demasiados casos de uso, creo que es perder tiempo, hay que poner globalmente lo justo y necesario.
Todos los demás nunca los usé. Para interpretar un estado usamos un esquema personal que entendemos todos, lo mismo para hacer algún algoritmo (diagrama de flujo).
En resumen, no creo que todos los que están en esta comunidad estén trabajando con bases de datos orientadas a objetos, así que tengan cuidado si su rechazo proviene por esto, no se confundan, UML no es lo mejor, lo mejor es lo que ccada empresa crea que lo es, ya que en cada empresa argentina hay buenos profesionales lo suficientemente cultos para reemplazar a UML si no fuera necesario.
En mi caso Diagrama de Clases y Casos de uso, lo demás es programar en pseudo, y no se en Estados Unidos, pero en Argentina los programadores son avanzados, saben hacer un sistema a partir de casos de uso y clases. Y por supuesto no nos olvidemos del DER, que es más importante en el 99% de las aplicaciones del mercado actual, a no ser que salga en algún futuro las base de datos OO al mercado.
Muchas Gracias
P.D.: RUP NO SE ADAPTÓ A MIS NECESIDADES, ASÍ QUE TENEMOS NUESTROS PROCEDIMIENTOS, HAGAN LOS SUYOS, Y POR FAVOR LOS RESPONSABLES ACADÉMICOS, TENGAN SENTIDO COMÚN, TENGAN UN POCO DE VISIÓN Y CONSIDERACIÓN, Y USTEDES ALUMNOS, ESTUDIEN PARA PODER CONOCER QUE UML ES LA MÁS FAMOSA, PERO SABIÉNDOLA PODRÁN HACER SU PROPIO LENGUAJE HASTA QUE SE DECIDAN A HACER UN LIBRO, YO SE LOS VOY A COMPRAR, PERO LOS DE UML, LOS TENGO PARA EL ASADO, CUANDO COMPRÉ EL 1RO ERA DE UML 1.3 Y AHORA SALE LA 2.0, ESO NO SON VERSIONES, SON PARCHES ENCUBIERTOS!!!.
SALUDOS
Como comentan arriba, casos de uso y de clases.Al menos son los que he usado jaja.
De todas formas, buenos puntos de vista!!
Si UML no te sirve no lo uses.
Hola chico me encanto tu opinon de UML, yo estoy en un curso de programación Java y estamos empezando con los UML y realmente me parece muy complejo. Total a la hora de programar es muy dificil seguir lo que hiciste en el diagrama
Por cierto: me encataria saber si el chico de la carta le subieron o no la nota
Mi opinión acerca de UML es la siguiente.
Te sirve en algunas cosas; por ejemplo el Modelo Conceptual te ayuda hacer una aproximación a solución implementada, te ayuda a que tu cliente pueda entender la abstración a muy alto nivel de la solución que le propones ….., entonces creó yo que podemos aprovechar está herramienta a distintos niveles.
Verle solo la forma cuadrada es cerrarce al cambio; creo que podemos sacar mucho más.
Respeto las opiniones de cada uno, y sus puntos de vista
La verdad no conozco a UML, para mi es muy interesante ya que en mi empresa estamos tratando de documentar los procesos de cada una de las oficinas, procesos estrategicos, clave y de apoyo, aun no hemos usado ninguna herramienta computacional, me gustaría que me aconsejaran una fácil de aprender y aplicar para graficar, representar y explicar los diferentes procesos. Es importante presentar a las empresas herramientas útiles provechosas y que sean optimas ya que la cuestion no es solo de tiempo, dinero sino de estrategia.
Podrían ayudarme? Ustedes son una luz muy provechosa en las tinieblas Gracias….. Dios los bendiga
Favor sitios web o manuales de usuario para porder aprender rápidamente.
Favor escribir a: Sandypathy1974@gmail.com
Yo creo que lo que define a un buen profesional es saber distinguir cuando debe apartarse de «lo que dice el libro».
Hasta la sacrosanta «tercera forma normal» se ve poco y nada «en la cancha» porque a veces seguir a rajatabla el libro no es lo mejor (y los buenos libros te lo dicen).
Todas las tecnicas y los procesos de desarrollo te aclaran que la idea es adaptarlos a tu proceso. Tomá lo que te sirve en el momento que te sirve, si un diagrama no te agrega valor, no lo hagas, si un paso no te sirve, omitilo. El mismo RUP lo enfatiza.
La diferencia entre un TP de la facu y el trabajo profesional es que en la facu el profesor te va a desaprobar si no rellenas la flechita que iba rellena, o esta en cursiva lo que iba en negrita. (especialmente los profesores que jamas en su vida trabajaron en IT). En la vida provesional, a la flechita no la vas a rellenar nunca y quizá la mayor parte de tus diagramas nunca abandonen el pizarrón, y si eso te sirve y ayuda a tu proceso, cumplió su objetivo.
UML seguro que no es perfecto, pero es lo mejorcito que hay por ahora, y normalmente ayuda bastante, eso no quita que uno use sus propios diagramas, cuando viene bien (quien no dibuja un cursograma cada tanto que tire la primera piedra).
De la práctica y la critica constructiva es que deben surgir las mejoras y los cambios en los métodos, pero claro, vende mas un «UML no sirve» que un «Como mejoramos UML»
Por fin encuentro a los de mi especie, me pregunto si alguno de los 3 amigos aparte de haber dado a luz el UML, como medio de encantador de serpientes y nomás hacer dinero a costa de incautos, alguna vez se han dado una vuelta por América Latina del Sur, se a topado con las realidades empresariales en todos sus tamaños y con todo su poder de modelado, pudieran en un diagrama sencillo y entendible representar todo los problemas que tiene que enfrentar un empresario en el día a día por mantener a flote sus empresas.
Se hubiesen quedado cada uno con su respectivo «hacer modelos» y los hubiesen mejorado y adaptado, actualizado a los tiempos actuales y de ese modo hubiésemos tenido mas opciones de elegir una forma de hacer las bien cosas.
Basta decir que acá hay muchas empresas que trabajan en el limite de la legalidad de software como para estarse distrayendo sus pocos pocos recursos financieros en una herramienta por demas costosa, inútil, que hace perder mucho tiempo sin que puedan dar una solución real al desarrollo de un buen software a medida, de mi parte estoy laborando en una empresa donde el viejo FoxPro para DOS cumple a cabalidad con la impresión de valores financieros, y esto sin haber pasado modelación alguna y el buen Visual FoxPro, el patito feo de la era .net de MS, da el suficiente soporte a las actividades de la empresa.
PD:
Ahora esta de moda el PMBOK (PMI), pero en su introducción a la tercera edición bien claro dice que no se hacen responsables del uso de la metodología en la implantación en el control de los procesos empresariales, me pregunto si una metodología hace creer el ser la panacea, la tabla de salvación para finiquitar problemas, hacen esa advertencia.
Yo creo que UML es como Herbalife, parece una cadena de esas para hacerse millonario verceando a la gente, o también los tiempos compartidos, por ejemplo, todos los cursos que se dan, los tutoriales, y como se dijo en el articulo, los libros de los cursos, los cursos de los libros, parece todo un verso, cual puede ser la utilidad de UML si nadie, absolutamente nadie no le ha encontrado una ambigüedad, que decir por ejemplo de el diagrama de secuencia y repito «secuencia» de UML, no entiendo, no es OO.
Pero si. UML sirve, sirve para el que no le gusta la programación, para el que no le parece mas favorable aprender un lenguaje de programación, siempre hablando en lo que respecta al desarrollo de un sistema de información, ni hablar a que se dedique a otras ramas de la informática.
Yo me pregunto, el especialista en UML si o si debería saber programar, por que si no como sabe si el desarrollador en definitiva uso UML como modelado y no archivo el lindísimo y tan ayornado modelado de UML y desarrollo como a el le pareció.
También esto nos lleva a tener que pensar en el desarrollador
No pero UML se pide en todos lados huuuuuu UML la verdad UML es un gran negocio.
Que dirá un programador cuando tiene que desarrollar un programa a través de lo que le pase el analista luego de haberlo diseñado y modelado al sistema con UML.
El desarrollador dirá, no tengo suficiente con saber, estudiar, actualizarme continuamente en la programación y aparte desarrollar el sistema en cuestión, si no que también tengo que descifrar estos símbolos vacíos de contenido que no dicen nada, por que recordemos que un desarrollador no trabajara siempre en el mismo lugar ni con el mismo equipo de análisis y diseño, y tengamos en cuenta que como esta dicho en UML no son obligatorios todos los diagramas, ni hay una manera única de hacer los diagramas.
Pero UML huhuhhhuuuuuu UML
Algunos dicen UML nos sirve como documentación para el sistema, es una presentación al cliente.
Ahora nos metemos con el pobre cliente que aparte de que se le cobra también el tiene que aprender UML.
Por que seamos sincero al cliente no le importa el papel, el cliente quiere ver soluciones no diagramas.
Por otro lado consideremos la posibilidad que se desarrolle un sistema para una gran empresa que dispone ella misma de un departamento informático con ingenieros y analistas y todos los chiches, contrata a otra empresa para que le desarrolle un software.
Y da la casualidad que estos ingenieros y analistas le solicitan el análisis y diseño con UML, supongamos que estos ingenieros y analistas de esta gran empresa son expertos en UML, ¿por que si son expertos en UML contratan a otros para que les diseñe un sistema en UML? y la otra empresa que supuestamente tiene que diseñar en UML teniendo en cuanta que le tiene que diseñar un sistema en UML a unos especialista en UML ¿que camino tomara?
Otra cosa al que dice que «como mejoramos UML» el solo echo de decir eso implícitamente esta diciendo que esta incompleto, con fallas y repito ambiguo.
Y no es que vende mas criticar a UML, como ya sabemos lo que vende mas es UML en si, para eso esta echo.
Veo muy a menudo que en cursos y facultades antes de aprender UML se aprende o se enseñan distintos lenguajes de programación y en las ultimas materias de la currícula se enseña UML ¿no es irónico.?
Pero por otro lado, también he visto currícula mas coherentes que antes de enseñar java enseñan UML, es decir ahora para aprender java hay que saber primero UML, ¿yo me pregunto y antes como se aprendía java?
También hay gente que dice, no hace falta que uses UML en su totalidad, solo usa lo que te sirva y el resto puedes omitirlo y seguir adelante, con ese pensamiento, es descabellado pensar en omitir todo UML?
Soy analista de sistemas desde hace 10 años, y trabajo con UML desde hace 5 años, trabajo como parte de un grupo de diseño y análisis con UML desde esa época y FRANCAMENTE UML NO TIENE NINGUNA UTILIDAD.
¡¡¡¡¡Pero,……….. es mi trabajo!!!!!!!!!!!!!!!
Saludos a todos muy linda la pagina.
Muy interesante, gracias por despejar mis dudas sobre el estupido UML es por demas decir que odio al UML pero bueno…
Que bueno que encontre este blog !!!!!!!!!!!….el lunes que viene debo presentar mi examen de grado de ingenieria en informatica y estara presente mi profesor de UML que se titulo de magíster en TI con su tema de memoría “Modelando Procesos de Negocios con UML»…y de seguro me pregunta ¿Por que elegiste BPM para modelar proceso de negocio y no UML?…
«Yo creo que UML es como Herbalife»
Me mató el comentario ese!! Jajajaa!!
Estaba buscando de muy mal humor el libro El Lenguaje Unificado de Modelado y me encontré con este blog! Es un buen punto de vista, y está redactado de una forma muy graciosa esa carta (para los que no nos simpatiza UML, jaja).
Mi profesora me está volviendo loca con esos malditos diagramas, yo quiero programar!!! Encima hace unas semanas tuve que investigar sobre Extreme Programming, y la verdad que me dieron ganas de tirar toda la documentación por la ventana, aunque lamentablemente no se pueda =(
Y bueh, es hora de que siga haciendo los diagramas de secuencia y de estado =S Fucking UML!
Muy buen blog, felicitaciones!
«Mi profesora me está volviendo loca con esos malditos diagramas, yo quiero programar!!!»
para Angie: jaja a eso aspiran los programadores, entonces dedicate a estudiar un lenguaje a fondo, y no a diseñar software… los q sepan los «malditos diagramas que se estandarizan con el lenguaje UML» seran los que te digan q programar y como, y no te daran lugar a pensar.
ahora bien leyendo varios comentarios me doy cuenta de la ignorancia con q se suelen tomar estos tipos de articulos al estar en contra de algo Estandarizado, y q esta Monopolizando el diseño «con su enorme campaña de marketing», donde en la mayoria de los casos hacen un mal uso del UML y se castiga a este.
Mejor sigo estudiando, justamente UML, en unas horas rindo.
A favoritos este blog pero no justamente por ser favorito, sino para despeus tener mas tiempo de leer y asentir o discrepar.
Atte Javier, Cordoba Argentina
Fue absolutamente interesante leer todos y cada uno de los comentarios a esta entrada de Javier desde nov2006. Se nota que a lo largo de este par de años UML ha tomado cierta madurez, así como el proceso unificado. Se pueden definir varias conclusiones de todo esto, pero me parece personalmente que la más relevante es: utilizar los que nos sea más útil.
Hoy por hoy existe una campaña masiva de muchas casas comerciales (Microsoft, Cisco, IBM, etc, etc.) por difundir sus «mejores prácticas» y obligar a cientos de profesionales en IT a certificarse en sus productos.
Con cuánta tristeza he mirado cómo muchos proyectos Open Source al final han mostrado su cara oculta o se han visto obligados a volverse un asunto comercial.
Es nuestra obligación (profesionales y/o académicos) el no perder el sentido común y mostrar nuestra insatisfacción cuando la tengamos y proponer soluciones cuando se las requiera. Todos tenemos la suficiente capacidad para tomar lo mejor de una u otra metodología (agradeciendo a sus mentores por el esfuerzo que hicieron) y, por qué no, crear nuestras propias metodologías de trabajo.
Y finalmente a todos los que están pasando por aulas: no se vuelvan locos por favor!!(como dijeran en algún comentario) sigan siendo críticos, constructivos y construyan caminos…
No sean, UML Es lo mejor que puede haber para modelar software.
Esta discución se trata más sobre el formalismo a utilizar en el desarrollo de software, más que sobre UML en sí mismo.
Todas las críticas a UML que leí en este post son puros ataques Ad Hominem a los cradores/distribuidores, no hay ningun argumento que tenga como objetivo demostrar que utilizar este lenguaje de modelado provoca resultados negativos. El hecho que tenga una campaña de marketing impresionante o que haya chantas llenandose los bolsillos sacando libros y dando charlas no desmerece la herramienta en sí misma. A fin de cuentas UML es eso, una HERRAMIENTA. Si te sirve la usas, si no te sirve no la usas… es así de simple.
Ya todos sabemos que uno de los principales problemas existentes en la idustria del software son las «modas» y los intentos de desarrollar una «bala de plata» que nunca van a llegar a buen puerto… lástima que mucha gente (en especial en el ambito empresarial) no logren entender este concepto…
Todo lo q lei en esta insolita critica a UML, son puras estupideces, porq no encuentro una forma mas suave de decirlo (ironicamente como hace el mediocre q envio esa carta al profesor), podra ser muy astuto al seleccionar las palabras para tratar de jactarse de su razon, pero esta lejos de ser coherente, y en algunas partes se nota su falta de conocimiento, un ejemplo: «un CASO DE USO no tiene nada de ORIENTADO A OBJETOS», pero eso es OBVIO, los casos de uso simplemente son los procesos o servicios q nuestro sistema debe hacer para realizar los requerimientos de nuestro CLIENTE, independientemente del paradigma de programacion q utilizemos, se nota q si le pregunto a su abuelo en vez de buscarlo en un libro es un mediocre mas…
UML es un lenguaje visual orientado a darnos la posibilidad de poder modelar nuestro sistema para disminuir los posibles errores q cometeriamos si nos largaramos a escribir TONELADAS de CODIGO sin tener una arquitectura confiable y probada, y correctamente especificada. ESA ES LA IMPORTANCIA DE MODELAR! y usar UML es importante porq esta estandarizado y todos hablariamos el «mismo idioma», es simplemente una HERRAMIENTA, si no les gusta usarlo, o lesda vagueza aprenderlo, es porq no forman parte de un grupo de desarrollo en alguna empresa y no les importa comunicarse usando el mismo lenguaje.
Si estas destinado a ser programador ni te metas a estudiar PUD o UML, si total para eso estamos los q aspiramos a ING, y mandar a los programadores a hacer el trbajo duro y repetitivo…
Apoyo lo que dice Javier Ergui. La gente que «quiere programar», como «Angie», no tiene por qué aprender UML ni nada sobre ningún modelo. Tienen que dedicarse a ser programadores, que son algo así como los albañiles a las órdenes de un ingeniero (civil). Pueden saber mucho sobre levantar paredes, pero si se mandan de una a hacer un edificio de 20 pisos se les viene todo abajo antes de llegar a la primera pared del 5º.
Por otro lado, leí por ahí que «UML es una metodología». Gente: lean, estudien, practiquen, después comenten.
«Si estas destinado a ser programador ni te metas a estudiar PUD o UML, si total para eso estamos los q aspiramos a ING, y mandar a los programadores a hacer el trbajo duro y repetitivo…» – Javier Ergui
Esta separación entre «Ingenieros» que se dedican a modelar y Programadores que solamente se dediquen a construir me parece una visión terriblemente anticuada.
NUNCA se va a poder equiparar una serie de diagramas UML con, por ejemplo, los planos de un edificio que se pueden mandar a los obreros (programadores) para que lo construyan.
El diseño-programación-prueba tiene demasiado de «arte» para eso. Por ejemplo, no podés medir cuantitativamente la legibilidad de un bloque de código (requisito indispensable para cualquier intento de mantenimiento).
PD: Leyendo mi comentario me dí cuenta que se puede mal interpretar y suponer que estoy en contra de la separación de tareas y roles, y a favor de equipos «all-programmers»… nada más lejos de la verdad.
Hay que tener cuidado con las metáforas, porque su poder de abstracción también nos puede cegar a otros aspectos.
La realidad es que el desarrollo de software es una actividad como ningúna otra.
PDD: «I believe the hard part of building software to be the specification, design, and testing of this conceptual
construct, not the labor of representing it and testing the fidelity of the representation» – Fred Brooks
Me parecen muy interesantes los dos puntos de vista y creo que algunas personas aun no comprenden que el crear intangibles como lo son el software es producto del trabajo de personas, es mas como un arte y que al tratar de formalizar el mismo unicamente se ataca a la innovacion de personas que como Angie lo unico que quieren es programar y que muchas veces debido a las ataduras de UML desperdician el gran potencial que pueden tener.
Aca les dejo un link sobre un artículo muy interesante que trata de como algunas personas debido a toda esa publicidad de UML y ese rollo pueden adquirir una ceguera, lo que llaman enfermedad en este articulo, el cual lleva por titulo : Muerte por fiebre de UML.
http://www.ufpa.br/cdesouza/teaching/es/Death-by-UML-Fever.pdf
Saludos desde Guatemala.
Estubo muy bueno leer este blog. Me gusta que arme la rosca y que cada uno de su opión.
Y por eso voy a dejar la mía. Veo a UML como al idioma Inglés, hay mejores idiomas(sictacticamente, semántica y morfologicmaente hablando) pero la mayoría de la gente lo habla y sirve para comunicarse. Aunque por ahi lo pronucies mal o no te entiendan bien, creo que seguramente será mejor que hablar dos idiomas totalmente ditintos. Creo que tambien que cada uno «habla» su UML, veces unos hablan mejor que otros y se consiguen en el mismo lenguaje decir lo mismo pero de mejor manera o de forma mas expresiva.
Creo que se lo debe tomar a uml como un lenguje que entiende la mayoría(esta bueno tener protocolos de comunicación mas o menos definidos, para los humanos) y que posiblemente si te encuentras con algún persona dedicada a IT tengas mas chances de entenderte con el hablando UML que otro lenguaje.
Si no es completo, si tiene falencias que de debe tenerlas seguro con el aporte de los académicos y profesionales se ira perfeccionando. Nadie es perfecto. Y si hay parchar parcharemos, y si hay que rehacer lo deberemos de rehacer.
Si bien es cierto el cliente solo quiere el software ande y para ayer. Tambien querra que mañana no se cobre por tener que reacer el sistema desde cero o que se le vuelvan a hacer las mias preguntas que ya se le hicieron. Documentar, seguramente servirá mas a los desarrolladores que a los clientes. Sin embargo, Supongamos que mañana no ganamos la lotería y ya no necesitamos trabajar en la idustria IT (yo particulamente me habriría una cuenta en las islas caiman o en suiza y viviría de los intereses), la vida de los clientes sigue y tienen que algo de donde partan otros profesionales para no tener que vovler a reinventar la rueda. Me parece que ahi entra un poco la ética. Si alguien me dice, y vos documentas todo? y respondo no la verdad que no, pero no me enorgullezco de no hacerlo, al contrario me da verguenza(mi unico atenuante es que el contexto no me ayuda,a los jefes les importa una bledo la documentación)
Uf, escribi bastante al fianal. Aclaro que intento ser más académico (candidato a doctor, autobecado) pero el contexto me lleva a ser profesional.
Saludos a todos me gusto mucho el blog.
Bueno llegue a leer este articulo y muchisimos de los comentarios que se generaron porque justamente estaba buscando falencias en UML ya que estoy por rendir Diseño de sistemas y estaba estudiando el tema.
Bien respecto a todo esto quiero decir que despues de informarme y leer mucho no estoy de acuerdo con el articulo y con esto no quiero que se piense que solo me quedo en los libro ya que he desarrollado un sistema medianamente grande utilizando UML y dio resultado. Aun asi no lo defiendo completamente, es cierto, UML es complejo para asimilarlo completamente de un solo mordisco (tiene muchas flechitas por aqui y triangulitos por alla) pero en un proyecto real nunca es necesario utilizar el 100% del lenguaje (como en el lenguaje natural hay construcciones que no se usan siempre y todas las analogias que puedan decirse al respecto) cuando uno aprende a ver que cosas son las que son necesarias para cierto tipo de proyecto es cuando UML funciona.
El proceso que se utilice -o el que no se utilice ninguno- tambien es un aspecto clave en el desarrolo de un sistema y no debe pensarse «para que sigo con todos estos dibujitos que lo unico que hacen es retrasar la construccion real del sistema: LA CODIFICACION» esto es un pensamiento errado y deberia reflexionarse, ademas los programadores desde ya hace mucho tiempo tuvieron que verse obligados a aprender e interpretar diversos tipos de diagramas para poder realizar su trabajo, su trabajo no es sencillo y nadie dijo que asi seria.
En uno de los post vi que decian que UML o RUP puede obscurecer a un gran «GURU» de la programacion, esto puede ser cierto (a medias) pero el fin de todo el legunaje y proceso de sw es obtener sw de calidad por procesos repetibles, es decir que tanto un programador que no es tan bueno como uno que es un «guru» puede llegar al mismo resultado. Por supuesto que el programador guru siempre podra mejorar la implementacion del sistema.
Por ultimo, en cuanto a los que se encuentran todavia estudiando como es mi caso recomiendo que se informen como yo lo hago pero que tomen las cosas con pinzas y no crean de una lo que dicen en un foro, blog o lo que fuere solo porque dan argumentos que hacen parecer que lo que se dice es cierto, investiguen y no se queden con lo que leen por ahi, luego de investigar y poner en practica lo aprendido es cuando recien se puede formar una opinion y sacar conclusiones y luego las suben a internet ;) Esto lo digo por muchos post que lei del tipo: «recien estamos dando UML en la facu y no me gustaba, pero ahora entiendo el porque…» obviamente digo esto sin animos de ofender a nadie.
slds. Miguel
Yo pienso que hay que saber cuando usarlo y cuando no….
http://www.luisalberto.org/uml-si-o-no/
No estoy de acuerdo con el artículo, hace muchos años que trabajo en informática y desde el principio lo he usado y he tenido exito con el uso.
Claro, no hay una forma única de escribir las cosas, estoy de acuerdo que no es tan unificado, pero es mucho mejor que MOR y TDN.
Cuanto tiempo pierdan documentando un sistema va relacionado a lo que quieran invertir en ese tema.
El lenguaje sirve para explicar a alguien en un pizarron, no hay que asociarlo únicamente a perder muchisimo tiempo en un proyecto o que tengan que estar obligados a utilizar todos los diagramas en un proyecto.
Además, si no están de acuerdo con UML, porque no proponen otra metodología??? Porque lo único que he visto del artículo es un palo destructivo a una metodología y ningún aporte sobre otra cosa que pueda ser mejor.
Entonces si no hay otra mejor, hay que usar la que hay y además es la mas extendida que conoce todo el mundo.
salu2
Efectivamente. la opinion de Tincho es la mejor, a parte de el articulo que se extendio por mucho tiempo por lo que veo. Lo unico que hacen es criticar, y ninguno da una mejor solucion.
Si UML no es la Tecnologia,Herramienta,Metologia, Metodo, Lenguaje, O como lo quieran llamar entonces Cual es esa herramienta que sin duda hace las cosas mejor que UML. Den el nombre de esa Tecnologia,Herramienta,Metologia, Metodo, Lenguaje, que reemplaza a el UML y que le gana en todo…
Muchas gracias, el articulo es interesante pero como Historia. para leer un rato, Porque en cuestion de definicion de la mejor alternativa.. NINGUNO se pronuncio.
Por mi parte yo uso el UML hace muchos anos.. y nunca.. pero nunca sea el proyecto que sea.. CMS, ERP, CCM, ETC, ninguno se ha salido de la regla de usar UML, en parte en algunos proyectos se aplico algun modelo de UML, dependiendo del rol, se implemento algun modelo… Ejemplo: El modelo de Clases auqnue es muy visual. y el cleinte lo «entiende» No es para que el cliente mire como vamos o si vamos bien o no… Es para los desarrolladores, asi como el modelo de casos de uso, Al igual que para el cliente, y para los desarrolladores, es un lenguaje comun entre las dos partes.
Y pues mi opinion llega hasta aqui, para mi UML funciona perfecto. y el que diga lo contrario que me diga donde descargar, leer, aprender, una nueva alternativa
Bye
Tincho, Mackpipe:
Si algo ha hecho Bertrand Meyer en los últimos veinte años es, justamente, proponer otra metodología.
Les sugiero que busquen «diseño por contratos» (o «design by contract») en la web.
Si por el año en que cursaste se nota que careces de formacion;para el desarrollo orientado a objetos, ni hablar de conocimiento de programacion extrema.
Si haces programas ,para el almcenero,o el kiosco ,utilizando visual basic, vb.net Esta bien que pienses asi,ya que vb no es orientado a objeto
Pero si se va a relizar aplicaciones CRM,ERP,etc, ahi lo que decis es una estupidez.Conceptos como componente,modulo,proceso,servicios Se basan en la definicion de los objetos del negocio, y eso lo haces utilizando las definiciones de UML.Hablas de RUP un metodo pesado e inutil inventado,por ibm para su software rad (rationat developer);pero existe metodos mas modernos , y ligero,como la XP de las metodologia agiles.Que permite reducir los tiempos de puesta a punto de soft;por medio de los test unitarios, y otras yerbas.
Reduce el impacto de los cambios;por que se aplica solo a los modulos que afecta, y en el caso de tener que escalar puedo reutilzar los componentes, y modulos
Si programas en genexus,visual basic/.net es inutil que lo comprendas;pero si desarrollas en serio con Java/c/c++ creo que entendes te equivocaste
Supongo que por tu comentario programas en cobol , y te hecahro de iBM
Antes pensaba como vos. Incluso publicite por todos lados esta nota. Tengo q admitir q fue un gran error. Se nota q nunca trabajaste en un proyecto grande, porque si lo hubieras hecho, no opinarias esto…
Martín:
¿Bertrand Meyer tampoco? ;)
bUNEA MAN , en mi centro de estudios tambien me di cuenta de esto, por suerte no le dedique mas de 5 horas de estudio a esta rama, sin embargo los sistemas que hize los hize sin usar ninguno de estos metodos, tu eres la voz de muchos, jejeje bye un saludo
Nunca dije que no tuviera falencias, pero lo adaptas un poco a tu parecer y funciona basatante bien ;)
Fernando es el claro ejemplo de que solo una persona ignorante podría utilizar «ignorante» como un insulto.
Hizo una exposición (a mi entender) muy buena de conocimientos y de defensa a UML, exposición que podemos o no compartir. Pero, como dicen en mi barrio, la «cago toda» utilizando insultos para tratar de ¿refutar? las aseveraciones de Javier.
La verdad que ver discutir a 2 personas es algo atractivo y hasta educativo, pero cuando uno de los 2 es un ignorante (sin utilizarlo como insulto) en la materia del buen trato personal y de la discusión en buenos términos… pierde bastante la gracia.
Por si las dudas y para que «El Mendocino» no cargue todas sus tintas contra mi, a él que le gustan tanto las asociaciones que imponen una u otra cosa le dejo la definición de «ignorante» de nuestra vieja y queridisima RAE:
ignorante.
(Del ant. part. act. de ignorar; lat. ignōrans, -antis).
1. adj. Que no tiene noticia de algo. U. t. c. s.
El que lo usa como insulto, no tiene noticia de que es un ignorante del insulto.
He leido el post bueno casi todo, a pesar de que no tengo mucha experiencia en uml.
Creo que siempre se debe ser abierto a criticas hacia cualquier metodologia, pero esto va para rellenar ese error actual. no para decir que esto no sirve y ya. en otras cosas creo que UML se vuelve tan complejo pero sera porque asi estan modelando el sistema (Es tu forma de verlo ) puede ser que alguien mas lo vea de otra forma.
En mi caso uml fue una herramineta muy util al momento de elaborar nuestro sistema en la clase de sistemas de informacion en mi carrera. Aunque si pesado, y complejo pues nos presento varias complicaciones que retrazaron el proyecto un tiempo considerable.
no creo que sea como tu lo llamas «un lenguaje totalmente inutil» me suena a una exageracion, como si simplemente batallaste con el lenguaje, pero bueno, esa es tu opinion, pero si existe el lenguaje.. y hasta la fecha se sigue utilizando es por que ha funcionado, de caso contrario ya no fuera tan popular, y si bien al principio a mi me parecio tedioso, despues de acostumbrarse empiezas a verle las ventajas, es de cierta manera es mas facil programar si primero ya lo creaste arquitectonicamente habalndo.. ya es segur las instrucciones se podria decir. En fin, a mi no me parece «un lenguaje totalmente unutil»
no estoy de acuerdo con tu punto de vista, tiene varias herramientas muy utiles, por ejemplo el diagrama de casos de uso ademas poder ver la secuencia de ejecucion y su reaccion en diversas circunstancias, es un diagrama visual que no necesitas ser un programador para entenderlo, por lo tanto se lo puedes mostrar al cliente y llevar acabo una mejor acertividad. No me digas que no es util el diagrama clases, si puedes crear toda la estructura de tu programacion, relacionando tus clases y hasta el codigo te genera.
no se me hace buena idea empezar a construir sin los planos de la casa.
Estoy en total descuerdo con el autor de este Post. Si bien UML puede ser en ocaciones terrible y enfadoso, realmente tiene muchas aspectos utiles. Muchos creen que un programador no nesesita de uml para programar un sistema y es cierto no lo nesesita pero sin duda tener una guia en diagramas de todo lo tenemos que programar nos resulta provechoso y nos evita la perdida de tiempo. Los diagramas de clases por ejemplo la mayormplo nos brindaia de la esctructura de la programacion, por lo que decir que ulm solo le sirve a los lideres de proyectos es ridiculo.
Hola, buenísimo el post y buenísima la traducción. «Me quito el sombrero».
Te sigo desde hace años y no había visto este post.
Saludos.
Buen post y aún mejores comentarios.
UML no me parece tan malo, al menos es estándar y eso ya es algo (sobre todo en informática).
Cambiando de tema, Eiffel me parece genial, lástima que no sea comercial/software libre (o que Meyer no quiso que lo fuera).
no termino de darle valor a los comentarios. Mayoritariamente me parecen comentarios de personas que están estudiando, y no entienden al profe o al lenguaje, como me pasó a mi. Sería bueno saber cuantos años de experiencia en Captura de Requisitos, Análisis, Diseño, Implementación y Pruebas llevan como para saber si se habla de experimentado o de resentido.
haciendo referencia a lo que comenta GerMDZ soy uno más de los que recién empiezan a estudiar esto del desarrollo unificado apoyandome en el libro ppal. de jacobson, booch.. mi crítica es al libro de los inventores de este lenguaje +q a la herramienta uml.
tengo algo de experiencia en desarrollo en empresas de soft . y mi visión del libro esque se subestima mucho la labor del programador, en el sentido que todos los que participan en el desarrollo del producto los llama ingenieros excepto el desarrollador que es quien para mi , otra pers con más conocimientos técnicos no puede haber, y nombran a ing. de prueba a una pers. que hace ctrl. de calidad, q en la práctica no deben tener más requisitos que estar atento a que el sist no largue errores, para probar un videojuego el requisito es ser un adicto a los jueguitos y para el libro son ingenieros… pero por favor!
La verdad es que yo opino lo mismo, no sirve, pero cuando uno dice eso es como remar contra la corriente, pero es muy inutil.
Gracias por compartir sus comentarios
Creo, como varios aqui, que Fernando ‘la cagó’ usando insultos totalmente innecesarios.
Muy interesante el artículo y los comentarios, la verdad, me aclararon algo el panorama de UML y sus competidores (poco publicitados).
Actualmente soy usuario de un portal de cursos virtuales en mi país Colombia y todos los cursos dedicados a esta materia usan UML y explican UML para el diseño OO.
Este tipo de discusión ayuda sobretodo al principiante (como yo). Los viejos zorros en esto ya saben como es el cuento, pero nosotros no y necesitamos este tipo de información para saber la realidad de esto EN LA PRACTICA.
a mi particularmente me fue muy útil leer esto.
aún así no es bueno aceptar algo sólo porque lo escuchamos (o leemos) de otro. Hay que investigar por uno mismo.
Saludos.
Pd. Leeré acerca de Diseño por contratos, me parece interesante.
primero que nada encuentro genial que escribas sobre UML no importa si es malo o bueno.
la naturaleza del proyecto es un planteamiento que da el cliente,él cliente no la sabe, pero el señor ingeniero de sistemas sí al momento de entrevistar o hablar con el cliente ..etc.
en mi opinion UML sirve y de mucho, de hecho alguna logica de software se ve nesesaria para el planteamiento y desarrollo de sistemas pequeños o complejos.
el uso de UML se ve nesesario para entender la logica del negocio, de sistemas junto con los diagramas de casos de uso…..
por mi experiencia es necesario crear diagrama UML para el desarrollo de sistemas no importando su naturaleza ni que tan complejo pueda ser.
Creo que UML es un lenguaje UNIVERSAL
Nadie dijo que era para software, de hecho, se puede modelar todo lo modelable con el, hasta el cuerpo humano, un coche, la evolucion humana, una casa, etc….
Solo ese detalle queria dejar expresado,
Muy buen articulo, se nota el esmero al escribir y compartir con todos tu punto de vista!
Saludos
Me parece muy interesante la informacion expresada, pero me parece que uno no solo debe ponerse en la tarea de criticar sino tambien de aportar, por lo cual si consideran que existe una alternativa mejor, por favor compartanla.
Gracias,
Interesante polémica y felicito a las dos partes más radicalizadas. He aprendido de cada uno. Aporto mi granito. Tengo algo de experiencia en el uso efectivo de UML y de verdad entiendo la frustración que suele provocar.
Desde mi punto de vista el problema radica en que no es fácil encontrar libros, profesores o colegas que expliquen de manera sencilla y práctica cómo usar UML de manera efectiva dentro de un proceso de desarrollo dado.
Empecemos por entender lo básico. UML es simplemente una forma estandarizada de documentar un sistema. Es una herramienta que puedes usar o no. Y que la uses o no, no implica que tu sistema será mejor o peor, como no puede ser mejor o peor tu programa si colocas comentarios en el código. Por ello, no tiene sentido pedirle a UML que ofrezca mayor robustez, flexibilidad y demás características deseables de un sistema moderno. ¿Esperaríamos que por el hecho de crear un buen archivo de ayuda para el usuario final, nuestro sistema fuera más flexible, robusto, etc?
UML se creó con la idea básica de poder contar con una forma estándar de comunicar ideas. Punto. Cuando hablamos con nuestros colegas sobre el programa que estamos haciendo solemos hacer dibujos en una hoja para hacernos entender. UML es una forma más formal de hacer estos dibujos. Si tú dibujas las clases como triángulos y yo las dibujo como rectángulos no nos vamos a entender fácilmente. Pongámonos de acuerdo. Eso es UML.
El problema de UML empieza con el gran número de artefactos que a cualquier principiante puede abrumar. Pero como bien lo dicen los mismos creadores, la gran mayoría de proyectos se pueden documentar fácilmente sólo con el 20% de todos los artefactos de UML. (Lo malo fue que nunca nos dijeron cuál era ese 20%).
Y aquí es donde empieza el problema del uso efectivo del UML. Como todo lenguaje, UML tiene una gramática (una estructura del lenguaje) y un vocabulario (cómo se nombran las cosas). Por lo general los libros, profesores, seminarios y cursos, explican con detalle estos dos aspectos. Y nos abruman con diagramas, símbolos, flechas, etc. Pero muy raramente encuentra uno quien explique cómo usar toda esa gramática y ese vocabulario en un proyecto real y de manera efectiva. Ese es otro cuento.
Para mi ha sido un proceso doloroso, no lo niego, pero no es por culpa de UML, sino por el mal enfoque de quiénes lo explican. Una vez que entiendes cómo usarlo se te hace difícil crear un sistema complejo sin apoyarte en UML.
UML es una herramienta de apoyo en el proceso de desarrollo, pero como toda herramienta, si es mal usada puede terminar siendo un verdadero lastre. Lo ideal, es poder usar UML junto con una metodología de desarrollo que se adapte a la forma de trabajo del equipo de desarrollo.
Ahora bien, no existe una única metodología que funcione bien con UML. Cada equipo termina adaptando la que le parece más adecuada a su forma de trabajar.
Es importante tener en cuenta que la ingeniería del software es una disciplina muy joven, si la comparamos con la ingeniería civil, química o eléctrica por ejemplo. Estas últimas llevan cientos de años, incluso miles de años de evolución. Nuestra profesión ni siquiera ha alcanzado sus primeros cien años. Por ello, todavía hay mucho en qué mejorar. UML sólo ha sido el primer intento por estandarizar la documentación de un sistema, y sigue evolucionando. Se crean herramientas software que día a día facilitan más su uso efectivo. Y es de esperar que un futuro no lejano, gracias a estas herramientas, UML pueda mostrarse en toda su potencia y utilidad práctica.
seria interesante volver a ver la opinion de javier despues de 4 años de evolucion del UML aunque creo que sera la misma, o no?? un analisis seria muy buena idea. yo que no creo en los blogs, pero creo que este fue muy bueno.
Exelente post! al igual la traducción
Un saludo
la verdad tienen razón ambas partes los que defienden y los que arremeten con que UML no sirve…….. la única verdad es que UML solo te da una aproximación de la solución (si eres programador y realizaste proyectos) , porque el análisis al programa hayyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy muchhhhhhhhhhhhhhhhhhooooooooooo trecho…
y creo que todos me apoyan en eso, excepto si haces proyecto simples y rutinarios………..
1. Practicamente no he conseguido ejemplos ni claros ni concisos.
2. No consigo que nadie me explique que relación hay entre cada uno de los diagramas.
3. No consigo con cuál diagrama se comienza y con cual se termina.
4. No consigo qué orden lleva el desarrollo de los diagramas.
5. No es KISS, (Keep It Simple Stupid).
Conseguí un libro excelente, que explica los diagramas de clases, se llama: PROGRAMACIÓN ORIENTADA A OBJETOS PARA PHP5 por Enrique Place
Este libro está también que me dió esperanzas de nuevo para entender UML.
Pero los demás libros y ejemplos son puro texto y texto, que termina mareando y en definitiva: Si es complicado, no es bueno, así de fácil, así de simple.
Un cordial saludo.
P.D.: Si alguien tiene información sobre un ejercicio completo se lo agradecería mucho.
Wow, estamos en el 2011 y aún da para discutir esta nota (o publicación, no soy de usar blog así que no se como decirle)
Creo que un diagrama de clases en UML (sin querer detallar mucho) es útil, pero de nuevo, solo para dar una idea muy básica del diseño. Para detallar es mejor dejar el diagrama básico y usar algún otro método para hacerlo.
Los demás diagramas pueden ser útiles pero creo que hay que usarlos con cuidado por que después pueden terminar causando mas problemas que soluciones.
Usar cursiva para definir un método o clase abstracta me parece algo totalmente incomprensible, no entiendo como no se dieron cuenta que NO SE NOTA!, el único que sabe que un método es abstracto es el que hizo el diseño o alguien con una agudeza visual realmente envidiable.
Querer especificar «genericidad» (clases templates en c++ si no me equivoco) no está muy bien hecho.
La carta del alumno me parece genial!, gracias por la traducción.
Saludos.
Señores!!!, creo que hay que acotar algo: UNA HERRAMIENTA NO ES UNA METODOLOGÍA!. Javier creo que confunde las cosas aclarando que Eiffel es una metodología. A pesar de los insultos apollo a Mendocino, sin embargo, uno no usa UML de buenas a primeras: TODO DEPENDE DEL PROYECTO A DESARROLLAR. Si un proyecto decae, no es necesariamente por la herramienta (RUP, UML, DFDs, etc) sino por la metodología. Todo depende del que gestione el proyecto!!!!!. Yo uso UML para análisis y diseño de sistemas y no lo he visto difícil como menciona Javier!!!, Javier una metodología es SOA o Ciclo de vida del desarrollo de sistemas (eso que uno aprende en preparatoria cuando ve sus primeras clases de computación). No confundan lenguajes de programación con lenguajes de modelado por favor!!!! caen en un error grandísimo y si no saben diferenciarlos vuelvan a la universidad!!!!!!!!!!!.
Javier, no JUSTIFIQUES LO INJUSTIFICABLE, como aprendíz y estudiante universitario NO CUESTIONES A LOS QUE TIENEN EXPERIENCIA. Trata de aceptar al UML, vamos únete al lado oscuro!!!!, tendrás más poder al desarrollar aplicaciones, el modelarlas con UML te hará más y más poderoso que un JEDI, sé un SIT Javier.
Muy bueno el artículo. En la facu no vi los puntos oscuros de UML.
Pero lo siguen utilizando y cada vez mas. Mi opìnión tiene sus puntos fuertes y débiles como todo en sistemas.
Muchas gracias por la info.
Buenos Dias: por lo que lei tu sabes bastante sobre el tema, necesito de tu ayuda urgente, ya que tengo que hacer un trabajo para desarrollo de sistemas de informacion en la U y no se mucho sobre UML y me pidieron hacer un informe con 2 empresas que hayan usado UML, agradeceria mucho tu ayuda.
Siempre pensé que el UML no servia de mucho y estos comentarios no hacen mas que validar mi idea. En realidad, es dificil usar para programacion algo que fue creado para ser mucho mas general que eso.
Se necesita un lenguaje de modelo especifico, yo creo que tendria que ser algo recursivo para que funcione bien, desde el entendimiento de los procesos, hasta llegar al codigo.
Yo estoy por presentar mi tesis de grado y lo tengo que hacer usando el Proceso Unificado y UML. La cosa es que lo que no me dicen ni RUP ni UML es el «grado de abstracción» que hay que tener, algunos dirán «claro, la abstracción la das vos», eso es lo mismo que decir que la velocidad en la ruta la ponés vos y no hay que darle bolilla a las señales que dicen «80 la máxima»; de alguna manera el nivel de abstracción debe ser regulado.
Por lo demás, UML y todos los demás tienen su utilidad y su parte oscura. El que quiera usarlo que lo use y el que no, que no lo compre, para evitar colaborar con el negocio de los creadores, y use otra metodología.
Personalmente hablando, en cuanto termine con mi tesis, lo largo y me dedico a estudiar otra metodología que sea mas «sencilla».
Saludos, feliz navidad.
Santiago.
para santiago, UML no es una metodologiaaaa
una dudota que tengo que pasa si el lenguaje de programacion es orientado a objetos en este caso Visula Bacis 2010 pero se programo en forma esructurada que problemas hay? °_° profa alguien que me pueda conestar
qisiera saber que es el UML que no intenta hacer
pues el 90 % es inutil
Por fin termino de leer todos los comentarios. Me agrada que en varios hay posturas y alternativas.
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.
Tuve la fortuna de hacer parte de los backers de Broken Age de DoubleFine y ver todo el proceso de desarrollo del juego (lo que documentaron en video y en foros), en algún momento estaban hablando de programación y surgió esta conversación:
-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 :-)
Smaldone:
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.
Se vé que no saben para que es el diagrama UML, no es ni una metodologia ni estrategia de desarrollo, es simplemente demostrar graficamente con actores involucrados el paso a paso de los requerimientos, los invito a que lo usen para representar requerimientos funcionales.
Pues interesante creo. Pero creo que estaría bien si dieras una alternativa al uso de UML.
Saludos