El Cedazo

En la entrada anterior comenté, entre otras muchas cosas, que a principios de los ochenta se comenzó a utilizar en España de forma sistemática la nueva técnica de Diseño Estructurado de Programas. Esto no quiere decir que fuera inmediatamente adoptada por todas las empresas, no. Las empresas pioneras, el banco donde trabajaba entonces entre ellas, comenzaron a usar Programación Estructurada de forma generalizada (incluso, al cabo de poco tiempo, y visto lo bien que nos fue durante los primeros tiempos, de forma obligatoria). El diseño y codificación de los nuevos programas se hizo más rápido, y con mayor fiabilidad, pero sobre todo se ganó muchísimo en el mantenimiento de los programas a lo largo de los años.

Pero la adopción de la nueva técnica no fue tampoco un camino de rosas. Siempre había algún virguero de la codificación tradicional que era capaz de, GOTO p’arriba, GOTO p’abajo, hacer el mismo programa más rápido y más eficiente que cualquiera, con o sin estructuras. Hubo bastante controversia (no sólo en España) sobre la manera de codificar en los lenguajes de la época (todos ellos  ”procedurales”, desde luego), con o sin GOTOs, con o sin Inicio y Final obligatorio…

Antes de entrar en cómo nos fuimos adaptando al nuevo método de programación, debo obligatoriamente, fiel a mi estilo lenguaraz, describir qué es la Programación Estructurada, y daros unas pinceladas históricas.

 

Ya sabéis que en los cincuentas, sesentas y primeros setentas, los informáticos de la época (en muchos casos, ingenieros metidos a informáticos), programaban sus rutinas como buenamente sabían y podían. Fueron inventando las diversas maneras de programar conforme programaban, con lo que los más avispados (o afortunados, quién sabe) fueron encontrando maneras de solucionar problemas diversos sobre la marcha.

Pero, en definitiva, la forma aceptada de programar era, mayormente, a la “mecagüendiez”, traducción castiza del no menos castizo “cada maestrillo tiene su librillo”.

En una entrada anterior, ya incluí un organigrama añejo copiado literalmente de la pizarra, donde, en Segundo de Carrera, un profesor explicaba el método para actualizar ficheros indexados.

En una palabra, en los primeros setenta, ésa era toda la cera que ardía…

Claro que, si nos damos cuenta, el problema no era todavía excesivamente importante: Había pocos ordenadores funcionando, y no había muchos programas en Producción, y, sobre todo, éstos eran muy pequeños. No había otro remedio, con 8, 16 ó 32Kb de memoria, no se podían hacer programas muy complejos, simplemente porque no cabían.

…Y sin embargo, alguien estaba ya dándose cuenta de que esa no era la manera correcta de programar de cara al futuro. Cuando el uso de las máquinas se fuera generalizando, éstas fueran cada vez más y más potentes, y más y más programadores se fueran incorporando a la profesión, los programas spaghetti no serían adecuados, debido no sólo a la dificultad de diseñarlos, programarlos y probarlos, sino sobre todo, de mantenerlos.

Conforme más y más aplicaciones se ponían en marcha, más y más aplicaciones había que mantener, modificar, cambiar… y la programación “personal” constituía un problema serio, sobre todo cuando el autor original del engendro, eeeh, digo, del programa, ya no estaba en la empresa para desentrañar lo que ahí dentro había (…y a veces, ni así).

En 1966, Bohm y Jacopini publicaron un artículo en el que demostraron formalmente que, usando exclusivamente tres estructuras de control era posible programar cualquier función computable. Las tres estructuras eran, claro está, la secuencial, la repetitiva y la alternativa. Combinándolas recursivamente es factible realizar cualquier programa.

Una Secuencia consiste en una serie de elementos que ocurren secuencialmente, uno detrás de otro, y siempre en el mismo orden. Esta serie de elementos podría estar vacía, es decir, no contener elemento alguno.

Una Repetición (o iteración) consiste en un único elemento que se repite una y otra vez, o ninguna, hasta que cierta condición sea satisfecha. O lo que es lo mismo, de 0 a n veces, mientras se satisfaga una cierta condición.

Una alternativa (o selección) consiste en dos elementos, de los que sólo ocurre uno u otro, dependiendo de cierta condición. Aunque en principio se definen sólo dos elementos para definir la selección, no hay ningún problema en permitir más de dos ramas, siempre que sólo ocurra una de ellas, dependiendo siempre de dicha condición (en realidad es el resultado de des-anidar varias selecciones anidadas).

No obstante su importancia para la ciencia de la computación, el artículo de Bohm y Jacopini fue poco menos que ignorado, ya que ellos se limitaron a demostrar matemáticamente que esto era así (lo que hoy en día se conoce como Teorema de Bohm y Jacopini), pero no rompieron lanza alguna para defender que programar en base al uso de las tres estructuras fuera bueno y recomendable. Y todo el mundo siguió a su bola…

Hasta que uno de los científicos de la computación más reputados de entonces, y de todos los tiempos, el holandés Edsger W. Dijkstra publicó en 1968 su famoso artículo “Go To Statement Considered Harmful”, en el que cargó con armas y bagajes contra el uso (y el abuso) de la sentencia de bifurcación, abogando fuertemente por el uso exclusivo de las tres sentencias básicas.

La (reducida) comunidad informática de entonces aceptó bien, en general, la recomendación del maestro, pero seguía habiendo dificultades: todo esto está muy bien, pero, ante una necesidad determinada, cuando hay que resolver un problema concreto, ¿cómo diseñamos y codificamos el programa usando exclusivamente las tres estructuras?; en definitiva, ¿cuál debe ser el método a seguir?

Por tanto, no fue hasta que se comenzaron a formalizar métodos de Diseño Estructurado de Programas que se comenzó a considerar en serio la posibilidad de utilizar la técnica en el mundo real.

Y el primero que realizó esta necesaria formalización fue el ingeniero francés Jean Dominique Warnier, a la sazón trabajando en Bull, que publicó en 1972 su libro “Logique de Construction de Programmes”.

Proporcionaba, por primera vez, un método sencillo y potente para diseñar un programa usando sólo las tres estructuras, utilizando llaves (estas llaves: “{“ ) que permitían definir el nivel siguiente, que a su vez se descomponía en otros, usando más llaves…

Se fijaba en los datos que tenía que tratar el programa para obtener la estructura correcta de tratamiento. Y obligaba siempre a especificar que cada bloque lógico tuviera un principio y un fin, aunque no hubiera nada que hacer allí, y estuvieran vacíos. Esto último, por muy completo que fuese, que lo es, fue lo que menos gustó al informático de calle, como podéis suponer.

 

El resultado de diseñar un programa con su método era como el que veis aquí al ladito, pintado a mano, naturalmente, que era como se hacían las cosas entonces.

Indudablemente, representó un gran avance. Mi primer contacto con esta nueva Programación Estructurada fue en Tercero de Carrera, donde en una asignatura de nombre “Metodología de la Programación”, el profesor dedicó un par de días o tres, no más, a explicar el método Warnier (por si os lo preguntáis, el resto de la asignatura versaba sobre el manejo de tablas, listas, árboles, y su representación, como la Polaca y la Polaca inversa, y su tratamiento en algoritmos: ordenación, búsquedas dicotómicas y hash, LIFOs –Pilas- y FIFOs –Colas-, etc; era una asignatura divertidísima).

En España, Bull tradujo del francés y publicó el libro de Warnier con el nombre de “La Programación Lógica”, libro que yo tenía, que presté… y que no he vuelto a ver. En fin.

La publicación de este método no tuvo, sin embargo, la repercusión que hubiera debido, por dos causas: primero, no se centraba en ningún lenguaje concreto, es decir, no daba instrucciones concretas sobre cómo llevar a la práctica sus predicados en Fortran, o Cobol, Assembler o lo que fuera. Y segunda, ¡era una cosa “not invented here” ! Como era obra de un francés, y publicada originalmente en francés, el mundo anglosajón no entró mucho al trapo… Entonces, igual que ahora, la informática se escribía en inglés, en inglés americano, para más señas. Y Jean Dominique Warnier era francés, había cometido la tropelía de publicar originalmente en francés… y para colmo, trabajaba en Bull, una empresa francesa.

No fue hasta que Ken Orr, a principios de los ochenta, publicó su método, muy similar al de (o basado en el de) Warnier, denominado Warnier-Orr en la literatura, que el mundo anglosajón descubrió a Warnier… ¡y cómo!, puesto que fue adoptado por una de las Metodologías importantes de Desarrollo de mediados y finales de los 80: Method/1, de Arthur Andersen (que aún no se había convertido en Andersen Consulting, ni mucho menos en Accenture).

Me encantaba Method/1: Como cuarenta o cincuenta o más, no me acuerdo, volúmenes de ochocientas o mil páginas cada uno… que nadie leyó nunca, claro, más allá de algún resumen. Pero especificaba todo, todo, todo lo que había que hacer, de qué manera documentar, quién debía firmar, etc, para asegurar que… para asegurar que… eeh…

…Bueno, en teoría para asegurar que el proyecto se ejecutaba conforme a especificaciones, tiempo y coste (cosa que nunca pasaba), así que en realidad lo que aseguraba era que… en caso de que el proyecto se fuera al garete, tú, pobre director del proyecto, tuvieras la espalda cubierta, mayormente. Pero esa es otra historia, y será contada en otro momento.

Gracias a Orr se arregló la segunda de las causas antes citadas (el idioma y el “not invented here”); en cuanto a la primera de ellas (la falta de normas específicas de codificación) la solventó en 1974 Marie Thérèse Bertini, cuando publicó, junto a Yves Tabourier como coautor, “Le Cobol Structuré” (en francés, claro está). Apenas se encuentra nada en la red para refrescarme la memoria, así que recurriré exclusivamente a ella.

Básicamente el “método Bertini” derivaba del de Warnier, ambos de origen francés, y creo recordar que colegas en Bull durante una temporada: una vez conseguido el diagrama todo lleno de llaves, Bertini lo que preconizaba era, aproximadamente, reescribir la estructura del programa, pero ahora con “cerezas” (es decir, circulitos) para cada bloque lógico, conectados con líneas, pero ahora la jerarquía no era de izquierda a derecha, como ocurría con la técnica de Warnier, sino de arriba abajo, lo que resultaba más natural.

Sin embargo, supongo que para mantener algún tipo de compatibilidad con las llavecitas, inexplicablemente se empeñó en que los niveles se codificaran de derecha a izquierda, y no de la forma natural para los occidentales, de izquierda a derecha. Aunque, si he de ser sincero, siempre que he visto un diagrama de Bertini, estaba escrito de izquierda a derecha, dijera el libro lo que dijera…

Pero lo importante fueron sus normas para codificar la cosa resultante en Cobol (y sólo en Cobol; no publicó nada, que yo sepa, para ningún otro lenguaje). No eran muy complicadas, y básicamente se centraban en tres aspectos:

Por un lado, la obligatoriedad de codificar los inicios y finales de cada bloque (mediante un PERFORM INICIO-TAL-COSA y PERFORM FIN-TAL-COSA, respectivamente), incluso aunque alguno estuviera vacío (porque no hubiera nada que hacer allí), en cuyo caso llevarían sólo la instrucción EXIT, que no es tal instrucción, como imaginaréis, pues sólo sirve para que un párrafo vacío no esté… vacío.

Por otro, la prohibición de codificar PERFORM .. THRU … Esto forzaba a que para codificar una alternativa, hubiera que hacerlo así: IF tal y tal  PERFORM FULANO  ELSE  PERFORM MENGANO. Por tanto, generaba una gran profusión de procesos anidados en cascada.

Y por fin, la prohibición total y absoluta para siempre jamás de usar el GOTO.

La verdad es que yo nunca fui bertiniano practicante, aunque sí me leí en su día lo que cayó en mis manos… ventajas de haber aprobado cuatro años de francés en el Instituto. O sea, que treinta años después no estoy seguro al 100% de si las tres reglas eran exactamente así, o me falta o sobra alguna: Si algún lector bondadoso es o fue bertiniano y detecta algún error, por favor que me lo comunique y lo corrijo de inmediato.

El método tuvo un cierto éxito, y se enseñó bastante en centros de formación durante unos años. Pero no era perfecto. Bien está que se prohíban los GOTOs indiscriminados, pero es que, si quieres usar toda la potencia del Cobol, en ciertos casos es obligatorio usar GOTOs. Por ejemplo, si codificas con más de una sección, lo que es bueno y recomendable por claridad, necesitas en todas ellas menos la principal dirigirte al final físico de la sección para poder devolver el control al proceso llamador. Y no se me ocurre otra forma de hacerlo que con un GOTO. Es decir, usar Bertini implicaba codificar todo el programa en una sola sección, y cuando tienes dos o tres mil líneas de código en la PROCEDURE DIVISION… no es exactamente una buena idea.

Además, existían ya en la época ciertos problemas que no habían recibido atención por parte de ninguno de aquéllos incipientes metodólogos.

Hasta que, en 1975, el científico de la computación inglés Michael A. Jackson (que, que yo sepa, además de ser blanco durante toda su vida, canta y baila fatal), publicó su “Principles of Program Design”.  Y el tema se solucionó. Literalmente. Definitivamente. Ya no se volvió a publicar ningún otro método general de Diseño Estructurado de Programas, pues no había mucho más que añadir.

Resolvió tanto el procedimiento formal de diseño, dotándole de una lógica aplastante, como esos “casos especiales” que molestaban a los otros métodos de diseño estructurado. Y además, preconizaba una forma de codificar en los lenguajes más importantes de la época, significativamente Cobol, Fortran y PL/1.

…Después del rollo que os llevo soltado, ¡no me quedo con las ganas de citar brevemente cómo es el Método de Jackson!, que por algo es mi preferido, además del más completo. Espero sepáis perdonarme…

Lo más impactante del método es que todo el diseño de la estructura del programa se basa en lo único que es completamente conocido, fijo y seguro: los datos. Efectivamente, todo programa que se precie (y que sirva para algo) debe leer y escribir ciertos datos, que estarán en cualquier tipo de soporte, y que tendrán una estructura determinada, conocida y fija (si no es así, malamente vamos a poder programar nada). Y a partir de la estructura intrínseca de los datos, va siguiendo unos pasos concretos y muy bien definidos que terminan con el programa codificado en pseudocódigo, o directamente en el lenguaje que sea.

La idea es que, dado un problema determinado que se aplica sobre ciertos datos conocidos, sólo haya una solución posible. Como supongo suponéis, esto no es exactamente así… pero hay que reconocer que se parece mucho.

La notación que utiliza para representar las tres estructuras famosas es arborescente, y bastante intuitiva:

 
Cada bloque individual puede estar a su vez descompuesto en cualquier otro tipo de estructura, lo que permite crear árboles tan grandes como deseemos. Y con esta notación se pueden representar tanto datos como programas. Veamos sucintamente el método, que preconiza cinco pasos secuenciales (en la página de la Wikipedia inglesa dedicada al JSP hay un ejemplo de los diagramas de cada uno de los pasos; así, si os interesa, podéis seguirlo con algún ejemplo, porque no lo voy a repetir aquí).

1 Establecer la Estructura de los Datos. De todos los datos, por separado, tanto los de entrada como los de salida.

2 Establecer las Correspondencias entre Datos. Para que haya correspondencia entre dos entidades de dos conjuntos de datos, sean de entrada o de salida, debe darse que: a) Ambas tengan el mismo número de elementos, y b) Éstos estén en el mismo orden en ambas entidades, o sea, ordenados de la misma forma.

Hasta aquí, fácil, ¿no?

3 Crear la Estructura del Programa. Para ello, cada entidad con correspondencias da origen a una única entidad, del mismo tipo, en la estructura final del programa, y el resto se insertarán en su lugar correspondiente, sin cambiarles de naturaleza. Como en este paso tratamos ya con procesos y no con datos, el propio nombre de las entidades cambia. La entidad de datos “CUENTA”, por ejemplo, pasará a llamarse ahora “PROCESAR CUENTA”. Aquí al lado tenéis un pequeño ejemplo de cómo estamos hasta este paso.

Tampoco esto es muy difícil…

4 Listar y asignar las operaciones individuales. Jackson propone un checklist de operaciones, que debe cumplimentarse en orden, para que no se olvide nada:

a) Instrucciones de finalización del programa.

b) Instrucciones de cierre de ficheros.

c) Instrucciones de apertura de ficheros.

d) Instrucciones de escritura en ficheros.

e) Instrucciones de lectura de Ficheros.

f) Instrucciones de movimiento de campos, entre ellos los de claves de ruptura.

g) Instrucciones de cálculo.

Una vez obtenida la lista, se asignan por riguroso orden las instrucciones a la estructura. ¿Dónde? Siempre en secuencia, y en aquél lugar donde la instrucción se ejecute una y sólo una vez, teniendo en cuenta las operaciones ya asignadas, para situarla antes o después de ellas. Siguiendo el orden preconizado en el checklist, es fácil determinar el lugar exacto donde asignar cada instrucción. ¿Cómo? Con un círculo (otra cereza, vaya), dentro del cuál se inserta el número ó código de la instrucción en la lista.

Sencillo ¿no?

El Resultado sería algo como el siguiente gráfico (bueno, normalmente, bastante más complicado), en el que el autor ha sustituido los circulitos para representar las instrucciones (las cerezas) por cuadrados, por razones tipográficas (supongo).

5 Generar el pseudocódigo. Muy fashion en esa época, pero nadie escribía ya el pseudocódigo, sino directamente el programa. Tiempo que se ahorra uno… Para ello, Jackson propuso un sistema de codificación de sus estructuras en los lenguajes más usados del momento, sobre todo Cobol, Fortran y PL/1.

¡Hala! Ya tenemos el programa escrito. Un auténtico chollo. Sencillo, rápido, bien definido… Además, catorce programadores diferentes a cuál más raro, obtendrán la misma estructura, puesto que los datos son como son, están perfectamente definidos, y todo lo demás se deriva de ellos… Más o menos… O así…

Además, Jackson, en su libro de 1975, resolvió una serie de problemas que se plantean habitualmente en computación. Entre ellos, preconizó la lectura adelantada (eso, ahora obvio, de leer el primer registro de cada fichero nada más abrirlo, lo formalizó él), incluso la doble o triple lectura adelantada, cuando sean precisas; y sistematizó el procedimiento para mezclar dos o más ficheros por clave (¡otra vez el Padre-Hijo a escena!). Pero además, formalizó la solución a otra serie de problemas habituales:

a) El backtracking. En esta estructura especial se trata un conjunto de datos como si lo que hiciéramos fuera a valer, pero permitiendo cambiar de opinión cuando detectamos que nos hemos equivocado. Puede parecer algo poco útil, pero es que exactamente eso es lo que pasa en las transacciones online: Hay que validar, en primer lugar, que todos los campos de entrada son correctos y la acción demandada es factible; sólo cuando se ha verificado que todo es correcto, se procede a realizar las actualizaciones pertinentes. La validación puede resultar bastante complicada, accediendo a diferentes Bases de Datos, etc. Además, en cuanto se detecta un error, se informa del mismo al peticionario, y se termina el proceso de la transacción: no tiene sentido seguir validando y gastando ciclos de CPU cuando ya sabes que la transacción es errónea.

Diseñar este caso sin backtracking es… es un tostonazo, con ramas de alternativas bajo ramas de alternativas bajo ramas de alternativas… Un tostón; y sin embargo usar un backtracking resuelve el tema de forma elegante y sencilla, como podemos observar en el ejemplo siguiente.

b) La Programación Invertida. (¡y no valen chistes, que bastantes hacíamos ya nosotros entonces…!), que resuelve el problema de la colisión de estructuras (es decir, cuando no es posible encontrar correspondencias entre una entidad de la estructura de datos de entrada y otra entidad en la de salida). La solución obvia es dividir el programa en dos, mucho más sencillos, usando un fichero intermedio…

Pero este fichero intermedio rara vez queremos (o podemos permitir) que exista físicamente. Debe ser un fichero virtual. Lo que sistematiza el método de Jackson es un procedimiento para eliminar físicamente ese fichero intermedio, pero que sigue existiendo lógicamente, es decir, sin cambiar en nada ni la estructura ni la codificación de ambos programas. Se consigue “invirtiendo” uno de los dos programas respecto del otro, es decir, convirtiendo uno de los dos programas en una rutina de entrada (o de salida) del otro, y comunicándose exclusivamente ente sí con el registro del fichero intermedio, que comparten ambos programas.

Supongamos que hemos decidido convertir al primer programa P1 en rutina invertida de entrada del segundo, P2, que queda en este caso como el principal. En este último poco hay que hacer: cada vez que en él se lee el fichero intermedio, se sustituye por una simple llamada a P1 (y se eliminan Open y Close, obviamente). Únicamente hay que tener en cuenta cómo comunicar el fin del fichero: la solución obvia es pasar el registro con una marca (en Cobol, típicamente, HIGH-VALUES, es decir, “FF’s” hexadecimales).

Pero, en el otro lado, para el programa P1, el P2 es su propia rutina de salida… Así que, cada vez que en este programa P1 se debe escribir el registro del fichero intermedio, lo que ahora debe hacer es devolver el control a su llamador (P2) que se encargará de “escribir” el registro, y volverá a llamar a P1 cuando necesite un nuevo registro… e informándole, de paso, de que su registro ha sido escrito, y que puede seguir su proceso por donde iba.

En una palabra, ambos programas se ejecutan simultáneamente, en una especie de columpio, cediéndose mutuamente el control de la ejecución, y comunicándose exclusivamente mediante el área del registro del fichero intermedio.

Es una solución de una elegancia suprema, y una potencia inigualable. Además, no está restringida exclusivamente a procesos batch. Puede utilizarse también (yo lo he hecho en bastantes ocasiones) en la resolución de transacciones online. Y sin embargo, siempre ha sido muy poco utilizada, no por la dificultad de entender el mecanismo, que es realmente sencillo, sino por la aparente dificultad de codificar la inversión en el programa invertido, pues supone usar GOTOs extraños, incluso GOTOs condicionales (GO TO DEPENDING ON) que casi nadie quiere utilizar, porque dan yuyu… y se pierden una de las técnicas más poderosas de programación jamás inventada.

.

Bien, terminado el paseo por el Método de Jackson de Estructuración de Programas, desde entonces prácticamente no se ha avanzado más en la teoría, porque todo había quedado establecido. Jackson hizo un trabajo formidable, y realmente no dejó mucho más que rascar.

Y fue entonces, principios de los ochenta, cuando nos pusimos en España a utilizar técnicas de Programación Estructurada en empresas e instituciones. Pero antes de eso, hubo que dar a conocer la nueva técnica a los responsables de Informática, para convencerlos de que era mejor para sus negocios adoptarla.

Como podéis imaginar, en aquellos años los responsables de Proceso de Datos no estaban demasiado al tanto de las novedades que se producían en la profesión, primero por su origen (casi ninguno era informático de profesión, sino que provenían de puestos administrativos, y su formación era en otras áreas, quien la tenía, porque, por ejemplo, uno de los Directores de Informática que yo conocí comenzó su carrera en el Banco como botones, lo que dice mucho en favor de su capacidad), y luego, por el dichoso inglés. Apenas se hacían salidas a Conferencias el Extranjero, y no se leían muchas revistas especializadas americanas o inglesas, que además de ser incomprensibles (por el idioma) eran caras… pero caras.

Por lo tanto, el trabajo de promoción le correspondió a las Consultoras y/o Empresas de Formación, que vieron en esta nueva técnica una vía de incrementar su negocio, así que promocionaron intensamente su propagación.

Ninguna entidad se adhirió al asunto de inmediato, pero ciertamente muchas comenzaron a hacer sus pinitos, sus pruebas para ver si la cosa de verdad funcionaba (y mejoraba la productividad de la programación) o era un canto más de sirenas, de los que de tanto en cuando aparecen aquí y allá. Así que enviaron a recibir formación en las nuevas técnicas a uno, o dos, quizá cuatro programadores “escogidos” (escogidos por las razones que fueran), en cursos abiertos que duraban tres o cuatro días. Yo fui uno de esos elegidos, a finales de los setenta, en el primer Banco en el que estuve.

Estos pocos programadores, al volver a su instalación, comenzaban a utilizar la nueva técnica, sobre todo por curiosidad, inicialmente de forma balbuceante, pero poco a poco con mayor convicción. Hablo por mí, y también por otros colegas de otras instalaciones, pues la Programación Estructurada era un tema caliente de las conversaciones entre colegas de la época.

Hicimos nuestros pequeños pinitos, sí, pero no conseguíamos convencer a nuestros mayores de que fuera conveniente la adopción generalizada de la técnica, entre otras cosas, porque éramos simples programadores… o sea, unos mindundis.

Y de pronto, algo ocurría: ante la necesidad que acontecía de vez en cuando de escribir un programa complicadísimo de resolver (de esos a los que nadie se atrevía a hincarle el diente), entonces te lo encargaban para que lo escribieras de forma estructurada, con la coletilla de “Hala (listillo: esto lo pensaban pero no lo decían), a ver si eres capaz de resolver este embolado con esa cosa rara nueva…”, y todo esto con una aviesa sonrisilla de diablillo que te llegaba hasta el hígado…

…Y entonces el avispado programador, tocado en su amor propio, se ponía a diseñar y codificar el maldito programa… y resulta que, sorprendentemente, en mucho menos tiempo del que se suponía, el programa estaba listo, y encima funcionaba bien rápidamente (no, a la primera, no, que a la primera no funciona nunca nada…), y además no se eternizaba en máquina… Y entonces era cuando las fuerzas vivas comenzaban a darse cuenta de la potencia del asunto, y a tomárselo en serio.

Por lo que yo sé, procesos similares fueron ocurriendo poco a poco en diferentes Centros de Cálculo, conforme las historias de éxito iban siendo conocidas, y además, aunque las entidades (los Bancos, por ejemplo) fueran competencia unas de otras, entre los informáticos de entonces había una sana camaradería, por lo que unos íbamos contando a los otros nuestras experiencias, ayudando a desechar lo que no había funcionado y a extender lo que sí. Así que, a lo largo de la primera mitad de los ochenta, las empresas se fueron convenciendo gradualmente de la bondad de la Programación Estructurada, y sobre 1983-84 ya todos los Centros de Proceso de Datos importantes habían adoptado la técnica.

Y se prepararon Planes de Formación para reciclar a los profesionales más antiguos (en algunos casos se contrataron empresas de formación, en otros se utilizaron recursos internos, depende de lo tacaña que fuera la empresa), y todo el mundo fue convertido a la nueva religión estructurada. Aunque no todas las conversiones fueron completas, pues seguía habiendo adoradores de los antiguos dioses del GOTO que, siempre que podían, elevaban una ofrenda a su dios ancestral…

Muchos adoptaron el Método de Bertini, quizá no en su forma completa, pero sí al menos su principal mandamiento: “El que ponga un GOTO, ¡al infierno de cabeza!”. Una norma sencilla de entender por todo el mundo. No es ni mucho menos tan completa y eficaz como el Método de Jackson, pero obligaba necesariamente a codificar de forma estructurada, así que muchas consultoras y empresas de Servicios adoptaron el Método, pues ahorraba costes de formación a su personal, y les permitía ser productivos lo antes posible.

Otras empresas (aunque no tantas) adoptaron el Método de Jackson; la posibilidad de usar backtracking, sobre todo en un entorno transaccional, facilitaba enormemente la codificación de las validaciones, y la programación invertida resolvía algunos problemas muy molestos. Vale, Jackson permite usar GOTOs (no cualquier GOTO, desde luego, sino en ciertos sitios y lugares, y siempre “hacia abajo” nunca “hacia arriba”, según se explica en su libro original, el mítico “Principles of Program Design”). Y el uso de GOTOs no gustaba a algunos (muchos de ellos, desertores del spaghetti, pero en fin). Los buenos resultados que se obtuvieron eliminaron casi todas las reticencias en no mucho tiempo.

En el mundo Jackson, todo el mundo hacía el “mono”, o sea, la estructura del programa con las instrucciones asignadas, a partir del cuál se codificaba. Aparecieron diversos precompiladores y programas, entre ellos JSP-COBOL del propio Jackson, que ayudaban al diseño y codificación de programas escritos según este método. Pero ninguno tuvo mucho éxito entonces, al menos en España, por una razón evidente: ¡No había PC’s! Y los pocos que había, carísimos y con muy poca potencia, se dedicaban a otros menesteres, no para que un vulgar programador pintara su “mono”.

Una pena.  Si hubiéramos dispuesto entonces de las facilidades que hubo sólo cinco, seis o siete años después, cuando se generalizó el uso de PC’s en Proceso de Datos, seguramente otro gallo hubiera cantado. Pero las cosas fueron así. Porque ahora, cuando sí es posible fácilmente preparar un programa para, visualmente, diseñar y codificar el programa estructurado… no hay interés. Aquí tenéis un programita freeware que permite diseñar programas usando el Método de Jackson y generar luego el código en C o Pascal. Lo he probado en Firefox y aparentemente funciona bien y es muy intuitivo, pero en IE me ha dado un error de “Java Unsupported Version y tal pascual”, aunque quizá sea culpa de mi anticuada versión de IE.

Bien, entonces, a falta de precompiladores o productos que ayudaran en el diseño y codificación, los “monos” (los de Bertini o los de Jackson) se hacían a mano, y los programas se codificaban conforme a las prescripciones del método correspondiente… y a las manías y querencias del programador de turno.

Por eso las empresas (las instituciones de la Administración Pública también, pero más tarde, y menos) empezaron a emitir normas de programación, en las que se especificaba qué método de diseño se debía utilizar, y, lo más importante, cómo codificar el programa resultante. Tanto Bertini como Jackson proponían un método de codificación en Cobol (el lenguaje más usado con mucho en la época), así que en muchos casos se adaptó la normativa a lo que decían ambos métodos, aunque en otros se usaron normas diferentes, o una sana mezcla entre ambas posibilidades.

Además de prohibir los GOTOs (o restringirlos a los usos especificados en el método de Jackson), y especificar cómo codificar Secuencias, Alternativas y Repeticiones (y Backtrackings y tal, en su caso), se dieron normas de nomenclatura, sobre cómo llamar a los procesos y campos de los programas, así como a los ficheros, impresos, bases de datos, y a los propios programas en sí.

Todo este esfuerzo normativo fue muy importante: en unos momentos de enorme actividad (muchas empresas estaban construyendo Sistemas de Información nuevos, de los que una parte considerable permanecen hoy en día), asegurar una serie de criterios unificados de nomenclatura y codificación redundó en una mucha mayor facilidad de mantenimiento posterior.

En el artículo dedicado al Cobol cité el hecho de que programas escritos hace veinte o veinticinco años sigan funcionando, tras años de modificaciones, y que sigan siendo mantenibles. El uso de toda esta batería de normas rígidas a lo largo del tiempo ha facilitado, si no directamente permitido, que esto sea posible.

Muchas empresas no sólo se quedaron en la publicación de las normas y la obligación, más o menos “moral”, de su uso: escribieron programas que verificaban que los programas que se ponían en Producción cumplían escrupulosamente la normativa, y si no… en general impiden su puesta en Producción; pero en otras, se limitan a informar al autor para que se arregle el desaguisado, pero se permite su uso, de momento (esto es así para facilitar el arreglo de un programa malvado a las tres de la mañana…).

Tomar una u otra opción depende de la instalación, ambas son en principio válidas. Pero lo que sí es cierto es que, una vez que un programa está en Producción, y si funciona como es debido, nadie lo va a tocar motu propio sólo para arreglar su adecuación a las normas, con la cantidad de trabajo que hay que hacer… Por eso es lo generalmente preferido que el Portero del Cotarro no permita el uso en Producción del programa, hasta que esté convenientemente arreglado y quede de acuerdo a toda la normativa de codificación y nomenclatura de la empresa.

…Y claro, dada una norma, siempre hay quien se rompe la cabeza… para romperla. Parece que es una de las características del carácter de los españoles es saltarse, por puro placer, las normas establecidas, sólo por el hecho de hacerlo (ignoro si por ahí fuera esto ocurre también, aunque sospecho que mucho menos que acá). Y fuimos capaces de saltarnos las normas, ya lo creo. Por puro deporte, además, sin ningún ánimo de ser perniciosos.

Cuando no había programas que comprobaban el cumplimiento de las normas, era muy fácil: bastaba con inventarse un caso donde con un par de GOTOs se evitaba una estructura compleja… así que ya teníamos nuestra coartada. Pero cuando se implantaron los programas de control, ya no era tan fácil… y sin embargo lo conseguíamos.

Por ejemplo, para meter un GOTO y que se lo tragara el Portero, poníamos la G en la columna 72 de una línea, y en la siguiente línea poníamos un guión en la columna 7 (en Cobol esto significa que es una línea de continuación, y debe añadir su contenido al de la línea anterior: se usa sobre todo para literales largos), y después la O en la columna 12. El compilador recomponía el GO de ambas líneas y lo interpretaba sin problemas… ¡pero el programador del programa de verificación no había pensado que un verbo GO no estuviera en una sola línea! (Normal, ¿a quién se le ocurre, si no es para fastidiar…?). Y así engañábamos al sistema… que en definitiva era engañar a nuestros propios compañeros, o sea, a nosotros mismos… pero así nos lo pasábamos bien. En descargo mío, debo confesar que, las poquísimas veces que lo hice, luego lo arreglé en la siguiente modificación… pero hubo quien no.

Y así, años más tarde, somos quienes somos, estamos donde estamos y hacemos lo que hacemos… porque venimos de donde venimos.

¿Se usa actualmente la Programación Estructurada? Pues sí. Más o menos. Nadie pone GOTOs (que definitivamente son considerados por todo el mundo “harmful”, como Dijkstra decía en su día, cuarenta años ha). Pero se trata de una programación estructurada “intuitiva”, poco apoyada en fundamentos teóricos… porque no se enseñan, que yo sepa.

¿Se usan los métodos de diseño estructurado de programas? Pues no creo, al menos tal como fueron definidos. Hace años que no veo a ningún programador pintar un “mono” de ningún tipo. Las pocas veces que Yo hago uno, me miran como si viniera de Marte… Quizá porque ahora son mucho más inteligentes que nosotros lo éramos y no lo necesitan. Porque nosotros… nosotros sí que lo necesitábamos.

¿Es conveniente que se enseñen estos métodos? Bajo mi modestísimo punto de vista, desde luego que sí. Es más, cuando alguien comienza a estudiar informática, ESO sería lo primero que yo le enseñaría, y se lo grabaría a fuego para que no se le olvide nunca. Porque sigue siendo útil; más que útil, necesario. Por mucho que el paradigma de Orientación a Objetos haya cambiado la forma de concebir y diseñar las Aplicaciones, cada proceso que se debe realizar, lo queramos o no, sigue siendo un proceso susceptible de ser estructurado. Sobre todo si es un proceso complejo, que debe acceder a Bases de Datos, validar una serie de campos, generar una respuesta…

Y del batch, ya, ni hablamos. Porque sigue haciendo falta ejecutar procesos batch. Y ahí sí que no hay excusa. Y se ve cada cosa por ahí codificada… yo me he encontrado con barbaridades como para erizarte el cabello de la peluca. Sin ir más lejos, y esto es un caso real, acceder a la Base de Datos de Cuentas una vez por cada movimiento de la Cuenta, en lugar de una vez por cada Cuenta. Y eso es, ni más ni menos, que por no asignar correctamente la instrucción de lectura (la SELECT cuenta… FROM TABLA-CUENTAS WHERE …) en su lugar correspondiente de la estructura. Y eso es, a su vez, por no saber. Ni más ni menos. Y el programa funcionaba perfectamente, claro que sí. Utilizando ocho o diez veces más de los recursos necesarios. Y lo peor es que, cuando avisas al programador (amablemente, lo juro) para que modifique el programa, porque está mal parido y consume muchos recursos, ¡encima se mosquea!, que esto… esto es lo que menos entiendo.

Bueno, como de costumbre me he extendido más de la cuenta. Y como de costumbre solicito vuestra indulgencia para que perdonéis la incontinencia, de momento sólo verbal, de este pobre informático pasado de moda… Y, por supuesto, todos vuestros comentarios y sugerencias serán bien recibidos.

El próximo episodio no va mucho de batallitas. Éstas volverán en el que le siga, pero el próximo lo dedicaré a contaros qué es eso del “Sort”, que tantas veces aparece en mis notas, y que tantos quebraderos de cabeza nos ha dado a los informáticos desde hace tantos años… si sorprendentemente todavía estáis ahí para leerme, y el Gran Jefe Pedro aún me consiente que siga dando el tostón al personal…

Disfrutad de la vida, mientras podáis.