Ingeniería de Software Basada en Componentes

5/11/2018 Ingeniería de Software Basada en Componentes - slidepdf.com

http://slidepdf.com/reader/full/ingenieria-de-software-basada-en-componentes 1/42

Ingeniería de Software Basada en Componentes La ingeniería de software basada en reutilización se está convirtiendo en la principal

aproximación de desarrollo para sistemas comerciales y de empresas. Las entidades que son

reutilizadas varían desde funciones específicas hasta sistemas enteros. Los desarrollosestandarizados promovidos por los principales vendedores de software han dado lugar

actualmente a que los componentes puedan interoperar dentro de un marco de trabajo

como lo esCORBA. Éste ha abierto oportunidades para la reutilización sistemática a través de

la ingeniería de software basada en componentes (ISBC).

La ISBC (o CBSE , por sus siglas en inglés de Component-Based Software Engineering) surgió

a finales de los 90 como una idea basada en la reutilización al desarrollo de sistemas. Su

creación fue motivada por la frustración de diseñadores de que el desarrollo orientado a

objetos no ha conducido a una reutilización extensiva, tal y como se sugirió inicialmente. A

pesar de las predicciones optimistas iniciales, nunca se desarrolló un mercado significativo

para objetos individuales.

La ISBC es el proceso de definir, implementar e integrar en sistemas componentes

independientes débilmente acoplados. Se ha convertido en una importante aproximación de

desarrollo de software debido a que los sistemas son cada vez más grandes y complejos y los

clientes demandan software más confiable que sea desarrollado más rápidamente. La única

forma en la que se puede enfrentar a la complejidad y entregar mejor software rápidamente

es reutilizar componentes, en vez de reimplementarlos.

El desarrollo basado en componentes se está adoptando cada vez más como una idea

fundamental en la ingeniería de software, incluso aunque los componentes reutilizables no

estén disponibles. Los componentes son independientes para que no interfieran en su

funcionamiento unos con otros. Los detalles de implementación se ocultan, por lo que la

implementación de los componentes puede cambiarse sin afectarse el resto del sistema. Los

componentes se comunican a través de interfaces bien definidas, de forma que si éstas se

mantienen, un componente puede reemplazarse por otro que proporcione una

funcionalidad adicional o mejorada. Además, las infraestructuras de componentes

proporcionan plataformas de alto nivel que reducen los costos de desarrollo de aplicaciones.

Hasta ahora, el principal uso de la ISBC ha sido la construcción de sistemas de empresas,

tales como sistemas de comercio electrónico. Los componentes que se reutilizan sondesarrollados internamente o se obtienen de proveedores de conocida confianza.

Desarrollo de Software Basado en Componentes

ResumenEsta lecci´on presenta los modelos, conceptos y mecanismos fundamentales sobre los que seapoya actualmente el desarrollo de aplicaciones software basado en componentes reutilizables.



En primer lugar, las arquitecturas software y los marcos de trabajo intentan ofrecer soluciones dediseñ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 propugnala construcción de componentes reutilizables en entornos abiertos y distribuidos, con el objetivode lograr un mercado global de software. Basados en ellos, los modelos y plataformas decomponentes proporcionan los mecanismos adecuados para tratar la complejidad de losproblemas que aparecen en los sistemas abiertos y distribuidos. Finalmente, se describen lasdificultades 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 hablarrealmente 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 laforma 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 delhardware y las comunicaciones, y la aparición de redes de datos de cobertura global handisparado el uso de los sistemas abiertos y distribuidos. Esto ha provocado, entre otras cosas, quelos modelos de programación existentes se vean desbordados, siendo incapaces de manejar deforma 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 lacoordinación, la programación orientada a componentes, o la movilidad, que persiguenuna mejora en los procesos de construcción de aplicaciones software. En ellos se trabaja tanto enextensiones de los modelos existentes como en nuevos modelos, en la estandarización de susinterfaces 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 comoDesarrollo de Software Basado en Componentes (DSBC), que trata de sentar las bases para eldiseñ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 vistaacadémico como desde el industrial, en donde la demanda de estos temas es cadad´ıa mayor. La presente lección pretende servir como una breve introducción a algunos de los conceptos ymétodos fundamentales sobre los que se apoya el DSBC. En particular, nos centraremos en lasarquitecturas software y los marcos de trabajo, la programación orientada a componentes, y enlas 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 parapoder 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.

12 Conceptos Básicos



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

En primer lugar, entendemos por sistema a un conjunto de mecanismos y herramientas quepermiten la creación e interconexión de componentes software, junto con una colección deservicios para facilitar las labores de los componentes que residen y se ejecutan en él.

Un sistema se denomina independientemente extensible [Szyperski, 1996] si puede serdinámicamente extendido, y en donde pueden combinarse extensiones independientementedesarrolladas por distintas partes o entidades, sin conocimiento unas de otras.

Diremos que un sistema es abierto si es concurrente, reactivo, independientemente extensible, ypermite a componentes heterogéneos ingresar o abandonar el sistema de forma dinámica. Estascondiciones implican que los sistemas abiertos son inherentemente evolutivos, y que la vida desus componentes es más corta que la del propio sistema. No hemos querido incluir en nuestradefinició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 nuestroestudio comprenden ambas propiedades, siendotanto abiertos como distribuidos.

Como consecuencia de dichas caracter´ısticas, el desarrollo de aplicaciones para este tipo desistemas 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, ladificultad 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, puesla 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 paralos 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 expresarclaramente la distinción entre los aspectos computacionales y meramente composicionales de laaplicación, y que hace prevalecer la visión de objeto sobre la de componente, estos últimoscomo unidades de composición independientes de las aplicaciones. Asimismo, tampoco tiene encuenta 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 unaextensió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 loque ser´ıa un mercado global de software.

Sin embargo, disponer de componentes no es suficiente tampoco, a menos que seamos capacesde 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 fuediseñ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 podidollegar más allá de la definición de estos conceptos.

Para hablar de la existencia de un mercado de componentes software es necesario que loscomponentes estén empaquetados de forma que permitan su distribución y composición conotros componentes, especialmente con aquellos desarrollados por terceras partes. Esto nos lleva ala definición de componente:

“Un componente es una unidad de composición de aplicaciones software, que posee un conjuntode 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 tiempo yespacio” *Szyperski, 1998+.

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

Finalmente, a partir de los componentes reutilizables dentro de un mercado global de softwarenace 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 espropietario —o la reutilización se reduce a un ámbito local (el de la empresa que desarrolla elsoftware)—, 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 nuevasformas de desarrollo e implementación de aplicaciones, sino también en alteraciones durante lasfases de especificación y diseño para tener en cuenta este tipo de elementos. Aparecen tambiénnuevos problemas, como el de la búsqueda y reconocimiento de los componentes que senecesitan, su posible adaptación, o la resolución de solapamientos entre las funciones y serviciosque 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 entornode desarrollo y de ejecución de componentes que permite aislar la mayor parte de las dificultades

conceptuales y técnicas que conlleva la construcción de aplicaciones basadas en loscomponentes de ese modelo *Krieger y Adler, 1998+. En este sentido, podemos definir una

plataforma como una implementación de los mecanismos del modelo, junto con una serie deherramientas asociadas. Ejemplos de estas plataformas son ActiveX/OLE, Enterprise Beans y Orbix,que se apoyan en los modelos de componentes COM, JavaBeans y CORBA, respectivamente.

Por otro lado, un mercado global necesita también de estándares que garanticen lainteroperabilidad de los componentes a la hora de construir aplicaciones. En el mundo de lossistemas abiertos y distribuidos estamos presenciando la clásica ‘guerra’ de estándares que



sucede antes de la maduración de cualquier mercado. Todos los fabricantes y vendedores desistemas tratan de convertir sus mecanismos en estándares, a la vez que pertenecen a variosconsorcios que también tratan de definir estándares, pero de forma independiente. Pensemospor ejemplo en Sun, que intenta imponer JavaBeans como modelo de componentes, mientras queparticipa junto con otras empresas en el desarrollo de los estándares de CORBA. Actualmente lainteroperabilidad se resuelve mediante pasarelas (bridges) entre unos modelos y otros,componentes especiales que se encargan de servir de conexión entre los distintos componentesheterogéneos. La mayor´ıa de los modelos comerciales ofrecen pasarelas hacia el resto, pues

reconocen la necesidad de ser abiertos.

3 Arquitecturas Software y Marcos de Trabajo

El disponer de componentes software no es suficiente para desarrollar aplicaciones, ya provengan

éstos de un mercado global o sean desarrollados a medida para la aplicación. Un aspecto cr´ıtico

a la hora de construir sistemas complejos es el diseño de la estructura del sistema, y por ello elestudio de la Arquitectura Software se ha convertido en una disciplina de especial relevancia en laingenier´ıa del software [Shaw y Garlan, 1996].

Entendemos por Arquitectura Software la representación de alto nivel de la estructurade un sistema o aplicación, que describe las partes que la integran, las interacciones entreellas, los patrones que supervisan su composición, y las restricciones a la hora de aplicar esospatrones.

En general, dicha representación se va a realizar en términos de una colección de componentesy de las interacciones que tienen lugar entre ellos. De esta forma aparecen las arquitecturasbasadas en componentes y conectores: los primeros se dedican a labores computacionales,mientas que los conectores encapsulan los patrones de sincronización y coordinación entre loscomponentes. Este tipo de arquitecturas son completamente modulares y favorecen la

reutilización de todos sus elementos, incluyendo losque definen las distintas relaciones entreellos.

Una arquitectura software viene determinada por las diferentes instancias de cada tipo decomponentes y conectores que la componen, y por una serie de enlaces (bindings) espec´ıficos

que definen la unión de todas ellas formando una estructura. A esta estructura se le da el nombrede configuración, y suele considerarse insertada en una jerarqu´ıa, pues toda entidad software,

independientemente de su granularidad, dispone de una estructura que puede ser descritamediante una arquitectura software.

Cuando lo que interesa no es obtener una configuración concreta, sino extraer los patrones

genéricos que definen a una familia de sistemas, se habla de estilos arquitectónicos. La

definición de estilos tiene 3una gran importancia desde el punto de vista de la reutilización, y esun aspecto fundamental en la arquitectura del software.

En general, la arquitectura software nace como una herramienta de alto nivel para cubrir distintosobjetivos, entre los que destacamos:

1. Comprender y manejar la estructura de las aplicaciones complejas.2. Reutilizar dicha estructura (o partes de ella) para resolver problemas similares.



3. Planificar la evolución de la aplicación, identificando sus partes mutables e inmutables, as´ı

como los costes de los posibles cambios.4. Analizar la corrección de la aplicación, y su grado de cumplimiento respecto a los requisitosiniciales (prestaciones o fiabilidad). 5. Permitir el estudio de alguna propiedad espec´ıfica del dominio.

Se han propuesto diversos modelos de arquitecturas software usando componentes y conectoresque se basan en la especificación de la arquitectura del sistema. En esta l´ınea podemos citar los

trabajos que parten del modelo inicial de Allen y Garlan [Allen y Garlan, 1994], como UNICON[Shaw et al., 1995], AESOP [Garlan et al., 1994] [Garlan et al., 1995], ±arwin [Magee et al.,1995][Magee y Kramer, 1996], Executable Connectors [Ducasse y Richner, 1997] y LEDA [Canal etal., 1997]. Todos ellos comparte la misma visión arquitectónica de los sistemas, aunque cada unode ellos utilice notaciones y formalismos diferentes.

3.1 Lenguajes de Descripción de Arquitecturas

Todas las propuestas mencionadas anteriormente utilizan los Lenguajes de Descripción de

Arquitecturas (LDAs) para expresar la estructura de las aplicaciones. Los LDAs proporcionan losmodelos, notaciones y herramientas que permiten describir los componentes y conectores queforman una aplicación, as´ı como sus enlaces espec´ıficos. Los LDAs deben ser capaces de:

1. Gestionar los diseños a alto nivel, adaptarlos a implementaciones espec´ıficas, y permitir la

selección de patrones o paradigmas de arquitecturas especificados previamente.

2. Representar nuevos patrones de arquitecturas y nuevas formas de interacción entre loscomponentes, de forma que puedan ser reutilizados en diseños futuros.

3. Aportar un conjuntos de herramientas formales para demostrar propiedades sobre los sistemas

expresados en ese lenguaje (seguridad o de viveza, por ejemplo).

4. Aportar otro conjunto de herramientas de desarrollo para realizar implementaciones parcialesde los sistemas a partir de su descripción en un LDA concreto.

En cuanto al tipo de arquitectura que permiten describir los distintos LDAs, los hay que sólopermiten las arquitecturas estáticas [Tanir, 1996], en donde las conexiones entre loscomponentes no var´ıan a lo largo de la vida del sistema; la utilidad de dichos LDA estáticos sepone de manifiesto para la descripción de sistemas hardware o sistemas eléctricos, aunque no semuestran muy adecuados para sistemas abiertos.

En este tipo de sistemas es preciso que los LDAs permitan expresar los cambios en las conexionese interacciones entre los componentes en tiempo de ejecución, pues van a depender, porejemplo, de los recursos disponibles o del perfil de los usuarios. Los LDAs mencionados antespermiten la descripción de arquitecturas dinámicas, as´ı como Rapide *Luckham et al., 1995+.

Por otro lado, hay muchas propuestas a nivel de especificación de arquitecturas software basadas en formalismos cuyos únicos objetivos son el prototipado rápido de aplicaciones y la verificación

formal de algunas de sus propiedades, entre los que podemos citar Wright [Allen y Garlan, 1997] yACME [Garlan et al., 1997]. Aunque las bondades de estas propuestas son innegables, la mayor´ıa



de ellas se quedan a este nivel de diseño, no abordando la problemática de la generación de

código a partir de las especificaciones. De esta forma dejan una laguna importante en el ciclo de

desarrollo de las aplicaciones, perdiéndose la descomposición del sistema en componentes yconectores cuando se llega al nivel de la implementaci on [Allen y Garlan, 1997]. Conseguirmetodolog´ıas que cubran todo el ciclo de vida de 4las aplicaciones a partir de su arquitecturasoftware es otro de los caminos de investigación abiertos actualmente.

Hasta ahora hemos hablado de LDAs de propósito general que, al menos en teor´ıa, pueden

usarse para cualquier dominio de aplicación. Sin embargo, cada dominio tiene sus peculiaridadesespec´ıficas y de ah´ı surgen los Lenguajes para Dominios Espec´ıficos (LDEs), que incorporan

conceptos y funciones particulares de un dominio concreto como parte del propio lenguaje.

Los LDEs proporcionan grandes ventajas al arquitecto de sistemas, entre ellas su especialización ygran expresividad en su dominio de aplicación, aunque suelen presentar un serio problema deextensibilidad: apenas aparece un nuevo concepto relacionado con el dominio que no estabaprevisto en el lenguaje, éste deja de ser útil [Bosch y Dittrich, 1997].

Además de los LDAs y LDEs, existen otras propuestas que, teniendo su mismo objetivo, ofrecen unpunto de vista más composicional que arquitectónico para la construcción de sistemas basadosen componentes. Nos referimos a los denominados Lenguajes Composicionales [Nierstrasz, 1995][Lumpe et al., 1997]. Un lenguaje composicional es una combinación entre un LDA y un lenguajede configuración (scripting language), que sirven como soporte para un entorno de composición

visual.

Los diferentes estilos arquitectónicos se definen a niveles de componentes y conectores, y la

unión entre ellos (glue) se define mediante el lenguaje de configuración. El objetivo es definir, a

partir de un lenguaje composicional, metodolog´ıas y entornos de desarrollo de aplicacionessoftware.

Aunque ya se conocen las caracter´ısticas que deben poseer estos lenguajes composicionales para

su tratamiento en entornos arquitectónicos *Nierstrasz, 1995+, todav´ıa no existe ninguno

consolidado, siendo quizá Pict [Nierstrasz et al., 1996] el primer intento. Pict es un lenguajebasado en ¼-cálculo que simplifica notablemente esta notación formal, pero permite utilizar la

mayor parte de sus ventajas. Piccola [Lumpe et al., 1997] es una evolución de Pict creado comolenguaje de configuración con tipos dinámicos.

Piccola trata de resolver las dos principales desventajas que ha mostrado Pict: su demasiado bajonivel, y la ausencia de hooks, necesarios para especializar componentes mediante técnicas dereutilización de caja negra.

3.2 Marcos de Trabajo

La reutilización de arquitecturas software se define dentro un marco de trabajo (framework, o

abreviadamente MT). En general, un MT se suele definir de la siguiente forma:

“Un MT es un diseño reutilizable de todo o parte de un sistema, representado por unconjunto de clases abstractas y la forma en la cual sus instancias interactúan”.



Otra forma de expresar este concepto es:

“Un MT es el esqueleto de una aplicación que debe ser adaptado a necesidades concretas por el programador de la aplicación”.

En ambas definiciones podemos ver que un MT encapsula el patrón de la arquitectura software

de un sistema o de alguna de sus partes, que puede además estar parcialmente instanciada.Las principales ventajas que ofrecen los MT son la reducción del coste de los procesos dedesarrollo de aplicaciones software para dominios espec´ıficos, y la mejora de la calidad del

producto final [Fayad y Schmidt, 1997].

Sin embargo, la utilización de MT presenta actualmente ciertas dificultades, aunque se suelenenglobar todas en lo que comúnmente se denomina el problema de la documentación de un MT*Sparks et al., 1996+. Este problema combina las dificultades que presenta la identificación del MTy de su utilización (reutilización). En primer lugar, el desarrollador de una aplicación se enfrentacon la dificultad de que le es muy complicado, si no imposible, decidir si un MT es el adecuado

para resolver su problema, y hasta qué grado es capaz de resolverlo. Y en segundo lugar, si

realmente el MT es el apropiado, ha de saber cómo ha de utilizarlo (acomodándolo,especializándolo y posiblemente extendiéndolo) para integrarlo en su implementación concreta.A esa adaptación se le denomina comúnmente extensión del MT, y constituye la forma dereutilización de los marcos de trabajo.

Usualmente los MT se extienden mediante los denominados puntos de entrada (hot spots ohooks), componentes (o procedimientos) cuya implementación depende del sistema o entornofinal en el que se ejecuta la aplicación, y que permiten adaptarla. Dichos puntos de entrada sondefinidos por el diseñador del MT, cuya arquitectura debe orientar para que estos sean la formanatural de extensión del marco [Schmidt, 1997b].

El problema de la documentación se debe principalmente a que no existe una forma clara deespecificar los marcos de trabajo. De hecho, la documentación de mayor parte de los MTexistentes no está unificada, 5es pobre, o bien se encuentra dispersa entre mucha literaturaheterogénea y dirigida a usuarios de muy distintos perfiles. La razón fundamental de estos

hechos es que los marcos de trabajos existentes han nacido normalmente como generalización deaplicaciones ya realizadas, cuya estructura ha sido extra´ıda y recompuesta como un MT para suposterior reutilización. Y en cuanto a los MT de nueva creación, estos se enfrentan a la falta deestandarización de su documentación, por lo que dependen en gran medida de la voluntad yconocimientos de sus desarrolladores.

Por tanto, ser´ıa preciso disponer de mecanismos y herramientas para describir de forma unificada

y completa la arquitectura de un MT, los problemas para los que está diseñado, y la forma en la

que hay que utilizarlo. Existen diferentes propuestas en este sentido, que pasamos a describir.

En primer lugar, algunos autores proponen la construcción de entornos gráficos que permiten

‘navegar’ por la arquitectura del MT, consultando en cada uno de sus puntos la información queel usuario considera relevante. La representación de la arquitectura se realiza de forma gráfica,

ya sea mediante grafos [Meusel et al., 1997][Florijn et al., 1997] o mediante secuencias demensajes [Lange y Nakamura, 1995].



Estas propuestas aportan un conocimiento más profundo del marco de trabajo, aunque nodefinen una metodolog´ıa que permita utilizar ese conocimiento para adaptar el MT a la nueva

aplicación. Su utilidad queda por tanto reducida a la fase de identificación del MT.

Los contratos de reutilización [Steyaert et al., 1996] pueden ser también utilizados en estosentornos para definir la forma en la que pueden cooperar los diseñadores del MT y los

encargados de adaptarlo o extenderlo *Codenie et al., 1997+. Este enfoque define la información

necesaria para documentar adecuadamente un MT. As ı, se deben documentar cada una de las

clases con sus métodos, indicando los que se consideran puntos de entrada al MT, y las relacionesde herencia, composición, etc. Por otro lado, las extensiones que se realicen a un MT debendocumentarse siguiendo el mismo método, incluyéndose en la documentación final.

Los Patrones de Diseño (Design Patterns) son otro enfoque muy útil tanto para diseñar la

arquitectura de un MT como para documentar el diseño realizado, según postulan diferentes

autores [Lange y Nakamura, 1995][Odenthal y Quiebel-Cirkel, 1997][Meijler y Engel, 1997]. Unpatrón de diseño ofrece una solución abstracta a un problema de diseño que aparece muy

frecuentemente, expresada mediante una conjunto de relaciones e interacciones entre

componentes [Gamma et al., 1995]. Sobre los patrones de diseño hablaremos con mayor detalleen el siguiente apartado.

Finalmente, el uso de herramientas visuales es uno de los enfoques de mayor aceptaciónactualmente.

Dichas herramientas proporcionan notaciones visuales que permiten representar tanto a loscomponentes como a los conectores, y definir sus enlaces. Asimismo, permiten agregar nuevos

componentes y definir nuevas relaciones entre ellos. Las principales ventajas de estas propuestasse basan en su facilidad de uso y la rapidez con la que permiten identificar la adecuación de un

MT a una aplicación concreta, as´ı como los trabajos necesarios para extenderlo y adaptarlo. Por

otro lado, las principales desventajas que poseen estos métodos provienen de que no suelenpermitir ningún tipo de verificación sobre el diseño realizado, puesto que no suelen poseerningún tipo de lenguaje que sirva de soporte a la notación gráfica, y que permita especificar

más formalmente la arquitectura de la aplicaci on y verificar sus propiedades.

La unión de este tipo de notaciones gráficas con los LDAs descritos anteriormente es otro de los

campos en donde se está trabajando actualmente.

3.3 Patrones de Diseño

Los patrones de diseño (PD) aparecen tras la tesis de E. Gamma publicados en un libro querecoge no sólo su definición, sino todo un catálogo de PDs aplicables a la programación básica

orientada a objetos, y que cubren la mayor parte de los pequeños problemas recurrentes que se

plantean en el desarrollo de cualquier programa [Gamma et al., 1995].

El trabajo de Gamma ha sido extendido por distintos autores, y actualmente existen numerososcatálogos de PDs aplicables a casi todas las disciplinas (programación, enseñanza, negocios,

etc.), en cuya construcción se trabaja de forma muy activa. Casi todo el trabajo sobre PDs está



tutorizado por un colectivo de investigadores y empresarios que se reúnen de forma periódica enlas conferencias PLoP.

Los patrones de diseño y los marcos de trabajo son disciplinas complementarias, y por lo generalun MT suele estar compuesto por una colección de PDs. En este sentido, los PDs suelen ser deuna granularidad menor que la de un MT.

Pero los PDs también presentan algunos inconvenientes. La propuesta de ‘diseñar

documentando’ se basa en que todo MT debe poder ser construido en base a PDs más o menosconocidos o estándares. Sin embargo, esto no es siempre cierto, pues cada dominio de aplicaciónpresenta peculiaridades espec´ıficas, 6que deben ser abordadas de forma particular. Otro de losinconvenientes de los PDs es su elevado número, que los está haciendo inmanejables; por esouno de los retos que también trata de abordar la comunidad de PDs es su catalogación. Por otrolado, la complejidad de ciertos PDs que modelan relaciones complicadas entre un gran número decomponentes hacen dif´ıcil su comprensión y entendimiento, y por tanto su uso.

Y por último, tampoco está claramente definida la composición de PDs, por lo que se hace

compleja la reutilización de PDs para construir arquitecturas en base a ellos.

3.4 Clasificación de los Marcos de Trabajo

Hemos definido los MT y hablado sobre ellos y sobre las ventajas que pueden proporcionar para

construir aplicaciones, pero no hemos citado ejemplos concretos ni de MT, ni de sus dominios deaplicación. En primer lugar vamos a dividir los marcos de trabajo según su aplicabilidad enhorizontales y verticales, de acuerdo al tipo de aplicación que acometan.

Entre los horizontales existen aquellos MT dedicados a modelar infraestructuras decomunicaciones [Schmidt, 1997a][Hüni et al., 1997], las interfaces de usuario [Taylor et al., 1996],

los entornos visuales [Florijn et al., 1997] y, en general, cualquiera de los aspectos relacionadoscon el sistema subyacente [Bruegge et al., 1993].

Dentro de los MT horizontales merecen especial atención los denominados Marcos de TrabajoDistribuidos (Middleware Application Frameworks), diseñados para integrar componentes y

aplicaciones software en ambientes distribuidos, permitiendo altos niveles de modularidad yreutilización en el desarrollo de nuevas aplicaciones, y aislando la mayor parte de las dificultades

conceptuales y técnicas que conlleva la construcción de aplicaciones distribuidas basadas encomponentes [Fayad y Schmidt, 1997].

En la terminolog´ıa de la programación orientada a componentes, este término es sinónimo de

Plataforma de Componentes Distribuidos (Distributed Component Platform). Ejemplos de estosmarcos de trabajo distribuidos son CORBA [Siegel, 2000], ActiveX/OLE/COM [Box, 1998],JavaBeans [www.javasoft.com], ACE [Schmidt, 1994], Hector [Arnold et al., 1996] o Aglets [Lange yOshima, 1997].

Por otro lado, los marcos de trabajo verticales son aquellos desarrollados espec´ıficamente para

un dominio de aplicación concreto, y cubren un amplio espectro de aplicaciones, desde lastelecomunicaciones (TINA [TINA-C, 1995]), la fabricación [Schmidt, 1995], o los serviciostelemáticos avanzados y la multimedia (MultiTEL [Fuentes y Troya, 1999]). Por ser muy



espec´ıficos y requerir un conocimiento muy preciso de los dominios de aplicación resultan losmás costosos de desarrollar, y por tanto los más caros en caso de ser comercializados.

También destacaremos otros marcos de trabajo de especial relevancia dentro de laprogramación orientada a componentes, que son los denominados Marcos de Trabajo paraComponentes (Component Frameworks). Se trata de MTs tanto verticales como horizontales, peroque están realizados exclusivamente para el desarrollo de aplicaciones basadas en componentesreutilizables, y por tanto presentan unas caracter´ısticas especiales para tratar los problemas

espec´ıficos que plantean dichos componentes (composición tard´ıa, extensibilidad, etc.).

En general, pueden definirse como una implementación concreta de uno o más patrones de

diseño mediante componentes reutilizables, realizado a medida para un dominio de usoespec´ıfico *Johnson, 1997+. Desarrollados sobre una plataf orma de componentes concreta, estosmarcos de trabajo suponen el siguiente nivel al de los componentes base para el desarrollo deaplicaciones. OpenDoc [www.omg.org] y BlackBox [Oberon Microsystems, 1997] son dos de lospocosmarcos de trabajo para componentes visuales que existen actualmente.

3.5 Técnicas de Extensión de los Marcos de Trabajo

En este apartado discutiremos otra clasificación de los marcos de trabajo, esta vez atendiendo a la

forma en la que permiten ser extendidos. De esta forma hablaremos de cuatro tipos de marcos detrabajo: de caja blanca, de caja de cristal, de caja gris y de caja negra. Esta taxonom´ıa es la misma

en la que se clasifican las diferentes formas de reutilización que permiten los objetos y

componentes de un sistema, pues de hecho la extensión es la forma que ofrecen los MT para sureutilización.

Los MT de caja blanca se extienden mediante los mecanismos básicos que ofrece el paradigma de

orientación a objetos. De esta forma, los puntos de entrada al MT se presentan como clases ymétodos abstractos, que han de ser implementados para extender el MT. Además, se tieneacceso al código del MT y se permite reutilizar la funcionalidad encapsulada en sus clasesmediante herencia y reescritura de métodos.

Los MT que permiten extensión por caja de cristal admiten la inspección de su estructura eimplementación, pero no su modificación ni reescritura, salvo para sus puntos de entrada. Los MT de caja negra se extienden mediante composición y delegación, en vez de utilizarherencia.

De esta forma, el MT tiene definido una serie de interfaces que deben implementar los

componentes que extienden el MT.

En general, los MT de caja blanca exigen al usuario un conocimiento muy profundo de suestructura interna y pueden llevar aparejados los problemas que acarrea la herencia, comopueden ser las anomal´ıas de la herencia [Matsuoka y Yonezawa, 1993] o el problema de la clasebase frágil [Mikhajlov y Sekerinski, 1998].



Por otro lado, los MT de caja negra se enfrentan a los t´ıpicos problemas de la programaciónorientada a componentes, como son la composición tard´ıa *Szyperski, 1996+ o la clarividencia

(previsión de los posibles usos futuros del MT).

El término caja gris fue acuñado en *Büchi y Weck, 1997+, y define una forma intermedia dereutilización, en donde sólo parte del interior de un MT (o componente) se ofrece de formapública, mientras que el resto se oculta. Es una solución intermedia entre las cajas blancas ynegras, y de ah´ı su nombre.

Aunque el nombre de caja gris es menos conocido que los otros, es el que describe la forma deextensión más utilizada.

3.6 Composición de Marcos de Trabajo

Otro de los problemas que se plantea en la construcción de software mediante la utilización demarcos de trabajo es el de su composición. Este problema surge cuando el diseñador de un

sistema necesita utilizar dos o más MT dentro de su arquitectura, y donde cada una resuelve un

problema concreto (p.e. un MT vertical y dos horizontales). Existe una buena discusión de esteproblema en [Mattson y Bosch, 1997], en donde se identifican las principales dificultades de la

composición de MT, sus causas más comunes, y un conjunto de soluciones que ayudan a resolvertotal o parcialmente estas situaciones.

Básicamente, los problemas que se plantean a la hora de componer marcos de trabajo son lossiguientes:

1. Gestión del control de la aplicación. Cada MT suele tomar control de la aplicación cuando esejecutado, invocando a las extensiones proporcionadas por el usuario. El problema es cómo hacercoexistir dos o más entidades que tratan de tomar control simultáneamente.

2. Adaptación de los servicios ofrecidos por cada uno de los MT. Cada MT ofrece servicios, queson utilizados por los componentes de los otros MT. Sin embargo, no suelen ser completamentecompatibles los servicios ofrecidos con los demandados, por lo que es preciso realizaradaptaciones.

3. Falta de funcionalidad y servicios. A veces es necesario añadir elementos adicionales a lacomposición de marcos de trabajo, pues su unión no cubre completamente nuestras necesidades(existen gaps o lagunas). El problema fundamental es que estas extensiones han de sercompatibles con el resto de los servicios ofrecidos por los distintos marcos de trabajo.

4. Solapamiento de representaciones. Este problema ocurre cuando dos o más MT contienen larepresentaci on de la misma entidad del mundo real, pero modelada desde distintas perspectivas.

5. Solapamiento de funcionalidad. En determinadas ocasiones distintos MT ofrecen la mismafuncionalidad, por lo que es preciso arbitrar quién la proporciona, y mantener actualizado elestado de todos los MT, que han de saber que la función ha sido efectuada. Para llevar a cabo laarbitración y la notificación suelen utilizarse soluciones basadas en los patrones de diseño

adapter y observer [Gamma et al., 1995].



Obsérvese cómo la interoperabilidad entre distintas plataformas de componentes puedencontemplarse también desde la perspectiva de la composición de marcos de trabajo, en dondelos problemas anteriores también aparecen. De las plataformas de componentes hablaremos conmás detalle en la sección 6.

4 Paradigmas de Programación para Sistemas Abiertos

Hasta ahora hemos considerado la construcción de aplicaciones software desde su perspectivaarquitectónica, analizando su estructura y expresándola mediante LDAs que permitenrepresentar las abstracciones de las entidades que las componen y las relaciones entre ellas. Sinembargo, existen otros enfoques 8no arquitectónicos basados en distintos modelos y paradigmasde programación. Todos ellos persiguen el mismo objetivo, la construcción de aplicaciones ensistemas abiertos y distribuidos, aunque cada uno trata de realizarlo desde perspectivasdiferentes.

Al principio sólo exist´ıa la programación secuencial, pues cada programa sólo se ejecutaba en

una máquina monoprocesador y aislada. Posteriormente aparecieron las máquinas

multiprocesador y los sistemas operativos multitarea, por lo que nacieron nuevos paradigmas ymecanismos de programación.

En este sentido, la programación concurrente proporciona la noción de procesos, aportando unaserie de primitivas para controlarlos y algunos mecanismos de comunicación y sincronización.

Dichos mecanismos pueden estar basados en memoria compartida (semáforos y monitores) o enmensajes (rendez-vous y RPCs). Por último aparece la programación distribuida, que comenzó atomar auge cuando la interconexión entre distintos computadores pudo hacerse de formaeficiente y económica. Las primeras soluciones estaban basadas en una extensión de losmecanismos que ofrec´ıa la programación concurrente para tratar con los problemas de

localización y dispersión que presentan las aplicaciones distribuidas (sockets, XWindows, RPCs,etc.), pero en seguida se vio que estas extensiones no eran suficientes. Incluso los paquetes

comerciales existentes a este nivel (PVM, MPI, Horus o ISIS) han probado su efectividaden cuanto a la implementación de las aplicaciones, pero no a la hora de diseñarlas.

En primer lugar, esas extensiones son de demasiado bajo nivel para permitir el diseño y

construcción de grandes aplicaciones distribuidas con el nivel de abstracción necesario. En estesentido, la programación paralela hab´ıa desarrollado algunos esquemas organizativos (también

llamados skeletons) de mayor nivel conceptual que los semáforos, monitores o sockets, y quedeber´ıan poder expresarse a nivel de diseño: esquemas como maestro-trabajadores o las granjasde procesos [Cole, 1989][Pelagatti, 1993]. Lo mismo ocurre con los esquemas desarrollados por lainteligencia artificial, como pueden ser las pizarras (blackboards) o las redes de contratos.

En segundo lugar, los sistemas abiertos introducen la necesidad de integrar programasheterogéneos para formar aplicaciones, as´ı como de poder trabajar con aplicaciones ya

existentes (legacy systems).

Y por último, y desde un punto de vista formal, cierta propiedades del comportamiento colectivode los componentes (localidad, movilidad, seguridad, etc.) no son fácilmente manejablesutilizando las lógicas y semánticas desarrolladas para lenguajes concurrentes convencionales.



Entre los principales modelos y paradigmas de programación que han surgido para el diseño e

implementación de aplicaciones para sistemas abiertos y distribuidos se encuentran, entre otrosla coordinación, los actores y la programación concurrente, la programación paralelacomputacional, la reflexión y la meta-programación, la programación orientada a componentes,la computación móvil, o los agentes.

Cada uno de estos paradigmas trata de solucionar los problemas mencionados anteriormentedesde un enfoque distinto, no existiendo ningún paradigma lo suficientemente general y

extendido como para abarcarlos todos. En esta lección vamos a centrarnos principalmente en laprogramación orientada a componentes (POC), los problemas que trata de solucionar, losconceptos sobre los que se fundamenta, y los mecanismos que ofrece.

5 La Programación Orientada a Componentes (POC)

La Programación Orientada a Componentes (POC) *Szyperski y Pfister, 1997+ *Szyperski, 1998+

aparece como una variante natural de la programación orientada a objetos (POO) para los

sistemas abiertos, en donde la POO presenta algunas limitaciones; por ejemplo, la POO no permiteexpresar claramente la distinción entre los aspectos computacionales y meramentecomposicionales de la aplicación, no define una unidad concreta de composición independientede las aplicaciones (los objetos no lo son, claramente),y define interfaces de demasiado bajo nivel

como para que sirvan de contratos entre las distintas partes que deseen reutilizar objetos.

La POC nace con el objetivo de construir un mercado global de componentes software, cuyosusuarios son los propios desarrolladores de aplicaciones que necesitan reutilizar componentes yahechos y probados para construir sus aplicaciones de forma más rápida y robusta.

Las entidades básicas de la POC son los componentes, en el mismo sentido que los hemos

definido en la sección 2, cajas negras que encapsulan cierta funcionalidad y que son diseñadaspara formar parte de ese mercado global de componentes, sin saber ni quién los utilizará, nicómo, ni cuándo. Los usuarios conocen acerca de los servicios que ofrecen los componentes através de sus interfaces y requisitos, pero normalmente ni quieren ni pueden modificar su

implementación.

En el contexto de este documento consideraremos a la POC como un paradigma de programaciónque 9se 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. No discutiremos aqu´ı sin

embargo otros aspectos de marketing que lleva asociado un mercado de componentes software,como cualquier otro mercado:

distribución, comercialización, empaquetamiento, almacenamiento, publicidad, licencias, etc.Aunque son de especial relevancia para la POC, hemos preferido centrarnos solamente en losaspectos de técnicos de desarrollo y utilización de los componentes software.

5.1 El concepto de componente



Actualmente existe una gran discrepancia entre la mayor´ıa de los ingenieros de software sobre el

concepto de Componente Software. La polémica suscitada recientemente entre ClemensSzyperski y Bertrand Meyer en la columna “Beyond Objects”de la revista Software Development

[disponible en la Web en la dirección //www.sdmagazine.com/features/uml/beyondobjects/]sobre qué es y qué no es un componente, sus propiedades y su naturaleza, podemosconsiderarla como uno de los ejemplos más recientes y representativos sobre la confusión quesuscita el propio concepto de componente. Quizás, las causas podamos encontrarlas en laproblemática existente en los modelos de componentes actuales, y que también ha destacadoJon Hopkins en el número especial de las Comunicaciones de ACM de Octubre de 2000 dedicado amarcos de trabajo basado en componentes: “Mientras que el concepto de componente softwarees conocido virtualmente desde los inicios de la ingenier´ıa del software, la problemática y

aspectos prácticos relativos a los mismos han evolucionado continuamente a lo largo del tiempo”.

Actualmente existen distintas definiciones de componente, aparte de la ya mencionada

anteriormente de Szyperski. Entre todas las definiciones hemos querido destacar las siguientes,

que son quizá las más representativas y aceptadas por la comunidad de ingenier´ıa del software:

² A unit of composition with contractually specified interfaces and explicit context dependenciesonly. A software component can be deployed independently and is subject by composition bythird parties (agreed definition by the participants of WCOP’96 *Szyperski y Pfister, 1997]).

² A set of simultaneously deployed ‘atomic’ components. An atomic component is a ‘module’ plus

a set of ‘resources’. A module is a set of classes and possibly other non object-oriented constructs,such as procedures or functions. A resource is a frozen collection of typed items [that parametrizethe component+ (”technical definition”by Clemens Szyperski, *Szyperski, 1998+). ² The ”seven criteria”definition [Meyer, 1999]:

1. May be used by other software elements.

2. May be used by clients without the intervention of the component’s developer. 3. Includes a specification of all dependencies.4. Includes a specification of the functionality it off ers.5. Is usable on the sole basis of its specifications.6. Is composable with other components.7. Can be integrated into a system quickly and smoothly.² A logically cohesive, loosely coupled module that denotes a single abstraction (Grady Booch,1987)

² Prefabricated, pre-tested, self-contained, reusable software modules —bundles of data andprocedures— that perform specific functions (Meta Group, 1994)

² A static abstraction with plugs [Nierstrasz, 1995]² A piece of software small enough to create and maintain, big enough to deploy and support, andwith standard interfaces for interoperability (Jed Harris, 1995 —also adopted by Orfali et al.)² Anything that can be composed (agreed definition by the participants of WCOP’97 *Weck et al.,

1997]).

² Self-contained, clearly identifiable pieces that describe and/or perform specific functions, haveclear interfaces, appropriate documentation, and defined resuse status (James Sametinger, 1997).



² A system-independent binary unit that implements one or more interfaces (Kai Koskimies, , in[Broy et al., 1998]). 10² A binary unit that exports and imports functionality using a standardizedinterface mechanism (Michael Stal, in [Broy et al., 1998]).

² A part of a kit, which defines a common set of protocols between its members. A generic chunkof software with robust, well-defined interfaces (Allan C. wills, in [Henderson-Sellers et al., 1999]).² A physical, replaceable part of a system that packages implementation and provides therealization of a set of interfaces. It is a meta-subclass of Classifier (OMG UML 1.3 specification,1999).

Por otro lado, existe también una confusión habitual entre el concepto de componente con el declase, objeto, módulo, etc. Con el fin de distinguirlas entre s´ı, recogemos aqu´ı las definiciones

más aceptadas de otras entidades software, as´ı como sus principales diferencias.

Clase Las clases no hacen referencia expl´ıcita a sus dependencias y requisitos. Las clases suelen

construirse mediante herencia de implementación, y por tanto no suelen permitir unainstanciación e instalación por separado de la clase base y de sus clases hijas. Esto puede causar

problemas si se realiza composición tard´ıa (pudiendo aparecer, por tanto, el problema de la clasebase frágil).

Módulo Un módulo es un conjunto de clases, junto con opcionalmente otros elementos noorientados a objetos, como pueden ser procedimientos y funciones.

Paquetes/Librer´ıas Un paquete es un conjunto de clases, usualmente agrupadas

conceptualmente. Los paquetes no suelen ser ejecutables, y pueden ser consideradas como laversión orientada a objetos de las librer´ıas tradicionales.

Subsistema Un subsistema es una agrupación de elementos de modelado que representa una

unidad de comportamiento en un sistema f´ısico. De acuerdo a la especificación de UML 1.3, unsubsistema es una subclase de Classifier y de Package, y por tanto no tiene un comportamientopropio, sino que organiza elementos ejecutables que lo poseen (por ejemplo, componentes).

Recurso Un recurso es una colección no modificable de elementos con tipo *Szyperski, 1998+. Frameworks Los marcos de trabajo suelen estar compuestos de componentes, de los cuales unosestán fi jados por el propio marco, y otros son los que proporciona el usuario para especializar elmarco de trabajo.

Objects Are apples oranges? [Szyperski, 2000].

5.2 Otros conceptos básicos de la POC

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

Composición tard´ıa D´ıcese de aquella 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 poralguien ajeno a su desarrollo, es decir, que sólo conoce al componente por su interfaz o contrato,



pero no tiene porqué conocer ni sus detalles de implementación, ni la forma en la que fueconcebido para ser usado.

Entornos Un entorno es el conjunto de recursos y componentes que rodean a un objeto ocomponente dado, y que definen las acciones que sobre él se solicitan, as´ı como su

comportamiento. Se pueden definir al menos dos clases de entornos para los componentes: el

entorno de ejecución y el de diseño. En primero de ellos es el ambiente para el que se ha

construido el componente, y en donde se ejecuta normalmente. El entorno de diseño es un

ambiente restringido, que se utiliza para localizar, configurar, especializar y probar los

componentes que van a formar parte de una aplicación, y en donde los componentes han depoder mostrar un comportamiento distinto a sucomportamiento normal durante su ejecución.

11Eventos Mecanismo de comunicación por el que se pueden propagar las situaciones queocurren en un sistema de forma as´ıncrona. La comunicación entre emisores y receptores de loseventos se puede realizar tanto de forma directa como indirecta, siguiendo el mecanismo publish-and-subscribe que describiremos más adelante. Los eventos suelen ser emitidos por los

componentes para avisar a los componentes de su entorno de cambios en su estado o decircunstancias especiales, como pueden ser las excepciones.

Reutilización Habilidad de un componente software de ser utilizado en contextos distintos aaquellos para los que fue diseñado (reutilizar no significa usar más de una vez). Existen 4modalidades de reutilización, dependiendo de la cantidad de información y posibilidades decambio que permita el componente a ser reutilizado: caja blanca, caja de cristal, caja gris y cajanegra. Dichas modalidades coinciden con las que describiremos para los marcos de trabajo(sección 3.5).

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. Loscontratos cubren aspectos tanto funcionales (semántica de las operaciones de la interfaz) comono 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 mismocomportamiento en un contexto dado. Ambas acepciones representan los dos lados de una mismamoneda. En POO el polimorfismo se relaciona con la sobre-escritura de métodos y la sobrecargade operadores (polimorfismo ad-hoc). Sin embargo, en POC muestra tres nuevas posibilidades:

² La reemplazabilidad, o capacidad de un componente de reemplazar a otro en una aplicación,sin romper los contratos con sus clientes (también conocido por polimorfismo de subtipos o de inclusión).

² El polimorfismo paramétrico, o implementación genérica de un componente. Similar en

concepto a los generics de Ada o a los templates de C, el polimorfismo paramétrico no se resuelve como ellos 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 combina los polimorfismos de inclusión y paramétrico

para poder realizar restricciones sobre los tipos sobre los que se puede parametrizar uncomponente [Szyperski, 1998].

Seguridad Por seguridad en este contexto se entiende la garant´ıa que debe ofrecer un

componente de respetar sus interfaces y contratos, y forma el concepto básico sobre el que sepuede garantizar la seguridad (en su acepción más amplia) de un sistema. Se puede hacer unadistinción entre seguridad a nivel de tipos y a nivel de módulos. La primera se refiere a que la

invocación de los servicios de un componente se realice usando parámetros de entrada de lostipos adecuados (o supertipos suyos: contravarianza) y que los servicios devuelvan tambiénvalores del tipo adecuado (o subtipos suyos: covarianza). La seguridad a nivel de módulo*Szyperski y Gough, 1995+ se refiere a que sólo se utilicen los servicios ajenos al componente quehayan sido declarados por él, y no otros.

Reflexión La reflexión es la habilidad de una entidad software de conocer o modificar su estado.

A la primera forma se le denomina reflexión estructural, y a la segunda reflexión decomportamiento.

En la sección 5.5 hablaremos con más detalle de este concepto.

5.3 tendencias actuales de la POC

Dentro de la POC se está trabajando en varios frentes: la adecuación de los lenguajes deprogramación y modelos de objetos existentes para que incorporen estos conceptos; el diseño

de nuevos lenguajes y modelos de componentes; la construcción de herramientas de desarrollo ymarcos de trabajo para componentes; y la aplicación de técnicas formales para razonar sobre lasaplicaciones desarrolladas a base de componentes.

En cuanto a los lenguajes de programación, sólo hay unos pocos que realmente incorporenconceptos suficientes para realizar una programación orientada a componentes: Oberon, Java,

Ada95, Modula-3 y Component Pascal. Sin embargo, ninguno de ellos incorpora todos losconceptos, sino solamente unos pocos. Quizá Java y Component Pascal sean los más destacados:ambos permiten compatibilidad binaria 12(considerando como binarios también a los Javabytes)y la composición tard´ıa, son seguros tanto a nivel de tipos como de módulos, y permitenencapsulamiento y distintas clases de polimorfismo.

Por otro lado, muchos de los lenguajes que dicen ser ‘orientados a componentes’, son realmente lenguajes de configuración o entornos de desarrollo visuales, como es el caso de Visual Basic,Delphi, o C++ Builder. Ellos permiten crear y ensamblar componentes, pero separan totalmente losentornos de desarrollo y de utilización de componentes.

Más allá de estos meros entornos visuales de desarrollo de componentes, los marcos de trabajopara componentes (MTC) suponen el entorno natural en donde los componentes nacen, viven, ycumplen su misión. Los primeros MTC nacieron de la idea de los documentos compuestos, endonde la entidad básica pasa a ser el documento, en vez de la aplicación. Los usuarios dejan as´ı

de disponer de un conjunto de aplicaciones, cada una con una idea distinta de lo que es undocumento, y pasan a disponer sólo de documentos. A su vez, un documento puede contener a



su vez a otros documentos, y es la responsabilidad del sistema manejar a cada tipo de documentocon su aplicación correspondiente.

² Por ejemplo en Visual Basic todo son formularios, que pueden contener controles, aunque la listade los posible controles es completamente abierta. De hecho, la industria comenzó pronto aofrecer desde hojas de cálculo a procesadores de texto como controles de Visual Basic para poderintegrarlos fácilmente.

² En OLE se define el concepto de contenedor y se extiende el concepto de control, que pasa adenominar cualquier tipo de servidor de documentos. De esta forma los componentes pueden sertanto contenedores como servidores de documentos simultáneamente, y es posible que, porejemplo, un documento Word se incluya en una hoja de cálculo Excel, que a su vez forme partede otro documento Word.

² Otro ejemplo de documento compuesto es la Web, en donde es posible incluir en páginas HTMLmultitud de objetos distintos, como por ejemplo los Applets de Java. Aunque más reciente queOLE, supone un paso atrás en cuanto al concepto que estamos tratando, pues los objetos que

forman parte de las páginas Web no pueden ser a su vez contenedores, es decir, estamos frente auna tecnolog´ıa similar a la que ofrec´ıa Visual Basic con sus formularios y controles (aunque ya esposible en la última versión de Visual Basic definir controles que sean componentes ActiveX, que s´ı son contenedores de otros componentes).

² OpenDoc fue diseñado desde el principio como un MTC para documentos compuestos, y portanto ofrece numerosas ventajas frente a Visual Basic y OLE. Sin embargo, no ha gozado dedemasiado éxito comercial, aunque se espera que vuelva a renacer tras ser incorporado por laOMG como parte de las facilidades de CORBA.

5.4 Problemas t´ıpicos de la POC

POC es una disciplina muy joven y por tanto en la que los resultados obtenidos hasta ahora secentran más en la identificación de los problemas que en la resolución de los mismos. En ese

sentido, destacaremos los siguientes retos y problemas con los que se enfrenta actualmente:

1. Clarividencia. Citado originariamente en el libro de B. Meyer [Meyer, 1997] y comúnmentealudido por Miguel Katrib en sus amenas conferencias (él lo denomina Macumba), este problemase 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; además, se encuentra también con la paradoja de “maximizing reuse minimizes use”

[Szyperski, 1998]. Este problema está intr´ınsecamente 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 lossistemas grandes han de poder coexistir varias versiones de un mismo componente. Existendistintos enfoques para abordar este problema (desde la inmutabilidad de interfaces de COM a laintegración de interfaces que propugna CORBA), aunque ninguno totalmente satisfactorio.

3. Percepción del entorno (environment-awareness). Esta es la habilidad de un objeto ocomponente 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. La inspección y la reflexión

estructural son dos mecanismos comúnmente utilizados para implementar esta habilidad.

134. Particularización. Cómo particularizar los servicios que ofrece un componente paraadaptarlo a las necesidades y requisitos concretos de nuestra aplicación, sin poder manipular suimplementación.

La reflexión de comportamiento es la técnica comúnmente utilizada, componiendo el

componente con envolventes (wrappers, decorators o adapters) que le proporcionan lafuncionalidad apropiada.

La composición simultánea de envolventes y el estudio de las propiedades del nuevocomponente a partir de las del antiguo son campos de investigación actualmente abiertos.

5. Falta de soporte formal. Por otro lado, 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 unaclase 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, como por ejemplo

sucede cuando se añade un método a una superclase, lo que en teor´ıa deber´ıa obligar a

recompilar todas sus clases hijas. El FBCP a nivel semántico ocurre cuando lo que se altera es laimplementación de los métodos de la superclase, lo que puede llevar a que el comportamientode las clases hijas se altere sustancialmente [Mikhajlov y Sekerinski, 1998].

7. Asincron´ıa y carreras de eventos. En los sistemas abiertos y distribuidos, los tiempos de

comunicación no están acotados inicialmente, ni se pueden despreciar los retrasos en las

comunicaciones. Por consiguiente, es muy dif´ıcil garantizar el orden relativo en el que sedistribuyen los eventos, sobre todo cuando los producen distintas fuentes. Asimismo, el procesode difusión de eventos es complicado cuando tanto los emisores como los receptores puedencambiar con el tiempo. La situación se complica cuando lo que se pretende es razonarformalmente sobre la aplicación a partir de sus componentes.

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 losnombres 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étodosofrecidos en una interfaz en el orden adecuado. El estudio de la interoperabilidad de componentesa nivel de protocolos (orden entre los mensajes) o semántico (“significado” de las operaciones) esotro de los problemas abiertos.

Quizá sea POC la disciplina de la programación con mayor proyección a corto y medio plazo, nosólo por el planteamiento tan apropiado que realiza de la construcción de aplicaciones parasistemas abiertos, sino por la apremiante necesidad que existe en la industria de un paradigma deprogramación como el que POC proporciona. Actualmente es uno de los campos de investigaciónmás activos de la comunidad software, tanto académica como industrial.



5.5 Reflexión y Metaprogramación

La reflexión es una propiedad que permite representar el estado de los objetos de un sistema

como entidades de primera clase, y por tanto poder observarlos, manipularlos y razonar sobreellos como elementos básicos. Fundamentalmente hay dos tipos de reflexión: la lógica y la

computacional.

La reflexión lógica se aplica sobre los marcos formales lógicos de razonamiento, y permite a sus módulos ser accesibles como entidades de primera clase, de forma que operaciones como lacomposición o la transformación de módulos pueden ser definidas rigurosamente en la lógica y

por tanto ser también ejecutadas. Otra consecuencia importante de la reflexión lógica es que

permite representar unas lógicas en términos de otras, y de ah ı poder hablar de

interoperabilidad formal [Meseguer, 1998].

Por reflexión computacional se entiende la habilidad de una entidad software de conocer o modi-

ficar su estado. A la primera forma se le denomina reflexión estructural, y a la segunda reflexiónde comportamiento *Manola, 1993+. En lo que sigue el término reflexión se referirá solamente a

la reflexión computacional, en cualquiera de sus dos formas.

A la programación que utiliza técnicas de reflexión se le denomina Metaprogramación *Kiczales

et al., 1991], y es la fuente de numerosos modelos de objetos que persiguen un tratamientoseparado de los distintos requisitos de una aplicación. De entre todos ellos mencionaremos elmodelo de Filtros Composicionales 14de M. Aksit, el modelo de capas LayOM de Jan Bosch, y laProgramación Orientada a Aspectos de George Kiczales y el grupo de Xerox.

Por ejemplo, el modelo de Filtros Composicionales [Aksit et al., 1993] es una extensión del

modelo de objetos para permitir la separación entre la computación y el resto de los aspectos yrequisitos de una aplicación. Este modelo se apoya en la visión de un objeto como una entidadque se comunica con su entorno a través de mensajes, mediante los cuales recibe lasinvocaciones de sus métodos y devuelve las respuestas. Los Filtros son entidades que capturan losmensajes entrantes y salientes de un objeto y los manipulan de acuerdo a la funcionalidad quetrate de proporcionar cada filtro al objeto al que se asocia. De esta forma, cada requisito delsistema o de la aplicación se añade a los componente mediante distintos filtros. Existen filtros de

entrada (input filters) y de salida (output filters) dependiendo del tipo de mensajes que capturan.Los filtros pueden componerse, constituyendo una cadena de filtros que han de atravesar losmensajes para llegar al objeto o salir de él. Cada uno de ellos viene definido por un patrón deaceptación y por la serie de acciones que el filtro realiza sobre cada mensaje, lo que constituye el tipo de filtro.

Por otro lado, la Programación Orientada a Aspectos se basa en descomponer los programas endiferentes aspectos, encargándose cada uno de estos aspectos de un requisito independiente delprograma (prestaciones, seguridad, concurrencia, fiabilidad), y pudiendo estar desarrollado deforma separada de los demás, incluso en lenguajes diferentes [Kiczales et al., 1997]. Comoanalog´ıa, piénsese en las distintos partes que componen la construcción de un edificio

(electricidad, conducciones de agua, de aire, etc.).



Lo normal es tener planos de cada uno de estos aspectos por separado, que afectan a todo eledificio, en vez de un plano de cada planta que contenga todos los distintos aspectos. Esto es loque diferencia a los aspectos de otros paradigmas. Una herramienta especial, llamada tejedor(weaver) se encarga de juntar ordenadamente todos los aspectos entre s´ı, y con el núcleo

computacional del programa.

6 Modelos y Plataformas de Componentes

Más que a describir los principales modelos, plataformas, y marcos de trabajo para componentes(PCD) que existen hoy en d´ıa, hemos preferido dedicar esta sesión a discutir las principales

caracter´ısticas que distinguen a las plataformas de componentes, abstrayendo sus elementos yservicios comunes con independencia de cómo se implementan en cada PCD particular.Como mencionamos en la primera sección, un Modelo de Componentes es un estándar quedefine los interfaces de los componentes y los mecanismos para interconectarlos entre ellos,mientras que un Marco de Trabajo Distribuido es un MT diseñado para integrar componentes y

aplicaciones software en ambientes distribuidos, permitiendo la modularidad y reutilización en eldesarrollo de nuevas aplicaciones *Fayad y Schmidt, 1997+. En la terminolog´ıa de la programación

orientada a componentes, este término es sinónimo de Plataforma de Componentes Distribuidos(PCD). Este tipo de marcos ofrecen un entorno de desarrollo y de ejecución de componentessoftware que permite aislar la mayor parte de las dificultades conceptuales y técnicas queconlleva la construcción de aplicaciones basadas en componentes.

Cada plataforma se apoya en los estándares y mecanismos definidos por su modelo de

componentes base; en este sentido, podemos definir una plataforma como una implementación

de los mecanismos del modelo, junto con una serie de herramientas asociadas. Ejemplos de estasplataformas son ActiveX/OLE, Enterprise Beans y Orbix, que se apoyan en los modelos decomponentes COM, JavaBeans y CORBA, respectivamente.

En esta sección describiremos una serie de conceptos básicos sobre los que se apoyan lasplataformas de componentes distribuidos: los componentes, sus interfaces, los contenedores, lameta-información, los servicios disponibles y los entornos de desarrollo integrados queproporcionan para desarrollar componentes. Todas las plataformas incorporan estos conceptos yofrecen esos servicios a sus componentes, aunque fundamentalmente lo único que var´ıa es la

forma en la que los implementan.

6.1 Componentes e interfaces

El término componente ya fue definido anteriormente como una “unidad de composición de

aplicaciones software, que posee un conjunto de interfaces y un conjunto de requisitos, y que hade poder ser desarrollado, adquirido, incorporado al sistema y compuesto con otros componentesde forma independiente, en tiempo y espacio” *Szyperski, 1998+.

Las interfaces de un componente determinan tanto las operaciones que el componenteimplementa como las que precisa utilizar de otros componentes durante su ejecución. En losmodelos de componentes 15habituales cada interfaz va a venir determinada por el conjunto deatributos y métodos públicos que el componente implementa, y por el conjunto de eventos que



emite. Los eventos especifican la forma en la que el componente notifica al exterior una respuestaa un est´ımulo externo o bien una cambio en una condición interna (p.e. la modificación del

estado de una variable). En la interfaz de un componente seespecifica tanto la signatura del

evento como la condición que hace que éste se produzca, pero sin indicar ni el consumidor delevento ni la forma en la que se ha de tratar, por ser detalles que el componente nipuede, ni quiere conocer.

La interacción tradicional entre componentes está basada en RPCs para la invocación de losmétodos públicos, y en el modelo de publish-and-subscribe para los eventos. En este modelo lacomunicación entre emisores y receptores se puede realizar tanto de forma directa comoindirecta. En el primer caso los receptores se registran en el emisor, quien env´ıa los eventos a los

receptores que tenga registrados en el momento de producirse el evento. Pero también puedenutilizarse distribuidores, entidades a las que el emisor env´ıa el evento para que sea distribuido a

los receptores potenciales. Los receptores pueden registrarse con los distribuidores, o bien estosúltimos pueden utilizar estrategias de difusión total (broadcast) o parcial (multicast ) paracomunicar las ocurrencias de un evento a los receptores.

6.2 Contenedores

Los componentes suelen existir y cooperar dentro de contenedores, entidades software quepermiten contener a otras entidades, proporcionando un entorno compartido de interacción. Seaplica sobre todo para objetos y componentes visuales, que contienen a su vez a otros objetosvisuales. Por ejemplo, un control ActiveX puede ser un contenedor de otros controles ActiveX.Normalmente la relación entre los componentes y sus contenedores se establece medianteeventos.

Como ejemplo, pensemos en un contenedor, que se registra al ser creado en un escritorio oventana (en general, un drop site, DS) para ser informado de cuándo alguien deposita ah´ı un

componente. Cuando un usuario hace una operación que arrastra y suelta (drag-and-drop) uncomponente y lo deposita en el DS, el mecanismo de eventos del DS se lo notifica al contenedor,

invocando el procedimiento que previamente éste registró, y pasándole como parámetro unareferencia (handle) al componente que ha sido dejado en el DS. Ante esta notificación, el

contenedor suele cambiar el aspecto del icono del componente para indicar que la operación dearrastre (drag-and-drop) ha terminado con éxito, y pasarle al componente una referencia a losservicios que ofrece el contenedor, para que el componente pueda utilizarlos.

6.3 Meta-información

Los nuevos estándares de componentes ya especifican el tipo de información que un

componente debe hacer pública sobre s´ı mismo y sobre sus propiedades. Esa meta-informaciónes la que permite a los contenedores, entornos y herramientas de desarrollo, y a otroscomponentes descubrir la funcionalidad que ofrece un componente, y poder manipularlo. A laacción de examinar la meta-información de un componente se le denomina inspección, y puedeser tanto estática, en tiempo de diseño, como dinámica, en tiempo de ejecución.



La forma usual de implementar la meta-información de los componentes es mediante técnicasreflexivas, que están cobrando cada vez más importancia pues constituyen la mejor forma de

descubrir los recursos de un entorno dado y adaptarlos de forma flexible y modular para construir

aplicaciones (sección 5.5). Introspecci on es la acción de examinar la propia meta-información,cuando el modelo de componentes soporta reflexión.

6.4 Entornos de Desarrollo Integrados

Un Entorno de Desarrollo Integrado (IDE) es una aplicación visual que sirve para la construcciónde aplicaciones a partir de componentes. Por lo general todas ellas cuentan con los siguienteselementos:

² una o más ‘paletas’ para mostrar como iconos los componentes disponibles;² un ‘lienzo’ o ‘contenedor’ en el cual se colocan los componentes y se interconectan entre s´ı; ² editores espec´ıficos para configurar y especializar los componentes; ² visores (browsers) para localizar componentes de acuerdo a ciertos criterios de búsqueda;16² directorios de componentes;

² acceso a editores, intérpretes, compiladores y depuradores para desarrollar nuevoscomponentes;² y finalmente, acceso a algunas herramientas de control y gestión de proyectos y CSCW,

esenciales para grandes proyectos software.

Ejemplos de IDEs son Visual Studio de Microsoft, VisualAge de IBM o VisualCafe de Symantec,complementados con lenguajes de configuración como VBScript y JavaScript. 6.5 Servicios y facilidades La programación de aplicaciones distribuidas se basa en un conjunto deservicios que proporcionan a los componentes el acceso a los recursos compartidos de una formasegura y eficiente. Estos servicios suelen englobarse en las siguientes categor´ıas básicas:

² Comunicaciones Remotas: proporcionan una serie de mecanismos para la comunicación remotaentre componentes, como pueden ser los mensajes, RPCs, canales, etc.² Servicios de Directorio: proporcionan un esquema de direccionamiento global para los recursos,servicios y componentes de un sistema, incluyendo la asignación de sus nombres, y suorganización, localización y acceso.

² Seguridad: proporcionan el acceso seguro y autentificado a los recursos y servicios del sistema,

as´ı como protección frente a ataques externos o internos.

² Transacciones: proporcionan los mecanismos para coordinar las interacciones de loscomponentes cuando estos comparten datos cr´ıticos, de forma que siempre se pueda garantizar

su coherencia.

² Gestión: proporcionan un conjunto de facilidades para la monitorización, gestión yadministración de los componentes, recursos y servicios del sistema.

Es importante señalar que casi todas las PCD actuales implementan estos mecanismos y servicios,

lo que nos ha permitido describirlos y estudiarlos de una forma general.



7 Bases para una metodolog´ıa Una vez definidos los conceptos y mecanismos fundamentales que

constituyen las bases sobre las que se apoya el desarrollo de software basado en componentes(DSBC), en esta sección discutiremos el impacto que la POC y los componentes COTS introducensobre las metodolog´ıas tradicionales de desarrollo de software.

En primer lugar, y desde la perspectiva de los componentes, su diseño ha de realizarse tratando

que puedan ser reutilizados globalmente, dentro de un mercado global de software. Esto suponeel primer compromiso, pues como mencionamos antes, “maximizing reuse minimizes use”, y es

dif´ıcil diseñar un componente sin tener en cuenta los posibles usos que puedan darse.

Por otro lado, el desarrollo de componentes no puede hacerse de forma arbitraria, sino deacuerdo a los modelos existentes, incorporando aquellos mecanismos que permitan a dichoscomponentes interoperar con otros. En este sentido, el desarrollo de componentes se veampliamente beneficiado por la existencia de dichos modelos y plataformas de componentes, as´ı

como de las pasarelas entre unos y otros.

A un primer nivel, la interoperabilidad entre componentes (casi independientemente del modelo

de componentes sobre el que se apoyen) podemos decir que está actualmente superada: lasprincipales PCDs incorporan ya pasarelas que permiten a los componentes entenderse y trabajarindependientemente de si son objetos CORBA, COM o simples beans. Y los nuevos modelos decomponentes, como puede ser CCM (CORBA Component Model) [OMG, 1999] ya incorporandesde su origen la interoperabilidad entre componentes de distintos modelos. Sin embargo, unavez esa interoperabilidad básica está casi superada, nuevos retos se plantean al ser necesariatambién una interoperabilidad entre componentes a un nivel más alto, como puede ser elsemántico.

En este sentido, la comunidad cient´ıfica está trabajando en proporcionar estándares,mecanismos y herramientas que permitan extender las descripciones de los componentes para

que puedan incorporar ese tipo de información, y que pueda ser manejada a la hora de construiraplicaciones y razonar sobre ellas.

17Otro aspecto que aparece en estos ambientes es la necesidad de extender la funcionalidad delos repositorios de componentes y los servicios de directorio, as´ı como la de los corredores de

servicios (traders) que los explotan. Un mercado global de componentes COTS necesita disponerde mejores servicios para almacenar, localizar, distribuir y recuperar componentes.

Asociados a la recuperación de componentes, aparece también toda una serie de problemas enel momento en que el emparejamiento entre el componente que buscamos y el que estédisponible no sea uno-a-uno. Si necesitamos (y normalmente este será el caso) utilizar varioscomponentes COTS para obtener los servicios que hemos especificado, nos veremos obligados a

tratar con problemas de solapamiento, lagunas, e incompatibilidades entre los componentesrecuperados, además de los clásicos problemas que puede ocasionar su potencial adaptación. Espreciso por tanto disponer de mecanismos y procedimientos para identificar y resolver este tipo

de problemas.

Asimismo, y aunque se aleja un poco del ámbito de este art´ıculo, también hace falta definir toda



una serie de estándares, herramientas y servicios para poder incorporar los aspectos demercadotecnia básicos en un mercado global de componentes: licencias, pol´ıticas de precios y

alquileres, documentación, publicidad, disponibilidad, demos, etc.

Eso es en lo relativo a los componentes y al mercado. Sin embargo, en donde la Ingenier´ıa del

Software se plantea sus mayores retos es en cuanto a metodolog´ıa de diseño y construcción de

aplicaciones basados en estos componentes COTS. La razón fundamental se debe a que lasmetodolog´ıas tradicionales utilizan un enfoque descendente: desde el análisis de requisitos a lasfase de especificación, diseño, implementación y pruebas; cada uno de esos pasos se varefinando sucesivamente, consiguiendo en cada etapa una definición más precisa de los

componentes finales de la aplicación, hasta su implementación definitiva.

Todos los elementos que se obtienen de esta forma (desde la arquitectura de la aplicación hastalos componentes finales) se pretende que puedan ser reutilizados en otras aplicaciones, dentro delo posible [Rumbaugh et al., 1999].

Esta situación cambia si queremos utilizar componentes COTS, pues su existencia debe ser

considerada desde las primeras fases de la metodolog´ıa, incluyendo por ejemplo el análisis derequisitos [Robertson y Robertson, 1999]. De esta forma se altera el proceso tradicional, puesaparecen en él una serie de restricciones muy importantes que condicionan todas sus fases (lasimpuestas al tener que considerar componentesya existentes a la hora de especificar, diseñar e

implementar las aplicaciones), as´ı como ciertos procesos ascendentes (p.e. la búsqueda,identificación y recuperación de componentes COTS). De esta forma están apareciendonumerosas l´ıneas de investigación que tratan de estudiar el impacto en lasmetodolog´ıas

tradicionales de desarrollo de software en ambientes COTS.

Finalmente, sólo destacar la importancia que están tomando también los marcos de trabajo a lahora de desarrollar aplicaciones basadas en componentes. Aparte de las ventajas que hemos

mencionado cuando los describ´ıamos en la sección 3, se ha visto que sobre dichas estructuras esdonde deben descansar con mayor peso las propiedades no funcionales de las aplicaciones(calidad de servicio, fiabilidad, eficiencia, escalabilidad, etc.). De esta forma se ha encontrado un

equilibrio muy importante entre los componentes y los marcos de trabajo, haciendo descansar laspropiedades funcionales de las aplicaciones sobre los primeros, y las no funcionales sobre lossegundos.

8 Conclusiones

En esta lección hemos tratado de ofrecer una visión sobre lo que constituye el desarrollo deaplicaciones software basado en componentes reutilizables.En primer lugar se han introducido las arquitecturas software y los marcos de trabajo, queintentan ofrecer soluciones de diseño desde el punto de vista estructural de las aplicaciones, y de

las relaciones entre sus componentes.

A un nivel más bajo se encuentran la programación orientada a componentes, un paradigma quepropugna la construcción de componentes reutilizables en entornos abiertos y distribuidos, con elobjetivo de lograr un mercado global de software.



Basados en ella, los modelos y plataformas de componentes proporcionan los mecanismosadecuados para poder tratar la complejidad de los problemas que aparecen en la construcción deaplicaciones para sistemas abiertos y distribuidos, como pueden ser la heterogeneidad, laasincron´ıa, la dispersión, fallos en la seguridad, retrasos y problemas en las comunicaciones, lacomposición tard´ıa, etc.

Por último, hemos mencionado las dificultades con las que se encuentra actualmente la

Ingenier´ıa del Software para tratar de ofrecer metodolog´ıas de desarrollo de aplicaciones en

estos ambientes. Si bien es 18cierto que actualmente podemos hablar de “Desarrollo de Software

Basado en Componentes”, pensamos que aún queda cierto camino que recorrer antes de poderhablar con propiedad de una “Ingenier´ıa del Software Basada en Componentes”, capaz de ofrecer soluciones totales a los retos que plantea la construcción de grandes aplicaciones en sistemasabiertos y distribuidos.

Desarrollo de Software basado en Componentes

Contenido

1. Introducción 2. Beneficios del Desarrollo de Software basado en Componentes 3. Metrópolis: Analogía de la Evolución del Software basado en Componentes 4. Industrialización del Software a través de la Plataforma .net 5. Fábricas de Software: el Nuevo Paradigma 6. Conclusión

1. Introducción

La complejidad de los sistemas computacionales actuales nos ha llevado a buscar la reutilización delsoftware existente. El desarrollo de software basado en componentes permite reutilizar piezas de códigopreelaborado que permiten realizar diversas tareas, conllevando a diversos beneficios como las mejoras a lacalidad, la reducción del ciclo de desarrollo y el mayor retorno sobre la inversión. Al comparar la evolucióndel ambiente de IT con el crecimiento de las metrópolis actuales, podemos entender el origen de muchosproblemas que se han presentado históricamente en la construcción de software y vislumbrar las posibles yprobables soluciones que nos llevarán hacia la industrialización del software moderno.

Este proceso de industrialización ha dado ya sus inicios con implementaciones como la plataforma .net, lacual impulsa la idea de industrializar el software utilizando tecnologías de componentes. Los avances ymejoras presentados en esta plataforma van mucho más allá de las implementaciones iniciales como COM yCORBA, convirtiendo a los componentes .net en verdaderas piezas de ensamblaje, en un estilo muy similar alas líneas de ensamblaje modernas. Asimismo, los nuevos paradigmas como las Fábricas de Softwareproveen de los medios para hacer la transición desde el 'hacer a mano' hacia la fabricación o manufacturade software.

Si hay algo que ha aprendido el ser humano desde tiempos muy antiguos es a reutilizar el conocimientoexistente para sus cada vez más ambiciosas empresas. En efecto, al reutilizar trozos de experiencias, ideas yartefactos, no solo nos aseguramos de no cometer los mismos errores del pasado, sino que logramosconstruir cosas cada vez más grandes y maravillosas, con bases firmes y calidad incomparable. Este conceptode la reutilización, uno de los primeros que se nos enseñan a quienes entramos al mundo del desarrollo de

http://msdn.microsoft.com/es-es/library/bb972268.aspx#EFAA


http://msdn.microsoft.com/es-es/library/bb972268.aspx#EEAA


http://msdn.microsoft.com/es-es/library/bb972268.aspx#EDAA


http://msdn.microsoft.com/es-es/library/bb972268.aspx#ECAA


http://msdn.microsoft.com/es-es/library/bb972268.aspx#EBAA


http://msdn.microsoft.com/es-es/library/bb972268.aspx#EAAA










software, habremos de utilizarlo desde el mismo instante en que escribamos nuestra primera línea decódigo.

Los sistemas de hoy en día son cada vez más complejos, deben ser construidos en tiempo récord y debencumplir con los estándares más altos de calidad. Para hacer frente a esto, se concibió y perfeccionó lo quehoy conocemos como Ingeniería de Software Basada en Componentes (ISBC), la cual se centra en el diseño y

construcción de sistemas computacionales que utilizan componentes de software reutilizables. Esta cienciatrabaja bajo la filosofía de "comprar, no construir", una idea que ya es común en casi todas las industriasexistentes, pero relativamente nueva en lo que a la construcción de software se refiere.

Para este momento, ya muchos conocen las ventajas de este enfoque de desarrollo y, de la misma forma,muchos se preguntan día a día el por qué son tan pocos los que realmente alcanzan el éxito siguiendo estafilosofía. En realidad, hasta ahora solo hemos tanteado un poco con las posibilidades del software basado encomponentes, y es justo hora, en la presente década, que la industria del software despegará y seperfeccionará para estar a la par de cualquier otra industria del medio. Las analogías que nos han llevado aestudiar a los sistemas comparándolos con las complejas metrópolis de la actualidad, así como las iniciativasmás innovadoras como las Fábricas de Software de Microsoft, son la clara representación de que estamos apunto de presenciar un nuevo gran cambio en la forma como pensamos en software.

Principio de la página

2. Beneficios del Desarrollo de Software basado en Componentes

En esencia, un componente es una pieza de código preelaborado que encapsula alguna funcionalidadexpuesta a través de interfaces estándar (1) . Los componentes son los "ingredientes de las aplicaciones",que se juntan y combinan para llevar a cabo una tarea (2) . Es algo muy similar a lo que podemos observaren el equipo de música que tenemos en nuestra sala. Cada componente de aquel aparato ha sido diseñadopara acoplarse perfectamente con sus pares, las conexiones son estándar y el protocolo de comunicaciónestá ya preestablecido. Al unirse las partes, obtenemos música para nuestros oídos.

El paradigma de ensamblar componentes y escribir código para hacer que estos componentes funcionen seconoce como Desarrollo de Software Basado en Componentes. El uso de este paradigma posee algunasventajas:

1. Reutilización del software. Nos lleva a alcanzar un mayor nivel de reutilización de software.2. Simplifica las pruebas. Permite que las pruebas sean ejecutadas probando cada uno de los

componentes antes de probar el conjunto completo de componentes ensamblados.3. Simplifica el mantenimiento del sistema. Cuando existe un débil acoplamiento entre

componentes, el desarrollador es libre de actualizar y/o agregar componentes según sea necesario,sin afectar otras partes del sistema.

4. Mayor calidad. Dado que un componente puede ser construido y luego mejorado continuamentepor un experto u organización, la calidad de una aplicación basada en componentes mejorará con elpaso del tiempo.

De la misma manera, el optar por comprar componentes de terceros en lugar de desarrollarlos, poseealgunas ventajas:

1. Ciclos de desarrollo más cortos. La adición de una pieza dada de funcionalidad tomará días en lugarde meses ó años.

2. Mejor ROI. Usando correctamente esta estrategia, el retorno sobre la inversión puede ser másfavorable que desarrollando los componentes uno mismo.

http://msdn.microsoft.com/es-es/library/bb972268.aspx#mainSection


http://msdn.microsoft.com/es-es/library/bb972268.aspx#ref01











3. Funcionalidad mejorada. Para usar un componente que contenga una pieza de funcionalidad, solose necesita entender su naturaleza, más no sus detalles internos. Así, una funcionalidad que seríaimpráctica de implementar en la empresa, se vuelve ahora completamente asequible.


3. Metrópolis: Analogía de la Evolución del Software basado en Componentes

Pat Helland (3) , uno de los arquitectos con mayor experiencia en Microsoft, ha desarrollado recientementeuna metáfora llamada Metrópolis (4) , en la cual compara la evolución de las tecnologías de la informacióncon la forma como las ciudades de Estados Unidos han evolucionado durante los 2 últimos siglos. Alcomprender la evolución de las ciudades actuales, podemos darnos una idea del futuro promisorio que tieneel desarrollo de software basado en componentes.

Como lo menciona Helland, las ciudades y las casas de software comparten un pasado muy similar, puesambas empezaron en ambientes que se desarrollaron aisladamente. Este desarrollo independiente conllevóa diferencias de cultura con respecto a la forma como se hacían las cosas. A mediados del siglo XIX, las víasde ferrocarril conectaron la mayor parte de las ciudades en los Estados Unidos. Esto permitió que las

personas y distintos artículos empezaran a trasladarse de una forma que no era posible anteriormente. Seinició entonces una carrera por asegurar que los artículos trabajen entre sí y cumplan estándares decompatibilidad. Estos cambios en expectativas y capacidades alimentaron la explosión del comercio, lafabricación y llevaron a la urbanización de la vida, tal y como la conocemos hoy.

Por muchos años, las casas de software han desarrollado aisladamente, con aplicaciones creadasindependientemente y sin mayor necesidad de interacción entre ellas. Dado que estas aplicaciones noestaban conectadas, no había mayores consecuencias para aquello. Pero recientemente se ha vuelto muypráctico el interconectar tanto las aplicaciones dentro de una casa de software, así como entre múltiplescasas de software alrededor del mundo. Ahora la gente ya puede navegar y visitar aplicaciones muydistantes. Cantidades cada vez más grandes de información son fácilmente transmitidas entre aplicaciones.Pero lo que aún es difícil es hacer que estos datos trabajen entre distintas aplicaciones.

Para entender entonces lo que está ocurriendo en este momento con el ambiente IT hay que explorar 6facetas de esta analogía:

Ciudades - Casas de Software Las ciudades evolucionaron gradualmente como lugares para hacer comercio y manufactura. En estasciudades existían edificios con poca o ninguna conexión entre ellos. Las ciudades tenían un contacto muylimitado con sus ciudades aledañas y desarrollaron su propia cultura, estilo y forma de hacer cosas(Ver Figura 1). De la misma forma, las casas de software evolucionaron gradualmente mientras nuevasaplicaciones fueron construidas y luego extendidas. Cada aplicación separada e independiente de sussimilares en la misma casa de software. Cada casa de software tenía su propia cultura, estilo y forma dehacer las cosas (VerFigura 2):









http://msdn.microsoft.com/es-es/library/bb972268.aspx#figura01













Figura 1: Evolución de las ciudades. Volver al texto. Figura 2: Evolución de las casa

Las presiones económicas cambiaron nuestras ciudades, ya que fue la oportunidad económica la querealmente llevó a las ciudades a la modernización, a compartir servicios y a pensar en medios creativos para

alcanzar eficiencias. Asimismo, las presiones económicas están cambiando nuestras casas de software.Mientras se construyen nuevas aplicaciones y se renuevan las más antiguas, hay que considerar cómoenlazarlas a la infraestructura compartida, cómo conectarlas y cómo dividirlas de manera que se maximice lareusabilidad de las mismas. Este es el reto al que todos nos vemos enfrentados en la actualidad.

Fábricas y Edificios - Aplicaciones En los primeros años del siglo XIX, la manufactura típicamente era simple e independiente. Los bienesproducidos estaban limitados tanto por las necesidades del mercado local, como por la sofisticación delproceso de manufactura. Las fábricas producían todas las partes del ensamblado final, armaban elensamblado e incluso lo vendían. Si uno quería un par de zapatos, tenía que irse a la fábrica de zapatos. Estano era la forma más eficiente de fabricar bienes y los ítems fabricados eran caros y usualmente no de lamejor calidad (Ver Figura 3). Muchas de nuestras aplicaciones actuales son como aquellas fábricas.Producen datos procesados independientemente unos de otros, los cuales se entregan en 'mercados'

limitados. Están integradas verticalmente y usualmente no aceptan el trabajo de otras aplicaciones comoentrada (Ver Figura 4):

Figura 3: Fábricas y edificios. Volver al texto. Figura 4: Aplicaciones.

El ferrocarril alteró profundamente la manufactura. Al bajar los costos de transportar las partes fabricadas,el mismo permitió que los fabricantes locales produjeran bienes más sofisticados y de mayor calidad. La

http://msdn.microsoft.com/es-es/library/bb972268.aspx#figura01back



















componentización les permitió a los artesanos enfocarse en sus principales competencias, en lugar de tenerque entender los diversos procesos necesarios para producir todo un ensamblado sofisticado. Los negociosse especializaron e independizaron. Tanto para las fábricas como para las aplicaciones, la independencia esesencial. Uno no puede terminar su trabajo si se necesita hacer que todo trabaje en conjuntoperfectamente. Pero, aunque la independencia es esencial, no se pueden olvidar las ventajas de lainterconexión, ya que es a través de la reutilización del trabajo de los demás que uno logra cumplir su

trabajo con éxito y es justamente la demanda que ejercen los demás sobre nuestro trabajo lo que nos da elestímulo económico para seguir existiendo.

Transporte - Comunicaciones A mediados del siglo XIX llegó el ferrocarril. Se hicieron enormes cantidades de dinero moviendo personas,carbón y trigo de un lugar a otro. Con una demanda arrolladora de transporte, eventualmente todo EstadosUnidos estaba interconectado por ferrocarril. No solo que la gente empezó a viajar a nuevos lugares paraconocer nuevas culturas, sino que ahora los comerciantes podían vender artículos de formas nunca antespensadas. Pero más importante aún, el movimiento de los artículos despertó la expectativa de que las cosasfuncionen en conjunto. Antes del ferrocarril simplemente no importaba si los bienes de un fabricante eranincompatibles con los de otro fabricante.

Figura 5: Transporte. Volver al texto. Figura 6: Comunicacion

Al final del siglo XX llegó Internet. Se invirtieron montos enormes en navegación, correo electrónico, JPEGs,MP3s y chat. Se tendieron los hilos para permitir la navegación y el movimiento de las formas más simplesde datos. El navegador le permitió a la persona el transportarse para interactuar directamente con unaaplicación distante. Sin embargo, el movimiento de los datos aún no funciona bien en conjunto, haciendomuy limitados los procesos de negocios a través del Internet. Las nuevas conexiones implicaron nuevoscambios en la estandarización de los artículos y los datos. Pronto esto implicaría cambios en los procesos denegocios.

Bienes Fabricados - Datos Estructurados

A inicios del siglo XVIII los bienes se hacían a mano. Los ensamblados se creaban "haciendo ajustes". Si unallave no encajaba en la cerradura, se ajustaba la cerradura de alguna manera para que permita el paso de lallave. Pioneros como Honore LeBlanc y Eli Whitney propusieron la idea de crear partes estandarizadas en elproceso de manufactura. Al establecer controles severos sobre la especificación y producción de las partescomponentes, se pudieron realizar masivas producciones de todo tipo de artículos. Sin embargo, esta erauna estandarización hacia dentro de las empresas. Pero para finales del siglo XVIII la idea ya se habíaexpandido entre los fabricantes y se produjeron todo tipo de estándares para las partes comunes. Habíatamaños y medidas para los artículos, con la expectativa de que aquellos producidos por una fábrica seríanintercambiables e interoperables con componentes similares y complementarios producidos por otra. Las







compañías que produjeron las partes con un alto grado de precisión tuvieron éxito; lo que tenían un procesomenos consistente, fracasaron (VerFigura 7 y Figura 8):

Figura 7: Bienes fabricados. Volver al texto. Figura 8: Datos estructura

Hoy en día aún tenemos estructuras de datos no estandarizadas. Cada aplicación modela la información a supropia manera y dependemos de operadores humanos para 'ajustar' las aplicaciones y así lograr integrarlas.Es necesario agregar semántica para hacer que las aplicaciones se entiendan. De la misma forma como elmercado demandó que se pudieran intercambiar artículos a finales de los '80, el mismo demandará elintercambio de datos en un futuro cercano. Esto significa estandarizar la funcionalidad de conceptos denegocio como un 'cliente' o una 'orden de compra'. Las organizaciones que no se percaten de las eficienciasde la integración-por-diseño perderán a la larga frente a los que persigan estas eficiencias. El resultado deeste cambio será un boom económico para las compañías que sobrevivan a él y un dramático mejoramientopara el diario vivir de las personas.

Ensamblados Fabricados - Empresas Virtuales

La mayoría de los fabricantes de bicicletas no producen llantas, de la misma forma como quienes hacencamisas no producen sus propios botones. Al crear ensamblados con los mejores componentes disponibles,los fabricantes de bicicletas pueden crear productos más sofisticados y de mayor calidad. La competenciaentre fabricantes de componentes conlleva eficiencias y mejoras en la calidad. Para lograr esto, necesitanespecificaciones detalladas de las partes componentes, así como deben también considerar el contexto en elque cada parte será usada. Las compañías de hoy en día están 'creando ensamblados' de su funcionalidad denegocios (Ver Figura 9). En lugar de crear un departamento de distribución y entrega, el trabajo se entregacomo outsourcing. En lugar de fabricar el producto, se delega la construcción del mismo a una compañíaque se especialice en producción de bajo costo y alta calidad. La definición de 'compañía' evoluciona(Ver Figura 10):























Figura 9: Ensamblados fabricados. Volver al texto. Figura 10: Empresas

Las comunicaciones de alta velocidad e información estructurada ofrecen beneficios similares, produciendola virtualización de las organizaciones. Se puede crear un modelo de componentes de negocio definiendo

claramente la semántica y requerimientos operacionales de nuestras capacidades de negocios. Al definirinterfaces claras, se puede encapsular los detalles de cómo estas capacidades son implementadas y cadacomponente puede ser orquestado como miembro de cualquier número de procesos. Se pueden inclusocrear proveedores especializados que ofrezcan servicios de marketing, ventas, producción, recursoshumanos, etc. Para lograr esto, se necesitan especificaciones detalladas de las capacidades de loscomponentes. Así, con estándares, se puede lograr la composición de cualquier cosa, porque losproveedores de componentes pueden manejar el costo de optimización a través de mercados amplios y lacompetencia conlleva cada vez mayores eficiencias.

Comercialización y Distribución - Procesos de Negocio A finales del siglo XIX los centros de comercio urbanos se habían desarrollado. Los bienes se habían vueltomás sofisticados y las opciones del consumidor habían aumentado. Sin embargo, el ir de compras era algotedioso. Un día de compras podía implicar el tomar el tren hacia la ciudad, luego ir donde el carnicero yluego donde el panadero, pasar comprando las verduras y por último una vuelta por la farmacia. Sinembargo, muy pronto la estandarización de los tamaños redujo significativamente el costo de muchosbienes permitiendo la producción masiva y la habilidad de transportar bienes a ubicaciones centrales para laventa y dieron origen a los centros comerciales y el supermercado. Así por ejemplo, Wal-Mart logró nuevaseficiencias al hacer primar el poder del comercio sobre los fabricantes. Wal-Mart logró proveer de unaexperiencia de compras placentera, de bajo costo y centralizada en un solo punto (Ver Figura 11):











Figura 11: Comercialización y distribución. Volver al texto. Figura 12: Proces

Examinando la situación actual de los procesos de negocios, podemos observar dos tipos de integración.Una de ellas se basa simplemente en enviar un fax y esperar que el mismo haya sido recibido y que tal veznos respondan. Otra técnica que reduce errores es la conocida integración ALT-TAB, la cual permite el usodel porta papeles para copiar datos entre aplicaciones. Pero si se quiere hacer algo realmente mejor, senecesita lograr el intercambio y estandarización de datos y operaciones. Los procesos de negocios aún sonhechos a mano y los estándares son muy pobres. En lo futuro, los procesos de negocios crecerán para ser lafuerza que le dé la forma y defina los estándares para las nuevas aplicaciones, de la misma forma como Wal-Mart impone los estándares para cientos y miles de artículos (Ver Figura 12).


4. Industrialización del Software a través de la Plataforma .net

La Plataforma .net representa una nueva etapa en la evolución de COM, la plataforma de componentes deMicrosoft. Con ella, Microsoft impulsa la idea de 'industrializar' el software utilizando tecnologías decomponentes (5) .

Las tecnologías COM y CORBA, equivalentes a la era industrial temprana, han logrado producir partesintercambiables básicas. El mayor avance de la Plataforma .net es la implementación de la parteintercambiable de software en la herramienta de desarrollo misma, de manera que cada 'parte' de softwarecreada es un componente intercambiable. Este es un avance equivalente a la etapa de 'línea de ensamblaje'de la industrialización. La plataforma en sí es análoga a una industria de creación de herramientas, la cualentrega a los vendedores de software ambientes especializados de desarrollo, conocidos también como'fábricas' para el ensamblaje eficiente de 'máquinas de software' basadas en servicios Web.

La tecnología de metadatos del Lenguaje Intermedio (IL) de .net, a través de la cual un compilador

automáticamente crea un 'plano' de la interacción de componentes en 'assemblies', nos recuerda las líneasde ensamblaje recientes, donde la unidad que está siendo ensamblada lleva consigo las instrucciones parasu creación. Clemens Szyperski (6) , arquitecto experimentado de Microsoft, confirma esta analogía:

El construir software ensamblando componentes conlleva grandes promesas para la ingeniería de softwarede la nueva generación. Yo iría más allá y aseguraría que no se puede hablar de ingeniería antes de haberdominado este paso ... Si no, se está hablando de hacer las cosas a mano, algo similar a la manufacturatemprana previa a la Revolución Industrial. Así que, es claro que deberíamos empezar a construir softwarebasado en componentes.

Estos 'planos' conocidos como metadatos representan la interfaz del componente, la clave para elintercambio e interoperabilidad, en términos de un 'contrato' que la interfaz hace con su infraestructura. Los

lenguajes de definición de contratos están en el límite de la ciencia de las computadoras.

Así, la plataforma .net se convierte en una implementación ejemplar que ya es parte de la RevoluciónIndustrial del Software que nos mencionaba Bill Gates (7)hace varios años ya:

... La Revolución Industrial del software está finalmente ante nosotros. La especialización de recursos,estándares para partes intercambiables, y herramientas de ensamblaje de última generación han sidousadas en otras industrias por cientos de años para acelerar el desarrollo de productos altamente

























complejos. A pesar de su ubicuidad, la aplicación de estos conceptos a la industria moderna del softwaresolamente ha empezando.


5. Fábricas de Software: el Nuevo Paradigma

Las Fábricas de Software son una iniciativa propuesta por Microsoft que plasma la necesidad y provee de losmedios para hacer la transición desde el 'hacer a mano' hacia la fabricación o manufactura. En sí, unaFábrica de Software es un ambiente de desarrollo configurado para soportar el desarrollo acelerado de untipo específico de aplicación. Las Fábricas de Software no son más que el siguiente paso lógico en laevolución continua de los métodos y prácticas de desarrollo de software; sin embargo, prometen cambiar elcarácter de la industria de software introduciendo patrones de industrialización (8) .

¿Es posible automatizar el desarrollo del software? En realidad, ya lo hemos hecho. Los editores WYSIWYGpor ejemplo, hacen mucho más fácil el construir y mantener interfaces gráficas de usuario, proveyendobeneficios como independencia de dispositivos y el ensamblaje visual. El diseño de base de datos ofreceformas similares de automatización. El tema recurrente que podemos observar en la creación de este tipo

de herramientas es el hecho de pensar en modelos, más que solamente en objetos (9) .

Uno de los elementos clave de este patrón es el elevar el nivel de abstracción de los desarrolladores.Actualmente usamos UML para la documentación. Sin embargo, lo que buscamos hoy en día es laproductividad. Mientras los estereotipos y los tags pueden ser usados para decorar modelos UML, laexperiencia muestra que se necesitan características más precisas del lenguaje para soportar compilación,depuración, pruebas y otros tipos de tareas de desarrollo.

Pero aún cuando los modelos juegan un rol importante, no lo son todo. Para llegar a niveles más altos deproductividad necesitamos la habilidad de configurar, adaptar y ensamblar rápidamente componentesdesarrollados independientemente, autodescriptivos e independientes de ubicación, para producir así familias de sistemas similares, pero diferentes. Para ello, será necesaria la creación de patrones con dominio

específico, frameworks y herramientas que se alineen tanto con la arquitectura del producto como con elciclo de vida del producto. Más aún, debemos considerar los procesos que usamos para analizarrequerimientos, desarrollar software y ponerlo en producción. Necesitamos disponer de las mejoresprácticas, contenido reutilizable y distintos tipos de patrones. La aplicación de todo esto en conjunto seconoce como Fábrica de Software.

Una fábrica de software es una línea de producto que configura herramientas de desarrollo extensiblescomo Microsoft Visual Studio Team System con contenido empaquetado y guías, cuidadosamente diseñadaspara construir tipos específicos de aplicaciones. Una fábrica de software contiene tres ideas básicas:

Un esquema de fabricación. La analogía de esto es una receta. En ella se listan ingredientes, comoproyectos, código fuente, directorios, archivos SQL y archivos de configuración, y explica cómo

deberían ser combinados para crear el producto. Especifica qué Lenguajes de Dominio Específico(DSL) pueden ser usados y describe cómo los modelos basados en estos DSLs pueden transformarseen código y otros artefactos, o en otros modelos. Describe la arquitectura de la línea de producto, ylas relaciones clave entre componentes y frameworks que la componen.

Una plantilla de fábrica de software. Esta es una gran bolsa de supermercado que contiene losingredientes listados en la receta. Provee los patrones, guías, plantillas, frameworks, ejemplos,herramientas personalizadas como herramientas para edición visual de DSLs, scripts, XSDs, hojas deestilos, y otros ingredientes para construir el producto.













Un ambiente de desarrollo extensible. Un ambiente como Visual Studio Team System es la cocina enla cual la comida es cocinada. Cuando se configura con una plantilla de fábrica de software, VisualStudio Team System se convierte en una fábrica de software para la familia de productos.

Si llevamos más allá la analogía, los productos son como comidas servidas en un restaurante. Los clientes dela fábrica de software son como los clientes que ordenan comidas de un menú. Una especificación de

producto es como una orden de comida específica. Los desarrolladores del producto son como cocinerosque preparan las comidas descritas en las órdenes, los cuales podrían modificar las definiciones de lascomidas, o preparar comidas fuera del menú. Los desarrolladores de la línea de producto son como chefsque deciden qué aparecerá en el menú, y qué ingredientes, procesos, y equipo de cocina se usará paraprepararlos.

Un ejemplo más concreto del uso de una fábrica de software sería el diseño de un esquema para laconstrucción de aplicaciones de clientes livianos para comercio electrónico usando el Microsoft .netFramework, C#, el Microsoft Business Framework, Microsoft SQL Server, Microsoft Biztalk Server y elMicrosoft Host Integration Server - una familia amplia pero muy útil de aplicaciones. Podríamos usar esteesquema de fábrica de software para configurar Visual Studio Team System para convertirse en una fábricade software que construya miembros de esta familia.

Para este ejemplo, el esquema de software podría contener un DSL que represente requerimientosconfigurables, un DSL para describir procesos de negocios, un DSL para describir modelos lógicos y físicos, unDSL para describir la navegación Web, y un DSL para describir entidades de negocio. Podríamos usar lascaracterísticas de extensibilidad de Visual Studio Team System para hostear una plantilla de fábrica desoftware basada en este esquema. En esa plantilla incluiríamos algunos bloques de aplicación liberados porel grupo de Microsoft Patterns and Practices, políticas de check-in de Team Foundation Server, estructurasde proyecto, la guía de proceso de Microsoft Solution Framework (MSF), entre otros. Con esta fábrica desoftware, el equipo de desarrollo podría rápidamente lanzar una variedad de aplicaciones de comercioelectrónico, cada una conteniendo características únicas basadas en requerimientos únicos de clientesespecíficos.

Las fábricas de software son posibles hoy en día y representan el intento de aprender de otras industriasque encaran problemas similares, y aplican patrones específicos de automatización a tareas de desarrollomanual existentes. Las fábricas de software vuelven más rápida, barata y fácil la construcción deaplicaciones, concretando así la visión de la industrialización del software moderno.


6. Conclusión

Tenemos la fortuna de presenciar el nacimiento de una nueva forma de hacer software, que traerábeneficios inmensos para todos. El desarrollo de software basado en componentes desde siempre fue laidea revolucionaria que nos llevó a pensar que sí era posible el construir software de calidad en cortotiempo y con la misma calidad que la mayoría de las industrias de nuestro tiempo. Al mirar hacia atrás,vemos los increíbles avances que hemos logrado en la comprensión de la forma correcta de reutilizar elsoftware y el conocimiento existente, y nos asombramos cada vez más al darnos cuenta de que este solo esel inicio.

El desarrollo de software basado de componentes se convirtió en el pilar de la Revolución Industrial delSoftware y se proyecta hoy en día en diversas nuevas formas de hacer software de calidad con los costosmás bajos del mercado y en tiempos que antes eran impensables. Empresas como Microsoft entendieron elpotencial de esta metodología hace años y hoy nos ofrecen nuevas iniciativas y herramientas que buscan






llevar al proceso de construcción de software hacia el sitial privilegiado en el que debió colocarse desde unprincipio.

Component-based software engineering

Component-based software engineering (CBSE) (also known as component-based development (CBD)) is abranch of software engineering that emphasizes the separation of concerns in respect of the wide-ranging

functionality available throughout a given software system. This practice aims to bring about an equally

wide-ranging degree of benefits in both the short-term and the long-term for the software itself and for

organizations that sponsor such software.

Software engineers regard components as part of the starting platform for service-orientation. Components

play this role, for example, inWeb services, and more recently, in service-oriented architectures (SOA),

whereby a component is converted by the Web service into aservice and subsequently inherits further

characteristics beyond that of an ordinary component.

Components can produce or consume events and can be used for event driven architectures (EDA).

Contents

[hide]

1 Definition and characteristics of components

2 History

3 Differences from object-oriented programming

4 Architecture

5 Technologies

6 References

7 See also

8 Further reading

9 External links

[edit]Definition and characteristics of components

An individual component is a software package, a Web service, or a module that encapsulates a set of related functions (or data).

All system processes are placed into separate components so that all of the data and functions inside each

component are semantically related (just as with the contents of classes). Because of this principle, it is

often said that components are modular and cohesive.

http://en.wikipedia.org/wiki/Software_engineering



http://en.wikipedia.org/wiki/Separation_of_concerns



http://en.wikipedia.org/wiki/Service-orientation



http://en.wikipedia.org/wiki/Web_services



http://en.wikipedia.org/wiki/Service-oriented_architecture



http://en.wikipedia.org/wiki/Event_driven_architecture



http://en.wikipedia.org/wiki/Software_componentry



http://en.wikipedia.org/wiki/Software_componentry#Definition_and_characteristics_of_components


http://en.wikipedia.org/wiki/Software_componentry#History


http://en.wikipedia.org/wiki/Software_componentry#Differences_from_object-oriented_programming


http://en.wikipedia.org/wiki/Software_componentry#Architecture


http://en.wikipedia.org/wiki/Software_componentry#Technologies


http://en.wikipedia.org/wiki/Software_componentry#References


http://en.wikipedia.org/wiki/Software_componentry#See_also


http://en.wikipedia.org/wiki/Software_componentry#Further_reading


http://en.wikipedia.org/wiki/Software_componentry#External_links


http://en.wikipedia.org/w/index.php?title=Component-based_software_engineering&action=edit&section=1



http://en.wikipedia.org/wiki/Modular_programming























With regard to system-wide co-ordination, components communicate with each other via interfaces. When

a component offers services to the rest of the system, it adopts a provided interface that specifies the

services that other components can utilize, and how they can do so. This interface can be seen as a signature

of the component - the client does not need to know about the inner workings of the component

(implementation) in order to make use of it. This principle results in components referred to

as encapsulated . The UML illustrations within this article represent provided interfaces by a lollipop-symbol

attached to the outer edge of the component.

However, when a component needs to use another component in order to function, it adopts

a used interface that specifies the services that it needs. In the UML illustrations in this article, used

interfaces are represented by an open socket symbol attached to the outer edge of the component.

A simple example of several software components - pictured within a hypothetical holiday-reservation system represented

in UML 2.0.

Another important attribute of components is that they are substitutable, so that a component can replace

another (at design time or run-time), if the successor component meets the requirements of the initial

component (expressed via the interfaces). Consequently, components can be replaced with either an

updated version or an alternative without breaking the system in which the component operates.

As a general rule of thumb for engineers substituting components, component B can immediately replace

component A, if component B provides at least what component A provided and uses no more than what

component A used.

http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming)



http://en.wikipedia.org/wiki/Unified_Modeling_Language






http://en.wikipedia.org/wiki/File:Component-based_Software_Engineering_(CBSE)_-_example_2.gif









Software components often take the form of objects(not classes) or collections of objects (from object-

oriented programming), in some binary or textual form, adhering to some interface description

language (IDL) so that the component may exist autonomously from other components in acomputer.

When a component is to be accessed or shared across execution contexts or network links, techniques such

as serialization or marshalling are often employed to deliver the component to its destination.

Reusability is an important characteristic of a high-quality software component. Programmers should design

and implement software components in such a way that many different programs can reuse them.

Furthermore, component-based usability testing should be considered when software components directly

interact with users.

It takes significant effort and awareness to write a software component that is effectively reusable. The

component needs to be:

fully documented

thoroughly tested

robust - with comprehensive input-validity checking

able to pass back appropriate error messages or return codes

designed with an awareness that it will be put to unforeseen uses

In the 1960s, programmers built scientific subroutine libraries that were reusable in a broad array of

engineering and scientific applications. Though these subroutine libraries reused well-defined algorithms in

an effective manner, they had a limited domain of application. Commercial sites routinely created

application programs from reusable modules written in Assembler, COBOL, PL/1 and other second-

and third-generation languages using both system and user application libraries.

As of 2010, modern reusable components encapsulate both data structures and the algorithms that are

applied to the data structures. It[clarification needed ]

builds on prior theories of software objects, software

architectures, software frameworks and software design patterns, and the extensive theory of object-

oriented programming and the object oriented design of all these. It claims that software components, like

the idea of hardware components, used for example in telecommunications, can ultimately be made

interchangeable and reliable. On the other hand, it is argued that it is a mistake to focus on independent

components rather than the framework (without which they would not exist).[1]

[edit]History

The idea that software should be componentized - built from prefabricated components - first became

prominent with Douglas McIlroy's address at the NATO conference on software

engineering in Garmisch, Germany, 1968, titled Mass Produced Software Components. The conference set

http://en.wikipedia.org/wiki/Object_(computing)



http://en.wikipedia.org/wiki/Class_(computer_science)



http://en.wikipedia.org/wiki/Object-oriented_programming




http://en.wikipedia.org/wiki/Interface_description_language




http://en.wikipedia.org/wiki/Computer


http://en.wikipedia.org/wiki/Serialization



http://en.wikipedia.org/wiki/Marshalling_(computer_science)



http://en.wikipedia.org/wiki/Reusability


http://en.wikipedia.org/wiki/Component-Based_Usability_Testing



http://en.wikipedia.org/wiki/Error_message



http://en.wikipedia.org/wiki/Subroutine



http://en.wikipedia.org/wiki/Algorithms



http://en.wikipedia.org/wiki/Assembly_language



http://en.wikipedia.org/wiki/COBOL



http://en.wikipedia.org/wiki/PL/1



http://en.wikipedia.org/wiki/Second_generation_language


http://en.wikipedia.org/wiki/Third_generation_language



http://en.wikipedia.org/wiki/Operating_system



http://en.wikipedia.org/wiki/Wikipedia:Please_clarify



http://en.wikipedia.org/wiki/Object_(object-oriented_programming)



http://en.wikipedia.org/wiki/Software_architecture




http://en.wikipedia.org/wiki/Software_framework



http://en.wikipedia.org/wiki/Software_design_pattern







http://en.wikipedia.org/wiki/Object_oriented_design



http://en.wikipedia.org/wiki/Electronic_component



http://en.wikipedia.org/wiki/Software_componentry#cite_note-0






http://en.wikipedia.org/wiki/Software



http://en.wikipedia.org/wiki/Douglas_McIlroy



http://en.wikipedia.org/wiki/NATO







http://en.wikipedia.org/wiki/Garmisch-Partenkirchen



http://en.wikipedia.org/wiki/Germany












































out to counter the so-called software crisis. McIlroy's subsequent inclusion of pipes and filters into

the Unix operating system was the first implementation of an infrastructure for this idea.

Brad Cox of Stepstone largely defined the modern concept of a software component.[2]

He called

them Software ICs and set out to create an infrastructure and market for these components by inventing

the Objective-C programming language. (He summarizes this view in his bookObject-Oriented Programming -

An Evolutionary Approach 1986.)

IBM led the path with their System Object Model (SOM) in the early 1990s. As a reaction, Microsoft paved

the way for actual deployment of component software with OLE and COM.[3]

As of 2010 many successful

software component models exist.

[edit]Differences from object-oriented programming

Proponents of object-oriented programming (OOP) maintain that software should be written according to a

mental model of the actual or imagined objects it represents. OOP and the related disciplines of object-

oriented analysis and object-oriented design focus on modeling real-world[citation needed ]

interactions and

attempting to create "nouns" and "verbs" that can be used in more human-readable ways, ideally by end

users as well as by programmers coding for those end users.

Component-based software engineering, by contrast, makes no such assumptions, and instead states that

developers should construct software by gluing together prefabricated components - much like in the fields

of electronics or mechanics. Some peers[who? ]

will even talk of modularizing systems as software components

as a new programming paradigm.

Some[who? ]

argue that earlier computer scientists made this distinction, with Donald Knuth's theory of

"literate programming" optimistically assuming there was convergence between intuitive and formal

models, and Edsger Dijkstra's theory in the article The Cruelty of Really Teaching Computer Science , which

stated that programming was simply, and only, a branch of mathematics.[4][5]

In both forms, this notion has led to many academic debates[weasel words]

about the pros and cons of the two

approaches and possible strategies for uniting the two. Some[who? ]

consider the different strategies not as

competitors, but as descriptions of the same problem from different points of view.[citation needed ]

[edit]Architecture

A computer running several software components is often called an application server. Using this

combination of application servers and software components is usually called distributed computing. The

usual real-world application of this is in e.g. financial applications or business software.

http://en.wikipedia.org/wiki/Software_crisis



http://en.wikipedia.org/wiki/Pipeline_(Unix)



http://en.wikipedia.org/wiki/Unix





http://en.wikipedia.org/wiki/Brad_Cox


http://en.wikipedia.org/wiki/Stepstone






http://en.wikipedia.org/wiki/Objective-C



http://en.wikipedia.org/wiki/IBM


http://en.wikipedia.org/wiki/System_Object_Model



http://en.wikipedia.org/wiki/Microsoft



http://en.wikipedia.org/wiki/Object_linking_and_embedding



http://en.wikipedia.org/wiki/Component_Object_Model


http://en.wikipedia.org/wiki/Software_componentry#cite_note-claims-2









http://en.wikipedia.org/wiki/Object-oriented_analysis




http://en.wikipedia.org/wiki/Object-oriented_design



http://en.wikipedia.org/wiki/Wikipedia:Citation_needed



http://en.wikipedia.org/wiki/Electronics



http://en.wikipedia.org/wiki/Mechanics



http://en.wikipedia.org/wiki/Wikipedia:Avoid_weasel_words



http://en.wikipedia.org/wiki/Programming_paradigm






http://en.wikipedia.org/wiki/Computer_scientist



http://en.wikipedia.org/wiki/Donald_Knuth



http://en.wikipedia.org/wiki/Literate_programming



http://en.wikipedia.org/wiki/Edsger_Dijkstra



http://en.wikipedia.org/wiki/The_Cruelty_of_Really_Teaching_Computer_Science



http://en.wikipedia.org/wiki/Mathematics

















http://en.wikipedia.org/wiki/Application_server



http://en.wikipedia.org/wiki/Distributed_computing












































[edit]Technologies

Business object technologies

Newi

Component-based software frameworks for specific domains

Earth System Modeling Framework (ESMF)

Component-oriented programming

Bundles as defined by the OSGi Service Platform

Common Component Architecture (CCA) - Common Component Architecture Forum [1],

Scientific/HPC Component Software

TASCS [2] - SciDAC [3] Center for Technology for Advanced Scientific Component Software

Eiffel programming language

Enterprise JavaBeans from Sun Microsystems (now Oracle)

Flow-based programming

Fractal component model [4] from ObjectWeb

MidCOM [5] component framework for Midgard and PHP

Oberon, Component Pascal, and BlackBox Component Builder

rCOS method of component-based model driven design [6] from UNU-IIST

SOFA component system [7] from ObjectWeb

The System.ComponentModel namespace in Microsoft .NET

UNO from the OpenOffice.org office suite

VCL and CLX from Borland and similar free LCL library.

Visual Basic Extensions, OCX/ActiveX/COM and DCOM from Microsoft

XPCOM from Mozilla Foundation

Compound document technologies

Active Documents in Oberon System and BlackBox Component Builder

Bonobo (component model), a part of GNOME

Fresco

KPart, the KDE compound document technology

Object linking and embedding (OLE)

OpenDoc

Distributed computing software components

.NET Remoting from Microsoft

9P distributed protocol developed for Plan 9, and used by Inferno and other systems.




http://en.wikipedia.org/wiki/Business_object_(computer_science)


http://en.wikipedia.org/wiki/Newi





http://en.wikipedia.org/wiki/ESMF



http://en.wikipedia.org/wiki/Osgi



http://en.wikipedia.org/wiki/Common_Component_Architecture


http://www.cca-forum.org/wiki



http://tascs-scidac.org/



http://www.scidac.gov/



http://en.wikipedia.org/wiki/Eiffel_(programming_language)


http://en.wikipedia.org/wiki/Enterprise_JavaBeans


http://en.wikipedia.org/wiki/Sun_Microsystems



http://en.wikipedia.org/wiki/Oracle_Corporation



http://en.wikipedia.org/wiki/Flow-based_programming


http://en.wikipedia.org/wiki/Fractal_component_model

http://fractal.ow2.org/



http://www.objectweb.org/



http://en.wikipedia.org/w/index.php?title=MidCOM&action=edit&redlink=1

http://www.midgard-project.org/documentation/midcom/



http://en.wikipedia.org/wiki/Midgard_(software)



http://en.wikipedia.org/wiki/PHP



http://en.wikipedia.org/wiki/Oberon_(programming_language)


http://en.wikipedia.org/wiki/Component_Pascal



http://en.wikipedia.org/wiki/BlackBox_Component_Builder



http://en.wikipedia.org/wiki/RCOS


http://rcos.iist.unu.edu/



http://www.iist.unu.edu/



http://en.wikipedia.org/wiki/SOFA_component_system

http://sofa.ow2.org/






http://en.wikipedia.org/wiki/Microsoft_.NET



http://en.wikipedia.org/wiki/Universal_Network_Objects


http://en.wikipedia.org/wiki/OpenOffice.org



http://en.wikipedia.org/wiki/Visual_Component_Library


http://en.wikipedia.org/wiki/Component_Library_for_Cross_Platform



http://en.wikipedia.org/wiki/Borland



http://en.wikipedia.org/wiki/Lazarus_(software)



http://en.wikipedia.org/wiki/Visual_Basic_Extension





http://en.wikipedia.org/wiki/Distributed_Component_Object_Model






http://en.wikipedia.org/wiki/XPCOM


http://en.wikipedia.org/wiki/Mozilla_Foundation



http://en.wikipedia.org/wiki/Compound_document


http://en.wikipedia.org/wiki/Oberon_(operating_system)






http://en.wikipedia.org/wiki/Bonobo_(component_model)


http://en.wikipedia.org/wiki/GNOME



http://en.wikipedia.org/wiki/Fresco_(computing)


http://en.wikipedia.org/wiki/KPart


http://en.wikipedia.org/wiki/KDE





http://en.wikipedia.org/wiki/OpenDoc




http://en.wikipedia.org/wiki/.NET_Remoting





http://en.wikipedia.org/wiki/9P


http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs



http://en.wikipedia.org/wiki/Inferno_(operating_system)


































http://en.wikipedia.org/wiki/SOFA_component_system










http://en.wikipedia.org/w/index.php?title=MidCOM&action=edit&redlink=1



http://en.wikipedia.org/wiki/Fractal_component_model


















CORBA and the CORBA Component Model from the Object Management Group

D-Bus from the freedesktop.org organization

DCOP from KDE (deprecated)

DCOM and later versions of COM (and COM+) from Microsoft

DSOM and SOM from IBM (now scrapped)

ICE from ZeroC

Java EE from Sun

Universal Network Objects (UNO) from OpenOffice.org

Web services

REST

Zope from Zope Corporation

Generic programming emphasizes separation of algorithms from data representation

Interface description languages (IDLs)

Open Service Interface Definitions (OSIDs)

Part of both COM and CORBA

Platform-Independent Component Modeling Language

SIDL [8] - Scientific Interface Definition Language

Part of the Babel [9] Scientific Programming Language Interoperability System (SIDL and Babel

are core technologies of the CCA and the SciDAC TASCS Center - see above.)

SOAP IDL from World Wide Web Consortium (W3C)

WDDX

XML-RPC, the predecessor of SOAP

Inversion of Control (IoC) and Plain Old C++/Java Object (POCO/POJO) component frameworks

Pipes and Filters

Unix operating system

http://en.wikipedia.org/wiki/CORBA


http://en.wikipedia.org/wiki/CORBA_Component_Model



http://en.wikipedia.org/wiki/Object_Management_Group



http://en.wikipedia.org/wiki/D-Bus


http://en.wikipedia.org/wiki/Freedesktop.org



http://en.wikipedia.org/wiki/DCOP







http://en.wikipedia.org/wiki/Component_object_model












http://en.wikipedia.org/wiki/Internet_Communications_Engine


http://en.wikipedia.org/wiki/ZeroC



http://en.wikipedia.org/wiki/Java_EE










http://en.wikipedia.org/wiki/Web_service


http://en.wikipedia.org/wiki/Representational_State_Transfer


http://en.wikipedia.org/wiki/Zope


http://www.zope.com/



http://en.wikipedia.org/wiki/Generic_programming


http://en.wikipedia.org/wiki/Open_Service_Interface_Definitions








http://en.wikipedia.org/w/index.php?title=Platform-Independent_Component_Modeling_Language&action=edit&redlink=1


https://computation.llnl.gov/casc/components/components.html



http://en.wikipedia.org/wiki/Babel_Middleware


https://computation.llnl.gov/casc/components/babel.html











http://en.wikipedia.org/wiki/SOAP




http://en.wikipedia.org/wiki/World_Wide_Web_Consortium



http://en.wikipedia.org/wiki/WDDX


http://en.wikipedia.org/wiki/XML-RPC


http://www.pocomatic.com/docs/whitepapers/ioc


http://en.wikipedia.org/wiki/Pipeline_(software)














http://en.wikipedia.org/wiki/SOAP


































Ingeniería de Software Basada en Componentes

Documents

Transcript of Ingeniería de Software Basada en Componentes