Blog de JoseMPelaez

Aprendimiento: aprender del entorno con atrevimiento

Maestros y estructuras

Posted by josempelaez en Viernes, 27 junio 2008

Hace pocos días estuve contrastando opiniones con Luis-tic616 y Rafa en el Diario de un Director de sistemas sobre la interacción entre aplicaciones empresariales. Luis decía:

«Creo que hay que resolver todavía como disponer de estructuras maestras comunes para las transacciones particulares – el caso típico es el de maestro de clientes.»

Para pensar un poco más y tratar de fundamentar las mías he regresado en buena medida al pasado, cuando aún no se hablaba de “aplicativos”. Para el que vaya a leer esta entrada en el blog, aviso de antemano que sólo va a ser la primera parte de mi argumentación.

Enlace entre bloques estructuralesEn 1973, mi padre cambió mi regla de cálculo por una calculadora científica para que ganara agilidad en la resolución de problemas de resistencia de materiales. Gastó unos 4.700€ de hoy (actualizando con el IPC) en una HP45, pero debió de pensar que merecía la pena si yo aprobaba finalmente la materia que amenazaba con retenerme en 2º de carrera. Desarrollé mucha destreza ejecutando algoritmos a mano con la curiosa RPN, y pasé de curso (no sólo gracias a la maquinita, claro).

Pocos meses después, ya en 3º, aprendí a programar procesos de cálculo en Fortran IV en un miniordenador de HP con tarjetas perforadas. Por cierto, recuerdo que, por aquella época, uno de nuestros profesores iba a uno de los famosos cursos de IBM para enterarse de lo que era el time-sharing. El Cobol sólo me sonaba de nombre, y así se quedó poco más o menos. Me dijeron que era para “programas de gestión”, y que nosotros éramos ingenieros. Además de resolver ecuaciones con métodos numéricos, nos adiestrábamos programando juegos, como el clásico del ahorcado, o calculando duraciones de proyecto e identificando caminos críticos en un grafo PERT. La “gestión” era otra cosa, y se aplicaba en la banca, seguros, administración pública….

En la primera mitad de los 80 tuve que utilizar ordenadores IBM en la ingeniería donde trabajaba. Me familiaricé con los lotes (batch processing), el JCL, los ficheros indexados (ISAM) y las bases de datos transaccionales jerárquicas (IMS). El análisis funcional y orgánico de la época me introdujo en los modelos de datos, el distingo entre transaccionales y maestros y en la «arquitectura de información».

De alguna forma reviví las estructuras resistentes y sus «muros maestros». Estas aplicaciones se sustentaban en datos y no en procesos. Los modelos de comportamiento rígido, elástico y plástico resurgieron como agradables recuerdos (me gradué en la especialidad de estructuras). Lo que ahora no veía en este marco era el aislamiento de elementos mediante condiciones de contorno, tan típico de mi querido análisis estructural. En éste, las acciones externas y elementos colindantes se aislaban mediante su representación con campos de fuerzas. Éstas “solicitaban” al elemento resistente, que respondía deformándose (si no se rompía) y reaccionando.

Programando en Fortran descomponíamos los problemas en módulos de flujo que codificábamos en bloques estructurados. También empleábamos muchas funciones y subrutinas, que devolvían resultados (request-response) sin saber cómo estaban programadas aquellas bibliotecas (libraries) de cálculo reutilizables. Era algo que me resultaba familiar.

Ahora ya no programaba, pero en los análisis que hacía —para “lo de la gestión”— echaba de menos los flujogramas que diagramaba antes. En este trabajo lo importante eran los «organigramas de datos», como yo los llamaba. Las relaciones entre elementos del sistema se habían reducido a las de las entidades de información, compuestas por ficheros o tablas de registros que variaban mucho (transacciones) o poco (maestros). Los “cálculos” que había que hacer eran «alta, baja y modificación» y, a todo tirar, teníamos que contar, sumar y dividir para sacar subtotales y medias. El súmmum eran los «totales de totales», también llamados “grandes totales”. Todo aquello, según IBM y Andersen Consulting, por lo menos, recibía el apelativo de Management Information System. ¡Qué curioso y sencillo me resultaba este enfoque, especialmente cuando soy de los que conserva sus viejos y apreciados instrumentos de cálculo (regla deslizante, HP45 y otras tres más, ya programables)!

Me perdí la entrada en la liza comercial de las bases de datos relacionales al cambiarme a la consultoría de dirección y a la gestión de personal. No obstante, recuerdo haber leído cosas sobre las reglas de Codd. Las simplifiqué mentalmente pensando que trataban, básicamente, de aportar flexibilidad, reducción de duplicados y consistencia de datos.

En 1992 escuché hablar por vez primera de la programación orientada a objetos. A mitad de esa década leí sobre el desarrollo basado en componentes: módulos encapsulados, débilmente acoplados y buenas abstracciones. En el “mundo real”, la BD Access de PC se popularizaba reemplazando al DBase III y Clipper en muchas empresas. Los lenguajes de programación 4GL habían hecho furor en las más grandes y pudientes de la mano de los SO Unix, y de la fulgurante expansión comercial de las BD relacionales (Oracle, Ingres, Informix, Sybase…) con sus 4GLs. Aparecieron los entornos RAD con Delphi, PowerBuilder, etc. que fueron cediendo terreno al Visual Basic. Ya en esta década, el auge de la web había catapultado a Java con su plataforma robusta y compleja, se popularizaron los lenguajes dinámicos (scripting) abiertos de internet, entró a competir la arquitectura .NET (un SO y varios lenguajes), y blablabla…

Por hoy lo voy a dejar aquí. Ya está bien de historieta. El próximo día pasaré raudo y veloz sobre flujogramas, organigramas, algoritmos, datos, maestros, profesores, consultores… y llegaré a mi destino, espero. ¿Será la SOA?

[Imagen: Equilibro estructural. Prof. Dr. Dimitris Theodossopoulos de la Universidad de Edimburgo. Ilustra dos sistemas estrucurales de la naturaleza que interactúan mediante un puente. Éste permite los intercambios entre ellos, además de soportarlos.]

2 comentarios to “Maestros y estructuras”

  1. Ostras, esto va a ser un master sobre la historia de los sistemas de información. Vaya pozo de ciencia el tuyo José María.

    Me interesa la reflexión de que el modelo de aplicaciones en esa época se sustentaba sobre el modelo de datos, en contraposición con lo que intuyo que va a venir en los posts siguientes. Esa línea de análisis promete

  2. Jopé, Luis, que dice mi sobrino pequeño. No te “metas” tanto con los viejos (más cerca de 70 que de 40), aunque sea con cariño, que tu tocayo también contribuye a ganar eurocopas.

    ¡Hombre!, ni master ni pozo de ciencia. Si acaso cierta curiosidad, duda y experiencia, unidas a un porrón de recuerdos.

    Hace más de nueve años “sentimos” que los SI no deberían estar centrados en su modelo de datos, enfoque que creo que aún sigue predominando. Ahora me puse a escribir con la idea de tratar de cimentar este supuesto ahondando en mis experiencias. Pero claro, no debemos confundir los casos clínicos con el método científico, que sólo me gradué como ingeniero de estructuras (maestras y aprendices😉.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

 
A %d blogueros les gusta esto: