trabajo fin de carrera straight skeletons · completa del tejado que apoya, de manera uniforme, su...

Universidad Politécnica de Madrid

Facultad de Informática

TRABAJO FIN DE CARRERA

STRAIGHT SKELETONS

AUTOR: José M. Migoya Elduayen

TUTOR: Manuel Abellanas Oar

A la memoria de mi abuelo Joaquín

Agradecimientos

En primer lugar, quisiera agradecer a mis padres su apoyo y entrega total a lo

largo de toda la carrera, incluyendo sus ánimos y regañinas, lo que me ha llevado a

poder concluir con la realización de este proyecto. Ellos, que son mi mayor apoyo y a

los que debo absolutamente todo, espero sepan leer entre estas líneas cuanto les quiero y

admiro.

A mis hermanas Ana y Laura, a mis cuñados Miguel y Alberto y a mis sobrinas

Aitana y Ariadna, que me ayudaron y animaron mucho más de lo que ellos puedan

pensar. Todos ellos son los responsables de mis sonrisas en los malos momentos.

A mis compañeros Javi, Carlos, Santi, Yago e Isma por su amistad, apoyo,

trabajo y compañerismo durante toda la carrera, ellos han hecho que todos estos años

tengan otro sentido para mí.

A todos mis amigos, en especial a Kike, Eu, Sergio, Luisma, David, JuanJo y

Laura, que, con su mano en mi hombro, me han aportando lo mejor de cada uno de ellos.

Gracias de corazón.

Por último, y no por ello menos importante, quisiera agradecer a mi tutor de

proyecto, Manuel Abellanas, su trabajo, esfuerzo y dedicación. Además, quiero destacar

su forma abierta y accesible de trabajar junto con la total libertad que han hecho de este

proyecto una de las mejores experiencias de mi carrera. Gracias.

Straight Skeletons José M Migoya Elduayen

- 4 -

1 Índice

1 Índice 4

2 Objetivo 6

3 Introducción 8

4 Estudio teórico 10

4.1 Introducción 10

4.2 Proceso de encogimiento 11

4.3 Aplicaciones prácticas 17

4.4 Características 22

5 Análisis y diseño 26

5.1 Requisitos 26

5.2 Algoritmo 27

5.3 Restricciones 37

5.4 Diseño 39

5.5 Clases 51

6 Entorno de implementación 59

6.1 Internet 59

6.2 WWW y HTTP 62

6.3 HTML 64


- 5 -

6.4 Antecedentes y conceptos sobre Java 69

6.5 Java 73

6.6 Applets 76

6.7 Requisitos 79

7 Utilización del entorno 81

7.1 Navegación por el entorno 81

7.2 Ejecución 83

8 Conclusiones y comentarios 90

9 Bibliografía y enlaces 92

9.1 Artículos 92

9.2 Direcciones web 92

10 Anexos 94

10.1 Tabla de ilustraciones 94

10.2 Formatos de puntos y segmentos 97

10.3 Modelo entidad - relación 99


- 6 -

2 Objetivo

Dentro de la Geometría Computacional existen multitud de algoritmos

tremendamente útiles que, a día de hoy, no tienen una solución, a la vez, bien

documentada, analizada e implementada.

Uno de estos algoritmos es el de los straight skeletons o esqueletos rectilíneos.

Aparecieron analizados, a nivel teórico, en 1995 y, aunque tienen una utilidad práctica

tremenda, no existen implementaciones libres. Se han escrito varios artículos sobre ellos

ampliando la especificación inicial y se pueden encontrar repartidos por Internet con

facilidad.

Los straight skeletons tienen varias aplicaciones prácticas destacando, entre

todas ellas, el cálculo del tejado perfecto a dos aguas de una edificación, también

llamado, forma canónica de construir un tejado. Este modelo ofrece la descripción

completa del tejado que apoya, de manera uniforme, su peso sobre cada una de las

paredes asumiendo que tienen igual altura.

El objetivo principal de este proyecto fin de carrera es el de desarrollar una

aplicación pública y libre que implemente el algoritmo geométrico de los esqueletos

rectilíneos.

La implementación deberá incluir un entorno gráfico para una mejor

comprensión del cálculo y del algoritmo. Además, deberá tener la capacidad de resolver

cualquier polígono que un usuario pudiese desear. Para ello, se habilitarán dos maneras

de introducir el polígono, por una serie de puntos que conformen los vértices del

polígono que el usuario pudiese escribir o, directamente, poder dibujar el polígono con

el ratón.

También debe ser capaz de obtener el resultado de manera dual, es decir, que se

vea el esqueleto rectilíneo gráficamente y de manera explicita, es decir, con los puntos y

segmentos que lo forman.


- 7 -

Además, debido a su dispersión, se quiere hacer un análisis de toda la

documentación disponible para conocer a fondo este modelo, recopilando diferentes

artículos y aplicaciones prácticas.


- 8 -

3 Introducción

En 1995, Oswin Aichholzer, David Alberts, Franz Aurenhammer y Bernd

Gartner publicaron un artítulo titulado ‘A Novel Type of Skeleton for Polygons” (‘Un

nuevo tipo de esqueleto para polígonos’). En él, se presenta y analiza un esqueleto

rectilíneo para polígonos sobre el plano.

Este esqueleto se compone de varios fragmentos de los bisectores angulares del

polígono que se va formando en un proceso de reducción, generando a su vez una serie

de polígonos monótonos.

Ya existían estudios y versiones de otro tipo de esqueletos, los obtenidos a raíz

de los diagramas de Voronoi, por ejemplo. Los diagramas de Voronoi están basados en

una función de distancia que genera esqueletos que dividen el polígono en lados

equidistantes. Los straight skeletons, en cambio, se basan en un proceso de

encogimiento de todos los lados del polígono.

Según se van reduciendo, o encogiendo, los lados del polígono, sus

intersecciones van produciendo los segmentos de bisectores que forman el esqueleto

rectilíneo. En su ejecución, se pueden dar dos tipos de circunstancias o eventos: los

eventos de corte y los eventos de colapso, también llamados eventos de borde o eventos

de reducción.

Los eventos de corte ocurren cuando uno de los vértices del polígono reducido

corta a uno de los lados de ese mismo polígono reducido. Esto da lugar, por un lado a

un nuevo vértice del esqueleto, y por otro, a dos polígonos sobre los que aplicar, a su

vez, el mismo cálculo de los straight skeletons. La suma de las dos soluciones será la

solución total del polígono del que parten.

Los eventos de colapso se producen cuando un lado se reduce tanto que llega a

tener un tamaño de cero. En ese momento, se obtiene un nuevo vértice del esqueleto y

se puede seguir aplicando el algoritmo sobre el polígono reducido que queda, pero con

un lado menos.


- 9 -

En polígonos convexos, tanto los diagramas de Voronoi como los straight

skeletons, generan esqueletos rectos idénticos. La diferencia surge cuando se analizan

polígonos no convexos pues los diagramas de Voronoi ofrecen esqueletos con secciones

curvas. Los straight skeletons ofrecen igualmente una serie de esqueletos de lados

rectilíneos, independientemente que sean convexos o no.

La importancia de este esqueleto es su gran utilidad. En ese mismo primer

artículo se destaca su uso a la hora de construir el tejado de una edificación. Dada la

planta de un edificio de paredes de igual altura, el esqueleto rectilíneo resultante es el

tejado a dos aguas perfecto y único que reparte el peso de manera homogénea en todas

las paredes.

Sus aplicaciones no sólo se quedan ahí. También es aplicable, por ejemplo, para

la reconstrucción de terrenos en base a accidentes geográficos como ríos, valles y

montañas, y para generar modelos de caída de agua por superficies o terrenos.


- 10 -

4 Estudio teórico

4.1 Introducción

El straight skeleton de un polígono es conjunto de segmentos único que forman

parte de las bisectores angulares que dividen el polígono en una serie de polígonos

monótonos. Un polígono es monótono con respecto a una línea o recta, R, si su frontera

puede descomponerse en dos cadenas monótonas con respecto a esa línea, siendo una

cadena monótona, con respecto a otra S, si cualquier línea ortogonal a R intersecciona

con S en, a lo sumo, un punto.

De una manera menos estricta, se puede definir como el conjunto de segmentos,

fragmentos de los bisectores angulares del polígono, que se van formando al reducir el

polígono en un proceso de encogimiento sobre si mismo.

A través de los diagramas de Voronoi se puede obtener un esqueleto en base al

eje medio de los lados. Este esqueleto, en polígonos convexos, coincide completamente

con el correspondiente straight skeleton de ese polígono. Es con los polígonos no

convexos en los que aparecen diferencias notables pues, cuando se tienen vértices

reflejos, es decir, vértices que ‘van hacia dentro del polígono’, aparecen fragmentos

curvos en el esqueleto. A partir de ahí, el esqueleto resultante puede no tener nada que

ver el obtenido por un algoritmo o por otro.

Esto ocurre porque el esqueleto rectilíneo no usa, en su cálculo, una función de

distancia como los diagramas de Voronoi, sino que se forma con el proceso de

encogimiento antes mencionado.


- 11 -

4.2 Proceso de encogimiento

El proceso de encogimiento del polígono para obtener el esqueleto rectilíneo se

basa en la reducción de todos sus lados hacia el interior del mismo provocando, en este

proceso, la construcción del polígono en base a las bisectrices angulares.

La reducción se aplica construyendo un polígono semejante al original basado en

rectas paralelas a todos los lados. Paso a paso, se puede ver mejor con un ejemplo

(figura 1).

Figura 1. Polígono de ejemplo

Se obtienen las paralelas a cada uno de sus lados a una misma distancia (figura

2).

Figura 2. Paralelas de un polígono


- 12 -

Las intersecciones de estas paralelas son llamadas vértices reducidos (figura 3 y

4).

Figura 3. Intersecciones entre polígonos

Estos vértices reducidos delimitan los extremos de los segmentos que forman el

nuevo polígono encogido (figura 5).

Figura 4. Vértices reducidos

Cada uno de los vértices es un punto que pertenece a las diferentes bisectrices

angulares del polígono original y como tal, al unirlas a los vértices del polígono original,

se obtiene un segmento del bisector que irá creciendo a medida que se aumente el

encogimiento (figura 6).


- 13 -

Figura 5. Polígono reducido

Estos segmentos, trozos de los bisectores angulares, son los que van formando el

straight skeleton.

Figura 6. Bisectores parciales y partes del esqueleto

Esto se aplica hasta que ocurren dos tipos de ocurrencias o eventos: los eventos

de corte y los llamados eventos de colapso o reducción. Cada evento generará una cima

que será un vértice del esqueleto rectilíneo. Los eventos de corte se dan cuando un

vértices reducido, en su proceso de encogimiento, corta a alguno de los otros lados del

polígono reducido (figura 7).


- 14 -

Figura 7. Evento de corte

El evento de corte genera uno de los segmentos definitivos del esqueleto

rectilíneo formado por ese evento, es decir, la cima que corta y el vértice del polígono

del que sale (figura 8).

Figura 8. Segmento generado por un evento de corte

Los eventos de colapso se dan cuando uno de los lados, de tanto reducirse,

desaparece, es decir, su longitud queda en cero. Otra manera de ver estos eventos de

colapso es el momento en el que dos vértices del polígono reducido adyacentes

coinciden (figura 9).


- 15 -

Figura 9. Evento de colapso

Los eventos de colapso generan varios segmentos definitivos del esqueleto

rectilíneo. Los dos segmentos que se generan de manera segura son los formados por la

intersección de los vértices reducidos y los vértices del polígono de los que salieron

(figura 10).

Figura 10. Segmentos generados por un evento de colapso

Al darse un evento de colapso puede ocurrir de manera múltiple, es decir, que

coincidan más de dos vértices reducidos que se interseccionen en el mismo punto. Esto

ocurre, por ejemplo, cuando el polígono a reducir tiene tres lados y las tres bisectrices

angulares se cortan en el mismo punto.

Cuando esto pasa se formarán tantos segmentos definitivos del straight skeleton

como los formados por la coincidencia de los vértices reducidos y cada uno de los


- 16 -

vértices de donde se originaron. Es este caso, se finalizaría la reducción de ese polígono

pues no queda nada que reducir (figuras 11 y 12).

Figura 11. Evento de colapso final

Al analizar el evento de colapso puede que sólo quede un vértice reducido,

además de las que han provocado el evento, lo que significará el final de la reducción

obteniendo, además de los dos segmentos antes indicados, los segmentos que aparece de

unir la cima que queda solitaria con el evento de colapso y con el vértice del que partió

(figura 13).

Figura 12. Segmentos generados de un evento de colapso final


- 17 -

Figura 13. Evento de colapso dejando un polígono de dos lados

Después de cualquiera de estos eventos, aparecen uno o dos nuevos polígonos

reducidos sobre los que hay que aplicar de nuevo la reducción hasta que no quede

ninguno. Sus soluciones parciales se sumarán hasta formar el esqueleto final (figura 14).

Figura 14. Esqueleto rectilíneo final

4.3 Aplicaciones prácticas

Como se ha indicado, la aplicación más importante e intuitiva es la construcción

del tejado a dos aguas perfecto. El paso del modelo tridimensional que supone una casa

al modelo bidimensional que supone un plano, se realiza tomando la planta de la casa,

es decir, plasmando el dibujo de la casa vista desde arriba sobre el plano, lo cual


- 18 -

formará un polígono (figura 15). Es sobre este polígono sobre el que se aplicará el

algoritmo para obtener el esqueleto rectilíneo (figura 16) que coincidirá con el tejado a

dos aguas (figura 17).

Figura 15. Planta de un edificio

Para que este modelo sea correcto hay que tener en cuenta que se ha de realizar

sobre una edificación de paredes de igual altura. El esqueleto rectilíneo ofrece el dibujo

sobre la planta del tejado a dos aguas perfecto y, en su cálculo, la forma canónica de

obtenerlo (figura 16). Al obtener solamente el dibujo sobre la planta del edificio, no se

obtiene la altura del mismo (el tercer componente de la tridimensionalidad que se pierde

al trabajar sobre el plano) dependiendo esta del diseño arquitectónico, los materiales y

otros factores externos a este cálculo.

Figura 16. Esqueleto rectilíneo de la planta del edificio


- 19 -

La construcción del esqueleto implica que se compone de pedazos de bisectores

definidos a partir de los bordes del polígono teniendo, cada uno de ellos, grado uno. Las

cimas del straight skeleton tendrán grado tres al estar formadas por la intersección de

tres segmentos del esqueleto.

Figura 17. Tejado del edificio

Esta definición de la construcción, por si sola, no es válida para definir un

esqueleto rectilíneo pues genera más de una solución posible, es decir, los esqueletos

rectilíneos generados no son únicos (figura 18).

Figura 18. Falta de unicidad en los esqueletos


- 20 -

Si se tiene un polígono sobre el plano horizontal, Π0, se puede asociar a cada

lado, e, un semiplano, Πe, que genera un modelo en tres dimensiones. El corte del plano

Πe con el plano horizontal, Π0, es el formado por la recta que incluye el lado e y que, a

su vez, tiene una pendiente fija, por ejemplo 45 grados, dado que ambos planos no se

tienen porque cortar de manera perpendicular.

Para dos lados adyacentes del polígono, e y e’, se formarán dos semiplanos, Πe y

Πe’. Tal y como se ha dicho, si ambos tienen la misma pendiente con el plano horizontal,

su intersección, Πe ∩ Πe’, proyectada sobre el plano Π0 será la bisectriz angular de los

lados e y e’.

Así se define un tejado para un polígono sobre el plano como los semiplanos que

interseccionan con Π0, todos ellos con una misma pendiente, y cuyos cortes forman el

polígono. La intersección de dos semiplanos formará una de las aristas del tejado

mientras que la intersección de tres de esos semiplanos formará uno de los vértices o

cimas.

Cada una de las cimas, u, se puede elevar del plano, λ(u), formando una figura

tridimensional. Si cada una de estas cimas está formada por la extensión de tres lados, a,

b y c, se dará que λ(u) ∈ Πa ∩ Πb ∩ Πc. Cada uno de los planos del tejado que se

generan por los semiplanos estará limitado por el lado que lo genera y la intersección

con los otros semiplanos. Cada uno de los lados del tejado se puede definir con una

función, f, y cada uno de sus lados se podrá definir como (x,e), donde e es un lado del

polígono y x se mueve a través de los bisectores.

Al tener que λ(u) ∈ Πe, para todos los puntos u de f, la elevación de los

bisectores da la elevación de los semiplanos que forman las caras del tejado. De igual

manera que sobre el plano, mantiene una continuidad dado que cada lado toca a sus

adyacentes a lo largo de los diferentes segmentos, f(e), del tejado. Además, los lados

convexos formarán los ‘picos’, o puntos más altos, del tejado mientras que los reflejos

formarán los ‘valles’, o puntos más bajos.


- 21 -

Existe una extensión a los esqueletos rectilíneos de polígonos de gran utilidad,

los polígonos con islas (figura 19). Estos problemas se componen de un polígono, como

los que se han analizado hasta ahora, añadiendo en su interior otro más pequeño que lo

contenga completamente. La aplicación del algoritmo se extiende a ambos polígonos

que interactúan como si fueran uno. La única diferencia radica en que el polígono

mayor se reduce y el polígono más pequeño se agranda, para lo cual hay que buscar la

dirección contraria en el cálculo de las paralelas.

Figura 19. Polígono con isla

Otra de las aplicaciones ya comentadas es el de la reconstrucción de terrenos en

base a accidentes geográficos. Puestos sobre un plano los accidentes geográficos

parciales de una zona obtenidos, por ejemplo, vía satélite se puede aproximar una

reconstrucción del terreno.

La mejor aproximación y utilidad en este campo es el de el análisis y previsión

de caídas de agua sobre un terreno. Teniendo, por ejemplo, un mapa geográfico con

curvas de nivel (figura 20) se puede calcular el straight skeleton para cada curva con su

adyacente. La continuación de los segmentos que se van formando en cada una de las

islas construirá una serie de caminos por los que, teóricamente, se producirá la caída de

agua sobre ese terreno.


- 22 -

Figura 20. Mapa con curvas de nivel

Sobre este modelo apenas se ha trabajado con esqueletos rectilíneos pero las

pruebas realizadas parecen indicar que ofrecen un modelo mucho más realista que otros

basados en otras funciones. El más usado en estos entornos es el que se basa en los

diagramas de Voronoi.

Figura 21. Caída del agua por un terreno

4.4 Características

Los esqueletos rectilíneos cumplen una serie de características que son muy

interesantes a la hora de obtenerlos y comprenderlos mejor.


- 23 -

Si el polígono tiene n lados, el esqueleto contendrá n-2 vértices y 2n-3

segmentos. Se puede comprobar que sobre un polígono de tres lados, el menor que se

puede dar, el corte de las tres bisectrices angulares coincide en un punto y se convierte

en el único vértice, es decir, un polígono de tres lados genera un solo vértice. Los

polígonos de más de tres lados, se reducen en base al encogimiento del polígono

generando vértices para cada uno de los eventos que van apareciendo. Cada evento es

un vértice más y el cálculo de los restantes se basa en la reducción del polígono que

queda eliminando uno de los vértices. Se puede, entonces, comprender fácilmente que la

reducción provoca un vértice del segmento por cada vértice del polígono hasta que

queda un polígono de tres lados, que genera un solo vértice, es decir, n-2 vértices en

total.

Comprobar que el número de segmentos es 2n-3 es sencillo sabiendo que existen

n-2 vértices. De cada vértice de polígono sale un segmento que se une con alguno de los

vértices del esqueleto, lo que lleva a tener n segmentos. A estos, hay que añadirles los

segmentos que salen de unir los vértices del esqueleto pues, si hay n-2 vértices, se

podrán unir, reutilizando cada uno de ellos como vértice de dos segmentos, obteniendo

n-4 segmentos. Como no se forma una estructura cíclica, hay un par de vértices que no

se unen, es decir, que se obtienen realmente n-3 segmentos. Estos, sumados a los n

anteriores, nos dan los 2n-3 (n+n-3).

Al aplicar el proceso de reducción sobre un polígono, se puede dar lo que los

autores llaman cimas degeneradas. Este tipo de cimas son las que se producen cuando

más de un evento coincide en el mismo punto. Un ejemplo muy sencillo se puede ver

con un cuadrado (figura 21).

La reducción da como resultado que los dos eventos coinciden justo en el centro,

para este caso. La literatura evita analizar estos casos dado que, estrictamente hablando,

no mantiene algunas de las características comentadas anteriormente como el número de

vértices esa n-2. Para su resolver este problema algunos autores recomiendan desplazar

mínimamente uno de los dos eventos y así poder obtener las cimas esperadas y un

esqueleto rectilíneo equivalente.


- 24 -

Figura 22. Cimas degeneradas

En este proyecto se ha decidido mantener cada uno de los eventos en su lugar

tomando, cada uno de ellos, como un evento diferente en el mismo punto lo cual genera

dos cimas distintas, c1 y c2, que coinciden en el mismo punto. Así se mantienen todo lo

dicho aunque hay que tener siempre en cuenta que se pueden dar cimas que coincidan.

La desventaja más importante de los straight skeletons frente a otros modelos

son las escasas implementaciones, de hecho, hasta la fecha, este proyecto que se

presenta es el primero que aporta una solución correctamente implementada y

documentada. Así, como para los diagramas de Voronoi se han desarrollado

mecanismos potentes y especializados para su cálculo, para los esqueletos rectilíneos no

existen. Esto merma su posible aplicación.

En base a la solución propuesta se tiene una complejidad de O(n2 log n). Esta no

es la mejor solución dado que, tal y como publicaron David Eppstein y Jeff Erickson en

su artículo “Raising Roofs, Crashing Cycles, and Playing Pool” demuestran que se

puede llegar a implementar con una complejidad de O(n1+n + n8/11+n r9/11+n).

Este algoritmo, de menor complejidad, tiene handicaps que no recomiendan su

implementación. Por un lado, requiere el manejo de una serie de recursos excesivo lo

que ofrece una solución menos eficiente a nivel de tiempo de respuesta. Por otro lado,

este algoritmo es más complejo de entender e implementar y no permite ver una

solución tan intuitiva como la aportada.


- 25 -

Figura 23. Diagramas de Voronoi vs. Straight Skeletons

Por último, hay que destacar la diferencia real entre el esqueleto generado a

través de los diagramas de Voronoi y los straight skeletions. Como se ha indicado, en

polígonos convexos, los esqueletos coinciden completamente mientras que en polígonos

no convexos aparecen fragmentos curvos en el generado por los diagramas de Voronoi

mientras que en los esqueletos rectilíneos siguen siendo rectos (figura 22).


- 26 -

5 Análisis y diseño

5.1 Requisitos

Para realizar el diseño y poder llegar a la implementación, se necesita reunir

todas las necesidades en un sólo apartado para diseñar correctamente y que el resultado

cumpla todos los planteamientos. Este conjunto de características se denominan

requisitos.

Uno de los requisitos básicos es la necesidad de que sea una aplicación abierta, a

través de Internet, a cualquier persona interesada asumiendo los múltiples entornos y

plataformas que se pueden dar. Así, debe ser lo más estándar y compatible que se pueda

para dar el mayor soporte.

La aplicación se basa, principalmente, en obtener el esqueleto rectilíneo, o

straight skeleton, de un polígono dado.

Tal y como se explica en el estudio teórico, el algoritmo de resolución se basa en

la reducción del polígono sobre sí mismo a base de calcular paralelas a cada uno de los

lados y los cruces de estas. Con ellas se van formando las bisectrices angulares y, de

paso, cada uno de los segmentos que componen el esqueleto rectilíneo.

Se tendrá que controlar los diferentes eventos que se podrán suceder y, dado que

algunos de ellos provocan otros polígonos a los que hay que aplicar este mismo

algoritmo, se deberá orientar a la ejecución recursiva.

Todo el sistema debe estar sustentado por un entorno gráfico amigable que

permita ver la ejecución y resolución del esqueleto rectilíneo de un polígono. Además,

cualquier usuario podrá interactuar con el software a través de este mismo entorno para

obtener los resultados de los polígonos que desee.

Los polígonos se podrán introducir por parte del usuario de dos maneras, uno,

pintando sobre la pantalla de una manera intuitiva, y dos, a través de los vértices que


- 27 -

compondrán cada uno de los polígonos. En este último método se tendrá en cuenta un

formato para definir cada punto pues se deberán que escribir, o pegar con las opciones

de los entornos visuales, a través de texto. Sería conveniente, además, que ambos

métodos se pudieran complementar de manera que tras incluir parte de un polígono, se

pueda seguir dibujando con el ratón.

El usuario podrá dibujar e introducir polígonos repetidamente, bajo la forma que

desee, permitiendo el borrado de cada uno de ellos para poder trabajar con otro nuevo.

Además, tras trabajar con uno, podrá obtener los datos de ese polígono para, en base a

dicha información, poder generar nuevos problemas y comparar soluciones.

Cada straight skeleton, además de poder ser observado en el entorno gráfico

como antes se ha indicado, se podrá obtener en forma de texto con el formato que se

defina. Todos los formatos deberán ser rápidamente comprensibles e intuitivos para

cualquier usuario.

Se necesitará que la ejecución sea eficiente, de fácil comprensión y visual. La

eficiencia será necesaria para la ver el resultado en tiempo real y no sea demasiado lenta.

Para evitar el extremo contrario, se habilitará un mecanismo para poder ejecutar la

aplicación con un retardo que permita ver, claramente, cómo se va resolviendo el

esqueleto rectilíneo.

Se necesitará tener un control sobre la ejecución del usuario en el entorno y

poder hacer un seguimiento de él.

5.2 Algoritmo

El algoritmo por el cual se obtiene el esqueleto rectilíneo de un polígono se basa

en la reducción de sus lados sobre sí mismos hasta que se dé algún tipo de dos los

eventos comentados en la explicación teórica.


- 28 -

Para una mejor comprensión de este algoritmo se muestra el proceso de

encogimiento de un polígono de ejemplo (figura 24) a través de una serie de figuras a

las que se irá haciendo referencia en la explicación.

Figura 24. Polígono de ejemplo

Los datos que se manejan son, por un lado, el conjunto de vértices que forman el

polígono y, por otro, el conjunto de puntos que forman el polígono temporal sobre el

que se aplica el algoritmo. Esto es así porque el algoritmo es recursivo y ante uno de los

eventos, se aplica de nuevo sobre los polígonos resultantes del evento. Pero la solución,

una vez que se ha dado un situación de este tipo, implica a los nuevos eventos que se

den y a los vértices del polígono original, y no a los del los polígonos parciales.

Figura 25. Lado seleccionado

Para empezar, se calculan las paralelas de cada uno de los lados (figura25).


- 29 -

Figura 26. Paralelas al lado seleccionado

Cuando se tiene un segmento o una recta, es sencillo obtener las dos paralelas a

una distancia dada pero es más complicado identificar cual es la paralela que ‘va hacia

dentro del polígono’ (figura 26).

Figura 27. Perpendiculares y cortes con el resto del polígono

Esto se hace calculando las dos rectas perpendiculares que pasan por un punto

del segmento y comprobando cuantos cortes se producen con el resto de lados del

polígono (figura 27). Una de las rectas perpendiculares tendrá un número impar de

cortes mientras que la otra tendrá cero o un número par.


- 30 -

Figura 28. Paralela válida

El sentido de las paralelas será el que indica la perpendicular con un número

impar de cortes (figura 28). Esto se aplica sobre cada uno de los lados del polígono y

para no repetir la operación en cada ciclo del bucle, se almacena dicha dirección (figura

29).

Figura 29. Paralelas validas a todos los lados e intersecciones

Antes de empezar, se comprueba si el número de lados es dos. Esto, inicialmente

no se puede dar, pero en la ejecución recursiva se puede dar al tener dos eventos en el

mismo ciclo (figura 39). Si este es el caso, significa que se ha producido un evento

colapso o reducción a la vez que se dio uno de corte lo que lleva a que se añadan a la

solución los segmentos asociados y se finalice (figura 40). Los segmentos asociados son


- 31 -

los formados por cada uno de los vértices del polígono temporal y cada vértice

correspondiente al polígono padre de dicha reducción.

Figura 30. Polígono reducido

Antes de empezar la ejecución del bucle de reducción, se comprueba si existen

dos vértices consecutivos que coincidan. Esta comprobación es obligatoria porque, de

nuevo, el proceso recursivo puede da lugar a estas situaciones al producirse dos o más

eventos en un mismo ciclo de reducción (figura 37).

Figura 31. Trozos de bisectores

Si se da el caso, se comprueba si el polígono temporal es de tres vértices o más.

En el caso de que sea de tres vértices, se añaden a la solución las tres bisectrices

formadas por los tres vértices del polígono temporal y los tres vértices del polígono

padre del temporal (figuras 34 y 35). Si el polígono es de más de tres vértices, se añaden


- 32 -

a la solución las dos bisectrices formadas por los vértices coincidentes del polígono

reducido y por los dos vértices del polígono padre asociados (figura 37).


Se crea un nuevo polígono temporal igual al anterior pero sin uno de los nuevos

puntos consecutivos y su vértice padre asociado. El vértice que queda en el polígono

temporal, se tendrá como padre a si mismo. Se lanza de nuevo la ejecución del

algoritmo de manera recursiva con los nuevos polígonos temporal y padre. Tras ello, se

añaden las soluciones de este nueva situación a las ya existentes y se finaliza la

ejecución (figura 36).

Figura 33. Polígonos resultantes de un evento de corte

Ahora si, se lanza el bucle de reducción que trabajará hasta que se encuentre con

algún tipo de evento. Lo primero es calcular todos los datos de esa iteración, las


- 33 -

paralelas (figura 29), los cortes de esas paralelas que forman los vértices del nuevo

polígono temporal reducido (figura 30) y las bisectrices que se forman con los vértices

del polígono padre (figura 31).


Una vez que se tiene toda esa información, se comprueba si hay algún tipo de

corte entre bisectrices, lo que significaría un evento de colapso o reducción en esa

intersección (figuras 34, 37, 39 y 42).

Figura 35. Segmentos generados por un evento de colapso final

Si existe alguno de ellos, se añaden las dos bisectrices formadas por el evento de

colapso y cada uno de los vértices correspondiente al polígono padre de dicha reducción

(figura 34).


- 34 -

Figura 36. Polígono a reducir

Se crea el nuevo polígono sin los dos puntos que se han juntado, tanto en el

polígono temporal como en el padre, y se deja, en su lugar, el evento de colapso como

vértice del polígono padre de la reducción y como vértice del polígono temporal (figura

38).

Figura 37. Evento de colapso

El resto de los puntos y vértices se mantiene.


- 35 -

Figura 38. Polígono a reducir tras evento de colapso

Lo siguiente a hacer es comprobar si hay cortes entre lados no consecutivos, es

decir, eventos de corte (figura 32 y 39). Si hay alguno, se añade la bisectriz formada por

el evento de corte y el vértice correspondiente del polígono padre. Tras esto, se

formarán dos polígonos temporales sobre los que se aplicará el algoritmo (figura 33).


Si el polígono antiguo fuera de tres vértices, se añade la bisectriz restante a la

solución y se finalizaría la ejecución de este polígono (figuras 35 y 42). En caso de que

sea mayor, se calcula el esqueleto del nuevo polígono creado ejecutando el algoritmo

recursivo sobre él y se añaden los esqueletos resultantes a la solución, finalizando la

reducción de este polígono.


- 36 -

Figura 40. Polígono de dos lados resultado de un evento de corte y colapso a la vez

Estos dos polígonos se forman con los puntos y los vértices correspondientes de

polígono padre que quedan a un lado y a otro del evento. El evento también estará

incluido en ambos polígonos como punto y vértice de los nuevos polígonos padres.

Antes de lanzar la ejecución recursiva sobre cada uno de ellos, se comprueba que no

esté, cada uno por separado, compuesto por uno o dos lados. Si esto ocurre, significa

que se ha dado, en el mismo ciclo del evento de corte, un evento de colapso. Como tal,

se añade a la solución la bisectriz formada por el otro punto del polígono y su vértice

asociado y el otro segmento formado por ese mismo punto y el evento de corte (figura

39). No se ejecutan en recursividad los polígonos que les ocurra esto.

Figura 41. Polígono a reducir

Después de la ejecución, se añaden a la solución los resultados de las

ejecuciones recursivas y se finaliza.


- 37 -


Cuando no quedan polígonos que reducir, se juntan todos los segmentos que

forman el esqueleto rectilíneo finalizando la ejecución (figura 43).

Figura 43. Esqueleto rectilíneo final

5.3 Restricciones

Antes de desarrollar el diseño, hay que tener en cuenta todas las implicaciones

que se derivan del entorno y sus restricciones.

La primera restricción es que tiene que estar disponible en el entorno de Internet

para ser accesible por cualquier usuario del mundo. Esto implica, inmediatamente, que


- 38 -

ha de ser desarrollado para adecuarse al entorno natural de la red de redes, es decir, ha

de estar incrustado en un documento HTML.

Existen multitud de lenguajes sobre los que desarrollar la aplicación pero, si se

quiere que sea accesible a todo el mundo, ya trabajen con un sistema operativo u otro,

habrá que elegir un lenguaje multiplataforma. Tras este requisito, el lenguaje

multiplataforma por excelencia es Java que incluye todas las características modernas

de los lenguajes orientados a objetos de última generación.

Una vez elegido el lenguaje, existen dos posibilidades de implementación: en

forma de applets, completamente integrado en la web, o como una aplicación externa a

la web. Debido a que es posible implementar una aplicación sobre un appet, la decisión

es ofrecer ambas posibilidades.

Se realizará en forma de applet para que sea ejecutado desde la misma página

web y no haya que bajarse nada al propio ordenador. Descargar un software de la red

requiere cierta confianza por parte del usuario que no se le puede exigir, puesto que este

código se ejecuta posteriormente y puede tener algún virus o código no deseable. La

opción de realizar un applet firmado, lo que le aportaría más posibilidades al software,

se ha descartado porque requiere un conocimiento, por parte del usuario, tampoco

asumible: qué es un certificado, cómo se instalan, qué implicaciones tiene, cómo se ha

de habilitar esas opciones, etcétera.

Además se realizará una aplicación sobre el applet, que permita la ejecución del

programa sin necesidad de estar conectado a Internet. Simplemente, se añadirá, dentro

del applet, la posibilidad de ejecutarlo como una aplicación normal que abra una

ventana que incluya el applet y todo su software.

Dentro de Java existen numerosas versiones (hasta la fecha, cinco liberadas con

sucesivos parches, cada una de ellas). Cada una de ellas requiere una máquina virtual

diferente, siendo compatibles las versiones superiores con las inferiores, es decir, el

software implementado bajo las normas de la versión 1.0 será ejecutado sin problemas

por cualquier máquina virtual, en cambio, si se realizan implementaciones con


- 39 -

características propias de la versión, por ejemplo, 1.4, tan sólo será ejecutable sobre esa

versión y las superiores, es decir, 1.4 y 1.5.

Estas características y el requerimiento de que se ejecute sobre cualquier entorno,

por cualquier usuario, hace que la elección de la versión sea sencilla: la más baja y

compatible con todos, Java 1.0. Esto tiene también su lado negativo y es que, como

toda primera versión, no contiene todas las funcionalidades y características de las

últimas versiones. El caso más llamativo es el del aspecto gráfico: mientras que la

versión 1.0 y 1.1 usaban unas librerías llamadas AWT (Abstract Window Toolkit) que

permiten unos gráficos limitados sin muchas opciones, a partir de esas versiones se

incluyen otras librerías, además de las AWT por compatibilidad, llamadas Swing que

permiten multitud de nuevos gráficos, posibilidades y ventajas.

Por último, se requiere que todo esté documentado en formatos reconocibles y,

también, gratuitos. Toda la web está diseñada en HTML, como antes se ha indicado, que

se puede visualizar con cualquier navegador web, o browser, integrado en los sistemas

operativos o accesibles a cualquier usuario. Parte de la documentación y esta misma

memoria se puede encontrar, para un formato más robusto y manejable, en archivos PDF

(Portable Document Format), que es un formato muy extendido y estandarizado por

Adobe. Para su visualización, tan sólo se requiere el lector Adobe Reader, que es

gratuito y descargable tanto desde la web de Adobe, como y desde este mismo entorno.

5.4 Diseño

Aunque los requisitos y las restricciones no se han descrito como un listado

enumerado de sentencias que se deban cumplir, para mayor comprensión y facilidad de

lectura, se pueden ir sacando uno a uno sin dificultad e ir formando las entidades,

relaciones y demás elementos. Igualmente, el diseño se redactará de una manera menos

precisa y puntual para ganar en claridad y comodidad.


- 40 -

Parece claro que se ha de contar con un entorno basado en páginas web, Java

como lenguaje de programación y un applet como base del entorno gráfico y comienzo

de la aplicación. El entorno gráfico vendrá dado, entonces, por la entidad principal que

heredará de la clase Java que representa y contiene todas las características de los

applets, java.applet.Applet. Esta entidad será el StraightSkeletons.

Figura 44. Herencia entre StraightSkeletons y Applet

Como esta entidad es el núcleo de la aplicación y soporta las funcionalidades de

muchas de las entidades aquí definidas y descritas, será mejor definirlas al final de este

capítulo, cuando ya se tengan todos los dato, entidades y funciones.

Las necesidades de un espacio para poder cargar polígonos y visualizar la

solución, ambos en formato de texto, hace buscar uno o dos elementos que, de manera

visual, contengan dicha información. En versiones más avanzadas de la máquina virtual

Java, se podría usar diferentes elementos que fueran apareciendo y ocultando cuando el

usuario las necesite o requiera. En este caso, se dispondrán dos elementos que el usuario

visualizará constantemente y, para el que contiene los vértices, podrá escribir en él para

modificar, borrar o añadir datos. Sobre el elemento que contiene la solución, el usuario

sólo podrá visualizar y, como mucho, seleccionar el resultado para copiarlo y pegarlo en

algún otro lugar.


- 41 -

En estos dos elementos, dado que la información puede ocupar bastante espacio,

dependiendo del número de vértices que contenga el polígono, deberán tener una barra

de desplazamiento por todo el texto incluido, es decir, la capacidad de hacer scroll, Así,

estos dos elementos serán componentes gráficos, dado que se visualizarán en pantalla,

contendrán información que irá variando y deben contener un scroll, lo que lleva a

recurrir al único elemento en Java 1.0 que permite todo ello: java.awt.TextArea.

Sus nombres serán PanelVertices y PanelSolucion.

Figura 45. Herencia de PanelVertices y PanelSolucion con TextArea

Ambos elementos estarán incluidos dentro del entorno gráficos, es decir, del

applet, lo que implica que StraightSkeletons tendrá una referencia a ambos para

que las órdenes del usuario puedan llegar a cada uno de los elementos.

Figura 46. Relación entre StraightSkeletons y paneles


- 42 -

Ambos paneles contendrán las funcionalidades propias definidas y requeridas en

los requisitos. El panel de soluciones permitirá añadir un mensaje sin más, la definición

de un segmento como parte de la solución y que se borren todos los datos. El panel de

vértices tendrá los métodos que permitan actualizarse con los datos del polígono pintado

en el plano y borrar todos los datos del panel. Además tendrá los métodos para capturar

las pulsaciones de teclado sobre él y que lean, parseen y resuelvan el texto escrito como

una cadena de puntos válida.

El panel de mensajes requiere las mismas características que el panel de las

soluciones, es decir, es un componente gráfico, requiere un scroll y contiene

información que va variando. La solución, pues, será la misma, una componente que

herede de java.awt.TextArea. Se llamará PanelMensajes. También de igual

manera, estará relacionada con el applet.

Figura 47. Relaciones del PanelMensajes y herencias

Este panel, sin embargo, es accesible por cualquier otro componente que

necesite escribir algo en esta consola. Por ello, se implementará como un componente

único en el sistema, en Java se denomina estático, lo que permite que sea accesible por

todos. Además del método para obtener esta única instancia en el sistema, tendrá

implementados los métodos que cubren las necesidades, es decir, añadir un mensaje y

borrar todos los mensajes existentes en el panel.

Los botones serán, de nuevo, componentes gráficos. Estarán agrupados y

gestionados por un componente contenedor que permita la ejecución de cada uno de


- 43 -

ellos y controlar su estado en relación con los demás, es decir, que habilite y deshabilite

cada uno de ellos cuando sea necesario.

Los botones serán cinco, en correspondencia con las cinco acciones que necesita

el usuario: limpiar el panel gráfico donde se visualiza el polígono, cerrar el polígono,

lanzar la ejecución del cálculo del esqueleto rectilíneo, lanzar la misma ejecución pero a

una velocidad menor y, por último, cargar el polígono escrito en modo texto al panel

gráfico. Así, se llamarán ‘Limpiar‘, ‘Cerrar‘, ‘Ejecutar, ‘Ejecutar Lento‘ e

‘Introducir vértices‘, respectivamente. Todos ellos serán instancias de la clase

Java que define los botones, java.awt.Button.

Todos estos botones estarán incluidos en una clase que herede del típico

contenedor de componentes gráficos, java.awt.Panel, y se llamará PanelBotones.

Tendrá las funcionalidades para capturar las pulsaciones sobre cada uno de ellos y será

el responsable de habilitar y deshabilitar los botones dependiendo de la situación que se

dé en cada momento.

Como en los casos anteriores, es un componente gráfico que se incluye dentro de

la aplicación por lo que estará referenciada desde el applet para su presentación. Pero,

además, este panel de botones al ejecutar los servicios asociados a cada botón tendrá

que usar servicios de otros objetos para llevar a cabo su labor. Para esto último, el panel

de botones tendrá, a su vez, una referencia del applet.

Figura 48. Relaciones del PanelBotones y herencias


- 44 -

Los dos grandes requisitos del proyecto son la resolución del algoritmo que

obtiene el esqueleto rectilíneo y que dicha resolución se haga de una manera gráfica.

Para este segundo caso, hará falta un componente gráfico sobre el que se pueda dibujar

cualquier polígono que se desee. El componente ideal para esto es java.awt.Canvas,

por lo que se diseña la clase Lienzo que, heredando de esta, tenga el resto de

características necesarias.

Este componente contendrá el polígono y todo lo necesario para obtener el

straight skeleton. Necesitará las funcionalidades para capturar las pulsaciones del ratón

sobre este lienzo y saber donde y cuando desea el usuario poner un vértice en el plano.

También deberá incluir los servicios y ordenes que permitan realizar las acciones que

desea el usuario, a saber, limpiar el lienzo, cerrar el polígono, lanzar la ejecución del

cálculo, cargar los puntos escritos en el panel de vértices y, por supuesto, pintar u

ordenar pintar todos los componentes que contenga.

Figura 49. Relaciones y herencias del Lienzo

Definir un polígono y su funcionamiento requiere una de las labores más

importantes y delicadas del diseño. Un polígono se puede definir de dos maneras, como

un conjunto de segmentos unidos en el plano y como una sucesión de vértices unidos en

el mismo plano.


- 45 -

Ambas soluciones son viables y dan una correcta solución a la implementación.

Ahora bien, en el cálculo se usarán constantemente ambos conceptos, los segmentos y

los vértices que forman el polígono, por lo que, a nivel de rendimiento, sería muy

costoso contar con realizar los cálculos de uno u otro cada vez que se necesitan. Por eso,

se mantienen las dos definiciones y datos, es decir, los vértices y los segmentos, para

tenerlos siempre disponibles y aunque se ocupe más memoria se gana en rendimiento

que, en este caso, es un requisito más.

El polígono será único en el lienzo borrándose los datos cuando se borre del

lienzo y así no se malgasta más recursos creando clases innecesarias. Tendrá,

evidentemente, todas las funcionalidades que permitan trabajar sobre él, a saber, borrar

dicho polígono, añadir un vértice más al polígono y cerrar el polígono automáticamente

siempre que sea posible. El polígono será, pues, una clase referenciada desde el Lienzo

y se llamará Poligono.

Figura 50. Relaciones del Lienzo y el Poligono

Tal y como se ha definido el polígono, hay que basarse en la descripción de dos

elementos básicos del sistema, el segmento y los vértices, que, además, requerirán un

tercero, la recta. Un vértice es, realmente, un punto en el plano. Se hace necesaria el

diseño de un componente que lo defina en el plano y, de paso, lo dibuje si es necesario.

La clase Punto no es más que un par de números que definen las coordenadas en el eje

0X y 0Y del plano y las funciones necesarias para trabajar con ellos, es decir, obtener la


- 46 -

coordenada X, la coordenada Y, pintarlo en el plano y decir si ese punto es igual a otro

dado.

Este último aspecto cobra especial relevancia cuando se empiezan a hacer

operaciones y existen redondeos de manera que, en teoría, un punto obtenido después de

una operación puede ser igual a otro dado y, realmente, no sea así. Un ejemplo puede

ser que tras analizar el corte de dos rectas se obtenga el punto (12.34, 56.78) y,

comparándolo con ese mismo punto, obtenido de otra operación, se le comparé con

(12.34, 56.779999999999). Ambos puntos deberían ser el mismo pero al existir

redondeos por las limitaciones de rangos numéricos, no se obtiene lo mismo. Cuando se

aplican estos redondeos de manera recursiva y acumulada, como es este el caso, los

resultados pueden ser tremendamente erróneos. En esta misma sección, cuando se hablé

del esqueleto, se adentra más en esta problemática.

Para definir los segmentos de los que se ha hablado antes, hay que irse a la

definición funcional de este componente en el plano, un trozo de recta comprendido

entre dos puntos. Para definir un segmento, pues, se necesita definir antes una recta.

Una recta tiene, matemáticamente hablando, diferentes representaciones en

forma de ecuación: la ecuación general, la analítica, la punto pendiente o las ecuaciones

paramétricas, por poner unos ejemplos. La más común y de rápido cálculo, es la

ecuación general que se define como Ax + By + C = 0. Así, con almacenar los

parámetros A, B y C se puede calcular y dibujar sin problema cualquier requerimiento.

Con esto, la clase Recta soportará, en su definición, diferentes formatos: la

fórmula general, la punto pendiente y la definición de una recta por dos puntos, aunque

internamente trabaje con la fórmula general. Además, tendrá las funcionalidades

requeridas para hacer los cálculos del algoritmo que obtiene el esqueleto rectilíneo, por

ejemplo, obtener las dos rectas paralelas a una distancia dada, obtener la recta

perpendicular a otra dada, calcular el punto de intersección con otra rectas, obtener las

coordenadas X e Y y, por supuesto, pintar la recta en el plano.


- 47 -

Una vez definida la recta y el punto, se puede pasar a definir un segmento dado

que, como se ha comentado, este es el trozo de recta comprendido entre dos puntos. Así,

el segmento será una clase llamada Segmento y que heredará de Recta. Está recta

estará limitada por dos puntos que formarán la propia recta, y de ahí que se necesite el

constructor de la recta basado en dos puntos.

Además, tendrá las funcionalidades que requiere el cálculo, es decir, los puntos

extremos del segmento, la comprobación de si es igual a otro segmento, la intersección

con otro segmento o con otra recta y pintar la recta en el plano.

Figura 51. Relaciones y herencias entre Poligono, Segmento, Recta y Punto

Por último, se define el Esqueleto. Definir el esqueleto requiere el mismo

análisis que con el polígono, es decir, se puede definir como un conjunto de vértices

ordenados o como un conjunto de segmentos. Ambas formas serían correctas y darían

solución al problema pero, de nuevo, a nivel de rendimiento será mucho mejor mantener

la doble definición, es decir, la información del esqueleto duplicada de las dos maneras,

para no tener que realizar cálculos cada vez que se requiera dicha información y la

ejecución sea mejor.


- 48 -

El Esqueleto almacena, pues, la información pero hay que tener en cuenta que

también contendrá la ejecución explícita del algoritmo de cálculo. Debido a que existe

un tipo de evento que se puede dar, el evento de corte, y este provoca la ejecución

recursiva del cálculo, el algoritmo se ha de implementar de acuerdo con una solución

recursiva que asuma la construcción del esqueleto de esta manera. Esto tiene especial

interés a la hora de definir las llamadas pues no es lo mismo el cálculo de un polígono

inicial que el de uno surgido de un evento de corte. Esto ocurre porque los vértices del

esqueleto, en el primer caso, son los vértices del polígono, mientras que en el segundo

caso no es así, simplemente son vértices de un polígono temporal que no tienen porqué

formar parte de la solución.

Debido a esta última necesidad, el esqueleto se construirá en base al lienzo, para

poder ir pintando los resultados y la ejecución en sí, el conjunto de vértices del polígono

padre y el conjunto de vértices del polígono que se va a hallar. El esqueleto contendrá,

además, las funcionalidades necesarias para completar el cálculo, es decir, obtener la

solución y el cálculo de la dirección de las paralelas.

Figura 52. Relaciones en ejecución


- 49 -

Existe un factor, antes comentado, que repercute tremendamente en el resultado

sobre casos muy específicos: el factor de reducción. El algoritmo, simplificando su

funcionamiento, se basa en la reducción de un polígono sobre si mismo hasta que sus

lados se colapsan o se cortan unos a otros. Este proceso requiere ir calculado la paralela

a cada lado y ver si se produce algún evento. El problema es decidir a qué distancia se

calcula esa paralela.

Esa distancia a la que se calculan las paralelas recursivas tiene una doble

implicación que impide que se determine un valor demasiado grande o demasiado

pequeño. Si el valor es demasiado grande, es decir, el cálculo de las paralelas se hará a

una distancia elevada, y esto aumentará la probabilidad de que se den eventos en el

mismo ciclo cuando no debería ser así. Esto tiene repercusiones porque se puede perder

en precisión e, incluso, si se dan muchos eventos de corte en el mismo ciclo, se podría

perder rendimiento pues habría que recalcular los polígonos donde se ha producido el

evento pues no son los mismos que el reducido.

Por otro lado, si la distancia a la que se calculan las paralelas es demasiado

pequeña el resultado es mucho más preciso pero se calculan demasiados ciclos donde no

se producen eventos. Las comprobaciones no son gratuitas y requieren un coste de

cómputo elevado por lo que se perdería en velocidad. Si añadimos que los polígonos

pueden tener muchos lados, de hecho, no hay limitación, el rendimiento se puede

resentir muchísimo.

Antes de decidir cual es la distancia más acertada, hay que tener en cuenta un

valor más relacionado con este problema, los redondeos. Los formatos de los números

son finitos, es decir, los números tienen un rango computacional por mucha precisión

que tengan. Esto requiere el mismo análisis, si se usan formatos con poca precisión, se

pierde precisión también en la solución y, sin embargo, si usamos formatos con mucha

precisión, se pierde en rendimiento y velocidad pues el calculo le es más costoso a la

máquina.

A este hecho hay que añadirle que, según sea la precisión, así se redondea cada

número. Los redondeos pueden ser muy sutiles y asumibles en una ejecución lineal pero


- 50 -

en una recursiva, como es el caso, los redondeos hacen que se pierda precisión de

manera acumulada produciendo situaciones como la comentada antes con los puntos. Es

necesario que el factor de reducción, es decir, la distancia a la que se calculan las

paralelas para reducir, y los redondeos a la hora de calcular y comparar puntos, estén

relacionados para evitar resultados erróneos en situaciones límite.

Así, se ha estimado que para un lienzo de dibujo como este, de 525 por 350, una

precisión a centésima de punto es suficiente para equilibrar el rendimiento, la

visualización de la solución y los redondeos correctos.

Es importante aclarar que este problema sólo se produce en casos extremos

donde los cálculos son muy ajustados, por ejemplo, cuando hay que calcular la

intersección de dos rectas que son paralelas, o que no lo son por una pendiente muy

pequeña, cuando dos vértices están muy juntos o cuando en el cálculo de las paralelas,

una perpendicular pasa justamente por un vértice del polígono. Están situaciones son

muy escasas pero se han dado, lo que obliga a este ajuste.

Después de toda esta descripción literal del diseño de la aplicación, hay que

reunir las funciones del applet, StraightSkeletons que acumula los interfaces de

muchos componentes haciendo, simplemente, de distribuidor de llamadas.

El applet tendrá las funciones que actualizan los puntos del panel de vértices

cuando se cierra el polígono en el lienzo, la función que cierra el polígono siempre que

sea posible, las dos ejecuciones, a velocidad normal y lenta, todas las referencias a

paneles, contenedores y resto de componentes de la aplicación, las funciones de

limpieza, tanto del lienzo como de los paneles y pasar los puntos escritos por el usuario

del panel de vértices al lienzo.

Hay cuatro funciones más a destacar que se salen de la aplicación en sí pero

tienen una gran importancia, son funciones heredadas de la clase que define un applet,

java.applet.Applet, y el método que hace que se puede ejecutar el software como

una aplicación además de como un applet. Una de las funciones heredadas es la de

pintado (public void paint(java.awt.Graphics)) que se ejecutará cuando

haga falta pintar el applet, normalmente a llamadas del sistema operativo a través de la


- 51 -

máquina virtual. Cada vez que se repinta se recalcula el tamaño del lienzo pues ha

podido ser modificado al cambiar de tamaño el visualizador HTML.

Otra función es la inicialización del applet (public void init()) y será en

este punto donde se creen los componentes y objetos básicos como el lienzo, el

polígono, los distintos paneles, etcétera. La última función heredada es la de comienzo

de ejecución (public void start()) y se da cada vez que el navegador se activa o

después justo de la inicialización del applet. En este caso, esta función sólo tiene que

recalcular el tamaño del lienzo, como en el repintado. Esta dos sencillas cuestiones son

vitales y requisitos del entorno ya que la aplicación está enclavada en un entorno gráfico

que puede modificar su tamaño.

Por último, se debe implementar la función que hace que este software se pueda

ejecutar como una aplicación externa (static void

main(java.lang.String[])). Esta función creará una ventana y añadirá la

aplicación dentro de ella para su ejecución.

5.5 Clases

El software que incluye el applet se compone de once clases que contienen la

información y la implementación necesaria que responde a los requisitos y restricciones

planteadas. Estas son las clases y sus métodos más importantes:

StraightSkeletons: Este el applet que contiene la aplicación, las constantes

comunes a todo el entorno y las funciones comunes entre los diferentes paneles y

botones. Además, incluye la posibilidad de ejecutar el software en modo aplicación y

no applet. Sus métodos más importantes son:

� StraightSkeletons(): Constructor de la clase.

� void actualizarPuntos(): Actualiza el panel de vértices con los

datos del polígono cerrado.


- 52 -

� void cerrar(): Cierra el polígono dibujado.

� void ejecutar(): Lanza la ejecución del cálculo del esqueleto sobre

el polígono dibujado y cerrado en el lienzo.

� void ejecutarLento(): Lanza la ejecución más lenta del cálculo del

esqueleto sobre el polígono dibujado y cerrado en el lienzo.

� void init(): Creación del applet.

� void limpiar(): Limpia el lienzo, el polígono y las soluciones.

� static void main(java.lang.String[] args): Método para la

ejecución del applet en forma de aplicación.

� void start(): Actualiza el ancho y el alto cada vez que se comienza

la inicialización del applet.

� boolean writePuntos(): Cargar los puntos escritos en el panel de

vértices en el sistema formando un polígono no cerrado con ellos.

Lienzo: Lienzo donde se dibuja el polígono, se muestra la ejecución de la

resolución y, en definitiva, se trabaja. También es la encargada de controlar el

movimiento y las pulsaciones del ratón sobre el propio lienzo.

� Lienzo(StraightSkeletons straightSkeletons): Constructor

que crea e inicializa el lienzo. Se le pasa el esqueleto rectilíneo para

poder actualizar el resto de los componentes.

� void cargarPuntos(java.util.Vector puntos): Limpia el

plano y carga los nuevos vértices pintando el polígono.

� void cerrarPoligono(): Cierra el polígono, si se puede, calculando

los datos básicos del esqueleto rectilíneo.


- 53 -

� PanelSolucion getPanelSolucion(): Devuelve el panel de

soluciones para actualizarlo.

� Poligono getPoligono(): Devuelve el polígono.

� java.util.Vector getSolucion(boolean lento): Cálculo del

esqueleto rectilíneo.

� void limpiarPlano(): Limpia el plano e inicializa el lienzo para

volver a trabajar sobre él limpiamente.

� boolean poligonoCerrado(): Indica si el polígono está cerrado o

no.

Poligono: Define un polígono en el plano. Se define, a nivel interno, de las dos

maneras posibles para ser más eficiente dado que ambos datos son requeridos por otras

clases: con una colección ordenada de puntos o como una colección ordenada de

segmentos.

� Poligono(): Constructor del polígono.

� void addPunto(Punto punto): Añade un punto al polígono siempre

que no esté cerrado.

� void borrarPuntos(): Borra todos los puntos del polígono dejándolo

abierto para añadir nuevos puntos.

� boolean cerrar(): Cierra el polígono siempre que sea posible, es

decir, que existan más de dos puntos, que sus dos extremos se puedan

unir sin intersecciones con otro lados y, además, que no existan

intersecciones entre el resto de los lados.

� java.util.Vector getVertices(): Devuelve un vector con todos

los puntos del polígono cerrado.


- 54 -

� boolean isCerrardo(): Indica si el polígono ha sido cerrado o no.

Segmento: Define un segmento como una recta en el plano, limitada por dos

puntos de la misma. Se define, a nivel interno, sobre la definición general de una recta :

Ax + By + C = 0.

� Segmento(Punto p0, Punto p1): Constructor que define un

segmento cuyos extremos son los puntos que vienen como parámetros.

� boolean equals(Segmento segmento): Indica si un segmento

dado es igual a otro pasado por parámetro.

� Punto interseccion(Recta recta): Devuelve el punto de

intersección entre el segmento y una recta.

� Punto interseccion(Segmento segmento): Devuelve el punto de

intersección entre el segmento y el otro dado.

Recta: Define una recta en el plano y las operaciones que se pueden realizar

sobre ella. Se define, a nivel interno, sobre la definición general de una recta: Ax + By +

C = 0.

� Recta(double factorX, double factorY, double

constante): Constructor de la recta que definen los factores de X, Y y

la constante.

� Recta(Punto punto, double pendiente): Constructor de la recta

que definen un punto y su pendiente.

� Recta(Punto p0, Punto p1): Constructor de la recta que define la

recta que pasa por dos puntos.


- 55 -

� Recta[] getParalelas(double distancia): Devuelve la dos

rectas paralelas a la dada, a una distancia determinada.

� Recta getPerpendicular(Punto punto): Devuelve la recta

perpendicular a la dada que pasa por un punto.

� Punto interseccion(Recta recta): Devuelve el punto de

intersección entre la recta y otra dada.

� double x(double y): Devuelve la posición x de un valor y dado, en

la recta.

� double y(double x): Devuelve la posición y de un valor x dado, en

la recta.

Punto: Define un punto en el plano y las operaciones que se pueden realizar

sobre él.

� Punto(double x, double y): Constructor de la clase.

� boolean equals(Punto punto): Indica si un punto dado, es igual

con el que se le compara.

Esqueleto: Esqueleto representa el esqueleto rectilíneo, o straight skeleton, de

un polígono junto con todos los métodos para ser calculado.

� Esqueleto(Lienzo lienzo, java.util.Vector vertices,

java.util.Vector puntos): Constructor que crea e inicializa el

esqueleto basándose en el lienzo donde está asociado, los vértices del

polígono y los puntos del polígono reducido.


- 56 -

� java.util.Vector getSolucion(java.awt.Graphics g,

boolean lento): Obtiene el esqueleto rectilíneo del polígono.

� void getDireccionParalelas(): Obtiene la dirección de las

paralelas.

PanelBotones: Botonera que muestra y controla sus acciones asociadas.

� PanelBotones(StraightSkeletons straightSkeletons):

Constructor que crea e inicializa la botonera. Se le pasa el esqueleto

rectilíneo para poder actualizar el resto de los componentes.

� void actionPerformed(java.awt.event.ActionEvent e):

Método de obligado desarrollo al implementar el escuchador de

pulsación.

PanelMensajes: Área de texto donde aparecen escritos los mensajes que va

dando la aplicación.

� PanelMensajes(): Constructor que inicializa el área de texto.

� void addMsg(java.lang.String msg): Añade una cadena al área

de texto.

� void borrarMensajes(): Borra todos los mensajes.

� PanelMensajes getInstancia(): Devuelve la instancia única en el

sistema de esta clase.


- 57 -

PanelSolucion: Área de texto donde aparecen escritos los segmentos que

forman el esqueleto rectilíneo del polígono, junto con los vértices internos que los

forman.

� PanelSolucion(): Constructor que inicializa el área de texto.

� void addMsg(java.lang.String msg): Añade un mensaje al área

de texto separándolo del resto del texto por un salto de línea.

� void addSegmento(Segmento segmento): Añade la representación

literal de un segmento separándolo de los otros segmentos por un salto de

línea.

� void borrarDatos(): Borra el área de datos.

PanelVertices: Área de texto donde aparecen escritos los vértices del

polígono o donde el usuario puede escribir y modificar los vértices para representar el

polígono que se desee. Implementa el escuchador de teclado para detectar cuándo es

modificado por el usuario.

� PanelVertices(StraightSkeletons straightSkeletons):

Constructor que inicializa el área de texto. Se le pasa el esqueleto

rectilíneo para poder actualizar el resto de los componentes.

� void actualizar(): Actualiza los datos del panel obteniéndolos del

polígono contenido en el lienzo del applet.

� void borrarDatos(): Borra todos los datos del área de texto.

� java.lang.String leerNumero(java.lang.String cadena,

int i): Lee un número de una cadena a partir de una posición

determinada.


- 58 -

� java.util.Vector leerPuntos(): Lee los puntos que hay en el

área de texto devolviendo un vector de puntos, en formato de pares de

números.


- 59 -

6 Entorno de implementación

6.1 Internet

Fue tras la segunda guerra mundial cuando se estableció una relación

institucional entre la comunidad científica y el sector empresarial de los Estados Unidos,

lo que llevó a que se crearan una serie de asociaciones como la NSF (National Science

Foundation) y ARPA (Advanced Research Projects Agency). Desde ARPA, Vannevar

Bush, que trabajó para la creación de estas agencias, escribió un artículo titulado "Cómo

podemos pensar" en el que describía un dispositivo teórico de almacenamiento y

extracción de datos al que llamó meme" y que utilizaría un sistema muy similar a lo que

hoy se llama HiperTexto.

ARPA fue creada por el presidente Dwight Einsenhower después de que los

soviéticos lanzasen el satélite Sputnik, en octubre de 1957, lo que provocó una crisis en

EEUU. ARPA fue formada para asegurarse que no volvieran a ser cogidos con la

guardia baja en cuanto a tecnología. En 1962, J.C.R. Licklider comenzó a trabajar en

ARPA. Licklider, un psicólogo e informático, creía que los ordenadores se podrían

utilizar para aumentar el pensamiento humano y sugirió que se estableciera una red de

ordenadores para permitir, a los investigadores de ARPA, comunicar información con el

resto de los trabajadores de manera eficiente.

En esta época, investigadores de instituciones de reconocido prestigio, como el

MIT (Massachusetts Institute of Technology), sentaron las bases tecnológicas que

facilitaron en años posteriores la creación de Internet. Leonard Kleinrock fue el primero

que habló sobre la teoría de conmutación por paquetes en su artículo "Flujo de

Información en Redes Amplias de Comunicación". J.C.R. Licklider y W. Clark,

escribieron "Comunicación hombre - ordenador" y Paul Baran publicó "Redes de

Comunicación Distribuida", en el que hablaba de redes conmutadas por paquetes, sin

punto único de interrupción.


- 60 -

En 1965, DARPA (U.S. Defense Advanced Research Projects Agency)

promueve un estudio sobre "Redes cooperativas de computadoras de tiempo

compartido" y al año siguiente Larry Roberts, del MIT, publica "Hacia una red

cooperativa de computadoras de tiempo compartido". Bob Taylor, director de IPTO

(Information Processing Techniques Office), quería encontrar una manera eficiente de

permitir compartir recursos informáticos a varios trabajadores y recogió la vieja idea de

Licklider de una red. Empleó a Larry Roberts para dirigir el proyecto y se convirtió en

el arquitecto principal de una nueva red de ordenadores conocida como Arpanet.

A finales de los años sesenta, una de las preocupaciones de las Fuerzas Armadas

de los Estados Unidos era conseguir una manera de que las comunicaciones estuvieran

descentralizadas, es decir, evitar un centro neurálgico de comunicaciones que pudiera

ser destruido en un eventual ataque militar con armas nucleares y que así, aún sufriendo

el ataque, las comunicaciones no se bloquearan, sino que solamente se perdiera un nodo.

Por fin, en 1969, DARPA y la compañía Rand Corporation desarrolló una red

sin nodos centrales basada en conmutación de paquetes tal y como había dicho Paul

Baran. La información se dividía en paquetes y cada paquete contenía la dirección de

origen, de destino, el número de secuencia y una cierta información de control. Los

paquetes al llegar al destino se ordenaban según el número de secuencia y se juntaban

para dar lugar a la información. Al viajar por la red paquetes, era más difícil perder

datos ya que, si un paquete no llegaba al destino o llegaba defectuoso, el ordenador

receptor debía sólo solicitar al ordenador emisor el paquete que le faltaba. El protocolo

de comunicaciones de llamó NCP (Network Control Protocol).

Arpanet conectó los ordenadores centrales a través de unos pequeños

ordenadores de pasarela conocidos como IMP (Interface Message Processors). El 1 de

septiembre de 1969, el primer IMP llegó a UCLA; un mes después el segundo fue

instalado en Stanford; después en UC Santa Barbara y , finalmente, en la universidad de

Utah.

En 1971 se creó el primer programa para enviar correo electrónico combinando

un programa interno de correo y otro de transferencia de ficheros. En ese mismo año, un


- 61 -

grupo de investigadores del MIT presentaron la propuesta del primer protocolo para la

transmisión de archivos, basado en el sistema de correo electrónico, y que sentó las

bases para el futuro protocolo de transmisión de ficheros FTP.

En los años setenta, la NSF (National Science Foundation) fue dando acceso a

sus seis centros de super-computación, a otras universidades a través de Arpanet. Poco a

poco, otros organismos y entidades se fueron conectando a la red mientras que los

responsables desarrollaban estándares y protocolos como Telnet o NVP (Network Voice

Protocol). También se creó la red Ethernet, la hawaiana ALOHANET y la red enlazada

de satélites, SATNET.

En 1974, Vinton Cerf, junto con Bob Kahn, publica "Protocolo para

intercomunicación de redes por paquetes" donde se especifica en detalle el diseño de un

nuevo protocolo: TCP (Transmission Control Protocol), que se convirtió en el estándar

aceptado. En 1979, ARPA crea la primera comisión de control de la configuración de

Internet y tras varios años de trabajo, en 1981, se termina de definir el protocolo TCP/IP

(Transfer Control Protocol / Internet Protocol) que es adoptado por Arpanet un año

más tarde, sustituyendo a NCP. En 1983, Arpanet se separa de la red militar que la

originó y esta fecha se conoce como el nacimiento de Internet.

En los años ochenta se multiplican las conexiones y los usuarios; aparecen

nuevos recursos y servicios; comienzan los primeros hackers y virus. En los Estados

Unidos, el gran aumento de usuarios provocó, en 1990, la retirada de la agencia ARPA

y pasa a estar a cargo de la NSF. Internet se comienza saturar y, para evitar el colapso,

se restringen los accesos.

También en 1990 y usando hipertexto, Tim Berners-Lee, crea el WWW (World

Wide Web) que provocará la apertura total de Internet a todos los usuarios unos años

más tarde. El WWW hacen mucho más fácil compartir y encontrar datos en la red. El

World Wide Web fue aumentado por otros y se creó nuevo software y tecnologías para

hacerlo más funcional como, por ejemplo, Marc Andreesen que creó un nuevo

navegador llamado Mosaic y después dirigió al equipo que creó Netscape Navigator.


- 62 -

Tim Berners-Lee creó las bases del protocolo de transmisión HTTP, el lenguaje de

documentos HTML y el concepto de las URL.

En septiembre de 1993 se inició el primer servidor web en español. Se aumentó,

además, la potencia de las redes troncales de EE.UU a la vez que se eliminó las

restricciones de uso comercial de la red y el gobierno de EEUU dejó de controlar la

información de Internet.

En 1995, se produce el gran “boom” de Internet cuando la WWW supera a FTP

en el servicio más popular de la red, después de que el año anterior superase a Telnet.

Se incrementa de manera exponencial el número de servicios que operan en la red:

banca, radio y televisión comercial, gobiernos, motores de búsqueda inteligentes en

varios idiomas, entornos virtuales (VRML), telefonía, comercio electrónico, telefonía

móvil, etcétera.

6.2 WWW y HTTP

Los tres servicios más usados en Internet son la visualización de páginas web, la

transferencia de ficheros y el correo electrónico. Cada uno de ellos funciona gracias a

unos protocolos estandarizados que permiten la conectividad correcta entre cualquier

máquina conectada a la red: para la transferencia de ficheros se usa el FTP, para el

envío y recepción de correo electrónico se usan POP3 y SMTP, y para visualizar

páginas web se usa el HTTP.

El HTTP (Hypertext Transfer Protocol), o protocolo de transferencia de

HiperTexto, es un sencillo protocolo cliente-servidor que articula los intercambios de

información entre los clientes y los servidores web, o de HTTP. La especificación

completa del protocolo HTTP 1/0 está recogida en el RFC 1945 y fue propuesta por Tim

Berners-Lee, como antes se ha contado, atendiendo a las necesidades del sistema global

de distribución de información llamado WWW (World Wide Web).


- 63 -

Desde el punto de vista de las comunicaciones, está soportado sobre los servicios

de conexión TCP/IP, y funciona de la misma forma que el resto de los servicios

comunes de los entornos en Internet: un proceso servidor escucha en un puerto de

comunicaciones TCP, por defecto el 80, y espera las solicitudes de conexión de los

clientes web. Una vez que se establece la conexión, el protocolo TCP se encarga de

mantener la comunicación y garantizar un intercambio de datos libre de errores.

HTTP se basa en sencillas operaciones de solicitud / respuesta de manera que,

cuando un cliente establece una conexión con un servidor, envía un mensaje con los

datos de la solicitud y el servidor responde con un mensaje similar, que contiene el

estado de la operación y su posible resultado. Todas las operaciones pueden adjuntar un

objeto o recurso sobre el que actúa: documento HTML, fichero multimedia, imágenes,

archivos de todo tipo, applets de Java, etcétera. Cada uno de estos recursos es conocido

por su URL (Uniform Resource Locator) que es la dirección unívoca que identifica ese

objeto en la red.

Los recursos, u objetos, que actúan como entrada o salida de un comando HTTP

están clasificados por su descripción MIME de manera que el protocolo puede

intercambiar cualquier tipo de dato sin preocuparse de su contenido. La transferencia se

realiza en modo binario, byte a byte, y la identificación MIME permitirá que el receptor

trate adecuadamente los datos.

MIME Extensión Tipo de fichero

text/html html, htm documento HTML

text/plain txt, default Texto plano

image/gif gif Imagen GIF

image/jpeg jpg, jpeg Imagen JPEG

Figura 53. Principales tipos MIME


- 64 -

Toda la comunicación entre los clientes y servidores se realiza a partir de

caracteres de 8 bits permitiendo transmitir cualquier tipo de documento, respetando su

formato original. No mantiene ningún tipo de estado y cada petición de un cliente a un

servidor no es influida por las transacciones anteriores: el servidor trata cada petición

como una operación totalmente independiente del resto.

Existen tres acciones básicas, o más usadas, por un cliente para dialogar con un

servidor: GET, para recoger un objeto; POST, para enviar información al servidor; y

HEAD, para solicitar las características de un objeto (por ejemplo, la fecha de

modificación de un documento HTML).

HTTP se diseñó específicamente para el WWW siendo un protocolo rápido y

sencillo que permite la transferencia de múltiples tipos de información de forma

eficiente y rápida. Se puede comparar, por ejemplo, con FTP, que es también un

protocolo de transferencia de ficheros pero con un conjunto muy amplio de comandos.

6.3 HTML

El HTML (HyperText Markup Language) es un lenguaje que permite visualizar

información con un formato específico que sea ‘portable’ de una plataforma a otra, es

decir, que es compatible sobre diferentes plataformas puesto que es un estándar. Los

documentos HTML son documentos SGML con semántica genérica y son apropiados para

representar información a partir de un amplio espectro de aplicaciones.

El HTML usa marcas para indicar el formato y las características del documento.

Estas marcas son fragmentos de texto destacado de una forma especial que permiten la

definición de las distintas instrucciones de HTML, tanto los efectos a aplicar sobre el

texto como las distintas estructuras del lenguaje. A estas marcas se las denomina

etiquetas, o tags, y son la base principal del lenguaje HTML de manera que un

documento HTML es un fichero texto con etiquetas que varían la forma de su

presentación.


- 65 -

Una etiqueta será un texto incluido entre los símbolos menor que, <, y mayor

que, >. El texto incluido dentro de los símbolos será explicativo de la utilidad de la

etiqueta. Por ejemplo:

<BR> <A> <TABLE> <APPLET> <HTML> <IMG>

Existe, normalmente, una etiqueta de inicio y otra de fin que contienen el mismo

texto interno salvo una barra inclinada, /, en el de fin, justo después de la apertura de tag

o etiqueta. El efecto que define la etiqueta tendrá validez para todo lo que este incluido

entre las etiquetas de inicio y fin, ya sea texto plano u otras etiquetas HTML.

<ETIQUETA>Elementos Afectados por la Etiqueta</ETIQUETA>

Por ejemplo, con la etiqueta siguiente, <B>, se indica que el texto debe ir en

negrita:

<B>Este texto irá en negrita</B> y este otro no

y se obtendrá:

Este texto irá en negrita y este otro no

Las etiquetas pueden presentar modificadores que se llaman atributos y que

permiten definir diferentes posibilidades de la instrucción HTML. Estos atributos se

definen en la etiqueta de inicio y consisten normalmente en el nombre del atributo y el

valor que toma separados por un signo de igual. El orden en que se incluyan los

atributos es indiferente y no afecta a el resultado. Un ejemplo de atributo es:

La palabra <FONT FACE=”Arial”>fuente</FONT> se verá con Arial

y se obtendrá:

La palabra fuente se verá con Arial

Un documento HTML está definido por una etiqueta de apertura <HTML> y una

etiqueta de cierre </HTML>. Dentro de este se dividen dos partes fundamentales: la


- 66 -

cabecera delimitada por la etiqueta <HEAD>, y el cuerpo delimitado por la etiqueta

<BODY>. Por tanto la estructura de un documento HTML es:

<HTML>

<HEAD>

datos de la cabecera

</HEAD>

<BODY>

texto y etiquetas

</BODY>

</HTML>

Es indiferente separar con saltos de línea lo escrito dado que en HTML se ignoran

todos los espacios, tabuladores y saltos de línea a partir de que se ponga uno. Para

realizar un salto de línea en el texto hay una etiqueta específica, <BR>. Por tanto, el

texto anterior se podría escribir de la siguiente forma sin que variase su representación

final a través del browser o visualizador:

<HTML><HEAD>datos de la cabecera</HEAD><BODY>texto y etiquetas</BODY></HTML>

Ninguno de estos elementos es obligatorio, salvo el par <HTML> </HTML>,

pudiendo componer documentos HTML que se muestren sin ningún problema sin incluir

estas etiquetas de identificación. Si se utilizan, por ejemplo, elementos que

forzosamente deban ser incluidos en la cabecera (como la etiqueta de titulo, <TITLE>),

no serán reconocidos correctamente si no se incluyen entre las etiquetas de <HEAD> y

</HEAD>.

En la cabecera de un documento HTML, delimitado por las etiquetas <HEAD> y

</HEAD> como ya se ha indicado, se pueden incluir diferentes definiciones generales

que afectarán a todo el documento. Todas son opcionales y se usan sólo en casos muy

determinados. Los componentes más comunes que se pueden incluir son:


- 67 -

<TITLE>, especifica el título del documento HTML y normalmente se muestra en

la parte superior de la ventana del navegador, browser o visualizador de HTML. Se utiliza

principalmente para etiquetar e identificar las páginas en los bookmarks, o marcadores,

y las history list, lista de documentos accedidos.

<BASE>, es la URL base del documento. Especificará la URL que se tomará como

base del documento HTML, esta se utilizará para las referencias a URL relativas dentro

del documento.

<ISINDEX>, indica que el documento es un índice, y por tanto se deberá realizar

una búsqueda en él.

<META>, indica información sobre la información contenida. Puede llegar a tener

una naturaleza muy variada que va desde indicar con qué editor se realizó la página a

ordenar el refresco de la página en un número de segundos.

En el cuerpo de un documento HTML, delimitado por las etiquetas <BODY> y

</BODY>, se incluye todo el texto del documento junto con su formato, el cual, viene

indicado por etiquetas. Existen una infinidad de etiquetas que permiten la deseada

visualización como la distribución en tablas, hacer saltos de línea, insertar de imágenes

o crear formularios.

Las etiquetas que se pueden encontrar dentro del cuerpo tienen diferentes

funciones, tanto de visualización como de ejecución, y aquí se listan las más habituales

que, además, se han usado en este proyecto.

<P>, define un párrafo o un cambio de párrafo. Se usa al comienzo o al final de

un párrafo de texto e introduce un espaciado de separación, normalmente dos líneas, con

el próximo texto que se exprese.

<BR>, define un salto de línea y su utilidad es similar al anterior pero, en este

caso, el espaciado del texto es menor y automáticamente se pasa a la línea siguiente, sin

dejar una línea de separación.


- 68 -

<HR>, regla horizontal que se usa para dividir un documento en distintas

secciones mostrando una línea horizontal de tamaño determinable.

<PRE>, define una zona de texto pre-formateado, es decir, que todo lo que se

encuentre entre las etiquetas de inicio y fin del texto se mostrará tal y como se expresa

en el fuente del documento HTML. Para mostrar este texto se utiliza una fuente de

espaciado fijo más pequeña que el texto normal.

<CENTER>, centrado de texto e imágenes. Se usa para centrar líneas de texto,

imágenes o cualquier otro elemento HTML (tablas, listas, etc ...).

representa a un espacio en blanco. Con esta secuencia de caracteres se

consigue espacios en blanco que se mostrarán de forma efectiva dado que, como antes

se indicó, para los visualizadores de HTML, sólo se considera un espacio cualquier

cadena de espacios, tabuladores y saltos de línea que existan en el código fuente.

Para representar caracteres especiales, como caracteres acentuados, que no se

pueden incluir en un documento de manera normal, se deben utilizar una serie de

secuencias de escape que al mostrar el documento se sustituyen por el carácter deseado.

Estas secuencias de escape comienzan todas con el símbolo & seguido de un texto,

siempre en minúsculas, que define el carácter deseado y termina con el símbolo de

punto y coma, ;. Por ejemplo, y poniendo entre paréntesis el símbolo resultante, <

(<),> (>), & (&), " (“), á (á), ú (ú),

ñ (ñ), ì (ì), Ü (Ü), ® (®), © (©).

<FONT>, define la fuente, en tamaño, estilo, color y resto de características, a

través de atributos.

<A HREF=...>, es un hiperenlace, es decir, un enlace a otro documento o

elemento externo al documento actual pudiendo estar localizado a través de su URL que

es el valor que se define en el atributo HREF.


- 69 -

<IMG SRC=...>, inclusión de una imagen localizada en la URL que indica el

atributo SRC. Los tipos de gráficos soportados por los navegadores son dos de los más

comunes, GIF y JPEG.

<TABLE>, define una tabla. Visualiza, en forma de tabla, filas y columnas, la

información que se desee. Las filas, dentro de la etiqueta de tabla, se indican con las

etiquetas <TR> y </TR>. Las columnas, dentro de las filas, se definen con las etiquetas

<TD> y </TD>. Admite atributos que modifican la visualización como bordes, espacio

de celdas, espacio entre celdas, ancho de celdas, etcétera.

<FORM>, indica que el bloque entre la etiqueta de inicio y fin es un formulario o

plantillas que permiten la creación de documentos HTML con peticiones de datos a un

servidor. La principal utilidad de los formularios es la posibilidad de crear cuestionarios,

encuestas, páginas de comentarios o cualquier documento en la que se desee una

interacción por parte del usuario.

Para los colores se usa normalmente el siguiente formato: #rrvvaa donde se

indica en formato hexadecimal la proporción de rojo, verde y azul que forma el color

deseado.

Los atributos de la etiqueta del cuerpo, <BODY>, son de definición global para

todo el documento y estos definirán los colores y el fondo del documento HTML, por

ejemplo. Los atributos de BODY son: BACKGROUND, define la imagen que se utilizará de

fondo del documento HTML; BGCOLOR, indica el color del fondo del documento HTML;

TEXT especifica el color del texto normal dentro del documento; LINK, indica el color

que tendrán los hiperenlaces que no han sido accedidos; VLINK, indica el color de los

enlaces que ya han sido visitados.

6.4 Antecedentes y conceptos sobre Java

Cuando se desarrolla una aplicación en un lenguaje como C o C++, por ejemplo,

el archivo binario que genera el compilador, y que contiene el código que implementa


- 70 -

dicha aplicación, se puede ejecutar únicamente sobre la plataforma sobre la cual fue

desarrollada debido a que dicho código es específico a esa plataforma.

La plataforma Java se encuentra por encima de plataformas. El código que

generan los compiladores Java no es específico de una maquina física en particular,

sino de una máquina virtual, MVJ (máquina virtual Java). Aunque existen múltiples

implantaciones de la MVJ, cada una específica de la plataforma sobre la que funciona,

existe una única especificación de la máquina virtual que proporciona una vista

independiente del hardware y del sistema operativo sobre el que se esté trabajando. De

esta manera un programador en Java escribe su programa una vez, y lo ejecuta sobre la

plataforma que quiera, siempre que posea una máquina virtual conforme al estándar.

La MVJ es la clave de la independencia de los programas Java sobre el sistema

operativo y el hardware en que se ejecutan ya que se encarga de proporcionar la vista de

un nivel de abstracción superior donde, además de la independencia de la plataforma

mencionada, presenta un lenguaje de programación simple, orientado a objetos, con

verificación estricta de tipos de datos, múltiples hilos, con ligado dinámico y con

recolección automática de basura (objetos no usados o no referenciados que se generan

en tiempo de ejecución).

El concepto de máquina virtual es antiguo: fue usado por IBM en 1959 para

describir uno de los primeros sistemas operativos que existieron en la historia de la

computación, el VM. En 1970, el entorno de programación de SmallTalk llevó la idea

a un nuevo nivel y construyó una máquina virtual para soportar abstracciones orientadas

a objetos de alto nivel sobre las máquinas subyacentes.

Las máquinas virtuales tienen varias ventajas importantes. La primera es que

presentan un medio excelente para alcanzar la compatibilidad entre plataformas

diferentes, también llamado, portabilidad. Otra de las ventajas importantes es que

introduce otro nivel de abstracción y de protección entre la computadora y el software

que ejecuta sobre ella. Esto cobra particular importancia en un ambiente donde el

código que se ejecuta proviene de cualquier lugar del mundo, como los appets por

Internet..


- 71 -

Los lenguajes totalmente interpretados, como Tcl y JavaScript, también son

altamente portables y seguros, pero estos no se basan en una máquina virtual lo que

tiene una implicación directa sobre la eficiencia. Para ejecutar un programa escrito en

un lenguaje completamente interpretado, el intérprete debe realizar el análisis léxico y

sintáctico en el momento de estar ejecutando el programa, lo que provoca una

sobrecarga muy considerable en la ejecución del mismo. Algunas pruebas de Tcl han

llegado a ser hasta 200 veces más lento que C.

Los lenguajes basados en una máquina virtual, comúnmente son más rápidos que

los totalmente interpretados, debido a que utilizan una arquitectura de código intermedio.

La idea es dividir la tarea de ejecutar un programa en dos partes. En la primera, se

realiza el análisis léxico y sintáctico del programa fuente para generar el programa en

instrucciones del procesador virtual, también llamado código intermedio, y en el

segundo paso, se itera sobre el código intermedio para obtener la ejecución final del

programa.

Por todo esto, los lenguajes compilados de código intermedio son mucho más

rápidos que los lenguajes completamente interpretados pero más lentos que lenguajes

optimizados como C o C++.

Java es un lenguaje de programación de Sun Microsystems originalmente

llamado Oak, que fue concebido bajo la dirección de James Gosling y Bill Joy, quienes

pertenecían a una empresa subsidiaria de Sun, conocida como FirstPerson Inc. Tras

unos comienzos dudosos, Sun decidió crear esta filial para dar margen de maniobra al

equipo responsable del proyecto y fue en el proyecto Green donde se aplicó por primera

vez Java. Consistía en un sistema de control completo de los aparatos electrónicos y el

entorno de un hogar. Con este fin se construyó un ordenador experimental denominado

*7 (Star Seven). El sistema presentaba una interfaz basada en la representación de la

casa de forma animada y el control se llevaba a cabo mediante una pantalla sensible al

tacto. En el sistema aparecía ya Duke, la mascota de Java.

Posteriormente, Java se aplicó de nuevo a otro proyecto llamado VOD (Video

On Demand) en el que se empleaba como interfaz para la televisión interactiva que se


- 72 -

pensaba iba a ser el principal campo de aplicación de Java. Ninguno de estos proyectos

se convirtió nunca en un sistema comercial, pero fueron desarrollados enteramente en

un Java primitivo. Una vez que en Sun se dieron cuenta de que a corto plazo la

televisión interactiva no iba a ser un gran éxito, pidieron a FirstPerson que desarrollara

con rapidez nuevas estrategias que produjeran beneficios, entre los que se encontraba su

aplicación en Internet aunque, en ese momento no se juzgó productivo. FirstPerson

cerró en la primavera de 1994.

No pasó mucho tiempo, cuando en Sun se dieron cuenta de que todas estas

características cubrían a la perfección las necesidades de las aplicaciones de Internet. De

esta manera, con unos cuantos retoques, Oak se convirtió en el lenguaje actualmente

conocido como Java, debido a que dicho nombre ya estaba registrado por otra empresa.

Aunado a todas las características que posee Java (modelo de objetos dinámico,

sistema estricto de tipos, paquetes, hilos, excepciones, etcétera), cuando Nestcape Inc.

anunció su incorporación dentro de su navegador Netscape Navigator el nivel de interés

sobre el lenguaje creció drásticamente debido al número importantísimo de personas

que utilizan WWW diariamente.

Hoy en día Java es el lenguaje más usado en el entorno de Internet debido a sus

características, tanto en cliente como en servidor, teniendo como competidor la

arquitectura de Microsoft, .Net.

Pero no todo son ventajas con las máquinas virtuales. Una de las razones por las

que las máquinas virtuales no son la panacea de la computación es que agregan gran

complejidad al sistema en tiempo de ejecución. Por ejemplo, la MVJ espera que la

computadora sobre la que subyace, soporte el estándar de IEEE para los números de

punto flotante de 32 y 64 bits, así como enteros largos de 64 bits. La mayoría de las

plataformas lo hacen pero hay algunas que no, lo que implica procesamiento extra.

La principal desventaja de los lenguajes basados en máquina virtual es que,

efectivamente, son más lentos que los lenguajes completamente compilados debido a la

sobrecarga que genera tener una capa de software intermedia entre la aplicación y el


- 73 -

hardware de la computadora. El rendimiento se ha mejorado mucho de muy variadas

formas como, por ejemplo, mejorando los algoritmos de recolección de basura, de

asignación de memoria, de ejecución de métodos, etcétera. Además, existen unos chips

que tienen la capacidad de ejecutar directamente el código del procesador virtual Java.

El código Java, código JIT o compilado justo en el momento, tampoco puede

competir con el código completamente compilado de C debido a que los compiladores

son diseñados para obtener todas las ventajas posibles de la arquitectura sobre la que

subyace mientras que Java tiene que cargar con las restricciones que impone el diseño

del conjunto de instrucciones del procesador virtual que están basadas en el uso de la

pila.

6.5 Java

Java es un lenguaje de programación compilado de código intermedio que es

totalmente portable, es decir, multiplataforma. Esta es sin duda la cualidad esencial de

Java que le separa de otros lenguajes y que tan cerca lo ha situado de Internet, donde

existen una multitud de plataformas conectadas al mismo entorno y compartiendo

recursos. Es posible ejecutar el mismo archivo de clase, fichero con extensión .class,

sobre una amplia variedad de arquitecturas de hardware y de software, sin ninguna

modificación.

Java es un lenguaje dinámico, debido a que las clases son cargadas en el

momento en que son necesitadas, ya sea del sistema de archivos local o desde algún

sitio de la red mediante algún protocolo URL.

Java tiene la capacidad de aumentar su sistema de tipos de datos dinámicamente

o en tiempo de ejecución. Este late-binding, enlace tardío, significa que los programas

sólo crecen al tamaño estrictamente necesario, aumentando así la eficiencia del uso de

los recursos. Java hace menos suposiciones sobre las implantaciones de las estructuras


- 74 -

de datos que los lenguajes estáticos de early-binding, o enlace temprano, es decir, en

tiempo de compilación como C o C++.

Debido a que Java nació en la era post-Internet, fue diseñado con la idea de la

seguridad y la fiabilidad de ahí que se integraron varias capas de seguridad para evitar

que programas maliciosos pudiesen causar daños en los sistemas sobre los que ejecuta

la implantación de la MVJ.

La MVJ, máquina virtual Java, es el núcleo del lenguaje. De hecho, es

imposible ejecutar un programa Java sin ejecutar alguna implantación de la MVJ. En la

MVJ se encuentra el motor que en realidad ejecuta el programa y es la clave de muchas

de las características principales como la portabilidad, la eficiencia y la seguridad.

Siempre que se corre un programa Java, las instrucciones que lo componen no

son ejecutadas directamente por el hardware sobre el que subyace sino que son pasadas

a un elemento de software intermedio que es el encargado de que las instrucciones sean

ejecutadas por el hardware. Es decir, el código Java no se ejecuta directamente sobre

un procesador físico sino sobre un procesador virtual Java que es, precisamente, el

software intermedio comentado anteriormente.

Sun utiliza el término máquina virtual Java para referirse a la especificación

abstracta de una máquina de software para ejecutar programas Java. La especificación

de esta máquina virtual define elementos como el formato de los archivos de clases, así

como la semántica de cada una de las instrucciones que componen el conjunto de

instrucciones de la máquina virtual. A las diferentes implantaciones de esta

especificación se les conocen como JRE, Java Runtime Environment o sistema en

tiempo de ejecución Java.

Las MVJ incluyen una serie de elementos comunes que aportan las

características básicas de un JRE. Algunos de estos elementos son:

Un motor de ejecución que se compone de un procesador virtual que se encarga

de ejecutar el código Java, bytecode, generado por algún compilador.


- 75 -

Un manejador de memoria encargado de obtener memoria para las nuevas

instancias de objetos, arreglos, etcétera, y realizar tareas de recolección de basura, es

decir, la liberación de espacio de memoria que ha dejado de usarse.

Un manejador de errores y excepciones que se encargado de generar, lanzar y

atrapar excepciones, tanto a nivel de aplicación como de errores de compilación,

ejecución o de recursos.

El soporte de métodos nativos es el encargado de la ejecución de los interfaces

con otros lenguajes desde Java, tanto en un sentido como en el otro.

El interfaz multihilos permite la ejecución de varios hilos de aplicación y

monitores que permiten el trabajo concurrente.

La función del cargador de clases es cargar dinámicamente las clases Java a

partir de los archivos de clase, ficheros con extensión .class.

Existe, además, un módulo de administración de seguridad que se encarga de

asegurar que las clases cargadas sean seguras y que no hacen un uso indebido de los

recursos del sistema.

Adicionalmente, existe un conjunto de clases Java estándar fuertemente ligadas

a la implantación de cada MVJ en particular, llamadas librerías. Las funciones

principales que cubren estas clases son los recursos básicos como los accesos a los

recursos de la red, el manejo del sistema de ventanas, los hilos y el sistema de archivos

local. Todos estos elementos en conjunto actúan como una interfaz de alto nivel, para

acceder a los recursos del sistema operativo. Es esta interfaz la clave de la portabilidad

de los programas Java, debido a que independientemente del hardware o sistema

operativo sobre el que se esté trabajando, la máquina virtual oculta todas estas

diferencias.


- 76 -

6.6 Applets

Los programas Java se dividen en tres grupos: applets, servlets y aplicaciones

propiamente dichas.

Los servlets son programas Java que se encuentran en un servidor de

aplicaciones, normalmente asociado a un servidor web, y que se activan a través de una

URL, es decir, de peticiones HTTP como si de una página HTML normal se tratará. La

petición pone en marcha el servlet que tras ejecutarse debe responder, o devolver, al

llamante una respuesta, tal y como indica el protocolo, que suele ser una página HTML.

Es importante destacar que la ejecución del servlet ser produce en el servidor web y no

en el navegador, o browser, es decir, que el cliente no tiene por qué poseer una JRE,

mientras que el servidor de aplicaciones sí.

Las aplicaciones son programas independientes y más generales escritos en

lenguaje Java. Estas aplicaciones necesitan solamente un entorno de ejecución, JRE,

para poder lanzarse y, de hecho, se pueden utilizar como se hace con C o Pascal. Por

ejemplo, el navegador de web creado por Sun, HotJava, es una aplicación escrita

íntegramente en lenguaje Java.

Los applets son programas Java que se ejecutan dentro de una página HTML, es

decir, dentro de un navegador que, como es lógico, tendrá integrado un JRE para poder

ejecutarlos. La mayoría de los navegadores actuales lo traen instalado por defecto o

ponen herramientas automáticas para su instalación. Los applets, como parte de un

documento HTML, son referenciados como cualquier otro elemento estático, por ejemplo,

una imagen, a través de una URL y será enviada, igualmente, por un servidor web.

Los applets se encuentran, por tanto, en los servidores de páginas web como un

recurso estático más y son ejecutados por los navegadores en el ordenador cliente.

También es importante destacar que, aún estando en un servidor web, jamás se ejecutará

allí y sólo se hará cuando sea descargado en un ordenador, dentro de una página HTML.


- 77 -

Un mismo programa Java puede ser un applet y una aplicación a la vez,

dependiendo de cómo se diseñe e implemente el programa.

Al ejecutarse sobre un entorno gráfico, se le ha aportado unas características

como gráficos sofisticados, elementos de interfaz de usuario, funciones de red y otras

herramientas para tratar eventos generados tanto por el usuario como por el sistema.

Las ventajas de los applets sobre las aplicaciones, respecto a gráficos e

interfaces de usuario, se ven mermadas por fuertes restricciones de seguridad. Dado que

los applets viven residentes en los servidores web de Internet y se ejecutan en el sistema

cliente de cualquier usuario de la red, son necesarias ciertas restricciones para prevenir

que un applet pueda producir efectos no deseados. Si no existieran estas restricciones,

se podrían escribir applets que actuaran como caballos de Troya o cualquier otro virus.

Las restricciones son las siguientes: uno, los applets no pueden leer o escribir en

el sistema de ficheros del ordenador cliente excepto en directorios especificados por el

usuario a través de una lista de control que, por defecto, se encuentra vacía; dos, los

applets no pueden establecer una comunicación con ningún otro servidor que no sea el

que sirvió el applet; tres, no se permite a un applet ejecutar un programa de los que se

encuentran en el sistema cliente; cuatro, tampoco se permite a un applet cargar

programas nativos en la estación cliente, incluyendo librerías de acceso dinámico.

En la versión 1.1 de Java, Java 1.1, se introduce el concepto de signed applet,

o applet firmado, en el que los applets que poseen una firma digital correcta son

considerados como fiables. Estos reciben los mismos privilegios que el código obtenido

del sistema de archivos, es decir, que tienen permisos para acceder a los recursos locales.

Los applets firmados, junto con la firma, se envían en un archivo CAB (Cabine), para el

navegador Microsoft Internet Explorer, o en un archivo JAR (Java Archive), para todos

los demás navegadores.

Un applet, para serlo, tiene que heredar de una clase perteneciente a las librerías

básicas de Java, java.applet.Applet. Este es el requisito necesario y suficiente

para que una clase sea un applet. De la misma manera que una aplicación ha de tener


- 78 -

implementado el método public static void main(String args[]) y un

servlet ha de heredar de javax.servlet.http.HttpServlet.

Cuando se lanza una aplicación, lo primero que se ejecuta es el método main, de

manera similar al resto de lenguajes de programación, y ese es el inicio de la ejecución.

El caso de los applets es distinto dado que siguen un ciclo de vida. Un applet, cuando

pasa de un estado a otro del ciclo de vida, se ejecuta un método predeterminado y

establecido por el estándar a través de un evento.

Los cinco métodos que conforman el ciclo de vida de un applet son:

public void init(), la inicialización ocurre cuando el applet se carga por

primera vez, junto con la página HTML de donde se le invoca. La inicialización implica

crear nuevos objetos, inicializar variables, cargar imágenes o fuentes, etcétera.

public void start(), es llamado tras el método init y cada vez que el

applet se lance de nuevo después de haber sido parado. Esto ocurre cuando se cambia de

página HTML o se minimiza el navegador. Este método se puede llamar varias veces

durante el ciclo de vida del applet mientras que el método init sólo es llamado una

única vez.

public void stop(), es llamado al cambiar de página HTML. Por defecto,

cuando el usuario cambia de página, el applet continúa ejecutándose utilizando los

recursos del sistema. Sobreescribiendo el método stop se puede suspender la ejecución

del applet o realizar otras acciones.

public void destroy(), es llamado cuando el usuario abandona el

navegador, finalizando la ejecución del applet con la consiguiente liberación de recursos.

public void paint(java.awt.Graphics), es llamado cada vez que hay

que dibujar la ventana o área de ventana donde se ejecuta el applet. Este método se

puede invocar muchas veces durante el ciclo de vida de un applet, por ejemplo, al

inicializar el applet, si el navegador, ocultado por otra ventana, vuelve a ser la ventana

activa, si se mueve la ventana, o en el caso de animaciones. Este método tiene un


- 79 -

argumento, una instancia de la clase java.awt.Graphics que referencia es espacio o

panel gráfico que se visualiza en pantalla.

Para poder insertar un applet en una página HTML, como para insertar cualquier

otro elemento, se usa una etiqueta con diferentes atributos que indican el applet y resto

de datos necesarios, o recomendables, para visualizarlo.

La etiqueta es <APPLET> y tiene su etiqueta final, </APPLET>, para que se

pueda almacenar los parámetros que se quieran introducir en la ejecución. Estos

parámetros se introducen con la etiqueta <PARAM>, donde sus atributos NAME y VALUE

indican los nombres y los valores.

Dentro de la etiqueta <APPLET> va el atributo CODE que indica la clase, el

fichero con extensión .class, que es el applet. Si el fichero está en un directorio, se

indica con el atributo CODEBASE su ubicación. También se pueden definir el ancho,

WIDTH, el alto, HEIGTH, del applet dentro de la página.

Un ejemplo de todo esto es:

<APPLET CODE=Ejem.class CODEBASE=’./dir’ WIDTH=300 HEIGTH=500>

<PARAM NAME=nombreParametro VALUE=valorParametro>

Esto es un applet de ejemplo llamado Ejem

</APPLET>

6.7 Requisitos

Para poder navegar por el entorno de la aplicación se requiere un navegador web,

o browser, que se puede encontrar incluido en la instalación básica de cualquier sistema

operativo. Se recomienda el navegador de Microsoft, el Internet Explorer, debido a que

es el más popular aunque no hay problema en trabajar con cualquier otro.


- 80 -

Para ejecutar la aplicación, hace falta tener instalado un entorno de ejecución

Java, es decir, un JRE. Todos ellos, incluyen en su instalación el pluggin para el

navegador. La versión es indiferente pues se ha desarrollado en la más baja, Java 1.0,

para total compatibilidad con todas las instalaciones. En el entorno de trabajo se puede

encontrar la versión 1.4.1 para Windows. Para otras distribuciones se recomienda

acceder a la página de Sun Microsistems donde están accesibles, de manera gratuita,

todas las versiones.

Existen dos tipos de documentos en el entorno, documentos web y pdf. Para la

visualización de documentos web, HTML y MHT, se pueden realizar con el mismo

navegador. Para los documentos pdf hace falta el Adobe Acrobat Reader, como mínimo.

Este es un software de la casa Adobe para la visualización de documentos. Es gratuito y

que también se incluye el instalador de la versión 5.0 en el entorno.


- 81 -

7 Utilización del entorno

7.1 Navegación por el entorno

La aplicación está enmarcada en una web que contiene toda la documentación,

instrucciones y datos sobre el proyecto, incluida esta memoria. Todo ello está

enmarcado en páginas HTML que son visibles con cualquier navegador web. Además, si

el navegador incluye una máquina virtual Java, también podrá ejecutar el applet.

Figura 54. Entorno

Todas las pantallas tienen una cabecera, que incluye el título de proyecto y de la

página que se está visualizando. Tras esto, hay una barra de navegación que permite

volver al último click, a la página principal, imprimir la pantalla visualizada en ese

momento e ir al final de documento (figura 55).


- 82 -

Figura 55. Cabecera

Si, además, hay desplazamiento vertical, aparecerá a la derecha una barra de

desplazamiento (figura 56).

Figura 56. Desplazamiento

La página principal, o índice, incluye enlaces a todas los recursos y componentes

de la web. Está dividido por temas: información básica, instrucciones de uso,

programas, documentación y descargas.

La información básica, incluye el ámbito y el resumen del proyecto (figura 57).

Figura 57. Información básica

En instrucciones de uso se puede encontrar la documentación para poder trabajar

con el software, tanto el applet como la aplicación, y obtener los esqueletos rectilíneos

de los polígonos que se desee (figura 58).

Figura 58. Instrucciones de uso

En programas, se encuentran las dos opciones implementadas: un applet que se

puede ejecutar en el mismo entorno web, y una aplicación que se puede descargar para

su ejecución sin navegador y sin tener que estar conectado a la red (figura 59).


- 83 -

Figura 59. Programas

En la documentación se pueden encontrar todos los fuentes la aplicación, la

documentación del código (javadoc), esta misma memoria y la bibliografía y enlaces

usados para la realización de este proyecto (figura 60).

Figura 60. Documentación

Por último, en la sección descargas, se puede encontrar los requisitos necesarios

para visualizar y ejecutar todo el entorno. Además, se incluye todo el software necesario

para poder ser descargado e instalado en el momento como la máquina virtual 1.4.1 y el

Acrobar Reader (figura 61).

Figura 61. Descargas

7.2 Ejecución

El entorno de ejecución de la aplicación se compone de una serie de paneles,

unos de trabajo, otros informativos, además de una serie de botones que contienen la

funcionalidad para dibujar los polígonos que se deseen y obtener sus esqueletos

rectilíneos o straight skeletons (figura 62).


- 84 -

Figura 62. Entorno de ejecución

El panel de dibujo, o lienzo, es el rectángulo blanco bordeado por una fina línea

roja que se presenta en el centro (figura 63). En ella, se podrá dibujar el polígono que se

desee, visualizar polígonos introducidos por texto, ver la ejecución del algoritmo y,

finalmente, ver el straight skeleton.

Figura 63. Lienzo


- 85 -

Para poder pintar un polígono, tan sólo hay que ir pulsando un botón del ratón

donde se quiera un vértice. Cada vez que se mueva el ratón, una vez pulsada el primer

vértice, se irá visualizando.

Figura 64. Botonera

La botonera, o conjunto de botones que se pueden ver en la parte inferior

izquierda, es una de las partes más importantes del sistema (figura 64). Los botones

contienen las acciones a realizar sobre el lienzo y el polígono dibujado. Contienen un

texto suficientemente explicativo de su funcionalidad que, para mayor claridad, se

describe aquí mismo.

Limpiar: este botón borra el polígono dibujado en el lienzo, se encuentre

en el estado que sea (figura 65). Además, borra el resultado actual del panel de

soluciones y todos los mensajes del panel de mensajes. Como resultado de todo

ello, los botones quedan en su estado inicial, para poder trabajar con ellos, y no

borra el panel de vértices, para poder trabajar con el último polígono creado.

Figura 65. Limpiar

Cerrar: este botón intenta cerrar el polígono. Esto sucederá

correctamente mientras haya más de un lado en el lienzo, no existan lados que se


- 86 -

crucen, el polígono dibujado no esté cerrado ya y, por último, si los dos

extremos se pueden unir son provocar cruces a su vez (figura 66).

Figura 66. Cerrar

Ejecutar: este botón lanza el cálculo del esqueleto rectilíneo, o straight

skeleton, Para ello, el polígono debe estar cerrado (figura 67).

Figura 67. Ejecutar

Ejecutar lento: este botón lanza la misma acción que el botón de

‘Ejecutar‘ con un retardo para que se pueda ver más despacio la ejecución del

cálculo (figura 68).

Figura 68. Ejecutar lento

Introducir vértices: este botón borra el polígono que hay en el lienzo en

ese momento y lo sustituye por la secuencia de puntos que hay escrita en el

panel de vértices. Se van añadiendo los lados del nuevo polígono uno a uno,

sobre el que había, para ver las diferencias y cuales son los lados. Esto es

especialmente útil cuando existen lados paralelos consecutivos (figura 69).

Figura 69. Introducir vértices

Todos los botones estarán, dependiendo del estado de la aplicación, habilitados o

deshabilitados para su uso. Por ejemplo, los botones de Ejecutar y Ejecutar lento están

deshabilitados mientras no se cierre el polígono pues no tiene sentido lanzar el cálculo

cuando no hay un polígono cerrado.

El panel de vértices es el panel que hay arriba a la derecha, bajo el rótulo azul

que pone Vértices, y contiene, en principio, los vértices del último polígono dibujado y


- 87 -

cerrado en el lienzo (figura 70). En cualquier momento se puede escribir sobre él para

modificar los datos existentes. Debido a esto, si el texto aparece en color azul, significa

que son los vértices del último polígono dibujado, en cambio, si aparece en color rojo,

significa que se ha modificado el contenido y no tiene por que corresponder con lo

dibujado.

Figura 70. Panel de vértices

Sobre este mismo panel, el panel de vértices, se puede hacer copiar/pegar para

trasladar polígonos obtenidos en otro lugar. Por otro lado, cuando se quiere trasladar los

puntos escritos en el panel de vértices a el lienzo, se debe pulsar el botón Introducir

vértices. Después de esto, se puede seguir dibujando, a mano, sobre el lienzo hasta el

cierre del polígono.

Los vértices escritos, aquí o en otros paneles, tendrán el formato de puntos en el

plano, es decir, un par de números entre paréntesis, separados por una coma, y, si tienen

decimales, se separarán por un punto de la parte entera. Por ejemplo, (258.23 ,

92.7). Entre los diferentes puntos puede haber espacios, tabuladores, saltos de línea o

nada.

El panel de solución está situado a la derecha, bajo el rótulo verde que pone

Solución y contiene el resultado del cálculo del esqueleto rectilíneo (figura 71). Cada

vez que se limpia el lienzo se limpia automáticamente este panel. No se puede escribir


- 88 -

sobre él aunque si hacer copiar/pegar. Si se cierra el polígono, aparecerá la información

básica sobre el polígono: el número de lados del polígono, el número de vértices y el

número segmentos que tendrá el esqueleto rectilíneo, o straight skeleton.

Figura 71. Panel de solución

Cuando se lanza el cálculo del esqueleto rectilíneo, irán apareciendo los vértices

obtenidos y, cuando finalice, aparecerán todos y cada uno de los segmentos que forman

el esqueleto. Estos últimos, aparecerán como un par, entre corchetes, de dos puntos. Los

puntos aparecerán siempre con el formato indicado en el panel de vértices.

Figura 72. Panel de mensajes


- 89 -

El panel de mensajes está situado abajo a la derecha, es decir, bajo el panel de

solución y a la diestra de la botonera (figura 72). En él, irán apareciendo los mensajes

propios del trabajo y la ejecución sobre esta aplicación: lectura de datos el panel de

vértices, resultado del parseo de esos datos, borrado del lienzo, el cierre del polígono y

su resultado, etcétera.

Tras tener el polígono cerrado en el lienzo, se puede lanzar la ejecución pulsando

Ejecutar o Ejecutar lento resultado el mismo cálculo, tan sólo diferenciado por la

velocidad del mismo. Según se lance la ejecución, los lados del polígono se irán

reduciendo hasta que se produzca uno de los dos eventos explicados en la parte teórica.

Cuando se produzcan, se verá una pequeña animación sobre él, para verlo con más

claridad, en forma de onda de agua de color verde.

Al final del cálculo, aparecerá, también en verde, el esqueleto rectilíneo dentro

del polígono sobre el lienzo y los datos en el panel de solución.


- 90 -

8 Conclusiones y comentarios

Encontrar una forma única de construir tejados perfectos a dos aguas a través de

un algoritmo computacional ha sido toda una sorpresa. Las similitudes y diferencias con

otros algoritmos como los diagramas de Voronoi han conseguido una mayor

comprensión de ambos algoritmos.

Por encima de todo, la realización de este proyecto ha sido muy interesante y ha

servido para aprender muchísimo sobre aplicaciones web, cálculo computacional y

resolución eficiente de algoritmos.

El cálculo de los straight skeletons se basa en un algoritmo relativamente

sencillo que, de manera recursiva, resuelve el esqueleto. Su simplicidad teórica esconde

una complejidad en su implementación no prevista dado que las múltiples posibilidades

y casuísticas no eran previsibles como encontrar polígonos de dos lados, factores de

reducción o redondeos.

El redondeo es un tema a destacar dado que tiene una importancia capital en la

resolución. El único software libre localizado, antes de la presentación de este proyecto,

que intentaba resolver los esqueletos rectilíneos falla en su resolución por varios

aspectos, destacando entre todos ellos, el redondeo. El redondeo era un aspecto tenido

en cuenta pero con una incidencia no prevista.

Hacer cálculos muy precisos y repetitivos, dado que el cálculo es recursivo,

implica tener poner límites y redondeos a los números para no ir acarreando errores que,

a la larga, acaban desvirtuando el resultado. Hay cálculos especialmente sensibles como

son las paralelas de dos lados consecutivos paralelos a su vez. Esto, al hacer cálculos,

puede dar lugar a paralelas que no son paralelas a su vez debido a los redondeos y sus

intersecciones tremendamente desplazadas de la realidad.

Es importante destacar, además, las implicaciones de los factores de reducción

sobre el cálculo. Como ya se ha indicado, ajustar ese factor es imprescindible a la hora


- 91 -

de no redundar en cálculos y no encontrar en cada reducción eventos simultáneos

cuando no se deberían encontrar.

Localizar un entorno agradable y con facilidad para la ejecución ha sido un reto

de investigación y búsqueda. Analizar otras webs, software, versiones y herramientas de

implementación, también ha sido interesante y ha servido para aprender más sobre estos

entornos.


- 92 -

9 Bibliografía y enlaces

9.1 Artículos

“Novel Type of Skeleton for Polygons”

Oswin Aichholzer, David Alberts, Franz Aurenhammer y Bernd Gartner.

1995, 9 páginas

“A CGAL implementation of the Straight Skeleton of a Simple 2D Polygon with Holes”

Fernando Cacciola.

CGAL web, 4 páginas

“Raising Roofs, Crashing Cycles, and Playing Pool”

David Eppstein y Jeff Erickson.

Discrete & Computational Geometry, 28 de marzo de 1999, 24 páginas

“Straight Skeletons Implementation”

Petr Felkel y Stepan Obdrzalek.

Extraído de Proceedings of Spring Conference on Computer Graphics,

Ed. Lazlo Szirmay-Kalos

9.2 Direcciones web

“Roofs”

http://vterrain.org/Culture/BldCity/roofs.html


- 93 -

“Designing Roofs of Buildings”

http://www.sable.mcgill.ca/~dbelan2/roofs/roofs.html

“Raising roofs, crashing cycles, and playing pool”

http://compgeom.cs.uiuc.edu/~jeffe/pubs/cycles.html

“CGAL (Computational Geometry Algomithms Library)”

http://www.cgal.org/

“Geometría Analítica”

http://apuntes.rincondelvago.com/geometria-analitica.html


- 94 -

10 Anexos

10.1 Tabla de ilustraciones

Figura 1. Polígono de ejemplo........................................................................................ 11

Figura 2. Paralelas de un polígono.................................................................................. 11

Figura 3. Intersecciones entre polígonos ........................................................................ 12

Figura 4. Vértices reducidos ........................................................................................... 12

Figura 5. Polígono reducido............................................................................................ 13

Figura 6. Bisectores parciales y partes del esqueleto...................................................... 13

Figura 7. Evento de corte ................................................................................................ 14

Figura 8. Segmento generado por un evento de corte..................................................... 14

Figura 9. Evento de colapso............................................................................................ 15

Figura 10. Segmentos generados por un evento de colapso ........................................... 15

Figura 11. Evento de colapso final ................................................................................. 16

Figura 12. Segmentos generados de un evento de colapso final..................................... 16

Figura 13. Evento de colapso dejando un polígono de dos lados ................................... 17

Figura 14. Esqueleto rectilíneo final............................................................................... 17

Figura 15. Planta de un edificio ...................................................................................... 18

Figura 16. Esqueleto rectilíneo de la planta del edificio................................................. 18

Figura 17. Tejado del edificio......................................................................................... 19


- 95 -

Figura 18. Falta de unicidad en los esqueletos ............................................................... 19

Figura 19. Polígono con isla ........................................................................................... 21

Figura 20. Mapa con curvas de nivel .............................................................................. 22

Figura 21. Caída del agua por un terreno........................................................................ 22

Figura 22. Cimas degeneradas ........................................................................................ 24

Figura 23. Diagramas de Voronoi vs. Straight Skeletons............................................... 25

Figura 24. Polígono de ejemplo...................................................................................... 28

Figura 25. Lado seleccionado ......................................................................................... 28

Figura 26. Paralelas al lado seleccionado ....................................................................... 29

Figura 27. Perpendiculares y cortes con el resto del polígono ....................................... 29

Figura 28. Paralela válida ............................................................................................... 30

Figura 29. Paralelas validas a todos los lados e intersecciones ...................................... 30

Figura 30. Polígono reducido.......................................................................................... 31

Figura 31. Trozos de bisectores ...................................................................................... 31

Figura 32. Evento de corte .............................................................................................. 32

Figura 33. Polígonos resultantes de un evento de corte.................................................. 32


Figura 35. Segmentos generados por un evento de colapso final ................................... 33

Figura 36. Polígono a reducir.......................................................................................... 34

Figura 37. Evento de colapso.......................................................................................... 34


- 96 -

Figura 38. Polígono a reducir tras evento de colapso ..................................................... 35

Figura 39. Evento de corte .............................................................................................. 35

Figura 40. Polígono de dos lados resultado de un evento de corte y colapso a la vez.... 36

Figura 41. Polígono a reducir.......................................................................................... 36


Figura 43. Esqueleto rectilíneo final............................................................................... 37

Figura 44. Herencia entre StraightSkeletons y Applet ................................................... 40

Figura 45. Herencia de PanelVertices y PanelSolucion con TextArea........................... 41

Figura 46. Relación entre StraightSkeletons y paneles................................................... 41

Figura 47. Relaciones del PanelMensajes y herencias.................................................... 42

Figura 48. Relaciones del PanelBotones y herencias ..................................................... 43

Figura 49. Relaciones y herencias del Lienzo ................................................................ 44

Figura 50. Relaciones del Lienzo y el Poligono ............................................................. 45

Figura 51. Relaciones y herencias entre Poligono, Segmento, Recta y Punto ............... 47

Figura 52. Relaciones en ejecución ................................................................................ 48

Figura 53. Principales tipos MIME................................................................................. 63

Figura 54. Entorno .......................................................................................................... 81

Figura 55. Cabecera ........................................................................................................ 82

Figura 56. Desplazamiento ............................................................................................. 82

Figura 57. Información básica ........................................................................................ 82


- 97 -

Figura 58. Instrucciones de uso ...................................................................................... 82

Figura 59. Programas ...................................................................................................... 83

Figura 60. Documentación.............................................................................................. 83

Figura 61. Descargas....................................................................................................... 83

Figura 62. Entorno de ejecución ..................................................................................... 84

Figura 63. Lienzo ............................................................................................................ 84

Figura 64. Botonera ........................................................................................................ 85

Figura 65. Limpiar .......................................................................................................... 85

Figura 66. Cerrar............................................................................................................. 86

Figura 67. Ejecutar.......................................................................................................... 86

Figura 68. Ejecutar lento................................................................................................. 86

Figura 69. Introducir vértices.......................................................................................... 86

Figura 70. Panel de vértices ............................................................................................ 87

Figura 71. Panel de solución........................................................................................... 88

Figura 72. Panel de mensajes.......................................................................................... 88

10.2 Formatos de puntos y segmentos

Los puntos se representan como pares de números encerrados entre paréntesis y

separados por una coma. Cada uno de los números, si tiene decimales, serán reparados

por un punto. Por ejemplo (12.34, 56.78)


- 98 -

Los segmentos se definen como un par de puntos, con la descripción anterior,

separados por una coma y entre corchetes. Por ejemplo [(12.31, 56), (12, 56.8)]


- 99 -

10.3 Modelo entidad - relación


- 100 -

trabajo fin de carrera straight skeletons · completa del tejado que apoya, de manera uniforme, su...

Documents