Uml, el giro positivo

UML: El giro positivo
Por Bertrand Meyer Versión original (en inglés): http://archive.eiffel.com/doc/manuals/technology/bmarticles/uml/page.html. Traducción al español: Javier Smaldone (17/11/2006).

De: Cándido Smith, alumno de OO-101 A: Profesor Severa Stern Asunto: Mi solicitud para el cambio de calificación Estimado Profesor Stern: El auxiliar de cátedra de su clase OO-101 me ha indicadoque 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 enmendarmi 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 elconsejo 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 cuales 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 60pá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") ysemá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 tanhermoso) 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...