La orientación a componentes es un paradigma de programación que arrancó dentro del mundo académico allá por el año 2000. Aunque sus desarrollos iniciales fueron en el campo del back, el término no se ha popularizado hasta su reciente llegada al terreno del front. Esta serie de artículos es un intento por precisar qué se encierra dentro de esta nueva aproximación de construcción de software.

De repente, así como de la noche a la mañana, el mundo del desarrollo se está orientando a componentes. Como suele ocurrir a menudo a lo largo de nuestra breve y tortuosa historia, este giro copernicano no lo está siendo tanto como debiera mientras se llena de malentendidos polisémicos y grandilocuencias comercialistas. Esto es especialmente cierto en el mundo del front. Por este motivo, resulta cada vez más urgente centrar el término componente en el marco de su historia y precisar qué es exactamente la orientación a componentes y qué factores diferenciales presenta con otros paradigmas. De todo esto me encargaré en los próximos artículos. Hoy veamos cómo empezó todo.

La historia de la ingeniería del software puede describirse en términos de una búsqueda infatigable por encontrar nuevas aproximaciones de desarrollo de productos que resultaran más ágiles y productivas. Cuando llegó la orientación a componentes al mundo académico allá por el año 2000 se notaba una evidente fatiga y decepción dentro de la comunidad acerca de las opciones que a este respecto nos habían dejado los paradigmas anteriores, programación estructurada primero y programación orientada a objetos y funcional después.

Pese a las nada desdeñables mejoras que había supuesto en la cultura del desarrollo la aparición de estos paradigmas aún necesitábamos idear nuevas formas de concebir el desarrollo. Algo que hiciera madurar nuestra disciplina para convertirla en una verdadera ingeniería del software. En ese sentido, mirábamos con recelo a nuestros compañeros del mundo de la electrónica. Dentro de su campo sí que se había conseguido establecer un mundo centrado en componentes maduro. Artefactos estereotipados con parámetros de funcionamientos estandarizados operaban sobre unos esquemas eléctricos normalizados y bien definidos. Construir sistemas electrónicos era un proceso de ensamblaje más que de diseño. Y todo ello estaba logrado a distintos niveles generacionales. Esta era una carrera de abstracción progresiva que parecía no tener fin. ¿No se podía logran lo mismo dentro de nuestra disciplina? ¿Idear, aunque fuera en el ámbito restringido de un determinado dominio de negocio, un catálogo de componentes que ofrecieran servicios estándar y que, en justo paralelismo con la aproximación electrónica, operará bajo unos estándares y normativas conocidos y bien establecidos?

Al trasladar todas estas ideas a un terreno práctico resultó ser que no. Todo parecía indicar que, como suele ocurrir recurrentemente en el mundo del software, nada de esto podía ser tan sencillo. El campo de lo electrónico encierra ciertas características que no se dan en el mundo del código y que, no obstante, resultan punto menos que imprescindibles para hacer de nuestra disciplina una verdadera ingeniería con procesos sistemáticos. Revisemos estas características:

• Similaridad de productos. El mundo electrónico es fácil de estandarizar porque los tipos de productos finales también lo están. Dicho sea con todo el respeto a nuestros colegas de la ingeniería electrónica, estandarizar una industria parece sencillo cuando de lo que se trata es siempre de sacar los mismos estereotipos de productos. La electrónica tiene enseñado a sus clientes que cualquier ejercicio de personalización supone unos costes prohibitivos lo que justifica una conformidad hacia lo estereotipado. Sin embargo, en el mundo del software no es así. Cada cliente necesita imperiosamente soluciones confeccionadas a medida. En el batir de los tiempos, y entre ola y ola de moda y modernidad tecnológica, a veces hemos estado más cerca de convencer a nuestros consumidores de operar bajo unos esquemas de uniformidad. El caso de las soluciones de escritorio que se dio a finales de los 90 cuando surgieron herramientas de desarrollo visual fue un momento de éxito en ese sentido. Nadie parecía presentar problemas por operar con interfaces homogéneas basadas en un modelo de ventanas estereotipadas. Sin embargo, cuando teníamos solucionado - por estandarizado - ese mundo, a algún iluminado se le ocurrió felizmente que teníamos que saltar al mundo de la ubicuidad y comenzar a convertir la Web inmadura en una plataforma de ejecución. Quizá eso sea harina de otro costal pero lo cierto es que ese último cambio tecnológico nos ha costado a los desarrolladores superarlo la friolera de 20 años. Me pregunto, cuándo los informáticos nos dedicaremos a mejorar procesos de negocio y no a migrar soluciones funcionales de una plataforma tecnológica a la siguiente. Difícil hacer crecer un paradigma como la orientación a componentes cuando lo urgente no nos deja espacio para lo importante.

• Similaridad de artefactos. En el mundo de la electrónica el conjunto de artefactos que se emplean para conformar una solución es reducido y bien conocido en el marco de una familia generacional. Si operamos en el espacio de los transistores, todo son transistores. Si lo hacemos en el de puertas lógicas, todo son puertas lógicas. Y si lo hacemos con memorias programables todo son módulos de este tipo. En el software, esto es verdad sólo en parte. Hay artefactos recurrentes cuya reutilización puede reconocerse universalmente. Pero por norma general, se descubre que el nivel de especialización funcional de los artefactos no puede ser muy alto si queremos mantener óptimo el nivel de reutilización. Este es un gran problema que es frecuente tener que acomodar en cada caso. Las tensiones entre reutilización y productividad exigen llegar a soluciones de compromiso que son una característica esencial de la orientación a componentes. Mientras que en otros paradigmas como la programación orientada a objetos se apuesta por reutilización sacrificando productividad y especialización funcional de los artefactos, en la orientación a componentes es justo al revés, prefiriendo artefactos de alta productividad aunque ello sea en detrimento de su reutilización transversal. Todo ello significa, que la orientación a componentes opera bajo una premisa fundamental. Trata de dar respuesta a problemas recurrentes en el ámbito de un dominio determinado. Y si para hacer efectiva la productividad se requiere cerrar el ámbito de aplicación hacia un dominio más estrecho se cierra dicho dominio antes que sacrificar los índices de productividad.

• Similaridad de procesos. En el mundo de la electrónica se opera con ciertos estándares que ayudan a estereotipar igualmente los procesos de desarrollo. Cada artefacto tiene interfaces eléctricas y electrónicas bien conocidas y cualquier ejercicio de construcción puede concebirse como un proceso de ensamblaje entre artefactos estereotipados. Todo ello gracias a la similaridad que se da en el espacio de los productos finales tal y como mencionábamos anteriormente. En el mundo del software esto no es así. Puede que alcancemos un ecosistema de componentes definido de forma precisa bajo unos parámetros arquitectónicos bien conocidos y puede que consigamos conectarlos de formas estereotípicas para atender a necesidades recurrentes. Pero en un mundo completamente estereotipado es complicado dejar espacio para inyectar los requerimientos específicos del cliente, ese pequeño ingrediente adaptativo que se demanda especialmente en el caso de productos software. A toda esta lógica, que sobre todo se expresa en el plano de procesos de integración entre componentes estereotipados, se le conoce como código pegamento (Glue Code) o lógica de composición. Ello significa que, para hacer de la orientación a componentes de software una aproximación universal es preciso dejar espacio para incorporar está lógica específica en los pliegues compositivos de nuestra arquitectura.

A la luz de lo anterior, parece que hacer software no resulta tan similar al desarrollo de productos electrónicos estereotipados. Sin embargo, antes de rendirse en este esfuerzo mimético, el mundo de la ingeniería del software sacó grandes lecciones aprendidas que pronto germinarían en los mimbres metodológicos de un nuevo paradigma: la programación orientada a componentes. No es momento de entrar en profundidad a discutir estas lecciones así que las trataremos en una próxima entrega.

Lo que si es cierto, es que a partir de aquí surgiría una nueva forma de concebir los procesos de desarrollo de software que, después de 15 años en barbecho dentro del espacio académico verían la luz de manera efectiva primero más tímidamente en el mundo del back y luego de manera más sonada en el mundo del front. Este es el comienzo de la historia de cómo llegamos al mundo actual de los componentes Web que desarrollaremos en próximas entregas. ¿Me acompañas en este camino?