Introducción

Los procesos de diseño y construcción de software siempre comienzan, de manera consciente o inconsciente, por la selección de un paradigma de programación. Un paradigma establece un marco de conceptos y restricciones que dirige las actividades de desarrollo de manera conveniente. De esta manera, debe entenderse que un paradigma es en realidad una herramienta de trabajo que nos ayuda a posicionarnos en un marco mental para articular los trenes de pensamiento que conducen a una solución.

Ocurre de forma habitual que la elección de un paradigma de programación suele ser una consideración de carácter cultural en la que parecen primar antes criterios de experiencia y confort del equipo de desarrollo frente a consideraciones de conveniencia tecnológica o arquitectónica del proyecto. Sin embargo, es importante advertir que la elección de un paradigma suele condicionar hasta tal punto el desarrollo que imprime una impronta importante en la estructura y comportamiento del producto de software resultante. Por eso la elección debe ser realizada siempre de forma cuidadosa y atendiendo a las restricciones del espacio del problema.

El primer punto de fricción en este área dentro de la comunidad es que ni siquiera existe una conceptualización precisa acerca de lo que realmente es un paradigma de programación. No puedo evitar aprovechar esta oportunidad para ofrecer una definición formal acerca de este concepto, si bien soy consciente que este tipo de esfuerzos, por abstractos, suelen quedarse en un mero ejercicio de vanidad intelectual.

Paradigma de Programación. Un paradigma establece un marco de conceptos y restricciones que dirige las actividades de diseño y construcción de software de acuerdo a ciertos criterios de estructura y comportamiento.

A la luz de lo anterior, ¿puede considerarse que la programación estructurada, la programación orientada objetos, o la programación funcional son ejemplos clásicos de paradigmas de programación? Lo cierto es que aunque esto es una creencia popular de la comunidad no es del todo precisa. Un paradigma de programación se describe en términos de dos dimensiones características complementarias. De un lado está la diferenciación entre los distintos modelos de abstracción y de otro destacan los modelos de ejecución. A la primera dimensión pertenece la enumeración que daba inicio a este párrafo. La segunda dimensión discute los diferentes modos en los que el software es ejecutado en tiempo de uso.

A lo largo de esta serie de artículos revisaremos el concepto de modelo de abstracción vinculado a los paradigmas de programación y revisitaremos cada uno de estos modelos para los principales paradigmas en uso en la actualidad. Los modelos de ejecución serán objeto de estudio en otra serie subsiguiente.

Modelos de Abstracción

Los modelos de abstracción definen los ciudadanos de primera categoría que constituyen los elementos de construcción a partir de los cuales deben elaborarse las arquitecturas de software en el marco de un paradigma. Como se desprende de lo descrito en la introducción, hablar de modelos de abstracción tiene un sesgo intencional ya que cada modelo es una visión proyectiva de cómo se percibe una solución de software desde la perspectiva de cierto paradigma.

Modelo de Abstracción. Un modelo de abstracción define el tipo de artefacto que se utiliza en los procesos de construcción de software en el marco de un paradigma y modula su pragmática de uso en términos de los objetivos de comportamiento, principios de diseño y técnicas de desarrollo definidos dentro del mismo.

En concreto, en linea con lo anterior, es correcto decir que la orientación a objetos persigue una conceptualización en la que todo el software está basado en abstracciones de datos llamadas objetos, que la programación funcional reconoce las abstracciones funcionales como la unidad de trabajo fundamental y que, de manera similar, pero no idéntica, la programación estructurada identifica los procedimientos como la unidad de trabajo centrada en tareas.

Ejes Dimensionales

Con los ejemplos anteriores, parece que se presenta mucho más nítido el concepto de modelo de abstracción y su relación dentro del marco de un paradigma. Es interesante advertir cómo, en efecto, cada modelo de abstracción ofrece un tipo de artefacto arquitectónico propio que presenta una estructura anatómica y una pragmática de operación característica. Pensar en un paradigma, a menudo se traduce en reflexionar en base al modelo de abstracción del mismo. Adquirir competencias en el desarrollo de arquitecturas de un nuevo paradigma, exige un cambio mental que es, sin lugar a dudas el mayor reto cognitivo que los desarrolladores hacemos en nuestro recorrido profesional.

Pero el uso de un modelo de abstracción determinado no se limita a definir un tipo de artefacto arquitectónico característico para operar dentro del paradigma. Mucho más allá de eso, el uso de cada tipo de artefacto tiene una impronta directa en relación a cierto espacio de objetivos perseguidos, los principios de diseño que deben respetarse para alcanzar esos objetivos y las técnicas de soporte que debe proporcionar el lenguaje de programación subyacente.

Desde cierto punto de vista puede aceptarse que existe una relación simbiótica entre ambos elementos de discurso. Los artefactos de un modelo de abstracción son estratégicamente diseñados para ajustarse al marco de objetivos, principios y técnicas. Recíprocamente, las técnicas, principios y objetivos son la consecuencia natural de hacer una concepción ontológica del mundo basada en determinado tipo de artefactos.

De acuerdo a esto, podemos afirmar que todo modelo de abstracción y por extensión su paradigma de desarrolla asociado, puede ser caracterizado en términos de esa terna antedescrita que al representarla como ejes dimensionales da lugar a un espacio de operación donde nace y se desarrolla cada modelo de solución diseñado (Figura 1). A continuación describimos cada uno de estos ejes.

• Objetivos. Un objetivo en el marco de una solución software es toda cualidad observable que resulta de interés deseable dentro de la misma. La reusabilidad, la robustez o la resiliencia son ejemplos de objetivos típicamente perseguidos dentro de los paradigmas de desarrollo. En tanto que hablamos de cualidades del software, los objetivos no suelen ser medibles en términos cuantitativos y este hecho ha sido objeto de debate dentro de las comunidades de arquitectura, especialmente aquel referido a la reutilización. Sin embargo, está bajo criterio del equipo de arquitectura de cada producto determinar el grado de alcance de cada objetivo dentro del paradigma en uso.

• Principios. Los principios de diseño ofrecen directrices de actuación que deben ser de velado cumplimiento en el marco de cada paradigma. Como explicaremos más adelante, Los principios guardan una estrecha relación con los objetivos en tanto que mientras que los primeros se formulan en términos desiderativos con respecto a las cualidades de una arquitectura los segundos son vectores de empuje que velan por que dichos objetivos se cumplan en mayor o menor medida. Este hecho tiende a crear confusión dentro de la literatura porque muchos autores formulan ciertos principios en términos de los objetivos a los que contribuyen de manera nuclear y no formulan el objetivo como un valor en si mismo. Se habla del principio de reutilización por no hablar de la reutilización como objetivo.

• Mecanismos. Los mecanismos del lenguaje hacen referencia a todas aquellas características y capacidades de los lenguajes de soporte subyacentes que permiten articular soluciones dentro del paradigma de programación seleccionado. La herencia, el polimorfismo, la delegación, la ligadura dinámica o la genericidad son mecanismos típicos de la orientación a objetos. Sin embargo, conviene advertir que el desarrollo de soluciones de software en el marco de todo paradigma es una actividad esencialmente intelectual. Siguiendo con el ejemplo, es posible crear abstracciones orientadas a objetos en lenguajes que no tienen un soporte completo a todo el juego de mecanismos definidos en el perímetro de este paradigma. En efecto, las abstracciones de datos de Wirth, que hoy se entienden como sustrato de base de la orientación a objetos, fueron desarrolladas inicialmente como base del desarrollo modular reutilizable en el marco de lenguajes de programación estructurada.

Objetivos, principios y mecanismos constituyen tres ejes dimensionales en torno a los cuales conformar un espacio de actividad para el diseño y la construcción de productos de software elaborados en el marco de cierto paradigma. Cada paradigma, puede describirse, de hecho, a partir de la caracterización precisa de cada uno de estos tres ejes. Sin embargo, es importante advertir que, como siempre en desarrollo, la cultura organizacional cobra un valor preponderante y muchas veces conviene adaptar estos tres elementos característicos a la misma. Los objetivos perseguidos, los principios de diseño rectores, e incluso los mecanismos soportados en uso son susceptibles de sufrir extensiones o adaptaciones en pro de la cultura de los equipos de desarrollo.

Planos de Actividad

Si bien los tres ejes característicos anteriores resultan dimensiones complementarias en la caracterización de un modelo de abstracción, y por extensión de un paradigma de programación, lo cierto es que estas dimensiones no quedan exentas de presentar ciertas relaciones entre sí. De hecho, en la sección anterior, ya señalábamos que objetivos y principios de diseño son dimensiones tan entrelazadas que frecuentemente tienden a confundirse dentro de la literatura.

Precisamente para arrojar un poco de luz en este punto, conviene ahondar en la descripción de cómo puede caracterizarse la relación precisa que se da entre cada uno de los pares de las tres dimensiones anteriores. Descritas sobre la base de la figura anterior, estas relaciones conforman sendos planos de corte sobre los cuales realizar actividades arquitectónicas de diversa índole. Explicar la naturaleza y variabilidad de este tipo de actividades ayudará a entender el tipo de relación que se da entre cada uno de los ejes vertebrales del espacio de caracterización de paradigmas.

• Arquitecturas. El recubrimiento que se da desde los objetivos hacia los principios de diseño constituye el plano de actividad del modelado arquitectónico. Todo modelo arquitectónico conocido, es la materialización de un marco estructural, coercitivo y relacional en torno al cual se articulan soluciones específicas y particulares de software. Al utilizar un modelo arquitectónico específico estamos poniendo estrés en el uso de ciertos principios como vectores directores para alcanzar aquellos objetivos que consideremos más prioritarios y relevantes en el espacio de nuestra solución. Sin el ánimo de ser exhaustivos podemos citar como ejemplos de modelos arquitectónicos de referencia las arquitecturas de plugins, las arquitecturas de microservicios o las arquitecturas dirigidas por eventos. Una descripción exhaustiva de este perímetro queda fuera de los objetivos de este artículo.

• Patrones. Mientras que los modelos arquitectónicos ofrecen marcos generales extremo a extremo para el desarrollo de soluciones de software, los patrones de diseño ofrecen soluciones probadas de ámbito local ante problemas de aparición recurrente dentro del desarrollo. Los patrones de diseño se describen en términos de una vinculación entre un problema específico y una solución dada que persigue conferir al software ciertas cualidades. Expresado en términos de nuestro marco conceptual, este tipo de activos de arquitectura se ubican en el plano que relaciona los principios de diseño con los mecanismos del lenguaje. En efecto, cada patrón hace un uso particular de ciertos mecanismos para alcanzar el alineamiento con ciertos principios.

• Técnicas. Realmente, las técnicas constituyen todo ese cuerpo de conocimiento táctico a disposición de los desarrolladores para dar respuesta a las necesidades del espacio del problema a partir de los mecanismos y capacidades ofrecidos Por el lenguaje y la tecnología de soporte. En este sentido, puede apreciarse como la familia de técnicas de un paradigma de programación se ubica en el plano que relaciona los mecanismos del lenguaje con los objetivos del espacio del problema. Aunque muchos autores han dado en llamar a este espacio de conocimiento patrones de desarrollo lo cierto es que en realidad son más bien aproximaciones frecuentemente modísticas y culturales y con una fuerte dependencia de las capacidades expresivas de la sintaxis del lenguaje y no se expresan como patrones universales.

Si observamos la enumeración anterior, advertiremos que cada uno de los tres planos de actividad conforman un recorrido convergente desde el plano más abstracto de los objetivos hasta el más específico de los mecanismos del lenguaje. En efecto, para poder expresar los objetivos perseguidos del paradigma en un modelo de solución, es preceptivo elegir un modelo de arquitectura que ayude a vehicular, de manera sistemática, el alcance de los principios de diseño. Igualmente, en las actividades recurrentes de diseño local, se requiere aplicar, de manera sistemática e inteligente, los patrones de diseño pertinentes para conformar soluciones uniformes, estándares y bien formadas. Finalmente, para implementar los activos que encuentren un alineamiento claro con el espacio de requisitos del problema, es necesario aplicar técnicas que se apoyen de forma sólida en la familia de mecanismos ofrecidos por la tecnología subyacente.

Conclusiones

A lo largo de este artículo, hemos estresado la importancia de elegir un buen paradigma de programación para desarrollar cada producto de software. En efecto, esta elección condiciona considerablemente no solamente el proceso de desarrollo en si mismo sino también el resultado de dicho producto en tanto que el tipo de artefactos arquitectónicos utilizado en la solución como el conjunto de objetivos, principios de diseño y técnicas de desarrollo asociados al mismo se verá fuertemente condicionado.

Para explicar este hecho, nos hemos servido de un marco conceptual caracterizado por tres ejes dimensionales, los arriba citados objetivos, principios y técnicas. Asimismo, hemos señalado la relación existente que se da entre cada uno de ellos para conformar sendos planos de actividad donde encuentran un locus de ubicación los modelos arquitectónicos, principios de diseño y las técnicas de desarrollo que conocemos en el perímetro de nuestra profesión.

Este marco conceptual será de utilidad para describir, en próximos artículos de esta serie, los modelos de abstracción propios de los paradigmas de programación más conocidos. Pese a que la didáctica obliga a un enfoque secuencial en la descripción de estos paradigmas, lo cierto es que hay determinados hechos relevantes que no pueden ser pasados por alto al contemplar los paradigmas desde una pragmática real.

En primer lugar, es necesario señalar el hecho de que, en productos reales, se producen efectos comunes de hibridación de paradigmas. En este sentido, es frecuente encontrar modelos de solución arquitectónica que conjugan capacidades y artefactos propios de distintos paradigmas. Una arquitectura en la nube por ejemplo, puede modelar su lógica de negocio en base a objetos, su lógica de arranque en base en funciones y su lógica de control en base a servicios.

El segundo hecho relevante a destacar aquí es que los paradigmas se desarrollan siempre de acuerdo a un proceso incremental. Esto significa que cada paradigma siempre se apoya sobre la base de un paradigma anterior. Así por ejemplo, la orientación a objetos puede ser considerada como una evolución estratégica de la programación estructurada. La orientación a componentes puede concebirse como una extensión de la orientación objetos. Y la orientación a servicios es una extensión natural de la orientación a componentes en el perímetro de la computación distribuida.

Finalmente, es necesario estresar que el uso de paradigmas tiene un fuerte anclaje en los aspectos culturales de las comunidades que los desarrollan y hacen evolucionar. En términos generales, en este sentido, se observa que existen dos grandes caminos de evolución paradigmática en línea con lo explicado en el párrafo anterior. Por un lado, desde la programación estructurada, esencialmente imperativa, se avanza hacia la orientación a objetos, la orientación a componentes, la orientación aspectos, la orientación a servicios, etc. Por otro lado, la programación funcional, con un corte mucho más declarativo, evoluciona hacia modelos de programación lógica, programación con restricciones, lógicas modales, etc. A lo largo de todos los artículos de esta serie recorreremos el primer camino que está más vinculado a los procesos de ingeniería de software mientras que el recorrido del segundo camino es una actividad más de nicho perteneciente a la comunidad de ingeniería del conocimiento e inteligencia artificial.