PDF de programación - Compositor: Una herramienta para la generación de conectores

COMPOSITOR: Una Herramienta para la Generación

de Conectores

Jose Luis Pastrana, Ernesto Pimentel

Departamento de Lenguajes y Ciencias de la Computación

ETSI Informática, Universidad de Málaga

Málaga, España

{pastrana,ernesto}@lcc.uma.es

trabajo presenta

Abstract— El siguiente
la herramienta
COMPOSITOR (proyecto financiado por la iniciativa FEDER
TIN2008-05932) que ha sido desarrollada para la generación de
conectores que
implementan el modelo de composición y
coordinación de componentes software que ha sido desarrollado
por los autores de la misma y presentado en [1]. El modelo está
basado en el uso de conectores que son definidos por el cliente de
un componente servidor,
los cuales usan contratos para
especificar los requerimientos no funcionales deseados por el
cliente (tales como sincronización o calidad de servicio). Los
conectores, además, usan una ontología del dominio del servidor
para poder realizar adaptación dinámica de las invocaciones a un
servicio en tiempo de ejecución, en el caso de que se produzca
algún cambio o actualización en el componente que proporciona
los servicios.

Keywords-component; Herramienta, Conectores, Composición,

componentes software, adaptación, ontología

I.

INTRODUCCÓN

El desarrollo de software basado en componentes es un
proceso que consiste en la definición, implementación e
integración y composición de componentes independientes en
el sistema. El objetivo que reside bajo este proceso es el de
reutilizar componentes ya existentes en lugar de reinventar o
re-implementar componentes software. Las actividades que se
realizan en las diferentes fases de este desarrollo del software y
que pueden observarse en Fig. 1 son:

Requisitos: La primera fase consiste en el análisis y
especificación de los requisitos funcionales y no-funcionales de
nuestro sistema.

Diseño del Sistema: En esta fase se organiza el sistema en
módulos, componentes, clases u otras unidades, así como el
comportamiento y las responsabilidades de cada unidad y la
interacción y colaboración entre ellas. Esta fase depende de la
disponibilidad de componentes previos y el diseñador debe
determinar qué unidades van a ser implementadas y cuáles van
a reutilizar componentes ya existentes.

Implementación y Pruebas Unitarias: En un caso ideal,
toda la aplicación sería construida integrando y conectando
componentes ya existentes. Sin embargo, generalmente hay
que implementar algunas unidades que deben ser testeadas
previamente a su integración en el sistema (test unitarios).



Miguel Katrib

Departamento de Computación

F. Matemática y Computación, Universidad de la Habana

La Habana, Cuba

[email protected]

Selección de Componentes: En esta fase se seleccionan los
componentes que implementan algunas de las unidades. Cada
componente debe ser individualmente adaptado y testeado (test
unitario).

Integración del Sistema: El proceso de integración incluye
la integración de la infraestructura estándar de componentes, de
los componentes desarrollados y de
los componentes
reutilizados y adaptados.

Verificación y Validación del Sistema: Aquí se usan

técnicas estándar de validación y verificación.

Operaciones de Soporte y Mantenimiento: los procesos
de soporte y mantenimiento incluyen la modificación o
reemplazo de servicios ya existentes y que presentan
problemas.

Requisitos


Prueba Sistema



Diseño del Sistema



Integrar Sistema



Operaciones de
Mantenimiento



Implementación Unidades



Prueba unitaria



Selección de
Componentes



Adaptar
Servicios

Figura 1. Proceso de desarrollo de un sistema



La herramienta desarrollada permite la implementación del
modelo de conectores [1] que es usado para la adaptación de
los servicios de los componentes reutilizados mediante la
especificación de los requisitos no-funcionales y de calidad de
servicio (sincronización, rendimiento, seguridad, fiabilidad,
etc.) deseados por el cliente de los mismos, así como el uso de
una ontología del dominio del componente que ofrece los
servicios para poder realizar adaptación semántica de las
llamadas en tiempo de ejecución. Lo que resulta bastante útil si
hay que modificar o cambiar algún componente en la fase de
mantenimiento.



Todas

las

restricciones

impuestas al servidor son
establecidas como contratos (precondiciones, postcondiciones e
invariante) que son representados por expresiones lógicas. El
conector, comprobará el invariante y la precondición de un
servicio antes de ejecutarlo y la postcondición y el invariante
después de hacerlo. El conector también puede ejecutar un
conjunto de sentencias en el caso de que algún contrato falle.
De esta forma, el cliente puede modelar el comportamiento que
desee del servidor y qué hacer en el caso de que esos
requerimientos fallen (Fig. 3).

Una importante diferencia entre nuestro modelo y el
modelo presentado por la propuesta de Meyer [2] (como puede
verse en el diagrama de actividad de la Fig. 3) es que en
nuestro modelo un servicio no falla cuando se incumple un
contrato, sino que se ejecuta un conjunto de acciones para
reparar esa situación y continuar con la ejecución del servicio.

Esta diferencia mejora el modelo de contrato permitiendo al
cliente expresar el comportamiento deseado en vez de fallar la
llamada.

En la sección 2 se presenta el modelo propuesto, así como
las características del mismo y cómo se implementan en la
herramienta. La sección 3 muestra un ejemplo de un sistema
gestor de artículos de un congreso. La sección 4 muestra
detalles de implementación y finalmente la sección 5 presenta
las conclusiones y trabajos futuros.

II. EL MODELO PROPUESTO Y SU DESARROLLO CON

COMPOSITOR

Una de las tareas esenciales en el desarrollo de software
basado en componentes (como puede verse en la Fig. 1) es
encontrar el componente adecuado que ofrece la funcionalidad
e
interfaz deseada. Una vez que el componente es
seleccionado, el modelo propuesto usa un conector para
adaptar el comportamiento y los requisitos no-funcionales
deseados por el cliente sin modificar el componente servidor.
Esta adaptación (Fig. 2) conlleva la definición (o selección de
una existente) de una ontología del dominio del componente
servidor, definir el invariante deseado para el componente y
qué acciones se deben realizar en caso de que sea violado y
definir las precondiciones y postcondiciones deseadas para
cada servicio ofrecido por el componente y las acciones a
realizar en caso de fallo de las mismas.

Un conector es un servicio web que media entre el
componente cliente y el componente servidor, por lo que no
trata de modificar ni alterar ninguna parte interna del servidor.
El conector será un componente encargado de manejar,
conectar y adaptar el comportamiento del servidor para un
cliente determinado. Por lo que un cliente que desee obtener los
servicios de un componente servidor podrá utilizar un conector
ya implementado que tenga el comportamiento por él deseado
o bien definir un nuevo conector para dicho servidor con el
comportamiento que él mismo desee.

Figura 3. Diagrama de modelo de actividad de un conector



Lo primero que debemos hacer una vez seleccionado el
componente servidor que queramos es cargar su interfaz en la
herramienta. Dicho componente servidor podrá ser un
componente binario (tipo DLL) o un servicio web. Para ello, la
herramienta nos ofrece en el menú de componentes (Get
Component) la opción de obtener la interfaz de un servicio web
dada su url (WebService) o bien la interfaz de un componente
binario (DLL, Corba, Others), como puede observarse en la
Fig. 4.



Figura 2. Proceso de adaptación de un componente



características de QoS. Además, se podrá especificar otros
componentes (o conectores) externos que vayan a ser usados en
el contexto de la aplicación y que quieran usarse como parte de
los contratos usando las sentencias external.

componentes

Es importante notar que un conector puede ser usado por
varios
clientes que deseen un mismo
comportamiento del componente servidor, al igual que un
mismo componente servidor puede ser usado al mismo tiempo
por varios clientes que deseen un comportamiento distinto, a
través de conectores distintos. A continuación se mostrará la
sintaxis y la semántica de las diferentes funcionalidades
predefinidas:

Componentes Externos (external at): Expresan las
dependencias externas del componente. Nos permiten asegurar
que todos los componentes externos están disponibles y poder
usarlos como parte de los contratos. Los componentes externos
serán implementados como referencias remotas que estarán
activas durante la vida del conector.

Sintaxis: external <type> <name> at <url>;

Ejemplo: external PayService pp

at "http://.../pay.asmx";

Figura 4. Carga de la Interfaz de un Componente



Una vez cargada la interfaz del componente en la
herramienta habría que añadir el invariante, el comportamiento
no funcional y de calidad de servicio (QoS) deseado para cada
servicio (contratos) además de la ontología del dominio del
componente servidor, la cual es traducida a cláusulas de Horn
escritas en Prolog y que será utilizada para realizar la