PDF de programación - Implementación y Sincronización de Objetos Separate en Java

Implementación y Sincronización de Objetos Separate

en Java

M. Katrib, E. Pimentel, J.L.Pastrana

[email protected] , (ernesto, pastrana)@lcc.uma.es

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

E.T.S.I.Informática. Universidad de Málaga

Abstract. El siguiente trabajo, enmarcado en el contexto de objetos y
componentes, presenta una propuesta para la implementación y sincronización
de objetos separate en Java basada en la metáfora de Diseño por Contrato,
introducida por Meyer. A lo largo del mismo se expondrán las características de
la propuesta, así como determinados detalles de implementación y su posible
aplicación en lenguajes de definición de interfaces (IDL) para permitir el
desarrollo de componentes más robustos, correctos y tolerantes a fallos.

1 Introducción

Muchos de los sistemas software que se desarrollan hoy en día, están basados en el
paradigma de la orientación a objetos y son intrínsecamente distribuidos, por lo tanto,
podemos ver nuestro sistema como un conjunto de objetos que cooperan e interactúan
entre sí para lograr un objetivo común. Las tendencias actuales en la ingeniería del
software se basan en la construcción de software mediante la integración de objetos
y/o componentes. Meyer en su libro Construcción de Software Orientado a Objetos
presenta la metáfora de Diseño por Contrato[1] como una metodología para el desarrollo
de software orientado a objetos. Dicha metáfora se basa en considerar un sistema
como una colección de componentes que colaboran del mismo modo en que lo hacen
los negocios que tienen éxito: respetando unos contratos que definen explícitamente
las obligaciones y beneficios que incumben a cada una de las partes. La idea central
de este trabajo consiste en el uso de la metáfora del contrato para la integración y
sincronización de objetos y/o componentes que se encuentren en diferentes
procesadores lógicos y a los que llamaremos objetos separate[1].
Los términos en que se establecerán los contratos serán expresados mediante asertos
de tres tipos: precondiciones, postcondiciones e invariantes. Cada método ofrecido
por una clase y ejecutado a través de sus objetos exige el cumplimiento de una
condición (precondición) por parte del cliente y a cambio garantiza una condición
(postcondición) que se cumplirá al terminar la ejecución del servicio. Además de estos
“contratos particulares” entre cada servicio de la clase proveedora y la clase cliente, la
clase proveedora asegura un invariante o condición que será satisfecha por los objetos
de la clase proveedora cada vez que se relacionen con la clase cliente.

En este trabajo extenderemos la semántica del contrato de manera que pueda ser usada
para garantizar la sincronización de objetos separate con las características esenciales
de exclusión mutua, equitabilidad (cualquier objeto que desee acceder a un objeto de
sincronización debe ser capaz de hacerlo en un intervalo finito de tiempo) y ausencia
de bloqueos basándonos en el trabajo realizado para hebras en el contexto del
lenguaje Java: Synchronizing Java threads using assertions [2].

2 Objetos Separate

Un objeto separate (que puede ser definido en Java como un objeto de una clase que
implementa un determinado interfaz llamado Separate) es un objeto que será
gestionado por otro procesador (físico o lógico). Nuestro trabajo asumirá que dicho
objeto existe y está activo. Será entonces el sistema (un demonio o gestor de objetos)
el que se encargue de su enlace y/o activación. Como restricción a los objetos
Separate impondremos que dichos objetos tendrán sus atributos como privados y sólo
podrán ser consultados/modificados por sus métodos. Esta restricción, a parte de ser
una recomendación metodológica general en la ingeniería de objetos, nos permitirá
poder asegurar la consistencia del estado de los objetos, ya que sus atributos no
podrán ser modificados directamente sin el cumplimiento de los contratos que se
impongan.

3 Objetos de Sincronización

Un objeto especial (que implementa un interfaz Synchronizable) será el encargado de
sincronizar los diferentes separate que actúan en nuestro sistema. El comportamiento
de dicho objeto es comparable al de un token que da acceso a un recurso compartido
en sistemas distribuidos pero con la característica añadida de que el propio recurso
está encapsulado en el
token. Estos objetos de sincronización pueden ser
implementados mediante JavaSpace [7], herramienta que nos sirve para el intercambio
de los objetos de sincronización, garantizándonos su acceso en exclusión mutua.

4 Semántica del Contrato: Asertos

En la semántica definida para el contrato se establecen una serie de asertos
(precondiciones, postcondiciones e invariantes), que definen los términos del mismo.
A continuación pasaremos a definir dichos asertos, expresando la semántica que
queremos asociar a cada uno de ellos:

Precondiciones: Se definen para los métodos. Establecen las obligaciones que debe
cumplir el cliente para que el servicio sea garantizado. El incumplimiento de las
mismas tendrá una doble semántica según afecte o no a un objeto de sincronización: el

incumplimiento de una precondición (o una parte la misma) que no afecta a objetos de
sincronización provocará un fallo en la llamada (excepción) que podrá ser recuperado.
Por otra parte, el incumplimiento de una precondición de un objeto de sincronización
implicará la suspensión del objeto que intenta validarla (llamante) hasta que dicha
precondición sea cierta. Esta doble semántica en las precondiciones nos sirve para
poder expresar las necesidades de sincronización de una manera cómoda, elegante y
formal. Pensemos por ejemplo en un típico problema de productor consumidor con la
restricción (para ilustrar mejor la diferencia entre ambas semánticas) de que los
objetos producidos/consumidos son números enteros entre 1 y 1000. Tanto el
productor como le consumidor son separate que ven a un objeto de sincronización
que es un buffer acotado que puede tener una interfaz como la siguiente:

interface buffer implements Synchronizable

Invariant: (numberOfElements() >=0)&& (numberOfElements() <=100)

{ boolean isEmpty();

boolean isFull();

int numberOfElements();

void Put(int x);

Require: (x>0)&&(x<=1000)&&(!this.isFull())

Ensure: (!isEmpty())

int Get();

Require: (!this.isEmpty())

Ensure: (!this.isFull())

}

podemos ver fácilmente que, por ejemplo, la llamada por parte del productor a un
método “Put” con un argumento negativo supone el incumplimiento de una de las
condiciones del contrato y debe producir un fallo en la llamada. Sin embargo, el que
el buffer esté lleno no es “culpa” del productor, es simplemente una condición de
sincronización y su efecto será la suspensión del productor hasta que el buffer deje de
estar lleno.

Postcondiciones: Se definen para los métodos. Establecen las obligaciones que debe
cumplir la clase proveedora tras la finalización del servicio. El incumplimiento de las
mismas provocará un fallo en la llamada (excepción) que podrá ser recuperado.

Invariantes: Se definen para las clases. Establecen las propiedades que debe cumplir
todo objeto de dicha clase para que esté en un estado consistente. Serán añadidas a la
precondición y postcondición de cada método ya que éste es el único mecanismo para

modificar el estado de un objeto. El incumplimiento de las mismas provocará un fallo
en la llamada (excepción) que podrá ser recuperado.

Sentencias de Rescate: Permitirán recuperar un fallo, su objetivo es retornar al objeto
a un estado consistente por lo que siempre deberán terminar con un retry (reintentar la
llamada) o con un fail (fallar la llamada, lo que supondrá elevar la excepción al
llamante). Se incluirán automáticamente sentencias de rescate “por defecto” para los
asertos que serán las siguientes:

Precondiciones: this.fail()
Postcondiciones: this.OldState() ; this.fail()
Invariantes: this.OldState() ; this.fail()

Donde el método, OldState retorna el objeto al estado anterior a efectuar la llamada.
Esto se ve justificado porque la recuperación de una violación del invariante o de la
postcondición debería dejar el objeto en un estado consistente.

5 Semántica de la Invocación a un Separate

Podemos distinguir entre dos tipos de invocaciones a un objeto separate: órdenes y
consultas. La ejecución de una orden: x.f(a), espera a que se evalúe la precondición de
f. En ese momento podemos asegurar que el cliente va a ser servido por lo que puede
proseguir con su cómputo. En el caso de la ejecución de una consulta, y = x.f(a), se
produce una espera por necesidad. y el objeto actual no podría proseguir con su
cómputo hasta que no haya recibido el valor. Esto supone una pérdida del rendimiento
que podemos alcanzar mediante el uso de sistemas distribuidos, por lo que hemos
realizado una implementación “perezosa” en la que una vez validada la precondición
de la llamada, se proseguirá con el cómputo, invocando un método del tipo “dame el
valor de la llamada” justo antes de usar ‘y’ o finalizar su ámbito. Todo esto realizado,
obviamente, de forma transparente al diseñador de la clase.

6 Conclusiones y Trabajos Futuros.

Nuestro trabajo presenta una propuesta de implementación y sincronización de los
objetos Separate de Meyer en Java. Dicho trabajo se enmarca en el ámbito de la pro-
gramación distribuida orientada a objetos nos permite utilizar la semántica definida
por Meyer para garantizar la interoperabilidad semántica y/o de protocolos entre
objetos.
Se pretende como trabajos futuros caminar en dos direcciones: por un lado, la i