En los actuales tiempos en que las empresas cuentan con multitud de sistemas heterogéneos que integrar, además de con un gran número de requerimientos de usuarios que satisfacer, la desaforada profusión de técnicas, métodos y herramientas software sólo procura bien problemas adicionales de integración bien la sujeción inamovible a un particular esquema tecnológico. Esto es particularmente cierto en las grandes empresas y corporaciones, que además desean “Zero Administration Clients” y personalización extrema de contenidos. Esta situación –pese a la presión comercial de plataformas tecnológicas como Java, o estándares de facto como MS Windows- sitúa a las empresas en la difícil tesitura de basar sus sistemas de información –ya ineludiblemente imbricados en sus líneas productivas- ora en productos monolíticos (SAP, etc.), ora en prolijas tecnologías de confuso o, al menos, incierto asentamiento (Java, CORBA, DNA, etc.). La lógica cuestión aquí es: ¿por qué plegarse a un esquema en que la naturaleza de la pregunta condiciona la respuesta? Esto es, ¿por qué no formular una pregunta distinta? ¿Cuánto cuesta sobrepasar la costumbre, el vicio de ajustarse a lo disponible? ¿Por qué no cambiar las reglas y así, de paso, variar el resultado? Veamos el por qué y el porque.

SOBRE LA NAVEGACIÓN Y LOS HUNDIMIENTOS

Recientemente tuve la ocasión de revisar –en prepublicación- un artículo sobre la medición de la percepción, por parte del usuario, del “sentido” o significado de los iconos de navegación por interfaces gráficos de usuario. Es decir, hasta qué punto son intuitivamente inteligibles para un usuario no avisado los grafismos, paradigmas y –mayormente- bobadas generalistas de un frontal gráfico: un botón de edición representado por una pluma sobre un papel, una acción de creación de un documento nuevo significada por una pequeña hoja en blanco con un borde doblado, etc. El enfoque del artículo era –es- claro: inventamos un modus-operandi, un universo artificial, y luego medimos la adaptabilidad del usuario al mismo. Exactamente lo mismo que ocurre con el diseño software. Exactamente el mismo problema. Y es que, si podemos coincidir en que se dan –o van a dar- una serie nucleica de conceptos en una aplicación, ¿por qué nos empeñamos, a la vez, en dotarlos de una imagen ora ligada a variaciones de normalizaciones multitudinarias (MS Windows, paquetes ofimáticos, etc.), ora reflejo de nuestras personales fobias y carencias/excesos educativos? Esto es: ¿por qué no dejar que el usuario decida sobre la representación de conceptos y, en todo caso, podamos únicamente permitirnos aconsejarle sobre algunas correspondencias? Es decir: en lugar de obligar al usuario a aceptar nuestro psicótico diccionario de conceptos-imágenes, por qué no decirle simplemente:

“He aquí los conceptos que son necesarios para esta aplicación (adelante, atrás, cancelar, etc.). Detecto que usted ya tiene asociados grafismos a algunos de ellos. ¿Desea que respetemos sus actuales asociaciones y apliquemos, donde usted no haya decidido, las que proponemos? ¿O más bien desea revisar la lista completa de correspondencias gráficas para el presente aplicativo, para así validarlas de forma manual?”

Claro que, en esta posición, algún lector quisquilloso podría oponer: “No estoy convencido, porque tal enfoque supone que los conceptos habrán de ser únicos para todos los programas, y esto ni siquiera se da en la vida real”. Precisamente, inquieto lector. Precisamente. La adopción de un esquema como el propuesto implica que nunca más la compra, adopción o instalación de paquetes software debiera ser la que hasta ahora era. Es decir: que se acabaron los criterios políticos, los brillos sustitutivos de la ignorancia y las asunciones “por defecto”. Y es que un esquema como el antedicho supone que no es el software el que establece el modelo (softwaremorphysm) sino que, como proclamaba Le Corbusier, es la medida humana la que se ha de imponer a sus creaciones. O sea, el software requerido (y por tanto, el de deseada construcción) será aquél que cumpla -al menos en cuanto a la solución gráfica para su navegación y uso- las propiedades de:

1. Coherencia semántica. Así, por ejemplo, "atrás" ha de significar el regreso a una o más de las situaciones que nos involucraron o posiciones que visitamos, y no debe querer decir "te voy a enseñar la parte posterior de esta ventana".
2. Separación entre conceptos-acciones y sus representaciones gráficas, manteniendo la relación en un formato independiente de lenguajes y sistemas. Se posibilitaría, así,
3. Cooperación cliente-servidor (en cualquier esquema topológico) para el mantenimiento, cambio y copia de perfiles de asignación de gráficos a conceptos de navegación-uso. Una evidente implementación se sostendría en tecnología Pushing en suscripción de canales y espacios compartidos de perfiles.

Un tal sistema software permitiría a un usuario recuperar su configuración de navegación (es decir sus pares de conceptos y gráficos asociados) en una máquina cliente no preparada para ello (quizás tras el proceso de login), o incluso "copiar" la configuración, que hemos descubierto más apropiada, de un compañero más prudente (supuesto que éste quisiera "publicar" su configuración para que otros la copiaran). En la práctica informática, esto supondría que en el cliente existirá un perfil de asociaciones de paradigmas (como "editar", etc.) con grafismos: esto es, una suerte de barra de herramientas conceptual que será comprada con lo que el servidor ofrece, y así algunos iconos serán sustituidos, otros consultados y otros simplemente reemplazados automáticamente. Existirán así perfiles conceptuales personales, de servidor y de copia de otros usuarios (que hayan decidido publicarlos en el servidor mediante su sola volición). Esto, a efectos, por ejemplo, del WBT (Web-based training), supone que cada uno podría tener la barra de navegación que quisiera para deslizarse por fases y contenidos del título de aprendizaje. Pero retomemos una idea anterior: se dijo que el perfil de asociaciones existiría en el cliente, pero, dado que tal perfil está indisolublemente asociado al perfil del usuario, esto en realidad significa que tras efectuarse el login (nombre de usuario y contraseña, en su versión reducida), el sistema comprobará si existe tal perfil "cacheado" (no podría ser de otra manera, si queremos "Zero Administration") en la máquina local; si existe, comprobará si en el servidor existe una versión más actualizada (quizás modificada por el mismo usuario desde otra máquina cliente) y, en caso afirmativo, procederá a la actualización del perfil cliente. En caso que no existiera caché alguno en el cliente, el servidor enviará a éste el perfil correspondiente al usuario "logged". Humm, pero hemos hablado de un "sistema" que realizaría todo esto, aunque... ¿cómo sería tal? ¿Se trataría de un "tuner", matizado o no? ¿De alguna aplicación XML que utilizara OSD, también matizado o no? ¿O no debiera, más bien, embeber tal comportamiento la mínima aplicación/interfaz de "login"? ¡Demonios! Parece que estamos definiendo una "sub-arquitectura de encaje de paradigmas de navegación" ¡Dios mío! El próximo paso sería, naturalmente, imbricar... ¡Eh! ¡Alto, alto! ¡Nos estamos desmadrando! En realidad lo que estoy describiendo es el ánimo de una cualquiera de las primeras pasadas reuniones, de esas que absurdamente llaman inter-disciplinares, de lo que luego ha pasado a denominarse "Proyecto GIRALDA". La escalada de ilusiones está, con todo, fielmente reflejada. Y ahora la desilusión: la paquetería software actualmente existente no está preparada para los cometidos y funciones aquí descritos, y, la verdad, únicamente podría ser forzada a la deseada modificación mediante una operación previa de eliminación total. "¿Cómo que no está preparada? -arrecia el lector de antes- ¡Mi software me permite cambiar las barras de botones y sus gráficos a voluntad!". Por supuesto, hirsuto lector, pero... ¡es que su voluntad es muy pobre! Y, además, ¿significa eso que tendré que repetir parecidos esquemas de actualización con todos los paquetes software que actualmente utilizo (con las restricciones y arbitrariedades que cada uno imponga)? ¿Y cómo encaja todo eso, además, con las políticas de reducción del tiempo ocupado por el Departamento de Sistemas en instalar y mantener bobadas en los clientes de red? Pues encaja con dolor, sufrimiento y algunas ofrendas humanas. O sea, que no.

Visiones como la anterior nos conducen, inevitablemente, a la presunción de que sería posible la construcción de un esquema software que razonablemente cumpliera las premisas expuestas, acercándonos, por tanto, al... ¡Bálsamo de Fierabrás Software! Y, claro, con este ánimo el desbarrar se apropia de todo. Volvamos, pues, a la realidad gris perla del software. Y volvamos a GIRALDA.

LOS TRES ESCENARIOS, DE DUMAS

Cualquiera de las reuniones iniciales en GIRALDA nos conducía (sucesivamente a través de la desilusión, el deseo, la esperanza, el anhelo y el pasmo) a deseables resultados muy similares en el fondo a los expuestos respecto del interfaz cliente para la navegación y uso de aplicaciones software. Tras estudiar tales rasgos comunes, que no casualmente resultaron también coincidir con los requerimientos de distintos clientes industriales, decidimos expresarlos en los cuatro distintos escenarios que informalmente se detallan a continuación:

1. Un escenario de login, donde cuando quiera que un usuario se conecta a un servidor GIRALDA, se le envía por la red (corporativa: o sea, de alta velocidad) un interfaz concreto ajustado a su perfil, de forma que en lugar de utilizar una llorosa aplicación multi-propósito con menúes agrisados (signo y señal de un esquema restrictivo neurotizante e hipersimple), se proveería a cada usuario con exactamente lo que necesitara con arreglo a sus derechos de acceso. Y es que no hay más que imaginar el frustrante escenario de un usuario navegando a través de un cúmulo de menúes jerárquicos expresamente "agrisados" para descubrir finalmente que la aplicación software ha cambiado y que su anteriormente única opción permitida está ahora... ¿dónde? Así que, en lugar de instruir a los usuarios en la navegación de sistemas tremendamente complejos (por su número de opciones), habría que proveerles de programas pequeños, intuitivos y fáciles de usar (y, consecuentemente, fáciles de cambiar). Los aspectos utilitarios, como subsistemas de caché para evitar la carga perpetua de los mismos interfaces para un usuario repetitivo, quedan relegados al esquema de diseño.
2. Un escenario de cambio dinámico de contenidos, sustanciado en un subsistema software actualizable que (re)dirija peticiones de contenidos (datos, imágenes, assets multimedia, etc.). Así, por ejemplo, una aplicación podría cambiar de idioma ante los ojos del usuario (y no sólo me refiero a los menúes, sino principalmente a los assets asociados), de forma que un gráfico con una calavera y la mención "Achtung!" podría cambiar a un signo de admiración con la leyenda "Warning!", o, en esencia, un determinado contenido o "recurso" cambiara dinámicamente (esto es, sin parar el sistema ni reinicializarlo) por otro.
3. Un escenario de cambio dinámico de software, dondequiera que el comportamiento de un subsistema software (o su percepción en el lado cliente) pueda ser variado mediante la publicación de un nuevo continente en el servidor/transmisor GIRALDA y, automática, transparente y eficientemente tal cambio fuera actualizado en el cliente. Un posible efecto observable sería que, sujeto al universo de derechos y restricciones de un perfil de usuario dado, la operatividad de tal usuario podría ser, por ejemplo, restringida a conectar dos componentes dados o, por el contrario, modificada para conectar otros dos componentes previamente disconexos. La idea, por supuesto, no es tanto cambiar un componente como mudar el comportamiento de una aplicación (o de parte de ella), mostrando a la vez al usuario que un cambio ciertamente dramático bien de un perfil de uso bien de una aplicación no ha de cambiar el esquema de distribución del software mismo. De esta manera el usuario y, por ende, la corporación en que está inserto quedarían liberados de la opresiva tiranía de proveedores software que únicamente aportan entornos de tratamiento propietario de contenidos.

D’ARTAGNAN Y LA ARQUITECTURA RGB TM

Estos tres primeros escenarios, de aplicabilidad universal a cualquier tipo de software a construir (pues la realidad es otra), constituyen una descripción informal de lo que en GIRALDA hemos denominado (y desarrollado) como "Arquitectura RGB". Se trata, siguiendo el símil que agrupa a la vez a colores básicos y a todas sus posibles combinaciones, de compilar en un patrón arquitectónico de combinación [1] el completo esquema colaborativo que permita la arbitraria componenda de los tres anteriores escenarios respecto de cualquier aplicación software. Es decir, que, en base a un universo de perfiles de configuración dinámica, los usuarios dispongan de aplicaciones gestionadas por servidores/repetidores y canales bidireccionales (servidor-cliente y retroalimentación cliente-servidor), a más de capacidades de personalización extrema y persistente en el lado cliente. Claro que aquí estamos describiendo únicamente los escenarios observables de uso y poco más. Pero, antes de seguir, había yo hablado de un escenario adicional. Y es que como en la novela de Dumas, no hay tres sin cuatro, así que, sobre los colores básicos anteriores cabe todavía una viva capa D'Artagnanesca, reflejada por el siguiente último escenario no tan básico:

• Un escenario de conexión o API (en realidad, un conjunto de interfaces de un framework) que, a modo de capa adaptadora, puente y fachada (en el sentido de los patrones del libro GOF, de Gamma y otros), establezca una superficie homogénea de uso de los servicios básicos provistos por los tres escenarios-capas-módulos anteriores.

En realidad no se trataba aquí tanto de crear un sistema arquitectónico completo como de procurar un "núcleo arquitectónico de distribución" que pueda aplicarse a los sistemas reclamados tanto por corporaciones como por los mismos usuarios. Me explico: no se trata de otra "novísima arquitectura general", como pudiera serlo CORBA respecto de la interoperabilidad de módulos software, sino más bien de la adaptación al dominio software de un nuevo esquema de construcción de aplicaciones basado directamente en lo que nosotros denominamos SPA (Software Partnership Agreement): es decir, en el truncamiento del tradicional modelo cliente-servidor para edificar, en su lugar, una relación basada en la colaboracion constructiva entre corporación (tradicionalmente “el cliente”) y empresa de software (usualmente “el proveedor”). Cambian, así, actores y roles, de forma que la esencia misma del software cambia. Así que un examen más cuidadoso de este nuevo [2] enfoque se impone.

PRINCIPIOS CONSTRUCTIVOS

En su corto texto sobre el experimento de Oregón (esto es, sobre el proceso de construcción y acomodación de la Universidad de Oregón, basado en un “plan maestro” representado por el libro mismo), Christopher Alexander expone los principios que sustancian la praxis de una nueva forma de abordar las construcciones, y que, en breve, no es sino la expresión real de sus trabajos teóricos anteriores. Bastante se ha hablado, con todo, de la perplejidad de Alexander sobre la repercusión de su trabajo en el área software, así que intentaré, simplemente, aplicar lo que de tal trabajo nos interesa. En realidad lo más importante es el concepto, la nueva forma de construcción software que los requerimientos de usuario, velozmente cambiantes y, a la vez, convergentes, están imponiendo en los últimos tiempos. Así que simplemente intentaré hacer patente la aplicación de los principios que Alexander enumera al dominio software, y a tal fin conviene que antes los detalle en las palabras de su creador. Así, los principios de construcción son:

1. Orden orgánico : Planificación y construcción han de guiarse por un proceso que permita al conjunto emerger gradualmente de acciones locales.
2. Participación : Todas las decisiones sobre qué construir, y cómo construirlo, deberán estar en manos de los usuarios.
3. Crecimiento pieza a pieza : La construcción asociada a un período presupuestario se dirigirá sobremanera hacia pequeños proyectos.
4. Patrones : Todo el diseño y construcción estará guiado por una colección de principios adoptados comunalmente y denominados patrones.
5. Diagnosis : La integridad esencial del conjunto se ha de proteger mediante una diagnosis anual que explique, en detalle, qué espacios están vivos y cuáles muertos, en cualquier momento en la historia de la comunidad.
6. Coordinación : Finalmente, la lenta emergencia del orden orgánico en el conjunto se asegurará mediante un proceso de dotación dineraria que regule el flujo de proyectos individuales alimentado por los usuarios.

Todo lo que tales principios enuncian es la adaptabilidad parte-a-parte, la construcción gradual y adaptativa, la garantía de ajuste de lo planeado, de lo finalmente construido, a los requerimientos del usuario. Y tal aseguramiento se deberá, por encima de todo, a que el proceso de construcción mismo, la granuralidad elemental del proyecto, se dará “por y para” los usuarios. Es decir, que los usuarios participarán de forma naturalmente decisiva en la construcción.

EL PLAN MAESTRO Y LA OMNIPOTENCIA SOFTWARE

Como bien explica Alexander, los planes maestros, que intentan detallar con cuidado el futuro aspecto de una construcción software son tan buenos como buena y posible es su inmutabilidad. Es decir, que su valoración depende de su estricta observancia en el tiempo, porque la idoneidad de la inserción de los módulos/paquetes en las ranuras preparadas a tal fin requiere que no cambien las condiciones conocidas o previstas en que se desarrolló tal plan. Tradicionalmente los proyectos software han querido, de forma expresa, alejarse de la incertidumbre de los cambios asociando su escaso plazo de desarrollo a un supuesto acercamiento a los requerimientos del cliente, asegurando, además, mediante un complejo entramado de intenciones, la "extensibilidad futura" del software finalmente construido. Fíjense si será pretencioso este esquema, que al software así construido se le ha venido en llamar "solución". Claro que finalmente se ha evidenciado que, igual que en otras áreas, en el software tampoco se da la clarividencia.

GIRALDA: ECLECSIS DE ALTURA

Con las premisas ya anunciadas y con un fuerte componente tecnológico (que es a lo anterior lo que la producción es al visionado de un film), GIRALDA es un proyecto y producto tecnológico, desarrollado en el ámbito del Departamento de I+D de TransTOOLs S.A., que se caracteriza por proveer un método propio para la determinación de las necesidades del cliente mediante la inserción de éste en el proceso productivo (del software) mismo, aportando a la vez los bloques técnicos necesarios para construir el sistema así acordado. Así, superando en la práctica los esquemas constructivos denominados CBD (Component-Based Development), se posibilita la transferencia de know-how tecnológico al cliente y se habilita, a la vez, la construcción de un "rango de soluciones" para éste, que se constituye desde el principio en "partner" real del proyecto.

GIRALDA: ENUMERACIÓN TÉCNICA

Claro que, aparte del método, hay que hablar de herramientas, de tecnologías y de productos. Pero precisamente este proyecto se distingue de otros en que no necesita del empaquetamiento masivo de soluciones genéricas, sino que más bien fomenta el refinamiento de un claro y eficiente núcleo de soluciones tecnológicas construido por y para el cliente. Y es que GIRALDA es, a la vez, un método, un marco software extensible y un conjunto de herramientas personalizables que, haciendo uso de tecnologías de distribución y uso de la información, procura una solución a medida de las necesidades del cliente, precisamente porque es el cliente quien las requiere, sustancia y dirige. En realidad una definición más formal, para aquellos lectores necesitados de tacto técnico, sería la de "entorno-marco (framework) actualizable y extensible, basado en componentes, con capacidades visuales, multi-soporte y multi-protocolo, con utilidades de comportamiento y escalable para diferentes capacitaciones y niveles de experencia de usuarios con trabajo en entornos cooperativos". Y, claro, con tal definición, sus bases técnicas han de apoyarse en:

• Tecnología Orientada-a-Objetos
• Modelo de componentes JavaBeans
• CORBA EJB como plataforma servidora de componentes
• Canales Pushing
• Computación Distribuida
• Administración "Cero" y clientes livianos
• Patrones de Diseño Software
• Modelos de Roles colaborativos
• Componentes Adaptables mediante "Dipping"
• Repositorios compartidos para trabajo en equipo
• Esquemas de versionamiento
• Multi-soporte de lenguajes de programación

En realidad GIRALDA se compone, en su definición extensiva actual, de varios subsistemas arquitectónicos que permiten un conjunto de visiones no-ortogonales de los sistemas de información a modelar, entre los que se encuentran los siguientes, alternados con útiles y herramientas de programación:

CONCLUSIONES VELOCES

• ¿El objeto? La representación en el dominio software de las colaboraciones entre objetos en el mundo real
• ¿Los sujetos? Cliente y proveedor de software, ahora transformados en "partners"
• ¿El resultado? La inequívoca adecuación de los sistemas de información al uso pretendido.
• ¿El método? GIRALDA, claro está.
• ¿Mi interés? El de la consanguinidad.

REFERENCIAS DIRECTAS

• A System of Patterns, by Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad and Michael Stal, 1996, Addison-Wesley, 0-471-95869-7.
• Design Patterns CD: Elements of Reusable Object-Oriented Software, by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, 1998, Addison-Wesley, 0-201-63498-8.
• Patterns of Software: Tales from the Software Community, by Richard P. Gabriel, 1996, Oxford University Press, 0-19-510269-X.
• The Oregon Experiment, by Christopher Alexander, Murray Silverstein, Shlomo Angel, Sara Ishikawa and Denny Abrams, 1975, Oxford University Press, 0-19-501824-9.
• The Design Patterns Smalltalk Companion, by Sherman R. Alpert, Kyle Brown and Bobby Woolf, 1998, Addison-Wesley, 0-201-18462-1.
• Software Architecture in Practice, by Len Bass, Paul Clements and Rick Kazman, 1998, Addison-Wesley, 0-201-1930-0.

[1] En el sentido de patrón arquitectónico derivado de "A System of Patterns", de Buschmann y otros.

[2] La novedad no está tanto en el planteamiento como en la seguridad de la asunción de la importancia real del usuario en el proceso productivo. La idea, por otro lado, es todo menos nueva, claro. Es cuestión de matices, finalmente. Como siempre.