UNIVERSIDAD NACIONAL DE SAN LUIS FACULTAD DE … Oscar Testa.pdf · Especificación Formal en RSL de una Infraestructura abierta y estándar de Servicios Web de SIG Lic. Oscar Alfredo

UNIVERSIDAD NACIONAL DE SAN LUIS

FACULTAD DE CIENCIAS FÍSICO MATEMÁTICAS Y NATURALES

Tesis

para optar a la titulación de postgrado correspondiente a la Maestría en Ingeniería de Software

Especificación Formal en RSL de una Infraestructura

abierta y estándar de Servicios Web de SIG

Lic. Oscar Alfredo Testa

Director: Mg. Ing. Germán Montejano Ms. Ing. Daniel Riesco

San Luis 2009

A Miriam

Por su apoyo, por el tiempo,

por estar siempre.

A Luciana y Francisco

Por ser la luz de mis ojos.

El único modo de hacer un

gran trabajo es amar lo

que haces. Si no lo has

encontrado todavía, sigue

buscando. No te acomodes.

Como con todo lo que es

propio del corazón, lo

sabrás cuando lo

encuentres.

Steve Jobs

RECONOCIMIENTOS

Queremos agradecer al Dr. Mario BERÓN, quien ha dedicado su valioso tiempo en colaborar en la adecuada redacción del informe.

Índice

- V -

ÍNDICE 1. INTRODUCCIÓN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Justificación del uso de métodos formales . . . . . . . . . . . . . . . . . . . . . 4 1.4 Estructura del informe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. ASPECTOS TEÓRICOS DE LOS SISTEMAS DE INFORMACIÓN GEOGRÁFICA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2 Historia de los Sistemas de Información Geográfica. . . . . . . . . . . . . . 7 2.3 ¿Qué es un Sistema de Información Geográfica? . . . . . . . . . . . . . . . 8 2.4 Composición de un mapa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.4.1 Proyecciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.4.2 Modelos lógicos. Formatos raster y vectorial . . . . . . . . . . . . . . . 12 2.4.2.1 Formato raster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.4.2.2 Formato vectorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.5 Bases de Datos espaciales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.5.1 El modelo geo-relacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.5.2 Geodatabase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.5.3 Metadatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.6 Aplicaciones de los Sistemas de Información Geográfica. . . . . . . . . . 19 2.7 Mapas en la Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3. DEFINICIÓN Y ANTECEDENTES DEL FRAMEWORK . . . . . . . . . . . . . 25 3.1 Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.1.1 Especificaciones estándares del OGC . . . . . . . . . . . . . . . . . . . . 26 3.1.1.1 OGC Location Services (OpenLS) Implementation Specification . . . . . . . . . . . . . . . . . . . 27 3.1.1.2 OpenGis Geography Markup Language (GML) . . . . . . . . . 30 3.1.1.2.1 El Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.1.1.2.2 Perfiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.1.1.2.2.1 GML Simple Feature Profile . . . . . . . . . . . . . . . . . 31 3.1.1.2.2.2 Subset Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 3.1.1.2.3 Esquema de aplicación. . . . . . . . . . . . . . . . . . . . . . . . . 31 3.1.1.2.4 Geometrías GML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.1.1.2.5 Características . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.1.1.2.6 Coordenadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.1.1.2.7 Sistema de coordenadas de referencia . . . . . . . . . . . . 33 3.1.1.3 OpenGis Web Feature Service (WFS) Implementation Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.1.1.3.1 Arquitectura WFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.1.1.3.2 Procesamiento de pedidos WFS. . . . . . . . . . . . . . . . . . 35 3.1.1.3.3 Operaciones del Servicio Web de características (WFS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.1.1.4 OpenGis Web Map Service (OMS) Implementation Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.1.1.4.1 Operaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Índice

- VI -

3.1.2 Infraestructuras de Datos Espaciales . . . . . . . . . . . . . . . . . . . . . 39 3.1.2.1 National Spatial Data Infraestructure . . . . . . . . . . . . . . . . . . 40 3.1.2.1.1 Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.1.2.1.2 Organización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.1.2.2 Infraestructure for Spatial Information in Europe (INSPIRE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.1.2.2.1 Arquitectura técnica . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.1.2.2.1.1 Tipos de Servicios . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.1.2.2.1.2 Infraestructura de los servicios de red . . . . . . . . . 46 3.1.2.3 Proyecto Sistema de Información Geográfica Nacional de la República Argentina. (PROSIGA) . . . . . . . . . . . . . . . . . . . . . . . . 49 3.1.2.3.1 Base Tecnológica. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 3.1.2.3.2 Ventajas del Proyecto. . . . . . . . . . . . . . . . . . . . . . . . . . 50 3.1.2.3.3 Servicios disponibles . . . . . . . . . . . . . . . . . . . . . . . . . . 50 3.1.2.3.4 Estándares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 3.2 Framework propuesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 3.2.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 3.2.2 Definición de los servicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4. MÉTODO DE DESARROLLO RAISE . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.1 Desarrollo separado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.1.1 Requerimientos sin cumplir . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.1.2 Requerimientos cambiantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.1.3 Pasos sin implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.2 Desarrollo gradual o incremental . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.3 Inventar y verificar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 4.4 Rigurosidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.5 El rol de RAISE en la Ingeniería de Software . . . . . . . . . . . . . . . . . . 67 4.5.1 Validación y verificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 4.5.2 Analizando requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 4.5.3 Mantenimiento de la corrección . . . . . . . . . . . . . . . . . . . . . . . . . 71 4.5.4 Concentración en descubrir errores a medida que son introducidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 4.5.5 Producción de documentación que facilita el mantenimiento . . . 73 4.6 Uso selectivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 4.6.1 Grados de formalidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 4.6.1 Aplicación selectiva de formalidad . . . . . . . . . . . . . . . . . . . . . . . 76 4.6.2.1 Seleccionando propiedades. . . . . . . . . . . . . . . . . . . . . . . . . 76 4.6.2.2 Seleccionando componentes . . . . . . . . . . . . . . . . . . . . . . . . 76 4.7 Sistemas formales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 5. ESPECIFICACIÓN FORMAL DEL FRAMEWORK . . . . . . . . . . . . . . . . . 80 5.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 5.2 RAISE Specification Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 5.3 Especificación de la Infraestructura . . . . . . . . . . . . . . . . . . . . . . . . . 84 5.3.1 Conceptos importantes de la Infraestructura . . . . . . . . . . . . . . . 84 5.3.1.1 Definición informal de la Infraestructura . . . . . . . . . . . . . . . 86 5.3.2 Especificación formal de la Infraestructura . . . . . . . . . . . . . . . . . 88 6. CONCLUSIONES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

Índice

- VII -

7. FUTURAS EXTENSIONES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 REFERENCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 ANEXO I 135 ANEXO II 142 ANEXO III 144

Introducción

- 1 -

1. INTRODUCCIÓN

Los Sistemas de Información Geográfica (SIG) han surgido en la década de 1960 y su inserción y uso dentro de las empresas y los organismos públicos ha sido muy importante. Cabe mencionar que más del 80% de los negocios requieren de servicios o prestaciones de localización geográfica. Los beneficios que aporta para la toma de decisiones, inteligencia que adiciona a los negocios, operaciones e información pública son innumerables, sin embargo muchos factores han mitigado estos beneficios. Algunos de los factores se mencionan a continuación (sólo por mencionar los más importantes) [11], [12], [21]:

• La cartografía no se encuentra en el formato deseado.

• Los mecanismos de localización son particulares o propietarios del software adquirido y no se condicen con nuestra base de datos de clientes.

• La cartografía necesaria para el ámbito del problema no se encuentra en un formato unificado, siendo la misma provista por muchas fuentes de información.

• La forma de comunicación entre el servidor de mapas y el dispositivo que realiza la petición no se encuentra estandarizada.

• El costo de licenciamiento del software de base es muy alto.

• Duplicación de información geográfica dentro de la misma región (empresa, País, etc.) sin posibilidad de interoperabilidad entre ellos.

• Alto costo de la cartografía de base.

Estos problemas que a menudo sucedían dentro de las organizaciones, luego sucedieron a nivel de regiones/países y se fueron convirtiendo en necesidades de los propios organismos de gobierno. Es decir que la necesidad de: compartir la cartografía de base, no tener que hacer enormes inversiones en licenciamiento de las herramientas, tener un repositorio común de la información, con el único propósito de mejorar el rendimiento de los SIG ( aumentando la utilización de los mismos), mejorar la confianza en el formato y actualización de la información y en la reducción de costos, se fueron convirtiendo en las necesidades básicas para poder llevar adelante exitosamente un plan de implementación de una solución con sistemas de información geográfica.

Hoy, con el advenimiento en primer lugar de la tecnología de servicios

Web y luego con los servicios Web orientados a SIG estos problemas han encontrado una solución.

Los servicios web son servicios que están disponibles en Internet

(Intranet), utilizan un sistema de mensajería estandarizada y no están ligados a sistema operativo alguno o lenguaje de programación. A su vez los servicios web pueden (es deseable que así sea) tener dos propiedades adicionales: se describen a sí mismos y se deben publicar para que se conozca [3].

Los servicios Web de SIG son una solución ideal para las

organizaciones que desean hacer uso de información espacial y no encontrarse

Introducción

- 2 -

con los problemas mencionados anteriormente. Al poder hacer un “outsourcing” de los servicios de datos espaciales, se encuentra la organización con una serie de beneficios: menor costo, menores riesgos, menores tiempos de desarrollo y disponibilidad de la información, menor cantidad de recursos especializados para poder llevar adelante la solución [22].

1.1 Objetivo

Como se menciona en el apartado anterior, los negocios de las organizaciones manejan un 80% de información geográfica o espacial, esto muestra lo importante que es contar en las empresas con un SIG. Es decir, la utilización de un sistema de esta naturaleza mejoraría el desempeño y los resultados estratégicos de la organización, sobre todo si se piensa que existen constantemente presiones para que se tomen mejores decisiones y de una manera menos costosa y más eficiente.

El éxito de la implementación en las organizaciones de un sistema con éstas características depende de muchos factores, pero como se introdujo anteriormente, básicamente los costos y la diversidad de información y formatos figuran entre los más destacados.

Se tiene la fuerte convicción de que si las organizaciones tuvieran herramientas que les permitieran desarrollar sistemas de información geográfica en forma rápida y sencilla, siguiendo modelos establecidos y utilizando cartografía y datos espaciales probados y existentes, podrían tener ventajas competitivas respecto del resto (o al menos podrían tener una visión de la realidad diferenciada que les permita analizar los eventos a través de una dimensión extra: la geográfica).

Debido a que no existen frameworks que permitan la generación

automatizada de sistemas de información geográfica, se propone como objetivo construir, a través de la utilización de especificaciones formales, una infraestructura abierta y estándar de servicios web, de forma tal que se pueda abordar la construcción de sistemas de información geográfica a partir de modelos probados y de utilización directa.

El lenguaje de especificación formal utilizado en este caso es el RAISE

Specification Language (RSL), dado que el mismo es reconocido en la industria del software para especificaciones formales de desarrollos reales.

RSL es un lenguaje formal, basado en el formalismo de la matemática

usando conceptos tales como la teoría de conjuntos, lógica de primer orden, lógica de orden superior, destacándose entre otros conceptos matemáticos, y, que están netamente orientados a construir modelos, ya sea describiendo un dominio de la realidad o describiendo una herramienta a desarrollar y sus requerimientos [1].

Introducción

- 3 -

1.2 Antecedentes

Compartir información geográfica y servicios asociados es una tarea que

ha sido objeto de investigación desde hace varios años, su resurgimiento se debe inicialmente a los organismos gubernamentales, principalmente de Estados Unidos.

En particular, la definición formal de una infraestructura como la que aquí

se muestra fue fue presentada en San Juan, Argentina para su evaluación ante la comunidad científica en abril de 2009 en el XI Workshop de Investigadores en Ciencias de la Computación [54], el cual fue discutido y aceptado por el comité formado a tal fin.

Luego fue también presentado el trabajo en el Seminario de Tecnología

de Información en Geociencias (CGI-IUGS Seminar) y Primera Reunión Latinoamericana de Especialistas en Geoinformación en Organizaciones Geocientíficas, realizado en el mes de junio de 2009, en el Servicio Geológico Minero Argentino, Buenos Aires, Argentina.

Un primer proyecto, en el año 1994, fue iniciado por el entonces

presidente William J. Clinton, a través de la orden presidencial 12906 para poner en marcha la Infraestructura Nacional de Datos Espaciales de EEUU (NSDI) [21], con el propósito de que: “compartir conocimiento es fuente del crecimiento económico”.

En Agosto de 2002 se comienza con la construcción del framework, el

cual fue encomendado al Federal Geographic Data Committee (FGDC) para su coordinación. De todos modos esta infraestructura no contempla aún servicios para la utilización de los metadatos, simplemente muestra la conveniencia de compartir información espacial, tanto entre organismos gubernamentales como privados.

Otro de los proyectos iniciados para formar una Infraestructura de Datos

Espaciales fue el de la Comunidad Económica Europea (INSPIRE), a través de la Directiva 2007/2CE del Parlamento Europeo y del Consejo, con fecha 14 de Marzo de 2007 [23]. En dicha Directiva se hace mención a los problemas relativos a la disponibilidad, calidad, organización, y puesta en común de información espacial y servicios asociados a las mismas.

A su vez define la infraestructura de información espacial como los

metadatos, conjuntos de datos espaciales y los servicios de datos espaciales; los servicios y tecnologías de red; los acuerdos de acceso de la información. Y define servicios de datos espaciales como las operaciones que se pueden efectuar, a través de aplicaciones, sobre los datos espaciales.

En Argentina en el año 2004, se crea el Proyecto Sistema de

Información Geográfica Nacional de la República Argentina (PROSIGA), donde se plantea como objetivo vincular los generadores y usuarios de información espacial mediante una estructura nodal de intercambio de datos a través de

Introducción

- 4 -

redes públicas y privadas, permitiendo a la comunidad en general contar con una herramienta de base para la toma de decisiones basadas en criterios espaciales homogéneos [24].

En éste trabajo se presenta una profundización de los proyectos antes

mencionados, ya que se propone una especificación formal que subyace a todos los trabajos realizados, dando a su vez un marco mucho más riguroso (gracias a la utilización de un lenguaje formal como es RAISE RSL) a las infraestructuras de datos espaciales existentes.

1.3 Justificación del uso de métodos formales El Grupo del Método RAISE [1] menciona que las computadoras están siendo usadas para tareas donde las fallas traen severas consecuencias, incluyendo la pérdida de vidas humanas. Esta tendencia se está incrementando cada vez más. Las computadoras juegan un rol esencial en el control aeroespacial, en la aeronavegación, en el control de trenes, autos, reactores nucleares y equipamiento hospitalario, por dar simplemente algunas pocas de las aplicaciones más críticas. Si las personas están preocupadas por un aterrizaje seguro de su avión o que su cuenta bancaria tenga el saldo correcto, entonces concordarán que es de vital importancia que los sistemas de computación que están por detrás de ellos sean completamente confiables. Si bien esto es estrictamente cierto, se debe destacar también, que los métodos formales no son utilizados únicamente para los sistemas críticos, sino que como se menciona en el libro “Specification Case Studies in RAISE” [25], RAISE es utilizado para un gran espectro de áreas de aplicación (autenticación de los protocolos de comunicación, detección de errores en los programas de computación, administración de una biblioteca, reutilización de software y varios más), entre ellas los sistemas de información geográfica.

A continuación se mencionan algunos puntos importantes que justifican

la utilización de los métodos formales: - Los sistemas de información geográfica en muchas ocasiones son

utilizados en situaciones críticas, donde la preservación de vidas humanas es primordial, como desastres naturales (terremotos, incendios forestales, accidentes aéreos, inundaciones), atentados o desastres provocados por el hombre. También son muy importantes (casi imprescindibles) en las metas estratégicas de cualquier organización, donde el posicionamiento geográfico es un elemento de fundamental importancia.

- La inversión significativa, en tiempo y en esfuerzo, asociada a la

aplicación de métodos formales, posee un recupero intangible, que si bien en algunos casos es incalculable (las vidas humanas no pueden tomarse como un valor económico cuantificable), en otros es muy evidente en las etapas posteriores del desarrollo de un sistema (como es el caso de las metas estratégicas de una organización).

Introducción

- 5 -

- Los requerimientos específicos correspondientes a la especificación de un SIG en particular, frecuentemente se ven afectados por los efectos perniciosos de la ambigüedad, la incompletitud e inconsistencias que se detectan en abundancia cuando se utilizan métodos y herramientas menos rigurosos que los métodos formales. Se debe recordar que uno de los problemas de la falla en la implementación de los SIG es el costo del licenciamiento, por lo que si a ello se le suma un mal análisis o un diagnóstico equivocado las pérdidas serían aún mayores, incrementando aún más los problemas de implementación.

- La confiabilidad, definida como “que el sistema haga el trabajo que se

supone debe hacer”, es un requerimiento tanto para el hardware como para el software, aunque en el presente trabajo se orienta a los componentes de software solamente.

- Construir software confiable es especialmente dificultoso: cualquier

programa que es capaz de hacer algo interesante es tan complejo que es imposible probarlo completamente.

- Una técnica importante para ayudar a incrementar la confiabilidad del

software es el uso de los métodos formales. La idea básica, es que debería ser posible razonar acerca de las propiedades del software o sistemas que involucran software. Por ejemplo, si los requerimientos dicen que debe haber a lo sumo un tren en cualquier sección de una vía, se debe poder producir una prueba tal que el software siempre refleje este requerimiento.

- Los métodos formales no son la respuesta completa. En principio, las

“pruebas” pueden contener defectos. Las pruebas no triviales tienden a ser grandes y dificultosas, para que puedan llevarse adelante de forma automática, típicamente algunos pasos serán rotulados como “obvios” y no serán demostrados formalmente. Para algunas pruebas que son hechas automáticamente se debe preguntar: ¿cómo saber que el probador es correcto?. Entonces se producen problemas más amplios. ¿Cómo se hace para saber que el modelo del mundo contenido en el software (en el cual hay solamente un tren por sección) está reflejado en el mundo real?. Los desarrolladores comienzan con una narrativa de requerimientos, escritos generalmente en un lenguaje natural. Los métodos formales pueden ofrecer seguridad que los requerimientos son correctos, encontrando inconsistencias y faltantes, pero seguridad no es certeza. También, el uso de los métodos formales involucra interpretar los requerimientos creando un modelo de ellos (aunque matemáticos y abstractos) en otro lenguaje. Tales procesos están sujetos a errores.

1.4 Estructura del informe

El trabajo se estructura de la siguiente manera:

Introducción

- 6 -

En el Capítulo 2 se presentan los aspectos teóricos de los conceptos

básicos sobre los sistemas de información geográfica. En este capítulo se dan los conocimientos básicos y las distintas variantes que existen en la implementación y utilización de los sistemas de información geográfica en las organizaciones. Se menciona también en este capítulo la forma en que han ido evolucionando a lo largo del tiempo los SIG de acuerdo a la evolución de la tecnología disponible en cada etapa. Se presenta al final del capítulo una breve introducción a los servicios web.

El lector avezado en los temas de SIG podrá no leer el Capítulo 2

completo e ir directamente al Capítulo 3 si requiere conocimiento profundo de los antecedentes y trabajos previos del Framework.

En el Capítulo 3 se presentan los aspectos teóricos del Framework. En

este capítulo se hace una descripción profunda de las infraestructuras de datos espaciales existentes en el mundo, de los estándares internacionales referidos a la materia y de trabajos de investigación relacionados. Con todo, queda un amplio espectro de conocimiento para luego ahondar en la especificación formal del Framework en el Capítulo 5.

En el Capítulo 4 se describe el método RAISE para desarrollo de

aplicaciones industriales usando RSL. No sólo se hace una descripción comprensiva del método, sino que se dan algunas sugerencias con enfoque práctico para el aseguramiento de la calidad.

Los lectores expertos en métodos formales en general, o conocedores

del método de desarrollo RAISE en particular, podrán eximirse de la lectura del Capítulo 4.

En el Capítulo 5 se formaliza el framwork presentado, a medida que se

van introduciendo los conceptos básicos del lenguaje RSL necesarios para la especificación que se va realizando. Con las especificaciones formales de la infraestructura queda una base sólida para la construcción de herramientas automatizadas que permitan utilizar la metodología de Sistemas de Información Geográfica, en especial a través de Servicios Web.

En el Capítulo 6 se dan las conclusiones del presente trabajo y las

futuras extensiones que se proponen se plantean en el Capítulo 7.

Aspectos Teóricos de los Sistemas de Información Geográfica

- - 7

2. ASPECTOS TEÓRICOS DE LOS SISTEMAS DE INFORMACIÓN GEOGRÁFICA

2.1 Introducción

Desde comienzos de la década de 1990 se vive en la era de la

información (Manuel Castells), más específicamente en la era de la información digital, ya que la información digital es un ingrediente crítico para el éxito de cualquier actividad que se desee llevar adelante. Es prácticamente inviable llevar adelante cualquier tipo de negocio sin el uso de las tecnologías de la comunicación y de la información. Un tipo específico de información digital también se ha vuelto importante y esencial para tener éxito en los negocios hoy día: la información geográfica.

Aunque es algo que las personas hacen sin darse cuenta o sin pensar,

constantemente se están relacionando las actividades con una ubicación geográfica: si se busca trabajo se deberá evaluar el lugar geográfico donde se encuentra; si se busca una vivienda para comprar o alquilar es de suma importancia saber la ubicación de la misma, como así también las vías de comunicación hacia los centros comerciales, las escuelas, etc.; si se quiere establecer una planta de pasteurizado de leche deberá estar ubicada en las cercanías de los tambos que la proveen para una mejor administración de las rutas y recolección de la leche; y así en muchas más tareas, actividades y negocios como se pudo apreciar con estos ejemplos simples.

La revolución digital que se produjo en el final del siglo XX (más

específicamente desde el año 1975 en adelante) ha permitido que la información geográfica sea más fácil de acceder de lo que había sido antes. Utilizando sistemas de información geográfica las organizaciones en general están hoy capacitadas para analizar oportunidades, y solucionar problemas de un gran espectro.[26]

2.2 Historia de los Sistemas de Información Geográfica

Las raíces del SIG datan del año 1960 aproximadamente, donde la tecnología y la epistemología estaban en sus comienzos. En el año 1962 Ian McHarg [28], un arquitecto de paisajes, introdujo el término de superposición, el cual luego vino a ser el “alma mater” de la tecnología de los sistemas de información geográfica. Este arquitecto buscaba el lugar óptimo para realizar el trazado de una nueva ruta. El principal objetivo era encontrar el mejor recorrido minimizando el daño ecológico del medio ambiente. Para ello, superpuso varias capas (mapas en papel vegetal) de información, conteniendo en cada una de ellas distintos elementos: plantas, montañas, valles, casas existentes, etc. Luego, pudo distinguir la intersección de estas distintas capas y de esta manera poder determinar o “ver” el camino óptimo o lógico que tenía que tener la nueva ruta. Todo este proceso fue realizado sin la ayuda de computadora o tecnología, salvo papel y mapas.

Uno de los primeros sistemas cartográficos fue desarrollado en Canadá

por Roger Tomilson y Lee Pratt [28], quienes propusieron al Ministerio de


- - 8

Agricultura de ese país la construcción de un SIG que muestre en formato de capas la utilización de la tierra en todo el ámbito del país. Estos mapas debían contemplar la visualización de la agricultura, la forestación, áreas recreativas, valles, etc. Este sistema se denominó Canadá Geographical Information System (CGIS), y fue desarrollado en el año 1964.

De forma paralela en Inglaterra, David Rhind [28] había determinado dos

corrientes de innovación en el desarrollo de sistemas de información geográfica. Por un lado estaba el trabajo iniciado por los cartógrafos, quienes estaban comenzando con las primeras tareas del digitalizado y creación de mapas en forma automatizada a un costo razonablemente accesible. Por otro lado estaban los geógrafos que comenzaron a desarrollar algoritmos en computadora para resolver problemas espaciales. Este trabajo fue la base para futuros desarrollos en análisis espaciales para este tipo de sistemas.

A su vez en EEUU, en los laboratorios gráficos de Harvard se estaba

produciendo una revolución alrededor de esta nueva tecnología. Las investigaciones establecían un eficiente método para la superposición de capas en una computadora. Dentro de los investigadores se encontraban Nicholas Chrisman y Tom Poiker [28]. Una diáspora de investigadores de este laboratorio, por el año 1970, hicieron que la tecnología de sistemas de información geográfica se comenzara a hacer popular en el sector privado. En el año 1981, Scott Morehouse, un miembro joven de dicho grupo se fue a trabajar a una compañía denominada Environmental Research Systems Inc. (ESRI). Allí comenzó con el desarrollo de los algoritmos que luego dieron origen al programa ArcInfo.

2.3 Conceptos de Sistema de Información Geográfica

Los sistemas de información geográfica son sistemas informáticos que

trabajan uniendo la información o datos a una ubicación geográfica (un punto, una recta, polilínea, etc.). Normalmente se piensa en la información geográfica como la altura que tiene un determinado cordón montañoso, o la extensión de un río, la cantidad de km2 que ocupa un lago, etc. La potencia de los SIG radica en la posibilidad de asociar otro tipo de información o datos a la información geográfica que ya posee.

Los mapas a través de un SIG se convierten en supermapas. Cuando se

ve una ruta en un mapa de papel solamente se puede ver la longitud de un tramo de dicha ruta, su nombre y no mucha más información. Esta misma ruta en un mapa digitalizado, utilizando tecnología SIG puede mostrarnos información del estado actual, fecha de construcción, empresa constructora, tráfico en horas picos y cualquier otra información que sea de utilidad para la cual fue concebido el sistema. En general se puede decir que no hay límite para la cantidad y calidad de información que se desee asociar al objeto geográfico en cuestión.

A continuación se aborda una definición más formal de Sistemas de

Información Geográfica:


- - 9

“Es una tecnología y metodología basada en computadoras para recolectar, manejar, analizar, modelizar y presentar datos geográficos para un rango muy amplio de aplicaciones o problemas” [27]

Es decir que un SIG se refiere a 3 elementos integrados:

• Geografía: el mundo, la realidad espacial. • Información: datos e información; su significado y uso. • Sistema: tecnología que da soporte a la infraestructura.

2.4 Composición de un Mapa

Como se mencionó en el punto 2.3, los mapas en un SIG se convierten

en supermapas. Esta afirmación intenta mostrar la potencialidad que tienen este tipo de sistemas, que es la capacidad de mostrar en capas (en inglés layers) la información que desean presentar al usuario final.

Los mapas se componen de distintas capas de información, cada una de

ellas representa un conjunto de información homogénea. Las capas son superpuestas una sobre la otra para formar de esa manera un mapa. Se puede decir entonces que cada capa contiene una parte del mapa completo, como se muestra en la Figura 2.1. Cada capa contiene información acerca de la temática definida. Como ejemplos de capas de información se pueden mencionar:

• Capa de ríos y lagos. • Capa de rutas nacionales y provinciales. • Capa catastral, la cual contiene información de cada una de las

parcelas que componen las manzanas de una determinada ciudad.

• Capa de ciudades, donde se muestra un punto por cada ciudad.

Figura 2.1: Capas o layers que componen un mapa

Esto son sólo algunos ejemplos de capas que se pueden realizar. Las

capas se determinan de acuerdo al problema que se debe solucionar, por lo que distintos problemas contienen distinta cantidad y tipo de capas.


- - 10

Las capas poseen el elemento geográfico que la compone y los datos

asociados al mismo. Por ej.: en una capa de ciudades el elemento geográfico es el punto o círculo (de un determinado tamaño, color y relleno) y de la información que se quiera consultar de la ciudad en el campo de aplicación que se utilice (por ej.: país, provincia, departamento, cantidad de habitantes, código postal, etc.).

Las capas que componen el mapa pueden ser reordenadas de acuerdo

a necesidades específicas del usuario, pueden ser ocultadas (no visibles), eliminadas o agregar nuevas si fuera necesario.

Si se considera la realidad como una yuxtaposición de objetos, cualquier

entidad que aparezca en el espacio (ciudades, árboles, edificios, rutas, autopistas, etc.) se puede modelizar como un objeto extraído de la geometría euclidiana, los cuales a su vez componen o forman las capas de información. Pueden clasificarse estos objetos geométricos de la siguiente manera (ver figura 2.2):

• Objetos puntuales: objetos geométricos de dimensión cero, su

localización espacial se representa por un par de coordenadas (X,Y).

• Objetos lineales: objetos geométricos de dimensión uno, su localización espacial se representa como una sucesión de pares de coordenadas llamados vértices. La cantidad de vértices debe ser al menos dos, en cuyo caso se denomina segmento y cuando es mayor a dos se lo denomina polilínea.

• Objetos poligonales: objetos geométricos de dimensión dos. Se representan como un objeto lineal cerrado, es decir el primer vértice es igual al último.

Figura 2.2: Objetos geométricos

El proceso de selección del objeto adecuado que se utilizará para

representar la realidad dependerá en gran medida de la escala a utilizar (una ciudad en un mapa de todo el mundo se verá como un punto y una ciudad en


- - 11

un mapa callejero se explotará en muchos objetos combinados), de la característica del problema o la abstracción que se pretenda hacer del mismo.

Cada objeto que compone una capa puede decirse que tiene distintos

tipos de información que lo identifican:

• Identificador: valor cuantitativo que identifica a cada objeto unívocamente dentro del grupo de objetos.

• Posición: determina la ubicación del objeto en un espacio, generalmente bidimensional. Implícitamente también posee su dimensión y su forma. De este modo cada tipo de objeto tiene información espacial adicional que se desprende de su codificación espacial. Los objetos lineales poseen distancia o longitud, orientación, sinuosidad, etc. Los objetos poligonales poseen área, perímetro, distancias máximas y otros indicadores que se calculan directamente a partir de estas características.

• Propiedades espaciales: variables cuantitativas medidas en magnitudes espaciales que indican algún aspecto de la extensión espacial la cual no puede ser representada como objeto gráfico en sí. Este es el caso por ej. de la profundidad de un cauce de un río.

• Propiedades no espaciales: variables cuantitativas o cualitativas que no tienen nada que ver con el espacio del objeto con el que se relacionan. Son el resultado de mediciones simples o de descripciones, que pueden ser variables o constantes a lo largo del tiempo. Como ejemplo se puede mencionar la población de una ciudad, el nombre, su código postal, etc.

En el punto 2.4.2 se retomará el estudio de las capas, desde un punto de

vista de su formato, es decir la forma lógica en cómo se muestran y organizan las variables y objetos que las componen.

2.4.1 Proyecciones

Para poder continuar con el estudio de los sistemas de información

geográfica se abordará la definición de algunos conceptos básicos de la ciencia cartográfica.

Si se quisiera representar sobre un plano un objeto como la tierra, se

presentarían los siguientes inconvenientes:

• Se producirían distorciones inevitablemente. • La tierra no tiene forma esférica, sólo se asemeja a un esferoide o

elipsoide, ligeramente achatado en los polos o extremos y un ensanchamiento en la parte ecuatorial.

• La aproximación mencionada tampoco es válida cuando se desciende al detalle ya que la tierra incluye numerosas irregularidades, se dice entonces que es un geoide para hacer referencia a la tierra como un objeto geométrico irregular.


- - 12

Geodesia es la ciencia que estudia el tamaño y forma de la tierra y las posiciones sobre la misma. Debido a la irregularidad mencionada, para describir la forma de la tierra suele utilizarse modelos de la misma, denominados esferoides o elipsoides de referencia. Estos se definen por dos parámetros: el tamaño del semieje mayor y el tamaño del semieje menor. Alterando los valores de estos parámetros es que se obtienen diferentes o diversos elipsoides de referencia. La razón para tener diferentes esferoides es que cada uno de ellos puede adaptarse razonablemente bien a una zona concreta y acotada de la superficie terrestre. Por lo tanto cada país utilizará el elipsoide que más se adapte a su zona geográfica.

El proceso de transformar las coordenadas geográficas del esferoide en

coordenadas cartesianas o planas para representar una parte de la superficie terrestre se conoce como proyección (ver figura 2.3).

Por lo tanto, se puede concluir entonces que los SIG asignan a cada

punto de la superficie terrestre un par de coordenadas siguiendo una proyección determinada.

Figura 2.3: Proyección de la superficie terrestre en un plano

2.4.2 Modelos lógicos. Formatos raster y vectorial

El modelo lógico hace referencia a cómo se muestran y organizan las variables y objetos para lograr una representación lo más adecuada posible. En los sistemas de información geográfica existen dos modelos lógicos: formato raster y formato vectorial.

2.4.2.1 Formato raster

El formato raster se fundamenta en la división del área de estudio o

análisis en una matriz de celdas, generalmente cuadradas. Cada una de estas celdas recibe un único valor que se considera representativo para toda la superficie abarcada por la celda. Este formato cubre la totalidad del espacio.


- - 13

Los elementos que componen una capa raster son los siguientes:

• La matriz de datos: puede contener tres tipos de datos:

� Valores numéricos, en caso de que la variable a representar sea cuantitativa.

� Identificadores numéricos, en caso de que se trate de una variable cualitativa. Estos identificadores se corresponden con etiquetas de texto que describen los distintos valores de las variables cuantitativas.

� Identificadores numéricos únicos para cada una de las entidades representadas, en caso de que la capa raster contenga entidades (puntos, polígonos, líneas).

• Información geométrica acerca de la matriz y su posición en el

espacio:

� Número de columnas. � Número de filas. � Coordenadas de las esquinas de la capa. � Resolución o tamaño de píxel en latitud y en longitud.

• Una tabla de colores que represente con qué color debe pintarse

la celda en la pantalla.

En la figura 2.4 se puede apreciar un ejemplo de formato raster, representando una variable cualitativa.

Figura 2.4: Representación de un formato raster.

Para trabajar con este tipo de capas en los sistemas SIG, se dispone de

un conjunto de herramientas de cálculo con matrices, denominado álgebra de


- - 14

mapas. El álgebra de mapas incluye un amplio conjunto de operadores que se aplican a una o varias de las capas raster que componen el mapa y producen resultados en una o varias capas raster. Por operador se entiende un algoritmo que realiza una misma operación en todas las celdas de una capa de este estilo. Los operadores que trabajan con este tipo de capas pueden clasificarse en: locales, de vecindad o focales, de bloque, de área, de área extendida o globales.

2.4.2.2 Formato vectorial

Al contrario de lo que ocurre con el formato raster, el formato vectorial

define objetos geométricos (puntos, líneas, polígonos) a través de la codificación explícita de sus coordenadas. Es decir que en un formato vectorial lo que se almacena son solamente las coordenadas de los puntos que componen el objeto. Esta forma de almacenamiento trae consigo la ventaja de que el espacio que ocupa en almacenarse es mucho menor que en el raster.

En este tipo de capa, la información que se almacena tiene que ver más

que nada con el contorno del objeto y no tanto con la parte interior, cosa que toma más relevancia en un formato raster.

Se pueden mencionar tres tipos de datos u objetos en el formato

vectorial: los puntos, las líneas y los polígonos (como se mencionó en el apartado 2.4). A continuación se mencionan algunos ejemplos de cada uno de los tipos o elementos que conforman una capa vectorial, también se puede ver en la Figura 2.5.

• Puntos: ciudades, restaurantes, hospitales, hoteles, estaciones de

policía, lugares turísticos, etc. • Líneas: ríos, vías, rutas, líneas eléctricas (alta, media y baja

tensión), cañerías de agua o gas, redes de telefonía, TV, etc. • Polígonos: contornos de provincias, partidos o departamentos,

países, zonas de conflicto, etc. .


- - 15

Figura 2.5: Ejemplos de polígonos, líneas y puntos vectoriales.

Dentro de los cálculos que se llevan a cabo dentro de una capa vectorial, o mejor dicho, sobre los elementos vectoriales que componen la capa, se pueden mencionar aquellos que se basan en su posición y en las relaciones topológicas entre objetos:

• Distancia entre dos puntos. • Punto de corte de dos segmentos. • Longitud de una línea. • Distancia en línea recta entre el inicio y el final de una línea o

polilínea. • Perímetro de un polígono. • Área de un polígono.

A modo de comentario final sobre ambos formatos se puede decir que

son dos formatos radicalmente distintos y las funciones y módulos que los manejan son totalmente diferentes. Resulta difícil que un programa mantenga el equilibrio entre capacidades raster y vectoriales. Existen algunos programas que han desarrollado más (o incluso en algunos casos han desarrollado una única forma) un formato que otro. Por ej. ArcInfo tiene desarrollada más la componente vectorial y GRASS la componente raster. Si el objetivo del SIG es trabajar fundamentalmente en ámbitos socioeconómicos o de ordenación del territorio es preferible el formato vectorial, pero si los objetivos están más centrados en las ciencias de la Tierra o medioambientales es preferible que se utilice el formato raster.

2.5 Bases de Datos espaciales

Desde el comienzo de la utilización de la tecnología de sistemas de información geográfica, los Sistemas de Gestión de Bases de Datos (SGBD) han estado siempre presentes e incluso han interpretado un rol muy


- - 16

importante. En los comienzos los SGBD solamente ayudaban a los SIG a almacenar los datos temáticos de los objetos geográficos, mientras que éstos últimos eran almacenados en un formato propietario (por lo general) de cada vendedor. Por lo tanto para poder hacer algunas consultas y/o análisis espaciales había que hacer varios pasos para poder llegar a un resultado. También se debe destacar que las bases de datos propietarias que utilizaban los SIG para almacenar los datos geográficos permitían almacenar información temática, pero el acceso a dicha información era dificultosa en términos de: velocidad, accesibilidad, administración de la concurrencia, etc.

Hoy en día los SGBD permiten el almacenamiento de información

geométrica (conjunto de coordenadas) de las entidades espaciales. Aunque se han hecho algunos intentos para almacenar información en formato raster aún no se han logrado resultados satisfactorios.

A continuación se brinda un estudio más pormenorizado de las

estructuras de las bases de datos espaciales más utilizadas en los sistemas de información geográfica.

2.5.1 El modelo geo-relacional

Lo más habitual durante muchos años fue utilizar los SGBD para almacenar la información temática y el SIG para almacenar la información geométrica y topológica. Una de las funcionalidades de este modelo es el enlazado de ambos tipos de información, que se encuentran en formatos y espacios totalmente diferentes. Esta forma de almacenamiento puede apreciarse en la Figura 2.6.

Figura 2.6: Ejemplo del modelo geo-relacional.

El mayor interés del modelo geo-relacional está en poder realizar una consulta SQL y obtener una o varias entidades espaciales (en lugar de número, tabla o fila) como respuesta. Para poder llevar adelante esta consulta se debe relacionar la base de datos espacial (mapa vectorial) con la base de datos temática (tablas en la BD) mediante una columna en una de las tablas de la base de datos, que contenga los mismos identificadores que las entidades en


- - 17

la base de datos espacial. Se puede pensar entonces en un mapa vectorial como en una tabla en la que cada registro es un objeto (polígono, línea o punto) que contiene un campo identificador y un campo que contiene la localización (conjunto de coordenadas X e Y de tamaño variable). El hecho de que esta información se presente en forma de tabla o en forma de mapas es solamente por conveniencia (de acuerdo a la necesidad de visualización que se desee).

Si se pide como resultado de una consulta a la base de datos temática,

estos identificadores comunes, en realidad lo que estamos obteniendo son objetos espaciales (polígonos en el caso de los municipios). Los resultados de las consultas podrían presentarse de esta manera en forma de mapa en lugar de forma de tabla de modo que a los diferentes polígonos se le asignarían diferentes colores en función de que se cumpliera o no una condición, o de los valores que adoptase una variable o índice.

En estos casos se necesita un módulo específico que transforme los

resultados de las consultas en una serie de reglas para pintar los polígonos asignando al mismo tiempo una paleta de colores definida por el usuario.

En definitiva, la única diferencia entre el trabajo de un gestor tradicional

de bases de datos y el enlace de un SIG a base de datos es el modo de presentación: tabla o mapa. Casi todo el trabajo lo hace el gestor de bases de datos y el Sistema de Información Geográfica, se limita a presentar los resultados.

Hasta ahora lo que se ha visto es obtener objetos espaciales como

resultado de una consulta, pero cuando se trabaja con un SIG enlazado a una base de datos, se pretende que las consultas incluyan también condiciones espaciales. Sin embargo en el modelo geo-relacional la información geográfica está en el SIG y no en el SGBD, por lo tanto las consultas deben contener indefectiblemente un pre-proceso y/o un post-proceso.

Pre-procesamiento significa que al realizar la consulta se deberán tener

en cuenta parámetros o criterios espaciales definidos por el usuario antes de realizar la consulta en el SGBD. Por ej.: si el usuario necesita conocer las ciudades que se encuentran dentro de una determinada zona o región, primero deberá determinar los identificadores de dichas ciudades y luego incluir esos identificadores en la consulta que se realiza al SGBD:

SELECT nombre, censo_2000 FROM municipios WHERE id IN (17,19,21,89); (donde 17,19,21,89 son los identificadores

de las ciudades que están o caen dentro de la zona seleccionada por el usuario en el plano)

Post-procesamiento significa que los resultados de la consulta realizada

al SGBD deberán filtrarse de alguna manera para satisfacer los criterios espaciales seleccionados por el usuario. Para poder cumplir con esta condición, una de las columnas pedidas en la consulta debe ser el identificador del objeto geográfico en el plano. Por ej.: si el usuario necesita visualizar un


- - 18

mapa con la densidad poblacional de la Provincia de La Pampa, deberá traerse de la base de datos no sólo la cantidad de habitantes por localidad o partido, sino además el identificador de la localidad o partido para que pueda ser relacionado gráficamente con la zona en cuestión. 2.5.2 Geodatabase

El concepto de Geodatabase es uno de los que han experimentado en los últimos años una mayor expansión en el área de los sistemas de información geográfica. Se trata de una base de datos que almacena toda la información relativa a un conjunto de entidades espaciales (geometría, topología, identificadores) y los datos temáticos correspondientes. Las ventajas que ofrece este tipo de base de datos son las que se mencionan a continuación:

• Posibilidad de usar SQL, una versión ampliada de SQL en

realidad, para hacer consultas y análisis sobre mapas vectoriales. • Integración en una sola herramienta, de todas las funciones para

trabajar con información vectorial.

El inconveniente que se presenta con el uso de este tipo de bases de datos es que se necesita un programa externo, el SIG o software de base geográfico, para acceder a los datos y visualizarlos.

Dentro de los operadores que se incluyen en el lenguaje estructurado de

consulta (SQL) para manejar información espacial se pueden mencionar: es_igual, se_solapa_con, toca_a, cruza, esta_dentro_de, cubre_a, intersección, unión, diferencia, longitud, area, etc.

Entre los programas que permiten trabajar con geodatabases se pueden

mencionar 2, en primer lugar Oracle spatial y en segundo lugar PostgreSQL + PostGIS. Oracle está considerado como el mejor programa de gestión de base de datos, siendo uno de sus inconvenientes su elevado costo. PostgreSQL, en cambio, es una alternativa libre (y gratuita) que está muy acorde con las bases de datos comerciales. PostGIS es una extensión, también libre, de PostgreSQL que permite trabajar con geodatabases, por lo que son una alternativa muy válida a la hora de elegir un gestor de geodatabases.

A continuación se brinda un ejemplo de una consulta SQL realizada en

el gestor PostgreSQL + PostGIS [41]: SELECT ST_Intersection(r.the_geom, m.the_geom) AS intersection_geom, ST_Length(r.the_geom) AS rd_orig_length, r.* FROM bc_roads AS r, bc_municipality AS m WHERE ST_Intersects(r.the_geom, m.the_geom) AND m.name = 'PRINCE GEORGE';


- - 19

2.5.3 Metadatos

Los metadatos son definidos como los datos acerca de los datos. Es la

información que se necesita para documentar suficientemente el conjunto de datos, para que quien necesite de dichos datos pueda entenderlos, y saber qué significa cada clave de información, cuál es el significado de los valores que toma una determinada variable, etc. Las primeras implementaciones de metadatos espaciales o geoespaciales eran simples archivos de texto.

Desde el año 1990 que se vienen haciendo trabajos para la

estandarización de los formatos de los metadatos, para saber qué información debe ser obligatoria, qué información adicional, el orden de los datos, y muchas otras cuestiones para llegar a una estandarización. Los primeros trabajos los realizó el Comité Federal de Datos Geográficos de los Estados Unidos (FDGC), quien estableció las primeras estandarizaciones que luego se fueron expandiendo hacia otros países y regiones del mundo.

El proyecto Dublin Core integra metadatos estándares para distintas

disciplinas y tipos de datos digitales. Los metadatos son un elemento fundamental en el trabajo de mapas en

la web (que se analizará más adelante en este capítulo). Allí cobran mayor importancia los metadatos ya que al estar disponibles los mapas para cualquier usuario y al no contar con una persona que indique cómo utilizarlos, se debe encontrar una manera de entender dicha información y darle un uso correcto.

2.6 Aplicaciones de los Sistemas de Información Geográfica

Como se puede observar a lo largo de este capítulo se ha hablado de las

cuestiones básicas de los sistemas de información geográfica. En esta sección se abordará para qué se utilizan o qué aplicaciones se pueden resolver con este tipo de sistemas.

Las funciones básicas y más habitualmente utilizadas de un SIG son el

almacenamiento, visualización, consulta y análisis de datos espaciales. Ya en un uso un poco más avanzado se los utiliza para la toma de decisiones en ordenación territorial o para la modelización de problemas ambientales, es decir la toma de decisiones en general.

Dentro de los tipos básicos de consultas que se realizan a los SIG se

pueden mencionar: qué objeto se encuentra en la coordenada X,Y; qué puntos cumplen una determinada condición; qué relación hay entre los objetos A y B (a qué partido pertenece la ciudad de General Pico); cuál es la distancia entre dos puntos del plano; cuál es la mejor ruta entre dos ciudades determinadas.

Estos son ejemplos de algunas consultas básicas, pero más interesante

resulta utilizar los sistemas de información geográfica para análisis de datos o para la toma de decisiones en base a datos o información espacial, como puede ser en el ordenamiento territorial, estudios de impacto ambiental, cursos


- - 20

de acción ante catástrofes naturales o causadas por el hombre. Algunas de las cuestiones o preguntas que se pueden resolver son las siguientes:

1. ¿Qué tipo de actividad es la más adecuada para el cultivo

intensivo de soja?. 2. ¿Cuál es la mejor zona para un establecimiento acopiador de

leche de tambo?. 3. ¿Cuál es la ubicación óptima para cabinas de seguridad en la

ciudad de Buenos Aires?. 4. ¿Cuál es la zona adecuada para instalar una sala de atención

hospitalaria?. 5. ¿Cuál resulta ser el mejor barrio para la localización de una

sucursal bancaria?.

Las aplicaciones más elaboradas de los SIG son aquellas relacionadas con la integración de modelos matemáticos de procesos naturales, dinámicos y especialmente distribuídos. Los objetivos perseguidos pueden ser tanto científico como de planificación y ordenación, por ej.: saber qué zonas pueden ser inundables, qué consecuencias naturales puede tener la construcción de un embalse o represa sobre un determinado cauce de un río, cómo podría mejorarse la eficiencia en el uso del agua, cuál va a ser el impacto de desmontar determinada cantidad de hectáreas de un bosque, etc.

Entre las aplicaciones más usuales de los SIG se encuentran:

• Científicas: en ciencias medioambientales, desarrollo de modelos empíricos, modelización cartográfica, modelos dinámicos, teledetección.

• De Gestión: información pública (catastro), planificación de espacios protegidos, evaluación de recursos, ordenamiento territorial, planificación urbana, cartografía automática.

• Empresarial: Marketing, estrategias de distribución, localización óptima de sucursales o negocios.

Observando los usos y utilidades que brindan los sistemas de

información geográfica, podemos resumir que las peticiones al software de base del SIG se basan principalmente en solicitudes de ubicación de determinadas cosas, operaciones con objetos geográficos, búsqueda de rutas o caminos, obtener una dirección postal de un determinado punto, un punto en el plano a partir de una dirección postal y algunas cuestiones de consultas “ad-hoc” en base al sistema que estemos desarrollando. 2.7 Mapas en la web

Como se ha visto en la historia de los SIG, estos han ido ganando

popularidad y uso a lo largo de los años. Un paso importante en la popularidad de este tipo de sistemas se produjo a lo largo de la década de los ’90 cuando el costo de los mismos estuvo al alcance de las pequeñas y medianas empresas, para ser utilizadas en los equipos desktops. Luego, con el advenimiento de


- - 21

Internet comenzó a ser cada vez más común encontrar mapas interactivos en la web.

Durante los últimos años las organizaciones y las empresas han estado

proveyendo mapas y servicios de mapas en la web. Este tipo de sistemas de mapas en la web fueron implementados con herramientas propietarias (ArcInfo, Mapinfo, InterGraph, etc.). Como resultado de este tipo de implementaciones se obtiene que estos sistemas no pueden interactuar entre sí, debido a la diversidad de los formatos y a que dichos formatos no se encuentran abiertos ni estandarizados. En la figura 2.7 se puede apreciar la situación planteada, donde se observa que existen muchos mapas en la web (la capa más alta de la figura), y cada uno de ellos accede a una base de datos espacial, pero sin posibilidad de conexión entre ellos (denotado en la figura por letras “x” en color rojo).

Figura 2.7: Estado de los distintos mapas en la web con sistemas propietarios. [11] Otra figura donde se muestra el estado actual de la gran mayoría de los

servicios web de mapas es la figura 2.8, en la que se puede observar la poca interacción entre distintas aplicaciones, las cuales se deben acceder desde distintos lugares, todas implementadas de manera distinta, pero que quizás contienen los mismos datos espaciales. Incluso se puede observar también, el proceso de petición de las páginas con mapas a través de la web (los servicios de http request y response). En esta figura también se puede apreciar que el servidor de mapas 3 tiene una pequeña interacción con la base de datos del servidor de mapas 2, pero entre el servidor 1 y 2 no existe conexión alguna, por lo tanto los clientes de estos servidores no pueden tener acceso a los servicios o prestaciones brindados por otros servidores de mapas.

Con Web Mapping (mapas en la Web), al igual que con otras

aplicaciones web, existe una gran cantidad de servidores de distintos proveedores y organizaciones. Con este tipo de implementaciones, los beneficios que brinda Internet (amplio acceso de y para todos) no es captado si cada servidor tiene servicios propietarios, no estandarizados y sin ser públicamente documentados. Aunque con una documentación pública no alcanza si estos servicios no se encuentran estandarizados.


- - 22

Figura 2.8: Falta de interoperabilidad entre servidores de mapas. [11]

Para solucionar el problema planteado, el Open Gis Consortium (OGC)

[6] ha desarrollado un enfoque para los mapas en la web basado en interfaces abiertas. El trabajo que se realiza en el OGC, a través de los programas de Especificación e Interoperabilidad proveen un proceso de consenso para planificar, desarrollar, revisar y oficialmente adoptar las interfaces promovidas por el OGC, que permite disponer de procesos geoespaciales de servicios, datos y aplicaciones ínter operables.

Interoperabilidad, en el contexto del OpenGis Specification Program, se

refiere a componentes de software trabajando recíprocamente para superar el trabajo bastante tedioso de conversión, importación y exportación de datos y de heterogeneidad de entornos (que incluyen productos, sistemas operativos, etc.).

A través de la iniciativa de OGC Web Services (OWS) se ha abierto un

nuevo enfoque para que los proveedores de software de SIG puedan producir software basado en web ínter-operable. Con esta posibilidad, los usuarios cuentan con la posibilidad de poder visualizar mapas temáticos desde diferentes fuentes de información distribuidas a lo largo de varios servidores web y de distintos proveedores de los productos de software. En la figura 2.9 se puede observar las ventajas que brinda esta iniciativa del OGC.

Todas las interfaces provistas por el OGC, brindan un alto nivel de

abstracción de permite ocultar el “trabajo sucio” en los ambientes web de mapas. Este “trabajo sucio” incluye encontrar servidores de mapas remotos, solicitar información de dichos servidores, cambiar el sistema de coordenadas o retornar información para ser mostrada en un cliente.


- - 23

Figura 2.9: Vista integrada de servicios espaciales. [11]

Con las interfaces provistas por el OGC en materia de Servicios de

mapas en la web, cada servidor de mapas implementa una interface común y un protocolo de mensajes (WMS interface) para recibir y contestar peticiones de mapas. De esta manera un cliente puede tener acceso a múltiples servidores de datos y de mapas, donde cada servicio de mapa es accedido de la misma manera. De esta forma se puede observar en la Figura 2.10 cómo se modifica la problemática que se mostraba en la Figura 2.8.

Figura 2.10: Interoperabilidad entre los clientes y los servidores. [11]

Entonces, se puede observar que un único cliente puede acceder simultáneamente o no a distintos servidores de mapas y a los beneficios que pueden brindar cada uno de ellos. Esto permite, sin lugar a ninguna duda, a tener aplicaciones más abiertas, colaborativas entre sí y trasladar la complejidad del desarrollo a solucionar problemas cada vez más complejos.

A lo largo del capítulo se ha abordado los distintos conceptos de los

sistemas de información geográficos, donde se puede apreciar que son sistemas muy potentes y que con el correr de los años no sólo se han hecho más populares y de uso cotidiano, sino que han ido desarrollando capacidades para ser hoy una herramienta fundamental en la toma de decisiones en las


- - 24

distintas organizaciones. Se ha analizado también las distintas posibilidades que brindan este tipo de sistemas junto a las operaciones básicas que desarrollan cada uno de ellos.

Sobre el final del capítulo se ha comenzado a analizar los aspectos

iniciales de los mapas en la web, y más específicamente de los servicios de mapas en la web, los cuales se basan en las especificaciones que brinda el OGC.

En el próximo capítulo se abordarán en profundidad los temas

relacionados con los servicios web de mapas, junto a un análisis minucioso de los distintos estudios y frameworks de mapas disponibles. También se hará una especificación teórica del trabajo de esta tesis.

Definición y Antecedentes del Framework

- 25 -

3. DEFINICION Y ANTECEDENTES DEL FRAMEWORK

Los sistemas de información geográfica han surgido en la década de 1960 y su inserción y uso dentro de las empresas y los organismos públicos ha sido muy importante. Cabe mencionar que más del 80% de los negocios requieren de servicios o prestaciones de localización geográfica. Los beneficios que aporta para la toma de decisiones, inteligencia que adiciona a los negocios, operaciones e información pública son innumerables; sin embargo muchos factores han mitigado estos beneficios.

La necesidad de compartir la cartografía de base, no tener que hacer

enormes inversiones en licenciamiento de las herramientas, tener un repositorio común de la información, con el único propósito de mejorar el rendimiento de los SIG (aumentando la utilización de los mismos), mejorar la confianza en el formato y actualización de la información y en la reducción de costos, se fueron convirtiendo en las necesidades básicas para poder llevar adelante exitosamente un plan de implementación de una solución con sistemas de información geográfica.



Los servicios Web son servicios que están disponibles en Internet

(intranet), utilizan un sistema de mensajería estandarizada y no están ligados a sistema operativo alguno o lenguaje de programación. A su vez los servicios Web pueden (es deseable que así sea) tener dos propiedades adicionales: se describen a sí mismos y se deben publicar para que se conozcan [3].

Por lo tanto, los servicios Web de SIG son servicios disponibles en

Internet, que utilizan los mismos mecanismos que los servicios Web, pero que brindan información y funcionalidades específicas y propias de sistemas de información geográfica.


organizaciones que desean hacer uso de información espacial y no encontrarse con los problemas mencionados anteriormente. Al poder hacer un “outsourcing” de los servicios de datos espaciales, se encuentra la organización con una serie de beneficios: menor costo, menores riesgos, menores tiempos de desarrollo y disponibilidad de la información, menor cantidad de recursos especializados para poder llevar adelante la solución [22].

3.1 Antecedentes

Compartir información geográfica y servicios asociados es una tarea que se viene investigando y haciendo ensayos desde hace varios años, su resurgimiento se debe principalmente a los organismos gubernamentales, quienes han sido, quizás por su naturaleza, los pioneros en implementar estructuras de trabajo que permitan compartir información geográfica.


- 26 -

También se ha abordado la problemática de servicios Web de SIG, de SIG en la Web y de infraestructuras de datos espaciales desde distintos trabajos de investigación [32][33][34][35][36][37][38][39]. Todos estos trabajos versan sobre la necesidad de contar con una infraestructura con interface Web, principalmente para el manejo de información estandarizada, así como de las capas (de negocio y físicas) necesarias para desarrollar las aplicaciones de este estilo. En algunos casos se han encontrado trabajos de investigación donde se encuentran desarrollos específicos de las especificaciones del OpenGis Consortium [43] en distintos lenguajes como Java, .NET y otras herramientas, pero sin ser alguno de ellos una especificación formal desde la cual partir para una generación automática de servicios SIG.

Actualmente existen ya definidas especificaciones estándares de cómo

se deben almacenar y presentar los mapas, los formatos de los mismos, los mecanismos de transferencia de dicha información, los servicios para acceder a los mapas, y la forma en que se deben presentar los “features” o características en el plano, como se muestra en la Figura 3.1.

Figura 3.1. Rol del Servidor de dispositivos móviles geográfico.[15]

Existen otros proyectos que integran mapas en la Web y servicios de información geográfica, los cuales iremos detallando más adelante en el capítulo.

3.1.1 Especificaciones estándares del OGC

El Open Geospatial Consortium [43], a través de sus miembros, se encarga de desarrollar especificaciones de interfaces públicas. Este organismo soporta soluciones interoperables que hacen que la Web sea “geo-enable”1. 1 Geo-enable se puede definir como que la Web permita la utilización de objetos y cálculos geográficos.


- 27 -

Dentro de la vasta lista de especificaciones [43] estándares que ha

desarrollado el OGC, en el presente trabajo describiremos brevemente aquellas que son de utilización directa en el espacio del problema. Las especificaciones abordadas serán las siguientes:

- OGC Location Services (OpenLS) Implementation Specification: Core

Services [15]. - OpenGis Geography Markup Language (GML) [19] - OpenGis Web Feature Service (WFS) Implementation Specification

[17]. - OpenGis Web Map Specification (OMS) Implementation Specification

[44].

3.1.1.1 OGC Location Services (OpenLS) Implementation Specification

Esta especificación de implementación define los servicios de localización, los cuales son un conjunto básico de servicios que comprende la plataforma OpenLS. Esta plataforma también es conocida como el servidor Geomobility (Figura 3.1), una plataforma abierta de servicios de localización.

Esta especificación se basa en la definición de: - Tipos abstractos de datos (ADT): Estos tipos abstractos son

construcciones básicas de información utilizadas por el Servidor Geomobility y por los servicios que allí se encuentran. Estos tipos consisten en tipos de datos y estructuras conocidas o bien formadas para la información de localización. Dentro de los ADTs se encuentran:

o Address ADT: contiene información de dirección de un

punto o lugar geográfico. Consiste de una calle (o intersección), nombre de lugar (ej: ciudad, municipalidad, etc.), código postal, calle de localización y alguna información adicional.

o Area of interest ADT: contiene un área de interés, definida

como un círculo, un rectángulo o un polígono con nombre. Este tipo de dato es utilizado como parámetro en los servicios básicos.

o Location ADT: es un tipo extensible para todas las

expresiones de localización que pueden ser utilizadas en la plataforma (aplicaciones y servicios) para especificar la localización de un receptor. Es la raíz del árbol semántico que incluye a un punto, Position ADT, Address ADT y POI ADT y sus subtipos.

o Map ADT: contiene un mapa renderizado, consiste de

información de contenido (formato, ancho y largo) e


- 28 -

información de contexto (rectángulo de alcance, punto central y escala).

o Point of Interest (POI) ADT: Lugar o entidad con una

posición fija que puede ser utilizado como punto de referencia u objetivo en uno de los servicios de la plataforma. Contiene nombre, tipo, categoría, dirección, número telefónico, y alguna otra información de directorio acerca del lugar, producto y/o servicio.

o Position ADT: contiene una posición observada o

calculada. Principalmente contiene una posición geográfica y la calidad de dicha posición.

o Route Instruction List ADT: consiste de una lista de

indicaciones de ruta conteniendo paso a paso el camino, junto a avisos y puntos de interés a lo largo de la ruta, ordenados en orden de secuencia o aparición desde el comienzo hasta el final.

o Route ADT: está compuesto por dos ADTs a saber; Route

Summary y Route Geometry. Route summary contiene todas las características de la ruta, como el punto de inicio, puntos intermedios, punto final o de llegada, tipo de transporte, distancia total, tiempo de viaje, y un área de influencia. Route geometry contiene una lista de posiciones geográficas a lo largo de la ruta. Este también contiene los puntos de todos los nodos que componen la ruta, incluyendo los puntos intermedios.

- Servicios básicos (Core Services): Los servicios básicos que

componen la plataforma, y que en definitiva son quienes cumplen las tareas solicitadas por los suscriptores o clientes. Dentro de los servicios podemos mencionar los siguientes:

o Directory Service: el servicio de directorio permite a los

suscriptores acceso a un directorio en línea para encontrar el servicio, o producto más cercano o un lugar específico. Como ejemplos del uso de este servicio se presentan los siguientes casos de uso:

- ¿Dónde se encuentra el restaurante chino “Dragón

Rojo”?. - ¿Dónde se encuentran los restaurantes chinos en

una determinada ciudad?. - ¿Cuál es el restaurante chino más cerca al hotel

donde me encuentro alojado?. - ¿Cuáles son los restaurantes chinos que se

encuentran a 500 metros de mi hotel?.


- 29 -

o Location Utility Service (Geocoder / Reverse Geocoder): el servicio de ubicación (geocodificación y geocodificación inversa) determina una posición geográfica a partir de un nombre de lugar, calle o dirección postal. A su vez retorna una descripción completa y normalizada del lugar. También realiza una geocodificación inversa, brindando una dirección completa y normalizada de un lugar determinado a partir de una posición geográfica dada. Algunos ejemplos de utilización de este servicio se brindan a continuación:

- La base de datos de una empresa contiene un

listado de los clientes con su dirección postal normalizada. La compañía pretende asociar un punto geográfico asociado a cada dirección (a cada cliente).

- Un automovilista desea llegar a un punto determinado en una ciudad, por ej: el obelisco. Una vez localizado el punto geográfico, este es utilizado dentro de una rutina de ruteo para obtener la hoja de ruta.

- ¿Dónde me encuentro? Una persona desea saber en qué calle se encuentra de acuerdo a su posición geográfica brindada por el dispositivo móvil con que cuenta (el cual debe contar con un dispositivo de posicionamiento global).

o Presentation Service: este servicio se encarga de mostrar

la información geográfica (mapa) en un dispositivo móvil o desde donde se solicita la información. Las respuestas geográficas de los servicios brindados por la plataforma son manejados por este servicio.

o Route Service: el servicio de ruteo determina la ruta que

debe realizar un solicitante. El usuario indica el punto de inicio y el de fin, puntos intermedios (si existieran), el plan de ruta deseado (la ruta más rápida, la más corta, etc.) y el medio de transporte (a pie, vehículo, etc.); el servicio entonces determina la ruta de acuerdo a los parámetros dados. A continuación se mencionan algunos casos de uso del servicio:

- ¿Qué ruta debo tomar para llegar desde mi

ubicación actual hasta el Club Belgrano?. - ¿Cuál es el camino óptimo para ir desde el Obelisco

hasta el Aeropuerto internacional Ezeiza?.

A modo de resumen se muestra la Figura 3.2, donde se puede ver la interrelación de los tipos abstractos de datos y los servicios brindados por la especificación del OGC.


- 30 -

3.1.1.2 OpenGis Geography Markup Language (GML) GML es una gramática XML, escrita en el conjunto XML para modelar,

transportar y almacenar información geográfica, principalmente sobre Internet. Los conceptos claves utilizados por GML para modelar el mundo fueron

tomados del OpenGis Abstract Specification [45] y de las normas ISO 19100. GML provee una variedad de tipos de objetos para describir geografía,

incluyendo características, sistemas de coordenadas de referencia, geometrías, topologías, tiempo, unidades de medida y valores generalizados.

Una característica geográfica2 es una abstracción de un fenómeno del

mundo real, es una característica geográfica si está asociada con una ubicación relativa a la tierra. Por lo que la representación digital del mundo real puede ser pensada como un conjunto de características. El estado de una de estas características está definido por un conjunto de propiedades.

En la especificación el concepto de característica (feature) es muy

general y no solamente abarca objetos “vectoriales” o discretos, contempla coberturas y datos sensoriales. La clave de esta especificación es la habilidad para integrar todas las formas de información geográfica.

Figura 3.2. Modelo de información de OpenLS. [15]

3.1.1.2.1 El Modelo

El modelo original GML se basó en el World Wide Web Consortium’s Resource Description Framework (RDF) [46]. Luego el OGC introdujo los diagramas XML dentro de la estructura de GML para ayudar a conectar la gran variedad de bases de datos geográficas existentes, cuya estructura relacional era mejor representada por los esquemas XML.

GML contiene un rico conjunto de primitivas utilizadas para construir

esquemas específicos de aplicaciones. Las primitivas incluyen: - Características.

2 Geographic feature, se traduce como característica geográfica, aunque resulta más difícil de ver, es la

traducción al castellano que se debe utilizar.


- 31 -

- Geometrías. - Sistema de coordenadas de referencia. - Tiempo. - Características dinámicas. - Coberturas. - Unidades de medida. - Reglas de estilo de presentación del mapa.

3.1.1.2.2 Perfiles Los perfiles son restricciones a GML, pueden ser expresadas por un

documento, un esquema XML o ambas. La finalidad de estos perfiles es simplificar la adopción de GML, para facilitar una rápida adaptación del estándar. A continuación se expresan algunos ejemplos de perfiles propuestos para uso público:

- Point profile. - GML Simple feature profile.

3.1.1.2.2.1 GML Simple Feature Profile

Este perfil soporta una gran variedad de objetos vectoriales:

1. Un modelo geométrico reducido incluyendo objetos geográficos de cero, una, dos y tres dimensiones y las correspondientes geometrías agregadas.

2. Un modelo simplificado, donde solamente se permite un solo nivel de profundidad.

3. Todas las propiedades no geométricas tienen que ser esquemas XML de tipos simples (no pueden contener elementos anidados).

4. Referencias remotas a propiedades.

Ya que este perfil intenta proveer de un solo punto de entrada, no soporta lo siguiente:

- Coberturas - Topologías - Observaciones - Datos de sensores de tiempo real - Características dinámicas

3.1.1.2.2.2 Subset Tool

La especificación cuenta además con una herramienta para la generación perfiles GML, conteniendo una lista de componentes especificada por el usuario. La herramienta consiste de un par de códigos XSLT. Estos códigos generan un perfil que el desarrollador puede extender manualmente. 3.1.1.2.3 Esquema de aplicación


- 32 -

A fin de exponer una aplicación con datos geográficos con GML, una

organización crea un esquema XML específico para el dominio de interés de la aplicación (el esquema de la aplicación). Este esquema describe los tipos de objetos que a la organización le interesa y quieren exponer. Por ej. una aplicación para turismo podría definir tipos de objetos que incluyan monumentos, lugares de interés, museos, salidas de autopistas, etc.

3.1.1.2.4 Geometrías GML

GML codifica las características geométricas de los objetos geográficos como elementos dentro de los documentos GML. Las geometrías de estos objetos pueden describir rutas, ríos, puentes, etc.

Los tipos de objetos geográficos claves en GML son: - Puntos - Líneas - Polígonos

3.1.1.2.5 Características

GML define características como algo distinto de objetos geométricos. Una característica es un objeto de la aplicación que representa una entidad física, ej: un edificio, una ruta, un río, etc. Una característica puede o no tener aspectos geográficos. Un objeto geométrico define una ubicación o región en lugar de una entidad física y por lo tanto es distinto que una característica. Esta distinción en GML entre características y objetos geográficos difiere del modelo que utilizan los SIG, en donde característica y objeto geográfico son la misma cosa.

En GML la característica puede tener asociados varias propiedades

geométricas que describen aspectos geométricos o geográficos de la característica. A su vez, se permite que las características compartan propiedades geométricas, haciendo referencia a la misma como referencia remota a la propiedad. 3.1.1.2.6 Coordenadas

Estas representan las coordenadas de los objetos geométricos. Las

coordenadas pueden ser especificadas por alguno de los elementos siguientes: - <gml:coordinates> - <gml:pos> - <gml:posList> En GML existen varias formas para representar coordenadas. Veamos

algunos ejemplos: <gml:Point gml:id="p21" srsName="urn:ogc:def:crs:EPSG:6.6:4326">


- 33 -

<gml:coordinates>45.67, 88.56</gml:coordinates> </gml:Point> <gml:Point gml:id="p21" srsName="urn:ogc:def:crs:EPSG:6.6:4326"> <gml:pos dimension="2">45.67 88.56</gml:pos> </gml:Point> <gml:LineString gml:id="p21" rsName="urn:ogc:def:crs:EPSG:6.6:4326"> <gml:coordinates>45.67, 88.56 55.56,89.44</gml:coordinates> </gml:LineString >

3.1.1.2.7 Sistema de coordenadas de referencia El sistema de coordenadas de referencia determina la geometría de

cada elemento geométrico en un documento GML.

3.1.1.3 OpenGis Web Feature Service (WFS) Implementation Specification

Esta especificación define la interface para describir la operación de datos geográficos de características geográficas. Estas operaciones de manejo de datos incluyen la habilidad para:

- Obtener o consultar por características basado en restricciones

geográficas o no. - Crear una nueva instancia de una característica. - Borrar una característica. - Actualizar una característica.

El servicio WFS describe las operaciones de exploración, consulta, o

transformación de datos. El pedido es generado en el cliente y es colocado en un servidor de características Web, utilizando HTTP. El servidor luego lee y ejecuta el pedido. Ver figura 3.3.

Esta especificación permite a los clientes obtener información

geoespacial codificada en GML desde varios Servicios Web de características. Los requerimientos para un servicio Web de características son: - La interface debe estar definida en XML.

- Se debe utilizar GML para expresar las características dentro de la

interface.

- Un mínimo de un WFS debe ser capaz de presentar las características utilizando GML.

- La forma en que se almacenan las características geográficas debe

ser oculta para las aplicaciones de los clientes y la única forma de poder visualizar los datos tiene que ser a través de la interface WFS.


- 34 -

3.1.1.3.1 Arquitectura WFS

La figura 3.4 muestra los componentes necesarios para servir características geográficas y procesar los requerimientos de transacciones desde una aplicación cliente utilizando HTTP como el ambiente de computación distribuido.

Figura 3.3. Web Feature Service. [17]

La figura 3.4 muestra los componentes necesarios para servir

características geográficas y procesar los requerimientos de transacciones desde una aplicación cliente utilizando HTTP como el ambiente de computación distribuido.

A continuación abordaremos una breve descripción de cada uno de los

componentes de la arquitectura mostrada: - Client Application (Aplicación Cliente): cualquier programa o proceso

que se comunica vía http con un servidor Web. El ejemplo típico es un navegador Web, pero no solamente se refiere a este tipo de clientes.

- HTTP Server (Servidor HTTP): es un programa que maneja pedidos

http, como es el caso de Apache Web Server.

- Web Feature Server (WFS): un programa o módulo que implementa interfaces que soportan transacciones y/o consultas en características Web accesibles.

- Feature Datastore (Base de características): un componente de

software para el manejo y almacenamiento persistente de las propiedades espaciales y no espaciales de las características geográficas. Esta base puede estar basado en una base de datos SQL relacional, archivos planos, XML, etc.


- 35 -

Figura 3.4. Arquitectura WFS. [17]

3.1.1.3.2 Procesamiento de pedidos WFS

En este punto se explicará en líneas generales el protocolo a seguir cuando se solicitan o se tramitan pedidos WFS.

Procesar las solicitudes debería seguir los siguientes lineamientos: - Una aplicación cliente solicita un documento de capacidades

(capabilities) del WFS. Este documento contiene una descripción de todas las operaciones que WFS soporta y una lista de todos los tipos de características que puede ofrecer.

- Una aplicación cliente (opcionalmente) puede solicitar al servidor de

características por la definición de una o más tipos de características que el WFS puede ofrecer.

- Basado en la definición de los tipos de características, una aplicación

cliente genera una solicitud como se especifica en la especificación WFS.

- La solicitud es colocada en un servidor Web.

- El WFS es invocado para leer y servir el pedido o solicitud.

- Cuando WFS ha completado de procesar la solicitud, generará un

reporte de estado y será enviado al cliente que lo solicitó. En el caso de que ocurriera un error el reporte de estado así lo hará saber.

El proceso descripto anteriormente puede ser visto en la Figura 3.5, de

forma simplificada. En la figura se muestra la interacción o envío de mensajes entre el cliente, el WFS y la base de datos de características.

3.1.1.3.3 Operaciones del Servicio Web de características (WFS)


- 36 -

Tal como se mencionó al comienzo del apartado 3.1.1.3, donde se mencionaban las operaciones que son especificadas, a continuación se definen con más detalle las mismas:

- GetCapabilities: Un servidor Web de características debe ser capaz

de describir sus capacidades. Específicamente, debe indicar qué tipos de características puede servir y qué operaciones son soportadas para cada tipo de característica.

- DescribeFeatureType: un servidor Web de características debe ser

capaz de, a petición, describir la estructura de cualquiera de las características que puede servir.

- GetFeature: un servidor Web de características debe ser capaz de

servir un pedido de obtener una instancia de una característica. Además, el cliente debe ser capaz de especificar qué propiedades de la característica obtener y ser capaz de restringir la búsqueda con parámetros geográficos y no geográficos.

- Transaction: Un servidor Web de características debe ser capaz de

soportar solicitudes transaccionales. Una transacción se compone de operaciones que modifican características (crear, actualizar y borrar características geográficas).

- LockFeature: un servidor Web de características debe ser capaz de

realizar una operación de bloqueo en una o más instancias de características por lo que dura una transacción. Esto asegura que las transacciones serializadas pueden ser soportadas.


- 37 -

Figura 3.5.Diagrama de secuencia que muestra el protocolo involucrando un cliente, un WFS y la base de datos. [17]

3.1.1.4 OpenGis Web Map Service Specification (OMS) Implementation Specification

Un Servicio de Mapas en la Web produce mapas dinámicos con

información espacial referenciada a partir de información geográfica. Este estándar internacional define que un “mapa” va a ser una imagen de información geográfica como una imagen en formato digital que puede ser mostrada en una pantalla de computadora. Un mapa no es un dato en sí mismo. Los mapas producidos a través de WMS son mostrados normalmente en un formato de imagen digital como PNG, GIF o JPEG, y ocasionalmente como gráficos basados en formato vectorial en formato SVG (Vector Scalable Graphics) o en formato WebGCM (Web Computer Graphics Metafile).

Este estándar internacional define tres operaciones: una devuelve

metadatos a nivel de servicio; otro retorna un mapa donde los parámetros geográficos y dimensionales están bien definidos; y opcionalmente una tercera operación retorna información acerca de una característica existente en el mapa.

Las operaciones de un Servicio de Mapas en la Web pueden ser

invocadas utilizando un navegador Web realizando peticiones a una URL. El contenido de esta URL dependerá del tipo de operación solicitado. En particular, cuando se solicita un mapa el URL indica qué información debe ser mostrada en el mapa, qué parte de la tierra se mostrará, el sistema de coordenadas de referencia deseado, y el tamaño de la imagen de respuesta (ancho y alto). Cuando dos o más mapas son producidos, con los mismos


- 38 -

parámetros geográficos, estas pueden ser compuestas o superpuestas para producir mapas compuestos. Al utilizar formatos de imágenes que permiten fondos transparentes (como es el caso de GIF o PNG) permiten la creación de este tipo de mapas compuestos. Además los mapas individuales (que componen el mapa general) pueden ser solicitados de servidores distintos. Por lo tanto WMS permite la creación de una red de servicios de mapas distribuidos donde los clientes pueden construir mapas personalizados.

Un servicio básico de WMS clasifica su información geográfica en

“capas” y ofrece una cantidad finita de “estilos” en los cuales mostrar esas capas. Esta especificación solamente se basa en las “capas” con nombres y estilos, y no incluye un mecanismo para símbolos definidos por el usuario.

3.1.1.4.1 Operaciones Las tres operaciones definidas son las siguientes: - GetCapabilities: el propósito de esta operación es obtener metadatos

del servicio, el cual es una descripción, legible para la máquina (y también para el hombre), de la información de contenido y de los valores de los parámetros requeridos por el servidor. Los parámetros que se necesitan en una petición a esta operación son los siguientes: VERSION, SERVICE, REQUEST, FORMAT, UPDATESEQUENCE. La respuesta de esta operación es un documento XML conteniendo la información de metadata del servicio, con el formato de acuerdo al esquema XML.

- GetMap: esta operación retorna un mapa. Dentro de los parámetros

que se necesitan en una petición a esta operación se pueden nombrar: VERSION, REQUEST (el nombre de la operación solicitada), LAYERS (la lista de capas a solicitar que compongan el mapa), BBOX (tamaño del cuadro de referencia del mapa), WIDTH (ancho en píxeles de la imagen resultado), HEIGHT (alto en píxeles de la imagen resultado), FORMAT (formato de la imagen), TRANSPARENT, BGCOLOR (color de fondo de la imagen)

- GetFeatureInfo: Esta operación está soportada para aquellas capas

que están seteadas como queryable=1 (capas consultables). Los clientes no podrán utilizar esta operación para las capas que no tienen ese seteo establecido. El resultado de esta operación es proveer a los clientes con más información acerca de las características que forman parte de una imagen de mapa solicitada previamente (a través de la operación GetMap). La idea del uso de esta operación es que el usuario al ver el resultado de un mapa, seleccione un punto (i,j) en el mapa obtenido para el cual quiere obtener mayor información. La operación básica provee a los clientes la habilidad de especificar qué punto es el solicitado, qué capa y en qué formato se necesita que se devuelva la información solicitada.


- 39 -

Como el protocolo WMS es estático, en la solicitud de la operación se deben indicar muchas de las cosas que se solicitaron en la operación GetMap. Dentro de los parámetros que se incluyen en el pedido de la operación se encuentran: VERSION, REQUEST (en este caso es GetFeatureInfo), map request part (parte de los parámetros de la petición de la operación GetMap), QUERY_LAYERS (lista de capas a consultar), FEATURE_COUNT (cantidad de características a retornar como respuesta), I=pixel_column (coordenada i de la imagen), J=pixel_row (fila j de la imagen), INFO_FORMAT (formato de la respuesta).

3.1.2 Infraestructuras de Datos Espaciales

El mundo de la información geográfica ha cambiado en los últimos años

con la introducción de una serie de conceptos y metodologías que giran alrededor de las denominadas Infraestructuras de Datos Espaciales. Tanto es así, que es ahora cuando esas nuevas corrientes empiezan a verse reflejadas de forma práctica en el software y al ser adoptadas por las distintas administraciones públicas.

Pero, ¿qué es una Infraestructura de Datos Espaciales? Las Infraestructuras de Datos Espaciales (IDE), es el nombre que

reciben los mecanismos para compartir información en y entre organizaciones. Podríamos decir que una IDE es un Sistema de Información Geográfico distribuido, cuyo objetivo es maximizar el acceso a los datos geográficos a los usuarios, minimizando así la duplicación de esfuerzo e inversiones.

La historia de las infraestructuras de datos espaciales comienza, en el

año 1994, cuando el entonces presidente norteamericano William J. Clinton publicó una orden presidencial para poner en marcha la Infraestructura Nacional de Datos Espaciales de EEUU (NSDI) [7]. El motivo principal es el razonamiento de que "compartir conocimiento es fuente del crecimiento económico".

En 2004, la Comisión Europea consiguió la admisión a debate

parlamentario europeo de la directiva INSPIRE [5] por la que se establece una infraestructura de información espacial en la Comunidad. La IDE Europea se conforma como un rompecabezas formado por las distintas Infraestructuras de Datos Espaciales locales y nacionales.

También sobre fines del año 2004, en la República Argentina se

comenzó con un proyecto integrado para toda la información geográfica disponible en el país, tanto para uso público como privado. Dicho proyecto se denominó PROSIGA (Proyecto Sistema de Información Geográfica Nacional de la República Argentina) [8]. El objetivo principal de este proyecto es de disponibilizar en forma integrada información geográfica de la República Argentina, con intervención directa de múltiples actores gubernamentales,


- 40 -

vinculados mediante una estructura nodal de intercambio de datos a través de redes teleinformáticas.

A continuación iremos abordando cada uno de los proyectos en más

detalle para que el lector pueda entender el estado del arte actual.

3.1.2.1 National Spatial Data Infraestructure

E proyecto, en el año 1994, fue iniciado por el entonces presidente William J. Clinton, a través de la orden presidencial 12906 para poner en marcha la Infraestructura Nacional de Datos Espaciales de EEUU (NSDI) [21], cuyo propósito fundamental fue el razonamiento de que “compartir conocimiento es fuente del crecimiento económico”.

Recién en Agosto de 2002, cuando es reafirmada la orden del año 1994,

es que se comienza con la construcción del framework, el cual fue encomendado al Federal Geographic Data Committee para su coordinación.

El framework es un esfuerzo colaborativo para crear una fuente de datos espaciales lo suficientemente amplia. Los aspectos clave del framework son:

- Siete temas de datos geográficos digitalizados, que son los más

comúnmente utilizados, - procedimientos, tecnología, y lineamientos que provee la integración,

uso e intercambio de estos datos,

- relaciones institucionales y prácticas de negocio que aseguran el mantenimiento y uso de los datos.

La idea es seguir el lema “datos en los cuales confiar”, donde estos

datos sean los mejores disponibles para un área determinada, certificada, estandarizada y descripta acorde a estándares.

3.1.2.1.1 Componentes

El framework contiene cuatro componentes principales: - Contenido de la información: El framework contiene los datos

geográficos temáticos utilizados por la mayoría de las organizaciones. Estas áreas temáticas son las siguientes: control geodésico, ortoimágenes, elevación, transporte, hidrografía, unidades gubernamentales e información catastral. Los datos dentro de estos temas son los más comúnmente producidos. A pesar de que los datos del framework sirven como base para una gran cantidad de problemas y operaciones, normalmente no proveen todos los datos necesarios para una tarea determinada. En la práctica, la idea es que los datos del framework sean complementados con información o datos específicos del usuario (tanto en datos geográficos como en


- 41 -

atributos). La infraestructura solamente intenta proveer información geográfica de base en un formato común que sea fácilmente accedido por todos los actores. A continuación se brindará una descripción de los datos temáticos expuestos en NSDI.

o Control Geodésico: este tema provee de un sistema de referencia común para establecer las posiciones de coordenadas de todos los datos geográficos. Esta componente (control geodésico) consiste de estaciones de control geodésico e información relacionada (nombre, código de identificación de características, latitud y longitud, altura ortométrica, elipsoide de referencia y metadatos).

o Ortoimagen: provee una imagen correctamente

posicionada de la tierra. Una ortoimagen es una imagen georeferenciada preparada desde una fotografía aérea o de algún otro sensor de datos.

o Elevación: provee información acerca de los terrenos.

Elevación se refiere a la posición vertical espacialmente referenciada, por encima o debajo de un dato de superficie. El framework incluye la elevación de las superficies terrestres y de profundidades por debajo de superficies de agua.

o Transporte: incluye las siguientes características comunes

y más utilizadas en las redes de transporte:

• Carreteras

• Senderos

• Ferrocarriles

• Vías navegables

• Aeropuertos y puertos marítimos

• Puentes y túneles

La información de transporte es utilizada en muchas aplicaciones. Algún uso de esta información puede ser solamente con propósitos de referencia, como un elemento que compone un mapa de base, y en otros puede ser la clave en la utilización del mapa.

o Hidrografía: incluye características de las aguas superficiales, como lagos, estanques, arroyos y ríos, canales, océanos y costas.

o Unidades gubernamentales: incluye las áreas geográficas

de las unidades de gobierno. Estas unidades incluyen:


- 42 -

• la nación,

• estados y áreas estadísticas equivalentes,

• condados y áreas estadísticas equivalentes,

• lugares y ciudades consolidadas,

• divisiones jurídicas,

• reservas Americanas en la India,

• corporaciones regionales nativas de Alaska.

Este tipo de información (unidades gubernamentales) son utilizadas para una gran variedad de aplicaciones. Algunas de ellas solamente la necesitan para información y orientación; otras las requieren para utilizar los polígonos que las componen para determinar inclusiones de otras características.

o Información Catastral: se refiere a los intereses de las propiedades. Los datos catastrales representan los derechos de las extensiones geográficas del pasado, presente y futuro y los intereses en la propiedad real. La información espacial necesaria para describir las extensiones geográficas y los derechos e intereses incluyen encuestas, sistemas de referencia y descripciones legales, y encuestas parcela por parcela y su descripción.

La información catastral es la base para algunos análisis, toma de decisiones, y aplicaciones operacionales, como puede ser el de la elecciones, la utilización de las redes de servicios (eléctrico, gas, etc.), planificación del transporte.

- Contexto técnico: este contexto está diseñado para hacer fácil a la

gente la contribución y utilización de datos. Los usuarios podrán incorporar actualizaciones al framework sin generar problemas en sus propios datos. Cada participante podrá contribuir datos al framework.

El modelo de datos espaciales del framework y el soporte técnico de las características tiene que estar diseñado para permitir el almacenamiento de datos y ser actualizados sin riesgo y para permitir que la información sea agregada.

- Contexto operacional: el ambiente operacional del framework se basa en accesibilidad y facilidad de uso. Las características operacionales son las siguientes:

o Actualizaciones transaccionales: los productores de datos

proveen solamente los archivos cambiados, y los usuarios necesitan solamente procesar los cambios.

o Permitir la entrada a una versión oficial de los datos del framework a través de redes de información y medios digitales.


- 43 -

o Los datos del framework pueden ser encontrados a través

de la red de productores de datos geoespaciales.

- Contexto de negocios: con el fin de que el framework sea ampliamente utilizado y útil, los datos están abiertos permanentemente, incluyendo información acerca de las limitaciones de los datos, conforme a estándares aprobados, y están certificados. Una premisa básica de este contexto es eliminar las prácticas restrictivas.

3.1.2.1.2 Organización

El framework está construido y administrado por un esfuerzo cooperativo de todos los participantes, locales, regionales, de estado y agencias del gobierno federal, compañías del sector privado, instituciones educativas, organizaciones sin fines de lucro y cualquier otro participante.

Se han identificado 7 funciones principales del framework:

1. desarrollo de los datos, mantenimiento e integración, 2. acceso a los datos, 3. manejo de los datos, 4. coordinación, 5. guía ejecutiva, 6. manejo de los recursos, 7. monitoreo y respuesta.

A lo largo de la breve descripción que se ha hecho de la infraestructura, la misma no contempla aún servicios para la utilización de los datos, sino simplemente el hecho de compartir la información espacial, tanto entre organismos gubernamentales o privados. Es decir la utilización de los datos se reduce a su consulta o actualización, pero no a actividades o servicios puramente geográficas.

3.1.2.2 Infraestructure for Spatial Information in Europe (INSPIRE)

Otro de los proyectos iniciados para formar una Infraestructura de Datos Espaciales fue el de la Comunidad Económica Europea (INSPIRE) , a través de la Directiva 2007/2CE del Parlamento Europeo y del Consejo, con fecha 14 de Marzo de 2007 [23]. En dicha Directiva se hace mención a los problemas relativos a la disponibilidad, calidad, organización, y puesta en común de información espacial y servicios asociados a las mismas.

A su vez define la infraestructura de información espacial como los

metadatos, conjuntos de datos espaciales y los servicios de datos espaciales; los servicios y tecnologías de red; los acuerdos de acceso de la información. Y define servicios de datos espaciales como las operaciones que se pueden efectuar, a través de aplicaciones, sobre los datos espaciales.


- 44 -

Los lineamientos principales de esta infraestructura fueron: - las infraestructuras de información espacial en los Estados miembros

tienen que ser designadas para asegurar que la información espacial es almacenada, se hace disponible y mantenida en los niveles más apropiados,

- que sea posible combinar datos espaciales de diferentes fuentes a

través de la Comunidad de una forma consistente y compartida entre los usuarios y las aplicaciones,

- que la información coleccionada en un nivel de la infraestructura

pueda ser compartido con los otros niveles,

- que la información se hace disponible bajo condiciones que no restringen su utilización,

- que es fácil descubrir los datos espaciales disponibles, evaluar su

adecuación para un propósito y conocer las condiciones de uso.

3.1.2.2.1 Arquitectura técnica

En la figura 3.6 se puede apreciar el gráfico donde se muestra la arquitectura técnica de la infraestructura.

Como elemento principal de la arquitectura se puede apreciar los

servicios: Discovery, View, Download, Transform e Invoque (se describirán en las próximas secciones).

Los servicios son accedidos a través de la capa GeoRM y pueden ser

accedidos por aplicaciones y geoportales vía el canal de servicios de INSPIRE. A continuación se irán brindando explicaciones más particulares de cada

uno de los elementos que componen la figura.

3.1.2.2.1.1 Tipos de Servicios

En esta sección describiremos brevemente cada uno de los servicios principales, los cuales se pueden apreciar en la Figura 3.7.

- Discovery Service: este servicio permite la búsqueda de conjuntos

de datos espaciales y servicios. Algunos ejemplos son: Servicio de catálogos, directorio de datos espaciales, catálogos geográficos. El objetivo de este servicio es el de soportar el descubrimiento o búsqueda, evaluación y uso de datos y servicios espaciales a través de sus metadatos. Metadato es la información y documentación, que


- 45 -

hacen que estos recursos sean entendibles y que se puedan compartir entre los usuarios a través del tiempo.

- View Service: debe como mínimo garantizar las siguientes

operaciones; mostrar, navegar, zoom para acercar y alejar, movimiento del plano, superponer conjuntos de datos espaciales, mostrar información de leyenda e información relevante como metadatos.

- Download Service: debe permitir realizar copias de los conjuntos de

datos espaciales, o parte de ellos, para ser bajados y donde sea posible, accedidos directamente.

- Transformation Service: este servicio aún no se encuentra

totalmente definido. Aunque la idea principal acerca de este es que permita la transformación de datos espaciales.

- Invoke Spatial Service Services: permite la definición de los datos de

entrada y salida esperados por el servicio espacial y definir un flujo de trabajo o servicio que combina múltiples servicios. A su vez permite la definición de la interface de servicio Web externo de la cadena de flujo o servicio. Permite invocar servicios espaciales individuales así como la combinación de servicios espaciales individuales de forma asincrónica como sincrónica. Para aquellos servicios disponibles en Internet, este servicio, le permitirá a un cliente o aplicación cliente poder ejecutarlo sin la necesidad de contar con la disponibilidad de un SIG.


- 46 -

Figura 3.6. Arquitectura técnica de INSPIRE. [54]

Figura 3.7. Servicios principales de la infraestructura. [54]

3.1.2.2.1.2 Infraestructura de los servicios de red

En la Figura 3.8 se puede apreciar un esquema de cómo y cuáles son estos servicios dentro de la infraestructura.

Estos servicios son necesarios para compartir datos espaciales entre los

distintos niveles de autoridad pública en la Comunidad. Se establece que sea posible la interoperabilidad de estos servicios, sin necesidad de intervención manual. Estos servicios pueden ser vistos como un protocolo a ser utilizado para descubrir un bus de servicios geoespaciales en todo Europa:

- Los servicios de red exponen servicios para establecer comunicación

máquina-a-máquina. Debe haber al menos un flujo de trabajo que siga el patrón de diseño “publicar – encontrar – unir”. Sin embargo los


- 47 -

usuarios no necesariamente tienen que seguir este patrón de diseño, pueden invocar los servicios directamente.

- Distintos proveedores de servicios que contribuyen al proyecto

INSPIRE

- Aplicaciones INSPIRE solucionando tareas específicas a través del llamado a servicios INSPIRE.

- Un geo-portal INSPIRE a nivel de la Comunidad Económica Europea

y de los demás miembros ofreciendo funciones INSPIRE para distintos grupos de usuarios.

Todos los datos y metadatos existentes en INSPIRE son accedidos y

procesados a través de la utilización de servicios Web. Todos los servicios son descriptos por descripciones de servicios (metadatos) permitiendo de esta manera descubrir instancias específicas de determinados servicios tanto por computadoras como por humanos.

Aún no se encuentra definida cuál es la forma en que los mensajes

serán enviados, ya sea utilizando OGC Web Services (utilizando protocolos http/GET y http/POST) o bien utilizando SOAP/WDSL como protocolos propuestos y sugeridos por la World Wide Consortium.

Otra forma de ver la red de servicios INSPIRE es como un mediador

entre los servicios provistos por los estados miembros o por los ofrecidos por terceras partes y por ejemplo el geoportal. Aquí es donde se dice que el geoportal INSPIRE significa un sitio de Internet que provee acceso a los servicios de: Discover, Transform, View y Download Spatial Data, Invoke Spatial Data y ervicios de e-commerce.

Figura 3.8. Servicios de red de la infraestructura.

En la figura 3.9 se puede apreciar la visión del mediador en la arquitectura, es decir del geoportal.


- 48 -

Figura 3.9. Vista del mediador (geoportal). [54]

La arquitectura puede ser estructurada en múltiples capas que pueden

ser organizadas en forma de cascada. El caso más simple es la organización en cliente-servidor. En el caso de una organización en cascada los servicios INSPIRE pueden a su vez interactuar con otros servicios INSPIRE, incluso de otros proveedores.

La arquitectura de INSPIRE, así como la del geoportal, puede ser vista

como una arquitectura multicapa (como se muestra en la Figura 3.10), donde hay separación entre:

- Capa de usuario de INSPIRE (humano u otra aplicación) - Capa de servicio representando todos los servicios INSPIRE que

pueden ser accedidos por los estados miembro, por ej. el geoportal.

Figura 3.10. Arquitectura multicapa. [54]

En lo antes descrito para esta arquitectura INSPIRE, hemos visto también un énfasis especial en el hecho de compartir datos espaciales en toda


- 49 -

la Comunidad Económica Europea, pero con un espacio importante para los servicios, los cuales no se definen explícitamente (al menos hasta la fecha).

3.1.2.3 Proyecto Sistema de Información Geográfica Nacional de la República Argentina. (PROSIGA)

El proyecto Prosiga [8] es una iniciativa llevada a cabo por organismos

de la República Argentina que buscan conformar un nuevo mapa del país con información generada por productores oficiales, en formato digital, de acceso público y disponible a través de Internet. Este proyecto brinda la posibilidad de poner al alcance de la población un gran volumen de datos geográficos, que están en condiciones de ser actualizados rápidamente por los mismos organismos que lo generan. A su vez ofrece por ej: tener la última imagen satelital, o los datos estadísticos más recientes, conviviendo con la información de base, los datos de producción, infraestructura y toda aquella información que se desee incorporar.

Este proyecto se inició oficialmente con la firma de un Convenio de

Cooperación Interinstitucional entre la Secretaría de Energía de la Nación, el Gobierno de la Ciudad Autónoma de Buenos Aires (GCBA) [50], la Secretaría de Agricultura Ganadería Pesca y Alimentos [49] y el Instituto Geográfico Militar [48], el 13 de octubre de 2004; si bien los estudios de factibilidad comenzaron ocho meses antes como fruto de un Convenio Específico entre la Secretaría de Energía [47] y el Instituto Geográfico Militar [48].

Estos organismos y el GCBA trabajaron en forma coordinada,

distribuyéndose las responsabilidades, esfuerzos y dirección del proyecto en forma horizontal; conformando un grupo de trabajo homogéneo con objetivos claros, que lograron en el termino de un año implementar un mapa digital en Internet de acceso público y poner a disposición la documentación desarrollada para aquellos que la necesitaran (http://www.sig.gov.ar).

Fue factible la ejecución de este proyecto a partir de una excelente

integración técnica lograda entre los organismos participantes que comparten información y una base tecnológica común.

Actualmente doce organismos y municipios forman parte del proyecto,

ellos son: 1. La Secretaría de Energía de la Nación (SE). 2. El Gobierno de la Ciudad Autónoma de Buenos Aires (GCBA). 3. La Secretaría de Agricultura Ganadería Pesca y Alimentos (SGPyA). 4. El Instituto Geográfico Militar (IGM). 5. El partido de Malvinas Argentinas (Pcia. de Bs. As.). 6. El Instituto Nacional de Estadísticas y Censos (INDEC). 7. El Ente Nacional Regulador del Gas (ENARGAS). 8. El Partido de Luján (Pcia. de Bs. As.). 9. El Parido de Junín (Pcia. de Bs. As.). 10. El Municipio de Viedma (Pcia. de Río Negro).


- 50 -

11. La Universidad Provincial de la Punta (Pcia. de San Luis). 12. ETISIG (Equipo de Trabajo Interdisciplinario en sistema de

Información Geográfica de la Provincia del Chaco) El objetivo del proyecto es desarrollar, en forma conjunta, sobre la base

del Sistema de Información Geográfica (SIG) 250 del IGM, un SIG integrado con datos aportados por los organismos participantes para su consulta a través de Internet.

El propósito es lograr a través de acciones coordinadas el desarrollo y la

implementación de estándares comunes, disponibilidad de datos digitales y tecnologías interoperables como apoyo a las tomas de decisiones, a todas las escalas y para múltiples propósitos. Estas acciones abarcan políticas, competencias organizacionales, datos, tecnología, estándares y mecanismos de entrega para asegurar que todos aquellos que trabajan a escala global, regional o nacional no se vean impedidos de alcanzar sus objetivos

3.1.2.3.1 Base Tecnológica

La base tecnológica que se está empleando para la gestión de datos, se apoya en la tecnología SIG, que básicamente consiste en representar la información geográfica a través de gráficos con sus atributos almacenados en base de datos, relacionados con los mismos. Internet para la difusión de la información, servidores de mapas para depósito de datos y una interconexión segura de redes entre nodos, red privada virtual (VPN), teniendo también como alternativa la posibilidad de brindar un servicio de datos clasificados.

3.1.2.3.2 Ventajas del Proyecto

Entre las ventajas que brinda este proyecto, podemos mencionar el acceso remoto a la información a través de Internet, la disponibilidad de visualización simultánea de la información geoespacial por los que planifican y ejecutan diversos tipos de operaciones, la actualización simultánea desde distintos organismos de un gran volumen de datos, el acceso a información integrada de distintas escalas de captura, nacionales o regionales a catastrales, la exigencia a los organismos generadores de datos de trabajar bajo normas y estándares que aseguren la integración de los mismos y la posibilidad de evitar la superposición y duplicidad de esfuerzos.

3.1.2.3.3 Servicios disponibles

Actualmente, y desde el año 2008 se encuentran disponibles en el

proyecto los siguientes servicios: - Servicio de mapas en Web (WMS): El objetivo de este servicio es

posibilitar la visualización de Información Geográfica. Proporciona una representación, una imagen del mundo real para un área requerida; esta representación puede provenir de un archivo vectorial o raster, organizado en una o más capas, que pueden visualizarse, hacerse transparente y ocultarse una a una. Además, posibilita


- 51 -

consultar cierta información disponible y las características de la imagen del mapa, así como superponer visualmente y consultar datos vectoriales o raster, situados en distintos servidores.

- Nomenclador: Un nomenclador es un catálogo de entidades del

mundo real que contiene alguna información sobre su posición. La información sobre la localización, puede brindarse bajo la forma de coordenadas o mediante una descripción. Este servicio, posibilita localizar un fenómeno geográfico, asociado a un lugar con un determinado nombre. Se define como un servicio que admite como entrada, el nombre de una entidad, con las posibilidades habituales de nombre exacto; la devolución de la localización son las coordenadas del fenómeno en cuestión. Adicionalmente, la consulta por nombre permite fijar otros criterios como la extensión espacial en que se desea buscar o el tipo de fenómeno dentro de una lista disponible (río, montaña, población,…).

Dentro de los servicios que se implementarán a futuro se encuentran:

- Servicio de catálogo: Los servicios de catálogo, permiten publicar y

buscar información sobre los datos -Metadatos-, servicios, aplicaciones y en general de todo tipo de recursos. Los servicios de catálogo, son considerados como necesarios para brindar una mayor capacidad en la búsqueda de los recursos registrados dentro de una IDE.

- Servicio de Características en Web (WFS): Permite acceder y

consultar todos los atributos de una característica (fenómeno) geográfico como un río, una ciudad o un lago, representado en modo vectorial, con una geometría descripta por un conjunto de coordenadas. Habitualmente los datos proporcionados están en formato GML, pero cualquier otro formato vectorial puede ser válido.

- Servicio de Coberturas en Web (WCS): Es el servicio análogo a un

WFS para datos raster. Permite no solo visualizar información raster, como ofrece un WMS, sino además consultar el valor de los atributos almacenados en cada píxel.

- Descriptor de Estilo de Capas (SLD): Esta especificación, describe

un conjunto de reglas que permite al usuario definir estilos personalizados para la simbolización de las entidades geográficas, posibilitando elegir y editar la simbología de un WMS.

3.1.2.3.4 Estándares

Además de los servicios, el proyecto cuenta con una serie de especificaciones de estándares y normas a cumplir en cada uno de los atributos y metadatos que se encuentran cargados en el proyecto.


- 52 -

Estas normas tienen por objeto asegurar la integración espacial de los datos provenientes de distintas fuentes, la visualización adecuada a la presentación de los mismos (colores, grosores, tramas, etc.) así como una categorización que facilite al usuario la búsqueda y armado del mapa en la pantalla, en función de sus requerimientos.

Independientemente del cumplimiento de estas normas, la información

que aporten los organismos mantendrá la autoría intelectual de los mismos y estará residente en los servidores propios o eventualmente en los de otro organismo, según cada uno de ellos lo determine en función de sus necesidades técnicas o aspectos de interés particular.

Cada organismo será responsable de la actualización de la información

que aporte, ya que la misma depende de las disponibilidades, planes de trabajo, desarrollo de proyectos y /o actividades propias de la institución que genera la información.

Los datos a integrar, deberán responder indefectiblemente a las normas

técnicas desarrolladas a tal efecto. Dentro de la documentación del proyecto existen definiciones acerca de

la estructura de representación de datos Geoespaciales, donde se indica el tipo, forma y demás atributos de cada elemento que se representará en el plano [51].

3.2 Framework propuesto Hasta este momento se ha planteado el estado del arte actual respecto

de infraestructuras SIG, así como también una descripción de los estándares internacionales establecidos por el OGC en materia de mapas en la Web y la manera en que se debe intercambiar información geográfica (datos y metadatos), mediante la utilización de la tecnología de Servicios Web.

Se desprende del análisis de las infraestructuras presentadas que en

todas ellas se hace un fuerte hincapié en compartir datos e información geográfica y de mantener una base común, única, estandarizada de los mismos. También en los distintos proyectos se puede detectar que existe la voluntad de brindar servicios Web, pero aún no se encuentran especificados los mismos ni tampoco existe una lista de servicios básicos como los que se presentan en este trabajo de tesis. Sí se establece en cada proyecto las bases de cómo se estructuran estas capas de servicios, sus arquitecturas y los estándares a los cuales se deben ajustar.

Se evidencia entonces que existe un espacio no definido ni abordado

respecto de un framework de servicios Web de SIG que permita la generación automatizada de sistemas de información geográfica. El objetivo del presente trabajo es el de construir, a través de la utilización de especificaciones formales, una infraestructura abierta y estándar de servicios Web, de forma tal


- 53 -

que se pueda abordar la construcción de sistemas de información geográfica a partir de modelos probados y de utilización directa.

Como solución al objetivo propuesto, se brindará a continuación una

descripción de los servicios Web de SIG, que en los capítulos siguientes se especificarán formalmente. Antes de ello se hará una breve introducción a la problemática que intenta abordar esta lista de servicios del framework aquí presentado.

3.2.1 Introducción

La información geográfica es necesaria para tomar decisiones acertadas a escala local, regional y global. La gestión de los recursos naturales, el desarrollo de obras de infraestructura, la planificación urbana, la reducción de daños por inundaciones, la recuperación medioambiental, las valoraciones de terrenos de uso comunitario y la recuperación después de desastres, son sólo algunos ejemplos de las áreas en las que los encargados de tomar decisiones oportunas pueden beneficiarse con esta información.

Para la toma de decisiones hay una clara necesidad, en todos los

niveles, de poder acceder, integrar y usar los datos espaciales provenientes de diversas fuentes. Así pues, nuestra capacidad para tomar decisiones colectivas acertadas local, regional y globalmente, depende de la puesta en práctica de la Infraestructura de Datos Geográficos que proporcione compatibilidad a través de jurisdicciones, promoviendo el acceso y la utilización de los datos.

Conocer adecuadamente la superficie del terreno donde se va a

desarrollar una obra de infraestructura, una urbanización, un emprendimiento agropecuario, una operación militar o de ayuda humanitaria, significa que tenemos que planificar con un grado de certeza que nos posicione en excelentes condiciones para cumplir con el objetivo buscado. Estamos ante una gran oportunidad para: ampliar la actividad económica, mejorar la prestación de servicios, la formulación de planes y la ejecución de proyectos de desarrollo, así como la calidad de las decisiones.

En nuestros días generar y describir datos geográficos y permitir el

acceso a ellos para usarlos en análisis temáticos y planificación, es una responsabilidad ineludible para dar soporte técnico a la sociedad reconociendo que la información geográfica es vital para la toma de decisiones acertadas.

Los servicios incorporados en esta versión del framework han sido

seleccionados a partir de las definiciones estándares del OGC, de los distintos proyectos vistos y analizados anteriormente y en base a un estudio de las aplicaciones que se llevan adelante con los sistemas de información geográfica, junto a la experiencia en desarrollo de sistemas de este estilo a nivel profesional. En base a estos antecedentes se identificaron las funcionalidades más importantes y que pueden ser la base para construcciones más complejas o para la realización de análisis como los planteados anteriormente. Esta lista de servicios propuesta puede ser ampliada para situaciones específicas en la utilización de herramientas SIG.


- 54 -

3.2.2 Definición de los servicios

De acuerdo a la introducción de los problemas que se pueden resolver con un SIG, como se describió en las secciones 3.2 y 2.6 (Aplicaciones de los Sistemas de Información Geográfica) es que se plantean a continuación los servicios básicos que debe tener una infraestructura como la que se plantea en este trabajo, con una breve descripción de los mismos. A partir de estos servicios básicos se pueden construir luego otros servicios y desarrollar aplicaciones Web de servicios SIG.

Antes de comenzar a describir los servicios, vamos a nombrar los tipos

de datos abstractos (ADT) utilizados luego en cada uno de los servicios. Estos tipos de datos fueron tomados principalmente de la definición del OGC Location Services (OpenLS) Implementation Specification, presentados en la sección 3.1.1.1. La lista de ADTs es la siguiente:

- ADT_ADDRESS - ADT_POI - ADT_AOI A continuación se mencionan junto a una breve descripción los servicios

básicos del framework que luego en el capítulo 5 serán desarrollados formalmente.

- Geocode: Este servicio intenta a través de una dirección dada (calle

y altura, código postal, lugar, etc.) y un mapa con una zona determinada, encontrar un punto x,y (longitud, latitud) en el plano. Para ello se tiene que valer de llamadas a funciones específicas del software SIG de base que se esté utilizando. La idea es poder ubicar en el plano puntos a partir de su dirección. Como resultado retorna un conjunto de direcciones normalizadas junto al punto que le corresponde en el plano de acuerdo a la dirección dada. En el caso de que no se pueda geocodificar una dirección se devuelve un punto vacío o nulo. A cada resultado se le asocia un nivel de precisión de la geocodificación. Este servicio es fundamentalmente útil en cualquier área de aplicación de los sistemas de información geográfica, ya que normalmente en las bases de datos existentes en las organizaciones se encuentran los datos normalizados de las direcciones de los clientes o suscriptores. A su vez, cualquier dispositivo móvil que necesite de algún servicio, salvo aquellos dispositivos que cuentan con un módulo de posicionamiento global, puede brindar su ubicación a través del lugar donde se encuentra.

- Reverse geocode: este servicio realiza el trabajo inverso al anterior.

Dada una lista o conjunto de puntos en el plano, ya geocodificados, deberá devolver para cada uno de ellos la dirección normalizada. Este es un servicio que es particularmente importante para los dispositivos que cuentan con una unidad de posicionamiento global,


- 55 -

pudiendo de esta forma saber inmediatamente el lugar donde se encuentra. A su vez este servicio de reverse geocode puede ser utilizado por otros servicios como base para la consulta que deseen realizar.

- Directory: el servicio permite a los usuarios acceso a un directorio en

línea para encontrar el servicio, o producto más cercano o un lugar específico. Como ejemplos del uso de este servicio se presentan los siguientes casos de uso:

o ¿Dónde se encuentra el restaurante chino “Dragón Rojo”?. o ¿Dónde se encuentran los restaurantes chinos en una

determinada ciudad?.

o ¿Cuál es el restaurante chino más cerca al hotel donde me encuentro alojado?.

o ¿Cuáles son los restaurantes chinos que se encuentran a

500 metros de mi hotel?.

Este servicio también puede resultar de importancia para los estudios de marketing, ya que al tener el registro de estas peticiones se pueden realizar análisis estadísticos y de pedidos.

- Route: el servicio de ruteo determina la ruta que debe realizar un

solicitante. El usuario indica el punto de inicio y el de fin, puntos intermedios (si existieran), el plan de ruta deseado (la ruta más rápida, la más corta, etc.) y el medio de transporte (a pie, vehículo, etc.); el servicio entonces determina la ruta de acuerdo a los parámetros dados. Este servicio es considerado de suma utilidad para una vasta cantidad de soluciones informáticas a problemas de investigación operativa, los cuales son aplicados a un número muy importante de problemas, entre los cuales se pueden mencionar:

o Encontrar el mejor camino para que una ambulancia llegue a rescatar los accidentados en un siniestro en una gran ciudad.

o Encontrar el camino más óptimo para la entrega de

mercaderías.

o Encontrar el camino indicado para poder llegar de la forma más rápida a una determinada ciudad .

- Buffer: a partir de un punto determinado, el cual no necesariamente

tiene que ser un punto geocodificado (lo resuelve este servicio), se generan una serie de círculos o circunferencias a determinada distancia del punto dado.


- 56 -

La utilización de esta funcionalidad permite entre otras cosas obtener por ej: radios de alcance y peligrosidad de catástrofes naturales, zonas de influencias de una determinada patrulla policial, áreas de cobertura de antenas para telefonías celulares, zonas de congestionamientos urbanos, etc.

- Higway states: determina el estado de las distintas rutas a nivel de

congestionamiento, devolviendo como resultado una lista de rutas con diversos colores y tamaños, información temática, donde cada color y tamaño representa distintos niveles de congestionamiento, de forma gradual. Este servicio fue adicionado al framework como una manera de visualizar qué cosas además de las básicas pueden ser incorporadas para el mejoramiento del mismo.

- Get Map: este servicio es el que devuelve ante una petición una

imagen de una zona determinada del plano con que se está trabajando en un momento dado. Este servicio, por simple que parezca es la base para todas las operaciones de movimiento del plano (zoom para acercar y alejar, paneos, extensiones, etc.). Sin este servicio sería imposible poder brindar los otros servicios descriptos anteriormente.

Adicionalmente a estos servicios, y como base para los mismos, se

cuenta con una serie de funcionalidades y servicios privados, que no son de acceso público. Estas funcionalidades básicas no son planteadas ni descriptas en el presente trabajo ya que las mismas no se consideran de importancia ni relevantes para la finalidad del framework.

Todo lo expuesto en el trabajo realizado se encuentra pensado para

interactuar sobre un portal Web de SIG que se base sobre estándares del OGC y del World Wide Web Consortium [52]. Es por ello que en la definición de los servicios no se encuentra mención ni implementación de ningún tipo, de todos aquellos protocolos y servicios estándares necesarios para poder cumplir con la problemática de mapas en la Web.

En la Figura 3.11 se muestra la forma en que los servicios expuestos anteriormente interactúan en un ambiente de servicios Web.


- 57 -

Portal de servicios Web de SIG (geoportal)

Acceso al framework

Servicios disponibles

Figura 3.11. Arquitectura del framework.

- Geocode

- Reverse geocode

- Directory

- Route

- Buffer

- GetMap

- Highways state

- …..

Método de Desarrollo RAISE

- 58 -

4. MÉTODO DE DESARROLLO RAISE

RAISE (Rigorous Approach to Industrial Software Engineering) fue desarrollado durante los años 1985 a 1990 en un proyecto colaborativo de Europa, el programa ESPIRIT-I. Un segundo proyecto, LaCoS (Large - scale Correct Systems using Formal Methods), fue el que dio lugar a la tecnología RAISE, particularmente los métodos y herramientas, y a su vez este proyecto testeó a este en el desarrollo de una gran cantidad de proyectos.

El Lenguaje de Especificación RAISE (RSL) es un lenguaje de

especificaciones formales; es decir un lenguaje con bases matemáticas formales para soportar la definición precisa de los requerimientos de software y un desarrollo confiable de esos requerimientos, que los transforme en una implementación final exitosa.

RSL es un lenguaje de amplio espectro ya que el mismo puede ser

utilizado tanto para formular especificaciones iniciales y muy abstractas como para expresar cuestiones de diseño de muy bajo nivel, convirtiendo dichas especificaciones a un lenguaje de programación determinado. El método abarca:

• Formulación de especificaciones abstractas.

• Desarrollo de estas especificaciones en especificaciones más concretas.

• Justificación de la correctitud del desarrollo.

• Traducción de las especificaciones finales a un lenguaje de programación específico.

El método RAISE está pensado para ser utilizado en desarrollos reales,

no solamente para ejemplos. Las características principales de RAISE se basan en 4 principios

básicos:

• Desarrollo separado.

• Desarrollo gradual o incremental.

• Inventar y verificar.

• Rigurosidad. En las secciones siguientes se irán desarrollando cada una de estas

características.

4.1 Desarrollo separado Es claro que, si se desarrollaran sistemas de cualquier tamaño, de lo

que se debe ser capaz es de descomponer su descripción en componentes y componer el sistema desde los componentes desarrollados. Esto es válido tanto para cuando la descripción es una especificación como cuando la descripción es un programa.


- 59 -

Es también claro que, para la mayoría de los sistemas es necesario tener gente (o equipos de gente) trabajando en diferentes componentes al mismo tiempo. Habrá entonces entidades (archivos, documentos, etc.) que estarán siendo compartidas. Esto genera básicamente dos dificultades:

1. Debe quedar claro quién es el responsable de actualizar esas

entidades compartidas, y cuál es el estado de cada versión en cada momento. Esto es un problema de control de configuraciones estándar y no específicamente de los métodos formales.

2. No debe haber ambigüedad alguna acerca de qué significan esas

entidades compartidas, y esto causa más problemas (o la integración de los sistemas debería ser más simple!). El problema típico es que una persona escribe una función que otro necesita utilizar. Es bastante sencillo compartir la información acerca del nombre de la función, qué parámetros tiene y qué tipo de resultado debería tener. Pero no es tan obvio o sencillo ser exacto acerca de la semántica de la función, particularmente qué hace bajo diferentes condiciones externas y cómo puede afectar a otras componentes o partes del sistema.

Entonces surge la pregunta: ¿qué pueden hacer los usuarios para

asumir esto?. Si se considera además el desarrollo de componentes compartidas aparece un problema adicional: ¿qué puede hacer el desarrollador para que esto no afecte a los usuarios?.

Lo que se necesita entonces es claro, declaraciones no ambiguas que

actúen como un acuerdo o contrato entre el desarrollador y los usuarios. Al desarrollador un contrato le dice qué debe proveer; a los usuarios les informa qué cosas deben asumir.

Si durante el desarrollo los usuarios descubren que necesitan más

prestaciones, o diferentes, se necesita renegociar el contrato, o bien desarrollar sus componentes libremente.

Si un desarrollador descubre durante el desarrollo que solamente puede

suministrar menores prestaciones, o diferentes, también necesita renegociar el contrato, o puede desarrollar libremente mientras se conserve las prestaciones contratadas.

Esto además significa que se debe saber quiénes son los usuarios y los

desarrolladores, para poder saber quiénes estarán involucrados en la renegociación.

La especificación de un módulo (o un grupo de ellos) puede actuar como

este contrato. Una especificación dice de forma precisa cuáles son las prestaciones esenciales de lo que se está especificando. En este caso es mucho mejor que algo escrito en un lenguaje de programación, ya que puede establecer qué es lo esencial o importante e ignorar lo que no lo es. Una


- 60 -

especificación permite precisión controlable; puede ser tan precisa o imprecisa como el especificador y usuario requieran. Imprecisión no es lo mismo que ambigüedad o falta de claridad. Nuestra lógica nos permite abordar algunas conclusiones para una especificación y no para otras, por lo tanto una especificación (implícitamente) establece qué es lo esencial y qué es lo irrelevante.

Un programa que representa un contrato evita el problema de la

vaguedad en una descripción informal, pero su incapacidad para ignorar lo irrelevante presenta otro problema. Un programa es completo en el sentido que contiene toda la información para permitirle su ejecución. Por lo tanto, es preciso acerca de lo que hace, y entonces un desarrollo de ello causará que sus prestaciones existentes cambien. De ahí que el desarrollo se tiene poco en cuenta como un contrato.

De allí que surge la siguiente pregunta: ¿cuál es el rol de un contrato en

el desarrollo? En la Figura 4.1 se puede apreciar cómo trabaja el desarrollo separado

en un simple caso de desarrollo de un módulo A que es utilizado en otro módulo B. La versión inicial de A y B son A0 y B0, y estos son desarrollados en los pasos n y m a Bn y Am respectivamente. El modulo A0 actúa como el contrato entre los dos desarrollos; nótese que la referencia en B hacia A es A0 en cada estado a excepción del último en los desarrollos B. Cuando el desarrollo se encuentra completo los integramos utilizando Am en lugar de A0 en Bn, para formar Bn+1.

Lo que se quiere en el sistema final (Am y Bn+1) es integrar los

requerimientos originales. Un conjunto de condiciones suficientes para esto es:

• Los módulos iniciales (A0 y B0) juntos reúnen los requerimientos, es decir que tienen todas las características requeridas.

• Cada paso del desarrollo de A y B es un paso de implementación, lo que significa que cada módulo implementa el inmediatamente precedente.

Desarrollo de A Desarrollo de B

Integración

A0 = ..... B0 = ...... A0 .....

Am = .....

Bn = ...... A0 .....

Bn+1 = .... Am ....


- 61 -

Figura 4.1: Desarrollo separado

Es útil además, asegurarse que cada Bi (0 ≤ i ≤ n) es una extensión conservativa de A0.

La figura que se presentó del desarrollo separado es obviamente ideal.

En la práctica raramente se siga exactamente como está dibujada. A continuación se muestran algunas variantes:

• No todos los requerimientos son cumplidos.

• Los contratos pueden necesitar cambios.

• Algunos pasos del desarrollo podrían no ser implementados. A continuación se abordarán cada uno de estos puntos más en detalle.

4.1.1 Requerimientos sin cumplir Las especificaciones iniciales no podrán cumplir todos los

requerimientos. Esto puede ocurrir por dos razones fundamentalmente:

1. Algunos requerimientos no pueden ser capturado en RSL, debido a que estos están fuera del alcance del lenguaje. Algunos ejemplos de este tipo de requerimientos pueden ser: el sistema debe ejecutarse en un hardware determinado bajo un sistema operativo X, codificado en el lenguaje A, o bien otros más complejos como restricciones de tiempo, etc. En resumen, son los requerimientos denominados: requerimientos no funcionales.

2. Algunos requerimientos conscientemente deben ser aplazados

para cuando el desarrollo esté más avanzado, debido a que la inclusión de ellos en el comienzo haría las especificaciones iniciales muy complejas.

En cualquiera de los dos casos habrá que registrar las necesidades aún

no cubiertas o insatisfechas y asegurarse de que se tratarán más adelante en el desarrollo. A su vez, también en ambos casos, se tendrá que estar bastante seguro de que se podrán resolver los requerimientos, sino se deberá rehacer el desarrollo.

4.1.2 Requerimientos cambiantes

Eventualmente se podrían necesitar cambios en un contrato (como en el caso A0) durante el desarrollo.

Esto puede ser causado porque los desarrolladores de B necesitan

propiedades adicionales o diferentes de aquellas que fueron originalmente contratadas. Puede ser también que los desarrolladores de A encuentren imposible, o demasiado costoso (ya sea a nivel de tiempo de desarrollo o en


- 62 -

términos de eficiencia de la implementación final) proveer lo que fue contratado originalmente. En cualquiera de los dos casos el contrato debe ser renegociado.

Volviendo al ejemplo de la sección 4.1, supongamos que en un punto

determinado del desarrollo de A, Ai es desarrollado pero no es una implementación de sus predecesores. Los desarrolladores de B tienen que desarrollar Bj usando Ai y el desarrollo continúa desde este punto. Este cambio en el contrato se puede apreciar en la figura 4.2.

Renegociación

Integración

Figura 4.2: Desarrollo separado con renegociación de contrato

4.1.3 Pasos sin implementación

En algunos casos es necesario realizar un paso sin implementación

durante el desarrollo. Esto se debe, principalmente, a que el diseño que se quiere elegir solamente trabaja en un caso más restringido que el que se había pensado, por lo que se quiere ir a las especificaciones iniciales y cambiar las propiedades. En teoría es simple, ir al comienzo, cambiar los requerimientos y rehacer el desarrollo. El problema es que esto puede provocar mucho trabajo de pequeños cambios (sobre todo si ya se han realizado pruebas). Por lo tanto, ¿hay recortes pequeños para situaciones donde se sabe con cierta certeza de que el cambio es menor?

A0 = ..... B0 = ...... A0 .....

Ai-1 = .....

Bj-1 = ...... A0 .....

Bn = .... Ai ....

Ai = .....

Am = .....

Bj = ...... Ai .....

Bn+1 = .... Am ....


- 63 -

Lo primero que se puede decir es que cualquier cambio por pequeño que sea es peligroso, y sólo debería realizarse con mucho cuidado. Se pueden examinar entonces algunas posibilidades:

• Si el cambio ocurre en el desarrollo de A puede todavía ser el caso que el cambio que se desea realizar es una implementación del contrato. Si se puede establecer esto no hay problemas.

• Si el cambio ocurre en el desarrollo de B entonces, nuevamente, podría ser el caso de estar implementando B0 (o Bj después de cambiado el contrato), y no habría ningún tipo de problema. Pero a menudo este no es el caso. Si a nivel de sistema no hay otros desarrollos dependientes, se puede aceptar el cambio a este nivel sin tener que rehacer los trabajos previos. Lo que se debería hacer es documentar formalmente cuál es la relación y también documentar formalmente qué cambios efectivos hay respecto de los requerimientos. Si la especificación original cumple los requerimientos y se están cambiando las propiedades entonces, potencialmente, se están satisfaciendo los requerimientos cambiados.

4.2 Desarrollo gradual o incremental

En la discusión acerca del desarrollo separado se asumió que existen varios pasos en el desarrollo de A y B. Es importante destacar que esto es posible, que se puede desarrollar software en una secuencia de pasos. Se puede entonces comenzar con una abstracción bastante adecuada, decidir cuáles son las cuestiones de diseño que se necesitan hacer y qué dependencias existen entre ellas así como también hacer un plan para establecer el orden en el cual se atacarán. Las decisiones típicas de diseño involucran:

• Proveer definiciones explícitas para los valores habiendo sido dados previamente sólo las definiciones implícitas o axiomas.

• Proveer definiciones explícitas para variables y canales previamente referenciados sólo por any.

• Brindar definiciones concretas para tipos abstractos.

• Cambiar las definiciones de tipos para permitir mayor detalle o potencialmente más eficiencia a las funciones (ej: listas para conjuntos).

• Agregar nuevas definiciones o axiomas.

• Agregar variables de estado, ya sean locales o globales para reemplazar parámetros.

• Cambiar el estilo de la especificación entre aplicativa e imperativa o entre secuencial o concurrente.

• Agregar parámetros o canales extras para expresar más funcionalidad.

• Hacer las cosas más reutilizables, como agregar parámetros a esquemas o ampliar los tipos de los parámetros en las funciones.


- 64 -

• Remover construcciones dificultosas para convertirlas en el lenguaje destino seleccionado.

Tratar con una o más de estas decisiones significa que se está haciendo

un desarrollo por pasos, que se producen nuevas especificaciones en las cuales se puede verificar que sean conforme a lo realizado previamente. Es importante ser capaz de hacer solamente una, o al menos solamente unas pocas decisiones de diseño en cada paso del desarrollo, para poder atacar de a un problema a la vez.

Resolviendo cuáles son las decisiones principales también brinda un

plan global de actividades para el desarrollo. Por ejemplo, para un sistema de ascensores el plan de nivel superior es aproximadamente como sigue:

• Formular una especificación abstracta concentrándose en producir funciones y axiomas adecuados que puedan ser validados contra los requerimientos.

• Desarrollar una especificación concreta diseñando de forma adecuada un tipo de estado global y definiciones de las funciones, para que las definiciones puedan ser chequeadas en la implementación de axiomas.

• Descomponer el estado global en componentes de estado separados para el motor, puertas y botones.

• Introducir concurrencia reflejando los distintos procesos. Notar que los problemas que están siendo abordados aquí son, en

orden:

• Reunir los requerimientos principales.

• Diseñar un tipo de estado global adecuado.

• Descomponer el estado.

• Introducir concurrencia. Por supuesto que hay cierta interacción entre el proceso de diseño y los

problemas a ser resueltos. Eligiendo diferentes problemas primero darían lugar a diferentes presentaciones de los problemas. Pero decidir sobre esta clase de plan de nivel superior es un paso crítico en el comienzo de un desarrollo.

El número de pasos de desarrollo desde una especificación inicial puede

variar, pero la experiencia indica que típicamente son uno o dos. Los componentes principales tenderán a tener más pasos que sub-componentes.

4.3 Inventar y verificar

Hay técnicas de desarrollo que confían en la transformación, como las

desarrolladas por el proyecto CIP en Munich [42]. Con dicha técnica el desarrollador comienza con una expresión y aplica una regla de transformación que crea expresiones diferentes pero equivalentes. De esta forma el desarrollador se garantiza a priori que la nueva expresión es equivalente a la


- 65 -

anterior porque las reglas de transformación son conocidas para preservar la equivalencia.

En verdad, utilizando la justificación RAISE es un ejemplo de una técnica

de transformación, pero aplicada a expresiones lógicas en vez de aplicado a programas. Cualquier aplicación formal de reglas de prueba correctas produce un argumento, el cual no es necesario de probarlo más adelante.

Por otro lado, “inventar y verificar”, es un estilo que permite a los

desarrolladores inventar un nuevo diseño. Después, el desarrollador verifica su correctitud.

La ruta transformacional suena sencilla, porque hay solamente un paso y

la correctitud está asegurada. Las ventajas son:

• Los sistemas transformacionales son demasiado extensos para lenguajes de tamaño razonable. El editor de justificación de RSL tiene aproximadamente 2000 reglas. Esto es solamente un pequeño sistema diseñado con un propósito muy particular de hacer justificaciones: muchas de las reglas son equivalencias. El diseño de un sistema transformacional podría ser considerablemente más extenso porque tendría un propósito más general y porque no debería ser restringido a equivalencias. Equivalencias deberían ser útiles para algoritmos pero no para tipos de datos donde, por ejemplo, a menudo se introduce redundancia. Por lo tanto el sistema sería extremadamente extenso con dificultades, primero en popularidad y luego en encontrar reglas aceptables.

Se puede argumentar que un sistema extensible permitiría

el agregado de reglas como sea necesario. Pero luego se debe volver a inventar y verificar. Una vez inventadas las reglas necesarias, se verifican en su correctitud y luego se aplican. La regla está disponible para ser aplicada en el futuro, pero solamente si se ha tomado la precaución de generalizarlo convenientemente cuando se inventó.

• En la práctica, las reglas transformacionales solamente son aplicables en circunstancias particulares; mostrando que aquellas circunstancias generan “efectos colaterales” que necesitan ser probadas. Por lo tanto la parte “y verificar” tiende a estar de todos modos.

• Es fácil el enfoque inventar y verificar para inventar varios pasos, tal vez cambiando varias veces el pensamiento, previamente decidiendo sobre el enfoque correcto y realizando las verificaciones. Con las transformaciones el enfoque tiende a ser más formal que al comienzo.


- 66 -

• En la práctica, como cuando se presentó el desarrollo separado, algunos pasos del desarrollo no serán implementados y podrían, en cambio, tener poca relación formal con el nivel anterior. No obstante se puede todavía desear preservar el nivel anterior como una guía de cómo se ha alcanzado el nuevo diseño. Por lo tanto se necesita hacer pasos “incorrectos”, los cuales corren el contador a un enfoque “garantizado correcto”. Puede haber todavía oportunidades para verificación tan bien como invención en este caso cuando se hace un postulado a una relación formal.

Se notará que en principio estas no son objeciones al enfoque

transformacional. En verdad, todos estos comentarios podrían ser realizados en contra de hacer justificaciones seleccionando reglas y usándolas: una técnica utilizable debe permitir que se definan y utilicen lemas (las “nuevas reglas”), que se generan condiciones colaterales, que la justificación de las condiciones sean diferidas e inclusive que las metas cambien a mitad de camino vía pasos informales. Por lo tanto, en parte es un producto de ingeniería, y a juicio de los diseñadores del método RAISE los sistemas transformacionales no son todavía suficientemente poderosos para realizar todo el desarrollo transformacional para un lenguaje como RSL.

4.4 Rigurosidad

El desarrollo es dificultoso, pero las pruebas lo son aún más. Es poco práctico demostrar todo, dado el estado actual de los demostradores de teoremas. Y, si aún se pudiera, con poco esfuerzo, demostrar que cada cosa es verdad, no queda claro que esta habilidad fuera suficiente. A menudo se aprende mucho de las fallas de una demostración, pero se aprende más de los detalles precisos de la falla. No es suficiente solamente ser capaz de hacer pruebas, se debe ser capaz de explorar las propiedades de las especificaciones.

Otro problema es que hay demasiados casos de prueba posibles para

ejecutar en tiempo real. Por lo tanto hay muchas propiedades posibles.

• Como con el testeo, hay que mirar los casos “interesantes”, como es el caso de los extremos o casos límite. Luego es necesario realizar las pruebas para los casos sospechados.

• Existe otra analogía con el testeo. Si se necesita repetir muchos de los testeos “obvios”, la eficiencia en la detección de problemas caería ya que el proceso completo se volvería muy tedioso.

Siempre se debería preguntar cuál es la actividad más efectiva para

ayudar a lograr los objetivos propuestos. Tanto en la demostración como en el testeo, usando programas apropiados (tácticas de pruebas programadas, arneses de testeo, y algunos otros) se reduce la intervención humana y lo tedioso de la tarea.


- 67 -

Existe un riesgo al seleccionar los casos de prueba, se pierden errores debido a que es “obvio” que ellos no estén. Nuevamente, esto es como la selección de casos de testeo, donde es también peligroso pero necesario seleccionar un conjunto de casos relevantes. Como con el testeo, se utilizan guías en la selección de los casos de testeo y revisión por otros para ayudar a evitar tales problemas.

Por lo tanto resulta necesario seleccionar las propiedades candidatas de

una investigación profunda, y demostrar formalmente aquellas de las cuales se sospecha. Pero cuando se investigan algunas propiedades (en parte) informalmente, se debería también registrar el argumento de por qué se piensa que es verdadero como parte normal de documentación (algo que es revisado ahora y referenciado nuevamente más tarde). Esta argumentaci{on que puede ser total o parcialmente informal es llamada justificación. Los argumentos que contienen pasos informales son denominados rigurosos. Una justificación que es completamente formal es una prueba.

Se debe notar además que aquí se está avocando a lo riguroso y no

tanto a los argumentos totalmente formales, aún así se necesitaría más bases formales del método. Esto es crítico, si alguien más contradice la correctitud de una parte informal de una justificación, que se pueda formalizarla y responder la refutación terminantemente. 4.5 El rol de RAISE en la Ingeniería de Software

Un método es un medio para lograr algo, y en el contexto en que se está

estudiando, el algo es el desarrollo de un sistema de software. Por sistema de software se entiende:

• Un programa, o una colección de programas conectados entre sí, escritos en algún lenguaje de máquina. Un lenguaje ejecutable o de máquina es uno en el cual los programas pueden correr en un hardware apropiado, generalmente luego de un proceso de compilación.

• Documentación asociada que abarca cómo mantener y utilizar los programas.

Nótese que se ha incluido la documentación tanto como a los

programas. Luego se verá que los métodos formales tienen mucho que ver en la producción de software, y mucho que hacer con la producción de la documentación que da soporte al mantenimiento y poco para hacer con la producción de la documentación que soporta el uso.

Un método consiste esencialmente en procedimientos a ser seguidos y

técnicas que facilitan los procedimientos1.

1 Las herramientas son comúnmente consideradas como parte de un método, esto es así porque un

método sería inutilizable sin ellas. Estamos convencidos que las herramientas son esenciales para el

práctico uso de RAISE.


- 68 -

Procedimientos o actividades son usualmente descriptas en varias capas. En la parte más alta están las actividades mayores que, colectivamente se dice que forman el ciclo de vida del software. Típicamente consisten de actividades como la captura y análisis de requisitos, diseño arquitectural, diseño detallado, codificación, testeos de unidad, integración, testeos de aceptación y mantenimiento. Dentro de estas actividades más importantes existen actividades componentes como producir un tipo particular de documentación (plan de actividades, diseño arquitectural, diseño modular, códigos de módulos, plan de testeo, casos de testeo, etc.), seguir un plan de aseguramiento de la calidad, cambiar un documento existente, etc.

Junto con estos procedimientos se identifican varias clases de

actividades que poseen técnicas particulares a ser utilizadas. Existen técnicas para el análisis de requerimientos, para el diseño, para realizar revisiones, para la generación de casos de testeo, para analizar cobertura de testeos, etc.

El método RAISE comprende técnicas para los siguientes cuatro

procedimientos:

1. Especificación. 2. Desarrollo. 3. Justificación. 4. Traducción.

Las técnicas tienen que estar relacionadas con los procedimientos que

las requieren. Los proveedores y compradores de software particulares generalmente tienen su propia noción de qué método tiene que ser utilizado, generalmente embebido en sus estándares de calidad. Dichos estándares describirán en detalle qué significa, para ellos, procedimientos como “especificación de testeo”, por ejemplo. Tales estándares recetan los procedimientos componentes, sus entradas y sus salidas, qué técnicas (y hasta incluso las herramientas) son aceptables u obligatorias, qué procedimientos de aseguramiento de calidad serán aplicados, etc. El uso de métodos formales afectará a algunos de estos más que a otros. Es poco probable, por ejemplo, cambiar sustancialmente el orden en el cual las cosas se hacen, pero cambiará la proporción de tiempo utilizado en algunas actividades comparadas con otras. Algunas técnicas (como la preparación de la documentación textual) serán afectadas poco o nada, algunas otras (como la generación de los casos de testeo) pueden cambiar debido a que sus entradas son diferentes y tal vez disponibles tempranamente, pero serán esencialmente sin cambios, mientras que algunas otras (como el diseño) serán radicalmente diferentes. El método RAISE no pretende reemplazar absolutamente todo, sino que se pretende mostrar cómo este método afectará a los métodos típicos que ya se encuentran en uso. Es necesario entonces describir al menos algunas características de un método típico, para explicar cómo se utilizan algunos términos.

Se utilizarán los siguientes términos que describen los procedimientos

de más alto nivel, los cuales son los más afectados cuando se utiliza el método RAISE:


- 69 -

• Especificación comienza con la identificación de requerimientos, escrita normalmente en un lenguaje natural (español por ejemplo), y produce una descripción en RSL. Para todos los sistemas, inclusive para los más simples, esto será organizado en un número de módulos. La especificación definirá el comportamiento del sistema en suficiente detalle para reunir todos los requerimientos que contemplan la mayor funcionalidad. Este procedimiento cubre lo que normalmente se describe como análisis de requerimientos.

La salida principal de este procedimiento será llamada la especificación inicial. Esto se denomina así porque es lo primero que se escribe, puede haber varias versiones de intento antes que una sea seleccionada, inclusive es una técnica común producir versiones más concretas para ganar confianza en la más abstracta. Se denomina la primera especificación porque es la base para las especificaciones más detalladas producidas durante el desarrollo. Idealmente la especificación inicial será libre de “detalles de implementación”. Algunas veces esto es conocido como que la especificación inicial debería definir el qué del sistema y no el cómo se debe hacer. Por lo tanto, idealmente, no debería reflejar ninguna decisión del diseño arquitectural. En la práctica puede haber algunas variantes de esto. Los sistemas extensos con muchos requerimientos serán difíciles de describir en un único módulo, y en cambio podrían necesitar ser modulares, porque utilizando la modularidad es como se puede atacar la complejidad. Mientras que es teóricamente posible utilizar la composición como la descomposición para cambiar la estructura modular durante el desarrollo, es poco probable en la práctica, y menos aún con un desarrollo separado. Por lo tanto las especificaciones iniciales contienen a menudo algunos diseños arquitecturales.

• Desarrollo comienza con la especificación inicial y produce una nueva y más detallada especificación en RSL que se ajusta a las originales y que se encuentra lista para ser traducida a la especificación final. Este procedimiento es a menudo denominado diseño detallado.

• Traducción comienza con la especificación final de RSL y

produce un programa o colección de programas en algún lenguaje ejecutable. Este procedimiento normalmente se conoce con el nombre de codificación.

Obsérvese que estos procedimientos pueden ser aplicados tanto a

mantenimiento como a un desarrollo original.


- 70 -

4.5.1 Validación y verificación

Hay dos facetas para mostrar la correctitud que comúnmente se destacan, la validación y la verificación:

• Validación es lo que permite comprobar que estamos creando lo que se requiere. Puede ser expresado como la comprobación que nos dice que estamos resolviendo el problema en la forma correcta. Debido a que este chequeo se realiza contra los requerimientos escritos en un lenguaje natural, necesariamente este chequeo es informal.

• Verificación es la comprobación de que el proceso de

desarrollo es correcto. Por lo tanto se incluye en particular la formulación y justificación de las relaciones formales entre los distintos pasos de desarrollo. Puede ser expresado como el chequeo que nos permite solucionar el problema correcto. La verificación puede ser hecha con distintos grados de formalidad.

La validación requiere que se pueda seguir la traza de los

requerimientos y relacionarlos con las especificaciones que se están satisfaciendo. Se debería ser capaz de relacionar un requerimiento funcional con la especificación inicial o con un nivel de desarrollo posterior. Una vez que se conoce que un requerimiento ha sido capturado se usa la verificación para chequear que continúa capturando.

También es posible relacionar requerimientos no funcionales a pasos del

desarrollo, ya que estos son principalmente los que dirigen la dirección del desarrollo. La elección de un algoritmo en particular o una estructura de datos es a menudo determinada por el tipo de lenguaje de programación o sistema operativo seleccionado, o por algún requerimiento de capacidad o eficiencia.

4.5.2 Analizando requerimientos

La gran potencia de los métodos formales es que teniendo que crear una descripción formal de un sistema en las etapas tempranas de su desarrollo se está forzado a tomar decisiones sobre clases de cosas en las cuales los requerimientos están tácitos o tienen interpretación abierta. Esto descubre algunos problemas con la documentación de los requerimientos (problemas que generalmente son inherentes a la documentación en lenguaje natural por más bien escritos que estén).

El segundo punto de importancia es que es particularmente valioso

encontrar errores y resolver la ambigüedad en las etapas tempranas. Es sabido ya que cuanto más tarde se descubre un error más costoso es su solución, esto es debido a que por un lado el trabajo tiene que rehacerse y por otro el tiempo transcurrido.


- 71 -

En tercer lugar se puede destacar que la experiencia del grupo de trabajo utilizando métodos formales permite entender en forma común el problema y esto provoca una mejora en la creación y discusión de la especificación. Cuando los requerimientos son redactados en lenguaje natural, la comunicación del equipo queda expuesta a malos entendidos y confusiones. Mientras que se desarrolla y se acuerda una especificación tiende a dar significados exactos a los componentes del sistema, sus funciones, sus interfaces, etc., y la comunicación entre los miembros del equipo mejora consecuentemente. Este efecto inclusive ha sido informado por equipos que habían trabajado juntos previamente en sistemas similares, cuando ellos hicieron especificaciones formales primero.

Debido a estos efectos a veces es válido re-escribir los requerimientos

desde las especificaciones, ya que esto produce un documento que tiene menos olvidos, contradicciones y repeticiones, está mejor estructurado y es más consistente en su terminología. Esto es particularmente útil si el documento original resulta ser poco apropiado en estos aspectos o si el cliente no puede entender las especificaciones formales. Yendo hacia atrás con el entendimiento de uno acerca de algo, es una buena manera de chequear que uno realmente lo ha entendido.

Es evidente el valor de hacer un buen trabajo produciendo las

especificaciones iniciales. Es importante gastar una buena cantidad de tiempo y esfuerzo en la especificación inicial, más aún de la que se invierte en el análisis de los requerimientos. Una buena especificación inicial permitirá realizar un desarrollo más rápido y confiable. Por lo tanto, es normal en el procedimiento de especificación hacer varias iteraciones, buscar alternativas (particularmente distintas arquitecturas), planificar y bosquejar la ruta del desarrollo para ver si existen pasos dificultosos que puedan hacerse fáciles, para crear especificaciones más concretas que puedan ser testeadas directamente por ejecución simbólica o traducidas y ejecutadas como prototipos. En verdad un estilo muy iterativo de desarrollo en el cual, para el momento en que se acuerda la especificación inicial, mucho del trabajo de diseño y algo de la traducción ya ha sido realizado, parece estar bien aceptado para especificación formal entre equipos pequeños. Con equipos más grandes trabajando separadamente esto es menos práctico, por las interfaces, no obstante se puede adoptar para componentes.

4.5.3 Mantenimiento de la corrección

El paso esencial para el diseño detallado es realizar un sólido y correcto punto de partida y algunas otras cosas que la claridad y la lógica de los métodos formales hacen posible. Luego se trata de mantener la corrección; aquí son importantes respecto de las especificaciones la relación de implementación en particular y la habilidad para razonar en general.

4.5.4 Concentración en descubrir errores a medida que son

introducidos


- 72 -

Los ingenieros de software pierden mucho tiempo buscando y corrigiendo errores, pero pierden mucho más tiempo introduciéndolos. Aparte de aquellos inherentes a los requerimientos, todos los errores en los sistemas son introducidos por los desarrolladores y los que lo mantienen. Por lo tanto estos métodos pueden ser útilmente orientados a evitar la introducción de errores o para encontrarlos inmediatamente.

Los errores pueden catalogarse en varias categorías, a saber:

• Requerimientos que no reflejan las necesidades reales de los clientes o usuarios.

• Fallas para especificar requerimientos de performance y confiabilidad que si bien se tratan de diseñar, rara vez pueden garantizarse de antemano.

• Malentendidos en los requerimientos o niveles de desarrollo previo.

• Equivocaciones de los desarrolladores o mantenedores en no escribir lo que realmente deberían.

La primer categoría es normalmente la más cara de corregir, la última

probablemente la más común. El uso de los métodos formales ayudará en la primera categoría de

errores en el grado que los requerimientos sean obviamente no claros o incompletos, ya que en la etapa del análisis surgirán cantidades de preguntas a partir de los requerimientos y las resolverán sus propios autores. Pero si los requerimientos dicen construir X cuando ello significa Y, y el requerimiento de X parece razonable, hay poca chance de que algún método formal detecte el problema. Construir un prototipo tempranamente para muestra es una buena idea si este es el problema.

Los métodos formales tienen alguna dificultad con la segunda categoría

de errores (fallas en la especificación de requerimientos que no pueden ser fácilmente expresados como una propiedad de lo que debería hacer una componente particular). Los requerimientos de tiempo real son un ejemplo particular de esto, y cómo tratarlos es un área de investigación aún abierta. Lo que se puede hacer con este tipo de requerimientos es utilizarlos como una guía hacia donde enfocar el desarrollo y los estándares que se adopten. Por lo tanto para lograr el rendimiento o fiabilidad de los requerimientos se debe considerar varias arquitecturas posibles (incluyendo tanto el software como el hardware), utilizar técnicas estándares para analizar la performance potencial, tasas de error, etc., y guiar el desarrollo hacia la arquitectura seleccionada. Para lograr un nivel de calidad particular en el producto se deberán aplicar los estándares apropiados en el desarrollo (y aquí los métodos formales tienen mucho para ofrecer para lograr más fiabilidad en el proceso de desarrollo).

Los métodos formales además ayudan con la tercer categoría de

errores, ya que reducen fuertemente la posibilidad de malentendidos.


- 73 -

Respecto de la cuarta categoría de errores, no resulta muy claro si se es más o menos propenso a cometer errores si se escribe en RSL que en otras herramientas. Las herramientas pueden ayudar a determinar inmediatamente algunas equivocaciones simples, y sucede muchas veces el caso de que el tipo de error en una especificación indica un problema más profundo que simplemente un desliz.

Pero indudablemente los errores se cometen de esta manera, y las

especificaciones formales no son fáciles de obtener. Pero las especificaciones formales tienen dos ventajas sobre los programas:

1. Pueden ser verificadas contra los niveles previos (contra

requerimientos al tratar de comprobar requerimientos expresados formalmente, y contra los niveles previos escritos en RSL al expresar la implementación y luego su justificación). Aunque este proceso se utilizara solamente para extender cuidadosamente la examinación de las pruebas obligatorias, sin realmente hacer y registrar justificación alguna, no obstante es muy efectivo para descubrir errores.

2. Las especificaciones formales pueden ser revisadas. La lectura

de código es reconocida como una manera efectiva de descubrir errores, y leer RSL es generalmente fácil porque es más abstracto y contiene menos detalle. Por lo que revisar código RSL, por personas expertas en éste lenguaje y con check-lists de problemas típicos, resulta muy efectivo.

4.5.5 Producción de documentación que facilita el mantenimiento

El mantenimiento del software es muy caro y muy propenso a cometer errores. La documentación de diseño normalmente falta o está desactualizada.

Las especificaciones formales, tanto las iniciales como las de desarrollo,

pueden ayudar considerablemente ya que proveen un medio para comprender la codificación del estilo top - down. Los comentarios que se pongan en las especificaciones ayudan al proceso. Si el cambio a producir es una extensión, una adaptación o una corrección, entonces es posible descubrir los módulos afectados y el primer nivel de desarrollo en el cual el cambio se puede evidenciar, y rehacer el desarrollo desde dicho punto. Las interfaces entre los módulos RSL son todos explícitos, por lo que resulta fácil determinar qué más es afectado (normalmente utilizando herramientas).

El proceso es inclusive mucho más sencillo (y cómodo de seguir) si

todos o la gran mayoría de las especificaciones finales son automáticamente traducidas. Este es también un factor crucial para que las especificaciones sean actualizadas. Uno de los problemas con el diseño de la documentación tradicional es que una vez que ha sido creada no hay incentivo real para mantenerla; cambiando la documentación y el código parece como si fueran dos tareas en donde solamente importa una de ellas. Cuanto más se pueda


- 74 -

construir código generado a partir del diseño más probable es que los diseños sean consistentes con el código.

4.6 Uso selectivo

Existen dos formas importantes en las cuales se puede ser selectivo en el uso de RAISE: en cuán formal se decide ser y a qué componentes de un sistema se elige para ser aplicadas.

4.6.1 Grados de formalidad

Como ya se estuvo analizando en la sección 4.4, no es necesario comprobar todo. En realidad existe un principio mucho más general: el grado de formalidad que se aplica necesita ser apropiado al problema y una manera eficiente de atacarlo. Existen algunas oportunidades para ser más o menos formal en el desarrollo. Se podría clasificar en 3 estilos de desarrollo:

1. Especificaciones formales solamente: La formalidad es

aplicada al proceso de especificación. Se escriben las especificaciones con el objetivo de:

• Lograr y documentar una sentencia precisa y no ambigua de lo que se entiende que el sistema debe hacer, así como las bases para crearlo ahora y mantenerlo en el futuro.

• Utilizar esto como una guía para hacer un diseño detallado y escribiendo el código, pero utilizando técnicas informales de diseño.

• Validar las especificaciones contra los requerimientos para descubrir algunas discrepancias y resolviéndolas.

• Formular casos de testeo para ser utilizados en la codificación posterior.

2. Especificaciones formales y desarrollo riguroso: La

formalidad es aplicada al proceso de especificación como antes, pero además al proceso de desarrollo. Esto significa que se escribe las especificaciones abstractas y más concretas y además se documenta la relación entre el desarrollo y las especificaciones. Estas relaciones están sujetas luego a ser examinadas y quizás revisadas, pero no para ser justificadas.

3. Especificaciones formales y desarrollo formal: se extiende el

paso previo realizando las justificaciones. Aún se mantiene el consejo dado de estar siempre concentrado en las partes dificultosas o interesantes y justificarlas, incluyendo argumentos informales, en vez de pruebas profundas. Por lo tanto esta categoría debería ser llamada “especificaciones formales y desarrollo más riguroso”.

¿Entonces, qué nivel se debería adoptar?. Muchas experiencias con los

métodos formales han sido en utilizarlo en el primer nivel, y sin duda el proceso


- 75 -

de especificaciones formales ha sido extremadamente efectivo porque ha encontrado algunas ambigüedades y omisiones en los requerimientos. Resultó también efectivo brindando las bases para los casos de testeo y para determinar los resultados esperados, y para brindar documentación que puede ser utilizada en el mantenimiento. En términos de valor (principalmente el incremento de confianza en el software) por esfuerzo es extremadamente conveniente en la relación costo-eficiencia.

Pero utilizando el primer nivel solamente aún deja una brecha entre la

especificación inicial y el código. Si solamente se intenta producir un nivel de especificación, se puede estar tentado de hacerlo muy detallado, capturar todos los requerimientos y dejarlos muy cercanos al código. Existe, entonces, un riesgo de que se pierdan algunas de las ventajas de la especificación formal en no ser suficientemente abstractos, y crear especificaciones que son difíciles de razonar (ya sea mentalmente, en papel o con herramientas). Una vez que se ha perdido la habilidad de razonar acerca de lo que significan las especificaciones, se pierde mucho el objetivo del producto. Podemos decir entonces que existen muchos y buenos argumentos para adoptar el segundo nivel.

No es necesario adoptar el desarrollo riguroso uniformemente. La

especificación inicial brindará una descomposición del máximo nivel en componentes del sistema, y algunas de estas necesitarán más trabajo de desarrollo que otros. Algunas podrán ser muy simples y fáciles de codificar; otras serán componentes estándares para los cuales ya existen desarrollos con traducción.

Algunos de los beneficios del primer nivel recaen en encontrar los

errores (errores, omisiones, contradicciones o ambigüedades en los requerimientos). Muchos de los beneficios del segundo nivel residen en evitar los errores: habiendo alcanzado una buena especificación inicial se puede mantener concordancia con ella. A su vez produce un registro de cómo fue hecho el desarrollo lo que es muy valioso a la hora del mantenimiento. El segundo nivel produce RSL el cual puede ser traducido automáticamente. En términos de costo-efectividad (mejora la calidad por esfuerzo) puede ser menos efectivo que el primer nivel, pero puede aún ser una gran ayuda por sobre otras alternativas.

El tercer nivel, el de hacer realmente las justificaciones, continúa la

tendencia de incrementar el esfuerzo sustancialmente para obtener un retorno más pequeño de mejora de la calidad. Las justificaciones pueden consumir demasiado tiempo y es casi siempre reservada para componentes más críticos. Debería notarse que es aquí donde hay posibilidades de obtener un logro que no puede ser alcanzado de cualquier otra manera. Aún los sistemas más simples son demasiado complicados de testear comprensivamente, así que hay límites estadísticos muy claros sobre la confiabilidad alcanzable a través del testeo. El incremento en la utilización de los sistemas en paralelo y distribuidos hace que estos problemas sean aún peores. Hay algunos ejemplos, como la aplicación por parte de Bull en el proyecto LaCos de


- 76 -

ESPIRIT, donde previamente no se habían descubierto errores luego fueron descubiertos mediante justificación.

Finalmente, se debe mencionar que se requiere cierta experiencia para

convertirse en un buen especificador. Se requiere de un poco más aún para convertirse en un diseñador riguroso, porque se necesita experiencia para juzgar qué desarrollar primero, cuánto detalle poner en cada paso de desarrollo, cuándo descomponer, qué desarrollos previos pueden ser reutilizados, cuáles construcciones serán fáciles o difíciles de traducir en un lenguaje destino, cómo tomar en cuenta otras restricciones como problemas de tiempo hardware, sistemas operativos, etc. Se requiere más experiencia todavía para ser capaz de realizar justificaciones, porque existen técnicas particulares a ser aprendidas. Por lo tanto los equipos nuevos de métodos formales deberían concentrarse en las especificaciones formales antes que tratar el desarrollo riguroso, y más tarde aún para desarrollar habilidades para las justificaciones.

4.6.2 Aplicación selectiva de formalidad

En la sección anterior (4.6.1) se habló de la posibilidad de ser más o menos formal en la forma en que se aplican los métodos formales. Es también el caso en el que se puede elegir aplicar métodos formales sólo a partes del sistema y no a otras. Existen dos maneras en las cuales se puede hacer esto: seleccionando las propiedades y seleccionando componentes.

4.6.2.1 Seleccionando propiedades

Se puede elegir para especificar solamente unas pocas propiedades

críticas, como seguridad o confiabilidad. Normalmente se obtienen dos beneficios de esto:

1. Profundo entendimiento de la propiedad en sí misma a

través de la captura en un lenguaje formal. 2. Entendimiento (probablemente luego de algunos

desarrollos formales) de cómo los componentes de sistema necesitan interactuar para poder mantener la propiedad.

4.6.2.2 Seleccionando componentes

Se puede elegir especificar solamente ciertos componentes del sistema. Los componentes para los cuales los métodos formales son probablemente menos útiles incluyen:

• Componentes estándares como bases de datos, sistemas operativos con los cuales el sistema a desarrollar debe tener interfaces. Especificar dichas interfaces formalmente involucraría especificar las propiedades relevantes de los componentes estándares, y esto muy pocas veces vale la pena.


- 77 -

• Componentes genéricos con los cuales el sistema a desarrollar necesita instanciar. Se necesitaría especificar el componente genérico y también el código que se necesita escribir para hacer la instanciación particular. Este código está normalmente escrito en algún lenguaje especial. Por ejemplo: un sistema de procesamiento de lenguajes (analizadores léxicos, parsers, generadores de compiladores, editores orientados a la sintaxis) utilizarán notaciones especializadas como “expresiones regulares” y BNF. Al tratar de utilizar un lenguaje de especificación de propósito general como lo es RSL para especificar la entrada en estas notaciones puede ser incómodo, menos claro y a menudo no abstracto.

Las interfaces de usuario también entran en esta categoría. Los sistemas modernos típicamente utilizan componentes genéricas estándares para generar interfaces gráficas para el usuario, y aquí las características importantes como la apariencia y el tiempo de respuesta son difíciles de especificar efectivamente en un lenguaje de especificación.

• Componentes cuyo comportamiento no son considerados muy críticos.

• Componentes existentes que no están formalmente especificados y que se están adaptando. Esta es una práctica peligrosa, porque es precisamente el software complejo con una documentación inadecuada o desactualizada que es peligroso adaptar. Pero el costo de especificar formalmente un componente existente es normalmente difícil de justificar cuando se espera ahorrar tiempo de desarrollo por la adaptación. A largo plazo puede ser más barato comenzar desde cero y desarrollar apropiadamente, pero es poco probable que aparente serlo al principio.

Por lo tanto los componentes que se deben especificar formalmente son

aquellos cuya correctitud es crítica y que se construyen desde el comienzo o adaptación.

El software que es desarrollado formalmente es también más fácil de

mantener y adaptar, porque la historia de especificación y desarrollo brinda una efectiva documentación para estos propósitos. Otro criterio para elegir formalidad son el tiempo de vida esperado del sistema y la probabilidad de re-uso.

4.7 Sistemas formales

En esta sección se discutirán los aspectos de RAISE como un sistema

formal. Un sistema formal contiene cuatro componentes esenciales:

1. Una notación con una sintaxis definida. 2. Un conjunto de reglas bien formadas.


- 78 -

3. Una semántica. 4. Una lógica.

Si se toman las expresiones aritméticas como un ejemplo, las reglas de

sintaxis deberían decir que el término “1”, “2”, “+”, y “1 + 2” son sintácticamente correctos, pero los términos como “1 +” y “+ +” no lo son.

Reglas bien formadas cubren las áreas comúnmente llamadas como

chequeo de “alcance”, “visibilidad”, y “tipo”. Si se extendiera el ejemplo para incluir “booleans” así como aritméticos, y además para permitir expresiones let, la expresión siguiente:

let x = 2 in 1 + y end y let x = true in 1 + x end

violarían las reglas de alcance/visibilidad y de tipo respectivamente.

La semántica de un sistema define su significado, usualmente en términos de alguna teoría matemática como puede ser la de los números naturales, o teoría de conjuntos. La semántica es normalmente solamente definida para términos bien formados.

Para el ejemplo simple anterior, es obvia la relación entre aritméticos y

booleanos y entre los números naturales y los valores de verdad. Pero todavía existe el problema de explicar qué significan las expresiones “let”.

Hasta ahora, lo que se ha considerado incluye los lenguajes de

programación, o al menos los lenguajes de programación que se les ha dado una semántica matemática. Entonces, ¿es Ada un sistema formal?. Aún le está faltando el cuarto elemento, una lógica. Esto es lo que permite razonar acerca de los términos en el sistema formal. Por ejemplo, en este sistema, el siguiente caso de igualdad, ¿es verdadero?

1 + 2 = 2 + 1 (1) Una forma de responder a este problema es apelar a la semántica, para

decidir que las dos expresiones en ambos lados de la igualdad representan en matemática el número natural “3”, y que por lo tanto nos permite decir que la respuesta es “sí”. Otra forma, si este sistema es un lenguaje de programación, es testearlo y verlo. Esencialmente (asumiendo que la ejecución de un programa sigue su correcta semántica) estas maneras son lo mismo. Se está “ejecutando” la expresión, simbólicamente o mecánicamente, para ver qué valor semántico se obtiene.

Pero si se tuviera una lógica se tendrían reglas como i + j = j + I (2)


- 79 -

junto a las reglas para la instanciación de nombres “i” y “j” con enteros como “1” y “2”. Ahora no sólo se puede responder el problema de si (1) es verdadero sin tener que ejecutarla, simbólicamente o de otra manera, sino que también se puede responder una pregunta aún más general, como si ¿“es i + 1 lo mismo que 1 + i para cualquier entero i”?

Hay un costo en tener una lógica, un conjunto de reglas como en (2), como también la semántica: ya que se tiene dos formas de responder preguntas se tiene que asegurar que se obtiene el mismo resultado o respuesta. En otras palabras la lógica tiene que ser consistente con la semántica. En RAISE se aborda esto al comenzar con una lógica pequeña que contiene un conjunto mínimo de reglas “básicas”, las cuales pueden ser chequeadas contra la semántica, y que luego pueden chequear otras reglas mostrando cómo son derivadas de las otras básicas.

El sistema formal que se describe es RAISE, basado sobre su lenguaje

de especificación, RSL. El libro de RSL [9] describe su sintaxis, las reglas bien formadas y (informalmente) su semántica. Es importante considerar primero la pregunta de por qué es necesario RSL. ¿Por qué no se provee una lógica para Ada, o Pascal o algún otro lenguaje de programación?

La razón es que estos lenguajes fueron diseñados para escribir

software. Ellos tienen algunas características de “bajo nivel” como punteros que ayudan a escribir software de manera eficiente. Pero tales características de “bajo nivel” hacen un razonamiento muy complicado, y su lógica sería muy complicada. Un lenguaje de especificación como RSL apunta a hacer razonamientos posibles, y por lo tanto incluyen características (como tipos abstractos y axiomas) que hacen el razonamiento más tratable, y evitan aspectos que hacen el razonamiento más complicado.

RSL es sin embargo, un lenguaje de amplio espectro porque está

pensado para ser utilizado no solamente para las especificaciones iniciales, sino que además permite el desarrollo a lenguajes como Ada o C++. De aquí que incluye algunas características de bajo nivel como variables con asignación y ciclos. El razonamiento es más fácil si se utilizan solamente las características de aplicación secuencial de RSL que cuando se incluyen características imperativas y concurrentes. Aquí es donde el método sugiere (pero no lo fuerza) que las especificaciones iniciales sean secuenciales y aplicativas para que se puedan razonar inicialmente con cierta facilidad.

Especificación formal

- 80 -

5. ESPECIFICACIÓN FORMAL DEL FRAMEWORK

5.1. Introducción

En este trabajo se presenta una infraestructura abierta y estándar de servicios de SIG, que permite abordar la construcción de sistemas de información geográfica a partir de modelos probados y de utilización directa, lo que brinda la posibilidad de generar de manera automatizada sistemas de información geográfica.

La especificación de la infraestructura se realiza en un lenguaje de

especificaciones formales como es RSL, el cual es reconocido en la industria del software para especificaciones formales de desarrollos reales.

Para poder mostrar la especificación formal del framework propuesto,

inicialmente se hará una introducción a la especificación y desarrollo de sistemas utilizando RAISE, para luego abordar la especificación formal junto a un desarrollo teórico de las características fundamentales del lenguaje RSL, lo que va a permitir realizar un sistema de autocontenido y aprendizaje progresivo según las necesidades de aplicación del conocimiento.

5.2 RAISE Specification Language

Existen distintos estilos para escribir especificaciones en RSL. En esta sección se abordará las diferencias que existen entre las especificaciones imperativas y aplicativas, y entre los estilos secuenciales y concurrentes. Luego se describirán los estilos abstractos y concretos.

Dentro de los estilos de especificación, en el párrafo anterior se

mencionó que existían varios de ellos, a saber:

• Aplicativo secuencial: un estilo de programación funcional sin variables y concurrencia.

• Imperativo secuencial: con variables, asignaciones, secuenciación, bucles, etc., pero sin concurrencia.

• Aplicativo concurrente: programación funcional con concurrencia.

• Imperativo concurrente: con variables, asignaciones, secuenciación, bucles, etc., y concurrente.

Las especificaciones aplicativas concurrentes son a menudo

inapropiadas para la implementación en lenguajes de programación; en general los procesos principales son recursivos en estructura y su ejecución continuada incrementa permanentemente el tamaño de la pila de llamadas. Por lo tanto a menos que se esté implementando en un lenguaje aplicativo que cubra este problema, será necesario utilizar entonces un estilo imperativo; el uso de variables permite que la recursión sea reemplazada por bucles. Por lo tanto


- 81 -

quedan solamente tres tipos de módulos disponibles: aplicativo secuencial, imperativo secuencial e imperativo concurrente, los cuales podemos abreviar como aplicativo, imperativo y concurrente.

La experiencia puede decir que de los tres, el estilo aplicativo es el más

sencillo tanto para las especificaciones como para las justificaciones. Esto conduce a que se puede comenzar fácilmente con las especificaciones en un estilo aplicativo y desarrollarlas luego en uno imperativo o concurrente.

Así como se puede distinguir entre los estilos de especificación

aplicativo e imperativo, secuencial y concurrente, también se puede distinguir entre los estilos abstracto y concreto.

Por abstracto se entiende, en general, escribir especificaciones que

dejen la mayor cantidad posible de rutas o alternativas abiertas como sea posible. Es decir, cuanto menos decisiones de diseño se hayan tomado al expresar las especificaciones, más abstracto será. Por decisiones de diseño se entiende lo siguiente:

• Decidir cómo formular un módulo utilizando otros módulos.

• Decidir en una estructura de datos particular.

• Decidir un algoritmo determinado.

• Decidir qué variables utilizar.

• Decidir qué canales y patrones de comunicación utilizar.

Lo opuesto de abstracto es concreto. La diferencia entre ambos no es blanco sobre negro, sino que se puede caracterizar módulos en cada una de las tres categorías como tendiendo a ser abstracto o concreto.

• Los módulos aplicativos abstractos: utilizan tipos abstractos y utilizan signaturas y axiomas en lugar de definiciones explícitas para algunas o incluso todas las funciones.

• Los módulos aplicativos concretos: utilizan tipos concretos y contienen mayor cantidad de funciones definidas explícitamente.

• Los módulos imperativos abstractos: no definen variables y utilizan any en sus accesos y utilizan axiomas.

• Los módulos concretos imperativos: definen variables y contienen definiciones de funciones de manera más explícita.

• Los módulos abstractos concurrentes: no definen variables o canales y utilizan any en sus accesos y utilizan axiomas.

• Los módulos concretos concurrentes: definen variables y canales


- 82 -

y contienen definiciones de funciones de manera más explícita.

Un módulo puede ser abstracto de alguna manera y concreto de otra. Ciertamente una especificación de un sistema contendrá módulos en estilos variables y en niveles de abstracción variables. Se usa el término axiomático para describir un estilo de definición de valor (“value”) en términos de signatura y axioma.

El presente trabajo se basa en un estilo aplicativo secuencial abstracto,

para la especificación formal del framework. Los objetivos de escribir la especificación formal, en especial en este

trabajo, son los siguientes:

• Lograr y documentar un enunciado preciso y no ambiguo de lo que se entiende por el sistema que se va a hacer, como una base para construirlo ahora y mantenerlo en el futuro.

• Usar esto como una guía para hacer el diseño detallado y escribir el código, utilizando para ello técnicas de diseño informales.

• Validar la especificación contra los requerimientos para descubrir algunas discrepancias y resolverlas.

• Formular los casos de testeo para usarlos después de la codificación.

Entonces, surge la pregunta: ¿cuál nivel debería adoptarse?. Como se

veía en el capítulo anterior, la mayoría de las experiencias con métodos formales fueron en el primer nivel, y ciertamente el procedimiento de especificación formal parece ser extremadamente efectivo ya que encuentra muchas ambigüedades y omisiones en los requerimientos. También es efectivo al proveer una base para casos de testeo y para determinar los resultados esperados, además de brindar documentación para ser usada durante la etapa de mantenimiento. En términos de valor (principalmente el incremento de confianza en el software) por esfuerzo es extremadamente conveniente en la relación costo-eficiencia.

La escritura de la especificación inicial es la tarea más crítica en el

desarrollo de software. Si estas especificaciones son erróneas, el trabajo siguiente será desperdiciado. Es sabido que los errores cometidos al comienzo del ciclo de vida son considerablemente más caros de solucionar que aquellos errores que se cometen al estar más avanzado el proyecto, precisamente porque tienen un costo de tiempo y esfuerzo para solucionarlos y volver a la dirección correcta. No se puede garantizar que no se cometerán errores, pero si se pueden detectar rápidamente, entonces el daño que pueden causar no es demasiado.

El principal problema en el entendimiento de los requerimientos es que

normalmente pertenecen a un dominio del cual no se es experto, además que


- 83 -

aquellos que escriben los requerimientos y a los que les es familiar el dominio, tienden a no explicitar aquello que para ellos es obvio. Además los requerimientos están escritos en un lenguaje natural, el cual resulta ser en muchos casos ambiguo. Estos tienden a ser extensos documentos desarrollados por varias personas durante un período de tiempo. Como resultado resulta ser que son a menudo contradictorios: lo que se dice en una página puede variar de lo que se dice en otra.

El objetivo de la especificación inicial es capturar los requerimientos de

una manera precisa y formal. Por formalidad se entiende que la especificación tenga una único significado, es decir que no sea ambigua. Por capturar los requerimientos se entiende reescribirlos en términos nuestros, creando un modelo de lo que el sistema debe hacer. Existen algunos consejos para capturar los requerimientos que permitirán luego obtener estos modelos de manera precisa:

• Ser abstracto: La especificación debería ser abstracta, debería tener la menor cantidad posible de detalles. Los requerimientos pueden demandar que algunos identificadores tengan algún formato determinado, o determinadas fechas expresadas en un formato específico o que ciertos cálculos se deben hacer con un grado de precisión determinado, pero se deberá tratar de extraer la información esencial: que existen identificadores, presumiblemente diferentes entidades que identifican, que se necesitan fechas o que ciertos cálculos deben ser realizados.

• Utilizar los conceptos del usuario: Los conceptos en las especificaciones deben ser los mismos que los conceptos brindados por el usuario. No se deben hacer referencias a bases de datos, tablas, registros: estos son conceptos de computación que describen la manera en que se soluciona el problema, donde lo que interesa primero es describir el problema y no su solución.

• Hacerlas legibles: Las especificaciones son escritas con la finalidad de que puedan ser leídas por otros: por aquellos que deben validar que las especificaciones se corresponden con con los requerimientos, por aquellos que luego deben mantener el sistema, etc. Aquí las recomendaciones se refieren principalmente a manejar identificadores con significado, comentarios, funciones simples, etc.

• Buscar los problemas: Se debe concentrar en aquellas cosas que aparecen como las más dificultosas, raras, o nuevas, y se ignoran aquellas que resultan más directas o sencillas. Al capturar los requerimientos se está intentando además si el sistema que se intenta desarrollar es factible, al menos dentro de las posibilidades económicas, y de saber de antemano si podemos tener solución para todos los posibles problemas.

• Minimizar los estados: por estado de un sistema (o módulo) se


- 84 -

entiende la información que se almacena, que persiste entre las interacciones con él. A fin de minimizar la información de estado, no se debe incluir información que depende del estado, es decir información que puede ser calculada de otra información del estado, aunque en una etapa posterior del desarrollo se decida almacenar esta información calculada para lograr mayor velocidad de procesamiento

• Identificar condiciones de consistencia: las condiciones de consistencia son necesarias si algunos de los valores de los estados posibles no se corresponden con la realidad: dos usuarios de una biblioteca solicitan el mismo libro al mismo tiempo. Las condiciones de policía son aquellas que pueden, tal vez, surgir en la realidad pero que se intentan que no sucedan: un usuario intentando solicitar muchos libros al mismo tiempo. Si el sistema no se corresponde con la realidad entonces se vuelve inutilizable: por ej. no puede decir quién tiene determinado libro, y probablemente de esta manera no se le pueda “creer” alguna otra información que nos pueda dar.

Por lo tanto preservar las condiciones de consistencia es más crítico para la salud del sistema que cuidar las condiciones de política. Las condiciones de consistencia a veces se pueden controlar fácilmente estableciendo un tipo mas restrictivo, por ejemplo Nat para evitar números negativos, otras veces, en cambio, es necesario definir una función expresándola, por ejemplo cuando los requerimientos de consistencia abarcan más de un módulo.

5.3 Especificación de la Infraestructura Inicialmente se describirán los conceptos más importantes del

framework, de una manera informal, para poder de esta manera introducirse luego en la especificación formal del mismo. 5.3.1 Conceptos importantes de la Infraestructura

Los sistemas de información geográfica han surgido hace ya más de 20

años y su inserción y uso dentro de las empresas y los organismos públicos ha sido muy importante. Cabe mencionar que más del 80% de los negocios requieren de servicios o prestaciones de localización geográfica. Los beneficios que aporta para la toma de decisiones, inteligencia que adiciona a los negocios, operaciones e información pública son innumerables; sin embargo muchos factores han mitigado estos beneficios.

La necesidad de compartir la cartografía de base, no tener que hacer

enormes inversiones en licenciamiento de las herramientas, tener un repositorio común de la información, con el único propósito de mejorar el


- 85 -

rendimiento de los SIG (aumentando la utilización de los mismos), mejorar la confianza en el formato y actualización de la información y en la reducción de costos, se fueron convirtiendo en las necesidades básicas para poder llevar adelante exitosamente un plan de implementación de una solución con sistemas de información geográfica.



Los servicios Web son servicios que están disponibles en Internet

(intranet), utilizan un sistema de mensajería estandarizada y no están ligados a sistema operativo alguno o lenguaje de programación. A su vez los servicios Web pueden (es deseable que así sea) tener dos propiedades adicionales: se describen a sí mismos y se deben publicar para que se conozcan [3].

Por lo tanto, los servicios Web de SIG son servicios disponibles en

Internet, que utilizan los mismos mecanismos que los servicios Web, pero que brindan información y funcionalidades específicas y propias de sistemas de información geográfica.


organizaciones que desean hacer uso de información espacial y no encontrarse con los problemas mencionados anteriormente. Al poder hacer un “outsourcing” de los servicios de datos espaciales, se encuentra la organización con una serie de beneficios: menor costo, menores riesgos, menores tiempos de desarrollo y disponibilidad de la información, menor cantidad de recursos especializados para poder llevar adelante la solución [22].

Compartir información geográfica y servicios asociados es una tarea que

se viene investigando y haciendo ensayos desde hace varios años, su resurgimiento se debe principalmente a los organismos gubernamentales, quienes han sido, quizás por su naturaleza, los pioneros en implementar estructuras de trabajo que permitan compartir información geográfica.

Se desprende del análisis de las infraestructuras presentadas en 3.1,

que en todas ellas se hace un fuerte hincapié en compartir datos e información geográfica y de mantener una base común, única, estandarizada de los mismos. También en los distintos proyectos se puede detectar que existe la voluntad de brindar servicios Web, pero aún no se encuentran especificados los mismos ni tampoco existe una lista de servicios básicos como los que se presentan en este trabajo de tesis. Sí se establece en cada proyecto las bases de cómo se estructuran estas capas de servicios, sus arquitecturas y los estándares a los cuales se deben ajustar.

Por lo expuesto se evidencia que existe un espacio no definido ni

abordado respecto de una infraestructura de servicios Web de SIG. A continuación se brindará una descripción y definición informal de los servicios Web de SIG que luego en las secciones siguientes se especificarán formalmente.


- 86 -

5.3.1.1 Definición informal de la Infraestructura

Los servicios incorporados en esta versión de la infraestructura han sido

seleccionados a partir de las definiciones estándares del OGC, de los distintos proyectos vistos y analizados anteriormente y en base a un estudio de las aplicaciones que se llevan adelante con los sistemas de información geográfica, junto a la experiencia en desarrollo de sistemas de este estilo a nivel profesional. En base a estos antecedentes se identificaron las funcionalidades más importantes y que pueden ser la base para construcciones más complejas. Esta lista de servicios propuesta puede ser ampliada para situaciones específicas en la utilización de herramientas SIG.

Antes de comenzar a describir los servicios, se nombran los tipos de

datos abstractos (ADT) utilizados en cada uno de los servicios. Estos tipos de datos han sido tomados principalmente de la definición del OGC Location Services (OpenLS) Implementation Specification, presentados en la sección 3.1.1.1. La lista de ADTs es la siguiente:

- ADT_ADDRESS - ADT_POI - ADT_AOI A continuación se mencionan, junto a una breve descripción, los

servicios básicos del framework que luego en la sección siguiente serán desarrollados y especificados formalmente.

- Geocode: Este servicio intenta a través de una dirección dada (calle

y altura, código postal, lugar, etc.) y un mapa con una zona determinada, encontrar un punto x,y (longitud, latitud) en el plano. Para ello se tiene que valer de llamadas a funciones específicas del software SIG de base que se esté utilizando. Como resultado retorna un conjunto de direcciones normalizadas junto al punto que le corresponde en el plano de acuerdo a la dirección dada. En el caso de que no se pueda geocodificar una dirección se devuelve un punto vacío o nulo. A cada resultado se le asocia un nivel de precisión de la geocodificación. Este servicio es fundamentalmente útil en cualquier área de aplicación de los sistemas de información geográfica, ya que normalmente en las bases de datos existentes en las organizaciones se encuentran los datos normalizados de las direcciones de los clientes o suscriptores. A su vez, cualquier dispositivo móvil que necesite de algún servicio, salvo aquellos dispositivos que cuentan con un módulo de posicionamiento global, puede brindar su ubicación a través del lugar donde se encuentra.

- Reverse geocode: este servicio realiza el trabajo inverso al anterior.

Dada una lista o conjunto de puntos en el plano, ya geocodificados, deberá devolver para cada uno de ellos la dirección normalizada.


- 87 -

Este es un servicio que es particularmente importante para los dispositivos que cuentan con una unidad de posicionamiento global, pudiendo de esta forma saber inmediatamente el lugar donde se encuentra. A su vez este servicio de reverse geocode puede ser utilizado por otros servicios como base para la consulta que deseen realizar.

- Directory: el servicio permite a los usuarios acceso a un directorio en

línea para encontrar el servicio, o producto más cercano, o un lugar específico. Como ejemplos del uso de este servicio se presentan los siguientes casos de uso:

o ¿Dónde se encuentra el restaurante chino “Dragón Rojo”?. o ¿Dónde se encuentran los restaurantes chinos en una

determinada ciudad?.

o ¿Cuál es el restaurante chino más cerca al hotel donde me encuentro alojado?.

o ¿Cuáles son los restaurantes chinos que se encuentran a

500 metros de mi hotel?.

Este servicio también puede resultar de importancia para los estudios de marketing, ya que al tener el registro de estas peticiones se pueden realizar análisis estadísticos y de pedidos.

- Route: el servicio de ruteo determina la ruta que debe realizar un

solicitante. El usuario indica el punto de inicio y el de fin, puntos intermedios (si existieran), el plan de ruta deseado (la ruta más rápida, la más corta, etc.) y el medio de transporte (a pie, vehículo, etc.); el servicio entonces determina la ruta de acuerdo a los parámetros dados. Este servicio es considerado de suma utilidad para una vasta cantidad de soluciones informáticas a problemas de investigación operativa, los cuales son aplicados a un número muy importante de problemas, entre los cuales se pueden mencionar:

o Encontrar el mejor camino para que una ambulancia llegue a rescatar los accidentados en un siniestro en una gran ciudad.

o Encontrar el camino más óptimo para la entrega de

mercaderías.

o Encontrar el camino indicado para poder llegar de la forma más rápida a una determinada ciudad .

- Buffer: a partir de un punto determinado, el cual no necesariamente

tiene que ser un punto geocodificado (lo resuelve este servicio), se


- 88 -

generan una serie de círculos o circunferencias a determinada distancia del punto dado. La utilización de esta funcionalidad permite entre otras cosas obtener por ej: radios de alcance y peligrosidad de catástrofes naturales, zonas de influencias de una determinada patrulla policial, áreas de cobertura de antenas para telefonías celulares, zonas de congestionamientos urbanos, etc.

- Highway states: determina el estado de las distintas rutas a nivel de

congestionamiento, devolviendo como resultado una lista de rutas con diversos colores y tamaños, información temática, donde cada color y tamaño representa distintos niveles de congestionamiento, de forma gradual. Este servicio fue adicionado al framework como una manera de visualizar qué cosas además de las básicas pueden ser incorporadas para el mejoramiento del mismo.

- Get Map: este servicio es el que devuelve ante una petición una

imagen de una zona determinada del plano con que se está trabajando en un momento dado. Este servicio, por simple que parezca es la base para todas las operaciones de movimiento del plano (zoom para acercar y alejar, paneos, extensiones, etc.). Sin este servicio sería imposible poder brindar los otros servicios descriptos anteriormente.

Adicionalmente a estos servicios, y como base para los mismos, se

cuenta con una serie de servicios privados, que no son de acceso público. Estas funcionalidades básicas no son planteadas ni descriptas en el presente trabajo ya que las mismas no se consideran de importancia ni relevantes para la finalidad del framework. 5.3.2 Especificación formal de la Infraestructura

Antes de pasar directamente a la especificación formal en RSL, es

importante introducir algunos conceptos básicos sobre el lenguaje de especificación RSL (sintácticos y semánticos) a fin de dar mayor comprensión al formalismo que se desarrolla, de manera de abordar el estudio de RSL de una manera autocontenida, por lo que los conceptos van siendo desarrollados a medida que son necesarios, es decir, no es un curso exhaustivo del lenguaje, sino que se van exponiendo sólo los elementos que se usan en la especificación formal.

Todos los conceptos de RSL que resultan obvios en el medioambiente

de la ingeniería de software en particular o de las ciencias de la computación o informática en general no son explicitados a fin de no ahondar en detalles menos significativos.

En primer término se explicita el concepto de módulos, que es la primera

estructura que se observa en la primera especificación, tanto desde el punto de vista sintáctico como semántico.


- 89 -

Módulos en RSL Los módulos en RSL son los bloques de construcción base. Todas las

declaraciones se realizan dentro de los módulos, ya que es el medio por el cual se descomponen las especificaciones en unidades comprensibles y reutilizables. Estos incluyen definiciones de tipos, constantes, funciones, variables, canales y objetos.

Los esquemas son denominados expresiones de clase y representan

modelos de expresiones de clases. Los módulos en RSL corresponden a los “módulos”, “paquetes” o “clases” en los lenguajes de programación. Las especificaciones en RSL pueden ser construidas de una forma jerárquica, ya que los módulos pueden referirse a entidades de otros módulos al definir sus propias entidades. Los módulos pueden ser parametrizados para dar soporte a especificaciones más generalizadas. Este es un mecanismo importante al crear módulos reutilizables. Un módulo puede ser adaptado para una aplicación determinada con sólo renombrar y ocultar algunas de sus entidades.

Hay dos clases de módulos:

• Objetos.

• Esquemas. Donde los esquemas son (probablemente parametrizado) expresiones

de clase, y los objetos son instancias de dichas clases. Podemos hacer una correlación entre las clases y objetos de los lenguajes de programación orientados a objetos y los de RSL.

Los módulos son las únicas entidades que se pueden definir en el nivel

más extremo de una especificación. En otras palabras, una especificación es una colección de declaraciones de módulos.

Previamente a introducir los conceptos de objetos y esquemas de una

manera más detallada, se describe el concepto de expresión de clase básica. Las expresiones de clase son fundamentales tanto en la definición de objetos como en la definición de esquemas.

Class (expresiones de clase básica) en RSL Existen varias formas de hacer expresiones de clases, pero la más

común es la expresión de clase básica, la cual consiste de las palabras class y end conteniendo algunas declaraciones de distinto tipo. Cada declaración es una clave seguida de una o más definiciones del tipo apropiado. Entonces, la forma básica de una expresión de clase tiene la siguiente forma: class declaration1, . . .


- 90 -

declarationn

end para n ≥ 0.

Las expresiones de clase son entidades por sí mismas y pueden también definirse dentro de las declaraciones (en los esquemas).

Una expresión de clase representa una clase (esencialmente un

conjunto) de modelos. Cada modelo asocia una entidad (“value”, tipo, variable, canal o módulo) con un identificador definido dentro de la expresión de clase. Puede haber más de un modelo ya que los identificadores pueden ser sub-especificados.

Las declaraciones no son obligatorias, muchas clases solamente

contiene declaraciones y de tipo únicamente. No es necesario tener las declaraciones ordenadas de cierta manera, pudiendo encontrar más de una ocurrencia de un tipo de declaración.

A manera de ejemplo considerar la siguiente expresión de clase:

class value i : Int axiom i = 1 ∨ i = 2 end

Esta expresión de clase representa la clase y dos modelos contenidos, debido al hecho que i está sub-especificado. La clase puede ser ilustrada de la siguiente manera:

{ [ i → 1 ] , [ i → 2 ] } La clase representada por una expresión de clase básica es la clase que

contiene todos los modelos que satisfacen las declaraciones. Cada uno de los dos modelos anteriores satisfacen las declaraciones. Tómese el ejemplo del primer modelo:

[ i → 1 ] Este modelo satisface la declaración de que i es un entero dado que i

está ligado a un valor dentro de Int. El modelo también satisface el axioma que i debe ser 1 o 2 dado que i está ligado a 1. Un caso similar ocurre con el segundo modelo.

En efecto, esta descripción es una simplificación. Con el fin de permitir

extensiones (agregar nuevas definiciones) como implementaciones se definen los modelos de una expresión de clase para incluir todas las posibles extensiones. Esto significa que la clase de modelos de alguna expresión de clase es infinita. Pero se pueden caracterizar las clases de modelos para este ejemplo simple como que todos contienen una asociación del valor i a 1 o 2.


- 91 -

Las expresiones de clase también pueden tener otras formas, aunque,

usualmente, estas formas se pueden expandir en expresiones de clase básicas equivalentes. En la literatura, se usa class_expr para referirse a la categoría de expresiones de clase. Con objetos se puede dar nombres a los modelos y con esquemas se puede dar nombres a las expresiones de clase. Scheme (declaraciones y definiciones de esquemas) en RSL

Un objeto representa un modelo, arbitrariamente elegido de la clase de

modelos representados por alguna expresión de clase. En algunas situaciones es conveniente tener medios para manipular expresiones sobre clases previamente a definir objetos. Un prerrequisito para poder hacerlo es poder darles nombre a las expresiones de clase.

Una expresión de clase con nombre se llama un scheme (“esquema”).

De esta forma, cada ocurrencia del nombre, llamado instanciación del esquema, puede reemplazarse con la expresión de clase y viceversa.

Los esquemas son entidades, como lo son los tipos, “values”, variables,

canales y objetos. Por eso todos ellos son definidos en las declaraciones. Una declaración de esquema tiene la siguiente forma:

scheme scheme_definition1, . . . scheme_definitionn

para n ≥ 1.

Una definición de esquema, en la forma simple que se ha visto, tiene la siguiente forma: id = class_expr

Es decir, el identificador id está definido como una abreviatura para la

class_expr. Como un ejemplo de su utilización se puede ver:

scheme S = class variable i : Int value v : i � i axiom forall i : Int •


- 92 -

. . . end

El esquema S se define como una abreviatura de su expresión de

definición de clase. A manera de ejemplo se pueden definir dos objetos O1 y O2, cada uno una instancia del esquema S: object O1 : S, O2 : S

Estas definiciones de objetos son exactamente equivalentes a las siguientes, donde las dos ocurrencias del nombre de esquema S han sido reemplazadas con su expresión de definición de clase.

object O1 : class . . . end, O2 : class . . . end

De esta manera se han definido dos objetos definiendo dos variables diferentes. Es decir, la variable O1.i es diferente a la variable O2.i.

Es importante destacar que las dos definiciones de objetos anteriores

podrían haber sido obtenidas sin introducir una definición de esquema. En lugar de introducir el esquema se podría haber forzado a escribir las formas expandidas del segundo ejemplo en lugar de la forma compactada del primer ejemplo. Pero el estilo de escribirlo dos veces requiere más escritura y oscurece el hecho que los dos objetos son instancias de la misma expresión de clase.

Type (declaraciones de tipos) en RSL

RSL, al igual que otros lenguajes de programación y de especificación,

es un lenguaje tipificado. Es decir que puede ser posible asociar cada ocurrencia de un identificador representando un valor, variable o canal con un único tipo, y para chequear que la ocurrencia del identificador es consistente con una colección de reglas de tipo.

Un tipo es una colección de valores relacionados lógicamente. Algunos

tipos ya vienen predefinidos en el lenguaje RSL. Como ejemplo se puede citar el tipo Nat que contiene todos los números naturales representados por los literales 0, 1, 2, ...

Además de los tipos predefinidos, se pueden definir tipos propios. Los tipos pueden estar etiquetados en declaraciones de tipo. Una

declaración de tipo tiene la forma: type type_definition1,


- 93 -

. . . type_definitionn

para n ≥ 1. Se puede ejemplificar de la siguiente manera: type ATTR, LAYER = ATTR-set

En este ejemplo de especificación hay dos definiciones de tipo: - La primera definición de tipo, que es de la forma: id

define el tipo ATTR como un tipo abstracto. Es decir, un tipo sin operadores predefinidos para generar y manipular sus valores, a excepción de “=” que compara dos valores del tipo a chequear si ellos son iguales. Cada tipo está asociado con un operador de igualdad “=” y un

operador de desigualdad “≠”, los cuales son aplicables a valores del tipo. El hecho que ATTR esté definido como un tipo abstracto refleja los requerimientos en los cuales no hay información acerca de cómo se identifican los elementos de ese tipo. Es decir, en la especificación formal se abstrae de tales detalles. A un tipo abstracto también se lo llama “sort” y su definición se la llama “definición de sort”.

- La segunda definición de tipo, que es de la forma: id = type_expr es una definición abreviada donde el nombre id se especifica como una abreviatura de la expresión de tipo que está del lado derecho del símbolo “=”. El tipo LAYER se especifica como un conjunto de ATTR. El operador de tipo -set cuando se aplica al tipo ATTR da un nuevo tipo LAYER que contiene como valores todos los subconjuntos (finitos) del conjunto de valores de ATTR. Un tipo que se obtiene por la aplicación de un operador de tipo a uno o más tipos se lo llama tipo compuesto. Los tipos abstractos (como ATTR) no son compuestos. Se podría elegir otra representación para LAYER, pero, si las necesidades de especificación requieren que el orden de los valores de ATTR es irrelevante y ningún valor de ATTR puede estar repetido, entonces parece natural modelarlo como un conjunto.


- 94 -

En orden de poder definir los tipos de valores, etc, se necesita una colección de tipos para ser utilizada. RSL tiene siete tipos predefinidos y como todo lenguaje tipificado tiene un número de operadores que los manipulan, los cuales pueden ser apreciados en la tabla 5.1.

Tabla 5.1 – Tipos predefinidos, operadores y ejemplos.

Técnicamente, los operadores para el tipo Bool son referenciadas como

conectores.

Value (declaraciones de valor) en RSL Habiendo visto una pequeña introducción de tipos, podemos considerar

que los valores popularizan los tipos. Los “values” pueden etiquetarse en las declaraciones de “value” (valor).

Una “declaración de value” tiene la forma: value value_definition1, . . . value_definitionn

para n ≥ 1.

Una definición de valor tiene en su forma más simple la siguiente forma: Id: expresión_de_tipo

Esto es, el identificador id es definido para representar un valor dentro de un tipo representado por expresión_de_tipo. Tal definición es a veces referida como una signatura de valor. A menudo por conveniencia se dice que tal definición de valor “define el valor de id’ en lugar de decir que “define el identificador id para representar un valor”.

A continuación podemos evaluar un ejemplo:

value RADIO: Real,

existe_en_directory: DIRECTORY_TYPE x Text x Text → Bool,


- 95 -

within_bb : Real x Real → Bool, En este ejemplo de especificación hay tres definiciones de value:

• La primera definición de “value” es el caso más simple, y es la que expresamos en el párrafo anterior.

• La segunda definición de “value” define la función existe_en_directory, y el tipo de existe_en_directory está representado por la expresión de tipo:

DIRECTORY_TYPE x Text x Text → Bool

la expresión de tipo se construye aplicando dos operadores de tipo. Para ilustrar mejor cómo se asocian los operadores de tipo, nótese que la expresión de tipo anterior es equivalente a la siguiente:

(DIRECTORY_TYPE x Text x Text ) → Bool

El operador de tipo “×” (producto cartesiano) se aplica a

DIRECTORY_TYPE, Text y Text, y el operador “→ ” (espacio de la función) se aplica al par que consiste del resultado del producto cartesiano y Bool. El producto cartesiano mostrado anteriormente es el tipo que contiene como valores todos los pares (directory1, texto1, textox) donde directory1 : DIRECTORY_TYPE , texto1 : Text y textox: Text.

• La tercera definición de “value” define la función within_bb, que, cuando se aplica a un Real y un Real, retorna un valor Boolean dentro del tipo predefinido en el lenguaje Bool. Este tipo contiene dos valores representados por los literales true y false (como se puede apreciar en la tabla 5.1).

Hasta ahora se ha explicado solamente cómo se definen los valores

dando su nombre y tipo. Ahora se verá cómo los valores reales que representan los nombres de valor pueden ser caracterizados por axiomas.

Para resumir, en el caso simple que se ha considerado aquí como

ejemplo, un módulo provee cero o más tipos etiquetados junto con cero o más valores etiquetados.

Axiom (declaraciones de axiomas) en RSL Los axiomas expresan propiedades de nombres de “values”. Una

declaración de axioma (en el caso más simple) tiene la forma: axiom


- 96 -

value_expr1, . . . value_exprn

para n ≥ 1. Se puede ejemplificar de la siguiente manera:

axiom ID1 ≡ { },

∀ t1 : T1, t2 : T2 • F1(t1,t2) ≡ {t1} ∪ t2,

∀ t1 : T1, t2 : T2 • F2(t1,t2) ≡ t1 ∈ t2 En este ejemplo de especificación hay tres definiciones de axiomas: - El primer axioma define el nombre ID1 para representar el conjunto

vacío (de elementos de T1) . Recordar que el tipo de ID1 es T2-set. Notar que se usa el símbolo de “≡” (equivalencia) en lugar del símbolo

de “=” (igualdad). Estos dos operadores tienen el mismo significado que en contextos aplicativos, pero sus significados son fundamentalmente diferentes en contextos secuenciales imperativos y concurrentes. Aunque estrictamente hablando no tienen el mismo significado ni en aplicativos, ni imperativos ya que la tabla de valores de verdad de la igualdad y equivalencia son distintas, el primero para el valor chaos da resultados chaos, mientras que el segundo para valores chaos da valores true o false según el caso.

Por razones de consistencia el símbolo “≡" normalmente será usado como el operador de comparación extremo en los axiomas.

El primer axioma establece que dos expresiones de valor son equivalentes, etiquetadas como ID1 y { }. Una expresión de valor evalúa a un valor.

Habitualmente “expresión” y “expresión de valor” se usan indistintamente cuando no generan confusión.

La expresión ID1 evalúa a un conjunto s1 y la expresión { } evalúa a un conjunto s2 (el conjunto vacío). Lo que requiere el axioma es que s1 y s2 sean el mismo.

De hecho, la expresión:

ID1 ≡ { }

es en sí misma una expresión de tipo Bool. Todos los axiomas son expresiones Boolean las cuales, por definición, deben evaluar a true.

- El segundo axioma del ejemplo expresa que la función F1 agrega un

elemento t1 de T1 a un conjunto t2 haciendo la unión de conjuntos de t2, el cual es un conjunto, y el conjunto single que contiene t1.

El axioma es una expresión cuantificada que se lee de la siguiente manera: para todo t1 del tipo T1 y para todos los conjuntos t2 del tipo

T2, la función F1 aplicada al par (t1,t2) debe ser equivalente a {t1} ∪ t2


- 97 -

- El tercer axioma del ejemplo define la función F2, en el cual evalúa si t1 pertenece al conjunto que representa t2.

La colección de axiomas está completa en el sentido que para cada

identificador de valor los axiomas establecen exactamente qué valor dentro de su tipo representa cada identificador. Así, por ejemplo, ID1 está definido para representar nada (el conjunto vacío). De forma similar, la función F1 representa una y sólo una función que agrega su primer argumento a su segundo argumento.

No obstante, los axiomas no necesitan estar completos. El caso extremo

sería la situación donde no hay ningún axioma. En ese caso el identificador de valor puede representar cualquier valor dentro de su tipo.

Un ejemplo de un axioma incompleto es el siguiente. Supóngase que se

quiere re-especificar la función F2 de manera tal que retorne true para cualquier t1 de T1 y t2 de T2 si t1 está en t2 y se satisface alguna condición adicional, aún desconocida. Esto se puede expresar con el siguiente axioma:

axiom ∀ t1 : T1, t2 : T2 • F2(t1,t2) ⇒ t1 ∈ t2 El axioma dice que para todo t1 de T1 y para todo t2 de T2, si el

predicado F2(t1,t2) vale, entonces t1 ∈ t2.

Este axioma está incompleto dado que satisfacen la condición varias

funciones F2 dentro de T1 × T2 → Bool. Por ejemplo, una de tales funciones es la que se especificó originalmente por el axioma:

axiom ∀ t1 : T1, t2 : T2 • F2(t1,t2) ≡ t1 ∈ t2 Otra función es la que satisface el siguiente axioma:

axiom ∀ t1 : T1, t2 : T2 • F2(t1,t2) ≡ t1 ∈ t2 ∧ F3(t1) Aquí la función F3 se supone que retorna true si el t1 cumple con la condición, de acuerdo a alguna regla. F3 debe tener el siguiente tipo:

value F3 : T1 → Bool Un identificador que no está completamente especificado a través de los

axiomas se dice que está sub-especificado. Los axiomas se pueden etiquetar o nombrar con propósitos de

documentación y para referenciarlos en las justificaciones. Los axiomas que definen ID1, F1 y F2 pueden ser escritos, por ejemplo, de la siguiente manera, donde los nombres de axiomas encerrados entre corchetes “[“ y “]” preceden a los axiomas:

axiom [axioma_ID1]


- 98 -

ID1 ≡ { }, [axioma_F1]

∀ t1 : T1, t2 : T2 • F1(t1,t2) ≡ {t1} ∪ t2, [axioma_F2]

∀ t1 : T1, t2 : T2 • F2(t1,t2) ≡ t1 ∈ t2 Los tres axiomas han sido etiquetados axioma_ID1, axioma_F1 y

axioma_F2. Los nombres o etiquetas de axiomas no agregan nada a las propiedades de una especificación.

La forma más generalizada de una declaración de axioma ahora es:

axiom opt-axiom_naming1 value_expr1, . . . opt-axiom_namingn value_exprn

para n ≥ 1. Un axiom_naming tiene la forma “[id]” y es opcional, como lo indica el prefijo opt- en la sintaxis.

Subtypes (declaraciones de subtipos) en RSL

Un tipo T1 es un subtipo de otro tipo T2 si todos los valores contenidos en T1 son a su vez contenidos en T2, a su vez el tipo T2 puede contener valores que no se encuentran en el tipo T1. Por ejemplo, el tipo Nat de todos los números naturales es un subtipo del tipo Int de los enteros.

Un tipo puede ser restringido por un predicado, resultando un subtipo del

tipo original. Por ejemplo veamos la siguiente declaración de subtipo:

{| t: Text • len t > 0|} Esta declaración representa el tipo de todos aquellos t de tipo Text donde la longitud de t es mayor que cero.

Otro ejemplo podría ser el siguiente:

{| (x,y) : Int × Int • x < y|}

Esto se lee como aquellos pares (x,y) de tipo Int × Int donde x es menor que y.

La forma general de una expresión de subtipo es la siguiente:

{| binding : expr_tipo • expr_valor |}

donde expr_valor debe ser una expresión booleana. El “binding”1 debe concordar con los valores del tipo representado por expr_tipo.

1 La traducción sería vinculación.


- 99 -

Especificación formal de los elementos base del Framework Los elementos base del framework son las definiciones sobre las que se

basa el framework y en cierta manera intentan definir la base del SIG sobre la cual se puede construir el resto.

Para ello se define un esquema denominado BASE_DEFINITIONS como

una unidad semántica, es decir el primer módulo, que se seguirá reutilizando en las próximas definiciones de los elementos componentes Framework planteado.

scheme BASE_DEFINITIONS =

La base de construcción de cualquier sistema de información geográfica,

como se planteó en la sección 2.4 (Composición de un Mapa), se conforma principalmente de un mapa que contiene capas de información categorizada (capas de: ríos, ciudades, catastro, etc.) dentro de un área de trabajo específica o de interés (por ej: toda la provincia de La Pampa, la República Argentina, todo el mundo, etc.). Por lo tanto se hacen las siguientes declaraciones de tipo para soportar las componentes:

type

ADT_MAP = (LAYER)-set × PROJECTION × BBOX,

De esta forma se está definiendo el mapa como un producto cartesiano

de: - Un conjunto de capas (el cual puede o no estar ordenado de una

manera determinada), las cuales se definen más abajo. - Una proyección (como se vio en la sección 2.4.1).

- Un área de interés, lo cual en la realidad representa un rectángulo

que abarca la zona con la cual se trabajará en el sistema.

LAYER = (POINT × ATTR)-set × (SEGMENT × ATTR)-set ×

(POLYLINE × ATTR)-set × (POLYGON × ATTR)-set ×

NAME × PROJECTION × BBOX,

Una capa se define como un producto cartesiano de: - Un conjunto de puntos y sus atributos. - Un conjunto de segmentos con atributos.

- Un conjunto de polilíneas con sus atributos.

- Un conjunto de polígonos y sus atributos.


- 100 -

- Un nombre, toda capa debe recibir un nombre para identificarla.

- Una proyección, la cual puede variar de la proyección del mapa.

- Un área de interés. En esta definición se encuentra que tanto los puntos, los segmentos, las

polilíneas y los polígonos cuentan con atributos que no son geográficos, sino atributos que hacen al espacio de la solución del problema que se plantea.

POINT = {| (x, y) : Real × Real • within_bb(x, y) |},

SEGMENT = {| s : POINT-set • card (s) = 2 |},

POLYLINE = {| pl : POINT-list • len (pl) > 2 |},

POLYGON = {| pg : POLYLINE • first(pg) = last(pg) |},

CIRCLE = POINT × RADIO,

A través de estas definiciones se aborda los elementos más atómicos

que componen un mapa, que son los puntos, segmentos, polilíneas y polígonos, como así también los círculos, los cuales se pueden definir como un polígono con ciertas características especiales y con un número de puntos lo suficientemente grande. En este caso particular hemos definido el círculo como un punto y un radio, a partir del cual se pueden definir el resto de los elementos del círculo.

Sí se puede decir que la unidad básica es el POINT, el resto de las

definiciones son subdefiniciones de un punto, o conjuntos de él.

PROJECTION,

ATTR,

STYLE,

IMAGEN,

BBOX = Real × Real × Real × Real, DISTANCE = Real,

NAME = Text,

TYPE = Text,

RADIO = Real,

STREET = Text

Aquí se han definido el resto de los elementos que componen un SIG,

donde la proyección, los atributos, estilos y las imágenes son cuestiones muy particulares de toda implementación, por lo que definirlas en este momento sería ir a un nivel de diseño muy profundo el cual no es conveniente tal como se vio en el capítulo anterior, más específicamente en la sección 4.1.1, donde se mencionaba que las especificaciones iniciales pueden no satisfacer todos los requerimientos. Más específicamente nos referimos a que algunos requerimientos que pueden ser capturados en RSL pero que son conscientemente diferidos para después en el desarrollo, debido a que incluirlos desde el comienzo tornaría la especificación inicial demasiado compleja y extensa.

Este criterio utilizado, expresado en los párrafos anteriores, sigue la idea


- 101 -

explicitada en los puntos dedicados a modelos y clases respectivamente, donde se decía que “...esta descripción es una simplificación. Con el fin de permitir extensiones (agregar nuevas definiciones) como implementaciones se definen los modelos de una expresión de clase para incluir todas las posibles extensiones.”

La especificación formal completa del esquema BASE_DEFINITIONS es

la siguiente: scheme BASE_DEFINITIONS =

class

type

ADT_MAP = (LAYER)-set × PROJECTION × BBOX,

POINT = {| (x, y) : Real × Real • within_bb(x, y) |},

SEGMENT = {| s : POINT-set • card (s) = 2 |},

POLYLINE = {| pl : POINT-list • len (pl) > 2 |},

POLYGON = {| pg : POLYLINE • first(pg) = last(pg) |},

CIRCLE = POINT × RADIO,

LAYER = (POINT × ATTR)-set × (SEGMENT × ATTR)-set ×

(POLYLINE × ATTR)-set × (POLYGON × ATTR)-set ×

NAME × PROJECTION × BBOX,

PROJECTION,

ATTR,

STYLE,

IMAGEN,

BBOX = Real × Real × Real × Real, DISTANCE = Real,

NAME = Text,

TYPE = Text,

RADIO = Real,

STREET = Text

value

within_bb : Real × Real → Bool,

within : POINT × Real → Bool,

intersects : SEGMENT × POINT → Bool,

intersects : POLYLINE × POINT → Bool,

first : POLYLINE → POINT,

last : POLYLINE → POINT,

arma_estilo: SEGMENT → STYLE,

obtener_imagen: ADT_MAP × LAYER-set × POINT × Real → IMAGEN

end

Extensiones en RSL

En RSL se puede construir una expresión de clase en pasos sucesivos,

agregando en cada paso declaraciones con el operador extend, permitiendo de esta forma ir agregando nuevos requerimientos.

La forma general de extensión de una expresión de clase es:

extend class_expr1 with class_expr2


- 102 -

La expresión de clase class_expr1 es típicamente un nombre de

esquema (“scheme”), mientras que la expresión de clase class_expr2 es típicamente una expresión de clase básica de la forma: class declaration1, . . . declarationn

end como fue planteado en el punto de expresiones de clase básicas. Las expresiones de clase constituyentes deben ser compatibles. Compatibles significa si todas sus definiciones son compatibles. Dos definiciones son compatibles si ellas definen identificadores y operadores distintos ó si ambas son definiciones de valor que definen el mismo identificador u operador pero con tipos maximales distinguibles. Por ejemplo, si el esquema S1 define un tipo llamado T, y si el esquema S2 también define un tipo llamado T, entonces la siguiente extensión no es bien-formada (“well-formed”): extend S1 with S2

Supóngase que cada una de las expresiones de clase class_expri (i ∈ {1, 2}) puede expandirse en una expresión de clase básica de la forma: class declarationi,1

. . . declarationi,ni

end Entonces la extensión anterior se podría expandir en: class declaration1,1

. . . declaration1,n1

declaration2,1

. . . declaration2,n2

end

List (listas) en RSL

Una lista es una secuencia de valores del mismo tipo, posiblemente con valores duplicados. Las listas se encuentran ordenadas, y es posible hablar de:


- 103 -

- Primer valor en una lista. - El número de ocurrencias de un valor particular en dicha lista.

- La cola de la lista.

Una expresión de tipo con la forma type_expr*

representa un tipo de lista finito. Cada lista contiene solamente valores del tipo representado por type_expr. Como ejemplos de listas finitas podemos encontrar:

1. ‹› 2. ‹true› 3. ‹false› 4. ‹true,false› 5. ‹true,true› 6. ‹true,false,true›

En el primer ejemplo se define una lista vacía, en el segundo una lista

con un único elemento true, en el quinto vemos que es una lista con dos elementos repetidos, y así se podría hacer una innumerable lista de ejemplos.

Un tipo de expresión con la forma

Type_expr ω

Representa un tipo de lista finito o infinito. El tipo Bool ω

contiene una lista de

tipos booleanos infinita junto a aquellas listas finitas.

Un ejemplo de listas infinitas es aquella que contiene todos los números primos en order creciente.

Para cualquier tipo T, T* es un subtipo de T ω

.

Una lista puede ser escrita explícitamente enumerando sus elementos.

Los ejemplos vistos anteriormente son de listas definidas explícitamente. La forma general de una expresión de lista enumerada tiene la siguiente forma:

‹expr_valor1,…,expr_valorn›

para n ≥ 0. Cada expresión es evaluada a un valor, el cual es incluido en la lista de


- 104 -

resultado en la posición apropiada. Nótese que el orden de las expresiones sí importa. Como un ejemplo de esto veamos lo siguiente:

‹1,2,3› ≠ ‹3,2,1› Una expresión de lista rango representa una lista de entero en un rango

desde un límite inferior a un límite superior. Ejemplos

‹3 .. 7› = ‹3,4,5,6,7› La forma general de una expresión de lista rango es:

‹expr_valor1 .. expr_valor2› donde expr_valor1 y expr_valor2 son expresiones valuadas a enteros. La

expresión representa la lista ordenada de enteros crecientes entre e incluyendo los dos extremos, siendo expr_valor1 el extremo inferior. En el caso de que expr_valor2 sea menor que expr_valor1, la lista está vacía.

Una nueva lista puede ser generada a partir de una lista existente

aplicando una función a cada miembro de la lista existente. Un ejemplo de esto es la siguiente declaración:

‹2*n | n in ‹0 .. 3››

lo que se lee como: “la lista de valores 2 * n donde n se mueve entre 0 y 3”, por

lo que la lista quedaría como ‹0,2,4,6›. Nótese que el orden de la lista

existente se sigue manteniendo en la lista nueva.

Es posible a través de un predicado limitar la selección de elementos de la lista origen o existente. Consideremos el ejemplo de una lista que consiste en todos los números primos entre 1 y 100, ordenados de forma creciente.

‹n | n in ‹1 .. 100› • es_primo(n) › = ‹2,3,4,7,.....,97›

La forma general de una expresión de lista de forma comprensiva es:

‹expr_valor1 | binding in expr_valor2 • expr_valor3› donde expr_valor2 es una expresión de lista y expr_valor3 es una

expresión de tipo boolean. El “binding” debe concordar con los elementos de la lista representada por expr_valor2.

Un elemento particular de una lista puede ser accedido vía su índice. El

índice tiene que ser un número natural, siendo como mínimo elemento el 1 y como máximo, sólo en el caso de las listas finitas, el número máximo de elementos. Ejemplo:


- 105 -

value l: Nat*

axiom l = ‹10,20,30›

por lo que acceder al elemento dos, se haría de la siguiente forma:

l(2) = 20 La forma general de una expresión de aplicación para este caso sería la

siguiente:

expr_valor1(expr_valor2)

donde expr_valor1 es una expresión de lista y expr_valor2 es una expresión de tipo entero que se evalua a un valor entre uno y la longitud de la lista.

Una lista infinita puede ser definida a través de una definición de valor y un axioma especificando que ésta será infinita. Consideremos el siguiente ejemplo:

value

todos_los_nros_naturales : Natω

axiom todos_los_nros_naturales(1) = 0

∀ idx : Nat •

idx >= 2 ⇒

todos_los_nros_naturales(idx) = todos_los_nros_naturales(idx – 1) + 1 Luego de esta definición de los números naturales a través de una lista

infinita, podríamos deducir la lista de todos los números primos a través de una expresión de lista por comprensión:

‹n | n in todos_los_nros_naturales • es_primo(n)› = ‹2,3,5,7,....›

Para el manejo de listas existen operadores tanto para ser utilizados de forma prefija como infija. A continuación se enumeran cada uno de estos operadores junto a ejemplos que demuestran cómo es su utilización.

- El operador de concatenación, que concatena dos listas:

∧ : T*

× Tω

→ Tω

Como resultado se obtiene una lista conteniendo todos los elementos del primer argumento seguido de los elementos del segundo argumento. Ejemplo:

‹1,2,3› ∧ ‹4,5› = ‹1,2,3,4,5›


- 106 -

- El operador que obtiene la cabeza de una lista:

hd : Tω

→ T

Este operador obtiene el primer elemento de la lista, es decir el elemento que se encuentra más a la izquierda.

hd‹e1,e2,... › = e1

- El operador que obtiene la cola de una lista:

tl : Tω

→ Tω

Este operador obtiene el resto de la lista salvo la cabeza.

tl‹e1,e2,... › = ‹e2, ... ›

- El operador longitud (length) retorna la longitud de una lista finita.

len : Tω

→ Nat Algunos ejemplos:

len ‹2,3,2› = 3

len ‹› = 0

Esta función es una función total cuando se aplica en listas finitas. La aplicación de esta función a una lista infinita retorna chaos.

- El operador inds, devuelve el índice que ocupa un elemento dentro

de una lista.

inds : Tω

→ Nat-infset

- El operador elems, devuelve el elemento que se encuentra en una posición determinada de la lista.

elems : Tω

→ T-infset Set (conjuntos) en RSL

Un conjunto es una colección de valores distintos del mismo tipo. Algunos ejemplos de conjuntos son los siguientes:

{1,2,2} {“Oscar Testa”,”Germán Montejano”,”Daniel Riesco”}

~

~

~

~

~


- 107 -

MARIOTE El primero es un conjunto de enteros, el segundo es un conjunto de textos.

El concepto de conjuntos es ampliamente aceptado por ser muy útil en especificaciones formales. Muchos aspectos de la vida real pueden ser modelados como conjuntos: “el conjunto de habitantes de una ciudad”, “el conjunto de participantes de un curso”, etc.

Una expresión de tipo con la forma expr_tipo-set representa un tipo de

conjunto finito. Cada conjunto es un subconjunto del conjunto de todos los valores en el tipo que representa en expr_tipo.

Una expresión de tipo con la forma expr_tipo-infset representa un tipo

de conjunto infinito. Cada conjunto es un subconjunto del conjunto de todos los valores del tipo representado por expr_tipo.

Un conjunto puede ser escrito explícitamente enumerando sus

miembros. Ejemplos: {1,2,3} {“Juan”,”Pedro”,”José”} {true,false} La forma general para una expresión de conjunto enumerado es la

siguiente: {expr_valor1,....,expr_valorn}

para n ≥ 0.

Cada expresión es evaluada a un valor en el cual se incluye en el conjunto de resultado.

Los conjuntos son desordenados, por lo que la siguiente comparación es

verdadera: {1,2,3} = {3,1,2} El conjunto vació se representa de la siguiente manera: {} Un conjunto puede ser definido implícitamente al dar un predicado con la

definición de sus miembros. Ejemplo:

{2*n | n : Nat • n ≤ 3} Esta expresión se lee de la siguiente manera: el conjunto de valores 2 * n donde n es un número natural tal que n es menor o igual que 3, por lo que el conjunto queda formado como:


- 108 -

{0,2,4,6}

La forma general de una definición de este tipo es la siguiente: {expr_valor1 | tipo1,... tipon • expr_valor2}

Una expresión de conjunto rango da un conjunto de enteros en un rango

desde un valor inicial hasta uno final. Ejemplos: {1 .. 7} = {1,2,3,4,5,6,7}

{3 .. 3} = {3}

La forma general de una definición de este tipo es la siguiente: {expr_valor1 .. expr_valor2 }

donde expr_valor1 y expr_valor2 son expresiones de valores enteros. La expresión representa el conjunto de los enteros entre el valor expr_valor1 y expr_valor2, incluyendo a los mismos. Nótese también que expr_valor1 es menor o igual que expr_valor2, caso contrario el conjunto resultado es vacío.

Para el manejo de conjuntos existen operadores tanto para ser utilizados de forma prefija como infija. A continuación se enumeran cada uno de estos operadores junto a ejemplos que demuestran cómo es su utilización.

- Los operadores de pertenencia o no a un conjunto: ∈ ∉. Se definen de la siguiente manera:

∈ : T × T-infset → Bool ∉ : T × T-infset → Bool Una expresión: e ∈ s es verdadera si y solo sí e es un miembro

del conjunto s. Para la versión negada se tendría: e ∉ s = ~(e ∈ s) Algunos ejemplos:

3 ∈ {1,3} = true

2 ∉ {1,3} = true

2 ∈ {1,3} = false

- Los operadores de unión e intersección permiten generar nuevos conjuntos compuestos por otros dos conjuntos. Las funciones se definen de la siguiente forma:

∪ : T-infset × T-infset → T-infset ∩ : T-infset × T-infset → T-infset

s1 ∪ s2 ≡ {e | e : T • e ∈ s1 ∨ e ∈ s2}


- 109 -

s1 ∩ s2 ≡ {e | e : T • e ∈ s1 ∧ e ∈ s2}

Algunos ejemplos:

{1.3.5} ∪ {5,7} = {1,3,5,7}

{1.3.5} ∩ {5,7} = {5}

{1.3.5} ∩ {6,7} = {}

- El operador de diferencia nos permite generar un nuevo conjunto a partir de otros dos de la siguiente forma:

\ : T-infset × T-infset → T-infset s1 \ s2 ≡ {e | e : T • e ∈ s1 ∧ e ∉ s2}

Algunos ejemplos: {1,3,5} \ {1} = {3,5} {1,3,5} \ {7} = {1,3,5}

- Los operadores de comparación de conjuntos, denominados subconjuntos y subconjunto propio:

⊆ : T-infset × T-infset → Bool ⊂ : T-infset × T-infset → Bool

s1 ⊆ s2 ≡ ∀ e : T • e ∈ s1 ⇒ e ∈ s2

s1 ⊂ s2 ≡ s1 ⊆ s2 ∧ s1 ≠ s2

Algunos ejemplos:

{1,3,5} ⊆ {1,3,5} = true

{1,3} ⊂ {1,3,5} = true - El operador cardinalidad retorna el tamaño de un conjunto finito, es

decir el número de elementos contenidos en el conjunto:

card : T-infset → Nat Algunos ejemplos: card {1,4,6,7} = 3 card {} = 0 card es una función total cuando se aplica a conjuntos finitos. La aplicación de card a un conjunto infinito retorna chaos.

~


- 110 -

Map (mapas) en RSL

Un mapa es una estructura en forma de tabla, muy similar a una función, que relaciona valores de un tipo en valores de otro tipo. Son ejemplos de mapas:

[3 → true, 5 → false]

[“Claudio” → 7, “Juan” → 2, “María” → 7]

El primero es un mapa de enteros a Boolean. El valor 3 está relacionado con true y 5 es relacionado a false. El segundo es un mapa de texto a enteros.

Al conjunto de valores para el cual está definido un mapa se lo llama

dominio del mapa. El segundo mapa del ejemplo anterior tiene como dominio:

{“Claudio”, “Juan”, “María”} El rango de un mapa es el conjunto de valores al cual está relacionado.

El segundo mapa del ejemplo tiene como rango {7, 2}. Los mapas son similares a la funciones en el sentido en que un mapa

puede aplicarse a un valor de dominio para retornar un valor de rango asociado. La diferencia entre funciones y mapas está básicamente en las clases de operadores que se pueden aplicar. Los mapas se pueden ver como conjuntos finitos o infinitos de pares dominio/rango los cuales pueden combinarse (“merged”), restringirse, aumentarse, reducirse, sobrescribirse, etc. Las funciones, en cambio, solamente pueden componerse y aplicarse a argumentos: en particular no se puede (salvo que ellos también dependan de variables) cambiar el conjunto de valores de dominio para los cuales están definidos, o cambiar los resultados de aplicarlos a valores de dominio particulares.

Un ejemplo clásico de mapa es el directorio de archivos de un sistema

operativo. Las expresiones de tipo mapa son de la forma:

type_expr1 m→ type_expr2

representa un tipo de mapas, cada uno asocia valores de type_expr1 a valores de type_expr2. Un mapa puede ser parcial, teniendo un dominio el cual es solamente un subconjunto del conjunto de valores del tipo representado por type_expr1.

Considerar por ejemplo la expresión de tipo:

Text m→ Nat


- 111 -

Este tipo contiene infinita cantidad de mapas:

[ ]

[“3” → 3]

[“Claudio” → 7, “Juan” → 2, “María” → 7] . . .

Nótese que el mapa [ ] vacío está incluido. Los mapas pueden ser infinitos, en el sentido de tener infinitos dominios.

El tipo de mapa anterior también contiene infinitos mapas.

Aquí se presentan conceptos de expresiones “value” de mapa. Un mapa puede escribirse enumerando explícitamente sus asociaciones, como se vio en los ejemplos anteriores.

La forma general de una expresión de mapa enumerada es:

[value _expr1 → value _expr1‘, . . . , value _exprn → value _exprn‘]

para n ≥ 0. Cada par de expresión (value _expri, value _expri‘) evalúa a valores vi y vi‘ y el mapa resultante entonces asocia vi a vi‘. Nótese que el orden de las asociaciones no interesa. Como un ejemplo considérese las dos expresiones de mapa las cuales representan el mismo mapa:

[3 → true, 5 → false] = [5 → false, 3 → true]

Un mapa de particular importancia es el que no tiene asociaciones, llamado mapa vacío: [ ].

Un mapa se puede definir implícitamente dando un predicado que define

las asociaciones. Un ejemplo de tal expresión de mapa por comprensión es:

[ n → 2*n | n : Nat • n ≤ 2 ] = [0 → 0, 1 → 2, 2 → 4] La expresión de mapa por comprensión se lee: “el mapa de n a 2 * n

donde n es un número natural tal que n es menor o igual a 2”. Es posible, vía expresión de mapa por comprensión, crear un mapa

infinito. Considerar por ejemplo:

[ n → 2*n | n : Nat • is_a_prime(n) ] = [2 → 4, 3 → 6, 5 → 10, 7 → 14, . . . ] También es posible crear un mapa que dará resultados no-

determinísticos cuando se aplique. Considerar el siguiente ejemplo:

[ x → y | x, y : Nat • {x, y} ⊆ {1, 2} ]


- 112 -

Este mapa asocia 1 a 1 y también a 2, similarmente ocurre para 2. Tales mapas usualmente deberían evitarse en especificaciones pero es posible crearlos.

La forma general de una expresión de mapa por comprensión es:

[ value_expr1 → value_expr2 | typing1, . . . , typingn • value_expr3 ]

para n ≥ 1, donde value_expr1 es una expresión Boolean. A continuación se desarrollan las formas de aplicación de un mapa. Un

mapa se puede aplicar a un “value” si el “value” pertenece al dominio del mapa. Como ejemplo considerar el mapa m definido así:

value m : Text m→ Nat axiom m = [“Claudio” → 7, “Juan” → 2, “María” → 7]

Entonces aplicando m a “Juan” da el valor 2: m(“Juan”) = 2 La forma general de una expresión de aplicación es: value_expr1(value_expr2)

donde value_expr1 es una expresión de mapa y value_expr2 debe retornar un valor dentro del dominio del mapa. Una expresión de mapa enumerada donde un valor del dominio se asocia a más de un valor del rango cuando se aplica puede dar un resultado no-determinístico. Como por ejemplo, considerar la siguiente aplicación de mapa:

[3 → true, 3 → false] (3)

Esta expresión evalúa a la expresión no-determinística “true false”. Respecto de los operadores prefijo sobre mapas, un operador básico

es el operador dominio el cual para un mapa particular retorna su dominio, el conjunto de valores para los cuales está definido:

dom : (T1 m→ T2) → T1-infset Algunos ejemplos son:

dom [“Claudio” → 7, “Juan” → 2] = {“Claudio”, “Juan”}

dom [ n → 2*n | n : Nat • is_a_prime(n) ] = { n | n : Nat • is_a_prime(n) } dom [ ] = { }

Un operador relacionado es el operador rango el cual retorna el rango


- 113 -

de un mapa:

rng [“Claudio” → 7, “Juan” → 2] = {7, 2}

rng [ n → 2*n | n : Nat • is_a_prime(n) ] = { 2*n | n : Nat • is_a_prime(n) } rng [ ] = { }

Respecto de los operadores infijo sobre mapas, el operador

sobrescribe lo que hace es sobrescribir un mapa con otro:

† : (T1 m→ T2) × (T1 m→ T2) → (T1 m→ T2) La prioridad la dan las asociaciones en el segundo argumento en casos

donde los valores del dominio hagan match. Algunos ejemplos son:

[3 → true, 5 → false] † [5 → true] = [3 → true, 5 → true]

[3 → true] † [5 → false] = [3 → true, 5 → false]

[3 → true] † [ ] = [3 → true] El operador unión combina dos mapas de una manera similar al operador sobrescribir:

∪ : (T1 m→ T2) × (T1 m→ T2) → (T1 m→ T2) Un ejemplo es:

[3 → true] ∪ [5 → false] = [3 → true, 5 → false] El operador unión se usa típicamente cuando se quiere indicar que se

conoce que los dos argumentos tienen dominios disjuntos. Hay dos operadores para restringir el dominio de un mapa llamados

“restringido por” y “restringido a”:

\ : (T1 m→ T2) × T1-infset → (T1 m→ T2)

/ : (T1 m→ T2) × T1-infset → (T1 m→ T2) El restringido por “\” remueve un conjunto de valores de dominio de un

mapa; el restringido a “/” restringe el dominio a un conjunto de valores de dominio. Ellos se definen como sigue:

m \ s = [ d → m(d) | d : T1 • d ∈ dom m ∧ d ∉ s ]

m / s = [ d → m(d) | d : T1 • d ∈ dom m ∧ d ∈ s ] Algunos ejemplos son:

[3 → true, 5 → false] \ {3} = [5 → false]

[3 → true, 5 → false] / {3} = [3 → true]

[3 → true, 5 → false] \ {3, 5, 7} = [ ]

[3 → true, 5 → false] / {3, 5, 7} = [3 → true, 5 → false]


- 114 -

El operador de composición de mapa hace posible componer dos

mapas:

º : (T2 m→ T3) × (T1 m→ T2) → (T1 m→ T3) El resultado de componer dos mapas m1 y m2 se define como sigue:

m1 º m2 = [ x → m1(m2(x)) | x : T1 • x ∈ dom m2 ∧ m2(x) ∈ dom m1 ] Algunos ejemplos son:

[3 → true] º [“Claudio” → 3] = [“Claudio” → true]

[3 → true, 5 → false] º [“Claudio” → 3, “Juan” → 7] = [“Claudio” → true]

[3 → true] º [“Claudio” → 5] = [ ] La segunda y tercera composiciones de mapa muestran qué sucede

cuando el rango del segundo argumento incluye valores que no están en el dominio del primer argumento: las asociaciones para las cuales no existen match son removidas.

Especificación formal de los Tipos Abstractos de Datos (ADTs) Los tipos abstractos de datos son aquellos definidos por el OGC, los

cuales representan tipos de información bien formados, que son aquellos que forman el framework del servidor de dispositivos móviles también especificado por el OGC.

Estos tipos abstractos de datos intentan representar estructuras de

información que son necesarias para la comunicación entre los servicios del framework y los clientes que hacen uso de ellos de manera tal que la comunicación sea estándar.

Esta especificación extiende la especificación BASE_SPECIFICATIONS,

ya que se hacen uso de los tipos y values allí especificados. Estos tipos abstractos se basan fundamentalmente sobre las especificaciones bases en el sentido de que éstas son los elementos básicos del SIG. Es decir, que aquí se introduce el concepto de extensión de una estructura de clase.

A continuación se irán detallando las distintas definiciones utilizadas: scheme ADT =

extend BASE_DEFINITIONS with

class

type

ADT_ADDRESS = STREET × PLACE × POSTAL_CODE × STREET_LOCATOR ×

BUILDING_LOCATOR × ADDITIONAL,

ADT_POI = NAME × TYPE × CATEGORY × ADT_ADDRESS ×

PHONE_NUMBER × ADDITIONAL,

ADT_AOI == empty | CIRCLE | BBOX | POLYGON,


- 115 -

Aquí se puede apreciar las definiciones más complejas de estos tipos de datos que son específicos del framework. Podemos ver que ADT_ADDRESS está compuesto por otros tipos que están definidos más delante de manera simple como es el caso de STREET, PLACE, POSTAL_CODE, etc. Este tipo de dato representa una dirección en el plano, para ser ubicada. A través de esta representación también se pueden hacer búsquedas de lugares determinados. Por ejemplo: ubicar un restaurante chino a través de su dirección, barrio y calle, o bien en forma inversa donde se solicita al framework que determine el restaurante más próximo a un determinado hotel, donde la información que es devuelta por el servicio es a través del tipo abstracto ADT_ADDRESS.

También se declaran los tipos ADT_POI, cuya finalidad es la de

determinar un punto de interés en el plano. Por ejemplo un punto de interés podría ser un hotel, de la categoría de hospedajes, o con un determinado número de teléfono.

Lo mismo ocurre con el tipo ADT_AOI, que representa un área de

interés, el cual está definido por una definición de tipo variant, que permite definirse como un círculo, un BBOX o un POLYGON, todos estos tipos se encuentran ya definidos en el esquema BASE_DEFINITIOSN.

CAMPO = {| x : Text • x = "PLACE" ∨ x = "CATEGORY" ∨ x =

"SUBCATEGORY" ∨ x = "NAME" ∨ x = "STREET" ∨ x = "POSTAL_CODE" ∨ x = "PHONE_NUMBER" |},

VALOR = Text,

Aquí se definen los tipos CAMPO y VALOR que luego son utilizados en el

servicio de directorio. Se utilizan básicamente para el pasaje de parámetros a la función.

El resto de las definiciones de tipos se presentan a continuación:

ROUTE_PLAN=PREFERENCE × Bool × START_TIME, PREFERENCE == Fatest | Shortest | Pedestrian,

START_TIME,

DIRECTORY_TYPE,

PLACE = Text,

POSTAL_CODE = Text,

STREET_LOCATOR = Text,

BUILDING_LOCATOR = Text,

ADDITIONAL = Text,

CATEGORY = Text,

PHONE_NUMBER = Text

Estos tipos definidos aquí son los que complementan las definiciones de

los tipos compuestos definidos inicialmente en este esquema. El esquema también contempla la definición de “values”, que se

presentan a continuación: value

within : ADT_AOI × POINT → Bool,


- 116 -

within : ADT_AOI × SEGMENT → Bool,

within : ADT_AOI × POLYLINE → Bool,

address_completa : POINT × ADT_AOI × ADT_ADDRESS × POINT → Real,

address_completa : ADT_ADDRESS → ADT_ADDRESS,

obtener_punto : ADT_ADDRESS → POINT,

obtener_punto : ADT_POI → POINT,

obtener_precision : ADT_ADDRESS → Real,

distancia: ADT_MAP × (Text m→ Text) × DIRECTORY_TYPE → Real,

obtener_atributo_bd: STREET � PLACE × POSTAL_CODE → ATTR,

existe_en_directory: DIRECTORY_TYPE × Text × Text → Bool

Estos valores, que terminan siendo definiciones de funciones, no se

implementan ya que como se mencionaba en las especificaciones anteriores, no es necesario a este nivel especificar con tanto nivel de detalle. Estas funciones normalmente vienen resueltas con los software de sistemas de información geográfica como funciones básicas.

A continuación se presenta el listado completo de las especificaciones

del presente esquema. scheme ADT =


class

type

ADT_ADDRESS = STREET × PLACE × POSTAL_CODE × STREET_LOCATOR ×

BUILDING_LOCATOR × ADDITIONAL,

ADT_POI = NAME × TYPE × CATEGORY × ADT_ADDRESS ×

PHONE_NUMBER × ADDITIONAL,


CAMPO = {| x : Text • x = "PLACE" ∨ x = "CATEGORY" ∨ x =

"SUBCATEGORY" ∨ x = "NAME" ∨ x = "STREET" ∨ x = "POSTAL_CODE" ∨ x = "PHONE_NUMBER" |},

VALOR = Text,

ROUTE_PLAN=PREFERENCE × Bool × START_TIME, PREFERENCE == Fatest | Shortest | Pedestrian,

START_TIME,

DIRECTORY_TYPE,

PLACE = Text,

POSTAL_CODE = Text,



ADDITIONAL = Text,

CATEGORY = Text,

PHONE_NUMBER = Text

value

within : ADT_AOI × POINT → Bool,

within : ADT_AOI × SEGMENT → Bool,

within : ADT_AOI × POLYLINE → Bool,

address_completa : POINT × ADT_AOI × ADT_ADDRESS × POINT → Real,

address_completa : ADT_ADDRESS → ADT_ADDRESS,


- 117 -

obtener_punto : ADT_ADDRESS → POINT,

obtener_punto : ADT_POI → POINT,

obtener_precision : ADT_ADDRESS → Real,

distancia: ADT_MAP × (Text m→ Text) × DIRECTORY_TYPE → Real,

obtener_atributo_bd: STREET � PLACE × POSTAL_CODE → ATTR,

existe_en_directory: DIRECTORY_TYPE × Text × Text → Bool end

Especificación formal de los servicios del framework

El presente esquema, el cual se deriva de los dos anteriormente descriptos, es el que contiene las especificaciones de los servicios que expone el framework hacia los clientes. Aquí es donde se plasman todas las definiciones de la infraestructura que se ha propuesto y que se ha estudiado en el capítulo 2.

Dentro de las especificaciones del esquema, algunas de ellas son las

que expone el framework para la utilización por parte de los clientes, y otras especificaciones que son utilizadas por las anteriores a fin de poder llevar a cabo el trabajo específico.

También es importante mencionar que en este esquema se hacen uso

de las definiciones de los esquemas anteriores: BASE_SPECIFICATIONS y ADT, ya que estas son la base necesaria de la infraestructura.

A continuación se van a ir describiendo cada uno de los servicios junto a

su definición en RSL, para luego sí brindar un listado completo del esquema.

geocode: (ADT_ADDRESS)-set × ADT_MAP →

(ADT_ADDRESS × POINT × Real)-set

geocode(lista_geocod, mapa) ≡ let (layers, proj, box) = mapa in

{(address_completa(direccion),

obtener_punto(direccion),

obtener_precision(direccion)) |

direccion : ADT_ADDRESS, posicion : POINT,

precision : Real •

(all direccion : ADT_ADDRESS •

direccion isin lista_geocod ∧

es_geocodificable(direccion, layers))}

end,

Este servicio, que es de uso público para los objetos que lo requieran,

permite convertir un conjunto de direcciones, ADT_ADDRESS-set, en un conjunto de puntos geográficos en el plano. El conjunto de puntos de resultado equivale a la posición geográfica (latitud, longitud) que le corresponde por la dirección postal (calle – altura - ciudad –cp).

El resultado puede ser cero, uno o más direcciones geocodificadas,

dependiendo de la solicitud realizada, el algoritmo utilizado y el criterio de


- 118 -

búsqueda. A continuación se listan los requerimientos que debe cumplir este servicio:

- Dada una dirección (ADT_ADDRESS), tiene que ser capaz de utilizar

un algoritmo de geocodificación para determinar una posición geográfica para la dirección especificada.

- Tiene que ser capaz de realizar una geocodificación con una

dirección incompleta y retornar una dirección completa.

- Tiene que indicar la cantidad de coincidencias en la respuesta.

- Tiene que ser capaz de procesar más de una dirección en un único llamado.

- Puede llegar a proveer información acerca de la calidad en el

proceso de geocodificación. reverse_geocode :

ADT_MAP × POINT × ADT_AOI →


reverse_geocode(mapa, posicion, area) ≡ let (layers, proj, box) = mapa in

{address_completa(posicion, area) |

resultado : ADT_ADDRESS × POINT × Real •

(all layer : LAYER •

layer isin layers ∧

buscar_lugares(layer, posicion, area))}

end,


permite obtener una dirección completa, normalizada de nombre de calle, lugar, código postal y altura a partir de una posición geográfica dada.

El resultado puede ser cero, uno o más direcciones, dependiendo de la

solicitud realizada, el algoritmo utilizado y el criterio de búsqueda. A continuación se listan los requerimientos que debe cumplir este servicio:

- Dada una dirección (ADT_ADDRESS), tiene que ser capaz de utilizar

un algoritmo de geocodificación para determinar una posición geográfica para la dirección especificada.

- Tiene que ser capaz de realizar una geocodificación con una

dirección incompleta y retornar una dirección completa.

- Tiene que indicar la cantidad de coincidencias en la respuesta.

- Tiene que ser capaz de procesar más de una dirección en un único llamado.


- 119 -

- Puede llegar a proveer información acerca de la calidad en el proceso de geocodificación.

directory: ADT_MAP × ADT_ADDRESS × Real × Real × Real × ADT_AOI

× DIRECTORY_TYPE × (CAMPO m→ VALOR) → (ADT_POI × Real)-set directory(mapa, direccion, within_distance, max_distance,

min_distance, withinboundary, directory, valores) ≡

{(punto_of_interes(valores,directory),distancia(mapa,valores,dir

ectory)) | punto: ADT_POI, distancia: Real •

(all clave : Text • clave ∈ dom(valores)

∧ existe_en_directory(directory,clave,valores(clave)) ∧

(within(obtener_punto(direccion),min_distance) ∨

within(obtener_punto(direccion),max_distance) ∨ within(withinboundary,obtener_punto(direccion))))

},

directory: ADT_MAP × DIRECTORY_TYPE × (CAMPO m→ VALOR) →

(ADT_POI × Real)-set

directory(mapa, directory, valores) ≡ {(punto_of_interes(valores,directory),distancia(mapa,valores,dir



∧ existe_en_directory(directory,clave,valores(clave)))

},


permite acceder a un directorio en línea para ubicar un lugar, servicio o producto específico o bien el más cercano a un determinado punto o ubicación. En base a los parámetros que se le pasan a este servicio, comienza con la búsqueda en el directorio específico o que más se adecue (páginas amarillas, guía de restaurantes, etc.), tratando de ubicar el lugar, producto o servicio específico o más cercano, de acuerdo a lo solicitado.

Como resultado brinda un conjunto de tipos abstractos de datos

(ADT_POI) junto a un número de orden en base a los resultados obtenidos de acuerdo a los parámetros de la búsqueda.

En este caso se hizo sobrecarga de funciones, característica de la

programación orientada a objetos que es totalmente utilizable y aplicable en RSL. De esta forma se pueden especificar las distintas alternativas en que se puede llamar este servicio desde otros objetos.

route: ADT_MAP × ADT_POI × ADT_POI × ROUTE_PLAN ×

ADT_POI-list × Real → (ADT_POI × SEGMENT)-list

route(mapa, inicio, fin, plan, puntos_int, scale) ≡ let (preferencia,rt_traffic,comienzo) = plan in

case preferencia of

Fatest → ‹(inicio,obtener_segmento(mapa,inicio,fin))› ∧


- 120 -

route(mapa, hd puntos_int, fin, plan, tl puntos_int,

scale),

Shortest → ‹(inicio,obtener_segmento(mapa,inicio,fin))› ∧


scale),

Pedestrian → ‹(inicio,obtener_segmento(mapa,inicio,fin))› ∧ route(mapa, hd puntos_int, fin, plan, tl puntos_int,

scale)

end

end,


permite obtener una ruta que una dos puntos, el de inicio y el de fin. En esta ruta deberá contemplar si hiciera falta los puntos intermedios que puedan ser especificados por el objeto que lo solicita. La petición de la ruta debe indicar el modo en que se realiza: a pie, la ruta más corta, la ruta más rápida.

La especificación recibe un mapa (ADT_MAP), el punto de origen o

partida y el de destino (ADT_POI), un plan de ruta (ROUTE_PLAN), una lista de puntos intermedios (ADT_POI-list, la cual puede ser vacía) y una escala en la cual se pretende el resultado (Real). Esta especificación es recursiva, ya que se va llamando a sí misma por cada par de puntos intermedios que hay que pasar, si es que están especificados, de lo contrario se solicita únicamente entre el inicio y el fin, tratando de buscar la mejor alternativa de acuerdo a lo solicitado por el usuario del servicio.

Se hace uso de una función interna, que no es de uso público

“obtener_segmento”, y que devuelve el mejor segmento entre los dos puntos solicitados. El código de esta función se muestra más abajo en la especificación.

buffer: ADT_MAP × ADT_POI × Real-list → CIRCLE-list

buffer(mapa,centro,radios) ≡

‹ (obtener_punto(centro), hd radios) › ^ buffer(mapa,centro,tl radios)

pre radios ≠ ‹›, Este servicio, que es de uso público para los objetos que lo requieran,

permite obtener una región de influencia (buffer) alrededor de una lista de puntos que se le envían al servicio como parámetro. También recibe la lista de radios que contendrá cada una de las regiones a generar a partir de los puntos dados.

En este caso se hizo uso, como en los casos anteriores, de la

recursividad en la definición, lo que permite que se vayan generando las distintas regiones o áreas de influencia una a una a partir de la lista enviada. Por cada vez que se llama recursivamente, se envía la cabeza y la cola de la lista para ser procesada en cada llamada.

~


- 121 -

Esta definición tiene como precondición que la lista a generar debe ser no vacía, ya que carece de sentido generar una lista de áreas de influencia a partir de una lista vacía de puntos.

highway_states: ADT_MAP × BBOX → (SEGMENT × STYLE)-set

highway_states(mapa,bounding_box) ≡ let (layers, proj, box) = mapa in

{(segmento, arma_estilo(segmento)) | segmento: SEGMENT,

estilo: STYLE •

(all capa: LAYER • capa ∈ layers ∧

let

(puntos, segmentos, polilineas, poligonos, nombre,

proyeccion, bbox) = capa in

(all (segmento,atributo): SEGMENT × ATTR •

(segmento,atributo) ∈ segmentos ∧ ishighway(segmento))

end

)

}

end,

Este servicio, que es de uso público para los objetos que lo requieran, permite obtener el estado actual de rutas, autopistas, o cualquier otro tipo de vía de comunicación. El análisis se realiza sobre un mapa y una zona de influencia (BBOX), y devuelve un conjunto de segmentos y estilos asociados, logrando de esta manera mostrar gráficamente (a través del uso de estilos) el estado de cada carretera en cada uno de los tramos que la componen. El análisis se realiza sobre los datos que están en ese momento almacenados en el repositorio de datos que corresponda.

Para poder realizar el análisis, se deben recorrer las capas que

corresponden, y verificando si cada segmento que allí se encuentra es una carretera, autopista, etc., y armando el estilo en base a la información disponible. Estas funciones de las que se vale este servicio son de uso privado y se muestra, tal como se mencionó previamente, más abajo en la especificación.

get_map: ADT_MAP × POINT × Real × NAME-list → IMAGEN

get_map(mapa,centro,escala, lista_layers) ≡ let (layers, proj, box) = mapa in

obtener_imagen(mapa,get_layers(layers,lista_layers),centro,

escala)

end,


brinda la posibilidad de obtener en forma de imagen un trozo del mapa sobre el cual se está trabajando. Para ello necesita que se le especifique el mapa (ADT_MAP), un punto central (POINT), una escala sobre la cual trabajar, y una lista de capas a ser incluidas en la generación. Como resultado se obtiene una


- 122 -

imagen en formato específico (de acuerdo a la implementación final). El servicio se vale de la función “obtener_imagen”, la cual es de uso

privado, que normalmente se encuentra ya codificada e implementada en los software de información geográfica.

A continuación se muestra un listado de las especificaciones de las

funciones de uso privado, que son utilizadas por las interfaces públicas de la presente especificación del framework.

es_geocodificable : ADT_ADDRESS × LAYER-set → Bool

es_geocodificable(direccion, layers) ≡ let

(calle, lugar, cp, calle_l, building_l, adicional) =

direccion

in

if calle ≠ "" ∧ cp ≠ "" then

(all capa : LAYER •

capa ∈ layers ∧

encontrar_segmento(calle, lugar, cp, capa))

else false

end

end,

encontrar_segmento : STREET × PLACE × POSTAL_CODE × LAYER → Bool

encontrar_segmento(calle, lugar, cp, capa) ≡ let


proyeccion, bbox) = capa

in

(all (segmento, atributo) : SEGMENT × ATTR •

(segmento, atributo) ∈ segmentos ∧ (atributo =

obtener_atributo_bd(calle,lugar,cp))) ∨

(all (polilinea, atributo) : POLYLINE × ATTR •

(polilinea, atributo) ∈ polilineas ∧ (atributo =

obtener_atributo_bd(calle,lugar,cp)))

end,

buscar_lugares : LAYER × POINT × ADT_AOI → Bool

buscar_lugares(capa, posicion, area) ≡ let



in

((all (punto, atributo) : POINT × ATTR •

((punto, atributo) ∈ puntos ∧

(punto = posicion ∨ within(area, punto)))) ∨


((segmento, atributo) ∈ segmentos ∧


- 123 -

(intersects(segmento, posicion) ∨

within(area, segmento)))) ∨

(all (multilinea, atributo) : POLYLINE × ATTR •

((multilinea, atributo) ∈ polilineas ∧

(intersects(multilinea, posicion) ∨

within(area, multilinea)))) ∨

(all (region, atributo) : POLYGON × ATTR •

((region, atributo) ∈ poligonos ∧

(intersects(region, posicion) ∨ within(area, region)))))

end ,

punto_of_interes: (CAMPO → VALOR) × DIRECTORY_TYPE → ADT_POI,

obtener_segmento: ADT_MAP × ADT_POI × ADT_POI → SEGMENT,

ishighway: SEGMENT → Bool,

obtener_layer: ADT_MAP × NAME → LAYER,

get_layers: LAYER-set × NAME-list → LAYER-set

get_layers(layers,lista_layers) ≡

{capa | capa: LAYER • let (puntos, segmentos, polilineas, poligonos, nombre,


(all capa: LAYER • capa ∈ layers ∧ nombre = hd

lista_layers)

end

} ∪ get_layers(layers,tl lista_layers)

end

Ahora sí, luego de haber presentado una por una las especificaciones

públicas, y las privadas se presenta el listado completo de las especificaciones del presente esquema. scheme FRAMEWORK =

extend ADT with

class

value

geocode: (ADT_ADDRESS)-set × ADT_MAP →


geocode(lista_geocod, mapa) ≡ let (layers, proj, box) = mapa in





precision : Real •

(all direccion : ADT_ADDRESS •

~


- 124 -

direccion isin lista_geocod ∧


end,

reverse_geocode :

ADT_MAP × POINT × ADT_AOI →


reverse_geocode(mapa, posicion, area) ≡ let (layers, proj, box) = mapa in


resultado : ADT_ADDRESS × POINT × Real •

(all layer : LAYER •

layer isin layers ∧


end,

directory: ADT_MAP × ADT_ADDRESS × Real × Real × Real × ADT_AOI

× DIRECTORY_TYPE × (CAMPO m→ VALOR) → (ADT_POI × Real)-set directory(mapa, direccion, within_distance, max_distance,

min_distance, withinboundary, directory, valores) ≡

{(punto_of_interes(valores,directory),distancia(mapa,valores,dir



∧ existe_en_directory(directory,clave,valores(clave)) ∧

(within(obtener_punto(direccion),min_distance) ∨

within(obtener_punto(direccion),max_distance) ∨ within(withinboundary,obtener_punto(direccion))))

},

directory: ADT_MAP × DIRECTORY_TYPE × (CAMPO m→ VALOR) →

(ADT_POI × Real)-set

directory(mapa, directory, valores) ≡ {(punto_of_interes(valores,directory),distancia(mapa,valores,dir



∧ existe_en_directory(directory,clave,valores(clave)))

},

route: ADT_MAP × ADT_POI × ADT_POI × ROUTE_PLAN ×

ADT_POI-list × Real → (ADT_POI × SEGMENT)-list

route(mapa, inicio, fin, plan, puntos_int, scale) ≡ let (preferencia,rt_traffic,comienzo) = plan in

case preferencia of

Fatest → ‹(inicio,obtener_segmento(mapa,inicio,fin))› ∧


scale),

Shortest → ‹(inicio,obtener_segmento(mapa,inicio,fin))› ∧



- 125 -

scale),

Pedestrian → ‹(inicio,obtener_segmento(mapa,inicio,fin))› ∧ route(mapa, hd puntos_int, fin, plan, tl puntos_int,

scale)

end

end,

buffer: ADT_MAP × ADT_POI × Real-list → CIRCLE-list

buffer(mapa,centro,radios) ≡

‹ (obtener_punto(centro), hd radios) › ^ buffer(mapa,centro,tl radios)

pre radios ≠ ‹›,

highway_states: ADT_MAP × BBOX → (SEGMENT × STYLE)-set

highway_states(mapa,bounding_box) ≡ let (layers, proj, box) = mapa in

{(segmento, arma_estilo(segmento)) | segmento: SEGMENT,

estilo: STYLE •

(all capa: LAYER • capa ∈ layers ∧

let



(all (segmento,atributo): SEGMENT × ATTR •

(segmento,atributo) ∈ segmentos ∧ ishighway(segmento))

end

)

}

end,

get_map: ADT_MAP × POINT × Real × NAME-list → IMAGEN

get_map(mapa,centro,escala, lista_layers) ≡ let (layers, proj, box) = mapa in

obtener_imagen(mapa,get_layers(layers,lista_layers),centro,

escala)

end,

es_geocodificable : ADT_ADDRESS × LAYER-set → Bool

es_geocodificable(direccion, layers) ≡ let


direccion

in

if calle ≠ "" ∧ cp ≠ "" then

(all capa : LAYER •

capa ∈ layers ∧


else false

end

~


- 126 -

end,

encontrar_segmento : STREET × PLACE × POSTAL_CODE × LAYER → Bool

encontrar_segmento(calle, lugar, cp, capa) ≡ let



in


(segmento, atributo) ∈ segmentos ∧ (atributo =

obtener_atributo_bd(calle,lugar,cp))) ∨

(all (polilinea, atributo) : POLYLINE × ATTR •

(polilinea, atributo) ∈ polilineas ∧ (atributo =


end,

buscar_lugares : LAYER × POINT × ADT_AOI → Bool

buscar_lugares(capa, posicion, area) ≡ let



in

((all (punto, atributo) : POINT × ATTR •

((punto, atributo) ∈ puntos ∧

(punto = posicion ∨ within(area, punto)))) ∨


((segmento, atributo) ∈ segmentos ∧

(intersects(segmento, posicion) ∨

within(area, segmento)))) ∨

(all (multilinea, atributo) : POLYLINE × ATTR •

((multilinea, atributo) ∈ polilineas ∧

(intersects(multilinea, posicion) ∨

within(area, multilinea)))) ∨

(all (region, atributo) : POLYGON × ATTR •

((region, atributo) ∈ poligonos ∧

(intersects(region, posicion) ∨ within(area, region)))))

end ,

punto_of_interes: (CAMPO → VALOR) × DIRECTORY_TYPE → ADT_POI,

obtener_segmento: ADT_MAP × ADT_POI × ADT_POI → SEGMENT,

ishighway: SEGMENT → Bool,

obtener_layer: ADT_MAP × NAME → LAYER,

get_layers: LAYER-set × NAME-list → LAYER-set

get_layers(layers,lista_layers) ≡

~


- 127 -

{capa | capa: LAYER • let (puntos, segmentos, polilineas, poligonos, nombre,


(all capa: LAYER • capa ∈ layers ∧ nombre = hd

lista_layers)

end

} ∪ get_layers(layers,tl lista_layers)

end

Así se ha llegado a especificar el framework en su totalidad, de manera formal a través de la herramienta de especificación RSL. Es importante mencionar en este punto que el lector puede encontrar el listado completo de todas las especificaciones en el Anexo I del presente trabajo. Allí se encuentra la especificación de forma completa junto a los comentarios necesarios para poder comprender el código sin tener que referenciar permanentemente el presente capítulo.

El listado del Anexo I puede ser directamente insertado en la

herramienta para el chequeo de sintaxis. En el Anexo II el lector podrá encontrar las pantallas con los resultados del chequeo de sintaxis realizado en la herramienta. Por último, en el Anexo III se encuentran las capturas de pantallas de la generación de “confidence conditions” para que el lector pueda comprobar la veracidad de las especificaciones.

Conclusiones

- 128 -

6. CONCLUSIONES

Para la toma de decisiones hay una clara necesidad, en todos los

niveles, de poder acceder, integrar y usar los datos espaciales provenientes de diversas fuentes. Así pues, la capacidad para tomar decisiones colectivas acertadas local, regional y globalmente, depende de la puesta en práctica de una Infraestructura de Datos Geográficos que proporcione compatibilidad a través de jurisdicciones, promoviendo el acceso y la utilización de los datos.

La utilización de información geográfica en las distintas organizaciones

se ha vuelto muy importante, sólo basta recordar que el 80% de los negocios requieren de servicios o prestaciones de localización geográfica. Por lo tanto podemos decir que un SIG es a las organizaciones lo que el instrumental de vuelo es al avión.

Actualmente, como se ha visto en la presentación de la infraestructura,

no existen especificaciones de servicios que permita a la organización el desarrollo de sistemas de información geográficos de manera rápida y sencilla, siguiendo modelos establecidos y utilizando cartografía y datos espaciales existentes y probados.

El sustancial aporte a la confiabilidad que puede lograrse mediante la

utilización adecuada de los métodos formales es particularmente relevante en el caso de los servicios Web de SIG.

La inversión significativa, en tiempo y en esfuerzo, asociada a la

aplicación de métodos formales, posee un recupero muy tangible y contundente al posibilitar, como mencionábamos en el párrafo anterior, el desarrollo rápido y sencillo de sistemas de información geográficos.

Los requerimientos específicos correspondientes a la especificación de

un desarrollo en particular de un SIG, frecuentemente se ven afectados por los efectos perniciosos de la ambigüedad, la incompletitud e inconsistencias que se detectan en abundancia cuando se utilizan métodos y herramientas menos rigurosos que los métodos formales.

La confiabilidad, definida como “que el sistema haga el trabajo que se

supone que debe hacer”, es un requerimiento tanto para el hardware como para el software, aunque aquí se orienta a las componentes de software solamente. La idea básica es que es posible razonar acerca de las propiedades del software o sistemas que involucran software.

Se han presentado por un lado los requerimientos funcionales más

comúnmente explicitados durante el desarrollo de un sistema de información geográfica y se ha desarrollado una especificación formal orientada a la construcción de sistemas de información geográfica de manera automática y de muy alta calidad/confiabilidad, el cual puede ser aplicado de forma directa en aquellas organizaciones que quieran desarrollar una solución de software con una dimensión geográfica de sus negocios.

Conclusiones

- 129 -

Se ha comprobado que el método RAISE y su lenguaje de especificación formal RSL han sido altamente exitosos, por las ventajas de los métodos formales antes mencionadas, para modelar formalmente los servicios planteados en la infraestructura. Por lo tanto se puede concluír cabalmente que se ha alcanzado el objetivo planteado.

Futuras Extensiones

- 130 -

7. FUTURAS EXTENSIONES

Dentro de los trabajos futuros se encuentra principalmente continuar en

la línea de producción de nuevos servicios o funcionalidades expuestas por la infraestructura para poder brindar una mayor base de conocimiento y de partida para las aplicaciones específicas que se quieran llevar adelante. También se encuentra el desarrollo de servicios más específicos.

Dentro de los servicios a especificar formalmente se encuentran los

siguientes: - Servicios que permitan la combinación de objetos geográficos para formar

nuevas características. Esto permite la generación de nuevos objetos geográficos a partir de accidentes geográficos existentes. Por ej: generación de una nueva parcela como combinación de dos existentes.

- Servicios específicos para áreas determinadas como puede ser el turismo.

De esta forma se puede hacer más específico la arquitectura para turismo. Ej.: generar un nuevo servicio de route (heredado del ya realizado) que permita la generación de un camino donde se encuentren determinados hitos (museos, localidades con historia relacionada, etc.). De la misma forma se podría pensar para otras áreas de gobierno.

- Servicios exclusivos para redes de servicios: energía eléctrica, agua, gas,

telefonía. Por ej: se podría pensar en realizar servicios que recorran a partir de un nodo determinado de una red eléctrica todos los elementos que se encuentran “aguas abajo” de dicho punto determinando de esta forma usuarios afectados por un corte programado.

- La construcción de una aplicación que utilice la definición de la

arquitectura aquí expuesta para poder mostrar fehacientemente el uso de la misma.

Referencias

- 131 -

REFERENCIAS

[1] The RAISE Method Group, “The RAISE Development Method”, The

Practitioner Series, Prentice-Hall, 1995.

[2] Clarke, E; Wing, J., “Formal Methods: State of the Art and Future Directions”.

[3] Ethan, Cerami, “Web Services Essentials – Distributed Applications with

XML-RPC, SOAP, UDDI & WSDL”, O’Reilly, 1th ed, 2002. [4] Newcomer, Eric, “Understanding Web Services Xml Wsdl Soap And

Uddi”, Addison Wesley.

[5] Infraestructure for Spatial Information in the European Community; http://www.ec-gis.org/inspire/

[6] The Open Geospatial Consortium Inc.; http://www.opengeospatial.org/

[7] National Spatial Data Infraestructure; http://www.fgdc.gov/framework

[8] Proyecto Sistema de Información Geográfica Nacional de la República

Argentina; http://www.sig.gov.ar [9] The RAISE Language Group, “The RAISE Specification Language”, The

BCS Practitioner Series, Prentice-Hall, 1992. [10] Kennedy, Melita, Kopp, Steve, “Understanding Map Projections”, ESRI

Series, 2000. [11] Kolodziej, Kris, “OpenGIS Web Map Server Cookbook”, OGC Document,

2003. [12] Harmon, John, Anderson, Steven, “The design and implementation of

Geographic Information Systems”, Wiley, 2003. [13] Nirvana, Storage, “Geospatial Data and Storage Resource Broker”,

Online GIS Integration in ESRI Environments with SRB MapServer and Centera, White Paper.

[14] Birbeck, Mark, Diamond, Jason, Duckett, Jon, Gudmundsson, Oli,

Kobak, Pete, Lenz, Evan, “Professional XML”, Wrox Press, 2nd ed., 2001. [15] Open Gis Consortium, “OpenGis Location Services (OpenLS): Core

Services”, Open Gis Consortium , 2004. [16] Open Gis Consortium, “OpenGis Web Services”, Open Gis Consortium,

2003. [17] Open Gis Consortium, “Web Feature Service Implementation

Referencias

- 132 -

Specification”, Open Gis Consortium, 2005. [18] Open Gis Consortium, “OpenGIS Web Services Common Specification”,

Open Gis Consortium, 2005. [19] Open Gis Consortium, “Geography Markup Language (GML) simple

features profile”, Open Gis Consortium, 2006. [20] Microsoft Virtual Earth, MapPoint Web Service

http://www.microsoft.com/virtualearth/products/geo_overview.mspx [21] Somers, Rebecca, Claire, Somers-St., “Framework – Introduction and

Guide”, Federal Geographic Data Committee, 1997. [22] “Gis Web Services – The changing GIS Landscape”, White paper,

GisFactory, 2003. [23] “Directiva 2007/2/CE”, Parlamento Europeo, 2007. [24] Anexo I – Términos de Referencia del Proyecto Sistema de Información

Geográfica Nacional de la República Argentina, 2004. [25] Dang, Van Hung, George, Chris, Janowski, Tomasz, Moore, Richard,

“Specification Case Studies in RAISE”, UNU-IIST, 2002. [26] Davis, David E., “GIS for Everyone”, ESRI Inc., 3rd ed., 2003. [27] Davis, Bruce E., “GIS: A Visual Approach”, Onword Press Thomson

Learning, 2nd ed., 2001. [28] Schuurman, Nadine, “GIS: a short introduction”, Blackwell Publishing,

2004. [29] Tomilson, R., “Thinking about GIS. Geographical Information System

Planning for Managers”, ESRI Press, 2003. [30] Rigaux, P.; Scholl,M. & Voisard, A. “Introduction to Spatial Databases:

Applications to GIS”, Morgan, 2001. [31] Rigaux, P.; Scholl, M. & Voisard, A, “Introduction to Spatial Databases:

Applications to GIS”, Morgan Kaufmann, 2001. [32] Luo, Yingwei, Wang, Xiaolin, Xu, Zhuoqun, “Design of a Framework for

Multi-User/Application Oriented WebGIS Services”, Computer Networks and Mobile Computing, 2001. Proceedings. 2001 International Conference on, IEEE, 2001.

[33] Yan, Liu, Mingguang, Zhuang, Qingling, Wang,Biao, Yu, “UTISP: An

Urban Traffic Information Portal based on WebGIS”, The Third International Conference on Internet and Web Applications and

Referencias

- 133 -

Services, IEEE, 2008. [34] Zhiming, GUI, Kai, SONG, “Building Improved GIS Service Based on

WSRF”, International Conference on Internet Computing in Science and Engineering, IEEE, 2008.

[35] Do-Hyun, Kim, Kwang-Soo, Kim, Haeock, Choi,Jong-Hun, Lee, “The

Design and Implementation of Open GIS Service Component”, Geoscience and Remote Sensing Symposium, 2001. IGARSS '01. IEEE 2001 International, 2001.

[36] Do-Hyun, Kim, Min-Soo, Kim, “Web GIS Service Component Based On

Open Environment”, Geoscience and Remote Sensing Symposium, 2002. IGARSS '02. 2002 IEEE International, 2002.

[37] Yue, Li, Zhong, Xie,Zhiyong, Huang, “Design and Implementation of a

WAP GIS Framework”, Web Information Systems Engineering (Workshops), 2002. Proceedings of the Third International Conference on, IEEE, 2002.

[38] Zhifeng, Guo, Xingling, Wang, Guoqing, Sun, “Research and Application

on Spatial Data Web Service Based on .Net Platform”, Geoscience and Remote Sensing Symposium, 2003. IGARSS '03. Proceedings. IEEE, 2003.

[39] Yuan, Ying, Bian, Fuling, “An Open Sharing and Interoperating Platform

for Spatial Information Based on GIS Web Services”, Wireless Communications, Networking and Mobile Computing, 2007. WiCom 2007. International Conference on, IEEE, 2007.

[40] The PostgreSQL Global Development Group, “PostgreSQL 8.0.0

Documentation”, The PostgreSQL Global Development Group, 2005. [41] Refractions Research Inc, “PostGIS 1.3.5 Manual”, Refractions Research

Inc., 2008. [42] C.I.P. Lnaguaje Group. The Munich CIP Project, vol II: The CIP Method.

Lecture Notes in Computer Science. Springer-Verlag, Heidelberg, Alemania, 1988.

[43] OpenGis Specifications; http://www.opengeospatial.org/standards/is [44] Open Gis Consortium, “OGC Web Map Service Interface”, Open Gis

Consortium, 2004. [45] Open Gis Consortium, “The OpenGis Abstract Specification”, Open Gis

Consortium, 2001. [46] Manola, Frank, Miller, Eric, “RDF Primer”, W3C, 2004.

Referencias

- 134 -

[47] Secretaría de Energía de la Nación; http://energia3.mecon.gov.ar/home/ [48] Instituto Geográfico Militar; http://www.igm.gov.ar/ [49] Secretaría de Agricultura, Ganadería, Pesca y Alimentos;

http://www.sagpya.mecon.gov.ar/ [50] Gobierno de la Ciudad de Buenos Aires; http://www.buenosaires.gov.ar/ [51] PROSIGA-IDERA, “Definición de Requerimientos y Estándares Técnicos

para la Representación de Datos Geoespaciales”, 2008. [52] World Wide Web Consortium; http://www.w3c.es/ [53] Montejano Germán, A., (2005). Especificación Formal en RSL del

Balanced Scorecard. Tesis. Facultad de Ciencias Físico Matemáticas y Naturales, UNSL.

[54] INSPIRE, “INSPIRE Technical Architecture - Overview”, INSPIRE, 2007.

Anexo I

- 135 -

ANEXO I

1. Listado del Código Fuente 1.1 Código fuente base_definitions.rsl /*

En este esquema se definen las construcciones básicas para dar

lugar a las siguientes definiciones de la infraestructura.

Aquí se encuentran las definiciones de base de los sistemas de

información geográfica. A partir de estas se pueden definir los

tipos abstractos de datos (ADTs) y los servcicios.

*/

scheme BASE_DEFINITIONS =

class

type

/*

ADT_MAP: Se define el mapa como un producto de un conjunto de capas,

proyección y un

área abarcativa.

El mapa es la base sobre la cual se hacen los análisis futuros.

*/

ADT_MAP = (LAYER)-set >< PROJECTION >< BBOX,

/*

A través de estas definiciones se aborda los elementos más

atómicos que componen un mapa, que son los puntos, segmentos,

polilíneas y polígonos, como así también los círculos, los

cuales se pueden definir como un polígono con ciertas

características especiales y con un número de puntos lo

suficientemente grande. En este caso particular hemos

definido el círculo como un punto y un radio, a partir del

cual se pueden definir el resto de los elementos del círculo.

*/

POINT = {| (x, y) : Real >< Real :- within_bb(x, y) |},

SEGMENT = {| s : POINT-set :- card (s) = 2 |},

POLYLINE = {| pl : POINT-list :- len (pl) > 2 |},

POLYGON = {| pg : POLYLINE :- first(pg) = last(pg) |},

CIRCLE = POINT >< RADIO,

/*

LAYER: Una capa se define como un producto cartesiano de:

- un conjunto de puntos y sus atributos,

- un conjunto de segmentos con atributos,

- un conjunto de polilíneas con sus atributos,

- un conjunto de polígonos y sus atributos,

- un nombre, toda capa debe recibir un nombre para identificarla,

- una proyección, la cual puede variar de la proyección del mapa,

- un área de interés.

*/

LAYER = (POINT >< ATTR)-set >< (SEGMENT >< ATTR)-set ><

(POLYLINE >< ATTR)-set >< (POLYGON >< ATTR)-set ><

NAME >< PROJECTION >< BBOX,

/*

BBOX: Se define como un producto de reales, y define las

coordenadas izquierda superior y derecha inferior de un

rectángulo de usos varios dentro de un GIS.

*/

BBOX = Real >< Real >< Real >< Real,

/*

Aquí encontramos definiciones que completan un GIS, las

cuales no se detallan en profundidad debido a que no es

necesario y se dejan libradas a la implementación final y

específica.

*/

DISTANCE = Real,

PROJECTION,

ATTR,

STYLE,

NAME = Text,

Anexo I

- 136 -

TYPE = Text,

RADIO = Real,

STREET = Text,

IMAGEN

value

/*

----------------------------------------------------------

FUNCIONES NO IMPLEMENTADAS EN EL PRESENTE TRABAJO

----------------------------------------------------------

*/

/*

Estas funciones se espera que sean implementadas por el

software geográfico de base.

*/

within_bb : Real >< Real -> Bool,

within : POINT >< Real -> Bool,

intersects : SEGMENT >< POINT -> Bool,

intersects : POLYLINE >< POINT -> Bool,

first : POLYLINE -> POINT,

last : POLYLINE -> POINT,

arma_estilo: SEGMENT -> STYLE,

obtener_imagen: ADT_MAP >< LAYER-set >< POINT >< Real -> IMAGEN

end

1.2 Código fuente ADT.rsl BASE_DEFINITIONS

/*

Esta definición extiende las definiciones Base

Aquí se pretende definir formalmente los tipos abstractos de Datos

correspondientes a la infraestructura.

*/

scheme ADT =


class

type

/*

ADT_ADDRESS: Este tipo de dato representa una dirección en el

plano, para ser ubicada. A través de esta representación

también se pueden hacer búsquedas de lugares determinados.

Por ejemplo: ubicar un restaurant chino a través de su

dirección, barrio y calle, o bien en forma inversa donde se

solicita al framework que determine el restaurant más próximo

a un determinado hotel, donde la información que es devuelta

por el servicio es a través del tipo abstracto ADT_ADDRESS.

*/

ADT_ADDRESS = STREET >< PLACE >< POSTAL_CODE >< STREET_LOCATOR ><

BUILDING_LOCATOR >< ADDITIONAL,

/*

ADT_POI: La finalidad de esta definición es la de determinar un punto de

interés en el

plano. Por ejemplo un punto de interés podría ser un hotel,

de la categoría de hospedajes, o con un determinado número de

teléfono.

*/

ADT_POI = NAME >< TYPE >< CATEGORY >< ADT_ADDRESS ><

PHONE_NUMBER >< ADDITIONAL,

/*

ADT_AOI: Representa un área de interés, el cual está definido por una

definición de tipo variant, que permite definirse como un

círculo, un BBOX o un POLYGON, todos estos tipos se

encuentran ya definidos en el esquema BASE_DEFINITIOSN.

*/


/*

CAMPO,VALOR: son utilizados en el servicio de directorio. Se utilizan

básicamente para el pasaje de parámetros a la función.

Anexo I

- 137 -

*/

CAMPO = {| x : Text :- x = "PLACE" \/ x = "CATEGORY" \/ x =

"SUBCATEGORY" \/ x = "NAME" \/ x = "STREET" \/ x = "POSTAL_CODE"

\/ x = "PHONE_NUMBER" |},

VALOR = Text,

/*

ROUTE_PLAN: tipo compuesto por la PREFERENCIA y el tiempo de

comienzo.

Define el plan que se va a utilizar para realizar un

recorrido en el servicio ROUTE.

*/

ROUTE_PLAN=PREFERENCE >< Bool >< START_TIME,

/*

PREFERENCE: define si la ruta a utilizar será la más rápida,

la más corta o el recorrido se realizará a pie.

*/

PREFERENCE == Fatest | Shortest | Pedestrian,

/*

La definición de estos tipos se deja librada a la

implementación en particular. Algunos de ellos se consideran

de tipo Texto y otros directamente sin tipo.

*/

START_TIME,

DIRECTORY_TYPE,

PLACE = Text,

POSTAL_CODE = Text,



ADDITIONAL = Text,

CATEGORY = Text,

PHONE_NUMBER = Text

value

/*

----------------------------------------------------------

FUNCIONES NO IMPLEMENTADAS EN EL PRESENTE TRABAJO

----------------------------------------------------------

Estas funciones se pretende que las brinde el software

geográfico de base (GIS de BASE).

*/

/*

within: pretende determinar si un punto (definido por el

ADT_AOI) se encuentra en un segmento, polilínea o punto.

Es de mucha utilidad para determinar puntos de pertenencia

*/

within : ADT_AOI >< POINT -> Bool,

within : ADT_AOI >< SEGMENT -> Bool,

within : ADT_AOI >< POLYLINE -> Bool,

/*

address_completa: a partir de determinados datos conforma una

dirección completa.

*/

address_completa : POINT >< ADT_AOI -> ADT_ADDRESS >< POINT >< Real,

address_completa : ADT_ADDRESS -> ADT_ADDRESS,

/*

obtener_punto: intenta obtener un punto a partir de una

dirección o de un punto de interés.

*/

obtener_punto : ADT_ADDRESS -> POINT,

obtener_punto : ADT_POI -> POINT,

/*

Aquí se definen algunos otros predicados de uso común en los

servicios de la infraestructura.

*/

obtener_precision : ADT_ADDRESS -> Real,

distancia: ADT_MAP >< (Text -m-> Text) >< DIRECTORY_TYPE -> Real,

obtener_atributo_bd: STREET >< PLACE >< POSTAL_CODE -> ATTR,

existe_en_directory: DIRECTORY_TYPE >< Text >< Text -> Bool

end

Anexo I

- 138 -

1.3 Código fuente framework.rsl

ADT

/*

Este esquema es el que realiza la especificación formal de los

servicios de la infraestructura. Utiliza las definiciones

anteriores de: BASE_DEFINITIONS y ADT.

*/

scheme FRAMEWORK =

extend ADT with

class

value

/*

----------------------------------------------------------

SERVICIOS EXPUESTOS DEL FRAMEWORK

----------------------------------------------------------

*/

/*

Este servicio, que es de uso público para los objetos que lo

requieran, permite convertir un conjunto de direcciones,

ADT_ADDRESS-set, en un conjunto de puntos geográficos en el

plano. El conjunto de puntos de resultado equivale a la

posición geográfica (latitud, longitud) que le corresponde

por la dirección postal (calle - altura - ciudad -cp).

*/

geocode: (ADT_ADDRESS)-set >< ADT_MAP ->

(ADT_ADDRESS >< POINT >< Real)-set

geocode(lista_geocod, mapa) is

let (layers, proj, box) = mapa in





precision : Real :-

(all direccion : ADT_ADDRESS :-

direccion isin lista_geocod /\


end,

/*


requieran, permite obtener una dirección completa, normalizada de

nombre de calle, lugar, código postal y altura a partir de una

posición geográfica dada.

*/

reverse_geocode :

ADT_MAP >< POINT >< ADT_AOI ->

(ADT_ADDRESS >< POINT >< Real)-set

reverse_geocode(mapa, posicion, area) is



resultado : ADT_ADDRESS >< POINT >< Real :-

(all layer : LAYER :-

layer isin layers /\


end,

/*


requieran, permite acceder a un directorio en línea para

ubicar un lugar, servicio o producto específico o bien el más

cercano a un determinado punto o ubicación. En base a los

parámetros que se le pasan a este servicio, comienza con la

búsqueda en el directorio específico o que más se adecúe

(páginas amarillas, guía de restaurantes, etc), tratando de

ubicar el lugar, producto o servicio específico o más

cercano, de acuerdo a lo solicitado.

*/

directory: ADT_MAP >< ADT_ADDRESS >< Real >< Real >< Real >< ADT_AOI ><

DIRECTORY_TYPE >< (CAMPO -m-> VALOR) -> (ADT_POI >< Real)-set

directory(mapa, direccion, within_distance, max_distance,

min_distance, withinboundary, directory, valores) is

{(punto_of_interes(valores,directory),distancia(mapa,valores,directory)) |

Anexo I

- 139 -

punto: ADT_POI, distancia: Real :-

(all clave : Text :- clave isin dom(valores)

/\ existe_en_directory(directory,clave,valores(clave)) /\

(within(obtener_punto(direccion),min_distance) \/

within(obtener_punto(direccion),max_distance) \/

within(withinboundary,obtener_punto(direccion)) ))

},

/*

En este caso se hizo sobrecarga de funciones, característica

de la programación orientada a objetos que es totalmente

utilizable y aplicable en RSL. De esta forma se pueden

especificar las distintas alternativas en que se puede llamar

este servicio desde otros objetos.

*/

directory: ADT_MAP >< DIRECTORY_TYPE >< (CAMPO -m-> VALOR) -> (ADT_POI ><

Real)-set

directory(mapa, directory, valores) is

{(punto_of_interes(valores,directory),distancia(mapa,valores,directory))

| punto: ADT_POI, distancia: Real :-

(all clave : Text :- clave isin dom(valores)

/\ existe_en_directory(directory,clave,valores(clave)))

},

/*


requieran, permite obtener una ruta que una dos puntos, el de

inicio y el de fin. En esta ruta deberá contemplar si

hiciera falta los puntos intermedios que puedan ser

especificados por el objeto que lo solicita. La petición de

la ruta debe indicar el modo en que se realiza: a pie, la

ruta más corta, la ruta más rápida.

*/

route: ADT_MAP >< ADT_POI >< ADT_POI >< ROUTE_PLAN ><

ADT_POI-list >< Real -> (ADT_POI >< SEGMENT)-list

route(mapa, inicio, fin, plan, puntos_int, scale) is

let (preferencia,rt_traffic,comienzo) = plan in

<.(inicio,obtener_segmento(mapa,inicio,fin,preferencia)).> ^

route(mapa, hd puntos_int, fin, plan, tl puntos_int, scale)

end,

/*


requieran, permite obtener una región de influencia (buffer)

alrededor de una lista de puntos que se le envían al servicio

como parámetro. También recibe la lista de radios que

contendrá cada una de las regiones a generar a partir de los

puntos dados.

*/

buffer: ADT_MAP >< ADT_POI >< Real-list -~-> CIRCLE-list

buffer(mapa,centro,radios) is

<.(obtener_punto(centro), hd radios).> ^ buffer(mapa,centro,tl

radios)

pre radios ~= <..>,

/*


requieran, permite obtener el estado actual de rutas,

autopistas, o cualquier otro tipo de vía de comunicación. El

análisis se realiza sobre un mapa y una zona de influencia

(BBOX), y devuelve un conjunto de segmentos y estilos

asociados, logrando de esta manera mostrar gráficamente (a

través del uso de estilos) el estado de cada carretera en

cada uno de los tramos que la componen. El análisis se

realiza sobre los datos que están en ese momento almacenados

en el repositorio de datos que corresponda.

*/

highway_states: ADT_MAP >< BBOX -> (SEGMENT >< STYLE)-set

highway_states(mapa,bounding_box) is


{

(segmento, arma_estilo(segmento)) | segmento: SEGMENT, estilo: STYLE

:-

(all capa: LAYER :- capa isin layers /\

let


Anexo I

- 140 -


(all (segmento,atributo): SEGMENT >< ATTR :-

(segmento,atributo) isin segmentos /\ ishighway(segmento))

end

)

}

end,

/*


requieran, brinda la posibilidad de obtener en forma de

imagen un trozo del mapa sobre el cual se está trabajando.

Para ello necesita que se le especifique el mapa (ADT_MAP),

un punto central (POINT), una escala sobre la cual trabajar,

y una lista de capas a ser incluídas en la generación. Como

resultado se obtiene una imagen en formato específico (de

acuerdo a la implementación final).

*/

get_map: ADT_MAP >< POINT >< Real >< NAME-list -> IMAGEN

get_map(mapa,centro,escala, lista_layers) is


obtener_imagen(mapa, get_layers(layers,lista_layers) ,centro,escala)

end,

/*

----------------------------------------------------------

FUNCIONES UTILIZADAS POR LOS SERVICIOS DEL FRAMEWORK

----------------------------------------------------------

*/

/*

A continuación se mencionan los servicios de uso privado que

son utilizados por los servicios públicos formalizados anteriormente.

*/

es_geocodificable : ADT_ADDRESS >< LAYER-set -> Bool

es_geocodificable(direccion, layers) is

let


direccion

in

if calle ~= "" /\ cp ~= ""

then

(all capa : LAYER :-

capa isin layers /\


else false

end

end,

encontrar_segmento : STREET >< PLACE >< POSTAL_CODE >< LAYER -> Bool

encontrar_segmento(calle, lugar, cp, capa) is

let



in

(all (segmento, atributo) : SEGMENT >< ATTR :-

(segmento, atributo) isin segmentos /\ (atributo =

obtener_atributo_bd(calle,lugar,cp))) \/

(all (polilinea, atributo) : POLYLINE >< ATTR :-

(polilinea, atributo) isin polilineas /\ (atributo =


end,

buscar_lugares : LAYER >< POINT >< ADT_AOI -> Bool

buscar_lugares(capa, posicion, area) is

let



in

((all (punto, atributo) : POINT >< ATTR :-

((punto, atributo) isin puntos /\

(punto = posicion \/ within(area, punto)))) \/


((segmento, atributo) isin segmentos /\

(intersects(segmento, posicion) \/

within(area, segmento)))) \/

(all (multilinea, atributo) : POLYLINE >< ATTR :-

((multilinea, atributo) isin polilineas /\

Anexo I

- 141 -

(intersects(multilinea, posicion) \/

within(area, multilinea)))) \/

(all (region, atributo) : POLYGON >< ATTR :-

((region, atributo) isin poligonos /\

(intersects(region, posicion) \/

within(area, region)))))

end ,

punto_of_interes: (CAMPO -m-> VALOR) >< DIRECTORY_TYPE -> ADT_POI,

obtener_segmento: ADT_MAP >< ADT_POI >< ADT_POI >< PREFERENCE -> SEGMENT,

ishighway: SEGMENT -> Bool,

obtener_layer: ADT_MAP >< NAME -> LAYER,

get_layers: LAYER-set >< NAME-list -> LAYER-set

get_layers(layers,lista_layers) is

{capa | capa: LAYER :-

let (puntos, segmentos, polilineas, poligonos, nombre,


(all capa: LAYER :- capa isin layers /\ nombre = hd

lista_layers)

end

} union get_layers(layers,tl lista_layers)

end

Anexo II

- 142 -

ANEXO II

1. Chequeo de sintaxis

1.1 Chequeo de base_definitions.rsl

1.2 Chequeo de ADT.rsl

1.3 Chequeo de framework.rsl

Anexo II

- 143 -

Anexo III

- 144 -

ANEXO III

1. Confidence Conditions

cd c:/TRABAJO/documentos/OSCAR/Maestría en Ingeniería del SW/Tesis/

C:\raise\rsl\rsltc -cc base_definitions

rsltc version 2.5 of Thu Apr 7 23:40:09 2005

Checking BASE_DEFINITIONS ...

Finished BASE_DEFINITIONS

base_definitions.rsl:30:43: CC:

-- subtype not empty

exists (x, y) : Real >< Real :- within_bb(x, y)



exists s : POINT-set :- card (s) = 2



exists pl : POINT-list :- len (pl) > 2



exists pg : POLYLINE :- first(pg) = last(pg)

rsltc completed: 4 confidence condition(s) generated

rsltc completed: 0 error(s) 0 warning(s)

Compilation finished at Fri Feb 27 20:34:18


C:\raise\rsl\rsltc -c ADT


Loading BASE_DEFINITIONS ...


Checking ADT ...

Finished ADT

ADT.rsl:47:30: CC:


exists x : Text :-

x = "PLACE" \/ x = "CATEGORY" \/ x = "SUBCATEGORY" \/

x = "NAME" \/ x = "STREET" \/ x = "POSTAL_CODE" \/

x = "PHONE_NUMBER"





C:\raise\rsl\rsltc -c framework


Loading BASE_DEFINITIONS ...


Loading ADT ...

Finished ADT

Checking FRAMEWORK ...

Finished FRAMEWORK

framework.rsl:28:7: CC:

-- function result in subtype

all (lista_geocod, mapa) : (ADT_ADDRESS)-set >< ADT_MAP :-

card


{(address_completa(direccion), obtener_punto(direccion),



precision : Real :-

Anexo III

- 145 -

(all direccion : ADT_ADDRESS :-

direccion isin lista_geocod /\


end

post

true



all (mapa, posicion, area) : ADT_MAP >< POINT >< ADT_AOI :-

card



resultado : ADT_ADDRESS >< POINT >< Real :-

(all layer : LAYER :-

layer isin layers /\


end

post

true


-- application arguments and/or precondition

clave isin valores



all

(mapa, direccion, within_distance, max_distance,

min_distance, withinboundary, directory, valores) :

ADT_MAP >< ADT_ADDRESS >< Real >< Real >< Real ><

ADT_AOI >< DIRECTORY_TYPE >< (CAMPO -m-> VALOR)

:-

card

{(punto_of_interes(valores, directory),

distancia(mapa, valores, directory)) |

punto : ADT_POI, distancia : Real :-

(all clave : Text :-

clave isin dom (valores) /\

existe_en_directory(directory, clave, valores(clave)) /\

(within(obtener_punto(direccion), min_distance) \/

within(obtener_punto(direccion), max_distance) \/

within(withinboundary, obtener_punto(direccion))))}

post

true



clave isin valores



all

(mapa, directory, valores) :

ADT_MAP >< DIRECTORY_TYPE >< (CAMPO -m-> VALOR)

:-

card

{(punto_of_interes(valores, directory),

distancia(mapa, valores, directory)) |

punto : ADT_POI, distancia : Real :-

(all clave : Text :-

clave isin dom (valores) /\

existe_en_directory(directory, clave, valores(clave))

)}

post

true



let x = puntos_int in x ~= <..> end



let x = puntos_int in x ~= <..> end



Anexo III

- 146 -

let (x1_, x2_, x3_, x4_, x5_, x6_) = hd puntos_int in

(len x1_ post true) /\ (len x2_ post true) /\

(len x3_ post true) /\

let (x7_, x8_, x9_, x10_, x11_, x12_) = x4_ in



(len x11_ post true) /\ (len x12_ post true)

end /\ (len x5_ post true) /\ (len x6_ post true)

end



let x = radios in x ~= <..> end



let x = radios in x ~= <..> end



let (mapa, centro, radios) = (mapa, centro, tl radios) in

radios ~= <..>

end



all (mapa, bounding_box) : ADT_MAP >< BBOX :-

card


{(segmento, arma_estilo(segmento)) |

segmento : SEGMENT, estilo : STYLE :-


capa isin layers /\

let

(puntos, segmentos, polilineas, poligonos,

nombre, proyeccion, bbox) = capa

in


(segmento, atributo) isin segmentos /\

ishighway(segmento))

end)}

end

post

true



let x = lista_layers in x ~= <..> end



let x = lista_layers in x ~= <..> end



all (layers, lista_layers) : LAYER-set >< NAME-list :-

(card

({capa |

capa : LAYER :-

let



in


capa isin layers /\ nombre = hd lista_layers)

end} union get_layers(layers, tl lista_layers))

post

true) /\

(all

x_ :

((Real >< Real) >< ATTR)-infset ><

((Real >< Real)-infset >< ATTR)-infset ><

((Real >< Real)-inflist >< ATTR)-infset ><

((Real >< Real)-inflist >< ATTR)-infset ><

Char-inflist >< PROJECTION ><

(Real >< Real >< Real >< Real)

:-

Anexo III

- 147 -

x_ isin

{capa |

capa : LAYER :-

let

(puntos, segmentos, polilineas, poligonos,

nombre, proyeccion, bbox) = capa

in


capa isin layers /\ nombre = hd lista_layers)

end} union get_layers(layers, tl lista_layers) =>

let (x13_, x14_, x15_, x16_, x17_, x18_, x19_) = x_ in

((card x13_ post true) /\

(all x_ : ((Real >< Real) >< ATTR) :-

x_ isin x13_ =>

let (x20_, x21_) = x_ in

let (x, y) = x20_ in within_bb(x, y) end

end)) /\

(card x14_ post true) /\

(all x_ : ((Real >< Real)-infset >< ATTR) :-

x_ isin x14_ =>

let (x22_, x23_) = x_ in

((card x22_ post true) /\

(all x_ : Real >< Real :-

x_ isin x22_ =>

let (x, y) = x_ in within_bb(x, y) end)

) /\ let s = x22_ in card (s) = 2 end

end) /\


(all x_ : ((Real >< Real)-inflist >< ATTR) :-

x_ isin x15_ =>

let (x24_, x25_) = x_ in

((len x24_ post true) /\


x_ isin x24_ =>

let (x, y) = x_ in within_bb(x, y) end)

) /\ let pl = x24_ in len (pl) > 2 end

end) /\


(all x_ : ((Real >< Real)-inflist >< ATTR) :-

x_ isin x16_ =>

let (x26_, x27_) = x_ in

(((len x26_ post true) /\


x_ isin x26_ =>

let (x, y) = x_ in within_bb(x, y) end

)) /\ let pl = x26_ in len (pl) > 2 end) /\

let pg = x26_ in first(pg) = last(pg) end

end) /\ (len x17_ post true)

end)




Documents

UNIVERSIDAD NACIONAL DE SAN LUIS FACULTAD DE … Oscar Testa.pdf · Especificación Formal en RSL de una Infraestructura abierta y estándar de Servicios Web de SIG Lic. Oscar Alfredo