PDF de programación - Abstracción en el desarrollo de software independiente de la plataforma

Tesis de Ingeniería en Informática

Abstracción en el desarrollo
de software independiente de

la plataforma

Análisis del proceso de desarrollo de Cross-Platform Support

Middlewares

Autor: Patricio Zavolinsky (81.611)

([email protected])

Tutora: Lic. Adriana Echeverría

Tesis de Ingeniería en Informática

Índice

Índice

Introducción

1. Herramientas de análisis de un CPSM

1.1. Modelo formal
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2. Parámetros característicos de un CPSM . . . . . . . . . . . . . . . . . . . . . .
1.2.1. Flexibilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.2. Compatibilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.3. Mantenimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.4. Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.5. Performance
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.6. Relación entre los parámetros característicos de un CPSM . . . . . . . .
1.3. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2. Desarrollo de un CPSM

2.1. Características generales de un CPSM . . . . . . . . . . . . . . . . . . . . . . .
2.1.1. Selección de paradigma . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2. Selección del lenguaje de programación . . . . . . . . . . . . . . . . . .
2.1.3. Propósito del CPSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.3.1. Flexibilidad vs. Seguridad . . . . . . . . . . . . . . . . . . . . . . .
2.2. Definición de servicios provistos por el CPSM . . . . . . . . . . . . . . . . . . .
2.2.1. Especificación de las interfaces de cada servicio provisto por el CPSM .
2.3. Definición de plataformas compatibles con el CPSM . . . . . . . . . . . . . . .
2.4. Mecanismos de abstracción en un CPSM . . . . . . . . . . . . . . . . . . . . . .
2.4.1.
Implementaciones alternativas vs. implementaciones incompatibles . . .
2.4.2. Compilación selectiva . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.2.1. Compilación condicional
. . . . . . . . . . . . . . . . . . . . . . . .
2.4.2.2. Separación física . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.3. Selección de implementaciones alternativas de un servicio . . . . . . . .
2.4.4.
Inicialización y Finalización de servicios . . . . . . . . . . . . . . . . . .
2.5. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3. Caso de Estudio

3.1. Descripción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2. Definición del CPSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1. Especificación de las interfaces de los servicios provistos . . . . . . . . .
3.2.1.1. Comunicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1.2. Concurrencia
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1.3. Bibliotecas dinámicas . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1.4. Servicios comunes . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.2. Mecanismo de abstracción . . . . . . . . . . . . . . . . . . . . . . . . . .
Implementación del CPSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1. Comunicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.3.

Patricio Zavolinsky (81.611)

1

4

6
6
11
11
14
16
19
21
21
23

25
25
25
28
30
31
34
35
40
41
41
41
42
43
50
52
57

59
59
59
61
61
64
68
70
72
76
77

1

Tesis de Ingeniería en Informática

86
3.3.2. Concurrencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
3.3.3. Bibliotecas dinámicas
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.4. Servicios comunes
96
3.4. Desarrollo de un programa sustentado sobre el CPSM . . . . . . . . . . . . . .
96
3.4.1. Primer intento: Comunicaciones . . . . . . . . . . . . . . . . . . . . . . .
3.4.2. Segundo intento: Comunicaciones y Concurrencia . . . . . . . . . . . . .
99
3.4.3. Tercer intento: Comunicaciones, Concurrencia y Bibliotecas dinámicas . 103

4. Análisis y Comparación de CPSMs

121
4.1. Netscape Portable Runtime (NSPR) . . . . . . . . . . . . . . . . . . . . . . . . 121
4.2. ADAPTIVE Communication Environment (ACE)
. . . . . . . . . . . . . . . . 125
4.3. Simple DirectMedia Layer (SDL) . . . . . . . . . . . . . . . . . . . . . . . . . . 127
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
4.4. Boost
4.5. wxWidgets
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
4.6. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

5. Conclusiones y futuras líneas de estudio

133

Apéndice

136
A. Glosario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Referencias

138

Patricio Zavolinsky (81.611)

2

Tesis de Ingeniería en Informática

Resumen

Un programa, en relación a la plataforma que lo sustenta, debe enfrentar un desafío:
mantener su compatibilidad en el tiempo y el espacio. Es decir, permanecer compatible
con la plataforma que lo sustenta a pesar de la evolución de ésta (compatibilidad en el
tiempo), y ser compatible con la mayor cantidad de plataformas posible (compatibilidad
en el espacio).

La solución tradicional a este problema consiste en concentrar los detalles propios de la
plataforma en una capa de abstracción. El objetivo de esta capa es encapsular los detalles
de las interfaces de programación provistas por distintas plataformas, en una única interfaz
homogénea. Una capa de abstracción con estas características se denomina Middleware.

Un Cross Platform Support Middleware (CPSM) es un Middleware que garantiza que
la interfaz que provee se encuentra implementada en su totalidad en todas las plataformas
con las que es compatible.

El objetivo de esta tesis consistió en analizar las actividades involucradas, y los proble-

mas que frecuentemente se deben enfrentar, en el desarrollo de un CPSM.

Dentro de las conclusiones derivadas del análisis presentado cabe destacar la relevan-
cia del proceso de desarrollo de un CPSM y la reconstrucción de dicho proceso a partir
de ejemplos completos de CPSMs que constituyen evidencia empírica de la viabilidad de
construcción de los mismos.

Para el problema de inicialización y finalización de servicios se realizó un análisis de
diferentes alternativas: inicialización y finalización explícitas e implícitas. Para el caso par-
ticular de inicialización implícita se propuso una solución original que, bajo ciertas res-
tricciones, resuelve el problema a través de la creación una instancia estática de una clase
Initializer.

Para ilustrar el desarrollo de un CPSM, se implementó un CPSM completo, como ca-
so de estudio, que provee servicios de concurrencia, comunicaciones y asociación explícita
de bibliotecas dinámicas en Microsoft Windows y GNU/Linux. Adicionalmente se cons-
truyó una aplicación sustentada sobre dicho CPSM que permite abstraer la interacción
propia de una aplicación cliente/servidor (i.e. el protocolo de comunicaciones) de el esta-
blecimiento de la conexión (sobre TCP/IP). En conjunto, dicha aplicación y el CPSM del
caso de estudio ejemplifican el proceso de desarrollo y la posterior utilización de un CPSM.

Patricio Zavolinsky (81.611)

3

Tesis de Ingeniería en Informática

Introducción

El 14 de Octubre de 1987, Henry Spencer publicó sus “Diez Mandamientos para los Pro-
gramadores C” en el grupo de noticias comp.lang.c[Spe87]. El décimo mandamiento ordenaba:

Thou shalt foreswear, renounce, and abjure the vile heresy which claimeth that “All
the world’s a VAX”, and have no commerce with the benighted heathens who cling
to this barbarous belief, that the days of thy program may be long even though the
days of thy current machine be short.1

Poco más de tres años más tarde, Spencer actualizó sus Mandamientos. En la versión

Anotada de 1990[Spe90], agregó la siguiente nota al décimo mandamiento:

This particular heresy bids fair to be replaced by “All the world’s a Sun” or “All
the world’s a 386” (this latter being a particularly revolting invention of Satan),
but the words apply to all such without limitation. Beware, in particular, of the
subtle and terrible “All the world’s a 32-bit machine”, which is almost true today
but shall cease to be so before thy resume grows too much longer.2

Al margen del tono jocoso en el cual está formulado, el décimo mandamiento denuncia una
preocupación que hoy en día no ha perdido vigencia. Los programas se sustentan sobre sistemas
operativos, los sistemas operativos sobre arquitecturas de hardware. Todo aquello sobre lo que
se construye un programa es considerado parte de la “plataforma”. Un programa, en relación
a la plataforma que lo sustenta, debe enfrentar un desafío: mantener su compatibilidad en el
tiempo y el espacio. Es decir, permanecer compatible con la plataforma que lo sustenta a pesar
de la evolución de ésta (compatibilidad en el tiempo), y ser compatible con la mayor cantidad
de plataformas posible (compatibilidad en el espacio).

El primer aspecto del desafío consiste en sobrevivir a las modificaciones en la plataforma
subyacente, puntualmente, a modificaciones en las interfaces de programación (APIs) de la
plataforma, como consecuencia de la evolución. El segundo, consiste en poseer compatibilidad
con más de una plataforma. Una motivación para buscar este tipo de compatibilidad es au-
mentar los usuarios potenciales del programa, a todos los usuarios de las plataformas con las
que el programa es compatible. En sistemas distribuidos, una motivación adicional es mejorar
la tolerancia a fallos (i.e. fault tolerance), utilizando redundancia heterogénea, ya