CONCEPTOS BÁSICOS:

Según [Vallecillo, Troya, & Fuentes, 2001], en este contexto entenderemos por  sistema de aplicación a un conjunto de  herramientas que permiten la creación e interconexión de componentes software, junto con una colección de servicios para facilitar las labores de los componentes que residen y se ejecutan en él.

Un sistema de aplicación se denomina independientemente extensible si puede ser dinámicamente extendido, y en donde pueden combinarse extensiones independientemente desarrolladas por distintas partes o entidades, sin conocimiento unas de otras.

Diremos que un sistema de aplicación es abierto si es concurrente, independientemente extensible, y permite a componentes heterogéneos ingresar o abandonar el sistema de forma dinámica. Estas condiciones implican que los sistemas abiertos son inherentemente evolutivos, y que la vida de sus componentes es más larga que la del propio sistema.

Así, la Programación Orientada a Objetos (POO) ha sido el sustento de la ingeniería del software para los sistemas de aplicación cerrados. Sin embargo, se ha mostrado insuficiente al tratar de aplicar sus técnicas para el desarrollo de aplicaciones en entornos abiertos.

Sin embargo, disponer de componentes no es suficiente tampoco, a menos  que seamos capaces de reutilizarlos. Y reutilizar un componente no significa usarlo más de una vez, sino que implica la capacidad del componente de ser utilizado en contextos distintos a aquellos para los que fue diseñado. En este sentido, la reutilización es un concepto más abarcativo que solo limitarse a la reutilización de código fuente: ella involucra el uso de otros elementos de software, tales como arquitecturas de software y soluciones diseños estructurales que han probado su utilidad en situaciones similares (“patrones de diseño”), e incluso partes enteras de programas se pueden reutilizar adaptándolas al proyecto especifico que estamos desarrollando.

PROGRAMACIÓN ORIENTADA A COMPONENTES

La programación orientada a componentes (POC) surge como una variante natural ante las limitaciones de la programación orientada a objetos (POO) en los sistemas de aplicación abiertos, por problemas como la falta de una unidad concreta de composición  independiente en las aplicaciones, y la definición de interfaces a demasiado bajo nivel, dificultando la reutilización comercial de objetos.

El objetivo de la POC es construir un mercado global de componentes software, en donde los usuarios son los desarrolladores de las aplicaciones que necesitan reutilizar componentes ya hechos y testeados para construir sus aplicaciones de forma más rápida y robusta.

En general, puede verse como una extensión natural de la programación orienta a objetos dentro del ámbito de los sistemas de aplicación abiertos y distribuidos.

Las entidades básicas de la POC son los componentes, estos pueden interpretarse como cajas negras que encapsulan cierta funcionalidad y que son diseñadas sin saber quien los utilizará, ni como, ni cuando. Los servicios de los componentes son conocidos mediante sus interfaces y requisitos.

La POC es un paradigma de programación que se centra en el diseño e implementación de componentes, y en particular en los conceptos de encapsulación, polimorfismo, composición tardía y seguridad.

CONCEPTOS BÁSICOS DE LA POC

Aparte del propio concepto de componente software, existe otro conjunto de conceptos básicos que intervienen en la POC, y que permiten diferenciarla del resto de los paradigmas de programación. Entre ellos se encuentran los siguientes:

Composición tardía: Composición que se realiza en un tiempo posterior al de la compilación del componente, como puede ser durante su enlazado, carga o ejecución, y por alguien ajeno a su desarrollo, es decir, que sólo conoce al componente por su interfaz o contrato, sin necesidad de conocer detalles de implementación, ni la forma en que fue creado. 

Eventos: Mecanismo de comunicación por el que se pueden propagar las situaciones que ocurren en un sistema de forma asíncrona. Emitidos  para avisar a los componentes de su entorno de cambios en su estado.

Reutilización: Habilidad de un componente software de ser utilizado en contextos distintos a aquellos para los que fue diseñado (reutilizar no significa usar más de una vez).

Contratos: Especificación que se añade a la interfaz de un componente y que establece las condiciones de uso e implementación que ligan a los clientes y proveedores del componente. Los contratos cubren aspectos tanto funcionales (semántica de las operaciones de la interfaz) como no funcionales (calidad de servicio, prestaciones, fiabilidad o seguridad).

Polimorfismo: Habilidad de un mismo componente de mostrarse de diferentes formas, dependiendo del contexto; o bien la capacidad de distintos componentes de mostrar un mismo comportamiento en un contexto dado. En POC muestra tres nuevas posibilidades:

• La reemplazabilidad (Inclusión), o capacidad de un componente de reemplazar a otro en una aplicación, sin romper los contratos con sus clientes.
• El polimorfismo paramétrico, o implementación genérica de un componente. Este no se resuelve en tiempo de compilación (generando la típica explosión de código) sino en tiempo de ejecución.
• Por último, el polimorfismo acotado, para indicar restricciones sobre los tipos sobre los que se puede parametrizar un componente.

Seguridad: Garantía que debe ofrecer un componente de respetar sus interfaces y contratos.

• Seguridad a nivel de tipos: Asegura que las invocaciones usen los parámetros adecuados (o supertipos) y que los valores que devuelven son del tipo adecuado (o subtipos).

• Seguridad a nivel de módulo: Asegura que solo se utilizan los servicios ajenos al componente que se han declarado.

Reflexión: Habilidad para conocer y modificar el estado de un componente.

PROBLEMAS TÍPICOS DE LA POC

La POC es una disciplina muy joven y por tanto en la que los resultados obtenidos hasta ahora se centran más en la identificación de los problemas que en la resolución de los mismos. Algunos de retos y problemas con los que se enfrenta actualmente son:

1. Clarividencia. Se refiere a la dificultad con la que se encuentra el diseñador de un componente al realizar su diseño, pues no conoce ni quién lo utilizará, ni cómo, ni en qué entorno, ni para qué aplicación. Este problema está muy ligado a la composición tardía y reusabilidad de los componentes.

2. Evolución de los componentes. La gestión de la evolución es un problema serio, pues en los sistemas grandes han de poder coexistir varias versiones de un mismo componente.

3. Percepción del entorno. Habilidad de un componente de descubrir tanto el tipo de entorno en donde se está ejecutando (de diseño o de ejecución), como los servicios y recursos disponibles en él.

4. Particularización. Cómo particularizar los servicios que ofrece un componente para adaptarlo a las necesidades y requisitos concretos de nuestra aplicación, sin poder manipular su implementación.

5. Falta de soporte formal. La POC también se encuentra con otro reto añadido, como es la dificultad que encuentran los métodos formales para trabajar con sus peculiaridades, como puede ser la composición tardía, el polimorfismo o la evolución de los componentes.

6. El problema de la clase base frágil (FBCP). Este problema ocurre cuando la superclase de una clase sufre modificaciones. El FBCP existe a dos niveles, sintáctico y semántico. A nivel sintáctico ocurre cuando las modificaciones de la superclase son puramente a este nivel. A nivel semántico ocurre cuando lo que se altera es la implementación de los métodos de la superclase.

7. Asincronía y carreras de eventos. Problema que se presenta por los tiempos de comunicación en los sistemas abiertos (no se pueden despreciar retrasos). Es muy difícil garantizar el orden relativo en el que se distribuyen los eventos. El proceso de difusión de eventos es complicado cuando los emisores y receptores pueden cambiar con el tiempo.

8. Interoperabilidad. Actualmente, los contratos de los componentes se reducen a la definición de sus interfaces a nivel sintáctico, y la interoperabilidad se reduce a la comprobación de los nombres y perfiles de los métodos. Sin embargo, es necesario ser capaces de referirnos y buscar los servicios que necesitamos por algo más que sus nombres, y poder utilizar los métodos ofrecidos en una interfaz en el orden adecuado. 

Quizá sea POC la disciplina de la programación con mayor proyección a corto y medio plazo por el planteamiento tan apropiado que realiza de la construcción de aplicaciones para sistemas abiertos, a partir de esto se busca cubrir las necesidades de la industria. Actualmente es uno de los campos de investigación más activos de la comunidad software.

REFERENCIAS:

• [Vallecillo,  Troya, & Fuentes, 2001] Desarrollo de Software Basado en Componentes, Lidia Fuentes, José M. Troya y Antonio Vallecillo, 2001, Universidad de Málaga.
• Metodología de Desarrollo de Software Basada en Componentes, trabajo de cátedra.