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...

Historias del abuelo Cebolleta: Programar ahora es para nenazas

Debía ser alrededor de 1983-84, Navidades. Hay que ponerse en situación, en aquella época no era ni mucho menos tan común como ahora el uso de aparatos electrónicos. Ahora cualquier niño de 4 años enseña a su abuelo a usar el smartphone, y desde antes incluso andan aporreando el tablet para algún extraño juego educativo. Pero yo sí era uno de los afortunados que había tenido algún contacto con cacharrillos electrónicos. Como por ejemplo con un Pong que había tenido mi padre:

las míticas Game & Watch con las que nos pillábamos unos vicios de cuidado entre los hermanos y primos:

o la no demasiado conocida Philips Videopac:

Sin embargo, esas Navidades algo especial iba a suceder. Uno de esos acontecimientos que no ocurren más de una o dos veces en cada vida pero que la cambian para siempre, que activan resortes que siempre han estado ahí, tan sólo esperando un empujoncito, y que sin él podrían incluso quedarse latentes de forma indefinida, quizá sin llegar a manifestarse jamás. Pero el empujón llegó, ese año recibí de regalo... mi primer ordenador. Y en ese momento...

¡¡¡ HABÍA NACIDO UN MONSTRUO !!!

(vale, un baby-monstruillo... ¡¡¡joer, ya os avisé de que era un chavalín!!!)

Toca otra vez ponerse en situación. Por si con las fotos anteriores no os había quedado claro, debo decir que por aquel entonces un ordenador no era exactamente lo que ahora nos viene a la cabeza al oír esa palabra. Nada de discos duros. Nada de ratón. Teclado sí... bueno, es que el ordenador ERA un teclado, aparentemente. Sólo 48 kilobytes de RAM. Se conectaba directamente a la televisión, lo que ocasionaba unos tremendos problemas familiares hasta que tus padres sabiamente decidían darte una televisión vieja para que te callaras (televisión que a menudo era en "glorioso blanco y negro"). De cosas como "Internet" o simplemente "red" ni hablamos, aún quedaba tela para eso. Y lo mejor de todo: los datos no se cargaban con un pen drive, ni con un disco duro USB, ni con un DVD ó Blue-ray, no. ¡se cargaban con cassettes!. Aunque por supuesto todo esto ya lo sabes, porque si aún estás leyendo esto, ejem, es que sin duda eres alguien con amplios conocimientos sobre informática (o un carrozón de cuidado).

Sí, amigos, con todos vosotros... ¡el ZX Spectrum!

Al principio el joven Andrew hizo lo que todo buen niño haría: jugar (bueno, a decir verdad el joven Andrew jugó al principio, al menos principio y al final, y no ha parado de jugar con la vida desde entonces, aunque ya de "joven" Andrew tiene más bien poco). Pero sí es verdad que en los ratos libres ya entonces iba "coqueteando" con el manual del BASIC del Spectrum, con idea de hacer algo pero sin acabar de decidirme. Debía tener yo unos 11 años cuando en el colegio les dio por ser innovadores y un año se decidieron a darnos un curso de Informática. Sí, sí, ya por entonces se llamaba Informática. En ese curso lo que nos enseñaron fue precisamente el BASIC del Spectrum. No recuerdo demasiado sobre aquella época, pero sí me acuerdo de que el profesor (o profesora, vete a saber) era bastante malo. Lo que sí me permitió la clase es picarme la curiosidad, que al fin y al cabo era lo más importante.

El caso es que junto a otro chico que al año siguiente se fue del colegio y que la verdad, ya no recuerdo cómo se llamaba... ¡hice mi primer programa! Se trataba de un juego del estilo del Arkanoid llamado: Baloon Man.

Sí, el juego es tan espectacular como aparenta. La verdad es que programar en el BASIC del Spectrum era todo un reto. Tenía algunas ventajas, como que las palabras clave estaban asignadas directamente a las teclas, por lo que con un par de pulsaciones escribías cualquier palabra clave. Sin embargo, era más bien tedioso a la hora de manejar conjuntos de constantes. Eso de crear un array e inicializarlo en el momento tenía su aquel, con el uso de unas míticas instrucciones READ, DATA, RESTORE. Pero lo cierto es que tenía muchas de las instrucciones del lenguaje estructurado, aderezadas con otras no tan estructuradas como el inevitable GOTO. Lo peor, en cualquier caso, es que ese BASIC no estaba nada preparado para hacer juegos. Los gráficos se tenían que crear como "caracteres especiales" (GDU se llamaban), y estaban muy limitados.

Pero lo que hacía imposible programar cualquier juego con movimiento estaba muy claro: ¡era insufriblemente lento!. Eso no me paró para hacer otros pocos juegos más durante los siguientes años: Tragaperras, El Halcón Callejero, El Trueno Azul y Súper Racer (a algún tipo curioso le dio por poner todos estos juegos disponibles en World of Spectrum y hasta pedirme permiso, todavía estoy anonadado por ello).

Como a todo el programador casero de la época, el BASIC se me quedó pequeño. El siguiente paso dentro del mundo del Spectrum era el código máquina.

Rastro arriba, Rastro abajo, conseguí comprar todas las revistas Micro-Hobby antiguas que contenían de forma coleccionable un completo curso de código máquina. Uf, esto ya tenía tela. Además, yo no tenía un ensamblador, así que mi método de programación era: 1) Programar en papel, 2) Convertir las instrucciones y los datos en números, pasando muy a menudo normalmente por números binarios y forzando muchas veces el uso de operaciones binarias como OR, AND y XOR, 3) Picar los numerillos del programa en el Spectrum, numerajo a numerajo, mediante DATA.

Con el tiempo, llegué a manejar las potencias de dos y los números binarios en general con una velocidad inusitada. De hecho todavía soy capaz de pasar con bastante rapidez de binario a decimal y viceversa, y de partir un número de 16 bits en sus dos partes de 8 bits, pasando por binario y recodificando.

El caso es que tampoco llegué a hacer grandes cosas con el código máquina. Comencé con una rutina para hacer un "efecto espejo" en los gráficos y ahorrar memoria. Y más tarde hice un conjunto más gordo de rutinas para mover sprites por pantalla y animarlos con varios frames. O sea, programé mi primera librería.

Lamentablemente, aunque llegué a hacer demos con gráficos animados de verdad nunca llegué a concluir mi proyecto. Había acabado una aventura conversacional (otro día hablaré sobre ellas), en la que había utilizado la rutina código máquina de espejo, y mi nuevo proyecto pretendía ser una mezcla de aventura gráfica y conversacional, con gráficos enormes y mucho mucho código máquina. Pero rondaba ya el año 91, los PCs ya eran ordenadores serios, y ya existían juegos impresionantes, y aventuras gráficas potentísimas como el Monkey Island. El Spectrum estaba agonizando. Había llegado tarde.

Ahora, muchos años después, programo en Java. He reemplazado el cuaderno en el que escribía las instrucciones de código máquina por un potente IDE en el que casi no tengo que escribir porque el auto-completar se ocupa de casi todo. Mientras que antes un error en el paso de un número a binario o viceversa daba lugar a un error muy difícil de localizar, ahora cuando me equivoco en algo de sintaxis me lo marca en seguida y hasta me lo puede arreglar él mismo muchas veces. Y mientras que antes un error en la ejecución a menudo llevaba a que el ordenador se quedara colgado y hubiera que rebobinar el cassete hasta el punto en el que estabas antes y volver a cargarlo todo, ahora tengo un potente debugger en el que puedo ejecutar paso a paso y ver el estado en el que están todas las variables en cada momento, y todavía si algo falla me muestra automáticamente el mensaje de error y la traza de ejecución indicándome dónde ha dado el error exactamente. He reemplazado la programación de librerías por el uso de unas que ha hecho un tipo en su casa y que ya te lo dan todo hecho (¡decenas en cada proyecto!). He reemplazado el dibujo de gráficos en hoja de papel de cuadros, codificación de binario a decimal e introducción mediante DATAs, por una búsqueda en Internet para usar una imagen multi-color que otro tipo (o quizá el mismo de antes) ha hecho en su casa. He reemplazado el coleccionable de código máquina de la Micro Hobby por una búsqueda rápida en Internet para buscar cómo se hace cualquier cosa. Y así muchas otras cuestiones.

Comodidad infinita, reutilización en vías de ser sistemática, subida cada vez mayor del nivel de abstracción... y aún se puede mejorar. Todavía se puede programar con más comodidad, todavía se puede hacer reutilización de forma más sistemática, y todavía se puede subir el nivel de abstracción. Y esto es lo que más me apasiona de la programación.

Eso sí, cuando miro atrás y veo las movidas que había que hacer antes para programar cualquier chorradilla y lo accesible y cómodo que está ahora, no puedo evitar pensar ¡bah!, programar ahora... ¡es para nenazas!