Personal tools
You are here: Home Production Proyectos Testing Documentos de trabajo Procedimientos de testeo de gvSIG Información relevante Proyectos de persistencia en gvSIG
Document Actions

Proyectos de persistencia en gvSIG

by Victoria Agazzi last modified 2010-09-10 15:20

En este apartado se ha puesto información sobre lo que hay que tener en cuenta de cara a generar un proyecto de persistencia, así como la documentación necesaria para su correcto uso, una vez éste está generado.

Para probar la persistencia de ciertas funcionalidades de un instalable de gvSIG es recomendable seguir ciertas prácticas de buen uso que se detallan a continuación:

¿Qué es un proyecto de persistencia?

En gvSIG entendemos que un proyecto de persistencia es aquel fichero .gvp o .gvm que, junto a la cartografía necesaria, hace que podamos comprobar que ciertas funcionalidades de gvSIG no se han "roto" en el proceso de estabilización de una versión. Las funcionalidades susceptibles de ser probadas de esta forma son las que no necesitan de un usuario para ser ejecutadas (al recuperar un proyecto), sino que se guardan con el propio proyecto y deben ser recuperadas una vez lo volvemos a abrir con gvSIG.

Para comprobar dichas funcionalidades, lo único que tendremos que hacer es abrir dicho proyecto, verificar visualmente su contenido, siguiendo un guión que se habrá preparado para poder hacer dicha comprobación visual.

¿Cómo utilizamos un proyecto de persistencia?

La utilización del proyecto es simple: una vez recreado el entorno en el ordenador en el que se quiere hacer la prueba, bastará con abrir gvSIG, abrir el proyecto de persistencia y hacer las comprobaciones que nos indique el guión (documento en donde explica qué es lo que nos encontraremos en dicho proyecto) de persistencia. Recrear el entorno significa copiar en disco duro (en la ubicación que nos indique el guión) toda la cartografía necesaria para ejecutar correctamente dicho proyecto.

Se deben realizar siempre dos tipos de pruebas de persistencia: persistencia con respecto a la versión anterior de gvSIG y con respecto a la actual. A continuación se describen los procedimientos a seguir para cada una de ellas:

  • Persistencia con respecto a la anterior versión. Abrir proyecto generado con la anterior versión y hacer todas las comprobaciones que indica el guión. Guardar el proyecto con un nuevo nombre indicando la versión y nº de build del ejecutable actual.
  • Persistencia con respecto a la versión actual. Abrir un proyecto previamente guardado con el ejecutable actual (con el que se pretende abrir) y hacer todas las comprobaciones que indica el guión.

IMPORTANTE: no machacar NUNCA un proyecto de persistencia generado con una versión o build anterior ya que el nombre del fichero no sería coherente. En el caso de uno generado con una versión anterior es crítico ya que en caso de que no haya una copia de seguridad se pierde la posibilidad de utilizarlo para las pruebas de los siguientes builds.

Documentos necesarios para poder ejecutar una prueba de persistencia

Para poder realizar correctamente una prueba de persistencia se hace necesario, por lo menos 3 documentos:

  • Proyecto en sí (fichero .gvp, .gvm) en el sistema operativo en el que se quiera pasar las pruebas
  • Cartografía y otros datos necesarios, para una vez abierto el proyecto, dichos datos sean correctamente visualizados en gvSIG
  • Guión de persistencia. Será un documento de texto gracias al cual seremos capaces de hacer las comprobaciones visuales.

¿Cómo generamos lo necesario para una prueba de persistencia?

La cartografía que utilizaremos será preferentemente libre, de modo que dicho proyecto de persistencia pueda ser distribuido y compartido. Dicha cartografía será copiada en un directorio que luego acompañará al proyecto, de tal modo que dicho entorno pueda ser fácilmente reproducible en cualquier otro ordenador.

Respecto al proyecto a generar, tendremos que tener en cuenta el tipo de funcionalidad que puede persistir, es decir, tener como objetivo las funcionalidades que hacen modificaciones sobre nuestros datos y se guardan en el propio proyecto. Para clarificar, pensar en que algunos de los elementos que podrían persistir son, por ejemplo, el nombre de una capa, la escala de visualización de la misma en la vista geográfica o la maquetación de un mapa. Pero no podremos persistir cualquiera de los geoprocesos que le apliquemos a esta capa (aunque si la visualización de su resultado).

Para poder interpretar si la persistencia de los elementos es correcta se generará un documento de texto, que ilustre de forma textual y gráfica, qué debemos encontrarnos una vez abierto el proyecto en cuestión. Siempre que se detallen las comprobaciones a hacer, será preferible añadir una imágen en lugar de una explicación textual.

Este documento además de ser la guía en función de la cual decidiremos si algo ha fallado, nos tiene que permitir reconstruir el contenido del proyecto de persistencia. Tener en cuenta que, a lo largo de la fase de estabilización, frecuentemente encontraremos errores a la hora de abrir dicho proyecto (para eso lo hacemos!, para detectar esos errores) y por tanto parte de su configuración puede ser eliminada, o incluso se podrá corromper dicho proyecto. El documento guía de persistencia nos permitirá volver a generar el proyecto, una vez los errores se hayan corregido.

Ejemplo de prueba de persistencia

  • Proyecto en sí (fichero .gvp, .gvm). Ejemplo
  • Cartografía y otros datos necesarios. Ejemplo
  • Guión de persistencia. Ejemplo

Powered by Plone CMS, the Open Source Content Management System

This site conforms to the following standards: