En busca del UML perdido

Años 90. Se puede considerar que por aquel entonces, en esto del desarrollo, estábamos en la época de las metodologías. Mentes pensantes se estrujaban las meninges para dar con el método perfecto que pudiera llevar a cualquier mindundi que no supiera nada a hacer programas, qué digo a hacer programas, ¡a hacer programas mantenibles y bien hechos!. Alguno igual hasta suspiraba porque su metodología fuera tan perfecta que los propios ordenadores fueran capaz de hacer sus propios programas, ellos solitos, mientras el programador daba cuenta de una jarra de cerveza. Se pensaba que si la metodología era buena, el programa resultante tenía que ser bueno.

Durante muchos años, la "cascada" era el modelo dominante, dentro de esas metodologías. Primero un señor A pensaba qué tenía que hacer el programa, y lo escribía todo en un documento. Luego, otro señor B pensaba cómo se iba a hacer lo que indicaba el señor A, y lo escribía todo en otro documento. Luego, el señor C, también llamado "el pringadete de turno" tenía que hacer el programa como habían dicho los otros dos. En la práctica, en cuanto el señor C empezaba a meterse en faena, se empezaba a dar cuenta de que había cosas que no cuadraban, otras que se habían pasado por alto, otras que no se entendían, otras que no tenían sentido, etc. Resultado: el proyecto se retrasaba horrores, el señor C hacía horas como un campeón y le tocaba tomar decisiones que no le correspondían, y los maravillosos documentos y esquemas realizados por los señores A y B quedaban anticuados a las dos semanas de trabajo de C. Al final, al cliente se le daban unos tochos de documentación, que le importaban un pepino y ni se molestaba en mirarlos para darse cuenta de que no estaban actualizados, y un programa que (con un poco de suerte) funcionaba pero se acababa convirtiendo en algo imposible de mantener (lo que viene a llamarse efecto bola de nieve). En definitiva, este método normalmente no funcionaba. Es más, esto causaba un divorcio entre el mundo académico y el mundo real, que necesita soluciones prácticas y eficientes para llegar a una solución.

Dentro de esa vorágine, aparecía el paradigma de la programación orientada a objetos. La mayor gracia de los objetos es que facilitan manejar un concepto que ya estaba haciendo mucha falta manejar: la incertidumbre. Vale, supongamos que somos humanos. Supongamos que no conocemos bien lo que se necesita hacer, que el desarrollo conlleva que el programador vaya aprendiendo gradualmente qué es lo que realmente se necesita. Supongamos que además, no conocemos qué se va a necesitar en el futuro, como van a evolucionar las necesidades y cómo van a ir cambiando las cosas. Supongamos, incluso, que esto que hemos hecho podemos acabar utilizándolo como parte de otros programas más grandes, reutilizándolo. En ese caso, necesitamos ser capaces de hacer estructuras y componentes que sean lo más flexibles posible. Eso es precisamente lo que permitían los objetos.

Por supuesto, como buena época de metodología en la que estábamos, rápidamente aparecieron más mentes pensantes buscando el método mágico con el que crear programas orientados a objetos fuera tan fácil que pudiera hacerlo hasta un niño de 3 años dormido y con las manos atadas a la espalda (y peor aún, en Lunes). Es más, aprovechando el vacío existente, cada mente pensante se inventaba sus propios diagramas para hacer el diseño del programa, con cajitas, nubecitas, flechitas o lo que fuera. Un carajal, vaya.

Un buen día tres de esas mentes pensantes que tenían sus propios métodos y notaciones (Booch, Rumbaugh y Jacobson) hicieron equipo, con el simpático nombre de los "three amigos", y en 1997 crearon una notación única para hacer diseño orientado a objetos, con ánimo de convertirse en un estándar (como así fue) y de que encajara en cualquiera de los métodos mágicos existentes. Había nacido el UML. La importancia de esto es grande, ya que con el UML se separaba el lenguaje de modelado de la metodología que se siga para obtenerlo, y se definieron los conceptos que se iban a manejar en el diseño orientado a objetos. Si tú veías un diseño orientado a objetos hecho en UML lo entenderías, independientemente de cómo se hubiera llegado a ese diseño. Y un diseño hecho en UML te da una perspectiva buenísima de cómo se ha pensado un programa, cómo se ha estructurado, cómo se ha diseñado. Esa perspectiva funciona tanto para el que lo está diseñando, que según lo va haciendo lo va entendiendo mejor, como para el que tiene que entenderlo para  modificar el programa más adelante y hacerle cambios sin volverse loco. Ayuda a pensar, ayuda a hacer entender.

No penséis que esta colaboración de los "amigos" vino propiciada por el buen corazón de estos tres tipos. Si fuera así, quizá habrían contado con otros teóricos notables de la época, como Martin Fowler ó Erich Gamma, que además habían hecho contribuciones importantes al empezar a proponer algo distinto a oooootra metodología mágica más: fomentar el uso de patrones. Un patrón no es más que un ejemplo "bien hecho" de cómo resolver de forma adecuada un problema común. O sea, básicamente permite que aprendas a diseñar "copiando" otras soluciones. Por tanto, no llegas a una solución buena por un método mágico, sino que llegas a ella copiándola de otro caso parecido, y al hacerlo, la aprendes y la haces tuya. Es como el que en arquitectura inventó la puerta, o la escalera de caracol, y luego todos copiaron la idea, o como el que inventó una forma innovadora de pintar los paisajes en los cuadros. Eso funciona.

Como decía, el motivo detrás de esta gran amistad tenía que ver con una empresa que había visto el filón que se le presentaba: Rational. Esta empresa contrató a estos tres amigos para impulsar la venta del que lanzaron como su producto estrella: Rational Rose. Sospecho que la jugada les salió bastante bien durante varios años. Sé que aunque mucha gente lo pirateaba, también había muchas empresas que pagaron licencias del producto, y realmente se llegó a "poner de moda". Los "amigos" no se quedaron ahí, y como buenos metodólogos, rápidamente inventaron también una metodología "única": el Proceso Unificado. El Proceso Unificado iba más allá de la cascada, y promovía el desarrollo basado en "iteraciones", en las que cada iteración venía a ser una mini-cascada.

Ahora, volvamos al presente (no se vaya a convertir esto en otra entrada en plan "abuelo cebolleta"). Han pasado ya unos cuantos añitos y se puede decir que los objetos han triunfado, sobre todo gracias a Java. Sin embargo, aunque se programa mucho con objetos, pienso que cada vez se ven menos diseños con objetos. La propia palabra "diseño" se usa hoy en día fundamentalmente para el diseño gráfico, más que para el diseño de software.

¿En qué momento se empezó a perder el diseño, si gracias a UML ya teníamos lo mínimo necesario, que es una notación común, y herramientas capaces de crear esos diseños con facilidad, y hace un rato he hecho un canto a las maravillas del diseño con UML?. ¿Qué pasó?. ¿Realmente hemos perdido algo, era útil, o era más bien prescindible?. ¿Todavía podría convertirse en algo práctico?. ¿Cómo?.

Daré mi opinión sobre todo esto en la segunda parte de esta apasionante saga, con el título provisional de "Herramientas y el UML maldito". Manteneros atentos y tened paciencia. Al fin y al cabo, cuando la serie acabe puede que el UML os haga cambiar vuestra forma de programar...