PDF de programación - Desarrollo de Software Basado en Componentes - Lección 1

Desarrollo de Software Basado en Componentes

Lección 1

Lidia Fuentes, José M. Troya y Antonio Vallecillo

Dept. Lenguajes y Ciencias de la Computación. Universidad de Málaga.

ETSI Informática. Campus Teatinos, s/n. 29071 Málaga, Spain.

{lff,troya,av}@lcc.uma.es

Resumen

Esta lección presenta los modelos, conceptos y mecanismos fundamentales sobre los que se apoya
actualmente el desarrollo de aplicaciones software basado en componentes reutilizables. En primer
lugar, las arquitecturas software y los marcos de trabajo intentan ofrecer soluciones de diseño desde
el punto de vista estructural de las aplicaciones, y de las relaciones entre sus componentes. A
otro nivel se encuentra la programación orientada a componentes, un paradigma que propugna la
construcción de componentes reutilizables en entornos abiertos y distribuidos, con el objetivo de
lograr un mercado global de software. Basados en ellos, los modelos y plataformas de componentes
proporcionan los mecanismos adecuados para tratar la complejidad de los problemas que aparecen
en los sistemas abiertos y distribuidos. Finalmente, se describen las dificultades que encuentran las
metodologías tradicionales para construir aplicaciones en estos nuevos ambientes, y los retos a los
que se enfrenta la Ingeniería del Software para poder hablar realmente de “Ingeniería del Software
Basada en Componentes”.

1 Introducción

Los continuos avances en la Informática y las Telecomunicaciones están haciendo cambiar la forma en
la que se desarrollan actualmente las aplicaciones software. En particular, el incesante aumento de la
potencia de los ordenadores personales, el abaratamiento de los costes del hardware y las comunicaciones,
y la aparición de redes de datos de cobertura global han disparado el uso de los sistemas abiertos y
distribuidos. Esto ha provocado, entre otras cosas, que los modelos de programación existentes se vean
desbordados, siendo incapaces de manejar de forma natural la complejidad de los requisitos que se les
exigen para ese tipo de sistemas. Comienzan a aparecer por tanto nuevos paradigmas de programación,
como pueden ser la coordinación, la programación orientada a componentes, o la movilidad, que persiguen
una mejora en los procesos de construcción de aplicaciones software. En ellos se trabaja tanto en
extensiones de los modelos existentes como en nuevos modelos, en la estandarización de sus interfaces y
servicios, y la pertinaz búsqueda del cada vez más necesario mercado global de componentes software.
Estos son parte de los nuevos retos con los que se enfrenta actualmente la ingeniería del software.

Uno de los enfoques en los que actualmente se trabaja constituye lo que se conoce como Desarrollo
de Software Basado en Componentes (DSBC), que trata de sentar las bases para el diseño y desarrollo
de aplicaciones distribuidas basadas en componentes software reutilizables. Dicha disciplina cuenta
actualmente con un creciente interés, tanto desde el punto de vista académico como desde el industrial,
en donde la demanda de estos temas es cada día mayor.

La presente lección pretende servir como una breve introducción a algunos de los conceptos y métodos
fundamentales sobre los que se apoya el DSBC. En particular, nos centraremos en las arquitecturas
software y los marcos de trabajo, la programación orientada a componentes, y en las plataformas de
componentes distribuidas. Asimismo, discutiremos sobre lo que debería constituir una metodología
para el DSBC. Por supuesto, aún queda mucho trabajo por hacer para poder hablar realmente de una
Ingeniería del Software Basada en Componentes, pero sin duda las bases se están sentando para hacer
de esta disciplina una realidad en un futuro cercano.

1

2 Conceptos Básicos

Comenzaremos con algunas definiciones básicas, que van a sentar las bases de los conceptos que mane-
jaremos a lo largo de esta lección.

En primer lugar, entendemos por sistema a un conjunto de mecanismos y 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 se denomina independientemente extensible [Szyperski, 1996] 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 es abierto si es concurrente, reactivo, independientemente extensible, y per-
mite 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 corta que la del propio sistema. No hemos querido incluir en nuestra definición de sistema abierto
la propiedad de ser distribuido, puesto que consideramos que ambas características son independientes
entre sí. Sin embargo, los sistemas objeto de nuestro estudio comprenden ambas propiedades, siendo
tanto abiertos como distribuidos.

Como consecuencia de dichas características, el desarrollo de aplicaciones para este tipo de sistemas
se ve afectado por una serie de problemas específicos, como son la gestión de la evolución del propio
sistema y de sus componentes, la falta de una visión global del sistema, la dificultad para garantizar la
seguridad y confidencialidad de los mensajes, la heterogeneidad de los componentes, o su dispersión, lo
que puede implicar retrasos y errores en las comunicaciones.

El tratamiento de estas situaciones es lo que ha hecho ver la necesidad de nuevos modelos, pues la
programación tradicional se ha visto incapaz de tratarlos de una forma natural. Así, la Programación
Orientada a Objetos (POO) ha sido el sustento de la ingeniería del software para los sistemas cerrados.
Sin embargo, se ha mostrado insuficiente al tratar de aplicar sus técnicas para el desarrollo de aplicaciones
en entornos abiertos. En particular, se ha observado que no permite expresar claramente la distinción
entre los aspectos computacionales y meramente composicionales de la aplicación, y que hace prevalecer
la visión de objeto sobre la de componente, estos últimos como unidades de composición independientes
de las aplicaciones. Asimismo, tampoco tiene en cuenta los factores de mercadotecnia necesarios en un
mundo real, como la distribución, adquisición e incorporación de componentes a los sistemas.

A partir de estas ideas nace la programación orientada a componentes (POC) como una extensión
natural de la orientación a objetos para los entornos abiertos [Nierstrasz, 1995][Szyperski y Pfister, 1997].
Este paradigma propugna el desarrollo y utilización de componentes reutilizables dentro de lo que sería
un mercado global de software.

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, uno de los sueños que siempre ha tenido la ingeniería del software es el de contar con un
mercado global componentes, al igual que ocurre con otras ingenierías, o incluso con el hardware. De
hecho, la analogía con los circuitos integrados (IC ) llegó a poner de moda los términos software IC,
software bus y software backplane, aunque nunca se haya podido llegar más allá de la definición de estos
conceptos.

Para hablar de la existencia de un mercado de componentes software es necesario que los componentes
estén empaquetados de forma que permitan su distribución y composición con otros componentes, espe-
cialmente con aquellos desarrollados por terceras partes. Esto nos lleva a la definición de componente:

“Un componente es una unidad de composición de aplicaciones software, que posee un con-
junto de interfaces y un conjunto de requisitos, y que ha de poder ser desarrollado, adquirido,
incorporado al sistema y compuesto con otros componentes de forma independiente, en tiem-
po y espacio” [Szyperski, 1998].

Las interfaces de un componente determinan tanto las operaciones que el componente implementa
como las que precisa utilizar de otros componentes durante su ejecución. Y los requisitos determinan
las necesidades del componente en cuanto a recursos, como por ejemplo las plataformas de ejecución que
necesita para funcionar. Obsérvese que los conceptos de objeto y componente son ortogonales, y que
ninguno de los dos depende del otro.

2

Finalmente, a partir de los componentes reutilizables dentro de un mercado global de software nace
el concepto fundamental en estos entornos, el de componente COTS (commercial off-the-shelf). Este
concepto va a cambiar la idea tradicional del desarrollo de software en donde todo es propietario —o la
reutilización se reduce a un ámbito local (el de la empresa que desarrolla el software)—, hacia nuevas
metodologías de desarrollo de software en donde es posible contar con elementos externos. Esto se va a
traducir, como veremos en la última sección, no sólo en nuevas formas de desarrollo e implementación de
aplicaciones, sino también en alteraciones durante las fases de especificación y diseño para tener en cuenta
este tipo de elementos. Aparecen también nuevos problemas, como el de la búsqueda y reconocimiento
de los componentes que se necesitan, su posible adaptación, o la resolución de solapamientos entre las
funciones y servicios que ofrecen.

Una vez disponemos del concepto de componente, un modelo de componentes define la forma de
sus interfaces y los mecanismos para interconectarlos entre ellos (p.e. COM, JavaBeans o CORBA).
Basada en un modelo de componentes concreto, una plataforma de componentes es un entorno de de-
sarrollo y de ejecución de componentes que permite aislar la mayor parte de las dificultades concep-
tuales y técn