PDF de programación - Adaptación y Reutilización de Componentes Distribuidos

Adaptación y Reutilización de Componentes Distribuidos

M. Katrib

Facultad de Matemática y

Computación.

Universidad de la Habana

[email protected]

E. Pimentel

E.T.S.I. Informática.

Universidad de Málaga

[email protected]



J.L. Pastrana

E.T.S.I. Informática.
Universidad de Málaga
[email protected]

Resumen



En el desarrollo de sistemas distribuidos a partir de componentes existentes, los requisitos funcionales y no-
funcionales están situados, tradicionalmente, en el servidor. Esto dificulta la reutilización de componentes y
la posibilidad de componer o agregar componentes en tiempo de ejecución. Este trabajo muestra cómo
partiendo de la metáfora de "Diseño por Contrato" se ha desarrollado una metodología y una herramienta,
para la composición, coordinación y adaptación de componentes. La idea central es: "El Cliente sabe cómo
quiere que se comporte el servidor" y establecerá sus propiedades no-funcionales. Los conectores, al ser
componentes, podrán utilizar técnicas clásicas de reutilización (herencia, composición, delegación). Además,
permitirán que se les suministre una ontología (en formato XML) del dominio del problema. Así, se puede
realizar una adaptación dinámica de los servicios en tiempo de ejecución. La implementación de los
conectores se basa en WebServices lo que propicia un acceso vía en protocolos estándar.

1. Introducción
La tecnología actual en ingeniería del software soporta el desarrollo de aplicaciones basadas en componentes.
Sin embargo, este soporte se basa sólo en que son meras interfaces sintácticas que no expresan (salvo a veces
textualmente o como comentarios) su comportamiento, salvo lo que puede inferirse de los tipos que se utilizan
en estas interfaces.
Por otra parte, problemas habituales como el desarrollo en equipo de sistemas software, el reemplazo de
partes de una aplicación e incluso la venta o alquiler de componentes software requieren de una definición
semántica o del comportamiento de los componentes, la interacción y coordinación entre componentes, etc., y
esta información no es posible de deducir sólo a partir de la definición sintáctica del componente.
Además, existen bastante problemas en el diseño e implementación de componentes para sistemas abiertos
debido a sus características de evolución y dinamicidad, ya que la vida de un componente por lo general es
menor que la vida del sistema. Estos problemas deberían ser resueltos si se aspira a la quimera de tener un
mercado de venta y alquiler de componentes donde los desarrolladores sólo tengan que tomar los
componentes e insertarlos en sus aplicaciones para ponerlas a trabajar.
Los diseñadores de componentes conocen la funcionalidad del componente (lo que hace) pero no tienen por
qué tener información sobre el contexto en que van a ser usados o de los usuarios que los usarán. Por lo tanto,
es muy deseable la existencia de una clara separación entre los aspectos funcionales del componente y otros
requisitos no funcionales, tales como la sincronización, coordinación, persistencia, replicación, adaptación,
distribución, tiempo real, etc.

1.1 Definiciones previas
Antes de comenzar, es conveniente fijar ciertos criterios y definiciones que serán usados a lo largo de este
trabajo. Llamaremos “sistema” a un conjunto de herramientas y mecanismos que permiten crear e
interconectar componentes software además de a un conjunto de servicios que ayudan a la ejecución de
dichos componentes. Diremos que un sistema es “independientemente extensible” [SZY 96] cuando se puede
extender (añadirle componentes o funcionalidad) dinámicamente, así como combinar las extensiones
desarrolladas por diferentes entidades sin que haya conocimiento mutuo. El interfaz de un componente será
una definición sintáctica de los servicios (operaciones, tipos y parámetros) que ofrece un determinado
componente que actúa como servidor (y que a su vez puede ser cliente de cualquier otro componente).
Entenderemos por componente una unidad software binaria (ejecutable por una máquina) que puede ser
insertada en un sistema y puesta a trabajar. Se pueden establecer siete criterios que caracterizan un compoente
[SZY 00]:


Incluyen una especificación de todas las dependencias.
Incluyen una precisa especificación de la funcionalidad que ofrece.

1. Pueden ser usados por otros elementos Software (Clientes).
2. Pueden ser usados por clientes sin la intervención de sus desarrolladores.
3.
4.
5. Sólo pueden ser usados basándose en su especificación.
6. Es componible con otros componentes.
7. Pueden ser integrados rápida y suavemente en un sistema


1.2 Reutilización de componentes
A la hora de reutilizar componentes para diseñar nuevos sistemas se nos plantean diversas dudas: ¿cómo
podemos asegurar el correcto funcionamiento de un componente? ¿Qué ocurre si un componente se comporta
de una manera inesperada bien sea por un mal uso o por un malfuncionamiento? Por lo tanto, necesitamos ser
capaces de determinar cuándo y cómo podemos usar un cierto componente en un determinado contexto. Sería
deseable tener una especificación del componente que nos dijera qué hace el componente. Tal especificación
debería ofrecer parámetros que nos permitieran validar y verificar el comportamiento del componente
suministrándonos un contrato entre el componente y sus usuarios.
La metáfora de Diseño por Contrato [MEY 97], se basa en considerar un sistema como un conjunto de
componentes que colaboran del mismo modo que se realizan los negocios en la vida real: a través de contratos
que regulan explícitamente las obligaciones y beneficios de cada parte.
Un trabajo previo [KAT 03] demuestra que dicha metáfora es una metodología factible y elegante para el
desarrollo de software. En esta línea, Beugnard [BEU 99] establece cuatro niveles de contratos entre
componentes: El primer nivel, básico o contrato sintáctico, es imprescindible para que el sistema funcione y
se corresponde con la interfaz del componente. El segundo nivel se corresponde a los contratos de
comportamiento. Este tipo de contratos aumenta el nivel de confianza del componente en un contexto
secuencial. El tercer nivel, o contratos de sincronización, aumenta el nivel de confianza del componente en un
contexto distribuido. Y el cuarto nivel, o contratos de calidad del servicio, cuantifica la calidad de los
servicios y habitualmente es negociable por las partes.
Los trabajos mencionados nos hacen pensar que las interfaces de los componentes deberían ser enriquecidas
con contratos que modelen los requisitos externos del componente, su sincronización y su reacción o
comportamiento en caso de fallo. Sin embargo, esta aproximación supone cambios en la implementación de
los componentes, los cuales hemos considerado como cajas negras y cuyo código, seguramente, no tengamos
disponible. Además, la respuesta a otros problemas, tales como escalabilidad y cambios de requisitos durante
la vida del sistema, quedan resueltos con un diseño basado en la composición de componentes
interconectados, de la misma manera que ocurre en la mayoría de los sistemas en otros campos como la
electrónica.
Este trabajo propone la definición de conectores extendiendo la semántica de la metáfora de Diseño por
Contrato con el fin de poder expresar el comportamiento adicional requerido por un cliente. Dichos
conectores serán componentes activos (que tienen un estado persistente) que permitirán la definición de
requisitos no funcionales del componente servidor, así como el comportamiento del mismo en caso de
incumplimiento de dichos requisitos expresados vía contratos. Denominaremos a esta metodología
“Desarrollo del Software Orientado al Cliente”.
A lo largo de la sección 2 presentaremos la metodología de desarrollo de “Desarrollo de Software Orientado
al Cliente”, así como un análisis de su necesidad, ventajas, inconvenientes y posibilidades. En la sección 3
mostraremos un ejemplo ilustrativo del uso de los conectores en un problema como puede ser la coordinación
de jugadores en el ajedrez. El apartado número 4 mostrará una de las bondades más significativas de este
trabajo que es la capacidad de adaptación de servicios en tiempo de ejecución. El punto 5 nos dará detalles a
cerca de la implementación de los conectores y por último, se hará una discusión sobre trabajos relacionados e
ideas de futuro, para terminar con las referencias bibliográficas usadas.

2 Desarrollo de software orientado al cliente

La Ingeniería del Software basada en componentes se ocupa del desarrollo de sistemas compuestos de partes
reutilizables (componentes), el desarrollo de dichos componentes, así como el mantenimiento y mejora de los
sistemas mediante el reemplazo o adaptación de componentes.

El desarrollo de sistemas a partir de componentes, así como el desarrollo de componentes que puedan ser
utilizados para componer sistemas, requiere el uso de una metodología establecida y unos procesos, no sólo
relacionados con las fases de desarrollo y mantenimiento sino con el ciclo de vida completo, incluyendo
aspectos organizacionales, legales, de marketing, etc.
Esta propuesta presenta una metodología, así como una herramienta asociada para el desarrollo de sistemas
software basados en la composición de componentes ya existentes. Esta herramienta genera automáticamente
todo el código del conector deseado a partir de la especificación del mismo mediante la extensión de la
interfaz del componente servido