Tomando la Temperatura de UML

Más de doce años han pasado desde que el Lenguaje de Modelado Unificado (UML) se convirtió en un estándar. Durante esos años, la percepción de UML ha variado desde las alturas del cielo hasta las
profundidades de la tierra.
A inicios de los 1990s existían 26 métodos publicados para orientación a objetos, la mayoría de ellos con su propia notación. UML fue creado para buscar resolver por lo menos el problema de la notación. Como la mayoría de ustedes sabe, Grady Booch, Jim Rumbaugh y un servidor iniciamos el diseño de lo que eventualmente se convirtió en UML, pero rápidamente muchas otras personas se unieron al esfuerzo y la OMG apadrinó el resultado y lo hizo público como estándar. UML rápidamente hizo superfluas al resto de las notaciones. Conforme sus notaciones se hicieron obsoletas, los métodos correspondientes también dejaron de ser usados, dejando al Proceso Unificado que había adoptado UML como base, como el estándar de facto como proceso para desarrollar software. En esos tiempos, la adopción de UML se esparció como el fuego.

Críticas y la pérdida de interés
En retrospectiva, debimos haber sabido que tal éxito inicial seguramente tendría sus consecuencias negativas, conforme las expectativas iniciales no se cumplieron. Todos esperaban que sucedieran
cosas mágicas, pero después de todo UML era tan solo una notación, no una bala de plata. Para empeorar esto, las herramientas de software para modelar UML no eran buenas, algunas eran avanzadas pero difíciles de usar. Todas las herramientas fueron vendidas en exceso, haciendo creer a los compradores que la herramienta era la solución. Muchos clientes quedaron decepcionados al darse cuenta que el mero hecho de hacer diagramas en UML no mejoró mágicamente sus resultados de desarrollar software. Conforme pasó el tiempo, la adopción de UML se frenó.

UML también encontró a un grupo de detractores. Fue criticado por el mundo académico. El gran David Parnas llamó a UML el “Undefined Modeling Language” (lenguaje de modelado no definido), una
crítica muy exagerada pero no infundada. La crítica dolió. Los líderes originales del movimiento ágil también estaban fuertemente en contra del modelado. Para ellos era el “Unnecessary Modeling
Language” (lenguaje de modelado no necesario). Ellos decían “no modeles, solo programa”.

Por su parte, Microsoft no soportó inicialmente a UML, ya que a fin de cuentas apoyarlo solamente fortalecería a sus competidores. Lo que ellos hicieron fue moverse en la dirección de los lenguajes de
dominio específico (Domain Specific Language, DSL).

Después del año 2003 el interés en UML bajó considerablemente. UML definitivamente estaba perdiendo su inercia.

Regresa el interés
A pesar de todo esto, ahora encontramos que el péndulo va enbla otra dirección y el interés en UML está regresando. Ya existe un buen número de herramientas buenas y fáciles de usar. La crítica por parte de la academia ha disminuido. El desarrollo ágil ha sido adoptado por empresas grandes que encuentran valor en una estrategia que combine el desarrollo ágil con el modelado “inteligente”. La gente utiliza UML aunque el escepticismo en las herramientas se mantiene; mucha gente trabaja con diagramas en pizarrones y casi no usa herramientas. Microsoft se ha dado cuenta que los lenguajes de dominio específico no reemplazan el rol de UML y que los clientes quieren usar UML, así que Microsoft ya respalda UML fuertemente.

Perspectiva a futuro Hoy el mundo ve hacia UML con una perspectiva más balanceada. Ya no es vendido como una “bala plateada” como hace diez años. Tampoco es tan malo como los agilistas acusaron hace 5 años. Utilizado de forma adecuada, es una herramienta práctica para aumentar el nivel de abstracción del nivel del código al nivel de todo el sistema. Ahora su uso está aumentando, pero con un mayor sentido común.

Aun así, UML se ha hecho complejo y torpe. Para el 80% de los sistemas de software, solo se requiere el 20% de UML. Sin embargo, no es sencillo encontrar un subconjunto de UML al que podamos identificar como el UML “esencial”. Debemos encontrar formas más inteligentes de usar UML.

Nota: Este artículo fue traducido y editado por SG con permiso del autor. La versión original se encuentra en http://bit.ly/77N0eJ