cenidet Centro Nacional de Investigación y Desarrollo Tecnológico Departamento de Ciencias Computacionales TESIS DE MAESTRÍA EN CIENCIAS

Transcripción

1 cenidet Centro Nacional de Investigación y Desarrollo Tecnológico Departamento de Ciencias Computacionales TESIS DE MAESTRÍA EN CIENCIAS Definición de Procesos con Datos Espaciales Mediante Flujos de Trabajo presentada por: Catalina Aranda Castillo Ing. en Sistemas Computacionales por el I. T. de Cuautla como requisito para la obtención del grado de: Maestra en Ciencias en Ciencias de la Computación Director de tesis: Dr. Juan Gabriel González Serna Co-Director de tesis: Dr. Rodolfo Abraham Pazos Rangel Jurado: Dr. Hugo Estrada Esquivel Presidente Dr. René Santaolaya Salgado Secretario Dr. Juan Gabriel González Serna Vocal Dr. José Antonio Zárate Marceleño Vocal Suplente Cuernavaca, Morelos, México. 17 de febrero de 2009

2

3 Resumen Los sistemas de workflow surgieron como una forma de reducir el tiempo y costo para llevar a cabo los procesos de negocio y asegurar que las tareas sean llevadas a cabo de forma consistente. Estos sistemas a pesar de no ser una tecnología emergente han evolucionado para satisfacer las necesidades actuales de las organizaciones, tanto públicas como privadas. Con la aparición y difusión de los sistemas de información geográfica, se ha facilitado el manejo y procesamiento de información georeferencial, lo cual ha sido aprovechado por algunos sistemas de workflow para integrar el manejo de esta clase de información. Varias organizaciones al tener la necesidad de ubicar las solicitudes de los servicios que ofrecen, han desarrollado soluciones a la medida, debido a que la mayoría de los sistemas de workflow que poseen esta funcionalidad son costosos o enfocados a un área en específico. Es por esto que en esta tesis se propone la integración de los servicios que ofrecen los sistemas de información geográfica a un sistema de workflow genérico de código abierto, con el objetivo de modelar procesos que incorporen información espacial. En este documento de tesis se presenta el estudio realizado sobre el estado del arte de sistemas de workflow comerciales que involucran el uso de información georeferencial y los sistemas de workflow de código abierto más representativos de esta comunidad. En base a este estudio se elaboró una tabla comparativa con respecto a la herramienta propuesta en esta tesis. Se presenta el análisis realizado a los componentes del sistema de workflow de código abierto Bonita, a partir del cual se desarrolló el modelo de solución. Seguido a éste, se describe el diseño y la implementación de las modificaciones. En el diseño se abordan los casos de uso contemplados y se explica el funcionamiento e interacción de la funcionalidad agregada con el resto de los componentes mediante los diagramas de actividad y de secuencias. Se describe el plan de pruebas desarrollado y aplicado al sistema modificado, con el fin de evaluar la funcionalidad del mismo. Este plan permitió comprobar que se pueden modelar procesos de negocio con información espacial mediante una herramienta para definición de procesos de código abierto modificada. Por último se presentan las conclusiones alcanzadas durante el desarrollo de este proyecto, las aportaciones generadas y las propuestas de trabajos futuros, las cuales mejorarían y complementarían el prototipo desarrollado presentado en este documento.

4

5 Abstract Workflow systems emerged as a way of reducing time and cost to carry out business processes and ensure that tasks are carried out in a consistent way. These systems in spite of not being an emergent technology have evolved to meet the current organizations needs, both public and private. With the emerge and spread of geographic information systems, has facilitated the handling and processing of georeferencial information, which has been exploited by some workflow systems to integrate the management of this kind of information. Several organizations in the need to locate request for the services they offer, have developed accurate solutions, because most of the workflow systems which have this feature are costly or targeted to a specific area. This is why this thesis proposes the integration of the services that offered by the geographic information systems to a generic open source workflow system, with the aim of modeling processes that incorporate spatial information. This thesis document presents the study of the state of art of workflow systems that involve the use of information georeferencial and open source workflow systems more representative of this community. Based on this study, it was elaborated a comparative table in respect to the tool proposed in this thesis. It s presented the analysis to the components of the open source system Bonita workflow, from which the model solution was developed. Following this, the design and implementation of the changes are described. The design describes the use cases covered and explains the operation and interaction of the added functionality with the other components using sequence and activity diagrams. It s described the test plan developed and applied to modified system, in order to assess the functionality of it. This plan allowed to prove that it s possible to model business processes with spatial information through an modified tool of open source for processes definition. Finally the reached conclusions are presented during the development of this project, the generated inputs and future proposals, which would enhance and complement the developed prototype presented in this document.

6

7 Tabla de contenido Tabla de contenido...i Lista de figuras...iii Lista de tablas...iv Glosario de términos y siglas...vi Introducción... 1 Capítulo 1. Antecedentes Antecedentes Planteamiento del problema Objetivo Justificación y beneficios Alcances y limitaciones Metodología de solución... 7 Capítulo 2. Marco teórico Proceso de negocio Workflow Sistema de workflow Modelo de referencia Herramienta de definición de procesos Motor de workflow Servicio de representación de workflow Interfaz de programación de aplicaciones de workflow (WAPI) Lenguaje de Definición de Procesos XML (XPDL) Sistema de Información Geográfica (GIS) Servidor de Mapas Funcionalidad de los servidores de mapas GeoServer Estándares OGC soportados por GeoServer OpenLayers API JDOM...16 Capítulo 3. Estado del arte Sistemas comerciales Sistemas de código abierto Análisis comparativo...22 Capítulo 4. Análisis del problema y solución propuesta Funcionamiento general del sistema Ingeniería inversa del sistema Bonita Motor de workflow Consola de administración de procesos jiapadmin Editor de procesos de negocio ProEd Editor de formularios xformeditor...34 i

8 Notación para atributos Modelo de solución Capítulo 5. Diseño e implementación del sistema Diseño de las modificaciones para el editor ProEd Casos de uso del editor ProEd Implementación de modificaciones sobre ProEd Cuantificación de las modificaciones de ProEd Diseño de las modificaciones para xformeditor Casos de uso del editor de formularios xformeditor Implementación de modificaciones sobre xformeditor Cuantificación de las modificaciones de xformeditor Diseño de las modificaciones para la consola jiapadmin Implementación de las modificaciones sobre la consola jiapadmin Capítulo 6. Pruebas Hipótesis Convención de nombres Plan de pruebas Casos de pruebas Resultados de pruebas Análisis de los resultados Capítulo 7. Conclusiones Conclusiones Aportaciones Trabajos futuros Publicaciones y reconocimientos Anexo A. Diagramas de clases del editor ProEd Anexo B. Escenarios de los casos de uso del editor ProEd y xformeditor Anexo C. Descripción de los casos de prueba Referencias ii

9 Lista de figuras Figura 1.1 Metodología de solución...1 Figura 2.1 Modelo de referencia de un sistema de workflow...10 Figura 4.1 Funcionamiento del sistema Bonita workflow...26 Figura 4.2 Arquitectura del motor de Bonita workflow...27 Figura 4.3 Arquitectura consola de procesos jiapadmin...29 Figura 4.4 Diagrama de clases del paquete java.webapp.bull.jiap.admin.process...31 Figura 4.5 Contenido del paquete chi...32 Figura 4.6 Diagrama de clases del paquete plugin...33 Figura 4.7 Diagrama de clases del paquete resources...34 Figura 4.8 Diagrama de clases del paquete xform...34 Figura 4.9 Diagrama de clases del paquete gui.xform...35 Figura 4.10 Diagrama de clases del paquete gui.app...35 Figura 4.11 Modelo de solución...37 Figura 5.1 Diagrama de casos de uso del editor de procesos...41 Figura 5.2 Diagrama de casos de uso de CU_4 definir atributos...41 Figura 5.3 Diagrama de casos de uso de CU_9 definir atributo espacial...42 Figura 5.4 Diagrama de actividades de creación de un atributo espacial...43 Figura 5.5 Diagrama de secuencia de creación de un atributo espacial...44 Figura 5.6 Diagrama de la clase DatafieldDialog...48 Figura 5.7 Diagrama de la clase Buttons...49 Figura 5.8 Diagrama de la clase ValidateDatafield...49 Figura 5.9 Diagrama de la clase ConnectionMapServer...50 Figura 5.10 Diagrama de la clase XFormProperty...51 Figura 5.11 Árbol XML de los atributos...1 Figura 5.12 Diagrama de la clase XPDLDatafield...53 Figura 5.13 Ventana para definir atributo Map Viewer...54 Figura 5.14 Diagrama de casos de uso de CU_10 Editar formulario...56 Figura 5.15 Diagrama de actividades de xformeditor...56 Figura 5.16 Diagrama de secuencias de xformeditor...57 Figura 5.17 Diagrama de la clase Application...59 Figura 5.18 Diagrama de la clase XComponent...60 Figura 5.19 Diagrama de las clases XComponent y XTr...61 Figura 5.20 Ventana principal del editor de formularios...62 Figura 5.21 Código generado...62 Figura 5.22 Diagrama de la clase UserTreeBuilder...64 Figura 6.1 Definición de atributo Map Viewer...1 Figura 6.2 Pestaña de atributos...1 Figura 6.3 Especificación del servidor de mapas...1 Figura 6.4 Despliegue de catálogo procesado...1 Figura 6.6 Modificación del atributo Map Viewer...1 Figura 6.5 Pestaña de atributos del proceso...1 Figura 6.7 Atributo modificado...1 Figura 6.8 Mensaje de advertencia al eliminar atributo...1 Figura 6.9 Mensaje de confirmación para eliminar atributo...1 Figura 6.10 Atributo eliminado...1 Figura 6.11 Atributos propagados...78 Figura 6.12 Formulario con atributos inherentes...1 Figura 6.15 Código generado por xformeditor...80 Figura 6.13 Mensaje de sincronización...1 Figura 6.14 Formulario a guardar...1 iii

10 Figura 6.16 Posición original del atributo... 1 Figura 6.17 Atributo desplazado... 1 Figura 6.18 Atributo cambiado de posición... 1 Figura 6.19 Visor de mapas cargado con éxito Figura 6.20 Escala por defecto del visor de mapas... 1 Figura 6.21 Visor de mapas con zoom in... 1 Figura 6.23 Visor de mapas con paneo aplicado Figura 6.22 Visor de mapas con zoom out aplicado... 1 Figura 6.26 Capa de lagos activada Figura 6.24 Capas disponibles en el visor de mapas... 1 Figura 6.25 Vista de la capa carreteras... 1 Figura 6.27 Marcado de punto de interés Figura 6.28 Almacenamiento de punto de interés Figura 6.29 Recuperación de punto de interés Figura 6.30 Código del proceso existente Figura 6.31 Selección de archivo XPDL a abrir Figura 6.32 Reconocimiento del atributo Map Viewer Figura 6.33 Propiedades del atributo Map Viewer reconocido Lista de tablas Tabla 1.1 Comparativa de trabajos relacionados comerciales Tabla 1.2 Comparativa de trabajos relacionados de código abierto Tabla 5.2 Métodos de la inner clase CheckBoxItem Tabla 5.3 Métodos de la clase CheckBoxRenderer Tabla 5.4 Métodos creados en la clase Buttons Tabla 5.5 Métodos modificados de la clase ValidateDatafield Tabla 5.6 Métodos creados de la clase ConnectionMapServer Tabla 5.7 Métodos modificados de la clase XformProperty Tabla 5.8 Métodos modificados de la clase XPDLDatafield Tabla 5.9 Métodos modificados de la clase Application Tabla 5.10 Métodos agregados a la clase XComponent Tabla 5.11 Métodos de la clase XTr Tabla 5.12 Métodos modificados de la clase UserTreeBuilder Tabla 6.1 Descripción de las tareas de prueba Tabla 6.2 Herramientas de hardware Tabla 6.3 Herramientas de software Tabla 6.4 Resultados del caso de prueba GEOPROED Tabla 6.5 Resultados del caso de prueba GEOPROED Tabla 6.6 Resultados del caso de prueba GEOPROED Tabla 6.7 Resultados del caso de prueba GEOPROED Tabla 6.8 Resultados del caso de prueba GEOPROED Tabla 6.9 Resultados del caso de prueba GEOPROED Tabla 6.10 Resultados del caso de prueba GEOPROED Tabla 6.11 Resultados del caso de prueba GEOPROED Tabla 6.12 Resultados del caso de prueba GEOPROED Tabla 6.13 Resultados del caso de prueba GEOPROED Tabla 6.14 Resultados del caso de prueba GEOPROED Tabla 6.15 Resultados del caso de prueba GEOPROED Tabla 6.16 Resultados del caso de prueba GEOPROED Tabla 6.17 Resultados del caso de prueba GEOPROED iv

11 Tabla 6.18 Resultados del caso de prueba GEOPROED Tabla 6.19 Resultados del caso de prueba GEOPROED v

12 Glosario de términos y siglas API Interfaz de Programación de Aplicaciones (Application Programming Interface). Es un conjunto de rutinas que provee una aplicación, que definen cómo invocar desde un programa un servicio que ésta presta. Es decir, una interfaz de comunicación entre componentes de software. BPMN BPEL BSD CORBA Dato espacial EJB (Business Process Modeling Notation) Es un estándar que proporciona una notación gráfica para representar procesos de negocio. (Business Process Execution Language) También conocido como BPEL4WS, es un Lenguaje de Ejecución de Procesos de Negocio que define una notación basada en XML para especificar procesos de negocio basados en servicios Web. (Berkeley Software Distribution) Licencia de software que pertenece al grupo de licencias de software libre. Esta licencia al contrario que la GPL permite el uso del código fuente en software no libre. (Common Object Request Broker Architecture) La Arquitectura Común de Intermediarios en Peticiones a Objetos es un estándar definido y controlado por el Object Management Group (OMG). CORBA empaqueta el código en otro lenguaje, en un paquete que contiene información adicional sobre las capacidades del código que contiene y sobre cómo llamar a sus métodos. Los objetos que resultan, pueden ser invocados desde otro programa (u objeto CORBA) desde la red. Un dato espacial es un valor que representa la localización de un objeto en el espacio. Normalmente se utilizan datos vectoriales, los cuales pueden ser expresados mediante tres tipos de objetos: punto, línea y polígono. (Enterprise JavaBeans) Los EJBs proporcionan un modelo de componentes distribuido estándar del lado del servidor. Su objetivo es dotar al programador de un modelo que le permita abstraerse de los problemas generales de una aplicación empresarial (concurrencia, transacciones, persistencia, seguridad, entre otros) para centrarse en el desarrollo de la lógica de negocio. vi

13 ESRI GIS (Environmental Systems Research Institute) Es una empresa dedicada al desarrollo y comercialización de Sistemas de Información Geográfica. (Geographic Information System) Un Sistema de Información Geográfica es un sistema para modelar, representar, almacenar, manipular, consultar, analizar y visualizar información con un componente geográfico. Georeferenciación Es el posicionamiento en el que se define la localización de un objeto espacial en un sistema de coordenadas y datum determinado. Este proceso es utilizado frecuentemente en los sistemas de información geográfica (GIS). GML HSQLDB JAAS JDBC JDOM JMS JOnAS J2EE (Geographic Markup Language) El Lenguaje de Marcado Geográfico codifica la información geográfica en XML para permitir su almacenamiento, transporte, procesado y transformación a información geográfica. (Hyperthreaded Structured Query Language Database) Es un sistema gestor de bases de datos libre escrito en Java. HSQLDB está basado en HypersonicSQL, un proyecto abandonado en la actualidad. (Java Authentication and Authorization Service) El Servicio de Autentificación y Autorización de Java es un conjunto de APIs que permiten a las aplicaciones Java acceder a servicios de control de autentificación y acceso. (Java DataBase Connectivity) Es una API de Java que permite que programas en Java ejecuten comandos SQL, permitiendo esto que los programas puedan usar bases de datos. (Java Document Object Model) API para leer, crear y manipular documentos XML en Java. (Java Message Service) Es un estándar de mensajería que permite a los componentes de aplicaciones basados en la plataforma de Java 2 crear, enviar, recibir y leer mensajes. (Java Open Application Server) Es un servidor de aplicaciones J2EE de código abierto implementado en Java. (Java 2 Enterprise Edition) Define un estándar para el desarrollo de aplicaciones empresariales multicapa diseñado por Sun Microsystems. vii

14 J2SE (Java 2 Standard Edition) Versión básica del conjunto de herramientas y APIs de Sun Microsystems destinadas a la creación de aplicaciones en plataforma Java. OGC (Open Geospatial Consortium) El OGC agrupa a más de 250 organizaciones públicas y privadas, su fin es la definición de estándares abiertos e interoperables dentro de los Sistemas de Información Geográfica. Anteriormente fue conocido como Open GIS Consortium. OMG POI SLD URL WCS WfMC WFS WMS XHTML (Object Management Group) El Grupo de Gestión de Objetos es un consorcio dedicado al establecimiento de estándares de tecnologías orientadas a objetos, como UML, XMI, CORBA. (Points Of Interest) Un Punto de Interés es una ubicación sobre un mapa donde se encuentra un elemento de especial relevancia. (Styled Layer Descriptor) Es un lenguaje estándar propuesto por el OGC para describir el conjunto de capas dentro de un GIS. (Uniform Resource Locator) El Localizador Uniforme de Recurso es una secuencia de caracteres, de acuerdo a un formato estándar, que se usa para nombrar recursos en Internet. (Web Coverage Service) El Servicio de Cobertura Web es una especificación que define un protocolo de intercambio de información geoespacial en forma de coberturas, las cuales se encuentran en formato ráster. (Workflow Management Coalition) La Coalición de la Gestión de Flujo de Trabajo es un consorcio formado para definir las normas para la interoperabilidad de los sistemas de gestión de flujos de trabajo. (Web Feature Service) Especificación que define un protocolo de intercambio de información vectorial. (Web Map Service) El Servicio de Mapas Web es una especificación que define un protocolo de acceso y de creación de vistas de información de tipo mapa. (extensible Hypertext Markup Language) El Lenguaje extensible de Marcado de Hipertexto es el lenguaje de marcado pensado para sustituir a HTML como estándar para las páginas Web. Es la versión XML de HTML, tiene básicamente, las mismas funcionalidades, pero cumple las especificaciones más estrictas de XML. Su objetivo es avanzar en el proyecto del World Wide viii

15 Web Consortium de lograr una Web semántica, donde la información y la forma de presentarla estén claramente separadas. XML XPDL (extensible Markup Language) El Lenguaje de Marcado extensible es un metalenguaje de etiquetas desarrollado por el World Wide Web Consortium (W3C). (XML Process Definition Language) El Lenguaje de Definición de Procesos XML es un lenguaje para la definición de un flujo de trabajo (workflow) creado por WfMC. ix

16

17 Introducción Introducción Los sistemas de workflow permiten la automatización de los procesos de negocio, asociando personas y grupos de trabajo con actividades para manejar las tareas que se realizan dentro de una organización, haciendo posible la cooperación de distintas personas. Es por esto, que la incorporación de estos sistemas en las empresas e instituciones ha repercutido en el servicio y atención al cliente, eficiencia y productividad, debido a que los trámites se agilizan y con ello aumenta la eficacia de la empresa. Estos sistemas han mejorado sus características, con el fin de satisfacer las demandas de las organizaciones actuales. Entre las más destacables se tienen: acceso vía Web, modelado de los procesos de negocio gráfico, arquitecturas distribuidas, adopción de estándares para asegurar interoperabilidad, entre otros. 1

18 Introducción Con la aparición de los sistemas de información geográfica (GIS) y los servidores de mapas Web, el uso de información geográfica se ha extendido, lo cual se debe al grado de detalle con que se representa la información. Siguiendo esta vertiente los sistemas de workflow han buscado involucrar el procesamiento de información geográfica, lo cual se ha logrado mediante la incorporación de las funcionalidades que ofrecen los GIS. En este trabajo de tesis se aborda el problema de la integración de información espacial (georeferencial) a los procesos de negocio en sistemas de workflow, para lo cual se propone la modificación de un sistema de workflow de código abierto con el fin de agregar esta funcionalidad desde la fase de modelado de los procesos. Organización del documento La organización del presente documento de tesis es descrita a continuación: En el capítulo 1 se presenta el contexto de este trabajo, el cual consta de una breve descripción de los antecedentes de esta tesis; el planteamiento del problema; el objetivo perseguido; la justificación de este trabajo y los beneficios que con él se obtienen; el estado del arte y por último los alcances y limitaciones consideradas para el desarrollo de esta investigación. En el capítulo 2 se presenta el marco teórico, el cual contiene los conceptos relevantes para la comprensión de este documento de tesis, como los sistemas de workflow; los Sistemas de Información Geográfica (GIS); los servidores de mapas; la biblioteca OpenLayers y por último la API para manipulación de documentos XML JDOM. En el capítulo 3 se aborda el análisis del problema y la solución propuesta, en éste se describe el funcionamiento general del sistema Bonita workflow; el análisis realizado al sistema y el modelo de solución desarrollado tras el análisis efectuado. En el capítulo 4 se describe el diseño e implementación del sistema, en el cual se presentan los casos de uso y la implementación de las modificaciones para el editor de procesos ProEd, el editor de formularios xformeditor y la consola de administración de procesos jiapadmin. En el capítulo 5 se presentan las pruebas de funcionalidad aplicadas al sistema, se describe el plan de pruebas utilizado; los casos de pruebas y los resultados obtenidos de la aplicación de las pruebas. Por último en el capítulo 6 se presentan las conclusiones generadas con el desarrollo y evaluación de este trabajo de tesis; las aportaciones logradas durante esta investigación; los trabajos futuros y los reconocimientos y publicaciones logrados durante el desarrollo de este trabajo de tesis. 2

19 Capítulo 1. Antecedentes Capítulo 1. Antecedentes En este capítulo se presenta el contexto de este trabajo de tesis, el problema que se ataca, el objetivo perseguido, la justificación, los beneficios que con ella se obtienen, los alcances y limitaciones considerados para el desarrollo de esta investigación y por último la metodología seguida para dar solución al problema planteado. 1.1 Antecedentes La incorporación de los sistemas de workflow para la gestión de los procesos en las empresas ha repercutido en el aumento de su eficacia. Lo cual es un elemento clave para la competitividad de la empresa en el mercado independientemente del sector en el que opere. 3

20 Capítulo 1. Antecedentes Para satisfacer las necesidades actuales de las organizaciones estos sistemas han incorporado nuevas características, entre las más destacables se encuentra el acceso vía Web, arquitectura distribuida, adopción de estándares, entre otras. Por otra parte, el procesamiento y despliegue de información georeferencial en los sistemas informáticos se ha facilitado y difundido tras la aparición de los sistemas de información geográfica (GIS) y de los servidores de mapas Web. Las áreas de aplicación de un GIS son muy variadas, como se menciona en [DELG03] y [TINO08], destacando entre ellas: la gestión de instalaciones, catastro, planificación urbana, transporte, marketing geográfico, gestión de recursos naturales, tareas de protección civil, estudio de yacimientos arqueológicos, investigación científica y enseñanza, gestión territorial, recursos mineros, demografía, planimetría, cartografía digital 3D, entre otros. Se ha considerado que el uso de información georeferencial en los procesos de negocio aporta mayores elementos para realizar la toma de decisiones [NURI07]. Es por esto que los sistemas de workflow han considerado la integración de servicios espaciales, lo cual se ha logrado a través de la inclusión de los servicios que ofrecen los sistemas de información geográfica. Ejemplo de un sector que necesita de los beneficios que otorgan los sistemas de workflow relacionados con los sistemas de información geográfica, es el área de catastro en los municipios, esto se debe a que la mayor parte de sus trámites incorporan el uso de mapas y croquis. Ejemplo de estos son los trámites de licencias de construcción, solicitud de tomas de agua, reportes de fugas, entre otros. La tendencia que se ha dado en estas organizaciones es reducir al máximo los costos en cuanto a adquisición de productos de software, por tanto se ha optado por soluciones de código libre, siendo deseable contar con un sistema de workflow con dichas características que permita manipular datos georeferenciales. En este trabajo de tesis se presenta la integración de información espacial (georeferencial) a un sistema de workflow de código abierto, para contar con una herramienta de modelado de procesos de negocio que permita modelar procesos de negocio que involucren el uso de información georeferencial. 1.2 Planteamiento del problema Los procesos de negocio de algunas organizaciones requieren la manipulación de datos georeferenciales para una o varias de las actividades que comprenden el procedimiento, por ejemplo, la solicitud de un servicio como Internet, en la cual se debe indicar en un croquis la ubicación de la vivienda en donde se desea dicho servicio. Los sistemas de workflow que permiten modelar procesos con este tipo de información, en su mayoría son desarrollados a la medida o comerciales de 4

21 Capítulo 1. Antecedentes propósito específico, es decir, para un área en especial como lo es minería o catastro municipal. Aunado a esto, los sistemas comerciales impiden agregar nuevas funcionalidades al sistema debido a que no se permite el acceso al código fuente, presentan problemas de interoperabilidad con sistemas de otras compañías y el costo de las licencias de uso es alto. Por tanto, el problema que se tiene es que no es posible modelar procesos de negocio que involucren el uso de información georeferencial con los sistemas de workflow de propósito genérico, ya que no contemplan el uso de información georeferencial ni interacción con componentes de servicios espaciales durante la fase de modelado, ni en la aplicación Web generada. Debido al problema mencionado anteriormente, se requiere de un sistema de workflow genérico que permita modelar procesos de negocio que incluyan información georeferencial y que su licencia sea de software libre o de código abierto para evitar pagos por licencias. 1.3 Objetivo Modelar procesos de negocio que incorporen información georeferencial y generar de forma automática las aplicaciones Web correspondientes, mediante la modificación de una herramienta de definición de procesos cuya licencia sea de código abierto, integrando los componentes necesarios a la arquitectura del sistema de workflow. 1.4 Justificación y beneficios Los sistemas de workflow han evolucionado para cubrir las necesidades de las organizaciones, el acceso al sistema vía Web es un claro ejemplo de esto. Como se explica en [RENA03], estos sistemas brindan beneficios como: mejora en la atención y servicio al cliente; incremento del número de actividades ejecutadas; minimiza el tiempo requerido por los participantes para acceder a la documentación, aplicaciones y bases de datos; disminuye drásticamente el tiempo de transferencia de trabajo, información y documentos entre actividades; asegura la continua participación y colaboración de todo el personal en el proceso; disminuye el tiempo que los participantes, supervisores y administradores necesitan para conocer la situación de un proceso; entre otros. La herramienta resultante de este proyecto permite modelar procesos en donde se utilice información georeferencial para determinar la ubicación de un objeto en un mapa, con lo cual se amplía el panorama de la persona encargada de llevar a cabo la toma de decisiones. Los beneficios que se obtienen con este proyecto son: Soporte para el manejo de información georeferencial durante la definición del proceso de negocio. 5

22 Capítulo 1. Antecedentes Comunicación con servidores de mapas remotos y obtención de los catálogos de mapas disponibles. Generación automática de la aplicación Web para manejar los procesos definidos y que ésta permita el uso de información georeferencial. Eliminación del pago de licencias por uso o adquisición de software, ya que la herramienta es de código abierto. Se brinda información georeferencial en forma de mapas para la toma de decisiones. Además de los beneficios listados anteriormente, se dejan las bases necesarias para la incorporación de nuevos componentes al sistema de workflow Alcances y limitaciones Alcances: Los alcances considerados dentro de este trabajo de tesis se mencionan a continuación: La herramienta para la definición de procesos utilizada es de código abierto y ha sido modificada para agregar la funcionalidad del manejo de información georeferencial durante la fase del modelado de procesos de negocio. La herramienta de definición de procesos es capaz de interactuar con servidores de mapas para desplegar el catálogo de los mapas disponibles en éste. La consola de administración de procesos es de código abierto y se ha modificado siguiendo principios de usabilidad para hacerla fácil e intuitiva de usar para el usuario final. La aplicación Web generada es capaz de conectarse al servidor de mapas en tiempo real. La aplicación Web generada permite insertar y almacenar los puntos de interés. Limitaciones: A continuación se mencionan las limitaciones consideradas dentro de este trabajo de tesis: 6

23 Capítulo 1. Antecedentes Las herramientas para la definición de procesos a analizadas fueron de software libre y aquellas de código abierto por las cuales no se debe pagar ningún tipo de licencia. Sólo se consideró el trabajo con servidores de mapas GeoServer, por motivos de prueba. No se trabajó con la creación de los mapas del servidor de mapas, ni con la nomenclatura de sus nombres. Este trabajo se ajustó a las funcionalidades que la herramienta de definición de procesos posee. Se trabajó con la versión 3 del sistema de workflow Bonita. Los identificadores utilizados en el editor de procesos no deben contener espacios en blanco y deben ser únicos en todo el proceso Metodología de solución Para dar solución al problema planteado en esta tesis se realizaron las siguientes actividades: Estudio de sistemas de workflow. Se realizó un estudio de sistemas de workflow que incorporan el uso de información georeferencial, el estudio comprendió las siguientes actividades: Análisis comparativo. Esta actividad comprendió el análisis de los sistemas de workflow en base a características consideradas como deseables para este proyecto, se creó una tabla comparativa de estos sistemas con respecto al proyecto presentado en esta tesis. Elección del sistema a modificar. En base a la tabla comparativa se seleccionó el sistema de workflow de código abierto Bonita. Análisis del sistema de workflow Bonita. Se analizó el sistema para conocer su funcionamiento, componentes y arquitectura. Se determinaron los componentes a modificar para agregar la funcionalidad deseada. Una vez identificados estos componentes se realizaron las siguientes actividades: Ingeniería inversa al editor de procesos ProEd. Se aplicó este proceso al editor para comprender a detalle su funcionamiento y de esta manera identificar las clases a modificar para agregar la nueva funcionalidad. 7

24 Capítulo 1. Antecedentes Ingeniería inversa al editor de formularios xformeditor. Por medio de este proceso se comprendió la generación del código para formularios y se identificaron las clases a modificar. Modelo de solución. Se diseño el modelo de solución para integrar el uso de información georeferencial al sistema de workflow. Diseño de modificaciones. Se diseñaron las modificaciones a realizar, así como las ventanas que sirven de interfaz para el usuario. Implementación de las modificaciones. Pruebas. Para verificar la funcionalidad agregada al sistema se desarrolló y aplicó un plan de pruebas de acuerdo al estándar IEEE para pruebas de funcionalidad de software. En la figura (1.1) se representa la metodología anteriormente descrita. Estudio de sistemas de workflow. Análisis del sistema de workflow Bonita Diseño del modelo de solución Pruebas Implementación modificaciones Diseño de modificaciones Figura 1.1 Metodología de solución 8

25 Capitulo 2. Marco teórico Capítulo 2. Marco teórico En este capítulo se describen los conceptos necesarios para la clara comprensión de este trabajo, abarcando los sistemas de workflow, el lenguaje XPDL, servidores de mapas, la biblioteca OpenLayers, la API JDOM, entre otros. 2.1 Proceso de negocio Es un conjunto de uno o más procedimientos o actividades directamente ligadas, que colectivamente realizan un objetivo del negocio, normalmente dentro del contexto de una estructura organizacional que define roles funcionales y relaciones entre los mismos [WfMC99]. 9

26 Capítulo 2. Marco teórico 2.2 Workflow Es la automatización de un proceso, en el cual documentos, información o tareas se pasan de un participante a otro para su procesamiento, de acuerdo a un conjunto de reglas establecidas [WfMC99]. 2.3 Sistema de workflow Un sistema de workflow de acuerdo a la WfMC [WfMC99] se define como: Un sistema que define, crea y maneja la ejecución de workflows con el uso del software, funcionando en uno o más motores del workflow, que puede interpretar la definición de proceso, interactuar con los participantes del workflow y donde se requiera, invocar el uso de herramientas de tecnologías de información (IT) y aplicaciones. Un sistema de gestión de workflow consiste en componentes para almacenar e interpretar las definiciones de proceso, crear y manejar instancias de workflow, monitorear su ejecución y controlar su interacción con los participantes del workflow y aplicaciones Modelo de referencia La WfMC ha publicado un modelo de referencia de la arquitectura de un sistema de workflow, describiendo su estructura e interfaces. Figura 2.1 Modelo de referencia de un sistema de workflow En la figura (2.1) se muestran las interfaces y componentes que se pueden encontrar en la arquitectura del sistema de workflow. Estos componentes se describen a continuación: 10

27 Capítulo 2. Marco teórico Herramienta de definición de procesos Se utiliza para crear una descripción de los procesos en una forma procesable para una computadora. Esta herramienta puede estar basada en un lenguaje de definición de procesos formal, en un modelo de interacción entre objetos, o simplemente en un conjunto de reglas de ruteo para transferir información entre los participantes [MARRO99] Motor de workflow El motor de workflow es el software que provee el control del ambiente de ejecución de una instancia de workflow, típicamente provee facilidades para: interpretación de la definición de procesos; control de las instancias de los procesos: creación, activación, terminación, entre otros; navegación entre actividades; soporte de interacción con el usuario; control de datos al usuario o hacia aplicaciones e invocación de aplicaciones externas [GERO07] Servicio de representación de workflow Interpreta la descripción de procesos, controla las instancias de estos, las secuencias de actividades, adiciona elementos a la lista de trabajo de los usuarios, e invoca aplicaciones necesarias. Estas tareas son hechas por uno o más motores de workflow Interfaz de programación de aplicaciones de workflow (WAPI) Las WAPI pueden ser vistas como un conjunto de API s y funciones de intercambio soportadas por el servicio de representación de workflow, permiten la interacción del servicio de representación de workflow con otros recursos y aplicaciones. [GERO07] 2.4 Lenguaje de Definición de Procesos XML (XPDL) La WfMC ha identificado 5 interfaces funcionales en el área de workflow como parte de su programa de estandarización. El lenguaje XPDL forma parte de la interfaz uno (Definición de procesos de negocio, ver fig. 2.1). Esta interfaz apoya la independencia del diseño y la importación/exportación de éste a través de diferentes motores de workflow o de herramientas especializadas en modelado [CARO03]. El lenguaje XPDL usa una sintaxis basada en XML, los elementos principales son: paquete, aplicación, proceso de workflow, actividad, transición, participante y datos relevantes del workflow. Paquete. Un paquete puede contener varios procesos, compartiendo las herramientas y participantes. Se recomienda crear un paquete por proceso de negocio el cual debería de contener todo lo necesario para el proceso de workflow así como las herramientas asociadas y los participantes de workflow. También es posible definir partes de una definición de proceso o partes comunes de varios procesos dentro de un paquete. [WfMC05] 11

28 Capítulo 2. Marco teórico Aplicación. Es una lista de todas las aplicaciones o herramientas requeridas e invocadas mediante el proceso de workflow definido dentro de una definición de proceso o un paquete. [WfMC05] Proceso de workflow. Es usado para definir un proceso o parte de un proceso de workflow. Está compuesto de elementos del tipo actividad y transiciones [WILM03]. Actividad. Es el elemento básico de una definición de proceso de workflow. Los elementos de este tipo son conectados a través de transiciones. Hay 3 tipos de actividades: ruta, implementación, y bloque de actividades. Las actividades del tipo ruta son usadas para propósitos de ruteo. Las actividades del tipo bloque se ejecutan como un conjunto de actividades y las del tipo implementación son pasos en el proceso los cuales son implementados mediante procedimientos manuales, por una o más aplicaciones o por otro proceso de workflow (subflow) [WILM03]. Transición. Es el elemento que conecta dos actividades. Una condición de transición permite evaluar que condición es verdadera (TRUE), si no se especifica condición de enrutamiento la transición se comporta como si una condición con valor TRUE estuviera presente [WILM03]. Participante. Se usa para especificar los participantes en el flujo de trabajo. Hay 6 tipos de participantes: conjunto de recursos, recurso, rol, unidad organizacional, humano y sistema [WILM03]. Datos relevantes del workflow. Usa los elementos DataField y DataType, El dato es usado para tomar decisiones o para referirse a datos fuera del workflow, es pasado entre las actividades y subflows [WILM03]. 2.5 Sistema de Información Geográfica (GIS) Un Sistema de Información Geográfica es un sistema informático capaz de reunir, almacenar, manipular, y visualizar información geográficamente referenciada, es decir, datos identificados de acuerdo a su ubicación. Un GIS permite ver, comprender, cuestionar, interpretar y visualizar los datos de diversas formas que revelan las relaciones, patrones y tendencias en forma de mapas, globos, informes y gráficos. La mayoría de las veces se asocian a los GIS con los mapas. Un mapa, sin embargo, es sólo una forma en que se puede trabajar con datos geográficos en un GIS y son sólo un tipo de producto generado por éste. Un GIS puede ser visto de las siguientes tres formas [GIS07]: 1. Vista base de datos. Un GIS es un tipo único de base de datos, una base de datos geográfica (geodatabase), es decir, el GIS está basado en una estructura de base de datos que describe el mundo en términos geográficos. 12

29 Capítulo 2. Marco teórico 2. Vista Mapa. Un conjunto de mapas inteligentes y otras vistas que muestran características y relaciones en la superficie de la tierra. Los mapas de la información geográfica pueden ser construidos y usados como ventanas a la base de datos para soportar consultas, análisis y edición de la información. 3. Vista modelo. Un conjunto de herramientas de transformación de la información que obtienen un nuevo conjunto de datos geográficos de conjuntos de datos existentes. Estas funciones de geoprocesamiento toman información de conjuntos de datos existentes, aplican funciones de análisis y escriben los resultados dentro de nuevos conjuntos de datos obtenidos. 2.6 Servidor de Mapas Un servidor de mapas permite al usuario tener interacción con la información geográfica. El usuario accede a información en su formato original, de manera que es posible realizar consultas tan complejas como las que haría un GIS. Un servidor de mapas es, de hecho, un GIS a través de Internet. Los servidores de mapas implementan tecnologías que permiten el intercambio de formatos e información siguiendo las especificaciones WMS (Web Map Service), WCS (Web Coverage Service) y WFS (Web Feature Service) creadas por el OGC [HERR07]. Cualquier Servidor de Mapas en Internet puede actuar como cliente y como servidor y así compartir cartografía, visualizarla y operar simultáneamente con datos propios y remotos. Para que todos sean capaces de concatenarse interactuar, es preciso que los servidores de mapas en Internet sigan los estándares del OGC Funcionalidad de los servidores de mapas En [HERR07] y [SERR02] se mencionan las funciones que permiten realizar los servidores de mapas: Devolver metadatos del nivel de servicio. Devolver un mapa cuyos parámetros geográficos y dimensionales han sido bien definidos. Devolver información de características particulares mostradas en el mapa. Selección de elementos por combinación de capas o análisis con operadores espaciales de superposición, contención, intersección, entre otros. Edición básica de líneas por parte del cliente, de manera que el administrador del servidor de mapas puede recuperar esas líneas e incorporarlas a la cartografía. Conexión a bases de datos geográficas. Conexión a bases de datos alfanuméricos. 13

30 Capítulo 2. Marco teórico Identificación de atributos alfanuméricos en cada elemento cartográfico. Consultas de atributos alfanuméricos. Conexión de bases de datos locales a la base de datos remota del servidor de mapas. 2.7 GeoServer Es un servidor de mapas desarrollado bajo la especificación J2EE, esto permite el despliegue de la aplicación sobre cualquier servidor de aplicaciones, libres como Tomcat (Apache), JBoss (RedHat) o Geronimo (Apache) o propietarios como WebLogic (BEA), WebSphere (IBM), etc. Se destaca especialmente por el soporte para el protocolo WFS-T convirtiéndose no sólo en un servidor de cartografía sino en un intermediario para la edición remota de información geográfica mediante estándares [MONT07]. WFS-T (transaccional) indica la manera de hacer que el cliente y el servidor realicen transacciones sobre una base de datos. Bajo esta especificación es posible actualizar datos remotamente en el depósito de datos del servidor [CALV07]. GeoServer implementa WMS, WFS, WCS, SLD, GML, administración en entorno Web, compatibilidad con bases de datos espaciales (PostGIS, Oracle, ArcSDE y DB2) y archivos shapefile [MUÑO06] Estándares OGC soportados por GeoServer Servicio de Mapas Web (WMS) El WMS produce mapas de forma dinámica a partir de información geográfica vectorial o ráster, presenta la información como imágenes digitales. La imagen suele ser en formato ráster: PNG, GIF o JPEG, y ocasionalmente se representan como información vectorial en formato Scalable Vector Graphics (SVG) o Web Computer Graphics Metafile (WebCGM). Los mapas pueden superponerse unos a otros, siempre y cuando los parámetros geográficos y el tamaño de salida sean los mismos. El uso de formatos que permiten fondo transparente (GIF o PNG) facilita la visualización simultánea de estos mapas [CONS08]. El estándar define tres operaciones: 1. Devolver metadatos del nivel de servicio. 2. Devolver un mapa cuyos parámetros geográficos y dimensionales han sido bien definidos. 3. Devolver información de características particulares mostradas en el mapa. 14

31 Capítulo 2. Marco teórico Las operaciones WMS pueden ser invocadas a través de un navegador Web por peticiones URL, el contenido de ésta depende de la operación solicitada. Al solicitar un mapa, la URL indica qué información debe ser mostrada en el mapa, qué porción de la tierra debe dibujar, el sistema de coordenadas de referencia, la anchura y la altura de la imagen de salida [GEOP08]. Servicio de Fenómenos (WFS) El WFS [IDEE08a] permite recuperar y modificar (insertar, actualizar y eliminar) datos vectoriales codificados en lenguaje GML (Geographic Markup Language). Cada servicio puede manejar uno o más tipos de fenómenos, cada uno de los cuales tiene asociado un esquema XML que describe su estructura. Para acceder y manipular estos fenómenos geográficos, el estándar WFS define interfaces que operan mediante la utilización de HTTP. El almacén de datos utilizado para almacenar fenómenos geográficos puede ser opaco para la aplicación cliente, siendo el único acceso a los datos a través del interfaz del WFS. La única función de un WFS cuando interacciona con el sistema de almacenamiento de fenómenos geográficos, es asegurarse que los cambios realizados en los datos sean coherentes [PANA05]. Servicio de Coberturas Web (WCS) El Servicio de Cobertura Web es una especificación que define un protocolo de intercambio de coberturas ráster, es decir, información geográfica espacial digital que representa fenómenos de variación espacial (distribución continua), de modo que sean útiles para la representación o como dato de entrada de modelos científicos. Al igual que el Servicio de Mapas Web (WMS) y el Servicio de Fenómenos Web (WFS), permite al cliente seleccionar parte de la información, que posee el servidor, basándose en diferentes criterios, como por ejemplo las restricciones espaciales. Descriptor de los Estilos de los Temas (SLD) Especificación de OGC que describe el lenguaje para producir mapas georeferenciados con estilos definidos por el usuario. Es un lenguaje en XML para personalizar la apariencia de un mapa. Tiene una estructura propia, formado por el elemento principal StyledLayerDescriptor que contiene una secuencia de definiciones de estilos para las capas o para las entidades. La especificación establece que en el esquema SLD se debe definir lo siguiente: los elementos y atributos que pueden aparecer en el documento; los elementos que son elementos hijos de otros; el orden de los elementos hijos; los tipos de datos para los elementos y los atributos; los valores por defecto y fijos para los elementos y los atributos; si un elemento está vació o puede contener un texto [SANC08]. 15

32 Capítulo 2. Marco teórico Lenguaje de marcado geográfico (GML) El Lenguaje de Marcado Geográfico es una gramática XML definida como un esquema en XML, para la modelización, transporte y almacenamiento de información geográfica. GML [FERN05] ofrece una amplia variedad de objetos para describir la geografía incluyendo entidades, sistemas de coordenadas, geometría, topología, tiempo, unidades de medida y valores generalizados. La definición de GML se realiza utilizando esquemas. Los esquemas de la especificación se pueden personalizar para el modelo de datos, ya sea extendiéndolos o especializándolos. 2.8 OpenLayers OpenLayers es una API JavaScript de código abierto distribuida bajo la licencia BSD, permite el despliegue de los datos de los mapas en los navegadores Web sin dependencias del lado del servidor [OPEN08]. Dentro de sus principales características se encuentran: Cargar mapas de diversas fuentes: GeoServer, Google Maps, OpenStreetMap, Virtual Earth, Yahoo! Maps, MapServer, ka-map, Servidores World Wind. Implementa los protocolos de acceso a datos Web Map Service (WMS), Web Feature Service (WFS) Soporte GeoRSS Navegación mouse/teclado Adición de marcadores Selección de capas Como marco de trabajo, OpenLayers separa las herramientas de mapa de los datos de mapa con el fin de que todas las herramientas puedan funcionar sobre todas las fuentes de datos. 2.9 API JDOM JDOM es una API basada en una estructura de árbol, para procesar documentos XML con Java. Se trata de un enfoque abierto para parsear, crear, manipular y serializar documentos XML. Es una herramienta en Java, para trabajar con XML y creada para permitir el rápido desarrollo de aplicaciones de XML [LUNA04]. JDOM representa el documento XML como un árbol compuesto de elementos, atributos, comentarios, instrucciones de proceso, nodos de texto, secciones de CDATA, etc. El árbol completo está disponible en todo momento y se puede acceder cualquier parte en cualquier momento. JDOM no incluye por sí mismo un parser, 16

33 Capítulo 2. Marco teórico en vez de eso depende de un parser de SAX con un manejador de contenido común para analizar documentos y construir modelos JDOM a partir de estos. Una vez que el documento está cargado en memoria, ya sea porque fue creado de raíz o analizado desde un stream (flujo de información), JDOM puede modificar el documento. Un árbol de JDOM es de lectura y escritura, todas las partes del árbol pueden ser movidas, eliminadas y agregadas, todo esto respetando las restricciones de XML. 17

34 Capítulo 3. Estado del arte Capítulo 3. Estado del arte Incluir el uso de información georeferencial en los procesos de negocio ha generado diversos trabajos de investigación, debido a los beneficios que ofrece el procesamiento de este tipo información. Estos trabajos han dado como resultado diferentes métodos y formas de abordar el problema. En este capítulo se describen los trabajos más representativos sobre este tema, sus características más sobresalientes y las diferencias que presentan con el presente trabajo. 18

35 Capítulo 3. Estado del arte 3.1 Sistemas comerciales En esta sección se presentan los sistemas de workflow que han incorporado el procesamiento de información georeferencial, sin embargo estos han sido enfocados a campos específicos como a continuación se describe. GeoPISTA GeoPISTA [GEOP04a] es un sistema de información territorial para ayuntamientos desarrollado en España que implementa las funcionalidades necesarias para la gestión territorial. Permite elaborar pequeños procesos o flujos de trabajo [GEOP04b]. Está programado en lenguaje Java. En [GEOP06] se diferencian cuatro elementos: base de datos, servidores, clientes GIS y módulos. Los cuales se describen a continuación: Datos servidor. Funciona con el gestor de base de datos PostgreSQL, con la ampliación PostGIS para tratar con información geográfica. La base de datos se estructura según un modelo predefinido para cada ámbito de aplicación (infraestructuras, información de referencia, patrimonio, entre otros). Servicios básicos internos. El administrador de cartografía se encarga de servir la información geográfica en forma de mapas, gestionar usuarios con distintos permisos y resolver problemas de concurrencia de acceso a los datos. Clientes. GeoPISTA permite conectar SIG de soluciones comerciales típicas (ArcGis, MicroStation y AutoCAD) con el sistema. Módulos específicos. Una serie de módulos asisten en la gestión municipal, en ámbitos tales como planificación urbanística, tramitación de licencias de obra, infraestructuras, inspección de actividades contaminantes, entre otros. Dorado Dorado [CORA99] es un sistema venezolano de concesiones mineras que tiene como objetivo hacer más eficiente la gestión de solicitudes. El sistema está basado en ambiente cliente/servidor para el manejo de los datos, tanto espaciales como de los procesos administrativos. La coordinación de procesos es mediante el uso del producto M&B Process. La administración del modelo de datos espacial utiliza aplicaciones desarrolladas bajo librerías de objeto de MapObjects (ESRI). El sistema se divide en cinco módulos los cuales se describen a continuación: Módulo de atención al cliente. Provee las herramientas que permiten la administración y coordinación de todas las solicitudes. Módulo de tramitación. Permite el ingreso y validación de los recaudos de las solicitudes, asignación de trabajo entre los diferentes funcionarios y control del 19

36 Capítulo 3. Estado del arte tiempo de duración de cada proceso. El componente espacial cumple con las funciones de actualización del catastro y validaciones espaciales tanto en el ingreso de áreas como en los procesos de evaluación técnica. Módulo de fiscalización. Registra, da seguimiento y evalúa las actividades de exploración y explotación minera. Maneja el control de concesiones y administración de comerciantes de oro, diamantes y otras piedras preciosas. Abarca lo concerniente a impuestos, multas y extinción de derechos mineros. Módulo de información estadística ejecutiva. Presenta la información de negocio para la alta directiva del ministerio. Módulo de mantenimiento. Provee herramientas para dar soporte a los procesos del sistema como la actualización de la información y administración de la plataforma multiusuario de los datos espaciales, permite procesos de carga masiva de datos para la actualización de los datos del catastro inicial. ArcCadastre ArcCadastre [LANT07] es un sistema para gestionar información catastral y geográfica, así como para la generación de mapas, basado en GIS, maneja información de mediciones catastrales y de campo. ArcCadastre es un producto sueco desarrollado en cooperación con ESRI Inc. y basado en las siguientes plataformas: ArcGIS; Survey Analyst empleado para las funciones de planimetría y cálculo; ME Objects utilizado para importar y exportar datos en diferentes formatos de archivos [LANT03]. Las actividades son manejadas y monitoreadas con la ayuda de un flujo de trabajo. La forma más sencilla de éstos es una lista de control, mientras que los flujos más complicados requieren personalización, usando programación VB y C++. Una representación gráfica del flujo de trabajo se puede ver en el monitor durante todo el proceso. La información es almacenada en bases de datos geográficas. ArcCadastre da soporte para almacenar la información en varios gestores de bases de datos como: MS Access, Oracle, IBM e Informix. 3.2 Sistemas de código abierto Los sistemas de workflow de código abierto que a continuación se describen son los más representativos de esta comunidad. A diferencia de los sistemas comerciales, estos son de propósito genérico. JaWE / Shark JaWE [TOGE07] (Java Workflow Editor) es un editor de procesos de workflow gráfico basado en Java y XML. Es compatible con las especificaciones WfMC, por tanto, 20

37 Capítulo 3. Estado del arte puede ser usado como editor para diversos motores de workflow como Enhydra Shark, Open Business Engine (OBE), WfmOpen, entre otros. Utiliza el lenguaje de definición de procesos XPDL XML Process Definition Language versión 1.0 y permite la importación o referencia de procesos guardados en las nuevas definiciones de procesos. Shark [TOGE07] es un motor de workflow basado en las especificaciones WfMC y OMG (Object Management Group), el cual utiliza el lenguaje de definición de procesos XPDL. Permite ser utilizado en diferentes entornos como: aplicación Web, aplicación Swing, instalado como un servicio CORBA y accedido por aplicaciones cliente mediante CORBA ORB o en un contenedor EJB. Jbpm-designer de JBoos JBPM JBoss jbpm [JBOO07] es un sistema de workflow que es interoperable con todas las tecnologías de integración basadas en J2EE incluyendo servicios Web, mensajería Java, conectores J2EE, JDBC y EJBs. Los componentes de esta herramienta son: jbpm-server. Un servidor de aplicación JBoss preconfigurado. jbpm-designer. Plugin eclipse para crear procesos en forma gráfica, provee un modelo de programación orientado a procesos con el lenguaje de definición de procesos jpdl jboss Process Definition Language. jbpm-db. Paquete de compatibilidad de la base de datos. JBoss jbpm se puede configurar con bases de datos, como: Oracle, MySQL, Hypersonic SQL, PostgreSQL, entre otras. jbpm. Componente central, está desarrollado en Java (J2SE) para administrar definiciones de proceso y el ambiente de ejecución para las instancias de proceso. jbpm-bpel. Referencia a la extensión BPEL de JBoss jbpm. Intalio Intalio [INTA07] es un sistema de workflow de código abierto basado en la especificación J2EE desarrollado bajo la licencia MPL Mozilla Public License. Utiliza el lenguaje de procesos BPEL, genera servicios Web, permite la simulación de procesos y posee una interfaz de usuario Web Se identifican tres componentes principales: Herramienta para la definición de procesos. Es un ambiente de desarrollo integrado basado en eclipse para procesos de negocio BPMN. Permite que un modelo 21

38 Capítulo 3. Estado del arte BPMN se vuelva un proceso ejecutable sin escribir código, lo cual se alcanza con una combinación de algoritmos propietarios de generación de código. Servidor de Aplicaciones. Es donde residen los servicios de procesos de negocio. Motor de workflow. Ejecuta los procesos generados por el diseñador de procesos. Bonita workflow Bonita [BULL07] es un sistema de workflow genérico. Cumple con las especificaciones del modelo de la WfMC, está desarrollado bajo la especificación J2EE Java 2 Enterprise Edition y es distribuido bajo la licencia LGPL. Utiliza el lenguaje para definición de procesos XPDL. Los elementos principales de este sistema son: Consola de administración Web. Aplicación Web para la administración de los procesos así como para la interacción con los usuarios. Herramienta para la definición de procesos ProEd. Utiliza el lenguaje para definición de procesos XPDL, es accesible a través de la red. Incorpora un editor de formularios. Motor de workflow. Motor para la ejecución de procesos basado en el modelo de anticipación de la actividad. Lo cual permite un incremento en la rapidez en el diseño y desarrollo de fases de aplicaciones cooperativas. APIs. Serie de APIs que permiten un control total en la definición y ejecución de procesos. 3.3 Análisis comparativo A continuación se presenta una tabla comparativa entre los sistemas de workflow investigados con respecto al proyecto presentado en esta tesis (ver tablas 3.1 y 3.2). Los aspectos tomados como medidas de comparación se explican a continuación: Cliente Web. Se refiere a que el sistema de workflow debe incorporar un cliente Web (consola de administración de procesos Web), para que los usuarios puedan acceder a este desde cualquier punto de la red. Modelado Web. Indica si el workflow cuenta con una herramienta para la definición de procesos que pueda ser accedida vía Web, sin instalar algún software específico en la máquina de trabajo. 22

39 Capítulo 3. Estado del arte Editor de formularios. Este punto evalúa si la herramienta para definir procesos incorpora un editor de formularios, el cual es utilizado para definir y manipular formularios. Lenguaje de definición procesos. Se refiere al lenguaje que utiliza el editor de procesos, ya que en este proyecto se prefiere el uso de un lenguaje estandarizado con el fin de garantizar interoperabilidad con otros sistemas. Información espacial. Indica si el sistema contempla el uso de información de tipo espacial. J2EE. Indica si el workflow sigue la especificación J2EE, la cual dicta las pautas para el desarrollo de aplicaciones empresariales, distribuidas y multicapa. Uso. Se refiere al área hacia la cual está dirigido el uso del sistema de workflow. Licencia. El tipo de licencia bajo la cual es distribuido el sistema de workflow se toma como criterio de evaluación debido a que se desea tener la libertad de acceder y modificar el código fuente de éste. Tabla 3.1 Comparativa de trabajos relacionados comerciales Sistema Cliente web Modelado Web Editor formularios Lenguaje definición procesos Información espacial J2EE Uso Licencia GeoPISTA Catastro El Dorado Minería Propietaria ArcCadastre UML Catastro Propietaria En base a la comparativa presentada en la tabla (3.2), se decidió trabajar con el sistema de workflow Bonita, debido a que posee las características deseadas en este proyecto. Como se mencionó en el objetivo de esta tesis presentado en la sección 1.3, en este trabajo se ha buscado incorporar el uso de información georeferencial a un sistema de workflow, al seleccionar el sistema de Bonita workflow, se han heredado todas sus características. 23

40 Capítulo 3. Estado del arte Tabla 3.2 Comparativa de trabajos relacionados de código abierto Sistema Cliente web Modelado Web Editor formularios Lenguaje definición procesos Información espacial J2EE Uso Licencia JaWE XPDL Genérico LGPL jbpm jpdl Genérico LGPL Intalio BPEL, BPMN Genérico MPL Bonita XPDL Genérico LGPL Tesis XPDL Genérico LGPL 24

41 Capítulo 4. Análisis del problema y solución propuesta Capítulo 4. Análisis del problema y solución propuesta Para agregar la funcionalidad de manejo de información espacial al sistema de workflow, es necesario conocer a detalle el funcionamiento, los componentes y la arquitectura del sistema para determinar los módulos a modificar para agregar la funcionalidad deseada. En este capítulo se presenta el análisis realizado a los componentes del sistema de workflow Bonita (consola de administración de procesos, herramienta para la definición de procesos ProEd y motor de workflow), a partir del cual se determinaron los componentes a modificar y el modelo de solución. Se describe el funcionamiento general del sistema, así como la composición de cada uno de ellos, de tal forma que tras el análisis del editor de procesos (ProEd) se determinaron las clases a modificar. 25

42 Capítulo 4. Análisis del problema y solución propuesta 4.1 Funcionamiento general del sistema El sistema de workflow Bonita consta de tres componentes: motor de workflow, consola de administración de procesos (jiapadmin) y herramienta para la definición de procesos (ProEd del Inglés Process Editor). La consola de administración de procesos es la interfaz gráfica para el usuario, a través de la cual se administran los procesos de negocio y sus instancias almacenadas en el motor de workflow. La consola también se encarga de invocar al editor de procesos a petición del usuario. El editor de procesos ProEd es la herramienta para el modelado de procesos, utiliza parte de la notación de procesos BPMN (Business Process Modeling Notation) para la representación gráfica de los elementos del proceso. ProEd guarda el proceso de negocio en lenguaje XPDL, de acuerdo a los estándares de la WfMC. El proceso modelado es importado en la consola de procesos y desplegado en el motor de workflow, lugar donde se crea toda la lógica necesaria para dar soporte al proceso de forma automática. La comunicación entre estos elementos se ejemplifica en la figura (4.1). Figura 4.1 Funcionamiento del sistema Bonita workflow 4.2 Ingeniería inversa del sistema Bonita Motor de workflow El motor de workflow es ejecutado en el servidor de aplicaciones JOnAS, el cual proporciona los componentes necesarios (contenedor Web, contenedor EJB, servicios de mensajería, entre otros) para dar soporte a las funciones de lógica de negocios y de acceso a los datos. 26

43 Capítulo 4. Análisis del problema y solución propuesta La función del motor de workflow es proveer toda la lógica para gestionar los procesos y sus instancias, así como la relación de éstas con los usuarios. Su arquitectura está representada en la figura (4.2) y es descrita a continuación. Figura 4.2 Arquitectura del motor de Bonita workflow Las APIs de Bonita permiten que otras aplicaciones como jiapadmin puedan interactuar con el motor de workflow. Estas APIs son: API de usuario. Provee control total sobre procesos en ejecución, por ejemplo inicio o parado de una actividad. Recupera automáticamente la identidad de un usuario en el contexto de seguridad J2EE. API de registro de usuario. Permite crear y modificar las propiedades de un usuario dentro del sistema de Bonita. API del proyecto. Incorpora funciones para definir un proceso de workflow como creación de actividades, transiciones, roles, acciones, entre otros. De acuerdo a las funciones que se realicen, las APIs pueden llamar a los siguientes EJBs 1 : Registro de sesión de usuario. Proporciona la interfaz para: creación de usuarios; administración de usuarios y creación de grupos Sesión de proyecto. Proporciona la interfaz para: creación de procesos; definición de nodos (actividades) y aristas (transiciones); listado y modificación de propiedades. 1 Un EJB (Enterprise JavaBean) es un componente de software ejecutado del lado del servidor que agrupa funcionalidades y servicios para una aplicación, el cual puede ser ejecutado en un entorno multi-capa distribuido. 27

44 Capítulo 4. Análisis del problema y solución propuesta Sesión de usuario. Implementa comandos y peticiones relacionadas a: proyectos de un usuario; listas de tareas por hacer; ejecución de actividades; comandos de inicio/termino/cancelar. Bean de motor de sesión. Implementa la máquina de estados y controla la ejecución de procesos. Contenedor Administrador de Persistencia (CMP). El contenedor mapea automáticamente los campos de Bonita a su correspondiente tabla de la base de datos. Los campos son mapeados en Bonita: objetos simples, objetos serializables, entidades referenciadas y colecciones. Sesión XPDL. Módulo que analiza un documento XPDL. Durante el proceso de análisis del archivo XPDL, este modulo llamará directamente al bean de sesión de proyecto de la API. De hecho esta tarea llamará un cliente java el cual llevará a cabo la llamada al bean de sesión XPDL responsable del análisis y la interacción con la API de Bonita [VALD06]. Controlador de mensajes. Implementa la notificación de los cambios en la definición y ejecución dentro de un proceso de workflow. Cada interacción del usuario es notificada al núcleo de Bonita y dependiendo de las preferencias del usuario, puede lanzar o no un evento de mensajes a través de la API JMS (Java Message Service), la cual se encarga de redireccionar los mensajes ya sea por correo electrónico o mensajería instantánea. El mecanismo de autentificación es a través de JAAS, una forma estándar de configurar la seguridad de una aplicación J2EE. El manejo de los datos y las instancias de los procesos se lleva a cabo a través de una base de datos, el sistema de Bonita workflow utiliza la base que trae por defecto JOnAS, la cual es HSQL. Cabe destacar que Bonita es interoperable con el servidor de aplicaciones JBoss y con otros gestores de bases de datos (MySQL, PostgreSQL, entre otros). La administración de los formularios es llevada a cabo por formgenerator, el cual está basado en XForms, un lenguaje de marcado para formularios Web que separa los datos y la lógica de la presentación [VALD05]. Formgenerator utiliza el procesador de formularios Chiba, el cual permite utilizar Ajax o JavaScript dentro de estos [BLAC07]. formgenerator maneja los siguientes escenarios para el manejo de los formularios: 1. Invocar un formulario existente para la instancia del proceso en ejecución, esto se hace siempre y cuando exista un formulario XHTML, guardado previamente con el editor de procesos ProEd durante el modelado del proceso. 28

45 Capítulo 4. Análisis del problema y solución propuesta 2. Generar el formulario en tiempo real en base a los atributos definidos en el proceso guardado en formato XPDL. En base al análisis anterior se determina que para integrar el componente espacial dentro del formulario se aprovechará el primer escenario que maneja formgenerator Consola de administración de procesos jiapadmin La consola de administración de procesos jiapadmin, está desarrollada bajo el patrón Modelo-Vista-Controlador con struts 2, su arquitectura está representada en la figura (4.3). Figura 4.3 Arquitectura consola de procesos jiapadmin Dentro de la arquitectura el cliente representa cualquier navegador Web que acceda al servidor de aplicaciones que contiene al motor de workflow y a la consola de administración de procesos. Las páginas JSP son la interfaz con las cuales el usuario interactúa con el motor de workflow y el editor de procesos ProEd. La aplicación divide su contenido en la siguiente estructura de directorios: src etc (contiene los archivos de configuración de struts) java (contiene los EJB que definen la lógica de negocio) web (contiene las páginas JSP y demás recursos para crear la vista) 2 Struts es marco de trabajo (framework) para el desarrollo de aplicaciones Web que implementa el patrón de arquitectura Modelo-Vista-Controlador (MVC) en Java. 29

46 Capítulo 4. Análisis del problema y solución propuesta Funcionamiento La consola de procesos jiapadmin maneja 4 roles de usuario, para controlar el nivel de acceso y configuración para el sistema, éstos se describen a continuación: Administrador. Es el encargado de modificar la configuración básica para la administración de usuarios; agregar o eliminar usuarios y perfiles específicos y acceder a la configuración de los datos del motor de workflow. Es el usuario con mayores privilegios. Diseñador. Las operaciones que realiza un usuario con este rol son: acceder al editor de procesos para crear o modificar modelos de procesos; administrar modelos de procesos e importar procesos XPDL. Operador. Este tipo de usuario es el encargado de: fijar preferencias de usuario; desplegar, comprimir e iniciar un modelo de proceso; terminar instancias de modelos de procesos; acceder a información de las instancias de los modelos de procesos; iniciar, terminar o cancelar una actividad en una instancia especifica; configurar y administrar las bitácoras e históricos para las instancias de los modelos de proceso. Usuario. Sus actividades se enfocan a la ejecución y atención de actividades como: iniciar procesos; iniciar, parar y cancelar actividades y mostrar las actividades terminadas todavía visibles. Clases para el manejo de los menús java.webapp.bull.jiap.admin El archivo ApplicationResources.properties contiene todas las constantes de los mensajes a mostrar para las acciones a realizar dentro de la consola de procesos. Este archivo es declarado dentro del archivo de configuración strustconfig.xml, con lo cual se permite realizar el cambio de idioma a la consola. java.webapp.bull.jiap.admin.accessi En este paquete se encuentra la clase AccesSITreeBuilder, ésta provee la interfaz para acceder a los métodos necesarios para desplegar el menú del usuario con rol de administrador. Permite invocar las acciones de configuración más avanzadas como son las bases de datos de workflow e importación de hojas de estilo y logos. java.webapp.bull.jiap.admin.process En la carpeta java.webapp.bull.jiap.admin.process se encuentran las clases encargadas de generar los menús presentados a cada usuario de acuerdo a su rol: La clase UserTreeBuilder es la encargada de crear el menú de usuario, la cual maneja las opciones de iniciar proceso (start), actividades en ejecución (running), actividades realizadas recientemente (done) y actividades por realizar (to do). 30

47 Capítulo 4. Análisis del problema y solución propuesta La clase OperatorTreeBuilder crea el menú para el rol de operador. Esta clase construye el menú con las opciones: supervisar los procesos de negocio por instancias y actividades, configurar la información desplegada en los históricos. El menú del rol de diseñador es creado por la clase ConceptorTreeBuilder, permite realizar las opciones: importación de archivos XPDL, acceder al editor de procesos ProEd y eliminar modelos de procesos de negocio. El diagrama de clases del paquete process se muestra en la figura (4.4) Figura 4.4 Diagrama de clases del paquete java.webapp.bull.jiap. admin.process El lenguaje por defecto utilizado en la consola es Inglés, por tanto, se ha decidido cambiar a Español, además de simplificar el menú de usuario quitando las opciones de ver actividades realizadas recientemente (done) y en ejecución (running) Editor de procesos de negocio ProEd El editor ProEd, permite realizar el modelado de procesos de negocio de forma gráfica utilizando parte de la notación de procesos BPMN y lo almacena en lenguaje XPDL. Para el análisis de esta herramienta se realizó el proceso de ingeniería inversa al código fuente proporcionado por sus desarrolladores, para lo cual se utilizó la herramienta Poseidon para UML. 31

48 Capítulo 4. Análisis del problema y solución propuesta El código fuente del editor consta de 7 paquetes los cuales se describen a continuación: actions Contiene las clases para dar soporte a los eventos contemplados dentro del editor de procesos como creación, eliminación y modificación de: atributos, hooks, actividades, bloques de actividades, deadlines, entre otros. Dentro de este paquete la clase ValidateDatafield permite agregar o modificar un campo de datos de acuerdo a su tipo a nivel de proceso o actividad. Por tanto se ha considerado necesario modificar esta clase para contemplar el atributo del tipo espacial. tesis. El diagrama de clases de este paquete se encuentra en el anexo A de esta chi En este paquete se encuentran las clases que crean la interfaz gráfica del editor, el contenido de este paquete se aprecia en la figura (4.5). La clase principal del editor se encuentra dentro del paquete mainframe y se llama MainFrame.java. Figura 4.5 Contenido del paquete chi Dentro del paquete panels se encuentran las clases para construir los paneles de diálogo para la interacción con el usuario. Dentro de este paquete se encuentra la clase DatafieldDialog, que es la encargada de definir la interfaz de los diálogos correspondientes a la definición de los atributos dentro del proceso o actividad. tesis. El diagrama de clases de este paquete se encuentra en el anexo A de esta 32

49 Capítulo 4. Análisis del problema y solución propuesta Al analizar este paquete se ha determinado modificar la clase DatafieldDialog, de forma tal que contemple un nuevo tipo de atributo, así como agregar los métodos necesarios para dar soporte a la definición de éste. graphmodel Las clases de este paquete son las encargadas de representar cada uno de los elementos utilizados dentro del editor, éstos son: acción, parámetro de acción, conjunto de actividades, actividad básica, bloque de actividades, colección de actividades y transiciones, campo de datos, plazo, actividad final, hooks (ganchos), mapper, iteración, participante, asignación de intérprete, actividad de proceso, proyecto, propiedad, actividad raíz, sub-flujo, transición, versión y proceso de workflow. Por cuestiones de espacio el diagrama de clases de este paquete es presentado en el anexo A de esta tesis. plugin Contiene las clases para construir el editor de procesos como un plugin para ser usado por el entorno de desarrollo integrado eclipse. El diagrama de clases se muestra en la figura (4.6). Figura 4.6 Diagrama de clases del paquete plugin resources Las clases de este paquete contienen los valores constantes utilizados tanto para mandar mensajes como para crear los menús y elementos dentro del editor de procesos. El diagrama de clases de este paquete es presentado en la figura (4.7). 33

50 Capítulo 4. Análisis del problema y solución propuesta Figura 4.7 Diagrama de clases del paquete resources xform Contiene las clases XFormProperty y XFormProcess, estas clases agregan los atributos a la estructura de árbol de un archivo XML de acuerdo al tipo de atributo, es decir, manejan un flujo XML el cual será utilizado para la edición del formulario con el xformeditor. La figura (4.8) presenta el diagrama de clases de este paquete. Figura 4.8 Diagrama de clases del paquete xform xpdl En este paquete se encuentran las clases que representan los elementos del lenguaje XPDL, las cuales contienen métodos que permiten realizar la importación/exportación de cada uno de los elementos desde/hacia el archivo XPDL. La clase XPDLDatafield crea la estructura de un árbol XML con los atributos y actividades como nodos, por tanto, se ha decidido modificar para que reconozca el nuevo tipo de atributo y sea almacenado dentro de la estructura XML Editor de formularios xformeditor El componente xformeditor permite realizar la creación de los formularios a utilizar para capturar la información del flujo de trabajo y se encuentra embebido dentro del editor de procesos ProEd. Los formularios son creados mediante el uso de la API para Java Xecers que permiten la creación y el análisis de documentos XML, XHTML y HTML. La creación del fichero XML se realiza utilizando la API JDOM. En el paquete gui.xform se encuentran representados los componentes utilizados dentro del formulario, en el cual, en base al tipo de atributo definido en el archivo XPDL se construyen los elementos HTML. Por tanto, se decidió crear una clase dentro de este paquete que represente el nuevo atributo a integrar y modificar las clases pertinentes para que esta clase sea reconocida. En la figura (4.9) se presenta el diagrama de clases de este paquete. 34

51 Capítulo 4. Análisis del problema y solución propuesta Figura 4.9 Diagrama de clases del paquete gui.xform En el paquete gui.app (ver fig. 4.10), la clase Application define el componente central que crea, abre y configura un editor apropiado. Obtiene los documentos que se utilizarán en la aplicación, ya sea mediante una solicitud al servidor o mediante la creación de ellos. Se decidió modificar esta clase Application para agregar el visor de mapas dentro del árbol XML. Figura 4.10 Diagrama de clases del paquete gui.app Notación para atributos En base al análisis realizado sobre el funcionamiento de esta herramienta, se identificó que para el etiquetado de los identificadores de los atributos se tienen restricciones, las cuales se presentan a continuación: 35

52 Capítulo 4. Análisis del problema y solución propuesta No utilizar espacios en blanco Los identificadores de los atributos deben ser únicos en todo el proceso. 4.3 Modelo de solución Para dar solución al problema de integración de datos espaciales a los flujos de trabajo, se propone la modificación del editor de procesos ProEd, proporcionado por el sistema de workflow de código abierto Bonita, logrando que durante el modelado de un proceso de negocio se definan atributos de tipo espacial. En estos atributos se introducen las características necesarias para construir un visor de mapas de manera automática. Con esta implementación se proporciona una herramienta que permite definir atributos espaciales de forma gráfica, con la ventaja de establecer conexión en tiempo real con los servidores de mapas para obtener y procesar los catálogos de los mapas existentes, evitando al diseñador de procesos la labor de recolectar la información de los mapas existentes en los servidores. En base al análisis presentado en este capítulo se ha diseñado un modelo de solución, esquematizado en la figura (4.11). En él se presentan los tres componentes de Bonita workflow, ahora contando con el editor de procesos ProEd en su versión modificada el cual tendrá la funcionalidad de establecer comunicación con servidores de mapas. Así como la consola de procesos también podrá establecer comunicación en tiempo real con el servidor de mapas especificado dentro del atributo espacial. El modelo de solución se ha desarrollado bajo las siguientes premisas: Cuando un proceso se modela, los formularios a utilizar se guardan en el motor de workflow en formato XHTML, de forma que cuando el proceso es importado e interpretado para crear el flujo de trabajo, éste procesa los formularios y los invoca cada vez que se crea una instancia de proceso dentro del motor del workflow. El motor de Bonita workflow incorpora el generador de formularios formgenerator, el cual utiliza el procesador de formularios Chiba, que permite utilizar Ajax y JavaScript dentro de los formularios. Por tanto, el visor de mapas creado desde el editor de formularios xformeditor incorporado en ProEd será desarrollado en lenguaje JavaScript utilizando las instrucciones de la biblioteca OpenLayers. 36

53 Capítulo 4. Análisis del problema y solución propuesta Figura 4.11 Modelo de solución De acuerdo al modelo de solución (ver fig. 4.11), la interfaz de usuario es la consola de administración de procesos jiapadmin, la cual es accesible vía Web, ésta a petición del usuario llama al editor de procesos ProEd. En caso de declarar un atributo del tipo espacial, se despliega un panel con los campos de la información que requiere para definir el atributo. Se introduce la dirección del servidor de mapas y el editor de procesos se comunica con el servidor declarado, obtiene el catálogo de mapas, lo procesa y muestra una lista de los mapas disponibles. El diseñador realiza la selección de los mapas a desplegar, señalando cual mapa es tomado como base y el resto como capas. Una vez definidos los atributos se crea el formulario en memoria con xformeditor, y se guarda en el motor de workflow en formato XHTML. La consola de administración (jiapadmin) al instanciar un proceso, llama a formgenerator, quien tras verificar la existencia de un formulario para el proceso lo invoca. Este formulario al cargarse se comunica con el servidor de mapas a través 37

54 Capítulo 4. Análisis del problema y solución propuesta de la biblioteca OpenLayers, desplegando los mapas dentro del visor de mapas en el formulario donde se introduce la información a almacenar. La información introducida en el formulario es enviada al motor de workflow, éste se encarga de almacenarla en una base de datos guardando correspondencia de la información con la instancia del proceso. El análisis de los componentes del sistema de workflow Bonita dio como resultado el modelo de solución, en base al cual se realizó el diseño. El diseño y la implementación de solución son descritos en el siguiente capítulo. 38

55 Capítulo 5. Diseño e implementación del sistema Capítulo 5. Diseño e implementación del sistema El desarrollo de esta tesis involucró la modificación de la herramienta para la definición de procesos que pertenece al sistema de workflow Bonita, el cual se encuentra disponible en Internet como producto de código abierto. Se crearon y modificaron clases de forma que se agregó una nueva funcionalidad al sistema. En este capítulo se presenta el diseño e implementación de las modificaciones realizadas al editor de procesos ProEd y al editor de formularios xformeditor, presentando los diagramas de casos de uso, secuencias, actividades y clases, así como el diseño de las ventanas que sirven de interfaz para el usuario. 39

56 Capítulo 5. Diseño e implementación del sistema 5.1 Diseño de las modificaciones para el editor ProEd Las modificaciones realizadas al editor de procesos para incorporar la nueva funcionalidad corresponden a las siguientes funciones: Definición de atributos del tipo espacial. El editor es capaz de definir un atributo espacial con sus respectivas propiedades a nivel actividad y proceso. Modificación de atributos espaciales. Los atributos de tipo espacial pueden ser editados 3 y eliminados a través del editor. Propagación del atributo definido. El atributo espacial es propagado y usado en el resto de las actividades que comprenden el proceso de negocio. Petición del catálogo de mapas. El editor de procesos ProEd establece conexión al servidor de mapas y obtiene el catálogo de los mapas disponibles. Procesamiento del catálogo de mapas. Se procesa el catálogo de mapas recibido, se extrae el nombre de las capas con sus atributos y las despliega en forma de lista al diseñador. En las siguientes secciones se presenta una visión general de las funcionalidades que posee ProEd, la funcionalidad agregada y su integración con el resto de los componentes Casos de uso del editor ProEd El editor de procesos permite crear y modificar procesos de negocios, estos procesos están comprendidos por actividades, atributos (campos de un formulario), participantes, transiciones, entre otros. En la figura (5.1) se presentan los casos de uso del editor de procesos ProEd, donde los casos CU_1 y CU_2 son ejecutados directamente por el diseñador de modelos de procesos. Los casos de uso CU_3 y C_U4 están incluidos dentro del caso CU_1 crear proceso, estos se encargan de definir actividades y atributos respectivamente y permiten al diseñador especificar las propiedades de cada uno de ellos. El caso de uso CU_2 modificar proceso extiende los casos CU_5 y CU_6, los cuales permiten modificar las propiedades de las actividades y atributos respectivamente. Estos se realizan siempre y cuando exista un proceso previamente definido. 3 Editar un atributo hace referencia a modificar sus propiedades. 40

57 Capítulo 5. Diseño e implementación del sistema CU_3 Definir actividades <<include>> <<include>> CU_1. Crear proceso CU_4. Definir atributos Diseñador <<extend>> CU_2. Modificar proceso CU_5. Modificar actividades <<extend>> CU_6. Modificar atributos Figura 5.1 Diagrama de casos de uso del editor de procesos En la figura (5.2) se presenta el diagrama del caso CU_4 definir atributos. CU_7. Definir atributo cadena <<extend>> <<extend>> CU_8. Definir atributos decisión CU_4. Definir atributos <<extend>> <<include>> CU_9. Definir atributo espacial CU_10. Editar formulario Figura 5.2 Diagrama de casos de uso de CU_4 definir atributos 41

58 Capítulo 5. Diseño e implementación del sistema Del caso CU_4 los casos CU_7, CU_8 y CU_10 se encuentran implementados por el editor de procesos ProEd. El CU_10 fue modificado, el diseño sus modificaciones se explican a mayor detalle en la sección 5.4 de este capítulo. El caso CU_9 definir atributo espacial, corresponde a la nueva funcionalidad integrada al editor de procesos. El caso de uso que comprende el caso CU_9 se ilustra en la figura (5.3), éste es: CU_11 procesar catálogo del servidor de mapas. El CU_11 corresponde al proceso de establecer conexión al servidor de mapas, obtener el catálogo de mapas y procesarlo, extrayendo los nombres de los mapas y sus propiedades. Los escenarios de éxito y fracaso de cada uno de los casos de uso presentados en esta sección se encuentran en el anexo B de esta tesis. <<include>> CU_9. Definir atributo espacial CU_11. Procesar catálogo del servidor de mapas Figura 5.3 Diagrama de casos de uso de CU_9 definir atributo espacial Los casos de uso CU_1 al CU_11 presentados en las figuras (5.1), (5.2) y (5.3), se encuentran representados en el diagrama de actividades de la figura (5.4), en él se muestra el flujo de las actividades a realizar cuando se desea crear un componente espacial que de ahora en adelante es llamado Map Viewer dentro de una actividad o un proceso. En el diagrama de actividades (ver fig. 5.4) se presenta el escenario de éxito para la creación de un atributo del tipo espacial, se asume que un proceso ha sido creado previamente, así como las actividades que lo comprenden. 42

59 Capítulo 5. Diseño e implementación del sistema Diseñador ProEd xformeditor Definir atributo espacial Mostrar panel de propiedades Definir dirección servidor de mapas Conectarse al servidor de mapas Obtener catálogo Seleccionar mapas Desplegar lista de mapas disponibles Procesar catálogo Seleccionar mapa base Crear atributo Editar formulario Invocar xformeditor Desplegar editor de formulario Realizar cambios Guardar cambios Guardar formulario Figura 5.4 Diagrama de actividades de creación de un atributo espacial Para ilustrar la interacción entre los componentes del sistema y la nueva funcionalidad, en la figura (5.5) se presenta el diagrama de secuencias que presenta el escenario de éxito para la creación de un atributo del tipo espacial a nivel de actividad, se asume que ya ha sido creado un proceso y actividades dentro de él. En este escenario el diseñador de procesos accede a las propiedades de una actividad de un proceso ya definido y selecciona la opción agregar atributo. El editor de procesos muestra un panel general de atributos en donde despliega una lista de los posibles atributos a definir. El diseñador selecciona el atributo del tipo Map Viewer y el editor de procesos muestra el formulario correspondiente para introducir las propiedades. El diseñador introduce la URL del servidor de mapas y selecciona la opción conectar. El editor de procesos realiza la conexión con el servidor de mapas especificado y obtiene el catálogo de los mapas disponibles en éste. Una vez obtenido el catálogo realiza un procesamiento, donde extrae los nombres de los mapas disponibles y sus propiedades. Posteriormente despliega una lista de selección múltiple con los nombres de los mapas encontrados en el servidor. 43

60 Capítulo 5. Diseño e implementación del sistema : Diseñador 1: Define atributo ProEd xformeditor 2: Despliega panel general 3: Selecciona tipo Map Viewer 4: Despliega panel correspondiente 5: Introduce direccion servidor de mapas 6: Establece conexión al servidor 7: Obtiene catálogo de mapas 8: Procesa el catálogo 9: Despliega lista de mapas 10: Selecciona mapas requeridos 11: Almacena propiedades 12: Selecciona mapa base 13: Crea atributo espacial 14: Selecciona editar formulario 15: Envía descripción de atributos 16: Genera código del formulario 17: Despliega editor de formularios 18: Edita formulario 19: Guarda cambios 20: Guarda formulario 21: Despliega mensaje de formulario guardado 22: Guarda proceso 23: Almacena proceso en formato XPDL 24: Despliega mensaje de proceso guardado Figura 5.5 Diagrama de secuencia de creación de un atributo espacial 44

61 Capítulo 5. Diseño e implementación del sistema De la lista anterior, el diseñador selecciona los mapas a desplegar, indicando cual es tomado como mapa base. El resto de los mapas se consideran como capas sobrepuestas, las cuales podrán ser activadas o desactivadas dentro del visor de mapas por el usuario final. ProEd guarda las propiedades de cada uno de los mapas seleccionados dentro del atributo Map Viewer definido. Una vez definido el atributo se procede a editar el formulario, para esto, el editor de procesos envía los atributos al editor de formularios xformeditor. Para el atributo Map Viewer, xformeditor crea el código para el visor de mapas en base las propiedades del atributo. Después de esto, crea los elementos HTML dentro de un árbol XML. Se presenta al usuario la ventana con los atributos definidos, ordenándolos por orden de creación e indicando su tipo. El diseñador puede cambiar el orden de aparición de éstos, en base al cual el formulario será guardado. Una vez que se realizan los cambios necesarios se elige la opción guardar. Xformeditor se conecta al motor de workflow y guarda el formulario en formato XHTML. Por último el usuario selecciona lo opción guardar proceso, y el editor de procesos guarda el proceso en lenguaje XPDL, para su posterior importación desde la consola de administración de procesos. 5.2 Implementación de modificaciones sobre ProEd El editor de procesos de negocio ProEd fue modificado para agregar la funcionalidad del manejo de información georeferencial dentro de los procesos de negocio. Las modificaciones se realizaron en base a los casos de uso planteados en la sección anterior. Se trabajó con la versión 3.0 de Bonita, implementada en Java, el código fuente fue descargado con un cliente SVN 4, las instrucciones y ligas para realizar la conexión y descarga se encuentran en la siguiente liga: plugins/scmsvn/index.php?group_id=56. Las clases y métodos modificados se describen a continuación, clasificadas de acuerdo al paquete al que pertenecen. Archivo ProEd.properties En el archivo ProEd.properties se definen los valores a utilizar por el editor de procesos para la creación de los componentes de la aplicación. En este archivo se agregaron las constantes a utilizar por el atributo Map Viewer. 4 SVN (SubVersióN) es un sistema de control de versiones usado para que varios desarrolladores puedan trabajar en un mismo proyecto. 45

62 Capítulo 5. Diseño e implementación del sistema Paquete org.objectweb.proed.chi.panels La clase DatafieldDialog define la interfaz de los diálogos correspondientes a la definición de los tipos de datos. Los métodos modificados y agregados se describen a continuación (ver tabla 5.1): Tabla 5.1 Métodos de la clase DatafieldDialog Método Descripción Acción createpanelmap getmapserver setmapserver unpacklayersproperties topacklayersproperties buildcheckboxitems createpanelgeneral gettype checkfields settype setdata Crea el panel a utilizar para definir las características del atributo Map Viewer. Obtiene la dirección del servidor de mapas introducida en el panel. Fija el valor de la dirección del servidor de mapas, en el panel Map Viewer. Empaqueta las propiedades de cada mapa seleccionado. Desempaqueta las propiedades de los mapas seleccionados. Crea una lista de checkboxes para asociar al catálogo de mapas disponibles en el servidor de mapas. Define el panel general para agregar atributos al formulario. Se agregaron las acciones a realizar para la creación y despliegue del panel de control para crear un atributo Map Viewer. Obtiene el tipo de dato del atributo a crear. Se incorporaron acciones para reconocer el atributo Map Viewer. Comprueba que los campos requeridos no hayan sido dejados en blanco. A este método se le anexó un chequeo para verificar que el usuario seleccione un mapa como capa base. Este método fija el valor del tipo de dato del atributo en el panel, es usado para la edición de los atributos. Se anexo el reconocimiento del atributo Map Viewer. Fija las propiedades del atributo a editar en el panel de acuerdo a su tipo. Se anexaron las acciones para el despliegue de las propiedades del atributo Map Viewer. Agregado Agregado Agregado Agregado Agregado Agregado Modificado Modificado Modificado Modificado Modificado 46

63 Capítulo 5. Diseño e implementación del sistema firstmissingfield Este método verifica que se hayan definido valores dentro de los atributos. Se anexo la funcionalidad para corroborar la selección de un mapa como base. Modificado Además de los métodos agregados y modificados, descritos anteriormente, se crearon las clases inner que a continuación se describen. La clase CheckBoxItem es una inner class (clase interna) para manejar las casillas de verificación de los datos de una JList, sus métodos se encargan de llevar el control de activado y desactivado de las casilla de verificación. En la tabla (5.2) se describen los métodos de esta clase. Tabla 5.2 Métodos de la inner clase CheckBoxItem Método CheckBoxItem ischecked setchecked Descripción Fija el valor de la variable ischecked a falso. Retorna el valor de la variable ischecked Fija el valor de la variable ischecked, con el valor de la variable recibida. La clase interna CheckBoxRenderer extiende la clase JCheckBox e implementa ListCellRenderer. Esta clase permite corresponder los objetos JCheckBox a la lista JList. Los métodos que comprenden esta clase se encuentran descritos en la tabla (5.3). Tabla 5.3 Métodos de la clase CheckBoxRenderer Método CheckBoxRenderer getlistcellrenderercomponent Descripción Constructor que configura los colores para la lista de las casillas de verificación Retorna el elemento de la lista que ha sido seleccionado El diagrama de la clase DatafieldDialog se aprecia en la figura (5.6). 47

64 Capítulo 5. Diseño e implementación del sistema Figura 5.6 Diagrama de la clase DatafieldDialog Paquete org.objectweb.proed.chi.components La clase Buttons contiene la definición de los botones utilizados en las ventanas del editor de procesos. Los métodos agregados a esta clase se describen en la tabla (5.4). Tabla 5.4 Métodos creados en la clase Buttons Método createbuttonconnect createbuttonsavelayers Descripción Crea el botón Connect utilizado en la ventana de definición del atributo Map Viewer. Crea el botón SaveLayers utilizado en la ventana de definición del atributo Map Viewer. 48

65 Capítulo 5. Diseño e implementación del sistema El diagrama de la clase Buttons se aprecia en la figura (5.7). Figura 5.7 Diagrama de la clase Buttons Paquete org.objectweb.proed.actions La clase ValidateDatafield agrega o modifica un campo de datos de acuerdo al tipo de dato del atributo. Los métodos modificados de esta clase se describen a continuación (ver tabla 5.5): Tabla 5.5 Métodos modificados de la clase ValidateDatafield Método actionperformed Descripción Almacena los valores de un atributo dentro del proceso o una actividad. Este método se modificó para reconocer el atributo Map Viewer y de esta manera guardar sus propiedades. En la siguiente figura se presenta el diagrama de la clase ValidateDatafield (ver fig. 5.8). Figura 5.8 Diagrama de la clase ValidateDatafield 49

66 Capítulo 5. Diseño e implementación del sistema La clase ConnectionMapServer fue creada para proporcionar los métodos para acceder al servidor de mapas especificados por el diseñador, obtener el catalogo de mapas disponibles y procesarlo de forma que se obtengan los nombres y las propiedades de cada mapa. Los métodos que conforman esta clase son descritos en la tabla (5.6). Tabla 5.6 Métodos creados de la clase ConnectionMapServer Método connection obtainlayers arrange Descripción Recibe la URL del servidor de mapas y termina de construir la petición para obtener el catálogo de mapas. Procesa el catálogo recibido en XML y extrae las siguientes propiedades de cada elemento Layer: Nombre de la capa, SRS, BoundingBox (MinX, MinY, MaxX, MaxY). Ordena el catálogo procesado por el sistema de referencia (SRS). El diagrama de la clase ConnectionMapServer se encuentra representado en la figura (5.9), la cual es presentada a continuación. Figura 5.9 Diagrama de la clase ConnectionMapServer Paquete org.objectweb.proed.xform La clase XformProperty agrega los atributos a una estructura de árbol XML, la cual es utilizada por el editor xformeditor para crear el formulario que corresponde a cada actividad o proceso. Los métodos modificados dentro de esta clase se describen en la tabla (5.7). Tabla 5.7 Métodos modificados de la clase XformProperty Método XFormProperty Descripción Este constructor fue modificado para considerar como un atributo al tipo Map Viewer dentro del archivo XPDL. 50

67 Capítulo 5. Diseño e implementación del sistema El diagrama de la clase XFormProperty se aprecia en la figura (5.10). Figura 5.10 Diagrama de la clase XFormProperty Paquete org.objectweb.proed.xpdl La clase XPDLDatafield agrega los atributos (DataField) definidos a nivel proceso y actividad a una lista de atributos (DataFields) en una estructura de árbol XML, esta estructura es almacenada en un archivo XPDL que describe el proceso. En la figura (5.11) se presenta el diseño de árbol de los atributos, se presentan los cuatro elementos Datafield que se crean de acuerdo al tipo del atributo. El primer elemento de izquierda a derecha corresponde al atributo de tipo cadena (string), el segundo al atributo de decisión estática, el tercero al atributo de decisión dinámica y el cuarto al atributo MapViewer. (5.8). Los métodos modificados a la clase XPDLDatafield se describen en la tabla Tabla 5.8 Métodos modificados de la clase XPDLDatafield Método XPDLDatafield tomodel Descripción Este constructor fue modificado, de forma que el tipo de dato Map Viewer sea reconocido y almacenado dentro de la estructura del árbol. Este método permite cargar en memoria los atributos de un proceso previamente definido y almacenado en lenguaje XPDL, reconociendo cada uno de los elementos que lo conforman. Este método fue modificado para que reconozca los atributos del tipo Map Viewer. 51

68 Capítulo 4. Diseño e implementación del sistema Elemento DataFields Elemento DataField Elemento DataField Elemento DataField Elemento DataField Atributo Id Atributo Id Atributo Nombre Atributo Id Atributo Nombre Atributo Nombre Atributo Id Atributo Name Elemento DataType Elemento InitialValue Elemento DataType Elemento InitialValue Elemento InitialValue Elemento DataType Elemento DataType Elemento BasicType Atributo Type Elemento EnumerationType Elemento EnumerationValue Atributo Name Elemento EnumerationType Elemento EnumerationValue Atributo Name Elemento ExtendedAttributes Elemento ExtendedAttribute Atributo Name Elemento MapType Elemento MapValue Atributo Name Figura 5.11 Árbol XML de los atributos 52

69 Capítulo 4. Diseño e implementación del sistema El diagrama de la clase XPDLDatafield se aprecia en la figura (5.12). Figura 5.12 Diagrama de la clase XPDLDatafield Ventana agregada al editor de procesos ProEd La ventana (panel) utilizada para definir el atributo Map Viewer fue implementada en lenguaje Java siguiendo el diseño que la herramienta proporciona para los atributos que maneja por defecto (ver fig. 5.13). En esta se encuentras los elementos que a continuación se describen. (a). Campo de texto para introducir el nombre del atributo Map Viewer a crear. (b). Campo de texto para realizar la descripción del atributo. (c). Combo para seleccionar el tipo de atributo a definir. (d). Campo de texto para introducir la URL del servidor de mapas. (e). Botón para establecer comunicación con el servidor de mapas, indicado en el campo de texto (d). (f). Área de despliegue de los mapas disponibles en el servidor. (g). Botón para guardar los mapas seleccionados. (h).combo para seleccionar de la lista de los mapas seleccionados, cuál fungirá como mapa base. (i). Botón para guardar las propiedades definidas en el atributo. 53

70 Capítulo 5. Diseño e implementación del sistema (a) (b) (d) (c) (e) ( f ) (g) (i) (h) Figura 5.13 Ventana para definir atributo Map Viewer 5.3 Cuantificación de las modificaciones de ProEd Para cuantificar el total de las modificaciones realizadas al editor ProEd se utilizó el método de conteo por líneas de código (LOC 5 ) [PELA03]. Los indicadores utilizados se describen a continuación: LOC Base [LOC (B)]. Es el tamaño de la versión original del producto antes de realizar alguna modificación. LOC Agregado [LOC (A)]. Es el código agregado al programa. LOC Modificado [LOC (M)]. Es el código que sufre alguna modificación. LOC Suprimido. Es el código de la versión original que se suprime. LOC Reutilizado [LOC (R)].- Es el código tomado de una librería u otro programa al nuevo programa sin hacer alguna modificación. LOC cambiante. Es el tamaño de las modificaciones realizadas al programa original. La fórmula para calcular este valor se presenta a continuación: LOC cambiante = Agregado + Modificado LOC Total. Es el tamaño total de un programa, sin importar de dónde salió el código empleado. Su valor se calcula con la siguiente fórmula: LOC Total = Base - Suprimido + Agregado + Reutilizado 5 Por sus siglas en inglés Lines of Code 54

71 Capítulo 5. Diseño e implementación del sistema Los valores de los indicadores para el editor de procesos ProEd se presentan a continuación: LOC (B): LOC (A): 487 LOC (M): 1 LOC Suprimido: 0 LOC (R): 0 El valor de las modificaciones realizadas para integrar el manejo de información georeferencial al editor ProEd es presentado a continuación: LOC cambiante = = 488 El tamaño total del editor tras agregar la nueva funcionalidad es presentado con el LOC total, cabe aclarar que para calcular el LOC total el valor de las líneas agregadas es la suma de las líneas agregadas más las modificadas. LOC Total = = LOC 5.4 Diseño de las modificaciones para xformeditor El módulo xformeditor permite crear el formulario de los atributos definidos en el editor de procesos en formato XHTML. Sin embargo, no reconocía atributos de tipo Map Viewer, por tanto no poseía acciones a realizar al encontrar un componente de este tipo. Las modificaciones realizadas a xformeditor corresponden a las siguientes funcionalidades: Generación de código para el atributo Map Viewer. El editor de formularios es capaz de generar el código para un visor de mapas y que éste sea capaz de realizar las acciones de zoom in, zoom out, paneo, vista de capas e inserción de puntos. Manipulación del atributo Map Viewer. Xformeditor permite manipular el atributo Map Viewer de forma que el diseñador puede cambiarlo de posición. En las siguientes secciones se describe la funcionalidad integrada y su interacción con el editor de procesos Casos de uso del editor de formularios xformeditor En la figura (5.14) se presentan los casos de uso del módulo xformeditor, el caso de uso CU_10 está incluido dentro del caso CU_4 definir atributos y tiene relación directa con el diseñador. El caso de uso CU_10 incluye los casos CU_12 y CU_13, que hacen referencia a generar código del visor de mapas y guardar el formulario respectivamente. 55

72 Capítulo 5. Diseño e implementación del sistema Los escenarios de éxito y fracaso de cada uno de los casos de uso presentados en esta sección se encuentran en el anexo B de esta tesis. <<include>> CU_12. Generar código del visor de mapas CU_10. Editar formulario <<include>> CU_13. Guardar formulario Figura 5.14 Diagrama de casos de uso de CU_10 Editar formulario Las actividades a ejecutar para llevar a cabo los casos de uso presentados anteriormente son representadas a través del diagrama de actividades mostrado en la figura (5.15). Diseñador ProEd xformeditor Editar formuario Mandar atributos Generar script visor de mapas Crear elementos HTML Desplegar editor Realizar cambios Guardar cambios Guardar formulario en motor de workflow Figura 5.15 Diagrama de actividades de xformeditor 56

73 Capítulo 5. Diseño e implementación del sistema Para explicar de forma detallada la interacción entre los componentes ProEd y xformeditor, se presenta el diagrama de secuencias de la figura (5.16). En este diagrama se muestra el escenario de éxito para la creación de un formulario XHTML, se asume que previamente se ha definido un proceso, actividades y un atributo de tipo Map Viewer. : Diseñador ProEd xformeditor 1: Selecciona editar formulario 2: Envía atributos 3: Genera código del script del visor de mapas 4: Genera código formulario 5: Agrega elementos HTML dentro de un árbol XML 6: Despliega formulario 7: Reubica atributos 8: Selecciona guardar 9: Establece conexión con el motor de workflow 10: Guarda formulario 11: Despliega mensaje de formulario almacenado Figura 5.16 Diagrama de secuencias de xformeditor 57

74 Capítulo 5. Diseño e implementación del sistema Después de generar el código del atributo, se presenta al diseñador una ventana con el nombre y tipo del atributo definido. En esta tabla puede cambiar la posición del atributo, en caso de haber más, una vez que el diseñador realiza los cambios necesarios selecciona la opción guardar. Xformeditor establece comunicación con el motor de workflow y guarda el formulario en una carpeta con la notación correspondiente al proceso y actividad a la que pertenece el formulario. 5.5 Implementación de modificaciones sobre xformeditor El editor de formularios xformeditor fue modificado para agregar las acciones a realizar cuando se define un atributo del tipo Map Viewer dentro de una actividad o proceso. Esto es, crear los elementos HTML a utilizar en el formulario. Las modificaciones se realizaron en base a los casos de uso planteados en la sección 4.3 de este capítulo. El lenguaje de programación utilizado es Java, se trabajó con la versión 3.0 de xformeditor. El código fuente fue descargado del mismo sitio que el editor de procesos ProEd (ver sección 5.2). Las clases y métodos modificados se describen a continuación, clasificadas de acuerdo al paquete que pertenecen. Paquete org.jbrix.gui.app La clase Application define el componente central que crea, abre y configura el editor. Obtiene los documentos que se utilizarán, ya sea mediante una solicitud al servidor o la creación de ellos. Los métodos agregados y modificados dentro de esta clase se describen en la tabla (5.9). Tabla 5.9 Métodos modificados de la clase Application Método Descripción Acción createdocuments createscript createstyle Se encarga de crear los elementos HTML de acuerdo al tipo de atributo definido. A este método se le agregaron las acciones para el atributo Map Viewer, para generar los componentes del visor de mapas dentro del árbol XML y el formulario XHTML. Este método crea el contenido del script para especificar los mapas a desplegar en el visor de mapas, los cuales corresponden a los mapas seleccionados durante la definición del atributo Map Viewer. Crea el contenido del tag de estilo HTML <style>, el cual define las reglas de estilo a utilizar por el visor de mapas Modificado Agregado Agregado tokenize Separa los atributos de los mapas: nombre, sistema de referencia espacial (SRS) y BoundingBox (MinX, MinY, MaxX, MaxY). Agregado 58

75 Capítulo 5. Diseño e implementación del sistema El diagrama de la clase Application se presenta en la figura (5.17). Figura 5.17 Diagrama de la clase Application Paquete org.jbrix.gui.xform La clase XComponent es la clase base de todos los componentes del formulario e implementa las funcionalidades comunes. XComponent es responsable de manejar el mapeo de los tags XML de las subclases. Los métodos agregados dentro de esta clase se describen en la tabla (5.10). Tabla 5.10 Métodos agregados a la clase XComponent Método getcaptionmapviewer Descripción Obtiene el valor del título del componente, es decir, su nombre. 59

76 Capítulo 5. Diseño e implementación del sistema 5.18) El diagrama de la clase XComponent se muestra en la siguiente figura (ver fig. Figura 5.18 Diagrama de la clase XComponent En este paquete se creó la clase XTr, la cual se encarga de definir a los elementos de líneas y columnas dentro de la tabla HTML usada para definir el formulario, este elemento es utilizado para contener el visor de mapas. En la tabla (5.11) se describen los métodos que la conforman. 60

77 Capítulo 5. Diseño e implementación del sistema Tabla 5.11 Métodos de la clase XTr XTr() Método Descripción Constructor por defecto, requerido por la clase XComponent, el cual crea una instancia. XTr(String label) configure() Constructor que define una instancia, con un elemento label. Método para configurar la instancia. El diagrama de la clase Application y su relación con la clase XComponent se encuentra representado en la figura (5.29). Figura 5.19 Diagrama de las clases XComponent y XTr Paquete resources En este paquete se modificó el archivo jbrix.xcomponents.xml, el cual indica que clases definen los elementos utilizados en el editor de formularios. El código agregado indica la clase que maneja la etiqueta HTML <tr>, utilizada para contener el visor de mapas dentro del formulario a crear. Ventana del editor de formularios La ventana del editor de formularios se presenta en la figura (5.20) en ella se puede apreciar que el atributo del tipo Map Viewer ha sido reconocido. Se despliega el nombre del atributo definido por el editor de procesos y enseguida se indica el tipo de éste. 61

78 Capítulo 5. Diseño e implementación del sistema (a) Atributo Map Viewer Figura 5.20 Ventana principal del editor de formularios Desde el botón View Document XML (a) se abre la ventana con el código del formulario a crear, como se muestra en la figura (5.21). Figura 5.21 Código generado Una vez descrito el diseño de las modificaciones e implementado las modificaciones a cada componente, se ha logrado incorporar el manejo de 62

79 Capítulo 5. Diseño e implementación del sistema información georeferencial en el sistema de workflow a través un visor de mapas que permite la captura y almacén de puntos de interés. El correcto funcionamiento de estas modificaciones se presenta en las pruebas de funcionalidad descritas en el siguiente capítulo. 5.6 Cuantificación de las modificaciones de xformeditor Los cambios realizados al editor de formularios xformeditor se cuantifican mediante las líneas de código (LOC). A continuación se presentan los valores del código base [LOC (B)], código agregado [LOC (A)], código modificado [LOC (M)], código suprimido [LOC Suprimido] y código reutilizado [LOC (R)]. LOC (B): 9554 LOC (A): 301 LOC (M): 0 LOC Suprimido: 0 LOC (R): 10 Para cuantificar el tamaño de las modificaciones realizadas al programa original se utilizó LOC cambiante, el cual es la suma del código agregado y modificado. La fórmula para calcular este valor se presenta a continuación: LOC cambiante = Agregado + Modificado El tamaño total del programa modificado (LOC total) fue calculado con la siguiente fórmula: LOC Total = Base - Suprimido + Agregado + Reutilizado El valor de las modificaciones realizadas al editor xformeditor y el tamaño total del editor (LOC total) tras agregar la nueva funcionalidad se presentan a continuación: LOC cambiante = = 488 LOC Total = = 9865 LOC 5.7 Diseño de las modificaciones para la consola jiapadmin Las modificaciones consideradas para la consola de administración de procesos jiapadmin corresponden a: Cambio de idioma de Inglés a Español para facilitar la interacción con el usuario. Simplificar el menú de usuario. 63

80 Capítulo 5. Diseño e implementación del sistema 5.8 Implementación de las modificaciones sobre la consola jiapadmin Las modificaciones realizadas a la consola de administración de procesos son descritas a continuación. java.webapp.bull.jiap.admin Se creó el archivo ApplicationResources_es.properties, el cual contiene las constantes de los mensajes a mostrar dentro de jiapadmin en Español. Este archivo es declarado dentro del archivo de configuración strust-config.xml. web.scripts La configuración de la gama de colores, tipos y tamaños de letra, márgenes, posición de objetos, entre otros, se realizó mediante la modificación de la hoja de estilo admin.css. De esta forma se obtiene el control del formato de la información a mostrar. java.webapp.bull.jiap.admin.process En este paquete se modificó la clase UserTreeBuilder, la cual es la encargada de crear el menú de usuario. Se simplificó el menú eliminando las opciones de ver actividades en ejecución (running) y actividades realizadas recientemente (done) y se eliminaron los métodos addprocessesstartednodes y addactivitiesdonenodes. Los métodos modificados en esta clase se describen a continuación: Tabla 5.12 Métodos modificados de la clase UserTreeBuilder Método Descripción Acción addusernode Este método agrega los nodos al menú correspondiente. Modificado rebuildusertree Este método construye el menú del rol de usuario, se eliminaron las opciones de: ver actividades en ejecución (running) y actividades realizadas recientemente (done). Modificado El diagrama de la clase UserTreeBuilder se presenta en la siguiente figura (ver fig. 5.22) Figura 5.22 Diagrama de la clase UserTreeBuilder 64

81 Capítulo 6. Pruebas Capítulo 6. Pruebas Para probar que el sistema de workflow modificado permite modelar procesos de negocios que involucren información georeferencial, se desarrolló un plan de pruebas de acuerdo al estándar IEEE para pruebas de funcionalidad de software. En este capítulo se presenta la hipótesis a probar, la descripción del plan de pruebas y los resultados obtenidos de las pruebas. 65

82 Capítulo 6. Pruebas 6.1 Hipótesis Al modificar la herramienta de definición de procesos para agregar el uso de información georeferencial es posible modelar procesos de negocios que involucren este tipo de información y la aplicación Web generada será capaz de manipularla. 6.2 Convención de nombres La convención de nombres que se utiliza para evaluar la funcionalidad del sistema se presenta a continuación: GEOPROED GEO: Geospatial (Geoespacial) PRO: Process (Proceso) ED: Editor (Editor) 6.3 Plan de pruebas a) Introducción El presente plan de pruebas está basado en el estándar IEEE [IEEE98] para pruebas de software, el cual permite verificar la funcionalidad agregada a la herramienta para definición de procesos ProEd. La cual consiste en definir atributos espaciales en la fase de modelado del proceso y generar de forma automática el código para éste. También se verifica que la aplicación Web generada contenga los atributos espaciales definidos en el modelo del proceso e interactúe con servidores de mapas para obtener los servicios que estos ofrecen. Para evaluar esta funcionalidad se realizan pruebas para la definición de atributos espaciales dentro del editor de procesos ProEd; la generación del código correspondiente al atributo definido a través de xformeditor, la interacción de la aplicación Web generada con servidores de mapas. En las pruebas se modela un proceso de negocio que involucra atributos espaciales, definidos tanto a nivel proceso como actividad. A partir del proceso modelado, se realiza el guardado del formulario en el motor de workflow y la importación del proceso en lenguaje XPDL al motor de workflow a través de la consola de administración de procesos jiapadmin. Una vez realizado el proceso anterior se puede realizar la ejecución de los procesos modelados para evaluar el resultado. Este plan de pruebas contiene los siguientes puntos: elementos de prueba, características a ser probadas, características excluidas de las pruebas, enfoque, criterio éxito/fracaso de casos de prueba, criterio de suspensión y requisitos de reanudación, tareas de pruebas, liberación de pruebas, requisitos ambientales, 66

83 Capítulo 6. Pruebas responsabilidades, riesgos y contingencias, procedimiento de pruebas y resultados obtenidos. b) Elementos de prueba Los casos de prueba tienen como fin validar y verificar que en la fase de modelado de un proceso se definen atributos espaciales y a partir de este modelo se genera de forma automática la aplicación Web correspondiente con componentes espaciales. Para realizar las pruebas es necesario modelar procesos de negocios, los cuales son creados considerando que deben tener atributos espaciales a nivel actividad y proceso. El servidor de mapas a utilizar es GeoServer, del cual se toman los servicios que presta y que permitirá que se obtenga un entorno distribuido. c) Características a probar Las características a probar se enlistan a continuación: Definición de atributos de tipo espacial. Se evaluará que atributos espaciales (de ahora en adelante llamados Map Viewer) sean definidos tanto a nivel actividad como proceso. Obtención del catálogo de mapas. Se verificará que el editor de procesos (ProEd) pueda establecer conexión al servidor de mapas GeoServer y que obtenga el catálogo de mapas. Procesamiento del catálogo de mapas. Se procesará el catálogo de mapas recibido del servidor de mapas en formato XML, extrayendo el nombre de las capas y sus atributos, desplegándolos en forma de lista al diseñador. Propagación del atributo definido. El atributo Map Viewer puede ser propagado y usado en el resto de las actividades que comprenden el proceso de negocio. Generación de código para el atributo Map Viewer. Se comprobará que el editor de formularios sea capaz de generar el código necesario para crear un visor de mapas. Interacción del formulario creado con el servidor de mapas. Se verificará que el visor de mapas embebido los formularios de la aplicación Web se comuniquen con el servidor de mapas especificado en las propiedades durante el modelado del proceso. Interacción con el mapa. Se corroborará que se puedan realizar las operaciones: zoom in, zoom out, paneo, vista de capas e inserción de puntos en el mapa desplegado dentro del visor de mapas. 67

84 Capítulo 6. Pruebas Almacenamiento de puntos de interés. Se verificará que se almacenen y recuperen los puntos de interés correspondientes a cada instancia de proceso y a cada visor de mapas en caso de haber más de uno. d) Características excluidas de las pruebas Las siguientes características no formarán parte del criterio de evaluación: Diseño de la interfaz de usuario. Funcionamiento del motor de workflow. Funcionamiento de la consola de administración de procesos jiapadmin. Uso de versiones de software diferentes a las establecidas en los requisitos ambientales descritos en el inciso (j) e) Pruebas realizar GEOPROED-01 Definición de formularios con datos espaciales. GEOPROED Definición del atributo Map Viewer GEOPROED Procesamiento del catálogo de mapas. GEOPROED Modificación del atributo Map Viewer GEOPROED Eliminación del atributo Map Viewer GEOPROED Propagación del atributo Map Viewer GEOPROED-02 Generación de formulario GEOPROED Generación del código para el atributo Map Viewer GEOPROED Manipulación del atributo Map Viewer dentro del formulario GEOPROED-03 Conexión de la aplicación Web con el servidor de mapas. GEOPROED-04 Interacción con el mapa. GEOPROED Realizar zoom in sobre el mapa GEOPROED Realizar zoom out sobre mapa GEOPROED Paneo sobre el mapa GEOPROED Manipulación de capas GEOPROED Inserción de puntos de interés (POIs) GEOPROED-05 Almacén de puntos de interés (POIs) GEOPROED Inserción de puntos de interés GEOPROED Recuperación de puntos de interés GEOPROED-06 Reconocimiento de atributos Map Viewer a partir de un proceso existente. e) Enfoque Las pruebas a realizar sólo serán para probar el uso de información espacial, ajustándose a las limitantes que tiene la herramienta con respecto a otras características, es decir no se hará ninguna mejora en cuanto al resto de las funcionalidades que ofrece. 68

85 Capítulo 6. Pruebas f) Criterio éxito/fracaso de casos de prueba La decisión de éxito o fracaso para cada uno de los casos de prueba descritos en el presente documento, se basará en la comparación de los resultados esperados contra los resultados obtenidos. Se considera que una prueba ha pasado con éxito cuando los resultados obtenidos coincidan con los resultados esperados descritos para cada unos de los casos de prueba. En caso de que la prueba no resulte con éxito, se analizarán las causas y se realizarán las modificaciones necesarias hasta obtener los resultados esperados. g) Criterios de suspensión y requerimientos de reanudación No se establece ningún criterio de suspensión de prueba. Cuando ocurra el escenario de que una prueba no cumple con los resultados esperados, ésta se analizará y corregirá las veces que sean necesarias hasta obtener los resultados esperados. h) Tareas de pruebas En este apartado se describen las tareas a desarrollar para preparar y aplicar las pruebas de este plan (ver tabla 6.1). Tabla 6.1 Descripción de las tareas de prueba Tarea Tarea precedente Habilidades Responsabilidad 1. Planificación de pruebas Evaluación de métodos de solución. Conocimiento del estándar IEEE 829 y del funcionamiento del sistema de workflow Bonita. Autora de tesis 2. Diseño de pruebas Tarea 1 Conocimiento de los objetivos de esta tesis, de los módulos del sistema de workflow Bonita. Autora de tesis 3. Ejecución de pruebas Tarea 2 Conocimiento de módulos y funcionamiento general del sistema de workflow Bonita. Autora de tesis 4. Depuración de errores 5. Evaluación de resultados Tarea 3 Tarea 2 y 3 Conocimiento de: Lenguaje de programación Java. Ambiente de desarrollo integrado. Servidores de mapas. Uso de la biblioteca OpenLayers. Conocimiento del objetivo, alcances, limitaciones e hipótesis de prueba de la investigación de esta tesis. Autora de tesis Autora de tesis 69

86 Capítulo 6. Pruebas i) Liberación de pruebas La liberación de las pruebas se basará en la comparación de los resultados obtenidos contra los esperados, si ambos coinciden se tomará como objetivo alcanzado y por tanto la prueba será aceptada. j) Requisitos ambientales La tabla (6.2) describe las características físicas del ambiente de prueba. Tabla 6.2 Herramientas de hardware. Hardware PC de escritorio (Servidor) PC de escritorio o laptop (Cliente) Características Procesador Pentium 4 Core Duo 1 GB de memoria en RAM 150 GB de capacidad en disco duro Tarjeta de red Ethernet 10/100Mbps Procesador Pentium 4 o superior 1 GB de memoria en RAM 80 GB de capacidad en disco duro o superior Tarjeta de red Ethernet/Wireless En la tabla (6.3) se describen las características de software del ambiente de prueba. Tabla 6.3 Herramientas de software. Software PC de escritorio (Servidor) PC de escritorio o laptop (cliente) Descripción Sistema Operativo Suse 10.2 / Windows XP Java 2 Standard Edition Development Kit (J2SE) Servidor de aplicaciones JOnAS con apache Ant. Sistema de workflow Bonita v 3.0 Navegador Web Mozilla 2.0 o superior Servidor de mapas GeoServer Biblioteca OpenLayers Java 2 Standard Edition Development Kit (J2SE) Navegador Web Mozilla 2.0 o superior k) Responsabilidades La responsabilidad de realizar e implementar las pruebas que se han especificado en este plan recae sobre la autora de esta tesis, ISC Catalina Aranda Castillo. La cual se encargará de modelar los procesos, editar los formularios, importar el proceso modelado, ejecutar las instancias del proceso y comparar los resultados obtenidos con los esperados. 70

87 Capítulo 6. Pruebas l) Riesgos y contingencias Se tomará el tiempo necesario para corregir los errores de los casos de prueba, aun cuando se afecte el tiempo programado en el cronograma de actividades. En caso de presentarse problemas no considerados, deberán ser resueltos por la responsable de la tesis. l) Aprobación El plan de pruebas debe ser aprobado por el director de esta tesis, el Dr. Juan Gabriel González Serna. 6.4 Casos de pruebas En esta sección se describe el propósito de cada caso de prueba desarrollado para evaluar la funcionalidad del editor de procesos ProEd. La descripción completa de cada caso de prueba se encuentra en el anexo C de esta tesis. GEOPROED Definición del atributo Map Viewer La prueba consiste en verificar la creación de un atributo Map Viewer, el cual contendrá las propiedades necesarias para crear un visor de mapas dentro del formulario del proceso o actividad correspondiente. GEOPROED Procesamiento del catálogo de mapas. La prueba consiste en verificar el procesamiento del catálogo obtenido del servidor de mapas, que consiste en extraer los nombres y atributos de los mapas disponibles en el servidor de mapas. GEOPROED Modificación del atributo Map Viewer La prueba consiste en verificar la modificación de las propiedades definidas en un atributo Map Viewer, permitiendo cambiar el servidor de mapas así como los mapas a desplegar. GEOPROED Eliminación de un atributo Map Viewer La prueba consiste en verificar que la herramienta sea capaz de eliminar atributos del tipo Map Viewer, de la definición del proceso. GEOPROED Propagación dato Map Viewer La prueba consiste en verificar la propagación de los atributos Map Viewer, es decir, que éstos puedan ser utilizados por las actividades definidas posteriormente. GEOPROED Generación del código para el atributo Map Viewer La prueba consiste en verificar que el editor de formularios genere el código para crear el visor de mapas correspondiente al atributo Map Viewer. 71

88 Capítulo 6. Pruebas GEOPROED Manipulación del atributo Map Viewer dentro del formulario La prueba consiste en verificar que el editor de formularios permita manipular el atributo Map Viewer, de forma que el diseñador pueda cambiarlo de posición. GEOPROED-03 Conexión de la aplicación Web con el servidor de mapas. La prueba consiste en verificar que los formularios de la aplicación Web establezcan comunicación con el servidor de mapas y reciban como respuesta el mapa solicitado, desde el proceso en ejecución a través del visor de mapas. GEOPROED Realizar zoom in sobre el mapa La prueba consiste en verificar que se pueda realizar la operación de zoom in (acercamiento) sobre el mapa. GEOPROED Realizar zoom out al mapa La prueba consiste en verificar que se pueda realizar la operación de zoom out (alejamiento) sobre el mapa. GEOPROED Paneo sobre el mapa La prueba consiste en verificar el movimiento del mapa (paneo) hacia la dirección que el usuario desee, con el fin de visualizar las zonas del mapa que se encuentran fuera de la pantalla del visor de mapas. GEOPROED Manipulación de capas La prueba consiste en verificar que se puedan activar y desactivar la visualización de las capas disponibles en el visor de mapas. GEOPROED Inserción de puntos de interés La prueba consiste en verificar que se puedan marcar puntos de interés (POIs) sobre el mapa a través del visor de mapas. GEOPROED Inserción de puntos de interés (POIs) La prueba consiste en verificar que el punto de interés insertado por el usuario se almacene en la instancia del proceso en ejecución. GEOPROED Recuperación de puntos de interés (POIs) La prueba consiste en recuperar y dibujar el punto de interés marcado por el usuario sobre el mapa, el cual corresponde a la instancia del proceso en ejecución. GEOPROED-06 Reconocimiento de atributos Map Viewer a partir de un proceso existente La prueba consiste en verificar el reconocimiento de atributos Map Viewer, los cuales se encuentran definidos en un proceso de negocio existente. Este proceso está almacenado en un archivo XPDL. 72

89 Capítulo 6. Pruebas 6.5 Resultados de pruebas Los resultados obtenidos una vez realizadas las pruebas descritas en la sección anterior se presentan a continuación. Tabla 6.4 Resultados del caso de prueba GEOPROED Caso de prueba: GEOPROED Definición del atributo Map Viewer Resultado: OK Se definió un atributo del tipo Map Viewer llamado Ubicacion_solicitud (ver fig. 6.1). Figura 6.1 Definición de atributo Map Viewer Figura 6.2 Pestaña de atributos Una vez introducidos los valores requeridos, se dio clic en ok para guardar el atributo. El editor de proceso creó el atributo, como se muestra en la figura (6.2) Observaciones: El atributo fue definido a nivel proceso Los mapas seleccionados fueron: topp:tasmania_cities; topp:tasmania_roads; topp:tasmania_water_bodies; y topp:tasmania_state_boundaries El mapa seleccionado como capa base fue topp:tasmania_cities Los identificadores de los atributos de tipo espacial no deben contener guiones intermedios ni acentos. La dirección del servidor de mapas utilizado es Responsable de la prueba: Catalina Aranda Castillo Cargo: Autora 73

90 Capítulo 6. Pruebas Tabla 6.5 Resultados del caso de prueba GEOPROED Caso de prueba: GEOPROED Procesamiento del catálogo de mapas Resultado: OK Durante la definición del atributo de la prueba GEOPROED-01-01, se comprobó este caso de prueba. Después de introducir la dirección del servidor de mapas se dio clic en el botón Connect (ver fig. 6.3). Figura 6.3 Especificación del servidor de mapas Figura 6.4 Despliegue de catálogo procesado La acción provocó el evento de conexión con el servidor de mapas, se procesó el catálogo recibido extrayendo los nombres y atributos de los mapas disponibles en el servidor. Por último se desplegó la lista de los mapas disponibles (ver fig. 6.4). Observaciones: El catálogo es ordenado de acuerdo al sistema de referencia espacial (SRS) El tiempo que tardó el proceso de conexión y procesamiento fue de 1.3 segundos Responsable de la prueba: Catalina Aranda Castillo Cargo: Autora Tabla 6.6 Resultados del caso de prueba GEOPROED Caso de prueba: GEOPROED Modificación del atributo Map Viewer Resultado: OK Para modificar el atributo, se seleccionó el atributo, se dio clic en Edit (fig. 6.5), con lo cual se desplegó la ventana con las propiedades definidas con anterioridad (fig. 6.6). 74

91 Capítulo 6. Pruebas Figura 6.5 Pestaña de atributos del proceso Figura 6.6 Modificación del atributo Map Viewer El editor guardó los nuevos valores establecidos, lo cual se aprecia en la figura (6.7). Figura 6.7 Atributo modificado Observaciones: Para este caso de prueba la modificación consistió en eliminar un mapa de los seleccionados. El atributo modificado corresponde al creado en el caso de prueba GEOPROED Responsable de la prueba: Catalina Aranda Castillo Cargo: Autora 75

92 Capítulo 6. Pruebas Tabla 6.7 Resultados del caso de prueba GEOPROED Caso de prueba: GEOPROED Eliminación del atributo Map Viewer Resultado: OK Para realizar la eliminación del atributo se seleccionó y se dio clic en la opción Delete. El editor mandó un mensaje indicando que si se borra el atributo también será borrado el performer assignments asociado (ver fig. 6.8). Figura 6.8 Mensaje de advertencia al eliminar atributo Confirmado el mensaje anterior, el editor manda un mensaje de confirmación para borrar del atributo, para aceptar se eligió la opción Yes (ver fig. 6.9). Figura 6.9 Mensaje de confirmación para eliminar atributo 76

93 Capítulo 6. Pruebas El atributo fue eliminado como se aprecia en la figura (6.10). Figura 6.10 Atributo eliminado Observaciones: El atributo eliminado corresponde al creado en el caso de prueba GEOPROED y modificado en la prueba GEOPROED Responsable de la prueba: Catalina Aranda Castillo Cargo: Autora Tabla 6.8 Resultados del caso de prueba GEOPROED Caso de prueba: GEOPROED Propagación del atributo Map Viewer. Resultado: OK Una vez definido un atributo del tipo Map Viewer es reconocido de forma automática como atributo inherente para el resto de las actividades que conforman el proceso. Al revisar la pestaña de atributos en la actividad, en la sección de atributos inherentes se muestra cómo el editor de procesos ha reconocido al atributo del tipo Ubicacion_solicitud y lo ha propagado a esta actividad (ver fig. 6.11). 77

94 Capítulo 6. Pruebas Figura 6.11 Atributos propagados Al editar el formulario, los atributos inherentes fueron contemplados dentro del formulario como se muestra en la figura (6.12). Observaciones: Figura 6.12 Formulario con atributos inherentes El atributo corresponde al creado en el caso de prueba GEOPROED El atributo fue creado a nivel proceso y propagado al resto de las actividades que lo integran. Los atributos mostrados corresponden a la Actividad_1 Responsable de la prueba: Catalina Aranda Castillo Cargo: Autora 78

95 Capítulo 6. Pruebas Tabla 6.9 Resultados del caso de prueba GEOPROED Caso de prueba: GEOPROED Generación del código para el atributo Map Viewer. Resultado: OK Se eligió la opción Edit Xform de la pestaña atributos de propiedades del proceso, el editor desplegó un mensaje pidiendo autorización para guardar el proyecto y de esta manera sincronizarlo con xforms. Se aceptó (ver fig. 6.13). Figura 6.13 Mensaje de sincronización En la figura (6.14) se muestra la pantalla del editor de formularios, en la cual se muestran los atributos que contiene el formulario a guardar. Como se aprecia el editor reconoció el atributo de tipo Map Viewer, desplegando el nombre y su tipo. Figura 6.14 Formulario a guardar 79

96 Capítulo 6. Pruebas El editor de formularios xformeditor generó el código para el visor de mapas con las propiedades especificadas, la figura (6.15) muestra la ventana con el código generado. Figura 6.15 Código generado por xformeditor Observaciones: El formulario utilizado es el creado en la prueba GEOPROED El código generado corresponde al script para pedir los mapas y fijar los POIs, los estilos, el script de la ubicación de OpenLayers, las tablas y columnas para contener el visor. La sincronización es realizada para cargar los atributos definidos en el editor de procesos en el editor de formularios. Responsable de la prueba: Catalina Aranda Castillo Cargo: Autora Tabla 6.10 Resultados del caso de prueba GEOPROED Caso de prueba: GEOPROED Manipulación del atributo Map Viewer dentro del formulario Resultado: OK El editor de formularios permitió manipular el atributo Map Viewer. En la figura (6.16) se aprecia la posición inicial del atributo, posteriormente se subió de nivel como se aprecia en la figura (6.17). 80

97 Capítulo 6. Pruebas Figura 6.16 Posición original del atributo Figura 6.17 Atributo desplazado Por último el atributo fue movido al final del formulario como se muestra en la figura (6.18). Figura 6.18 Atributo cambiado de posición Observaciones: El formulario presentado es el creado a nivel de proceso en el caso de prueba GEOPROED El atributo del tipo Map Viewer se identifica con el nombre Ubicacion_solicitud Los movimientos realizados en el formulario presentado en la ventana fueron reflejados en el creado dentro del motor de workflow. Responsable de la prueba: Catalina Aranda Castillo Cargo: Autora 81

98 Capítulo 6. Pruebas Tabla 6.11 Resultados del caso de prueba GEOPROED-03 Caso de prueba: GEOPROED-03 Conexión de la aplicación Web con el servidor de mapas. Resultado: OK Al instanciar el proceso el formulario para capturar la información es cargado, mientras se ejecuta esta acción el visor de mapas realiza la conexión al servidor de mapas y despliega los mapas recibidos. Figura 6.19 Visor de mapas cargado con éxito La figura (6.19) muestra el resultado de este proceso, lo cual corresponde al resultado esperado en este caso de prueba. Observaciones: El tiempo que tardó la aplicación en cargar el formulario y establecer comunicación con el servidor de mapas fue de 4.9 segundos. Responsable de la prueba: Catalina Aranda Castillo Cargo: Autora Tabla 6.12 Resultados del caso de prueba GEOPROED Caso de prueba: GEOPROED Realizar zoom in sobre el mapa Resultado: OK En la figura (6.20) se muestra el visor de formularios con la escala manejada por defecto, la cual es 1:5. 82

99 Capítulo 6. Pruebas Figura 6.20 Escala por defecto del visor de mapas Al aplicarse el zoom in (acercamiento) el mapa fue visualizado a mayor escala, lo cual correspondió al resultado esperado (ver fig. 6.21). Figura 6.21 Visor de mapas con zoom in Observaciones: El acercamiento realizado en esta prueba fue de 1:5M La escala máxima soportada por el visor de mapas es de 1: 166M El tiempo tomado para realizar el cambio de escala fue de 0.9 segundos Responsable de la prueba: Catalina Aranda Castillo Cargo: Autora 83

100 Capítulo 6. Pruebas Tabla 6.13 Resultados del caso de prueba GEOPROED Caso de prueba: GEOPROED Realizar zoom out sobre mapa Resultado: OK Una vez realizado el zoom out al mapa en la prueba GEOPROED-04-01, se aplicó la operación de zoom out para regresarlo a su escala original como se aprecia en la figura (6.22). Figura 6.22 Visor de mapas con zoom out aplicado Observaciones: Al realizar el acercamiento, éste se realizó en menor tiempo, debido a que los datos ya se encontraban cargados en memoria. El tiempo tomado para realizar el cambio de escala fue de 0.2 segundos Responsable de la prueba: Catalina Aranda Castillo Cargo: Autora Tabla 6.14 Resultados del caso de prueba GEOPROED Caso de prueba: GEOPROED Paneo sobre el mapa Resultado: OK Al posicionar el puntero sobre el mapa, darle clic a una región de éste y mover el cursor en sentido contrario fue posible realizar el paneo sobre el mapa. Esta operación se puede realizar hacia cualquier dirección. La figura (6.23) muestra el mapa después de aplicarse un paneo en dirección noroeste. Por tanto, el resultado obtenido de esta prueba corresponde con el esperado. 84

101 Capítulo 6. Pruebas Figura 6.23 Visor de mapas con paneo aplicado Observaciones: El paneo también puede realizarse con la flechas de movimiento situadas en la esquina superior izquierda, esta opción sólo permite el movimiento hacia los cuatro puntos cardinales. Responsable de la prueba: Catalina Aranda Castillo Cargo: Autora Tabla 6.15 Resultados del caso de prueba GEOPROED Caso de prueba: GEOPROED Manipulación de capas Resultado: OK En el menú desplegable situado en la parte superior derecha del visor de mapas (ver fig. 6.24), se da clic a las casillas de verificación para activar o desactivar la visibilidad de una capa. Figura 6.24 Capas disponibles en el visor de mapas 85

102 Capítulo 6. Pruebas En la figura (6.25) se muestra la desactivación de las capas: topp:tasmania_cities; topp:tasmania_water_bodies; y topp:tasmania_state_boundaries, quedando activa la capa topp:tasmania_roads. Figura 6.25 Vista de la capa carreteras La siguiente imagen corresponde al visor de mapas con la capa topp:tasmania_water_bodies como única capa activa (ver fig. 6.26). Figura 6.26 Capa de lagos activada Los resultados obtenidos corresponden a los esperados, por tanto esta prueba es evaluada satisfactoriamente. Observaciones: La manipulación de capas no incluye a la capa base. Responsable de la prueba: Catalina Aranda Castillo Cargo: Autora 86

103 Capítulo 6. Pruebas Tabla 6.16 Resultados del caso de prueba GEOPROED Caso de prueba: GEOPROED Inserción de puntos de interés (POI) Resultado: OK Cuando se dio clic sobre el mapa se marcó un punto de interés, lo cual corresponde al resultado esperado en esta prueba (ver fig. 6.27). Figura 6.27 Marcado de punto de interés Observaciones: Se ha restringido el visor de mapas de modo que sólo permita el marcado de un punto. En caso de que el usuario de clic en otro lugar el punto es removido y pintado en el lugar del segundo clic. Responsable de la prueba: Catalina Aranda Castillo Cargo: Autora Tabla 6.17 Resultados del caso de prueba GEOPROED Caso de prueba: GEOPROED Almacenamiento de puntos de interés Resultado: OK Cuando se marca el punto de interés (ver fig. 6.28) los valores son cargados en sus respectivos campos. 87

104 Capítulo 6. Pruebas Figura 6.28 Almacenamiento de punto de interés Observaciones: El almacén del punto de interés se realiza al enviar los datos del formulario al motor de workflow. Responsable de la prueba: Catalina Aranda Castillo Cargo: Autora Tabla 6.18 Resultados del caso de prueba GEOPROED Caso de prueba: GEOPROED Recuperación de puntos de interés Resultado: OK Cuando se inició la actividad que prosigue al inicio del proceso, en el cual se marcó el punto de interés, la aplicación cargo el visor de mapas y dibujó el punto almacenado, permitiendo de esta forma la continuidad de la información y su posterior uso (ver fig. 6.29). Figura 6.29 Recuperación de punto de interés 88

105 Capítulo 6. Pruebas Observaciones: El tiempo que tardó la aplicación en cargar el formulario y establecer comunicación con el servidor de mapas fue de 1.4 segundos. Cuando el visor de mapas es cargado y se detecta un punto marcado el visor se bloquea para que otro punto no pueda ser fijado y de esta forma modificar la información introducida con anterioridad. Responsable de la prueba: Catalina Aranda Castillo Cargo: Autora Tabla 6.19 Resultados del caso de prueba GEOPROED-06 Caso de prueba: GEOPROED-06 Reconocimiento de atributos Map Viewer a partir de un proceso existente. Resultado: OK El archivo Solicitud_1.0.XPDL contiene el código del proceso de negocio, en él se detalla cada elemento que conforma el proceso. En la figura (6.30) se muestra la parte en donde se define el atributo Map Viewer. Figura 6.30 Código del proceso existente En la opción open del editor de procesos, se eligió el archivo XPDL a abrir, de los archivos existentes se seleccionó Solicitud_1.0.XPDL (ver fig. 6.31). Una vez seleccionado el archivo se realizó el reconocimiento de todos los elementos que conforman al proceso, los cuales fueron cargados a memoria. 89

106 Capítulo 6. Pruebas Figura 6.31 Selección de archivo XPDL a abrir Una vez reconocidos y cargados los elementos del proceso, se accedió a las propiedades del proceso, en la pestaña atributos se comprobó que el atributo Ubicacion perteneciente al tipo Map Viewer fue reconocido y cargado dentro del modelo (ver fig. 6.32). Figura 6.32 Reconocimiento del atributo Map Viewer Para comprobar que el atributo es manipulable se procedió a ver sus propiedades a través de la opción Edit, la figura (6.33) muestra las propiedades de dicho atributo, las cuales pueden ser modificadas como se ha explicado en el caso de prueba GEOPROED